Re: [Bcm43xx-dev] [Fwd: State of the Union: Wireless]
Subsystems (2)
Quoted 5 lines
Quoted 5 lines
* We really have no wireless maintainer. I'm just the defacto guy, with no interest in the job. The ideal maintainer knows 802.11 well, uses git, and isn't an asshole with no taste. I'm just the guy who wants to make sure the net driver portion doesn't turn out to be a stinker (read: review and pass up the chain).
That problem is easiest to solve. ;)
Quoted 6 lines
Quoted 6 lines
* Wireless management, in particular the wireless kernel<->user interface, needs some thinking. Wireless Extensions (WE) isn't cutting it, but I haven't seen any netlink work yet (or some other interface). Whatever the userspace interface is, it will be basically carved in stone for years (unlike kernel APIs), so this needs a lot more thought than people have been giving it.
We did some brainstorming about this yesterday evening on the bcm irc channel. I think we all agreed on dropping WE.
So, now we asked: How would a sane UI look like. We had a few points:
* The interface needs to support some kind of "master" interface to configure the hardware, 80211 parameters and
to actually configure and setup the
* Virtual interfaces.
Data is transferred only though the virtual interfaces, which could be an AP interface, a STA interface in INFRA or Ad-Hoc mode, etc... . Configuration is done though the master interface.
How would the virtual interfaces look like? That is quite easy to answer. They are net_devices, as they transfer data.
They should probaly _not_ be on top of the ethernet, as 80211 does not have very much in common with ethernet. Basically they share the same MAC address format. Does someone have another thing, which he thinks is shared?
How would the master interface look like? A somewhat unusual idea came up. Using a device node in /dev. So every wireless card in the system would have a node in /dev associated (/dev/wlan0 for example).
A node for the master device would be ok, because no data is transferred through it. It is only a configuration interface.
So you would tell the, yet-to-be-written userspace tool wconfig (or something like that) "I need a STA in INFRA mode and want to drive it on the wlan0 card". So wconfig goes and write()s some data to /dev/wlan0 telling the 80211 code to setup a virtual net_device for the driver associated to /dev/wlan0.
The virtual interface is then configured though /dev/wlan0 using write() (no ugly ioctl anymore, you see...). Config data like TX rate, current essid,.... basically everything + xyz which is done by WE today, is written to /dev/wlan0.
This config data is entirely cached in the 80211 code for the /dev/wlan0 instance. This is important, to have the data persistent throughout suspend/resume cycles, if up/down cycles.
After configuring, a virtual net_device (let's call it wlan0) exists, which can be brought up by ifconfig and data can be transferred though it as usual.
This whole concept is derived from how dscape does the stuff. With a major exception, that a device node instead of a net_device is used for the master device. With the effect of getting rid of the ugly WE ioctl stuff.
Quoted 5 lines
Quoted 5 lines
* Long term, wireless should go from being a library of common code to a "real" wireless stack, as shown in the template developed by David Miller:
http://kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2
Zhu Yi @ Intel and Vladmir @ somewhere both independently did some work in this area.
This looks very interresting and in fact is part of our thoughts I explained above.
Quoted 5 lines
Quoted 5 lines
* I prefer GPL-only code. Dual licensing has proven in practice to be a logistical nightmare that concentrates power in the hands of a few. Dual licensing, BSD licensing works for some, but GPL-only code is quite simply the least amount of flamewars, headaches and worry. IOW, the P.I.T.A. level of GPL-only code is lowest.
I personally prefer EXPORT_SYMBOL_GPL().
But that's only my opinion and that does not really matter. ;)
Quoted 2 lines
Quoted 2 lines
Dual licensed code gives kernel hackers yet more legal crapola to worry about, which is never a good thing.
I don't see a point in dual licensing it.
The only benefit would be to allow BSD people to take the code. Honestly, I really don't see this happening, anyway. ;) They have net80211.
Quoted 4 lines
Quoted 4 lines
Patches welcome from all motivated, clueful parties. Jiri Benc has a long series of patches that looks nice. Johannes Berg has done some work on the ieee80211 softmac stuff and hw WEP. But maybe DeviceScape is what people like now.
Well, "like" is a strong word. I personally would say "It is better than all currently existing solutions, if some final polishing is done to dscape."
Signature · 1 line
Greetings Michael.
Hi Michael,
Quoted 18 lines
How would the virtual interfaces look like? That is quite easy to answer. They are
net_devices, as they transfer data.
They should probaly _not_ be on top of the ethernet, as 80211 does not have very much in common with ethernet. Basically they share the same MAC address format. Does someone have another thing, which he thinks is shared?
How would the master interface look like? A somewhat unusual idea came up. Using a device node in /dev. So every wireless card in the system would have a node in /dev associated (/dev/wlan0for example).
A node for the master device would be ok, because no data is transferred through it. It is only a configuration interface.
So you would tell the, yet-to-be-written userspace tool wconfig (or something like that) "I need a STA in INFRA mode and want to drive it on the wlan0 card". So wconfig goes and write()s some data to/dev/wlan0telling the 80211 code to setup a virtualnet_devicefor the driver associated to/dev/wlan0.
The virtual interface is then configured though/dev/wlan0usingwrite()(no ugly ioctl anymore, you see...). Config data like TX rate,
Quoted 8 lines
current essid,.... basically everything + xyz which is done by WE today, is written to
/dev/wlan0.
This config data is entirely cached in the 80211 code for the/dev/wlan0instance. This is important, to have the data persistent throughout suspend/resume cycles, if up/down cycles.
After configuring, a virtualnet_device(let's call it wlan0) exists, which can be brought up by ifconfig and data can be transferred though it as usual.
what is wrong with using netlink and/or sysfs for it? I don't see the advantage of defining another /dev something interface.
Regards
Marcel
Quoted 29 lines · you
Hi Michael,
Quoted 18 lines
How would the virtual interfaces look like? That is quite easy to answer. They are
net_devices, as they transfer data.
They should probaly _not_ be on top of the ethernet, as 80211 does not have very much in common with ethernet. Basically they share the same MAC address format. Does someone have another thing, which he thinks is shared?
How would the master interface look like? A somewhat unusual idea came up. Using a device node in /dev. So every wireless card in the system would have a node in /dev associated (/dev/wlan0for example).
A node for the master device would be ok, because no data is transferred through it. It is only a configuration interface.
So you would tell the, yet-to-be-written userspace tool wconfig (or something like that) "I need a STA in INFRA mode and want to drive it on the wlan0 card". So wconfig goes and write()s some data to/dev/wlan0telling the 80211 code to setup a virtualnet_devicefor the driver associated to/dev/wlan0.
The virtual interface is then configured though/dev/wlan0usingwrite()(no ugly ioctl anymore, you see...). Config data like TX rate,Quoted 8 lines
current essid,.... basically everything + xyz which is done by WE today, is written to
/dev/wlan0.
This config data is entirely cached in the 80211 code for the/dev/wlan0instance. This is important, to have the data persistent throughout suspend/resume cycles, if up/down cycles.
After configuring, a virtualnet_device(let's call it wlan0) exists, which can be brought up by ifconfig and data can be transferred though it as usual.
Quoted 2 lines
what is wrong with using netlink and/or sysfs for it? I don't see the advantage of defining another /dev something interface.
Nothing is wrong with that.
"brainstorming" was the most dominant word in the whole text. ;) I just personally liked the idea of having a device node in /dev for every existing hardware wlan card. Like we have device nodes for other real hardware, too. It felt like a bit of a "unix way" to do this to me. I don't say this is the way to go.
If a netlink socket is used (which is possible, for sure), we stay with the old way of having no device node in /dev for networking devices. That is ok. But that is really only an implementation detail (and for sure a matter of taste).
The _real_ main point I wanted to make was to _not_ use a net_device for the master device. What else should be used for master device, let it be a device node or a netlink socket, is rather unimportant at this stage.
Signature · 1 line
Greetings Michael.
Hi Michael,
Quoted 27 lines
Quoted 27 lines
Quoted 26 lines
How would the virtual interfaces look like? That is quite easy to answer. They are
net_devices, as they transfer data.
They should probaly _not_ be on top of the ethernet, as 80211 does not have very much in common with ethernet. Basically they share the same MAC address format. Does someone have another thing, which he thinks is shared?
How would the master interface look like? A somewhat unusual idea came up. Using a device node in /dev. So every wireless card in the system would have a node in /dev associated (/dev/wlan0for example).
A node for the master device would be ok, because no data is transferred through it. It is only a configuration interface.
So you would tell the, yet-to-be-written userspace tool wconfig (or something like that) "I need a STA in INFRA mode and want to drive it on the wlan0 card". So wconfig goes and write()s some data to/dev/wlan0telling the 80211 code to setup a virtualnet_devicefor the driver associated to/dev/wlan0.
The virtual interface is then configured though/dev/wlan0usingwrite()(no ugly ioctl anymore, you see...). Config data like TX rate, current essid,.... basically everything + xyz which is done by WE today, is written to/dev/wlan0.
This config data is entirely cached in the 80211 code for the/dev/wlan0instance. This is important, to have the data persistent throughout suspend/resume cycles, if up/down cycles.
After configuring, a virtualnet_device(let's call it wlan0) exists, which can be brought up by ifconfig and data can be transferred though it as usual.
Quoted 5 lines
Quoted 2 lines
what is wrong with using netlink and/or sysfs for it? I don't see the advantage of defining another /dev something interface.
Nothing is wrong with that.
"brainstorming" was the most dominant word in the whole text. ;)
so I might got the wrong impression, because it seemed you put a lot of thinking into the /dev/wlanX stuff without even considering netlink or something else.
Quoted 8 lines
I just personally liked the idea of having a device node in /dev for every existing hardware wlan card. Like we have device nodes for other real hardware, too. It felt like a bit of a "unix way" to do this to me. I don't say this is the way to go.
If a netlink socket is used (which is possible, for sure), we stay with the old way of having no device node in /dev for networking devices. That is ok. But that is really only an implementation detail (and for sure a matter of taste).
At the OLS last year, I think the consensus was to use netlink for all configuration task. However this was mainly driven by Harald Welte and he might be able to talk about the pros and cons of netlink versus a character device.
Quoted 4 lines
The _real_ main point I wanted to make was to _not_ use a
net_devicefor the master device. What else should be used for master device, let it be a device node or a netlink socket, is rather unimportant at this stage.
I am all for it, because I don't like dummy Ethernet devices that are only used for configuration. I am still not happy that IrDA uses irda0 to get somekind of packet management etc. instead of implementing a real suitable hardware abstraction.
Regards
Marcel
Quoted 10 lines · Marcel Holtmann
Quoted 8 lines
I just personally liked the idea of having a device node in /dev for every existing hardware wlan card. Like we have device nodes for other real hardware, too. It felt like a bit of a "unix way" to do this to me. I don't say this is the way to go.
If a netlink socket is used (which is possible, for sure), we stay with the old way of having no device node in /dev for networking devices. That is ok. But that is really only an implementation detail (and for sure a matter of taste).
Quoted 4 lines
At the OLS last year, I think the consensus was to use netlink for all configuration task. However this was mainly driven by Harald Welte and he might be able to talk about the pros and cons of netlink versus a character device.
I think the main advantages of netlink over a character device is its flexible format, which is easily extendable, and multicast capability, which can be used to broadcast events and configuration changes. Its also good to have all the net stuff accessible in a uniform way.
Re: State of the Union: Wireless
In reply to Michael BueschQuoted 8 lines
So, now we asked: How would a sane UI look like. We had a few points:
* The interface needs to support some kind of "master" interface to configure the hardware, 80211 parameters and
to actually configure and setup the
* Virtual interfaces.
Data is transferred only though the virtual interfaces, which could be an AP interface, a STA interface in INFRA or Ad-Hoc mode, etc... . Configuration is done though the master interface.
Two things to inject, from my own little corner of userspace:
1. Monitor mode formatting.
I ported over the BSD radiotap packet header system, it's in the Intel and I beleive some versions of the Devicescape stacks. Using these would be a very good thing for userspace. If for some reason it isn't used, then we (userspace tool people) need something equivalent. I like radiotap primarily because:
* Dynamic per-packet stats. Drivers provide what their firmware is capable of providing per frame. The more info provided the better.
* Expandable headers. New per-frame stats can be added into the RT headers without changing linktype, breaking existing apps, etc.
* Format indicators. Is the 4 byte FCS tacked onto the end of the frame in rfmon? If we don't know this in userspace, we can't do 802.11 validation, wep decoding, and other important stuff. Userspace shouldn't have to know which driver is being used, this ought to be in the frame headers.
Radiotap provides all of those and is already supported by tcpdump, ethereal, kismet, etc.
2. RFMon is weird/breaks interfaces
The other gotcha with rfmon is it often breaks a cards ability to associate (though less often with new cards). Even if it doesn't, whatever tool put it into rfmon is likely to want to take control of the channel hopping, which will interfere with the associations of other virtual interfaces.
Currently single-interface cards (ethX, whatever) thrown into rfmon just plain break, it a pretty obvious way. The linktype changes, traffic stops, and users more or less understand this is going to be the behavior. Once virtual interfaces come into play, it may cause some confusion if you can make virtual interfaces that do sta, adhoc, ap all at once without conflicting, and suddenly bringing up an rfmon interfaces causes them all to break.
I don't know if the solution to this is a warning, marking non-rfmon virtual interfaces down, or just saying "they'll figure it out", but I figured it's worth considering at an early stage.
-m
Signature · 9 lines
Mike Kershaw/Dragorn <[email protected]> GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 <>!*''# Waka waka bang splat tick tick hash ^@`$$- Caret at back-tick dollar dollar dash, !*'$_ Bang splat tick dollar under-score, %*<>#4 Percent splat waka waka number four, &)../ Ampersand right-paren dot dot slash, |{~~SYSTEM HALTED Vertical-bar curly-bracket tilde tilde CRASH.
Quoted 4 lines · Michael Buesch
The _real_ main point I wanted to make was to _not_ use a
net_devicefor the master device. What else should be used for master device, let it be a device node or a netlink socket, is rather unimportant at this stage.
If the only purpose of the master device was configuration, then it would be beter to use something other then a net_device, but you may want to send/receive raw 802.11 packets from userspace, most logicaly over a master interface.
Feyd
Quoted 10 lines · Feyd
Quoted 4 lines · Michael Buesch
The _real_ main point I wanted to make was to _not_ use a
net_devicefor the master device. What else should be used for master device, let it be a device node or a netlink socket, is rather unimportant at this stage.If the only purpose of the master device was configuration, then it would be beter to use something other then a
net_device, but you may want to send/receive raw 802.11 packets from userspace, most logicaly over a master interface.
We thought about that for a while, but it may not be feasible. Certain hardware that manages more stuff than others in firmware/hardware may not allow sending raw frames without going into some special mode, which is better handled by adding some kind of raw virtual device.
johannes
Quoted 6 lines · Michael Buesch
How would the virtual interfaces look like? That is quite easy to answer. They are
net_devices, as they transfer data.
They should probaly _not_ be on top of the ethernet, as 80211 does not have very much in common with ethernet. Basically they share the same MAC address format. Does someone have another thing, which he thinks is shared?
If you can make the virtual devices look like ethernet, I believe a lot of other things will just work w/out hacking, including user-space apps that think they know exactly what an ethernet frame/device looks like.
The only things I think of that won't work like ethernet is the ability to change the local MAC address or go into promisc mode. And, it's always possible that future wifi hardware will support that as well. Either way, the current API handles this fine: the requests to change will just fail with a convenient error.
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 17 lines · On Fri, 06 Jan 2006 13:46:15 +0100 Patrick McHardy <[email protected]> wrote:
Quoted 10 lines · Marcel Holtmann
Quoted 8 lines
I just personally liked the idea of having a device node in /dev for every existing hardware wlan card. Like we have device nodes for other real hardware, too. It felt like a bit of a "unix way" to do this to me. I don't say this is the way to go.
If a netlink socket is used (which is possible, for sure), we stay with the old way of having no device node in /dev for networking devices. That is ok. But that is really only an implementation detail (and for sure a matter of taste).Quoted 4 lines
At the OLS last year, I think the consensus was to use netlink for all configuration task. However this was mainly driven by Harald Welte and he might be able to talk about the pros and cons of netlink versus a character device.
Quoted 4 lines
I think the main advantages of netlink over a character device is its flexible format, which is easily extendable, and multicast capability, which can be used to broadcast events and configuration changes. Its also good to have all the net stuff accessible in a uniform way.
Also netlink doesn't have the naming issues that /dev node would.
Signature · 2 lines
Stephen Hemminger <[email protected]> OSDL http://developer.osdl.org/~shemminger
Quoted 17 lines · Patrick McHardy
Quoted 10 lines · Marcel Holtmann
Quoted 8 lines
I just personally liked the idea of having a device node in /dev for every existing hardware wlan card. Like we have device nodes for other real hardware, too. It felt like a bit of a "unix way" to do this to me. I don't say this is the way to go.
If a netlink socket is used (which is possible, for sure), we stay with the old way of having no device node in /dev for networking devices. That is ok. But that is really only an implementation detail (and for sure a matter of taste).Quoted 4 lines
At the OLS last year, I think the consensus was to use netlink for all configuration task. However this was mainly driven by Harald Welte and he might be able to talk about the pros and cons of netlink versus a character device.
Quoted 4 lines
I think the main advantages of netlink over a character device is its flexible format, which is easily extendable, and multicast capability, which can be used to broadcast events and configuration changes. Its also good to have all the net stuff accessible in a uniform way.
character devices are far easier to script. this really sounds like the type of configuration stuff that sysfs was designed for. can we avoid yet another configuration tool that's required?
David Lang
Signature · 2 lines
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
David S. Miller
maintainerFrom: David Lang <[email protected]>
Date: Fri, 6 Jan 2006 14:16:17 -0800 (PST)
Quoted 3 lines
character devices are far easier to script. this really sounds like the type of configuration stuff that sysfs was designed for. can we avoid yet another configuration tool that's required?
netlink is being recommended exactly because it can result in only needing one tool for everything
Quoted 9 lines · David Lang
Quoted 4 lines · Patrick McHardy
I think the main advantages of netlink over a character device is its flexible format, which is easily extendable, and multicast capability, which can be used to broadcast events and configuration changes. Its also good to have all the net stuff accessible in a uniform way.
character devices are far easier to script. this really sounds like the type of configuration stuff that sysfs was designed for. can we avoid yet another configuration tool that's required?
I think its not just configuration but also event handling for associating, link layer authentication, ..., which is not something handled by scripts but by some daemon. It might also want to set up routes or ip addresses which is done using netlink anyway.
Quoted 9 lines · David S. Miller
From: David Lang <[email protected]>
Date: Fri, 6 Jan 2006 14:16:17 -0800 (PST)Quoted 3 lines
character devices are far easier to script. this really sounds like the type of configuration stuff that sysfs was designed for. can we avoid yet another configuration tool that's required?
netlink is being recommended exactly because it can result in only needing one tool for everything
Yes, iproute2 rocks!
I recently discovered that it can do "xfrm" stuff and was amazed to see that the developer(s) had a big clue about what we like to see (and what is human readable), if we type "ip xfrm state" and "ip xfrm policy" as opposed to "setkey -D" and "setkey -PD".
So I can only hope that netlink and iproute will be chosen as a way to represent it to the user, just because of the clueful developers of iproute2.
Regards
Ingo Oeser
Quoted 10 lines · Patrick McHardy
Quoted 8 lines · Marcel Holtmann
Quoted 8 lines
I just personally liked the idea of having a device node in /dev for every existing hardware wlan card. Like we have device nodes for other real hardware, too. It felt like a bit of a "unix way" to do this to me. I don't say this is the way to go.
If a netlink socket is used (which is possible, for sure), we stay with the old way of having no device node in /dev for networking devices. That is ok. But that is really only an implementation detail (and for sure a matter of taste).
Quoted 7 lines
Quoted 4 lines
At the OLS last year, I think the consensus was to use netlink for all configuration task. However this was mainly driven by Harald Welte and he might be able to talk about the pros and cons of netlink versus a character device.
I think the main advantages of netlink over a character device is its flexible format, which is easily extendable, and multicast capability,
Especially the multicast capability is _extrmely_ handy, since you basically can have all sorts of dock-applets or monitoring applications that don't need to rely on polling device status but instead get multicast notifications of configuration changes.
Also, as a theoretical option, you could implement parts of the wireless subsystem outside of the kernel - esp. for the more extensive authentication/keying/rekeying functions.
A wireless configuration program would just speak netlink to a particular netlink multicast group. Whether or not the receiving functional entity is implemented in the kernel or in a wireless daemon in userspace could be completely transparent, as long as the protocol is the same.
Signature · 4 lines
- Harald Welte <[email protected]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)