Print

[donnied]

Router 1 ---- Bridge Router ---- Desktop P

I have Router 1 (running OpenWRT Kamikaze) set up with a tunnel from HE.
Machines physically connected to it get ipv6 no problem. However,
Desktop P is connected via a wireless bridge (another WRT54GL with
Kamikaze) to Router 1.

Desktop P receives an appropriate ipv6 address; however, it cannot ping6
anything other than Bridge Router. IP6Tables is not installed on the
bridge router. FORWARDING is 1 in the /proc/conf/net/forwarding files.


The bridge router can ping6 Desktop P and vice versa. They cannot,
however, ping6 Router 1 (or any other ipv6 address).

Could/ should/ how would I establish a 6-> 4 tunnel directly to the
second router?

If I were to manually specify the ip6 gateway address for the bridge, which ipv6 address should I use?

[cholzhauer]

A diagram and the IP addresses you've used would help.

But

1) Have you assigned an IPv6 address to the bridge router on the interface you're using to bridge?
2) What range are you using?

[cconn]

if you are using anything other than WDS, you cannot use IPv6 unless you are in routed mode.

http://wiki.openwrt.org/doc/howto/clientmode#bridged.client.mode.issues

your options are;

1) use WDS
2) set up routed client mode

I think this is the same reason that Virtualbox hosts will work wired but not wireless on the host OS.

[donnied]

I'm using WRT54GLs with vanilla Kamikaze and the IPv4 client mode works fine.
I have not assigned an IPv6 address to the bridge nor the Desktop P. However, they are both showing appropriate IPv6 addresses within the space alloted by HE. I have a /64 assignment from HE and I am letting Router 1 distribute the addresses via radvd.

WAN ---- Router 1 ---- Bridge------Desktop P

Router 1:
br-lan
inet6 addr: 2001:465:6d:165::/64 Scope:Global
inet6 addr: 2001:465:6c:165::/64 Scope:Global

henet
inet6 addr: 2001:465:6c:165::2/64



Bridge
br-lan
inet6 addr: 2001:465:6d:165:21a:70ff:fee1:ae9b/64 Scope:Global

Desktop P
br0
inet6 addr: 2001:470:6d:165:22cf:30ff:fe9c:67d1/64 Scope:Global


Which of these is the ip6gw address?:
br-lan
inet6 addr: 2001:465:6d:165::/64 Scope:Global
inet6 addr: 2001:465:6c:165::/64 Scope:Global
henet
inet6 addr: 2001:465:6c:165::2/64

[broquea]

Everyone knows HE is 2001:470::/32, so bad obfuscation is a waste of effort, just paste the actual info; you even missed trying to hide that on the desktop IP.
Your LAN interface on Router-1 should not be configured at all with the tunnel's prefix.
The "gateway IP" for the desktop machine, using RADVD, should be the link-local address of the advertising router's LAN facing interface.
Do you have 2001:470:6d:165::1/64 configured on Router-1's br-lan interface? Or some other IP in that range, and not actually 2001:470:6d:165::/64? (hint: don't use 2001:470:6d:165::/64 as the IP)

[kasperd]

if you are using anything other than WDS, you cannot use IPv6 unless you are in routed mode.

http://wiki.openwrt.org/doc/howto/clientmode#bridged.client.mode.issues

Why would that only affect IPv6? It looks like an Ethernet-layer issue, that would affect IPv4 as well as IPv6. An interesting question of course is, does the current setup work with IPv4? Was it ever tested with IPv4?

[cconn]

it doesn't work since the ARP-NAT that is done by Openwrt to allow traffic in client mode is designed for IPv4 only.  Run a wireshark capture and you will see that most of the ICMPv6 traffic is broken/missing.  WDS is the only way.  This is not a openwrt-specific problem, Virtualbox, VMware and others all clearly state that in order to use IPv6 over bridged interfaces, they have to be wired.

WDS however allows it.  Why not use WDS?!

[kasperd]

it doesn't work since the ARP-NAT that is done by Openwrt to allow traffic in client mode is designed for IPv4 only.

So, it really is a link level problem, which affects everything. But a hacky workaround is able to hide the link level problem in case of IPv4.

So it is not the problem that is IPv6 specific, it is the workaround that is IPv4 specific.

WDS however allows it.  Why not use WDS?!

Yeah, from the linked description, WDS sounds more like a solution and less like a hack. But the description also mentions that WDS is non-standard and doesn't work well with equipment from different vendors.

Also, something doesn't sound right about WDS either. Why does the MAC addresses of the sending and receiving AP have to be in the frame in the first place? It is a wireless link, the frame is going to be received by the radio of all APs in range on the frequence regardless. And instead of looking at the MAC of the destination AP it could just look on the MAC of the destination host. If packets for that destination MAC would be sent over one of the switch ports on this AP, then the packet is for this AP. If the packets for that destination MAC would be sent over the wireless interface, then it is not for this AP. That could eliminate the destination AP MAC address, and since the only purpose of the sending AP MAC address is to know what to put in the destination AP MAC address for return traffic, then both of them could be eliminated, bringing it down to just two MAC addresses, namely the two shown in red in the figures.

[cconn]

I wish I could explain the innards of client STA vs WDS mode.  I am not an expert in that regard.  I am just saying from experience that I went half-crazy trying to get RAs and ND working correctly on bridged client mode, and ended up giving up and moving to WDS which I had stayed away from for stupid reasons.  It works perfectly with multiple bridges in my network, I have both D-LINK and Linksys/Cisco APs and they all happily use WDS and all my nodes have IPv6.

[cvmiller]

I am coming to this discussion late, but it answers my question of why  I couldn't get IPv6 through a wireless-client mode (not WDS). Thanks!