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

Tim Niemeyer tim at tn-x.org
Mo Okt 16 21:45:40 CEST 2017


Am Sonntag, den 15.10.2017, 19:11 +0200 schrieb 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)

Ok, da es getestet wurde..

Und wegen dem mesh_type = adhoc und dem ath10k scheint der Konsens ja
zunächst zu sein mit Known-Issue zu fahren..

.. Patch applied.

Tim

> 
> > 
> > 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  : 488 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20171016/4274fdb5/attachment.sig>


Mehr Informationen über die Mailingliste franken-dev