Auflösung Dyndns bei IP-Änderung des Servers

[elNigm4]

Hi,
ich hab folgendes Problem festgestellt. Und zwar die oscam-Clients verlieren die Verbindung zum Server, falls dieser die IP, z.B. durch reconnect des DSL-Modems, ändert. Also die Dyndns-Adresse wird nicht mehr aufgelöst.
Gibt es einen Weg, dies zu erzwingen, bzw. falls ein Timeout und/oder rejected group auftritt, dies zu tun oder eventuell oscam sich selbst neustartet zu lassen (automatisch). Eventuell reicht es auch den CCCam reader neu zu initialisieren.

Ich nutze cccam protokoll über oscam bei Client sowie Server:
oscam-svn6574-sh4-amino-webif-dvb-Distribution.tar.gz auf Pingulux/Spark

LG elNigm4

 

[meister85]

[h=4]Vielleicht könnte dieser Parameter in der oscam.server helfen! Stell den mal auf 240!


reconnecttimeout[/h]

Sie müssen registriert sein, um Links zu sehen.

Parameter ist optional
Zeitspanne in Sekunden für eine Wiederverbindung im TCP, wenn Antworten ausbleiben
Beispiel

reconnecttimeout = 20 # Nach 20 Sekunden ohne Antworten, wird wiederverbunden = # [blank] default 30 Sekunden

 

[elNigm4]

Hatte ich auch durch gelesen, habs jetzt auch versucht, hilft aber nicht. IP bleibt die alte, er versucht nicht dyndns neu aufzulösen.
Ich habe ein Paar parameter durchgelesen, aber es scheint mir keinen zu geben der das Problem fixt. Vllt sollten die Oscam-Entwickler sich dem annehmen.
Falls noch jemand eine Idee hat oder das Problem gelöst hat, ich bin für jeden Tipp dankbar.

LG elNigm4

 

[werauchsonst]

Also ich weiss ja nicht aber irgendwas scheint bei dir nicht richtig zu sein. Poste mal die configs. Habe 3 Pingux davon einer im Lan. Wenn ich am Modem bastel und bekomme neue Ip, sind sofort alle wieder da. Interressant wäre noch das log der Clients oder was dann im Webif steht.

 

[aragorn]

es könnte auch ein problem mit der verwendeten unstable build sein die du verwendest. erhöh mal den debug level von oscam
oder es könnte auch schlicht ein problem mit deinem dyndns anbieter sein das der die dyndns nicht schnell genug aktualisiert beziehungsweise der verwendete dns die änderung nicht schnell genug übernimmt/mit kriegt. die dyndns wird denk ich schon aufgelöst nur zeigt diese noch auf die alte ip und das wäre dann besagtes problem von deinem anbieter oder des dns (domain name server)

 

[razorback]

Das rezept heißt

in der oscam.user
im accout den parameter
uniq = 3
setzen.

WARUM:
- der cccam listener läßt - wie auch das originale cccam - pro userid nur EINE verbindung zu.
- wenn man, wie es auch der Standard sein sollte, die DynDNS des connected users abprüft, passiert folgendes:

- der Provider disconnected und reconnected mit einer neuen IP-Adresse
- DynDNS weiß das aber noch nicht.
- OSCam auch nicht.

Der user connected also nach Zuweisung einer neuen IP-Adresse durch seinen Provider erneut zu seinem CS.
Der CS checkt über die DynDns die Gültigkeit - die geht allerdings in die Hose, da zu diesem Zeitpunkt der Update bei DynDNS noch nicht eingetragen ist.
Also: doppelter login von 2 verschiedenen IP Adressen --> abgeschossen °!

mit
uniq = 3
wird die noch vorhandene aktive session getrennt und der neue request mit der neuen IP aktiviert.

got it ?

R

 

[aragorn]

in der oscam.user
im accout den parameter
uniq = 3
setzen.

WARUM:
- der cccam listener läßt - wie auch das originale cccam - pro userid nur EINE verbindung zu.

