Erstellt vor 3 Jahren

Zuletzt geändert vor 3 Jahren

#2663 reopened defect

onlinechanged-cgi and 00get-ip are not executable

Erstellt von: bjo81 Verantwortlicher:
Priorität: normal Meilenstein: freetz-next
Komponente: unknown Version: devel
Stichworte: Beobachter:
Product Id: 7320 Firmware Version: 100.06.20 rev29478 / devel-12864

Beschreibung

Hi,

I updated my 7320 yesterday and wondered why the onlinechanged-cgi commands are not executed.

So I took a further look:

root@fritz:/etc/onlinechanged# ls -al
drwxr-xr-x    2 root     root            63 Jan 15 14:35 .
drwxr-xr-x   30 root     root          1564 Jan 15 14:35 ..
-rw-r—r—    1 root     root            78 Oct 10 16:33 00-get_ip
-rw-r—r—    1 root     root           141 Oct 10 16:33 onlinechanged-cgi
-rwxrwxrwx    1 root     root           512 Dec  2 18:48 webdav_net

Änderungshistorie (21)

comment:1 Geändert vor 3 Jahren durch oliver

Perhaps these files are sourced? Then they don't need an executeable flag…

comment:2 Geändert vor 3 Jahren durch Whoopie

There's no need that they have the executable flag set as sh is run to execute the scripts, see http://freetz.org/browser/trunk/make/mod/files/root/bin/onlinechanged.sh#L70

comment:3 Geändert vor 3 Jahren durch Whoopie

In 12865:

