Couple of weeks ago I received an interesting mail. It was from a guy, I will not mention his name here, and he was wondering about some internal workings of a KNXnet/IP Interface device.
In some of my previous posts I have covered the topic of KNXnet/IP Interface device. How KNXnet/IP Interface device is configured, what kind of messages are used and how to start using KNXnet/IP interface device in some of my favorite application (for more information check the posts KNXnet/IP interface device and Using IP interface device).
Similar to any other communication over IP, KNXnet/IP protocol defines two distinct roles. On one side we have a KNXnet/IP server and on the other side we have a KNXnet/IP client.
KNXnet/IP server represents a hardware KNXnet/IP Interface device. As an example for the KNXnet/IP server we can take Gira IP Router (device ID 2167 00), or any similar device from other manufacturers.
KNXnet/IP client can communicate with the server over IP, in order to exchange messages with the KNX network. Perfect example for the KNXnet/IP client would be the ETS application.
In this post I will try to provide more in depth information regarding the Tunnelling and Routing interfaces of the KNXnet/IP interface device. And I will do it from hardware (KNXnet/IP server) point of view.
So without further introduction, let’s dive right in.
KNXnet/IP Tunnelling Interface
Tunnelling interface of the KNXnet/IP interface device is connection based. This means that the connection needs to be established between a server and a client before messages can be exchanged.
Every KNXnet/IP interface device supports a fixed number of supported tunnelling connections. This number may vary, from 1 which is usually the case with less expensive device, to 4 or 5 for more expensive device implementations.
When client connects to the server it will reserve one of the available tunnelling connections. After the connection is reserved it cannot be used by any other client. In case when all connections are reserved, and a new client tries to open a new connection, the connection will be refused by the server with appropriate indication.
Reserved connections will stay unavailable until client disconnects or until server realizes that the connection is not active anymore. In that case the server will drop the connection and make it available again.
Connection based approach of the tunnelling interface has one major advantage compared to its alternative. There is a way to check if the server is still online and that the client can communicate with it. Also tunnelling interface is more robust. Every message is confirmed when received. With this mechanism it is practically impossible for a message to get lost.
This is the reason why ETS always uses tunnelling interface of the KNXnet/IP interface device, to program any device in the KNX network.
KNXnet/IP Routing Interface
Main difference compared to the Tunnelling interface, is that the Routing interface is connection less. This means that the client doesn’t need to do anything as preparation to exchange messages with the server. Client can start sending and receiving messages immediately.
On one side this is big advantage compared to the tunnelling interface. When all tunnelling connections are occupied, routing interface can be used by the client to communicate with the KNX network. We can say that the routing interface is always available.
On the other hand there is no confirmation mechanism. This means that the sender of the message has no idea if the message is delivered. Also the sender has no idea if someone is listening for the message.
Q & A
Question: I have a situation when all tunnelling connections are reserved. I have a client which tries to connect and the connection fails. This is expected. But I have another client that can connect. How is this possible?
Answer: The response is always the same. This is just not possible. Server will never favor one client compared to another. There are a couple of possible explanations. In most cases the second client is actually using Routing interface to communicate with the server. This can be a main communication channel for that client, or a fallback if tunnelling is not possible. The other option is that the connection was freed up by the server before the second client tried to open the connection.
In any case there is no option in the KNXnet/IP specification to implement “master” client that has the power to take the connection if all of the tunnelling connections are occupied.
Question: How can I check which interface of the KNXnet/IP interface device is used to send and receive messages by the client?
Answer: In most clients there is an indication which interface is used to communicate with the IP Router. For example ETS gives clear indication regarding this.
Some of the KNXnet/IP clients don’t give clear indication about the communication interface used, but provide information about the IP Address used for communication. If IP Address is from Multicast range (224.0.0.0 – 239.255.255.255) then Routing interface is used. In other case Tunnelling interface is used.
There is another way, to be absolutely sure which interface is used to communicate with the IP interface device. There is an application called Wireshark which can be used to monitor all the traffic that goes through a certain network adapter.
You can start the Wireshark application and use the client to communicate with the KNXnet/IP Interface device. Wireshark will record all the messages which go through the network adapter. After that you can use the Wireshark tool to filter the messages, find KNXnet/IP messages and check which interface was used for communication.
I hope that this post has cleared some of the questions you had.
If you have any other questions or doubts regarding the KNXnet/IP interface device, please leave a comment and I will try to provide more detailed information.