150 kbit/s Hintergrund-Traffic!?

ivenae · 25. Dezember 2014 um 03:19

Ich bin neu hier, seit ich mein WR841DN (ff-ivenae) auf Freifunk umgestellt hab, erzeugt mir dieses im LAN, aber auch im WAN 150 kbit/s Hintergrund-Traffic.

Ich finde das extrem viel. Das Zeug landet auch im Klartext in meinem LAN, obwohl dieses eigentlich abgeschirmt sein sollte. Kann mir jemand sagen, wo das herkommt? Die IPv6 Adressen gibt es in meinem LAN nicht.

Also ich habe herausgefunden, dass das vom Mesh-VPN kommt, denn mit /etc/init.d/fastd stop hört der Spuk auf.
Die Frage ist, warum das nicht nur über die Internetstrecke geht, sondern auch bei mir im LAN zu finden ist, d.h. die Broadcasts verlassen den Router über eth0 bzw. br-wan. Das sollte definitiv nicht so sein!

Die andere Frage ist, ob man das etwas begrenzen kann, denn Upload-technisch sind das 10% meiner WAN Kapazität. Das ist einfach zu viel!

root@ff-ivenae:~# ifconfig
bat0 Link encap:Ethernet HWaddr A0:F3:C1:D8:B5:66
inet6 addr: fe80::a2f3:c1ff:fed8:b566/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8818206 errors:0 dropped:0 overruns:0 frame:0
TX packets:45614 errors:0 dropped:30 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:834521577 (795.8 MiB) TX bytes:8900760 (8.4 MiB)

br-client Link encap:Ethernet HWaddr A0:F3:C1:D8:B5:66
inet6 addr: fe80::a2f3:c1ff:fed8:b566/64 Scope:Link
inet6 addr: 2a02:f98:0:28:a2f3:c1ff:fed8:b566/64 Scope:Global
inet6 addr: fda0:747e:ab29:cafe:a2f3:c1ff:fed8:b566/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8821706 errors:0 dropped:11230 overruns:0 frame:0
TX packets:51859 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:711471595 (678.5 MiB) TX bytes:9853695 (9.3 MiB)

br-wan Link encap:Ethernet HWaddr A0:F3:C1:D8:B5:65
inet addr:192.168.178.4 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: fe80::a2f3:c1ff:fed8:b565/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33180337 errors:0 dropped:0 overruns:0 frame:0
TX packets:19890460 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5867821041 (5.4 GiB) TX bytes:4242849356 (3.9 GiB)

eth0 Link encap:Ethernet HWaddr A0:F3:C1:D8:B5:65
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33867609 errors:0 dropped:0 overruns:0 frame:0
TX packets:20432351 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2818498862 (2.6 GiB) TX bytes:77775648 (74.1 MiB)
Interrupt:4

eth1 Link encap:Ethernet HWaddr A0:F3:C1:D8:B5:66
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:5

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:6019 errors:0 dropped:0 overruns:0 frame:0
TX packets:6019 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:546593 (533.7 KiB) TX bytes:546593 (533.7 KiB)

local-node Link encap:Ethernet HWaddr 16:41:95:40:F7:DC
inet addr:10.40.255.254 Bcast:255.255.255.255 Mask:255.255.255.255
inet6 addr: fda0:747e:ab29:cafe:ffff::1/128 Scope:Global
inet6 addr: fe80::1441:95ff:fe40:f7dc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1995746 errors:0 dropped:11230 overruns:0 frame:0
TX packets:8399 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:193937612 (184.9 MiB) TX bytes:1252426 (1.1 MiB)

mesh-vpn Link encap:Ethernet HWaddr A2:F7:C1:D8:B5:66
inet6 addr: fe80::a0f7:c1ff:fed8:b566/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1426 Metric:1
RX packets:33106180 errors:0 dropped:0 overruns:0 frame:0
TX packets:3878831 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:4140019672 (3.8 GiB) TX bytes:918834538 (876.2 MiB)

wlan0 Link encap:Ethernet HWaddr A2:F6:C2:D8:B5:86
inet6 addr: fe80::a0f6:c2ff:fed8:b586/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1528 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:30076240 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:379231466 (361.6 MiB)

wlan0-1 Link encap:Ethernet HWaddr 00:04:0E:D3:F3:66
inet6 addr: fe80::204:eff:fed3:f366/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:539445 errors:0 dropped:0 overruns:0 frame:0
TX packets:13109528 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:129701434 (123.6 MiB) TX bytes:2992947530 (2.7 GiB)

wlan0-2 Link encap:Ethernet HWaddr 00:12:34:56:78:90
inet6 addr: fe80::212:34ff:fe56:7890/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3484 errors:0 dropped:0 overruns:0 frame:0
TX packets:8520028 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:453362 (442.7 KiB) TX bytes:957636321 (913.2 MiB)

root@ff-ivenae:~# brctl show
bridge name bridge id STP enabled interfaces
br-client 7fff.a0f3c1d8b566 no eth1
bat0
wlan0-2
br-wan 7fff.a0f3c1d8b565 no eth0
wlan0-1

root@ff-ivenae:~# cat /etc/config/wireless
config wifi-device ‚radio0‘
option type ‚mac80211‘
option hwmode ‚11ng‘
option path ‚platform/ar934x_wmac‘
option channel ‚6‘
option htmode ‚HT40+‘
option country ‚DE‘

config wifi-iface ‚mesh_radio0‘
option mcast_rate ‚12000‘
option network ‚mesh_radio0‘
option macaddr ‚a2:f6:c2:d8:b5:86‘
option device ‚radio0‘
option mode ‚adhoc‘
option bssid ‚32:CA:FF:EE:BA:BE‘
option ssid ‚wifimesh-rheinufer‘

config wifi-iface ‚fritzbox‘
option network ‚wan‘
option device ‚radio0‘
option mode ‚ap‘
option ssid ‚FRITZ!Box Fon WLAN 7490‘
option encryption ‚mixed-psk‘
option key ‚XXX‘
option macaddr ‚00:04:0E:D3:F3:66‘

config wifi-iface ‚client_radio0‘
option device ‚radio0‘
option mode ‚ap‘
option network ‚client‘
option ssid ‚Freifunk‘
option macaddr ‚00:12:34:56:78:90‘

root@ff-ivenae:~# cat /etc/config/network

config interface ‚loopback‘
option ifname ‚lo‘
option proto ‚static‘
option ipaddr ‚127.0.0.1‘
option netmask ‚255.0.0.0‘

config globals ‚globals‘
option ula_prefix ‚fd6d:0ab8:1fd4::/48‘

config interface ‚wan6‘
option ifname ‚br-wan‘
option ip6table ‚1‘
option peerdns ‚0‘
option proto ‚none‘

config switch
option name ‚switch0‘
option reset ‚1‘
option enable_vlan ‚1‘

config switch_vlan
option device ‚switch0‘
option vlan ‚1‘
option ports ‚0 1 2 3 4‘

config interface ‚wan‘
option peerdns ‚0‘
option ifname ‚eth0‘
option auto ‚1‘
option type ‚bridge‘
option proto ‚static‘
option ipaddr ‚192.168.178.4‘
option netmask ‚255.255.255.0‘
option gateway ‚192.168.178.1‘

config rule6 ‚wan6_lookup‘
option mark ‚0x01/0x01‘
option lookup ‚1‘

config route6 ‚wan6_unreachable‘
option type ‚unreachable‘
option table ‚1‘
option target ‚::/0‘
option metric ‚65535‘
option gateway ‚::‘
option interface ‚loopback‘

config interface ‚client‘
option reqprefix ‚no‘
option ifname ‚eth1 bat0‘
option proto ‚dhcpv6‘
option type ‚bridge‘
option igmp_snooping ‚0‘
option macaddr ‚a0:f3:c1:d8:b5:66‘
option peerdns ‚1‘

config interface ‚bat0‘
option ifname ‚bat0‘
option macaddr ‚a0:f3:c1:d8:b5:66‘
option proto ‚none‘

config interface ‚mesh_radio0‘
option proto ‚batadv‘
option mesh ‚bat0‘
option mtu ‚1528‘

config interface ‚mesh_wan‘
option ifname ‚br-wan‘
option mesh ‚bat0‘
option proto ‚batadv‘
option auto ‚1‘

config interface ‚mesh_vpn‘
option ifname ‚mesh-vpn‘
option mesh_no_rebroadcast ‚1‘
option macaddr ‚a2:f7:c1:d8:b5:66‘
option mesh ‚bat0‘
option proto ‚batadv‘

config device ‚local_node_dev‘
option macaddr ‚16:41:95:40:f7:dc‘
option ifname ‚br-client‘
option name ‚local-node‘
option type ‚macvlan‘

config interface ‚local_node‘
option ifname ‚local-node‘
option ipaddr ‚10.40.255.254‘
option ip6addr ‚fda0:747e:ab29:cafe:ffff::1/128‘
option netmask ‚255.255.255.255‘
option proto ‚static‘

config route ‚local_node_route4‘
option target ‚10.40.0.0‘
option gateway ‚0.0.0.0‘
option netmask ‚255.255.0.0‘
option interface ‚client‘

config route6 ‚local_node_route6‘
option target ‚fda0:747e:ab29:cafe::/64‘
option gateway ‚::‘
option interface ‚client‘

adorfer · 25. Dezember 2014 um 04:47

Die 150kBit/s „pro Router mit Fastd“ kann ich bestätigen. Das geht mal auf 70kBit/s runter, mal auch auf 200kBit/s hoch, aber 150kBit/s ist ein solider Mittelwert.
(von daher habe ich halt sets akute Schwierigkeiten nachzuvollziehen, wenn jemand sagt „NW-Netmon ist schlecht, weil der so viel Traffic macht“. Denn den Broadcast-Hintergrundtraffic vom Batman topt niemand auf die Schnelle.)

Im Lan landet das bei mir nur, wenn ich „Mesh-on-WAN“ aktiviert habe.

CHRlS · 25. Dezember 2014 um 10:09

Mesh on Wan scheint dort auch aktiviert worden zu sein.

Viel wichtiger ist der Wert, wenn das Mesh über den Tunnel läuft, statt nach WAN, da dieser asymmetrisch sein sollte!

70-200 kbit/s sind da in Downloadrichtung realistisch, in Upload-Richtung sollte das deutlich weniger sein…

ivenae · 25. Dezember 2014 um 13:23

Ah. In Download-Richtung wäre das kein Problem. Wie deaktiviere ich mesh-on-wan über CLI? Hab das jetzt auf die schnelle nicht gefunden.

uci set network.mesh_wan.auto=0
uci commit

tut es auf jeden Fall nicht.

Edit: Okay, der Befehl hat tatsächlich den lästigen Broadcast-Traffic in meinem LAN bzw. WLAN abgeschaltet, auch der Netzwerkport meiner Netzwerkplatte blinkt nicht mehr synchron mit dem des Routers.
Dennoch hab ich das Hintergrundrauschen hin zum Internet. Laut Fritzbox sind das nur 75 - 100 kbit/s, aber das sind immer noch > 10% meiner Leitungskapazität.

tcatm · 25. Dezember 2014 um 15:56

Welche Gluon-Version ist das und wie sieht die site.conf dazu aus?

Generell ist dieser Traffic normal. Das ist zum einen der Managementtraffic von batman-adv um das Meshing zu koordinieren und zum anderen Broadcasttraffic von Clients im Netz. Letzteres wird von vielen Communities großzügig geblockt (ist bei Gluon default), vorher war es so schlimm, dass DSL Anschlüsse tatsächlich dicht waren.

Dieser Traffic ist auch das größte Problem an batman-adv Meshes. Linus hat das vor einiger Zeit mal aufbereitet: http://wiki.freifunk.net/images/e/e1/Batman-adv-scalability.pdf

So ein bisschen ist auch die übliche Architektur mit wenigen zentralen Gateways und Anbindung über asymmetrische DSL Anschlüsse. Funkstrecken zu Knotenpunkten mit mehr Upload helfen.

MPW · 25. Dezember 2014 um 16:47

Das PDF ist informativ, leider verstehe ich nicht alle Abkürzungen. Was ich so mitgenommen habe, ist dass wohl einige Optimierungen geplant sind. Oder diese schon umgesetzt wurden.

Was mir nicht klar ist, wozu dieser Traffic überhaupt notwendig ist? Wenn der Router keinen Client hat, brauchen doch keine Routinginformationen übertragen werden.

Und selbst wenn, warum so riesige Datenmengen? Was steckt technisch dahinter?

adorfer · 25. Dezember 2014 um 16:59

Die Optimierungen („split horizon“) sind in den von uns verwendeten Gluon-Versionen schon lange drin.
Aka „schnelle Besserung nicht absehrbar“. (Batman v16 soll ja vielleicht etc…)

Die Freifunkrouter einer Domain bilden zusammen einen virtuellen Switch.
Und dafür muss jeder Node jederzeit wissen, wo welche MAC-Adressen gerade angeschlossen sind. Diese Informationen werden per Broadcast übertragen.
So wie ich es verstanden habe gibt es keine zentrale Instanz, die die Mactabelle verwaltet. Und somit gibt es auch keine Möglichkeit zu sagen „es werden nur die Änderungen übertragen“, d.h. eine Zentralinstanz überwacht die Anwesenheit von Nodes und sagt dann Bescheid, wenn einer „weg“ ist, statt ständig die kompletten Tabellen erneut zu übertragen.

