[PATCH 0/2] d80211, rt2x00: fixes

[PATCH 0/2] d80211, rt2x00: fixes

[Jiri Benc]

John, in addition to the previous pull request, please also apply the
following two fixes.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs

[PATCH 1/2] rt2x00: fix breakage after pkt_type field was removed

[Jiri Benc]

Fix breakage after pkt_type field was removed from ieee80211_tx_control.

Signed-off-by: Jiri Benc <jbenc@suse.cz>

---
 drivers/net/wireless/d80211/rt2x00/rt2400pci.c |    2 +-
 drivers/net/wireless/d80211/rt2x00/rt2500pci.c |    2 +-
 drivers/net/wireless/d80211/rt2x00/rt2500usb.c |    2 +-
 drivers/net/wireless/d80211/rt2x00/rt2x00.h    |    3 +++
 drivers/net/wireless/d80211/rt2x00/rt61pci.c   |    2 +-
 drivers/net/wireless/d80211/rt2x00/rt73usb.c   |    2 +-
 6 files changed, 8 insertions(+), 5 deletions(-)

--- dscape.orig/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
+++ dscape/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
@@ -1428,7 +1428,7 @@ static void rt2400pci_write_tx_desc(stru
 	 * to be inserted into the frame.
 	 */
 	req_timestamp = !!(control->queue == IEEE80211_TX_QUEUE_BEACON ||
-		  	   control->pkt_type == PKT_PROBE_RESP);
+			   is_probe_resp(frame_control));
 
 	/*
 	 * Determine with what IFS priority this frame should be send.
--- dscape.orig/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
+++ dscape/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
@@ -1569,7 +1569,7 @@ static void rt2500pci_write_tx_desc(stru
 	 * to be inserted into the frame.
 	 */
 	req_timestamp = !!(control->queue == IEEE80211_TX_QUEUE_BEACON ||
-		  	   control->pkt_type == PKT_PROBE_RESP);
+			   is_probe_resp(frame_control));
 
 	/*
 	 * Determine with what IFS priority this frame should be send.
--- dscape.orig/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
+++ dscape/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
@@ -1540,7 +1540,7 @@ static void rt2500usb_write_tx_desc(stru
 	 * to be inserted into the frame.
 	 */
 	req_timestamp = !!(control->queue == IEEE80211_TX_QUEUE_BEACON ||
-		  	   control->pkt_type == PKT_PROBE_RESP);
+			   is_probe_resp(frame_control));
 
 	/*
 	 * Determine with what IFS priority this frame should be send.
--- dscape.orig/drivers/net/wireless/d80211/rt2x00/rt2x00.h
+++ dscape/drivers/net/wireless/d80211/rt2x00/rt2x00.h
@@ -130,6 +130,9 @@ static int rt2x00_debug_level = 0;
 #define is_rts_frame(__fc) \
 	( !!((((__fc) &  IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_CTL) && \
 	     (((__fc) &  IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_RTS)) )
+#define is_probe_resp(__fc) \
+	( !!((((__fc) & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_MGMT) && \
+	     (((__fc) & IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_PROBE_RESP)) )
 
 /*
  * TX result flags.
--- dscape.orig/drivers/net/wireless/d80211/rt2x00/rt61pci.c
+++ dscape/drivers/net/wireless/d80211/rt2x00/rt61pci.c
@@ -2024,7 +2024,7 @@ static void rt61pci_write_tx_desc(struct
 	 * to be inserted into the frame.
 	 */
 	req_timestamp = !!(control->queue == IEEE80211_TX_QUEUE_BEACON ||
-		  	   control->pkt_type == PKT_PROBE_RESP);
+			   is_probe_resp(frame_control));
 
 	/*
 	 * Determine with what IFS priority this frame should be send.
--- dscape.orig/drivers/net/wireless/d80211/rt2x00/rt73usb.c
+++ dscape/drivers/net/wireless/d80211/rt2x00/rt73usb.c
@@ -1803,7 +1803,7 @@ static void rt73usb_write_tx_desc(struct
 	 * to be inserted into the frame.
 	 */
 	req_timestamp = !!(control->queue == IEEE80211_TX_QUEUE_BEACON ||
-		  	   control->pkt_type == PKT_PROBE_RESP);
+			   is_probe_resp(frame_control));
 
 	/*
 	 * Determine with what IFS priority this frame should be send.

Re: [PATCH 1/2] rt2x00: fix breakage after pkt_type field was removed

[Ivo van Doorn]

On Wednesday 13 December 2006 18:00, Jiri Benc wrote:
> Fix breakage after pkt_type field was removed from ieee80211_tx_control.

Hmm, I must have missed that patch.
Your patch looks good to me.
Thanks

> Signed-off-by: Jiri Benc <jbenc@suse.cz>

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com

[PATCH 2/2] fix some wireless ext stuff

[Jiri Benc]

From: Johannes Berg <johannes@sipsolutions.net>

This fixes compilation with d80211/cfg80211/wireless ext.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Jiri Benc <jbenc@suse.cz>

--- linux-2.6-git.orig/net/core/net-sysfs.c	2006-12-06 12:31:04.247283692 +0100
+++ linux-2.6-git/net/core/net-sysfs.c	2006-12-06 12:31:11.865215130 +0100
@@ -329,7 +329,7 @@
 	.attrs  = netstat_attrs,
 };
 
-#ifdef WIRELESS_EXT
+#ifdef CONFIG_WIRELESS_EXT
 /* helper function that does all the locking etc for wireless stats */
 static ssize_t wireless_show(struct class_device *cd, char *buf,
 			     ssize_t (*format)(const struct iw_statistics *,
@@ -462,7 +462,7 @@
 	if (net->get_stats)
 		*groups++ = &netstat_group;
 
-#ifdef WIRELESS_EXT
+#ifdef CONFIG_WIRELESS_EXT
 	if (net->wireless_handlers && net->wireless_handlers->get_wireless_stats)
 		*groups++ = &wireless_group;
 #endif
--- linux-2.6-git.orig/net/d80211/Kconfig	2006-12-06 12:31:58.903791779 +0100
+++ linux-2.6-git/net/d80211/Kconfig	2006-12-06 12:32:07.355715711 +0100
@@ -3,6 +3,7 @@
 	select CRYPTO
 	select CRYPTO_ARC4
 	select CRYPTO_AES
+	select WIRELESS_EXT
 	---help---
 	This option enables the hardware independent IEEE 802.11
 	networking stack.
--- linux-2.6-git.orig/net/wireless/Makefile	2006-12-06 12:35:58.838632346 +0100
+++ linux-2.6-git/net/wireless/Makefile	2006-12-06 12:36:03.541590019 +0100
@@ -12,5 +12,5 @@
 
 # this needs to be compiled in...
 obj-$(CONFIG_CFG80211_WEXT_COMPAT) += wext-compat.o
-obj-$(CONFIG_CFG80211_WEXTNL_COMPAT)$(CONFIG_NET_WIRELESS) += wext-common.o
+obj-$(CONFIG_CFG80211_WEXT_COMPAT)$(CONFIG_NET_WIRELESS) += wext-common.o
 obj-y += $(obj-yy) $(obj-yn) $(obj-ny)

Re: [PATCH 0/2] d80211, rt2x00: fixes

[Lennart Sorensen]

On Wed, Dec 13, 2006 at 06:00:35PM +0100, Jiri Benc wrote:
> John, in addition to the previous pull request, please also apply the
> following two fixes.

What is the state of the rx2x00 driver by now?  I have been playing
around with an rt2500 based card, with some success but not enough for
me to switch over from wired ethernet yet on my machine.  I used to get
lots of hard lockups, but with the latest cvs snapshot in debian's
rt2x00-source package, it no longer seems to lockup.  It also now works
with WPA without using wpa_supplicant (Yay!  Good work.), it does
however very frequently pause the transfer, and then after a while (20
or 30 seconds probably) it will start moving data again and my transfer
will continue.  Is this considered normal for now?  My card happens to
be a linksys WMP54G version 4.0.  At least pauses beat crashes.  It's
going the right way for a work in progress.

I guess I should go read the bug tracking system and try out newer cvs
versions. :)

--
Len Sorensen

Re: [PATCH 0/2] d80211, rt2x00: fixes

[Dan Williams]

On Wed, 2006-12-13 at 12:12 -0500, Lennart Sorensen wrote:
> On Wed, Dec 13, 2006 at 06:00:35PM +0100, Jiri Benc wrote:
> > John, in addition to the previous pull request, please also apply the
> > following two fixes.
> 
> What is the state of the rx2x00 driver by now?  I have been playing
> around with an rt2500 based card, with some success but not enough for
> me to switch over from wired ethernet yet on my machine.  I used to get
> lots of hard lockups, but with the latest cvs snapshot in debian's
> rt2x00-source package, it no longer seems to lockup.  It also now works
> with WPA without using wpa_supplicant (Yay!  Good work.), it does

How, by private ioctls?  That's just wrong; I believe you still need to
go through the 4-way handshake to get the right keying information even
if you use PSK, which means you still need the supplicant, right?

dan

> however very frequently pause the transfer, and then after a while (20
> or 30 seconds probably) it will start moving data again and my transfer
> will continue.  Is this considered normal for now?  My card happens to
> be a linksys WMP54G version 4.0.  At least pauses beat crashes.  It's
> going the right way for a work in progress.
> 
> I guess I should go read the bug tracking system and try out newer cvs
> versions. :)
> 
> --
> Len Sorensen
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] d80211, rt2x00: fixes

