mac80211 ad-hoc mode problems

mac80211 ad-hoc mode problems

[Dan Williams]

Hi,

While adding adhoc shared network support to NM, I ran into a few
mac80211 problems.

1) doesn't send SIOCGIWAP event on successful adhoc activation (patch
forthcoming)

2) takes a _really_ long time to create an adhoc network.  This is
controlled by IEEE80211_IBSS_JOIN_TIMEOUT.  Why is that 20 seconds?  Th=
e
problem here is that wpa_supplicant has an association timer shorter
than =EF=BB=BFIEEE80211_IBSS_JOIN_TIMEOUT and will re-try the connectio=
n,
causing mac80211 to reset ifsta->ibss_join_req.  FullMAC drivers will
simply look in their scan list (and optionally perform one scan) and if
the IBSS isn't found, create it.  I'd really like to
take =EF=BB=BFIEEE80211_IBSS_JOIN_TIMEOUT down to 5 or 7 seconds.  This=
 is only
the initial IBSS creation, IBSS merging will still be in effect.  I
simply thing 20 seconds is really too long here.

3) doesn't send NULL SIOCGIWAP disassoc events when the device goes dow=
n
or the module is removed.  Where's the best place to put the event on
module remove?

4) Is the association expected to survive a up->down->up sequence?  If
not, then we should be sending NULL SIOCGIWAP event whenever dev_close(=
)
gets called.

5) mac80211 requires the device to be down when changing modes.  That's
fine; but requires a patch to wpa_supplicant to handle this.  This woul=
d
cause failures when switching AP that were different modes from NM.
See:

http://lists.shmoo.com/pipermail/hostap/2008-June/017894.html

Dan

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211 ad-hoc mode problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]

On Tue, 2008-06-03 at 21:41 -0400, Dan Williams wrote:
> Hi,
> 
> While adding adhoc shared network support to NM, I ran into a few
> mac80211 problems.
> 
> 1) doesn't send SIOCGIWAP event on successful adhoc activation (patch
> forthcoming)

Thanks.

> 2) takes a _really_ long time to create an adhoc network.  This is
> controlled by IEEE80211_IBSS_JOIN_TIMEOUT.  Why is that 20 seconds?  The
> problem here is that wpa_supplicant has an association timer shorter
> than IEEE80211_IBSS_JOIN_TIMEOUT and will re-try the connection,
> causing mac80211 to reset ifsta->ibss_join_req.  FullMAC drivers will
> simply look in their scan list (and optionally perform one scan) and if
> the IBSS isn't found, create it.  I'd really like to
> take IEEE80211_IBSS_JOIN_TIMEOUT down to 5 or 7 seconds.  This is only
> the initial IBSS creation, IBSS merging will still be in effect.  I
> simply thing 20 seconds is really too long here.

Yeah, I don't know why it is that long. Jouni, do you remember maybe?
I'm ok with reducing it.

> 3) doesn't send NULL SIOCGIWAP disassoc events when the device goes down
> or the module is removed.  Where's the best place to put the event on
> module remove?

Huh? Why does that matter, the network interface is going away so...?

> 4) Is the association expected to survive a up->down->up sequence?  If
> not, then we should be sending NULL SIOCGIWAP event whenever dev_close()
> gets called.

No, it's not, yes, we probably should send that event somewhere. Is it
ok to send the event while not associated?

> 5) mac80211 requires the device to be down when changing modes.  That's
> fine; but requires a patch to wpa_supplicant to handle this.  This would
> cause failures when switching AP that were different modes from NM.
> See:
> 
> http://lists.shmoo.com/pipermail/hostap/2008-June/017894.html

Don't understand. How can you switch to an IBSS AP? :)

It's probably fairly easy to remove this restriction because they all
use ieee80211_if_sta internally (sta, ibss, mesh) but since I don't care
too much about IBSS and see mesh as being quite different, I have no
motivation to try (and test) this.

johannes

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 ad-hoc mode problems

[Jouni Malinen]

On Wed, Jun 04, 2008 at 11:00:00AM +0200, Johannes Berg wrote:
> On Tue, 2008-06-03 at 21:41 -0400, Dan Williams wrote:
> > 2) takes a _really_ long time to create an adhoc network.  This is
> > controlled by IEEE80211_IBSS_JOIN_TIMEOUT.  Why is that 20 seconds?

> Yeah, I don't know why it is that long. Jouni, do you remember maybe?
> I'm ok with reducing it.

Can't remember.. The only thing I can come up with is that 20 was the
next round number that is larger than IEEE80211_SCAN_INTERVAL_SLOW
defined on the previous line.. ;-) Anyway, I don't see why we would need
to wait that long. It should be enough to wait for a full scan of all
channels to be completed. It is of course nicer to avoid creating a new
IBSS if there is an existing one, but as long as merging works, it
should be fine to reduce this timeout.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: mac80211 ad-hoc mode problems

