Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#1086 closed defect (fixed)

IPv6 failing in Zurich A

Reported by: mcr@… Owned by: panda@…
Priority: blocker Milestone: ietf-098
Component: wireless Keywords:
Cc: My Current Location: Zurich A
My MAC Address: 08:11:96:01:81:e0 My OS: Linux Debian, 4.7.0-0.bpo.1-amd64


Hi, I'm in Zurich A on IETF network.
IPv4 working great.

wlan0     Link encap:Ethernet  HWaddr 08:11:96:01:81:e0  
          inet addr:  Bcast:  Mask:
          inet6 addr: 2001:67c:370:128:a11:96ff:fe01:81e0/64 Scope:Global
          inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link

dooku-[~](2.3.0) mcr 10053 %iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"ietf"  
          Mode:Managed  Frequency:5.745 GHz  Access Point: FC:5B:39:32:D6:8E   
          Bit Rate=39 Mb/s   Tx-Power=15 dBm   

dooku-[~](2.3.0) mcr 10051 %ping6
PING 56 data bytes
... no answers.

tcpdump shows:
13:30:29.462685 IP6 2001:67c:370:128:a11:96ff:fe01:81e0 > 2607:f0b0:f:2::247: ICMP6, echo request, seq 5, length 64

traceroute -6 gets no reply, not even first hop:

13:30:52.235056 IP6 2001:67c:370:128:a11:96ff:fe01:81e0.41885 > 2607:f0b0:f:2::247.33450: UDP, length 32
13:30:52.235156 IP6 2001:67c:370:128:a11:96ff:fe01:81e0.40217 > 2607:f0b0:f:2::247.33451: UDP, length 32
13:30:52.235207 IP6 2001:67c:370:128:a11:96ff:fe01:81e0.43104 > 2607:f0b0:f:2::247.33452: UDP, length 32
13:30:52.235250 IP6 2001:67c:370:128:a11:96ff:fe01:81e0.36767 > 2607:f0b0:f:2::247.33453: UDP, length 32
13:30:52.235294 IP6 2001:67c:370:128:a11:96ff:fe01:81e0.60832 > 2607:f0b0:f:2::247.33454: UDP, length 32
13:30:52.235339 IP6 2001:67c:370:128:a11:96ff:fe01:81e0.46167 > 2607:f0b0:f:2::247.33455: UDP, length 32

dooku-[~](2.3.0) mcr 10056 %ip -6 route ls
2001:67c:370:128::/64 dev wlan0  proto kernel  metric 256  expires 2591998sec
fe80::/64 dev wlan0  proto kernel  metric 256 
default via fe80::128:1 dev wlan0  proto ra  metric 1024  expires 598sec hoplimit 64

yet, I'm clearly able to reach the 
dooku-[~](2.3.0) mcr 10058 %ping6 fe80::128:1%wlan0
PING fe80::128:1%wlan0(fe80::128:1) 56 data bytes
64 bytes from fe80::128:1: icmp_seq=1 ttl=64 time=24.8 ms
64 bytes from fe80::128:1: icmp_seq=2 ttl=64 time=28.5 ms

so, just to be sure, let's show mac addresses of router:

dooku-[~](2.3.0) mcr 10004 %sudo tcpdump -e -i wlan0 -n -p ip6 and not port 5353
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:32:03.625923 08:81:f4:8a:a7:f0 > 08:11:96:01:81:e0, ethertype IPv6 (0x86dd), length 150: fe80::128:1 > ff02::1: ICMP6, router advertisement, length 96
13:32:05.234207 00:00:5e:00:02:80 > 33:33:00:00:00:12, ethertype IPv6 (0x86dd), length 94: fe80::128:2 > ff02::12: ip-proto-112 40
13:32:05.278574 08:11:96:01:81:e0 > 00:00:5e:00:02:80, ethertype IPv6 (0x86dd), length 94: 2001:67c:370:128:a11:96ff:fe01:81e0.50299 > 2607:f0b0:f:2::247.33434: UDP, length 32
13:32:05.278658 08:11:96:01:81:e0 > 00:00:5e:00:02:80, ethertype IPv6 (0x86dd), length 94: 2001:67c:370:128:a11:96ff:fe01:81e0.60173 > 2607:f0b0:f:2::247.33435: UDP, length 32
13:32:05.278706 08:11:96:01:81:e0 > 00:00:5e:00:02:80, ethertype IPv6 (0x86dd), length 94: 2001:67c:370:128:a11:96ff:fe01:81e0.48191 > 2607:f0b0:f:2::247.33436: UDP, length 32
13:32:05.278758 08:11:96:01:81:e0 > 00:00:5e:00:02:80, ethertype IPv6 (0x86dd), length 94: 2001:67c:370:128:a11:96ff:fe01:81e0.59227 > 2607:f0b0:f:2::247.33437: UDP, length 32
13:32:05.278804 08:11:96:01:81:e0 > 00:00:5e:00:02:80, ethertype IPv6 (0x86dd), length 94: 2001:67c:370:128:a11:96f

which looks right:

dooku-[~](2.3.0) mcr 10060 %ip -6 neigh show
fe80::128:3 dev wlan0 lladdr 80:71:1f:c3:90:00 router STALE
fe80::128:1 dev wlan0 lladdr 00:00:5e:00:02:80 router DELAY

I also tried ping6, and ping6 (which is where I noticed breakage originally)
V6 was working for me in Zurich C this morning.

Change history (4)

comment:1 Changed 4 years ago by llynch@…

Component: incomingwireless
Owner: changed from llynch@… to panda@…
Priority: tbdblocker
Status: newassigned
Type: requestdefect

comment:2 Changed 4 years ago by mcr@…

As of 14:11, everything works.

comment:3 Changed 4 years ago by panda@…

Resolution: fixed
Status: assignedclosed


Thank you for the report.

We have checked this issue and found the wireless resource had occasionally been congested. We have rearranged the channel allocation to reduce interferences with the other nearby APs, and then it should become better now. If you experience the same issue, please re-open this ticket.

Thank you.
Hirochika Asai

comment:4 Changed 3 years ago by Rick Alfvin

Milestone: ietf-98ietf-098

Milestone renamed

Note: See TracTickets for help on using tickets.