[PATCH] ath9k: Do not remove header padding on RX from short frames

[PATCH] ath9k: Do not remove header padding on RX from short frames

[Jouni Malinen]

The 802.11 header is only padded to 32-bit boundary when the frame has
a non-zero length payload. In other words, control frames (e.g., ACK)
do not have a padding and we should not try to remove it. This fixes
monitor mode for short control frames. In addition, the hdrlen&3 use
is described in more detail to make it easier to understand how the
padding length is calculated.

Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>

---
 drivers/net/wireless/ath9k/recv.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- wireless-testing.orig/drivers/net/wireless/ath9k/recv.c	2008-12-11 11:35:56.000000000 +0200
+++ wireless-testing/drivers/net/wireless/ath9k/recv.c	2008-12-11 12:18:02.000000000 +0200
@@ -571,8 +571,16 @@ int ath_rx_tasklet(struct ath_softc *sc,
 		hdr = (struct ieee80211_hdr *)skb->data;
 		hdrlen = ieee80211_get_hdrlen_from_skb(skb);
 
-		if (hdrlen & 3) {
-			padsize = hdrlen % 4;
+		/* The MAC header is padded to have 32-bit boundary if the
+		 * packet payload is non-zero. The general calculation for
+		 * padsize would take into account odd header lengths:
+		 * padsize = (4 - hdrlen % 4) % 4; However, since only
+		 * even-length headers are used, padding can only be 0 or 2
+		 * bytes and we can optimize this a bit. In addition, we must
+		 * not try to remove padding from short control frames that do
+		 * not have payload. */
+		padsize = hdrlen & 3;
+		if (padsize && hdrlen >= 24) {
 			memmove(skb->data + padsize, skb->data, hdrlen);
 			skb_pull(skb, padsize);
 		}

-- 
Jouni Malinen                                            PGP id EFC895FA

[ath9k-devel] [PATCH] ath9k: Do not remove header padding on RX from short frames

[Jouni Malinen]

The 802.11 header is only padded to 32-bit boundary when the frame has
a non-zero length payload. In other words, control frames (e.g., ACK)
do not have a padding and we should not try to remove it. This fixes
monitor mode for short control frames. In addition, the hdrlen&3 use
is described in more detail to make it easier to understand how the
padding length is calculated.

Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>

---
 drivers/net/wireless/ath9k/recv.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- wireless-testing.orig/drivers/net/wireless/ath9k/recv.c	2008-12-11 11:35:56.000000000 +0200
+++ wireless-testing/drivers/net/wireless/ath9k/recv.c	2008-12-11 12:18:02.000000000 +0200
@@ -571,8 +571,16 @@ int ath_rx_tasklet(struct ath_softc *sc,
 		hdr = (struct ieee80211_hdr *)skb->data;
 		hdrlen = ieee80211_get_hdrlen_from_skb(skb);
 
-		if (hdrlen & 3) {
-			padsize = hdrlen % 4;
+		/* The MAC header is padded to have 32-bit boundary if the
+		 * packet payload is non-zero. The general calculation for
+		 * padsize would take into account odd header lengths:
+		 * padsize = (4 - hdrlen % 4) % 4; However, since only
+		 * even-length headers are used, padding can only be 0 or 2
+		 * bytes and we can optimize this a bit. In addition, we must
+		 * not try to remove padding from short control frames that do
+		 * not have payload. */
+		padsize = hdrlen & 3;
+		if (padsize && hdrlen >= 24) {
 			memmove(skb->data + padsize, skb->data, hdrlen);
 			skb_pull(skb, padsize);
 		}

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH] ath9k: Do not remove header padding on RX from short frames

[Bob Copeland]

On Thu, Dec 11, 2008 at 11:22 AM, Jouni Malinen
<jouni.malinen@atheros.com> wrote:
> The 802.11 header is only padded to 32-bit boundary when the frame has
> a non-zero length payload. In other words, control frames (e.g., ACK)
> do not have a padding and we should not try to remove it. This fixes
> monitor mode for short control frames.

Thanks Jouni, that clears up the question of the same code in ath5k
(http://marc.info/?l=linux-wireless&m=122888546315200&w=2).

-- 
Bob Copeland %% www.bobcopeland.com

[ath9k-devel] [PATCH] ath9k: Do not remove header padding on RX from short frames

[Bob Copeland]

On Thu, Dec 11, 2008 at 11:22 AM, Jouni Malinen
<jouni.malinen@atheros.com> wrote:
> The 802.11 header is only padded to 32-bit boundary when the frame has
> a non-zero length payload. In other words, control frames (e.g., ACK)
> do not have a padding and we should not try to remove it. This fixes
> monitor mode for short control frames.

Thanks Jouni, that clears up the question of the same code in ath5k
(http://marc.info/?l=linux-wireless&m=122888546315200&w=2).

-- 
Bob Copeland %% www.bobcopeland.com

Re: [PATCH] ath9k: Do not remove header padding on RX from short frames

[Jouni Malinen]

On Thu, 2008-12-11 at 11:49 -0800, Bob Copeland wrote:
> On Thu, Dec 11, 2008 at 11:22 AM, Jouni Malinen
> <jouni.malinen@atheros.com> wrote:
> > The 802.11 header is only padded to 32-bit boundary when the frame has
> > a non-zero length payload.

> Thanks Jouni, that clears up the question of the same code in ath5k
> (http://marc.info/?l=linux-wireless&m=122888546315200&w=2).

Yes, the same rules on 802.11 header padding applies to ath5k.

- Jouni

[ath9k-devel] [PATCH] ath9k: Do not remove header padding on RX from short frames

[Jouni Malinen]

On Thu, 2008-12-11 at 11:49 -0800, Bob Copeland wrote:
> On Thu, Dec 11, 2008 at 11:22 AM, Jouni Malinen
> <jouni.malinen@atheros.com> wrote:
> > The 802.11 header is only padded to 32-bit boundary when the frame has
> > a non-zero length payload.

> Thanks Jouni, that clears up the question of the same code in ath5k
> (http://marc.info/?l=linux-wireless&m=122888546315200&w=2).

Yes, the same rules on 802.11 header padding applies to ath5k.

- Jouni

Re: [PATCH] ath9k: Do not remove header padding on RX from short frames

[Senthil Balasubramanian]

On Thu, Dec 11, 2008 at 09:52:13PM +0530, Jouni Malinen wrote:
> The 802.11 header is only padded to 32-bit boundary when the frame has
> a non-zero length payload. In other words, control frames (e.g., ACK)
> do not have a padding and we should not try to remove it. This fixes
> monitor mode for short control frames. In addition, the hdrlen&3 use
> is described in more detail to make it easier to understand how the
> padding length is calculated.
> 
> Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
> 
> ---
>  drivers/net/wireless/ath9k/recv.c |   12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> --- wireless-testing.orig/drivers/net/wireless/ath9k/recv.c     2008-12-11 11:35:56.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/ath9k/recv.c  2008-12-11 12:18:02.000000000 +0200
> @@ -571,8 +571,16 @@ int ath_rx_tasklet(struct ath_softc *sc,
>                 hdr = (struct ieee80211_hdr *)skb->data;
>                 hdrlen = ieee80211_get_hdrlen_from_skb(skb);
> 
> -               if (hdrlen & 3) {
> -                       padsize = hdrlen % 4;
> +               /* The MAC header is padded to have 32-bit boundary if the
> +                * packet payload is non-zero. The general calculation for
> +                * padsize would take into account odd header lengths:
> +                * padsize = (4 - hdrlen % 4) % 4; However, since only
> +                * even-length headers are used, padding can only be 0 or 2
> +                * bytes and we can optimize this a bit. In addition, we must
> +                * not try to remove padding from short control frames that do
> +                * not have payload. */
> +               padsize = hdrlen & 3;
> +               if (padsize && hdrlen >= 24) {
I think "if(padsize && hdrlen > 24)" should be sufficient here as padsize is
anyway zero for hdlen==24.
>                         memmove(skb->data + padsize, skb->data, hdrlen);
>                         skb_pull(skb, padsize);
>                 }
> 
> --
> Jouni Malinen                                            PGP id EFC895FA
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ath9k-devel] [PATCH] ath9k: Do not remove header padding on RX from short frames

[Senthil Balasubramanian]

On Thu, Dec 11, 2008 at 09:52:13PM +0530, Jouni Malinen wrote:
> The 802.11 header is only padded to 32-bit boundary when the frame has
> a non-zero length payload. In other words, control frames (e.g., ACK)
> do not have a padding and we should not try to remove it. This fixes
> monitor mode for short control frames. In addition, the hdrlen&3 use
> is described in more detail to make it easier to understand how the
> padding length is calculated.
> 
> Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
> 
> ---
>  drivers/net/wireless/ath9k/recv.c |   12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> --- wireless-testing.orig/drivers/net/wireless/ath9k/recv.c     2008-12-11 11:35:56.000000000 +0200
> +++ wireless-testing/drivers/net/wireless/ath9k/recv.c  2008-12-11 12:18:02.000000000 +0200
> @@ -571,8 +571,16 @@ int ath_rx_tasklet(struct ath_softc *sc,
>                 hdr = (struct ieee80211_hdr *)skb->data;
>                 hdrlen = ieee80211_get_hdrlen_from_skb(skb);
> 
> -               if (hdrlen & 3) {
> -                       padsize = hdrlen % 4;
> +               /* The MAC header is padded to have 32-bit boundary if the
> +                * packet payload is non-zero. The general calculation for
> +                * padsize would take into account odd header lengths:
> +                * padsize = (4 - hdrlen % 4) % 4; However, since only
> +                * even-length headers are used, padding can only be 0 or 2
> +                * bytes and we can optimize this a bit. In addition, we must
> +                * not try to remove padding from short control frames that do
> +                * not have payload. */
> +               padsize = hdrlen & 3;
> +               if (padsize && hdrlen >= 24) {
I think "if(padsize && hdrlen > 24)" should be sufficient here as padsize is
anyway zero for hdlen==24.
>                         memmove(skb->data + padsize, skb->data, hdrlen);
>                         skb_pull(skb, padsize);
>                 }
> 
> --
> Jouni Malinen                                            PGP id EFC895FA
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ath9k-devel] 2.6.28-rc8-wl Connection status bug?

[Brian]

Hi,
I have been having this 'problem' since rc7
Just installed the above kernel as the change log indicate some changes
in this area for ath9k.
The problem is that my router displays

	IP Address	Mode	Rate (Mbps)	Signal (%)
	0.0.0.0		802.11g	130		76

Now it should not be possible to get 130 out of 11g.

My router is set up to do both 11g/n, see below.
Prior to rc7 it used to show 11n and 300Mbps.

Not sure if it is relevant but I think the only thing I have changed in
the router is turning on the Wi-Fi Protected Setup.

How can I provide more detail/tests

By the way, looking through the change log I cannot believe how much
effort is going into this. Thanks one and all.

Brian

Wireless LAN
Wireless Radio : Enabled
802.11 Mode : Mixed 802.11n and 802.11g
Channel Width : 40MHz
Channel : 4
Secondary Channel : 8
WISH : Active
Wi-Fi Protected Setup : Enabled/Configured