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

Mo Okt 16 15:09:38 CEST 2017

Ich wäre auch dafür, zumindest zunächst die Flexibilität im Code beizubehalten und das bei den known-issues oder so mit aufzunehmen, welche Geräte nicht IBSS sprechen.

Aber auf jeden Fall sollten alle neuen zentralen Hoods auf 11s setzen.

Fabian

> On 16. Oct 2017, at 12:25, Adrian Schmutzler <mail at adrianschmutzler.de> wrote:
> 
> Hallo,
> 
> ich bin dafür, die Flexibilität beizubehalten und sowohl 11s als auch ibss anzubieten.
> 
> Im Moment sind ja nur 2 (Nischen-)Geräte betroffen, wenn ich das richtig verstanden habe.
> 
> Grüße
> 
> Adrian
> 
>> -----Original Message-----
>> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf
>> Of Christian Dresel
>> Sent: Sonntag, 15. Oktober 2017 19:12
>> To: Tim Niemeyer <tim at tn-x.org>; franken-dev at freifunk.net; Fabian Bläse
>> <fabian at blaese.de>
>> Subject: Re: [PATCH v9] Support batman-adv meshing over 802.11s
>> 
>> 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/1c4a116a300d5447bf037760f
>>>> 64653556824ab77/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
>>> 
>>> 
>>> 
> 
> 
> --
> franken-dev mailing list
> franken-dev at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net

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