search

libremesh / lime-sdk

LibreMesh software development kit
http://libremesh.org/
GNU General Public License v3.0
50 stars 36 forks source link

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

Open 1am opened 5 years ago

1am commented 5 years ago

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 commented 5 years ago

Hi Piotr,

Thanks for your question. Quiestions go much better to the mailing list. If this ends up being a bug (looks like it), we will also need what codebase you are using, and ways to reproduce it.

Thanks

On October 29, 2018 11:20:56 AM GMT, Piotr notifications@github.com wrote:

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.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/libremesh/lime-sdk/issues/93

-- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

ilario commented 5 years ago

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 commented 5 years ago

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

1am commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

libremesh/lime-packages#431

nordurljosahvida commented 5 years ago

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 commented 5 years ago

@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