[Ivo van Doorn]

On Wednesday 13 December 2006 18:38, Dan Williams wrote:
> On Wed, 2006-12-13 at 12:12 -0500, Lennart Sorensen wrote:
> > On Wed, Dec 13, 2006 at 06:00:35PM +0100, Jiri Benc wrote:
> > > John, in addition to the previous pull request, please also apply the
> > > following two fixes.
> > 
> > What is the state of the rx2x00 driver by now?  I have been playing
> > around with an rt2500 based card, with some success but not enough for
> > me to switch over from wired ethernet yet on my machine.  I used to get
> > lots of hard lockups, but with the latest cvs snapshot in debian's
> > rt2x00-source package, it no longer seems to lockup.  It also now works
> > with WPA without using wpa_supplicant (Yay!  Good work.), it does
> 
> How, by private ioctls?  That's just wrong; I believe you still need to
> go through the 4-way handshake to get the right keying information even
> if you use PSK, which means you still need the supplicant, right?

rt2x00 completely uses the dscape stack, so I am not sure how he is
managing this wpa without wpa_supplicant with rt2x00.
Lennart, are you using rt2x00 or the legacy rt2500 driver?

> > however very frequently pause the transfer, and then after a while (20
> > or 30 seconds probably) it will start moving data again and my transfer
> > will continue.  Is this considered normal for now?  My card happens to
> > be a linksys WMP54G version 4.0.  At least pauses beat crashes.  It's
> > going the right way for a work in progress.
> > 
> > I guess I should go read the bug tracking system and try out newer cvs
> > versions. :)

Ivo

Re: [PATCH 0/2] d80211, rt2x00: fixes

[Lennart Sorensen]

On Wed, Dec 13, 2006 at 06:56:57PM +0100, Ivo van Doorn wrote:
> rt2x00 completely uses the dscape stack, so I am not sure how he is
> managing this wpa without wpa_supplicant with rt2x00.
> Lennart, are you using rt2x00 or the legacy rt2500 driver?

rt2x00 with dscape stack.

--
Len Sorensen

Re: [PATCH 0/2] d80211, rt2x00: fixes

[Lennart Sorensen]

On Wed, Dec 13, 2006 at 12:38:43PM -0500, Dan Williams wrote:
> How, by private ioctls?  That's just wrong; I believe you still need to
> go through the 4-way handshake to get the right keying information even
> if you use PSK, which means you still need the supplicant, right?

All I did was add this to /etc/network/interfaces:

iface wlan0 inet static
        address 192.168.1.51
        network 192.168.1.0
        netmask 255.255.255.0
        gateway 192.168.1.254
        broadcast 192.168.1.255
        pre-up ifconfig wlan0 up
        pre-up iwpriv wlan0 set AuthMode=WPAPSK
        pre-up iwpriv wlan0 set EncrypType=TKIP
        pre-up iwconfig wlan0 essid USR8054
        pre-up iwpriv wlan0 set WPAPSK="My WPA passphrase..."

It seems to work, although I guess I could be wrong.  It was what I
found in the documentation for the rt2x00 driver for doing WPA.  It
looks nothing like the wpa_supplicant stuff I used to have with an older
version of the driver.  My understanding was that the rt2x00 driver
and/or d80211 stack took care of it now.

--
Len Sorensen

Re: [PATCH 0/2] d80211, rt2x00: fixes

[Ivo Van Doorn]

Hi,

> > How, by private ioctls?  That's just wrong; I believe you still need to
> > go through the 4-way handshake to get the right keying information even
> > if you use PSK, which means you still need the supplicant, right?
>
> All I did was add this to /etc/network/interfaces:
>
> iface wlan0 inet static
>         address 192.168.1.51
>         network 192.168.1.0
>         netmask 255.255.255.0
>         gateway 192.168.1.254
>         broadcast 192.168.1.255
>         pre-up ifconfig wlan0 up
>         pre-up iwpriv wlan0 set AuthMode=WPAPSK
>         pre-up iwpriv wlan0 set EncrypType=TKIP
>         pre-up iwconfig wlan0 essid USR8054
>         pre-up iwpriv wlan0 set WPAPSK="My WPA passphrase..."

