Please take a look at the following log:
http://bu3sch.de/misc/crda.JPG
Note the ordering of the events.
Hostapd starts up and tells the kernel what country we're in.
Then the kernel calls CRDA, _but_ hostapd goes on with its business
before CRDA has finished its work.
So hostapd does set the channel before regulatory stuff is uploaded by CRDA
to the kernel. That fails, if we use channel 13, which is allowed in DE,
but not in the default regulatory settings.
On the second attempt to start hostapd it works fine, of course, because
the regulatory tables are already uploaded.
Any ideas?
--
Greetings, Michael.
On Monday 29 December 2008 04:45:22 Dan E wrote:
>
> On Sun, 28 Dec 2008 00:08:14 +0200, "Jouni Malinen" <[email protected]> said:
> > On Sat, Dec 27, 2008 at 10:08:20PM +0100, Michael Buesch wrote:
> > > Please take a look at the following log:
> > > http://bu3sch.de/misc/crda.JPG
> > >
> > > Note the ordering of the events.
> > > Hostapd starts up and tells the kernel what country we're in.
> > > Then the kernel calls CRDA, _but_ hostapd goes on with its business
> > > before CRDA has finished its work.
> >
> > Yes, because the netlink message was completed and hostapd assumes
> > everything is ready at that point. Ignoring the complexity in the kernel
> > (+ CRDA as a helper), this looks like reasonable expectation to make for
> > NL80211_CMD_REQ_SET_REG operation. There is no other mechanism that
> > would notify hostapd (or any other program setting country for that
> > matter) when the operation was actually fully completed and polling for
> > channel changes up to a timeout is not very appealing either.
> >
> > Unfortunately, I don't see an easy fix for this.
>
> This sounds like it's broken by design. Hostapd should not send
> NL80211_CMD_REQ_SET_REG if it is unable to evaluate the result. If it's
> necessary to do "iw reg set foobar" in a script prior to invoking
> hostapd, then why does hostapd even bother?
>
hostapd isn't broken. The CMD_REQ_SET_REG should block until regulatory
settings are done. It currently doesn't, because that's hard to implement (probably
by design).
--
Greetings, Michael.
On Sun, 28 Dec 2008 00:08:14 +0200, "Jouni Malinen" <[email protected]> said:
> On Sat, Dec 27, 2008 at 10:08:20PM +0100, Michael Buesch wrote:
> > Please take a look at the following log:
> > http://bu3sch.de/misc/crda.JPG
> >
> > Note the ordering of the events.
> > Hostapd starts up and tells the kernel what country we're in.
> > Then the kernel calls CRDA, _but_ hostapd goes on with its business
> > before CRDA has finished its work.
>
> Yes, because the netlink message was completed and hostapd assumes
> everything is ready at that point. Ignoring the complexity in the kernel
> (+ CRDA as a helper), this looks like reasonable expectation to make for
> NL80211_CMD_REQ_SET_REG operation. There is no other mechanism that
> would notify hostapd (or any other program setting country for that
> matter) when the operation was actually fully completed and polling for
> channel changes up to a timeout is not very appealing either.
>
> Unfortunately, I don't see an easy fix for this.
This sounds like it's broken by design. Hostapd should not send
NL80211_CMD_REQ_SET_REG if it is unable to evaluate the result. If it's
necessary to do "iw reg set foobar" in a script prior to invoking
hostapd, then why does hostapd even bother?
--
http://www.fastmail.fm - Accessible with your email software
or over the web
On Sat, Dec 27, 2008 at 10:08:20PM +0100, Michael Buesch wrote:
> Please take a look at the following log:
> http://bu3sch.de/misc/crda.JPG
>
> Note the ordering of the events.
> Hostapd starts up and tells the kernel what country we're in.
> Then the kernel calls CRDA, _but_ hostapd goes on with its business
> before CRDA has finished its work.
Yes, because the netlink message was completed and hostapd assumes
everything is ready at that point. Ignoring the complexity in the kernel
(+ CRDA as a helper), this looks like reasonable expectation to make for
NL80211_CMD_REQ_SET_REG operation. There is no other mechanism that
would notify hostapd (or any other program setting country for that
matter) when the operation was actually fully completed and polling for
channel changes up to a timeout is not very appealing either.
Unfortunately, I don't see an easy fix for this. cfg80211 would somehow
need to block sending of the NL80211_CMD_REQ_SET_REG response until CRDA
has completed doing whatever it is going to do (is that even something
that cfg80211 knows when the final step was completed?).. I haven't
taken a look at all the details, but I've asked for this kind of wait in
the past and at least it did not seem to be trivial to add since this
has not been fixed yet ;-).
--
Jouni Malinen PGP id EFC895FA
On Monday 29 December 2008 16:56:13 Luis R. Rodriguez wrote:
> On Mon, Dec 29, 2008 at 02:28:00AM -0800, Michael Buesch wrote:
> > On Monday 29 December 2008 04:45:22 Dan E wrote:
> > >
> > > On Sun, 28 Dec 2008 00:08:14 +0200, "Jouni Malinen" <[email protected]> said:
> > > > On Sat, Dec 27, 2008 at 10:08:20PM +0100, Michael Buesch wrote:
> > > > > Please take a look at the following log:
> > > > > http://bu3sch.de/misc/crda.JPG
> > > > >
> > > > > Note the ordering of the events.
> > > > > Hostapd starts up and tells the kernel what country we're in.
> > > > > Then the kernel calls CRDA, _but_ hostapd goes on with its business
> > > > > before CRDA has finished its work.
> > > >
> > > > Yes, because the netlink message was completed and hostapd assumes
> > > > everything is ready at that point. Ignoring the complexity in the kernel
> > > > (+ CRDA as a helper), this looks like reasonable expectation to make for
> > > > NL80211_CMD_REQ_SET_REG operation. There is no other mechanism that
> > > > would notify hostapd (or any other program setting country for that
> > > > matter) when the operation was actually fully completed and polling for
> > > > channel changes up to a timeout is not very appealing either.
> > > >
> > > > Unfortunately, I don't see an easy fix for this.
> > >
> > > This sounds like it's broken by design. Hostapd should not send
> > > NL80211_CMD_REQ_SET_REG if it is unable to evaluate the result. If it's
> > > necessary to do "iw reg set foobar" in a script prior to invoking
> > > hostapd, then why does hostapd even bother?
> > >
> >
> > hostapd isn't broken. The CMD_REQ_SET_REG should block until regulatory
> > settings are done. It currently doesn't, because that's hard to implement (probably
> > by design).
>
> It means adding a timer and picking a reasonable value for the timeout,
> then waiting for a response through nl80211 and disabling the timer from there and
> then finally sending the reply back. This seems rather hackish but we can implement
> if its desirable. I suppose the worst case scenerio would be CRDA and the
> regulatory db in an NFS mount or something like that.
I think this wouldn't be hackish, but do we actually _know_ when crda has finished
uploading regulatory information? Does it do it all in one step?
> An alternative would be for us to add a netlink event once the regultory rule is
> set in place. If the first approach is the better path to take then this secondary
> netlink event can be sent anyway as informational.
Would also be OK, but would also require knowledge about "did we finish already".
Do we have this knowledge?
--
Greetings, Michael.
On Mon, 2008-12-29 at 08:18 -0800, Luis R. Rodriguez wrote:
> > I think this wouldn't be hackish, but do we actually _know_ when crda has finished
> > uploading regulatory information? Does it do it all in one step?
>
> It would go in through another nl80211 command, NL80211_CMD_SET_REG. nl80211 eventually
> calls set_regdom() and this will set it, so if all goes well we can remove the timer
> at the end if its active (other means can call CRDA like for 802.11d or the wireless core
> upon initialization).
Can we have a command to _get_ regulatory settings? I think it would be
useful. Then hostapd could wait until the correct settings are active.
If it doesn't happen after some time, hostapd should exit with an error.
It would be even better if hostapd could wait for an event notifying of
the regulatory settings change.
--
Regards,
Pavel Roskin
On Mon, Dec 29, 2008 at 08:04:27AM -0800, Michael Buesch wrote:
> On Monday 29 December 2008 16:56:13 Luis R. Rodriguez wrote:
> > On Mon, Dec 29, 2008 at 02:28:00AM -0800, Michael Buesch wrote:
> > > On Monday 29 December 2008 04:45:22 Dan E wrote:
> > > >
> > > > On Sun, 28 Dec 2008 00:08:14 +0200, "Jouni Malinen" <[email protected]> said:
> > > > > On Sat, Dec 27, 2008 at 10:08:20PM +0100, Michael Buesch wrote:
> > > > > > Please take a look at the following log:
> > > > > > http://bu3sch.de/misc/crda.JPG
> > > > > >
> > > > > > Note the ordering of the events.
> > > > > > Hostapd starts up and tells the kernel what country we're in.
> > > > > > Then the kernel calls CRDA, _but_ hostapd goes on with its business
> > > > > > before CRDA has finished its work.
> > > > >
> > > > > Yes, because the netlink message was completed and hostapd assumes
> > > > > everything is ready at that point. Ignoring the complexity in the kernel
> > > > > (+ CRDA as a helper), this looks like reasonable expectation to make for
> > > > > NL80211_CMD_REQ_SET_REG operation. There is no other mechanism that
> > > > > would notify hostapd (or any other program setting country for that
> > > > > matter) when the operation was actually fully completed and polling for
> > > > > channel changes up to a timeout is not very appealing either.
> > > > >
> > > > > Unfortunately, I don't see an easy fix for this.
> > > >
> > > > This sounds like it's broken by design. Hostapd should not send
> > > > NL80211_CMD_REQ_SET_REG if it is unable to evaluate the result. If it's
> > > > necessary to do "iw reg set foobar" in a script prior to invoking
> > > > hostapd, then why does hostapd even bother?
> > > >
> > >
> > > hostapd isn't broken. The CMD_REQ_SET_REG should block until regulatory
> > > settings are done. It currently doesn't, because that's hard to implement (probably
> > > by design).
> >
> > It means adding a timer and picking a reasonable value for the timeout,
> > then waiting for a response through nl80211 and disabling the timer from there and
> > then finally sending the reply back. This seems rather hackish but we can implement
> > if its desirable. I suppose the worst case scenerio would be CRDA and the
> > regulatory db in an NFS mount or something like that.
>
> I think this wouldn't be hackish, but do we actually _know_ when crda has finished
> uploading regulatory information? Does it do it all in one step?
It would go in through another nl80211 command, NL80211_CMD_SET_REG. nl80211 eventually
calls set_regdom() and this will set it, so if all goes well we can remove the timer
at the end if its active (other means can call CRDA like for 802.11d or the wireless core
upon initialization).
> > An alternative would be for us to add a netlink event once the regultory rule is
> > set in place. If the first approach is the better path to take then this secondary
> > netlink event can be sent anyway as informational.
>
> Would also be OK, but would also require knowledge about "did we finish already".
> Do we have this knowledge?
During set_regdom() we can always inspect last_request which tells us the details
of who last set the regulatory domain, and at the end of set_regdom() it can be
assumed it did so successfully, right after update_all_wiphy_regulatory().
Luis
On Saturday 27 December 2008 23:08:14 Jouni Malinen wrote:
> On Sat, Dec 27, 2008 at 10:08:20PM +0100, Michael Buesch wrote:
> > Please take a look at the following log:
> > http://bu3sch.de/misc/crda.JPG
> >
> > Note the ordering of the events.
> > Hostapd starts up and tells the kernel what country we're in.
> > Then the kernel calls CRDA, _but_ hostapd goes on with its business
> > before CRDA has finished its work.
>
> Yes, because the netlink message was completed and hostapd assumes
> everything is ready at that point. Ignoring the complexity in the kernel
> (+ CRDA as a helper), this looks like reasonable expectation to make for
> NL80211_CMD_REQ_SET_REG operation. There is no other mechanism that
> would notify hostapd (or any other program setting country for that
> matter) when the operation was actually fully completed and polling for
> channel changes up to a timeout is not very appealing either.
>
> Unfortunately, I don't see an easy fix for this. cfg80211 would somehow
> need to block sending of the NL80211_CMD_REQ_SET_REG response until CRDA
> has completed doing whatever it is going to do (is that even something
> that cfg80211 knows when the final step was completed?).. I haven't
> taken a look at all the details, but I've asked for this kind of wait in
> the past and at least it did not seem to be trivial to add since this
> has not been fixed yet ;-).
Ok, thanks for the explanation. For now I added a workaround to the initscript
that starts hostapd which sets the regulatory and waits a seconds before starting
hostapd.
iw reg set DE
sleep 1
# start hostapd...
--
Greetings, Michael.
On Mon, Dec 29, 2008 at 01:27:36PM -0500, Pavel Roskin wrote:
> On Mon, 2008-12-29 at 08:18 -0800, Luis R. Rodriguez wrote:
> > > I think this wouldn't be hackish, but do we actually _know_ when crda has finished
> > > uploading regulatory information? Does it do it all in one step?
> >
> > It would go in through another nl80211 command, NL80211_CMD_SET_REG. nl80211 eventually
> > calls set_regdom() and this will set it, so if all goes well we can remove the timer
> > at the end if its active (other means can call CRDA like for 802.11d or the wireless core
> > upon initialization).
>
> Can we have a command to _get_ regulatory settings? I think it would be
> useful. Then hostapd could wait until the correct settings are active.
> If it doesn't happen after some time, hostapd should exit with an error.
>
> It would be even better if hostapd could wait for an event notifying of
> the regulatory settings change.
While I could make hostapd poll for the change (either with get or by
waiting in a local loop waiting for the event; both are about equally
horrible hacks), I would really prefer this to be done by blocking the
response message in the kernel rather than requiring all user space apps
(or scripts, for that matter) from having to do this. This is just
likely to result in silly "sleep 1" everywhere and hoping that it is
always long enough wait..
I might even be tempted to just push that out from hostapd and leave it
to be a somebody else's problem (that silly shell script with sleep 1)
if the needed mechanism would mean that restarting hostapd takes extra
time). A command for querying the current country would get rid of the
extra penalty on restarts, so I would probably prefer it if these two
options were the only available choices.
Either way, the main problems I see here is to figure out when exactly
the CRDA processing has been completed and to make sure that userspace
apps will somehow know when that happened (i.e., get country better not
return the new country code before all CRDA parameters have been
configured and available for the following set_freq command).
--
Jouni Malinen PGP id EFC895FA
On Mon, Dec 29, 2008 at 02:28:00AM -0800, Michael Buesch wrote:
> On Monday 29 December 2008 04:45:22 Dan E wrote:
> >
> > On Sun, 28 Dec 2008 00:08:14 +0200, "Jouni Malinen" <[email protected]> said:
> > > On Sat, Dec 27, 2008 at 10:08:20PM +0100, Michael Buesch wrote:
> > > > Please take a look at the following log:
> > > > http://bu3sch.de/misc/crda.JPG
> > > >
> > > > Note the ordering of the events.
> > > > Hostapd starts up and tells the kernel what country we're in.
> > > > Then the kernel calls CRDA, _but_ hostapd goes on with its business
> > > > before CRDA has finished its work.
> > >
> > > Yes, because the netlink message was completed and hostapd assumes
> > > everything is ready at that point. Ignoring the complexity in the kernel
> > > (+ CRDA as a helper), this looks like reasonable expectation to make for
> > > NL80211_CMD_REQ_SET_REG operation. There is no other mechanism that
> > > would notify hostapd (or any other program setting country for that
> > > matter) when the operation was actually fully completed and polling for
> > > channel changes up to a timeout is not very appealing either.
> > >
> > > Unfortunately, I don't see an easy fix for this.
> >
> > This sounds like it's broken by design. Hostapd should not send
> > NL80211_CMD_REQ_SET_REG if it is unable to evaluate the result. If it's
> > necessary to do "iw reg set foobar" in a script prior to invoking
> > hostapd, then why does hostapd even bother?
> >
>
> hostapd isn't broken. The CMD_REQ_SET_REG should block until regulatory
> settings are done. It currently doesn't, because that's hard to implement (probably
> by design).
It means adding a timer and picking a reasonable value for the timeout,
then waiting for a response through nl80211 and disabling the timer from there and
then finally sending the reply back. This seems rather hackish but we can implement
if its desirable. I suppose the worst case scenerio would be CRDA and the
regulatory db in an NFS mount or something like that.
An alternative would be for us to add a netlink event once the regultory rule is
set in place. If the first approach is the better path to take then this secondary
netlink event can be sent anyway as informational.
Thoughts?
Luis
On Mon, Dec 29, 2008 at 10:27:36AM -0800, Pavel Roskin wrote:
> On Mon, 2008-12-29 at 08:18 -0800, Luis R. Rodriguez wrote:
> > > I think this wouldn't be hackish, but do we actually _know_ when crda has finished
> > > uploading regulatory information? Does it do it all in one step?
> >
> > It would go in through another nl80211 command, NL80211_CMD_SET_REG. nl80211 eventually
> > calls set_regdom() and this will set it, so if all goes well we can remove the timer
> > at the end if its active (other means can call CRDA like for 802.11d or the wireless core
> > upon initialization).
>
> Can we have a command to _get_ regulatory settings? I think it would be
> useful. Then hostapd could wait until the correct settings are active.
> If it doesn't happen after some time, hostapd should exit with an error.
Yeah, I've been meaning to get to that but haven't yet, we should have
a nl80211 command which lets userspace get the entire rd structure, and maybe
some info from last_request.
> It would be even better if hostapd could wait for an event notifying of
> the regulatory settings change.
Whatever works. But as can be seen this just requires a bit of work.
Luis
