lime-dev November 2016

lime-dev@lists.libremesh.org

7 participants
6 discussions

Intro and Discovering local services using mdns

by nicopace

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

8 years

Neither Chef nor lime-build are producing images for routers with 4 MB flash

by Ilario

Hi devs! As lime-build now supports routers with 4 MB of flash (using make T=ar71xx-mini P=basic) why is not possible to take advantage of this in Chef? And why images for e.g. TP-Link wr841n and wr741nd are neither present in the downloads server under the ar71xx-mini directory [1]? Is that directory containing images made with lime-build with basic profile and ar71xx target? Still too big for 4MB routers?? These images are supported by OpenWrt [2]. This is a big problem for Ninux Bologna users who mainly use TP-Link wr841n and wr741nd hardware[3]. [1] http://downloads.libremesh.org/community_chaos/16.07/ar71xx-mini/generic/ [2] https://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/ [3] http://ml.ninux.org/pipermail/bologna/2016-November/001292.html

8 years, 1 month

Which routers did you flash with LibreMesh?

by Ilario

We're going to write on the web a list of tested routers, just for helping the visitors to have an idea of the supported/recommended routers without copying and pasting the whole list provided by OpenWrt/LEDE. The discussion on this is here: https://github.com/libremesh/lime-web/pull/14 Please answer with the routers you tried with LibreMesh. I played with: TP-Link WDR3600 TP-Link WR1043ND-v1 Ubiquiti NanoBridge M5 Ubiquiti NanoStation M5 XM Ubiquiti NanoStation LoCo M2

8 years, 1 month

http://downloads.libremesh.org down

by Gio

as in subject Cheers!

8 years, 1 month

Re: [lime-dev] [lime-users] Testing LibreMesh 16.07 on TPLink AC1750

by Gui Iribarren

On 09/11/16 00:56, Gui Iribarren wrote: > There's a group currently testing in Brasil how does LibreMesh run on > these ath9k+ath10k routers. > > ath9k = 2.4ghz > ath10k = 5ghz > > Extra packets needed so far: > > kmod-ath10k > ath10k-firmware-qca988x > > Progress so far: adhoc doesn't seem to work (virtual interface is not > created) on the ath10k interface. The 2.4ghz interface works correctly > (it's ath9k) adhoc confirmed not supported looking at "iw phy" > > Currently trying ieee80211s mode on ath10k. > Will report any news so, when trying to bring up the mesh interface, logread says ath10k_pci 0000:01:00.0: must load driver with rawmode=1 to add mesh interfaces tried simply reloading the driver with rawmode=1, but then logread said rawmode = 1 requires support from firmware following this https://github.com/o11s/open80211s/wiki/ath10k-(802.11ac)-for-Mesh-Support i downloaded this exact file https://github.com/kvalo/ath10k-firmware/raw/master/QCA988X/hw2.0/10.2.4.70… placed it the router /lib/firmware/ath10k/QCA988X/hw2.0/firmware-5.bin overwriting the one from the package ath10k-firmware-qca988x then # rmmod ath10k_pci ; rmmod ath10k_core # insmod ath10k_core rawmode=1 ; insmod ath10k_pci # wifi and it came up :) i had some issues with wireless.radioX.htmode=HT40, logread spits out some errors during wifi reload radio0 (24777): Usage: iw [options] dev <devname> set channel <channel> [HT20|HT40+|HT40-] radio0 (24777): Options: radio0 (24777): --debug enable netlink debugging looks like netifd is passing the parameters wrong to "iw" according again to this https://github.com/o11s/open80211s/wiki/ath10k-(802.11ac)-for-Mesh-Support the syntax is supposed to be "iw mesh0 set freq 5180 80 5210" and it looks like netifd is doing the classical "iw mesh0 set channel 48 HT40+" for the meantime, i just unset htmode, and it everything comes up fine (albeit slow, a netperf between the two nodes on the same table gives only ~20 mbps, it could be around ~100 mbps if properly configured) anyway this thread will turn definitely "lime-dev", and offtopic for lime-users, so I'm moving the discussion there :) > > If anyone has already tested this hardware or has any tips, much welcome :) > > cheers! > > > _______________________________________________ > lime-users mailing list > lime-users(a)lists.libremesh.org > https://lists.libremesh.org/mailman/listinfo/lime-users >

8 years, 1 month

trap in bmx6-auto-gw-mode logic

by Gui Iribarren

Hey friends, I've just stumbled this situation "in the wild" (a friend who tried libremesh on two routers and got stuck, then asked me to have a look inside) steps to reproduce: 1. router A, freshly flash with 16.07 from downloads.lime.org 2. connect router A via WAN to the internet 3. watchping detects the connection and executes bmx6 -c tunOut -inet4 && bmx6 -c tunIn inet4 /n 0.0.0.0/0 4. now go via luci interface and set, for example, hostname or whatever 5. "save & apply" triggers a "uci commit" 6. there are "pending changes" in bmx6 uci, which get commited as well -bmx6.inet4 bmx6.cfg1020b3='tunIn' bmx6.cfg1020b3.tunIn='inet4' bmx6.cfg1020b3.network='0.0.0.0/0' 7. disconnect WAN internet and reboot now flash another router B, connect router B via WAN to Internet, and try to access that connection from router A (router A not connected anymore directly to WAN) router A doesn't have the inet4 tunOut anymore, and actually publishes a "blackhole" tunIn 0.0.0.0/0 and it will stay in that broken state forever (unless, well, you "firstboot" it or something) a "proper" fix would be for bmx6 to not necesarily write runtime config changes to /tmp/.uci/bmx6 (say, have an option) a quick dirty workaround that comes off the top of my head would be to issue a "uci revert bmx6" at the end of /etc/watchping/wan-fail.d/bmx6-gw /etc/watchping/wan-ok.d/bmx6-gw @pau, what do you think? cheers! gui

8 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

lime-dev November 2016