Project

General

Profile

Actions
Copy link

Bug #3941

closed

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

Added by Chris Buechler over 9 years ago. Updated over 9 years ago.

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

100%

Estimated time:
Plus Target Version:
Release Notes:
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.

Actions
Copy link
 #1

Updated by Chris Buechler over 9 years ago

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.

Actions
Copy link
 #2

Updated by Chris Buechler over 9 years ago

  • Assignee set to Renato Botelho
Actions
Copy link
 #3

Updated by Chris Buechler over 9 years ago

  • Assignee changed from Renato Botelho to Chris Buechler

I'll take this one

Actions
Copy link
 #4

Updated by Chris Buechler over 9 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.

Actions
Copy link
 #5

Updated by Ermal Luçi over 9 years ago

  • Status changed from Confirmed to Feedback
Actions
Copy link
 #6

Updated by Ermal Luçi over 9 years ago

  • % Done changed from 0 to 100
Actions
Copy link
 #7

Updated by Ermal Luçi over 9 years ago

Actions
Copy link
 #8

Updated by Chris Buechler over 9 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

Actions
Copy link
 #9

Updated by Chris Buechler over 9 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.

Actions
Copy link
 #10

Updated by Renato Botelho over 9 years ago

  • Assignee changed from Ermal Luçi to Renato Botelho

I'll take it.

Actions
Copy link
 #11

Updated by Chris Buechler over 9 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.

Actions
Copy link
 #12

Updated by Chris Buechler over 9 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.

Actions
Copy link
 #13

Updated by Phillip Davis over 9 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.

Actions
Copy link
 #14

Updated by Chris Buechler over 9 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.

Actions
Copy link
 #15

Updated by Chris Buechler over 9 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.

Actions
Copy link
 #16

Updated by Chris Buechler over 9 years ago

  • Status changed from Feedback to Resolved

works in every scenario I can find

Actions
Copy link
 #17

Updated by Chris Buechler over 9 years ago

  • % Done changed from 50 to 100
Actions
Copy link

Also available in: Atom PDF