tcatm · 25. Dezember 2014 um 17:14

Es werden schon differentielle Daten übertragen. So naiv ist batman-adv nun auch nicht. Das Problem sind eher:

alle 5s broadcastet ein Knoten ein „bin noch da!“-Paket (OGM), das an jeden anderen Knoten ankommen muss
ARP Requests für bisher unbekannte Adressen sind Broadcasts und gehen an alle Nodes. Danach gibt’s caches (DAT).
IPv6 Neighbour Discovery (quasi ARP) geht auch effektiv per Broadcast, da die Multicastpatches für batman-adv noch nicht in Gluon angekommen sind.

Eigentlich wollte man den OGM Interval sogar von 5s auf ein paar hundert Millisekunden verringern damit das Mesh sehr viel schneller auf Topologieänderungen reagieren könnte. In so großen Meshes wie wir sie aktuell bauen, wäre dann aber wirklich jeder DSL Uplink dicht.

CHRlS · 25. Dezember 2014 um 18:13

Ich finde derzeit die Daten aus Hamburg immer spannend, weil deren Kollisionsdomäne schon noch deutlich größer ist als unsere.

Hier mal unsere aktuellen Knotenmengen pro Kollisionsdomäne:

http://map.freifunk-ruhrgebiet.de/counts/

Hier liegen die Trafficdaten aus Hamburg:

https://www.metameute.de/~tux/Freifunk/stats/ffhh

OGM ist aktuell bei über 600 Routern average 55 kbit/s:

MPW · 25. Dezember 2014 um 19:51

Hallo,

@tcatm: Danke für die Infos.

Bzgl. 5s broadcast: Ist das wirklich notwendig? Machen normale Router das gegenüber dem Internetprovider/DSLAM auch?

Bzgl. ARP Requests: Könnte man das nicht zentral auf die Gateways legen?

Bzgl. ND: Wie viel Traffic wird dann da gespart?

Also wenn ich das mal richtig überschlage: ~50 kbit/s /8 * 3600 * 24 * 30 /1024^2 ~ 15 GB Routing-Traffic. Das ist schon eine Menge finde ich. Und einige berichten von deutlich mehr Grundlast.

yayachiken · 25. Dezember 2014 um 20:10

Ja, man möchte möglichst schnell wissen, wenn ein Router auf der Strecke stirbt, damit man weiß, dass man wo anders langrouten muss. Warum man ausgerechnet 5s gewählt hat und nicht mehr, weiß ich auch nicht. Mit den 5s sollten nicht mal stehende TCP-Verbindungen sterben vermute ich.

Machen normale Router das gegenüber dem Internetprovider/DSLAM auch?

Da hat man das Problem ja nicht, weil man ja immer nur über den Internetprovider an das Netz kommen kann, also nicht in die Verlegenheit kommt, wo anders langrouten zu müssen.

Bzgl. ARP Requests: Könnte man das nicht zentral auf die Gateways legen?

Nein, dann hast du ja nichts gewonnen, da dann aus dem BATMAN-Traffic ARP-Traffic wird, den man ja ursprünglich sparen wollte (siehe auch: IPv6 Neighbor Discovery, das will man ja auch loswerden)

Bzgl. ND: Wie viel Traffic wird dann da gespart?

Laut verlinktem PDF sind ca. 17 kBit/s Neighbour Solicitations + Advertisements. ICMPv6 gesamt sind ca. 23 kBit/s (selbe Quelle) und zum Vergleich ARP immer noch unter 10 kBit/s.

tcatm · 25. Dezember 2014 um 22:09

Ja, das ist bei batman-adv so nötig und, wie schon beschrieben, eigentlich schon ein bisschen lang. Nötig ist es aber nicht unbedingt. Andere Protokolle (babel z.B.) tauschen sich z.B. nur mit ihren direkten Nachbarn aus um zu erfahren, wer noch alles da ist.

Was genau? Die DAT macht das schon ziemlich gut.

Das dürfte recht viel werden, weil ein großer Teil der Multicastgruppen nur wenige (vielleicht ein bis drei) Subscriber haben dürfte und somit viele der Pakete zu Unicast werden können, sobald sie in einem Teilbaum ankommen, in dem es nur noch einen Subscriber gibt.

