-
Notifications
You must be signed in to change notification settings - Fork 36
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
Comments
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 ***@***.***> 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](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:
#93
--
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
|
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 |
Thank you for your responses. I'll move my question to the mailing list and fill in the blanks. |
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. |
I'm not sure I got this bit. while true; do host lime-bbccdd.lan; sleep 60; done Would show good results at first and then start failing after a while? This is a serious issue if it's confirmed. |
I'm attaching a screenshot with log of my pinging 2 nodes, each under fd66: and 2a00: networks + doing Both addresses from fd66: disappear pretty much in the same moment but the rest works ok. Is there a reliable way to obtain the 2a00: ( I will try to use the |
I think this can be somehow related to systemd-resolved or dhclient behaviour on my linux. Could it be related to the 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.
|
I tried the approach described in ubuntu 17.04 Switching to DNS server issue
Actually it stops after |
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 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.
If this is not related, please feel free to ignore this to avoid going OT. Thanks! |
@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). Read more abouthow to use IPv6 link-local in the troubleshooting guide here |
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?
The text was updated successfully, but these errors were encountered: