Bug 266508 - dhclient sends renew through wrong interface
Summary: dhclient sends renew through wrong interface
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-19 21:53 UTC by flole
Modified: 2023-07-29 03:22 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description flole 2022-09-19 21:53:57 UTC 
When using dhclient in a multi-wan environment it sends the renew unicast requests through the wrong interface.

An example config is this:

eth0.1: 192.168.1.1/24
eth0.2: 192.168.2.1/24

default gateway: 192.168.1.254/24
dhcp server for both interfaces: 1.2.3.4

In this case dhclient always sends out the requests through eth0.1 to the dhcp server, even a renew for eth0.2. I don't know if it's possible to properly fix this as the system doesn't know which gateway to use to reach the dhcp server through eth0.2. If not I suggest to add an option to not send out unicast requests at all but send out broadcasts only which can be enabled in this case, or an option to save the from-MAC-address of the initial response and then blindly send back to that MAC address without even caring about the routing table. Or maybe an option to override the destination MAC for the unicast requests, with 00:00:00:00:00:00 being used to disable the feature and ff:ff:ff:ff:ff:ff obviously being used for broadcasting, and any other MAC is just blindly copied in case someone wants to manually specify the gateway MAC there.