Ständige Neustarts in der Domäne Ruhrgebiet

Technik Ruhrgebiet
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:

75

Ja, es muss in die Config Datei eingetragen werden.
Hier ist eine entsprechende Anleitung.

https://cosu.ro/blog/2011/09/26/ipv6-neighbour-table-overflow/

76

@Chris:
ich kann nicht bestätigen das die Router nicht mehr Booten.
Schau nur mal in den Alfred.

Die kisten krachen nur nicht direkt nach dem Start wieder weg. Somit ist es besser geworden.
Ich für meinen Teil finde das mehr als ein Reboot pro Tag deutlich zu viel sind.
Vorallem wenn man etwas dagegen machen kann.

Gruß
Thomas

77

Aber die Gruppen der Router die davon hauptsächlich betroffen waren sind nun mit einer Uptime 18h und 19h immer noch ohne reboot in der Alfred Liste drin!?

Das Router mal neustarten, entweder selber von sich aus, oder aber aus diversen Gründen:

  • der gute Geist des Haushalts brauchte die Steckdose zum Bügeln
  • die Katze ist über das Netzwerkkabel gestolpert
  • oder sonstiges
    war schon immer so.

Ich möchte aus einer Hand voll Routern die ne frische Uptime haben eigentlich kein Massenphänomen erkennen können. :wink: