Ständige Neustarts in der Domäne Ruhrgebiet

Technik Ruhrgebiet
55

1 - Kosmos / Abrazo:

Kein echtes Problem, lediglich ein Anzeigefehler.

Einfach den Alfred auf Kosmos neustarten, dann ist die Node wieder sichtbar und der Uplink auch wieder der richtigen Node zugeordnet…wird ebenfalls in 2014.4 besser, da dort Alfred stabiler laufen soll, ist nicht durch uns manipulierbar, da müssen wir auf die Gluon Entwickler hoffen…

2 - warum ist Freifunk so langsam / funktioniert nicht

Das kann an diversen Dingen liegen, sehr oft leider nicht an der Infrastruktur, ich würde sogar soweit gehen und sagen eher selten an der Infrastruktur. Die meisten Fehler treten lokal auf, durch schlechte Internetleitungen, wegbrechende Uplinks, zu geringem Durchsatz bei weit entfernten Routern in der Luft, usw usw. In Gelsenkirchen wird es massiv lokale Probleme geben, ganz sicher sogar, trust me…

2a - Übersetzung

Viel zu übersetzen ist ja eigentlich nicht gewesen.

Ich habe auf Seite der Infrastruktur diverse, die allgemeine Performance beeinflussende, Dinge auf Stand gebracht. Man merkt dass die Last auf den Nodes dadurch reduziert wurde und die Performance durch diese Entlastung massiv gesteigert wurde. Erstmal ist es besser und bleibt auch so.

3 - Nachhaltigkeit

Das ist in der heutigen Zeit eine eher belustigende Frage, es sei denn man wählt als Hotspot Anbieter die Telekom. Jedes andere Unternehmen kann auch morgen den Bach runter gehen und liefert dann nicht mehr.

Insgesamt ist festzuhalten das unsere Technik wesentlich komplexer ist als bei den gewöhnlichen Hotspot Anbietern. Dies ist dem Umstand geschuldet, dass wir in der Luft meshen. Gib jedem Freifunkrouter einen eigenen Uplink, dann hast Du die Probleme des Mesh in der Luft zumindest nicht mehr. Stell das ganze Netz darauf um nicht mehr in der Luft zu meshen, dann hast Du gar keine Probleme mehr, denn dann kannst Du direkt Layer3 statt Layer2 auf die Nodes fahren, allerdings dann komplett ohne Funktionen die unser Netz besonders machen, wie beispielsweise das uplinklose meshen in der Luft, Roaming über alle Router hinweg, etc.

Was wollen wir also,

  • die technisch anspruchsvollere Lösung mit entsprechenden Mehrwerten, aber auch mehr Arbeit und mehr notwendiges Know How vor Ort?
  • oder ein ruhigeres Leben, geringes Know How notwendig, dafür aber ein Netz auf dem technischen Niveau der proprietären Hotspot Anbieter, die nichts können ausser einen normalen Internetzugang zum autarken WLAN Hotspot zu machen?
1 „Gefällt mir“
56

Belastet bitte nur den Philip nicht zu sehr. Er hat eigentlich gänzlich andere Aufgaben als Alfred Dienste auf Routern vor Ort neu zu starten.

Die Map ist als Diagnosewerkzeug aktuell zumindest „ungünstig“, solange der Alfred in der Firmware der Nodes noch Probleme hat…

1 „Gefällt mir“
57

@Chris
Phillip war auf dem Router und hat das Alfred Problem überprüft. Ich gehe davon aus, dass er ihn auch neu gestartet hat - oder? Das Problem besteht immer noch.

Thema „Nachhaltigkeit“
Damit ist Manpower gemeint. Konkret: wie groß ist die Personaldecke. Was passiert, wenn Leistungsträger aus dem Bereich Technik im Bündel nach Irland weggekauft werden oder als Gang im Silicon Valley für viele Dollar tätig werden, statt unbezahlt Freifunk weiter zu machen. Das sind ernst gemeinte Fragen der Politik, die ich vor Ort auch beantworten muss.

Thema „Übersetzung“
am Ende ist es ja meistens nicht viel, was gemacht werden musste. Die Techniker verstehen die Lösung, wenn sie die „Suchwege“ nachvollziehen. Ich muss aber hier alle bedienen - technik affine Politiker, die Router-Bettreiber und die „Endkunden“ - und das alles ohne Technik-Sprech auf Kleine-Mann-von-der-Straße-Sprech runter brechen zu können.

58

Nachtrag zur Nachhaltigkeit:

Wir suchen fortlaufend nach fähigen Linux Experten, um das lokale Ruhrgebiets Admin Team zu verstärken.

„Der Papa“ hatte die letzten Wochen wegen zu vieler Projekte und einem privaten Fiasko leider nicht so viel Zeit wie üblich. Ich will nun gar nix schön reden, aber vielleicht haben die Probleme eben auch daran gelegen das ich zu wenig Zeit für das Netz verwendet habe. Zumindest hätte man es schneller lösen können…

