On Mon, Sep 04, 2006 at 10:35:09AM +0200, Johannes Berg wrote:
wireless.c and driver WE support in its current form must die.
I doubt you'll have anyone argue this point; not even JT. I doubt he
cares how WE is ultimately implemented, only that things continue
to just work.
The problems
On Wed, Oct 04, 2006 at 01:57:38PM -0400, Dan Williams wrote:
* None
- Crypto: None
- 802.11 Auth: Open System
* Static WEP
- Keys: up to 4 group keys
- Crypto: WEP-40, WEP-104, WEP-152, WEP-256
- 802.11 Auth: Open System or Shared Key
- Key Mgmt/Auth: none
*
On Thu, Jan 12, 2006 at 08:43:06PM +0100, Jiri Benc wrote:
I didn't mean channels, just frequencies. To be conformal with standards
and regulations, we can allow specific frequencies only. Those
frequencies are unambiguously mapped to channels anyway (you have to
specify a band of course). So
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,
On Sat, Jan 14, 2006 at 05:09:23PM -0500, Jeff Garzik wrote:
A big open issue: should you fake ethernet, or represent 802.11
natively throughout the rest of the net stack?
The former causes various and sundry hacks, and the latter requires that
you touch a bunch of non-802.11 code to make
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
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
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, 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 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 Wed, Jan 18, 2006 at 09:32:49AM +, Simon Kelley wrote:
That may be rather over-optimistic: the Atmel hardware dosen't even
produce consistent results over different chip revs.
But each chip on its own is fairly consistent, which is all that
random users care about. More bars mean
On Wed, Jan 18, 2006 at 12:36:09AM +0100, Stefan Rompf wrote:
prism2 usb is even worse - the urb is build of some control structure, the
802.11 3 address header, a 802.3 header and the 802.11 data part. Some bits
in the control structure decide whether the 802.11 or the 802.3 header is
used
On Mon, Jan 23, 2006 at 03:32:32PM +0100, Johannes Berg wrote:
Shouldn't you BSS-filter management packets too?
Filtering on BSSID is necessary for management frames, especially when
multicast management frames are thrown into the mix.
For example, STAs are supposed to respect broadcast
On Mon, Oct 23, 2006 at 02:40:28PM +0200, Jiri Benc wrote:
int icv_len:8; /* Length of the ICV/MIC field in octets */
int iv_len:8; /* Length of the IV field in octets */
+ u8 rc4key[16]; /* generated RC4 key for hw TKIP */
I don't like extending ieee80211_tx_control by 16 more
18 matches
Mail list logo
