UDP: How does the client know its server?

0
votes

I'm sniffing between two devices which communicate in a duplex fashion via udp. I'm using wireshark to sniff. The config file for the first device (a piece of hardware under test) states that the client port is 54718 and the server is 54717. In the config file for the second device (a simulator written years ago), only one port is specified. That of 54718.

The two devices communicate without any problems.

But how does the second device manage to connect and send to 54717 when it has no knowledge of it?

In wireshark I can see that the first device is sending to the second device such that the source port is 54717 and the destination is 54718. I can also see that the second device is sending to the first device such that the source port is 54718 and the destination is 54717.

The first device sends first and the protocol is described as that of UDP in Wireshark. The simulator replies, also via UDP. Subsequent exchanges are described as being STUN ChannelData TURN Messages. I've no knowledge of this protocol but maybe it explains why I don't see 54717 in the simulators config file.

Thanks for your help,

Barry

3
udpwireshark
Hello Barry. This is probably belongs on serverfault, but I don't have enough reputation to transfer you. – Aaron Newton
There is no fault. The two devices are communicating correctly. I just don't understand how. – Baz
serverfault.com is a StackExchange website like StackOverflow dedicated to servers, networking and related issues ;) Also, looking at the spec for UDP en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_structure the header includes both the source and destination port, so maybe the server and/or clients are listening on all ports (insane as that would be) and finding the header that way (it seems like someone has managed to do something similar stackoverflow.com/a/1244018/201648), then broadcasting to all networked machines (networkeducator.com/udp-broadcast.htm). – Aaron Newton

3 Answers

1
votes

First, in UDP communication, there is no "connect" action. UDP is not connection-oriented.

Second, the second device will get the peer address and port from recvfrom() api call.

1
votes

In all probability, the first device's use of the terminology "client port" and "server port" do not refer to two different ports within the client device. Instead, the "client port" refers to the port to be used as the point of origin within the first device, and the "server port" refers to the remote destination port on the far device, to which the first device's outgoing traffic will be sent.

The second device, on the other hand, is probably fundamentally a "listening" device. It only knows the UDP port it needs to listen on, and waits for any queries destined to that port to arrive from anywhere.

So, I will refer to the "first device" as the client, and the "second device" as the server.

Each datagram sent from the client to the server contains two sets of address information: 1) The destination IP address and port, and 2) The return IP address and port.

The server can use recvfrom() to extract the complete return address (including port number) from each incoming request.

This way, we really only need one port number to be predfined and agreed upon by both the server and the client ahead of time: The server's port number.

The client could conceivably choose to use any random port number as its origin port (but by convention it would likely choose to avoid any of the well-known reserved ports to avoid potential interoperability problems), and the server could dynamically read the return address information from each incoming request and send its responses to the correct destination dynamically.

0
votes

But how does the second device manage to connect and send to 54717 when it has no knowledge of it?

UDP is connectionless, and your program likely gets the 54717 as a default fallback value if nothing else is specified (e.g. in a config file).