-
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
LiMe networks trick clients into thinking IPv6 is available #95
Comments
The relevant data would be `ip -6 r`
Everyone gets an ipv6 address, but doesn't mean that you have a route
assigned over it.
Please let us know what is the output of that command.
Thanks,
…On 11/27/18 12:32 PM, Nicolas North wrote:
Every since I started using LiMe, any client on the lan thinks the
network is IPv6 enabled, even though the only gateway in the network is
IPv4 only. This happens across every LiMe deployment I have.
***@***.***:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc
noqueue state UNKNOWN group default qlen 1000 link/loopback
00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever inet6 ::1/128 scope host
valid_lft forever preferred_lft forever 2: ens33:
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1350 qdisc fq_codel state UP group
default qlen 1000 link/ether 00:0c:29:92:14:5a brd ff:ff:ff:ff:ff:ff
inet 10.42.127.114/16 brd 10.42.255.255 scope global dynamic
noprefixroute ens33 valid_lft 2898sec preferred_lft 2898sec inet6
2a00:1508:a42:2400:65a1:d08b:f4f0:c0b0/64 scope global temporary dynamic
valid_lft 85694sec preferred_lft 85268sec inet6
2a00:1508:a42:2400:a74c:b3c1:31c7:10cd/64 scope global dynamic
mngtmpaddr noprefixroute valid_lft 85694sec preferred_lft 85694sec inet6
fe80::31f8:75e3:9044:a458/64 scope link noprefixroute valid_lft forever
preferred_lft forever |
Therefore anytime an address is resolved in IPv6, some clients, such as
android devices, try using the IPv6 address, and of course connections fail.
I've noticed that an IPv6 range is generated in lime-defaults, why do
those look like global addresses?
Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#95>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABFX1dZcLIqQ6G5J7jrrKJIPN9aY6I7tks5uzYUjgaJpZM4Y2Fqj>.
|
It also happened to me, annoying, please check this: libremesh/lime-packages#236 |
Thank you for the super fast reply. Here it is:
This is a VM running on my pc, but I'm using connection sharing rather than a bridge. However this issue happens on all devices I have, and on android devices especially, many apps do this. I think it also depends on how the ns resolution is performed. To give you a very specific example, the conversations XMPP client will try connecting to our server [ae.os.vu] and will always fail from any LiMe network. This is the result of a host query for this hostname:
Thanks again |
Just helping to have as much information as possible for others to debug :)
It looks like you have a default gateway... so if the DNS resolves to a
AAAA record, it will try to use that.
Perhaps the thread @ilario mentioned can help.
…On 11/27/18 12:47 PM, Nicolas North wrote:
Thank you for the super fast reply.
Here it is:
***@***.***:~# ip -6 r 2a00:1508:a42:2400::/64 dev ens33 proto ra
metric 100 pref medium fe80::/64 dev ens33 proto kernel metric 100 pref
medium fe80::/64 dev ens33 proto kernel metric 256 pref medium default
via fe80::a8aa:aaff:fe42:24aa dev ens33 proto ra metric 100 pref medium |
This is a VM running on my pc, but I'm using connection sharing rather
than a bridge. However this issue happens on all devices I have, and on
android devices especially, many apps do this. I think it also depends
on how the ns resolution is performed. To give you a very specific
example, the conversations XMPP client will try connecting to our server
[ae.os.vu] and will always fail from any LiMe network. This is the
result of a host query for this hostname:
***@***.***:~# host ae.os.vu ae.os.vu has address 80.211.10.102
ae.os.vu has address 89.46.73.154 ae.os.vu has address 217.61.60.150
ae.os.vu has IPv6 address 2a00:6d40:72:7966::1 ae.os.vu has IPv6 address
2a00:6d41:10:109a::1 |
Thanks again
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#95 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/ABFX1TJ3GstydOH3V31Yd_efx23UEiJKks5uzYjMgaJpZM4Y2Fqj>.
|
Cool thanks. I hope we can figure this out. Let me know if any further data is needed. |
Nexthop should answer with an ICMP unreachable packet, if the client have no strange firewall rules it should be unnoticeable the delay caused by having the IPv6 default route |
Every since I started using LiMe, any client on the lan thinks the network is IPv6 enabled, even though the only gateway in the network is IPv4 only. This happens across every LiMe deployment I have.
Therefore anytime a hostname has an IPv6 record associated in DNS, some clients, such as android devices, try using the IPv6 address, and of course connections fail.
I've noticed that an IPv6 range is generated in lime-defaults, why do those look like global addresses?
Thanks
The text was updated successfully, but these errors were encountered: