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

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

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

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

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)

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/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)

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)

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 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)

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 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

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

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)

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

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

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

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

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.

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