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

[Adrian Schmutzler]

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
> >
> >
> >