-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

(taking this back to the list)

On 2014-02-26 14:55, Martin Peach wrote:

On 2014-02-26 03:47, IOhannes m zmoelnig wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2014-02-26 04:57, Martin Peach wrote:

how come? how does DNS (after all, a central service in the internet) work with this assumption?

UDP works fine with as a challenge/response system (less so as client/server, given that there is no notion of a "connection"), and for responses you need o be able to send messages somewhere.

for whatever reasons, many hardware manufacturers have the idea that sending/receiving on the *same* port is a good idea.

I see; but for DNS with [udpsend] and [udpreceive], it should work since one [udpsend] can send to port 53 of the DNS server and a separate [udpreceive 53] will receive its replies.

it seems i was a bit unclear here, and thus two separate things got mixed up:

- DNS is a bi-directional protocol: you send a query (from a random port N) to a DNS-server (on port 53), and the server sends a response from port 53 to that port N.

- hardware-manufacturers like the idea that the receiving port is the same as the sending port.

DNS does not have this limitation of using the same port (thus you can query a DNS-server on localhost without stepping on your own ports). so having both [connect dns.server 53(->[udpsend] + [udpreceive 53] is not sufficient to query a DNS-server.

The problem seems to be that [udpsend] will assign itself a random port to which the remote device will send replies, but [udpsend] doesn't know its own port number.

well, but that's only half of the solution (for the DNS-problem): even if [udpsend] had a notion of it's sending port, it would discard all messages arriving on this port. but it still *listens* on (and thus blocks) this port, so you cannot tell a [udpreceive] to (also) use it.

fg,asd IOhannes