Re: NM + IBSS + encryption (was: WPA + IBSS?)

[Dan Williams <dcbw redhat com>]

On Fri, 2008-12-12 at 21:31 +0200, Maxim Levitsky wrote:
> On Fri, 2008-12-12 at 08:11 -0500, Dan Williams wrote:
> > On Fri, 2008-12-12 at 12:08 +0200, Maxim Levitsky wrote:
> > > On Thu, 2008-12-11 at 23:26 -0500, Dan Williams wrote:
> > > > On Fri, 2008-12-12 at 04:00 +0200, Maxim Levitsky wrote:
> > > > > I am testing now the connection sharing feature of NM.
> > > > > It mostly works, but I found out that I can't create an ad hoc
> > wpa2
> > > > > protected network. 
> > > > > Is this possible (nm creates it, but it doesn't work)?
> > > > 
> > > > It should be possible, yes, but the first question is "does the
> > driver
> > > > work?"  This was the major problem when I was actually developing
> > the
> > > > feature, and I had to go fix the drivers and supplicant to make it
> > work.
> > > > So, make sure you have at least the following things:
> > > > 
> > > > - 2.6.26 or later kernel
> > > >    * mac80211: the IBSS search interval was too short, plus the
> > stack
> > > > never notified userspace that it had successfully created the
> > network
> > > >        872ba53395b2a8be08c3ea2d39e225e5b4a8cb40
> > > >        507b06d0622480f8026d49a94f86068bb0fd6ed6
> > > I use 2.6.28-rc7, so I guees that should be included?
> > > 
> > > I don't see first commit, but do see second in git history
> > > 
> > > 
> > > > 
> > > >    * ipw2200: the driver wouldn't expire old BSS entries when
> > creating
> > > > and IBSS and hit an internal BSS limit
> > > >        a6d4eae80157830af9c9d80de2daf6611696a34e
> > > I don't have this driver, iwl3945 here.
> > > 
> > > > 
> > > > - wpa_supplicant 0.6.6 or later
> > > >    * the wext driver was not correctly downing the interface and
> > > > bringing it back up again when switching from infra to ibss mode
> > > >        1d3c75b3b6663ed9f3a9a8dea8d47056cce2680f
> > > > 
> > > >    * the ordering of operations after mode switch was wrong
> > > >        ec5f180a24cd31ba9d3d7f2abc9dc557fd16602f
> > > > 
> > > >    * the supplicant wasn't waiting long enough for IBSS creation
> > > >        1d3c75b3b6663ed9f3a9a8dea8d47056cce2680f
> > > > 
> > > I install it soon.
> > > 
> > > > Then, see if you can set up a supplicant config that works for
> > you, and
> > > > if the supplicant can do it correctly, then we have a chance of
> > getting
> > > > NM to do it correctly.
> > > > 
> > > Just curios, what I understand is that wpa_supplicant deals with
> > > periodic key update, but I have seen that it also scans the network,
> > > implements roaming, etc..
> > 
> > wpa_supplicant controls wifi devices, irregardless of the "wpa" in the
> > name.
> 
> Thanks a lot for explanation.
> 
> 
> Let me tell current state of ad-hoc support:
> 
> 
> - good old unencrypted ad-hoc works perfectly, nat does its job, second
> system sees the network, association always work, also I tested
> connection sharing on wired connection and it works, this is very nice
> feature indeed.
> 
> - WEP encryption doesn't work well:
> When I set up the the ad-hoc wep on the iwl3945, network manager sets up
> an unencrypted network, as I can connect to it without password.
> also iwconfig confirms that there is no encryption.
> When I set it second time, the encryption key _is_ turned on, but
> beacons (at least the iwlist scan on other system) still specify and
> unencrypted network, so nm refuses to use wep for it, and if I set the
> key manually using iwconfig, while nm is trying to get ip settings,
> connection starts working.

This indicates that you don't have some of the driver or wpa_supplicant
updates; most likely it's the wpa_supplicant mode-switch patches you're
missing:

59c9707863336c1255936c755d24c8eb1ed8db2f
ec5f180a24cd31ba9d3d7f2abc9dc557fd16602f


> - WPA doesn't work at all.
> I tried using wpa_supplicant 0.6.6,but nm refuses to use it
> (I use nm from  http://ppa.launchpad.net/network-manager )

Make sure you have the right activation file
in /usr/share/dbus-1/system-services for wpa_supplicant, and that it's
launched with the "-u" flag.

> And there is one unpleasant cosmetic bug, it appears that both iwl3945
> and ath5k don't report any statistics about ad-hoc connection, and
> report 0 as a signal strength and noise level, thus the nm icon shows

This is a driver issue, and the drivers need to be fixed to report sane
signal strength in ad-hoc mode.  But yes, maybe we could special-case
it.

Dan