Public bug reported:
When receiving an IP from a DHCP server and a router IP that is not the
same IP, dhclient-script silently fails to add the router as a default
route for the interface (RTNETLINK answers: Network is unreachable).
Error occurs on line 320:
# set default route
ip -4 route add default via ${router} dev ${interface} \
${if_metric:+metric $if_metric} >/dev/null 2>&1
With no control over the DHCP server (an ISP-provided appliance
configured to propagate its external IP to this DHCP client), the
apparent solution (other than quick hard-coded hacks like `route add
default MYINTERFACE`) is to first create a single-ip route, adding the
preceding line:
ip -4 route add ${router} dev ${interface}
(Alternatively, collapsing the resulting two rules by replacing original
line's use of ${router} with ${new_ip_address} also works, and also
preserves the route table's resolution of the gateway ip to a hostname -
unlike the hack.)
I could probably write a more complex custom enter hook to correctly
handle the scenario, but this does not seem so terribly obscure to
justify it (standard appliance from a major Canadian ISP). With
sufficient information present to infer the correct routing, I believe
it should work out of the box.
I do not rule out consequences of doing so beyond my current grasp, and
it does seem odd to me that my ISP provides a gateway outside the
subnet. Nevertheless I hope some attention on the issue will yeild a
more robust stock configuration or at least some deeper insight.
(Sanitized) variable dump for dhclient-script:
Tue Dec 12 00:59:23 AST 2017: entering /etc/dhcp/dhclient-enter-hooks.d,
dumping variables.
reason='BOUND'
interface='eth0'
new_ip_address='123.45.114.112'
new_network_number='123.45.114.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='123.45.114.255'
new_routers='123.45.112.1'
new_domain_name='redacted.com'
new_domain_name_servers='127.0.0.1'
old_ip_address='123.45.114.112'
old_network_number='123.45.114.0'
old_subnet_mask='255.255.255.0'
old_broadcast_address='123.45.114.255'
old_routers='123.45.112.1'
old_domain_name='redacted.com'
old_domain_name_servers='127.0.0.1'
Routing rules with stock configuration (the only one that doesn't route
internet traffic):
Destination Gateway Genmask Flags Metric Ref Use
Iface
123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
With my added line:
Destination Gateway Genmask Flags Metric Ref Use
Iface
default fctnnbsc38w-123 0.0.0.0 UG 0 0 0 eth0
fctnnbsc38w-123 * 255.255.255.255 UH 0 0 0 eth0
123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
With interface ip as router ip:
Destination Gateway Genmask Flags Metric Ref Use
Iface
default fctnnbsc38w-123 0.0.0.0 UG 0 0 0 eth0
123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
With hardcoded hack:
Destination Gateway Genmask Flags Metric Ref Use
Iface
default * 0.0.0.0 U 0 0 0 eth0
123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
** Affects: isc-dhcp (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
When receiving an IP from a DHCP server and a router IP that is not the
same IP, dhclient-script silently fails to add the router as a default
route for the interface (RTNETLINK answers: Network is unreachable).
Error occurs on line 320:
- # set default route
- ip -4 route add default via ${router} dev ${interface} \
- ${if_metric:+metric $if_metric} >/dev/null 2>&1
+ # set default route
+ ip -4 route add default via ${router} dev ${interface} \
+ ${if_metric:+metric $if_metric} >/dev/null 2>&1
-
- With no control over the DHCP server (an IPS-provided appliance
+ With no control over the DHCP server (an ISP-provided appliance
configured to propagate its external IP to this DHCP client), the
apparent solution (other than quick hard-coded hacks like `route add
default MYINTERFACE`) is to first create a single-ip route, adding the
preceding line:
- ip -4 route add ${router} dev ${interface}
+ ip -4 route add ${router} dev ${interface}
(Alternatively, collapsing the resulting two rules by replacing original
line's use of ${router} with ${new_ip_address} also works, and also
preserves the route table's resolution of the gateway ip to a hostname -
unlike the hack.)
I could probably write a more complex custom enter hook to correctly
handle the scenario, but this does not seem so terribly obscure to
justify it (standard appliance from a major Canadian ISP). With
sufficient information present to infer the correct routing, I believe
it should work out of the box.
I do not rule out consequences of doing so beyond my current grasp, and
it does seem odd to me that my ISP provides a gateway outside the
subnet. Nevertheless I hope some attention on the issue will yeild a
more robust stock configuration or at least some deeper insight.
(Sanitized) variable dump for dhclient-script:
Tue Dec 12 00:59:23 AST 2017: entering /etc/dhcp/dhclient-enter-hooks.d,
dumping variables.
reason='BOUND'
interface='eth0'
new_ip_address='123.45.114.112'
new_network_number='123.45.114.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='123.45.114.255'
new_routers='123.45.112.1'
new_domain_name='redacted.com'
new_domain_name_servers='127.0.0.1'
old_ip_address='123.45.114.112'
old_network_number='123.45.114.0'
old_subnet_mask='255.255.255.0'
old_broadcast_address='123.45.114.255'
old_routers='123.45.112.1'
old_domain_name='redacted.com'
old_domain_name_servers='127.0.0.1'
Routing rules with stock configuration (the only one that doesn't route
internet traffic):
Destination Gateway Genmask Flags Metric Ref Use Iface
123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
With my added line:
Destination Gateway Genmask Flags Metric Ref Use Iface
default fctnnbsc38w-123 0.0.0.0 UG 0 0 0 eth0
fctnnbsc38w-123 * 255.255.255.255 UH 0 0 0 eth0
123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
With interface ip as router ip:
Destination Gateway Genmask Flags Metric Ref Use Iface
default fctnnbsc38w-123 0.0.0.0 UG 0 0 0 eth0
123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
With hardcoded hack:
Destination Gateway Genmask Flags Metric Ref Use Iface
default * 0.0.0.0 U 0 0 0 eth0
123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
** Description changed:
When receiving an IP from a DHCP server and a router IP that is not the
same IP, dhclient-script silently fails to add the router as a default
route for the interface (RTNETLINK answers: Network is unreachable).
Error occurs on line 320:
# set default route
ip -4 route add default via ${router} dev ${interface} \
${if_metric:+metric $if_metric} >/dev/null 2>&1
With no control over the DHCP server (an ISP-provided appliance
configured to propagate its external IP to this DHCP client), the
apparent solution (other than quick hard-coded hacks like `route add
default MYINTERFACE`) is to first create a single-ip route, adding the
preceding line:
ip -4 route add ${router} dev ${interface}
(Alternatively, collapsing the resulting two rules by replacing original
line's use of ${router} with ${new_ip_address} also works, and also
preserves the route table's resolution of the gateway ip to a hostname -
unlike the hack.)
I could probably write a more complex custom enter hook to correctly
handle the scenario, but this does not seem so terribly obscure to
justify it (standard appliance from a major Canadian ISP). With
sufficient information present to infer the correct routing, I believe
it should work out of the box.
I do not rule out consequences of doing so beyond my current grasp, and
it does seem odd to me that my ISP provides a gateway outside the
subnet. Nevertheless I hope some attention on the issue will yeild a
more robust stock configuration or at least some deeper insight.
(Sanitized) variable dump for dhclient-script:
Tue Dec 12 00:59:23 AST 2017: entering /etc/dhcp/dhclient-enter-hooks.d,
dumping variables.
reason='BOUND'
interface='eth0'
new_ip_address='123.45.114.112'
new_network_number='123.45.114.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='123.45.114.255'
new_routers='123.45.112.1'
new_domain_name='redacted.com'
new_domain_name_servers='127.0.0.1'
old_ip_address='123.45.114.112'
old_network_number='123.45.114.0'
old_subnet_mask='255.255.255.0'
old_broadcast_address='123.45.114.255'
old_routers='123.45.112.1'
old_domain_name='redacted.com'
old_domain_name_servers='127.0.0.1'
Routing rules with stock configuration (the only one that doesn't route
internet traffic):
- Destination Gateway Genmask Flags Metric Ref Use Iface
- 123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
+ Destination Gateway Genmask Flags Metric Ref Use
Iface
+ 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
With my added line:
- Destination Gateway Genmask Flags Metric Ref Use Iface
- default fctnnbsc38w-123 0.0.0.0 UG 0 0 0 eth0
- fctnnbsc38w-123 * 255.255.255.255 UH 0 0 0 eth0
- 123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
+ Destination Gateway Genmask Flags Metric Ref Use
Iface
+ default fctnnbsc38w-123 0.0.0.0 UG 0 0 0
eth0
+ fctnnbsc38w-123 * 255.255.255.255 UH 0 0 0
eth0
+ 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
With interface ip as router ip:
- Destination Gateway Genmask Flags Metric Ref Use Iface
- default fctnnbsc38w-123 0.0.0.0 UG 0 0 0 eth0
- 123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
+ Destination Gateway Genmask Flags Metric Ref Use
Iface
+ default fctnnbsc38w-123 0.0.0.0 UG 0 0 0
eth0
+ 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
With hardcoded hack:
- Destination Gateway Genmask Flags Metric Ref Use Iface
- default * 0.0.0.0 U 0 0 0 eth0
- 123.45.114.0 * 255.255.255.0 U 0 0 0 eth0
+ Destination Gateway Genmask Flags Metric Ref Use
Iface
+ default * 0.0.0.0 U 0 0 0
eth0
+ 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
** Description changed:
When receiving an IP from a DHCP server and a router IP that is not the
same IP, dhclient-script silently fails to add the router as a default
route for the interface (RTNETLINK answers: Network is unreachable).
Error occurs on line 320:
# set default route
ip -4 route add default via ${router} dev ${interface} \
${if_metric:+metric $if_metric} >/dev/null 2>&1
With no control over the DHCP server (an ISP-provided appliance
configured to propagate its external IP to this DHCP client), the
apparent solution (other than quick hard-coded hacks like `route add
default MYINTERFACE`) is to first create a single-ip route, adding the
preceding line:
ip -4 route add ${router} dev ${interface}
(Alternatively, collapsing the resulting two rules by replacing original
line's use of ${router} with ${new_ip_address} also works, and also
preserves the route table's resolution of the gateway ip to a hostname -
unlike the hack.)
I could probably write a more complex custom enter hook to correctly
handle the scenario, but this does not seem so terribly obscure to
justify it (standard appliance from a major Canadian ISP). With
sufficient information present to infer the correct routing, I believe
it should work out of the box.
I do not rule out consequences of doing so beyond my current grasp, and
it does seem odd to me that my ISP provides a gateway outside the
subnet. Nevertheless I hope some attention on the issue will yeild a
more robust stock configuration or at least some deeper insight.
(Sanitized) variable dump for dhclient-script:
- Tue Dec 12 00:59:23 AST 2017: entering /etc/dhcp/dhclient-enter-hooks.d,
dumping variables.
- reason='BOUND'
- interface='eth0'
- new_ip_address='123.45.114.112'
- new_network_number='123.45.114.0'
- new_subnet_mask='255.255.255.0'
- new_broadcast_address='123.45.114.255'
- new_routers='123.45.112.1'
- new_domain_name='redacted.com'
- new_domain_name_servers='127.0.0.1'
- old_ip_address='123.45.114.112'
- old_network_number='123.45.114.0'
- old_subnet_mask='255.255.255.0'
- old_broadcast_address='123.45.114.255'
- old_routers='123.45.112.1'
- old_domain_name='redacted.com'
- old_domain_name_servers='127.0.0.1'
+ Tue Dec 12 00:59:23 AST 2017: entering /etc/dhcp/dhclient-enter-hooks.d,
dumping variables.
+ reason='BOUND'
+ interface='eth0'
+ new_ip_address='123.45.114.112'
+ new_network_number='123.45.114.0'
+ new_subnet_mask='255.255.255.0'
+ new_broadcast_address='123.45.114.255'
+ new_routers='123.45.112.1'
+ new_domain_name='redacted.com'
+ new_domain_name_servers='127.0.0.1'
+ old_ip_address='123.45.114.112'
+ old_network_number='123.45.114.0'
+ old_subnet_mask='255.255.255.0'
+ old_broadcast_address='123.45.114.255'
+ old_routers='123.45.112.1'
+ old_domain_name='redacted.com'
+ old_domain_name_servers='127.0.0.1'
Routing rules with stock configuration (the only one that doesn't route
internet traffic):
- Destination Gateway Genmask Flags Metric Ref Use
Iface
- 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
+ Destination Gateway Genmask Flags Metric Ref Use
Iface
+ 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
With my added line:
- Destination Gateway Genmask Flags Metric Ref Use
Iface
- default fctnnbsc38w-123 0.0.0.0 UG 0 0 0
eth0
- fctnnbsc38w-123 * 255.255.255.255 UH 0 0 0
eth0
- 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
+ Destination Gateway Genmask Flags Metric Ref Use
Iface
+ default fctnnbsc38w-123 0.0.0.0 UG 0 0 0
eth0
+ fctnnbsc38w-123 * 255.255.255.255 UH 0 0 0
eth0
+ 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
With interface ip as router ip:
- Destination Gateway Genmask Flags Metric Ref Use
Iface
- default fctnnbsc38w-123 0.0.0.0 UG 0 0 0
eth0
- 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
+ Destination Gateway Genmask Flags Metric Ref Use
Iface
+ default fctnnbsc38w-123 0.0.0.0 UG 0 0 0
eth0
+ 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
With hardcoded hack:
- Destination Gateway Genmask Flags Metric Ref Use
Iface
- default * 0.0.0.0 U 0 0 0
eth0
- 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
+ Destination Gateway Genmask Flags Metric Ref Use
Iface
+ default * 0.0.0.0 U 0 0 0
eth0
+ 123.45.114.0 * 255.255.255.0 U 0 0 0
eth0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1737663
Title:
dhclient fails setting default gateway to unreachable host
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1737663/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
