> > * 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. ;)
> > * 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.
> > * 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.
> > * 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. ;)
> > 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.
> > 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."
--
Greetings Michael.
Hi Michael,
> 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.
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
On Friday 06 January 2006 12:38, you wrote:
> Hi Michael,
>
> > 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.
>
> 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.
--
Greetings Michael.
Hi Michael,
> > > 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.
> >
> > 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.
> 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.
> 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.
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
Marcel Holtmann wrote:
>>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.
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.
> 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
--
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.
Michael Buesch wrote:
> 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.
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
On Fri, 2006-01-06 at 17:12 +0100, Feyd wrote:
> Michael Buesch wrote:
> > 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.
>
> 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
Michael Buesch wrote:
> 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
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
On Fri, 06 Jan 2006 13:46:15 +0100
Patrick McHardy <[email protected]> wrote:
> Marcel Holtmann wrote:
>
> >>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.
>
> 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.
--
Stephen Hemminger <[email protected]>
OSDL http://developer.osdl.org/~shemminger
On Fri, 6 Jan 2006, Patrick McHardy wrote:
> Marcel Holtmann wrote:
>
>>> 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.
>
> 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
--
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
From: David Lang <[email protected]>
Date: Fri, 6 Jan 2006 14:16:17 -0800 (PST)
> 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
David Lang wrote:
> On Fri, 6 Jan 2006, Patrick McHardy wrote:
>
>> 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.
David S. Miller wrote:
> From: David Lang <[email protected]>
> Date: Fri, 6 Jan 2006 14:16:17 -0800 (PST)
>
> > 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
On Fri, Jan 06, 2006 at 01:46:15PM +0100, Patrick McHardy wrote:
> Marcel Holtmann wrote:
>
> >>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.
>
> 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.
--
- Harald Welte <[email protected]> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)