aaronjg
commented
3 years ago The issue is that after the initial DHCP exchange, which is done as a broadcast, the renew is using a unicast send from a socket which is using bind() to the IP of the interface. The source bound packet is then routed out by the default gateway with the lowest metric, which can be another interface.
Does this issue happen without mwan3? I'm not sure mwan3 is at fault here, and if it happens even without mwan3 it may be better to patch udhcpc.
while it might be better to generically apply this to all packets bound to the interface IP like done here ?
If you add rules like that, much of the outgoing traffic will be caught up in it. Even something like 'ping' is going to have a default source address, so adding those rules will break mwan3 for router originated traffic.
KarlVogel
jow-
feckert
Maintainer: @feckert @aaronjg Environment: OpenWrt SNAPSHOT r15338-8348896357 / LuCI Master git-20.339.75073-e54708a / x86 KVM
Description:
I'm using 2 upstream WAN connections (
wan/wanb) towards 2 docsis bridge modems to the same ISP. Both connections get a DHCP lease from the same DHCP Server IP. Every hour one of the connections stopped working. After debugging I found that the udhcpc renew message got send over the wrong interface hence it was seen as a spoofed packet. It was not apparent as the packet's source IP was using thewaninterface's IP, while the socket it originated from was bound to the otherwanbinterface's IP. It's only visible due to the wrong DHCP contents, ie. the Request from is different.It became clear from the tcpdump (masked some digits):
The last line is a valid packet, while the packets before it show that the DHCP packet from the
wanbis being send on thiswaninterface using the IP of thewaninterface.The issue is that after the initial DHCP exchange, which is done as a broadcast, the renew is using a unicast send from a socket which is using bind() to the IP of the interface. The source bound packet is then routed out by the default gateway with the lowest metric, which can be another interface.
I resolved the problem by adding a policy based route to force packets bound to an interface's IP to route via that interface.
ie. added IP rules 1501 / 1503:
..67.234 is the IP from
wan..130.55 is the IP fromwanbIt would be possible to use setsockopt to mark the packets, but that would require either patching udhcpc or using preload to inject the libwrap_mwan3_sockopt.so patch, but that would then only apply to this specific case while it might be better to generically apply this to all packets bound to the interface IP like done here ?