Keine commits mehr unter FHEM Code changes

[betateilchen]

Moin,

seit ungefähr einer Woche gibt es hier

https://forum.fhem.de/index.php?board=57.0

keine Aktualisierung mehr.
Ist das so gewollt oder hat das Problem schon jemand in Bearbeitung?

[Otto123]

Moin,

kann ja nur mit der Umstellung des Proxy zu tun haben. Wenn ich wüsste wie der Vorgang eigentlich funktioniert könnte ich nach dem Problem suchen. Ich mach mich mal auf die Suche, Hilfe ist aber gerne willkommen.

Der Update Prozess vom fhem update Pfad läuft ordentlich jedem Morgen 7:45 Uhr - daran ist das wohl nicht gekoppelt?
Edit: Mist das läuft doch nicht, bzw. nicht bis zu Ende?

svn: E170013: Unable to connect to a repository at URL 'https://svn.fhem.de/fhem/trunk/fhem';
svn: E000110: Error running context: Connection timed out
fhemupdate.pl END: Fri Nov 28 07:47:28 2025

@Rudi kannst Du Dir bitte den Prozess auf dem wiki Server anschauen? Der Zugriff auf den Pfad im svn funktioniert eigentlich. Sag Bescheid wenn ich da noch was am Proxy ändern muss.

Gruß Otto

[betateilchen]

Danke fürs Kümmern, es ist ja nix wirklich Weltbewegendes.

[rudolfkoenig]

@Rudi kannst Du Dir bitte den Prozess auf dem wiki Server anschauen?

Ich sehe in ~/fhemupdate/log:

svn: E170013: Unable to connect to a repository at URL 'https://svn.fhem.de/fhem/trunk/fhem';

Fuer Folgendes habe ich noch keine Erklaerung:

Code Auswählen Erweitern

> telnet svn.fhem.de 443
telnet: could not resolve svn.fhem.de/443: Temporary failure in name resolution
Exit 1
> ping svn.fhem.de
PING svn.fhem.de (188.40.131.57) 56(84) bytes of data.
64 bytes from fhem2-host (188.40.131.57): icmp_seq=1 ttl=64 time=0.371 ms
64 bytes from fhem2-host (188.40.131.57): icmp_seq=2 ttl=64 time=0.140 ms
64 bytes from fhem2-host (188.40.131.57): icmp_seq=3 ttl=64 time=0.126 ms
^C
> telnet svn.fhem.de 443
Trying 188.40.131.57...
^C


[Otto123]

ich  kann dem später mal nachgehen.

Spontan fällt mit auf, dass (vom vmhost.fhem.de)
ping -6 svn.fhem.de reagiert im 8 sekunden Takt (mit guten response zeiten)
ping -4 svn.fhem.de reagiert im sekunden Takt

[rudolfkoenig]

ping -6 svn.fhem.de reagiert im 8 sekunden Takt (mit guten response zeiten)

Hast einen komischen ping.
Bei mir macht es keinen Unterschied, beides ist 1 Sekunden Takt.

[JoWiemann]

ping -6 svn.fhem.de reagiert im 8 sekunden Takt (mit guten response zeiten)

Das muss der Ottiping, frei nach Otto Waalkes, sein. Bei mir auch indentisch zum ping -4.

Grüße Jörg

[Otto123]

naja, hab aber gesagt: ich mache das ping vom der konsole vmhost.fhem.de. Da ist das nachvollziehbar immer noch so.

Also irgendetwas ist komisch innerhalb unserer virtuellen Server Umgebung.
Auch das hier ist komisch

Code Auswählen Erweitern

okl@fhem2-wiki:~$ ping -6 svn.fhem.de
ping: svn.fhem.de: Temporary failure in name resolution
okl@fhem2-wiki:~$ ping -4 svn.fhem.de
ping: svn.fhem.de: Temporary failure in name resolution
okl@fhem2-wiki:~$ resolvectl
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp1s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.124.1
       DNS Servers: 192.168.124.1
okl@fhem2-wiki:~$ ping google.de
PING google.de (142.250.185.195) 56(84) bytes of data.
^C64 bytes from 142.250.185.195: icmp_seq=1 ttl=118 time=5.26 ms

--- google.de ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.258/5.258/5.258/0.000 ms
Insofern bin ich bei Dir Rudi: ich habe noch keine Erklärung 

[Otto123]

ich habe jetzt auf dem vmhost.fhem.de mal noch die zwei neuen virtuellen Maschinen mit interner IPv4 Adressen hinterlegt.

Jetzt sieht das alles besser aus. Rudi, kannst Du bitte nochmal testen.

[rudolfkoenig]

Jetzt sieht das alles besser aus. Rudi, kannst Du bitte nochmal testen.

Ich konnte keinen Unterschied feststellen.
Habe fhemupdate.pl nochmal gestartet, musste 2 Minuten warten, und dann kam die Fehlermeldung von oben.

[Otto123]

Das hat offenbar mit der Portumleitung (iptables) für IPv4  Port 443 zu tun.
Mit IPv6 gibt es keine Umleitung da funktioniert es, allerdings haben die meistens VMs keine IPv6 Adresse.

Wenn ich wget https://svn.fhem.de auf fhem2-wiki ausführe gibt es Fehler, wenn ich das auf fhem2-va ausführe funktioniert es.

Hat da jemand einen Tipp? Was ich ausführe:

Code Auswählen Erweitern

/sbin/iptables -t nat -I PREROUTING -p tcp -d 188.40.131.57 --dport 443 -j DNAT --to 192.168.124.63:443
 /sbin/iptables -I FORWARD -d 192.168.124.63 -p tcp --dport 443 -j ACCEPT
was daraus wird

Code Auswählen Erweitern

sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             fhem2-host           tcp dpt:https to:192.168.124.63:443
DNAT       tcp  --  anywhere             fhem2-host           tcp dpt:http to:192.168.124.63:80
Edit:
Lösung mit KI zumindest mein Test funktioniert jetzt

🛠� Lösung: Hairpin NAT aktivieren
Du musst zusätzlich eine SNAT/MASQUERADE-Regel setzen, damit interne Clients (VM2) über die öffentliche IP den Dienst in VM1 erreichen können.
Beispiel (ergänzend zu deinen Regeln):
# DNAT hast du schon:
iptables -t nat -I PREROUTING -p tcp -d 188.40.131.57 --dport 443 -j DNAT --to-destination 192.168.124.63:443
iptables -I FORWARD -d 192.168.124.63 -p tcp --dport 443 -j ACCEPT

# Jetzt Hairpin NAT hinzufügen:

Code Auswählen Erweitern

iptables -t nat -A POSTROUTING -s 192.168.124.0/24 -d 192.168.124.63 -p tcp --dport 443 -j MASQUERADE
��

✨ Wirkung
- Externe Clients: gehen wie bisher über DNAT → VM1.
- Interne Clients (VM2): wenn sie die öffentliche IP des Hosts nutzen, werden ihre Pakete durch die MASQUERADE-Regel so umgeschrieben, dass VM1 sie akzeptiert und die Antwort wieder korrekt zurückgeht.