RE: proposal for new wireless configuration API
On Fri, 2006-08-18 at 09:45 -0700, Simon Barber wrote: I did mean RSSI - just about anything that when interpreted as an 8 bit unsigned int and goes up with increasing signal fits the bill as an RSSI measure. RCPI requires a certain minimum accuracy and linearity (the accuracy required is not very high). Ah got it now, sorry. Yes, good point. Thanks for explaining, johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Sat, 2006-08-19 at 00:02 +0200, Michael Buesch wrote: We currently know 6 different radio chips used by bcm43xx: http://bcm-specs.sipsolutions.net/RadioID AFAIK the chip is from broadcom, too. It is, and there is no datasheet. See http://johannes.sipsolutions.net/files/asus-wl100g.png :) johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proposal for new wireless configuration API
On Thu, 2006-08-17 at 09:42 -0700, Simon Barber wrote: The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number, guaranteed to be a monotonically increasing function of signal strength. You don't get to know anything about the scale, or linearity of the function. In essence RSSI is a vendor specific value, of no known units. Not very useful unless you know some card specific details to help interpret it. Yeah, if you knew at least linearity it'd be more useful. Now some cards return a signal strength in dBm as the RSSI - note that this fits the requirements of a RSSI measure just fine. RCPI is simply a did you mean to write RCPI there? more tightly specified signal strength measure. Ah, ok. Yes, I think we almost know how to make the bcm card report dBm instead. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote: Or are here people, who really want to freely transmit on all frequencies their RF might be able to generate? Yes :P Some amateur radio people asked me about extending the spectrum a bit to the top (apparently they're allowed to use the band just above the ISM band as well). However, I don't think we need to cater them in the API. I think they ought to be able to live with kernel patches since we don't really know how far up the frequency on say the bcm43xx can go anyway before the card breaks/malfunctions. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Fri, Aug 18, 2006 at 09:12:05AM +0200, Johannes Berg wrote: On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote: Or are here people, who really want to freely transmit on all frequencies their RF might be able to generate? Yes :P Some amateur radio people asked me about extending the spectrum a bit to the top (apparently they're allowed to use the band just above the ISM band as well). However, I don't think we need to cater them in the API. I think they ought to be able to live with kernel patches since we don't really know how far up the frequency on say the bcm43xx can go anyway before the card breaks/malfunctions. I concur. It would be best to confine the normal API to things that are legitimately done without a license if at all possible. Those who are licensed for other spectrum uses should be more than capable of applying a patch to do so (thereby more clearly taking regulatory responsibility upon themselves). John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proposal for new wireless configuration API
I did mean RSSI - just about anything that when interpreted as an 8 bit unsigned int and goes up with increasing signal fits the bill as an RSSI measure. RCPI requires a certain minimum accuracy and linearity (the accuracy required is not very high). Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 12:02 AM To: Simon Barber Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes Subject: RE: proposal for new wireless configuration API On Thu, 2006-08-17 at 09:42 -0700, Simon Barber wrote: The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number, guaranteed to be a monotonically increasing function of signal strength. You don't get to know anything about the scale, or linearity of the function. In essence RSSI is a vendor specific value, of no known units. Not very useful unless you know some card specific details to help interpret it. Yeah, if you knew at least linearity it'd be more useful. Now some cards return a signal strength in dBm as the RSSI - note that this fits the requirements of a RSSI measure just fine. RCPI is simply a did you mean to write RCPI there? more tightly specified signal strength measure. Ah, ok. Yes, I think we almost know how to make the bcm card report dBm instead. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On 06-08-18 09:12 Johannes Berg wrote: On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote: Or are here people, who really want to freely transmit on all frequencies their RF might be able to generate? Yes :P Some amateur radio people asked me about extending the spectrum a bit to the top (apparently they're allowed to use the band just above the ISM band as well). I had some discussions with radio amateurs about the RFs in the ZD1211 devices. Even if I could transmit in their required bands, the RFs are so WLAN specific, that they don't fulfill their requirements. It's really funny, if somebody explains to you that these chips are of extremely low quality. I always try to explain to them that the complete devices are sold for only 17 Euros including VAT. You cannot expect for this price the quality required for long range transmissions at these high frequencies. I support the idea that radio amateurs should create their own patches if they need it. Supporting the frequencies in the interface, is a typical feature used by less than 1% of the user base, but would cost more than 80% of the effort. We should also not do anything, which would raise the impression, that we want to ignore regulatory rules. However, I don't think we need to cater them in the API. I think they ought to be able to live with kernel patches since we don't really know how far up the frequency on say the bcm43xx can go anyway before the card breaks/malfunctions. Do they have a separate RF? They data sheets are usually available, even if the not always explain the register programming. -- Uli Kunitz - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Friday 18 August 2006 23:29, Ulrich Kunitz wrote: On 06-08-18 09:12 Johannes Berg wrote: On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote: Or are here people, who really want to freely transmit on all frequencies their RF might be able to generate? Yes :P Some amateur radio people asked me about extending the spectrum a bit to the top (apparently they're allowed to use the band just above the ISM band as well). I had some discussions with radio amateurs about the RFs in the ZD1211 devices. Even if I could transmit in their required bands, the RFs are so WLAN specific, that they don't fulfill their requirements. It's really funny, if somebody explains to you that these chips are of extremely low quality. I always try to explain to them that the complete devices are sold for only 17 Euros including VAT. You cannot expect for this price the quality required for long range transmissions at these high frequencies. I support the idea that radio amateurs should create their own patches if they need it. Supporting the frequencies in the interface, is a typical feature used by less than 1% of the user base, but would cost more than 80% of the effort. We should also not do anything, which would raise the impression, that we want to ignore regulatory rules. I second that. We should not allow to drive devices outside of the specs. If someone wants to do this, he should be able to apply a one-liner patch to tune to some different frequency. ;) However, I don't think we need to cater them in the API. I think they ought to be able to live with kernel patches since we don't really know how far up the frequency on say the bcm43xx can go anyway before the card breaks/malfunctions. Do they have a separate RF? They data sheets are usually available, even if the not always explain the register programming. We currently know 6 different radio chips used by bcm43xx: http://bcm-specs.sipsolutions.net/RadioID AFAIK the chip is from broadcom, too. I don't like to check now, as that would require to disassemble my AP and look at the chip. ;) But I'm pretty sure. There is no datasheet available for the chip. At least nobody was able to get or found one so far... . -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proposal for new wireless configuration API
On Wed, 2006-08-16 at 11:02 -0700, Simon Barber wrote: I'd suggest that the new signal strength measure should be defined as 'RCPI' - the 'Received Channel Power Indicator' - which is defined in IEEE 802.11k (the Radio Measurements amendment to 802.11). Except that we unfortunately have no way of getting this with all the reverse engineered devices :) Hence, I guess we should then have multiple different possibilities. A device reporting RCPI would be better than just reporting RSSI, but that's still better than nothing... johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proposal for new wireless configuration API
The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number, guaranteed to be a monotonically increasing function of signal strength. You don't get to know anything about the scale, or linearity of the function. In essence RSSI is a vendor specific value, of no known units. Not very useful unless you know some card specific details to help interpret it. Now some cards return a signal strength in dBm as the RSSI - note that this fits the requirements of a RSSI measure just fine. RCPI is simply a more tightly specified signal strength measure. Just saying that a RSSI value is not very useful. Simon -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 12:20 AM To: Simon Barber Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes Subject: RE: proposal for new wireless configuration API On Wed, 2006-08-16 at 11:02 -0700, Simon Barber wrote: I'd suggest that the new signal strength measure should be defined as 'RCPI' - the 'Received Channel Power Indicator' - which is defined in IEEE 802.11k (the Radio Measurements amendment to 802.11). Except that we unfortunately have no way of getting this with all the reverse engineered devices :) Hence, I guess we should then have multiple different possibilities. A device reporting RCPI would be better than just reporting RSSI, but that's still better than nothing... johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Thursday 17 August 2006 21:39, Jean Tourrilhes wrote: On Tue, Aug 15, 2006 at 09:13:23PM +0200, Michael Buesch wrote: On Tuesday 15 August 2006 20:14, Dan Williams wrote: On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote: On Tuesday 15 August 2006 18:29, Dan Williams wrote: o Separate attributes for channel and frequency No, channel and freq is the same. It's just another name for the same child. I would say we only want to deal with channel numbers in the API. That's much easier, as we don't have to deal with this fixed-point (or even floating point) mess. Look at WE for the fixed-point mess. Right, I don't have a problem with only using one or the other; but we _HAVE_ to provide a function in the driver that allows userspace programs to convert channel - frequency both ways, like you suggest below. Obviously the channel/frequency mapping isn't the same everywhere. [ or is it? I'd be very uncomfortable using the same channel #s everywhere unless some IEEE spec states exactly what the channel #s are for every frequency range that wireless stuff operates in ] The channel-freq mapping is stable. We may need to double check this... It is already clear that WiMax, ZigBee and pre-802.11 HW don't use the same channel-freq mapping as 802.11. Further, I remember somebody (was it Jouni) mentioning that some variations of 802.11 have different channel mappings. But, we would need to check that. Yes, I should have been more verbose here. What I meant is: In a particular PHYMODE the channel-freq mapping is stable. That is, if we are in G-PHY mode, the mapping is always stable with channels 1-14. Wimax and so on would be another PHYMODE. The PHYMODE would be selected otherwise (through other netlink attrs or whatever). No argument here; as long as we provide the mapping function in the driver for each card. Hm, I don't know if I understand this correctly. You want to implement the mapping function in every driver or in the d80211 stack? A simple mapping table is probably enough, similar to what we already have. Well, a mapping function, because we must look at the different PHYMODEs. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On 06-08-17 09:42 Simon Barber wrote: The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number, guaranteed to be a monotonically increasing function of signal strength. You don't get to know anything about the scale, or linearity of the function. In essence RSSI is a vendor specific value, of no known units. Not very useful unless you know some card specific details to help interpret it. Now some cards return a signal strength in dBm as the RSSI - note that this fits the requirements of a RSSI measure just fine. RCPI is simply a more tightly specified signal strength measure. Just saying that a RSSI value is not very useful. we are simply not able to deliver RCPI, because we have no idea how RSSI is measured for the ZD1211 device. We had discussions with the vendor developers, but it seemed that their understanding was not really more advanced than our's. There is the same issue for signal quality and signal-to-noise ratio. -- Uli Kunitz - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On 06-08-15 18:38 Michael Buesch wrote: On Tuesday 15 August 2006 18:29, Dan Williams wrote: o Separate attributes for channel and frequency No, channel and freq is the same. It's just another name for the same child. I would say we only want to deal with channel numbers in the API. That's much easier, as we don't have to deal with this fixed-point (or even floating point) mess. Look at WE for the fixed-point mess. The userspace tools can easily convert freq to channel and back. And in the kernel, we can easily provide some small function to convert from channel to khz and back, for example. But I would like to see the fixed-point stuff in the API vanish. o Method of finding out channel - frequency mapping (not all drivers support this in the SIOCGIWRANGE handler now) Yes, that would be a good idea. Comes next to the conversion function (see above). Channel to frequency mapping is defined by 802.11. So we could get rid of frequencies totally in the user interface and it will also help with compliance to regulatory rules. Or are here people, who really want to freely transmit on all frequencies their RF might be able to generate? -- Uli Kunitz - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Tue, 2006-08-15 at 12:29 -0400, Dan Williams wrote: We might want to take the time to fix up a few of the ambiguities of WEXT that we've encountered over the past few years: Yes, I definitely agree. o Separate attributes for signal strength units; signed integer type for dBm, unsigned integer type for RSSI. One 8-bit var to represent both is just too confusing for people, evidently (which is true...) Yes, agreed, they should be separated. In general, I think that one attribute should always have a single meaning and unit attached, except for explicitly unit-less attributes (number of frames or whatever), or attributes that explicitly have no stable unit (raw rssi). o Merge functionality ENCODE and ENCODEEXT handlers into one Good one. I'm still not sure whether we should have an attribute for this, or a command. The whole key business seems rather complex and it might be good to have a command 'set key' with say a possible attribute for the mac address of a pairwise key, a key material attribute and an IV attribute or something. Otherwise we'll end up parsing the contents of an attribute again, which rather sucks... On the other hand, having it as a command won't allow the user to optimize setting the key and other things at once. I'm not too sure we should pay all that much attention to this problem though, it can't take forever and typically a user with such a card won't be changing the key or parameters all the time, hence it's usually probably done only at boo or association time. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Tue, 2006-08-15 at 15:59 -0400, Dan Williams wrote: Ok, so if somebody magically opens up new unlicensed ISM spectrum around, say, 7GHz, does that space get broken into channels and assigned specific numbers by the IEEE? I know there are stable channel #s for abg range. What about the future? [1] Can we guarantee that whenever new spectrum opens up that future 802.11 products may use, that the mappings are well-defined? That was my main question. I'd expect them to actually break it into channels and assign channel numbers. Or whoever creates the hardware first does it, and those numbers then get adopted in the year-long specification process ;) Besides, if we really really really needed something else later for whatever weird reason, we could add a new attribute for those cases, and have it reject the channel attribute then :) johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Tue, 2006-08-15 at 12:14 -0400, Luis R. Rodriguez wrote: Basically redo WE completely from scratch using netlink. Not quite, I hope! As Dan mentioned, for example all the key management stuff ought to be consolidated. Same for some other things. For per packet this makes sense, for modification of all packets I think configfs would be more suitable. Then again this is just an addition, I'm not disagreeing here with the approach. The same goes for several common wireless settings -- we could also have a configfs directory for each device which would allow manual read/writing for setting/getting certain values; mind you that congifs does allow for setting/getting multiple values at the same time, for those of you who have wondered. This could just could easily go in as a wrapper for configfs-new NL API. Yeah, that might not even be undesirable. But we also need per-packet controls, and a bunch of them. The current situation with a special header in front of a packet injected into the management interface isn't too great. I'm not sure what kind of generic packet sending parameters we have. Bitrate obviously, and all the other possible attributes... NL80211_ATTR_IFINDEX: index of interface to use This was just meant to be the ifindex of the eth0 or whatever device. (NL80211_ATTR_PHYIDX: (later) index of wiphy to configure) Do you mean to have a wireless device have its own device index, separate from the netdevice index? Can you elaborate a bit on this? Well, the d80211 stack gives each driver backend phyN in /sys/class/ieee80211/. If we ever want to get rid of the wmasterN interface, we probably want to allow configuring without an ifindex because the physical device might not have any network devices attached at that time. I'm not exactly sure if it really makes sense to configure the device then, but hey. With WE we were restricted to the number of attributes possibly changed by the number of ioctls and later by sub-ioctl hack restrictions. What restrictions are we to face with this? We can have tons of attributes, it's a 16-bit field. I think that should be sufficient :) Do we want to map each attribute directly to the respective WE ioctl number to make it easy to do backward compatibility? No, because that would mean having very large attribute numbers up-front, and due to the way genetlink works there is memory allocated for each possible attribute. Hence, attribute numbers should be allocated in an increasing fashion starting from 1, and not be sparse. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proposal for new wireless configuration API
I'd suggest that the new signal strength measure should be defined as
'RCPI' - the 'Received Channel Power Indicator' - which is defined in
IEEE 802.11k (the Radio Measurements amendment to 802.11). Here is the
full text of the definition from 802.11k draft 5.0:
received channel power indicator (RCPI): An indication of the total
channel power (signal, noise, and interference) of a received IEEE
802.11 frame measured on a single channel and at the antenna connector
used to receive the frame.
The RCPI indicator is a measure of the received RF power in the selected
channel for a received frame. This parameter shall be a measure by the
PHY sublayer of the received RF power in the channel measured over the
entire received frame or by other equivalent means which meet the
specified accuracy. RCPI shall be a monotonically increasing,
logarithmic function of the received power level defined in dBm. The
allowed values for the Received Channel Power Indicator (RCPI) parameter
shall be an 8 bit value in the range from 0 through 220, with indicated
values rounded to the nearest 0.5 dB as follows:
0: Power -110 dBm
1: Power = -109.5 dBm
2: Power = -109.0 dBm
and so on where
RCPI = int{(Power in dBm +110)*2} for 0dbm Power -110dBm
220: Power -0 dBm
221-254: reserved
255: Measurement not available
RCPI shall equal the received RF power within an accuracy of +/-5 dB
(95% confidence interval) within the specified dynamic range of the
receiver. The received RF power shall be determined assuming a receiver
noise equivalent bandwidth equal to the channel bandwidth multiplied by
1.1.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Johannes Berg
Sent: Tuesday, August 15, 2006 11:51 PM
To: Dan Williams
Cc: netdev@vger.kernel.org; Jean Tourrilhes
Subject: Re: proposal for new wireless configuration API
On Tue, 2006-08-15 at 12:29 -0400, Dan Williams wrote:
We might want to take the time to fix up a few of the ambiguities of
WEXT that we've encountered over the past few years:
Yes, I definitely agree.
o Separate attributes for signal strength units; signed integer type
for dBm, unsigned integer type for RSSI. One 8-bit var to represent
both is just too confusing for people, evidently (which is true...)
Yes, agreed, they should be separated. In general, I think that one
attribute should always have a single meaning and unit attached, except
for explicitly unit-less attributes (number of frames or whatever), or
attributes that explicitly have no stable unit (raw rssi).
o Merge functionality ENCODE and ENCODEEXT handlers into one
Good one. I'm still not sure whether we should have an attribute for
this, or a command. The whole key business seems rather complex and it
might be good to have a command 'set key' with say a possible attribute
for the mac address of a pairwise key, a key material attribute and an
IV attribute or something. Otherwise we'll end up parsing the contents
of an attribute again, which rather sucks...
On the other hand, having it as a command won't allow the user to
optimize setting the key and other things at once. I'm not too sure we
should pay all that much attention to this problem though, it can't take
forever and typically a user with such a card won't be changing the key
or parameters all the time, hence it's usually probably done only at boo
or association time.
johannes
-
To unsubscribe from this list: send the line unsubscribe netdev in the
body of a message to [EMAIL PROTECTED] More majordomo info at
http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
This all sounds good to me. A few comments here, to give you something to read when you get home. On 8/15/06, Johannes Berg [EMAIL PROTECTED] wrote: - we implement a bunch of commands, for example NL80211_CMD_INJECT and _SETATTR, _GETATTR[(attrnumber)] [easy with dumpit()], _GETATTRGROUP, ... Basically redo WE completely from scratch using netlink. - we have a whole bunch of possible attributes: NL80211_ATTR_FLAGS: flags for injecting a packet (e.g. want_notify) For per packet this makes sense, for modification of all packets I think configfs would be more suitable. Then again this is just an addition, I'm not disagreeing here with the approach. The same goes for several common wireless settings -- we could also have a configfs directory for each device which would allow manual read/writing for setting/getting certain values; mind you that congifs does allow for setting/getting multiple values at the same time, for those of you who have wondered. This could just could easily go in as a wrapper for configfs-new NL API. NL80211_ATTR_IFINDEX: index of interface to use (NL80211_ATTR_PHYIDX: (later) index of wiphy to configure) Do you mean to have a wireless device have its own device index, separate from the netdevice index? Can you elaborate a bit on this? NL80211_ATTR_ESSID, FRAGTHRESHOLD, CHANNEL,...: most of the old wext ioctls map to attributes now With WE we were restricted to the number of attributes possibly changed by the number of ioctls and later by sub-ioctl hack restrictions. What restrictions are we to face with this? Do we want to map each attribute directly to the respective WE ioctl number to make it easy to do backward compatibility? Luis - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Tue, 2006-08-15 at 17:28 +0200, Johannes Berg wrote: Hi, So I've thought about this all day long... After writing this mail I'll go home and hope my inbox collects some feedback ;) We might want to take the time to fix up a few of the ambiguities of WEXT that we've encountered over the past few years: o Separate attributes for signal strength units; signed integer type for dBm, unsigned integer type for RSSI. One 8-bit var to represent both is just too confusing for people, evidently (which is true...) o Merge functionality ENCODE and ENCODEEXT handlers into one o Separate attributes for channel and frequency o Method of finding out channel - frequency mapping (not all drivers support this in the SIOCGIWRANGE handler now) Nothing big here... but gives driver writers a much easier target to hit, and userspace app writers an easier API to understand. Dan I've arrived at the following conclusions: * we want to use genetlink * we need an equivalent of the old commit() call, but without all the stupidity * we want to do packet injection and many other advanced features with it, and keep it extensible NB: I have some code, so don't start ;) Hence, I came up with the following system. Note that I don't use any private header for the netlink messages. - we implement a bunch of commands, for example NL80211_CMD_INJECT and _SETATTR, _GETATTR[(attrnumber)] [easy with dumpit()], _GETATTRGROUP, ... - we have a whole bunch of possible attributes: NL80211_ATTR_FLAGS: flags for injecting a packet (e.g. want_notify) NL80211_ATTR_IFINDEX: index of interface to use (NL80211_ATTR_PHYIDX: (later) index of wiphy to configure) NL80211_ATTR_ESSID, FRAGTHRESHOLD, CHANNEL,...: most of the old wext ioctls map to attributes now NL80211_ATTR_FRAME: frame to inject, or received mgmt frame - we use a few multicast groups: (a) one for management frames that are received (b) one for scan results as they come available (When, for example, someone requests scan results, they are simply multicast to the group+the requester, if they come available during operation they can also be multicast here) Note that I haven't mentioned commit(). NL80211_CMD_GETATTRGROUP returns a list of attributes that make sense to set with a single _SETATTR call and multiple attributes. an old sequence of iwconfig eth0 essid 'lalala' iwconfig eth0 channel 2 iwconfig eth0 commit would then be translated in the compat layer to a single _SETATTR message with the channel and essid attributes. Ultimately, we'll get rid of this, so a userspace tool using the netlink configuration would just tell the user via _GETATTRGROUP which attributes make sense to group together for optimal card behaviour. As for the inject command, it looks like on the current wmgmt# interface for d80211 has a bunch of implicit behaviour like looking into the transmitted frame to see what type it is etc. I'd like to get rid of it and stuff the information for that into ATTR_FLAGS instead. Oh and of course we'll have a structure somewhere that drivers and stacks register with the module that provides this netlink interface. That module will then also multiplex the commands to the drivers/stacks. I have that mostly figured out. Since it will be easy to tell if a specific driver/stack implements old-style wext or this new API we can allow drivers with both APIs to coexist for a while. I won't map the new API to the old wext one of course, but mapping the wext API to the new one we need anyway. Hence, we can change the wext code to call the new API if present and the old one otherwise (with a big fat printk), and then slowly migrate drivers over. Due to the reduced commit logic, it should become simpler too, even for old drivers. Anyway, comments appreciated. If we can agree on this general framework I'll start implementing the groundwork and some of the rest for d80211 soon. johannes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Tuesday 15 August 2006 18:29, Dan Williams wrote: o Separate attributes for channel and frequency No, channel and freq is the same. It's just another name for the same child. I would say we only want to deal with channel numbers in the API. That's much easier, as we don't have to deal with this fixed-point (or even floating point) mess. Look at WE for the fixed-point mess. The userspace tools can easily convert freq to channel and back. And in the kernel, we can easily provide some small function to convert from channel to khz and back, for example. But I would like to see the fixed-point stuff in the API vanish. o Method of finding out channel - frequency mapping (not all drivers support this in the SIOCGIWRANGE handler now) Yes, that would be a good idea. Comes next to the conversion function (see above). -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote: On Tuesday 15 August 2006 18:29, Dan Williams wrote: o Separate attributes for channel and frequency No, channel and freq is the same. It's just another name for the same child. I would say we only want to deal with channel numbers in the API. That's much easier, as we don't have to deal with this fixed-point (or even floating point) mess. Look at WE for the fixed-point mess. Right, I don't have a problem with only using one or the other; but we _HAVE_ to provide a function in the driver that allows userspace programs to convert channel - frequency both ways, like you suggest below. Obviously the channel/frequency mapping isn't the same everywhere. [ or is it? I'd be very uncomfortable using the same channel #s everywhere unless some IEEE spec states exactly what the channel #s are for every frequency range that wireless stuff operates in ] The userspace tools can easily convert freq to channel and back. And in the kernel, we can easily provide some small function to convert from channel to khz and back, for example. But I would like to see the fixed-point stuff in the API vanish. No argument here; as long as we provide the mapping function in the driver for each card. o Method of finding out channel - frequency mapping (not all drivers support this in the SIOCGIWRANGE handler now) Yes, that would be a good idea. Comes next to the conversion function (see above). Yep. Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Tuesday 15 August 2006 20:14, Dan Williams wrote: On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote: On Tuesday 15 August 2006 18:29, Dan Williams wrote: o Separate attributes for channel and frequency No, channel and freq is the same. It's just another name for the same child. I would say we only want to deal with channel numbers in the API. That's much easier, as we don't have to deal with this fixed-point (or even floating point) mess. Look at WE for the fixed-point mess. Right, I don't have a problem with only using one or the other; but we _HAVE_ to provide a function in the driver that allows userspace programs to convert channel - frequency both ways, like you suggest below. Obviously the channel/frequency mapping isn't the same everywhere. [ or is it? I'd be very uncomfortable using the same channel #s everywhere unless some IEEE spec states exactly what the channel #s are for every frequency range that wireless stuff operates in ] The channel-freq mapping is stable. What is unstable is the allowed channels map. For APHY there are even many gaps in the map. For example channels 6, 40 and 55 may be the only ones allowed (6, 40, 55 are generated by my /brain/random device ;) ) The frequency range you mention is selected differently by another config option. In d80211 we call it the PHYMODE. Switching the PHYMODE changes the meaning of channel values and changes the output of the two functions below. So if I want to switch to channel 4 in the 2.4Ghz band, I would do: select PHYMODE B or G, select channel 4. That would lead to the card tuning to 2427 MHz. The userspace tools can easily convert freq to channel and back. And in the kernel, we can easily provide some small function to convert from channel to khz and back, for example. But I would like to see the fixed-point stuff in the API vanish. No argument here; as long as we provide the mapping function in the driver for each card. Hm, I don't know if I understand this correctly. You want to implement the mapping function in every driver or in the d80211 stack? It belongs into a central place in the 80211 stack. There where regulatory domain stuff is managed, too. We need functions like: u32 ieee80211_channel_to_freq(struct ieee80211 *ieee, u8 channel); u8 ieee80211_freq_to_channel(struct ieee80211 *ieee, u32 channel); These would be used in drivers to convert values. The validity of the channel value passed from userspace would be checked in the _stack_. If the user passes an illegal value for his country, it would never reach the driver. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: proposal for new wireless configuration API
A further complication happens in Japan with 802.11j, and now in the USA too - with 802.11y in the 3.65Ghz band - here there are some new channel widths that are possible. Normally 802.11 is 20 or 22Mhz wide (20Mhz for OFDM modulations - 11a/g, 22 for 11b). In Japan's 4.9Ghz band you can run the OFDM at half rate, giving a 10Mhz wide channel, or at quarter rate, giving a 5Mhz wide channel. Hence same frequency, different channel spec. Using a channel number is the way to go. If we need something to convert between the 2 it should probably be a library in user space (in hostapd or wpa_supplicant) - hostapd does have this today. It might be nice if other applications could access this data too - but I don't think it needs to be inside the kernel. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Buesch Sent: Tuesday, August 15, 2006 12:13 PM To: Dan Williams Cc: netdev@vger.kernel.org; Jean Tourrilhes; Johannes Berg Subject: Re: proposal for new wireless configuration API On Tuesday 15 August 2006 20:14, Dan Williams wrote: On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote: On Tuesday 15 August 2006 18:29, Dan Williams wrote: o Separate attributes for channel and frequency No, channel and freq is the same. It's just another name for the same child. I would say we only want to deal with channel numbers in the API. That's much easier, as we don't have to deal with this fixed-point (or even floating point) mess. Look at WE for the fixed-point mess. Right, I don't have a problem with only using one or the other; but we _HAVE_ to provide a function in the driver that allows userspace programs to convert channel - frequency both ways, like you suggest below. Obviously the channel/frequency mapping isn't the same everywhere. [ or is it? I'd be very uncomfortable using the same channel #s everywhere unless some IEEE spec states exactly what the channel #s are for every frequency range that wireless stuff operates in ] The channel-freq mapping is stable. What is unstable is the allowed channels map. For APHY there are even many gaps in the map. For example channels 6, 40 and 55 may be the only ones allowed (6, 40, 55 are generated by my /brain/random device ;) ) The frequency range you mention is selected differently by another config option. In d80211 we call it the PHYMODE. Switching the PHYMODE changes the meaning of channel values and changes the output of the two functions below. So if I want to switch to channel 4 in the 2.4Ghz band, I would do: select PHYMODE B or G, select channel 4. That would lead to the card tuning to 2427 MHz. The userspace tools can easily convert freq to channel and back. And in the kernel, we can easily provide some small function to convert from channel to khz and back, for example. But I would like to see the fixed-point stuff in the API vanish. No argument here; as long as we provide the mapping function in the driver for each card. Hm, I don't know if I understand this correctly. You want to implement the mapping function in every driver or in the d80211 stack? It belongs into a central place in the 80211 stack. There where regulatory domain stuff is managed, too. We need functions like: u32 ieee80211_channel_to_freq(struct ieee80211 *ieee, u8 channel); u8 ieee80211_freq_to_channel(struct ieee80211 *ieee, u32 channel); These would be used in drivers to convert values. The validity of the channel value passed from userspace would be checked in the _stack_. If the user passes an illegal value for his country, it would never reach the driver. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Tuesday 15 August 2006 21:27, Simon Barber wrote: A further complication happens in Japan with 802.11j, and now in the USA too - with 802.11y in the 3.65Ghz band - here there are some new channel widths that are possible. Normally 802.11 is 20 or 22Mhz wide (20Mhz for OFDM modulations - 11a/g, 22 for 11b). In Japan's 4.9Ghz band you can run the OFDM at half rate, giving a 10Mhz wide channel, or at quarter rate, giving a 5Mhz wide channel. Hence same frequency, different channel spec. Using a channel number is the way to go. If we need something to convert between the 2 it should probably be a library in user space (in hostapd or wpa_supplicant) - hostapd does have this today. It might be nice if other applications could access this data too - but I don't think it needs to be inside the kernel. We need this conversion function, as most devices tune to frequencies, not channels. So when a driver is instructed to tune to channel 2, it must call back into the 80211 stack to ask for the frequency (based on the current PHYMODE and the other parameters you mentioned above). That call should IMO not result in a call to userspace. Userspace should instead set flags _before_ in the stack and the conversion callback would act on these flags. That way userspace only has to tell the kernel once which frequency-band, half, quater freq, or whatever it wants. The actual conversion from channel number to freq (or the other way around) is trivial after that, as it's only a few ifs and elses based on some cheap flags. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Tue, 2006-08-15 at 21:13 +0200, Michael Buesch wrote: On Tuesday 15 August 2006 20:14, Dan Williams wrote: On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote: On Tuesday 15 August 2006 18:29, Dan Williams wrote: o Separate attributes for channel and frequency No, channel and freq is the same. It's just another name for the same child. I would say we only want to deal with channel numbers in the API. That's much easier, as we don't have to deal with this fixed-point (or even floating point) mess. Look at WE for the fixed-point mess. Right, I don't have a problem with only using one or the other; but we _HAVE_ to provide a function in the driver that allows userspace programs to convert channel - frequency both ways, like you suggest below. Obviously the channel/frequency mapping isn't the same everywhere. [ or is it? I'd be very uncomfortable using the same channel #s everywhere unless some IEEE spec states exactly what the channel #s are for every frequency range that wireless stuff operates in ] The channel-freq mapping is stable. Ok, so if somebody magically opens up new unlicensed ISM spectrum around, say, 7GHz, does that space get broken into channels and assigned specific numbers by the IEEE? I know there are stable channel #s for abg range. What about the future? [1] Can we guarantee that whenever new spectrum opens up that future 802.11 products may use, that the mappings are well-defined? That was my main question. What is unstable is the allowed channels map. For APHY there are even many gaps in the map. For example channels 6, 40 and 55 may be the only ones allowed (6, 40, 55 are generated by my /brain/random device ;) ) The frequency range you mention is selected differently by another config option. In d80211 we call it the PHYMODE. Switching the PHYMODE changes the meaning of channel values and changes the output of the two functions below. So if I want to switch to channel 4 in the 2.4Ghz band, I would do: select PHYMODE B or G, select channel 4. That would lead to the card tuning to 2427 MHz. That sounds fine to me. The userspace tools can easily convert freq to channel and back. And in the kernel, we can easily provide some small function to convert from channel to khz and back, for example. But I would like to see the fixed-point stuff in the API vanish. No argument here; as long as we provide the mapping function in the driver for each card. Hm, I don't know if I understand this correctly. You want to implement the mapping function in every driver or in the d80211 stack? If we can assume that future spectrum will have well-defined channel numbers, then I don't have a problem with having the mapping function _once_ in d80211. Will the d80211 stack _only_ be used for 802.11 [a|b|g|n] implementations? What if another implementation comes around that uses a different PHY but the same spectrum and same protocol? Ultrawide Band using 802.11 protocol or something? Who knows? It belongs into a central place in the 80211 stack. There where regulatory domain stuff is managed, too. No argument there. I'm just wondering aloud if we can guarantee that the mappings will always be the same for stuff other than 802.11[abgn]. Originally, Linux Wireless Extensions was designed with stuff in addition to 802.11. It happened that 802.11 is pretty much the only thing that uses WE. Since d80211 is by nature an _802.11_ stack, it's fine to restrict the configuration to 802.11 stuff. But we can't necessarily say what every 802.11 substandard is going to do with channels and spectrum in the future, can we? Making the mapping API flexible is one way to ensure that we don't get stuck a WE-type trap. Dan [1] Obviously we cannot ever anticipate everything, and nobody should try to excessively future-proof d80211, or nothing will get done. We need to balance extendability with over-anticipation. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: proposal for new wireless configuration API
On Tue, 2006-08-15 at 21:35 +0200, Michael Buesch wrote: On Tuesday 15 August 2006 21:27, Simon Barber wrote: A further complication happens in Japan with 802.11j, and now in the USA too - with 802.11y in the 3.65Ghz band - here there are some new channel widths that are possible. Normally 802.11 is 20 or 22Mhz wide (20Mhz for OFDM modulations - 11a/g, 22 for 11b). In Japan's 4.9Ghz band you can run the OFDM at half rate, giving a 10Mhz wide channel, or at quarter rate, giving a 5Mhz wide channel. Hence same frequency, different channel spec. Using a channel number is the way to go. If we need something to convert between the 2 it should probably be a library in user space (in hostapd or wpa_supplicant) - hostapd does have this today. It might be nice if other applications could access this data too - but I don't think it needs to be inside the kernel. We need this conversion function, as most devices tune to frequencies, not channels. So when a driver is instructed to tune to channel 2, it must call back into the 80211 stack to ask for the frequency (based on the current PHYMODE and the other parameters you mentioned above). That call should IMO not result in a call to userspace. Userspace should instead set flags _before_ in the stack and the conversion callback would act on these flags. That way userspace only has to tell the kernel once which frequency-band, half, quater freq, or whatever it wants. The actual conversion from channel number to freq (or the other way around) is trivial after that, as it's only a few ifs and elses based on some cheap flags. As long as there's a way for userspace to convert channel - frequency and back using the _same_ values as the driver is using, that's all I care about. I just don't want to have each userspace program have its own library of channel/frequency mappings simply because not enough information was exposed through the d80211 stack's API. Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
