On 02/02/16 17:24, Christopher Hesse wrote:
On Tue, Feb 2, 2016 at 3:09 AM, Antti Kantee <[email protected]> wrote:
Humh, same thing. Apparently a /32 subnet mask is a thing:
https://code.google.com/p/google-compute-engine/issues/detail?id=77
Never encountered that one before.
So, I guess someone(tm) has to hack the dhcp client to add an explicit route
to the gateway in the /32 case.
Yeah the networking sounds like it uses a not super popular DHCP RFC.
I'm not sure I understand how adding the explicit route would fix the
issue. I'm looking at rumprun/buildrump.sh/brlib/libnetconfig which I
suspect is the correct place to adjust this, but the output from my
instance was:
dhcp: vioif0: adding IP address 10.240.0.4/32
dhcp: vioif0: adding route to 10.240.0.1/32
dhcp: vioif0: adding default route via 10.240.0.1
Which seems to me that it already added an explicit route to the
gateway. So it's not clear to me what the fix is. Any suggestions?
No, not an IP route, but rather a link route. So you instruct the
networking stack that the address of the gateway is reachable via
vioif0, no matter what the IP routing table says. Now, I need to do
that kind of stuff once every 5 years, so I don't remember exactly how
to do it off the top of my head. A newer version of dhcpcd -- which
give or take some missing limbs and mutations is where the dhcp code
comes from -- might already contain the magic spell. Another way to
figure it out is to play with the route command from rumpctrl and use -v
to print the routing message you need to send to the networking stack.
