[PATCH] deactivate 802.11b on AP

Adrian Schmutzler mail at adrianschmutzler.de
Mo Mai 29 12:28:16 CEST 2017


Hallo,

in diesem Kontext vll. auch interessant für euch (v.a. die verlinkte
Präsentation):

https://github.com/lede-project/source/commit/e194e1b3c838a301178effb639804c
28fe67354d

https://mentor.ieee.org/802.11/dcn/14/11-14-0099-00-000m-renewing-2-4ghz-ban
d.pptx

Grüße

Adrian

-----Original Message-----
From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Montag, 29. Mai 2017 12:02
To: 'Christian Dresel' <fff at chrisi01.de>; franken-dev at freifunk.net
Subject: RE: [PATCH] deactivate 802.11b on AP

Klingt für mich aus Sicht aufs air interface absolut plausibel, daß man die
alten Zöpfe so langsam abschneidet. Die niederwertigen Modulationsarten
können allerdings für grenzwertige Verbindungen an der Reichweitengrenze
schon noch wichtig sein, daher scheint mir auch ein Häkchen im UI da eine
tolle Möglichkeit, das nur wahlweise abzudrehen. 

Die genannte hostapd-phy0.conf ist die Datei, in der ich auch manuell dran
drehen kann, oder wird die automagisch von anderswo her befeuert? Dann
könnte ich nämlich mal mit meinen Nutzern ein wenig experimentieren, ich
habe ja einerseits die im Haus gegenüber, und dann noch die Griller im
Wiesengrund :) Da sollte ich es schnell an den Nutzerzahlen bemerken, wenn
eine Einstellung nennenswert Nutzer ausschließt.

Viele Grüße

Ralph.

> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf 
> Of Christian Dresel
> Sent: Saturday, May 27, 2017 9:51 AM
> To: Moexe; franken-dev at freifunk.net
> Cc: Tobias Klaus
> Subject: Re: [PATCH] deactivate 802.11b on AP
> 
> Hi
> 
> netterweise wurde im IRC heute morgen ein Talk über WLAN (uh 11ax wird
geil
> OFDMA uhhh) von der GPN17 gepostet den ich mir direkt mal reingezogen 
> habe. Dabei hab ich mich wieder an diesen Patch erinnert welches noch 
> in
der
> Luft hängt.
> Ich hab mir das ganze mal angeguckt um ein paar "Daten" zu haben
> 
> ohne
> require_mode 'g'
> ohne basic/support rate set
> (also so wie es aktuell ist)
> 
> cat /var/run/hostapd-phy0.conf
> driver=nl80211
> logger_syslog=127
> logger_syslog_level=2
> logger_stdout=127
> logger_stdout_level=2
> country_code=DE
> ieee80211d=1
> hw_mode=g
> channel=1
> 
> 
> mit
> require_mode 'g'
> 
> cat /var/run/hostapd-phy0.conf
> driver=nl80211
> logger_syslog=127
> logger_syslog_level=2
> logger_stdout=127
> logger_stdout_level=2
> country_code=DE
> ieee80211d=1
> hw_mode=g
> basic_rates=60 120 240
> channel=1
> 
> mit
> supported_rates '6000 9000 12000 18000 24000 36000 48000 54000'
> basic_rate '6000 9000 18000 36000 54000'
> 
> cat /var/run/hostapd-phy0.conf
> driver=nl80211
> logger_syslog=127
> logger_syslog_level=2
> logger_stdout=127
> logger_stdout_level=2
> country_code=DE
> ieee80211d=1
> hw_mode=g
> supported_rates=60 90 120 180 240 360 480 540
> basic_rates=60 90 180 360 540
> channel=1
> 
> Wenn ich das richtig sehe, haben die auf Github recht, die 
> supported_rates werden durch require_mode 'g' nicht gesetzt. Dadurch 
> ist eine normale
(nicht
> Broad/Multicast) Kommunikation mit 11b theoretisch noch möglich.
> Ich bin also jetzt eindeutig dafür, die basic und support Rates per 
> Hand
zu
> setzen.
> 
> Dazu bin ich noch auf diesen Beitrag gestolpert, dort wird 
> angesprochen
alles
> unter 16-QAM (also BPSK und QPSK) abzuschalten:
> https://forum.freifunk.net/t/optimierung-der-wlan-datenraten-am-beispi
> el-
> aachen/14384/28
> 
> Demnach wären dann die Settings:
> 
> supported_rates '24000 36000 48000 54000'
> basic_rate '24000 36000 54000'
> 
> Mein Vorschlag:
> 
> Wir setzen Standartmäßig:
> supported_rates '6000 9000 12000 18000 24000 36000 48000 54000'
> basic_rate '6000 9000 18000 36000 54000'
> 
> um zumindest 11b los zu werden und geben im WebUI eine Option frei auf:
> supported_rates '24000 36000 48000 54000'
> basic_rate '24000 36000 54000'
> 
> zu setzen mit einer kurzen Erklärung dazu, das können Leute dann 
> expliziet probieren z.b. auch in Gegenden mit hoher Airtimebelastung
Probleme haben.
> 
> Meinungen dazu?
> 
> mfg
> 
> Christian
> 
> On 23.03.2017 21:00, Christian Dresel wrote:
> > Hallo Max
> >
> > ich hab mit Tobias nochmal darüber gesprochen. Die Meinung ging dann 
> > doch wieder eher Richtung mein Patch.
> > So recht sicher sind wir uns aber nicht gewesen.
> >
> > Ich würde das Zeug auch gerne bei mir rein basteln bin mir aber 
> > absolut unschlüssig was nun richtig ist. Messen kann man das ja auch 
> > nur ziemlich schlecht.
> >
> > Einerseits ja, require_mode='g' ist recht flexibel und überlässt es 
> > den Treiber/OS was genau deaktiviert werden soll, das wird schon 
> > wissen was richtig ist.
> > Interessant ist dabei halt dieser Satz:
> > "Also require_mode tut nichts anderes, als die basic_rate's setzen.
> > Damit werden zwar die 802.11b Geräte ausgeschlossen, aber der AP 
> > sagt, er könne noch 802.11b als mögliche Datenraten. Setzt mal 
> > supported_rates, verschwinden die langsamen Datenraten aus der Liste 
> > der unterstützten Datenraten."
> > Quelle:
> > https://github.com/freifunk-gluon/gluon/pull/467#issuecomment-137417
> > 11
> > 1 müsste man mal testen ob es wirklich so ist, wenn ja halte ich 
> > require_mode='g' wirklich für suboptimal.
> >
> > Anderseits wenn man Support/Basic Rate setzt, dann hab ich es in der 
> > Hand das zu setzen was ich auch wirklich will. Ich bin eher ein 
> > "manueller" Mensch und würde gerne selbst sagen was ich will. Daher 
> > bin ich bei mir stark am überlegen die Support/Basic Rates so zu setzen:
> >
> > 'supported_rates', '6000 9000 12000 18000 24000 36000 48000 54000'
> > 'basic_rate', '6000 9000 18000 36000 54000'
> >
> > und mich daran halten, was auch die Gluon Leute machen. Man kann 
> > dann noch drüber nachdenken die 6000 und 9000 komplett rauszunehmen 
> > und dafür
> > 12000 bei basic mit rein, würde ich wohl dort machen wo ich 
> > Airtimeprobleme hätte (aktuell nirgens bei mir der Fall) und es mal 
> > ausprobieren wenn dann beispielsweise 200Mbit bei 11n nicht möglich 
> > sind aber 180Mbit und 220Mbit (weil sich die 'n' Raten eben aus den 
> > Dingern ableiten und ich es dummerweise entfernt habe) was solls, 
> > dann ist es eben so.
> >
> > mfg
> >
> > Christian
> >
> > On 23.03.2017 14:27, Moexe wrote:
> >> Moin,
> >>
> >> hat sich hier noch was getan?
> >> Sind Die verschiedenen configs mal getestet worden?
> >>
> >> Ich würde das gerne auch mal testen, und wollte nur den aktuellen 
> >> Stand
> wissen.
> >>
> >> Grüße
> >>
> >> Max
> >>
> >>
> >>> Am 17.02.2017 um 15:04 schrieb Christian Dresel <fff at chrisi01.de>:
> >>>
> >>> Hallo
> >>>
> >>> danke für das Review. Bitte das Patch noch NICHT applien und 
> >>> erstmal hier lesen:
> >>>
> >>> https://github.com/freifunk-gluon/gluon/pull/467#issuecomment-1374
> >>> 17
> >>> 111
> >>>
> >>> Evtl. sollten wir doch die Support/Basic Rates setzen und das 
> >>> require_mode weglassen? Bin jetzt etwas zwiegespaltet. Was meint ihr?
> >>>
> >>> mfg
> >>>
> >>> Christian
> >>>
> >>>> On 16.02.2017 21:45, Tobias Klaus wrote:
> >>>> Hallo Christian,
> >>>>
> >>>> vielen Dank fürs googeln. Das hätte ich bei ner negativen Antwort 
> >>>> deinerseits natürlich auch gemacht, aber so wars ja dann praktischer.
> >>>>
> >>>> Also ich verstehe die Quelle deines ersten Links so, dass es 
> >>>> immer Einbußen bringt 11b zu unterstützen.
> >>>>
> >>>> Daher:
> >>>> Reviewed-by: Tobias Klaus <tk+ff at meskal.net>
> >>>>
> >>>> Das muss natürlich in den Releasenotes klar gemacht werden.
> >>>> Allerdings weiß ich bisher nur von einer Person, die noch ein 
> >>>> solches Gerät besitzt(Grüße ins IRC ;-) )
> >>>>
> >>>> Viele Grüße
> >>>> Tobias
> >>>>
> >>>> Am Dienstag, 14. Februar 2017, 19:03:43 CET schrieb Christian Dresel:
> >>>>> Hi
> >>>>>
> >>>>> wirklich beantworten kann ich dir deine Frage selbst nicht, aber 
> >>>>> ein wenig googlen:
> >>>>>
> >>>>> "Eine Erklärung ist, dass bei jedem datenpaket zusätzlich ein ‘b’
> >>>>> paket verschickt wird, um die Airtime zu reservieren. das fällt 
> >>>>> dann weg."
> >>>>>
> >>>>> Quelle:
> >>>>> https://bt.freifunk-dresden.de/index.php?do=details&task_id=66&s
> >>>>> ta tus[0]=&or der=status&sort=desc (ja Zertifikat ist kaputt ;))
> >>>>>
> >>>>> "In addition to the overhead created by the SSID’s you also have 
> >>>>> 802.11g protection mechanism that requires sending of an 802.11b 
> >>>>> packet reserving the airtime to then send the 802.11g or 802.11n 
> >>>>> packet – that’s two packets for every single user data packet – 
> >>>>> and this translates to as much as a 50% reduction of available
> bandwidth."
> >>>>>
> >>>>> Quelle:
> >>>>> https://forum.ortenau.freifunk.net/t/wlan-802-11b-abschalten-fue
> >>>>> r-
> >>>>> mehr-perfo
> >>>>> rmance/64
> >>>>>
> >>>>> wenn ich das richtig verstehe, gehts da wohl eher um die "Beacons"
> >>>>> die noch mit dem langsame "b" versendet werden und die Airtime
> kosten.
> >>>>>
> >>>>> Man liest aber auch immer wieder, das man am besten auch 
> >>>>> Basic/Supportrate setzen sollte, im 1. Link ist im Kommentar 
> >>>>> auch erklärt, wieso nur bis 54Mbit gesetzt werden, die "n" MCS 
> >>>>> Datenraten werden aus den "g" Datenraten abgeleitet, weshalb 
> >>>>> zumindest als support alle gesetzt werden müssen da sonst manche 
> >>>>> "n" Raten nicht mehr möglich sind.
> >>>>> Anderseits, wenn man "g" vorraussetzt, müsste alles unter 6Mbit 
> >>>>> sowieso nicht mehr möglich sein, da "g" keine kleineren 
> >>>>> Datenraten
> kennt.
> >>>>>
> >>>>> mfg
> >>>>>
> >>>>> Christian
> >>>>>
> >>>>>> On 14.02.2017 18:41, Tobias Klaus wrote:
> >>>>>> Hey Christian,
> >>>>>>
> >>>>>> hat es negativen Einfluss auf den Durchsatz eines Routers, wenn 
> >>>>>> wir weiterhin 'b' akzeptieren, aber gerade kein 'b' Gerät in
Reichweite
> ist?
> >>>>>> In diesem Fall wäre ich auch sofort dafür, 'b' abzuschalten.
> >>>>>>
> >>>>>> Falls dem nicht so ist und es nur schlecht wird, wenn ein 'b'
> >>>>>> Gerät kommuniziert, würde ich b gern weiterhin akzeptieren, da 
> >>>>>> ich lieber den vermutlich wirklich wenigen Geräten die 
> >>>>>> Verbindung "gönne". Ich denke in der Praxis sollte dieser Fall 
> >>>>>> eh nicht mehr auftauchen(ich hatte glaub noch nie ein 'b'-only 
> >>>>>> Gerät in der
Hand).
> >>>>>>
> >>>>>> Viele Grüße
> >>>>>>
> >>>>>> Tobias
> >>>>>>
> >>>>>> Am 14. Februar 2017 15:34:11 MEZ schrieb Christian Dresel
> >>>> <fff at chrisi01.de>:
> >>>>>>> Hiermit wird 802.11b auf den Accesspoint deaktiviert.
> >>>>>>>
> >>>>>>> Signed-off-by: Christian Dresel <fff at chrisi01.de>
> >>>>>>> ---
> >>>>>>> src/packages/fff/fff-wireless/files/lib/functions/fff/wireless 
> >>>>>>> |
> >>>>>>> 1 +
> >>>>>>> 1 file changed, 1 insertion(+)
> >>>>>>>
> >>>>>>> diff --git
> >>>>>>> a/src/packages/fff/fff-wireless/files/lib/functions/fff/wirele
> >>>>>>> ss 
> >>>>>>> b/src/packages/fff/fff-wireless/files/lib/functions/fff/wirele
> >>>>>>> ss
> >>>>>>> index 59c8ce2..0a16eb7 100644
> >>>>>>> ---
> >>>>>>> a/src/packages/fff/fff-wireless/files/lib/functions/fff/wirele
> >>>>>>> ss
> >>>>>>> +++ b/src/packages/fff/fff-wireless/files/lib/functions/fff/wi
> >>>>>>> +++ re
> >>>>>>> +++ less
> >>>>>>> @@ -37,6 +37,7 @@ wifiAddPhy() {
> >>>>>>>
> >>>>>>>        set wireless.${radio}.hwmode='${hwmode}'
> >>>>>>>        set wireless.${radio}.htmode='HT20'
> >>>>>>>        set wireless.${radio}.country='DE'
> >>>>>>>
> >>>>>>> +        set wireless.${radio}.require_mode='g'
> >>>>>>>
> >>>>>>>        commit wireless
> >>>>>>>
> >>>>>>>    __EOF__
> >>>>
> >>>
> >>> --
> >>> franken-dev mailing list
> >>> franken-dev at freifunk.net
> >>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.ne
> >>> t
> >>
> >
> >
> >


--
franken-dev mailing list
franken-dev at freifunk.net
http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net



Mehr Informationen über die Mailingliste franken-dev