lime

lime-users@lists.libremesh.org

493 discussions

[lime-users] To continue the conversation about the wiki

by Nicolas Pace

Hi guys, apologize for reorganizing this conversation again. I think it is better for it to have its own thread. So, to recap, the conversation comes from the thread "Recommended devices?": Patricio Gibbs on 07/27/2017 The conversation in this thread has documented some useful knowledge. Is there a place to compile this information in a list of compatible devices? I see the mostly empty list at: http://libremesh.org/docs/hardware/ Such a list could be part of a guide about how to choose a device, or how to guess whether a device might work or is definitely unsupported. Bruno Vianna on 07/29/2017 I like the idea too, but it would be much easier if it were a wiki or some kind of editable page. I contribute to openwrt's wiki every time when I find out info on a new device. I understand the content from libremesh is in github, but it is a lot more bureaucratic to edit the html, push it, wait for merge... So, dear libremesh site managers, do you think we can have a wiki or some open content solution? We talked with Gui/Gio/Pau/NicoE about this and think that would like to make a decision that reinforces the community, so instead of pushing a specific implementation, it is better to share our perspectives on the subject and consider experimenting something a bit in the way to the "advice process" http://www.reinventingorganizationswiki.com/Decisi on_Making, which we are implementing as: someone who is in a good/the best place to make this decision (can mean many things but let's consider responsible for implementing and maintaining, and accountable for the results... who would be me so far) will lead an "advice process" which means receiving advice from all those who can have relevant contributions and/on will be affected by it, meaning you. So this is a brief of the points of that group, which I'll share since I consider valuable for all to know them: Pro "current state" We left RedMine because it was not working, people was not contributing and the info was not being updated. Now that it is more code-related the info is kept in a more coherent way. On GitHub there is the "Edit" button. It is not necessarilly bad to have to wait for a Pull Request to be accepted. Pro "Wiki" Now we are a bigger communitty, how do we enhance involvement? We can make a monthly test with the GitHub wiki with the unnoficial info like "experiences with hw", "specific tutorials", "cases" and so. The downside of the github wiki is that it can only be editted by collaborators of the repository. So based on this information, which key points would be relevant to consider to move forwards? Please share your points of view so we move on to have a definition. As said, it is an experiment of using a decision making method which seemed to us can be a good one for the kind of community we work to build. Please then shared also your feedback about this. Part of this process has been promoted by a relative new member of the community (5 months or so), Rodrigo Monelos, who has been mainly acting as facilitator and Agile coach on the LibreRouter project, so he will be helping also with the coordination of it. I hope he can introduce himself to come out of the shadows :) Regards,

7 years, 2 months

Re: [lime-users] Fwd: Presentación

by Luciano Vega

