I’ve written socket programs before. Your interpretation of the comment is incorrect. That log statement, said another way is “We (i.e. openHAB) will accept data coming from the computer at address 10.4.1.4 to my port 56000.”
That is how I interpret the README. I’m assuming that the binding has some code in place to reject connections from IP addresses other than 10.4.1.4. I’ve not looked to verify that. By default, a socket will accept connections from any IP address on that port. This is something specifically implemented by the binding.
This sentence doesn’t make sense. There isn’t a “from port” with UDP packets. There is only a “to port”. The client sends a packet from IP 10.4.1.4 to port 61032 on your OH server. That is why there is no place in your UDP test tool to configure a source port. There is no concept of a source port in UDP sockets. Only the destination port.
I don’t doubt it. If your client is sending the packet to port 61032 instead of port 56000, accepting all packets on all ports from 10.4.1.4 then it would work.
All I can say is that either I have absolutely no memory of how sockets work (unlikely since I’ve had to code this stuff before myself, but always a possibility) or for some reason your test app is not actually sending the messages to port 56000.
I looked at the code a bit and luckily I end up in standard Java code pretty quickly. The address:port combo in the log statement above is coming from a SocketAddress object carried by the DatagramChannel. In the OH code it calls theChannel.channel.connect(theChannel.remote) and remote and I think that is where the hangup is coming from.
UDP is connectionless but when you call connect it sets up a two-way connection. So now I’m wondering if the error is indicating that you don’t have an outgoing Item config for 10.4.1.4:61032 so it doesn’t know how to set up the outgoing connection to send responses back to your client, even though your client is not expecting any.
Based on the README I assumed that the binding was using bind for the incoming connections, not connect. This does change things significantly.
Anyway, the tl;dr is that you will have to set up the Item using * like you have been doing and set up the incoming port in udp.cfg since someone (I’m not sure if it is the client or the server) is choosing a random port for the return communication that isn’t even going to be used.
I have no idea why they would set it up this way and perhaps I’m misreading the code.
This is a similar thread to this one.