27 Nov
2016
27 Nov
'16
12:08 p.m.
Hi All,
My name is Nicolás, I'm from Argentina and I'm working promoting
community networks while I travel in Latin America... Glad to be part
of this community, and thanks to you all for all you have been doing so
far, it is amazing!!!
I wanted to share with you some of my last work (that I've been
discussing with Nico Echaniz, who suggested to migrate it to here),
about how we can promote the use of local services.
My view about this has been on using local discovery techniques to
identify which local services are around using mdns, and then promote
those services via a captive portal.
There are many services that are already shared in this way (like
printers, media repositories, chat apps) and it is quite easy to add
new ones or index those that are not added manually also.
I have also defined a strategy on how to deploy this on LiMe based on
Nico`s experience on multicast packages (those used by the mDNS
discovery mechanism) on mesh networks (quite a mess for now)... so I
found a workaround for this specific case.
We cound add a daemon to LiMe that permanently scans its local network
searching for services, and shares that information via Alfred.
Together with another daemon that listens to Alfred and adds that
information to the LiMe mDNS Service (Avahi)... that sorts out the
multicast issue and lets us share that valuable information efficiently.
For those services that don't support mDNS we could add an interface on
luci to manually administer them.
Finally, we could add a section on the Captive Portal to show this
information.
What do you think?
Regards,
--
Nicolás Pace
http://www.linkedin.com/in/nickar
1 Dec
1 Dec
11:51 a.m.
In ninux.org we historically tried to take advantage on mDNS/avahi lot of
times, it is a mess and in the end all the time we decided it was too buggy
and bloaty to make use of it...
With time i can look for more info and arguments agains mDNS to forward but
right now i am very busy!
Cheers!!
On Sunday 27 November 2016 09:08:52 nicopace wrote:
Hi All,
My name is Nicolás, I'm from Argentina and I'm working promoting
community networks while I travel in Latin America... Glad to be part
of this community, and thanks to you all for all you have been doing so
far, it is amazing!!!
I wanted to share with you some of my last work (that I've been
discussing with Nico Echaniz, who suggested to migrate it to here),
about how we can promote the use of local services.
My view about this has been on using local discovery techniques to
identify which local services are around using mdns, and then promote
those services via a captive portal.
There are many services that are already shared in this way (like
printers, media repositories, chat apps) and it is quite easy to add
new ones or index those that are not added manually also.
I have also defined a strategy on how to deploy this on LiMe based on
Nico`s experience on multicast packages (those used by the mDNS
discovery mechanism) on mesh networks (quite a mess for now)... so I
found a workaround for this specific case.
We cound add a daemon to LiMe that permanently scans its local network
searching for services, and shares that information via Alfred.
Together with another daemon that listens to Alfred and adds that
information to the LiMe mDNS Service (Avahi)... that sorts out the
multicast issue and lets us share that valuable information efficiently.
For those services that don't support mDNS we could add an interface on
luci to manually administer them.
Finally, we could add a section on the Captive Portal to show this
information.
What do you think?
Regards,
--
Nicolás Pace
http://www.linkedin.com/in/nickar
1:11 p.m.
I agree with Gio, we also tried to use mDNS/avahi in several projects
and it was always a fail, in addition the layer2 dependency is a
restrictions which reduces the possible impact of the services sharing.
An alternative option would be to use the bmx6 SMS plugin [1], which
allows the transfer of small files using the routing packets. Here an
example of usage [2] and the code [3].
Using ALFRED from batman-adv would be also an option. On LiMe we are
already using it for the dhcp leases share system of dnsmasq, but again
it would work only for the cloud (not the entire network). So a kind of
bridge might be implemented.
Would be nice to put some effort here.
Cheers.
[1] https://github.com/axn/bmx6#sms-plugin
[2] http://bmx6.net/projects/bmx6/wiki/Mdns
[3] https://github.com/routek/qMp/tree/testing/packages/bmx6-mdns
On 01/12/16 12:51, Gio wrote:
In ninux.org we historically tried to take advantage
on mDNS/avahi lot of
times, it is a mess and in the end all the time we decided it was too buggy
and bloaty to make use of it...
With time i can look for more info and arguments agains mDNS to forward but
right now i am very busy!
Cheers!!
On Sunday 27 November 2016 09:08:52 nicopace wrote:
--
./p4u
Hi All,
My name is Nicolás, I'm from Argentina and I'm working promoting
community networks while I travel in Latin America... Glad to be part
of this community, and thanks to you all for all you have been doing so
far, it is amazing!!!
I wanted to share with you some of my last work (that I've been
discussing with Nico Echaniz, who suggested to migrate it to here),
about how we can promote the use of local services.
My view about this has been on using local discovery techniques to
identify which local services are around using mdns, and then promote
those services via a captive portal.
There are many services that are already shared in this way (like
printers, media repositories, chat apps) and it is quite easy to add
new ones or index those that are not added manually also.
I have also defined a strategy on how to deploy this on LiMe based on
Nico`s experience on multicast packages (those used by the mDNS
discovery mechanism) on mesh networks (quite a mess for now)... so I
found a workaround for this specific case.
We cound add a daemon to LiMe that permanently scans its local network
searching for services, and shares that information via Alfred.
Together with another daemon that listens to Alfred and adds that
information to the LiMe mDNS Service (Avahi)... that sorts out the
multicast issue and lets us share that valuable information efficiently.
For those services that don't support mDNS we could add an interface on
luci to manually administer them.
Finally, we could add a section on the Captive Portal to show this
information.
What do you think?
Regards,
--
Nicolás Pace
http://www.linkedin.com/in/nickar
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
2:14 p.m.
On 12/01/2016 10:11 AM, Pau wrote:
I agree with Gio, we also tried to use mDNS/avahi in
several projects
and it was always a fail, in addition the layer2 dependency is a
restrictions which reduces the possible impact of the services sharing.
An alternative option would be to use the bmx6 SMS plugin [1], which
allows the transfer of small files using the routing packets. Here an
example of usage [2] and the code [3].
Using ALFRED from batman-adv would be also an option. On LiMe we are
already using it for the dhcp leases share system of dnsmasq, but again
it would work only for the cloud (not the entire network). So a kind of
bridge might be implemented.
Would be nice to put some effort here.
I talked ahout this with nico a bit. We've also had a bad experience
with Avahi in general.
Maybe we can do some brainstorming about what we would like to
accomplish and then share ideas on how to do that.
Nico is motivated to work on this and that's awesome :)
Cheers!
Nico
11:16 p.m.
Ok... I see that you had a bad time using it.
I think it may have been because of how multicast ip packages work in
mesh networks... and that is why i'm proposing to have local mdns cache
servers, that proactively trigger mdns requests to their networks
(locally), and share that information with the rest of the mdns caches
via Alfred.
All mdns traffic would be contained on local networking (no routing
involved).
NicoEchaniz told me that there where some issues with mdns in the past,
but I guess this approach was reasonable... What do you think?
It would be very useful if you Gio and Pau could share a little bit
more about what was your experience with this.
Also, you are right Pau... it would only work on a certain layer... and
it would need something to coordinate with bmx6... but as of now, I
feel that this is a good start.
--
Nicolás Pace
http://www.linkedin.com/in/nickar
On Thu, Dec 1, 2016 at 11:14 AM, Nicolás Echániz
<nicoechaniz(a)altermundi.net> wrote:
On 12/01/2016 10:11 AM, Pau wrote:
I agree with Gio, we also tried to use
mDNS/avahi in several
projects
and it was always a fail, in addition the layer2 dependency is a
restrictions which reduces the possible impact of the services
sharing.
An alternative option would be to use the bmx6 SMS plugin [1], which
allows the transfer of small files using the routing packets. Here
an
example of usage [2] and the code [3].
Using ALFRED from batman-adv would be also an option. On LiMe we are
already using it for the dhcp leases share system of dnsmasq, but
again
it would work only for the cloud (not the entire network). So a
kind of
bridge might be implemented.
Would be nice to put some effort here.
I talked ahout this with nico a bit. We've also had a bad experience
with Avahi in general.
Maybe we can do some brainstorming about what we would like to
accomplish and then share ideas on how to do that.
Nico is motivated to work on this and that's awesome :)
Cheers!
Nico
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev 
2 Dec
2 Dec
8:45 a.m.
Am 2. Dezember 2016 00:16:26 MEZ, schrieb nicopace <nico(a)libre.ws>ws>:
Ok... I see that you had a bad time using it.
I think it may have been because of how multicast ip packages work in
mesh networks... and that is why i'm proposing to have local mdns cache
servers, that proactively trigger mdns requests to their networks
(locally), and share that information with the rest of the mdns caches
via Alfred.
All mdns traffic would be contained on local networking (no routing
involved).
in libremesh, the "local network of each node " is actually the whole town (or
neighborhood). batman-adv creates this extended layer2.
so only option would be to keep the mdns cache confined to the localhost (the router) and
only use it to announce services located on the router.
you could make a webinterface on the router for the user to manually setup extra
announcements, for example a homeserver
(commotion firmware had this)
but at that point, you're basically not using avahi for anything anymore ;)
NicoEchaniz told me that there where some issues with mdns in the past,
but I guess this approach was reasonable... What do you think?
It would be very useful if you Gio and Pau could share a little bit
more about what was your experience with this.
Also, you are right Pau... it would only work on a certain layer... and
it would need something to coordinate with bmx6... but as of now, I
feel that this is a good start.
--
Nicolás Pace
http://www.linkedin.com/in/nickar
On Thu, Dec 1, 2016 at 11:14 AM, Nicolás Echániz
<nicoechaniz(a)altermundi.net> wrote:
------------------------------------------------------------------------
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
On 12/01/2016 10:11 AM, Pau wrote:
> I agree with Gio, we also tried to use mDNS/avahi in several
> projects
> and it was always a fail, in addition the layer2 dependency is a
> restrictions which reduces the possible impact of the services
> sharing.
>
> An alternative option would be to use the bmx6 SMS plugin [1],
which
> allows the transfer of small files using the
routing packets. Here
> an
> example of usage [2] and the code [3].
>
> Using ALFRED from batman-adv would be also an option. On LiMe we
are
already
using it for the dhcp leases share system of dnsmasq, but
again
it would work only for the cloud (not the entire network). So a
kind of
bridge might be implemented.
Would be nice to put some effort here.
I talked ahout this with nico a bit. We've also had a bad experience
with Avahi in general.
Maybe we can do some brainstorming about what we would like to
accomplish and then share ideas on how to do that.
Nico is motivated to work on this and that's awesome :)
Cheers!
Nico
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
11:14 a.m.
On Thursday 01 December 2016 20:16:26 nicopace wrote:
Ok... I see that you had a bad time using it.
I think it may have been because of how multicast ip packages work in
mesh networks... and that is why i'm proposing to have local mdns cache
servers, that proactively trigger mdns requests to their networks
(locally), and share that information with the rest of the mdns caches
via Alfred.
All mdns traffic would be contained on local networking (no routing
involved).
Problems where not related just to the network topology but mainly to buggy
implementation, having avahi/mdns/zeroconf/jmDNS based stuff is usually a pain
Some years ago they were mostly abandoned software, i suspect the situation is
not better now...
I definitely would not invest my time on that technology
NicoEchaniz told me that there where some issues with
mdns in the past,
but I guess this approach was reasonable... What do you think?
It would be very useful if you Gio and Pau could share a little bit
more about what was your experience with this.
Also, you are right Pau... it would only work on a certain layer... and
it would need something to coordinate with bmx6... but as of now, I
feel that this is a good start.
If we plan to implement something about service discovery it should be
decoupled from lower network layer as much as possible, service discovery is
about applications and should reside in application layer too
Past experiment pushing application layer stuff into networking layer has
failed, moreover this would force to use a specific switching/routing
technology that is not a good idea.
As an example ebrain [0] that is an "application sharing" software started
some years ago depending on OLSR, then OLSR changed in an incompatible way,
hopefully they soon realized that it wasn't a good idea to depend on a specific
routing technology.
Cheers!
[0] http://ebrain.in/
--
Nicolás Pace
http://www.linkedin.com/in/nickar
On Thu, Dec 1, 2016 at 11:14 AM, Nicolás Echániz
<nicoechaniz(a)altermundi.net> wrote:
> On 12/01/2016 10:11 AM, Pau wrote:
>> I agree with Gio, we also tried to use mDNS/avahi in several
>>
>> projects
>>
>> and it was always a fail, in addition the layer2 dependency is a
>> restrictions which reduces the possible impact of the services
>>
>> sharing.
>>
>> An alternative option would be to use the bmx6 SMS plugin [1], which
>> allows the transfer of small files using the routing packets. Here
>>
>> an
>>
>> example of usage [2] and the code [3].
>>
>> Using ALFRED from batman-adv would be also an option. On LiMe we are
>> already using it for the dhcp leases share system of dnsmasq, but
>>
>> again
>>
>> it would work only for the cloud (not the entire network). So a
>>
>> kind of
>>
>> bridge might be implemented.
>>
>> Would be nice to put some effort here.
>
> I talked ahout this with nico a bit. We've also had a bad experience
> with Avahi in general.
>
> Maybe we can do some brainstorming about what we would like to
> accomplish and then share ideas on how to do that.
> Nico is motivated to work on this and that's awesome :)
>
>
> Cheers!
> Nico
>
>
> _______________________________________________
> lime-dev mailing list
> lime-dev(a)lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-dev
12:56 p.m.
I think if we want reliable service tracking, we need to go with TCP
connections.
How about not trying to detect services - just wait for them to
register? Run a daemon providing a simple REST API which :
+ allows services to register themselves
+ sends those registrations to other known instances
+ provides a client API to list known services (e.g. as an html widget)
That way the daemon doesn't have to run on every node and
services/registries only need a simple configuration of 1 or more
'upstream' addresses.
[ Since this is my first post here, I should probably introduce myself:
I'm a hobbyist Python programmer and GNU/Linux geek who has been
fascinated with peer-to-peer networking since I first read about ad-hoc
mode. I've just learned how to compile LibreMesh from source and I'm
trying to set up a community network in London, UK. I'm also trying to
find a way to earn a living working on interesting stuff like this! ]
-Kevin
13 Dec
13 Dec
5:14 a.m.
Great Discussion!
(BTW: welcome kevin, awesome to have you here)
We have been talking with NicoEchaniz these last days and he convinced
me about not using mDNS for multiple reasons:
* if we push this link-local information to a more centralized place,
we may be exposing our users without them being aware of that
* mDNS has proven not to be of trust on mesh networks in the past, and
we may better seek for a better (or at least intelligent for our
context) solution
So, one possible way to deal with this would be to do service
announcement instead of service discovery, and make it easy for users
with little technical experience to publish there if they wish.
That could be addressed by adding a section on lime admin page to deal
with this.
What do you think ?
Regards,
--
Nicolás Pace
http://www.linkedin.com/in/nickar
On Fri, Dec 2, 2016 at 6:56 AM, Kevin Steen <libremesh(a)kevinsteen.net>
wrote:
I think if we want reliable service tracking, we need
to go with TCP
connections.
How about not trying to detect services - just wait for them to
register? Run a daemon providing a simple REST API which :
+ allows services to register themselves
+ sends those registrations to other known instances
+ provides a client API to list known services (e.g. as an html
widget)
That way the daemon doesn't have to run on every node and
services/registries only need a simple configuration of 1 or more
'upstream' addresses.
[ Since this is my first post here, I should probably introduce
myself:
I'm a hobbyist Python programmer and GNU/Linux geek who has been
fascinated with peer-to-peer networking since I first read about
ad-hoc
mode. I've just learned how to compile LibreMesh from source and I'm
trying to set up a community network in London, UK. I'm also trying to
find a way to earn a living working on interesting stuff like this! ]
-Kevin
_______________________________________________
lime-dev mailing list
lime-dev(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
2693
days inactive
2709
days old
8 comments
6 participants
participants (6)
-
Gio -
Gui Iribarren -
Kevin Steen -
Nicolás Echániz -
nicopace -
Pau