nein das stimmt glaub ich so nicht. "uniq" wurde in letzter zeit in einem anderen thread auch schon behandelt. standard mässig ist das auf 0 genau so wie dropdups also sind unendlich viele verbindungen des gleichen users möglich.

- wenn man, wie es auch der Standard sein sollte, die DynDNS des connected users abprüft, passiert folgendes:

- der Provider disconnected und reconnected mit einer neuen IP-Adresse
- DynDNS weiß das aber noch nicht.
- OSCam auch nicht.

Der user connected also nach Zuweisung einer neuen IP-Adresse durch seinen Provider erneut zu seinem CS.
Der CS checkt über die DynDns die Gültigkeit - die geht allerdings in die Hose, da zu diesem Zeitpunkt der Update bei DynDNS noch nicht eingetragen ist.
Also: doppelter login von 2 verschiedenen IP Adressen --> abgeschossen °!

mit
uniq = 3
wird die noch vorhandene aktive session getrennt und der neue request mit der neuen IP aktiviert.

dein szenario setzt vorraus das er clients über "hostname" beschränkt. aber so wie ich seine ersten 2 sätze verstehe betrifft das problem den server auf den sich die clients nicht neu verbinden. das problem ist also nicht die dyndns der clients sondern die dyndns des servers

egal ob server oder client, die dyndns ist zunächst unabhängig des internet-service-providers. wird die verbindung getrennt und der router wählt sich neu ein muss das dyndns script (im router oder ein extra script) sich erst beim jeweiligen dyndns anbieter anmelden und dort für die dyndns-host eine neue ip hinterlegen. dieser wiederum aktualisiert diese ip in seinen dns und die wiederum updaten alle anderen dns da es mehrere gibt auch der internet-serice-provider hat eigene domain name server. deshalb kann es zum beispiel auch ein paar minuten dauern bis eine aktualisierte dyndns eines us-bürgers bei uns in deutschland "an kommt"

 

[razorback]

damit hast ja recht, jedoch ist es offenbar so, daß bei einer solchen zwangstrennung das OSCam die session NICHT verliert bzw. abbaut.

wenn der user jetzt beim reconnect nochmal daherkommt , dann sagt das OSCam am CCCam Listener, daß er schon da ist und wirft ihn ab. (auch bei uniq = 0, da das CCCam nur eine aktive Verbindung pro userid zuläßt).

Es sei denn, man verwendet uniq = 3, dann wird die bestehende alte Verbindung weggeschmissen und die neuerliche aktiviert.

R

 

[aragorn]

wenn der user jetzt beim reconnect nochmal daherkommt , dann sagt das OSCam am CCCam Listener, daß er schon da ist und wirft ihn ab. (auch bei uniq = 0, da das CCCam nur eine aktive Verbindung pro userid zuläßt).

aber es kommt doch gar nicht erst soweit das sich die clients neu verbinden!

ich hab folgendes Problem festgestellt. Und zwar die oscam-Clients verlieren die Verbindung zum Server, falls dieser die IP, z.B. durch reconnect des DSL-Modems, ändert. Also die Dyndns-Adresse wird nicht mehr aufgelöst.

wenn die clients die dyndns des servers nicht auflösen können beziehungsweise diese noch nicht auf die neue ip zeigt können sie sich gar nicht erst erneut beim server anmelden!

der oscam server hat eine zwangstrennung und wählt sich neu ein aber die dyndns zeigt noch nicht auf die neue ip. dann kann sich natürlich auch kein client neu verbinden weil die nicht auf dem server mit der neuen ip landen also hat "uniq" hierbei absolut gar keine auswirkung

Spoiler

normalerweise steht uniq auf 0 genauso wie dropdups und solange der themen ersteller diese einstellung nicht geändert hat wird eine erneute verbindung der clients nicht herrunter geschmissen. erst wenn er uniq >=2 oder uniq=1 und dropdups=1 einstellen würde verhält sich oscam so wie cccam aber wenn zum beispiel uniq=1 und dropdups=0 dann wird der client nur als duplicate markiert aber nicht getrennt!

