Keine KNX Verbindung / Problem writing individual address

[tuxedo]

Die Metrik sollte jetzt absolut egal sein. Die sollte eigentlich nur im KNX ROUTING Modus eine rolle spielen. Aber das habe ich nun umgangen, indem ich explizit beim Verbindungsaufbau das korrekte Netzwerkinterface angebe.

Beim KNX TUNNELING wird kein UDP, sondern TCP benutzt, womit das Ziel (das Interface) direkt adressiert wird. Und hier sollte es über die Routing-Tabelle eindeutig sein welches Netzwerkinterface hierfür verwendet wird (das macht das OS automatisch).

Tu mir mal den gefallen:

Alle Netzwerkschnittstellen wieder einsachalten, so dass das ganze wieder "kaputt" ist (also Metriken auch auf Originalzustand).

Und dann ein "route print" sowie ein "ipconfig /all" in der Shell ausführen und mir das Ergebnis jeweils zukommen lassen.


Aber probier bitte auch aus was ich dir per Email geraten hatte... nicht dass die Zeit die du zum abstellen der INterfaces gebraucht hast ausgereicht hat um die Verbindungen auf der KNX Schnittstelle wieder frei zu geben und das jetzt ein "zufallstreffer" war.

[hassel]

So habe dir mal route und ipconfig infos zugeschickt, jeweils in der "kaputten" auto variante und die manuelle die funktioniert

Kann dich leider beruhigen, das ist bei mir wirklich reproduzierbar. Habe sonnst nichts mehr am lauffen was eine verbindung aufbauen könnte und das MDT Interface auch schon zurückgesetzt.

auf auto stellen -> erkennung geht aber nutzung tod
manuell auf 1 --> erkennung und nutzung gehen sofort ohne murren

[tuxedo]

Ich hab da noch ne Vermutung... Vielleicht wird beim Aufbau der Verbindung zum IP Interface noch Multicast genutzt, und das geht wieder auf das falsche Netzwerkgerät?

Muss das mal debuggen.

[hassel]

ja ich glaube da hast du recht, hab vorhin mal wireshark auf mehreren interfaces lauffen lassen und da waren multikastanfragen beim start der suite auf dem ersten vom system erkannten interface. Auf der eigentlichen eth verbindung kam dann nichts raus

[tuxedo]

Hmm, Multicast wird nicht gesendet, wäre auch irgendwie unlogisch.

Aber es werden UDP Daten gesendet, an die IP der KNX IP Schnittstelle. Kannst du mal mit Wireshark o.ä. schauen ob er das auf dem richtigen Netzwerkinterface sendet (Port 3671) wenn du die Metrik auf Auto lässt?

Wenn ich mir den Code so anschaue, dann könnte es da wieder eine Lücke geben, wie es sie beim Finden der Schnittstellen gab:

Unbenannt.PNG

Erst wird gesendet, und ein paar Zeilen später wird der "receiver" gestartet der die Antwort erhalten soll.

Wenn die Schnittstelle aber zeitlich da dazwischen geantwortet hat, dann geht die Antwort verloren, weil der Receiver noch nicht bereit ist.

Das ganze müsste sich mit Wireshark nachvollziehen lassen. Erst müsste die Suite ein UDP Telegramm an die IP der KNX IP Schnittstelle senden, und dann müsste man in Wireshark eine Antwort sehen.

Wieso das mit geänderter Metrik "besser" funktioniert, kann ich mir noch nicht erklären.

[tuxedo]

Hab ein neues Ticket bei Calimero aufgemacht:

https://github.com/calimero-project/...core/issues/37

[hassel]

Diese anfrage geht auf der virtualbox schnittstelle raus


Auf der eigentlichen Ethernet schnittstelle gehen DNS anfragen an den router raus, kommt auch ne Antwort vom router. Aber keine weitere Reaktion der suite auch keine weiteren udp pakete. Also wird erstmal eine Namensauflösung durchgeführt welche schiefgeht. Und nicht direkt die ip angesprochen welche in der suite ja auch eingetragen ist.

Wenn ich jetzt nur eine der beiden virtualbox schnittstellen abschalte die "VirtualBox Host-Only Network #2" mit ip "169.254.152.163" gehts.
Wenn ich die schnittstelle an und abschalte während die suite ne verbindung hat geht auch alles.

Also sollte der von dir gefundene Fehler durchaus das Problem beheben. Hoffe ich mal.

Vielen Dank für deine ganze Mühe

[tuxedo]

Kann das Bild nicht öffnen :-(

[hassel]

oh komisch

naja da geht jeweils eine Multicast ipv4 und ipv6 LLMNR reverse DNS anfrage raus auf der virtualbox schnittstelle. Schätzungsweise von windows selbst angestoßen.
soll ich dir das ding per mail schicken?

[tuxedo]

Bild und am besten so ein Wireshark-Mitschnitt per Email. Dann kann ich es selbst mal in Wireshark anschauen.

Woher der Multicast ipv4 kommt ist mir ein Rätsel. Wenn ich den Calimero-Code anschaue, dann kommt da kein Multicast, sondern eind UDp Telegramm.

Nur damit wir vom gleichen reden: Multicast ist 224.x.x.x adressiert. Das UDP Telegramm geht an die IP des KNX Interfaces.

[tuxedo]

Mir kam noch ne Idee woran es liegen "könnte":

Ich habe ja den MDT IP Router, den neuen. Der macht Routing UND Tunneling.

Normalerweise nutze ich Routing. Wenn ich die Suche nach dem Interface aber starte, findet er das Tunneling-Interface auf einer 169.254.168.4 IP Adresse. Mein Netzwerk daheim lautet aber auf 192.168.200.x/255.255.255.0 ...

Wieso auch immer, das Tunneling-Interface hat eine IP in diesem "seltsamen" Bereich. Und wieso auch immer: Ich komm da von meinem 192.168.200.x Netzwerk auch drauf.
Da ich auf meiner Maschine keine Route in dieses Netz finden kann, muss es irgendwie von der Fritzbox stammen (denn die ist ja die letzte Routing-Instanz wenn gar nix mehr definiert ist).

So, nun zu deinem "Problem":

Du schreibst, wenn du das zweite Virtualbox-Interface abschaltest, dann klappt's auf einmal?

Ich zitiere mal aus deiner Email:

 
 Ethernet-Adapter VirtualBox Host-Only Network #2:     Verbindungsspezifisches DNS-Suffix:     Beschreibung. . . . . . . . . . . : VirtualBox NDIS 6.0 Miniport Driver    Physische Adresse . . . . . . . . : 0A-00-27-00-00-10    DHCP aktiviert. . . . . . . . . . : Ja    Autokonfiguration aktiviert . . . : Ja    Verbindungslokale IPv6-Adresse  . : fe80::a4f9:cd92:3ea2:98a3%16(Bevorzugt)     IPv4-Adresse (Auto. Konfiguration): 169.254.152.163(Bevorzugt)     Subnetzmaske  . . . . . . . . . . : 255.255.0.0    Standardgateway . . . . . . . . . :     DHCPv6-IAID . . . . . . . . . . . : 453509159    DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1B-CA-DF-DD-D4-3D-7E-B8-CE-AB    DNS-Server  . . . . . . . . . . . : fec0:0:0:ffff::1%1                                        fec0:0:0:ffff::2%1                                        fec0:0:0:ffff::3%1    NetBIOS ber TCP/IP . . . . . . . : Aktiviert

Siehe da: 169.254.152.163 mit einer 255.255.0.0 Netzmaske.

Wenn dein Tunneling-Interface nun eine IP aus diesem Bereich hat, wird wohl versucht, diese Netzwerkschnittstelle für die Verbindung zu nutzen.

ABER:

1) Deine Schnittstelle hat wohl die 192.168.188.56 und demnach in der Richtung kein Problem
2) Deiner Email von heute morgen mit dem Wireshark-Screenshots zu folge, wird versucht die IP 192.168.188.56 über "Link-local Multicast Name Resolution" "aufzulösen", was ja gar nicht notwendig ist

Punkt 1) fällt also raus. Verbleibt Punkt 2). Betrachten wir diesen mal näher:

Die Suite detektiert die Schnittstelle. Dazu sendet sie auf jedem Netzwerkinterface Telegramme raus und die Schnittstellen antworten entsprechend. D.h. in der Phase ist es völlig egal wieviele Netzwerkschnittstellen du hast.
Nach der erkennung, wird die Netzwerkschnittstelle versucht mi UDP-Telegrammen anzusprechen. Aber vorher wird - aus bisher ungeklärten Gründen - versucht die IP nochmals aufzulösen. Das ist unnötig. Denn eine IP ist eine IP und muss nicht aufgelöst werden. Was aber viel schlimmer ist, dass hier kein normaler Nameserver genutzt wird, sondern "Link-local Multicast Name Resolution". Hier wird wieder eine Multicast-Anfrage auf 225.0.0.252 raus gesendet. Und da haben wir wieder den Salat: Andere Netzwerkinterfaces schieben sich bei der Multicast-Kommunikation nach vorne, und das eigentlich Richtige Netzwerkinterface wird außen vor gelassen.

Durch das abschalten der "falschen" Netzwerkschnittstellen kann man forcieren dass die Anfrage auf der richtigen Schnittstelle raus geht.

Ich muss jetzt raus finden,

a) wieso überhaupt versucht wird die Adresse nochmals aufzulösen
b) warum das über dieses LLMNR passiert
c) wie ich das ganze umgehe

Für Beta4 wird das sicher nicht mehr reichen, denn das Release ist - oh wunder - für heute geplant. Aber vielleicht kann ich dir auch nach dem Release einen "Hotfix" anbieten. Mal schauen.

[hassel]

oh das klingt soweit gut, und sehr seltsam das das Interface 169er adressen verwendet

Das es für beta4 nicht reicht ist kein Beinbruch es geht ja, muss nur Schnittstelle abschalten oder metrik ändern. Damit kann ich erstmal leben.

[tuxedo]

Also meines nutzt eine 169er Adresse. Deines wohl nicht. Aber bei dir scheint es wohl so, als würde er - wieso auch immer - die IP nochmal auflösen wollen?!

Und irritierenderweise im "geht" Fall mit einem normalen Nameserver-Request auf UDP 53, und im "geht nicht" Fall mit LLMNR auf dem falschen Netzwerkinterface.

Ich schau gerade meinen Code durch ob ich da irgendwo die IP nochmal versuche aufzulösen (was ich nciht ganz glauben kann) und woher/warum dieses LLMNR kommt.

[tuxedo]

So, das "warum wird die AUflösung einmal so und einmal so gemacht" ist aufgeklärt:

https://newyear2006.wordpress.com/category/llmnr/

Wenn es in einem Netz einen DNS gibt, dann wird der benutzt (geht-Fall, wenn die Fritzbox mit ihrem DNS genutzt wird). Falls es aber keinen DNS auf der besagten Netzwerkschnittstelle gibt (geht-nicht-Fall), dann wird LLMNR gemacht... Danke@Windows ... :-(

Jetzt muss ich nur noch raus finden wieso überhaupt eine Namensauflösung gemacht wird. Denn wir arbeiten ja rein mit IP Adressen.

[tuxedo]

hassel
Kannst du mir mal folgende Datei zukommen lassen?

--> C:\Users\<Benutzername>\KonnektingSuite.properties ?