---------- Forwarded Message ----------
Subject: [Interop-dev] Battlemesh travel scholarships available
Date: Monday, June 22, 2015, 03:35:15 PM
From: Mitar <mitar(a)tnode.com>
To: interop-dev(a)lists.funkfeuer.at
Hi!
(Please spread the word to those you think might be interested in the
scholarship.)
We are opening a call for sponsored travel to attend Battlemesh for
anyone living outside Europe and would like to invite you to send your
application! Battlemesh is the annual conference/gathering/hack event on
community wireless networks and routing protocols will be between
3rd-9th August in Maribor, Slovenia. As Battlemesh is in the week before
the Chaos Communication Camp in Germany, this is an excellent
opportunity to be able to travel to both.
https://wlan-si.net/en/blog/2015/06/22/battlemesh-travel-scholarships-avail…
Event is free to attend and we still have organized accommodation
available at low cost.
Requirements
------------
Travel scholarships are open to people not living in Europe. To apply,
we would like to ask you to send a short video (not longer than two
minutes) to describe your situation:
- Where are you from?
- Why would you like to attend Battlemesh?
- What impact in your local environment do you expect from your
participation?
- Would you be able to attend without the travel scholarship?
- Will you continue to the Chaos Communication Camp? (Note that it is
not a problem if you also plan to go to the CC camp.)
Shoot a short video and upload it to one of the video sharing websites
and send us a link. Note that if it is private, we need a direct link
and/or password for it as well.
Contact
-------
E-mail your video to the local Battlemesh team at
<battlemeshv8(a)wlan-si.net>.
Deadline
--------
The deadline for applications is the 3rd of July. Decisions will be made
before 6th July.
What is Battlemesh?
-------------------
The Wireless Battle of the Mesh is an event that aims at bringing
together people from across Europe and beyond to test the performance of
different routing protocols for mesh networks, like Babel, B.A.T.M.A.N.,
BMX, IEEE 802.11s, OLSR. It is a tournament with a social character. If
you are a mesh networking enthusiast, community networking activist, or
have an interest in mesh networks and related technologies, come and attend.
The traditional goal of the event is to set-up hands-on testbed for each
available mesh routing protocol with a standard test procedure for the
different mesh networks. During the event, similar hardware and software
configuration will be used based on the OpenWrt and packages for each
protocol implementation. The event is also a great opportunity to
develop testing tools for PHY/MAC radio layers (drivers, scripts and PHY
analyzers). Alongside the testing of routing protocols, a number of
talks, workshops, and hackathons will be held on various mesh-related
topics, all from technology to community and social aspects of mesh
networks.
This years Battlemesh will take place from 3rd to 9th August 2015 in
Maribor, Slovenia.
Mitar
--
http://mitar.tnode.com/https://twitter.com/mitar_m
_______________________________________________
Interop-dev mailing list
Interop-dev(a)lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/interop-dev
-----------------------------------------
-------- Forwarded Message --------
Subject: Re: [qmp-dev] TunOutTimeout to zero by default
Date: Wed, 10 Jun 2015 12:17:32 +0200
From: Pau <pau(a)dabax.net>
Reply-To: quick mesh project development mailing list <qmp-dev(a)mail.qmp.cat>
To: qmp-dev(a)mail.qmp.cat
But still, as far as I know, it is just a cosmetic thing. There will be
a lot of network interfaces but at least the TCP connections will
persist over the time.
I don't like the idea of saying "in qMp the maximum persistent time is
1h", after that your connections will be reseted :P
What would fix the problem is to create the tunnel On demand but make it
persistent forever. Thus the nodes will only have the tunnels created
with the nodes which have been contacted at least one time (until the
next reboot).
What do you think, can you implement this option?
Thanks.
On 10/06/15 11:29, Axel Neumann wrote:
> I would not do that!!!
>
> tunOutTimeout=0 means that all possible tunnels are activated by default!
>
> For a large qmp cloud with each node offering its own ipv4 and ipv6
> tunnel endpoints this would be a massive amount of always activated
> tunnels !!! Something very upgly when looking at those nodes interface
> list.
>
> A tunOutTimeout != 0 means they are only activated on demand and the
> list of active tunnel interfaces remains usually small.
>
> A compromise could be to configure a large value (eg tunOutTimeout =
> 3600000) which means that tunnels are setup on demand but temporary
> cut down only every hour.
>
>
> /axel
>
> On 10.06.2015 10:42, Pau wrote:
>> Hello. Following the thread discussion [1], where the user reports
>> problems with streaming cuts, I would propose to add the option
>> tunOutTimeout=0 by default in the qMp system. The advantages of
>> this timeout are just cosmetics (as far as I know). So I would
>> disable it for the moment to avoid persistent connection problems
>> as reported by that user and some others.
>>
>> Find the patch at the end of this mail and feel free to apply it if
>> agreed.
>>
>> [1]
>> https://mail.dabax.net/pipermail/qmp-users/2015-June/000802.html
>>
>> diff --git a/packages/qmp-system/files/etc/qmp/qmp_functions.sh
>> b/packages/qmp-system/files/etc/qmp/qmp_functions.sh index
>> eba5887..450a2a7 100755 ---
>> a/packages/qmp-system/files/etc/qmp/qmp_functions.sh +++
>> b/packages/qmp-system/files/etc/qmp/qmp_functions.sh @@ -727,6
>> +727,7 @@ qmp_configure_bmx6() {
>>
>> qmp_configure_prepare $conf uci set $conf.general="bmx6" + uci set
>> $conf.general.tunOutTimeout=0 uci set
>> $conf.bmx6_config_plugin=plugin uci set
>> $conf.bmx6_config_plugin.plugin=bmx6_config.so
>>
>>
>>
>>
>>
>>
>> _______________________________________________ qmp-dev mailing
>> list qmp-dev(a)mail.qmp.cat
>> https://mail.dabax.net/cgi-bin/mailman/listinfo/qmp-dev
>>
>
> _______________________________________________
> qmp-dev mailing list
> qmp-dev(a)mail.qmp.cat
> https://mail.dabax.net/cgi-bin/mailman/listinfo/qmp-dev
>
--
./p4u
---------- Forwarded Message ----------
Subject: Re: [qmp-dev] TunOutTimeout to zero by default
Date: Wednesday, June 10, 2015, 11:29:21 AM
From: Axel Neumann <neumann(a)cgws.de>
To: qmp-dev(a)mail.qmp.cat
I would not do that!!!
tunOutTimeout=0 means that all possible tunnels are activated by default!
For a large qmp cloud with each node offering its own ipv4 and ipv6
tunnel endpoints this would be a massive amount of always activated
tunnels !!! Something very upgly when looking at those nodes interface
list.
A tunOutTimeout != 0 means they are only activated on demand and the
list of active tunnel interfaces remains usually small.
A compromise could be to configure a large value (eg tunOutTimeout =
3600000) which means that tunnels are setup on demand but temporary
cut down only every hour.
/axel
On 10.06.2015 10:42, Pau wrote:
> Hello. Following the thread discussion [1], where the user reports
> problems with streaming cuts, I would propose to add the option
> tunOutTimeout=0 by default in the qMp system. The advantages of
> this timeout are just cosmetics (as far as I know). So I would
> disable it for the moment to avoid persistent connection problems
> as reported by that user and some others.
>
> Find the patch at the end of this mail and feel free to apply it if
> agreed.
>
> [1]
> https://mail.dabax.net/pipermail/qmp-users/2015-June/000802.html
>
> diff --git a/packages/qmp-system/files/etc/qmp/qmp_functions.sh
> b/packages/qmp-system/files/etc/qmp/qmp_functions.sh index
> eba5887..450a2a7 100755 ---
> a/packages/qmp-system/files/etc/qmp/qmp_functions.sh +++
> b/packages/qmp-system/files/etc/qmp/qmp_functions.sh @@ -727,6
> +727,7 @@ qmp_configure_bmx6() {
>
> qmp_configure_prepare $conf uci set $conf.general="bmx6" + uci set
> $conf.general.tunOutTimeout=0 uci set
> $conf.bmx6_config_plugin=plugin uci set
> $conf.bmx6_config_plugin.plugin=bmx6_config.so
>
>
>
>
>
>
> _______________________________________________ qmp-dev mailing
> list qmp-dev(a)mail.qmp.cat
> https://mail.dabax.net/cgi-bin/mailman/listinfo/qmp-dev
>
_______________________________________________
qmp-dev mailing list
qmp-dev(a)mail.qmp.cat
https://mail.dabax.net/cgi-bin/mailman/listinfo/qmp-dev
-----------------------------------------
Hey devs!
On LiMe-Users mailing list there is a discussion on where to put the
documentation of Libre-Mesh.
It's long time that the lack of documentation _avoids_ people to
try/join/enjoy the project.
Returning to the email that I'm forwarding you, I will write a synopsis
so you don't have to learn Italian for getting the concept:
Federico: "documentation in ResTructuredText or Markdown on Github"
David agrees
Ilario: "too late, bad idea to move the documentation, wiki is ok"
David: "wiki of Redmine = shit, if you want a wiki use a proper one"
So?
-------- Forwarded Message --------
Subject: Re: [lime-users] [Bologna] Documentazione (Era: Fwd: LiMe broken.)
Date: Mon, 1 Jun 2015 01:09:50 +0200
From: David Costa <david.costa(a)ieee.org>
Reply-To: libre-mesh users <users(a)lists.libre-mesh.org>
To: bologna(a)ml.ninux.org
CC: libre-mesh users <users(a)lists.libre-mesh.org>
On 05/31/2015 07:59 PM, Nemesis wrote:
> Se posso permettermi di dare un consiglio, penso che la
> documentazione in formato ResTructuredText o Markdown conservata in
> un repository github sia la cosa migliore.
Concordo anch'io sull'avere la documentazione in un repo.
Se non è troppo grande può stare tranquillamente nello stesso repo del
codice, così si possono versionare insieme e avere la documentazione di
una release nello stesso commit di quella release.
On Sun, 31 May 2015 20:33:02 +0200
Ilario Gelmetti <iochesonome(a)gmail.com> wrote:
> Sarebbe figo, però ormai abbiamo iniziato a scriverla sui wiki e non
> mi sembra affatto una buona idea spostarla/copiarla.
> Eppoi il sito di libre-mesh ha anche la funzione wiki, mi sembra
> naturale usarla per metterci la documentazione di libre-mesh...
Il sito di libre-mesh è una istanza di Redmine e il wiki è una
funzionalità davvero marginale di quel programma...
le categorie non ci sono: si possono solo fare relazioni padre-figlio
tra le pagine (e si fa con il tasto "rename"), e le categorie sono
fondamentali nella documentazione per distinguere le pagine importanti
tipo "routing in libre-mesh" da pagine molto specifiche o di reference
("how-to: compilare libre-mesh su PPC").
Se vuoi portarti la documentazione off-line banalmente non puoi, a meno
che non salvi tutte le pagine una per una perché non esiste nessun tool
decente (e spero che qualcuno smentisca) per esportare il wiki
intero o una categoria... quindi una volta che scrivi nel wiki di
redmine non puoi migrare facilmente a niente di diverso, neanche un
altro sito che usa redmine.
Insomma, è per dire che il wiki di redmine non è un wiki normale, è una
roba che serve solo per sopperire a esigenze di sviluppo o per dare
link a risorse che non fanno parte della documentazione vera; per fare
un esempio un progetto grosso che usa redmine dall'inizio alla fine è
gnuradio [1], loro hanno nel wiki un po' di link a vari tutorial, dati
d'esempio e pagine organizzative, ma il manuale vero è fatto con Doxygen
e Sphinx (perché in realtà il bello di GNURadio sono le sue API).
Capisco che avere un wiki permetta a più persone di scrivere qualcosa
perché viene meno la sensazione di responsabilità che si avrebbe
committando su un repo e perché è effettivamente più facile da usare,
però che sia un wiki vero almeno, tipo dokuwiki o mediawiki :)
Metto in CC lime-users perché credo che a questo punto, con diverse
reti che vogliono iniziare _effettivamente_ ad usarlo converrebbe avere
delle linee guida per la documentazione decise insieme agli
sviluppatori.
[1] http://gnuradio.org/redmine/projects/gnuradio/wik
