lime-dev

lime-dev@lists.libremesh.org

338 discussions

Fwd: Re: [qmp-dev] TunOutTimeout to zero by default

by Pau

-------- 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

9 years, 6 months

Fwd: Re: [qmp-dev] TunOutTimeout to zero by default

by Gio

---------- 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 -----------------------------------------

9 years, 6 months

Fwd: [lime-users] Documentazione

by Ilario Gelmetti

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

9 years, 6 months

Easylist (uBlock, adBlock) breaks luci graphs with wlanX_adhoc

by Gui Iribarren

Hello fellows, i spent quite a while banging my head trying to understand why a luci graph was not working, the XHR.poll() was failing on a given, specific URL. turns out, it failed when the url ended like "whatever_adhoc" luci XHR appends a '?_=0.15089513623292194', resulting in a url like http://10.5.0.6/cgi-bin/luci/.../wlan0_adhoc?_=0.15089513623292194 after a quick chat with jow, i found out it was uBlock getting in the way; chromium with adBlockPlus gave the same problem. i have both with defaults settings, namely, just use Easylist see it for yourselves: https://easylist-downloads.adblockplus.org/easylist.txt includes the expression _adhoc? the "?" is not a regexp, it's a literal "?", but as i said XHR.poll appends a '?' to the end of the url, completing the blocked expression so this breaks, for example, luci Realtime Traffic graphs for the interface "wlan0_adhoc", amongst others. My suggestion for this bizarre coincidence of events, is simply to change our lime separator to "-" instead of "_" which, by the way, is more "in line" with upstream automatic names for several wifi-ifaces are like wlan0, wlan0-1, wlan0-2 so it's better if we use wlan0-adhoc, wlan0-ap, etc and for the vlanSeparator (which is currently '-') just use '_', so complete interface name will be wlan0-adhoc_167 and such (exactly the opposite of the current name, but at least to me it makes more sense, and as a bonus this will not end up in a blocked url) cheers!

9 years, 7 months

https on dev.libre-mesh.org

by David

I noticed that the subdomain dev.libre-mesh.org runs with a self-signed certificate, which is annoying because casual people browsing (and security paranoid) won't accept to add an exception in order to read more and will leave... A free browser-accepted certificate can be obtained from StartSSL [1] (for that specific domain, wildcards and extended verification certs are not for free of course, but we there is no need for them). [1] https://www.startssl.com/

9 years, 7 months

VLANs protocol in LibreMesh

by Roger Pueyo Centelles | Routek.net

Hi, This is Roger, from Barcelona, one of the maintainers of qMp [1]. I would like to ask you a couple of questions regarding VLANs in LiMe and its compatibility with qMp. In qMp we use 802.1q to create VLANs for BMX6 (e.g. eth0.12). This is quite a mess for devices with a switch, because they typically block traffic created on top of the switch's own VLANs (e.g. eth0.1.12). Therefore, we are going to switch to 802.1ad in wired devices, the same as in LiMe, from the next major release on. This will break backwards compatibility with previous versions of qMp, but I believe it's a good decision. I wonder how LiMe manages VLANs in wireless devices. Do you also use 802.1ad there, or 802.1q? In order not to completely break backwards compatibility, our idea is to keep using 802.1q on wireless devices. What do you think it would be the best approach to allow LiMe/qMp interoperability? Kind regards, Roger [1] http://qmp.cat

9 years, 7 months

5GHz channel selection Was: [OpenWrt-Devel] [patch] mac80211: Force Atheros drivers to respect the user's regdomain settings by default

by Gio

I have experienced problem changing 5GHz channel on our routers, do you think it may be related to this ? If so shoulb we enable by default that option at least on lime-build or lime- full ? ---------- Forwarded Message ---------- Subject: Re: [OpenWrt-Devel] [patch] mac80211: Force Atheros drivers to respect the user's regdomain settings by default Date: Friday, April 03, 2015, 12:53:00 PM From: bkil <bk.il.hU+ibLa_qUzy(a)gmail.com> To: Jiri Pirko <jiri(a)resnulli.us> CC: openwrt-devel <openwrt-devel(a)lists.openwrt.org> Unfortunately, your patch will never be merged because most developers are from the USA: https://dev.openwrt.org/ticket/6923 https://dev.openwrt.org/ticket/7777 https://dev.openwrt.org/ticket/9678 https://dev.openwrt.org/ticket/12991 https://dev.openwrt.org/ticket/16818 https://dev.openwrt.org/ticket/16862 ... There's no use in resending or even debating it. On Fri, Apr 3, 2015 at 12:09 PM, Jiri Pirko <jiri(a)resnulli.us> wrote: > User's regdomain should know the correct setting. So change default for > ath drivers to respect those. > > Signed-off-by: Jiri Pirko <jiri(a)resnulli.us> > --- > package/kernel/mac80211/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile > index 11c8bcf..ab79330 100644 > --- a/package/kernel/mac80211/Makefile > +++ b/package/kernel/mac80211/Makefile > @@ -503,6 +503,7 @@ define KernelPackage/ath/config > if PACKAGE_kmod-ath > config ATH_USER_REGD > bool "Force Atheros drivers to respect the user's regdomain settings" > + default y > help > Atheros' idea of regulatory handling is that the EEPROM of the card defines > the regulatory limits and the user is only allowed to restrict the settings > -- > 1.9.3 > _______________________________________________ > openwrt-devel mailing list > openwrt-devel(a)lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel(a)lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -----------------------------------------

9 years, 7 months

Merge merge_develop branch

by Gio

Hi! Although the branch merge_develop doesn't follow our naming convention seems no one has reported specific problems with that branch. Is there any undergoing test of that branch? Is it already tested? If so we should proceed to rename it to something like feature/feature_name or hotfix/hotfix_name and then merge it into develop anyone willing to do this job ? Cheers!

9 years, 7 months

Fwd: Re: [OpenWrt-Devel] OpenWrt release name

by Gio

Seems LiMe syrup is an affocial componet of next openwrt release :p ---------- Forwarded Message ---------- Subject: Re: [OpenWrt-Devel] OpenWrt release name Date: Monday, April 06, 2015, 09:35:52 AM From: John Crispin <blogic(a)openwrt.org> To: openwrt-devel(a)lists.openwrt.org i think we have a winner with 96 vs 50 votes. > == Dirty Diamond == > 2 cl Rum > 2 cl Vodka > 2 cl Tequila Silver > 2 cl Campari > 2 cl Curaçao Blue > 2 cl Lime syrup > 2 1/2 cl Orange juice > Coca Cola _______________________________________________ openwrt-devel mailing list openwrt-devel(a)lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -----------------------------------------

9 years, 8 months

Fwd: [Battlemesh] V8 Current Endorsements

by Gioacchino Mazzurco

We should endorse too! What do you think? ---------- Forwarded Message ---------- Subject: [Battlemesh] V8 Current Endorsements Date: Sunday, February 15, 2015, 05:38:25 PM From: Nemesis <nemesis(a)ninux.org> To: Battle of the Mesh Mailing List <battlemesh(a)ml.ninux.org> This is the current endorsers list: * Wlan Slovenia (host) * Batman * Openwrt * Freifunk * Ninux * Wireless Leiden * Wirelesspt.net http://battlemesh.org/BattleMeshV8#Endorsements So far we already have all the logos of these from last year. Somebody else wants to come on board right now and save us some time needed to reach? Federico -----------------------------------------

9 years, 10 months

← Newer
1
...
16
17
18
19
20
21
22
...
34
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

lime-dev