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

[Tim Niemeyer]

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

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

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

Tim
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 488 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20171015/5238b9de/attachment.sig>