Hola! Les escribo por que precisamente tengo el mismo problema con la asignación de servidor dns. A continuación les paso a detallar la conexion de los equipos en cuestión, en una computadora con una distribución basada en Debian esta instalado un servidor dns con bind9, y otros servicios como un Owncloud, una web institucional, etc; Ese servidor está conectado a un puerto Lan (ip fija) de un router con Openmesh. La idea de asignar un servidor dns por el momento solo cumpliria con el objetivo de que todo usuario que se conecte a la red tenga que pasar por un portal cautivo, por lo cual el servidor dns con cualquier url devuelve la ip del servidor. Si en las propiedades de conexión de los equipos defino el servidor dns con la ip del equipo en el cual esta instalado, el portal cautivo funciona. Realice las siguientes pruebas sin conseguir el resultado esperado: 1) En la interfaz web en el apartado de DHCP borre todos los servidores dns por defecto y dejé solo la dirección del servidor de la red local. 2) Modifique el archivo de configuración de Lime y ejecuté el comando lime-config, luego revisé si se propagaron los cambios a los otros archivos de configuración y los cambios en la configuración efectivamente se propagaban al resto de los archivos. 3) En el router instalé el paquete nodogsplash para probar otro método para cumplir con el objetivo del portal cautivo, seguí los pasos de configuración de diferentes guías y no logre que funcione. 4) no pude modificar el /etc/resolv.conf, cree un nuevo archivo fuera de la carpeta /tmp al que hago referencia desde el /etc/config/dhcp con la ip del servidor dns. Por lo cual me quedan las siguientes preguntas: ¿Como debería realizar la configuración para que se asignen los servidores dns a los clientes, o en su defecto lograr objetivo similar? ¿Esta bien conectar el servidor al puerto Lan o debería conectar el mismo al puerto Wan del router? ¿Las configuraciones para la red mesh debería aplicarla a todos los servidores? Disculpen la extensión del mensaje, ante todo agradezco por adelantado que me puedan llegar a orientar. Saludos! El 29 de septiembre de 2017, 17:21, Santi Vallazza <rulosanti(a)gmail.com> escribió: > > ---------- Forwarded message ---------- > From: Gui Iribarren <gui(a)altermundi.net> > Date: 2017-09-22 15:24 GMT-03:00 > Subject: Re: [lime-users] Fwd: Presentación > To: lime-users(a)lists.libremesh.org > > > On 22/09/17 18:21, Santi Vallazza wrote: > > reinstalamos el firmware y ahora guarda los cambios. > > > > Volviendo al tema original: > > > > Aún no pudimos hacer que el router asigne como DNS a los clientes la > > dirección IP de nuestro servidor. > > > > ¿Pueden indicarnos en qué archivo deberíamos realizar esa configuración? > > /etc/config/lime > > veras en > config lime 'network' > list resolvers '4.2.2.2' > list resolvers '141.1.1.1' > list resolvers '2001:470:20::2' > > reemplaza esas 3 lineas por 1 sola q diga > list resolvers '1.2.3.4' > (o sea, la ip de vuestro servidor) > > y luego corre 'lime-config' > > ( detras de escena, eso se "propaga" hacia... > /etc/config/dhcp > q a su vez terminan siendo lineas en > /var/etc/dnsmasq.conf.cfg* ) > > vale decir que, en los clientes el servidor DNS seguira siendo el router > libremesh (que corre dnsmasq), pero dnsmasq del router libremesh > forwardeara todos los pedidos hacia vuestro servidor deseado > > > > > Gracias! > > > > El 1 sept. 2017 6:40 a. m., "Gui Iribarren" <gui(a)altermundi.net > > <mailto:gui@altermundi.net>> escribió: > > > > On 01/09/17 10:50, Nicolás Echániz wrote: > > > On 08/31/2017 12:04 PM, Santi Vallazza wrote: > > >> Buenas! > > >> > > >> El routers es un wdr3600 > > >> > > >> La versión que tienen instalada los equipos es: > > >> lime-tl-wdr3600-v1-r44952-tandillibre-node-factory.bin > > > > > > Santi, de dónde descargaste ese .bin? > > > > sospecho que de aqui > > > > https://chef.altermundi.net/ls/tandillibre/r44952/node/ar71 > xx/openwrt-tl-wdr3600-v1-r44952-tandillibre-node-factory.bin > > <https://chef.altermundi.net/ls/tandillibre/r44952/node/ar7 > 1xx/openwrt-tl-wdr3600-v1-r44952-tandillibre-node-factory.bin> > > > > y es identico al release > > https://chef.altermundi.net/diff/tandillibre-node/libre-mesh-1509/ > > <https://chef.altermundi.net/diff/tandillibre-node/libre-mesh-1509/> > > > > por lo tanto no me queda otra explicacion que un fallo de hardware??? > > onda que la flash tenga un error y la monte como readonly? > > > > > > > > > > > > > > > > > _______________________________________________ > > > lime-users mailing list > > > lime-users(a)lists.libremesh.org <mailto:lime-users@lists.libre > mesh.org> > > > https://lists.libremesh.org/mailman/listinfo/lime-users > > <https://lists.libremesh.org/mailman/listinfo/lime-users> > > > > > > > > > _______________________________________________ > > lime-users mailing list > > lime-users(a)lists.libremesh.org <mailto:lime-users@lists.libre > mesh.org> > > https://lists.libremesh.org/mailman/listinfo/lime-users > > <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 > > > _______________________________________________ > lime-users mailing list > lime-users(a)lists.libremesh.org > https://lists.libremesh.org/mailman/listinfo/lime-users > >

