stimmt, hier auch…
Nahezu kein Speed:
Loss im Mittelfeld:
— google.de ping statistics —
20 packets transmitted, 15 received, 25% packet loss, time 19046ms
rtt min/avg/max/mdev = 64.739/137.940/434.574/88.651 ms
Nach der Bastelei an einem Router ist gerade die ganze Wolke um den Router herum von der Karte verschwunden und kommt bisher auch nicht wieder hoch.
Kann es sein, dass gerade keine neuen Slots für Nodes da sind? Ich sehe meinen 4900 hier zwar in der Heimnetzübersicht der Fritz!Box, aber nicht das „Grundrauschen“ - könnte ein Hinweis sein.
Den Webserver „in Richtung Heimnetz“ öffnen und dann auf die Status-Seite gucken:
uci set firewall.wan_http=rule
uci set firewall.wan_http.dest_port=80
uci set firewall.wan_http.src=wan
uci set firewall.wan_http.name=wan_http
uci set firewall.wan_http.target=ACCEPT
uci set firewall.wan_http.proto=tcp
uci commit
/etc/init.d/firewall reload
Guter Tipp - auch wenn ich seltsamerweise beim committen einen parse error kriege.
FF-RE-CampusVest-Buddestr-4900
Model: TP-Link TL-WDR4900 v1
Firmware release: 0.6
11:18:49 up 3:01, load average: 0.02, 0.07, 0.05
6: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/ether f8:1a:67:5a:99:01 brd ff:ff:ff:ff:ff:ff
inet6 2a03:2260:50:1:fa1a:67ff:fe5a:9901/64 scope global dynamic
valid_lft 86276sec preferred_lft 14276sec
inet6 fe80::fa1a:67ff:fe5a:9901/64 scope link
valid_lft forever preferred_lft forever
total used free shared buffers
Mem: 126528 42148 84380 0 2200
-/+ buffers: 39948 86580
Swap: 0 0 0
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2304 2304 0 100% /rom
/dev/mtdblock4 10944 500 10444 5% /overlay
Neighbours
wlan1
Joined IBSS 02:ff:13:37:ff:01 (on wlan1)
SSID: wifimesh-ruhrgebiet
freq: 2422
Station 6a:75:52:18:86:fa (FF-RE-REC-Koenigsbergerstr-Outdoor-01) (on wlan1)
inactive time: 32 ms
rx bytes: 13293483
rx packets: 183173
tx bytes: 10735
tx packets: 321
tx retries: 107
tx failed: 1
signal: -74 [-77, -78, -83] dBm
signal avg: -74 [-78, -79, -82] dBm
tx bitrate: 6.5 MBit/s MCS 0
rx bitrate: 60.0 MBit/s MCS 9 40MHz short GI
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
wlan0
Joined IBSS 02:ff:13:37:ff:02 (on wlan0)
SSID: wifimesh-ruhrgebiet5
freq: 5220
VPN status
fastd running for 10859.183 seconds
There are 12 peers configured, of which 2 are connected:
mesh_vpn_backbone_peer_ruhrgebiet9: not connected
mesh_vpn_backbone_peer_ruhrgebiet0: not connected
mesh_vpn_backbone_peer_ruhrgebiet2: not connected
mesh_vpn_backbone_peer_ruhrgebiet7: not connected
mesh_vpn_backbone_peer_ruhrgebiet6: not connected
mesh_vpn_backbone_peer_ruhrgebiet5: not connected
mesh_vpn_backbone_peer_ruhrgebiet11: not connected
mesh_vpn_backbone_peer_ruhrgebiet8: not connected
mesh_vpn_backbone_peer_ruhrgebiet4: not connected
mesh_vpn_backbone_peer_ruhrgebiet10: connected for 39.675 seconds
mesh_vpn_backbone_peer_ruhrgebiet3: not connected
mesh_vpn_backbone_peer_ruhrgebiet1: connected for 39.452 seconds
Wenn ich das richtig lese, war er gerade mal 40 Sekunden verbunden. Nach einem Refresh der Seite ist er wieder raus.
In der Wolke gibt es wohl so keinen Uplink mehr, auch der Meshpartner zwei Straßen weiter taucht nicht im Alfred auf.
Wed May 20 11:30:12 2015 daemon.info fastd[13919]: resolving host `ffrg8.freifunk-ruhrgebiet.de' for peer <mesh_vpn_backbone_peer_ruhrgebiet8>...
Wed May 20 11:30:12 2015 daemon.info fastd[13919]: resolved host `ffrg8.freifunk-ruhrgebiet.de' successfully
Wed May 20 11:30:13 2015 daemon.info fastd[13919]: sending handshake to <mesh_vpn_backbone_peer_ruhrgebiet6>[37.120.172.60:10000]...
Wed May 20 11:30:13 2015 daemon.info fastd[13919]: resolving host `ffrg6.freifunk-ruhrgebiet.de' for peer <mesh_vpn_backbone_peer_ruhrgebiet6>...
Wed May 20 11:30:13 2015 daemon.info fastd[13919]: resolved host `ffrg6.freifunk-ruhrgebiet.de' successfully
Wed May 20 11:30:14 2015 daemon.info fastd[13919]: sending handshake to <mesh_vpn_backbone_peer_ruhrgebiet11>[85.14.244.128:10000]...
Wed May 20 11:30:14 2015 daemon.info fastd[13919]: resolving host `ffrg11.freifunk-ruhrgebiet.de' for peer <mesh_vpn_backbone_peer_ruhrgebiet11>...
Wed May 20 11:30:14 2015 daemon.info fastd[13919]: resolved host `ffrg11.freifunk-ruhrgebiet.de' successfully
Wed May 20 11:30:16 2015 daemon.info fastd[13919]: sending handshake to <mesh_vpn_backbone_peer_ruhrgebiet10>[37.120.173.105:10000]...
Wed May 20 11:30:16 2015 daemon.info fastd[13919]: resolving host `ffrg10.freifunk-ruhrgebiet.de' for peer <mesh_vpn_backbone_peer_ruhrgebiet10>...
Wed May 20 11:30:16 2015 daemon.info fastd[13919]: resolved host `ffrg10.freifunk-ruhrgebiet.de' successfully
Es wird brav resolvet, Hände werden geschüttelt, aber sonst kommt nichts.
1 „Gefällt mir“
Slot wieder frei, Wolke wieder da.
Weshalb ist die Performance momentan so gut? 
Und fast 300 freie Tunnel slots haben wir auch.
1 „Gefällt mir“
die ersten umzuege werden zu merken sein.
1 „Gefällt mir“
— google.de ping statistics —
88 packets transmitted, 69 packets received, 21% packet loss
round-trip min/avg/max = 47.889/516.632/3161.394 ms
liegts an mir oder ist das Gesammtnetz momentan belastet?
Das siehst Du wenn Du
a) vom client den nextnode (plasterouter) pingst
b) vom client das IP-gateway pingst
c) vom client google/heise pingst.
eventuell kannst Du auch noch
d) vom Freifunk-Router aus ein batctl p machen auf das genutzte gateway (siehe batctl gwl)
Also ich bin per SSH auf dem FF Router (OpenWrt) und mache dort
Ping auf die Fritzbox = Gateway
— 192.168.178.1 ping statistics —
23 packets transmitted, 23 packets received, 0% packet loss
round-trip min/avg/max = 0.549/47.707/563.150 ms
Dann batctl p 192.178.168.1
batctl p 192.168.178.1
PING 192.168.178.1 (9c:c7:a6:bf:dd:d7) 20(48) bytes of data
From 192.168.178.1: Destination Host Unreachable (icmp_seq 1)
From 192.168.178.1: Destination Host Unreachable (icmp_seq 2)
From 192.168.178.1: Destination Host Unreachable (icmp_seq 3)
From 192.168.178.1: Destination Host Unreachable (icmp_seq 4)
From 192.168.178.1: Destination Host Unreachable (icmp_seq 5)
From 192.168.178.1: Destination Host Unreachable (icmp_seq 6)
From 192.168.178.1: Destination Host Unreachable (icmp_seq 7)
From 192.168.178.1: Destination Host Unreachable (icmp_seq 8)
… sagt mir jetzt wenig
Mein Linux Fu ist leider sehr begrenzt
„client“ ist das Gerät, welches sich mit Deinem Plasterouter verbindet.
und nur d) (was optional ist) machst Du vom Plasterouter aus. dort dann auf die adresse die Dir „bastctl gwl“ als MAC (6 x Byte in HEX) ausgibt.
Habe ein paar Rückmeldungen auf dem „öffentlichen Raum“ (Jugendeinrichtungen) gekriegt, dass FF mehrfach keine IP vergeben hat, wenn Clients sich einbuchen wollten. Ich versuche noch eine qualifiziertere Fehlerdarstellung zu kriegen, es sind aber nicht direkt von mir betreute Router.
1 „Gefällt mir“
es gibt wohl zombie supernotes die kein netz bereit stellen … obwohl der fastd steht … wir hatten das gestern auch … leider war ich auf der interschutz und konnte so nicht schauen welcher es war. nach einen reboot hatten die router alle bis auf einer wieder einen sn mit internet und ip vergabe …
Leider pruefen die clients ob internet da ist oder nicht und z.b. handy trennen ohne internet
Ich verfolge FF jetzt schon etwas länger und habe gestern Abend auch mal angefangen mit einem Router rumzuspielen und ihn ins Netz gehängt.
Leider muss ich sagen, dass ich ehrlich gesagt schockiert bin, was „hinten“ im FF-WLAN Richtung inet herauskam.
Ich habe einen 841v9 aufgestellt mit gl0.6 und bin am Anfang mit 0.2mbit down rumgekrebst, womit allerdings nicht mal eine einzige Webseite zu Ende geladen wurde - wahrscheinlich zu viele drops. Über SSH konnte ich hunderte ooms vom alfred sehen und der load ging durch die Decke. Nach einigen Reboots schien das oom Problem mehr oder weniger erledigt zu sein - warum weiß ich nicht - und ich kam so auf 2mbit downstream - was gerade noch akzeptabel ist meiner Meinung nach - aber irgendwie doch ziemlich wenig. Wobei ich mir gerade nach etwas weitreichenderem Stöbern im Forum die Frage stelle wie viel Performance man eigentlich innerhalb von FF und nach außen erwarten kann/soll/darf?
Da ich jetzt noch nicht so sehr mit den Internas von FF bewandert bin, stellt sich mir gerade die Frage inwiefern der genaue Grund für die Performanceprobleme überhaupt identifiziert werden konnte. Sind es die Gateways ins inet oder sind es vielleicht einfach Dutzende 841er wie meiner, die eigentlich nur noch oopsen vor Last und deswegen viel zu viele Drops im Netz hervorrufen?
Was mir hier in DEM „Performance Thread“ auch wirklich fehlt, ist die Anleitung für den FF-nochnicht-Veteranen: „wie treffe ich eine sinnvolle Aussage über meine Performance und welche Informationen muss ich liefern“. In welchen Logs stehen sinnvolle Infos? Wie überprüfe ich die Performance innerhalb des FF mesh und wie nach außen ins inet und inwiefern ist eine Trennung dieser Betrachtung sinnvoll und/oder notwendig? Ich habe versucht mich durch die 334 Posts zu quälen, habe aber hier leider keine zusammenhängenden Informationen gefunden.
3 „Gefällt mir“
Es gibt Dutzende von Gründen.
Alle hier im Thread zu finden… leider.
Von daher ist es immer leicht einen zu fixen und dann an einem anderen Flaschenhals zu stecken.
Faktisch wirst Du derzeit nicht mehr als 8MBit/s am Client bekommen, selbst wenn alles gut läuft und Du einen richtig teuren Plasterouter nutzt.
Und 2-4GB/24h an „Background-Traffic“ für einen Router ohne clients sind bei der Größe der Domain auch normal. Ist halt so.
Vorschläge das zu ändern gibt es mehrere. Einige sofort umsetzbar, andere eher langfristig (Q2/2016).
Einige kosten Geld (Spenden), andere benötigen mehr Arbeitskraft (aka hinreichend qualifizierte Admins).
Meine Einschätzung ist, dass ich zumindest kurzfristig binnen der nächsten 5-6 Monate an der Situation nichts entscheidend ändern wird, weil jegliche kleinen Maßnahmen sofort wieder durch das ständige Wachstum mehr als „aufgefressen“ werden.
1 „Gefällt mir“
Ein Verhalten, dass man eher bei Suchtkranken vermutet: man weiss, dass durch die Droge „Wachstum“ alles immer wieder zusammenbricht, lässt aber nicht davon ab.
Das Picopeering Agreement „freier Zugang für alle“ bedeutet in der Praxis „kein Zugang für Niemand“ - jeder weiss es und dennoch trägt man es wie eine Monstranz vor sich her.
Zur Suchterkrankung kommt also noch fundamentalistischer religiöser Eifer hinzu.
Die Heilserwartung, dass sich nächste Woche, nächsten Monat, nächstes Jahr etwas entscheidend ändert, bleibt ein jenseitiges Versprechen.
Ich denke es wird Zeit, dass das Kind endlich beim Namen genannt wird und Konsequenzen gezogen werden.
Abzutauchen, nicht zu reagieren, nicht wirklich das Desaster zu kommunizieren, ist natürlich auch eine Strategie, um die Zahl der Freifunker zu reduzieren.
Es gibt nach wie vor weder ein öffentlich kommuniziertes Konzept wie die verschiedenen „Flaschenhälse“ erweitert werden können, noch eine Strategie wie man langfristig FF stabilisieren und entwickeln will.
Kein Geld da, keine Manpower da, kein Wille vorhanden, die Ideologie auf den Prüfstand zu stellen, kein erkennbares Zukunftskonzept.
Kurz: so wird das nichts.
Mahlzeit!
Auch, wenn Durchsatzmessungen nicht immer gut ankommen… diese ist zumindest bei mir sehr gut angekommen: 14,31MBit down, 5,11MBit up - laut ookla.
Ich bin geplättet! Absoluter Rekorddurchsatz! Noch nie dagewesen! Unglaublich! Jaja, okay, ich beruhige mich wieder 
Woran liegt’s? Reduzierung der fastd-Tunnel bzw. die Entlastung der Super-Nodes? Zufall?
der Matze
2 „Gefällt mir“
Nope - kann ich hier am 4900 nicht nachvollziehen.
1 „Gefällt mir“
Selbstverständlich arbeitet man an Strategien und Lösungen und das wird auch klar kommuniziert:
- Kurzfristig: Eine statt zwei Tunnelverbindungen (mit dem jüngsten Update umgesetzt);
Domänensplit um die Grundlast zu verringern (in Arbeit) - Mittelfristig: Weg vom Layer2-Mesh (entsprechende Dienste dafür sind in der Sandbox-Domäne in der Erprobungsphase)
1 „Gefällt mir“