Now that my link is working, and since I don't know much about the
dscape stack I'm looking for something simple to work on to get
started. I noticed that SIOCGIWRANGE is not fully implemented.
jonsmirl@jonsmirl:/extra/wireless_tools.29$ sudo iwlist wlan0 channel
wlan0 0 channels
Current Frequency:2.412 GHz
jonsmirl@jonsmirl:/extra/wireless_tools.29$
Looking in ieee80211_ioctl.c the implementation is in
ieee80211_ioctl_giwrange().
I can work on this, but how should it be done? There is no callout
from the stack to the drivers for this IOCTL. It also doesn't make
sense that each driver have the code to build the entire channel
lists. But you do need to know whether the driver is b/g or a/b/g. How
does the driver indicate which channel domain it is in, Japan/US/EU?
Jon Smirl
[email protected]
_______________________________________________
wireless mailing list
[email protected]
http://lists.tuxdriver.org/mailman/listinfo/wireless
On Tue, Jan 30, 2007 at 08:12:19PM -0500, Michael Wu wrote:
> Fixing up giwrange is currently on my d80211 blockers todo list since it is
> part of fixing wireless statistics reporting in d80211. Helper functions for
> filling the channel lists is also somewhere on the todo list, though it isn't
> on the blocker list. The driver currently has no way to indicate what
> regulatory domain the hardware has stored in eeprom, and d80211 just assumes
> FCC. (after all, d80211 isn't merge ready yet ;) Yes, basic driver regulatory
> domain support is on my blocker todo list.
The simple workaround for client mode is indeed just assuming one
regulatory domain, but the original design of the Devicescape stack was
to use a user space component (hostapd in case of AP mode) to populate
the allowed channel information based on what the low-level driver
claims to support as far as channels are concerned and what is
configured for regulatory domain (in hostapd configuration).
> Listing rates and channels in giwrange should be easy - find the current mode,
> and iterate through the list of channels and rates in there. Ignore any
> channels which are not enabled. Count up all the enabled channels and stick
> it in num_channels and num_frequency.
Yes, all the needed information for this particular part should already
be in net/d80211 and there is no need for low-level driver changes for
this. The separate question is on how the channel flags should be set
based on the current location of the device.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
wireless mailing list
[email protected]
http://lists.tuxdriver.org/mailman/listinfo/wireless
On Tue, 2007-01-30 at 22:11 -0500, Jon Smirl wrote:
> Managed mode doesn't need to know the regulatory domain, right? It
> picks it up from the AP.
I'm afraid it does. The station can initiate scan requests. This
should be done on authorized frequencies only. Some countries disallow
passive scanning outright, and that's something the card should know as
well. The power limits are also different.
Still, I think we could have a minimal managed mode, in which the
station doesn't transmit anything except when it detects an AP on that
frequency, and even then, the station would follow the strictest txpower
limitations.
--
Regards,
Pavel Roskin
_______________________________________________
wireless mailing list
[email protected]
http://lists.tuxdriver.org/mailman/listinfo/wireless
On 1/30/07, Jouni Malinen <[email protected]> wrote:
> On Tue, Jan 30, 2007 at 08:12:19PM -0500, Michael Wu wrote:
>
> > Fixing up giwrange is currently on my d80211 blockers todo list since it is
> > part of fixing wireless statistics reporting in d80211. Helper functions for
> > filling the channel lists is also somewhere on the todo list, though it isn't
> > on the blocker list. The driver currently has no way to indicate what
> > regulatory domain the hardware has stored in eeprom, and d80211 just assumes
> > FCC. (after all, d80211 isn't merge ready yet ;) Yes, basic driver regulatory
> > domain support is on my blocker todo list.
>
> The simple workaround for client mode is indeed just assuming one
> regulatory domain, but the original design of the Devicescape stack was
> to use a user space component (hostapd in case of AP mode) to populate
> the allowed channel information based on what the low-level driver
> claims to support as far as channels are concerned and what is
> configured for regulatory domain (in hostapd configuration).
It seems like regulatory domain for an AP has to be controlled from
user space. What about the simple case of someone with a US laptop
that flies to Japan and runs hostap. Getting the value from the eeprom
won't work in this case. If this is the case then the drivers just
need to report up every channel they can handle.
I have several APs. The Netgear ones let me set the region from their
web interface. To change my travel router from Dlink you need to
download different firmware images (like anyone is going to do that
for a business trip).
Managed mode doesn't need to know the regulatory domain, right? It
picks it up from the AP.
AdHoc would need to know the regulatory domain.
>
> > Listing rates and channels in giwrange should be easy - find the current mode,
> > and iterate through the list of channels and rates in there. Ignore any
> > channels which are not enabled. Count up all the enabled channels and stick
> > it in num_channels and num_frequency.
>
> Yes, all the needed information for this particular part should already
> be in net/d80211 and there is no need for low-level driver changes for
> this. The separate question is on how the channel flags should be set
> based on the current location of the device.
>
> --
> Jouni Malinen PGP id EFC895FA
> _______________________________________________
> wireless mailing list
> [email protected]
> http://lists.tuxdriver.org/mailman/listinfo/wireless
>
--
Jon Smirl
[email protected]
_______________________________________________
wireless mailing list
[email protected]
http://lists.tuxdriver.org/mailman/listinfo/wireless
On Tuesday 30 January 2007 22:11, you wrote:
> On 1/30/07, Jouni Malinen <[email protected]> wrote:
> > On Tue, Jan 30, 2007 at 08:12:19PM -0500, Michael Wu wrote:
> > > Fixing up giwrange is currently on my d80211 blockers todo list since
> > > it is part of fixing wireless statistics reporting in d80211. Helper
> > > functions for filling the channel lists is also somewhere on the todo
> > > list, though it isn't on the blocker list. The driver currently has no
> > > way to indicate what regulatory domain the hardware has stored in
> > > eeprom, and d80211 just assumes FCC. (after all, d80211 isn't merge
> > > ready yet ;) Yes, basic driver regulatory domain support is on my
> > > blocker todo list.
> >
> > The simple workaround for client mode is indeed just assuming one
> > regulatory domain, but the original design of the Devicescape stack was
> > to use a user space component (hostapd in case of AP mode) to populate
> > the allowed channel information based on what the low-level driver
> > claims to support as far as channels are concerned and what is
> > configured for regulatory domain (in hostapd configuration).
>
> It seems like regulatory domain for an AP has to be controlled from
> user space. What about the simple case of someone with a US laptop
> that flies to Japan and runs hostap. Getting the value from the eeprom
> won't work in this case. If this is the case then the drivers just
> need to report up every channel they can handle.
>
Yes, of course. I've read 802.11d. :) However, we need to simple regulatory
domain stuff on the driver side for feature parity with existing drivers. I'm
not actually trying to solve the problem for good, but to fix it enough to
merge. Reporting every channel is what is currently done (except for ipw3945
which restricts channels in firmware due to their regulatory concerns), and I
think the userspace interface for setting valid channels is still there.
-Michael Wu
Jon Smirl wrote:
> I can work on this, but how should it be done? There is no callout
> from the stack to the drivers for this IOCTL. It also doesn't make
> sense that each driver have the code to build the entire channel
> lists. But you do need to know whether the driver is b/g or a/b/g. How
> does the driver indicate which channel domain it is in, Japan/US/EU?
This isn't a small project and is one of the remaining significant
things that some people would like to see before devicescape gets merged.
As you note, drivers do need to inform the stack of basic capabilities,
regulatory domain, supported reg domains, etc. And yes, channel
'databases' and frequency mappings should be stack level or higher.
I don't think there is an answer to your questions at the moment - this
is stuff that needs both designing and implementing. Good luck :)
Daniel
_______________________________________________
wireless mailing list
[email protected]
http://lists.tuxdriver.org/mailman/listinfo/wireless
On Tuesday 30 January 2007 19:36, Jon Smirl wrote:
> Looking in ieee80211_ioctl.c the implementation is in
> ieee80211_ioctl_giwrange().
>
> I can work on this, but how should it be done? There is no callout
> from the stack to the drivers for this IOCTL. It also doesn't make
> sense that each driver have the code to build the entire channel
> lists. But you do need to know whether the driver is b/g or a/b/g. How
> does the driver indicate which channel domain it is in, Japan/US/EU?
>
Fixing up giwrange is currently on my d80211 blockers todo list since it is
part of fixing wireless statistics reporting in d80211. Helper functions for
filling the channel lists is also somewhere on the todo list, though it isn't
on the blocker list. The driver currently has no way to indicate what
regulatory domain the hardware has stored in eeprom, and d80211 just assumes
FCC. (after all, d80211 isn't merge ready yet ;) Yes, basic driver regulatory
domain support is on my blocker todo list.
Listing rates and channels in giwrange should be easy - find the current mode,
and iterate through the list of channels and rates in there. Ignore any
channels which are not enabled. Count up all the enabled channels and stick
it in num_channels and num_frequency. I could probably just copy the code
from the adm8211 (wireless-2.6 version) giwrange handler and modify it to
traverse lists instead of arrays. Feel free to hack and submit a patch though
- it's not like I don't have enough things on my todo list. :)
-Michael Wu