Re: State of the Union: Wireless / 802.11 master device
On Thu, 19 Jan 2006 14:23:35 -0500 "John W. Linville" <[EMAIL PROTECTED]> wrote: > On Thu, Jan 19, 2006 at 08:03:43PM +0100, Stefan Rompf wrote: > > Am Donnerstag 19 Januar 2006 16:56 schrieb John W. Linville: > > > > > The above represents my thinking on the issue. Ultimately the WiPHY > > > (aka radio) device should be thought of as a new class of driver, > > > distinct from a netdev. If we have to reroute some infrastructure > > > (i.e. qdisc) to make that practical, we should do so. > > > > > > It makes the job bigger, but I think it is the right way to go. > > > > I couldn't disagree more. There is absolutely no point in duplicating > > infrastructure used for queuing, qdisc interface, NAPI, managing multicast > > reception, registration + reference count, statistics, etc. just to avoid > > the > > master device showing up in ifconfig. > > I don't believe I suggested this. I was implying that we teach the > existing infrastructure how to deal with the wiphy device concept. > I would make the master device its own class device. The object hierarchy is: kobject class_device (in /sys/class) net_device (in /sys/class/net) ether_device Properties of net_device are: takes network related ioctl's (legacy) can be controled by netlink as a device can transmit sk_buff's can be scheduled with NAPI, ... An ether_device is just a sub-class of net_device that takes a certain frame format (and responds to ethtool). If your master_device takes 802.11 packets as sk_buff's then it should be a net_device. If you need to stub somethings or do some object refactoring to split out net_device finer than that makes sense to. -- Stephen Hemminger <[EMAIL PROTECTED]> OSDL http://developer.osdl.org/~shemminger - 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: State of the Union: Wireless / 802.11 master device
On Thu, Jan 19, 2006 at 04:30:34PM +0100, feyd wrote: > The point of the master not being netdev is to separate the two > functions it serves - configuration and master interface, as combining > them makes sense only for softmac devices. > The single queue that all the packets have to pass and can be sheduled > is the raw/rfmon device. > > phy0 # not netdev, represents rather the radio > *->ap0 # no qdisc > *->sta0 # -//- > *->raw0 # qdisc This should also let use use raw0 to write packets from userspace in a consistent format (and this means the drivers will have to do some work in some cases if they don't match the 'consistent format'.) Right now I've been working on a userspace library to do common tx, because of the 5 or so drivers that I know support it, many have their own quirks about what they can do and how they format things (3addr, 4addr, different endians on the same host, etc). I also think some sort of ioctl to get the feature set of the rawX device would be good -- some can't inject all frames, some override sequence/bsstimestamp, etc, and we need to know this from userspace for some applications. I *suppose* we could even include endian formats in that, but I don't know that userspace ought to be dealing with endian flipping for a specific card type. -m -- Mike Kershaw/Dragorn <[EMAIL PROTECTED]> GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 "For every action there is an equal and opposite reaction. Unfortunately, for most people, that reaction is illiteracy." pgpa40sonJ1h0.pgp Description: PGP signature
Re: State of the Union: Wireless / 802.11 master device
On Thu, Jan 19, 2006 at 08:03:43PM +0100, Stefan Rompf wrote: > Am Donnerstag 19 Januar 2006 16:56 schrieb John W. Linville: > > > The above represents my thinking on the issue. Ultimately the WiPHY > > (aka radio) device should be thought of as a new class of driver, > > distinct from a netdev. If we have to reroute some infrastructure > > (i.e. qdisc) to make that practical, we should do so. > > > > It makes the job bigger, but I think it is the right way to go. > > I couldn't disagree more. There is absolutely no point in duplicating > infrastructure used for queuing, qdisc interface, NAPI, managing multicast > reception, registration + reference count, statistics, etc. just to avoid the > master device showing up in ifconfig. I don't think we should duplicate infrastructure. I think we should adapt and enhance that infrastructure in ways appropriate for wireless networking. 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: State of the Union: Wireless / 802.11 master device
On Thu, Jan 19, 2006 at 08:03:43PM +0100, Stefan Rompf wrote: > Am Donnerstag 19 Januar 2006 16:56 schrieb John W. Linville: > > > The above represents my thinking on the issue. Ultimately the WiPHY > > (aka radio) device should be thought of as a new class of driver, > > distinct from a netdev. If we have to reroute some infrastructure > > (i.e. qdisc) to make that practical, we should do so. > > > > It makes the job bigger, but I think it is the right way to go. > > I couldn't disagree more. There is absolutely no point in duplicating > infrastructure used for queuing, qdisc interface, NAPI, managing multicast > reception, registration + reference count, statistics, etc. just to avoid the > master device showing up in ifconfig. I don't believe I suggested this. I was implying that we teach the existing infrastructure how to deal with the wiphy device concept. 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: State of the Union: Wireless / 802.11 master device
On Thu, Jan 19, 2006 at 05:44:53PM +0100, Jiri Benc wrote: > On Thu, 19 Jan 2006 10:56:19 -0500, John W. Linville wrote: > > The above represents my thinking on the issue. Ultimately the WiPHY > > (aka radio) device should be thought of as a new class of driver, > > distinct from a netdev. If we have to reroute some infrastructure > > (i.e. qdisc) to make that practical, we should do so. > > I definitely agree. But it means that possibly large changes will be > needed in the networking core. Do you think it will be acceptable for > non-802.11 developers? It depends, of course, on the patches. If the end goal is sound (as I believe it is) and the changes are responsible, I don't see why we couldn't make such changes. I can't help but believe that part of the problem with wireless so far is based on the feeling that we need to tip-toe around and try to morph ourselves to fit existing infrastructure. If we need new infrastructure, I think we should build it. Does that mean we should rip-out existing architecture and break things just because we don't like them? No. I only mean to say that wireless should be a 1st class citizen, and that the kernel should accomodate it properly. 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: State of the Union: Wireless / 802.11 master device
Am Donnerstag 19 Januar 2006 16:56 schrieb John W. Linville: > The above represents my thinking on the issue. Ultimately the WiPHY > (aka radio) device should be thought of as a new class of driver, > distinct from a netdev. If we have to reroute some infrastructure > (i.e. qdisc) to make that practical, we should do so. > > It makes the job bigger, but I think it is the right way to go. I couldn't disagree more. There is absolutely no point in duplicating infrastructure used for queuing, qdisc interface, NAPI, managing multicast reception, registration + reference count, statistics, etc. just to avoid the master device showing up in ifconfig. We would increase maintenance burden and development time, and this in a situation where we'll have more than enough code to write and test. Let us be pragmatic: As soon as we realize that we need more then just a totally trivial part of the networking core, the master device should be a netdev. Stefan - 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: State of the Union: Wireless / 802.11 master device
On Thu, 19 Jan 2006 10:56:19 -0500, John W. Linville wrote: > The above represents my thinking on the issue. Ultimately the WiPHY > (aka radio) device should be thought of as a new class of driver, > distinct from a netdev. If we have to reroute some infrastructure > (i.e. qdisc) to make that practical, we should do so. I definitely agree. But it means that possibly large changes will be needed in the networking core. Do you think it will be acceptable for non-802.11 developers? Another possibility could be master net_device invisible to userspace. -- Jiri Benc SUSE Labs - 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: State of the Union: Wireless / 802.11 master device
On Thu, Jan 19, 2006 at 04:30:34PM +0100, feyd wrote: > The design that is rather agreed on proposes a master device that is > not netdev, is used for configuration of the shared resources (radio) > and for virtual devices creation, where the virtual devices cannot > switch mode. The above represents my thinking on the issue. Ultimately the WiPHY (aka radio) device should be thought of as a new class of driver, distinct from a netdev. If we have to reroute some infrastructure (i.e. qdisc) to make that practical, we should do so. It makes the job bigger, but I think it is the right way to go. 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: State of the Union: Wireless / 802.11 master device
Jouni Malinen wrote: > This may be the case with designs that do not provide anything else > than a simple interface for delivering and receiving frames. However, > the benefits--and I would be prepared to say even requirements--of > having a master device are extensive enough to use it with many wlan > designs. If a generic design is desired for both types, even fullmac > devices would need to keep the master netdev even if it is not really > needed. Other option would be to make it optional to add the master > netdev and have something else presenting the wlan device. The point of the master not being netdev is to separate the two functions it serves - configuration and master interface, as combining them makes sense only for softmac devices. The single queue that all the packets have to pass and can be sheduled is the raw/rfmon device. phy0 # not netdev, represents rather the radio *->ap0 # no qdisc *->sta0 # -//- *->raw0 # qdisc > In addition, even fullmac devices may have uses for master netdev. For > example, in AP mode with dynamic VLAN configuration (RADIUS > authentication server selecting which VLAN to use), there may be > benefits of being able to use multiple virtual interfaces (netdevs) that > would logically be collected into master netdev for scheduling and > transmission. If I understand what you mean, it could look like this: phy0 *->ap0 # qdisc *->vlan0 *->vlan1 There can be temptation to replace the phy0 by the ap0 (and by the raw0 in the former) so the master would still be netdev, but that would require the ap0 to be able to switch modes. The design that is rather agreed on proposes a master device that is not netdev, is used for configuration of the shared resources (radio) and for virtual devices creation, where the virtual devices cannot switch mode. Feyd - 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: State of the Union: Wireless / 802.11 master device
On Wed, Jan 18, 2006 at 09:18:26AM +0100, Feyd wrote: > With fullmac devices the master interface makes no sense, it cannot be > used for neither the sniffing or QoS. The design where the master device > is something else than net_device is cleaner, it treats both soft/fullmac > devices equaly, without need to special-case one of them. This may be the case with designs that do not provide anything else than a simple interface for delivering and receiving frames. However, the benefits--and I would be prepared to say even requirements--of having a master device are extensive enough to use it with many wlan designs. If a generic design is desired for both types, even fullmac devices would need to keep the master netdev even if it is not really needed. Other option would be to make it optional to add the master netdev and have something else presenting the wlan device. In addition, even fullmac devices may have uses for master netdev. For example, in AP mode with dynamic VLAN configuration (RADIUS authentication server selecting which VLAN to use), there may be benefits of being able to use multiple virtual interfaces (netdevs) that would logically be collected into master netdev for scheduling and transmission. -- Jouni MalinenPGP id EFC895FA - 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: State of the Union: Wireless / 802.11 master device
Jouni Malinen wrote: On Tue, Jan 17, 2006 at 01:05:16PM +0100, Jiri Benc wrote: On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote: Actually, there is a use for the master device. It can be used to monitor what is going on over the radio from all virtual APs/STAs, e.g., by running Ethereal on it. You can add a new "soft" monitor interface and use it instead. There is no need for separate master device. Sure, you can do it that way, too. However, this is not the only use. I just remembered another one: QoS. Devicescape 802.11 code uses a qdisc on the master interface to take care of determining which hardware TX queue to use with WMM (which uses four different TX queues). With fullmac devices the master interface makes no sense, it cannot be used for neither the sniffing or QoS. The design where the master device is something else than net_device is cleaner, it treats both soft/fullmac devices equaly, without need to special-case one of them. Feyd - 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: State of the Union: Wireless / 802.11 master device
On Tue, 17 Jan 2006 23:16:43 +0100 Stefan Rompf <[EMAIL PROTECTED]> wrote: > Am Dienstag 17 Januar 2006 20:42 schrieb Jouni Malinen: > > > Sure, you can do it that way, too. However, this is not the only use. I > > just remembered another one: QoS. Devicescape 802.11 code uses a qdisc > > on the master interface to take care of determining which hardware TX > > queue to use with WMM (which uses four different TX queues). > > so after all, it should be an implementation detail whether our master device > is a struct net_device or not, depending on how much infrastructure of the > networking core we need at this point. > > Stefan What ever it is, it needs to be a kobject, to allow for sysfs to work. Also, please make it hot removable (like netdevices) so module can be unloaded at any time (independent of ref counts). Look at bonding, bridging, and VLAN to see how layered devices can work. -- Stephen Hemminger <[EMAIL PROTECTED]> OSDL http://developer.osdl.org/~shemminger - 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: State of the Union: Wireless / 802.11 master device
Am Dienstag 17 Januar 2006 20:42 schrieb Jouni Malinen: > Sure, you can do it that way, too. However, this is not the only use. I > just remembered another one: QoS. Devicescape 802.11 code uses a qdisc > on the master interface to take care of determining which hardware TX > queue to use with WMM (which uses four different TX queues). so after all, it should be an implementation detail whether our master device is a struct net_device or not, depending on how much infrastructure of the networking core we need at this point. Stefan - 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: State of the Union: Wireless / 802.11 master device
On Tue, Jan 17, 2006 at 02:55:31PM -0500, jamal wrote: > On Tue, 2006-17-01 at 11:42 -0800, Jouni Malinen wrote: > so if i understood correctly: > You have a master netdevice which underneath it has child netdevices? I'm not sure what exactly "child netdev" means, but it sounds like something that could be indeed what the stack is using. The master netdev has a queue and all other netdevs do not use their own queue (i.e., they share the one used in the master netdev and all TX frames go through that). > > Each > > virtual interface do not include own queue and outgoing frames are > > queued through the master device (again, this is something that matches > > with VLAN implementation). > If i understood you correctly, what you are doing is certainly > reasonable. Instead of restructuring the netdevice layer to deal with > with multiple independent h/ware tx queues you've added a mother device > which does intermidiate queueing. The master netdev collects all TX frames and the special 802.11-aware qdisc takes care of scheduling them, e.g., based on WMM access categories to independent hardware TX queues. > > For WMM, the frames in different classes > > would need to be scheduled from all virtual interfaces together, not > > just separately. Would there be a better way of doing this without using > > a master netdev and qdisc/netsched? > I havent been following the thread so i dont understand this problem. > Can you explain it in details? Simon wrote some more details on related topic. The way I see this is that there can be multiple virtual netdevs (e.g., multiple virtual APs) using the same wlan radio. The frames for all these virtual APs should be able to share the same scheduling procedure, e.g., to allow voice calls get high priority regardless of which virtual AP is sending the frames for these traffic flows. Being able to set this all with existing tc tool for the master netdev looks like quite clean way of handling this. -- Jouni MalinenPGP id EFC895FA - 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: State of the Union: Wireless
To do qos properly there needs to be a single net_device that a single qdisc can be installed on - this alone is a good reason for a master net_device. (there must be a single 802.11 qdisc for a single physical piece of hardware). Here is another reason (for hardware devices that do not include a MLME in hardware): In the Devicescape stack the hardware driver (called the low level driver) uses an internal interface to the rest of the stack. The master net_device is created by the rest of the stack (80211.o module). I would like to change this, so that the hardware driver itself creates a net_device, with an 802.11 ARP_HDR. This would be the master device, and the interface between the kernel 802.11 code and a hardware 802.11 device that does not implement the MLME in hardware. The 80211.o module in the kernel would hook itself into this device by watching for the broadcast message when a new device is registered, and automatically installing the 802.11 qdisc on the new device. When the hadware receives 802.11 frames the hardware device driver would set the protocol type to 802.11 before calling netif_rx, and the 80211.o module would register itself as a protocol handler for 802.11. This change would remove the current special internal interface in the Devicescape stack between the hardware driver and the core of the stack - and would make the stack better integrated with the kernel. The design here is similar to the VLAN code for the RX direction, but using the qdisc for both queueing and part of the stack implementation is a new direction for the TX. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jiri Benc Sent: Tuesday, January 17, 2006 2:05 AM To: Jouni Malinen Cc: Krzysztof Halasa; Mike Kershaw; netdev@vger.kernel.org; Stefan Rompf; John W.Linville Subject: Re: State of the Union: Wireless On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote: > Actually, there is a use for the master device. It can be used to > monitor what is going on over the radio from all virtual APs/STAs, > e.g., by running Ethereal on it. You can add a new "soft" monitor interface and use it instead. There is no need for separate master device. -- Jiri Benc SUSE Labs - 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: State of the Union: Wireless / 802.11 master device
On Tue, 2006-17-01 at 11:42 -0800, Jouni Malinen wrote: > > Sure, you can do it that way, too. However, this is not the only use. I > just remembered another one: QoS. Devicescape 802.11 code uses a qdisc > on the master interface to take care of determining which hardware TX > queue to use with WMM (which uses four different TX queues). so if i understood correctly: You have a master netdevice which underneath it has child netdevices? > Each > virtual interface do not include own queue and outgoing frames are > queued through the master device (again, this is something that matches > with VLAN implementation). If i understood you correctly, what you are doing is certainly reasonable. Instead of restructuring the netdevice layer to deal with with multiple independent h/ware tx queues you've added a mother device which does intermidiate queueing. > For WMM, the frames in different classes > would need to be scheduled from all virtual interfaces together, not > just separately. Would there be a better way of doing this without using > a master netdev and qdisc/netsched? > I havent been following the thread so i dont understand this problem. Can you explain it in details? cheers, jamal - 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: State of the Union: Wireless / 802.11 master device
On Tue, Jan 17, 2006 at 01:05:16PM +0100, Jiri Benc wrote: > On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote: > > Actually, there is a use for the master device. It can be used to > > monitor what is going on over the radio from all virtual APs/STAs, e.g., > > by running Ethereal on it. > > You can add a new "soft" monitor interface and use it instead. There is > no need for separate master device. Sure, you can do it that way, too. However, this is not the only use. I just remembered another one: QoS. Devicescape 802.11 code uses a qdisc on the master interface to take care of determining which hardware TX queue to use with WMM (which uses four different TX queues). Each virtual interface do not include own queue and outgoing frames are queued through the master device (again, this is something that matches with VLAN implementation). For WMM, the frames in different classes would need to be scheduled from all virtual interfaces together, not just separately. Would there be a better way of doing this without using a master netdev and qdisc/netsched? -- Jouni MalinenPGP id EFC895FA - 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: State of the Union: Wireless
On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote: > Actually, there is a use for the master device. It can be used to > monitor what is going on over the radio from all virtual APs/STAs, e.g., > by running Ethereal on it. You can add a new "soft" monitor interface and use it instead. There is no need for separate master device. -- Jiri Benc SUSE Labs - 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: State of the Union: Wireless
Jouni Malinen <[EMAIL PROTECTED]> writes: > Actually, there is a use for the master device. It can be used to > monitor what is going on over the radio from all virtual APs/STAs, e.g., > by running Ethereal on it. Ok. Then I think all "master" operations should be applied to this master netdev, and it could be obviously different from the rest (different initial name and/or ARPHRD_ etc). > Isn't VLANs implemented in the same way It is. -- Krzysztof Halasa - 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: State of the Union: Wireless
On Wed, Jan 11, 2006 at 07:25:11PM +0100, Krzysztof Halasa wrote:
> 3. To have a master device which isn't represented by a network
> device (ifconfig doesn't show it etc.) but can be accessed only by
> the wireless tools. Or just using sysfs, echo and cat can be best
> tools. The slaves (netdevs) can be created and deleted at will.
>
> No obscure netdev with no apparent functionality and nothing special
> in the first, last or whichever netdev.
Actually, there is a use for the master device. It can be used to
monitor what is going on over the radio from all virtual APs/STAs, e.g.,
by running Ethereal on it. Isn't VLANs implemented in the same way with
the netdev added by the driver ("master device"). The low-level wireless
driver could do the same thing and then user space tools can add
whatever virtual interfaces are needed.
--
Jouni MalinenPGP id EFC895FA
-
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: State of the Union: Wireless
Jiri Benc <[EMAIL PROTECTED]> writes: > I think this is manageable. > > We need real 802.11 devices - all of frames, including management ones, > end up in one queue (in one net_device). And we are not able to do > Ethernet->802.11 conversion then, because we don't know how (and storing > pointer to originating net_device or so in cb is not a solution, as the > device can go away while the frame is queued). Also management frames > with Ethernet headers are a bit hard to imagine. Exactly. Testing DECNET etc. (anyone using it at all?) should not be a problem - we don't carry DECNET over most link types anyway and if someone wants it it could be easily added. And we're going to support bridging with Ethernet, right? -- Krzysztof Halasa - 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: State of the Union: Wireless
On Wed, 11 Jan 2006 20:58:28 +0100, Stefan Rompf wrote: > I see a third problem - the in kernel protocols. Just do a quick fgrep -r > ARPHRD_ over linux/net and you'll see what I mean. While moving away from the > ethernet emulation, we have to touch a bunch of protocols, even ones we > possibly cannot test, e.g. decnet. Even though I don't like the ethernet > emulation hack, I'm not sure if it is worth the pain just to be able to show > up as a real 802.11 device. I think this is manageable. We need real 802.11 devices - all of frames, including management ones, end up in one queue (in one net_device). And we are not able to do Ethernet->802.11 conversion then, because we don't know how (and storing pointer to originating net_device or so in cb is not a solution, as the device can go away while the frame is queued). Also management frames with Ethernet headers are a bit hard to imagine. -- Jiri Benc SUSE Labs - 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: State of the Union: Wireless
On Wed, 11 Jan 2006 13:29:09 -0500, John W. Linville wrote: > > 3. To have a master device which isn't represented by a network > > device (ifconfig doesn't show it etc.) but can be accessed only by > > the wireless tools. Or just using sysfs, echo and cat can be best > > tools. The slaves (netdevs) can be created and deleted at will. > > > > No obscure netdev with no apparent functionality and nothing special > > in the first, last or whichever netdev. > > Yes, this is the option that is making the most sense to me. Thinking a bit more about this, there is really no reason why the last interface couldn't be removed. To retain backward compatibility, it is only needed that one net_device appears after inserting a module/card. -- Jiri Benc SUSE Labs - 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: State of the Union: Wireless
Johannes Berg wrote: >>> - "Global" configuration requests (setting channel etc.) can be performed on >>> any device and will affect all devices. >> Yup. > > I disagree. I rather envision a netlink protocol that says 'you cannot > change the channel on just this single device' (unless the driver > supports it), so you need a request saying 'change channel on all > virtual devices'. Userspace helpers would tell the user that if > necessary. I second this. The global options are properties of the radio (and, depending on how particular firmware handles things, maybe other stuff), and should be configured there. The virtual interfaces should export only their own properties (not limited to virtual stuff, when the card allows for per packet txpower, the interfaces could allow to set the txpower as their own independent property, for exmple), the parent should be used for the rest. That whould nicely describe the sharing. The ioctls could of course handle this transparently and allow to configure anything over any virtual interface. Feyd - 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: State of the Union: Wireless
Am Mittwoch 11 Januar 2006 15:49 schrieb Jiri Benc: > - There should be only as few net_devices as needed. I. e. when the card > acts as a client to one AP, only one device is present. > - The type of a device (AP, client, WDS link, monitor, etc.) should be > specified in the usual way (by iwconfig mode or whatever will eventually > replace it). > - When you need a new device (e. g. because you want to connect to another > AP at the same time, or you want to add a new WDS link), you just invoke > some command and a new device will appear. Then you can configure the new > device in the usual way (iwconfig mode, etc.) That proposal sounds fine to me, it gives users least headaches. > There are two problems regarding native 802.11 devices: I see a third problem - the in kernel protocols. Just do a quick fgrep -r ARPHRD_ over linux/net and you'll see what I mean. While moving away from the ethernet emulation, we have to touch a bunch of protocols, even ones we possibly cannot test, e.g. decnet. Even though I don't like the ethernet emulation hack, I'm not sure if it is worth the pain just to be able to show up as a real 802.11 device. Stefan - 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: State of the Union: Wireless
Am Mittwoch 11 Januar 2006 20:23 schrieb Jeff Garzik: > They may mean carrying some compat code in the kernel for a while, or > some other solution... The compat code could simply call netlink > internally, for example. after all, the most important achievement for driver writers is that there is no need to handle all WE configuration commands seperatly anymore, but get a configuration frame like dscapes struct ieee80211_conf instead. Whether the upper layer library fills it via WE or netlink, nobody cares. Netlink gives userspace the big advantage to change multiple settings at once. Stefan - 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: State of the Union: Wireless
Am Mittwoch 11 Januar 2006 16:05 schrieb Mike Kershaw: > As far as link type, theres no real reason radiotap couldn't be used > internally, but theres also no reason it's needed on anything other than > rfmon if we don't think we'll ever care about per-frame stats in > non-rfmon. a software AP could care for receive statistics to force a client to roam - but after all, this is not important enough to solve it now, so ACK. Stefan - 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: State of the Union: Wireless
On Wed, 11 Jan 2006 14:23:40 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Johannes Berg wrote: > > On Wed, 2006-01-11 at 18:20 +0100, Jiri Benc wrote: > > > > > >>Sure, it is way more better. But again, it's the question of > >>compatibility. I think that at least for some time the new netlink API > >>and WE should coexist. After some time, WE support can be removed. > > > > > > Wouldn't it make more sense to put compatibility one layer up by > > introducing a new helper command 'iwconfig' that has the same user-level > > syntax but calls the netlink api instead? > > > I agree with Jiri's base assertion -- we shouldn't completely obliterate > the userland API immediately, since Linux's holy grail is not breaking > userland. > > They may mean carrying some compat code in the kernel for a while, or > some other solution... The compat code could simply call netlink > internally, for example. > Ideally, any new infrastructure could do all the compatibility translation so existing drivers wouldn't see it. -- Stephen Hemminger <[EMAIL PROTECTED]> OSDL http://developer.osdl.org/~shemminger - 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: State of the Union: Wireless
On Wed, Jan 11, 2006 at 02:23:40PM -0500, Jeff Garzik wrote: > Johannes Berg wrote: > >On Wed, 2006-01-11 at 18:20 +0100, Jiri Benc wrote: > > > > > >>Sure, it is way more better. But again, it's the question of > >>compatibility. I think that at least for some time the new netlink API > >>and WE should coexist. After some time, WE support can be removed. > > > > > >Wouldn't it make more sense to put compatibility one layer up by > >introducing a new helper command 'iwconfig' that has the same user-level > >syntax but calls the netlink api instead? > > > I agree with Jiri's base assertion -- we shouldn't completely obliterate > the userland API immediately, since Linux's holy grail is not breaking > userland. > > They may mean carrying some compat code in the kernel for a while, or > some other solution... The compat code could simply call netlink > internally, for example. Isn't this how "traditional" netdev configuration ioctl's (think ifconfig) are handled already? I would think we would do the same thing for the wireless ioctl's. 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: State of the Union: Wireless
Johannes Berg wrote: On Wed, 2006-01-11 at 18:20 +0100, Jiri Benc wrote: Sure, it is way more better. But again, it's the question of compatibility. I think that at least for some time the new netlink API and WE should coexist. After some time, WE support can be removed. Wouldn't it make more sense to put compatibility one layer up by introducing a new helper command 'iwconfig' that has the same user-level syntax but calls the netlink api instead? I agree with Jiri's base assertion -- we shouldn't completely obliterate the userland API immediately, since Linux's holy grail is not breaking userland. They may mean carrying some compat code in the kernel for a while, or some other solution... The compat code could simply call netlink internally, for example. Jeff - 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: State of the Union: Wireless
Jiri Benc <[EMAIL PROTECTED]> writes: > Because all of frames need to go through the master device. So frames > will be transmitted/received only when the master device is up. You have > two possibilities: > > 1. To have a "physical" master device with no functionality (like you > proposed). > 2. To have one special device that cannot be removed. 3. To have a master device which isn't represented by a network device (ifconfig doesn't show it etc.) but can be accessed only by the wireless tools. Or just using sysfs, echo and cat can be best tools. The slaves (netdevs) can be created and deleted at will. No obscure netdev with no apparent functionality and nothing special in the first, last or whichever netdev. -- Krzysztof Halasa - 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: State of the Union: Wireless
On Wed, Jan 11, 2006 at 07:25:11PM +0100, Krzysztof Halasa wrote: > Jiri Benc <[EMAIL PROTECTED]> writes: > > > Because all of frames need to go through the master device. So frames > > will be transmitted/received only when the master device is up. You have > > two possibilities: > > > > 1. To have a "physical" master device with no functionality (like you > > proposed). > > > > 2. To have one special device that cannot be removed. > > 3. To have a master device which isn't represented by a network > device (ifconfig doesn't show it etc.) but can be accessed only by > the wireless tools. Or just using sysfs, echo and cat can be best > tools. The slaves (netdevs) can be created and deleted at will. > > No obscure netdev with no apparent functionality and nothing special > in the first, last or whichever netdev. Yes, this is the option that is making the most sense to me. 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: State of the Union: Wireless
On Wed, 2006-01-11 at 18:20 +0100, Jiri Benc wrote: > Sure, it is way more better. But again, it's the question of > compatibility. I think that at least for some time the new netlink API > and WE should coexist. After some time, WE support can be removed. Wouldn't it make more sense to put compatibility one layer up by introducing a new helper command 'iwconfig' that has the same user-level syntax but calls the netlink api instead? johannes signature.asc Description: This is a digitally signed message part
Re: State of the Union: Wireless
On Wed, 11 Jan 2006 17:37:00 +0100, Johannes Berg wrote: > I thought I had addresses this already but maybe no one took notice. I > think the 'master' device should not be represented as a net_dev at all, > but be somewhat abstract. In that, you could delete the last real device > attached to it and create a new one, in fact you might *have to* delete > the last attached virtual device (which is a real net_dev) in order to > make an incompatible one (well, I said it might suffice to bring the > other ones down, which is ok too). That abstract thing is represented by ieee80211_device (ieee80211_hw). Yes, I'm proposing nearly the same as you, except that I'm trying to preserve backward compatibility. I think we need it, at least for some time. > I disagree. I rather envision a netlink protocol that says 'you cannot > change the channel on just this single device' (unless the driver > supports it), so you need a request saying 'change channel on all > virtual devices'. Userspace helpers would tell the user that if > necessary. Sure, it is way more better. But again, it's the question of compatibility. I think that at least for some time the new netlink API and WE should coexist. After some time, WE support can be removed. -- Jiri Benc SUSE Labs - 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: State of the Union: Wireless
On Wed, 2006-01-11 at 10:05 -0500, Mike Kershaw wrote: > Agreed, though there is a benefit to being able to specify the type of > the initial card. Many drivers offer it as a modprobe option, ie, to > initialize the card in rfmon to prevent it from sending any probe req's > before configuration. A bit of a fringe IDS aspect, but I don't know if > we ought to cut them out. Does anyone actually USE this functionality? > I don't, myself, but I know it exists. Nah. Like Jiri said, as long as the dev isn't up it doesn't do anything. Not much point in this. That said, the driver is free to still provide that functionality. > I don't know if I concur -- having the "control" interface move around > is confusing. I'd rather have one unique ID for that wireless phy > (however this is presented) and then create dynamic devices from it via > whatever command. Atheros ties this to a master wifiX device that is > uses to spawn dynamic devices. It just seems that, logically, it makes > more sense to have something like: > wlanadddev phy0 dyn0 > wlanadddev phy0 dyn1 > wlanadddev phy1 dyn2 > wlandeldev dyn1 > wlandeldev dyn2 > wlanmakedev phy1 dyn1 > > rather than have the 'source' phy change over time. I thought I had addresses this already but maybe no one took notice. I think the 'master' device should not be represented as a net_dev at all, but be somewhat abstract. In that, you could delete the last real device attached to it and create a new one, in fact you might *have to* delete the last attached virtual device (which is a real net_dev) in order to make an incompatible one (well, I said it might suffice to bring the other ones down, which is ok too). > > - "Global" configuration requests (setting channel etc.) can be performed on > > any device and will affect all devices. > > Yup. I disagree. I rather envision a netlink protocol that says 'you cannot change the channel on just this single device' (unless the driver supports it), so you need a request saying 'change channel on all virtual devices'. Userspace helpers would tell the user that if necessary. > I'd like to know why. :) See above for my counter-argument about > confusing users. I'd be willing to agree that the control phy "master > device" doesn't need to be a netdev, but I think it ought to be a > constant, unique value. Tracking down what interface is still mapped to > what phy in a multicard situation seems like it would make a much bigger > hassle. I think that each of your cards in the multicard case is represented by an abstract 'master' device that is not a net_dev. Unless your driver wants to be smart enough to distribute the virtual devices over multiple physical devices it may control. johannes signature.asc Description: This is a digitally signed message part
Re: State of the Union: Wireless
On Wed, 11 Jan 2006 10:05:19 -0500, Mike Kershaw wrote:
> > - The type of a device (AP, client, WDS link, monitor, etc.) should be
> > specified in the usual way (by iwconfig mode or whatever will eventually
> > replace it).
>
> Agreed, though there is a benefit to being able to specify the type of
> the initial card. Many drivers offer it as a modprobe option, ie, to
> initialize the card in rfmon to prevent it from sending any probe req's
> before configuration. A bit of a fringe IDS aspect, but I don't know if
> we ought to cut them out. Does anyone actually USE this functionality?
> I don't, myself, but I know it exists.
The card should not send any frame when it is down. So the initial mode
doesn't matter.
> I don't know if I concur -- having the "control" interface move around
> is confusing. I'd rather have one unique ID for that wireless phy
> (however this is presented) and then create dynamic devices from it via
> whatever command. Atheros ties this to a master wifiX device that is
> uses to spawn dynamic devices. It just seems that, logically, it makes
> more sense to have something like:
See below.
> > (*) At first, I was thinking that the first device ("master device")
> > shouldn't allow to be deleted. But it doesn't solve anything (don't want to
> > make this mail longer; ask me if you want to know why) and just confuses
> > users.
>
> I'd like to know why. :) See above for my counter-argument about
> confusing users. I'd be willing to agree that the control phy "master
> device" doesn't need to be a netdev, but I think it ought to be a
> constant, unique value.
Because all of frames need to go through the master device. So frames
will be transmitted/received only when the master device is up. You have
two possibilities:
1. To have a "physical" master device with no functionality (like you
proposed). It's just hanging there and its purpose is obscure for an
user. It's confusing for him - the master device is not usable at all,
it is just present in list produced by ifconfig and it gets up and down
randomly by itself (or, the worst case, you have to up it manually to
let your wifi work).
2. To have one special device that cannot be removed. It acts exactly
like devices in my proposal, but you can't remove it. It doesn't work -
you have to have this device up, otherwise your wifi device won't
send/receive anything (imagine this situation: add_new_iface wlan0 wlan1
; iwconfig wlan1 mode managed ; ifconfig wlan1 up -- oops, I have my
card configured properly but it doesn't work).
In the second case you still need to select master device dynamically.
It has the "advantage" that you can pass struct net_device to a driver
(because you have one that cannot be removed). But if you look closer,
it is not an advantage at all - the driver is still not allowed to do
anything useful with that net_device (because most operations need to be
performed on several net_devices so you need ieee80211 to do this for
you anyway).
Regarding your comment about "control" interface moving around: there is
nothing like control iterface. You can issue any command on any
interface. When the command is a "local" one, it gets applied to that
interface only, when it is a "global" one, it gets applied to all
interfaces. In fact, every interface is a control interface. Migration
of master device is not visible to userspace.
> Tracking down what interface is still mapped to
> what phy in a multicard situation seems like it would make a much bigger
> hassle.
I think some userspace helper (small program that just nicely presents
information from sysfs) that outputs which device is related to which
device will solve this.
> So long as the driver can do client-mode bridging with fake associations
> for all the clients.
Or the stack perhaps?
> As far as link type, theres no real reason radiotap couldn't be used
> internally, but theres also no reason it's needed on anything other than
> rfmon if we don't think we'll ever care about per-frame stats in
> non-rfmon. I don't think anyone has written any tools to use them,
> since it hasn't been an option. I don't know that theres a lot of
> demand. Rfmon *definitely* needs standard per-frame headers of radio
> data, and I've campaigned for RT previously so i won't bore people with
> it again now. :)
I think radiotap headers should be included when the interface is in
monitor mode.
Thanks a lot for your comments,
--
Jiri Benc
SUSE Labs
-
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: State of the Union: Wireless
On Wed, Jan 11, 2006 at 03:49:37PM +0100, Jiri Benc wrote:
> Here is my proposal:
>
> - There should be only as few net_devices as needed. I. e. when the card
> acts as a client to one AP, only one device is present.
See below...
> - The type of a device (AP, client, WDS link, monitor, etc.) should be
> specified in the usual way (by iwconfig mode or whatever will eventually
> replace it).
Agreed, though there is a benefit to being able to specify the type of
the initial card. Many drivers offer it as a modprobe option, ie, to
initialize the card in rfmon to prevent it from sending any probe req's
before configuration. A bit of a fringe IDS aspect, but I don't know if
we ought to cut them out. Does anyone actually USE this functionality?
I don't, myself, but I know it exists.
> - When you need a new device (e. g. because you want to connect to another
> AP at the same time, or you want to add a new WDS link), you just invoke
> some command and a new device will appear. Then you can configure the new
> device in the usual way (iwconfig mode, etc.)
Sounds good.
> - Devices can be deleted. You can delete any device (including the first one
> that appeared after modprobe/inserting the card (*)). Of course, you
> cannot delete the last device (i. e. at least one device will be always
> present).
I don't know if I concur -- having the "control" interface move around
is confusing. I'd rather have one unique ID for that wireless phy
(however this is presented) and then create dynamic devices from it via
whatever command. Atheros ties this to a master wifiX device that is
uses to spawn dynamic devices. It just seems that, logically, it makes
more sense to have something like:
wlanadddev phy0 dyn0
wlanadddev phy0 dyn1
wlanadddev phy1 dyn2
wlandeldev dyn1
wlandeldev dyn2
wlanmakedev phy1 dyn1
rather than have the 'source' phy change over time.
> - "Global" configuration requests (setting channel etc.) can be performed on
> any device and will affect all devices.
Yup.
> - "Local" configuration requests (setting mode, ESSID, etc.) will affect
> only the device they are called on.
Yup.
> - You can add as many devices as you want and configure them in any way. But
> only devices that are "compatible" (i. e. the hardware permits them to
> operate together) can be brought up.
Sounds good, provided the error is reasonable. Reasonable presentation
of the error is, admittedly, more userspace than kernel space, but since
we're talking about designing new uspace tools...
>
> *snip*
>
> (*) At first, I was thinking that the first device ("master device")
> shouldn't allow to be deleted. But it doesn't solve anything (don't want to
> make this mail longer; ask me if you want to know why) and just confuses
> users.
I'd like to know why. :) See above for my counter-argument about
confusing users. I'd be willing to agree that the control phy "master
device" doesn't need to be a netdev, but I think it ought to be a
constant, unique value. Tracking down what interface is still mapped to
what phy in a multicard situation seems like it would make a much bigger
hassle.
> *snip*
> There are two problems regarding native 802.11 devices:
>
> 1. Bridging between Ethernet and 802.11 device. Ethernet<->802.11 conversion
> can be implemented in the bridging code. There should be no problem with it.
So long as the driver can do client-mode bridging with fake associations
for all the clients. Or the interface is in AP mode.
> ... *snip*
As far as link type, theres no real reason radiotap couldn't be used
internally, but theres also no reason it's needed on anything other than
rfmon if we don't think we'll ever care about per-frame stats in
non-rfmon. I don't think anyone has written any tools to use them,
since it hasn't been an option. I don't know that theres a lot of
demand. Rfmon *definitely* needs standard per-frame headers of radio
data, and I've campaigned for RT previously so i won't bore people with
it again now. :)
-m
--
Mike Kershaw/Dragorn <[EMAIL PROTECTED]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
America is a large, friendly dog in a very small room. Every time it
wags its tail, it knocks over a chair.
-- Arnold Joseph Toynbee
pgpPfHqX9Kh4w.pgp
Description: PGP signature
Re: State of the Union: Wireless
On Tue, 2006-01-10 at 11:09 -0500, Mike Kershaw wrote: > I don't think that I really agree with that. I don't, as a user or as a > programmer, want to unconfigure all my existing stuff just to drop into > rfmon for a few minutes. I'd definitely prefer that they stop working, > than have to remember what all my virtual interfaces were and recreate > them. Well, we can allow you to create the rfmon device when the others are 'down', and not allow you to bring them up again until you take the rfmon device down. Or something like that anyway. johannes signature.asc Description: This is a digitally signed message part
Re: State of the Union: Wireless
On Sat, 2006-01-07 at 20:17 +0100, Stefan Rompf wrote: > Caveats: > -rfmon can affect all virtual devices as Mike pointed out See my reply to him. > -As a matter of fact, virtual devices are not independant eveb without rfmon, > simply because one physical device can only tune to one channel at a time Same here. Cards that can't do this properly disallow some settings. Or e.g. if you have an AP virtual device then you can't change the channel on the virtual STA device etc. > -Which link type should be used by the virtual device? Is it easier to change > all protocols to support 802.11 frames or is ethernet emulation mode > simplest? > -If we use 802.11 natively, should we always tack on radiotap headers? imho it should use 802.11 natively but not tack on radiotap headers (overhead?) unless for a rfmon virtual device. > Questions: > -what happens to iwpriv? It goes away. > -where are the netlink messages/wireless extensions handled? Should the > device > driver forward into the stack, or should the stack call into the device > driver? I think the "stack" provides demultiplexing and validation of the data received from userspace and then calls into a driver method to handle the changed configuration, which makes the driver again call some 'stack library' methods to make that configuration. IOW the driver validates the configuration and rejects it if necessary, and the 'stack library' applies it. > c)which stack to use? Actually, it's intel vs. devicescape. I'm about to port > the driver of a popular card to devicescape to get a personal opinion. I think neither of the two support what we want. dscape is closer, and we may be able to work from there. > I think we should start discussing a), beginning with b) when we have > answered > most questions concerning a). right. johannes signature.asc Description: This is a digitally signed message part
Re: State of the Union: Wireless
> > 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. > > I think the solution lies with the driver: It just doesn't allow > creating an rfmon virtual interface if that was going to break the other > interfaces, so to get one you have to remove the others (and obviously > that tells you that you can't do that during operation) I don't think that I really agree with that. I don't, as a user or as a programmer, want to unconfigure all my existing stuff just to drop into rfmon for a few minutes. I'd definitely prefer that they stop working, than have to remember what all my virtual interfaces were and recreate them. I know this sort of contradicts my original point, but I think we should find the least-disruptive most-obvious method for making the rfmon device. I want my cake, and to eat it too. :P -m -- Mike Kershaw/Dragorn <[EMAIL PROTECTED]> GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 "Dear Die-ary, Today I stuffed some dolls with dead rats I put in a blender. I'm beginning to wonder if, maybe, I really am screwed up." -- Johnny C. (JtHM) pgpDambRbV4Ij.pgp Description: PGP signature
Re: State of the Union: Wireless
On Fri, 2006-01-06 at 18:08 -0500, Mike Kershaw wrote: > Two things to inject, from my own little corner of userspace: Thanks. > 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. I think the solution lies with the driver: It just doesn't allow creating an rfmon virtual interface if that was going to break the other interfaces, so to get one you have to remove the others (and obviously that tells you that you can't do that during operation) johannes signature.asc Description: This is a digitally signed message part
Re: State of the Union: Wireless
Denis Vlasenko wrote: > I am confused. Which isn't really all that surprising. > ftp://ftp.berlios.de/pub/bcm43xx/snapshots/softmac/ieee80211softmac-20060107.tar.bz2 > which is not the same. For example, ieee80211softmac.h file exists in both > tarballs but is not identical. > > Suppose one wants to use softmac in a project. What tarball contains > the bleeding edge of softmac? The one from the softmac page is created from the git repository. The one on the bcm page is created from the now historical mercurial archive. I need to get the bcm people to take away that snapshot and link to the correct one. 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: [Acx100-devel] Re: State of the Union: Wireless
Hi, On Tue, Jan 10, 2006 at 08:39:25AM +0200, Denis Vlasenko wrote: > On Friday 06 January 2006 06:22, Jeff Garzik wrote: > > > > State of the Union - Wireless > > January 5, 2006 > > [ snip ] > > > * Wireless drivers and the wireless stack need to be maintained IN-TREE > > as a COLLECTIVE ENTITY, not piecemeal maintenance as its done now. > > > > The whole point of working in-tree, the whole point of this open source > > thing is that everybody works on the same code, and the entire Internet > > is your test bed. Quality improves the more people work together. > > The entire Linux kernel engineering process is focused on getting core > > kernel code out to distributions (then to end users) and power users. > > Out-of-tree code breaks that model, breaking the It Just Works(tm) > > theme applicable to other Linux-supported hardware. > > Cool, so may I please know why acx driver is not included in the mainline? > In case it needs more work, well, (a) at least tell us what exactly > you want improved, and (b) why do you think that in-tree acx would not > be improved? It will get more visibility, maybe some people will > get interested and will send a patch or two to us... I think wording is a tad bit too aggressive here, since we (well, at least me) haven't made many efforts to get it included, since we had to work out some things. However at this point we should really go for inclusion, the sooner the better (right?). > > * Release early, release often. Pushing from an external repository to > > the official kernel tree every few months creates more problems > > than it solves. Out-of-tree drivers fail to take advantage of > > recent kernel changes and coding practices, which leads to bugs and > > incompatibilities. Slow pushing leads to huge periodic updates, > > which are awful for debugging, testing, and general use. > > I want to avoid exactly this, and therefore want acx in mainline. ACK. > How are we going to find out which stack is best and which stack > we should concentrate our efforts on? In an absense of wifi maintainer, > maybe we should throw _all stacks_ (currently two) into the mainline, > and evolution will find the best one. Yes, it would be a bit ugly > at first, but I hope it will speed up evolution a lot. I have to admit that a big item on our acx ToDo list was the missing ieee80211 integration, but now that there's a second stack on the horizon and things look less decided I'm not that much troubled by our lack of ieee80211 use any more ;) That said, of course we should try to get rid of our own, historic (originating from binary TI driver!) in-driver stack very soon. I won't do any comments on which stack to use, though, I will do research first and then work out which one to use depending on popularity and features matching our chips' properties. Andreas Mohr - 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: State of the Union: Wireless
On Tuesday 10 January 2006 00:39, Denis Vlasenko wrote: > How are we going to find out which stack is best and which stack > we should concentrate our efforts on? In an absense of wifi maintainer, > maybe we should throw _all stacks_ (currently two) into the mainline, > and evolution will find the best one. Yes, it would be a bit ugly > at first, but I hope it will speed up evolution a lot. > > Let current stack sit in include/net/ieee80211*.h and net/ieee80211/*, > add dcape one into include/net/wlan*.h and net/wlan/* > (s/wlan/dscape/ or whatever) > > We can even give Devicescape folks blanket permissions to > maintain their stack in include/net/wlan*.h and net/wlan/*. > Maybe they can act as a wifi maintainer long term. > > Existing drivers won't need to closely track every change > in dscape stack. If dscape will survive, old drivers can be > converted to it gradually. If not, just dike it out. I don't like the idea of maintaining two of anything. What if I have two wireless interfaces, each using a different stack? Performance--, Kernel size++ I get that it's hard to get everyone to agree on one stack or another, but we need to make the decision now because the longer we don't have a decision made (this includes maintaining two in-tree stacks) the longer it's going to take us to have serious / robust / reliable / consistent wireless support. I know basically nothing about 802.11, but it seems to me that what should happen is that if there is sufficient motivation to boot ieee80211 in favor of DeviceScape, someone should cook up the patches. Besides, assume we did bless two stacks. Every new driver / driver that wanted to go mainline would choose one or another (it's already clear that people disagree). Thus we end up with *more* work to do in order to decide one way or another (since we have to partially break & fully port all the drivers from one stack to another). There's incompatibility all over this wireless landscape. The best way to deal with it is to make all the big hard decisions now - say "this is the way it's going to be" and work from there. We can always undo mistakes later, but we'll never get to that point if we don't start moving in one direction instead of ten. > -- > vda > - Cheers, Chase - 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: State of the Union: Wireless
On Friday 06 January 2006 06:22, Jeff Garzik wrote: > > State of the Union - Wireless > January 5, 2006 [ snip ] > * Wireless drivers and the wireless stack need to be maintained IN-TREE > as a COLLECTIVE ENTITY, not piecemeal maintenance as its done now. > > The whole point of working in-tree, the whole point of this open source > thing is that everybody works on the same code, and the entire Internet > is your test bed. Quality improves the more people work together. > The entire Linux kernel engineering process is focused on getting core > kernel code out to distributions (then to end users) and power users. > Out-of-tree code breaks that model, breaking the It Just Works(tm) > theme applicable to other Linux-supported hardware. Cool, so may I please know why acx driver is not included in the mainline? In case it needs more work, well, (a) at least tell us what exactly you want improved, and (b) why do you think that in-tree acx would not be improved? It will get more visibility, maybe some people will get interested and will send a patch or two to us... > * Release early, release often. Pushing from an external repository to > the official kernel tree every few months creates more problems > than it solves. Out-of-tree drivers fail to take advantage of > recent kernel changes and coding practices, which leads to bugs and > incompatibilities. Slow pushing leads to huge periodic updates, > which are awful for debugging, testing, and general use. I want to avoid exactly this, and therefore want acx in mainline. > * ALL wireless stacks need work. It is currently fashionable to laud > DeviceScape and trash in-kernel ieee80211, but outside of the > cheerleading, BOTH have real technical issues that need addressing. > IOW, no matter what code is chosen, _somebody_ is on the hook for > a fair amount of work. A switch is not without its costs. > > * I would prefer that people patch the in-tree ieee80211 code, > probably in the direction of Jiri Benc's proposed ieee80211_device > direction. I take patches from all parties, not just Intel. > > * However, if the engineering reasons for switching to DeviceScape > or another wireless stack are powerful enough to overcome Linux's > "no big patches, evolve it" maxim, great! But make sure to work > on converting drivers to this new stack. The wireless drivers and > wireless stack should evolve in tandem. Otherwise, drivers get > left behind, grow moldy, and Linux users suffer. How are we going to find out which stack is best and which stack we should concentrate our efforts on? In an absense of wifi maintainer, maybe we should throw _all stacks_ (currently two) into the mainline, and evolution will find the best one. Yes, it would be a bit ugly at first, but I hope it will speed up evolution a lot. Let current stack sit in include/net/ieee80211*.h and net/ieee80211/*, add dcape one into include/net/wlan*.h and net/wlan/* (s/wlan/dscape/ or whatever) We can even give Devicescape folks blanket permissions to maintain their stack in include/net/wlan*.h and net/wlan/*. Maybe they can act as a wifi maintainer long term. Existing drivers won't need to closely track every change in dscape stack. If dscape will survive, old drivers can be converted to it gradually. If not, just dike it out. > * Feel free to submit radical changes -- wireless is yet young -- > just make sure all drivers keep working from release to release. > > * 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. > > * Please CC wireless stack/driver discussions to netdev@vger.kernel.org > mailing list, rather than everybody hiding in their own little > corner. [snip] > So... there it is. We suck. There's hope. No Luke Skywalker in sight. > I hope we can avoid being slaves to fashion, by merging a rewrite, but > that way be the way to go. -- vda - 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: State of the Union: Wireless
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Rompf schrieb: | so, can we agree on this: | | a)we want to distinguish between physical devices and virtual devices. | Physical devices represent a network card, virtual devices a function based | on the card (access point, sta, ...). Some cards can handle multiple | functions parallel, we support it this way. | | Caveats: | -rfmon can affect all virtual devices as Mike pointed out | -As a matter of fact, virtual devices are not independant eveb without rfmon, | simply because one physical device can only tune to one channel at a time Current devices. What to do when Foo, Inc creates a device with 3 radios ~ that can be used in parallel? ~ > b)we want to replace the wireless extension ioctl()s with netlink so we have | the possibility to change multiple config items at once | | Questions: | -what happens to iwpriv? Drop it. As this discussion targets an in-kernel stack (though it has yet to be written), kernel rules for APIs should be applied. Keep backwards compatibility where necessary (meaning: never drop support for old 80211-messages-over-netlink protocols) but don't hesitate to extend the API, which would be as easy as incrementing an id field. | -where are the netlink messages/wireless extensions handled? Should the device | driver forward into the stack, or should the stack call into the device | driver? IMHO the stack should handle the messages. Each driver should provide a "80211_ops" table. Also, the stack must be able to do all those operations in when not provided by the drivers. | c)which stack to use? Actually, it's intel vs. devicescape. I'm about to port | the driver of a popular card to devicescape to get a personal opinion. Though i'm probably biased, i'd still vote to use the current intel 'stack' together with the emerging softmac module. In my eyes it has a big upside when compared to devicescape: It's already in the kernel... Why not use the current ieee80211 device(s) as masterdevices? This way, we keep compatibility with userspace (at least for some time) Danny - -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDwDetaVNL8NrtU6IRAlvBAJ9lUduuu4EFZ2gZzpp7BL6e3OaxWACeOgZk zJERmHa3LfFMOC99SlPoLME= =Ywr6 -END PGP SIGNATURE- - 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: State of the Union: Wireless
Hi, so, can we agree on this: a)we want to distinguish between physical devices and virtual devices. Physical devices represent a network card, virtual devices a function based on the card (access point, sta, ...). Some cards can handle multiple functions parallel, we support it this way. Caveats: -rfmon can affect all virtual devices as Mike pointed out -As a matter of fact, virtual devices are not independant eveb without rfmon, simply because one physical device can only tune to one channel at a time Question: -Which link type should be used by the virtual device? Is it easier to change all protocols to support 802.11 frames or is ethernet emulation mode simplest? -If we use 802.11 natively, should we always tack on radiotap headers? b)we want to replace the wireless extension ioctl()s with netlink so we have the possibility to change multiple config items at once Questions: -what happens to iwpriv? -where are the netlink messages/wireless extensions handled? Should the device driver forward into the stack, or should the stack call into the device driver? c)which stack to use? Actually, it's intel vs. devicescape. I'm about to port the driver of a popular card to devicescape to get a personal opinion. I think we should start discussing a), beginning with b) when we have answered most questions concerning a). Thoughts? Stefan - 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: State of the Union: Wireless
On Friday 06 January 2006 13:31, Johannes Berg wrote: > On Fri, 2006-01-06 at 12:00 +0100, Michael Buesch wrote: > > > * "master" interface as real device node > > * Virtual interfaces (net_devices) > > I didn't want to spam the netdev wiki with this (yet) so I collected > some more structured things outside. Anyone feel free to edit: > http://softmac.sipsolutions.net/802.11 I am confused. There is http://softmac.sipsolutions.net/softmac-snapshot.tar.bz2 at http://softmac.sipsolutions.net/SoftMAC, page also says "Projects using this layer: * Broadcom 43xx driver" but Broadcom driver page at ftp://ftp.berlios.de/pub/bcm43xx/snapshots/softmac/ has ftp://ftp.berlios.de/pub/bcm43xx/snapshots/softmac/ieee80211softmac-20060107.tar.bz2 which is not the same. For example, ieee80211softmac.h file exists in both tarballs but is not identical. Suppose one wants to use softmac in a project. What tarball contains the bleeding edge of softmac? > I'll move that content to the netdev wiki if anyone else thinks it would > be a good way forward to start with requirements, API issues and > similar. > > Until we get there, we'll fix up softmac to make it usable for most > people in basic station mode without any kind of virtual devices, which > will need some slight changes to the current ieee80211. -- vda - 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: State of the Union: Wireless
[ Sorry, this went to linux-kernel, meant to send it to netdev. Apologies to those who see it twice. ] > 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, in 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 "Yes, yes, LORD OF HUMANS! I will rule you ALL with an iron fist! YOU! OBEY THE FIST!" -- Invader Zim pgpJF2IWX0ckO.pgp Description: PGP signature
Re: State of the Union: Wireless
On Fri, 2006-01-06 at 13:48 +0100, Stefan Rompf wrote: > With hardware like prism2 usb that gets "don't touch me now mode" for a while > after a join command is issued, current API requires a driver to delay > starting an association in order to wait if other config requests are issued > - an ugly hack. So that settles the 'need to change multiple settings at once' issue, saying that yes, it is indeed required. johannes signature.asc Description: This is a digitally signed message part
Re: State of the Union: Wireless
Am Freitag 06 Januar 2006 12:46 schrieb Dominik Brodowski: > From someone who has no idea at all (yet) about 802.11: why character > device, and not sysfs or configfs files? Like sysfs shares the main problem with wireless extensions: It configures one value per file / per ioctl. Setting up a wireless card to associate or form an IBSS network consists of multiple parameters, many requiring the card to disasscociate. With hardware like prism2 usb that gets "don't touch me now mode" for a while after a join command is issued, current API requires a driver to delay starting an association in order to wait if other config requests are issued - an ugly hack. I vote for netlink. It's a defined and tested interface and has all features needed to set multiple values in one transaction. Stefan - 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: State of the Union: Wireless
> From someone who has no idea at all (yet) about 802.11: why character > device, and not sysfs or configfs files? Like As Michael already said -- there's no real reason for that. We were just brainstorming. The /dev idea seemed like a good plan at first, but then it isn't fixed. What you suggested below does look useful too. Coming back to the point Michael already raised: the overarching idea is to get rid of the net_dev for the 'master' device, even if the underlying hardware supports only a single virtual device (which might then be created by the driver automatically) I'll move the wiki pages a bit to accomodate different models, please check in a few minutes. johannes signature.asc Description: This is a digitally signed message part
Re: State of the Union: Wireless
On Fri, Jan 06, 2006 at 12:31:24PM +0100, Johannes Berg wrote: > On Fri, 2006-01-06 at 12:00 +0100, Michael Buesch wrote: > > > * "master" interface as real device node > > * Virtual interfaces (net_devices) > > I didn't want to spam the netdev wiki with this (yet) so I collected > some more structured things outside. Anyone feel free to edit: > http://softmac.sipsolutions.net/802.11 >From someone who has no idea at all (yet) about 802.11: why character device, and not sysfs or configfs files? Like TASK: get list of MAC addresses available to hardware device (usually only one for current hw) cat /sys/devices/path/to/device/wireless/address TASK: get list of virtual devices including (some of) their properties ls -l /sys/devices/path/to/device/wireless/ ... wlan0 -> /sys/class/net/wlan0 wlan1 -> /sys/class/net/wlan1 TASK: create virtual device (with arbitrary type, netdev name and mac address) ^^ isn't nameif / udev for that? echo "$type" > /sys/devices/path/to/device/wireless/new_if ... we get uevents for this new interface; in this we can set the mac adress doing: echo "$mac" > /sys/class/net/wlan0/wireless/address TASK: configure virtual device (key is the device name since that needs to be unique anyway) echo "$some_config_option_for_virtual_device" > /sys/class/net/wlan0/wireless/some_option echo "$some_config_option_for_physical_device"> /sys/devices/path/to/dev/wireless/some_other_option Of course the configuration userspace tool would use libsysfs for that, not "echo" scripts... but they'd work too. Dominik - 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: State of the Union: Wireless
On Fri, 2006-01-06 at 12:00 +0100, Michael Buesch wrote: > * "master" interface as real device node > * Virtual interfaces (net_devices) I didn't want to spam the netdev wiki with this (yet) so I collected some more structured things outside. Anyone feel free to edit: http://softmac.sipsolutions.net/802.11 I'll move that content to the netdev wiki if anyone else thinks it would be a good way forward to start with requirements, API issues and similar. Until we get there, we'll fix up softmac to make it usable for most people in basic station mode without any kind of virtual devices, which will need some slight changes to the current ieee80211. johannes signature.asc Description: This is a digitally signed message part
