-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DHCP-misbehaviour of LAN-LAN-connected nodes with anygw #1007
Comments
Thanks @pony1k !
to a network made like this: Pedro's laptop-ethernet port____cable____LAN port-LibreMesh router-LAN port____LAN port-LibreMesh router. The SSH connection was frequently breaking because both routers were answering him on the same IP. |
I am really not into firewalls, but if we add a firewall rule for avoiding the forwarding of packets destinated to the anygw IPs, also this issue should be solved, right? |
There is a rule already in place that does just that, but on Layer 2: As for the ssh to anygw issue, I have no clue. It should not happen, as far as I'm concerned. |
AnyGW IP is not meant to use for non any-castable stuff, and SSH is one of those non-anycast stuff so the thing reported by Pedro is to be expected, and not to be considered a issue |
Except for the fact that a client get multiple leases while using just one, that doesn't seems a big problem per se, what kind of misbehavior is caused by this? We could add filters, but:
|
I was thinking it could be problematic in small address spaces. But dnsmasq seems to give the same IP everywhere, so might not be a problem really.
How would that work? Even If the configuration suceeds, the client would have the anygw-address configured as default route. But when the client ist not connected via cable, they would not be able to send unicast packets there, because of the
Right! I totally forgot that. I think a saw it working when I tested my proposed rule on two DSA-devices, but now I am unsure on how that could even work. I don't think we even want to filter every packet that goes through the switch, because that would create a lot of overhead on the CPU and the path between CPU and the internal switch. I will close this issue now, because I don't think anymore that it is really an issue, at least not one that can be fixed. |
This happens in setups where multiple nodes with
lime-proto-anygw
in the same cloud are connected with cables.When a client connects to an AP, it broadcasts a DHCP-Discover into the network.
Since the AP-interfaces and the LAN-interfaces are bridged together, the message will arrive at every cable-connected node. Every node will then send a DHCP-Offer to the client. There would not be a problem if dnsmasq was not to put the interfaces primary ip address into the
Server-ID (54)
-field of the DHCP-Offer. The anygw-IP is the same everywhere in the cloud. The client then gets a bunch of DHCP-Offers with idenctialServer-ID
s. The client then broadcasts a DHCP-Request with theServer-ID
they chose to accept the offer from. Usually the chosen DHCP-server would then reply with ACK and store the new lease in its file while the rest of the servers would reply with NAK. In this case however, all the servers create a lease in their file and reply with ACK. This can easily be verified by looking into the lease files of the nodes. They will contain mostly the same mac-addresses.Attached is a tcpdump of the DHCP-traffic in a network with 8 cable-connected nodes. It countains 2 Discovers from the client, 16 Offers, 1 Request and then 8 ACKs from the servers.
dhcp tcpdump.txt
According to https://dnsmasq-discuss.thekelleys.org.narkive.com/M9Rwt2oy/cannot-override-dhcp-server-identifier-option-54 it is not possible to make dnsmasq send a different Server-ID.
However, I was able to solve the problem by adding an ebtables rule that prevents the DHCP-Discover and DHCP-Request messages from being forwarded.
The nft version would be (I think):
This effectively replicates the behaviour of batman-adv when setting
gw_mode
toclient
everywhere (which is what anygw does).Maybe we could add this to the anygw-package? Are there any other ideas?
The text was updated successfully, but these errors were encountered: