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