If that could be done easily, I can confirm this is definitely an issue.

Had I not an additional router [a routerboard hex in this case] between the ISP router and the “first lime node” as Nicolas calls it, my ISP router would be offline since a few months ago.

The hex is not vulnerable to dhcp broadcasts [or however they’re called] from the lan interfering with its own DHCP on the wan side, but that’s not the case with other routers.

DHCP broadcasts inside the lime network [or “hyper-lan” as I’m calling it in case of multiple LiMe nodes connected lan-to-lan] should never be forwarded outside the network, in any event, I think, and they’re big risk to LANs above them if a “vulnerable” router is serving uplink to the first lime node.

Thanks again


Nk


On 3 August 2017 at 13:48:59, Gui Iribarren (gui@altermundi.net) wrote:

On 04/07/17 01:19, Nicolás Echániz wrote:
> On 07/03/2017 11:39 AM, Ilario wrote:
>> 2017-07-02 19:02 GMT+02:00 Nicolas Pace <nico@libre.ws>:
>>> On Sun, 2017-07-02 at 18:30 +0200, Nikksno via lime-users wrote:
>>>> I have a POE switch with one cable going to a UBNT AC lite, one going
>>>> to a Bullet M2, one going to a 1043ND [on its wan port] and one to an
>>>> Archer C7 [on its wan port]. All 4 devices have the latest images
>>>> downloaded from repo.libremesh.org, just to be on the safe side. The
>>>> fifth cable is going to my ISP router [IP 192.168.111.1].
>>>>
>>>> They all mesh correctly, and even the two UBNTs serve internet
>>>> connectivity perfectly. The problem is that when I connect to these
>>>> two devices wirelessly with clients, I often get a DHCP assignment
>>>> from my ISP router [as it's on the 192.168.111.x subnet] and not a
>>>> 10.13.0.x assignment.
>>>
>>> Yes!
>>>
>>> That is because DHCP requests are coming from your devices to your UBNT
>>> AP, from there they move the DHCP request to the switch, and as the
>>> request goes to the broadcast address, the switch sends the packet to
>>> all the devices at the same time... so the one that replies faster is
>>> the response that the devices accepts.
>>
>> Thaaaat's interesting!
>> In my opinion LiMe routers should not forward DHCP requests or DHCP offerings.
>> Clients should get DHCP offering from the very LiMe router they're
>> connecting to.
>> Why don't we filter forwarding of DHCP packets?
>
> This is already the default behavior... is it not?
>
> Since we are setting batman gw-mode to client.

Correct, batadv gw-mode is set to client, but that only prevents
forwarding of DHCP requests over bat0,

in this case, the path of the request goes
laptop-->wlan0-ap-->br-lan-->eth0-->switch-->...

we could add (yet another!) ebtables rules to prevent that forwarding at
br-lan, say "if packet is dhcp, comes from wlan0-ap or wlan0-name and
wants to go out eth0, drop it". But i get the feeling that would break
scenarios that i'm not having in mind right now :)

>
>
>
>
> _______________________________________________
> lime-users mailing list
> lime-users@lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users
>

_______________________________________________
lime-users mailing list
lime-users@lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users