On 09/11/16 17:59, Gio wrote:
> Hey!
>
> If i rembember well i have implemented 80211s support in libremsh
> long time ago!!
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
>
> https://github.com/libremesh/lime-packages/blob/develop/ packages/lime-system/files/ usr/lib/lua/lime/mode/ ieee80211s.lua
>
> So no need of dirty stuff in chef! Yeah I know you like dirty stuff
> :p
>
> But no need this time just add ieee80211s to wifi modes and protos
> and it should work like a charm (beware that this combination just
> use ieee80211s like a smarter adhoc but don't use it for routing or
> other trickeris)
>
> Baci!
>
> On Wednesday 09 November 2016 17:44:33 Gui Iribarren wrote:
>> On 09/11/16 17:21, Gui Iribarren wrote:
>>> 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.7
>>>
>>>
0/firmware-5.bin_10.2.4.70.6-2
>>>
>>> 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)
>>
>> 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
>>
>>> 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@lists.libremesh.org
>>>> https://lists.libremesh.org/mailman/listinfo/lime-users
>>>
>>> _______________________________________________ lime-users
>>> mailing list lime-users@lists.libremesh.org
>>> https://lists.libremesh.org/mailman/listinfo/lime-users
>>
>> _______________________________________________ lime-users mailing
>> list lime-users@lists.libremesh.org
>> https://lists.libremesh.org/mailman/listinfo/lime-users
>
> _______________________________________________ lime-users mailing
> list lime-users@lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users
>
_______________________________________________
lime-users mailing list
lime-users@lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users