That is definately the rt2500 legacy driver and _not_ the rt2x00 driver.

> It seems to work, although I guess I could be wrong.  It was what I
> found in the documentation for the rt2x00 driver for doing WPA.  It
> looks nothing like the wpa_supplicant stuff I used to have with an older
> version of the driver.  My understanding was that the rt2x00 driver
> and/or d80211 stack took care of it now.

Correct, that is why those iwpriv commands are the clear evidence
you are not using rt2x00 but rt2500 legacy. Check which driver is loaded
rt2500 means legacy
rt2500pci means rt2x00.

Ivo

Re: [PATCH 0/2] d80211, rt2x00: fixes

[Lennart Sorensen]

On Wed, Dec 13, 2006 at 10:28:15PM +0100, Ivo Van Doorn wrote:
> That is definately the rt2500 legacy driver and _not_ the rt2x00 driver.

Yeah I just noticed that a few minutes ago.  I had been trying out both
to see how they worked, and I left the old module loaded by accident.

> Correct, that is why those iwpriv commands are the clear evidence
> you are not using rt2x00 but rt2500 legacy. Check which driver is loaded
> rt2500 means legacy
> rt2500pci means rt2x00.

Yep I am now poking with the wpa_supplicant again, getting other
interesting messages from it.

I will try to give a report on how my system behaves with the 2x00
driver soon since apparently some of my testing was with the wrong
driver.  Oops. :)

--
Len Sorensen

Re: [PATCH 0/2] d80211, rt2x00: fixes

[Ivo van Doorn]

On Wednesday 13 December 2006 18:12, Lennart Sorensen wrote:
> On Wed, Dec 13, 2006 at 06:00:35PM +0100, Jiri Benc wrote:
> > John, in addition to the previous pull request, please also apply the
> > following two fixes.
> 
> What is the state of the rx2x00 driver by now?  I have been playing
> around with an rt2500 based card, with some success but not enough for
> me to switch over from wired ethernet yet on my machine.  I used to get
> lots of hard lockups, but with the latest cvs snapshot in debian's
> rt2x00-source package, it no longer seems to lockup.  It also now works
> with WPA without using wpa_supplicant (Yay!  Good work.), it does
> however very frequently pause the transfer, and then after a while (20
> or 30 seconds probably) it will start moving data again and my transfer
> will continue.  Is this considered normal for now?  My card happens to
> be a linksys WMP54G version 4.0.  At least pauses beat crashes.  It's
> going the right way for a work in progress.
> 
> I guess I should go read the bug tracking system and try out newer cvs
> versions. :)

Well results seem to vary between users. Since recently users have started
reporting panics and freezes with rt2x00. I have not yet traced that problem
to the source, because the panics I have received don't contain any rt2x00
or d80211 functions. But the presence of the rt2x00 module is the
important factor in reproducing the crash. :(
Others however seem to have more success with rt2x00, master mode
seems to work with reasonable speed. Association with managed mode
is still very shortlifed. People who manage to get associated are being
kicked from the AP quite quickly. (This could be because d80211 is not
sending NULL-frames every once in a while).

But since results vary much between users, I can still descrive the rt2x00
state as "experimental driver"

Ivo

Re: [PATCH 0/2] d80211, rt2x00: fixes

[Lennart Sorensen]

On Wed, Dec 13, 2006 at 06:49:07PM +0100, Ivo van Doorn wrote:
> Well results seem to vary between users. Since recently users have started
> reporting panics and freezes with rt2x00. I have not yet traced that problem
> to the source, because the panics I have received don't contain any rt2x00
> or d80211 functions. But the presence of the rt2x00 module is the
> important factor in reproducing the crash. :(
> Others however seem to have more success with rt2x00, master mode
> seems to work with reasonable speed. Association with managed mode
> is still very shortlifed. People who manage to get associated are being
> kicked from the AP quite quickly. (This could be because d80211 is not
> sending NULL-frames every once in a while).

I should do some more testing and submit a report of how it is behaving.
Anything specific worth checking if it misbehaves (so far misbehaving
seems to be pausing the network transmissions for a short period and
then resuming).

> But since results vary much between users, I can still descrive the rt2x00
> state as "experimental driver"

Well every once in a while I load a new version and see how it is.
Eventually I hope it will work perfectly, and I can move my mythtv box
into the living room with the TV using wireless, rather than sitting in
the basement next to the router machine using wired ethernet.  Running
ethernet cable through the wall when the basement is all finished just
seems like too much work.  I got an rt based card because I knew it was
being worked on.  I know someday it will simply work, which is good
enough for me.

--
Len Sorensen