Teilbäume ohne Subscriber bekämen das Paket dann garnicht. Zugegeben, Uplinks entlasten würde das bei der aktuell Architektur wohl weniger.

Ja, das ist noch recht viel und unser nächstes Skalierungsproblem. Vielleicht können wir ja während des 31c3 überlegen, wie man damit umgehen könnte. Vielleicht könnte man ja mal über eine Art adaptiven OGM Interval nachdenken.

ivenae · 26. Dezember 2014 um 00:57

In meinem Fall habe ich nur in wenigen Fällen überhaupt einen Client. Und nur in diesem Fall möchte ich überhaupt, dass der Tunnel aufgebaut wird. Kein Client, kein Traffic. Ich finde das ganze so schlimm, dass ich überlege, wieder mein eigenen Hotspot aufzubauen, unabhängig von Freifunk. Bei mir werden 3 Gb pro Woche alleine an völlig unnützen Routerbroadcasts übertragen. Das geht gar nicht!

Zumindest möchte ich mir die Tage eine Lösung programmieren, die den Tunnel schliest, wenn keiner angemeldet ist.

Ein Mesh brauche ich auch gar nicht, es ist hier sowieso kein Freifunk Router nebenan. Ich verstehe nicht, warum wir überhaupt alle in einer Broadcastdomäne sind. Das ist für das Meshen gut, aber sobald WAN Uplinks ins Spiel kommen, ist das absolut unnötig! Und hier gibt es nunmal kein Mesh, weil kein Nachbar vor Ort ist und jeder DSL hat.

CHRlS · 26. Dezember 2014 um 01:09

Finde ich alles andere als schlimm und kann den Showstopper irgendwie nicht erkennen.

Zumal es kein unnützer Traffic ist, der da übertragen wird, da dieser notwendig ist um Deinen Knoten in die Infrastruktur einzubinden.

Klar, weniger ist besser, aber das sollte nicht das ausschlaggebende Kriterium sein…

adorfer · 26. Dezember 2014 um 04:11

Dann baue es wenigstens so, dass der fastd auch dann startet, sobald ein mesh-Nachbar auftaucht.
Und mache ein Gluon-Paket daraus, das wird auch andere interessieren, inbesondere Leute, die unterwegs einen UMTS-Uplink nutzen wollen.

So ein Paket würde dann nämlich mindestens(!) drei Fliegen mit einer Klappe schlagen.
a) Strom sparen
b) Traffic sparen
c) airtime sparen (freuen sich die Nicht-Freifunker drüber)

Ach ja, und das „fastd wiederanschalten wenn Mesh-Neighbours im adhoc-wifimesh auftauchen“ wäre wirklich wichtig: Denn ICH komme eigentlich unterwegs immer per Mesh um die Ecke. Weil ich einen MR3040 unter Gluon nutze, weil mein Laptop eine dermaßen unteridische Wlan-Leistung hat (vermutlich Kabelbruch im Scharnier zum Display oder so), dass ich über den portablen Router online gehe, wahlweise als Mesh-Node oder als WISP-Client (ja, ich weiss, der Kanal ist dann ggf falsch)

wusel · 26. Dezember 2014 um 23:34

Doch, sehr gut sogar.

Was genau ist Dein Problem an dieser Stelle? Du bist bei o2 und hast keine Flatrate, sondern einen Volumentarif im Flatrate-Pelz? Weil, wenn nicht, wo ist das … Problem? Bits roden nicht den Regenwald, und ob ein DSL-Modemrouter wirklich meßbar weniger Energie verbraucht, wenn man keine Daten überträgt, bezweifle ich einfach.

Ich gehe davon aus, Du hast Deinen DSL-Modemrouter trotz Flatrate nicht in einem on-demand-Modus konfiguriert? Abbau der DSL-Strecke, das könnte in der Tat energiesparend wirken …

Wie angeregt, wenn Du dazu im Stande bist, wäre ein Gluon-Package, welches fastd stoppt, wenn weder per Ad-Hoc noch per AP Geräte angemeldet sind, und im umgekehrten Fall ihn wieder startet, begrüßenswert. (Problematisch bleibt dann der Auto-Updater, der sollte ggf. den fastd-Tunnel auch aktivieren können.) Es bleibt natürlich der Alptraum in jeglichem Monitoring.

Wenn bei Dir eh’ keiner ist, der jemals meshen könnte, warum machst Du dann Freifunk? Der Router kostet Dich faktisch Geld (durch die Energie), aufregen tust Du Dich aber über immatrielle Dinge, die Dich nichts kosten?!

MPW · 27. Dezember 2014 um 00:17

Mich stört nicht der Traffic an sich, aber es ist irgendwie ineffizient.

Der Ping steigt, das ist blöd, wenn man über dieselbe Internetleitung Egoshooter spielen will.
Müssen die Leute, die Daten von meinem Rechner laden, länger warten (legale Torrents, Http per Dyndns, FTP). Mein Upload ist mehrere Stunden am Tag ausgelastet. Da machen 5-10% mehr oder weniger schon einen Unterschied.
Ich kann schlechter Videos streamen, also durch die DSL-Leitung hochladen. Sind in diesem Fall per DVB-S aufgezeichnete Sachen.
Einmal 15 GB sind nicht schlimm. Aber wenn jeder Freifunk machen würde, geht es schon auf die Grundlast des Netzbetreibers. Letztendlich mögen die uns dadurch noch weniger als ohnehin.

Hier wird immer von 55-100 Kbit/s geredet. Bei mir sind es aber eher 80 KByte/s (Münster). Das merkt man schon.

Ich fände es auch gut, wenn das deutlich effizienter wird und man evtl. das VPN abschaltet, solange kein Client dran hängt.

Viele haben sicherlich 100/10er Leitungen, aber ich hab z. B. nur VDSL 25 (Upload 5). Da ist man halt eingeschränkter. Und mehr gibt es hier nicht, da kein Kabelnetz und Leitung zu lang.

Und viele müssen mit viel weniger auskommen.

Ich teile gerne die Leitung, aber für sinnvolle Sachen. Wenn jemand etwas herunterlädt, warte ich auch gerne Mal ein paar Sekunden länger auf einen Download. Aber ohne Clients muss das nicht sein.

Ich denke mittelfristig sollte da etwas geändert bzw. verbessert werden.

Grüße
MPW

ivenae · 27. Dezember 2014 um 01:52

Obwohl schon überwiegend geschehen, möchte ich hier auch nochmal die Gründe zusammenfassen:

Wenn du den Router nur für andere betreibst…
Das ist nicht so. Der Router verstärkt mit einer anderen SSID, die als Bridge geschaltet ist mein WLAN. Im Gegenteil: Der Router steht hier so oder so, soll aber Freifunk zur Verfügung stellen.
Wenn du eh keine Gäste hast…:
Auch das ist Blödsinn: Hier ist eine Fahrradstrecke mit Leuten, die ausgerechnet hier an meinem Eckhaus gerne nach dem Weg fragen oder auf eine Karte schauen. Aber auch grundsätzlich ist das Argument unsinnig. Wenn hier 10 Leute im Monat für jeweils 10 min ins Internet kommen und wichtige Dinge erledigen können, würde ich das ganze als sinnvolle Maßnahme erachten. Die Auslastung liegt dann aber nur bei 2,5 Promille. Dennoch könnte ich 99,975 % des Traffics der 15 GB im Monat sparen. Wir reden hier also von mehreren Größenordnungen, die einzusparen sind.
Knappe Ressource: Das Upload nichts kostet, stimmt so nicht. Der Upload macht 10% meiner Bandbreite aus. Die fehlt mir beim Internettelefonieren, die macht meinen Upload in Tauschbörsen geringer (und sorgt dafür, dass meine Netzwerkplatte dann 10% länger active ist), die sorgt für größere Latenzzeiten beim Onlinespielen und sorgt dafür, dass ich auch auf versendete E-Mails 10% länger warten muss. Man kann jetzt die 10% kleinreden oder sonst wie relativieren. Aber es ist nunmal so, dass sie unnütz sind. Und hätte ich 9 weitere, ähnliche Anwendungen, die für genauso unsinnige Dinge Traffic verschwenden, sieht die Rechnung plötzlich so aus, dass die Internetverbindung verstopft ist, ohne dass sie genutzt wird. Alleine aus diesem Grund verbietet es sich. Weil es unethisch ist, Ressourcen ohne erkennbaren Grund zu verbrauchen, nur weil sie nichts kosten.
Was sind denn 15 GB. Das ist viel. Sogar ungemein viel. Das ist in etwa der dreifache Verbrauch eines durchschnittlichen DSL Nutzers. Ich habe auch schon darüber nachgedacht, bei 1und1 einen günstigeren Tarif zu wählen, der nur 5 Euro weniger kostet, aber bei 100GB drosselt. Ich habe davon abgesehen, weil ich diese Grenze schon einige Male überschritten habe, für - in meinen Augen - sinnvolle Anwendungen. Aber dieses hier ist so eine Anwendung, die nicht sinnvoll ist, aber dennoch einen essentiellen Beitrag zu der Größenordnung 100 GB liefert. Noch einmal: Es mag sein, dass es einigen Leuten scheiß egal ist, aber anderen so etwas einzureden, dafür ist die Größenordnung über die wir hier reden zu groß. Punkt aus!
Das Konzept des Broadcasts in der hier betriebenen Anwendung ist völlig obsolet. Nicht nur, dass dieser konzeptionelle Einsatz von Broadcastdomänen spätestens seit Ende der 90er Jahre veraltet ist, weil hier Netztrennungen auf Layer3 Basis viel sinnvoller sind. Es leuchtet mir auch nicht ein, warum MEIN ROUTER Broadcasts sendet, obwohl niemand dort im Netz ist. Mein Router ist in 99,975% der Zeit ein „Stub“-Netzwerk, das hat verdammt nochmal nichts zu senden. Wenn es 150 kbit/s empfängt: Meinetwegen. Aber senden? Wofür? Dafür, dass hier „immernoch niemand“ im Netz ist? Ich habe ja mit vielen Reaktionen auf meinen Post gerechnet. Dass ich etwas falsch eingestellt habe. Das ich etwas übersehe. Aber das hier irgendwelche 90er Jahre beepworld-Hippies ihr völlig anachronistisches Konzept wie so ein Apple-Fanboy verteidigen. Sorry, damit muss ich erstmal klarkommen, damit hab ich nicht gerechnet.

