5 ms·

Isn't that normal UDP behavior? Source port on responses can always be anything?

ra1n85 9y ago
Not really - DNS, DHCP, NTP, etc, all respond from the source port the service is bound to.
DSMan195276 9y ago
You're half right. In most cases, programs have the OS pick their source port, but that's for the computer initiating the communication. So for example, in the communication he gave the 50950 was likely picked by the OS (by selecting a currently open port) and 1900 is the destination port. When the remote computer responds (his printer), they don't then pick a new random source port, they just swap the source/dest from the previous message. If they didn't keep it the same then the OS wouldn't always be able to know packets are part of which connections, because you can multiple connections open with the same computer at the same time to the same dest port, and the only differentiation would be the source port.
- zAy0LfpBZLC8mAC 9y ago
  > If they didn't keep it the same then the OS wouldn't always be able to know packets are part of which connections UDP does not have connections. > and the only differentiation would be the source port. ... or some request/session/flow id in the application layer protocol. Some UDP protocols use UDP in this way, some don't, UDP itself doesn't care.
  - DSMan195276 9y ago
    > UDP does not have connections. UDP does not have connections, but the OS does have a concept of UDP connections to a degree in the form of packet filtering/routing. Point being, if you send a DNS request (for example), the source IP/port and dest IP/port is how the OS will decide which packets to route back to you when the DNS server responds. If the responding DNS server changes the source port, the OS will not route that packet to the original socket because the source port does not match. You can still make it work, but you would have to be already listening for packets from that port (one way or another), so you would have to know beforehand they are going to be using a different port. > ... or some request/session/flow id in the application layer protocol. Some UDP protocols use UDP in this way, some don't, UDP itself doesn't care. You still have to get the packets though, and the OS had no idea about any application layer routing. If you want to get UDP packets from a bunch of different ports, you have to be listening on those ports. Edit: It's true I was playing a bit loose with the terminology (UDP is connectionless), but the behavior of packet routing and how changing the source port would mess with that is what I was getting at. If you want to be more correct, replace "connection" with "socket" in my original comment.
    - zAy0LfpBZLC8mAC 9y ago
      > UDP does not have connections, but the OS does have a concept of UDP connections to a degree in the form of packet filtering/routing. The filtering is completely optional to use. > Point being, if you send a DNS request (for example), the source IP/port and dest IP/port is how the OS will decide which packets to route back to you when the DNS server responds. That depends on how the requesting resolver has configured the socket. > If the responding DNS server changes the source port, the OS will not route that packet to the original socket because the source port does not match. That depends on how the requesting resolver has configured the socket. > You can still make it work, but you would have to be already listening for packets from that port (one way or another), so you would have to know beforehand they are going to be using a different port. Yes, obviously you have to know the application protocol you are trying to speak and how it uses UDP before you try to speak it. > You still have to get the packets though, and the OS had no idea about any application layer routing. Which is why application layer routing is called application layer routing. > If you want to get UDP packets from a bunch of different ports, you have to be listening on those ports. No, you listen on local ports, not on remote ports. > If you want to be more correct, replace "connection" with "socket" in my original comment. Well, technically, some minor details would be more correct - but the fundamental assumption that you can only receive datagrams from one remote address/port with a given socket is just completely and utterly wrong, and not just in the sense that it's a theoretical possibility, but it's a perfectly normal use case. To take an obvious example, a common configuration for an OpenVPN server is to accept authenticated packets from any remote address and automatically switch to changing remote addresses for the sending direction, so when the client changes addresses, the OpenVPN session just keeps going. As long as you don't connect() a datagram socket in the BSD sockets API, you will receive datagrams from any remote address (and you'll have to specify remote addresses using sendto() when transmitting).
      - DSMan195276 9y ago
        It's seems the context of my original comment just went way over your head. Yes, obviously, if the protocol is defined to allow for varying the source port then yes it will work because you specifically write your program to handle that. But the person I was responding too was asking in the context of protocols like SSDP, which is not defined that way. And he was asking if you could vary the source port anyway even though the protocol doesn't support it, and I said no and explained why that wouldn't work.
- dicknuckle 9y ago
  When the OS picks a random port, it's from a pool of Ephemeral ports. Which can vary from OS to OS. My assumption is that printer responding with a different source port breaks the communication over NAT. Is it a possibility that this is intended?
  - DSMan195276 9y ago
    Well I mean, you're correct it would break the communication over NAT, but it breaks the communication over the local network at well. You might still receive that packet to your NIC, but unless you know beforehand it will send using that source port and thus tell the OS (by setting up a socket or etc. to collect that packet) then the packet will never be routed to your application. So I don't really feel like this could be intended because it just makes stuff not work.
    - dingo_bat 9y ago
      > So I don't really feel like this could be intended because it just makes stuff not work. Sounds exactly like UPnP to me!
j_s 9y ago
I see it as more of a dev courtesy; the default is as you say, it takes extra work to do otherwise.

Not really - DNS, DHCP, NTP, etc, all respond from the source port the service is bound to.

DSMan195276 9y ago

You're half right. In most cases, programs have the OS pick their source port, but that's for the computer initiating the communication. So for example, in the communication he gave the 50950 was likely picked by the OS (by selecting a currently open port) and 1900 is the destination port. When the remote computer responds (his printer), they don't then pick a new random source port, they just swap the source/dest from the previous message. If they didn't keep it the same then the OS wouldn't always be able to know packets are part of which connections, because you can multiple connections open with the same computer at the same time to the same dest port, and the only differentiation would be the source port.

zAy0LfpBZLC8mAC 9y ago
> If they didn't keep it the same then the OS wouldn't always be able to know packets are part of which connections UDP does not have connections. > and the only differentiation would be the source port. ... or some request/session/flow id in the application layer protocol. Some UDP protocols use UDP in this way, some don't, UDP itself doesn't care.
- DSMan195276 9y ago
  > UDP does not have connections. UDP does not have connections, but the OS does have a concept of UDP connections to a degree in the form of packet filtering/routing. Point being, if you send a DNS request (for example), the source IP/port and dest IP/port is how the OS will decide which packets to route back to you when the DNS server responds. If the responding DNS server changes the source port, the OS will not route that packet to the original socket because the source port does not match. You can still make it work, but you would have to be already listening for packets from that port (one way or another), so you would have to know beforehand they are going to be using a different port. > ... or some request/session/flow id in the application layer protocol. Some UDP protocols use UDP in this way, some don't, UDP itself doesn't care. You still have to get the packets though, and the OS had no idea about any application layer routing. If you want to get UDP packets from a bunch of different ports, you have to be listening on those ports. Edit: It's true I was playing a bit loose with the terminology (UDP is connectionless), but the behavior of packet routing and how changing the source port would mess with that is what I was getting at. If you want to be more correct, replace "connection" with "socket" in my original comment.
  - zAy0LfpBZLC8mAC 9y ago
    > UDP does not have connections, but the OS does have a concept of UDP connections to a degree in the form of packet filtering/routing. The filtering is completely optional to use. > Point being, if you send a DNS request (for example), the source IP/port and dest IP/port is how the OS will decide which packets to route back to you when the DNS server responds. That depends on how the requesting resolver has configured the socket. > If the responding DNS server changes the source port, the OS will not route that packet to the original socket because the source port does not match. That depends on how the requesting resolver has configured the socket. > You can still make it work, but you would have to be already listening for packets from that port (one way or another), so you would have to know beforehand they are going to be using a different port. Yes, obviously you have to know the application protocol you are trying to speak and how it uses UDP before you try to speak it. > You still have to get the packets though, and the OS had no idea about any application layer routing. Which is why application layer routing is called application layer routing. > If you want to get UDP packets from a bunch of different ports, you have to be listening on those ports. No, you listen on local ports, not on remote ports. > If you want to be more correct, replace "connection" with "socket" in my original comment. Well, technically, some minor details would be more correct - but the fundamental assumption that you can only receive datagrams from one remote address/port with a given socket is just completely and utterly wrong, and not just in the sense that it's a theoretical possibility, but it's a perfectly normal use case. To take an obvious example, a common configuration for an OpenVPN server is to accept authenticated packets from any remote address and automatically switch to changing remote addresses for the sending direction, so when the client changes addresses, the OpenVPN session just keeps going. As long as you don't connect() a datagram socket in the BSD sockets API, you will receive datagrams from any remote address (and you'll have to specify remote addresses using sendto() when transmitting).
    - DSMan195276 9y ago
      It's seems the context of my original comment just went way over your head. Yes, obviously, if the protocol is defined to allow for varying the source port then yes it will work because you specifically write your program to handle that. But the person I was responding too was asking in the context of protocols like SSDP, which is not defined that way. And he was asking if you could vary the source port anyway even though the protocol doesn't support it, and I said no and explained why that wouldn't work.
dicknuckle 9y ago
When the OS picks a random port, it's from a pool of Ephemeral ports. Which can vary from OS to OS. My assumption is that printer responding with a different source port breaks the communication over NAT. Is it a possibility that this is intended?
- DSMan195276 9y ago
  Well I mean, you're correct it would break the communication over NAT, but it breaks the communication over the local network at well. You might still receive that packet to your NIC, but unless you know beforehand it will send using that source port and thus tell the OS (by setting up a socket or etc. to collect that packet) then the packet will never be routed to your application. So I don't really feel like this could be intended because it just makes stuff not work.
  - dingo_bat 9y ago
    > So I don't really feel like this could be intended because it just makes stuff not work. Sounds exactly like UPnP to me!

j_s 9y ago

I see it as more of a dev courtesy; the default is as you say, it takes extra work to do otherwise.