ElabNET Technik Forum

Robert_Mini hat geschrieben: ↑Sa Feb 02, 2019 12:18 pm Gut dass zwischenzeitlich das WireGate als KNX/IP Schnittstelle übernimmt.

ja, so läuft das bei mir (leider) auch noch. Leider geht auch kein knxd/eibd Container als Ersatz, da man ja auch nicht auf andere Container zugreifen kann.

Im Moment hilft daher nur:
1) eine eigene Externe KNX IP Schnittstelle (das kann auch ein wiregate mit eibd sein...)
2) die USBtoLAN Lösung von oben um die LAN Konfig selbst anpassen zu können

Aber da das Thema ja nun doch einige mehr betrifft hoffe ich auf nun auf schnellere Lösung seitens ElabNet.

Hi zusammen,

je länger ich darüber sinniere desto unklarer wird das irgendwie für mich. Meine ETS kommt über den TW an meine KNX-Devices, er kann die Kommunikation also von einem separaten PC mal korrekt entgegennehmen. Warum gelingt das dann aus dem EDOMI-Container der seine Quell-IP im identischen Subnetz hat nicht auch? Und das mal unabhängig davon, ob die ETS gerade läuft oder nicht. Mir sind die Besonderheiten der „Tunnelthematik“ da einfach noch nicht klar.

Wer oder was ist die Instanz, die bei einem ankommenden Request von einem Kommunikationspartner, der aktuell noch keine Verbindung besitzt, dann die aktive Rolle beim Öffnen eines neuen Tunnels übernimmt? Antwortet der TW in einer speziellen Form auf den Request, die dann der Client spezifisch antworten muss? Müssen also beide Seiten ein spezielles Protokoll supporten, oder ist das nur auf Seiten des TW eine Thematik?

Also in wessen Hälfte des Spielfeldes liegt der Ball eigentlich gerade?

Hat da einer nen Überblick?

Gruß
Jens

Ich verstehe das als Konflikt von Docker auf Betriebssystem-Level selbst, so wie wenn man mit 2 Treibern auf die gleiche Hardware will.

Robert

Hallo @Robert_Mini,
das fällt mir noch schwer zu glauben. Wenn das so weit unten wäre, gäbe es an anderer Stelle, völlig ausserhalb unseres Dunstkreises hier, sicher auch massig Stress mit dem Thema. (Habe das aber nicht weiter recherchiert!)

Wie käme zudem sonst die CometVisu an den Bus? Die unteren Schichten im Dockerumfeld sind schließlich für alle identisch.
Ich vermute hier doch eher einen Implementierungsfehler bei der Umsetzung des relevanten Protokolls auf höherer Ebene.

Die EDOMI wird da sicherlich schon eine größere Menge von Devices bedienen. Daher befürchte ich, dass da evtl. auf Seiten des TW noch was unrund läuft.

Gruß
Jens

blaubaerli hat geschrieben: ↑So Feb 03, 2019 12:01 pm Die EDOMI wird da sicherlich schon eine größere Menge von Devices bedienen. Daher befürchte ich, dass da evtl. auf Seiten des TW noch was unrund läuft.

Das Problem ist ja auch bekannt und Stefan's Jungs sehen sich das demnächst an!
Robert

Dann harren wir der Dinge die da kommen.

Gruß
Jens

Hallo Jens,

blaubaerli hat geschrieben: ↑So Feb 03, 2019 10:19 amWer oder was ist die Instanz, die bei einem ankommenden Request von einem Kommunikationspartner, der aktuell noch keine Verbindung besitzt, dann die aktive Rolle beim Öffnen eines neuen Tunnels übernimmt? Antwortet der TW in einer speziellen Form auf den Request, die dann der Client spezifisch antworten muss? Müssen also beide Seiten ein spezielles Protokoll supporten, oder ist das nur auf Seiten des TW eine Thematik?

Beide Seiten müssen ein spezielles Protokoll supporten ("KNXnet/IP Tunneling").

Grob:

• Der Anbieter von Tunneln (hier der TW Server) veröffentlicht per MultiCast, dass er Tunnel zur Verfügung stellt (deshalb kann die ETS das auch anzeigen)
• Per UniCast requestet ein anfragendes Device beim Device das den Tunnel zur Verfügung (hier TWS) stellt eine solche Tunnelverbindung und die Art der Verbindung (weil es gibt neben den normalen Tunneln auch Busmonitor-Verbindungen)
• Per UniCast antwortet das Device das Tunnel zur Verfügung dann mit ACK oder NACK und dem genauen Port usw.
• Damit ist dann der Tunnel aufgebaut

blaubaerli hat geschrieben: ↑So Feb 03, 2019 10:19 amAlso in wessen Hälfte des Spielfeldes liegt der Ball eigentlich gerade?

Also mal unabhängig davon, dass ich glaube, dass es sich hier nicht um ein Problem mit dem Tunnel-Protokoll handelt, möchte ich Bescheiden anmerken, dass unser IP-Stack im Prinzip zertifiziert ist, der eibd / knxd aber nicht und auch niemals zertifizierbar sind, weil 3/4 des nöigen Codes dafür fehlen (die vielen Extras, welche verlangt werden sowie vor allem die Programmierbarkeit durch die ETS).

Das Problem sehen wir darin, dass die Unterstützung für macvlan nicht nur im Docker sondern auch auf der Schnittstelle zum Host (parent "upper device") gegeben sein müssen, damit das "Bridging" von Paketen von den verschiedenen "Hosts" auf einem Interface auch funktioniert. Insbesondere dass alle Container untereinander kommunizieren können, braucht man macvlan in der Betriebsart "macvlan bridge" und damit diese mit dem Host-System sprechen können, muss dessen Interface ebenfalls ein "macvlan subinterface (slave)" sein.

Folgende Info mag hierzu ganz hilfreich sein: Bridge vs. MacVlan


lg

Stefan

Ja das ist keinerlei KNX Tunnelproblem! viel mehr ist das ein LAN / VLAN Problem bei Einsatz von macvlan über ein und denselben physikalischen LAN port. Deswegen muss damit das funktioniert alles über dasselbe VLAN laufen und das kann man erreichen wenn man den phy. LAN eth0 auch auf VLAN umkonfiguriert. Mangels root Zugang kann das aber nur Elabnet...

Da Stefan das Grad auch gut ergänzt hat: Macvlan im bridgemodus kann man heute schon im portainer einfach konfigurieren und ich hab das auch in der EDOMI Anleitung schon ergänzt. Fehlt jetzt noch die eth0 konfig damit das alles geht.

Hallo zusammen,
ich danke euch für die vetständnissfördernden Details.

Gruß
Jens