Mal etwas anderes zum Clientsocket 
Der Clientsocket funktioniert bei mir nicht mit der Angabe eines Hostnamens oder eines FQDN.
Bekomme dann nur einen Timeout.
Auf dem System ist der Name aber auflösbar (per nslookup und ping überprüft) und per IPv4 und IPv6 erreichbar.
Mit der Angabe der IP4v funktioniert der Socket.
Michael
Hat das Problem wirklich keiner 
Oder hatten wir das schon mal ?
Michael
Abend!
Ich kann nur von der Windows Version sprechen (3.40 #3774), da funktioniert es mit Hostname (mit und ohne) FQDN im ClientSocket…gerade getestet…
Grüße,
Chris
Äh… falsche Antwort oder eher falsches IPS 
Wenn schon Windows, nimm 4.0
Ist ja der Test-Bereich für die 4.0 hier.
Michael
Deswegen sagte ich > kann nur von (meiner) Windows Version sprechen
Und von IPS 4 steht hier noch nix 
ForumIP-Symcon 2.x/3.xTest Bereich (Ubuntu, RaspberryPi, Mac OSX)
Könnte man mal anpassen
Grüße,
Chris
Aber in meiner Problemstellung auch nix von Windows :rolleyes:
Und nun mal ganz ehrlich.
Das es unter 3.4 geht, ist mit klar. Immerhin ist das mein Produktivsystem.
Und ich arbeite im lokalen Netz nur mit Namen (+ eigenen DNS-Server). Das wäre schon irgendwann aufgefallen.
Und dann, wie du schon richtig bemerkt hast, ist dies der ‚Test Bereich (Ubuntu, RaspberryPi, Mac OSX)‘.
Also werde ich ja wohl eines dieser Systeme meinen, oder ?
Als ich den Thread erstellt habe gab es auch noch keine Testversion von 4.0 für Windows.
Was soll mir dein Post nun sagen ?
Außer dass es überhaupt nix mit dem eigentlichen Problem zu tun hat
Michael
So Fehler eingerenzt.
IPS 4 kann den Namen auslösen und bekommt eine IPv6 und eine IPv4 zurück.
Leider versucht IPS das Ziel nur über IPv6 zu erreichen, eine Rückfallebene auf IPv4 fehlt !
Nicht jeder Dienst auf dem Server kann IPv6 
Unter IPS 3.x wird ausschließlich IPv4 genutzt, darum fällt dass dort nicht auf.
Michael
Leider in der aktuellen Version noch immer nicht umgesetzt
Unter IPS 3.x funktioniert das wunderbar.
Nur IPS 4.0 stellt sich stur und versucht gar nicht erst per IPv4 eine Verbindung aufzubauen.
Michael
PS: Wenn Ihr tcpdumps braucht, einfach melden
Fehler im nächsten Update korrigiert. Wir nutzen wieder primär IPV4. Der UDP Socket hat dies bereits korrekt gemacht.
paresy
Primär kann er ja gerne IPv6 nutzen. Nur sekundär hat der CS ja gar nicht erst versucht
Michael
Auf jeden Fall klappt es jetzt. Das ist das wichtigste
Danke,
Michael