[gelöst] hm-rpc verbindet sich nicht

[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 …