schade das auch deine danker das immer noch nicht verstehen


elNigm4: du könntest ausprobieren bei mehreren dyndns anbietern dir eine host anzulegen um diese einzeln durch zu testen. so könntest du vielleicht herraus finden ob da einer bei ist der die domain name server schneller aktualisiert

 

[Pilot]

Hallo aragon,

muß ehrlich gestehen, das ich ich deine Ausfüfuhrungen für sehr lehrreich halte. Dabei komme ich aber nicht dahinter, was der Themen Ersteller machen muß, das sein Problem gelöst. Client logt sich ein und aus, ohne sein Ziel zu ereichen, Karten Signal zu bekommen.
Du sagst richtig: uniq =3 ist nicht die Lösung. Was ist aber dann die Lösung?

Mlg piloten

 

[aragorn]

muß ehrlich gestehen, das ich ich deine Ausfüfuhrungen für sehr lehrreich halte. Dabei komme ich aber nicht dahinter, was der Themen Ersteller machen muß, das sein Problem gelöst. Client logt sich ein und aus, ohne sein Ziel zu ereichen, Karten Signal zu bekommen.
Du sagst richtig: uniq =3 ist nicht die Lösung. Was ist aber dann die Lösung?

wie ich schon sagte eventuell einen anderen dyndns anbieter nutzen der seinen dns schneller aktualisiert. keine ahnung welchen dyndns-anbieter der themen ersteller derzeit nutzt

wie ich auch schon zwei mal sagte, der server trennt die verbindung und kriegt eine neue ip. diese neue ip muss der server bei seinem dyndns anbieter hinterlegen und der anbieter wiederum muss diese neue ip mit hilfe der domain name server für die dyndns-host hinterlegen. die dn-server aktualisieren sich dann untereinander. es könnte also eventuell auch reichen wenn die betroffenen clients einen anderen/schnelleren dns nutzen würden der diese änderung schneller mit kriegt
ich weiss aber leider nicht um was für einen internet service provider es sich dabei handelt oder welche domain name server die clients nutzen

Sie müssen registriert sein, um Links zu sehen.

Spoiler

Ständig wechselnde Einträge sind im Domain-Name-System eigentlich nicht vorgesehen. Um Netzressourcen zu sparen, sollen DNS-Einträge möglichst lange zwischengespeichert werden, mehrere Stunden oder sogar Tage. Um dennoch dynamische DNS-Einträge zu ermöglichen, kann man die maximale Speicherzeit (TTL = time to live) der DNS-Einträge stark verringern (zum Beispiel auf 60 Sekunden). Wer DynDNS verwendet, sollte testen, ob der von ihm verwendete

Sie müssen registriert sein, um Links zu sehen.

die Speicherzeit (TTL) tatsächlich korrekt wiedergibt. Unter Unix geht dies mit

Sie müssen registriert sein, um Links zu sehen.

domainname. In der Answer-Section wird dann die Speicherzeit angezeigt.
Um einen DynDNS-Eintrag in den Nameservern des Betreibers zu aktualisieren, wird üblicherweise ein DynDNS-

Sie müssen registriert sein, um Links zu sehen.

installiert. Dies ist ein Programm, das sich automatisch bei einem IP-Wechsel mit dem DynDNS-Server verbindet und die neue IP-Adresse des Rechners übermittelt. Die meisten aktuellen

Sie müssen registriert sein, um Links zu sehen.

haben einen derartigen Client bereits integriert, den man alternativ verwenden kann.
Die meisten dieser Systeme haben allerdings das Problem, dass ein

Sie müssen registriert sein, um Links zu sehen.

-Gehen des Rechners nicht bemerkt wird und deshalb die letzte IP-Adresse im DNS gespeichert bleibt.
Dieses Problem kann mit Hilfe von DynAccess (kostenpflichtig) gelöst werden, in dem ein sogenannter Heartbeat - ein Signal zum DynAccess-Server vom dem Client in periodischen Abständen, um online Status zu bestätigen, gesendet wird. Sonst setzt der DynAccess-Server die IP-Adresse auf eine Standard-Adresse zurück. So wird auch die korrekte Funktion des Backup-Mailexchangers ermöglicht.

Einige DynDNS-Anbieter bieten auch das temporäre Löschen des DNS-Eintrags an. Ein DynDNS-Client kann zum Beispiel beim Herunterfahren des Rechners die

Sie müssen registriert sein, um Links zu sehen.

des DynDNS-Eintrags löschen, sodass der DNS-Eintrag während der Offline-Zeit undefiniert ist und damit nicht auf die vorherige (mittlerweile obsolete) IP-Adresse zeigt.

Probleme

DynDNS kann jedoch eine statische IP-Adresse nicht ersetzen. Offene Netzwerkverbindungen bleiben beim Offline-Gehen oder beim Wechsel der IP-Adresse hängen und brechen nach dem

Sie müssen registriert sein, um Links zu sehen.

zusammen. Innerhalb eines Zeitraums von bis zu 60 Sekunden, in dem der alte DynDNS-Hostname zwischengespeichert wird, können keine neuen Verbindungen zu dem Host aufgebaut werden. Durch unausgereifte DynDNS-Client-Software kommt es auch gelegentlich vor, dass der DynDNS-Hostname über eine längere Zeit nicht aktualisiert wird. Dies geschieht zum Beispiel, wenn der Client nur einmal beim Einwählen den DynDNS-Hostnamen zu aktualisieren versucht, es jedoch bei Misserfolg nicht erneut versucht. Eine andere Gefahr ist, dass man beim IP-Wechsel eine Adresse zugewiesen bekommt, die vorher auf einer

Sie müssen registriert sein, um Links zu sehen.

stand – z. B. wegen Spamversands.

eventuell findet er auch einen dyndns-anbieter wo er die TTL einstellen kann. zum beispiel

Sie müssen registriert sein, um Links zu sehen.

bietet das aber nur für die bezahlenden kunden an
oder er besorgt sich einen vserver/vps auf den er seine karten shared und zusätzlich noch andere shares die seinen 24h disconnect abfedern würden

aber wie gesagt finde ich es schade das razorback für seinen verfehlten post bedankt wurde. liest hier keiner das was der themen ersteller schreibt?

 

[razorback]

Asche auf mein Haupt,

ich hab tatsächlich den falschen Baum angebellt, da die von mir geschilderten Umstände bei einigen meiner User bereits aufgetreten sind und auch mit dem von mir geposteten Rezept behoben werden konnten.

In der umgekehrten Richtung hatt ich das mit meinen Peers bisher noch überhaupt nicht.

Aragorn hat also sicher recht, daß es sich lohnen würde, mal einen anderen DynDNS Anbieter auf der Server-Seite zu suchen....

R

 

[janni1]

Muß mich jetzt auch mal kurz hier "reinhängen".
Entweder seh ich den Wald vor lauter Bäumen nicht oder es steht hier wirklich nirgendwo.
Womit gleicht den der TE eigendlich seine Dyndns-Adresse ab bzw. in welchen Abständen wird verglichen?

Gruß
janni1

 

[elNigm4]

Hi, habe eure Tipps gerade mal durch gelesen.
Am Dyndns selbst liegt es nicht, der name wird im client NICHT aufgelöst, denn über ein ping -a im cmd sieht man, dass die neue Adresse von Dyndns korrekt weitergeleitet wird.

uniq könnte ein Problem sein, dass werde ich versuchen.
Aber das wäre ein Serverseitiges Problem, ich gehe davon aus, dass es ein Client Problem ist.

Danke

 

[aragorn]

uniq betrifft den server. wenn das client-oscam aber die host nicht erneut auflöst liegts denk ich eher am client
welches oscam nutzt denn der client?
kannst du von einem client vielleicht ein log posten wo das problem auftritt?