[PATCH] deactivate 802.11b on AP

Christian Dresel fff at chrisi01.de
Sa Mai 27 09:50:38 CEST 2017


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-beispiel-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-137417111
> 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-137417111
>>>
>>> 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&status[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-fuer-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/wireless
>>>>>>> b/src/packages/fff/fff-wireless/files/lib/functions/fff/wireless
>>>>>>> index 59c8ce2..0a16eb7 100644
>>>>>>> --- a/src/packages/fff/fff-wireless/files/lib/functions/fff/wireless
>>>>>>> +++ b/src/packages/fff/fff-wireless/files/lib/functions/fff/wireless
>>>>>>> @@ -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.net
>>
> 
> 
> 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20170527/c8a8c83d/attachment.sig>


Mehr Informationen über die Mailingliste franken-dev