[Dan Williams]

On Wed, 2008-06-04 at 12:16 +0300, Jouni Malinen wrote:
> On Wed, Jun 04, 2008 at 11:00:00AM +0200, Johannes Berg wrote:
> > On Tue, 2008-06-03 at 21:41 -0400, Dan Williams wrote:
> > > 2) takes a _really_ long time to create an adhoc network.  This is
> > > controlled by IEEE80211_IBSS_JOIN_TIMEOUT.  Why is that 20 seconds?
> 
> > Yeah, I don't know why it is that long. Jouni, do you remember maybe?
> > I'm ok with reducing it.
> 
> Can't remember.. The only thing I can come up with is that 20 was the
> next round number that is larger than IEEE80211_SCAN_INTERVAL_SLOW
> defined on the previous line.. ;-) Anyway, I don't see why we would need
> to wait that long. It should be enough to wait for a full scan of all
> channels to be completed. It is of course nicer to avoid creating a new
> IBSS if there is an existing one, but as long as merging works, it
> should be fine to reduce this timeout.

Ok, I'll drop it down to 5 seconds if that's OK with you.  That's still
the same amount of time as the wpa_supplicant assoc_failed auth timeout
in wpa_supplicant_associate() though, so they could still step on each
other.  Not quite sure what to do about that except bump up the
wpa_supplicant assoc_failed timeout by a few more seconds?

dan

Re: mac80211 ad-hoc mode problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]


> > Can't remember.. The only thing I can come up with is that 20 was the
> > next round number that is larger than IEEE80211_SCAN_INTERVAL_SLOW
> > defined on the previous line.. ;-) Anyway, I don't see why we would need
> > to wait that long. It should be enough to wait for a full scan of all
> > channels to be completed. It is of course nicer to avoid creating a new
> > IBSS if there is an existing one, but as long as merging works, it
> > should be fine to reduce this timeout.
> 
> Ok, I'll drop it down to 5 seconds if that's OK with you.  That's still
> the same amount of time as the wpa_supplicant assoc_failed auth timeout
> in wpa_supplicant_associate() though, so they could still step on each
> other.  Not quite sure what to do about that except bump up the
> wpa_supplicant assoc_failed timeout by a few more seconds?

Fine with me either way. Like I said, I don't really care too much about
IBSS and appreciate the time you're investing to make it work.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: mac80211 ad-hoc mode problems

[Jouni Malinen]

On Wed, Jun 04, 2008 at 10:18:24AM -0400, Dan Williams wrote:

> Ok, I'll drop it down to 5 seconds if that's OK with you.  That's still
> the same amount of time as the wpa_supplicant assoc_failed auth timeout
> in wpa_supplicant_associate() though, so they could still step on each
> other.  Not quite sure what to do about that except bump up the
> wpa_supplicant assoc_failed timeout by a few more seconds?

As long as there is still enough time for the scan to be completed
before deciding to create a new IBSS. I don't remember how that code
worked, so I don't know whether 5 second as the IBSS timeout will
guarantee this for every case. If there are any problems in providing
such guarantee, I have nothing against increasing the wpa_supplicant
timeout for IBSS. I might do that anyway since there is not really much
point in timing out IBSS join/create in most cases.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: mac80211 ad-hoc mode problems

[Dan Williams]

On Wed, 2008-06-04 at 18:55 +0300, Jouni Malinen wrote:
> On Wed, Jun 04, 2008 at 10:18:24AM -0400, Dan Williams wrote:
> 
> > Ok, I'll drop it down to 5 seconds if that's OK with you.  That's still
> > the same amount of time as the wpa_supplicant assoc_failed auth timeout
> > in wpa_supplicant_associate() though, so they could still step on each
> > other.  Not quite sure what to do about that except bump up the
> > wpa_supplicant assoc_failed timeout by a few more seconds?
> 
> As long as there is still enough time for the scan to be completed
> before deciding to create a new IBSS. I don't remember how that code
> worked, so I don't know whether 5 second as the IBSS timeout will
> guarantee this for every case. If there are any problems in providing
> such guarantee, I have nothing against increasing the wpa_supplicant
> timeout for IBSS. I might do that anyway since there is not really much
> point in timing out IBSS join/create in most cases.

That's probably the best solution; to increase the supplicant's timeout
for the IBSS case and decrease the mac80211 IBSS create timeout.

Dan

Re: mac80211 ad-hoc mode problems

[Dan Williams]

On Wed, 2008-06-04 at 11:00 +0200, Johannes Berg wrote:
> On Tue, 2008-06-03 at 21:41 -0400, Dan Williams wrote:
> > Hi,
> >=20
> > While adding adhoc shared network support to NM, I ran into a few
> > mac80211 problems.
> >=20
> > 1) doesn't send SIOCGIWAP event on successful adhoc activation (pat=
ch
> > forthcoming)
>=20
> Thanks.
>=20
> > 2) takes a _really_ long time to create an adhoc network.  This is
> > controlled by IEEE80211_IBSS_JOIN_TIMEOUT.  Why is that 20 seconds?=
  The