wusel · 27. Dezember 2014 um 02:42

„Der Ping steigt, das ist blöd, wenn man über dieselbe Internetleitung Egoshooter spielen will.“ Hmm, dürfte er nicht bei den genannten Werten; außer, Du benötigst 100+% Deines Upstreams, sollten paar kBit/sec Grundrauschen sich nicht bemerkbar machen.

„Müssen die Leute, die Daten von meinem Rechner laden, länger warten“ Yepp, das ist so; technisch geht es derzeit nicht anders (freifunkseitig). Ganz prinzipiell frage ich mich natürlich, welchen Sinn ein Freifunk-AP hinter einer dauerhaft ausgelasteten Leitung auch für Freifunk macht.

„Ich kann schlechter Videos streamen, also durch die DSL-Leitung hochladen. Sind in diesem Fall per DVB-S aufgezeichnete Sachen.“ Ja, das schmerzt; ich mußte gestern auch 2+ Stunden warten, bis die DVB-S-Aufzeichnung von Doctor Who durch das 2,2-Mbit/sec-VDSL-Nadelöhr zuhause zu meinem Aufenthaltsort getröpfelt war (First World Problems: Dein stationärer Upstream ist ein Fünftel Deines mobiles Downstreams). Wobei ich meine 5+ Freifunk-Knoten im und am Haus nicht gespürt habe …

„Einmal 15 GB sind nicht schlimm. Aber … Grundlast des Netzbetreibers.“ Sorry, aber ich denke, Netflix, Watchever und Co., neben YouTube, machen jenen deutlich mehr zu schaffen als die 6000 Freifunk-Knoten. Wo es sie nervt, dürften die Orte sein, wo sie Hotspots hingestellt haben und nun Freifunk frei funkt …

„Bei mir sind es aber eher 80 KByte/s (Münster).“ Äh. 80 kByte(!)/sec, da gäbe ich Dir recht, das wäre spürbar. Kann ich aber wirklich nicht nachvollziehen:

Ich ‚hänge‘ hier grade an einer ‚UMTS-Leitung‘; Weihnachten, DSL-lose Verwandschaft, Ihr kennt das. Obiges ist der Graph der FB, an der u. a. 2 FF-Knoten hängen (1 per LAN, 1 im 1. Stock meshend zur besseren Abdeckung). Die Knoten sind normale Knoten im Gütersloher Freifunk-Netz, aktuell 148 Knoten und 101 Clients online. Ich denke mal, 80 kByte/sec müßte ich da deutlicher sehen. Aber ja, Traffic fließt, kontinuierlich; es wird ein spannendes Rennen, ob erst das Jahr oder erst das Inklusivvolumen am Ende sein wird

