[pkg-wpa-devel] Bug#610931: Please build wpasupplicant-udeb

[Gaudenz Steinlin]

Excerpts from Kel Modderman's message of 2011-07-26 15:14:11 +0200:
> Hi,
> 
> On Mon, 25 Jul 2011 09:34:27 AM Gaudenz Steinlin wrote:
> > > > > > > Has there been any solution for the netcfg integration already,
> > > > > > > see <201011041811.11753.kel at otaku42.de> [1], referring to the
> > > > > > > originally proposed introduction of embedded source copies of
> > > > > > > wpasuppliant's wpa_ctrl.[hc] into netcfg. Please also keep in
> > > > > > > mind that crda/ wireless-regdb is required for accessing
> > > > > > > channels 11-13/14 on modern drivers.
> > > > > > 
> > > > > > I've applied the existing WPA netcfg support patches developed by
> > > > > > Glenn Saberton, and they do appear to include a (stripped down)
> > > > > > wpa_ctrl.c.
> > > > > 
> > > > > That stripped down crap probably was extracted from a sideline
> > > > > project (python-wpactrl) I was working on, and is not good long term
> > > > > solution.
> > > > > 
> > > > > wpa_ctrl.{c,h} from current wpasupplicant source tree have lots more
> > > > > dependency on other stuff. Extracting and patching wpa_ctrl.{c,h} to
> > > > > be standalone is something which should be avoided - I just do not
> > > > > know how currently.
> > > > > 
> > > > > Asked upstream wpa_supplicant if wpa_ctrl could be provided in a way
> > > > > where it could be a shared library but received no response.
> > > > 
> > > > Is there any progress on this?
> > > 
> > > Nope.
> > 
> > Do you think it's worth poking about this again? The current code in
> > netcfg works (at least for the debconf wpa-psk network), but a real
> > library would be nicer ;-).
> 
> It cannot hurt to ask. I've already asked before, so maybe someone else can 
> this time :).

I'll see what I can do.

> 
> > 
> > > > > > I
> > > > > > have no idea what the story is with crda/wireless-regdb, as I said
> > > > > > before, I don't know anything about WPA.  If you'd like to help
> > > > > > out, though, your knowledge would be greatly valued.
> > > > > 
> > > > > I wouldn't mind helping out, don't know how though, Have little idea
> > > > > about D-I environment and took long enough to just reply to this
> > > > > request to feel a little embarrassed.
> > > > > 
> > > > > Also haven't seen the proposed change to netcfg anytime in recent
> > > > > past to comment further. Can that be reviewed?
> > > > 
> > > > It's in branch people/womble/wpa of
> > > > git://git.debian.org/git/d-i/netcfg.
> > > > 
> > > > Gaudenz
> > > 
> > > Thanks for the link.
> > 
> > Do you have time to look at the code in the next days? Otherwise I'll
> > probably just merge as it is now and we can fix things later if there
> > are problems.
> 
> Do not wait for any activity from me, I'm currently not very active with 
> Debian work - mostly keeping up with basic maintenace related tasks.
> 
> Not familiar with netcfg or the debian-installer environment at all
> yet.

OK. How do you feel about me NMUing wpa_supplicant to add the udeb? I
added an updated patch for the udeb to this mail. If you are OK I'll
upload this as an NMU after libnl1-udeb enters the archive.

> 
> > 
> > I have another yet unresolved problem: With the proposed udeb
> > configuration from the original patch and using the netlink driver I can
> > connect to the network, but DHCP does not work. When I build a udeb with
> > the same
> > configuration as for the normal linux package minus DBUS and smartcard
> > support it works. Do you know which options I need to include to get a
> > package where DHCP also works with the netlink driver?
> 
> From the top of my head I do not know why you observe this difference in 
> behaviour. Where WEXT works, nl80211 should work and vice versa.

I found out that I have to enable either CONFIG_IEEE8021X_EAPOL or
CONFIG_WPS. I don't know why it is like this, but both options don't
seem to be related to the problem. This is probably a bug in
wpa_supplicant where a #ifdef enables some code that should be enabled
unconditionally. But a quick grep through the source code did not show
something suspicious. If I get around to it I'll report a bug
upstream.

Gaudenz
-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_wpasupplicant_udeb_v2.patch
Type: application/octet-stream
Size: 3964 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/attachments/20110726/bd9f03ed/attachment.obj>