7 years, 2 months

[lime-users] [SPAM] tp-link 4310 refurbished

by Ilario

Sorry for the spam, but I thought it would be interesting for someone, it's just the motherboard without antennas nor chassis of a TP-Link WDR4300 for 23 € on aliexpress ---------- Messaggio inoltrato ---------- Da: Leonardo Maccari <mail(a)leonardo.ma> Date: 28 giugno 2017 14:41 Oggetto: [Ninux-Wireless] tp-link 4310 refurbished A: wireless(a)ml.ninux.org Ciao, long story short: Dopo il BM qualcuno mi ha chiesto di contattare Panayotis (un ricercatore che conosco) per sapere dove ha preso le device che hanno usato per uno workshop ad Atene. Ecco la risposta: https://www.aliexpress.com/item/openwrt-firmware-5g-wifi-2-port-usb-router-… ciao, leonardo. _______________________________________________ Wireless mailing list Wireless(a)ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless

7 years, 2 months

[lime-users] LEDE 17.01.3 & Severe dnsmasq vulnerabilities affecting LEDE

by Ilario Gelmetti

Yesterday LEDE 17.01.3 was released. A few days earlier some severe security vulnerabilities in DNSmasq have been disclosed. Images of LibreMesh 17.06 based on LEDE 17.01.3 can be compiled using lime-sdk but please notice that this is untested. For doing this you can replace 17.01.2 with 17.01.3 in feeds.conf.defaults and options.conf files in lime-sdk, then run ./cooker -f --force and then compile as usually. On my PC the compilation worked well but I didn't test on any router. -------- Forwarded Message -------- Subject: [LEDE-DEV] Severe dnsmasq vulnerabilities affecting LEDE Date: Tue, 3 Oct 2017 21:08:16 +0200 From: Jo-Philipp Wich <jo(a)mein.io> To: LEDE Development List <lede-dev(a)lists.infradead.org>, LEDE Project Administration <lede-adm(a)lists.infradead.org> The Google security team identified a number of critical security issues present in dnsmasq, the embedded DNS and DHCP server used by LEDE as well as many other different open and proprietary firmwares and network appliances. A total of six different flaws affecting both DNS and DHCP functionality have been identified in dnsmasq versions up to v2.77: - CVE-2017-14491 - Remote code execution, through DNS, due to heap overflow - CVE-2017-14492 - Remote code execution, through DHCP, due to heap overflow - CVE-2017-14493 - Remote code execution, through DHCP, due to stack overflow - CVE-2017-14494 - Information leak, through DHCP, potentially weakening ASLR - CVE-2017-14495 - Denial of service, through DNS, out-of-memory due missing free() - CVE-2017-14496 - Denial of service, through DNS, integer underflow causing huge memcpy() - CVE-2017-13704 - Denial of service, through DNS, integer underflow causing service crash According to Simon Kelley, the author of dnsmasq, most critical flaws are present in dnsmasq since a very long time, having even survived a number of audits. The security issues have been fixed in the most recent dnsmasq version, v2.78, which has been included into both the LEDE master and lede-17.01 release branches. MITIGATION In order to solve the security issues above you can either update the dnsmasq package through opkg: opkg update opkg upgrade dnsmasq Or update to a newer LEDE image. Master snapshots newer than revision r4969-67ac017fef and the upcoming LEDE release 17.01.3 images already contain a fixed dnsmasq version. WORKAROUND There is no secure workaround available, though the attack surface can be reduced somewhat by disabling the DNS service part of dnsmasq and only allowing trusted hosts to obtain DHCP leases in the local network. In order to disable the DNS service, issue the following commands: uci set dhcp.(a)dnsmasq[0].port="0" uci add_list dhcp.lan.dhcp_option="6,8.8.8.8" uci commit dhcp /etc/init.d/dnsmasq restart This will stop dnsmasq from serving DNS requests and instruct all DHCP clients to use Google's public DNS server instead of the router itself for name resolution. REFERENCES The orginal article published on the Google security blog: https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.h… Dnsmasq security notice: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q4/011772.html Debian security advisory: https://www.debian.org/security/2017/dsa-3989 _______________________________________________ Lede-dev mailing list Lede-dev(a)lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev

