Continuing on this topic:
G10h4ck wrote:
> During the meeting I mentioned a specific thing to detect and notify to start with.
> _Rogue DHCP_
> Which happens very often in community networks.
> AKA
> 1) Participant have libremesh router on the roof
> 2) One or more unsupportable routers around at home with disabled DHCP connected via Ethernet port to the libremesh router on the roof.
>
> This happens because often those unsupported routers are much cheaper/available then supported ones on some markets. Everything works fine, except one day a spike in the current or whatever random condition, cause some of those unsupported routers to reset to default and so their DHCP server get enable by default and everything stop working.
>
> 3) I also suggested where to start to look
>
> Look into OpenWrt DHCP client to see how easy/hard would be to implement a functionality like `dhcpcd -T eth0` that could be used to periodically check for the aforementioned condition and notify the user/network via lime-app
Just found out that we can udhcpc has the -s option that can be used for that.
The description is:
-s PROG Run PROG at DHCP events (default
/usr/share/udhcpc/default.script)
The script is in charge of applying the offered IP, so writing another
script we can use the udhcpc without applying the IP to any interface.
For example, you can try this simple script just printing out the
variables mentioned in the original script:
#!/bin/sh
echo arg1 $1 arg2 $2 ip $ip subnet $subnet broadcast $broadcast max
$max interface $interface router $router staticroutes $staticroutes
msstaticroutes $msstaticroutes
save it as /root/fake-udhcp.script , give it executable permissions with
chmod a+x /root/fake-udhcp.script
and then run (the script path has to be absolute):
udhcpc -i br-lan -s /root/fake-udhcp.script
Ilario wrote:
> 1) on the whole network, as a spurious DHCP server appears and the clients could get a wrong ip and wrong gateway from it instead of receiving the right one from the LibreMesh nodes (and this would not happen every time, but only when the wrong DHCP offer arrives before the good one, so the problem would be difficult to identify);
> In my opinion, the problem 1 should be fixed with a firewall rule, active by default, that eliminates the incoming DHCP offers. This rule should be possible to disable with some option in /etc/config/lime-* in case someone does that on purpose, disabling the DHCP from LibreMesh and using an external one. Or this firewall rule should be included, and always active, in the optional lime-proto-anygw package.
> I found an ancient issue on this, where it seems that there is not yet a firewall rule for that:
> https://github.com/libremesh/lime-packages/issues/658
Just tested again and can confirm that this still happens.
So also this issue is still valid:
https://github.com/libremesh/lime-packages/issues/658
I tested 2 situations:
(laptop)ethernet -wire- LANport(LibreMesh router)LANport -wire-
commercial router
(laptop)wifi -wireless- AP(LibreMesh router)LANport -wire- commercial router
and in both cases the laptop received also DHCP offers from the
commercial router.
So I think that the firewall rule in lime-proto-anygw is really
needed, anyone able to write that? (I am not :P)
Ciao!
Ilario
