Tunneling connection not possible if working with multiple networkinterfaces about calimero-core HOT 9 CLOSED

I asked the user to capture with wireshark to see if there is an response to the connect datagram.

I would be interested in the wshark trace for that, i.e., the case of the timeout error.

from calimero-core.

I'll try to provide this. But still takes some time. There are other important things.

from calimero-core.

I reproduced the issue. Setup:

• Win10 running in Virtualbox (sorry, don't have a native windows machine here ...)
• installed OpenVPN to get an additional network interface (did not connect it, just to have one)
• installed Virtualbox to get another additional network interface (did not use it, just to have one)

The first one is my local network interface, which is connected to my local LAN.
The 2nd and 3rd one is from OpenVPN and Virtualbox. They are not actively used. They are just "there".

Test No.1 - all network interfaces "enabled" (like in previos screenshot)
Starting my appliaction with KNX Tunneling mode. MDT IP Router used as network-interface with IP 192.168.200.71

My application tries to start the connection, but after a small timeout, it bringt ups this exception (like in 1st post of this issue:

Wireshark was running in background, started capturing BEFORE the application has been started, and stopped after the exception.
I filtered on the KNX Interface IP address:

--> I don't see any UDP connection... Just multicast traffic (coming from other KNX devices/software running in the network)

Test No. 2 - disabled all but the local LAN interface (only "Ethernet" is enabled, the others are disabled)

There's no timeout. Connection just works and I can listen to telegrams on KNX...

Wireshark started/stopped the same way as in Test No.1:

Now I can see UDP traffic.

I tried to go back to Test No. 1 and capture traffic on the other two interfaces. Maybe the software is sending on the wrong network device... But ... nothing. There are no packets at all.
So I'm a bit lost... Where is the UDP packet on Test No.1 ?!

from calimero-core.

Thank you for the traces.

• What is the local IP in both cases? Calimero logs (i think on info level) an entry "establish connection from x to y". That should help figure out the selected gateway/interface.
• How does the routing table change, specifically gateway and metric?
• I don't know in detail the win10 icons, but the red x indicates a disconnected physical medium, no? If so, that interface is probably not considered at all in the overall process.

As a preliminary observation: a tunneling connection cannot work if the request does not even get through the intended outgoing interface.

from calimero-core.

Bullet point 1+2: I will provide this information later this day/later this week.

Bullet point 3:
Indeed, it's physically and also virtually not connected at all (OpenVPN was not connected). So you're right, it's probably not considered at all.

As a preliminary observation: ...

You're absolutely right. That's why I wrote:

So I'm a bit lost... Where is the UDP packet on Test No.1 ?!

The data seems to be sent, but on which "magical/mysterious" interface?!

from calimero-core.

As there were no further updates or related issues in quite a while, I will close this as "works as designed".

from calimero-core.

@calimero-project
Sorry, I forgot about this issue, as I was not directly affected by this (but other users).
Today the issue raised again...
So please reopen.

The situation is as follows:

• Win10
• Multiple network interfaces (wireless, wired, vpn, virtualbox, ...)
• Facing exception:

de.root1.slicknx.KnxException: Error connecting to KNX: on connect to /192.168.200.7:3671
	at de.root1.slicknx.Knx.<init>(Knx.java:304)
	at de.konnekting.suite.Main.connectKnx(Main.java:258)
	at de.konnekting.suite.Main.access$100(Main.java:86)
	at de.konnekting.suite.Main$2.run(Main.java:180)
	at java.lang.Thread.run(Thread.java:748)
	at de.konnekting.suite.BackgroundTask$1.run(BackgroundTask.java:59)
Caused by: tuwien.auto.calimero.exception.KNXException: on connect to /192.168.200.7:3671
	at tuwien.auto.calimero.knxnetip.ClientConnection.connect(ClientConnection.java:173)
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.<init>(KNXnetIPTunnel.java:131)
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.<init>(KNXNetworkLinkIP.java:142)
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.<init>(KNXNetworkLinkIP.java:180)
	at de.root1.slicknx.Knx.<init>(Knx.java:298)
	... 5 more
Caused by: java.net.SocketException: Network is unreachable: Datagram send failed
	at java.net.DualStackPlainDatagramSocketImpl.socketSend(Native Method)
	at java.net.DualStackPlainDatagramSocketImpl.send(DualStackPlainDatagramSocketImpl.java:136)
	at java.net.DatagramSocket.send(DatagramSocket.java:693)
	at tuwien.auto.calimero.knxnetip.ClientConnection.connect(ClientConnection.java:158)
	... 9 more

The shown IP is the correct IP of the KNX IP INTERFACE. If I disable all network interfaces but the wireless, the connection works.

I debugged the issue and found this out:

The UDP is using a local-endpoint instead of letting the OS choose the correct local endpoint, based on the requested target IP.
InetAddress.getLocalHost() is returning the correct hostname "p1593", but not an IP of the wireless-card (192.168.200.x) but from "Hyper-V Virtual Ethernet Adapter #4", which is obviously totally wrong.

The reason for this is obviously this:

ping -4 p1593

Ping wird ausgeführt für p1593.ibsolution.local [172.26.67.161] mit 32 Bytes Daten:
Antwort von 172.26.67.161: Bytes=32 Zeit<1ms TTL=128
Antwort von 172.26.67.161: Bytes=32 Zeit=1ms TTL=128
Antwort von 172.26.67.161: Bytes=32 Zeit<1ms TTL=128
Antwort von 172.26.67.161: Bytes=32 Zeit<1ms TTL=128

So it's resolving to wrong IP. And that's why java is getting wrong IP for localhost.

BUT: Isn't there an option to NOT use an local endpoint?
What about using the "useNAT" flag in code? According to screenshot, useNAT is not used at all for this code-part. Can't this be used to control whether its using local EP or not (=letting OS decide about local EP).

br,
Alex

p.s. using core 2.3.0, have't checked if newer version has same issue.

from calimero-core.

Hmm, there's an updated version:

https://github.com/calimero-project/calimero-core/blob/master/src/tuwien/auto/calimero/knxnetip/ClientConnection.java#L158

Trying that ...

from calimero-core.

Works. Issue can stay closed.

from calimero-core.