7 years, 2 months

[lime-users] How to know which DNS Linux

by Santi Vallazza

Hello, I want to know which DNS is assigned to my laptop when i connect to a network working with DHCP. I think that these commands tell me something: host -v google.com nslookup yahoo.com Do you have any other suggestion? Thanks Santiago

7 years, 2 months

[lime-users] Survey on legal obligations, of Community Networks by netcommons.eu

by Ilario Gelmetti

I forward from NetCommons a survey on which legal problems you encountered while participating in a community network. You can participate on this page: https://d52netcommons.limequery.com -------- Forwarded Message -------- Dear Sir/Madam, We kindly invite you to participate in the Survey on legal obligations of Community Networks which is part of the research of the netCommons project. netCommons (http://netcommons.eu/) is a research project supported by the European Commission (2016-2018), which proposes a trans-disciplinary methodology to study and support the development of local network internet infrastructures as commons, for resiliency, sustainability, democracy, privacy, self-determination, and social integration. You are being invited to take part in this research study because we identified your organization as a key player in this field. The goal of this online survey is to assess how the European legal framework is actually applied by CNs. The results of this survey will serve as a basis for creating /Guidelines for Community Networks to deal with legal issues./ As the survey concerns legal obligations, we would be very glad if the person(s) dealing with legal issues in your CN could answer the questions. *Participation is anonymous*. You will not be asked your personal information. We will only use your answers. If you are willing to accept our invitation, you can take part in the survey via an online platform: https://d52netcommons.limequery.com The survey, which should take between 20 and 30 minutes, will be open _until October 10_. Thank you very much for your participation! Mélanie Dulong de Rosnay & Félix Tréguer – CNRS Federica Giovanella - University of Trento For further information, please contact Federica Giovanella: federica.giovanella(a)unitn.it <mailto:federica.giovanella@unitn.it>

7 years, 2 months

[lime-users] https not available

by Amuza

Bona tarda, Probably you aware of it, but just in case: http://libremesh.org/ works fine https://libremesh.org/ does not work at all

7 years, 2 months

[lime-users] Disaster Mesh for Dominica

by Support

You must have heard about hurricane that destroyed north carribean islands this month. I am organizing a mission to send to Dominica a bunch of router to help country to recover Internet coverage. https://www.google.fr/search?q=maria+dominica&client=firefox-b&dcr=0&prmd=i… I am conducting donation events in France and Internet to send first help. I am contacting libre mesh group for getting support and help about disaster Internet solution we could provide. Thanks everyone Fred. http://madeinzion.org

7 years, 2 months

[lime-users] Difference between qmp.cat and libremesh.org

by Paul Spooren

Hello, I found the qmp.cat project and it looks to me like a similar user scope. Do they have very different approaches? Would a merge be possible (looks like some devs are already in both projects). Best regards, Paul

7 years, 2 months

[lime-users] Release 17.06 "Dayboot Rely"

by Gui Iribarren

