Ahoi,
manche Router machen Probleme, obwohl sie eigentlich erreichbar sein müssten.
Beispiel: FF-OS-Theater-Foyer
MAC: f8:1a:67:eb:c7:7e
LL: fe80:0:0:0:fa1a:67ff:feeb:c77e ULA: fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e
Per Batman erreichbar, Alfred-Daten kommen an.
traceroute to f8:1a:67:eb:c7:7e (fa:1e:67:eb:c7:7e), 50 hops max, 20 byte packets 1: fa:1e:67:eb:c7:7e 20.240 ms 20.102 ms 19.835 ms
Auf IP-Ebene geht aber nix.
Wer mag, kann sich die dumps im Root-Home auf srv06 anschauen oder ziehen: http://srv06.ffnw.de/theaterfail%5B1-4%5D.dump
Hi,
ich kann da gerade auch nur in die Glaskugel schauen aber nach den Stats zu urteilen ich würde spontan vermuten, dass da irgendwas stark überlastet ist und es dadurch zu sehr merkwürdigen Problemen kommt, die sich nicht debuggen lassen.
Vorschlag: * Zusätzlichen Server mieten, am besten nen dedicated bei serverdiscount, laufzeit 1 Monat, kostet 20€ => haben wir * Neue Supernode auf der Kiste hochziehen * Update raushauen * Hoffen dass die Last sinkt und die Probleme dadurch verschwinden
LG Clemens
Am Mittwoch, 10. Juni 2015, 13:49:35 schrieb Bjoern Franke:
Ahoi,
manche Router machen Probleme, obwohl sie eigentlich erreichbar sein müssten.
Beispiel: FF-OS-Theater-Foyer
MAC: f8:1a:67:eb:c7:7e
LL: fe80:0:0:0:fa1a:67ff:feeb:c77e ULA: fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e
Per Batman erreichbar, Alfred-Daten kommen an.
traceroute to f8:1a:67:eb:c7:7e (fa:1e:67:eb:c7:7e), 50 hops max, 20 byte packets 1: fa:1e:67:eb:c7:7e 20.240 ms 20.102 ms 19.835 ms
Auf IP-Ebene geht aber nix.
Wer mag, kann sich die dumps im Root-Home auf srv06 anschauen oder ziehen: http://srv06.ffnw.de/theaterfail%5B1-4%5D.dump
Hi,
warum wollen wir nicht erstmal einen der älteren hochziehen, wie srv04 oder 01? Bald ist eh neue Hardware da..
Am 10. Juni 2015 18:26:27 MESZ, schrieb Clemens John clemens.john@floh1111.de:
Hi,
ich kann da gerade auch nur in die Glaskugel schauen aber nach den Stats zu urteilen ich würde spontan vermuten, dass da irgendwas stark überlastet ist und es dadurch zu sehr merkwürdigen Problemen kommt, die sich nicht debuggen lassen.
Vorschlag:
- Zusätzlichen Server mieten, am besten nen dedicated bei
serverdiscount, laufzeit 1 Monat, kostet 20€ => haben wir
- Neue Supernode auf der Kiste hochziehen
- Update raushauen
- Hoffen dass die Last sinkt und die Probleme dadurch verschwinden
LG Clemens
Am Mittwoch, 10. Juni 2015, 13:49:35 schrieb Bjoern Franke:
Ahoi,
manche Router machen Probleme, obwohl sie eigentlich erreichbar sein müssten.
Beispiel: FF-OS-Theater-Foyer
MAC: f8:1a:67:eb:c7:7e
LL: fe80:0:0:0:fa1a:67ff:feeb:c77e ULA: fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e
Per Batman erreichbar, Alfred-Daten kommen an.
traceroute to f8:1a:67:eb:c7:7e (fa:1e:67:eb:c7:7e), 50 hops max, 20 byte packets 1: fa:1e:67:eb:c7:7e 20.240 ms 20.102 ms 19.835 ms
Auf IP-Ebene geht aber nix.
Wer mag, kann sich die dumps im Root-Home auf srv06 anschauen oder ziehen: http://srv06.ffnw.de/theaterfail%5B1-4%5D.dump
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
warum wollen wir nicht erstmal einen der älteren hochziehen, wie srv04 oder 01? Bald ist eh neue Hardware da..
+1
SRV04 kann eigentlich für das neue Setup vorbereitet werden. Da spricht nix gegen.
srv01 und 2 müssen wir mal evaluieren wie wir das mit den Setup machen. Im Grunde könnte man srv02 auch umstellen allerdings würden dann alle Firmwares vor 0.5.5.2 komplett vom Netz abgeschnitten, da diese sich dann nicht mehr zu den Servern verbinden können.
LG Tarek
Und srv02 hat Tunnel zum FFRL und Berlin. Dann wäre der srv04 das sinnvollste. Könnten wir das mit einer FW zeitnah hinbekommen? Das Netz ist grade sonst ein wenig instabil.
Am 10. Juni 2015 18:54:59 MESZ, schrieb Jan-Tarek Butt tarek@ring0.de:
warum wollen wir nicht erstmal einen der älteren hochziehen, wie
srv04 oder 01?
Bald ist eh neue Hardware da..
+1
SRV04 kann eigentlich für das neue Setup vorbereitet werden. Da spricht nix gegen.
srv01 und 2 müssen wir mal evaluieren wie wir das mit den Setup machen. Im Grunde könnte man srv02 auch umstellen allerdings würden dann alle Firmwares vor 0.5.5.2 komplett vom Netz abgeschnitten, da diese sich dann nicht mehr zu den Servern verbinden können.
LG Tarek
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Am Mittwoch, den 10.06.2015, 19:00 +0200 schrieb Stefan:
Und srv02 hat Tunnel zum FFRL und Berlin. Dann wäre der srv04 das sinnvollste. Könnten wir das mit einer FW zeitnah hinbekommen? Das Netz ist grade sonst ein wenig instabil.
Nope. 01 hat zu Rheinland, 04 zu Berlin.
Am Mittwoch, 10. Juni 2015, 18:43:19 schrieb Stefan:
warum wollen wir nicht erstmal einen der älteren hochziehen, wie srv04 oder 01? Bald ist eh neue Hardware da..
Hi,
wenn das kein Problem darstellt dann ist das auf jeden Fall der bessere Weg. Hatte den Vorschlag mit neuer Hardware gebracht, damit wir die Verbindung zu alten Routern halten können, aber wenn das nicht notwendig ist, dann srv04 und srv02 hochziehen.
Firmware Update müssen wir allerdings in jedem Fall nachschieben, da sich die 0.5.6 nicht zu vpn03/02 verbinden kann.
LG Clemens
wenn das kein Problem darstellt dann ist das auf jeden Fall der bessere Weg. Hatte den Vorschlag mit neuer Hardware gebracht, damit wir die Verbindung zu alten Routern halten können, aber wenn das nicht notwendig ist, dann srv04 und srv02 hochziehen.
Ich würde nur 04 sagen oder wollen wir auf die Router vor 0.5.5.2 verzichten ? Ich wäre dagegen.
Firmware Update müssen wir allerdings in jedem Fall nachschieben, da sich die 0.5.6 nicht zu vpn03/02 verbinden kann.
Das ist kein Problem
LG Tarek
Erstmal nur 04 oder? Dann haben wir ja wieder Luft bis neue HW on ist.
Am 10. Juni 2015 19:16:31 MESZ, schrieb Jan-Tarek Butt tarek@ring0.de:
wenn das kein Problem darstellt dann ist das auf jeden Fall der
bessere Weg.
Hatte den Vorschlag mit neuer Hardware gebracht, damit wir die
Verbindung zu
alten Routern halten können, aber wenn das nicht notwendig ist, dann
srv04 und
srv02 hochziehen.
Ich würde nur 04 sagen oder wollen wir auf die Router vor 0.5.5.2 verzichten ? Ich wäre dagegen.
Firmware Update müssen wir allerdings in jedem Fall nachschieben, da
sich die
0.5.6 nicht zu vpn03/02 verbinden kann.
Das ist kein Problem
LG Tarek
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Am Mittwoch, den 10.06.2015, 19:16 +0200 schrieb Jan-Tarek Butt:
wenn das kein Problem darstellt dann ist das auf jeden Fall der bessere Weg. Hatte den Vorschlag mit neuer Hardware gebracht, damit wir die Verbindung zu alten Routern halten können, aber wenn das nicht notwendig ist, dann srv04 und srv02 hochziehen.
Ich würde nur 04 sagen oder wollen wir auf die Router vor 0.5.5.2 verzichten ? Ich wäre dagegen.
Ja, du würdest ja gerne auch noch 0.4.xx mitnehmen, ne? :p
Am Mittwoch, den 10.06.2015, 19:25 +0200 schrieb Jan-Tarek Butt:
Ja, du würdest ja gerne auch noch 0.4.xx mitnehmen, ne? :p
0.4 geht nicht mehr du hole Nuss. Das solltest du wissen. :D
Ja, aber du möchtest ja auch 02 laufen lassen um irgendwelche Altlasten zu supporten.
vg
Ja, aber du möchtest ja auch 02 laufen lassen um irgendwelche Altlasten zu supporten.
ne aber ich finde es blöd wenn wir einfach auf gut 100 Router verzichten. Mir scheint es so als würde der fastd auf Port 10000 nicht mehr laufen, hattest du den abgestellt ?
Ich finde das nur ein wenig unfair den Freifunk Routern gegenüber.
LG Tarek
Am Mittwoch, den 10.06.2015, 19:33 +0200 schrieb Jan-Tarek Butt:
Ja, aber du möchtest ja auch 02 laufen lassen um irgendwelche Altlasten zu supporten.
ne aber ich finde es blöd wenn wir einfach auf gut 100 Router verzichten. Mir scheint es so als würde der fastd auf Port 10000 nicht mehr laufen, hattest du den abgestellt ?
100 Router? 51 Fastd-Verbindungen (2,9,40) im alten Netz, 66 Router laut Alfred. 63 mit 0.5.5.4. Und überwiegend mit Autoupdater.
fastd auf Port 10000 war gestorben, neu gestartet hat er nun 2 Verbindungen.
Ich finde das nur ein wenig unfair den Freifunk Routern gegenüber.
Freifunk ist aber auch kein kommerzielles Produkt, bei dem die Routerbetreiber eine jahrelange Upgradegarantie gebucht haben. Und ebenso kein Ubuntu LTS. Wer ein halbes Jahr altes Arch updaten will, kann auch Probleme bekommen.
Am 10.06.2015 um 19:56 schrieb Bjoern Franke:
Am Mittwoch, den 10.06.2015, 19:33 +0200 schrieb Jan-Tarek Butt:
Ja, aber du möchtest ja auch 02 laufen lassen um irgendwelche Altlasten zu supporten.
ne aber ich finde es blöd wenn wir einfach auf gut 100 Router verzichten. Mir scheint es so als würde der fastd auf Port 10000 nicht mehr laufen, hattest du den abgestellt ?
100 Router? 51 Fastd-Verbindungen (2,9,40) im alten Netz, 66 Router laut Alfred. 63 mit 0.5.5.4. Und überwiegend mit Autoupdater.
Ja ich hab ungefair 30 router mit ganz alten setup dazu gerechnet aber es sind wohl nur 2.
fastd auf Port 10000 war gestorben, neu gestartet hat er nun 2 Verbindungen.
Ah ok naja die zwei. Wir könnten dehnen ne mail schreiben und sagen das wir den fastd auf 10000 jetzt abschalten.
Ich finde das nur ein wenig unfair den Freifunk Routern gegenüber.
Freifunk ist aber auch kein kommerzielles Produkt, bei dem die Routerbetreiber eine jahrelange Upgradegarantie gebucht haben. Und ebenso kein Ubuntu LTS. Wer ein halbes Jahr altes Arch updaten will, kann auch Probleme bekommen.
Das hat nix mit kommerziell zutuhen. Ich fände es nur doof wenn wir ohne Vorwarnung und Blog Artikel einfach Router Kicken aber wenn die Mehrheit das so will ich doch alles in Ordnung.
LG Tarek
Zitat von Jan-Tarek Butt tarek@ring0.de:
Das hat nix mit kommerziell zutuhen. Ich fände es nur doof wenn wir ohne Vorwarnung und Blog Artikel einfach Router Kicken aber wenn die Mehrheit das so will ich doch alles in Ordnung.
wie wäre ein kompromiss?
die ff_nodes informieren und dann 24-48h später abschalten? kommt halt drauf an wie schnell es passieren muss.
ja klar ihr habt beide recht, aber ich bin da eher bei bjo. wer freifunk macht muss etwas mit der zeit gehen.
was denkt ihr?
Am Mittwoch, den 10.06.2015, 20:10 +0200 schrieb freifunk@fr32k.de:
Zitat von Jan-Tarek Butt tarek@ring0.de:
Das hat nix mit kommerziell zutuhen. Ich fände es nur doof wenn wir ohne Vorwarnung und Blog Artikel einfach Router Kicken aber wenn die Mehrheit das so will ich doch alles in Ordnung.
wie wäre ein kompromiss?
die ff_nodes informieren und dann 24-48h später abschalten? kommt halt drauf an wie schnell es passieren muss.
ja klar ihr habt beide recht, aber ich bin da eher bei bjo. wer freifunk macht muss etwas mit der zeit gehen.
was denkt ihr?
Von den Port 10000-Kandidaten ist der eine FFSandeRuestringerStr67Sued, der andere FF-OS-WIM-03 von Chris (FF Ruhrgebiet). Beide sind auf 0.5.3.2, letzterer allerdings auf experimental.
vg
Hoi,
Ja ich hab ungefair 30 router mit ganz alten setup dazu gerechnet aber es sind wohl nur 2.
fastd auf Port 10000 war gestorben, neu gestartet hat er nun 2 Verbindungen.
Ich hab dir die Macs mal geschickt.
Das hat nix mit kommerziell zutuhen. Ich fände es nur doof wenn wir ohne Vorwarnung und Blog Artikel einfach Router Kicken aber wenn die Mehrheit das so will ich doch alles in Ordnung.
Was die 66 Router betrifft - klar, da bin ich vollkommen bei dir. Aber eigentlich müssten sich die restlichen 0.5.5.4er mit Autoupdate ja auch allmählich mal updaten.-- xmpp bjo@schafweide.org
Am 10.06.2015 um 20:12 schrieb Bjoern Franke:
Hoi,
Ja ich hab ungefair 30 router mit ganz alten setup dazu gerechnet aber es sind wohl nur 2.
fastd auf Port 10000 war gestorben, neu gestartet hat er nun 2 Verbindungen.
Ich hab dir die Macs mal geschickt.
Thx
Das hat nix mit kommerziell zutuhen. Ich fände es nur doof wenn wir ohne Vorwarnung und Blog Artikel einfach Router Kicken aber wenn die Mehrheit das so will ich doch alles in Ordnung.
Was die 66 Router betrifft - klar, da bin ich vollkommen bei dir. Aber eigentlich müssten sich die restlichen 0.5.5.4er mit Autoupdate ja auch allmählich mal updaten.--
Ich glaube die sind hängen geblieben. Lass und doch mal versuchen alle Router über einen Broadcast ping abstürzten zu lassen.
LG Tarek
Hi,
gleiches Problem bei dem Router hier: http://netmon.nordwest.freifunk.net/router.php?router_id=1304
Viele Grüße, Stefan
Am Mittwoch, den 10.06.2015, 18:51 +0200 schrieb Stefan:
Hi,
gleiches Problem bei dem Router hier: http://netmon.nordwest.freifunk.net/router.php?router_id=1304
Da ist kein Netzwerkinterface (br-client) und IPv6 eingetragen, da weiß Netmon nicht, wo es die Daten nehmen soll.
Ui, danke total übersehen. Der Router ist heute neu. Verhält sich das bei allen neuen so?
Am 10. Juni 2015 19:16:22 MESZ, schrieb Bjoern Franke bjo@nord-west.org:
Am Mittwoch, den 10.06.2015, 18:51 +0200 schrieb Stefan:
Hi,
gleiches Problem bei dem Router hier: http://netmon.nordwest.freifunk.net/router.php?router_id=1304
Da ist kein Netzwerkinterface (br-client) und IPv6 eingetragen, da weiß Netmon nicht, wo es die Daten nehmen soll.
-- xmpp bjo@schafweide.org
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Normal im Netmon eingetragen
Am 10. Juni 2015 19:20:57 MESZ, schrieb Bjoern Franke bjo@nord-west.org:
Am Mittwoch, den 10.06.2015, 19:17 +0200 schrieb Stefan:
Ui, danke total übersehen. Der Router ist heute neu. Verhält sich das bei allen neuen so?
Wie wurde der denn eintragen? Über die ULA sollte er sich doch garnicht als neuer Router melden können.
-- xmpp bjo@schafweide.org
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Am Mittwoch, den 10.06.2015, 19:28 +0200 schrieb Stefan:
Normal im Netmon eingetragen
Dann war der da aber schon länger?
Bei der Anmeldung an Netmon wird ja die IPv6 aus https://git.nordwest.f reifunk.net/ffnw/packages/blob/master/configurator/files/configurator.c onfig genommen, die müsste man auf die ULA von 06 setzen. Eigentlich (TM) müsste man da ja auch einen Namen setzen können, wäre die Frage, ob das verhunzte dnsmasq das auflösen kann.
vg
Den haben wir eben erst angelegt :-) War ein neuer Router
Am 10. Juni 2015 19:31:49 MESZ, schrieb Bjoern Franke bjo@nord-west.org:
Am Mittwoch, den 10.06.2015, 19:28 +0200 schrieb Stefan:
Normal im Netmon eingetragen
Dann war der da aber schon länger?
Bei der Anmeldung an Netmon wird ja die IPv6 aus https://git.nordwest.f reifunk.net/ffnw/packages/blob/master/configurator/files/configurator.c onfig genommen, die müsste man auf die ULA von 06 setzen. Eigentlich (TM) müsste man da ja auch einen Namen setzen können, wäre die Frage, ob das verhunzte dnsmasq das auflösen kann.
vg
-- xmpp bjo@schafweide.org
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Hi,
gleiches Problem bei dem Router hier: http://netmon.nordwest.freifunk.net/router.php?router_id=1304
Viele Grüße, Stefan Viele Grüße, Stefan
Am Mittwoch, den 10.06.2015, 18:26 +0200 schrieb Clemens John:
Hi,
ich kann da gerade auch nur in die Glaskugel schauen aber nach den Stats zu urteilen ich würde spontan vermuten, dass da irgendwas stark überlastet ist und es dadurch zu sehr merkwürdigen Problemen kommt, die sich nicht debuggen lassen.
Wenn das Problem per Zufall auftreten würde, würde ich dem zustimmen. Nun zwar zwischenzeitlich 05, 06 und 08 down (Downgrade auf Kernel 3.16 und Batman 2014.3*), und das Problem tritt weiterhin mit denselben Routern auf.
Von daher würde ich vorschlagen, gleich mal die Batman-Devs zu kontaktieren und mit denen das zu debuggen.
Was die Supernodes betrifft, könnten wir 04 hochziehen. Desweiteren könnte man ggf. Netmon weiterhin auf 06 lassen, Web und Git von 03 auf 01 schieben und 03 dann als Supernode fahren.
vg
Hi,
ich denke wir sollten den 04 auf das neue BATMAN hochziehen und zeitnah ein Update raushauen.
Netmon kann auf 06 ruhig bleiben, läuft ja soweit.
Am 10. Juni 2015 19:00:58 MESZ, schrieb Bjoern Franke bjo@nord-west.org:
Am Mittwoch, den 10.06.2015, 18:26 +0200 schrieb Clemens John:
Hi,
ich kann da gerade auch nur in die Glaskugel schauen aber nach den Stats zu urteilen ich würde spontan vermuten, dass da irgendwas stark überlastet ist und es dadurch zu sehr merkwürdigen Problemen kommt, die sich nicht debuggen lassen.
Wenn das Problem per Zufall auftreten würde, würde ich dem zustimmen. Nun zwar zwischenzeitlich 05, 06 und 08 down (Downgrade auf Kernel 3.16 und Batman 2014.3*), und das Problem tritt weiterhin mit denselben Routern auf.
Von daher würde ich vorschlagen, gleich mal die Batman-Devs zu kontaktieren und mit denen das zu debuggen.
Was die Supernodes betrifft, könnten wir 04 hochziehen. Desweiteren könnte man ggf. Netmon weiterhin auf 06 lassen, Web und Git von 03 auf 01 schieben und 03 dann als Supernode fahren.
vg
-- xmpp bjo@schafweide.org
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Am Mittwoch, den 10.06.2015, 19:05 +0200 schrieb Stefan:
Hi,
ich denke wir sollten den 04 auf das neue BATMAN hochziehen und zeitnah ein Update raushauen.
Netmon kann auf 06 ruhig bleiben, läuft ja soweit.
Dann muss im configurator-Package allerdings die ULA von 06 eingetragen werden.
vg
Wann wollen wir das umziehen? Das sollte dann relativ zeitnah geschehen, da ja doch Probleme aktuell auftreten.
Am 10. Juni 2015 19:13:06 MESZ, schrieb Bjoern Franke bjo@nord-west.org:
Am Mittwoch, den 10.06.2015, 19:05 +0200 schrieb Stefan:
Hi,
ich denke wir sollten den 04 auf das neue BATMAN hochziehen und zeitnah ein Update raushauen.
Netmon kann auf 06 ruhig bleiben, läuft ja soweit.
Dann muss im configurator-Package allerdings die ULA von 06 eingetragen werden.
vg
xmpp bjo@schafweide.org
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Am 10.06.2015 um 19:22 schrieb Bjoern Franke:
Am Mittwoch, den 10.06.2015, 19:16 +0200 schrieb Stefan:
Wann wollen wir das umziehen? Das sollte dann relativ zeitnah geschehen, da ja doch Probleme aktuell auftreten.
Was nun wohin?
srv04 auf batman 2014.3
Ich mache schon eine 0.5.6.1 fertig.
LG Tarek
Tarek versteht mich :-P Signen könnte ich morgen vormittag :-)
Am 10. Juni 2015 19:28:04 MESZ, schrieb Jan-Tarek Butt tarek@ring0.de:
Am 10.06.2015 um 19:22 schrieb Bjoern Franke:
Am Mittwoch, den 10.06.2015, 19:16 +0200 schrieb Stefan:
Wann wollen wir das umziehen? Das sollte dann relativ zeitnah geschehen, da ja doch Probleme aktuell auftreten.
Was nun wohin?
srv04 auf batman 2014.3
Ich mache schon eine 0.5.6.1 fertig.
LG Tarek
Admin mailing list Admin@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/admin
Viele Grüße, Stefan
Am Mittwoch, den 10.06.2015, 19:28 +0200 schrieb Jan-Tarek Butt:
Am 10.06.2015 um 19:22 schrieb Bjoern Franke:
Am Mittwoch, den 10.06.2015, 19:16 +0200 schrieb Stefan:
Wann wollen wir das umziehen? Das sollte dann relativ zeitnah geschehen, da ja doch Probleme aktuell auftreten.
Was nun wohin?
srv04 auf batman 2014.3
Ich mache schon eine 0.5.6.1 fertig.
Dann ändere auch in den packages die ULA von netmon.
Am Mittwoch, den 10.06.2015, 19:49 +0200 schrieb Bjoern Franke:
Am Mittwoch, den 10.06.2015, 19:28 +0200 schrieb Jan-Tarek Butt:
Am 10.06.2015 um 19:22 schrieb Bjoern Franke:
Am Mittwoch, den 10.06.2015, 19:16 +0200 schrieb Stefan:
Wann wollen wir das umziehen? Das sollte dann relativ zeitnah geschehen, da ja doch Probleme aktuell auftreten.
Was nun wohin?
srv04 auf batman 2014.3
Ich mache schon eine 0.5.6.1 fertig.
Dann ändere auch in den packages die ULA von netmon.
Oder trag gleich netmon.ffnw ein.
root@bjo-wohnung:/tmp# ping6 netmon.ffnw PING netmon.ffnw (fd74:fdaa:9dc4::24:1): 56 data bytes 64 bytes from fd74:fdaa:9dc4::24:1: seq=0 ttl=64 time=33.129 ms 64 bytes from fd74:fdaa:9dc4::24:1: seq=1 ttl=64 time=32.239 ms ^C --- netmon.ffnw ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 32.239/32.684/33.129 ms
Am Mittwoch, den 10.06.2015, 21:50 +0200 schrieb Jan-Tarek Butt:
Was nun wohin?
srv04 auf batman 2014.3
Ich mache schon eine 0.5.6.1 fertig.
Dann ändere auch in den packages die ULA von netmon.
Oder trag gleich netmon.ffnw ein.
Done
Ja, hab ich eben auch, und ein paar Anpassungen im Configurator selbst, damit er nicht http://%5Bnetmon.ffnw%5D/ nimmt.
Von daher würde ich vorschlagen, gleich mal die Batman-Devs zu kontaktieren und mit denen das zu debuggen.
+1
Was die Supernodes betrifft, könnten wir 04 hochziehen. Desweiteren könnte man ggf. Netmon weiterhin auf 06 lassen, Web und Git von 03 auf 01 schieben und 03 dann als Supernode fahren.
Könnte man srv02 die ULA von 01 geben ? Dann könnten sich alle Geräte weiter das update ziehen und srv01 könnte ebenfalls hochgezogen werden.
LG Tarek
Hi,
zu dem Thema gibt es neue Erkenntnisse.
Der Router ist wohl online, eine DHCP bekomme ich zugewiesen. Zum Teil haben die Seiten nach 10 Minuten geladen, MTR ging auch intern durch.
Es ist wohl so, dass alles ein wenig verstopft ist.
So, next FW Pls :-)
Stefan
Am 10.06.2015 um 13:49 schrieb Bjoern Franke:
Ahoi,
manche Router machen Probleme, obwohl sie eigentlich erreichbar sein müssten.
Beispiel: FF-OS-Theater-Foyer
MAC: f8:1a:67:eb:c7:7e
LL: fe80:0:0:0:fa1a:67ff:feeb:c77e ULA: fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e
Per Batman erreichbar, Alfred-Daten kommen an.
traceroute to f8:1a:67:eb:c7:7e (fa:1e:67:eb:c7:7e), 50 hops max, 20 byte packets 1: fa:1e:67:eb:c7:7e 20.240 ms 20.102 ms 19.835 ms
Auf IP-Ebene geht aber nix.
Wer mag, kann sich die dumps im Root-Home auf srv06 anschauen oder ziehen: http://srv06.ffnw.de/theaterfail%5B1-4%5D.dump
Am Mittwoch, den 10.06.2015, 13:49 +0200 schrieb Bjoern Franke:
Ahoi,
manche Router machen Probleme, obwohl sie eigentlich erreichbar sein müssten.
Beispiel: FF-OS-Theater-Foyer
MAC: f8:1a:67:eb:c7:7e
LL: fe80:0:0:0:fa1a:67ff:feeb:c77e ULA: fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e
Per Batman erreichbar, Alfred-Daten kommen an.
traceroute to f8:1a:67:eb:c7:7e (fa:1e:67:eb:c7:7e), 50 hops max, 20 byte packets 1: fa:1e:67:eb:c7:7e 20.240 ms 20.102 ms 19.835 ms
Auf IP-Ebene geht aber nix.
Wer mag, kann sich die dumps im Root-Home auf srv06 anschauen oder ziehen: http://srv06.ffnw.de/theaterfail%5B1-4%5D.dump
Weitere Erkenntnis:
root@bjo-wohnung:~# ping6 fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e PING fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e (fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e): 56 data bytes 64 bytes from fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e: seq=0 ttl=64 time=196.575 ms 64 bytes from fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e: seq=1 ttl=64 time=72.192 ms 64 bytes from fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e: seq=2 ttl=64 time=98.699 ms 64 bytes from fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e: seq=3 ttl=64 time=106.448 ms 64 bytes from fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e: seq=5 ttl=64 time=120.734 ms 64 bytes from fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e: seq=6 ttl=64 time=106.688 ms 64 bytes from fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e: seq=10 ttl=64 time=77.952 ms ^C --- fd74:fdaa:9dc4:0:fa1a:67ff:feeb:c77e ping statistics --- 12 packets transmitted, 7 packets received, 41% packet loss round-trip min/avg/max = 72.192/111.326/196.575 ms
Von den Gateways also durchgängig nicht erreichbar, von anderen Routern im selben VPN schon.
-
Bjoern Franke -
Clemens John -
freifunk＠fr32k.de -
Jan-Tarek Butt -
Stefan -
Stefan || Freifunk Osnabrück