[Fli4l_dev] chrony und VPN?==?utf-8?Q?-Tunnels starten nicht auf ?==?utf-8?Q?Ethernet-Router

[Hans Bachner]

Hallo Christoph,

>>  kann man das nicht wieder umdrehen?
>
> Nein, denn in den trunk investiere ich, was Netzwerkkonfiguration,
> Circuits,
> Firewall etc. anbetrifft, keine (Entwicklungs-)Zeit mehr, da der
> dortige
> Code ohnehin zu großen Teilen durch den Code im FFL-506-Zweig
> ersetzt werden
> wird.

Hmmm... wäre das die stable-Version, gäb's vielleicht einen Patch...

> Abgesehen davon ist der Zeitpunkt des Setzens von ip_up_events für
> den
> aktuellen trunk-Tarball absolut unerheblich, denn erst am Ende des
> Bootvorgangs wird geprüft, ob ein ip-up-Ereignis ausgelöst werden
> soll --
> und das wird nur gemacht, wenn (a) es eine Default-Route gibt und
> (b)
> ip_up_events auf "no" steht.

Wie im letzten Beitrag geschildert, ist der Zeitpunkt insofern *nicht*
unerheblich, weil der Inhalt der Variablen durch später folgende
Skripte wieder geändert werden kann. Es hilft gar nichts, ip_up_events
in rc320.route auf "no" zu setzen, wenn die Variable gleich danach in
rc340.circuits.isdn wieder auf "yes" gesetzt wird. Dass das
ip_up-Ereignis erst viel später (unter bestimmten Bedingungen)
ausgelöst wird, hat damit nichts zu tun.

Was war eigentlich der Grund, die Logik "default=yes, bei Bedarf auf no
setzen" auf "default=no, bei Bedarf auf yes setzen" umzudrehen?

Ich kann mir nicht einmal mit dem opt_usercmd behelfen, weil
rc990.usercmd erst nach rc990.base ausgeführt wird :(

> Da FFL-506 alle diese Probleme behebt bzw. beheben wird, zerbreche
> ich mir,
> ehrlich gesagt, da weniger den Kopf...

gibt es schon eine grobe Schätzung, wann der FFL-506-Zweig zum trunk
"befördert" wird, d.h. eine vergleichbare Stabilität (auch
hinsichtlich der Konfiguration) aufweisen wird?

Danke,
Hans.