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 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 wireless stack need to be maintained IN
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 as its done now.
>
>
-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
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
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
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
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.
54 matches
Mail list logo