onlinechanged-cgi: clean it up a bit (refs #2663)

comment:4 Geändert vor 3 Jahren durch Whoopie

Was zeigt eigentlich /var/log/onlinechanged.log?

comment:5 Geändert vor 3 Jahren durch Whoopie

In 12866:

onlinechanged-cgi: change script to cover "online" and "onlineipv6" status (refs #2663)

comment:6 Geändert vor 3 Jahren durch Whoopie

In 12867:

onlinechanged-cgi: change script to cover "offline" and "offlineipv6" status (refs #2663)

comment:7 Geändert vor 3 Jahren durch CarstenSchuette

Whoopie, führen deine aktuellen Änderungen jetzt nicht dazu, dass das alles doppelt ausgeführt wird? Einmal für die ipv4- und einmal für die ipv6-Verbindung?

comment:8 Geändert vor 3 Jahren durch bjo81

Das Log sagte, dass /etc/onlinechanged/onlinechanged-cgi ausgeführt wird, es passierte aber nix.
Nach der Aktivierung des onlinechanged-Replacements läufts nun.

comment:9 Geändert vor 3 Jahren durch Whoopie

CarstenSchuette, bei meinem DSL-Anschluss mit Dual-Stack steht in /var/log/onlinechanged.log nur onlineipv6. Somit denke ich, dass es nicht 2mal ausgeführt wird.

comment:10 Antwort: Geändert vor 3 Jahren durch Whoopie

@bjo81, könntest Du es nochmal ohne Replacement testen? Vorher aber Deine /tmp/flash/onlinechanged/onlinechange-cgi entweder löschen oder gemäß der Default-Datei entsprechend anpassen.

Zuletzt geändert vor 3 Jahren von Whoopie (vorher) (Diff)

comment:11 Geändert vor 3 Jahren durch CarstenSchuette

Whoope, bei mir sieht deutlich mehr im syslog:

Jan 16 21:37:31 fritz user.notice ONLINECHANGED[6611]: [onlineipv6] waiting
Jan 16 21:37:31 fritz user.notice ONLINECHANGED[6609]: [online] approved
Jan 16 21:37:31 fritz user.notice ONLINECHANGED[6609]: [online] executing /etc/onlinechanged/00-get_ip
Jan 16 21:37:31 fritz user.notice ONLINECHANGED[6609]: [online] executing /etc/onlinechanged/10-htpdate
Jan 16 21:37:32 fritz user.notice ONLINECHANGED[6609]: [online]  * Running htpdate ... done.
Jan 16 21:37:32 fritz user.notice ONLINECHANGED[6609]: [online] executing /etc/onlinechanged/onlinechanged-cgi
Jan 16 21:37:34 fritz user.notice ONLINECHANGED[6609]: [online]  * Stopping RRDstats ... done.
Jan 16 21:37:36 fritz user.notice ONLINECHANGED[6609]: [online]  * Starting RRDstats ... done.
Jan 16 21:37:37 fritz user.notice ONLINECHANGED[6609]: [online]  * rrdstats (webcfg-one) is updating inetd ... inactive.
Jan 16 21:37:37 fritz user.notice ONLINECHANGED[6609]: [online]  * rrdstats (webcfg-rrd) is updating inetd ... inactive.
Jan 16 21:37:39 fritz user.notice ONLINECHANGED[6609]: [online]  * Stopping vnstat ... done.
Jan 16 21:37:40 fritz user.notice ONLINECHANGED[6609]: [online]  * Starting vnstat ... done.
Jan 16 21:37:40 fritz user.notice ONLINECHANGED[6609]: [online]  * vnstat (webcfg-vns) is updating inetd ... inactive.
Jan 16 21:37:40 fritz user.notice ONLINECHANGED[6609]: [online] executing /etc/onlinechanged/webdav_net
Jan 16 21:37:40 fritz user.notice ONLINECHANGED[6609]: [online]  * webdav_net online status_onlinev4v6
Jan 16 21:37:41 fritz user.notice ONLINECHANGED[6609]: [online] finished
Jan 16 21:37:41 fritz user.notice ONLINECHANGED[6611]: [onlineipv6] approved
Jan 16 21:37:41 fritz user.notice ONLINECHANGED[6611]: [onlineipv6] executing /etc/onlinechanged/00-get_ip
Jan 16 21:37:41 fritz user.notice ONLINECHANGED[6611]: [onlineipv6] executing /etc/onlinechanged/10-htpdate
Jan 16 21:37:41 fritz user.notice ONLINECHANGED[6611]: [onlineipv6] executing /etc/onlinechanged/onlinechanged-cgi
Jan 16 21:37:41 fritz user.notice ONLINECHANGED[6611]: [onlineipv6] executing /etc/onlinechanged/webdav_net
Jan 16 21:37:41 fritz user.notice ONLINECHANGED[6611]: [onlineipv6]  * webdav_net onlineipv6 status_onlinev4v6
Jan 16 21:37:43 fritz user.notice ONLINECHANGED[6611]: [onlineipv6] finished

comment:12 als Antwort auf: ↑ 10 Geändert vor 3 Jahren durch bjo81

Replying to Whoopie:

Läuft nun, danke :) Wird allerdings wie bei CarstenSchuette doppelt ausgeführt.

Zuletzt geändert vor 3 Jahren von bjo81 (vorher) (Diff)

comment:13 Geändert vor 3 Jahren durch Whoopie

OK, Ihr habt recht, es wird doppelt ausgeführt. Aber nur online ist auch nicht gut, denn für IPv6-only-Verbindungen (wie z.B. bei vielen Kabelanbietern) würden die Skripte nie ausgeführt.

Was machen wir am besten?

comment:14 Antwort: Geändert vor 3 Jahren durch SaschaBr

Ich könnte mir vorstellen, dass "Setting by User" das einfachste ist, oder?

IPv4 (default)
IPv6
IPv4+IPv6

Zusätzlich könnte man eine Option "Automatik" anbieten (aber ich glaube das ist overkill): Man könnte beim Starten der Box einmalig ip4v4 und v6 laufen lassen, und für dort wo keine IP kommt, automatisch deaktivieren.

comment:15 als Antwort auf: ↑ 14 Geändert vor 3 Jahren durch PeterPawn

Replying to SaschaBr:

Zusätzlich könnte man eine Option "Automatik" anbieten (aber ich glaube das ist overkill): Man könnte beim Starten der Box einmalig ip4v4 und v6 laufen lassen, und für dort wo keine IP kommt, automatisch deaktivieren.

Für mich keine gute Idee. Das Prozess des Auswürfelns von IPv4- und IPv6-Adressen ist nach meinen Begriffen (getestet mit 7390 über LAN1) vollkommen unabhängig realisiert für beide Protokolle und ohne Kenntnis des richtigen Zeitpunkts greift so eine Automatik in die falsche Schublade.

Eine IPv6-Adresse kann relativ lange brauchen, bis die über SLAAC konfiguriert ist, wenn da kein DHCPv6-Server vorhanden ist und erst alle notwendigen Parameter über link-lokale Kommunikation zusammen gesammelt werden müssen. Bei mir kommt u.U. die IPv4-Adresse von DHCP-Server sofort, während die IPv6-Konfiguration erst nach 3 Minuten ein TO für den DHCPv6-Server resümiert und dann zu SLAAC übergeht. Da kommen dann tatsächlich "onlinechanged"-Events im Abstand von mehreren Minuten zustande.

Meiner Meinung nach bleibt tatsächlich nichts weiter übrig, als sich den Status der Abarbeitung von einmalig auszuführenden Aktionen in irgendeiner Weise zu merken (Semaphore über File in /tmp o.ä.) und dann entweder Dienste zu stoppen und neu zu starten, wenn ein Zusammenhang zu den verfügbaren externen Adressen besteht (AVM macht das ja "blind", egal ob das z.B. für den WebDAV-Client notwendig wäre oder nicht) oder für bestimmte Dienste ein Delay beim Start einzuführen (das macht AVM z.B. beim DynDNS-Client so, da gibt es ein "initial_delay", um "flapping" zu vermeiden).

Die einzige (nach meinen Erfahrungen) verläßliche Konstante ist die Angabe, welche Protokolle beim Aufruf tatsächlich noch "online" sind. Bei "echtem Dualstack" und bei IPv6-Tunnel-Protokollen, wo keine Registrierung beim Broker notwendig ist, habe ich den Eindruck, daß nur ein gemeinsames Event erzeugt wird, das aber auch nicht immer v6 oder v4 ist. Meine Interpretation war es, daß die erste gesetzte Adresse entscheidet, ob v4 oder v6 für das Event benutzt wird … das muß so nicht stimmen.

Letzten Endes kann das imho nur jedes "onlinechanged"-File selbst entscheiden, wie es in der jeweiligen Situation reagieren will. Wer wirklich "status flapping" verhindern will, sollte sich den jeweils letzten Stand der "status_*"-Angabe speichern und erst mit einiger Verzögerung die Konsequenzen aus der Änderung ziehen (zumindest dann, wenn es "online" war, denn "offline" dürfte sich immer sofort behandeln lassen, wenn man z.B. Dienste stoppt o.ä.).

Das wird sich sicherlich schwerlich in einem Template für's GUI so abbilden lassen, vielleicht ist es ja besser, das etwas ausführlicher im Template zu erläutern, welche Zustände wie signalisiert werden.

Denn eigentlich ist die Reaktion auf $1 für mich die falsche … das ist nur die Info, daß sich etwas ändert (mit etwas Glück auch was) und wie es gerade aktuell aussieht, steht eben in $2. Wenn also ein Dienst unbedingt eine IPv4-Adresse benötigt, dann kann er bei "status_onlinev4v6" oder "status_onlinev4" gestartet werden oder bleiben, ansonsten eben nicht; analog für v6. Ist ihm alles egal, entscheidet für ihn nur "status_offline" vs. "status_online*". Diese Auswertung, zusammen mit einem "Gedächtnis" für den letzten Status, macht es zwar nicht einfacher, aber sie funktioniert m.E. besser als das Schielen auf $1.

comment:16 Geändert vor 3 Jahren durch CarstenSchuette

Also, ich konnte durch die doppelte Ausführung heute keine negativen Auswirkungen feststellen.

Allerdings ist mir heute aufgefallen, dass "onlineipv6" beim Hochfahren der Box nach einem Firmware-Update rejected wurde:

Jan  1 01:01:23 fritz user.notice ONLINECHANGED[2780]: [online] sleeping
Jan 17 18:49:52 fritz user.notice FREETZMOD: Setting up onlinechanged scripting ... done.
Jan 17 18:49:53 fritz user.notice ONLINECHANGED[2852]: [onlineipv6] rejected
Jan 17 18:49:56 fritz user.notice ONLINECHANGED[2780]: [online] approved
   blabla
Jan 17 18:50:04 fritz user.notice ONLINECHANGED[2780]: [online] finished

Der onlineipv6-Event kam ca 90 Minuten später:

Jan 17 20:28:50 fritz user.notice ONLINECHANGED[24658]: [onlineipv6] approved
Jan 17 20:28:50 fritz user.notice ONLINECHANGED[24658]: [onlineipv6] executing /etc/onlinechanged/00-get_ip
Jan 17 20:28:50 fritz user.notice ONLINECHANGED[24658]: [onlineipv6] executing /etc/onlinechanged/10-htpdate
Jan 17 20:28:51 fritz user.notice ONLINECHANGED[24658]: [onlineipv6]  * Running htpdate ... done.
Jan 17 20:28:51 fritz user.notice ONLINECHANGED[24658]: [onlineipv6] executing /etc/onlinechanged/webdav_net
Jan 17 20:28:51 fritz user.notice ONLINECHANGED[24658]: [onlineipv6]  * webdav_net onlineipv6 status_onlinev4v6
Jan 17 20:28:53 fritz user.notice ONLINECHANGED[24658]: [onlineipv6] executing /tmp/flash/onlinechanged/onlinechanged-cgi
Jan 17 20:28:53 fritz user.notice ONLINECHANGED[24658]: [onlineipv6] finished
Jan 17 20:29:58 fritz user.notice ONLINECHANGED[24983]: [onlineipv6] waiting

Negative Seiteneffekte hatte ich durch das Doppelte ausführen von webdav_net und htpdate wie gesagt nicht. Wenn ich direkt auf dem WebIF "neu verbinden" klicke, sieht das anders aus, dann kommt online und onlineipv6 unmittelbar hintereinander wie oben schon mal gepostet.

Soll das so? Oder hatte mein ipv6 Tunnelprovider Bauchschmerzen und die Verbindung hat einfach ewig gedauert?

comment:17 Geändert vor 3 Jahren durch Whoopie

Ich sehe ehrlich gesagt auch nichts "Schlimmes" darin, die Befehle 2mal ausführen zu lassen. Dann ist man auf der sicheren Seite.

@CarstenSchuette: ich habe leider keine Erfahrung mit Tunnelprovidern, daher weiss ich nicht, wie lange es normalerweise dauern sollte.

comment:18 Geändert vor 3 Jahren durch Whoopie

  • Lösung auf fixed gesetzt
  • Status von new nach closed geändert

comment:19 Geändert vor 3 Jahren durch CarstenSchuette

Es gibt doch einen Seiteneffekt: Wenn bei mir der Tunnelprovider ausfällt, dann bleibt zwar die Internetverbindung aktiv, aber der offlineipv6-Event läuft und die Skripte werden mit dem "offline"-Status ausgeführt. Danach denkt die Box, dass sie ganz offline wäre. Im Log sieht das so aus (Status: ipv4+ipv6 sind verbunden, von unten nach oben lesen, ist von der AVM-WebIF-Seite):

23.01.15	02:27:52	Verbindung zum Online-Speicher beendet.
23.01.15	02:27:50	Running onlinechanged: offlineipv6
22.01.15	05:39:33	Verbindung zum Online-Speicher hergestellt.
22.01.15	05:39:28	Running onlinechanged: online

Seitdem ist ipv4 verbunden, ipv6 aber nicht, die Box denkt, sie sei offline. Klicke ich im AVM WebIF auf "neu verbinden", holt sich die Box neue ipv4- und ipv6-Daten, aber im syslog steht nur:

Jan 23 22:13:23 fritz kern.info kernel: [146140.830000] kdsld: internet: set_snd_ipaddr: 77.183.13.118
Jan 23 22:13:23 fritz user.notice ONLINECHANGED[9120]: [offlineipv6] approved
Jan 23 22:13:23 fritz user.notice ONLINECHANGED[9120]: [offlineipv6] executing /etc/onlinechanged/00-get_ip
Jan 23 22:13:23 fritz user.notice ONLINECHANGED[9120]: [offlineipv6] executing /etc/onlinechanged/10-htpdate
Jan 23 22:13:23 fritz user.notice ONLINECHANGED[9120]: [offlineipv6] executing /etc/onlinechanged/webdav_net
Jan 23 22:13:23 fritz user.notice ONLINECHANGED[9120]: [offlineipv6]  * webdav_net offlineipv6 status_offline
Jan 23 22:13:24 fritz user.notice ONLINECHANGED[9151]: [onlineipv6] waiting
Jan 23 22:13:24 fritz user.notice ONLINECHANGED[9120]: [offlineipv6] executing /tmp/flash/onlinechanged/onlinechanged-cgi
Jan 23 22:13:24 fritz user.notice ONLINECHANGED[9120]: [offlineipv6] finished
Jan 23 22:13:25 fritz user.notice ONLINECHANGED[9151]: [onlineipv6] approved
Jan 23 22:13:25 fritz user.notice ONLINECHANGED[9151]: [onlineipv6] executing /etc/onlinechanged/00-get_ip
Jan 23 22:13:25 fritz user.notice ONLINECHANGED[9151]: [onlineipv6] executing /etc/onlinechanged/10-htpdate
Jan 23 22:13:26 fritz user.info syslog: No time correction needed
Jan 23 22:13:26 fritz user.notice ONLINECHANGED[9151]: [onlineipv6]  * Running htpdate ... done.
Jan 23 22:13:26 fritz user.notice ONLINECHANGED[9151]: [onlineipv6] executing /etc/onlinechanged/webdav_net
Jan 23 22:13:26 fritz user.notice ONLINECHANGED[9151]: [onlineipv6]  * webdav_net onlineipv6 status_onlinev4v6
Jan 23 22:13:29 fritz user.notice ONLINECHANGED[9151]: [onlineipv6]  * smbd is updating inetd ... active.
Jan 23 22:13:29 fritz mark.debug syslog: davfs2 1.3.3
Jan 23 22:13:29 fritz mark.err syslog: opening /home/jpluschke/FBox/0-spezial/GU_F14_vr9/MASSENSPEICHER_TOOLS_vr9_build/webdav/../filesystem/etc/davfs2/davfs2.conf failed
Jan 23 22:13:29 fritz mark.err syslog: opening /home/jpluschke/FBox/0-spezial/GU_F14_vr9/MASSENSPEICHER_TOOLS_vr9_build/webdav/../filesystem/etc/davfs2/secrets failed
Jan 23 22:13:30 fritz user.notice ONLINECHANGED[9151]: [onlineipv6] executing /tmp/flash/onlinechanged/onlinechanged-cgi
Jan 23 22:13:30 fritz user.notice ONLINECHANGED[9151]: [onlineipv6] finished

Da fehlt mir der ipv4-Teil jetzt komplett. Die erste Zeile zeigt aber deutlich, dass der kdsld eine neue ipv4-Adresse bekommen hat.

Zuletzt geändert vor 3 Jahren von CarstenSchuette (vorher) (Diff)

comment:20 Geändert vor 3 Jahren durch CarstenSchuette

  • Lösung fixed gelöscht
  • Status von closed nach reopened geändert

comment:21 Geändert vor 3 Jahren durch PeterPawn

Das ist in etwa das, was ich versucht habe in comment 15 zu beschreiben.

Wenn Du bei der Behandlung der Events nicht auf $1 setzt (also auf das, was sich da (unter anderem) geändert hat), sondern auf $2 mit der Aufteilung in "offline" oder "online", bei "online" dann noch in "v4" und "v6" (ein bißchen Parsen, dann klappt das schon), dann weißt Du am Ende auch, wie der aktuelle Zustand tatsächlich ist. Wenn man das noch als "Übergang von→nach" braucht, muß man eben den Stand vom letzten Aufruf speichern und dann selbst ermitteln, was sich inzwischen alles geändert hat. Der multid faßt da offenbar auch schon mal zwei Ereignisse zu einem einzelnen zusammen, wenn sie zeitlich nahe beieinander liegen.

Vielleicht hilft es ja auch für alle zu einem besseren gemeinsamen Verständnis der Abläufe, wenn man erst einmal die Protokollierung von $2 im Syslog mit in das äußere onlinechanged-Skript mit aufnimmt - wobei man natürlich in comment 19 auch schon anhand der Meldungen vom WebDAV-Skript sehen kann, daß da onlineipv6 mit status_onlinev4v6 aufgerufen wird (nach vorherigem status_offline) und somit zu diesem Zeitpunkt schon beide Adressen vorhanden sind.

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.