Bug #3317
openNetwork vtnet0 not working on Hetzner cloud
Added by mneumann over 2 years ago. Updated over 2 years ago.
0%
Description
After running `dhclient vtnet0`, I cannot ping anything except the default gateway (172.31.1.1).
`route show` shows two entries for the default route (172.31.1.1) and
one contains very strange characters:
(See the second line for 172.31.1.1...)
Files
clipboard-202206091711-dw2gp.png (69.3 KB) clipboard-202206091711-dw2gp.png | Screenshot | mneumann, 06/09/2022 08:11 AM | |
clipboard-202206140707-0biu1.png (326 KB) clipboard-202206140707-0biu1.png | mneumann, 06/13/2022 10:07 PM | ||
clipboard-202206140730-vzpkc.png (302 KB) clipboard-202206140730-vzpkc.png | mneumann, 06/13/2022 10:30 PM | ||
clipboard-202206171102-blgae.png (66 KB) clipboard-202206171102-blgae.png | mneumann, 06/17/2022 02:02 AM |
Updated by mneumann over 2 years ago
- File deleted (
clipboard-202206091708-tazmu.png)
Updated by mneumann over 2 years ago
I can get `ping` to work when I flush the default route and add it again.
Updated by mneumann over 2 years ago
ah wait, no, I can't get `ping` to work. when I `route delete 172.31.1.1` and then `route add default 172.31.1.1` I have again two routes and one of them contains the strange characters in the Gateway column.
Updated by tuxillo over 2 years ago
I wonder if those characters are garbage. Have you tried using kgdb to inspect the kernel structures? I don't know from the top of my head which ones are.
I'm assuing that's a KVM VM (since it's using vtnet)
Updated by mneumann over 2 years ago
I will try to use `kgdb` at the weekend. Yes, I think it's KVM. The "garbage" changes when I remove the routes and add them again.
Updated by tuxillo over 2 years ago
Also, is it possible to mount a custom image from the Hetzner Cloud panel? I dont' see an option for that.
Updated by mneumann over 2 years ago
No, it's not possible to mount a custom ISO image. But I asked the support, and ~30 minutes later, they had the DragonFly (dfly-...) image uploaded and made available!!! Kudos.
Updated by mneumann over 2 years ago
I have to correct myself. It's possible to mount a custom ISO. You just need to ask the support to do it (the dragonfly ISO is a custom ISO)
Updated by mneumann over 2 years ago
Some dmesg output:
Updated by mneumann over 2 years ago
I also checked the integrity of the ISO image by doing an `dd if=/dev/cd0s0 bs=2k | md5` and it is correct (d41d8...27e; 6.2.1).
Updated by mneumann over 2 years ago
This error message might be of interest:
rtsock: received more addr bits than sockaddrs.
Updated by mneumann over 2 years ago
I'd like to setup the routes manually (not via dhclient), but I am strugging with it. This is what I do:
ifconfig vtnet0 inet 192.119.117.156 netmask 255.255.255.255 up
route add -interface 172.31.1.1 vtnet0
route add default 172.31.1.1
But, it's not showing "link#1" in the Gateway field for route 172.31.1.1 (it is initially empty, and later shows the MAC address) as it does when this route is added via `dhclient`.
Not sure what I am doing wrong?
Updated by tuxillo over 2 years ago
Can you please try this in your rc.conf?
[...] static_routes="hetzner default" route_hetzner="172.31.1.1 -interface vtnet0" route_default="default 172.31.1.1" ifconfig_vtnet0="inet x.x.x.x netmask 255.255.255.255" [...]
Updated by mneumann over 2 years ago
Hi tuxillo,
1000x thanks!
With your snippet above, it works!
Now I can install things and maybe we can figure out why DHCP does not work properly.
Updated by tuxillo over 2 years ago
I didn't know DHCP was supposed to work, I'll give it a try and see what's up.
Updated by tuxillo over 2 years ago
It seems to be related with our dhclient, it's definitely route related becuase if I use the config below in my rc.conf I'll get the bug you're reporting.
ifconfig_vtnet0="DHCP"
However, if I just use dhcpcd, all seems to work fine, can you please try it?
dhcpcd_enable="YES"
Updated by tuxillo over 2 years ago
Nice!
The question is now, should we find out what's the problem with dhclient? Because it might be uncovering at the very least a route(8) issue.
Updated by mneumann over 2 years ago
"We" probably should :). I guess DragonFly uses a different "dhclient" than FreeBSD, so diffing is not an option. Is "dhclient" going to be deprecated in DragonFly, or why is there a working alterantive (dhcpcd)?
Updated by mneumann over 2 years ago
There is `/sbin/dhclient-script` which is invoked with the following env variables set:
I could image that this script is doing something wrong.
The script is calling the following commands:
ifconfig vtnet0 inet 168.119.117.156 netmask 255.255.255.255 broadcast 168.119.117.156
route add 172.31.1.1/32 -iface vtnet0
route add default 172.31.1.1
after afterwards one of the routes shows up scrabled, as in the original bug report.
I tried to enter exactly the same commands as dhclient-script produces, and voila I end up with the same scrabled route entry. So, it's not the fault of `dhclient`!!!
Updated by mneumann over 2 years ago
Found the bug. So when I change:
route add 172.31.1.1/32 -iface vtnet0
to
route add 172.31.1.1 -iface vtnet0
it works! Might be a parsing problem in `route`.
Updated by tuxillo over 2 years ago
- Status changed from New to In Progress
- Assignee set to tuxillo
mneumann wrote in #note-19:
"We" probably should :). I guess DragonFly uses a different "dhclient" than FreeBSD, so diffing is not an option. Is "dhclient" going to be deprecated in DragonFly, or why is there a working alterantive (dhcpcd)?
Yes, the idea is to permanently switch to dhcpcd and remove dhclient. dhclient comes from OpenBSD by the way.
Updated by mneumann over 2 years ago
- Assignee deleted (
tuxillo)
debugged it further:
route add 172.31.1.1/32 -iface vtnet0
will result in:
add net 172.31.1.1: gateway vtnet0
while
route add 172.31.1.1 -iface vtnet0
will result in
add host 172.31.1.1: gateway vtnet0
An IP with /32 doesn't really look like a network to me. Maybe something is going havoc in the kernel if a network with /32 is given?
Updated by tuxillo over 2 years ago
Ok, we will have to check route(8) then, there might be a bug that needs fixing there.