Re: mac80211 IPv6 problems
On Fri, Aug 17, 2007 at 02:52:56AM +0200, Johannes Berg wrote:
> On Mon, 2007-08-06 at 13:05 -0400, John W. Linville wrote:
>
> > --- a/net/mac80211/ieee80211.c
> > +++ b/net/mac80211/ieee80211.c
> > @@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
> > memcpy(dst, hdr->addr1, ETH_ALEN);
> > memcpy(src, hdr->addr3, ETH_ALEN);
> >
> > - if (sdata->type != IEEE80211_IF_TYPE_STA) {
> > + if (sdata->type != IEEE80211_IF_TYPE_STA ||
> > + (is_multicast_ether_addr(dst) &&
> > +!compare_ether_addr(src, dev->dev_addr)))
> > return TXRX_DROP;
>
> I can confirm that this works (applies if you s/ieee80211.c/rx.c/) for
> IPv6 link local addresses, and it's definitely the right thing to do
> here.
Yes, seems so. FWIW, this patch is in later Fedora kernels.
Unfortunately (due to the ieee80211.c -> rx.c issue you mentioned)
applying this to 2.6.23 conflicts with patches already queued for
2.6.24. Since my experiments show that git doesn't help much in this
instance, I'll need to work something out with Dave M. if we are to
get this into 2.6.23.
If nothing else, I suppose we can just wait for 2.6.23 and send this
patch to -stable. Would that burn anyone's biscuits?
John
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Mon, 2007-08-06 at 13:05 -0400, John W. Linville wrote:
> --- a/net/mac80211/ieee80211.c
> +++ b/net/mac80211/ieee80211.c
> @@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
> memcpy(dst, hdr->addr1, ETH_ALEN);
> memcpy(src, hdr->addr3, ETH_ALEN);
>
> - if (sdata->type != IEEE80211_IF_TYPE_STA) {
> + if (sdata->type != IEEE80211_IF_TYPE_STA ||
> + (is_multicast_ether_addr(dst) &&
> + !compare_ether_addr(src, dev->dev_addr)))
> return TXRX_DROP;
I can confirm that this works (applies if you s/ieee80211.c/rx.c/) for
IPv6 link local addresses, and it's definitely the right thing to do
here.
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Fri, Aug 03, 2007 at 01:02:12AM -0700, Michael Wu wrote:
> This doesn't seem quite right. I think ieee80211_rx_h_data is a safer place
> for this check (inside the IEEE80211_FCTL_FROMDS case), and allows various
> statistics to be updated. ieee80211_rx_h_sta_process is another function that
> might work though that would probably involve more code to add all the right
> checks.
The patch below seems to work for me w/ an otherwise stock F-7 kernel
w/ iwl3945. Thoughts?
From: John W. Linville <[EMAIL PROTECTED]>
[PATCH] mac80211: filter locally-originated multicast frames
In STA mode, the AP will echo our traffic. This includes multicast
traffice.
Receiving these frames confuses some protocols and applications,
notably IPv6 Duplicate Address Detection.
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
net/mac80211/ieee80211.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index a42e70e..0097b0a 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -3030,9 +3030,10 @@ ieee80211_rx_h_data(struct ieee80211_txrx_data *rx)
memcpy(dst, hdr->addr1, ETH_ALEN);
memcpy(src, hdr->addr3, ETH_ALEN);
- if (sdata->type != IEEE80211_IF_TYPE_STA) {
+ if (sdata->type != IEEE80211_IF_TYPE_STA ||
+ (is_multicast_ether_addr(dst) &&
+!compare_ether_addr(src, dev->dev_addr)))
return TXRX_DROP;
- }
break;
case 0:
/* DA SA BSSID */
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Thu, 2007-08-02 at 20:55 -0400, John W. Linville wrote: > I hacked-up the (untested) patch below -- thoughts? I tried to test it. Today, I get no connectivity with bcm43xx-mac80211 (from Fedora 7 + your patch). It does manage to associate, but tcpdump shows it doesn't seem to receive any packets correctly -- http://david.woodhou.se/bcm43xx-bad.txt I tried taking the device down and back up, and setting the WEP key again (I think I've seen it screw up before and have to be told the WEP key again before it starts working), but that didn't help. Removing the module left rmmod and ksoftirqd both eating CPU, so I had to reboot. I don't have time to do any more right now; I might look at it again in a couple of weeks when I get home. But all this ought to be reproduceable elsewhere -- and if it isn't, I have a Cardbus card which seems to be exactly the same rev 4306 as my shinybook's internal device. Give me an address to ship it to :) -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Thu, Aug 02, 2007 at 11:46:18PM +0100, David Woodhouse wrote:
> On Thu, 2007-08-02 at 18:30 -0400, Daniel Drake wrote:
> > This may be a stack-level issue. This is one of the issues holding back
> > zd1211rw-mac80211 going into mainline: we have a report that
> > zd1211rw-softmac works fine with IPv6 but mac80211 only works
> > occasionally with the same device on the same system.
> >
> > Does anyone have any ideas?
>
> It receives its own neighbour solicitation (multicast) packets when the
> AP sends them back out again. These packets...
>
> 23:41:56.046939 00:0a:95:f3:99:92 > 33:33:ff:f3:99:92, ethertype IPv6
> (0x86dd), length 78: :: > ff02::1:fff3:9992: ICMP6, neighbor
> solicitation, who has fe80::20a:95ff:fef3:9992, length 24
>
> You should be able to see this without _any_ IPv6 infrastructure -- and
> you'll see the link-local IPv6 address remains 'tentative'.
>
> Once you've fixed that, setting up a local route advertisement dæmon
> (radvd) to give you site-local addresses is fairly trivial too -- and
> then you can also check that Ethernet multicast is working properly.
I hacked-up the (untested) patch below -- thoughts?
---
From: John W. Linville <[EMAIL PROTECTED]>
[PATCH] mac80211: filter locally-originated multicast frames
In STA mode, the AP will echo our traffic. This includes multicast
traffice.
Receiving these frames confuses some protocols and applications,
notably IPv6 Duplicate Address Detection.
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
net/mac80211/ieee80211.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index a42e70e..6dc6451 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -4263,11 +4263,14 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct
sk_buff *skb,
rx.u.rx.ra_match = 0;
} else if (!multicast &&
compare_ether_addr(sdata->dev->dev_addr,
- hdr->addr1) != 0)
{
+ hdr->addr1)) {
if (!sdata->promisc)
continue;
rx.u.rx.ra_match = 0;
- }
+ } else if (multicast &&
+
!compare_ether_addr(sdata->dev->dev_addr,
+ hdr->addr3))
+ rx.u.rx.ra_match = 0;
break;
case IEEE80211_IF_TYPE_IBSS:
if (!bssid)
--
John W. Linville
[EMAIL PROTECTED]
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
mac80211 IPv6 problems
David Woodhouse wrote: > My experience is that mac80211 is broken w.r.t IPv6 -- it receives its > own packets. It would be suboptimal for me if the softmac version of > bcm43xx were to go away before that got fixed. This may be a stack-level issue. This is one of the issues holding back zd1211rw-mac80211 going into mainline: we have a report that zd1211rw-softmac works fine with IPv6 but mac80211 only works occasionally with the same device on the same system. Does anyone have any ideas? Thanks, Daniel ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Thu, 2007-08-02 at 18:30 -0400, Daniel Drake wrote: > This may be a stack-level issue. This is one of the issues holding back > zd1211rw-mac80211 going into mainline: we have a report that > zd1211rw-softmac works fine with IPv6 but mac80211 only works > occasionally with the same device on the same system. > > Does anyone have any ideas? It receives its own neighbour solicitation (multicast) packets when the AP sends them back out again. These packets... 23:41:56.046939 00:0a:95:f3:99:92 > 33:33:ff:f3:99:92, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:fff3:9992: ICMP6, neighbor solicitation, who has fe80::20a:95ff:fef3:9992, length 24 You should be able to see this without _any_ IPv6 infrastructure -- and you'll see the link-local IPv6 address remains 'tentative'. Once you've fixed that, setting up a local route advertisement dæmon (radvd) to give you site-local addresses is fairly trivial too -- and then you can also check that Ethernet multicast is working properly. -- dwmw2 ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 IPv6 problems
On Friday 03 August 2007, Daniel Drake wrote: > David Woodhouse wrote: > > My experience is that mac80211 is broken w.r.t IPv6 -- it receives its > > own packets. It would be suboptimal for me if the softmac version of > > bcm43xx were to go away before that got fixed. > > This may be a stack-level issue. This is one of the issues holding back > zd1211rw-mac80211 going into mainline: we have a report that > zd1211rw-softmac works fine with IPv6 but mac80211 only works > occasionally with the same device on the same system. > > Does anyone have any ideas? This is certainly an issue in the packet filtering of mac80211. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
