2 Jul
2017
2 Jul
'17
4:30 p.m.
Hi all
I've finally had the chance to test out what some of you were saying about LiMe doing
mesh over ethernet using Lan - to - Lan connections.
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].
Since the lite and the bullet only have one ethernet port, stock lime configures it as a
Lan port, with 10.13.0.x DHCP being handed out over it, and so on. So from the switch I
have two cables going to wan ports [1043 and C7] and two going to "Lan" ports
[lite and bullet] since that's what their default behavior is.
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.
I still don't understand how a network with not one, but several DHCP servers can
work correctly. I seem to understand that LiMe can ignore such advertisements on its Lan
ports, but what happens to a client that is on such wired network, say, with another cable
from the switch I mentioned? Won't he receive advertisements from all servers at
once? Does LiMe terminate advertisements upstream-bound when it detects others?
And in the case of the 1043 and C7 that are using their wan ports, how does LiMe
understand when it should mesh with other devices over it and when it should become a DHCP
client to an upstream non-mesh router in a traditional way?
And how do I solve this DHCP leaking from ISP router to LiMe routers' clients in the
case of the lite and bullet?
Thank you in advance
Nk
2 Jul
2 Jul
5:02 p.m.
On Sun, 2017-07-02 at 18:30 +0200, Nikksno via lime-users wrote:
Hi all
I've finally had the chance to test out what some of you were saying
about LiMe doing mesh over ethernet using Lan - to - Lan connections.
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].
Since the lite and the bullet only have one ethernet port, stock lime
configures it as a Lan port, with 10.13.0.x DHCP being handed out
over it, and so on. So from the switch I have two cables going to wan
ports [1043 and C7] and two going to "Lan" ports [lite and bullet]
since that's what their default behavior is.
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.
I still don't understand how a network with not
one, but several DHCP
servers can work correctly.
LibreMesh DHCPs can live together because they know of their
presence... the external DHCP should be connected to one single Mesh
node.
Mesh nodes that belong to the same network (the AC Lites, the Archer C7
and 1034ND) can connect between each other through the LAN ports.
Your ISP router should be connected to the WAN port of any of those
devices.
5:31 p.m.
Thank you Nicolas, so what you're saying is that instead of connecting the ISP router
to the switch, and then having cables from the switch going either to the wan port of LiMe
routers [if they have one] or to their Lan port [if it's the only one they have], I
should connect the ISP router directly to the wan port of a LiMe router that has both,
such as a 1043 or a C7, and then connecting all other nodes to that device's Lan
ports, or, should they not suffice, draw a cable from that router's LAN port to the
switch, and then connect all other devices to the switch, is this correct?
This way, you say, only the first LiMe router receives the external DHCP. But still there
are multiple advertisements. Is this not a problem any more since they are all the same,
is this your point?
But still, how can all LiMe routers on that wired network have the 10.13.0.1 IP at that
point though?
Thanks again
Nk
On July 2, 2017 7:02:52 PM GMT+02:00, Nicolas Pace <nico(a)libre.ws> wrote:
On Sun, 2017-07-02 at 18:30 +0200, Nikksno via
lime-users wrote:
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi all
I've finally had the chance to test out what some of you were saying
about LiMe doing mesh over ethernet using Lan - to - Lan connections.
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].
Since the lite and the bullet only have one ethernet port, stock lime
configures it as a Lan port, with 10.13.0.x DHCP being handed out
over it, and so on. So from the switch I have two cables going to wan
ports [1043 and C7] and two going to "Lan" ports [lite and bullet]
since that's what their default behavior is.
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.
I still don't understand how a network with
not one, but several DHCP
servers can work correctly.
LibreMesh DHCPs can live together because they know of their
presence... the external DHCP should be connected to one single Mesh
node.
Mesh nodes that belong to the same network (the AC Lites, the Archer C7
and 1034ND) can connect between each other through the LAN ports.
Your ISP router should be connected to the WAN port of any of those
devices.
3 Jul
3 Jul
8:20 a.m.
On July 2, 2017 8:31:44 PM GMT+03:00, Nk via lime-users <lime-users@lis
ts.libremesh.org> wrote:
Thank you Nicolas, so what you're saying is that
instead of
connecting
the ISP router to the switch, and then having cables from the switch
going either to the wan port of LiMe routers [if they have one] or to
their Lan port [if it's the only one they have], I should connect the
ISP router directly to the wan port of a LiMe router that has both,
such as a 1043 or a C7, and then connecting all other nodes to that
device's Lan ports, or, should they not suffice, draw a cable from
that
router's LAN port to the switch, and then connect all other devices
to
the switch, is this correct?
So, from my point of view, best possible scenario is for all libremesh
routers to be connected via cable through the LAN sockets.
If they are too far to reach via a cable (+100m) i would use Wifi.
This way, you say, only the first LiMe router receives
the external
DHCP. But still there are multiple advertisements.
Not in the same network.
You have one DHCP in the outside network between the ISP Gateway and
the first LibreMesh router, and you have a cloud of LibreMesh DHCP
routers in the other network.
Is this not a
problem any more since they are all the same, is this your point?
Yes
But still, how can all LiMe routers on that wired network have
the 10.13.0.1 IP at that point though?
That is a 'trick' of the LibreMesh Routers... they announce the same
Gateway IP, that is a local IP of each router, to allow Roaming devices
between Access Points.
4 Jul
4 Jul
9:22 a.m.
Thank you Nicolas,
What I mean is that if I do the setup ad you said, so ISP ROUTER Lan [eth] First LiMe
router Wan and then First LiMe router Lan [eth] other LiMe router's LAN ports, if I
connect a wired client [say a desktop pc] to that huge Lan, it will receive several DHCP
broadcasts. This might not be an issue as you're saying since they all advertise the
same stuff, but I don't understand how all LiMe nodes can apparently respond to
10.13.0.1 on that **wired** network. I know about the trick on the wireless / Lan side of
every node, and I've always found it a genius trick, I just don't understand how
it can work to connect several LANs together over wired, especially since they all try to
have the same IP.
In any event, this setup has an issue whereby DHCP advertisements [if that's what
they're called] of LiMe nodes connected lan-to-lan travel upwards through the wan
port of the first lime node [the one connected to the ISP router via its wan port, as you
suggested] and confuses the ISP router itself, to such point that my ISP router
wasn't managing to connect upstream to the VDSL endpoint, and was not connecting to
the public facing internet. As soon as I disconnected the cable going from the ISP
router's LAN port to the first lime node's wan port, the ISP router started
working again.
Also, as soon as we figure this stuff out, and I understand it [hardest part ;], I
volunteer to write a fully detailed guide on how to design a lime topology so that our
design works all across the world, and deployers like me know how to engineer their
networks.
Thanks again to both of you
Nk
________________________________
From: Nicolas Pace <nico(a)libre.ws>
Sent: Jul 3, 2017 10:20 AM
To: Nk; libremesh users
Subject: Re: [lime-users] DHCP conflicts
On July 2, 2017 8:31:44 PM GMT+03:00, Nk via lime-users <lime-users@lis
ts.libremesh.org> wrote:
Thank you Nicolas, so what you're saying is
that instead of
connecting
the ISP router to the switch, and then having cables from the switch
going either to the wan port of LiMe routers [if they have one] or to
their Lan port [if it's the only one they have], I should connect the
ISP router directly to the wan port of a LiMe router that has both,
such as a 1043 or a C7, and then connecting all other nodes to that
device's Lan ports, or, should they not suffice, draw a cable from
that
router's LAN port to the switch, and then connect all other devices
to
the switch, is this correct?
So, from my point of view, best possible scenario is for all libremesh
routers to be connected via cable through the LAN sockets.
If they are too far to reach via a cable (+100m) i would use Wifi.
This way, you say, only the first LiMe router
receives the external
DHCP. But still there are multiple advertisements.
Not in the same network.
You have one DHCP in the outside network between the ISP Gateway and
the first LibreMesh router, and you have a cloud of LibreMesh DHCP
routers in the other network.
Is this not a
problem any more since they are all the same, is this your point?
Yes
But still, how can all LiMe routers on that wired network have
the 10.13.0.1 IP at that point though?
That is a 'trick' of the LibreMesh Routers... they announce the same
Gateway IP, that is a local IP of each router, to allow Roaming devices
between Access Points.
5 Jul
5 Jul
8:07 a.m.
On Tue, 2017-07-04 at 11:22 +0200, Nikksno via lime-users wrote:
> Also, as soon as we figure this stuff out,
and I understand it
> [hardest part ;], I volunteer to write a fully detailed guide on how
> to design a lime topology so that our design works all across the
> world, and deployers like me know how to engineer their networks.
Great!!!
When you get here, let's coordinate :)
Thank you Nicolas,
What I mean is that if I do the setup ad you said, so ISP ROUTER Lan
[eth] First LiMe router Wan and then First LiMe router Lan [eth]
other LiMe router's LAN ports, if I connect a wired client [say a
desktop pc] to that huge Lan, it will receive several DHCP
broadcasts. This might not be an issue as you're saying since they
all advertise the same stuff, but I don't understand how all LiMe
nodes can apparently respond to 10.13.0.1 on that **wired** network.
I don't have much experience on this, but I guess all send DHCP
responses, all are similar, so the client picks one and announce the
DHCP server which he chose, and that's it.
No matter which router registers the data, as it is a wired network
I guess it will work.... maybe the more experienced guys can comment.
:)
In any event, this setup has an issue whereby DHCP
advertisements [if
that's what they're called] of LiMe nodes connected lan-to-lan travel
upwards through the wan port of the first lime node [the one
connected to the ISP router via its wan port, as you suggested] and
confuses the ISP router itself, to such point that my ISP router
wasn't managing to connect upstream to the VDSL endpoint, and was not
connecting to the public facing internet. As soon as I disconnected
the cable going from the ISP router's LAN port to the first lime
node's wan port, the ISP router started working again.
I guess this should not be happening.
6:28 p.m.
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]
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
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?
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?
I’m available to test any setup if someone can point me in the right direction
Thanks again!
Nk
On July 5, 2017 at 10:07:34 AM, Nicolas Pace (nico(a)libre.ws) wrote:
On Tue, 2017-07-04 at 11:22 +0200, Nikksno via lime-users wrote:
> Also, as soon as we figure this stuff
out, and I understand it
> [hardest part ;], I volunteer to write a fully detailed guide on how
> to design a lime topology so that our design works all across the
> world, and deployers like me know how to engineer their networks.
Great!!!
When you get here, let's coordinate :)
Thank you Nicolas,
What I mean is that if I do the setup ad you said, so ISP ROUTER Lan
[eth] First LiMe router Wan and then First LiMe router Lan [eth]
other LiMe router's LAN ports, if I connect a wired client [say a
desktop pc] to that huge Lan, it will receive several DHCP
broadcasts. This might not be an issue as you're saying since they
all advertise the same stuff, but I don't understand how all LiMe
nodes can apparently respond to 10.13.0.1 on that **wired** network.
I don't have much experience on this, but I guess all send DHCP
responses, all are similar, so the client picks one and announce the
DHCP server which he chose, and that's it.
No matter which router registers the data, as it is a wired network
I guess it will work.... maybe the more experienced guys can comment.
:)
In any event, this setup has an issue whereby DHCP
advertisements [if
that's what they're called] of LiMe nodes connected lan-to-lan travel
upwards through the wan port of the first lime node [the one
connected to the ISP router via its wan port, as you suggested] and
confuses the ISP router itself, to such point that my ISP router
wasn't managing to connect upstream to the VDSL endpoint, and was not
connecting to the public facing internet. As soon as I disconnected
the cable going from the ISP router's LAN port to the first lime
node's wan port, the ISP router started working again.
I guess this should not be happening.
9 Jul
9 Jul
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).
21 Aug
21 Aug
2:34 p.m.
On 07/09/2017 05:38 PM, Nicolas Pace wrote:
On Wed, 2017-07-05 at 20:28 +0200, Nk via lime-users
wrote>> 3] What Ilario said – quote here:
I think I totally misunderstood the network setup Nk described in his
first email... Sorry for that.
For a situation like that the more sensible solution is to configure
also Bullet and Lite AC ethernet ports as WAN, as explained here under
"Specific network options":
http://libremesh.org/docs/en_changing_network_behavior.html
Solving this "issue" could be nice anyway, do you think it could avoid
loops generated by (up to now unsupported) LiMe-WAN to LiMe-LAN connections?
This issue should be related:
https://github.com/libremesh/lime-packages/issues/172
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.
3:10 p.m.
Hi Ilario
Thanks for referencing this on the GitHub issue and for re-reading my situation.
Just to make sure we’re on the same page, the two LiMe nodes are connected LAN-to-LAN.
To quote from my comment on GitHub:
I don't know if my issue is directly related, but it is the "first LiMe
node" that lets DHCP "broadcasts" [terminology might be incorrect] travel
from inside the LAN-to-LAN LiMe "hyperlan" outside through the wan port and into
the ISP router. The only "requirements" for such error are only two in my
tests:
1] multiple [two are sufficient] LiMe nodes connected LAN-to-LAN
2] a "vulnerable" ISP router to which one of the LiMe nodes is connected
[by vulnerable i mean an ISP router that lets DHCP "broadcasts" coming from
inside the LAN on its LAN port influence its decisions on how to connect to the ISP
"backbone" on its WAN side]
I'm running stock LiMe and still have this issue.
Thanks to all!
Nk
On 21 Aug 2017, 16:34 +0200, Ilario Gelmetti <iochesonome(a)gmail.com>om>, wrote:
On 07/09/2017 05:38 PM, Nicolas Pace wrote:
On Wed, 2017-07-05 at 20:28 +0200, Nk via
lime-users wrote>> 3] What Ilario said – quote here:
I think I totally misunderstood the network setup Nk described in his
first email... Sorry for that.
For a situation like that the more sensible solution is to configure
also Bullet and Lite AC ethernet ports as WAN, as explained here under
"Specific network options":
http://libremesh.org/docs/en_changing_network_behavior.html
Solving this "issue" could be nice anyway, do you think it could avoid
loops generated by (up to now unsupported) LiMe-WAN to LiMe-LAN connections?
This issue should be related:
https://github.com/libremesh/lime-packages/issues/172
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
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. 
12 Aug
12 Aug
6:41 p.m.
On 07/04/17 11:22, Nikksno via lime-users wrote:
Thank you Nicolas,
What I mean is that if I do the setup ad you said, so ISP ROUTER Lan
[eth] First LiMe router Wan and then First LiMe router Lan [eth] other
LiMe router's LAN ports, if I connect a wired client [say a desktop
pc] to that huge Lan, it will receive several DHCP broadcasts. This
might not be an issue as you're saying since they all advertise the
same stuff, but I don't understand how all LiMe nodes can apparently
respond to 10.13.0.1 on that **wired** network. I know about the trick
on the wireless / Lan side of every node, and I've always found it a
genius trick, I just don't understand how it can work to connect
several LANs together over wired, especially since they all try to
have the same IP.
As you probably already know, all lime nodes have the same MAC (anyMAC)
and the same IP (anyIP), we call this "any gateway" or anyGW.
What happens if two nodes and a client are wired connected to the same
LAN and a client sends a packet to the network gateway?
If two nodes are connected through an Ethernet switch, as both of them
have the same MAC the switch will decide to which port each packes is
sent. Usually the nearest is the one with more possibilities for receive
the packet, however it might change in some moment. Anyway it won't be a
problem, batman-adv takes care of the layer two (for the WiFi mesh) and
it's bridged to the wired br-lan network, so the packet will arrive to
its destination and also the reply will arrive to the client, it does
not matter via which libremesh node (the first one which drops the
packet to the layer2 network).
There are only two scenarios where this behavior (switch changes the
port for the anyMAC address) will be a problem:
1) TCP connections from the client to the node connected to the switch
(session will be lost, but this cases are not very common and you can
always use the uniq IP to reach a libremesh gateway).
2) If the two libremesh nodes connected to the same switch are using
different mesh gateways to the Internet the TCP connections will be
lost. However this is a strange case cause bmx6 decides the gw following
the same heuristics and both nodes are very close.
Hope it is clear enough, you might find some more information on the
comments of this discussion:
https://github.com/libremesh/lime-packages/issues/108
In any event, this setup has an issue whereby DHCP
advertisements [if
that's what they're called] of LiMe nodes connected lan-to-lan travel
upwards through the wan port of the first lime node [the one connected
to the ISP router via its wan port, as you suggested] and confuses the
ISP router itself, to such point that my ISP router wasn't managing to
connect upstream to the VDSL endpoint, and was not connecting to the
public facing internet. As soon as I disconnected the cable going from
the ISP router's LAN port to the first lime node's wan port, the ISP
router started working again.
Sorry but I don't understand this behavior :/
Also, as soon as we figure this stuff out, and I understand it
[hardest part ;], I volunteer to write a fully detailed guide on how
to design a lime topology so that our design works all across the
world, and deployers like me know how to engineer their networks.
that would be great :)
Thanks again to both of you
Nk
------------------------------------------------------------------------
*From:* Nicolas Pace <nico(a)libre.ws>
*Sent:* Jul 3, 2017 10:20 AM
*To:* Nk; libremesh users
*Subject:* Re: [lime-users] DHCP conflicts
On July 2, 2017 8:31:44 PM GMT+03:00, Nk via lime-users wrote: >
Thank you Nicolas, so what you're saying is that instead of >
connecting > the ISP router to the switch, and then having cables
from the switch > going either to the wan port of LiMe routers [if
they have one] or to > their Lan port [if it's the only one they
have], I should connect the > ISP router directly to the wan port
of a LiMe router that has both, > such as a 1043 or a C7, and then
connecting all other nodes to that > device's Lan ports, or,
should they not suffice, draw a cable from > that > router's LAN
port to the switch, and then connect all other devices > to > the
switch, is this correct? So, from my point of view, best possible
scenario is for all libremesh routers to be connected via cable
through the LAN sockets. If they are too far to reach via a cable
(+100m) i would use Wifi. > This way, you say, only the first LiMe
router receives the external > DHCP. But still there are multiple
advertisements. Not in the same network. You have one DHCP in the
outside network between the ISP Gateway and the first LibreMesh
router, and you have a cloud of LibreMesh DHCP routers in the
other network. > Is this not a > problem any more since they are
all the same, is this your point? Yes > > But still, how can all
LiMe routers on that wired network have > the 10.13.0.1 IP at that
point though? That is a 'trick' of the LibreMesh Routers... they
announce the same Gateway IP, that is a local IP of each router,
to allow Roaming devices between Access Points.
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
13 Aug
13 Aug
9:03 a.m.
Hi p4u
Thanks, it is clear now.
Is the issue not clear to you or have you never experienced it / can't reproduce it?
I will explain in further detail, otherwise please check my older email where it was more
carefully explained.
It is an issue, an important one I think.
Thank you
Nk
On August 12, 2017 8:41:44 PM GMT+02:00, pau <pau(a)dabax.net> wrote:
On 07/04/17 11:22, Nikksno via lime-users wrote:
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Thank you Nicolas,
What I mean is that if I do the setup ad you said, so ISP ROUTER Lan
[eth] First LiMe router Wan and then First LiMe router Lan [eth]
other
LiMe router's LAN ports, if I connect a
wired client [say a desktop
pc] to that huge Lan, it will receive several DHCP broadcasts. This
might not be an issue as you're saying since they all advertise the
same stuff, but I don't understand how all LiMe nodes can apparently
respond to 10.13.0.1 on that **wired** network. I know about the
trick
on the wireless / Lan side of every node, and
I've always found it a
genius trick, I just don't understand how it can work to connect
several LANs together over wired, especially since they all try to
have the same IP.
As you probably already know, all lime nodes have the same MAC (anyMAC)
and the same IP (anyIP), we call this "any gateway" or anyGW.
What happens if two nodes and a client are wired connected to the same
LAN and a client sends a packet to the network gateway?
If two nodes are connected through an Ethernet switch, as both of them
have the same MAC the switch will decide to which port each packes is
sent. Usually the nearest is the one with more possibilities for
receive
the packet, however it might change in some moment. Anyway it won't be
a
problem, batman-adv takes care of the layer two (for the WiFi mesh) and
it's bridged to the wired br-lan network, so the packet will arrive to
its destination and also the reply will arrive to the client, it does
not matter via which libremesh node (the first one which drops the
packet to the layer2 network).
There are only two scenarios where this behavior (switch changes the
port for the anyMAC address) will be a problem:
1) TCP connections from the client to the node connected to the switch
(session will be lost, but this cases are not very common and you can
always use the uniq IP to reach a libremesh gateway).
2) If the two libremesh nodes connected to the same switch are using
different mesh gateways to the Internet the TCP connections will be
lost. However this is a strange case cause bmx6 decides the gw
following
the same heuristics and both nodes are very close.
Hope it is clear enough, you might find some more information on the
comments of this discussion:
https://github.com/libremesh/lime-packages/issues/108
In any event, this setup has an issue whereby
DHCP advertisements [if
that's what they're called] of LiMe nodes connected lan-to-lan travel
upwards through the wan port of the first lime node [the one
connected
to the ISP router via its wan port, as you
suggested] and confuses
the
ISP router itself, to such point that my ISP
router wasn't managing
to
connect upstream to the VDSL endpoint, and was
not connecting to the
public facing internet. As soon as I disconnected the cable going
from
the ISP router's LAN port to the first lime
node's wan port, the ISP
router started working again.
Sorry but I don't understand this behavior :/
Also, as soon as we figure this stuff out, and I understand it
[hardest part ;], I volunteer to write a fully detailed guide on how
to design a lime topology so that our design works all across the
world, and deployers like me know how to engineer their networks.
that would be great :)
Thanks again to both of you
Nk
------------------------------------------------------------------------
*From:* Nicolas Pace <nico(a)libre.ws>
*Sent:* Jul 3, 2017 10:20 AM
*To:* Nk; libremesh users
*Subject:* Re: [lime-users] DHCP conflicts
On July 2, 2017 8:31:44 PM GMT+03:00, Nk via lime-users wrote: >
Thank you Nicolas, so what you're saying is that instead of >
connecting > the ISP router to the switch, and then having cables
from the switch > going either to the wan port of LiMe routers
[if
they have one] or to > their Lan port [if
it's the only one they
have], I should connect the > ISP router directly to the wan port
of a LiMe router that has both, > such as a 1043 or a C7, and
then
connecting all other nodes to that >
device's Lan ports, or,
should they not suffice, draw a cable from > that > router's LAN
port to the switch, and then connect all other devices > to > the
switch, is this correct? So, from my point of view, best possible
scenario is for all libremesh routers to be connected via cable
through the LAN sockets. If they are too far to reach via a cable
(+100m) i would use Wifi. > This way, you say, only the first
LiMe
router receives the external > DHCP. But
still there are multiple
advertisements. Not in the same network. You have one DHCP in the
outside network between the ISP Gateway and the first LibreMesh
router, and you have a cloud of LibreMesh DHCP routers in the
other network. > Is this not a > problem any more since they are
all the same, is this your point? Yes > > But still, how can all
LiMe routers on that wired network have > the 10.13.0.1 IP at
that
> point though? That is a 'trick' of the LibreMesh Routers... they
> announce the same Gateway IP, that is a local IP of each router,
> to allow Roaming devices between Access Points.
>
>
>
> _______________________________________________
> lime-users mailing list
> lime-users(a)lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users
3 Jul
3 Jul
2:39 p.m.
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:
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?
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. 
11:19 p.m.
On 07/03/2017 11:39 AM, Ilario wrote:
2017-07-02 19:02 GMT+02:00 Nicolas Pace
<nico(a)libre.ws>ws>:
This is already the default behavior... is it not?
Since we are setting batman gw-mode to client.
On Sun, 2017-07-02 at 18:30 +0200, Nikksno via
lime-users wrote:
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? 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. 
3 Aug
3 Aug
11:48 a.m.
On 04/07/17 01:19, Nicolás Echániz wrote:
On 07/03/2017 11:39 AM, Ilario wrote:
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 :)
2017-07-02 19:02 GMT+02:00 Nicolas Pace
<nico(a)libre.ws>ws>:
This is already the default behavior... is it not?
Since we are setting batman gw-mode to client. On Sun, 2017-07-02 at 18:30 +0200, Nikksno via
lime-users wrote:
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? 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.
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
7 Aug
7 Aug
9:41 a.m.
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:
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 :)
2017-07-02 19:02 GMT+02:00 Nicolas Pace
<nico(a)libre.ws>ws>:
This is already the default behavior... is it not?
Since we are setting batman gw-mode to client. On Sun, 2017-07-02 at 18:30 +0200, Nikksno via
lime-users wrote:
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? 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.
_______________________________________________
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
2688
days inactive
2738
days old
lime-users@lists.libremesh.org
15 comments
8 participants
participants (8)
-
Gui Iribarren -
Ilario -
Ilario Gelmetti
-
Nicolas Pace -
Nicolás Echániz -
Nk -
nk＠os.vu
-
pau