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
> > > (a
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
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.
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.
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
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 p
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 pra
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 repres
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 w
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, wi
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 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
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
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 tha
@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., b
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
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.
>
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
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, a
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)
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
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"
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
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
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
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 iwc
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 i
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 co
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
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 s
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 mo
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
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 ha
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 compa
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 an
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.
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 ty
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.) s
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 remem
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
> > 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
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 co
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 want
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
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
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
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 th
-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 car
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.
Cav
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 th
[ 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 a
> It can be in promiscious mode (wardriving).
Just to nitpick:
Promisc implies delivering all data frames from the medium. rfmon is
actually a different link type and delivers management frames (for which
there isn't a clear equivalent in 802.3).
Promisc does not imply disabling normal operatio
Michael Buesch <[EMAIL PROTECTED]> 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 sha
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 th
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 re
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 thi
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 o
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 fo
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 s
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 configurat
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 u
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 us
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 wi
> 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 suggest
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
>
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 et
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 stru
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 form
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.
> > * 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
> >
State of the Union - Wireless
January 5, 2006
Another banner year has passed, with Linux once again proving
its superiority in the area of crappy wireless (WiFi) support.
Linux oldsters love the current state of wireless, because it hearkens
back to the
71 matches
Mail list logo
