[PATCH v9] Support batman-adv meshing over 802.11s

[Christian Dresel]

hi

On 15.10.2017 19:06, Tim Niemeyer wrote:
> Hi
> 
> Am Sonntag, den 15.10.2017, 18:58 +0200 schrieb Fabian Bläse:
>> Hallo Tim,
>>
>>>> diff --git a/bsp/ar71xx/.config b/bsp/ar71xx/.config
>>>> index b407f7d..0a5b9b9 100644
>>>> --- a/bsp/ar71xx/.config
>>>> +++ b/bsp/ar71xx/.config
>>>> @@ -7,9 +7,9 @@ CONFIG_TARGET_MULTI_PROFILE=y
>>>>  CONFIG_TARGET_DEVICE_ar71xx_generic_DEVICE_gl-ar150=y
>>>>  CONFIG_TARGET_DEVICE_PACKAGES_ar71xx_generic_DEVICE_gl-ar150=""
>>>>  CONFIG_TARGET_DEVICE_ar71xx_generic_DEVICE_archer-c25-v1=y
>>>> -CONFIG_TARGET_DEVICE_PACKAGES_ar71xx_generic_DEVICE_archer-c25-v1="-kmod-ath10k kmod-ath10k-ct -ath10k-firmware-qca9887 ath10k-firmware-qca9887-ct"
>>>> +CONFIG_TARGET_DEVICE_PACKAGES_ar71xx_generic_DEVICE_archer-c25-v1="-kmod-ath10k kmod-ath10k-ct"
>>> Es braucht kein Firmware Package? Wie auch immer dies zu lesen ist, ich
>>> hätte stumpf die Invertierung erwartet:
>>>
>>> CONFIG_TARGET_DEVICE_PACKAGES_ar71xx_generic_DEVICE_archer-c25-v1="kmod-ath10k -kmod-ath10k-ct ath10k-firmware-qca9887 -ath10k-firmware-qca9887-ct"
>>>
>>> Warum ist meine Annahme falsch?
>>
>> Weil diese Pakete per default drin sind, deswegen muss für den CT ja auch das “normale” raus (-kmod-ath10k)
> Ah, ja das ergibt Sinn!
> 
> Dann würde ich jetzt annehmen, dass das so sein müsste:
> CONFIG_TARGET_DEVICE_PACKAGES_ar71xx_generic_DEVICE_archer-c25-v1=""

ich habs mir von Gluon abgeguckt und die setzen beim kmod IMMER den -ct
ein (auch bei ibss) warum, weshalb? Weiß ich gerade nicht. Daher bin ich
der Meinung wie oben richtig. (ohne es anders getestet zu haben aber wie
oben tut es auf jeden Fall richtig, auch getestet)

> 
> Die kmod-ath10k ath10k-firmware-qca9887 sind ja beide schon drin und
> die *-ct Dinger sind ja eh nur ein Modul. Also per default auch nicht
> drin. Wobei ich mich dann auch Christians Anmerkung anschließen würde
> und die *-ct Pakete ganz aus der Config abwählen würde.>
>> Siehe auch: https://github.com/lede-project/source/blob/1c4a116a300d5447bf037760f64653556824ab77/target/linux/ar71xx/image/tp-link.mk#L108
>> Was genau war am normalerweise eingebauten Treiber eigentlich schlecht?
> Nach meinem Verständnis: Der "ohne -ct" Treiber kann zwar 11s aber kein
> ibss, der "-ct" kann es. Ganz sicher bin ich mir aber nicht..

ja gilt aber wohl nur für Firmware, für den kmod weiß ich es auch nicht
exakt was da der Unterschied ist.

> 
>>
>>>> @@ -155,9 +156,20 @@ if [ -s /tmp/keyxchangev2data ]; then
>>>>>>>>>  			# here we set a bit for add hidden AP
>>>>>  			touch /tmp/hiddenapflag
>>>>  
>>>>>>>>> -			if ! wifiAddAdHocMesh "$radio" "$mesh_essid" "$mesh_bssid"; then
>>>>>>>>> -				echo "Can't add AP interface on $radio."
>>>>>>>>> -				exit 1
>>>>>>>>> +			# add 802.11s mesh if type == "802.11s"
>>>>>>>>> +			if ( [ -n "$radio5" ] && [ "$mesh_type5" == "802.11s" ] ) || [ "$mesh_type2" == "802.11s" ]; then
>>>>>>>>> +				if ! wifiAddMesh "$radio" "$mesh_id"; then
>>>>>>>>> +					echo "Can't add Mesh interface on $radio."
>>>>>>>>> +					exit 1
>>>>>>>>> +				fi
>>>>> +			fi
>>>> +
>>>> +			# add IBSS mesh if type == "ibss"
>>> Das würde in dem Fall der ath10k Geräte nicht funktionieren. Man sollte
>>> mal testen, was dann konkret passiert. Wenn durch das Aktivieren von
>>> ibss auf einem ath10k mit 11s Firmware irgendwelche Nebeneffekte
>>> passieren wäre das hinlänglich doof.
>>>
>>> Wäre das der Fall, müsste man hier die Kompatibilität prüfen!
>>
>> Ja, das muss auf jeden Fall getestet werden. Ich dachte eigentlich,
>> dass ich das irgendwo mit dazu geschrieben hätte, aber scheinbar hab
>> ich das vergessen.
> Shit! Dann müssen wir irgendwo hinterlegen, welche Geräte mit welchem
> Type kompatibel sind.
> 
> Wenn wir den Aufwand nicht wollen, stelle ich nochmal zur Diskussion
> auf ibss ganz zu verzichten. Der Nachteil ist, dass wir keine wirkliche
> Field-Test Erfahrung mit 11s haben. Der Vorteil ist aber eine deutlich
> gesunkene Komplexität.
> 
> Im Moment müssen die Knoten eh mit allem kompatibel sein, weil es
> eigentlich gar keine Alternative gibt. Beim dezKeyX könnte der Knoten
> einfach die nächste Hood nehmen. Hier nicht.

also wegen mir kann ibss auch ganz fallen, ich bin da für alles offen.

mfg

Christian

> 
> Tim
> 
> 
> 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20171015/567f251f/attachment.sig>