Einen mutigen Admin Kandidaten haben wir noch in der Pipeline, da bin ich noch nicht zu gekommen mich zu kümmern, aber das Admin Team zu verstärken ist unumgänglich, da es für die allgemeine Administration derzeit nur aus mir besteht - auch wenn ich noch die Hoffnung hege, dass der Jörg sich auch in die allgemeine Administration reinmischt. :wink:

1 „Gefällt mir“
59

kann ich bestätigen nach einem einfachen sysupdate :smiley:

60

Die Personaldecke sieht derzeit so aus:

Chris: Administration global
Philip (@pberndro): PR, Firmwarekompilierung/Firmwarebetreuung (aktuell auch noch zusätzlich allgemeiner Support)
Jörg: Administration DNS / Mail / Security
Thomas (@thomasDOTwtf): Notfalladmin fürs Ruhrgebiet, Admin der Domäne Möhne
Thomas (@fragstone): aktuell Admin Bewerber

3 „Gefällt mir“
61

okay, werd das hier nicht vertiefen, eine persönliche Begegnung vor einer Befragung durch die Ratsfraktionen würde mir ein sichereres Gefühl geben. Möchte schon von dem „Alles nur Avatare“ Gefühl wegkommen und selber einschätzen können… usw,

Nachtrag: bin in Sachen Freifunk und Vertrauen setzten in Einzelpersonen gebranntes Kind

62

Sahen ich, Julian, Andy, Jörg etc. aus wie Avatare?

Du bist eine der ganz ganz wenigen Personen die nicht nur unmittelbar, in ca. 3 Meter Abstand, zu ffrg0 etc. bei uns im RZ gestanden haben, sondern auch direkt noch mehrere Personen, die sonst nie jemand zu Gesicht bekommt, gesehen haben…oder ich muss Deinen Memory debuggen!? :smiley:

2 „Gefällt mir“
63

vielleicht wäre diese Info an zentralerer Stelle besser aufgehoben, zB. hier:

64

ohh… ich dachte die arbeiten der Deutschen Bank oder Julian Assange zu … :wink: - und die dürfen wirklich nicht da raus? :smile:

Nee ernsthaft noch mal - einige von euch denken, dass ich ein seltsamer Kauz (Troll usw.) wäre. Was nicht weiter schlimm ist, ob ich nun was tue oder unterlasse, es hat keine Auswirkung auf den Freifunk.

Läuft aber einer der Leistungs- und Entscheidungsträger „Amok“ - sieht das anders aus. Wenn ich also etwas glaubwürdig vertreten soll, sollte ich da auch Sicherheiten haben - in diesem Fall, dass ich ungefähr einschätzen kann, wie die Menschen „ticken“ die das Projekt verantwortlich stemmen.

65

Höre eine Eingebung: es wäre ein MAC/Bit Problem - es muss ein völlig anderer, neuer Router da hin, dann ginge es auch.

66

Ich habe gestern zu der Zeit, in der das Problem mit den Neustarts äußerst akut war, ebenfalls festgestellt, dass Freifunk sehr träge war. Das war aber auch der einzige Moment. Ich hatte diesbezüglich sonst nie Probleme.

67

Es handelt sich dabei um einen DHCPv6 Client, nicht Server. Das dieser mehrfach läuft ist natürlich trotzdem nicht schön. In Rheinufer sieht das übrigens so aus (Allerdings Gluon 2014.4):

root@Cyrus-Foxden01:~# ps w
  PID USER       VSZ STAT COMMAND
    1 root      1388 S    /sbin/procd
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    5 root         0 SW<  [kworker/0:0H]
    7 root         0 SW<  [khelper]
   59 root         0 SW<  [writeback]
   62 root         0 SW<  [bioset]
   64 root         0 SW<  [kblockd]
   97 root         0 SW   [kswapd0]
  144 root         0 SW   [fsnotify_mark]
  175 root         0 SW<  [ath79-spi]
  256 root         0 SW<  [deferwq]
  326 root         0 SWN  [jffs2_gcd_mtd3]
  410 root      1220 R    /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300
  412 root       896 S    /sbin/ubusd
  413 root       772 S    /sbin/askfirst ttyS0 /bin/ash --login
  441 root      1392 S    -ash
  531 root      1388 R    ps w
  580 root         0 SW<  [bat_events]
  675 root         0 SW<  [cfg80211]
  947 root      1036 S    /sbin/logd -S 16
  952 root      1600 S    /usr/sbin/haveged -w 1024 -d 32 -i 32 -v 1
 1093 root      1608 S    /sbin/netifd
 1136 root      1152 S    /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300
 1146 root       788 S    /usr/sbin/gluon-crond /lib/gluon/cron
 1151 root      1104 S    /usr/sbin/gluon-radvd -i br-client -p fda0:747e:ab29:cafe::/64
 1184 root      1140 S    /usr/sbin/uhttpd -f -h /lib/gluon/status-page/www -r Cyrus-Foxden01 -x /cgi-bin -t 60 -T 30 -A 1 -n 3 -R
 1194 root       920 S    /usr/sbin/dnsmasq -x /var/run/gluon-wan-dnsmasq.pid -u root -i lo -p 54 -h -r /var/gluon/wan-dnsmasq/reso
 1431 root       812 S    odhcp6c -s /lib/netifd/dhcpv6.script -t120 br-client
 1437 root      1392 S    /usr/sbin/ntpd -n -p fda0:747e:ab29:cafe::fec1 -p fda0:747e:ab29:cafe::fec2 -p ntp1.ptb.de
 1464 root      1108 S    /usr/sbin/alfred -i br-client -b bat0
 1485 root      1320 S    /usr/sbin/batadv-vis -i bat0 -s
 1664 root      1576 S    /usr/sbin/hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
 1723 nobody     924 S    /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k
 6712 root         0 SW   [kworker/0:0]
 6855 root      3172 S    /usr/bin/fastd --config - --daemon --pid-file /var/run/fastd.mesh_vpn.pid
 6914 root       792 S    /usr/bin/gluon-announced -g ff02:0:0:0:0:0:2:1001 -p 1001 -s /lib/gluon/announce/announce.lua nodeinfo -i