FTR, in GT habe ich nur VDSL 22/2,5 (mehr ist halt nicht, indoor, 900+m; FTTH kommt dank BNetzA never; Kabelanschluß kostete schlappe 2k5 EUR als Schäppchenangebot mit 24monatiger Vertragsbindung, durch die weitere Kosten entstehen); aber auch da sehe ich die 80 kByte, von denen Du sprichst, nicht.

Was die Optimierung angeht: ich denke, „da ist man dran“; aber das geht alles nicht von heute auf morgen, was wir heute haben, ist ja schon eine weitgehend optimierte Struktur. Ein sich selbst verwaltendens Netz – und nicht weniger ist in modernes Freifunk-Netz! – benötigt auch ein bißchen Verwaltungsoverhead. Deine 80 kByte/sec (ich rechne das mal platt in 800 kBit/sec um) ist zuviel, aber fraglich, für mich, ist, ob das wirklich reiner batman_adv-Managementtraffic ist. 100 kBit/sec, 10% eines DSL16k-Upstreams, fände ich für Netze mit 200-300 Knoten nock akzeptabel — und ja, wir haben Geschäfte gefunden, die bei uns mitmachen wollten, aber nur DSL3000 hatten. (Oft nie angepaßte Altverträge.)

Kurzum: ich denke, der Ruf wurde erhört — allerdings schon vorher, denn Freifunker sind selten die mit den 3 VDSL100-Anschlüssen.

wusel · 27. Dezember 2014 um 03:18

„Der Upload macht 10% meiner Bandbreite aus. Die fehlt mir beim Internettelefonieren,“ Das ist definitiv falsch, außer, Du betreist ein Call-Center. Typischerweise gehen 80 kBit/sec je SIP-Call drauf, wenn 100 kBit/sec 10% Deiner Upstream-Bandbreite sind, hast Du also noch Bandbreite für mehr als 9 parallele(!) SIP-Calls. Es sei denn, „Internettelefonie“ schließt bei Dir HD-Videofonie mit ein, da fehlt bei einem MBit/sec-Upstream natürlich jedes Bit.

„die sorgt für größere Latenzzeiten beim Onlinespielen“ Auch das stelle ich bei 10% Grundlast in Abrede, jeweils dahingehend, daß dies meßbar wäre.

„Das Konzept des Broadcasts in der hier betriebenen Anwendung ist völlig obsolet. Nicht nur, dass dieser konzeptionelle Einsatz von Broadcastdomänen spätestens seit Ende der 90er Jahre veraltet ist, weil hier Netztrennungen auf Layer3 Basis viel sinnvoller sind.“ Es heißt ja nicht umsonst: you have the source to fix it. github needs YOU!

Wo, außer in Nordkorea, „dieser konzeptionelle Einsatz von Broadcastdomänen spätestens seit Ende der 90er Jahre veraltet“ sein soll, erschließt sich mir nicht. Jedes Heimnetz wird noch immer so aufgebaut, und in den Wolkenkuckucksheimen bildet man dieses Konstrukt sogar neu nach. Ich würde ja soweit gehen uns sagen, jeder VDSL-Anschluß ist Teil einer Broadcastdomain, aber, hey, ich habe da länger nicht mehr nachgeschaut.

Ja, der Gluon-Ansatz hat was von Apple-Kram; er ist elegant, er ist benutzerfreundlich — und unter der Haube nicht wirklich schön.

Im Grunde™ sollte man die Netze anders bauen. Planquadrate anlegen, je Planquadrat (Kantenlänge <=200m) IP-Adressbereiche, SSIDs und Gateways definieren. Der erste Knoten je Planquadrat zementiert dieses. Bildet sich eine fortlaufefende Linie, werden betroffene Planquadrate dem 1. dieser Linie zugeschlagen, welches sich entsprechend vergrößert. Plätze haben Vorang vor Straßen. Und schon gibt es nur 1-100 Knoten pro batman_adv-Mesh, mit entsprechend weniger Overhead.
Die Planung verzögert den Rollout, Knoten ohne genaue Positionsangabe können nicht mehr partizipieren, die Nutzer müssen alle paar hundert Meter eine andere SSID freischalten, da alle paar hundert Meter andere Layer-3-Variablen gelten.

Du hast recht, es ist mir unbegreiflich, warum diese »90er Jahre beepworld-Hippies ihr völlig anachronistisches Konzept« – das blöderweise auch noch einfach funktioniert – verteidigen — Dein Layer-3-Non-Mesh ist doch so viel gradliniger!