Am Sonntag 15 Januar 2006 21:11 schrieb Johannes Berg:
> [iwconfig mode ...]
>
> Yeah, I agree with this, it is much cleaner to handle in the kernel.
> Think about the issues if you have a struct net_device that has 250
> bytes of "payload" for the struct virtual_sta_device in it and you want
> to
On Jan 17, 2006, at 13:41, Stuffed Crust wrote:
On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote:
If I have told my equipment to obey UK law I expect it to do so.
If I hop on the train to France and forget to revise my
configuration I'd prefer it also believed the APs
It's not that
On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote:
> If I have told my equipment to obey UK law I expect it to do so. If I
> hop on the train to France and forget to revise my configuration I'd
> prefer it also believed the APs
It's not that you might forget to revise your configuration, bu
On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote:
> I would expect equipment to honour the subset of configurations that
> meet BOTH the regulatory domain the system believes it exists within
> (which may change dynamically!) AND the AP advertisement.
>
> If I have told my equipment to ob
On Llu, 2006-01-16 at 14:06 -0500, John W. Linville wrote:
> If regulators come down on someone, it seems like common sense
> that they would be more lenient on mobile stations complying with a
> misconfigured AP than they would be with a mobile station ignoring a
> properly configured AP? I know
On Mon, Jan 16, 2006 at 10:16:06PM +0200, Samuel Ortiz wrote:
> Well, I'd rather trust a governement regulated network than my neighbour's
> AP ;-) In fact, some phones set their 802.11 regulatory domain based on
> the information they received from a somehow government regulated network,
> e.g. a
On Mon, Jan 16, 2006 at 12:14:08PM -0800, Sam Leffler wrote:
> Please read what I wrote again. Station mode power save work involves
> communicating with the ap and managing the hardware. The first
> interacts with bg scanning. We haven't even talked about how to handle
> sta mode power save.
On Mon, 16 Jan 2006, ext John W. Linville wrote:
> On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote:
> > On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> >
> > > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > > > Regarding 802.11d and regulatory domains, the stack sho
Stuffed Crust wrote:
On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote:
The way you implement bg scanning is to notify the ap you are going into
power save mode before you leave the channel (in sta mode). Hence bg
scanning and power save operation interact.
That is not "powersave o
On Mon, Jan 16, 2006 at 10:00:18AM -0800, Sam Leffler wrote:
> Perhaps you haven't hit some of the more recent standards that place
> more of a burden on the ap implementation? Also some vendor-specific
> protocol features suck up space for ap mode only and it is nice to be
> able to include th
On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> You may hear another beacon when the STA is awake, you may not. BSSID
> filtering has nothing to do with 802.11 power save, but rather is
> intented to reduce the host load (interrupts, processing overhead) and
> thus the host power consumption.
I k
On Mon, Jan 16, 2006 at 09:07:52PM +0200, Samuel Ortiz wrote:
> That is true, thin MACs usually don't filter beacons on the same channel.
> But in some cases (mainly power saving), you really want to avoid
> receiving useless beacons and having the host woken up for each of them.
> You may even wan
On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote:
> The way you implement bg scanning is to notify the ap you are going into
> power save mode before you leave the channel (in sta mode). Hence bg
> scanning and power save operation interact.
That is not "powersave operation" -- that
On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> Background scanning, yes -- but there are all sorts of different
> thresholds and types of 'scanning' to be done, depending on how
> disruptive you are willing to be, and how capable the hardware is. Most
> thin MACs don't filter out foreign BSSIDs
On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote:
> On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
>
> > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > > Regarding 802.11d and regulatory domains, the stack should also be able to
> > > stick to one regulatory domain if
On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > Regarding 802.11d and regulatory domains, the stack should also be able to
> > stick to one regulatory domain if asked so by userspace, whatever the APs
> > around tell us.
>
> ...and
On Mon, 2006-01-16 at 12:28 -0500, Stuffed Crust wrote:
> Scans should be specified as "non-distruptive" so the hardware driver
> has to twiddle whatever bits are necessary to return the hardware to the
> same state that it was in before the scan kicked in. Beyond that, the
> scanning smarts are a
Stuffed Crust wrote:
On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote:
I really don't see why a plain STA mode card should be required to carry
around all the code required for AP operation -- handling associations
of clients, powersave management wrt. buffering, ... Sure, fragment
Stuffed Crust wrote:
On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote:
The above is a great synopsis but there is more. For example to support
roaming (and sometimes for ap operation) you want to do background
scanning; this ties in to power save mode if operating as a station.
On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote:
> I really don't see why a plain STA mode card should be required to carry
> around all the code required for AP operation -- handling associations
> of clients, powersave management wrt. buffering, ... Sure, fragmentation
From the per
On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote:
> The above is a great synopsis but there is more. For example to support
> roaming (and sometimes for ap operation) you want to do background
> scanning; this ties in to power save mode if operating as a station.
Opportunistic roami
On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> Regarding 802.11d and regulatory domains, the stack should also be able to
> stick to one regulatory domain if asked so by userspace, whatever the APs
> around tell us.
...and in doing so, violate the local regulatory constraints. :)
On Mon, 2006-01-16 at 15:23 +0100, Jiri Benc wrote:
> You are right. But it breaks compatibility with iwconfig unless we
> emulate 'iwconfig mode' command by deleting and adding interface. This
> means some events are generated, hotplug/udev gets involved etc. In the
> worst case it can mean that
On Fri, 13 Jan 2006 23:32:02 +0100, Johannes Berg wrote:
> IMHO there's not much point in allowing changes. I have a feeling that
> might create icky issues you don't want to have to tackle when the
> solution is easy by just not allowing it. Part of my thinking is that
> different virtual types ha
On Sun, Jan 15, 2006 at 11:39:41AM -0800, Sam Leffler wrote:
> The big stumbling block I found to going with virtual devices is that it
> affects user apps. I looked at doing things like auto-create a station
> device for backwards compatibility but decided against it. If you
> really want thi
On Sun, 15 Jan 2006, ext Stuffed Crust wrote:
> * Knowing the hardware frequency capabilities, the 802.11 stack applies
>802.11d and regdomain rules to the available frequency set, and
Regarding 802.11d and regulatory domains, the stack should also be able to
stick to one regulatory domain if
On Sun, 2006-01-15 at 12:08 -0800, Sam Leffler wrote:
> To do what you describe I would create a monitor mode device, switch
> channel, then destroy it. All the time you leave the station device
> unchanged, though you probably need to disable it. This may not be
> possible with all devices--
Stefan Rompf wrote:
Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg:
Isn't that rather a question of having good user-space tools that make
deactivating one type of interface and activating another seamless?
Well, it's always easy to point to userspace. However, unregister_netdev()
ini
Stuffed Crust wrote:
On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
This can be accomplished by passing a static table to the
register_wiphy_device() call (or perhaps via a struct wiphy_dev
parameter) or through a more explicit, dynamic interface like:
wiphy_register_supported_
Stefan Rompf wrote:
Am Samstag 14 Januar 2006 14:47 schrieb Ulrich Kunitz:
They one problem I can see is scanning over several frequencies.
If two virtual devices are doing this at the same time, we have a
conflict. Maybe each WiPHY would have only one active interface,
I think scanning can b
Stefan Rompf wrote:
Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg:
[Changing mode of virtual devices]
IMHO there's not much point in allowing changes. I have a feeling that
might create icky issues you don't want to have to tackle when the
solution is easy by just not allowing it. Part
Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg:
> Isn't that rather a question of having good user-space tools that make
> deactivating one type of interface and activating another seamless?
Well, it's always easy to point to userspace. However, unregister_netdev()
initiates a lot of acti
On Sat, Jan 14, 2006 at 06:41:56PM -0500, Dan Williams wrote:
> One other thing: capability. It's not enough to be able to configure
> the device, user-space tools also have to know what the device is
> capable of before they try touching it. Ie, which ciphers, protocols,
> channels, etc. Simila
Stefan Rompf wrote:
> Even though it is a bit more work on kernel side, we should allow changing
> the
> mode of virtual devices. Let's face it, even though we find multi-BSS
> capabilities very interesting, 999 of 1000 users won't care due to the two
> facts that IPW firmware IMHO doesn't allow i
On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
> >This can be accomplished by passing a static table to the
> >register_wiphy_device() call (or perhaps via a struct wiphy_dev
> >parameter) or through a more explicit, dynamic interface like:
> >
> > wiphy_register_supported_frequenc
Am Samstag 14 Januar 2006 14:47 schrieb Ulrich Kunitz:
> They one problem I can see is scanning over several frequencies.
> If two virtual devices are doing this at the same time, we have a
> conflict. Maybe each WiPHY would have only one active interface,
I think scanning can be easily serialize
Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg:
> [Changing mode of virtual devices]
>
> IMHO there's not much point in allowing changes. I have a feeling that
> might create icky issues you don't want to have to tackle when the
> solution is easy by just not allowing it. Part of my thinkin
John W. Linville wrote:
> Configuration seems to be coalescing around netlink. Among other
> things, this technology provides for muliticast requests and
> asynchronous event notification.
On the other hand, the tree structure of sysfs can handle the
resource exclusivity and sharing naturaly.
A
On Fri, 2006-01-13 at 17:19 -0500, John W. Linville wrote:
> Configuration
> =
>
> Configuration seems to be coalescing around netlink. Among other
> things, this technology provides for muliticast requests and
> asynchronous event notification.
>
> The kernel should provide generic
Stuffed Crust wrote:
The hardware knows what frequencies it supports. Unfortunately this has
to be a somewhat dynamic thing, as this is often not queryable until the
device firmware is up and running.
This can be accomplished by passing a static table to the
register_wiphy_device() call (or
Johannes Berg <[EMAIL PROTECTED]> writes:
> Yeah, this is about what I thought of -- and it makes me wonder if the
> stack really should be aware of the channelization, or if the WiPHY
> driver might better just handle it itself.
The latter, possibly using library functions from the stack :-)
--
On Fri, 13 Jan 2006, John W. Linville wrote:
> Configuration
> =
>
> At init, physical devices should be represented by a "WiPHY" device,
> not directly by a net_device. The list of physical devices should
> be discoverable through netlink and/or sysfs. (A WiPHY device is an
> abstr
On Fri, 2006-01-13 at 20:17 -0500, Stuffed Crust wrote:
> If you're talking about the former.. things get quite complicated, but
> that could be handled by having two WiPHY devices registered.
The former; and yes, I thought about that too -- having a driver that
shows two physical WiPHY devices
On Fri, Jan 13, 2006 at 11:32:02PM +0100, Johannes Berg wrote:
> I'm not sure this is worth it. While putting this into the WiPHY device
> creates more logic there, putting knowledge like 'how many different
> channels can this WiPHY device support' etc. into some representation
> that can be used
"John W. Linville" <[EMAIL PROTECTED]> writes:
> Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
> raw?, other modes?) which defines its "on the air" behaviour. Should
> this mode be fixed when the wlan device is created?
I think so. If needed one can delete and create.
[since none our replies made it to the lists, here mine are again.
apologies to those who see it twice, just skip it, I only pasted my
previous replies]
> Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
> raw?, other modes?) which defines its "on the air" behaviour. Should
Configuration
=
Configuration seems to be coalescing around netlink. Among other
things, this technology provides for muliticast requests and
asynchronous event notification.
The kernel should provide generic handlers for netlink
configuraion messages, and there should be a per-devic
47 matches
Mail list logo
