9 Jul
2017
9 Jul
'17
3:38 p.m.
On Wed, 2017-07-05 at 20:28 +0200, Nk via lime-users wrote:
Ok thank you
Let’s figure out
1] Why dhcp leaks outside the lan-to-lan “hyperlan” between lime
nodes up into the first lime node’s wan and into the upstream router
[ISP in my case]
Don't know. Still don't know if it is an issue or not.
A DHCP request goes to a broadcast IP... I guess we shouldn't be
forwarding broadcast, right?
Can you add this as an issue here?
https://github.com/libremesh/lime-packages/issues/new with all the info you can provide
(such as the steps to reproduce the
problem)
2] If lan-to-lan hyperlans are safe for wired
equipment that hooks up
to the network directly [i.e. to a switch] and **not** as a wired
client to a lime router
What do you mean with safe?
This are safe for both.
3] What Ilario said – quote here:
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?
We could... goes together with what you said first.
Last question: as I had noticed in the past, when
lan-to-lan meshing
over ethernet, the BATMAN status page still shows nodes being
connected via wlan interfaces.
BMX6 instead has br-lan as via-device. Is this normal? Can I verify
the routing is being done correctly, via ethernet, and in the most
efficient way, with a trace route for example, or in any other way?
Actually, meshing is done via all the interfaces it has... and which
one it chooses depends on the metric of the meshing algorithm (BMX6 and
Batman-adv have metric algorithms, but don't know how they work... but
for sure they choose cable all the time).