ok, das problem war ein anderes. wenn der hoodselector losläuft, bevor namensauflösung funktioniert hängt der sich gnadenlos auf. dies hat dann erratisches Verhalten wie zB einfrierende shells zur Folge. könnt ihr ausprobieren, wenn ihr mal dafür sorgt, dass unmittelbar nach dem hochfahren, wo der router noch kein dns hat, den hoodselector manuell startet. mit einiger wahrscheinlichkeit bleibt das ding hängen. dann ne weitere ssh-session auf das ding aufmachen und zb mal ifconfig aufrufen oder batctl gwl. friert alles ein. und ein tunnel wird nie aufgebaut.
habe aber schon einen patch geschrieben, der zuerst mal testet, ob namensauflösung überhaupt funktioniert und dann erst den rest erledigt. hier mal ein pull-request. forken im gitlab ging iwie nicht wegen visibility level restricted (?) was muss ich tun, damit ich forken kann? oder ist das gar nicht vorgesehen?
-------------------------------8<-------------------------------
warn: No match for commit d3a71d8259a57bf9e476438f162f9875fc1a95d7 found at packages-lrnzo warn: Are you sure you pushed 'HEAD' there? The following changes since commit e83ccda778ec0d46444e685808eca9656ef52759:
Dont put a slash between hoodname and number! Also added appropriate dns entries to our dns server. (2016-06-02 23:59:33 +0200)
are available in the git repository at:
https://github.com/lrnzo/ffnw-packages
for you to fetch changes up to d3a71d8259a57bf9e476438f162f9875fc1a95d7:
geändert: hoodselector/luasrc/hoodselector test-name ist jetzt ffnw.de (2016-06-22 23:27:27 +0200)
---------------------------------------------------------------- Johannes Rudolph (7): hoodselctor: Cron every 2 Minutes fixes #55 hoods.json: Add Second Peer Friesland Fixes #60 hoods.json: Add Hood Butjadingen Fixes #58 hoods.json: Add Hood Wittmund Closes #59 hoods.json: Add Dinklage Fixes #57 hoods.json: Add Lohne Fixes #56 hoods.json: Reduce size of Wittmund
lrnzo (2): geändert: hoodselector/luasrc/hoodselector der hoodselector läuft nur noch los, wenn namensauflösung sicher funktioniert. Anderenfalls hängt er sich auf und es hilft nur noch reboot ... also bei mir zumindest. geändert: hoodselector/luasrc/hoodselector test-name ist jetzt ffnw.de
hoods/files/lib/ffnw/hoods/hoods.json | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- hoodselector/files/usr/lib/micron.d/hoodselector | 2 +- hoodselector/luasrc/hoodselector | 9 +++++++++ 3 files changed, 122 insertions(+), 2 deletions(-)
------------------------------->8-------------------------------
den umgang mit dem git lerne ich auch noch ...
Am 19.06.2016 um 12:24 schrieb lrnzo via Nordwest:
Hallo Leute,
manche stehen ja gelegentlich vor dem Problem, dass Router (insbesondere Offloader) an unterschiedlchen Anschlüssen nicht oder nur so halb erratisch online komme. ping 8.8.8.8 geht dann zwar aber ping google.de nicht und viele fangen dann an, im config mode dhcp und radvd abzustellen und stattdessen statische v4 configs und statische DNS-server einzutragen. Ein anderer workaround sieht so aus, dass man ip-adressen von supernodes in die cofig von fastd hardcoded. Manche sagen auch, es sei ein Vodaphoneproblem, ich habe es aber nicht nur dort beobachtet.
Das kann man sich möglicherweise alles sparen. Ich habe gerade mal versuchsweise im conigmode v6 auf WAN deaktiviert und schon läuft alles wie es soll: Namesauflösung, tunnelaufbau, hoodselector.
kann das jemand mal bei sich reproduzieren?
LG Lorenz _______________________________________________ Nordwest mailing list Nordwest@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/nordwest
jetzt bin ich gerade etwas perplex. gestern bei Thomas war das völlig eindeutig und heute kann ich den Fehler nirgendwo reproduzieren. Mich beschleichen ernsthafte Zweifel an der Richtigkeit meiner Beobachtung. hat noch irgendjemand ähnliches irgendwo (Kombination aus Hardware/Firmware/Anschluss) beobachtet oder war das alles nur ein Phantom?
Am 23.06.2016 um 02:51 schrieb lrnzo via Dev:
ok, das problem war ein anderes. wenn der hoodselector losläuft, bevor namensauflösung funktioniert hängt der sich gnadenlos auf. dies hat dann erratisches Verhalten wie zB einfrierende shells zur Folge. könnt ihr ausprobieren, wenn ihr mal dafür sorgt, dass unmittelbar nach dem hochfahren, wo der router noch kein dns hat, den hoodselector manuell startet. mit einiger wahrscheinlichkeit bleibt das ding hängen. dann ne weitere ssh-session auf das ding aufmachen und zb mal ifconfig aufrufen oder batctl gwl. friert alles ein. und ein tunnel wird nie aufgebaut.
habe aber schon einen patch geschrieben, der zuerst mal testet, ob namensauflösung überhaupt funktioniert und dann erst den rest erledigt. hier mal ein pull-request. forken im gitlab ging iwie nicht wegen visibility level restricted (?) was muss ich tun, damit ich forken kann? oder ist das gar nicht vorgesehen?
-------------------------------8<-------------------------------
warn: No match for commit d3a71d8259a57bf9e476438f162f9875fc1a95d7 found at packages-lrnzo warn: Are you sure you pushed 'HEAD' there? The following changes since commit e83ccda778ec0d46444e685808eca9656ef52759:
Dont put a slash between hoodname and number! Also added appropriate dns entries to our dns server. (2016-06-02 23:59:33 +0200)
are available in the git repository at:
https://github.com/lrnzo/ffnw-packages
for you to fetch changes up to d3a71d8259a57bf9e476438f162f9875fc1a95d7:
geändert: hoodselector/luasrc/hoodselectortest-name ist jetzt ffnw.de (2016-06-22 23:27:27 +0200)
Johannes Rudolph (7): hoodselctor: Cron every 2 Minutes fixes #55 hoods.json: Add Second Peer Friesland Fixes #60 hoods.json: Add Hood Butjadingen Fixes #58 hoods.json: Add Hood Wittmund Closes #59 hoods.json: Add Dinklage Fixes #57 hoods.json: Add Lohne Fixes #56 hoods.json: Reduce size of Wittmund
lrnzo (2): geändert: hoodselector/luasrc/hoodselector der hoodselector läuft nur noch los, wenn namensauflösung sicher funktioniert. Anderenfalls hängt er sich auf und es hilft nur noch reboot ... also bei mir zumindest. geändert: hoodselector/luasrc/hoodselector test-name ist jetzt ffnw.de
hoods/files/lib/ffnw/hoods/hoods.json | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
hoodselector/files/usr/lib/micron.d/hoodselector | 2 +- hoodselector/luasrc/hoodselector | 9 +++++++++ 3 files changed, 122 insertions(+), 2 deletions(-)
------------------------------->8-------------------------------
den umgang mit dem git lerne ich auch noch ...
Am 19.06.2016 um 12:24 schrieb lrnzo via Nordwest:
Hallo Leute,
manche stehen ja gelegentlich vor dem Problem, dass Router (insbesondere Offloader) an unterschiedlchen Anschlüssen nicht oder nur so halb erratisch online komme. ping 8.8.8.8 geht dann zwar aber ping google.de nicht und viele fangen dann an, im config mode dhcp und radvd abzustellen und stattdessen statische v4 configs und statische DNS-server einzutragen. Ein anderer workaround sieht so aus, dass man ip-adressen von supernodes in die cofig von fastd hardcoded. Manche sagen auch, es sei ein Vodaphoneproblem, ich habe es aber nicht nur dort beobachtet.
Das kann man sich möglicherweise alles sparen. Ich habe gerade mal versuchsweise im conigmode v6 auf WAN deaktiviert und schon läuft alles wie es soll: Namesauflösung, tunnelaufbau, hoodselector.
kann das jemand mal bei sich reproduzieren?
LG Lorenz _______________________________________________ Nordwest mailing list Nordwest@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/nordwest
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 06/23/16 23:48, lrnzo via Dev wrote:
jetzt bin ich gerade etwas perplex. gestern bei Thomas war das völlig eindeutig und heute kann ich den Fehler nirgendwo reproduzieren. Mich beschleichen ernsthafte Zweifel an der Richtigkeit meiner Beobachtung. hat noch irgendjemand ähnliches irgendwo (Kombination aus Hardware/Firmware/Anschluss) beobachtet oder war das alles nur ein Phantom?
Ich bin mir auch unsicher. Denn wenn die Router garkeit internet uplink haben, sondern sich nur in einer reinen lokalen mesh wolke befinden sollte was doch der von dir beschriebene zustand ohne namensauflösung entsprächen?
vg Tarek
um das zu beuteilen bin ich noch nicht tief genug im hoodselector-code drin. aber es macht ja schon einen unterschied, ob jetzt nur nacktes Internet da ist oder auch namensauflösung funktioniert ...
vielleicht tritt das problem auch nur zu (un-)bestimmten Zeiten auf, wenn $provider irgendwas an seinem netz ändert. "normale" computer ihrer Kunden wundern sich kurz und fragen einfach nochmal nach dns, unsere offloader fressen sich fest. alles nur spekulation, aber es bleibt spannend.
Am 24.06.2016 um 11:37 schrieb Jan-Tarek Butt via Dev:
On 06/23/16 23:48, lrnzo via Dev wrote:
jetzt bin ich gerade etwas perplex. gestern bei Thomas war das völlig eindeutig und heute kann ich den Fehler nirgendwo reproduzieren. Mich beschleichen ernsthafte Zweifel an der Richtigkeit meiner Beobachtung. hat noch irgendjemand ähnliches irgendwo (Kombination aus Hardware/Firmware/Anschluss) beobachtet oder war das alles nur ein Phantom?
Ich bin mir auch unsicher. Denn wenn die Router garkeit internet uplink haben, sondern sich nur in einer reinen lokalen mesh wolke befinden sollte was doch der von dir beschriebene zustand ohne namensauflösung entsprächen?
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-
Jan-Tarek Butt -
lrnzo