[opensuse] default ipv6 route is lost (after a while)
I'm running Leap15 on a couple of small NanoPi Neo Air. The network is configured with dhcp and radvd, the latter also hands out the default route. Today I noticed that both had lost their default routes: nano1:~ # uptime 18:06:44 up 9 days 7:31, 1 user, load average: 0.00, 0.00, 0.00 nano1:~ # ip -6 route show 2001:db8::1::/64 dev wlan0 proto kernel metric 256 expires 85071sec pref medium fe80::/64 dev wlan0 proto kernel metric 256 pref medium After a reboot, the default route is back: nano1:~ # uptime 18:22:47 up 0:00, 1 user, load average: 1.03, 0.29, 0.10 nano1:~ # ip -6 route show 2001:db8::1::/64 dev wlan0 proto kernel metric 256 expires 86381sec pref medium fe80::/64 dev wlan0 proto kernel metric 256 pref medium default via fe80::1 dev wlan0 proto ra metric 1024 expires 1781sec hoplimit 64 pref medium I've put up some monitoring to try to determine when the route is lost, but why would it be lost at all?? -- Per Jessen, Zürich (9.2°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 27/03/2019 18.41, Per Jessen wrote:
I'm running Leap15 on a couple of small NanoPi Neo Air. The network is configured with dhcp and radvd, the latter also hands out the default route. Today I noticed that both had lost their default routes:
nano1:~ # uptime 18:06:44 up 9 days 7:31, 1 user, load average: 0.00, 0.00, 0.00 nano1:~ # ip -6 route show 2001:db8::1::/64 dev wlan0 proto kernel metric 256 expires 85071sec pref medium fe80::/64 dev wlan0 proto kernel metric 256 pref medium
After a reboot, the default route is back:
nano1:~ # uptime 18:22:47 up 0:00, 1 user, load average: 1.03, 0.29, 0.10 nano1:~ # ip -6 route show 2001:db8::1::/64 dev wlan0 proto kernel metric 256 expires 86381sec pref medium fe80::/64 dev wlan0 proto kernel metric 256 pref medium default via fe80::1 dev wlan0 proto ra metric 1024 expires 1781sec
It has a short expiration period. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))
Carlos E. R. wrote:
On 27/03/2019 18.41, Per Jessen wrote:
I'm running Leap15 on a couple of small NanoPi Neo Air. The network is configured with dhcp and radvd, the latter also hands out the default route. Today I noticed that both had lost their default routes:
nano1:~ # uptime 18:06:44 up 9 days 7:31, 1 user, load average: 0.00, 0.00, 0.00 nano1:~ # ip -6 route show 2001:db8::1::/64 dev wlan0 proto kernel metric 256 expires 85071sec pref medium fe80::/64 dev wlan0 proto kernel metric 256 pref medium
After a reboot, the default route is back:
nano1:~ # uptime 18:22:47 up 0:00, 1 user, load average: 1.03, 0.29, 0.10 nano1:~ # ip -6 route show 2001:db8::1::/64 dev wlan0 proto kernel metric 256 expires 86381sec pref medium fe80::/64 dev wlan0 proto kernel metric 256 pref medium default via fe80::1 dev wlan0 proto ra metric 1024 expires 1781sec
It has a short expiration period.
Yes, that is the default, 3 x MaxRtrAdvInterval = 1800s. The default MaxRtrAdvInterval is 600. -- Per Jessen, Zürich (4.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/27/2019 01:41 PM, Per Jessen wrote:
I've put up some monitoring to try to determine when the route is lost, but why would it be lost at all??
That would depend on where the problem is. Fire up Wireshark, to ensure the RAs are being transmitted periodically. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 03/27/2019 01:41 PM, Per Jessen wrote:
I've put up some monitoring to try to determine when the route is lost, but why would it be lost at all??
That would depend on where the problem is. Fire up Wireshark, to ensure the RAs are being transmitted periodically.
They are, radvd is working just fine. Has been for years. What's new is that I'm also letting radvd do the default route. -- Per Jessen, Zürich (6.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
James Knott wrote:
On 03/27/2019 01:41 PM, Per Jessen wrote:
I've put up some monitoring to try to determine when the route is lost, but why would it be lost at all??
That would depend on where the problem is. Fire up Wireshark, to ensure the RAs are being transmitted periodically.
They are, radvd is working just fine. Has been for years. What's new is that I'm also letting radvd do the default route.
Just in case, I did check. RAs are being transmitted just fine. The presence of the default route on a Nanopi seems to suggest RAs are also being received, but I've checked that too: nano1:~ # tcpdump -n -i wlan0 ip6[40]==133 or ip6[40]==134 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes 19:12:27.183650 IP6 fe80::1 > fe80::96a1:a2ff:fea3:ba7a: ICMP6, router advertisement, length 136 19:12:58.946961 IP6 fe80::1 > fe80::96a1:a2ff:fea3:ba7a: ICMP6, router advertisement, length 136 nano2:~ # tcpdump -n -i wlan0 ip6[40]==133 or ip6[40]==134 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes 19:12:27.191338 IP6 fe80::1 > fe80::96a1:a2ff:fea4:2446: ICMP6, router advertisement, length 136 19:12:58.954853 IP6 fe80::1 > fe80::96a1:a2ff:fea4:2446: ICMP6, router advertisement, length 136 -- Per Jessen, Zürich (13.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2019-03-27 18:41, Per Jessen wrote:
I've put up some monitoring to try to determine when the route is lost, but why would it be lost at all??
Probably because net.ipv6.conf.default.autoconf is enabled # sysctl net.ipv6.conf.default.autoconf net.ipv6.conf.default.autoconf = 1 You might need to turn off the individual net.ipv6.conf.wlan0.autoconf to. And even accept_ra Cheers, -- /bengan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bengt Gördén wrote:
On 2019-03-27 18:41, Per Jessen wrote:
I've put up some monitoring to try to determine when the route is lost, but why would it be lost at all??
Probably because net.ipv6.conf.default.autoconf is enabled
# sysctl net.ipv6.conf.default.autoconf net.ipv6.conf.default.autoconf = 1
Yep, it is on. The individual wlan0 too. I should look up what that 'autoconf' setting means, but instinctively it seems it ought to be on, as it is?
You might need to turn off the individual net.ipv6.conf.wlan0.autoconf to. And even accept_ra
Can you elaborate - surely I want accept_ra to be on? The setup has been working fine for days, at least since 18 March when I added the default route to radvd. Since I started the monitoring last night, I also see no problem. -- Per Jessen, Zürich (5.1°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2019-03-28 08:04, Per Jessen wrote:
Can you elaborate - surely I want accept_ra to be on?
Your right. Just came home from work and saw my comment. The only thing I can say to my defense is that it was to early and to little caffeine. Sorry about that. What I meant was if you by any chance have forwarding enabled you need to set accept_ra=2 to override the kernel not to discard RA. Cheers, -- /bengan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bengt Gördén wrote:
On 2019-03-28 08:04, Per Jessen wrote:
Can you elaborate - surely I want accept_ra to be on?
Your right. Just came home from work and saw my comment. The only thing I can say to my defense is that it was to early and to little caffeine. Sorry about that.
No worries :-)
What I meant was if you by any chance have forwarding enabled you need to set accept_ra=2 to override the kernel not to discard RA.
Yeah, I did see something about that, but there's no forwarding. Well, I can't think of any reason why a route should suddenly be lost. I'm now monitoring both, maybe I'll at least get some evidence (that I'm not going crazy). -- Per Jessen, Zürich (3.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 03/29/2019 02:18 AM, Per Jessen wrote:
maybe I'll at least get some evidence (that I'm not going crazy).
There's plenty that says otherwise! ;-)
Hahaha, nice one James! Well, last night at 19:10 and 19:07, the nanopi boards both lost their default ipv6 route. When my monitoring script noticed this (it checks every 5 minutes), it started a tcpdump: tcpdump -c5 -s0 -w /tmp/ip6ra.cap -i wlan0 ip6[40]==133 or ip6[40]==134 "capture 5 packets with IPv6 router advertisement or solicitation". Both tcpdumps are still running, which I have to interpret as "no RAs have been seen since last night 19:10. I have checked radvd, it is sending RAs, I have also checked other machines, they see RAs. The nanopis are on wlan, but other machines on the same wlan are receiving RAs. I have tried to find a way to trigger a router solicitation manually (for testing it), but I haven't found one. Looking at RAs being sent (my radvd doesn't use multicast), I don't see any RAs going out to the nanopis, whereas other machines are fine. Any reason why radvd would stop sending RAs to certain addresses?? 2nd pair of eyes, a whack with the cluebat, even cheaky comments - all very welcome. -- Per Jessen, Zürich (8.0°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Looking at RAs being sent (my radvd doesn't use multicast), I don't see any RAs going out to the nanopis, whereas other machines are fine. Any reason why radvd would stop sending RAs to certain addresses??
Here is something interesting - I looked up the neighbours: # ip -6 neigh 2001:db8:7f7f:1::1000 dev wlan0 lladdr 00:08:02:58:7f:ac REACHABLE 2001:db8:7f7f:1:ff99::dde5 dev wlan0 lladdr 94:a1:a2:a4:24:46 STALE fe80::202:a5ff:fe3f:7f45 dev wlan0 lladdr 00:02:a5:3f:7f:45 STALE 2001:db8:7f7f:1:221:86ff:fe4f:8ac4 dev wlan0 lladdr 00:21:86:4f:8a:c4 REACHABLE 2001:db8:7f7f:1:ff99::d98d dev wlan0 lladdr 88:25:2c:d4:ec:f5 STALE fe80::1 dev wlan0 lladdr 00:0b:cd:3f:5f:d3 router STALE 2001:db8:7f7f:1:fc8a:1197:7ee0:9a0d dev wlan0 lladdr 00:01:6c:84:9b:86 STALE The default gateway is supposed to be fe80::1, so I thougfht I would try pinging it: nano1:~ # ping6 -I wlan0 fe80::1 PING fe80::1(fe80::1) from fe80::96a1:a2ff:fea3:ba7a%wlan0 wlan0: 56 data bytes 64 bytes from fe80::1%wlan0: icmp_seq=4 ttl=64 time=2161 ms 64 bytes from fe80::1%wlan0: icmp_seq=5 ttl=64 time=1121 ms 64 bytes from fe80::1%wlan0: icmp_seq=6 ttl=64 time=81.3 ms 64 bytes from fe80::1%wlan0: icmp_seq=7 ttl=64 time=8.47 ms 64 bytes from fe80::1%wlan0: icmp_seq=8 ttl=64 time=2.91 ms After that my default rouite has reappeared: nano1:~ # ip -6 route show 2001:db8:7f7f:1::/64 dev wlan0 proto kernel metric 256 expires 86389sec pref medium fe80::/64 dev wlan0 proto kernel metric 256 pref medium default via fe80::1 dev wlan0 proto ra metric 1024 expires 1789sec hoplimit 64 pref medium So, I pinged the router which somehow made it wake up and start sending RAs to 'nano1'. I still have a 'nano2' in this weird state - now I'm wondering what I might investigate on the router side? -- Per Jessen, Zürich (15.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/04/2019 16.06, Per Jessen wrote:
Per Jessen wrote:
Looking at RAs being sent (my radvd doesn't use multicast), I don't see any RAs going out to the nanopis, whereas other machines are fine. Any reason why radvd would stop sending RAs to certain addresses??
Here is something interesting -
I looked up the neighbours:
# ip -6 neigh 2001:db8:7f7f:1::1000 dev wlan0 lladdr 00:08:02:58:7f:ac REACHABLE 2001:db8:7f7f:1:ff99::dde5 dev wlan0 lladdr 94:a1:a2:a4:24:46 STALE fe80::202:a5ff:fe3f:7f45 dev wlan0 lladdr 00:02:a5:3f:7f:45 STALE 2001:db8:7f7f:1:221:86ff:fe4f:8ac4 dev wlan0 lladdr 00:21:86:4f:8a:c4 REACHABLE 2001:db8:7f7f:1:ff99::d98d dev wlan0 lladdr 88:25:2c:d4:ec:f5 STALE fe80::1 dev wlan0 lladdr 00:0b:cd:3f:5f:d3 router STALE 2001:db8:7f7f:1:fc8a:1197:7ee0:9a0d dev wlan0 lladdr 00:01:6c:84:9b:86 STALE
The default gateway is supposed to be fe80::1, so I thougfht I would try pinging it:
nano1:~ # ping6 -I wlan0 fe80::1
Why fe80, is that not a hardware address? I don't know if that is related or not, if it is normal or not. My router doesn't have an external IPv6 address, so I can't even test.
PING fe80::1(fe80::1) from fe80::96a1:a2ff:fea3:ba7a%wlan0 wlan0: 56 data bytes 64 bytes from fe80::1%wlan0: icmp_seq=4 ttl=64 time=2161 ms 64 bytes from fe80::1%wlan0: icmp_seq=5 ttl=64 time=1121 ms 64 bytes from fe80::1%wlan0: icmp_seq=6 ttl=64 time=81.3 ms 64 bytes from fe80::1%wlan0: icmp_seq=7 ttl=64 time=8.47 ms 64 bytes from fe80::1%wlan0: icmp_seq=8 ttl=64 time=2.91 ms
After that my default rouite has reappeared:
nano1:~ # ip -6 route show 2001:db8:7f7f:1::/64 dev wlan0 proto kernel metric 256 expires 86389sec pref medium fe80::/64 dev wlan0 proto kernel metric 256 pref medium default via fe80::1 dev wlan0 proto ra metric 1024 expires 1789sec hoplimit 64 pref medium
So, I pinged the router which somehow made it wake up and start sending RAs to 'nano1'.
You pinged from the nano, or from other?
I still have a 'nano2' in this weird state - now I'm wondering what I might investigate on the router side?
Reboot it? You know that my router has a tendency to freeze, and that I wrote a pascal program to ping it every minute to check. If the ping fails for a minute or so, I reboot the router via a power strip with an ethernet connection. Ie, a DIY router watchdog. Recently, the power strip's ethernet has failed completely, my watchdog has died :'-( If the reboot works for you, maybe you need another watchdog :-p -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
On 03/04/2019 16.06, Per Jessen wrote:
Per Jessen wrote:
Looking at RAs being sent (my radvd doesn't use multicast), I don't see any RAs going out to the nanopis, whereas other machines are fine. Any reason why radvd would stop sending RAs to certain addresses??
Here is something interesting -
I looked up the neighbours:
# ip -6 neigh 2001:db8:7f7f:1::1000 dev wlan0 lladdr 00:08:02:58:7f:ac REACHABLE 2001:db8:7f7f:1:ff99::dde5 dev wlan0 lladdr 94:a1:a2:a4:24:46 STALE fe80::202:a5ff:fe3f:7f45 dev wlan0 lladdr 00:02:a5:3f:7f:45 STALE 2001:db8:7f7f:1:221:86ff:fe4f:8ac4 dev wlan0 lladdr 00:21:86:4f:8a:c4 REACHABLE 2001:db8:7f7f:1:ff99::d98d dev wlan0 lladdr 88:25:2c:d4:ec:f5 STALE fe80::1 dev wlan0 lladdr 00:0b:cd:3f:5f:d3 router STALE 2001:db8:7f7f:1:fc8a:1197:7ee0:9a0d dev wlan0 lladdr 00:01:6c:84:9b:86 STALE
The default gateway is supposed to be fe80::1, so I thougfht I would try pinging it:
nano1:~ # ping6 -I wlan0 fe80::1
Why fe80, is that not a hardware address?
No, that's just link-local.
So, I pinged the router which somehow made it wake up and start sending RAs to 'nano1'.
You pinged from the nano, or from other?
From the nano.
I still have a 'nano2' in this weird state - now I'm wondering what I might investigate on the router side?
Reboot it?
Investigate(!) - the router is obviously working fine. All our office and datacentre traffic passes thru it. -- Per Jessen, Zürich (5.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/04/2019 23.56, Per Jessen wrote:
Carlos E. R. wrote:
On 03/04/2019 16.06, Per Jessen wrote:
Per Jessen wrote:
Looking at RAs being sent (my radvd doesn't use multicast), I don't see any RAs going out to the nanopis, whereas other machines are fine. Any reason why radvd would stop sending RAs to certain addresses??
Here is something interesting -
I looked up the neighbours:
# ip -6 neigh 2001:db8:7f7f:1::1000 dev wlan0 lladdr 00:08:02:58:7f:ac REACHABLE 2001:db8:7f7f:1:ff99::dde5 dev wlan0 lladdr 94:a1:a2:a4:24:46 STALE fe80::202:a5ff:fe3f:7f45 dev wlan0 lladdr 00:02:a5:3f:7f:45 STALE 2001:db8:7f7f:1:221:86ff:fe4f:8ac4 dev wlan0 lladdr 00:21:86:4f:8a:c4 REACHABLE 2001:db8:7f7f:1:ff99::d98d dev wlan0 lladdr 88:25:2c:d4:ec:f5 STALE fe80::1 dev wlan0 lladdr 00:0b:cd:3f:5f:d3 router STALE 2001:db8:7f7f:1:fc8a:1197:7ee0:9a0d dev wlan0 lladdr 00:01:6c:84:9b:86 STALE
The default gateway is supposed to be fe80::1, so I thougfht I would try pinging it:
nano1:~ # ping6 -I wlan0 fe80::1
Why fe80, is that not a hardware address?
No, that's just link-local.
Ok, but the numbers are tied to the hardware. To the MAC. It is not an address you define. And does not work on firefox, for instance.
So, I pinged the router which somehow made it wake up and start sending RAs to 'nano1'.
You pinged from the nano, or from other?
From the nano.
Ah, so the router found out the nano existed.
I still have a 'nano2' in this weird state - now I'm wondering what I might investigate on the router side?
Reboot it?
Investigate(!) - the router is obviously working fine. All our office and datacentre traffic passes thru it.
If rebooting the router cures the issue for now, that's another bit for the investigation :-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 04/03/2019 06:13 PM, Carlos E. R. wrote:
Ok, but the numbers are tied to the hardware. To the MAC. It is not an address you define. And does not work on firefox, for instance.
It is possible to change it. For example, with my pfSense router, the gateway address is fe80::1:1. However, MAC addresses are commonly used to form the link local address. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2019 03.18, James Knott wrote:
On 04/03/2019 06:13 PM, Carlos E. R. wrote:
Ok, but the numbers are tied to the hardware. To the MAC. It is not an address you define. And does not work on firefox, for instance.
It is possible to change it. For example, with my pfSense router, the gateway address is fe80::1:1. However, MAC addresses are commonly used to form the link local address.
Why use a link-local address on the router or anywhere, if Firefox refuses to work with them? They are problematic. My printer uses one, I can not assign another. It is not reachable over IPv6 because of that. A decade old bug. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
On 04/04/2019 03.18, James Knott wrote:
On 04/03/2019 06:13 PM, Carlos E. R. wrote:
Ok, but the numbers are tied to the hardware. To the MAC. It is not an address you define. And does not work on firefox, for instance.
It is possible to change it. For example, with my pfSense router, the gateway address is fe80::1:1. However, MAC addresses are commonly used to form the link local address.
Why use a link-local address on the router or anywhere, if Firefox refuses to work with them? They are problematic.
Not at all. They are _not_ meant to be used by humans. Every IPv6 device needs a link local address.
My printer uses one, I can not assign another. It is not reachable over IPv6 because of that. A decade old bug.
Your printer needs the link-local address. You probably just need an IPv6 router or dhcpv6 on your network. -- Per Jessen, Zürich (2.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2019 17.35, Per Jessen wrote:
Carlos E. R. wrote:
On 04/04/2019 03.18, James Knott wrote:
On 04/03/2019 06:13 PM, Carlos E. R. wrote:
Ok, but the numbers are tied to the hardware. To the MAC. It is not an address you define. And does not work on firefox, for instance.
It is possible to change it. For example, with my pfSense router, the gateway address is fe80::1:1. However, MAC addresses are commonly used to form the link local address.
Why use a link-local address on the router or anywhere, if Firefox refuses to work with them? They are problematic.
Not at all. They are _not_ meant to be used by humans. Every IPv6 device needs a link local address.
My printer uses one, I can not assign another. It is not reachable over IPv6 because of that. A decade old bug.
Your printer needs the link-local address. You probably just need an IPv6 router or dhcpv6 on your network.
The printer IPv6 is not configurable whatsoever. Only a link-local address. Firefox refuses to use that address. The syntax was: http:///[FE80::21E:BFF:FE08:4CCB%eth0] but then firefox people intentionally removed that syntax: <https://support.mozilla.org/en-US/questions/1111992> <https://bugzilla.mozilla.org/show_bug.cgi?id=700999> Apparently IoT devices are not reachable because of this. We talked about this a year ago. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
On 04/04/2019 17.35, Per Jessen wrote:
Carlos E. R. wrote:
On 04/04/2019 03.18, James Knott wrote:
On 04/03/2019 06:13 PM, Carlos E. R. wrote:
Ok, but the numbers are tied to the hardware. To the MAC. It is not an address you define. And does not work on firefox, for instance.
It is possible to change it. For example, with my pfSense router, the gateway address is fe80::1:1. However, MAC addresses are commonly used to form the link local address.
Why use a link-local address on the router or anywhere, if Firefox refuses to work with them? They are problematic.
Not at all. They are _not_ meant to be used by humans. Every IPv6 device needs a link local address.
My printer uses one, I can not assign another. It is not reachable over IPv6 because of that. A decade old bug.
Your printer needs the link-local address. You probably just need an IPv6 router or dhcpv6 on your network.
The printer IPv6 is not configurable whatsoever. Only a link-local address.
Put up a radvd dameon to hand out RAs (even just a site-only range), and you'll probably see it working.
http:///[FE80::21E:BFF:FE08:4CCB%eth0] but then firefox people intentionally removed that syntax: <https://support.mozilla.org/en-US/questions/1111992> <https://bugzilla.mozilla.org/show_bug.cgi?id=700999>
Apparently IoT devices are not reachable because of this.
We talked about this a year ago.
Yes I remember. Devices (iot or printers or whatever) on ipv6 will not work unless they are actually on a correctly configured IPv6 network. I guess the nanopis and raspberry pis could be considered IoT device?, and they work. On my electricity monitoring site, the graphs are fetched from the two nanos over ipv6. -- Per Jessen, Zürich (2.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2019 12:18 PM, Carlos E. R. wrote:
The printer IPv6 is not configurable whatsoever. Only a link-local address. Firefox refuses to use that address. The syntax was:
You don't normally configure IPv6 addresses. They're automagically assigned via SLAAC or DHCPv6. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2019 05:08 AM, Carlos E. R. wrote:
It is possible to change it. For example, with my pfSense router, the gateway address is fe80::1:1. However, MAC addresses are commonly used to form the link local address. Why use a link-local address on the router or anywhere, if Firefox refuses to work with them? They are problematic.
You'll have to ask the Firefox people about that. It used to work. Normally, you'd have a global or local address, which would work with Firefox. Does your printer not get that type of address? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2019 23.18, James Knott wrote:
On 04/04/2019 05:08 AM, Carlos E. R. wrote:
It is possible to change it. For example, with my pfSense router, the gateway address is fe80::1:1. However, MAC addresses are commonly used to form the link local address. Why use a link-local address on the router or anywhere, if Firefox refuses to work with them? They are problematic.
You'll have to ask the Firefox people about that. It used to work.
There is a bugzilla on firefox site already. Eight years old. They intentionally removed the functionality, because the syntax "http:///[FE80::21E:BFF:FE08:4CCB%eth0]" has a security problem when parsing the "%" symbol if I recall correctly. Eight years later they still have not settled on an alternative. If you want to reach the configuration page of a device on IPv6, which means using its link-local address, you have to use an old version of Firefox, which some people keep for that purpose alone (version 6, I think).
Normally, you'd have a global or local address, which would work with Firefox. Does your printer not get that type of address?
Not manually, as I do with the IPv4 address. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
On 03/04/2019 23.56, Per Jessen wrote:
Carlos E. R. wrote:
On 03/04/2019 16.06, Per Jessen wrote:
Per Jessen wrote:
Looking at RAs being sent (my radvd doesn't use multicast), I don't see any RAs going out to the nanopis, whereas other machines are fine. Any reason why radvd would stop sending RAs to certain addresses??
Here is something interesting -
I looked up the neighbours:
# ip -6 neigh 2001:db8:7f7f:1::1000 dev wlan0 lladdr 00:08:02:58:7f:ac REACHABLE 2001:db8:7f7f:1:ff99::dde5 dev wlan0 lladdr 94:a1:a2:a4:24:46 STALE fe80::202:a5ff:fe3f:7f45 dev wlan0 lladdr 00:02:a5:3f:7f:45 STALE 2001:db8:7f7f:1:221:86ff:fe4f:8ac4 dev wlan0 lladdr 00:21:86:4f:8a:c4 REACHABLE 2001:db8:7f7f:1:ff99::d98d dev wlan0 lladdr 88:25:2c:d4:ec:f5 STALE fe80::1 dev wlan0 lladdr 00:0b:cd:3f:5f:d3 router STALE 2001:db8:7f7f:1:fc8a:1197:7ee0:9a0d dev wlan0 lladdr 00:01:6c:84:9b:86 STALE
The default gateway is supposed to be fe80::1, so I thougfht I would try pinging it:
nano1:~ # ping6 -I wlan0 fe80::1
Why fe80, is that not a hardware address?
No, that's just link-local.
Ok, but the numbers are tied to the hardware. To the MAC. It is not an address you define.
Yes and no. By default, each interface is given a link-local address derived from the MAC, but you can also defined/add your own. As in this case - fe80::1.
So, I pinged the router which somehow made it wake up and start sending RAs to 'nano1'.
You pinged from the nano, or from other?
From the nano.
Ah, so the router found out the nano existed.
It already knew - the setup has been working for days, then suddenly the router advertisements stop being sent to the two nanos. Rebooting a nano makes it work again. -- Per Jessen, Zürich (3.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/03/2019 02:45 PM, Carlos E. R. wrote:
nano1:~ # ping6 -I wlan0 fe80::1 Why fe80, is that not a hardware address?
No, it's a link local address, but part of it is usually based on the MAC address. Link local addresses are commonly used for routing. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2019 03.16, James Knott wrote:
On 04/03/2019 02:45 PM, Carlos E. R. wrote:
nano1:~ # ping6 -I wlan0 fe80::1 Why fe80, is that not a hardware address?
No, it's a link local address, but part of it is usually based on the MAC address. Link local addresses are commonly used for routing.
I mean that it is not an address me or my router assigns to the devices, they get those automatically, they invent them, whatever.
ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.14 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fc00::14 prefixlen 64 scopeid 0x0<global> inet6 fe80::221:85ff:fe16:2d0b prefixlen 64 scopeid 0x20<link> ether 00:21:85:16:2d:0b txqueuelen 1000 (Ethernet)
The inet6 address gets part of the MAC to invent the numbers. The MAC is the hardware address (yes, I know I can change it), so the fe80:: address to me it is also a hardware related address. Even if it can be reprogrammed. The devices have those fe80:: addresses automatically, independent of where they are connected. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 04/04/2019 05:05 AM, Carlos E. R. wrote:
The inet6 address gets part of the MAC to invent the numbers
Actually, it gets all 48 bits of the MAC address, inserts fffe in the middle and inverts bit 2, to form the host 64 bits. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
So, I pinged the router which somehow made it wake up and start sending RAs to 'nano1'. I still have a 'nano2' in this weird state - now I'm wondering what I might investigate on the router side?
Well, this is also interesting - on the main router: # ip -6 neigh | egrep '2446|ba7a|39b0' fe80::12d0:7aff:fef6:39b0 dev eth0 lladdr 10:d0:7a:f6:39:b0 STALE fe80::96a1:a2ff:fea4:2446 dev eth0 FAILED fe80::96a1:a2ff:fea3:ba7a dev eth0 FAILED Those are the three nanopis, all on wifi. There is the reason the latter two (nano1 and nano2) are not getting any RAs - the router can't talk to them. nano3 has been running for a couple of days, I'm waiting for it to be failed too. I don't understand that FAILED state. From my desktop, I'm logged in to both nano1 and nano2 over ssh, for days. It works fine. The only thing that set those two nanos apart is that they are connected over another wifi AP (we have three), a Netgear WG602v3. I don't understand why there should be an issue with link-local addresses. -- Per Jessen, Zürich (2.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 4/4/19 8:50 AM, Per Jessen wrote:
Per Jessen wrote:
So, I pinged the router which somehow made it wake up and start sending RAs to 'nano1'. I still have a 'nano2' in this weird state - now I'm wondering what I might investigate on the router side?
Well, this is also interesting - on the main router:
# ip -6 neigh | egrep '2446|ba7a|39b0' fe80::12d0:7aff:fef6:39b0 dev eth0 lladdr 10:d0:7a:f6:39:b0 STALE fe80::96a1:a2ff:fea4:2446 dev eth0 FAILED fe80::96a1:a2ff:fea3:ba7a dev eth0 FAILED
It means neighborhood discovery failed. It tried probing the address and received no response. Is there some firewall running on the nanos? neighborhood discovery is happening over ICMPv6 so if that is blocked, it will cause problems..
I don't understand that FAILED state. From my desktop, I'm logged in to both nano1 and nano2 over ssh, for days. It works fine.
hmmm... I'm assuming you are not using link local address for this?
The only thing that set those two nanos apart is that they are connected over another wifi AP (we have three), a Netgear WG602v3. I don't understand why there should be an issue with link-local addresses.
There is no issue with link-local address as that's already on the IP layer. It could also be a link-layer issue, so that the wlan connection is down somehow and neighbourhood discovery fails? - Adam -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Adam Majer wrote:
On 4/4/19 8:50 AM, Per Jessen wrote:
Per Jessen wrote:
So, I pinged the router which somehow made it wake up and start sending RAs to 'nano1'. I still have a 'nano2' in this weird state - now I'm wondering what I might investigate on the router side?
Well, this is also interesting - on the main router:
# ip -6 neigh | egrep '2446|ba7a|39b0' fe80::12d0:7aff:fef6:39b0 dev eth0 lladdr 10:d0:7a:f6:39:b0 STALE fe80::96a1:a2ff:fea4:2446 dev eth0 FAILED fe80::96a1:a2ff:fea3:ba7a dev eth0 FAILED
It means neighborhood discovery failed. It tried probing the address and received no response.
Right. I also see the state go INCOMPLETE, then back to FAILED every now and then.
Is there some firewall running on the nanos? neighborhood discovery is happening over ICMPv6 so if that is blocked, it will cause problems..
There's no firewall on either, and neighbour sol/adv works fine: 13:12:17.255717 IP6 fe80::96a1:a2ff:fea3:ba7a > 2001:db8:4c68:1::1000: ICMP6, neighbor solicitation, who has 2a03:7520:4c68:1::1000, length 32 13:12:17.265141 IP6 2001:db8:4c68:1::1000 > fe80::96a1:a2ff:fea3:ba7a: ICMP6, neighbor advertisement, tgt is 2a03:7520:4c68:1::1000, length 24 13:12:22.375707 IP6 fe80::96a1:a2ff:fea3:ba7a > 2001:db8:4c68:1:221:86ff:fe4f:8ac4: ICMP6, neighbor solicitation, who has 2a03:7520:4c68:1:221:86ff:fe4f:8ac4, length 32 13:12:22.379097 IP6 2001:db8:4c68:1:221:86ff:fe4f:8ac4 > fe80::96a1:a2ff:fea3:ba7a: ICMP6, neighbor advertisement, tgt is 2a03:7520:4c68:1:221:86ff:fe4f:8ac4, length 24 (roughly every 50sec). First solicitation is for the nameserver at 1::1000, the second one is my desktop. Both nanos show the same traffic.
I don't understand that FAILED state. From my desktop, I'm logged in to both nano1 and nano2 over ssh, for days. It works fine.
hmmm... I'm assuming you are not using link local address for this?
Right, both nanos have dynamic addresses from a pool.
The only thing that set those two nanos apart is that they are connected over another wifi AP (we have three), a Netgear WG602v3. I don't understand why there should be an issue with link-local addresses.
There is no issue with link-local address as that's already on the IP layer. It could also be a link-layer issue, so that the wlan connection is down somehow and neighbourhood discovery fails?
It is a slightly poor wifi connection, but easily good enough for an ssh session. Both nanos also have a thttpd running, serving graphs for a website. (which does not work without the default route). nano1:~ # iwconfig wlan0 wlan0 IEEE 802.11 ESSID:"ENIDAN" Mode:Managed Frequency:2.462 GHz Access Point: 00:14:6C:E0:71:FB Bit Rate=54 Mb/s Tx-Power=31 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=55/70 Signal level=-55 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:1 Invalid misc:0 Missed beacon:0 nano2:~ # iwconfig wlan0 wlan0 IEEE 802.11 ESSID:"ENIDAN" Mode:Managed Frequency:2.462 GHz Access Point: 00:14:6C:E0:71:FB Bit Rate=54 Mb/s Tx-Power=31 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=53/70 Signal level=-57 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 -- Per Jessen, Zürich (2.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2019 08.50, Per Jessen wrote:
Per Jessen wrote:
So, I pinged the router which somehow made it wake up and start sending RAs to 'nano1'. I still have a 'nano2' in this weird state - now I'm wondering what I might investigate on the router side?
Well, this is also interesting - on the main router:
# ip -6 neigh | egrep '2446|ba7a|39b0' fe80::12d0:7aff:fef6:39b0 dev eth0 lladdr 10:d0:7a:f6:39:b0 STALE fe80::96a1:a2ff:fea4:2446 dev eth0 FAILED fe80::96a1:a2ff:fea3:ba7a dev eth0 FAILED
Those are the three nanopis, all on wifi. There is the reason the latter two (nano1 and nano2) are not getting any RAs - the router can't talk to them. nano3 has been running for a couple of days, I'm waiting for it to be failed too.
I don't understand that FAILED state. From my desktop, I'm logged in to both nano1 and nano2 over ssh, for days. It works fine.
The only thing that set those two nanos apart is that they are connected over another wifi AP (we have three), a Netgear WG602v3. I don't understand why there should be an issue with link-local addresses.
Well, that's what I'm trying to say, that link-local addresses have issues. I call them hardware related addresses because the devices have those addresses per se, no need to assign them. You say they are not hardware addresses. Well, whatever, in my very limited experience they cause issues. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
Well, this is also interesting - on the main router:
# ip -6 neigh | egrep '2446|ba7a|39b0' fe80::12d0:7aff:fef6:39b0 dev eth0 lladdr 10:d0:7a:f6:39:b0 STALE fe80::96a1:a2ff:fea4:2446 dev eth0 FAILED fe80::96a1:a2ff:fea3:ba7a dev eth0 FAILED
Those are the three nanopis, all on wifi. There is the reason the latter two (nano1 and nano2) are not getting any RAs - the router can't talk to them. nano3 has been running for a couple of days, I'm waiting for it to be failed too.
I don't understand that FAILED state. From my desktop, I'm logged in to both nano1 and nano2 over ssh, for days. It works fine.
The only thing that set those two nanos apart is that they are connected over another wifi AP (we have three), a Netgear WG602v3. I don't understand why there should be an issue with link-local addresses.
Well, that's what I'm trying to say, that link-local addresses have issues.
Carlos, that is just plainly wrong. They are required for IPv6 to work at all. They don't have "issues". The problem I'm having (finally narrowed down) is why the router and other machines do not receive neighbour advertisements from those two addresses (of the nanopis). -- Per Jessen, Zürich (2.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/04/2019 11:51 AM, Carlos E. R. wrote:
Well, that's what I'm trying to say, that link-local addresses have issues. I call them hardware related addresses because the devices have those addresses per se, no need to assign them. You say they are not hardware addresses. Well, whatever, in my very limited experience they cause issues.
They are not hardware addresses, though they are often derived from them. The MAC addresses are hardware addresses and work at layer 2, not 3, where IP works. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
I'm running Leap15 on a couple of small NanoPi Neo Air. The network is configured with dhcp and radvd, the latter also hands out the default route. Today I noticed that both had lost their default routes:
Sofar thanks to everyone who has chipped in. The default route not being advertised (the original $SUBJ) is caused by the nanopis not getting the neighbour solicitations from the router and therefore not sending any advertisements in response. As discussed yesterday, neighbour status for both nanopis is FAILED. They also show failed on other machines, e.g. my desktop. 1) icmp6 in general works fine, between nanopi and router. I can see the nanopi soliciting my desktop, the dns server or the router, and I see neighbor advertisements going back. 2) I know the router sends neighbour solicitations to the nanopis, tcpdump shows them going out. I see them going directly to the link-local address as well as to the ff02::1 address. 3) tcpdump on the nanopis shows no neighbour solicitations coming in. I have a third nanopi, connected over a different wifi access point, this has yet to show any problems, but it's only been running for 3 days. It seems to me the issue has to be with the nanopis (running Leap15) or in the wifi access point? Rebooting a nanopi also restores normal operation, for a while. (this is really the most puzzling). I've now taken an old laptop (last booted up 2013) and put it in the same location as nano1. Sofar it's doing fine. -- Per Jessen, Zürich (8.7°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi, It seems that if you were to either move the "working" third nanopi to the same access point as the other two -- or, failing that, move one of the "problematic" nanopis onto the same wifi access point as the working one, you could eliminate (or confirm) the OS as being the issue. Brendan On 05/04/2019 18:48, Per Jessen wrote:
Per Jessen wrote:
I'm running Leap15 on a couple of small NanoPi Neo Air. The network is configured with dhcp and radvd, the latter also hands out the default route. Today I noticed that both had lost their default routes:
Sofar thanks to everyone who has chipped in.
The default route not being advertised (the original $SUBJ) is caused by the nanopis not getting the neighbour solicitations from the router and therefore not sending any advertisements in response.
As discussed yesterday, neighbour status for both nanopis is FAILED. They also show failed on other machines, e.g. my desktop.
1) icmp6 in general works fine, between nanopi and router. I can see the nanopi soliciting my desktop, the dns server or the router, and I see neighbor advertisements going back.
2) I know the router sends neighbour solicitations to the nanopis, tcpdump shows them going out. I see them going directly to the link-local address as well as to the ff02::1 address.
3) tcpdump on the nanopis shows no neighbour solicitations coming in.
I have a third nanopi, connected over a different wifi access point, this has yet to show any problems, but it's only been running for 3 days.
It seems to me the issue has to be with the nanopis (running Leap15) or in the wifi access point? Rebooting a nanopi also restores normal operation, for a while. (this is really the most puzzling).
I've now taken an old laptop (last booted up 2013) and put it in the same location as nano1. Sofar it's doing fine.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brendan McKenna wrote:
Hi,
It seems that if you were to either move the "working" third nanopi to the same access point as the other two -- or, failing that, move one of the "problematic" nanopis onto the same wifi access point as the working one, you could eliminate (or confirm) the OS as being the issue.
I'll move the third one into the same location as nano2, but the third one does not (yet) have a working wifi, it's only connected on serial. I'm also thinking of swapping the access point to different hardware. -- Per Jessen, Zürich (11.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Brendan McKenna wrote:
Hi,
It seems that if you were to either move the "working" third nanopi to the same access point as the other two -- or, failing that, move one of the "problematic" nanopis onto the same wifi access point as the working one, you could eliminate (or confirm) the OS as being the issue.
I'll move the third one into the same location as nano2, but the third one does not (yet) have a working wifi, it's only connected on serial.
I'll stop annoying everyone with this - if I don't find something useful soon, I'll just add fixed routes to those nanopis. It's just such a really annoying problem. It is supposed to _just_ work. Today I got a 3rd nanopi running Leap15, now in the same location (2 meters away) as nano2 and an IBM laptop. When seen from the router: # ip -6 neigh | egrep '2446|ba7a|39b0|577b' fe80::12d0:7aff:fef6:39b0 dev eth0 lladdr 10:d0:7a:f6:39:b0 STALE (nano3) fe80::96a1:a2ff:fea4:2446 dev eth0 lladdr 94:a1:a2:a4:24:46 STALE (nano2) fe80::214:a4ff:fe76:577b dev eth0 lladdr 00:14:a4:76:57:7b STALE (laptop) fe80::96a1:a2ff:fea3:ba7a dev eth0 FAILED (nano1).
I'm also thinking of swapping the access point to different hardware.
Yesterday I swapped two access points (a Netgear and a Dlink), made no difference except nano2 got confused and I lost the connection :-) In desperation, I also tried out a couple of different wlan aerials, also no difference. Right now, I'm essentially waiting to see if/when nano2 and nano23 will "drop out", and I'd also like to see the laptop drop out. -- Per Jessen, Zürich (13.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
I'll stop annoying everyone with this - if I don't find something useful soon, I'll just add fixed routes to those nanopis. It's just such a really annoying problem. It is supposed to _just_ work.
Today I got a 3rd nanopi running Leap15, now in the same location (2 meters away) as nano2 and an IBM laptop.
Well, the third nanopi 'nano3' was lost after only a couple of days. Yesterday, 'nano2' also dropped out, after 5 days. The IBM laptop continues to work, in virtually the same position as nano3. The three nanos are all running Leap15, but the laptop is too old for that, it's running openSUSE 12.3, 32bit. I have active ssh sessions to nano1 and nano2, but nano3 dropped. I'm thinking of trying out Leap15 on another laptop. Is there really reason to think this problem might be related to the operating system? I'm sure the wifi is not optimal, but it works. I have also tried two different access points, different aerials and I'm getting another access point next week. -- Per Jessen, Zürich (5.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/13/2019 03:08 AM, Per Jessen wrote:
Is there really reason to think this problem might be related to the operating system? I'm sure the wifi is not optimal, but it works. I have also tried two different access points, different aerials and I'm getting another access point next week.
I'm running 15 on both my desktop and notebook computers. No problem at all. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 04/13/2019 03:08 AM, Per Jessen wrote:
Is there really reason to think this problem might be related to the operating system? I'm sure the wifi is not optimal, but it works. I have also tried two different access points, different aerials and I'm getting another access point next week.
I'm running 15 on both my desktop and notebook computers. No problem at all.
Ditto, I'm not suggesting any general issue with Leap15. It is only the three nanopis on this access point that are having this issue. It is just odd that the laptop in the same position has no issue. -- Per Jessen, Zürich (10.3°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 13 Apr 2019 15:55, Per Jessen wrote:
James Knott wrote:
On 04/13/2019 03:08 AM, Per Jessen wrote:
Is there really reason to think this problem might be related to the operating system? I'm sure the wifi is not optimal, but it works. I have also tried two different access points, different aerials and I'm getting another access point next week.
I'm running 15 on both my desktop and notebook computers. No problem at all.
Ditto, I'm not suggesting any general issue with Leap15. It is only the three nanopis on this access point that are having this issue. It is just odd that the laptop in the same position has no issue.
Well, in light of the fact you already tried different AP hardware, and a nearby Laptop with older WiFi hardware works, my suggestion would be: "Incorrect behaviour of the WiFi HW of the NanoPi". Explanation attempt: If the WiFi hw silently drops data packages that should have been forwarded to the CPU (e.g. the IPv6 management packages) and these packages aren't identified as missing by upper layers of the network stack as e.g. TCP packages would, then most of the observed behaviour would be explainable by that. Check for the firmware revision of the NanoPi Wifi hw, maybe there is a known fault, or even a never version available. - Yamaban.
Yamaban wrote:
On Sat, 13 Apr 2019 15:55, Per Jessen wrote:
James Knott wrote:
On 04/13/2019 03:08 AM, Per Jessen wrote:
Is there really reason to think this problem might be related to the operating system? I'm sure the wifi is not optimal, but it works. I have also tried two different access points, different aerials and I'm getting another access point next week.
I'm running 15 on both my desktop and notebook computers. No problem at all.
Ditto, I'm not suggesting any general issue with Leap15. It is only the three nanopis on this access point that are having this issue. It is just odd that the laptop in the same position has no issue.
Well, in light of the fact you already tried different AP hardware, and a nearby Laptop with older WiFi hardware works, my suggestion would be:
"Incorrect behaviour of the WiFi HW of the NanoPi".
I was also slowly working towards that conclusion. I think I'm going to let nano3 run the built-in Ubuntu for a while, to see if that also fails.
Explanation attempt: If the WiFi hw silently drops data packages that should have been forwarded to the CPU (e.g. the IPv6 management packages)
That is what it looks like - the router will issue neighbour solicitations, and this works for a while, but then they stop being seen by the nanos. OTOH, when the nanos issue solicitations, that works fine. -- Per Jessen, Zürich (8.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
05.04.2019 20:48, Per Jessen пишет:
Per Jessen wrote:
I'm running Leap15 on a couple of small NanoPi Neo Air. The network is configured with dhcp and radvd, the latter also hands out the default route. Today I noticed that both had lost their default routes:
Sofar thanks to everyone who has chipped in.
The default route not being advertised (the original $SUBJ) is caused by the nanopis not getting the neighbour solicitations from the router and therefore not sending any advertisements in response.
I do not understand how it is related. RAs are normally multicast by router, and router is no aware of other nodes nor does it need to contact them directly. Is your router configured to send periodical RAs? Do you see them on both sides of network (near router and near clients)? RAs could be unicast as response to explicit router solicitation. Do you see router solicitation coming from nodes in question?
As discussed yesterday, neighbour status for both nanopis is FAILED. They also show failed on other machines, e.g. my desktop.
1) icmp6 in general works fine, between nanopi and router. I can see the nanopi soliciting my desktop, the dns server or the router, and I see neighbor advertisements going back.
2) I know the router sends neighbour solicitations to the nanopis, tcpdump shows them going out. I see them going directly to the link-local address as well as to the ff02::1 address.
3) tcpdump on the nanopis shows no neighbour solicitations coming in.
I have a third nanopi, connected over a different wifi access point, this has yet to show any problems, but it's only been running for 3 days.
It seems to me the issue has to be with the nanopis (running Leap15) or in the wifi access point? Rebooting a nanopi also restores normal operation, for a while. (this is really the most puzzling).
I've now taken an old laptop (last booted up 2013) and put it in the same location as nano1. Sofar it's doing fine.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
05.04.2019 20:48, Per Jessen пишет:
Per Jessen wrote:
I'm running Leap15 on a couple of small NanoPi Neo Air. The network is configured with dhcp and radvd, the latter also hands out the default route. Today I noticed that both had lost their default routes:
Sofar thanks to everyone who has chipped in.
The default route not being advertised (the original $SUBJ) is caused by the nanopis not getting the neighbour solicitations from the router and therefore not sending any advertisements in response.
I do not understand how it is related. RAs are normally multicast by router, and router is no aware of other nodes nor does it need to contact them directly.
I use a clients{} statement in radvd.conf to control which clients get ipv6. I think that means radvd will send RAs to clients individually.
Is your router configured to send periodical RAs?
Yep.
Do you see them on both sides of network (near router and near clients)?
Yes and yes (when it works). In general there is no problem, it works fine on desktops etc, just not on these two arm boards.
RAs could be unicast as response to explicit router solicitation. Do you see router solicitation coming from nodes in question?
No router solicitations, no. Yesterday I rebooted nano2, and it's been working ever since. I see fe80::1 > fe80::96a1:a2ff:fea4:2446: ICMP6, router advertisement, length 152 every few minutes. Previously, it has taken 3-4 days before it stops. -- Per Jessen, Zürich (11.1°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Adam Majer -
Andrei Borzenkov -
Bengt Gördén -
Brendan McKenna -
Carlos E. R. -
Carlos E. R. -
James Knott -
Per Jessen -
Yamaban