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, but
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
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 switch
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 have
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 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 roaming
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
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.
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,
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 asked so
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 is
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 want
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 know
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
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 should also be
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.
I
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 GSM
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: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 obey
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
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 thinking is
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 serialized.
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_frequency(hw,
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 it
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. Similar
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
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.
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
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:
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
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, 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 this
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, 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
abstraction
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
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
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
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.
Or
38 matches
Mail list logo
