Benutzerdef. Dyndns - alternativer Port funktioniert nicht?!?

[ChAoS]

Hallo liebe Forengemeinde,

ich benutze seit ca. einem Jahr Dyndns im Eigenbau. Mit anderen Worten der Dyndns Server wurde von mir selber aufgesetzt im Netz und bietet bisher eine update PHP Seite über https Port 443 an.
Das funktioniert seitdem echt klasse, die Box aktualisiert bei jeder Einwahl perfekt indem sie die benutzerdef. url aufruft.

Die Url ist folgende:

[URL]https://[/URL][IP_des_DYNDNS_Servers]/dyndns.php?username=[MeinUser]&password=[MeinPasswort]&domain=test&ipaddr=<ipaddr>

die in eckigen Klammern geschriebene Werte sind statisch gesetzt.

Nun muss ich aus diversen Gründen den Port der PHP Seite ändern. z.B. von 443 auf 444.
Serverseitig war das nicht das Problem, die Seite läuft nun auf 444 und ein Aufruf mittels Browsers von

[URL]https://[/URL][IP_des_DYNDNS_Servers]:444/dyndns.php?username=[MeinUser]&password=[MeinPasswort]&domain=test&ipaddr=1.2.3.4

funktioniert problemlos. Es wird die IP 1.2.3.4 gesetzt

Trage ich den Link nun GENAU SO in der Box ein (natürlich wieder mit der Variable <ipaddr> wird nicht mehr aktualisiert und die Box meldet im Ereignisprotokoll 400 Bad request.

Wie teile ich der Box nun den korrekten Port mit?

Danke und LG
Dirk

 

[andiling]

Über die ar7.cfg sollte es gehen...

ddns {
        types {
                type = "name";
                url = "/dyndns.php?username=<username>&password=<pass>&domain=<domain>&ipaddr=<ipaddr>";
        }
        provider {
                name = "Name";
                type = "name";
                livedelay = 0w;
                touchtime = 0w;
                server = "server[COLOR="#FF0000"]:port[/COLOR]";
                infourl = "http://server/";
        } 
}

 

[ChAoS]

in der Tat merkwürdig, habe jetzt 444 und 8081 ausprobiert, einmal per benutzerdefinierte url sowie auch über die ar7.cfg wie du geschrieben hast, keins der 4 szenarien funktioniert... nur wenn ich auf den server die Seite auf 443 lege funktionierts.

Mit dem Browser manuell funktionierts sowohl bei 443, 444 als auch 8081...
Aber eigentlich gehe ich davon aus, dass die Box das können muss, da ja auch ein Template von no-ip mit einem 8xxxer port drin liegt...

Oder streubt die sich httpS über andere ports zu machen? denn bei den templates wie auch deinem Beispiel wird wonirgends http(s) angegeben (nur bei infourl - aber das ist ja nix ausschlaggebendes)

edit:
http -> S <- scheint das Problem zu sein *grrr* mit http gehts auf Anhieb

 

[andiling]

Dann hilft wohl nur eine zweite IPv4 oder IPv6 auf dem Server alternativ einen anderen DynDNS Dienst auf der Box.

 

[PeterPawn]

HTTPS ist ohnehin nur ein "Ausrutscher", der m.W. auch nur mit "custom" funktioniert. Alle bisherigen Versuche, einen zusätzlichen Provider in der ddns-Liste anzulegen, der dann auch TLS verwendet, sind bei mir fehlgeschlagen.

Daß der Client es prinzipiell beherrscht, merkt man an einem "custom"-Eintrag mit "https://..." - für die direkt hinterlegten Provider (ich füge immer zwei meiner Services direkt über die ar7.cfg hinzu und aktiviere dort auch mehrere Einträge) habe ich bisher noch keinen Weg gefunden, das irgendwie zu beeinflussen.

 

[ChAoS]

@Peter

genau, mit custom und Port 443 hat https jetzt 1 Jahr klaglos funktioniert (http hatte ich gar nicht erst auf dem Apache aktiv!). Hingegen verstellt man den Port geht es nicht mehr. Ich habe aber (leider) nicht ausprobiert, ob es denn bei "https://IP:444..." nicht doch eventuell einfach nur auf dem Port 443 landet, sprich, dass die Box durch das "s" automatisch einfach nur 443 nimmt und alles andere ignoriert... Naja, nun nutz ich 444 ohne "s" und es geht (das da verwendete Kennwort ist eh nirgends anders verwendet).... schade nur...

 

[andiling]

Vielleicht wäre das was für Dich: ssl multiplexer

In freetz gibt's ja opendd aber mit ssl funktioniert der glaube ich auch nur auf 443.

 

[sf3978]

... opendd aber mit ssl funktioniert der glaube ich auch nur auf 443.

Ja, weil "hardcodiert":

:~$ grep -E "443" opendd/*
opendd/opendd.c:        strlcpy(http_port, "443", sizeof(http_port)); /* use HTTPS */

Könnte man ja mal auf 444 ändern und probieren.