On Mon, Jun 05, 2017 at 03:08:34PM +0200, Pau wrote: Initial testing went quite ok, I only run into minor and easy to fix problems: * cooker de-facto blacklisted a bunch of packages: ``` # Not flavors but common set of packages _lime_common="-ppp -dnsmasq -ppp-mod-pppoe -6relayd -odhcp6c -odhcpd -firewall" ``` While this does make sense for dnsmasq (in order to use dnsmasq-ipv6) it makes it impossible to configure a lime node to act as a PPPoE gateway and have a reasonale WAN firewall. I've moved those package-removals into the shrinked-down flavors of lime, so lime-default (which has already grown beyond the 4MB mark) can be used as a gateway on typical commercial ISP lines. Note that this for now solves only IPv4 routing -- I have IPv6 in mind and am about to make another round about https://github.com/libremesh/lime-packages/pull/71 (ie. getting upstream prefix changes via ubus, maybe use odhcpd for alfred lease-sharing) * I've noticed that lime_mini removes opkg, however, opkg is used in a couple of lime-proto-* handlers to detect the presence of the default fw3 firewall. Did you test if luci.model.ipkg works even without opkg installed? * The IB was also using locally built packages even if they are part of the binary release. This caused checksum errors on non-reproducible packages. I added a filter to the repository.conf generation to make sure only the packages we have to build locally are being included from the local SDK. I'm wondering how things went for lime-related affairs in this years WBM. Especially: * any news in terms of bmx6/7 IPv6 gateway prefix propagation? * any news on the batman-adv front in terms of the BLA race condition we were discussing during last year's event? * any news on ath9k-deafness and possible work-arounds? * what was is your conclusion in terms of air-time-fairness scheduling? (the graphs are a bit misleading imho as the scale is not the same) Looking forward to hear from you! Cheers Daniel

