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 1
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: non
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 yo
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 disa
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
> u
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 bet
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: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, 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, 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, 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 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
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
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
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
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).
20 matches
Mail list logo
