Hi,
We pick up everything going to port 4 so if you are the responder and we are the query, that works. But with you as the query node and us as the responder, our response is not picked up because it goes to port 3xxxx. At least, I think that explains the behaviour I am seeing - if I force it to port 4, it works.
In the spec, section 5.3.2 says "the source UDP port...receives UDP messages in reply". And section 5.3.1 says "UDP port numbering must be...the same for messages in the same direction and swapped otherwise".
I guess the most trivial fix would be to send our Query from port 4, right? I will try to fix this bug as soon as possible. Thank you very much for pointing this out.
I committed a change to our development tree, which forces every outgoing packet to be send from port 4. This should "fix" the problem you had, namely, that you send the response to the source port we used in the query and this packet getting dropped. Of course, our implementation is still wrong, as it does not reply to the source port of the query when we switch roles. But as you wrote, you always listen on port 4, so this works for now.
To really fix this issue, I will need a little more time, as this requires some changes to our sending logic. Can you please ask Robert if it is safe to set the source port of the Query to the well known GIST port (aka 4 at the moment) or to another fixed port assigned by our implementation. What is a good policy to set the source port? (I am not sure, why Robert designed the port stuff this way)
BTW: What happened to Chris Lang (I hope this was his name). I think he was the one who worked on the roke implementation when we met in Paris, is this right?
Christian Dickmann