[PATCH] ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

[PATCH] ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

[Luis R. Rodriguez]

This is a port of commit
91ed19f5f66a7fe544f0ec385e981f43491d1d5a
for 2.6.29.

Without this after scanning your device will set
the association ID to something bogus and what is
being reported is multicast/broadcast frame are not
being received. For details see this bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=498502

>From the original commit:

So that a new created IBSS network
doesn't break on the first scan.

It seems to Sujith and me that this
stupid code unnecessary, too.

So remove it...

Reported-by: David Woodhouse <dwmw2@infradead.org>
Tested-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Alina Friedrichsen <x-alina@gmx.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Jouni Malinen <Jouni.Malinen@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath9k/main.c |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath9k/main.c b/drivers/net/wireless/ath9k/main.c
index 3c04044..1cc826b 100644
--- a/drivers/net/wireless/ath9k/main.c
+++ b/drivers/net/wireless/ath9k/main.c
@@ -2300,11 +2300,6 @@ static void ath9k_configure_filter(struct ieee80211_hw *hw,
 	rfilt = ath_calcrxfilter(sc);
 	ath9k_hw_setrxfilter(sc->sc_ah, rfilt);
 
-	if (changed_flags & FIF_BCN_PRBRESP_PROMISC) {
-		if (*total_flags & FIF_BCN_PRBRESP_PROMISC)
-			ath9k_hw_write_associd(sc->sc_ah, ath_bcast_mac, 0);
-	}
-
 	DPRINTF(sc, ATH_DBG_CONFIG, "Set HW RX filter: 0x%x\n", sc->rx.rxfilter);
 }
 
-- 
1.6.2.2.446.gfbdc0

IPV6 testing... Re: [PATCH] ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

[David Woodhouse]

On Tue, 2009-05-05 at 17:04 -0700, Luis R. Rodriguez wrote:
> This is a port of commit
> 91ed19f5f66a7fe544f0ec385e981f43491d1d5a
> for 2.6.29.
> 
> Without this after scanning your device will set
> the association ID to something bogus and what is
> being reported is multicast/broadcast frame are not
> being received. For details see this bug report:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=498502
> 
> From the original commit:
> 
> So that a new created IBSS network
> doesn't break on the first scan.
> 
> It seems to Sujith and me that this
> stupid code unnecessary, too.
> 
> So remove it...
> 
> Reported-by: David Woodhouse <dwmw2@infradead.org>
> Tested-by: David Woodhouse <dwmw2@infradead.org>
> Signed-off-by: Alina Friedrichsen <x-alina@gmx.net>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> Signed-off-by: Jouni Malinen <Jouni.Malinen@atheros.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>

Btw, people ought to be _really_ embarrassed by this. It shows that you
never even bothered to try a simple IPv6 ping to/from a machine with
this driver.

You should _ALWAYS_ test network drivers with IPv6; it exercises
multicast paths that Legacy IP won't usually touch.

A simple 'ping6 -I wlan0 fe80::217:c4ff:fe5e:dd55' doesn't even need any
infrastructure or prior setup (except for looking in 'ifconfig' to see
the link-local IPv6 address of the interface you want to ping, since my
father's laptop is unlikely to be on your local link).

And running radvd with a simple config like this is also trivial, and
lets you verify that the machines on the subnet really do pick up
addresses and routes. It doesn't need an IPv6 connection to the outside
world; the fec0::/16 addresses it advertises are site-local:

	interface eth0
	{
		AdvSendAdvert on;
		MinRtrAdvInterval 30;
		MaxRtrAdvInterval 100;
		prefix fec0::/64
		{
			AdvOnLink on;
			AdvAutonomous on;
			AdvRouterAddr off;
		};
	};

For that matter, setting up a real tunnel to somewhere like sixxs.net or
he.net (or just using 6to4) is fairly bloody trivial too.

There's no excuse for shipping stuff that fails even the most basic
testing.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: IPV6 testing... Re: [PATCH] ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

[David Miller]

From: David Woodhouse <dwmw2@infradead.org>
Date: Sat, 09 May 2009 09:49:30 +0100

> Btw, people ought to be _really_ embarrassed by this. It shows that you
> never even bothered to try a simple IPv6 ping to/from a machine with
> this driver.
> 
> You should _ALWAYS_ test network drivers with IPv6; it exercises
> multicast paths that Legacy IP won't usually touch.

I pretty much never test IPV6 and I'm not embarassed.  Really, I
simply do not use it and have no interest in IPV6 at all.  It's simply
not on my radar.  I'll work on ipv6 bugs, but as far as using it
actively and testing every driver I write with it, NO WAY.

And that is OK.

Nobody else should be embarrased about failing to test ipv6 either.
Don't be rediculious David.

The community will test that eventually, find the problems, and the
bugs will get fixed.  End of story.

Re: IPV6 testing... Re: [PATCH] ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

[David Woodhouse]

On Sat, 2009-05-09 at 12:29 -0700, David Miller wrote:
> I pretty much never test IPV6 and I'm not embarassed.  Really, I
> simply do not use it and have no interest in IPV6 at all.  It's simply
> not on my radar.  I'll work on ipv6 bugs, but as far as using it
> actively and testing every driver I write with it, NO WAY.

I wasn't suggesting that you should care about IPv6, per se.

I was suggesting that you should care about Ethernet multicast.

And the simplest way of testing that seems to be to use IPv6.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation