24h Trennung + FLI4L + Sipgate = Keine Verbindung

Hallo,

ich habe folgendes Problem.

Sobald mein FLI4L Router sich zwangsweise vom DSL Netz trennen muss danach sofort wieder die Verbindung selbstständig aufbaut habe ich danach keine neue Verbindung mehr von meinem SPA-2000 zu Sipgate.

Die Reconnect zeit ahbe ich auf 60sek gemacht aber es kommt im SPA-2000 immer die Meldung "Failed".


WENN ICH ABER...

den Router komplett neu boote bekommt er sofort eine neue Verbindung ohen das ich irgendwas am SPA oder sonstigem machen muss.

Worann kann das liegen?

Danke Maxe

PS: Ich wäre auch sehr dankbar, wenn einer mal seine Daten vom FLI4L posten könnte. Wüsste gern was die für Einstellungen haben. Danke!

Gehen wir mal logisch an die Sache ran.

Wo liegt der unterschied zwischen einem neu gebootetem FLI und einem FLI der sich neu eingewählt hat?

Was verändert der FLI wärend er läuft und eventuell ne neue Verbindung aufbaut?

Das was er da macht muss man automatisch wenn er sich neu verbindet wieder zurücksetzen. Aber was ist es?!?!?!

Jetzt wo mehrere dieses Problem haben sollten wir und wirklich mal dahinterklemmen.

Also Jungs, her mit denn Ideen.

Maxe

Jepp, kann ich bestättigen.

Ich trenne die Verbindung immer mit Imonc (ist ein client Programm für den FLI).

Mit diesem manuellen Trennen simuliere ich die 24h Trennung.

Maxe

Habe gerade eine interessant Nachricht aus einer FLI Newsgroup bekommen:

Der Grund fuer dieses Problem duerfte im NAT-Timeout fuer UDP liegen.
Bzw. ganz allgemein im Tracking der Verbindungen.
Der fli4l merkt sich fuer das masq wer von wo zu wem eine Verbindung
aufgebaut hat um Antworten von extern wieder an den richtigen Rechner
leiten zu koennen.
Wenn der fli4l jetzt einen reconnect erfaehrt bleibt dieses Tracking
erhalten was ansich kein grosses Problem ist. Allerdings merkt der fli4l
sich bei diesem Tracking auch welchen Port und welche IP der fli4l
selbst genutzt hat um die Daten zu versenden.
Nach dem Reconnect sendet der fli4l nun mit seiner alten IP weiter. Und
dort ist das Problem. Das Trackning kann nicht auf einen Timeout laufen
weil von intern immer Daten kommen und es bei UDP keine Rolle spielt was
die Gegenstelle sagt. Andererseits hat der Kernel wohl ein Problem den
Welchsel der IP mit dem Tracking abzugleichen.

Zum Vergrößern anklicken....

Was sagt ihr dazu???

Maxe

@Tom: Wieso auf dem SPA? das problem liegt eindeutig im FLI4L. Man muss den FLI dazu bekommen, dass sobald er ne neue Verbindung hat, den Tracking wieder auf "null" setzt.

Ich kenne mich leider nicht so in Linux aus, aber das nuss doch möglich sein. Man frägt die Zeit ab, seit wann man neu online ist, wenn diese Zeit kleiner als 10sek ist soll der tracking auf null gesetzt werden.

Geht sowas???

Maxe

neues Zitat aus einer Newsgroup:

Ich habe bisher auch noch keinen Weg gefunden, einzelne Einträge aus der
IP_CONNTRACK zu entfernen. Hier konnte niemand helfen, und Google ergab
als einzige Möglichkeit, gefälschte RST-Pakete zu schicken. Was
natürlich bei UDP nicht funktioniert.

In Deinem Fall könnte aber helfen, beim Verbindungsabbruch (man verwende
dafür ein Skript in /etc/ppp/ip-down.* oder /ip-up.* für Neuaufbau der
Verbindung) den UDP-Timeout auf 1 Sekunde herunterzusetzen und für
einige Sekunden dort zu belassen. Wenn nicht gerade öfter als einmal pro
Sekunde auf die alte Verbindung zugegriffen wird, sollte sie damit
verschwinden.

Den Timeout stellt man ein (und liest man aus) in
/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

Zum Vergrößern anklicken....

Was meint ihr???

Maxe

@TOM: Es hat doch aber nix mit den PORTFW zutun. Das Problem liegt darin, dass der FLI trotz neuer Verbdinung weiterhin Daten mit der alten IP sendet!!!

Es muss irgendwie ein Tracking gelöscht werden, damit die Einstellungen leer sind.

Maxe

Hallo zusammen,

ich habe gerade eine interesante Sache entdeckt und zwar folgendes:

Der SPA wirft ja syslog Dateien aus die man zum Auswerten von Fehlern benutzen kann. Und dort ist mir folgendes aufgefallen:

- Der SPA weist wenn er online ist in diese syslog die Zeile auf:
Via: SIP/2.0/UDP 82.83.50.223:61000;branch=z9hG4bK-d3701a0f;rport=61000

Aber genau die selbe Zeile steht auch dort wenn er eine Zwangstrennung hnter sich hat. D.h. in meinen Augen, er versucht immernoch mit der alten IP sich zu registrieren.

Und jetzt weiter mit meiner Info, wenn ich im Webinterface von dem SPA nachsehe finde ich dort unter: Info -> System Status -> External IP sowohl vor der Zwangstrennung als auch nach der Zwangstrennung (mit wieder einwahl) die selbe IP.

Und jetzt meine Idee (wenn es wirklich daran liegen sollte das er die alte IP intern behält):

- Kann man denn keine External IP in dem SPA vergeben? Wenn ja, dann würde ich einfach meine Dynamic DNS dort eintragen (meinename.dyndns.org) und dadurch das mein Router nach jedem Login seine IP im Internet hinter dieser DynamicDNS einträgt, würde es kein Problem mehr mit der IP geben.

Kann man die External IP im SPA vergeben???

So Jungs, ich hoffe wir haben den Fehler bald.

Maxe