ipv4-check maybe improved - wrong result
thomasschaeferm opened this issue · 4 comments
I have an Vodafone W5101 and an IPv6-native, NAT64-connection.
This device uses ipv4 for management via web and for DNS-Resolvers. Unfortunately the device itself has no CLAT included, so I gave your tool a try:
./clatd
Starting clatd v1.1 by Tore Anderson tore@fud.no
Performing DNS64-based PLAT prefix discovery (cf. RFC 7050)
Using PLAT (NAT64) prefix: 2a01:198:24c:dfff:1::/96
Device facing the PLAT: wwan0
Attempting to derive a CLAT IPv6 address from a EUI-64 address on 'wwan0'
Using CLAT IPv4 address: 192.0.0.1
Using CLAT IPv6 address: 2a01:198:24c:c152:e5b:8fc1:a727:9a64
Checking if this system already has IPv4 connectivity in 10 sec(s)
This system already has IPv4 connectivity; no need for a CLAT.
hpmini:/home/thomas/clat/clatd # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
ping: recvmsg: Network is unreachable
WARNING: kernel is not very fresh, upgrade is recommended.
From 192.168.0.1: icmp_seq=2 Destination Net Unreachable
ping: recvmsg: Network is unreachable
From 192.168.0.1: icmp_seq=3 Destination Net Unreachable
ping: recvmsg: Network is unreachable
From 192.168.0.1: icmp_seq=4 Destination Net Unreachable
ping: recvmsg: Network is unreachable
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4002ms
wwan0 Link encap:Ethernet HWaddr 0C:5B:8F:27:9A:64
inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: 2a01:198:24c:c152:cd56:67cb:eaad:9da6/64 Scope:Global
inet6 addr: 2a01:198:24c:c152:e5b:8fff:fe27:9a64/64 Scope:Global
inet6 addr: fe80::e5b:8fff:fe27:9a64/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14109 errors:0 dropped:0 overruns:0 frame:0
TX packets:13299 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9125673 (8.7 Mb) TX bytes:69712226 (66.4 Mb)
8: wwan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 0c:5b:8f:27:9a:64 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.100/24 brd 192.168.0.255 scope global wwan0
valid_lft forever preferred_lft forever
inet6 2a01:198:24c:c152:cd56:67cb:eaad:9da6/64 scope global temporary dynamic
valid_lft 7054sec preferred_lft 3454sec
inet6 2a01:198:24c:c152:e5b:8fff:fe27:9a64/64 scope global dynamic
valid_lft 7054sec preferred_lft 3454sec
inet6 fe80::e5b:8fff:fe27:9a64/64 scope link
valid_lft forever preferred_lft forever
cat /etc/resolv.conf
Generated by dhcpcd for interface wwan0
search VodafoneMobile.wifivodafonemobile.api
nameserver 192.168.0.1
nameserver 192.168.0.1
ip route
default via 192.168.0.1 dev wwan0
169.254.0.0/16 dev wwan0 scope link
192.168.0.0/24 dev wwan0 proto kernel scope link src 192.168.0.100
ip -6 route
2a01:198:24c:c152::/64 dev wwan0 proto kernel metric 256 expires 7000sec
fe80::/64 dev wwan0 proto kernel metric 256
default via fe80::d27a:b5ff:fe7b:e152 dev wwan0 proto ra metric 1024 expires 1600sec
Here's your problem:
ip route
default via 192.168.0.1 dev wwan0
So you do have an IPv4 default route, but it's not working. I don't know how to detect that situation short of doing active probing, but that has its own challenges, such as what do you probe exactly, and that you open up a whole new set of possible false positives (probe target down, packet loss in radio network, firewalls blocking the probing traffic, and so on). So I'm not convinced that having this in would be worth the effort.
Have you tried starting clatd with v4-conncheck-enable=no, btw? That ought to allow clatd to start, but another problem is that since you already have a default route, clatd would have to remove it to actually be useful (your preexisting default route has no metric, so clatd can't preempt it by adding an alternative default route with a lower metric than the preexisting one).
So I'm inclined to to close this as «won't fix», unless you have any suggestions on how to deal with your situation in a clean way?
I think it might a more reasonable approach in your case would be to try to figure out why you have a defective IPv4 default route in the first place, and address that problem instead.
Tore
To disable v4-conncheck-enable did not solve the problem, I have to remove the ipv4-default route too.
But then, if I remove the default route before, clatd has no problems.
I did not look into the code. So I did not know, that you checking only the existence of the ipv4-default-route. Of course you are right, other checking methods may have more unwanted effects.
The defect default route is caused by the stick. It needs at least the route for 192.168.0.0/24 dev wwan0, but it adds the default route too.
Because of the lack of an integrated clat-service, this is useless/harmful for external ipv6-only-connections.
won't fix is ok, it was just a suggestion.
The stick should be fixed. And now, we know a workaround.
Thanks
Okay, then I'll just go ahead and close this issue. Thanks for your feedback though, I appreciate it!
Here are some suggestions on how you could work around the problem:
- Have your DHCPv4 client not request the default router option (3)
- Have your DHCPv4 client add the default route with a metric (which you can then have clatd "beat" with v4-defaultroute-metric=n). If you're using NetworkManager I think you get a default metric of 1024 (at least that's what I get)
- Disable DHCPv4 on wwan0 and instead use a static address inside 192.168.0.0/24 for management
- Report the bug to Vodafone and hope that they will fix the modem so that it doesn't advertise a default router option in DHCPv4 (unless it actually has external IPv4 connectivity of course)
Tore
Last comment: Yes, I switched off IPv4 at W5101 (disable dhcp).
clatd now works beautiful.
Also DNS-via ipv6-link-local address to the router works, but not the management/web interface.
For that you have to remember its IPv4-adresse and set a suitable address to the wlan-interface manually.
Now I have an easy to use mobile-hotspot with IPv6 only.
Just one popular device doesn't work with that configuration, as you know (Android bug 32630).
Thomas