Bugzilla – Bug 4612
Unicast IPv6 works in only one direction through SB3 bridge
Last modified: 2010-05-07 10:52:52 UTC
Hello, I'm using a SB3 in bridge mode as follows: Internet <--> Linksys WRT54GS <-[wireless]-> SB3 <-[wired]-> Mac Mini I'm running 6.5.0 SlimServer on the Mac Mini. Everything works fine except for IPv6. I can pass unicast and multicast IPv6 traffic from the mini towards the Internet through the SB3 bridge fine (I see the traffic using tcpdump on the WRT), but only multicast IPv6 traffic passes from the WRT through the SB3 bridge to the Mac Mini. I know this because tcpdump on the mini shows only traffic destined to IPv6 multicast addresses (ff02::...) arriving on the mini. Unicast IPv6 traffic is dropped at the SB3 bridge. If the mini is connected directly (wired) to an ethernet port on the WRT, IPv6 unicast and multicast work fine in both directions. All IPv4 traffic works fine in both directions, of course. Why don't I just use the mini's Airport Extreme card and connect to the WRT wirelessly? Because there is a known problem with Airport Extreme cards and Linksys routers - the wireless connection drops once a day or so and manual intervention is required to bring it back up. And, yes, IPv6 unicast and multicast work fine in both directions when the mini talks wirelessly directly to the WRT (other than the irritating random connection drop problem). So, to summarize: 1) IPv6 multicast and unicast work fine through the SB3 bridge from wired to wireless. 2) IPv6 multicast works fine through the SB3 bridge from wireless to wired. 3) SB3 bridge does not pass IPv6 multicast from wireless to wired interface. Thanks, Steve
I thought a packet trace might be helpful. Scenario: Internet <----> WRT54GS <--[wireless]--> SB3 <--[wired]--> Mac mini Mac addresses: WRT54GS wireless interface: 00:12:17:19:79:c1 SB3 Bridge: 00:04:20:06:3D:CD Mac Mini: 00:16:cb:a7:27:8a Upon executing "ping6 www.kame.net", and after successful DNS resolution (using IPv4), the mini sends out a neighbor soliciation looking for it's router (Note this is sent to a IPv6 multicast address, which is mapped to a MAC multicast address 33:33:ff....). This is as seen using tcpdump on the mini: 08:35:42.043139 00:16:cb:a7:27:8a > 33:33:ff:19:79:c1, ethertype IPv6 (0x86dd), length 86: 2001:618:400:29a8:216:cbff:fea7:278a > ff02::1:ff19:79c1: ICMP6, neighbor solicitation, who has fe80::212:17ff:fe19:79c1, length 32 The WRT sees (using tcpdump on WRT) this packet (Note WRT sees packet arriving from SB3's bridge MAC addr): 08:35:42.186342 00:04:20:06:3d:cd > 33:33:ff:19:79:c1, ethertype IPv6 (0x86dd), length 86: 2001:618:400:29a8:216:cbff:fea7:278a > ff02::1:ff19:79c1: icmp6: neighbor sol: who has fe80::212:17ff:fe19:79c1 WRT immediately replies with a unicast IP neighbor advertisement (the reply) to the mini's MAC addr: 08:35:42.186790 00:12:17:19:79:c1 > 00:16:cb:a7:27:8a, ethertype IPv6 (0x86dd), length 86: fe80::212:17ff:fe19:79c1 > 2001:618:400:29a8:216:cbff:fea7:278a: icmp6: neighbor adv: tgt is fe80::212:17ff:fe19:79c1 This unicast IPv6 neighbor advertisement never arrives at the mini, so I assume it is dropped by the SB3 bridge.
The wireless bridge is really very dumb. I'm not sure what kind of glitch or fault it might have that is causing it to selectively drop your ipv6 packets. I don't keep an ipv6 network here to test with, but I've slapped one together in the past. Have you talked to anyone in the forums to see if they've had the same issue? This bug falls under the category of 'very few people are affected, but 1) it should work and 2) in time more people will be affected'
Christopher, I originally posted this problem on the forum and promptly received the suggestion to open a bug. And, no, no one else indicated they are having similar problems. I agree that this is an extreme edge case at this time, but I wanted to bring it to your attention. My workaround is to run a CAT5 cable from my WRT54GS to my Mac Mini rather than use the SB3 bridge. It looks ugly, but I have full IPv6 connectivity on my mini now. Are the NICs Broadcom by any chance? I've read somewhere that there's a known problem bridging IPv6 through some Broadcom NICs. Steve
All new Squeezebox products are likely to be based on the SqueezePlay platform. We do not plan to implement any further enhancements to the ip3k firmware or which are targeted specifically at ip3k-based products.