Skip to content
This repository has been archived by the owner on May 17, 2021. It is now read-only.

[KNX] Too much tunnel connections #5911

Open
teaserrr opened this issue Nov 9, 2019 · 5 comments
Open

[KNX] Too much tunnel connections #5911

teaserrr opened this issue Nov 9, 2019 · 5 comments

Comments

@teaserrr
Copy link

teaserrr commented Nov 9, 2019

I regularly notice that I cannot make a tunnel connection in ETS to the KNX bus anymore. I can resolve this by starting OpenHAB. After restarting, I have no problems for several weeks.

Today I had this issue again and I listed all the UDP connections:

$ sudo netstat -aunp | grep java
udp6       0      0 :::5353                 :::*                                682/java
udp6       0      0 192.168.0.180:37610     :::*                                682/java
udp6       0      0 192.168.0.180:38186     :::*                                682/java
udp6       0      0 192.168.0.180:36204     :::*                                682/java
udp6       0      0 :::1900                 :::*                                682/java
udp6       0      0 192.168.0.180:49556     :::*                                682/java
udp6       0      0 192.168.0.180:52725     :::*                                682/java

Then I restarted OpenHAB. Running the above command gave no results.
During startup, connections were created again:

$ sudo netstat -aunp | grep java
udp6       0      0 192.168.0.180:51413     :::*                                25775/java
udp6       0      0 :::5353                 :::*                                25775/java
udp6       0      0 :::1900                 :::*                                25775/java

After the KNX binding was initialized, and I started seeing loads of status telegrams in ETS group monitor (which always happens during startup), 1 more connection was created:
$ sudo netstat -aunp | grep java

udp6       0      0 192.168.0.180:51413     :::*                                25775/java
udp6       0      0 :::5353                 :::*                                25775/java
udp6       0      0 :::1900                 :::*                                25775/java
udp6       0      0 192.168.0.180:33478     :::*                                25775/java

So that's 4 UDP connections vs 7 before restart. We can assume at this point there is only 1 for KNX. My KNX IP interface has 4 tunnels, so 3 extra tunnels would mean all tunnels are occupied and any extra (e.g. ETS) cannot be established.

In the OpenHAB knx logging I sporadically see disconnects and reconnects. However sometimes it tries to reconnect multiple times in the same 100ms:

2019-11-06 10:02:00.549 [WARN ] [nx.internal.connection.KNXConnection] - KNX link has been lost (reason: server request on object tunneling link link (closed) 192.168.0.187:3671 TP1 medium, device 0.0.0, hopcount 6)
2019-11-06 10:02:00.553 [INFO ] [nx.internal.connection.KNXConnection] - KNX link will be retried in 30 seconds
2019-11-06 10:02:00.598 [WARN ] [nx.internal.connection.KNXConnection] - KNX link has been lost (reason: server request on object tunneling link link (closed) 192.168.0.187:3671 TP1 medium, device 0.0.0, hopcount 6)
2019-11-06 10:02:00.603 [INFO ] [nx.internal.connection.KNXConnection] - KNX link will be retried in 30 seconds 
...
2019-11-06 10:02:30.562 [INFO ] [nx.internal.connection.KNXConnection] - Trying to (re-)connect to KNX...
2019-11-06 10:02:30.615 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 192.168.0.187:3671 in mode TUNNEL.
2019-11-06 10:02:30.608 [INFO ] [nx.internal.connection.KNXConnection] - Trying to (re-)connect to KNX...
2019-11-06 10:02:30.646 [INFO ] [nx.internal.connection.KNXConnection] - Connected to KNX
2019-11-06 10:02:30.680 [INFO ] [nx.internal.connection.KNXConnection] - Established connection to KNX bus on 192.168.0.187:3671 in mode TUNNEL.
2019-11-06 10:02:30.697 [INFO ] [nx.internal.connection.KNXConnection] - Connected to KNX 

Could this be the cause? Or are the old tunnels somehow not released?

Your Environment

OpenHab 2.4.0 Release
binding-knx1 - 1.13.0
Running on Raspberry Pi 3
KNX IP interface: MDT SCN-IP100.02

knx.conf:

ip=192.168.0.187
ignorelocalevents=true
type=TUNNEL
localIp=192.168.0.180
autoReconnectPeriod=30
@quensen
Copy link
Contributor

quensen commented Nov 9, 2019

Did you try downgrading to org.openhab.binding.knx-1.11.0.jar?
That solved it for me so far...

@teaserrr
Copy link
Author

teaserrr commented Nov 9, 2019

Thanks for the suggestion. I've just downgraded the binding so I'll see how it works out.

@quensen
Copy link
Contributor

quensen commented Nov 18, 2019

Hi @teaserrr,

I need to withdraw my suggestion. I tried several KNX Binding releases 1.9 to 1.14 and after same runtime, I get these errors again. But these errors appeared weeks ago. They weren't there a few months ago. Strange...

Maybe, it's something server-related?
I am running OH 1.8.2 on a QNAP NAS with the most current firmware. You?

Regards,
Stefano

@teaserrr
Copy link
Author

teaserrr commented Nov 19, 2019

@SAQ1973 I'm running on an RPI 3B with Openhabian.

I havan't tried anymore since I downgraded and at the moment I can't check in ETS because I'm not on my home network and I can't access the bus over my VPN. But I can see that there are still only 4 UDP 'connections' when I log in to my RPI:

udp6       0      0 192.168.0.180:51413     :::*                                25775/java
udp6       0      0 :::5353                 :::*                                25775/java
udp6       0      0 :::1900                 :::*                                25775/java
udp6       0      0 192.168.0.180:43929     :::*                                25775/java

I also see 2 disconnects/reconnects since last time I restarted OH. In these cases there are no multiple reconnects in the same second as I originally reported. So for mee it seems solved by downgrading.

@quensen
Copy link
Contributor

quensen commented Nov 19, 2019

I noticed that my errors happened mostly (or maybe always) during the night. I will continue to monitor them.
I also reinstalled OH yesterday but keeping the configuration.
@teaserrr: Why is it udp6?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants