Kann ich 2 unterscheidliche ip über meine 1 Dyn benuzten?

[Schimmelreiter]

Ich habe ein relativ schlichtes Setup:
Als eigentlichen Internetzugang nutze ich Kabel-Internet (100 MBit/s), zusätzlich habe ich aber auch noch DSL mit 16 MBit/s, weil's das quasi gratis zum echten ISDN dazu gab.
Mein Router mit LEDE (Quasi OpenWrt in aktuell) verwaltet beide Verbindungen, die 16 MBit/s langsame Leitung dient dabei aber nur als Failover.
Die Freigaben sind dabei aber schon im Normalbetrieb dieselben.

Solange mein Server zuhause stand, habe ich auch mit beiden IPv4-Adressen aktualisiert, so daß man so (via Kabel) oder so (via DSL) auf meinen Server kam.
Dabei habe ich eben auch feststellen müssen - und inzwischen im Source-Code auch überprüft - daß oscam in dem Bezug ziemlich sch... programmiert ist und nicht wirklich wechselt.

oscam löst einen DynDNS genau ein mal auf die gewünschte Adressfamilie (IPv4 oder IPv6) auf, nur wenn keine IPv6 gefunden wird, erfolgt ebenfalls einmalig ein Rückfall bzw. eine erneute Auflösung auf IPv4.
Danach ackert es sich an dieser IP zu Tode, auch wenn diese nicht erreichbar ist, statt einfach zwischen zwei Versuchen auf die nächste IP zu wechseln.

Damit steht es aber nicht alleine da, Linux-Programmierer können es anscheinend nicht besser, busybox ist genauso schlecht programmiert und auch der CIFS-Treiber im Kernel tritt RFCs mit Füssen.

 

[pidi]

aua, das liegt doch nicht am oscam. namensauflösung passiert nicht auf applikationsebene.

 

[Schimmelreiter]

Wenn Du Dich nicht auskennst, dann sag doch einfach nix

Schau Dir den source code einfach mal an und Du wirst feststellen, daß oscam bei einem Fehlschlag nicht einfach die nächste IP nimmt, wenn der Server mehrere hat, sondern wieder neu auflöst (und dabei meistens das selbe Ergebnis erhält).
Es ist ganz simpel: Wenn oscam auflöst, dann erhält oscam eigentlich ein Array mit allen IPs, er verarbeitet aber nur das erste Element daraus weiter.
In der eigentlichen Verbindungsfunktion kennt oscam dann folglich auch nur diese eine.

Das ist ein struktureller Denkfehler bei der Programmierung:
Anstatt einfach das Array zu behalten und mit einer for-Schleife darüber zu laufen bis eine Verbindung aufgebaut wurde (und dann break) bzw. ggf. erst am Ende der Schleife zu scheitern, beschränkt es sich schon vorher und kann dann beim Verbinden gar nicht mehr anders.
Springt er beim erneuten Versuch wieder in die Funktion zur Namensauflösung, dann weiß diese ja nicht mehr, welche IP(s) er schon probiert hatte und liefert i.d.R. dieselbe.

Man kann denselben Fehler hier im busybox-Code besser sehen, weil in einer einzigen Datei gebündelt:

Du musst dich Anmelden oder Registrieren um diesen link zusehen!

Die Funktion xconnect bekommt genau eine IP-Adresse ...

Du musst dich Anmelden oder Registrieren um diesen link zusehen!

... und Du wirst feststellen, daß sie auch an keiner Stelle einfach wiederholt mit weiteren Adressen aufgerufen wird, falls die Verbindung scheitert.

Man kann das sehr schön sehen, wenn man einen ungepatchten Busybox mit aktivem "PREFER_IPV4_ADDRESS" auf einem IPv6-only-System benutzt:
busybox-wget kriegt keine Verbindung mehr hin, weil PREFER_IPV4_ADDRESS als FORCE_IPV4_ADDRESS programmiert wurde, die funktionierende IPv6 verwirft xconnect.c und beharkt die nicht erreichbare IPv4.

Wäre es sauber und ordentlich programmiert, dann hieße "PREFER_IPV4_ADDRESS" auch nur genau das, also "PREFER = bevorzugen" und er würde es zwar zuerst per IPv4 versuchen, dann aber auch IPv6 nehmen (Und ohne PREFER_IPV4_ADRESS genau umgekehrt, wie es in den RFCs vorgesehen ist).


Woran man auch sehen kann, daß Linux-"Programmierer" das eigentlich nicht für 5 Cent können ist hier:

Das ist das Ergebnis echter Profi-Programmierer:

Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Mein Windows-Rechner (fdff:affe:c0c0:0:96de:80ff:fe56:1234) hält sich an RFC 6724 und verbindet sich innerhalb des LANs bevorzugt über die ULA-Adresse.
Alle Samba-Shares aller vier Boxen sind über die ULA verbunden (Ich erspare mir das Cut'N'Paste von den drei anderen Boxen).

Nun einmal die umgekehrte Betrachtung, die Box verbindet zum Windows-Server:

Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Wie man sieht, baut das Hobby-Programmierer-Geraffel die Verbindungen rein nach dem Zufallsprinzip mal per ULA und mal per GLA auf, binnen Sekunden zum selben Server wohlgemerkt!

 

[Osprey]

Habe es auch gemerkt das sich meine ipv6 Clients nicht auf ipv4 verbinden auch wenn dieser erreichbar ist.

 

[Schimmelreiter]

Ich hätte es ja zu gerne korrigiert, aber meine Kenntnisse reichen nur zum Lesen des Codes und für sehr kleine Änderungen (Deshalb baue ich ja auch kein eigenes Betriebssystem *g*).
So wie oscam geschrieben ist, muß die Änderung simultan an mehreren Stellen erfolgen.

Die Funktion zur Namensauflösung müßte erst einmal statt nur der ersten "passenden" IP einfach alle IPs - idealerweise in einem nach RFC 6724 sortierten - Array zurückgeben.
In diesem Moment müßten aber auch alle Stellen die diese Funktion aufrufen derart angepaßt werden, daß sie ein solches Array als Rückgabewert auch akzeptieren.

Danach müßte die eigentliche Verbindungsroutine dieses Array durchlaufen. Erst wenn sie ganz durch ist und keine Verbindung hat, ist der Verbindungsversuch gescheitert.

 

[HarryHase]

schon mal die Anforderung mit Lösung im streamboard kommuniziert?

 

[Schimmelreiter]

Noch nicht dazu gekommen, meine To-Do-Liste ist länger als mein Schw....

Gesendet von meinem Siemens C25 mit Tapatalk

 

[Schimmelreiter]

Jetzt aber: h**p://

Du musst dich Anmelden oder Registrieren um diesen link zusehen!