DHCP relay RENEW problem with multiple interfaces routing out the wrong interface and IP

[hvisage]

Have two interfaces, each different metric, each on a network where a DHCP relay is used.

eth0 - metric 200 wlan0 - metric 300

When it gets to renew time for wlan0, the REQUEST is send out the lower metric (eth0 in this case) interface with it's IP, while the DHCP relay returns the response to the wlan0 interface IP (which the router/etc. correctly drop on the wlan0 network) thus dhcpcd doesn't get the renew response/ack.

The "correct" method would be to bind to the wlan0 interface (the one that needs to be renewed) to get/use that IP instead of the more prefered route's interface IP.

Is there a source interface setting I've missed somewhere?

leasetime 3600
request_time 60
hostname
duid
persistent
vendorclassid
option domain_name_servers, domain_name, domain_search
option classless_static_routes
option interface_mtu
option host_name
option ntp_servers
option rapid_commit
require dhcp_server_identifier
slaac hwaddr
interface wlan0
  metric 300
interface eth0
  metric 100

[rsmarples]

Even if dhcpcd receives wlan0 ACK/NAK on eth0 it should still work fine.

For DHCP, only the initial messages are sent via BPF which is locked to a specific interface. All other messages are generally unicast or broadcast at the network layer and thus routing will control which interface the messages leave by. DHCPv6 works exactly the same way.

Please state what version of dhcpcd you are using and on what platform.

[hvisage]

TEsts was on RaspberyPi 4B Debian 12 Dhcpcd 9.4 and 10.1 (Backports)

Is do see (in my case) DHCPCD send: src ip 192.168.55.3 -> dst IP 172.16.55.11 on eth0 DHCPrelay return packet: src ip 172.16.55.11 -> dst IP 10.1.10.26 on wlan0

But the packets don't seem to be "registering" as getting received (most probably 'cause the returing dst IP is not the same as the sending src IP)

[melnikovsky]

Hi. I had a similar problem (Linux), and was able to track it down to iptables -A INPUT -m state --state INVALID -j DROP in my setup. It seems conntrack does not recognize packets on a different interface as RELATED. Any chance you @hvisage are hit by the same problem?