-
From: Jiri Benc [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 10, 2007 6:20 PM
To: Jan Kiszka
Cc: netdev@vger.kernel.org; Ivo Van Doorn;
[EMAIL PROTECTED]; Jouni Malinen; Simon Barber
Subject: Re: d80211: How does TX flow control work?
On Mon, 08 Jan 2007 21:18:48 +0100, Jan Kiszka wrote
None of this should be in the kernel. See wpa_supplicant.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Zhu Yi
Sent: Wednesday, December 13, 2006 8:02 PM
To: netdev@vger.kernel.org
Subject: [PATCH 1/6] d80211: add IEEE802.11e/WMM MLMEs, Status
This policing of media time must be done in the qdisc - and made to work
per DA (Destination Address) - in order that AP mode will work as well
as STA mode. In addition the count of used time should be updated AFTER
the frame has been sent, not before, since the number of retries done
cannot be
This is all part of the client MLME - it would be much better to add
this functionality to wpa_supplicant, rather than adding it to the
kernel. Nothing here needs to be in the kernel for any reason.
The client MLME functions that are in the kernel were put in there for
test and debugging
Again - this DLS management frame processing code should not be in the
kernel - it should be in wpa_supplicant.
Only the frame processing code should be in the kernel.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Zhu Yi
Sent: Wednesday,
Devicescape does understant that the hardware can do retries - but it
adds software retries on top. This allows higher reliability, as well as
correct handling of the powersave state machine. (PS bit from a STA is
supposed to stop APs transmission immediately).
Simon
-Original Message-
W. Linville; Simon Barber; Michael Buesch;
Ivo van Doorn; Michael Wu; Jouni Malinen; Daniel Drake; Hong Liu; Luis
R. Rodriguez; James Ketrenos; David Kimdon; Udayan Singh
Subject: Re: wireless notes / pre d80211 merge
On Tue, 14 Nov 2006 23:19:57 +0100, Johannes Berg wrote:
1. master netdev
[mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 2:57 PM
To: Stephen Hemminger
Cc: Simon Barber; Christoph Hellwig; James Ketrenos; John W. Linville;
Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org
Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather
thand80211
PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Simon Barber
Sent: Friday, November 03, 2006 11:24 AM
To: Johannes Berg; Stephen Hemminger
Cc: Christoph Hellwig; James Ketrenos; John W. Linville; Jeff Garzik;
Patrick McHardy; David Kimdon; netdev@vger.kernel.org
Subject: RE: [patch] d80211: use
. Same could apply on receive.
Simon
-Original Message-
From: Johannes Berg [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 3:07 PM
To: Simon Barber
Cc: Stephen Hemminger; Christoph Hellwig; James Ketrenos; John W.
Linville; Jeff Garzik; Patrick McHardy; David Kimdon;
netdev
-Original Message-
From: Johannes Berg [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 6:23 AM
To: Christoph Hellwig
Cc: James Ketrenos; John W. Linville; Simon Barber; Jeff Garzik; Patrick
McHardy; David Kimdon; netdev@vger.kernel.org
Subject: Re: [patch] d80211: use pfifo_qdisc_ops
are essential.
Simon
-Original Message-
From: Christoph Hellwig [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 6:46 AM
To: Johannes Berg
Cc: Christoph Hellwig; Jiri Benc; James Ketrenos; John W. Linville;
Simon Barber; Jeff Garzik; Patrick McHardy; David Kimdon;
netdev
Perhaps the solution is to allow the prefix to be a kernel configuration
item?
Simon
-Original Message-
From: Jiri Benc [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 10:39 AM
To: Sven-Haegar Koch
Cc: Christoph Hellwig; James Ketrenos; John W. Linville; Simon Barber;
Jeff
for command line users to do what they need.
Simon
-Original Message-
From: Dan Williams [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 8:33 AM
To: Luis R. Rodriguez
Cc: Johannes Berg; Michael Wu; Simon Barber; David Kimdon;
netdev@vger.kernel.org; Jiri Benc; John W. Linville; Jean
One area that needs work is the 802.11 qdisc - there is no provision in
the current implementation for queueing certain frames because the
802.11 link is not ready to traqnsmit them yet, while letting other
frames through.
E.G. for normal client mode links it would be nice for the qdisc to
allow
Pfifo_fast does not make sense because the 802.11 qdisc already
categorizes the frames based on DSCP. The better thing would be to
extract the pfifo qdisc so that it does not require NET_SCHED, but this
is more work.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
thing.
Simon
-Original Message-
From: Patrick McHardy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 6:50 PM
To: Simon Barber
Cc: David Kimdon; netdev@vger.kernel.org; John W. Linville; Jiri Benc
Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than
d80211-specific
It's not possible to 'negotiate keys at the beginning' - since there is
no indication of a new station joining an IBSS. The first you ever know
about a station joining an IBSS is when you receive a frame from that
station.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
Doing this will slow down the qdisc - it does already run an external
classifier first if you install one. On typical laptops performance is
not a problem, but one common usage does have problems. The performance
of a wireless home gateway based on a simple linux kernel configuration
(NAT,
else (so same hard_start_xmit can be
used).
Simon
-Original Message-
From: Jeff Garzik [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 25, 2006 10:04 PM
To: Simon Barber
Cc: Patrick McHardy; David Kimdon; netdev@vger.kernel.org; John W.
Linville; Jiri Benc
Subject: Re: [patch] d80211
The Client MLME code in the kernel was only ever written to be used for
quick testing. It does not have good roaming performance, and was never
intended to be a complete client. The right place for the Client MLME is
in userspace, where it can be closely coupled with the supplicant, and
better
3:03 PM
To: Simon Barber
Cc: David Kimdon; netdev@vger.kernel.org; Jiri Benc; John W. Linville;
Jean Tourrilhes
Subject: Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/24/06, Simon Barber [EMAIL PROTECTED] wrote:
The Client MLME code in the kernel was only ever written
Removing the bitfields makes the code much harder to read and maintain.
Here we are working around a problem with the compiler by making the
code ugly - rather than fixing the compiler. The compilers are getting
better and better (GCC 4 has much better handling of this type of
optimization) but
with early G AP implementations - so the spec was
changed.
Simon
-Original Message-
From: Michael Wu [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 16, 2006 10:05 AM
To: mabbas
Cc: Simon Barber; netdev@vger.kernel.org
Subject: Re: [d80211] connecting to B-mode AP
On Friday 15
Message-
From: mabbas [mailto:[EMAIL PROTECTED]
Sent: Friday, September 15, 2006 10:19 AM
To: Simon Barber
Cc: netdev@vger.kernel.org
Subject: Re: [d80211] connecting to B-mode AP
Simon Barber wrote:
Why is it necessary to set phymode to B? - a G client can connect
perfectly well to a B AP
Hi Johannes,
Does the packet injection allow hostapd to use nl80211 instead of the
wlan0ap interface to send management frames? Important features for this
include requesting a transmit status - i.e. the ability for
hostapd/wpa_supplicant to know if the frame got acked or not.
Simon
Why is it necessary to set phymode to B? - a G client can connect
perfectly well to a B AP.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of mabbas
Sent: Thursday, September 14, 2006 4:25 PM
To: netdev@vger.kernel.org
Subject: [d80211] connecting
Why have both signal and rssi measures?
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Larry Finger
Sent: Wednesday, August 23, 2006 8:02 PM
To: Jiri Benc
Cc: John Linville; netdev@vger.kernel.org
Subject: [PATCH 1/4] Try 2: Add wireless
David - how long does the data flow need to be stopped when radar is
detected? If it's a short time it would be better to buffer the data
frames, if the connection can be disabled for a long time then dropping
them might be better.
There is one other application where data frames should be
One question - in most hardware implementations today the queues are DMA
rings. In this case the right length of the queue is determined by the
interrupt/tx_softirq latency required to keep the queue from becoming
empty. With 802.11 there are large differences in the time it takes to
transmit
sees frames before
they hit the DMA queue) and the hardware tx down. This allows the
software rate control to be more responsive.
Simon
-Original Message-
From: Michael Buesch [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 23, 2006 12:45 PM
To: Simon Barber
Cc: Jiri Benc; [EMAIL
: Michael Buesch [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 23, 2006 1:05 PM
To: Simon Barber
Cc: Jiri Benc; [EMAIL PROTECTED]; netdev@vger.kernel.org
Subject: Re: [PATCH] d80211: add ieee80211_stop_queues()
On Wednesday 23 August 2006 21:54, Simon Barber wrote:
I'd agree the memory benefit
of frames.
Simon
-Original Message-
From: Michael Buesch [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 23, 2006 1:20 PM
To: Simon Barber
Cc: Jiri Benc; [EMAIL PROTECTED]; netdev@vger.kernel.org
Subject: Re: [PATCH] d80211: add ieee80211_stop_queues()
On Wednesday 23 August 2006 22:10
1:57 PM
To: Simon Barber
Cc: Jiri Benc; [EMAIL PROTECTED]; netdev@vger.kernel.org
Subject: Re: [PATCH] d80211: add ieee80211_stop_queues()
On Wednesday 23 August 2006 22:32, Simon Barber wrote:
Right - and what I'm proposing is that we don't just count the number
of frames in the ring - but also
: Johannes Berg [mailto:[EMAIL PROTECTED]
Sent: Friday, August 18, 2006 7:51 AM
To: Jouni Malinen
Cc: netdev@vger.kernel.org; Simon Barber; Jiri Benc
Subject: Re: [clarification request] ieee80211_tx_control.pkt_type
On Fri, 2006-08-18 at 07:33 -0700, Jouni Malinen wrote:
Some hardware designs require
: Johannes Berg [mailto:[EMAIL PROTECTED]
Sent: Friday, August 18, 2006 12:02 AM
To: Simon Barber
Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes
Subject: RE: proposal for new wireless configuration API
On Thu, 2006-08-17 at 09:42 -0700, Simon Barber wrote:
The spec for RSSI is very loose
is not very useful.
Simon
-Original Message-
From: Johannes Berg [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 17, 2006 12:20 AM
To: Simon Barber
Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes
Subject: RE: proposal for new wireless configuration API
On Wed, 2006-08-16 at 11:02
I'd suggest that the new signal strength measure should be defined as
'RCPI' - the 'Received Channel Power Indicator' - which is defined in
IEEE 802.11k (the Radio Measurements amendment to 802.11). Here is the
full text of the definition from 802.11k draft 5.0:
received channel power indicator
A further complication happens in Japan with 802.11j, and now in the USA
too - with 802.11y in the 3.65Ghz band - here there are some new channel
widths that are possible. Normally 802.11 is 20 or 22Mhz wide (20Mhz for
OFDM modulations - 11a/g, 22 for 11b). In Japan's 4.9Ghz band you can
run the
The purpose of the wlap0ap or wlap0mgmt interface is to communicate
between hostapd/wpa_supplicant and the kernel. What travels over this
interface is not quite pure 802.11 management frames - there is some
meta-data with each frame, and a few special case messages. E.G.
transmitted frames are
There are many different functions in a complete 802.11 implementation -
and different implementations put these functions in different places.
In general, I would consider the primary difference between a full-mac
card and others to be the location of the MLME function. All full-mac
cards perform
). This
is forcing more and more vendors to do things the right way.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Simon Barber
Sent: Wednesday, August 09, 2006 2:33 PM
To: Dan Williams; Michael Wu
Cc: Johannes Berg; Mohamed Abbas; netdev@vger.kernel.org
The generic solution here is to use ebtables - the broute chain is there
to perform exactly this kind of filtering. Set a rule in the broute
chain to route these EAPOL frames, rather than bridging them. Then open
the packet socket on the original interface.
Simon
-Original Message-
-Original Message-
From: Jouni Malinen
Sent: Wednesday, March 15, 2006 4:48 PM
To: Simon Barber
Cc: Jiri Benc; netdev@vger.kernel.org
Subject: Re: [RFC/PATCH 6/13] d80211: remove obsolete stuff
On Wed, Mar 15, 2006 at 04:41:56PM -0800, Simon Barber wrote:
The more natural way for beacons to flow
The more natural way for beacons to flow from the 80211.o to the low
level driver would be for beacons to be passed down just like any other
802.11 frame is passed down - rather than having a special case for
beacons and buffered MC data, where they are pulled. I would suggest
making the qdisc
Overloading configuration parameters with extra meanings like this makes
it harder to configure the system - I think it's useful to keep an
on/off function separate from the power setting.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jouni
A quick suggestion for a feature improvement...
In 802.11 networks when connecting to a new AP on the same networks
(same SSID security settings) you typically don't have to do DHCP
again - but with some networks setups you do. In order to detect this,
when connecting to a new AP always issue an
Currently many wireless drivers handle SNAP-Ethernet header processing
- this is an obvious candidate for factoring out - and might possibly be
something that should be moved out of the wireless code completely.
Would it make sense to add the code to eth_trans_type or create a
protocol type. This prevents ebtables rules
and tc from working correctly.
Simon
-Original Message-
From: Stephen Hemminger [mailto:[EMAIL PROTECTED]
Sent: Friday, February 03, 2006 1:19 PM
To: Simon Barber
Cc: netdev@vger.kernel.org; Jouni Malinen
Subject: Re: SNAP headers, RFC1042
In order to get FCC certification the manufacturer must ensure there is
no easy way for the user to tune to illegal frequencies. Broadcom has
done their job - it was not easy to reverse engineer their driver. Now
the cat is out of the bag. The open source driver is not illegal -
although it may be
To do qos properly there needs to be a single net_device that a single
qdisc can be installed on - this alone is a good reason for a master
net_device. (there must be a single 802.11 qdisc for a single physical
piece of hardware). Here is another reason (for hardware devices that do
not include a
To fake ethernet or not?
There is a similar problem in the VLAN code - do you expect the rest of
the network stack to be able to interpret VLAN tagged frames? This was
the original state of the VLAN code - this caused problems since many
apps and modules did not
Hi Jeremy,
I implemented this functionality in Devicescape's 802.11 stack.
The approach I took was for the driver to install a device specific
qdisc as the root qdisc on the device. This root qdisc's purpose is to
expose the hardware queues directly, so other qdiscs can be attached as
leaf
would be to implement an 802.11
classifier, and install this by default on the 802.11 qdisc.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Simon Barber
Sent: Wednesday, December 14, 2005 3:07 PM
To: Jeremy Jackson; netdev@vger.kernel.org
Subject: RE
54 matches
Mail list logo