On Sun, Jun 11, 2017 at 01:52:34PM +0200, Pau wrote: Yes, will do. A broad test with many real-life users is going to follow starting on Tuesday when we deploy more nodes (for now it's only that one TP-LINK W8970B device replacing the stock VDSL router we got from the ISP (Vodafone). For now this has alreay been a success because I managed to extract the configuration of the original firmware and successfully use our hardware to manage the VDSL connection and setup VLANs, PPPoE, ... I committed to lime-sdk already. Nice, I overlooked that change (I forgot to git-pull my local copy of lime-packages which include that change) It has also been committed to lime-sdk already. I'm looking forward to get this going. babel and homenet have collected a lot of precious experience on how this can be achieved, hence all the logic is already present in netifd and we can subscribe to the relevant ubus events to get notified when ever the ISP delegates a new prefix via DHCP6. I was following this and it's also great news! Cool! Finally :) Isolation and lack of communication within our scene is the biggest problem we got imho. It looks like we are overcoming it, also thanks to LEDE being a more open and broad umbrella-project which now hosts several developers from different mesh communities and firmware projects. Cheers Daniel

On Mon, Jun 12, 2017 at 12:14:46AM +0200, Pau wrote: Things were deployed today and a small initial mesh went into production. There are about 8 more of TL-WR841Nv11 waiting in a box... Topology: Vodafone VDSL2 | TL-W8970B TL-WR841Nv11 | TL-WR841Nv11 | | +-----------(Ethernet wire)------------------------------------+ All three devices got ath9k radios and were setup with a simply community profile containing only /etc/config/lime-defaults: config lime system option hostname 'LiMe-%M4%M5%M6' option domain 'funkenteile' config lime network option primary_interface eth0 option main_ipv4_address '10.%N1.0.0/16' option main_ipv6_address '2a00:1508:0a%N1:%N200::/64' list protocols adhoc list protocols lan list protocols anygw list protocols batadv:%N1 list protocols bmx6:13 list resolvers 4.2.2.2 # b.resolvers.Level3.net list resolvers 141.1.1.1 # cns1.cw.net # list resolvers 2001:470:20::2 # ordns.he.net config lime wifi option channel_2ghz '1' option channel_5ghz '40' option country 'DE' option distance '2000' option htmode_5ghz 'HT40' option htmode_2ghz 'HT40' list modes 'ap' list modes 'ieee80211s' option ap_ssid 'Funkenteile' option ap_encryption 'psk2' option ap_key 'xxxxxxxxx' option ieee80211s_mesh_fwding '0' option ieee80211s_mesh_id 'LiMe' --- Let's start with the good side, the things that worked: * I mananged to configure VDSL2 and PPPoE on the TDW8970B! This is officially my first non-ar71xx LiMe node and it workes great! * 802.11s interfaces came up and got neighbours, AP+mesh mode works out-of-the-box on LEDE 17.01.2 * most other things worked as expected, which is great! Now to the non-working things (read: issues to be discussed): * watchping needs to be converted to procd so it gets the pppoe interface name when it actually comes up. Otherwise the gateway isn't detected (for obvious reasons) I can do that and will file a PR later tonight. * lm_net_wlan0_mesh was not created Despite being used a couple of times as an alias in /etc/config/network the 'config interface lm_net_wlan0_mesh' section wasn't created and hence all child vlan-interfaces also never came up. It was easy to fix it by adding config interface lm_net_wlan0_mesh option proto 'none' to /etc/config/network, after a subsequent network restart the VLANs got created and both bmx6 and batman-adv started meshing on top of the 802.11s mesh interface! To me the whole lime-system stuff is very intransparent and hard to wrap my head around, it also doesn't exactly have a lot of comments, so I'm totally in the dark why this section doesn't get created in first place. Fixing this is really important, but I couldn't do it (yet). Maybe someone who wrote the Lua code of lime-system can fix it...? * batman-adv and bmx6 vlans for wired interfaces I never quite understood how to connect two LiMe nodes over Ethernet in a way that they would exchange routing information, at least via bmx6 (I do understand that this nasty BLA bug prevents us from running batman-adv and a bare bridge-link and hence batman-adv-over- Ethernet doesn't work right now). Even worse: On the TL-WR841N devices the batman-adv and bmx6 VLANs were created only on the WAN interface (eth1). On the TDW8970 (which got only LAN Ethernet ports) the VLAN sections were created correctly, as 8021ad-type VLANs on top of the raw Ethernet device which is hooked into the br-lan bridge. I tried to build an image without the lime-hwd-openwrt-wan but didn't succeed, it somehow always ended up being installed :( Maybe there is a misunderstanding, but once again I'm failing to grasp how to debug lime-config, as (obviously) running it a second time after firstboot won't work :( Ok, that's it for the (obvious) bugs. In the long run it could be interesting to port the ciphers needed for SAE to be included in wpa_supplicant rather than needing OpenSSL for that. Then we could probably have something like a lime-zero-variant with encrypted mesh (but without webUI) which could be an intersting USE-case as well. However, I'd rather see bmx7 getting ready and allow using IPSec for bmx-created tun-interfaces :) Sidenote: Never, really never ever buy CCA (copper-coted-aluminum) wires. It's produced directly for the bin and not worth the effort even cutting, mounting and terminating it. Random link failures, some switches work, some don't, some just endup with a 10MB/s link, it's a hell you don't want to get in. I didn't even know that such bad things are sold, for now I always bought the cheapest Cat.6 cable and it always worked, this time was different :( I hope to hear from you and get things fixed up, so we'll have an awesome next LiMe release! Cheers Daniel

On 14/06/17 02:56, Daniel Golle wrote: Yes, you are not the first having this issue. ieee80211s must be enabled for WiFi but also Network configuration. https://github.com/libremesh/network-profiles/blob/master/libremesh/11s/etc… I've seen your PR, good work! We are testing it. -- ./p4u

On 14/06/17 02:56, Daniel Golle wrote: It looks like a bug, we checking this right now. -- ./p4u