18198 root         0 SW   [kworker/0:1]
20164 root      1388 S    udhcpc -p /var/run/udhcpc-br-wan.pid -s /lib/netifd/dhcp.script -f -t 0 -i br-wan -C
20167 root       816 S    odhcp6c -s /lib/netifd/dhcpv6.script -P0 -t120 br-wan
30100 root         0 SW   [kworker/u2:2]
30901 root         0 SW   [kworker/u2:1]
31591 root         0 SW   [kworker/u2:0]
68

Ich ignoriere also diese Meldungen?

The monitor Die Grünen (2a02:f98:0:26:ea94:f6ff:fecd:50c6) is back UP (Host Is Reachable) (It was down for 10 minutes and 0 seconds).

Cheers,

Uptime Robot
http://www.uptimerobot.com
http://twitter.com/uptimerobot

69

Nein, die Meldung von dem Uptime Robot kann schon stimmen, die Frage ist eher woran liegt es bei euch? Denn das ist kein allgemeiner Fehler in der Domäne, sondern ein lokales Phänomen / Problem…

Bezüglich identischer Mac Adressen von Kosmos und Abrazzo oder so ähnlich hatte ich mit Philip gesprochen, der Dir dann geschrieben hat. :wink:

70

@CyrusFox: die Scripte gehören nicht direkt zum Dienst, sondern werden automatisch gelauncht sobald der Router eine RA / RS Kombi im Netz sieht…ob bei URA auch weiß ich nicht, müsste ich Neo nochmal fragen, denke aber schon…

Mit anderen Worten, je mehr RA / RS / URA umhergeistern, desto mehr Scripte laufen gleichzeitig - was natürlich eine Frage der Client Fluktutation ist.

Wenn nun die Nodes ohnehin schon eine sehr hohe Load haben, so wie es bei uns der Fall war, dann werden die nicht mehr schnell genug abgearbeitet und klemmen im Memory fest - so sah es dann zumindest aus.

Aber ist erstmal bis auf Weiteres gelöst und die nervigen Reboots somit auch vorläufig Geschichte…

71

Ah okay, habt ihr jetzt die eingehenden RA’s auf den Supernode Interfaces blockiert? So haben wir das in Rheinufer schon seit Anfang an.

72

Nein, läuft alles noch nach standard ohne Filterung.

Der tatsächliche Unterschied für die Nodes ist im Grunde genommen nur die aktuellere fastd v16. Wobei wir die Liste entsprechend angepasst haben, damit die Server untereinander schon das umac nutzen, während die Nodes den unbekannten Method Eintrag ignorieren und den 2. Eintrag gmac zum connecten benutzen…

Sollte in den anderen Domänen am besten auch zeitnah umgestellt werden auf die aktuelle Version, da in v13,v14 und v15 massiv Verbesserungen für große Layer2 Netze eingeflossen sind laut Neo.

Bei Ubuntu ist es auch ziemlich simpel per apt-get zu machen, bei Debian musste man wegen der nicht erfüllbaren Abhängigkeiten ein wenig mehr fummeln, da es teilweise noch keine wheazy backports gibt.

73

Das hat nichts mit höherer Eingebung zutun!
Es gibt im Backend vom Alfred ein so genannten „fuzzy mac“ Bug, da kann es vorkommen, dass sehr ähnliche MAC-Adressen für gleiche MAC-Adressen gehalten werden.

Es ist lediglich ein Versuch diesen Anzeigefehler zu korrigieren, dies hat aber nichts mit der Funktionalität vom Freifunk-Netz zutun.

Gruß,
Philip

74

ist das eigentlich permanent, oder muss man es dazu in die Config-Datei eintragen?
Ich habe seitdem einen Node, der sich wieder langweilt :wink: