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

[Maxim Levitsky <maximlevitsky gmail com>]

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.

- 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 )

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
correctly this, could nm treat this as a special case, and show some
different icon, so user understands that signal strength isn't 0, but it
unavailable  (I understand that it is impossible to know it, as there is
no ap)



Best regards,
	Maxim Levitsky