In dem Fall ist der AP schon der Vormund vom Client, der AP sagt dem Client denn was er machen darf und was nicht.
nein, er sagt, was er technisch machen kann, er sagt nicht zum Client „mach das so“. Das ist Verantwortungbereich desjenigen, dem der Client gehört. Trenne technische Aspekte von rechtlichen.
(Anders wäre es, wenn Du hingehst, den Client so flasht mit 500 und dann dem Aufsteller gibts, gleich, ob er dann Eigentümer wird, oder nicht. Dann kann er davon ausgehen, dass Du legal gehandelt hast. Die Mutmaßung, Du habest illegal gehandelt, kann nicht unterstellt werden, allenfalls bei Mitwisserschaft, also Wegfall der Gutgläubigkeit.) Deswegen ist das alles Streit um des Kaisers Bart und hier völlig fehl. Wer von den Firmware- oder Gluon-Programmierern sich zum Vormund aufschwingt, hat entweder nicht seinen Denkfehler gesehen, oder aber bewegt sich ausserhalb des Freifunk Gedankens.
Edit
übrigens kann man auch sehen, dass das Argument Antennengewinn falsch berechnet und Beschränkungsgrenze für DE falsch sind, am 841n v9, was bislang 19db macht (kann gar keine 20) nun mit der neuen Firmware aber 18. D.h., obwohl sowieso unter der gesetzlichen Grenze von 20 liegend, wird es trotzdem nochmal gedrosselt. Denn die neue Firmware macht das ja auch beim Autoupdate der alten Router-Versionen genau so.
Ausserdem müsste dann erst mal dargelegt werden, welcher Antennengewinn denn im Kernel für welches Land berechnet ist, da er ja anscheinend nur bei De falsch berecht seinsoll. Dann spätestens würdesich zeigen,d ass es gar keine falsche Berechnung gibt; der Antennengewinn ist für alle Länder-Kernels identisch entsprechend den jeweiligen Standard-Antennen, so wie ausgeliefert; alles andere wäre auch höchst unsinnig, weil dann TP-Link x verschiedene Kernels mit unterschiedlichen Berechnungen machen müsste.
Du verstehst mich falsch. Er, also der AP, sagt er ist in BO. APs sind ortsgebunden und wissen wo sie sind. Der Client, also ein Smartphone oder Computer, bekommt vom AP wissentlich die falsche Information: Du bist jetzt in BO und es gelten die Bestimmungen von BO ab jetzt.
Diejenigen die also die Software für Deutschland wissentlich mit Einstellungen verbreiten die andere Geräte/Benutzer dazu zwingen die gesetzlich festgelegten Sendeleistungen zu überschreiten haben da aufjedenfall eine Mitschuld dran. Ohne Jura studiert zu haben sieht es meiner Meinung bei der vorhergegangenen Rechtsprechung zumindest danach aus, aber da wird ein Anwalt bestimmt eine qualifizierte Aussage zu treffen können.
hatte client = Router eines anderen mit WLAN verbundenen Aufstellers gleich gesetzt.
OK, so wie Du es schilderst, wäre es grenzwertig.
Ist aber für hier der falsche Diskussionsort, obwohl ich BO als Länderkennung eh für eine Schnapsidee halte.
Das ganze wirkt auf mich wie man will weg von der Bremsen-Vorgabe, ohne an dem eigentlichen Problem fundamental zu kritisieren und zu ändern. Erscheint mir wie Devotismus gegenüber Respektpersonen (die Programmiergötter da ganz oben werden sich dabei ja was gedacht haben, also nach Begründungen dafür suchen, statt zu hinterfragen, ob das wirklich richtig ist) statt kritischer Analyse des Vorhandenen.
Wir kommen damit natürlich in Netz- und Programmierpolitik, aber für mich ist ausgesprochen verdächtig, dass ausgerechnet nur für Deutschland eine falsche Berechnung des Antennengewinns vorliegen soll (der übrigens nur behauptet, nie belegt wurde). Würde ich akzeptieren, wenn bei unverändertem deutschen Kernel die Bremse auch bei BO und 00 drin wäre, aber so ist es entweder ein Fehler (falsche Prämisse beim Programmieren) oder es steckt eine andere Absicht dahinter. (Übrigens ist es egal, wie qualifiziert die/der Urheber sind/ist, auch Professoren machen Fehldiagnosen und operieren das falsche Bein, und so was gibts auch bei IT)
Edit
habe nun das getestet, was oben PetaByteBoy als „Lösung“ per UCI genannt hat: einfach auf DE ändern und txpower selbst setzen.
Ich muss mich fragen, ob er das, was er als stabile Firmware propagiert, eigentlich auch selbst mal getestet hat oder nur Theorie und Code kennt und für ihn das ist, was theoretisch kommen sollte.
Es klappt nämlich nicht.
uci set wireless.radio0.country= DE ergibt nämlch zwar in /wireless den Eintrag DE, aber bei iwinfo radio0 copuntrylist wird dann der Asterix neben US US angezeigt und nicht bei DE. (Ebenso wie jede andere Änderung bei counry, IMMER ist das Ergebnis US US. Der Eintrag in /wireless wird anscheinend einfach ignoriert.
Die Firmware ist buggy!
Edit2
Im Übrigen ist offensichtlich in diesem Punkt gegenüber der experiental von November nichts geändert worden: so bald als Land DE gesetzt wird (gleich was dann bei der Abfrage gezeigt wird), ist 16db hart verdrahtet, auch wenn man 18 oder 19 oder 20 mit txpower setzt.
Deswegen ist DE als Länderauswahl in jedem Fall die falscheste Lösung. Es bleibt nur BO oder (mein Dauervorshlag) 00
Das ganze ist ein ungenügender Workaround, keine veröffentlichungsfähige stabile Version.
Edit3
Der erkennbare Unterschied zwischen BO und 00 ist bei der Kanalwahl: Bei BO wird 1 + 5 genommen bei 00 nur 1
Wird hingegen DE genommen, kann man mit set txpower die Bremse nicht lösen. Um das zu erreichen, darf kein DE genommen werden.
Also genau so, wie bei der experimental von 20.11.2015
Alle Änderungen sind Kosmetik oder betreffen andere Funktionen, und die Einträge in /wireless und Anzeigen/Abfrageausgaben in iwinfo zu txpowerlist und country geben nur bedingt das wieder, was tatsächlich das Gerät macht, oder gar nichts. In /wireless kann stehen, was will (jedenfalls bei den beiden Zeilen), gemacht wird u.U. was anderes, das auch mit iwinfo nicht abfragbar und nur mit physischem Test überprüfbar ist.
Ich verstehe die ganze Aufregung überhaupt nicht (bezieht sich auf 841er) :
- Viele Leute haben festgestellt, daß wir ggf. vor gluon 2015.2 mit zuviel Sendeleistung als erlaubt (aufgrund des Antennengewinns) gesendet haben.
- Daraufhin wurde ein Limit gesetzt (Die Experten haben gewusst wo und wie am besten).
- Dies war wohl etwas niedrig, daher sind wir nun mit einigen Verbiegungen auf 18 dBm (was nach meinem Verständnis mit dem Antennengewinn den erlaubten 20 dBm entspricht). Dies ist ganz normal via Firmwareupdate für Leute wie mich patchbar.
- Falls jemand die Sendeleistung erhöhen will, kann er dies mit 4 einfachen Zeilen per SSH/Root machen. Bei mir zuhause getestet, funzt. Gemessen habe ich es mit meinen laienhaften Möglichkeiten (Network Signal Info, mehr dBM möglich als mit Original Firmware). Somit bräht der 841er dann wieder so stark wie früher (was mit Antennengewinn über dem erlaubten Niveau ist).
- Wenn noch gewünscht, kann sich jeder eine Firmware backen, die dies per Skript macht. Dann aber ohne meine Signierung!
Aus meiner Sicht ist das Thema keines welches mich vor dem Signieren abhält.
PS: Ansonsten bin ich mit den Labortests durch, bespreche mit @PetaByteBoy heute nachmittag den Test im Feld (Zug um Zug Rollout per Autoupdater).
selbst, wenn die Leistung so belassen wird, ist die Firmware noch in anderen Bereichen buggy. Was immer auch Du an „Labortests“ gemacht hast. Sie ist keinesfalls ausrollfähig per Autoupdate.
Welche meinst Du? Doch nicht die Kleinigkeiten wie Tippfehler?
@PetaByteBoy hat eine neue Firmware gemacht (20160227).
Tippfehler in Luci bereinigt, einen schönen Banner gebaut für diejenigen, welche SSH nutzen und nicht so Cracks sind:
BusyBox v1.23.2 (2016-02-27 00:08:51 CET) built-in shell (ash)
Freifunk Gluon Node http://gluon.readthedocs.org/
, , based on OpenWrt http://openwrt.org/
)\___/( powered by GNU/Linux http://gnu.org/
{(@)v(@)} respect PPA guidelines http://www.picopeer.net/
{|~~~|} building mesh networks http://freifunk.net/
{/^^^\} network documentation http://eulenfunk.de/
---`m-m`--- support needed? -> http://forum.freifunk.net/
____________________________________________________________________
for command line help type 'help'
____________________________________________________________________
root@FF_GL_Spielwiese6:~# help
autoupdater -f // Firmware-Update erzwingen
logread // logread -f // syslog Ausgabe auf Konsole
ping 8.8.8.8 // google-DNS wenn IPv4 lokal
ip a s // alle IPs anzeigen
ip r s t all // gesamte Routingtabelle
traceroute -n 10.155.0.254 // Traceroute via IP zu einem gateway
batctl gwl // batman-gateways inkl. Gewaehltes
batctl -m bat0 tr 10.155.0.254 // Traceroute via batman-adv
batctl o // batman Domain-Nachbarn anzeigen
batctl tl |grep W |wc -l // batman Clients zählen
batctl if // baman interfaces anzeigen
brctl show // alle bridges anzeigen
iwinfo // wlan-paramter anzeigen
iw dev client0 station dump // WLAN Nachbarn mit Details
nodeinfo // diverse infos ausgegeben
v4up // ipv4 holen, wenn kein vpnuplink
!Wichtige Info für Bergisch Gladbach und Leichlingen!
Wir (@PetaByteBoy und ich) haben nun unsere Tests fertig.
Modelle: 841v10, 841v9, 1043v2, LoCoM2, CPE210, Futro mit RTL und HP NIC, …
Teilweise seit 2 Wochen stabil im Dauerbetrieb bei Last.
Wir sehen daher die Release als stable an, ab morgen abend wird für Bergisch Gladbach und Leichlingen diese per autoupdate ausgerollt.
@PetaByteBoy wird diese noch mit der 2. Signatur versehen und dann endgültig verlinken
@Pinky: Bitte dann noch auf Deinen Seiten entsprechend austauschen. Danke!
An alle: Bitte ab Freitag abend auf Eure Router schauen, bei Problemen bitte neustarten und ggf. hier melden!
ich weis nicht, ob ich lachen oder weinen soll.
und bei der Gelegenheit direkt alle Router mit Freifunk-Burscheid abgeschossen?
Sieht so ein Test aus? Oder ist das Euch völlig egal?
Ich war jetzt einige Zeit nicht da und hab bereits vor Wochen auf das Problem hingewiesen, aber nur dumme Antworten bekommen.
Bei mir sind ALLE Router mit SSID Freifunk-Burscheid zwar verbunden, aber die clients bekommen keine Internetverbindung. Ping timeoutet.
Ich kann jetzt nicht testen, in wie weit die Stadt gänzlich betroffen ist, oder sich das nur partiell auswirkt.
841n v10
Firmware-Release 2016022221
SSID Freifunk-Burscheid
DHCP-aktiviert: Ja
IPv4-Adresse: 10.156.253.165
IPv4-Subnetzmaske: 255.255.0.0
IPv4-Standardgateway: 10.156.0.240
IPv4-DHCP-Server: 10.156.0.240
IPv4-DNS-Server: 10.156.0.1
KEIN INTERNETZUGRIFF
ping timeout
841n v9
Firmware-Release 20150713
SSID Freifunk-Burscheid
DHCP-aktiviert: Ja
IPv4-Adresse: 10.156.253.165
IPv4-Subnetzmaske: 255.255.0.0
IPv4-Standardgateway: 10.156.0.240
IPv4-DNS-Server: 10.156.0.1
KEIN INTERNETZUGRIFF
ping timeout
edit
hatte am 9.3. @PetaByteBoy schon mal darauf aufmerksam gemacht, aber nur eine flapsige Antwort erhalten, ich woll Wup fragen.
Wobei ich davon ausgehe, dass er ja für die Firmware und die neuen Netzkonfigurationen verantwortlich ist und @phip sicherlich nichts macht, was Burscheid betrfft und nicht von @PetaByteBoy ihm mitgeteilt wurde.
Jedenfalls sind bei ALLEN Freifunk-Burscheid-Routern, die ich auf die Schnelle testen konnte, keine Internetverbindungen für den Client möglich.
So wie ich es verstanden habe, soll das Update doch für Burscheid nicht ausgerollt werden entsprechend Deines Wunsches vor etwa 2 Wochen.
Damit erübrigen sich auch weitere Tests für diese Firmware für Burscheid.
nicht nur nicht in Buscheid, sondern (zumindest) auch nicht in Odenthal und (das ergibt das kommende Gespräch mit der Stadt am Mittwoch) in Leichlingen. Jedenfalls sind die Leichlinger alles andere als begeistert, mangels Kooperations- und Auskunftbereitschaft von @PetaByteBoy . Seine letzte Antwort an die Stadt war jedenfalls (vorsichtig formuliert) inadäquat. Was mit Bensberg und Overath ist, weis ich nicht. M.W. wissen die noch gar nichts davon.
Forum ist nunmal nicht repräsentativ.
Rollout läuf hervorragend.
Korrekt!
Bergisch Gladbach, Stand 17;30 Uhr:
109 Router auf aktueller Firmware
121 online
6 Router mit deaktiviertem oder exp. Autoupdate
Ich habe einen Router (CPE210) von Hand neu starten müssen.
Diverse Knoten (z.B. Bensberg) sind noch offline, wir (Bensberger) werden diese in den nächsten Tagen „abklappern“…
Aber unabhängig vom Update?
ja, z.T. schon seit Tagen
Rollout Status 22.03. 9:30 Uhr
Leichlingen:
57 von 59 Knoten online
51 auf aktueller Firmware
Bergisch Gladbach:
119 von 135 Knoten online
118 auf aktueller Firmware
In LLN gibt es folgende Problemkinder:
Mediteran, Cafe am Stadtpark:
Kabel rausgerutscht, keine ausreichenden Funklinks
@Pinky ? Wenn du keine Zeit hast kann ich nächste Woche vorbeigehen.
Eiscafe San Remo, Sinneswald Wietsche:
Alte Exp-FW, zieht Updates von anderer IP, ich kümmere mich
Woran sehe ich, dass der Knoten ( BGL-60e327b7a956e) ein Update erhalten hat?