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)
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
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
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
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
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
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
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
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
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,
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
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
@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
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
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, 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
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
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
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
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, 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.)
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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:
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
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
[ 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
47 matches
Mail list logo