So, this release was meant to be announced many months ago (as the numbering suggests) but lack of coordination (me, gio, pau) delayed it. In the meantime, some more fixes and improvements were introduced, and most importantly, several (unpublished) intermediate "release candidates" have been running for months now, in different community networks (QuintanaLibre mainly, thanks to persevering NicoEchaniz, and other smaller deployments) Highlights are that ieee80211s is used by default (instead of adhoc) which breaks "backward" connectivity with previous releases, as well as changes in vlan tagging policy of bmx6 and batadv (which also are not backwards compatible by default) most notably, this vlan change fixes a hard-to-debug mtu shrinking bug that pestered all releases so far (symptoms were varied and bizarre, like having timeouts when trying to browse certain https sites, sometimes, on random devices) the biggest highlight on the dev side, is that we now use upstream SDK (thanks to dangowrt for pushing this, and pau for implementing it!) which brings us much closer to LEDE/OpenWrt and allows reporting upstream ath9k bugs or such, among other benefits * generic binaries, meant for testing or setting up temporary networks (i.e. when having the default AP SSID = LibreMesh.org is fine) http://downloads.libremesh.org/dayboot_rely/17.06/targets/ (build is running right now, binaries should be ready tomorrow for sure) * for custom builds, the recommended tool at this point is lime-sdk http://libremesh.org/getit.html#cook_your_own_firmware_using_lime_sdk https://github.com/libremesh/lime-sdk * chef builds are not available at this point. there are plans to integrate this release into chef in the future, but no ETA :( ### Most of the following changelog was accomplished during the 2017/03 hackaton (https://www.youtube.com/watch?v=5UX1FwhIKGY) Changelog Dayboot Rely 17.06 (since 16.07) * based on LEDE 17.01.2 * build everything using LEDE SDK, via new lime-sdk cooker (instead of lime-build) * use ieee80211s instead of adhoc * reintroduced "firewall" package (to keep closer to upstream) * lime-system: fix ieee80211s proto, correctly construct ifnames * lime-system: sanitize hostname (transform everything into alphanumeric and dash) * lime-system: new proto static * lime-system: new wifi mode client * lime-system: set dnsmasq force=1 to ensure dnsmasq never bails out * lime-system: explicitly populate /etc/config/lime with calculated values * lime-webui: enable i18n, finally webinterface is available in Spanish * lime-webui: Major rework by NicoPace, thanks! * bmx6 node graph now uses colors in a clever way * simple way to add "system notes" that are shown along with /etc/banner and webui * luci-app-lime-location: fix google maps api key * new read-only view: switch ports status * alert luci-mod-admin users that their changes might get overwritten by lime-config * fix batman-adv status webui * new package available to install lighttpd instead of uhttpd (needed for an upcoming android app) * added a lime-sysupgrade command: does a sysupgrade but only preserving libremesh configuration file * added a lime-apply command: basically calls reload_config, but also applies hostname system-wide without rebooting * lime-hwd-ground-routing: ground routing now supports untagged ports too * lime-proto-anygw: unique mac based on ap_ssid (using %N1, %N2) * lime-proto-anygw: integrate better into /etc/config/dhcp instead of /etc/dnsmasq.d/ * lime-proto-wan: allow link-local traffic over wan (useful for local ping6 and ssh, without global exposure) * lime-proto-batadv: set batadv gw_mode=client by default to counteract rogue DHCP servers * lime-proto-bmx6: introduce bmx6_pref_gw option, adds priority (x10) to a specific bmx6 gateway * lime-proto-bmx6: don't tag bmx6 packets over ethernet and so use at least mtu=1500 everywhere * lime-proto-bmx6: avoid autodetected wan interface use vlan for bmx6 * bmx6: doesn't flood log with some spurious warnings anymore (syslog=0) * bmx6: sms plugin now enabled by default * bmx6: daemon is now supervised by procd, so it is restarted in case of crashes * bmx6: doesn't "configSync" by default anymore (no more "uci pending changes" because of auto-gw-mode) * new bmx6hosts tool: maintain an /etc/hosts that resolves fd66: <-> hostnames.mesh * watchping: convert to procd and add reload triggers * safe-reboot: fix, use /overlay/upper instead of /overlay * safe-reboot: add "discard" action * ath9k: debugged some hangs (interface is deaf) and workaround it, with new package "smonit" * set wifi default "distance" parameter to 1000 metres and make it configurable through webui * alfred: fix bat-hosts facter, check for errors and don't nuke /etc/bat-hosts in case of failure * introduce new lime-basic-noui metapackage * new packages separated: lime-docs and lime-docs-minimal * various Makefile dependency problems fixed known bugs: * safe-reboot: newly introduced "discard" action is half-baked, avoid usage until next release: It doesn't check whether there's a backup to restore or not - https://github.com/libremesh/lime-packages/issues/203 so executing "safe-reboot discard" without having done "safe-reboot" first, will brick the router. (unbricking is possible via failsafe boot, and doing "mount_root && firstboot") In the commit log authors you can see the usual suspects ;) but happily many new names! https://github.com/libremesh/lime-packages/graphs/contributors?from=2016-09… and remember it's not only code/commits what matters, so big thanks as well to everyone participating in mailing lists, maintaining website, documentation (spread around the web, in many languages!)

7 years, 3 months

← Newer
1
...
28
29
30
31
32
33
34
...
50
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

lime