24h Trennung + FLI4L + Sipgate = Keine Verbindung

G

Gast

Guest
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!
 

Pfeilschwanzkrebs

Neuer User
Mitglied seit
7 Jun 2004
Beiträge
40
Punkte für Reaktionen
0
Punkte
0
das hat mit portforwarding nichts zu tun. dieses problem hatte und habe ich bis heute mit meiner m0n0 Firewall. Im IPCopForum habe ich auch gelesen dass es probleme in dieser richtung gibt.
weiss wirklich niemand rat?
 

Trashcutter

Neuer User
Mitglied seit
23 Apr 2004
Beiträge
62
Punkte für Reaktionen
0
Punkte
0
Hallo,

habe das gleiche Problem mit meiner IPCop. Seit der Version 1.4 kann der VoIP Adapter sich nicht mehr verbinden, wenn eine Zwangstrennung gemacht wurde.

Bin bisher noch nicht dazu gekommen, diesen Fehler zu analysieren. Mein "Workaround" ist nun, nicht auf die Zwangstrennung zu warten, sondern per cronjob alle 24h das System neu zu starten. Es hatte nicht geholfen, wenn ich die Interfaces neu gestartet habe.

Dieses Phänomen habe ich sowohl mit meinem Cisco ATA als auch mit meinem Grandstream ATA. Liegt also definitiv an der Linux-Firewall.

Wenn ich mehr weiss, folgen weitere Infos.
 
G

Gast

Guest
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
 

Trashcutter

Neuer User
Mitglied seit
23 Apr 2004
Beiträge
62
Punkte für Reaktionen
0
Punkte
0
Mit meiner ipcop, ja. Wie gesagt inferface reset reicht nicht aus.
 
G

Gast

Guest
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
 
G

Gast

Guest
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.
Was sagt ihr dazu???

Maxe
 

Trashcutter

Neuer User
Mitglied seit
23 Apr 2004
Beiträge
62
Punkte für Reaktionen
0
Punkte
0
Hört sich plausibel an. Mail schauen, wie man da eleganter herauskommt, ohne Neutsart.
 
G

Gast

Guest
@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
 
G

Gast

Guest
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
Was meint ihr???

Maxe
 

TOM

Mitglied
Mitglied seit
31 Mai 2004
Beiträge
701
Punkte für Reaktionen
0
Punkte
0
sorry maxe war wohl etwas doof ausgedrückt. ich meinte natürlich portforwarding auf dem fli4l zum SPA (Static IP).

http://www.fli4l.de/faqengine/faq.php

Kategorie:
"portfw FAQ"
auswählen
 
G

Gast

Guest
@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
 

TOM

Mitglied
Mitglied seit
31 Mai 2004
Beiträge
701
Punkte für Reaktionen
0
Punkte
0
hi maxe,
sicher kann ich mich auch täuschen. es war nur die bitte, einen versuch zu unternehmen um die fehlereingrenzung zu erleichtern. aufgrund der angaben die du gemacht hast
...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.
...
scheint es mir, trotz deiner einwände, einen versuch wert.
 

otaku42

Admin-Team
Mitglied seit
26 Mrz 2004
Beiträge
1,670
Punkte für Reaktionen
0
Punkte
0
Spaetestens dann, wenn man die benoetigten Module rauswirft, neu laedt und neu konfiguriert sollten die alten Informationen ueber das Masquerading vergessen sein. Beim Kernel 2.4 gibts ausserdem ein Flag, in der man den Betrieb an einer "dynamischen oeffentlichen IP" konfigurieren kann, was beim beschriebenen Problem hilft - ob es das Flag auch bei 2.2 gibt, weiss ich nicht.
 
G

Gast

Guest
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
 

otaku42

Admin-Team
Mitglied seit
26 Mrz 2004
Beiträge
1,670
Punkte für Reaktionen
0
Punkte
0
Die Angabe eines DynDNS-Accounts ist keine Loesung. Meistens cachen die DNS-Server einmal getaetigte Anfragen, die Namens-Aufloesung wird nicht jedes Mal aufs Neue durchgefuehrt.

Unterstuetzt der SPA denn kein STUN?
 

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
233,180
Beiträge
2,031,027
Mitglieder
351,584
Neuestes Mitglied
rabbit19102