24h Trennung + FLI4L + Sipgate = Keine Verbindung

[fera]

Hallo,

ich hätte eine Lösung anzubieten allerdings keine "feine" sondern nur eine Nützliche.

1. Ihr legt den 24disc. so auf 4 Uhr Nachts. (da telefoniert wohl keiner )

2. Irgendein opt_ ermöglicht Zeit gesteuerte Befehle... d.h. ihr sagt dem fli4l das er um Punkt 4 Uhr Nachts neustarten soll...

Wer keine Lust auf nen opt_ hat, eine Zeit Schalt Uhr reicht auch

Sonst: In der fli4l NEWS-GROUP seit Ihr denke ich besser aufgehoben... da treiben sich nähmlich die ganzen Entwickler herrum

 

[TOM]

@fera
hättest du den ganzen tread gelesen, dann hättest du gesehen, das das problem mit der 2.1.7 gelöst ist.
da voip auch für die fli4ler noch neuland ist, ist wohl eine gemeinsame vorgehensweise newsgroup und diese forum sinnvoll, was ich als ehemaliges fli4l teammitglied auch veranlaßt habe.

 

[Kirk]

Ja kann das nur bestätigen!

Habe einen 2.1.7 ohne Probleme am laufen. Jedoch habe ich portfw für 5000-10000 udp in der Base eingestellt. Geht super. Telefon ist das BT101. Ausgepakt an den Router und los telefoniert.

 

[doQment91]

Hallo,

der zeitgesteuerte reboot ist leider nicht die Lösung mit
Fli 2.0.8.
Das Script für den reboot stirbt mit eben dem reboot
(Hab ich im Fli-forum gelesen)
Ich würde das mit der Zwangtrennung nochmal aufgreifen.
Man(n) trennt um z.B. 4.05 und verbindet wieder um 4.07.
Ob diese zeit ausreicht den Cache zu leeren?

Auch sehe ich den wechsel zur Entwicklerversion von Fli nicht immer als die glücklichmachende Lösung. Stable ist Stable = 2.0.8.

Grüßle roland

 

[bubeck]

Problemloesung fuer alle Linux-Router

Das Problem unter Linux liegt im Connection-Tracking-Modul. Es merkt nicht, dass sich die IP-Adresse aendert und kann deshalb die eingehenden Antworten nicht richtig zuordnen.

Loesung 1 (nur bis naechster Reboot):
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

Loesung 2 (dauerhaft):
Bei den meisten Linux-Distributionen in /etc/sysctl.conf

# Enable dynamic socket address rewriting on interface address change.
# This is useful for dialup interface with changing IP addresses.
net.ipv4.ip_dynaddr = 1

und mit "sysctl -p" aktivieren.

Loesung 3:
Kann man bei der Wiedereinwahl das connection-tracking modulen entladen und neu laden und damit die fehlerhaften Tabellen ruecksetzen:

rmmod ip_conntrack

was z.B. in /etc/ppp/ip-down geschehen kann.

Loesung 4:
Update auf Linux 2.6.10, wo das Problem nicht mehr auftritt.

 

[wona]

fli4l 2.0.8 24-Stunden Zwangstrennung Problemlösung

Hallo

Ich habe nun doch noch eine andere Möglichkeit als einen Reboot
oder eine Update auf 2.1.x gefunden.
Mit ist aufgefallen bzw. ich habe irgendwo gelesen, das der Sipura 1001 permanent udp-Pakete versendet.
Dadurch kann die NAT-Tabel nicht flushen. Deswegen setze ich noch das Interface für eine gewisse Zeit down.
Ich führe mit den Chronshop folgende Befehle aus:
um 4:00 Uhr trennen der DSL Verbindung
um 4:01 Herunterfahren des Interfaces zum Sipura
um 4:15 Hochfahren des Interfaces
Damit bleiben die Logfiles und die Uptime auf den Fli4l erhalten.
Auf den Sipura habe ich noch die Zeiten für das Resync geändert.

Das sieht nun wie folgt aus:
Auf den Sipura:
Unter Provisioning -
Resync Periodic: 900
Resync Error Retry Delay: 300

Auf den fli4l:
OPT_EASYCRON='yes' # EASYCRON: yes or no
EASYCRON_NOMAIL='no' # EASYCRON: yes or no - Mail von cron unterdrücken
EASYCRON_N='4' # EASYCRON: Anzahl
EASYCRON_1_CUSTOM='' # EASYCRON: eigene Einstellungen wie Umgebungsvariablen
EASYCRON_1_COMMAND='fli4lctrl hangup pppoe' # DSL-Verbindung trennen
EASYCRON_1_TIME='0 4 * * *' # EASYCRON: Zeitpunkt: min h Tag Monat Wochentag
.....
EASYCRON_3_CUSTOM='' # EASYCRON: eigene Einstellungen wie Umgebungsvariablen
EASYCRON_3_COMMAND='ifconfig -a eth0 down' # Interface eth0 down
EASYCRON_3_TIME='1 4 * * *' # EASYCRON: Zeitpunkt: min h Tag Monat Wochentag
EASYCRON_4_CUSTOM='' # EASYCRON: eigene Einstellungen wie Umgebungsvariablen
EASYCRON_4_COMMAND='ifconfig -a eth0 up' # Interfave eth0 up
EASYCRON_4_TIME='15 4 * * *' # EASYCRON: Zeitpunkt: min h Tag Monat Wochentag

Ich habe dies nun 4 Tage .... laufen ohne Probleme

Sollte dazwischen eine Abwahl erfolgen, geht das natürlich nicht. Dann müsste man wieder den Sipure vom LAN trennen oder über einen
Script das Interface down und wieder up setzten.
Die nötige Down-Zeit habe ich noch nicht ermittelt aber da ich das shuten Nachts durchführe ist es mir im Moment noch egal.

Die Problemlösung ist sicherlich auch für andere Adapter anwendbar.

Gruß Wolfgang

 

[Burmann]

Hallo, ich hab das gleiche Problem mit IPcop.
Was ich bisher heausgefunden habe ist, das die Vorschläge 1 und 2 von bubeck nicht funktioniern (/proc/sys/net/ipv4/ip_dynaddr, net.ipv4.ip_dynaddr), vorschlg 3 das tracking modul zu entladen viele Probleme mit dem wiedereinfügen der Regeln an die richtige Stelle mit sich bringt.

Bisher habe ich durch 4 minütiges dropen aller UDP-Pakete von der IP des Asterisk Servers gelöst. Jetzt habe ich die Idee gelesen /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream runter zu setzen (/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout beeinflußt das Problem nicht).

Hat jemand damit Erfahrung ?

und was/wie ist der Fehler bei fli4l 2.1.x behoben worden ? In Kernel 2.6.10 soll der fehler noch drin sein in 2.6.11.8 nicht (vgl. https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=329 )