> > problem here is that wpa_supplicant has an association timer shorte=
r
> > than =EF=BB=BFIEEE80211_IBSS_JOIN_TIMEOUT and will re-try the conne=
ction,
> > causing mac80211 to reset ifsta->ibss_join_req.  FullMAC drivers wi=
ll
> > simply look in their scan list (and optionally perform one scan) an=
d if
> > the IBSS isn't found, create it.  I'd really like to
> > take =EF=BB=BFIEEE80211_IBSS_JOIN_TIMEOUT down to 5 or 7 seconds.  =
This is only
> > the initial IBSS creation, IBSS merging will still be in effect.  I
> > simply thing 20 seconds is really too long here.
>=20
> Yeah, I don't know why it is that long. Jouni, do you remember maybe?
> I'm ok with reducing it.
>=20
> > 3) doesn't send NULL SIOCGIWAP disassoc events when the device goes=
 down
> > or the module is removed.  Where's the best place to put the event =
on
> > module remove?
>=20
> Huh? Why does that matter, the network interface is going away so...?

I guess it doesn't, but traditionally drivers have sent a disassoc even=
t
when they go down/away.

> > 4) Is the association expected to survive a up->down->up sequence? =
 If
> > not, then we should be sending NULL SIOCGIWAP event whenever dev_cl=
ose()
> > gets called.
>=20
> No, it's not, yes, we probably should send that event somewhere. Is i=
t
> ok to send the event while not associated?

Yeah, there's no ordering or pairing guarantee for SIOCGIWAP events
since there isn't an association transaction model with WEXT.

> > 5) mac80211 requires the device to be down when changing modes.  Th=
at's
> > fine; but requires a patch to wpa_supplicant to handle this.  This =
would
> > cause failures when switching AP that were different modes from NM.
> > See:
> >=20
> > http://lists.shmoo.com/pipermail/hostap/2008-June/017894.html
>=20
> Don't understand. How can you switch to an IBSS AP? :)

Sorry, when switching from BSS -> IBSS, like picking an IBSS from the
NetworkManager menu while you're connected to an AP.  Or, creating a ne=
w
IBSS while connected.

> It's probably fairly easy to remove this restriction because they all
> use ieee80211_if_sta internally (sta, ibss, mesh) but since I don't c=
are
> too much about IBSS and see mesh as being quite different, I have no
> motivation to try (and test) this.

I think it's fine to leave it as-is.  At least prism54 required the
interface to be !IFF_UP while changing modes, and I think madwifi has
required this too at some point.  This can be handled in the supplicant=
,
Jouni and I have already worked out what should be done and I'm going t=
o
update the linked patch.

Thanks,
Dan

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211 ad-hoc mode problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]


> > > 4) Is the association expected to survive a up->down->up sequence?  If
> > > not, then we should be sending NULL SIOCGIWAP event whenever dev_close()
> > > gets called.
> > 
> > No, it's not, yes, we probably should send that event somewhere. Is it
> > ok to send the event while not associated?
> 
> Yeah, there's no ordering or pairing guarantee for SIOCGIWAP events
> since there isn't an association transaction model with WEXT.

Yeah, true. You can either stick it right into ieee80211_stop, make a
new mlme-stop function that is called from there, or maybe do it when
the AP's sta_info struct is removed?

> > > 5) mac80211 requires the device to be down when changing modes.  That's
> > > fine; but requires a patch to wpa_supplicant to handle this.  This would
> > > cause failures when switching AP that were different modes from NM.
> > > See:
> > > 
> > > http://lists.shmoo.com/pipermail/hostap/2008-June/017894.html
> > 
> > Don't understand. How can you switch to an IBSS AP? :)
> 
> Sorry, when switching from BSS -> IBSS, like picking an IBSS from the
> NetworkManager menu while you're connected to an AP.  Or, creating a new
> IBSS while connected.

Ok, but that means you disconnect so you lose all configuration anyway.

> > It's probably fairly easy to remove this restriction because they all
> > use ieee80211_if_sta internally (sta, ibss, mesh) but since I don't care
> > too much about IBSS and see mesh as being quite different, I have no
> > motivation to try (and test) this.
> 
> I think it's fine to leave it as-is.  At least prism54 required the
> interface to be !IFF_UP while changing modes, and I think madwifi has
> required this too at some point.  This can be handled in the supplicant,
> Jouni and I have already worked out what should be done and I'm going to
> update the linked patch.

Sure. As far as I understand, even if mac80211 would change in the
future the patch Jouni asked for would then not down the interface.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]