24h Trennung + FLI4L + Sipgate = Keine Verbindung

[Gast]

Also bei mir geht das 1A mit der Aktualisierung der IP. Wenn man die DYNDNS im SPA eingeben könnte denke ich dass das Problem weg wäre (vielleicht).
Mein router aktualisiert bei jeder neuwahl die IP Nummer, ganz sicher, ich brauche diese DynDNS auch ziemlich oft deswegen weiß ich dass es 100% geht!

STUN steht zumindest des öfteren im Webinterface, aber ich als Leihe weiß nicht was das ist. Es steht derzeit bei STUN Server: stun.sipgate.net:10000

Maxe

 

[otaku42]

Du hast mich falsch verstanden. Natuerlich aktualisiert Dein Router die IP gleich auf dem DynDNS-Server. Aber hoechstwahrscheinlich wird Dein SPA spaetestens aber der DNS-Server Deines Routers, die Anfrage einmal stellen und sich das Ergebnis dann merken. Oder anders gesagt: nicht jedes Mal, wenn Dein SPA Deinen DynDNS-Account in die aktuelle IP-Adresse umwandeln muss, wird der DynDNS-Server tatsaechlich befragt. An irgendeiner Stelle wird gecacht und das bei der ersten Anfrage erhaltene Ergebnis "gespeichert".

Du wirst also sehr wahrscheinlich feststellen, dass Dein SPA trotz aktualisiertem DynDNS-Account nicht sofort die richtige IP-Adresse verwendet.

 

[Gast]

Ein Versuche wäre es aber wert.

Aber wo kann ich die IP bzw. die DYNDNS in dem SPA eintragen????

Danke Maxe

 

[otaku42]

Da ich selbst keinen SPA habe, kann ich Dir das leider nicht beantworten. Eventuell fragst Du einfach mal im Sipura-Bereich in diesem Forum?

 

[TOM]

Hab mal zum Test einen Fli4l Router mit 2.0.8 und einen mit 2.1.7 aufgesetzt. Als ATA hab ich einen HT286 verwendet, da ich leider keine Sipura zum Testen habe.

Beim 2.0.8 tritt o.g. Problem auf (Zwangstrennung sim. mit imonc). Hab testweise auch mal portforward eingestellt, gleiches Problem. Scheint also doch am masq modul zu liegen.

Das gleiche Szenario mit der 2.1.7 funktioniert dagegen einwandfrei. Nach sim. Zwangstennung baut der HT286 die Verbindung zum Provider wieder korrekt auf.

Sofern möglich wäre ein Update auf die 2.1.7 eine Lösung, ansonsten kann evtl. die Newsgroup eine Lösung finden, da das Problem, soweit ich das kurz testen konnte, bei der 2.1.7 gefixt ist.

 

[otaku42]

2.1.7 arbeitet mit einem 2.4er-Kernel, der wie gesagt schon kernelseitig Vorkehrungen fuer den Betrieb an einer dynamischen IP hat. Soweit ich weiss, gibts dieses Feature bei Kernel 2.2.x (wie er in der 2.0.8 noch verwendet wird) nicht - entsprechend ist das da ein bisschen komplizierter.

 

[Gast]

Hallo Tom,

erstmal alles gute nachträglich zum Geburtstag. Scheinst ja nicht arg gefeiert zu haben wenn du jetzt shcon wach bist.

Und jetzt zu FLI 2.1.7. Wie hast du die Diskette angefertigt? Weil mit dem Hilfsprogramm FliwizNG geht es nicht. Der kann irgendwie nicht damit umgehen. Ist nur für 2.0.8.

Da ich sonst kein LinuxFreak bin, bin ich ohne dieses Programm ziemlich aufgeschmissen.

Wäre nett wenn du mir kurz helfen könntest.

Danke Maxe

 

[Gast]

AN ALLE MIT DEM SELBEN PROBLEM:

FLI 2.1.7 ist die Lösung. Habe es mit zwei unterschiedlichen VoIP geräten veruscht und es geht 1A mit der neuen FLI Version!!!

Viel Spass damit.

Maxe

 

[tallman0815]

Hallo,

mit Fli4l 2.1.7 funzt es jetzt, Dank an die, die nicht locker gelassen haben bei der Problemsuche. :keks:

Gleich mal eine Frage zum PORTFW, muss es nun sein oder nicht. Ich dachte dazu ist STUN da, oder wie kann man testen ob STUN funzt ?

thx talli

 

[TOM]

nee, portforward is nicht nötig, zumindest nicht in der konfig von maxe.
wenn du dir eine signatur zulegst (kannst du im profil ändern) dann hat man mehr infos und kann evtl. mehr dazu sagen.

 

[tallman0815]

Hi,

also ohne PORTFW gehts bei mir nicht ....
Kann mir jemand sagen wie ich QOS konfig. muss für VOIP ?

talli

 

[TOM]

dann solltest du für sipgate auch noch udp 10000 für stun freigeben.
eigentlich sollte es ohne funktionieren, wäre interessant wie du dein bt101 konfiguriert hast. hatte mal testweise einen ata486 über einen fli4l laufen und es funktionierte ohne weitere einstellungen.
qos hab ich mir mal angeschaut, ist sehr umfangreich. evtl mal bei der fli4l newsgroup nachfragen und vorher die doku lesen :wink:

 

[otaku42]

Wenn STUN aktiviert ist, ist Portforwarding unnoetig (bzw. kontraproduktiv). Der Grund:

STUN schickt UDP-Pakete zu einem STUN-Server, der die Daten "ausgewertet" an den Client zurueckschickt. Dadurch kann er feststellen, wie diese UDP-Pakete durch die NAT-Funktion des Routers veraendert werden. Das funktioniert aber nur, wenn alle UDP-Pakete (oder zumindest die Port Ranges, die fuer VoIP verwendet werden) auf die gleiche Weise behandelt werden. Richtet man jetzt Portforwarding ein, dann werden die weitergeleiteten Ports anders behandelt als der STUN-Port - und schon funktioniert der Spass nicht mehr.

Fazit: STUN ist gerade dazu da, die Arbeitsweise des NAT-Gateways nachzuvollziehen und sich automatisch daran anzupassen. Portforwarding ist unnoetig und sollte vermieden werden. Agiert der Router gleichzeitig als Firewall, dann muss man allerdings dafuer sorgen, dass die Pakete der VoIP-Clients aus dem Netz raus und ins Netz rein kommen koennen.

 

[tallman0815]

Agiert der Router gleichzeitig als Firewall, dann muss man allerdings dafuer sorgen, dass die Pakete der VoIP-Clients aus dem Netz raus und ins Netz rein kommen koennen.

Mein Router ist auch Firewall und ohne PFW ging garnix, oder mach ich da was falsch ?

talli

 

[otaku42]

Mein Router ist auch Firewall und ohne PFW ging garnix, oder mach ich da was falsch ?

Ist STUN aktiviert gewesen, als Du das Port Forwarding noch nicht eingerichtet hattest? Wurde die Art des NAT-Gateways korrekt erkannt?

 

[TOM]

wäre interessant deine konfig dateien anzusehen. kannst du die hier mal posten? 1. vom bt101 und 2. die fli4l konfig dateien. evtl. als pdf und vorher !passwörter raus!.

 

[tallman0815]

Hi,

STUN ist aktiviert, ob das NAT-Gateway erkannt wurde weiß ich nicht. Wie kann man das prüfen? Deshalb war ja auch meine Frage ob man STUN testen kann.

talli

 

[TOM]

wenn du im webinterface deines bt 101 schaust, dann steht dort welche nat firewall es erkannt hat

 

[tallman0815]

also bei mir sagt er "detected NAT type is symmetric NAT" ....
Wenn ich die Ports 5004-5007 aus dem PFW rausnehme kommt keine Verbindung zustande, obwohl das BT101 symmetric NAT erkennt.

 

[Blackvel]

Also das mit STUN und Port-Forwarding kann ich leider nicht bestätigen.

Die Grandstream ATA 286 Adapter haben STUN implementiert.
Trotzdem geht bei Sipgate ins Festnetz nur One-Way Audio ohne Port-Forwarding.
Und dies trotz Cisco ISDN Router + offener Firewall.

Traurig aber war.