KNX bridge offline (communication_error) since move to new Raspi4

Hi everybody,

since I moved my installation to my new Raspi 4 I cannot connect the KNX bridge anymore. I did the following:

  • Created a backup of the old configuration
  • Stopped the old installation and removed the old Raspi 2
  • Setup the new Raspi with the same static IP address as I had before
  • Installed Openhab (2.4, same version as I had before)
  • Restored the backup

It seems the whole configuration is there. Bindings are installed, items, rules, things,…

One problem I have is that my KNX bridge thing doesn’t connect anymore. I get the following error:

'knx:ip:bridge' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): server control endpoint is unresolved: 10.0.0.2 :3671

My KNX Gateway is on 10.0.0.2, I did not change anything to the KNX gateway. I can also ping the IP from my new Rapi. As said, also the Raspi itself uses the same IP as in the past, so I guess the KNX thing configuration should still work (as it worked before)

Has anyone an idea?

Thanks

Interesting, I found one problem in my knx thing configuration. I had a blank at the end of my ip address, so something like "10.0.0.2 ".

The strange thins is that I had the same config also on my old raspberry and it connected without any problems.

Ok, it is still not working, but the error has changed:

2019-07-12 19:13:51.681 [ERROR] [ip.KNXnet/IP Tunneling 10.0.0.2:3671] - establishing connection failed, timeout connecting to control endpoint /10.0.0.2:3671

I also tried to increase the timeout, no luck…
I am wondering what could cause that it worked on my old raspberry but doesn’t on my new…

Hm, took a wireshark session from both pies.

It seems that the old pie does the following to initiate the connection:

→ ConnStateReq
← ConnStateResp OK
→ Tunnel ConnectReq
← Tunnel ConnectResp

The new pi seems to directlly start with a tunnel request without a connection request before:

→ Tunnel ConnectReq
← Tunnel ConnectResp

The wireshark session shows that the ip gateway responds, but it seems the connection setup is not initiated correctly. Has anybody an idea about that?

Is there a firewall on your Pi? Try using telnet to connect to that ip address & port to see if it is reachable.
It could be a firewall or apparmor? on your Pi ( I am more familiar with RedHat that uses selinux) blocking access.

No, there should be no firewall. At least I checked iptables and it seems to be default with accept for everything.

pi@raspberrypi:~ $ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Also I would probably not see an incoming response for the “Tunnel ConnectReq”. Very strange…

Try telnet 10.0.0.2 3671 both as root & your openhab user. Note that the number after the space determines the port.
If you get an error, your server cannot reach that ip address & port with a TCP connection, for some reason.

1 Like

Thanks, will try that…

I enabled some debugging and have the output from my old installation and from the new one:

Old (working)

2019-07-13 22:25:08.935 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus
2019-07-13 22:25:08.975 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is connecting to the KNX bus
2019-07-13 22:25:08.997 [DEBUG] [binding.knx.internal.client.IPClient] - Establishing connection to KNX bus on 10.0.0.2:3671 in mode TUNNEL.
2019-07-13 22:25:09.283 [INFO ] [ip.KNXnet/IP Tunneling 10.0.0.2:3671] - establish connection from /10.0.0.7:39700 to /10.0.0.2:3671
2019-07-13 22:25:09.309 [DEBUG] [ip.KNXnet/IP Tunneling 10.0.0.2:3671] - wait for connect response from /10.0.0.2:3671 …
2019-07-13 22:25:09.381 [DEBUG] [ip.KNXnet/IP Tunneling 10.0.0.2:3671] - using server-assigned data endpoint /10.0.0.2:3671
2019-07-13 22:25:09.393 [INFO ] [ip.KNXnet/IP Tunneling 10.0.0.2:3671] - connection established (channel 1)

New (not working):

2019-07-13 21:03:51.614 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus
2019-07-13 21:03:51.618 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is connecting to the KNX bus
2019-07-13 21:03:51.620 [DEBUG] [binding.knx.internal.client.IPClient] - Establishing connection to KNX bus on 10.0.0.2:3671 in mode TUNNEL.
2019-07-13 21:03:51.623 [INFO ] [ip.KNXnet/IP Tunneling 10.0.0.2:3671] - establish connection from /10.0.0.7:34055 to /10.0.0.2:3671
2019-07-13 21:03:51.626 [DEBUG] [ip.KNXnet/IP Tunneling 10.0.0.2:3671] - wait for connect response from /10.0.0.2:3671 …
2019-07-13 21:04:01.629 [ERROR] [ip.KNXnet/IP Tunneling 10.0.0.2:3671] - establishing connection failed, timeout connecting to control endpoint /10.0.0.2:3671
2019-07-13 21:04:01.631 [DEBUG] [nx.internal.client.AbstractKNXClient] - Error connecting to the bus: timeout connecting to control endpoint /10.0.0.2:3671

You are right:

pi@raspberrypi:~ $ sudo telnet 10.0.0.2 3671
Trying 10.0.0.2…
telnet: Unable to connect to remote host: Connection refused

Ping works:

pi@raspberrypi:~ $ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=128 time=0.140 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=128 time=0.174 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=128 time=0.167 ms

I think I found the problem. I thought maybe the knx gateway detects that a different device from the same IP tries to connect and blocks this. After restarting the knx ip gateway it seems to work…

1 Like

Glad you solved it. Even though I am not familiar with that bridge, common troubleshooting sometimes helps.
I just resolved an unusual problem today where my Pi would disappear off the network. The culprit turned out to be a bad network cable not making good contact on the router end. It would not lock into the port.

Yes, thanks a lot. You definitely guided me in the right direction.

Btw, the upgrade from a Raspberry Pi 2 to a Raspberry Pi 4 increased startup time from 10min to 3min (until fully started with cpu usage dropping from 100% to < 10%). Nice…

1 Like