Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fd66:66:66:7:c693 IPv6 unaccessble but 2a00:1508:ac6:d000:: works ok #93

Open
1am opened this issue Oct 29, 2018 · 11 comments
Open

fd66:66:66:7:c693 IPv6 unaccessble but 2a00:1508:ac6:d000:: works ok #93

1am opened this issue Oct 29, 2018 · 11 comments

Comments

@1am
Copy link

1am commented Oct 29, 2018

Hello,

I'm trying to figure one thing out and can't wrap my head around it - maybe someone could help me with it.

I create a small mesh network (2-7 devices) and it works fine initially. I connect with my PC to it and can ssh/ping and open LuCi over IPv4 and IPv6 addresses in IPv6 fd66:66:66:7:c693:ff: subnet (which is shown in LuCi under http://thisnode.info/cgi-bin/luci/status/bmx6/Nodes ) and 2a00:1508:ac6:d000:: (which is my option main_ipv6_address '2a00:1508:0a%N1:%N200::/64' in /etc/config/lime).

After around an hour of working the fd66:66:66:7:c693:ff: address become's unavailable and only 2a00:1508:ac6:d000:: works. This only fixes after I reconnect to the Mesh Wifi network from my PC.

I'm totally ok with using main_ipv6_address but LuCi bmx6/nodes shows only addresses from fd66:66:66:7:c693:ff: subnet which makes it very hard for end user to know what is the actual address of specific device (not to mention obtaining it's IPv4 address). Is there a way around this, eg. forcing Luci to show only the 2a00:1508:ac6:d000:: address or how to make fd66:66:66:7:c693:ff: not disappear after a while?

@nicopace
Copy link
Member

nicopace commented Oct 29, 2018 via email

@ilario
Copy link
Member

ilario commented Oct 29, 2018

That's an veryveryvery interesting question, I neither know how to get a 100% working IPv6 from LuCi.

The way I usually use for connecting to nodes is hostname.lan, e.g. for a node with MAC address aa:aa:aa:bb:cc:dd the working address will be lime-bbccdd.lan

@1am
Copy link
Author

1am commented Oct 29, 2018

Thank you for your responses. I'll move my question to the mailing list and fill in the blanks.

@1am 1am closed this as completed Oct 29, 2018
@1am
Copy link
Author

1am commented Oct 31, 2018

Unfortunately there's no response in the mailing list so far.

I don't know what to set up in LuCi or even if it makes any sense to force it to show 2a00:: addresses? That would be perfect to begin with.

When it comes to using the .lan suffix I think they were gone after a while also (together with the fd66: addresses) and the only thing which worked repeatedly is the 2a00.

@ilario
Copy link
Member

ilario commented Oct 31, 2018

When it comes to using the .lan suffix I think they were gone after a while also (together with the fd66: addresses) and the only thing which worked repeatedly is the 2a00.

I'm not sure I got this bit.
Do you mean that the resolving of lime-bbccdd.lan stopped working after a while for IPv6? Does this happen also for IPv4?
Just for understanding, something like:

while true; do host lime-bbccdd.lan; sleep 60; done

Would show good results at first and then start failing after a while?
In this case, can you check that the DNS server direction on your PC didn't change?

This is a serious issue if it's confirmed.

@1am
Copy link
Author

1am commented Oct 31, 2018

I'm attaching a screenshot with log of my pinging 2 nodes, each under fd66: and 2a00: networks + doing host lime-bbccdd.lan on each of them.

Both addresses from fd66: disappear pretty much in the same moment but the rest works ok.
This happens on my Linux machine and I can't reproduce this under OSX which I've launched at the same time so i guess this is good news as there would be no issue and could be the fault of my network card for some reason?

Is there a reliable way to obtain the 2a00: (main_ipv6_address) from all nodes like it is shown in LuCi? This way i could discover the whole network more easily and make sure that the more reliable address is used. I will try to test this on more client hardware to see if this is unique only to my PC or can be replicated on more devices. Not really sure where to look for and why the timeout is so repeatable. The PC doesn't go to any sleep mode and i even disabled display sleep to be sure. It just stops seeing the fd66: subnet in ~30minutes after connecting to mesh network.

