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(a)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(a)libre.ws>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(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users