Project

General

Profile

Bug #3941

adding a DHCP client interface results in missing default gateway on 2.2

Added by Chris Buechler about 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
High
Category:
Routing
Target version:
Start date:
10/16/2014
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.2
Affected Architecture:

Description

Take a simple WAN and LAN setup, WAN on DHCP with its dynamic gateway marked as default, LAN static. Add a third NIC as OPT1, configured as a DHCP client. Save and apply changes on OPT1. Your default gateway is now gone.

Not just the first time either, any time you save and apply changes on OPT1 in that scenario, the default gateway is gone. On boot, it's fine, and any other gateway-related operation seems to handle that just fine.

Associated revisions

Revision d35dfaae (diff)
Added by Ermal Luçi about 4 years ago

Fixes #3941. When optimizations of the loops were made this brought the problems of overriding default gateway by dynamic interfaces. Try to stick to the first found for now!

Revision 935fcedb (diff)
Added by Ermal Luçi about 4 years ago

Fixes #3941. When optimizations of the loops were made this brought the problems of overriding default gateway by dynamic interfaces. Try to stick to the first found for now!

Revision b0533f16 (diff)
Added by Chris Buechler about 4 years ago

Setting an interface's IP to 0.0.0.0 with mask 0.0.0.0 overwrites the
default route with that interface's link route. Later in dhclient, that
gets deleted and leaves the system with no default route. Using a /32 mask
here works in every scenario I can find, and stops the default route
deletion issues. Ticket #3941

Revision a9b305a8 (diff)
Added by Chris Buechler about 4 years ago

Set this to /8 instead since that's how it's done in stock FreeBSD 10.1. Ticket #3941

History

#1 Updated by Chris Buechler about 4 years ago

  • Affected Documentation 1 added

the subject doesn't quite cover all the breakage this causes, there are various times that the default gateway is removed in the described circumstance.

#2 Updated by Chris Buechler about 4 years ago

  • Assignee set to Renato Botelho

#3 Updated by Chris Buechler about 4 years ago

  • Assignee changed from Renato Botelho to Chris Buechler

I'll take this one

#4 Updated by Chris Buechler about 4 years ago

most I've found thus far is it still happens after removing all the "route delete default" commands from dhclient-script. Not seeing an obvious place it's happening. It's easy to replicate and re-replicate, set interface back to "none", save, apply. Set back to DHCP, save, apply. Default gateway gone.

#5 Updated by Ermal Luçi about 4 years ago

  • Status changed from Confirmed to Feedback

#6 Updated by Ermal Luçi about 4 years ago

  • % Done changed from 0 to 100

#7 Updated by Ermal Luçi about 4 years ago

#8 Updated by Chris Buechler about 4 years ago

  • Status changed from Feedback to Confirmed
  • Assignee changed from Chris Buechler to Ermal Luçi

that didn't fix the issue described here

#9 Updated by Chris Buechler about 4 years ago

the fix earlier in rc.linkup didn't have any effect here. Dug through this more tonight. Best I can definitively say right now beyond the above is it's none of the 'route' commands in system.inc to blame.

#10 Updated by Renato Botelho about 4 years ago

  • Assignee changed from Ermal Luçi to Renato Botelho

I'll take it.

#11 Updated by Chris Buechler about 4 years ago

  • Assignee changed from Renato Botelho to Chris Buechler
  • % Done changed from 100 to 50

getting close to finding this, back to me as I'm working on it now.

#12 Updated by Chris Buechler about 4 years ago

  • Assignee changed from Chris Buechler to Ermal Luçi

found the exact spot where the issue happens. /sbin/dhclient-script, line 325.

$IFCONFIG $interface inet 0.0.0.0 netmask 0.0.0.0 broadcast 255.255.255.255 up

When you ifconfig an interface with 0.0.0.0/0.0.0.0, FreeBSD overrides the default route with that interface. Then later in dhclient-script, it blows away the 0.0.0.0 IP and leaves the system with no default route.

The interface that's assigned with 0.0.0.0/0.0.0.0 seems to be how dhclient finds its interface though. Take out the above line, or just change it to:

$IFCONFIG $interface up

and dhclient spits out:

dhclient: PREINIT
em2: not found
exiting.

So I'm stuck there in a catch 22. If you put that 0.0.0.0 on the interface, it blows up the routing table. If you don't, dhclient can't function.

Over to Ermal.

#13 Updated by Phillip Davis about 4 years ago

Just a thought - perhaps the interface can be set to all/part of the link-local address space 169.254.0.0/255.255.255.0 for example. DHCP client should be able to do its broadcast DHCP request and get the broadcast response (it should not be blocked by the link-local address blocks that were added recently), and when DHCP client succeeds the interface will get its proper address.
Nobody will be using link-local address space for real on their router.
If that works on single WAN, would also need to test it running in parallel on multiple WANs to see if having multiple WANs temporarily with the same link-local subnet specified causes any issues.

#14 Updated by Chris Buechler about 4 years ago

  • Status changed from Confirmed to Feedback
  • Assignee changed from Ermal Luçi to Chris Buechler

Thanks for the comment Phil, that thought process brought to mind an idea. Using a /32 mask instead of 0.0.0.0 fixes the original issue here, and seems to work in all circumstances. I just committed that change after it tested out fine on my test systems. Leaving for feedback, hopefully that'll resolve it without breaking anything.

I suspect if the request isn't sourced from 0.0.0.0, at least some DHCP servers won't answer. Possibly some bridge devices that will only pass DHCP requests sourced from 0.0.0.0 or a known IP (for renewals). So a source of anything other than 0.0.0.0 at that stage is potentially problematic.

#15 Updated by Chris Buechler about 4 years ago

dhclient-script in 2.1x used the same 0.0.0.0/0.0.0.0, so that's a change in behavior between FreeBSD 8.3 and 10.1. Checking the dhclient-script in stock FreeBSD 10.1, they use a /8 mask there. /32 seems to work fine as well, but I changed it to /8 to stay consistent with FreeBSD. Both /8 and /32 appear to work fine.

Also reviewed a diff between our dhclient-script and stock FreeBSD's to see if there were other changes in behavior from 8.3 to 10.1. Didn't see anything relevant there.

#16 Updated by Chris Buechler about 4 years ago

  • Status changed from Feedback to Resolved

works in every scenario I can find

#17 Updated by Chris Buechler about 4 years ago

  • % Done changed from 50 to 100

Also available in: Atom PDF