Opened 5 months ago

Closed 5 months ago

#1240 closed defect (duplicate)

v6 advertised on ietf-hotel but doesn't work?

Reported by: jari.arkko@… Owned by: Clemens Schrimpe
Priority: tbd Milestone: ietf-103
Component: network Keywords:
Cc: My Current Location:
My MAC Address: My OS:

Description


Hi,

Wondering if this is a problem or something on my Mac…

When connected to the “ietf” SSID on floor 9, I get everything working nicely. But when connecting to “ietf-hotel”, again everything works nicely on v4, but on v6 I have no connectivity.

Yet there’s a prefix advertisement:

11:46:01.542449 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 96) fe80::46d9:e7ff:fe40:b938 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 96
	hop limit 64, Flags [other stateful], pref medium, router lifetime 600s, reachable time 0s, retrans time 0s
	  prefix info option (3), length 32 (4): 2001:67c:1232:144::/64, Flags [onlink, auto], valid time 2592000s, pref. time 2592000s
	    0x0000:  40c0 0027 8d00 0027 8d00 0000 0000 2001
	    0x0010:  067c 1232 0144 0000 0000 0000 0000
	  rdnss option (25), length 40 (5):  lifetime 15s, addr: 2001:67c:370:229::7 addr: 2001:67c:370:229::6
	    0x0000:  0000 0000 000f 2001 067c 0370 0229 0000
	    0x0010:  0000 0000 0007 2001 067c 0370 0229 0000
	    0x0020:  0000 0000 0006
	  source link-address option (1), length 8 (1): 44:d9:e7:40:b9:38
	    0x0000:  44d9 e740 b938

Which is accepted by my Mac, but then pinging on v6 doesn’t work.

Is ietf-hotel supposed to work on v6? If not, disable the advertisements… if yes… maybe some fixing to do on my Mac or your network...

$ ifconfig en0
en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	ether dc:a9:04:92:22:b4 
	inet6 fe80::869:c886:fe98:a78e%en0 prefixlen 64 secured scopeid 0x6 
	inet 31.133.156.201 netmask 0xfffff000 broadcast 31.133.159.255
	inet6 2001:67c:1232:144:18e0:e9d:5e7a:8fcc prefixlen 64 autoconf secured 
	inet6 2001:67c:1232:144:9c51:4c5a:7868:a721 prefixlen 64 autoconf temporary 
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active
m36:drop-tracer jariarkko$ ping6 -n www.google.com <http://www.google.com/>
PING6(56=40+8+8 bytes) 2001:67c:1232:144:9c51:4c5a:7868:a721 --> 2404:6800:4003:80d::2004
^C
--- www.google.com <http://www.google.com/> ping6 statistics ---
7 packets transmitted, 0 packets received, 100.0% packet loss


Change history (3)

comment:1 Changed 5 months ago by llynch@…

Component: incomingnetwork
Owner: changed from < default > to Clemens Schrimpe
Status: newassigned
Type: requestdefect

comment:2 Changed 5 months ago by Clemens Schrimpe

Well ... unfortunately we are at a hotel where they chose to deploy a Ruckus Wireless system - and all of a sudden it's Chicago 2017 again:

If APs run the user-traffic through(!) their shiny new "SmartNet?" controller then it eats up IPv6 neighbor discovery packets, because it thinks it nows better, thus effectively disabling the *use* of IPv6. Unfortunately the controller lets IPv6 Router Advertisements pass, so devices do have IPv6 addresses by means of SLAAC, but cannot use them. (We are aware that this is the worst state of IPv6 "deployment" - even beyond having no IPv6 in the first place ... *roll eyes*)

So, long story short: The above obstacle can be overcome by making the APs *not* tunnel the packets back through the dumbass controller, but directly dropping them into the switch-ports where the APs are connected to.

Those "mode" was set in the controller (literally) months ago, but there are *still* APs out there who haven't gotten the memo and thus *still* tunnel back "ietf-hotel" traffic.

We have two persons from the hotel's IT staff, including one from their service provider GuestTek? hunting down those rogue APs with said bad behavior since last Tuesday, but they haven't found all affected APs yet - unfortunately.

We're driving them to continue to hunt (& destroy!!1!11!!!) misbehaving APs. In the meantime please bear with us and keep on reporting places (or AP's MAC addresses) when you encounter the problem again.

PS: It has just been fixed for the pool area, so please come out again and enjoy! :-)

comment:3 Changed 5 months ago by jim@…

Resolution: duplicate
Status: assignedclosed

Jari, while we work this problem, let's track it in Chris Morrow's ticket (https://tickets.meeting.ietf.org/ticket/1239) rather than two parallel tickets for the same problem. I'll close this one, and add you as a watcher on the other one so you get updates.

Thanks! - Jim

Note: See TracTickets for help on using tickets.