[gelöst] hm-rpc verbindet sich nicht

[michihorn]

So sieht es direkt nach Neustart aus.

Michael
326_6.png

[michihorn]

Hier nur mal der rpc1 der den CuxD Daemon abbildet

Michael
326_7.png

[Solear]

Hallo michi,

hat sich vielleicht deine Adapteradresse geändert?

Bei dir steht: 192.168.178.44 WIFI. Möglicherweise hast du ein LAN-Kabel angesteckt? Dann lauscht er nun vielleicht am falschen Port.

Bei meiner VM habe ich das festgestellt, dass hm-rpc nur auf den ersten lokalen Netzwerkadapter lauschen kann.

[michihorn]

Hallo danke für den Tip. ich glaube ich habe ein WLAN Problem.

Ohne das ich irgendwas gemacht habe, klappt es jetzt.

Gruß Michael

[Qlink]

Hi Leute,

ich habe jetzt leider ebenfalls dieses Problem.

Ich musste heute die IP Adresse meines iobroker Servers ändern. (IP alt: 192.168.222.9 - IP neu: 192.168.30.9)

Das habe ich wie in diesem Thread von paul53 beschrieben durchgeführt: http://forum.iobroker.net/viewtopic.php … it=IP+host

Das hat auch soweit alles geklappt.

Nur habe ich nun dassselbe Problem wie michihorn.

Mein hm-rpc3 (wired) bekommt keine Verbindung mehr... und mein raspimatic hängt sich seit der iobroker IP Umstellung auf. Teilweise kommt noch "zuviele Verbindungen" beim CCU Webinterface, meistens aber tut sich gar nix mehr und ich muss den Strom wegnehmen, damit ich wieder für kurze Zeit auf das Webinterface komme ...

Ich habe schon die Adapter mehrmals neugestartet, den ganzen Server neu gestartet, den wired adapter gelöscht und neu angelegt, leider alles ohne Erfolg.

Momentan hab ich keine Idee mehr worans noch liegen könnte.

Hier meine Config:

Beste Grüße

[Homoran]

Bevor ich mir alles ansehe:

Das erste was mir auffällt ist, dass jetzt CCU und ioBroker in zwei verschiedenen Subnetzen sind. (und das wired Interface bestimmt auch)

Ich habe keine Ahnung ob das gut geht!

Gruß

Rainer

[Qlink]

Ja, das war ja auch der Hintergrund meiner Umstellung.

Ich habe aus Sicherheitsgründen mein Netzwerk in mehrere VLANs unterteilt.

Solange keine Layer 2 Protokolle laufen, sollten die unterschiedlichen Subnetze egal sein, solange das Routing/Portforwarding stimmt…

rfd und cuxd funktionieren ja, nur h485 will nicht ...

[Solear]

Und es scheint nicht dier erste LAN-Adapter zu sein. Bei mir war es so, dass nur der erste LAN-Adapter anerkannt wird.

Ich zitiere mich mal selbst 3 Beiträge vorher:

> Bei meiner VM habe ich das festgestellt, dass hm-rpc nur auf den ersten lokalen Netzwerkadapter lauschen kann.

[Qlink]

Du meinst vermutlich den ersten LAN Adapter von dem Server auf dem iobroker läuft.

Das ist bei mir eine Windows Homeserver 2011 VM, in der nur ein Hyper-V Netzwerkadapter installiert ist.

Die Bezeichnung LAN Verbindung 3 kommt daher, weil vor langer Zeit mal mehrere Adapter installiert waren.

Ich habe diese nun nichtmehr vorhandenen Adapter entfernt. Jetzt hat der Hyper-V Netzwerkadapter den Namen LAN Verbindung.

Geändert an dem Problem hat es aber trotzdem leider nix

Hier die aktuelle Config:

[Qlink]

So, ich habe jetzt sogar den Netzwerktraffic mitgesniffert.

iobroker und die CCU sprechen blendend miteinander:

98.699428 192.168.30.9.65126 -> 192.168.222.10.2000: syn 361665474
98.699750 192.168.222.10.2000 -> 192.168.30.9.65126: syn 3876638040 ack 361665475
98.700444 192.168.30.9.65126 -> 192.168.222.10.2000: ack 3876638041
98.700609 192.168.30.9.65126 -> 192.168.222.10.2000: psh 361665475 ack 3876638041
98.700708 192.168.222.10.2000 -> 192.168.30.9.65126: ack 361665883

Somit liegts definitiv nicht an der Netzwerkseite.

Wie dem auch sei.

Ich habe jetzt die CCU ebenfalls in das 30er VLAN geschoben und schon funktioniert alles tip top.

Ich werds jedenfalls jetzt so lassen, obwohl es sicherheitstechnisch besser ginge.