I will try to use the host lime-bbccdd.lan approach for now but i'm really curious about what is the source of this behaviour. The hostname might be a little tricky as my application only uses IP addresses and I already have input value validation in place.

tmux_009

@1am
Copy link
Author

1am commented Oct 31, 2018

I think this can be somehow related to systemd-resolved or dhclient behaviour on my linux.

Could it be related to the Grace period over, resuming full feature set (UDP+EDNS0) for DNS server logged by systemd-resolved at 20:25:57 ?

I've trimmed my journal to the interesting part. Around 20:42 is where pings start failing and it's very close to the dhclient lease timeout set at 20:18:59. Maybe you would have ideas? My config is pretty standard, I don't mess with networking beyond what's needed for normal usage.

paź 31 21:27:45 my-PC systemd-resolved[554]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server fe80::a8aa:aaff:fe0d:feaa%3.
paź 31 21:14:44 my-PC systemd-resolved[554]: Using degraded feature set (UDP) for DNS server fe80::a8aa:aaff:fe0d:feaa%3.
paź 31 21:13:36 my-PC nm-dispatcher[25962]: req:1 'dhcp4-change' [wlp3s0]: start running ordered scripts...
paź 31 21:13:36 my-PC nm-dispatcher[25962]: req:1 'dhcp4-change' [wlp3s0]: new request (1 scripts)
paź 31 21:13:36 my-PC systemd[1]: Started Network Manager Script Dispatcher Service.
...
paź 31 20:47:02 my-PC dhclient[24703]: bound to 10.13.152.240 -- renewal in 1593 seconds.
paź 31 20:47:02 my-PC dbus-daemon[857]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.11' (uid=0 pid=908 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
paź 31 20:47:02 my-PC NetworkManager[908]: <info>  [1541015222.9392] dhcp4 (wlp3s0): state changed bound -> bound
paź 31 20:47:02 my-PC NetworkManager[908]: <info>  [1541015222.9391] dhcp4 (wlp3s0):   domain name 'lan'
paź 31 20:47:02 my-PC NetworkManager[908]: <info>  [1541015222.9391] dhcp4 (wlp3s0):   nameserver '10.13.0.1'
paź 31 20:47:02 my-PC NetworkManager[908]: <info>  [1541015222.9391] dhcp4 (wlp3s0):   hostname 'my-PC'
paź 31 20:47:02 my-PC NetworkManager[908]: <info>  [1541015222.9390] dhcp4 (wlp3s0):   lease time 3600
paź 31 20:47:02 my-PC NetworkManager[908]: <info>  [1541015222.9390] dhcp4 (wlp3s0):   gateway 10.13.0.1
paź 31 20:47:02 my-PC NetworkManager[908]: <info>  [1541015222.9389] dhcp4 (wlp3s0):   plen 16 (255.255.0.0)
paź 31 20:47:02 my-PC NetworkManager[908]: <info>  [1541015222.9389] dhcp4 (wlp3s0):   address 10.13.152.240
paź 31 20:47:02 my-PC dhclient[24703]: DHCPACK of 10.13.152.240 from 10.13.204.122
paź 31 20:47:02 my-PC dhclient[24703]: DHCPREQUEST of 10.13.152.240 on wlp3s0 to 10.13.0.1 port 67 (xid=0xa9f1a0)
paź 31 20:44:09 my-PC systemd-resolved[554]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
paź 31 20:44:09 my-PC systemd-resolved[554]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
paź 31 20:42:52 my-PC systemd-resolved[554]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
paź 31 20:42:52 my-PC systemd-resolved[554]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
paź 31 20:25:57 my-PC systemd-resolved[554]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server fe80::a8aa:aaff:fe0d:feaa%3.
paź 31 20:19:05 my-PC avahi-daemon[818]: Server startup complete. Host name is my-PC-2.local. Local service cookie is 267633760.
paź 31 20:19:04 my-PC systemd-resolved[554]: Using degraded feature set (UDP) for DNS server fe80::a8aa:aaff:fe0d:feaa%3.
paź 31 20:19:04 my-PC systemd-resolved[554]: Using degraded feature set (UDP) for DNS server 10.13.0.1.
...
paź 31 20:19:03 my-PC avahi-daemon[818]: Host name conflict, retrying with my-PC-2
...
paź 31 20:19:03 my-PC avahi-daemon[818]: Registering new address record for 2a00:1508:a0d:fe00:c4ef:bc13:c9fb:d505 on wlp3s0.*.
paź 31 20:19:03 my-PC avahi-daemon[818]: Joining mDNS multicast group on interface wlp3s0.IPv6 with address 2a00:1508:a0d:fe00:c4ef:bc13:c9fb:d505.
paź 31 20:19:03 my-PC avahi-daemon[818]: Leaving mDNS multicast group on interface wlp3s0.IPv6 with address fe80::62ab:6747:6a36:dfe9.
paź 31 20:19:02 my-PC NetworkManager[908]: <info>  [1541013542.2932] policy: set 'LibreMesh.org 1' (wlp3s0) as default for IPv6 routing and DNS
paź 31 20:19:01 my-PC avahi-daemon[818]: Registering new address record for fe80::62ab:6747:6a36:dfe9 on wlp3s0.*.
paź 31 20:19:01 my-PC avahi-daemon[818]: New relevant interface wlp3s0.IPv6 for mDNS.
paź 31 20:19:01 my-PC avahi-daemon[818]: Joining mDNS multicast group on interface wlp3s0.IPv6 with address fe80::62ab:6747:6a36:dfe9.
paź 31 20:19:00 my-PC wpa_supplicant[909]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-23 noise=9999 txrate=1000
...
paź 31 20:18:59 my-PC dhclient[24703]: bound to 10.13.152.240 -- renewal in 1683 seconds.
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7762] device (wlp3s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7724] device (wlp3s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
paź 31 20:18:59 my-PC avahi-daemon[818]: Registering new address record for 10.13.152.240 on wlp3s0.IPv4.
paź 31 20:18:59 my-PC avahi-daemon[818]: New relevant interface wlp3s0.IPv4 for mDNS.
paź 31 20:18:59 my-PC avahi-daemon[818]: Joining mDNS multicast group on interface wlp3s0.IPv4 with address 10.13.152.240.
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7644] dhcp4 (wlp3s0): state changed unknown -> bound
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7644] dhcp4 (wlp3s0):   domain name 'lan'
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7644] dhcp4 (wlp3s0):   nameserver '10.13.0.1'
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7643] dhcp4 (wlp3s0):   hostname 'my-PC'
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7643] dhcp4 (wlp3s0):   lease time 3600
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7643] dhcp4 (wlp3s0):   gateway 10.13.0.1
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7642] dhcp4 (wlp3s0):   plen 16 (255.255.0.0)
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7642] dhcp4 (wlp3s0):   address 10.13.152.240
paź 31 20:18:59 my-PC dhclient[24703]: DHCPACK of 10.13.152.240 from 10.13.0.1
paź 31 20:18:59 my-PC dhclient[24703]: DHCPREQUEST of 10.13.152.240 on wlp3s0 to 255.255.255.255 port 67 (xid=0xa9f1a0)
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7073] dhcp4 (wlp3s0): dhclient started with pid 24703
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7031] dhcp4 (wlp3s0): activation: beginning transaction (timeout in 45 seconds)
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7022] device (wlp3s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7012] device (wlp3s0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful.  Connected to wireless network 'LibreMesh.org'.
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.7008] device (wlp3s0): supplicant interface state: associating -> completed
paź 31 20:18:59 my-PC kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready
paź 31 20:18:59 my-PC kernel: wlp3s0: associated
paź 31 20:18:59 my-PC wpa_supplicant[909]: wlp3s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
paź 31 20:18:59 my-PC wpa_supplicant[909]: wlp3s0: CTRL-EVENT-CONNECTED - Connection to c6:93:00:0c:cc:79 completed [id=0 id_str=]
paź 31 20:18:59 my-PC wpa_supplicant[909]: wlp3s0: Associated with c6:93:00:0c:cc:79
paź 31 20:18:59 my-PC kernel: wlp3s0: RX AssocResp from c6:93:00:0c:cc:79 (capab=0x421 status=0 aid=1)
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.6898] device (wlp3s0): supplicant interface state: authenticating -> associating
paź 31 20:18:59 my-PC kernel: wlp3s0: associate with c6:93:00:0c:cc:79 (try 1/3)
paź 31 20:18:59 my-PC kernel: wlp3s0: authenticated
paź 31 20:18:59 my-PC wpa_supplicant[909]: wlp3s0: Trying to associate with c6:93:00:0c:cc:79 (SSID='LibreMesh.org' freq=2462 MHz)
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.6818] device (wlp3s0): supplicant interface state: disconnected -> authenticating
paź 31 20:18:59 my-PC kernel: wlp3s0: send auth to c6:93:00:0c:cc:79 (try 1/3)
paź 31 20:18:59 my-PC kernel: wlp3s0: authenticate with c6:93:00:0c:cc:79
paź 31 20:18:59 my-PC wpa_supplicant[909]: wlp3s0: SME: Trying to authenticate with c6:93:00:0c:cc:79 (SSID='LibreMesh.org' freq=2462 MHz)
paź 31 20:18:59 my-PC nm-dispatcher[24649]: req:3 'down' [wlp3s0]: start running ordered scripts...
paź 31 20:18:59 my-PC nm-dispatcher[24649]: req:3 'down' [wlp3s0]: new request (1 scripts)
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2601] Config: added 'key_mgmt' value 'NONE'
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2600] Config: added 'bgscan' value 'simple:30:-80:86400'
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2600] Config: added 'scan_ssid' value '1'
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2600] Config: added 'ssid' value 'LibreMesh.org'
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2599] device (wlp3s0): Activation: (wifi) connection 'LibreMesh.org 1' requires no security.  No secrets needed.
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2591] device (wlp3s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2584] manager: NetworkManager state is now CONNECTING
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2581] device (wlp3s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2555] device (wlp3s0): Activation: starting connection 'LibreMesh.org 1' (9e3b30dd-1274-416a-9f7d-1011298a7bf7)
paź 31 20:18:59 my-PC kernel: IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2523] device (wlp3s0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed')
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2518] audit: op="connection-activate" uuid="9e3b30dd-1274-416a-9f7d-1011298a7bf7" name="LibreMesh.org 1" pid=2695 uid=1000 result="success"
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2515] manager: NetworkManager state is now CONNECTED_LOCAL
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2513] device (wlp3s0): state change: config -> deactivating (reason 'new-activation', sys-iface-state: 'managed')
paź 31 20:18:59 my-PC NetworkManager[908]: <info>  [1541013539.2512] device (wlp3s0): disconnecting for new activation request.
paź 31 20:18:55 my-PC NetworkManager[908]: <info>  [1541013535.5408] Config: added 'key_mgmt' value 'NONE'
paź 31 20:18:55 my-PC NetworkManager[908]: <info>  [1541013535.5406] Config: added 'bgscan' value 'simple:30:-80:86400'
paź 31 20:18:55 my-PC NetworkManager[908]: <info>  [1541013535.5404] Config: added 'scan_ssid' value '1'
paź 31 20:18:55 my-PC NetworkManager[908]: <info>  [1541013535.5402] Config: added 'ssid' value 'LiMe'
paź 31 20:18:55 my-PC NetworkManager[908]: <info>  [1541013535.5396] device (wlp3s0): Activation: (wifi) connection 'LiMe' requires no security.  No secrets needed.
paź 31 20:18:55 my-PC nm-dispatcher[24649]: req:2 'down' [wlp3s0]: start running ordered scripts...
paź 31 20:18:55 my-PC nm-dispatcher[24649]: req:2 'down' [wlp3s0]: new request (1 scripts)
paź 31 20:18:55 my-PC NetworkManager[908]: <info>  [1541013535.5325] device (wlp3s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
paź 31 20:18:55 my-PC nm-dispatcher[24649]: req:1 'connectivity-change': start running ordered scripts...
paź 31 20:18:55 my-PC nm-dispatcher[24649]: req:1 'connectivity-change': new request (1 scripts)
paź 31 20:18:55 my-PC NetworkManager[908]: <info>  [1541013535.5269] manager: NetworkManager state is now CONNECTING
paź 31 20:18:55 my-PC systemd[1]: Started Network Manager Script Dispatcher Service.
paź 31 20:18:55 my-PC dbus-daemon[857]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
paź 31 20:18:55 my-PC NetworkManager[908]: <info>  [1541013535.5237] device (wlp3s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
paź 31 20:18:55 my-PC NetworkManager[908]: <info>  [1541013535.5158] device (wlp3s0): supplicant interface state: completed -> disconnected
paź 31 20:18:55 my-PC NetworkManager[908]: <warn>  [1541013535.5147] sup-iface[0x558e31580420,wlp3s0]: connection disconnected (reason -3)
paź 31 20:18:55 my-PC NetworkManager[908]: <info>  [1541013535.5121] device (wlp3s0): Activation: starting connection 'LiMe' (d02ebcaf-8f95-403c-a69c-6ff3af585b68)
paź 31 20:18:55 my-PC wpa_supplicant[909]: wlp3s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
paź 31 20:18:55 my-PC wpa_supplicant[909]: wlp3s0: CTRL-EVENT-DISCONNECTED bssid=f4:ec:38:b3:bc:7e reason=3 locally_generated=1

@1am
Copy link
Author

1am commented Nov 1, 2018

I tried the approach described in ubuntu 17.04 Switching to DNS server issue
and switched to unbound on my linux but the result is the same.
The journal entry from the time when visibility of fd66 addresses ends is corelated in time with these entries:

paź 31 23:26:49 my-PC nm-dispatcher[7587]: req:1 'dhcp4-change' [wlp3s0]: new request (1 scripts)
paź 31 23:26:49 my-PC nm-dispatcher[7587]: req:1 'dhcp4-change' [wlp3s0]: start running ordered scripts...
paź 31 23:30:17 my-PC whoopsie[2373]: [23:30:17] Cannot reach: https://daisy.ubuntu.com
paź 31 23:30:18 my-PC whoopsie[2373]: [23:30:18] Cannot reach: https://daisy.ubuntu.com

Actually it stops after Cannot reach: https://daisy.ubuntu.com

@ilario
Copy link
Member

ilario commented Nov 26, 2018

@nordurljosahvida
Copy link

Not sure if this is related, but ever since I've started using LiMe, I cannot ping any node other than the one I'm currently connected to.

First off, the ping command always fails when using addresses such as fe80::a62b:b0ff:fede:ad4c, as found in the BATMAN page, not sure if that's normal. The only addresses that are accepted by the ping command are the ones found under the BMX6 -> nodes page, that look like: fd66:66:66:2e:a62b:b0ff:fede:ad4b.

That said, on rare occasions I am able to ping other nodes, but not all! Right now for instance, I can ping6 the node I'm connected to, another node that is not the gateway, but not the gateway.

	OPNT-3e9509	fd66:66:66:16:f6f2:6dff:fe3e:9508	br-lan	999M	4729	3	0	
	OPNT-dead4e	fd66:66:66:2e:a62b:b0ff:fede:ad4b	br-lan	999M	3923	3	0	
	OPNT-f9dcce	fd66:66:66:19:46d9:e7ff:fef9:dcce	---	128G	4728	0	0	

If this is not related, please feel free to ignore this to avoid going OT. Thanks!

@ilario
Copy link
Member

ilario commented Nov 28, 2018

@nordurljosahvida the IPv6 addresses strting with fe80: are the link-local ones, they can be used just specifying the network interface to use and they are not routed. In a BATMAN adv connected network you can use this for connecting to every router, as you're all in the same broadcast domain. You can use it also for SSH (and I can't remember if even browsers support link local, I don't think so).
For specifying the network interface you have to add a percentage % mark and the name of the interface at the end of the address, for example:
fe80::a62b:b0ff:fede:ad4c%enp0s25

Read more abouthow to use IPv6 link-local in the troubleshooting guide here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants