Network vtnet0 not working on Hetzner cloud
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...)
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 18.104.22.168 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?
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.
However, if I just use dhcpcd, all seems to work fine, can you please try it?
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 22.214.171.124 netmask 255.255.255.255 broadcast 126.96.36.199 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`!!!
- 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.
- Assignee deleted (
debugged it further:
route add 172.31.1.1/32 -iface vtnet0
will result in:
add net 172.31.1.1: gateway vtnet0
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?