Falls jedensfall jemand eine Lösung hat wie man iobroker (mit HM Wired Adapter) und die CCU in unterschiedlichen Subnetzen betreiben kann, bitte melden.

Beste Grüße

[Bluefox]

Warum ignorierst du meine Anmerkung über Subnetmaske?

Ich bin Netzwerkspezialist und glaub mir es kann die Kommunikation nicht funktionieren, wenn eine Maschine

192.168.30.9(255.255.0.0) mit der andere

192.168.222.10((255.255.255.0) versucht zu kommunizieren.

Es ist eher eine Ausnahme, dass manche Pakete durchgerutet werden.

[Qlink]

Hi Bluefox,

ich hab deine Anmerkung nicht ignoriert, sry dass ich sie nicht kommentiert habe…

Das die Geräte so nicht kommunizieren können wie du schreibst ist mir schon klar, deswegen hätte ich ja auch ein dementsprechendes Routing in meiner Firewall eingerichtet:

Wobei die Objects folgende Werte haben:

Clients(lan2) 192.168.30.254/24 - VLAN ID: 30

Server(lan2) 192.168.222.254/24 - VLAN ID: 222

Server: 192.168.222.9/32 (iobroker host)

CCU2: 192.168.222.10/32 (raspimatic)

Mit dieser Firewall Rule hätte ich testweise alle Ports aufgemacht (SERVICE ALL)um ein falsches Portforwarding ausschließen zu können und damit sollte es auch nicht notwendig sein die Subnetze sämtlicher Geräte auf 255.255.0.0 zu setzen…

Und wie mein Sniffern ja auch zeigt funktioniert die Netzwerkkommunikation zwischen iobroker und der CCU tadellos, es muss also an etwas anderem liegen ...

[Bluefox]

@Qlink:

Hi Bluefox,

ich hab deine Anmerkung nicht ignoriert, sry dass ich sie nicht kommentiert habe…

Das die Geräte so nicht kommunizieren können wie du schreibst ist mir schon klar, deswegen hätte ich ja auch ein dementsprechendes Routing in meiner Firewall eingerichtet:

policy.PNG

Wobei die Objects folgende Werte haben:

Clients(lan2) 192.168.30.254/24 - VLAN ID: 30

Server(lan2) 192.168.222.254/24 - VLAN ID: 222

Server: 192.168.222.9/32 (iobroker host)

CCU2: 192.168.222.10/32 (raspimatic)

Mit dieser Firewall Rule hätte ich testweise alle Ports aufgemacht (SERVICE ALL)um ein falsches Portforwarding ausschließen zu können und damit sollte es auch nicht notwendig sein die Subnetze sämtlicher Geräte auf 255.255.0.0 zu setzen...

Und wie mein Sniffern ja auch zeigt funktioniert die Netzwerkkommunikation zwischen iobroker und der CCU tadellos, es muss also an etwas anderem liegen ... `
Wenn du aber mit routing spielst, dann sollte auch defaultGateway oder iptables am raspi stimmen. Hast du die angepasst?

[starfish]

mir ist bei hm-rpc auch was aufgefallen, ob es sich um dasselbe Problem handelt weiss ich nicht. Irgendwas ist anders, als noch vor ein paar Wochen.

die Verbindung wird von Zeit zu Zeit gekappt und nicht wieder automatisch neu gestartet. Bei mir geht die Verbindung zu homegear auf demselben Rechner. Die Geräte lassen sich direkt über homegear aber ansprechen. Manueller restart des hm-rpc adapters startet die Kommunikation wieder.

Siehe thread: http://forum.iobroker.net/viewtopic.php?f=22&t=3765

[Qlink]

@Bluefox:

Wenn du aber mit routing spielst, dann sollte auch defaultGateway oder iptables am raspi stimmen. Hast du die angepasst? `

Natürlich hab ich auch die Gateways entsprechend angepasst…

Es hat ja wie gesagt nur der rpc wired Adapter ein Problem.

hm-rpc Funk funktioniert ohne Probleme

hm-rpc Cuxd funktioniert ohne Probleme

Beste Grüße

[Homoran]

Sind die wired Daten in der ccu denn aktuell, oder findet die ccu jetztcdas wired Gateway nicht mehr?

Gruß

Rainer

[Qlink]

In der CCU passt alles. Sie findet auch das Gateway. Hier gibt es keine Probleme.

Das Problem ist die hm-rpc wired Kommunikation (Port 2000) zwischen iobroker und CCU.

Netzwerkseitig findet eine Kommunikation statt (siehe Sniffer Auszug), aber der hm-rpc Adapter leuchtet gelb und sagt

Verbunden mit Host: wahr

Lebenszeichen: wahr

Verbunden mit hm-rpc: falsch

[Homoran]

Hast du ihn mal testweise von bin auf XML gestellt?

Gruß

Rainer

[Qlink]

jap, bringt keine Besserung …