4 ms·

Author here. Allow me to extend the post a bit. It turns out that about 2.4% of the IPs that respond to SSDP queries, do so from a weird port number! For exampl

• floatboth 9y ago
  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).
  • 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.
• pawmal 9y ago
  hypothesis: - listens on multicast/1900; - response over unicast, thus ephemeral sport. so we use DPI to drop SSDP DDoS-es.