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