SixXS::Sunset 2017-06-06

sixxs to wireless sensor network
[nz] Shadow Hawkins on Thursday, 24 October 2013 23:05:43
Hi guys. I'm desperately looking for a configuration solution to enable a sixxs tunnel to talk to wireless sensor nodes on the other side of a 6LowPAN border router. The setup is as follows: A sixxs tunnel with /48 subnet terminates in a raspberry pi (running raspian) - interface is sixxs. The RPi is itself running as a 6lbr 6LowPAN border router, or really a smart bridge to a wireless sensor network. The smart bridge appears on the RPi as tap0 interface. The smart bridge picks up radvd (also running on the RPi) advertisements so that itself and all the nodes in the network autoconfigure with the prefix (brilliant). The RPi also of course has an eth0 interface. Typically the eth0 is bridged to the tap0 interface, by attaching them to br0. This enables local network hosts to talk to wireless sensor nodes. This is all working excellently. When the sixxs/aiccu tunnel is added, with radvd configured with br0 as its interface the tunnel can talk to the Lan, the Lan can talk to the tunnel and the Lan can talk to nodes in the wireless sensor network (or at least pings both ways work fine). However I am unable to get the tunnel to ping the wireless sensor nodes. ICMP packets are sent but no replies are received. Here's details of the current configuration - I have tried a few other variations without success 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 inet6 ::1/128 scope host 3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 inet6 2001:4439:28b::1/64 scope global inet6 fe80::ba27:ebff:fef4:dd23/64 scope link 4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 500 inet6 2001:4439:28b:1::1/64 scope global 5: sit0: <NOARP,UP,LOWER_UP> mtu 1480 inet6 ::192.168.1.1/96 scope global inet6 ::127.0.0.1/96 scope host 6: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500 inet6 2001:4439:28b::1/128 scope global inet6 2001:4439:150:13b::2/64 scope global deprecated inet6 fe80::4439:150:13b:2/64 scope link Interfaces: auto lo iface lo inet loopback iface eth0 inet dhcp up ip -6 addr add 2001:4439:28b:2::1/64 dev eth0 down ip -6 addr del 2001:4439:28b:2::1/64 dev eth0 allow-hotplug wlan0 iface wlan0 inet manual auto tap0 iface tap0 inet dhcp up ip -6 addr add 2001:4439:28b:1::1/64 dev $IFACE down ip -6 addr del 2001:4439:28b:1::1/64 dev $IFACE auto br0 iface br0 inet dhcp bridge_ports tap0 eth0 up ip -6 addr add 2001:4439:28b::1/64 dev $IFACE down ip -6 addr del 2001:4439:28b::1/64 dev $IFACE wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf iface default inet dhcp radvd.conf interface br0 { AdvSendAdvert on; AdvHomeAgentFlag off; MinRtrAdvInterval 30; MaxRtrAdvInterval 100; AdvDefaultLifetime 0; prefix 2001:4439:28b::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; }; So when I attempt to ping a wireless sensor node there are no replies: --- 2001:4439:28b:0:280:e103:0:735b ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3012ms Below is in output from tshark on the RPi for interface br0 when a ping from the internet is sent through the tunnel at a wireless sensor node global address (2001:4439:28b:0:280:e103:0:735b). 9.090174 fe80::ba27:ebff:fef4:dd23 -> 2001:4439:28b:0:280:e103:0:735b ICMPv6 86 Neighbor Solicitation for 2001:4439:28b:0:280:e103:0:735b from 62:f2:aa:09:bb:06 9.090620 2001:4439:28b:0:280:e103:0:735b -> fe80::ba27:ebff:fef4:dd23 ICMPv6 86 Neighbor Advertisement 2001:4439:28b:0:280:e103:0:735b (sol, ovr) is at 02:03:00:00:6d:ef The MAC address that is returned (02:03:00:00:6d:ef) is that of the slip radio node that is the next hop from tap0 (the slip radio is the node that talks to the rest of the sensor network, which the RPi communicates with via a serial link). MACS: tap0 - 62:f2:aa:09:bb:06 br0 - 62:f2:aa:09:bb:06 eth0 - b8:27:eb:f4:dd:23 slip radio host - 02:03:00:00:6d:ef I can successfully ping a wireless sensor host from the Lan (2001:4439:28b:0:ba27:ebff:fe30:79cb): PING 2001:4439:28b:0:280:e103:0:6c57(2001:4439:28b:0:280:e103:0:6c57) 20 data bytes 28 bytes from 2001:4439:28b:0:280:e103:0:6c57: icmp_seq=1 ttl=63 time=137 ms 28 bytes from 2001:4439:28b:0:280:e103:0:6c57: icmp_seq=2 ttl=63 time=139 ms 28 bytes from 2001:4439:28b:0:280:e103:0:6c57: icmp_seq=3 ttl=63 time=145 ms 28 bytes from 2001:4439:28b:0:280:e103:0:6c57: icmp_seq=4 ttl=63 time=139 ms the MAC address of eth0 is again returned in the Neighbor Advertisement 1.617638 2001:4439:28b:0:ba27:ebff:fe30:79cb -> ff02::1:ff00:6c57 ICMPv6 86 Neighbor Solicitation for 2001:4439:28b:0:280:e103:0:6c57 from b8:27:eb:30:79:cb 1.618374 2001:4439:28b:0:280:e103:0:6c57 -> 2001:4439:28b:0:ba27:ebff:fe30:79cb ICMPv6 86 Neighbor Advertisement 2001:4439:28b:0:280:e103:0:6c57 (sol, ovr) is at 02:03:00:00:6d:ef Any suggested solutions to enable the wireless nodes to be accessed from the internet would be appreciated. Best wishes, Ron
sixxs to wireless sensor network
[ch] Jeroen Massar SixXS Staff on Friday, 25 October 2013 06:54:05
The culprint lies here:
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 2001:4439:28b::1/64 scope global
...
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 500
inet6 2001:4439:28b:1::1/64 scope global
...
6: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500
inet6 2001:4439:28b::1/128 scope global
inet6 2001:4439:150:13b::2/64 scope global deprecated
inet6 fe80::4439:150:13b:2/64 scope link
You should remove 2001:4439:28b::1/128 from the "sixxs" interface, it should not be there as it is already on another interface. Also, as you bridge tap0 to br0 you should not have the address there either. You should only have it on br0.
sixxs to wireless sensor network
[nz] Shadow Hawkins on Friday, 25 October 2013 10:04:41
Jeroen Massar wrote:
The culprint lies here:
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 2001:4439:28b::1/64 scope global
...
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 500
inet6 2001:4439:28b:1::1/64 scope global
...
6: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500
inet6 2001:4439:28b::1/128 scope global
inet6 2001:4439:150:13b::2/64 scope global deprecated
inet6 fe80::4439:150:13b:2/64 scope link
You should remove 2001:4439:28b::1/128 from the "sixxs" interface, it should not be there as it is already on another interface. Also, as you bridge tap0 to br0 you should not have the address there either. You should only have it on br0.
sixxs to wireless sensor network
[nz] Shadow Hawkins on Friday, 25 October 2013 10:05:29
Thanks for the response Jeroen, very much appreciated. Having experimented for quite a while with this, those incorrect addresses were left over. They are now removed. I rebooted. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: br0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 inet6 2001:4439:28b::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::ba27:ebff:fef4:dd23/64 scope link valid_lft forever preferred_lft forever 5: sit0: <NOARP,UP,LOWER_UP> mtu 1480 inet6 ::192.168.1.1/96 scope global valid_lft forever preferred_lft forever inet6 ::127.0.0.1/96 scope host valid_lft forever preferred_lft forever 6: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500 inet6 2001:4439:150:13b::2/64 scope global valid_lft forever preferred_lft forever inet6 fe80::4439:150:13b:2/64 scope link valid_lft forever preferred_lft forever Pinging from the internet across the tunnel to a wireless sensor node still gets no replies: IPv6 Ping Output: PING 2001:4439:28b:0:280:e103:0:735b(2001:4439:28b:0:280:e103:0:735b) 32 data bytes --- 2001:4439:28b:0:280:e103:0:735b ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3013ms Darn. I don't understand why I can ping wireless sensor nodes from the Lan and RPi but not via the tunnel. So far no configuration has enabled me to do this. I can still ping: - External sites from the RPi routing host - External sites from other hosts on the Lan - Hosts on the Lan from the internet via the tunnel - Wireless nodes from both the RPi routing host and Lan hosts These are now the rpi routes: ::/96 via :: dev sit0 metric 256 2001:4439:150:13b::/64 dev sixxs proto kernel metric 256 2001:4439:28b::/64 dev br0 proto kernel metric 256 fe80::/64 dev br0 proto kernel metric 256 fe80::/64 dev sixxs proto kernel metric 256 default via 2001:4439:150:13b::1 dev sixxs metric 1024 and routes of a Lan host: 2001:4439:28b::/64 dev eth0 proto kernel metric 256 expires 86385sec fe80::/64 dev eth0 proto kernel metric 256 ff00::/8 dev eth0 metric 256 default via 2001:4439:28b::1 dev eth0 metric 1024 Any other diagnostics and/or suggestions would be gratefully received. Cheers, Ron
sixxs to wireless sensor network
[ch] Jeroen Massar SixXS Staff on Friday, 25 October 2013 10:13:06
Darn. I don't understand why I can ping wireless sensor nodes from the Lan and RPi but not via the tunnel. So far no configuration has enabled me to do this.
Do the wireless nodes have a default route?
Any other diagnostics and/or suggestions would be gratefully received.
Looking at the default route of the wireless nodes would be a good step. tcpdump will likely also give you some extra details on which packets go missing.
sixxs to wireless sensor network
[nz] Shadow Hawkins on Friday, 25 October 2013 21:45:02
Hi Jeroen, problem solved!! As a result of your suggestion.
Looking at the default route of the wireless nodes would be a good step.
Details of the wireless sensor network configuration is available as a web page from the border router (i.e. 6lbr smart bridge). I had effectively prevented radvd from creating a border router default route as this was causing looping problems. With that statement commented out in radvd.conf (see below) a default route is generated and I am now getting replies from wireless network nodes to pings sent through the tunnel from the internet! Now just need to prevent that looping if its still happening. interface br0 { AdvSendAdvert on; AdvHomeAgentFlag off; MinRtrAdvInterval 30; MaxRtrAdvInterval 100; #AdvDefaultLifetime 0; prefix 2001:4439:28b::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; }; }; Just to say that when working on your own it can be invaluable to have somebody else, in this case yourself, to help break out of the thinking rut! What a relief .. now on to the next problem! Best wishes, Ron

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker