| Message ID | 1487082851-3346-1-git-send-email-fff@chrisi01.de |
|---|---|
| State | Superseded |
| Headers | show |
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__
Sperrt das eigentlich ac/n mit aus, auch wenn es die Hardware kann? On 14.02.2017 15:34, Christian Dresel wrote: > Hiermit wird 802.11b auf den Accesspoint deaktiviert. > > Signed-off-by: Christian Dresel <fff@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__ >
Hi On 14.02.2017 15:38, freifunk-mailing@chrisnew.de wrote: > Sperrt das eigentlich ac/n mit aus, auch wenn es die Hardware kann? also "n" sollte es auf keinen Fall aussperren, da "n" > "g" ist (require_mode -> das was mindestens unterstützt wird). a/ac ist aber tatsächlich interessant, weil bei meiner Lösung require_mode='g' auch auf 5GHz Radios gesetzt wird. Ich hab das eben mit einer 'a' Hardware (wdr4900) getestet und es stört hier nicht. Er sendet weiterhin ganz normal seine 5GHz aus und man kann verbinden usw. Vermutlich ist einfach 'a' >(=) 'g' anzusehen. Auf 'ac' kann ich es leider aus Mangel an Hardware nicht testen, aber ich denke wenn 'a' geht, geht auch 'ac' Hier mal eben paar Auszüge aus Tests: root@UFBWZ:~# iw dev w5ap station dump Station 64:bc:0c:80:7c:2b (on w5ap) inactive time: 5244 ms rx bytes: 40887 rx packets: 299 tx bytes: 73395 tx packets: 175 tx retries: 0 tx failed: 0 signal: -41 [-47, -45, -45] dBm signal avg: -41 [-48, -44, -44] dBm tx bitrate: 144.4 MBit/s MCS 15 short GI rx bitrate: 6.0 MBit/s expected throughput: 47.57Mbps authorized: yes authenticated: yes preamble: short WMM/WME: yes MFP: no TDLS peer: no connected time: 37 seconds root@UFBWZ:~# iw dev w2ap station dump Station 64:bc:0c:80:7c:2b (on w2ap) inactive time: 8 ms rx bytes: 36473 rx packets: 319 tx bytes: 76453 tx packets: 193 tx retries: 60 tx failed: 2 signal: -34 [-37, -39, -41] dBm signal avg: -33 [-37, -38, -37] dBm tx bitrate: 86.7 MBit/s MCS 12 short GI rx bitrate: 144.4 MBit/s MCS 15 short GI expected throughput: 36.529Mbps authorized: yes authenticated: yes preamble: short WMM/WME: yes MFP: no TDLS peer: no connected time: 7 seconds (Getestet mit einem Handy am wdr4900) mfg Christian > > > On 14.02.2017 15:34, Christian Dresel wrote: >> Hiermit wird 802.11b auf den Accesspoint deaktiviert. >> >> Signed-off-by: Christian Dresel <fff@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__ >> > >
Hallo nach der Doku unter https://lede-project.org/docs/user-guide/wifi_configuration require_mode string no none (AP mode) Set the minimum mode that connecting clients need to support to be allowed to connect. Supported values: g = 802.11g, n = 802.11n, ac = 802.11ac bewirkt das das mindestens g benutzt werden muss. evtl. könnten wir noch basic_rate list no (hostapd/driver default) Set the supported basic rates. Each basic_rate is measured in kb/s. This option only has an effect on ap and adhoc wifi-ifaces. supported_rateslist no (hostapd/driver default) Set the supported data rates. Each supported rate is measured in kb/s. This option only has an effect on ap and adhoc wifi-ifaces. Must be a superset of basic_rate. Basic_rate should be the lowest data rates. Anwenden wie am Beispiel von https://github.com/ffac/site/commit/a65f0e74ba41ab3e98adca0061c50cea3c9cc4aa MFG MisterCrumble Am 14. Februar 2017 um 15:38 schrieb <freifunk-mailing@chrisnew.de>: > Sperrt das eigentlich ac/n mit aus, auch wenn es die Hardware kann? > > > On 14.02.2017 15:34, Christian Dresel wrote: >> Hiermit wird 802.11b auf den Accesspoint deaktiviert. >> >> Signed-off-by: Christian Dresel <fff@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@freifunk.net > http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
hi On 14.02.2017 15:47, Mister Crumble wrote: > Hallo nach der Doku unter > > https://lede-project.org/docs/user-guide/wifi_configuration > > require_mode string no none (AP mode) Set the minimum mode that > connecting clients need to support to be allowed to connect. Supported > values: g = 802.11g, n = 802.11n, ac = 802.11ac > > bewirkt das das mindestens g benutzt werden muss. genau das bewirkt mein Patch, die Airtime klauenden 'b' Leute endlich komplett rauszusperren (falls es noch welche gibt...) > > evtl. könnten wir noch > > basic_rate list no (hostapd/driver default) Set the supported basic > rates. Each basic_rate is measured in kb/s. This option only has an > effect on ap and adhoc wifi-ifaces. supported_rateslist no > (hostapd/driver default) Set the supported data rates. Each supported > rate is measured in kb/s. This option only has an effect on ap and > adhoc wifi-ifaces. Must be a superset of basic_rate. Basic_rate should > be the lowest data rates. > > > Anwenden wie am Beispiel von > https://github.com/ffac/site/commit/a65f0e74ba41ab3e98adca0061c50cea3c9cc4aa darüber hab ich mir auch schon Gedanken gemacht. Ich würde das aber in 2,4GHz und 5GHz dann gerne aufteilen. Mein Vorschlag: 2,4GHz Basic: 12000, 18000, 36000, 54000 Support: 12000, 18000, 24000, 36000, 48000, 54000 Ich denke alles unter 12Mbit bringt auf 2,4GHz einfach rein gar nix, da machen die Störungen schon mehr kaputt als das noch irgendwas durch geht (und klauen gerade auf dem schmalen 2,4GHz Band gewaltig viel Airtime, ich weiß nicht wie gut das Airtime Fairness im LEDE schon klappt...). Bei Support bin ich mir unsicher, muss man da evtl. auch mehr angeben? Immerhin ist das nur 'g' was ist mit 'n' also bis 150Mbit bzw. 300Mbit oder gar 450Mbit...? Hab das nicht ganz verstanden warum das anscheinend nirgends angeben wird (ist im Unifi Controller aber ebenso, alles nur bis 54Mbit). Im noch freieren 5GHz Band, wäre ich etwas offener und würde zu Basic: 6000, 9000, 18000, 36000, 54000 Support: 6000, 9000, 12000, 18000, 24000, 36000, 48000, 54000 tendieren (Support das gleiche wie bei 2,4GHz unsicher...). Dazu müsste man das Script aber noch etwas weiter umbauen und das ist mir gerade etwas zuviel, wenn es jemand machen will nur zu. Meinen Review würde ich drunter hauen ;) mfg Christian > > MFG MisterCrumble > > > Am 14. Februar 2017 um 15:38 schrieb <freifunk-mailing@chrisnew.de>: >> Sperrt das eigentlich ac/n mit aus, auch wenn es die Hardware kann? >> >> >> On 14.02.2017 15:34, Christian Dresel wrote: >>> Hiermit wird 802.11b auf den Accesspoint deaktiviert. >>> >>> Signed-off-by: Christian Dresel <fff@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@freifunk.net >> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
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]=&order=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-performance/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@chrisi01.de>: >> Hiermit wird 802.11b auf den Accesspoint deaktiviert. >> >> Signed-off-by: Christian Dresel <fff@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__ >>
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@chrisi01.de>: >Hiermit wird 802.11b auf den Accesspoint deaktiviert. > >Signed-off-by: Christian Dresel <fff@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__ >
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@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@chrisi01.de>: > >> Hiermit wird 802.11b auf den Accesspoint deaktiviert. > >> > >> Signed-off-by: Christian Dresel <fff@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__
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@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@chrisi01.de>: >>>> Hiermit wird 802.11b auf den Accesspoint deaktiviert. >>>> >>>> Signed-off-by: Christian Dresel <fff@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__ >
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@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@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@chrisi01.de>: >>>>> Hiermit wird 802.11b auf den Accesspoint deaktiviert. >>>>> >>>>> Signed-off-by: Christian Dresel <fff@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@freifunk.net > http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
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@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@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@chrisi01.de>: >>>>>> Hiermit wird 802.11b auf den Accesspoint deaktiviert. >>>>>> >>>>>> Signed-off-by: Christian Dresel <fff@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@freifunk.net >> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net >
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@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@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@chrisi01.de>: >>>>>>> Hiermit wird 802.11b auf den Accesspoint deaktiviert. >>>>>>> >>>>>>> Signed-off-by: Christian Dresel <fff@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@freifunk.net >>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net >> > > >
Hi Am 27. Mai 2017 09:50:38 MESZ schrieb Christian Dresel <fff@chrisi01.de>: >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. Da die meisten Knoten eh nur reine Access Knoten sind würde ich es vielleicht sogar anders rum machen, sprich: per default min 24Mbit und per webui auf min 6Mbit runterstellbar. Tim >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@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@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@chrisi01.de>: >>>>>>>> Hiermit wird 802.11b auf den Accesspoint deaktiviert. >>>>>>>> >>>>>>>> Signed-off-by: Christian Dresel <fff@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@freifunk.net >>>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net >>> >> >> >>
Hi, wg. 6 vs. 24 Mbit/s: wie sind denn so die Empfindlichkeiten bei 1/6/11/24 Mbit der wichtigsten Router (841,1043,4300) ? Nicht dass wir da irgendwelche Meshverbindungen kappen... Fände ich unschön ;) Sind davon dann eigentlich auch die n-Modis betroffen (aka: werden die intern wie verbesserte g-Modi behandelt? Falls nein dürfte es nichts bringen (dann machen sie halt statt 6 Mbit/s 6,5 Mbit/s), falls ja führen dann halt Störungen (und wenn sie nur paar Sekunden bis Minuten sind) zu Abbrüchen auch bei Verbindungen, die sonst stabil 24 oder mehr Mbit machen. Ich hab z.B. ne stabile Meshverbindung laufen, die sich bei -78 dBm so zw. 20 und 45 Mbit/s einpendelt. Die würde es dann vermutlich zuweilen wegkegeln. Standard würde ich die min. 24 Mbit auf keinen Fall machen, optional wäre ok. Die APs, wo man auf die Air-Time aufpassen muss, sollten deutlich in der Unterzahl sein... Viele Grüße, Michael
Guten Morgen On 27.05.2017 23:37, Michael Fritscher wrote: > Hi, > > wg. 6 vs. 24 Mbit/s: > wie sind denn so die Empfindlichkeiten bei 1/6/11/24 Mbit der wichtigsten > Router (841,1043,4300) ? Nicht dass wir da irgendwelche Meshverbindungen > kappen... Fände ich unschön ;) ich glaube wenn wir eine 6/12Mbit Verbindung kappen... die will eh niemand nutzen. > > Sind davon dann eigentlich auch die n-Modis betroffen (aka: werden die > intern wie verbesserte g-Modi behandelt? Falls nein dürfte es nichts > bringen (dann machen sie halt statt 6 Mbit/s 6,5 Mbit/s), falls ja führen 6,5MBit sollte kein n-Modi sein oder wo kommt diese Zahl her? 11b hat: 1 2 5,5 und 11Mbit BPSK: 6 und 9MBit (g) QPSK: 12 und 18 Mbit QAM: ab 24Mbit n Modi liegen über 54Mbit und werden wohl aus den eingestellten g-modi abgeleitet. Das wäre evtl. ein Grund warum man die Werte ab 6Mbit nicht unbedingt wegsperren sollte, da dann u.U. auch irgendwelche MCS im n-Modus wegfallen. Wie genau das berechnet/abgeleitet wird, ist mir aktuell nicht bekannt müsste man mal raussuchen. Von der Seite gesehen wäre es wohl sinnvoll, doch alle Werte ab 6MBit mit reinzunehmen. > dann halt Störungen (und wenn sie nur paar Sekunden bis Minuten sind) zu > Abbrüchen auch bei Verbindungen, die sonst stabil 24 oder mehr Mbit > machen. > > Ich hab z.B. ne stabile Meshverbindung laufen, die sich bei -78 dBm so zw. > 20 und 45 Mbit/s einpendelt. Die würde es dann vermutlich zuweilen > wegkegeln. und da geht noch was sinnvolles drüber? mfg Christian > > Standard würde ich die min. 24 Mbit auf keinen Fall machen, optional wäre > ok. Die APs, wo man auf die Air-Time aufpassen muss, sollten deutlich in > der Unterzahl sein... > > Viele Grüße, > Michael >
Hi Am 28. Mai 2017 07:58:08 MESZ schrieb Christian Dresel <fff@chrisi01.de>: >Guten Morgen > >On 27.05.2017 23:37, Michael Fritscher wrote: >> Hi, >> >> wg. 6 vs. 24 Mbit/s: >> wie sind denn so die Empfindlichkeiten bei 1/6/11/24 Mbit der >wichtigsten >> Router (841,1043,4300) ? Nicht dass wir da irgendwelche >Meshverbindungen >> kappen... Fände ich unschön ;) > >ich glaube wenn wir eine 6/12Mbit Verbindung kappen... die will eh >niemand nutzen. > >> >> Sind davon dann eigentlich auch die n-Modis betroffen (aka: werden >die >> intern wie verbesserte g-Modi behandelt? Falls nein dürfte es nichts >> bringen (dann machen sie halt statt 6 Mbit/s 6,5 Mbit/s), falls ja >führen > >6,5MBit sollte kein n-Modi sein oder wo kommt diese Zahl her? >11b hat: 1 2 5,5 und 11Mbit >BPSK: 6 und 9MBit (g) >QPSK: 12 und 18 Mbit >QAM: ab 24Mbit >n Modi liegen über 54Mbit und werden wohl aus den eingestellten g-modi >abgeleitet. Das wäre evtl. ein Grund warum man die Werte ab 6Mbit nicht >unbedingt wegsperren sollte, da dann u.U. auch irgendwelche MCS im >n-Modus wegfallen. Wie genau das berechnet/abgeleitet wird, ist mir >aktuell nicht bekannt müsste man mal raussuchen. >Von der Seite gesehen wäre es wohl sinnvoll, doch alle Werte ab 6MBit >mit reinzunehmen. Machen wir es in zwei patches. Erstmal b abschalten. Das weiter kann dann separat diskutiert werden. Tim > >> dann halt Störungen (und wenn sie nur paar Sekunden bis Minuten sind) >zu >> Abbrüchen auch bei Verbindungen, die sonst stabil 24 oder mehr Mbit >> machen. >> >> Ich hab z.B. ne stabile Meshverbindung laufen, die sich bei -78 dBm >so zw. >> 20 und 45 Mbit/s einpendelt. Die würde es dann vermutlich zuweilen >> wegkegeln. > >und da geht noch was sinnvolles drüber? > > >mfg > >Christian > >> >> Standard würde ich die min. 24 Mbit auf keinen Fall machen, optional >wäre >> ok. Die APs, wo man auf die Air-Time aufpassen muss, sollten deutlich >in >> der Unterzahl sein... >> >> Viele Grüße, >> Michael >>
On 28.05.2017 09:13, Tim Niemeyer wrote: > Hi > > Am 28. Mai 2017 07:58:08 MESZ schrieb Christian Dresel <fff@chrisi01.de>: >> Guten Morgen >> >> On 27.05.2017 23:37, Michael Fritscher wrote: >>> Hi, >>> >>> wg. 6 vs. 24 Mbit/s: >>> wie sind denn so die Empfindlichkeiten bei 1/6/11/24 Mbit der >> wichtigsten >>> Router (841,1043,4300) ? Nicht dass wir da irgendwelche >> Meshverbindungen >>> kappen... Fände ich unschön ;) >> >> ich glaube wenn wir eine 6/12Mbit Verbindung kappen... die will eh >> niemand nutzen. >> >>> >>> Sind davon dann eigentlich auch die n-Modis betroffen (aka: werden >> die >>> intern wie verbesserte g-Modi behandelt? Falls nein dürfte es nichts >>> bringen (dann machen sie halt statt 6 Mbit/s 6,5 Mbit/s), falls ja >> führen >> >> 6,5MBit sollte kein n-Modi sein oder wo kommt diese Zahl her? >> 11b hat: 1 2 5,5 und 11Mbit >> BPSK: 6 und 9MBit (g) >> QPSK: 12 und 18 Mbit >> QAM: ab 24Mbit >> n Modi liegen über 54Mbit und werden wohl aus den eingestellten g-modi >> abgeleitet. Das wäre evtl. ein Grund warum man die Werte ab 6Mbit nicht >> unbedingt wegsperren sollte, da dann u.U. auch irgendwelche MCS im >> n-Modus wegfallen. Wie genau das berechnet/abgeleitet wird, ist mir >> aktuell nicht bekannt müsste man mal raussuchen. >> Von der Seite gesehen wäre es wohl sinnvoll, doch alle Werte ab 6MBit >> mit reinzunehmen. > > Machen wir es in zwei patches. Erstmal b abschalten. Das weiter kann dann separat diskutiert werden. Guten Morgen das hab ich mir gestern auch schon so überlegt. Denke auch das ist der sinnvollste Weg. Meine Wunschvorstellung wäre ja fast, das jeder User selbst die Raten einstellen kann in der Art: - mit 11b (das ist dann so wie früher, wird nicht empfohlen zu verwenden) - ohne 11b (das ist dann der Stand nach dem Patch) - ohne veraltete Modulation (das wäre dann erst alles ab 24Mbit genutzt) - Manuell (Hier kann dann die support&basic rates komplett manuell eingestellt werden mfg Christian > > Tim > > >> >>> dann halt Störungen (und wenn sie nur paar Sekunden bis Minuten sind) >> zu >>> Abbrüchen auch bei Verbindungen, die sonst stabil 24 oder mehr Mbit >>> machen. >>> >>> Ich hab z.B. ne stabile Meshverbindung laufen, die sich bei -78 dBm >> so zw. >>> 20 und 45 Mbit/s einpendelt. Die würde es dann vermutlich zuweilen >>> wegkegeln. >> >> und da geht noch was sinnvolles drüber? >> >> >> mfg >> >> Christian >> >>> >>> Standard würde ich die min. 24 Mbit auf keinen Fall machen, optional >> wäre >>> ok. Die APs, wo man auf die Air-Time aufpassen muss, sollten deutlich >> in >>> der Unterzahl sein... >>> >>> Viele Grüße, >>> Michael >>>
Moin, ja, über diese Leitung geht gut was drüber ;-) > 6,5MBit sollte kein n-Modi sein oder wo kommt diese Zahl her? Ich fürchte ich muss zu n bissle ausholen^^ 11n ist erstmal nur ein verbessertes 11g. Das, was es grundlegend inkompatibel zu 11g macht ist ein leicht optimiertes Spektrum, weil es 52 statt 48 Nutzträger hat (bei 20 MHz). Deswegen wurde aus 6 6,5 und aus 54 65 MBit. Das ist wie gesagt der einzige grundlegende Unterschied 11g / 11n. Daneben wurden einige Optionen eingeführt: * Wenn man das Guard-Intervall auf 400ns runterstellt sinds 7,2 bzw. 72 MBit - hat aber den Nachteil der höheren Echo-Empfindlichkeit. * Parallele Streams * 40 MHz Kanäle Bei 11ac wurde am HF-Aufbau gar nichts geändert, sodass die "unteren" Bereiche (bis 4 Streams / 40 MHz) 11n entsprechen. Außerdem hat mal als zusätzliche Modulationsstufe 256-QAM eingeführt. Das man es nur 5 GHz spezifiziert hat lag wohl am breiteren Frequenzband ;-) https://de.wikipedia.org/wiki/Datei:Modulations_802.11.png ist ne schöne Übersicht, auch wenn da paar Optionen fehlen (400 NS GI). Diese Tabelle hat statt der Angabe BPSK/QPSK/16-QAM/64-QAM/256-QAM in der Spalte Mod die Anzahl der Bits, die pro Symbol kodiert werden (1/2/4/6/8 bits) Ah, zum MCS: Bei 11n hat man da noch streamanzahlübergreifend durchnummeriert, was man an https://en.wikipedia.org/wiki/IEEE_802.11n-2009 gut sieht. Bei 11ac steht MCS nur noch für die Modulationsart und die FEC (aka coding rate) - sieht man unter https://de.wikipedia.org/wiki/IEEE_802.11ac schön. Man merkt, die WLAN-Standards werden zu Mal zu Mal systematischer ;-) Christian, hattest du da im irc nichtmal ein Poster zu verlinkt? > Das wäre evtl. ein Grund warum man die Werte ab 6Mbit nicht unbedingt wegsperren sollte, da dann u.U. auch irgendwelche MCS im n-Modus wegfallen. Wie genau das berechnet/abgeleitet wird, ist mir aktuell nicht bekannt müsste man mal raussuchen. Jep, genau darauf bezog sich meine Frage. Wenn der Treiber die Einschränkungen bei 11n parallel zu 11g anwendet sperrst du damit die jeweiligen 20% besseren Modulationsarten von 11n mit aus. Und wie so die üblichen Geräte reagieren, wenn da Modulationsarten gekappt werden will ich lieber gar nicht wissen - mich würde es nicht wundern wenn wir grad bei Smartphones auf so einige Bugs in der WLAN-HW oder Treibern stoßen, so schrottig wie gerade letztere gerne mal sind... Viele Grüße, Michael
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@freifunk.net] On Behalf Of > Christian Dresel > Sent: Saturday, May 27, 2017 9:51 AM > To: Moexe; franken-dev@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-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-13741711 > > 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@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-137417 > >>> 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@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&sta > >>>>> tus[0]=&or der=status&sort=desc (ja Zertifikat ist kaputt ;)) > >>>>> > >>>>> "In addition to the overhead created by the SSIDs 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 thats 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@chrisi01.de>: > >>>>>>> Hiermit wird 802.11b auf den Accesspoint deaktiviert. > >>>>>>> > >>>>>>> Signed-off-by: Christian Dresel <fff@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/wire > >>>>>>> +++ 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@freifunk.net > >>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net > >> > > > > > >
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@freifunk.net] On Behalf Of Ralph A. Schmid, dk5ras Sent: Montag, 29. Mai 2017 12:02 To: 'Christian Dresel' <fff@chrisi01.de>; franken-dev@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@freifunk.net] On Behalf > Of Christian Dresel > Sent: Saturday, May 27, 2017 9:51 AM > To: Moexe; franken-dev@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@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@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 SSIDs 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 thats 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@chrisi01.de>: > >>>>>>> Hiermit wird 802.11b auf den Accesspoint deaktiviert. > >>>>>>> > >>>>>>> Signed-off-by: Christian Dresel <fff@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@freifunk.net > >>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.ne > >>> t > >> > > > > > > -- franken-dev mailing list franken-dev@freifunk.net http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
Hiermit wird 802.11b auf den Accesspoint deaktiviert. Signed-off-by: Christian Dresel <fff@chrisi01.de> --- src/packages/fff/fff-wireless/files/lib/functions/fff/wireless | 1 + 1 file changed, 1 insertion(+)