Modify

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#4058 closed defect (wontfix)

ipv6 will not travel over wireless in client mode

Reported by: stupendoussteve@… Owned by: developers
Priority: response-needed Milestone: Bugs Paradise
Component: kernel Version: Kamikaze trunk
Keywords: Cc:

Description

I have a WRT54G running in client mode behind another WRT running radvd. The wireless clients connected to that AP receive addresses and connect to the outside just fine. The client router is receiving and passing advertisements from radvd, but actual IPv6 traffic will not pass over the wireless interface, from the client router or a wired system connected to it.

br-lan Link encap:Ethernet HWaddr 00:12:17:30:92:1F

inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
inet6 addr: 2001:XXXX:XXXX:0:212:17ff:fe30:921f/64 Scope:Global

root@router:~# ping6 2001:XXXX:XXXX::1
PING 2001:XXXX:XXXX::1 (2001:XXXX:XXXX::1): 56 data bytes

--- 2001:XXXX:XXXX::1 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss

2001:XXXX:XXXX::/64 dev br-lan proto kernel metric 256 expires 2591518sec mtu 1500 advmss 1440
fe80::/64 dev eth0 metric 256 mtu 1500 advmss 1440
fe80::/64 dev br-lan metric 256 mtu 1500 advmss 1440
fe80::/64 dev eth0.0 metric 256 mtu 1500 advmss 1440
fe80::/64 dev wl0 metric 256 mtu 1500 advmss 1440
ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440
ff00::/8 dev br-lan metric 256 mtu 1500 advmss 1440
ff00::/8 dev eth0.0 metric 256 mtu 1500 advmss 1440
ff00::/8 dev wl0 metric 256 mtu 1500 advmss 1440
default via 2001:XXXX:XXXX::1 dev br-lan metric 1024 mtu 1500 advmss 1440
unreachable default dev lo proto none metric -1 error -128

Attachments (0)

Change History (5)

comment:1 Changed 9 years ago by andrew@…

My neighbour and I are seeing similar behaviour where IPv6 pings (and traffic) aren't going over our wireless link.

We have discovered that neighbour solicitations (arps in IPv4 talk) are not being received by other nodes on the wireless network. We can see that solicitations are being sent, but nothing is received.

If we add neighbour details using "ip -6 neigh add <ip> dev br-wireless <mac>" for the other node on each box, then the pings do work.

I'll attach some tcpdumps to this ticket showing this behaviour soon.

comment:2 Changed 8 years ago by spudz76

  • Component changed from other to kernel
  • Milestone changed from Kamikaze to Kamikaze Bugs Paradise
  • Version set to Kamikaze trunk

[patchteam] Setting to response-needed as you left us hanging. Also need confirmation this is still an issue with newer revisions, could have been a side effect of an older 2.4/wl driver, or may work if 2.6/b43 is used.

comment:3 Changed 8 years ago by spudz76

  • Priority changed from normal to response-needed

comment:4 Changed 8 years ago by nbd

  • Resolution set to wontfix
  • Status changed from new to closed

It seems that you're bridging the client interface to the wired interface. That is completely unsupported, as the 802.11 client mode does not support bridging at all.

comment:5 Changed 8 years ago by jochen@…

With wds=1, it even works for me in client bridge mode:

ping6 www.netbsd.org
PING www.netbsd.org(www.NetBSD.org) 56 data bytes
64 bytes from www.NetBSD.org: icmp_seq=1 ttl=54 time=236 ms
64 bytes from www.NetBSD.org: icmp_seq=2 ttl=54 time=713 ms
64 bytes from www.NetBSD.org: icmp_seq=3 ttl=54 time=229 ms
64 bytes from www.NetBSD.org: icmp_seq=4 ttl=54 time=232 ms
64 bytes from www.NetBSD.org: icmp_seq=5 ttl=54 time=266 ms

Topology:

Laptop - eth0 - NM-700 - WDS link - WGT634U - sit0 (IPv6 tunnel)

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.