On 09/11/16 00:56, Gui Iribarren wrote: adhoc confirmed not supported looking at "iw phy" 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)

From that team, thanks especially to drebs! for allowing me to remotely

anyway this thread will turn definitely "lime-dev", and offtopic for lime-users, so I'm moving the discussion there :) _______________________________________________ lime-users mailing list lime-users(a)lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users

On 09/11/16 17:21, Gui Iribarren wrote: Thank you so much Pau for always being so stubborn about the "ieee80211s" mode support in libremesh, insisting it would be better supported than adhoc in the future :) you were right! in few words, I managed to get LibreMesh working on an 802.11ac equipment, using ath10k and ieee80211s now, what about ath10k stability? Well, that's left as an exercise for the brasilian team :) From that team, thanks especially to drebs! for allowing me to remotely login and try to brick their devices ;) nice, very nice, after recreating the interface manually on both sides, but using "VHT80" mode, i get ~100mbps what follows are the manual steps, i don't think there's anything to fix on "our" (LibreMesh) side to properly support this; it's even possible that netifd from LEDE is already fixed. so i'll just do one of my "horrible hacks" in chef (overwriting the firmware file, and such) for the "rede Mocambos" to progress ASAP. iw phy phy0 interface add mesh0 type mp mesh_id LiMe iw mesh0 set freq 5180 80 5210 ip l set up mesh0 iw mesh0 station dump root@LiMe-09248f:~# netperf -cCD1 -Hfe80::32b5:c2ff:fe09:6034%mesh0 MIGRATED TCP STREAM TEST from :: (::) port 0 AF_INET6 to fe80::32b5:c2ff:fe09:6034 () port 0 AF_INET6 : demo Interim result: 91.69 10^6bits/s over 1.001 seconds ending at 1478709257.529 Interim result: 95.98 10^6bits/s over 1.002 seconds ending at 1478709258.532 Interim result: 96.33 10^6bits/s over 1.000 seconds ending at 1478709259.532 Interim result: 96.36 10^6bits/s over 1.001 seconds ending at 1478709260.533 Interim result: 96.26 10^6bits/s over 1.001 seconds ending at 1478709261.534 Interim result: 95.60 10^6bits/s over 1.006 seconds ending at 1478709262.540 Interim result: 96.91 10^6bits/s over 1.001 seconds ending at 1478709263.541 Interim result: 97.17 10^6bits/s over 1.001 seconds ending at 1478709264.542 Interim result: 96.97 10^6bits/s over 1.002 seconds ending at 1478709265.543 Interim result: 96.74 10^6bits/s over 0.994 seconds ending at 1478709266.538 Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB 87380 16384 16384 10.02 95.95 99.10 88.72 84.617 75.756 root@LiMe-09248f:~# iw mesh0 station dump Station 30:b5:c2:09:60:34 (on mesh0) inactive time: 920 ms rx bytes: 4400805 rx packets: 37312 tx bytes: 130131582 tx packets: 84801 tx retries: 0 tx failed: 0 signal: -42 dBm signal avg: -43 dBm Toffset: 33792059 us tx bitrate: 6.0 MBit/s rx bitrate: 975.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 3 mesh llid: 7963 mesh plid: 60395 mesh plink: ESTAB mesh local PS mode: ACTIVE mesh peer PS mode: ACTIVE mesh non-peer PS mode: ACTIVE authorized: yes authenticated: yes preamble: long WMM/WME: yes MFP: no TDLS peer: no connected time: 29 seconds _______________________________________________ lime-users mailing list lime-users(a)lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users

On 09/11/16 17:59, Gio wrote: i know, i know, the configuration created by lime is perfectly correct (with proto=ieee80211s) the problem is that netifd doesn't configure the interfaces optimally and that the firmware bundled in the vanilla ath10k-firmware-qca988x doesn't support mesh mode :( so that's why i said there's nothing to fix in LiMe, they are all problems of openwrt 15.05.1 at some point, we could make a LiMe release 16.07.1 to workaround the problems, but first i'll test everything in a single network in chef, and then we can take that experience as a base packages/lime-system/files/usr/lib/lua/lime/mode/ieee80211s.lua 11ac)-for-Mesh-Support i downloaded this exact file QCA988X/hw2.0/10.2.4.7 0/firmware-5.bin_10.2.4.70.6-2 netlink 11ac)-for-Mesh-Support the syntax is supposed to be "iw mesh0 set freq 5180 80 5210" -43 dBm ACTIVE mesh peer no TDLS peer: _______________________________________________ lime-users mailing list lime-users(a)lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users