8 Apr
2014
8 Apr
'14
6:21 a.m.
Hi
I heard an presentation last year in berlin about libre mesh. I was amazed about the idea
to use clounds and a l3 routing protocol. I talked a bit later with Pau about a netsplit
problem where one cloud is split up. Then alfred isn't synchonizing, so that the dhcp
can't know wich ip is already in use. Is the problem resolved or further discussed?
Tim
(Freifunk Franken)
8 Apr
8 Apr
8:49 a.m.
It is a hard problem. If the L2 cloud split, you cannot sync the DHCP
servers. And once the cloud join afain, I don't know how the dhcp leases
file will became.
I quick/dirty solution would be to split the DHCP servers range. So
instead of /24, give /21 or so and each DHCP server offers a different
/24. However I don't know if it makes sense to break the cleanness of
the solution to solve this case.
Maybe (maybe...) dnsmasq can solve this by detecting duplicate addresses
and sending a DHCP renew to the affected clients.
@Gui, you are our dnsmasq guy, what do you think?
On 08/04/14 08:21, Tim Niemeyer wrote:
Hi
I heard an presentation last year in berlin about libre mesh. I was amazed about the idea
to use clounds and a l3 routing protocol. I talked a bit later with Pau about a netsplit
problem where one cloud is split up. Then alfred isn't synchonizing, so that the dhcp
can't know wich ip is already in use. Is the problem resolved or further discussed?
Tim
(Freifunk Franken)
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
--
./p4u
3:12 p.m.
Wouldn't you just do dhcp forwarding?
Host dhcp in the network core. So maybe a few dozen l2 clouds for a city, run an HA pair
of dhcp server virtual machines in Colo where the bmx router is?
That's how I do data center networks. L3 core with dns/dhcp etc and l2 edge with lots
of vlans .
On April 8, 2014 3:49:13 AM CDT, Pau <pau(a)dabax.net> wrote:
It is a hard problem. If the L2 cloud split, you cannot
sync the DHCP
servers. And once the cloud join afain, I don't know how the dhcp
leases
file will became.
I quick/dirty solution would be to split the DHCP servers range. So
instead of /24, give /21 or so and each DHCP server offers a different
/24. However I don't know if it makes sense to break the cleanness of
the solution to solve this case.
Maybe (maybe...) dnsmasq can solve this by detecting duplicate
addresses
and sending a DHCP renew to the affected clients.
@Gui, you are our dnsmasq guy, what do you think?
On 08/04/14 08:21, Tim Niemeyer wrote:
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi
I heard an presentation last year in berlin about libre mesh. I was
amazed about
the idea to use clounds and a l3 routing protocol. I
talked a bit later with Pau about a netsplit problem where one cloud is
split up. Then alfred isn't synchonizing, so that the dhcp can't know
wich ip is already in use. Is the problem resolved or further
discussed?
Tim
(Freifunk Franken)
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
--
./p4u
------------------------------------------------------------------------
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev 
4:41 p.m.
On Tuesday 08 April 2014 10:12:42 Charles N Wyble wrote:
Wouldn't you just do dhcp forwarding?
To forward who ?
Host dhcp in the network core.
Communty networks nodes are all "core"
So maybe a few dozen l2 clouds for a city,
run an HA pair of dhcp server virtual machines in Colo where the bmx router
is?
That's how I do data center networks. L3 core with dns/dhcp etc and l2 edge
with lots of vlans .
This seems more likely how an enterprise network works, community network are
completely another things, no central managment, no central power, no central
infrastructure, no centrar dhcp server...
libre-mesh aims to be completely distributed so there is no single point of
failure.
About the net split and rejoin it seems to me quite a corner case, but also if
shIt happens it shouldn't be a big problem also because dnsmasq give an ip
based on the client data, so it is unlikely that it assign the same address on
two temporarly splitted part of the net.
In anycase we might consider this casuality in future, now we are still
developing basic stuff, but if anyone wanna provide some patch would be
welcomed :)
5:42 p.m.
The L2 domain should never keep running split, there's no clean way of merging that
again.
Option 1: never split. Use a backup l2 vpn between all border gateways, so that they can
reach each other in the event of an internal mesh split. Traffic will flow between the two
segments over the internet, with limited bandwidth. It should be configured with minimum
priority so that it's never used under normal circumstances. Ninux.org pdf detailing
the network diagram implements this. It's on ninux blog post dated 2012 ipv6 day.
Idea 2: fencing. If one of the two segments happen to be left without gateways, it might
turn off dhcp servers, or throw away the given (temp, short-timed) leases when the split
dissolves (a gateway reappears)
Daydream 3: maybe none of this is a problem, with our hybrid setup... batman only cares
about macs (and they are unique), and bmx6 routes on the first hop out, so there's a
chance having duplicate ipv4 addresses for some time is not really a conflict? (?)
Red herring 4/6: dhcp database? I thought we were using stateless RA! I don't really
get what you people are talking about. There's no sync needed, ips are autoconfigured
by hosts themselves!
:P
On April 8, 2014 5:49:13 AM GMT-03:00, Pau <pau(a)dabax.net> wrote:
It is a hard problem. If the L2 cloud split, you cannot
sync the DHCP
servers. And once the cloud join afain, I don't know how the dhcp
leases
file will became.
I quick/dirty solution would be to split the DHCP servers range. So
instead of /24, give /21 or so and each DHCP server offers a different
/24. However I don't know if it makes sense to break the cleanness of
the solution to solve this case.
Maybe (maybe...) dnsmasq can solve this by detecting duplicate
addresses
and sending a DHCP renew to the affected clients.
@Gui, you are our dnsmasq guy, what do you think?
On 08/04/14 08:21, Tim Niemeyer wrote:
Hi
I heard an presentation last year in berlin about libre mesh. I was
amazed about
the idea to use clounds and a l3 routing protocol. I
talked a bit later with Pau about a netsplit problem where one cloud is
split up. Then alfred isn't synchonizing, so that the dhcp can't know
wich ip is already in use. Is the problem resolved or further
discussed?
>
> Tim
> (Freifunk Franken)
> _______________________________________________
> Dev mailing list
> Dev(a)lists.libre-mesh.org
> https://lists.libre-mesh.org/mailman/listinfo/dev
>
10 Apr
10 Apr
5:56 a.m.
Hey
Am 8. April 2014 19:42, schrieb Gui Iribarren:
The L2 domain should never keep running split,
there's no clean way of merging that again.
Option 1: never split. Use a backup l2 vpn between all border gateways, so that they can
reach each other in the event of an internal mesh split. Traffic will flow between the two
segments over the internet, with limited bandwidth. It should be configured with minimum
priority so that it's never used under normal circumstances. Ninux.org pdf detailing
the network diagram implements this. It's on ninux blog post dated 2012 ipv6 day.
I don't thing this is realistic, imho someone could reboot a router for service or a
defect mircowave kills a good working link.
Idea 2: fencing. If one of the two segments happen to be left without gateways, it might
turn off dhcp servers, or throw away the given (temp, short-timed) leases when the split
dissolves (a gateway reappears)
Daydream 3: maybe none of this is a problem, with our hybrid setup... batman only cares
about macs (and they are unique), and bmx6 routes on the first hop out, so there's a
chance having duplicate ipv4 addresses for some time is not really a conflict? (?)
Sounds, if you make some kind of NAT between the hole network and a cloud? Is the
backroute possible with this? I thought the backroute can be over a different
network-to-cloud router. Those wouldn't know about the existing connections over
nat.
Red herring 4/6: dhcp database? I thought we were using stateless RA! I don't really
get what you people are talking about. There's no sync needed, ips are autoconfigured
by hosts themselves!
Was there an evaluation wich client devices can work with ipv6 only? Maybe your herring
isn't so far. :)
Tim
:P
On April 8, 2014 5:49:13 AM GMT-03:00, Pau <pau(a)dabax.net> wrote:
It is a hard problem. If the L2 cloud split, you
cannot sync the DHCP
servers. And once the cloud join afain, I don't know how the dhcp
leases
file will became.
I quick/dirty solution would be to split the DHCP servers range. So
instead of /24, give /21 or so and each DHCP server offers a different
/24. However I don't know if it makes sense to break the cleanness of
the solution to solve this case.
Maybe (maybe...) dnsmasq can solve this by detecting duplicate
addresses
and sending a DHCP renew to the affected clients.
@Gui, you are our dnsmasq guy, what do you think?
On 08/04/14 08:21, Tim Niemeyer wrote:
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev Hi
I heard an presentation last year in berlin about libre mesh. I was
amazed about
the idea to use clounds and a l3 routing protocol. I
talked a bit later with Pau about a netsplit problem where one cloud is
split up. Then alfred isn't synchonizing, so that the dhcp can't know
wich ip is already in use. Is the problem resolved or further
discussed?
>
> Tim
> (Freifunk Franken)
> _______________________________________________
> Dev mailing list
> Dev(a)lists.libre-mesh.org
> https://lists.libre-mesh.org/mailman/listinfo/dev
> 
12:20 p.m.
----- Mensaje original -----
De: "Gioacchino Mazzurco"
<gio(a)eigenlab.org>
Para: dev(a)lists.libre-mesh.org
Enviados: Jueves, 10 de Abril 2014 13:48:17
Asunto: Re: [lime-dev] L2 netsplit
On Thursday 10 April 2014 07:56:21 Tim Niemeyer wrote:
Absolutely, Libre-mesh networks ARE 100% real Internet networks.
http://codigo-sur.net/article/las-redes-libres-y-la-ipv6-como-medio-para-ll…
Sounds, if you make some kind of NAT between the
hole network and a
cloud?
One of LiMe promises is no NAT 
11 Apr
11 Apr
3 p.m.
New subject: nuevo miembro en la lista
Good day for all!
I start to participate of mailist. My name is capo, I'm sysadmin of
lorea.org and part of group of informatics of Cooperativa Integral
Catalana (CIC), specified working as sysadmin of the project
aureasocial.org, here, we soon begin to implement a libre-mesh network
for have connection inside de building
For the deployment I have:
5 TL-WDR 3600
2 TL-WDR 4300
I don't sure what is the better place to download the firmware, I see
that can use the chef for compile but in the chef of altermundi and qmp
I see diferents release for compile the firmware.
I think now have several options, no?
qmp and altermesh develop in parallel?
kisses for all
capo
15 Apr
15 Apr
9:45 a.m.
New subject: Libre-mesh firmware from chef (was: "nuevo miembro en la lista")
Wellcome Capo!
Chefmasters: can we give a answer to Capo?
He's searching Libre-mesh firmware to flash on TP-Link WDR
I can recommend him to use our firmware in Garraf and change data in some lines UCI (Capo
has level to do it), but I think Chef is ready to just put name, it isn't?
Nico, Guido: which Chef, which revision, which "based on"?
Thanks.
----- Mensaje original -----
De: "kaneda" <kaneda(a)cooperativa.cat>
Para: dev(a)lists.libre-mesh.org
Enviados: Viernes, 11 de Abril 2014 17:00:26
Asunto: [lime-dev] nuevo miembro en la lista
Good day for all!
I start to participate of mailist. My name is capo, I'm sysadmin of
lorea.org and part of group of informatics of Cooperativa Integral
Catalana (CIC), specified working as sysadmin of the project
aureasocial.org, here, we soon begin to implement a libre-mesh
network
for have connection inside de building
For the deployment I have:
5 TL-WDR 3600
2 TL-WDR 4300
I don't sure what is the better place to download the firmware, I see
that can use the chef for compile but in the chef of altermundi and
qmp
I see diferents release for compile the firmware.
I think now have several options, no?
qmp and altermesh develop in parallel?
kisses for all
capo
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
12:43 p.m.
New subject: Libre-mesh firmware from chef
You can use lime-build to build your own firmware:
Clone the git repo on: https://github.com/libre-mesh/lime-build
And then type "make T=ar71xx"
Than should generate all ar71xx images for you.
On 15/04/14 11:45, al wrote:
Wellcome Capo!
Chefmasters: can we give a answer to Capo?
He's searching Libre-mesh firmware to flash on TP-Link WDR
I can recommend him to use our firmware in Garraf and change data in some lines UCI (Capo
has level to do it), but I think Chef is ready to just put name, it isn't?
Nico, Guido: which Chef, which revision, which "based on"?
Thanks.
----- Mensaje original -----
--
./p4u
De: "kaneda"
<kaneda(a)cooperativa.cat>
Para: dev(a)lists.libre-mesh.org
Enviados: Viernes, 11 de Abril 2014 17:00:26
Asunto: [lime-dev] nuevo miembro en la lista
Good day for all!
I start to participate of mailist. My name is capo, I'm sysadmin of
lorea.org and part of group of informatics of Cooperativa Integral
Catalana (CIC), specified working as sysadmin of the project
aureasocial.org, here, we soon begin to implement a libre-mesh
network
for have connection inside de building
For the deployment I have:
5 TL-WDR 3600
2 TL-WDR 4300
I don't sure what is the better place to download the firmware, I see
that can use the chef for compile but in the chef of altermundi and
qmp
I see diferents release for compile the firmware.
I think now have several options, no?
qmp and altermesh develop in parallel?
kisses for all
capo
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
5:50 p.m.
New subject: nuevo miembro en la lista
On Friday 11 April 2014 17:00:26 kaneda wrote:
5 TL-WDR 3600
2 TL-WDR 4300
You can find fresh images with default settings here
http://test.ninux.org/~gioacchino/openwrt/lime/bin/ar71xx/
I think you'll need to edit some config, but nothing difficult, i am waiting some
tl-wdr3600 arriving at my home then i can refine the firmware to work out of the
box (it should already do but i havent' tested)
16 Apr
16 Apr
1:52 a.m.
New subject: nuevo miembro en la lista
Ok, so you can not get your essid on firmware like you can get it with chef. But only need
to use this "justoneclick" for your network based on "justoneclick" in
garraflliure.guifi.net mesh network (after flashing with generic Libre-mesh Gioacchino
offer to you):
http://ca.wiki.guifi.net/wiki/Garraflliure.guifi.net
You can use directly same "Part fixa", but please change IP for "Part
variable" with IP and range 10.1.120.0/21 (is IP for your neighbourhood). I'm
going to keep them for you.
You have 7 routers, so 10.1.120.2/21 for first one, 10.1.120.33/21 for second one,
10.1.120.65/21,... plus 32 each one (10.1.120.1 is free for anygw purposes)
In IPv6, please use
uci set lime.network.main_ipv6_address=2a00:1508:a01:8400::2/64
in first one
2nd: 2a00:1508:a01:8400::33/64
3rd: 2a00:1508:a01:8400::65/64
...
You need to do it in each router. You'll have routed IPs inside guifi.net soon.
It is not an "elegant" way to do it, but it is just one to make it work before
Chef will be fully functional.
----- Mensaje original -----
De: "Gioacchino Mazzurco"
<gio(a)eigenlab.org>
Para: dev(a)lists.libre-mesh.org
Enviados: Martes, 15 de Abril 2014 19:50:52
Asunto: Re: [lime-dev] nuevo miembro en la lista
On Friday 11 April 2014 17:00:26 kaneda wrote:
5 TL-WDR 3600
2 TL-WDR 4300
You can find fresh images with default settings here
http://test.ninux.org/~gioacchino/openwrt/lime/bin/ar71xx/
I think you'll need to edit some config, but nothing difficult, i am
waiting some
tl-wdr3600 arriving at my home then i can refine the firmware to work
out of the
box (it should already do but i havent' tested)
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
17 Apr
17 Apr
12:44 a.m.
New subject: nuevo miembro en la lista
I have received tl-wdr3600 so i have done an adjuntive "un solo click" specific
for this device, from what openwrt wiki says tl-wdr4300 should work with the
same "un solo click" but i didn't got one to test it
this script just configure properly switch and vlans to avoid the switch dirver
bugs
http://test.ninux.org/~gioacchino/openwrt/un_solo_click-wdr3600
In the script these two variable are initializad as
meshPorts="1"
lanPorts="2 3 4 5"
change those two variables according to your necessity
18 Apr
18 Apr
9:06 a.m.
New subject: nuevo miembro en la lista
Ok, Capo, now you have quick fix for your issue with lan ports you told me yesterday.
Thanks a lot, Gio!
----- Mensaje original -----
De: "Gioacchino Mazzurco"
<gio(a)eigenlab.org>
Para: "libre-mesh developement" <dev(a)lists.libre-mesh.org>
Enviados: Jueves, 17 de Abril 2014 2:44:40
Asunto: Re: [lime-dev] nuevo miembro en la lista
I have received tl-wdr3600 so i have done an adjuntive "un solo
click" specific
for this device, from what openwrt wiki says tl-wdr4300 should work
with the
same "un solo click" but i didn't got one to test it
this script just configure properly switch and vlans to avoid the
switch dirver
bugs
http://test.ninux.org/~gioacchino/openwrt/un_solo_click-wdr3600
In the script these two variable are initializad as
meshPorts="1"
lanPorts="2 3 4 5"
change those two variables according to your necessity
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
10 Apr
10 Apr
5:54 a.m.
Hi
Am 8. April 2014 10:49, schrieb Pau:
It is a hard problem. If the L2 cloud split, you
cannot sync the DHCP
servers. And once the cloud join afain, I don't know how the dhcp leases
file will became.
I quick/dirty solution would be to split the DHCP servers range. So
instead of /24, give /21 or so and each DHCP server offers a different
/24. However I don't know if it makes sense to break the cleanness of
the solution to solve this case.
Yep, i think thats the only real solution. IMHO
it's enough to have 2-3 dhcpd's in one cloud. So a /24 could be easily split
into 1-127 and 128-254. But that needs to be configured. People need to speak each other
within a cloud and nobody should run an faulty dhcpd config.
Hm.. btw.. i have to took at the lm config frontend.
Tim
Maybe (maybe...) dnsmasq can solve this by detecting duplicate addresses
and sending a DHCP renew to the affected clients.
@Gui, you are our dnsmasq guy, what do you think?
On 08/04/14 08:21, Tim Niemeyer wrote:
Hi
I heard an presentation last year in berlin about libre mesh. I was amazed about the idea
to use clounds and a l3 routing protocol. I talked a bit later with Pau about a netsplit
problem where one cloud is split up. Then alfred isn't synchonizing, so that the dhcp
can't know wich ip is already in use. Is the problem resolved or further discussed?
Tim
(Freifunk Franken)
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
--
./p4u
_______________________________________________
Dev mailing list
Dev(a)lists.libre-mesh.org
https://lists.libre-mesh.org/mailman/listinfo/dev
3900
days inactive
3910
days old
15 comments
7 participants
participants (7)
-
al -
Charles N Wyble -
Gioacchino Mazzurco -
Gui Iribarren -
kaneda -
Pau -
Tim Niemeyer