UPnP / Simple Service Discovery Protocol (SSDP)
sparky mark said:
I have three PanelViews in this installation and Wireshark shows all three broadcasting with a destination IP address of 239.255.255.250...
Just to point this out...
The 239.255.255.250 multicast address and UDP port 1900 are specific to the Simple Service Discovery Protocol (SSDP) when used over IPv4 networks. If this is the address one sees in Wireshark, then the protocol is undoubtedly SSDP and most likely coming from one or more PanelView Plus 6 or newer terminals with UPnP enabled. Pre PVP 6 terminals do not broadcast these packets.
SSDP is the discovery protocol that UPnP devices use to advertise their services to the host and beyond.
I'll post that Technote here again for ease of access...
505268 - PanelView Plus 6 & PanelView Plus 7 terminals broadcast SSDP packets on Ethernet network
Access Level: TechConnect
Just to clarify the original issue in the other thread...
Stonent said:
Lots of ARP traffic from a PanelView
We have one PanelView that is generating about 67% of all packets on it's subnet. Approximately 49 ARP requests per second...
...Wireshark captures show it looks like it's just going through all the IP addresses in the scope (255.255.254.0) which is a little over 500; over and over again...
...It was Universal Plug and Play was enabled on the PV. We went into the windows control panel and then services and de-selected it and rebooted the PV and it went away...
...wireshark filter that will show it
UDP && HTTP...
The OP in the other thread said they were getting excessive ARP requests and that they were all in the range of 255.255.254.0 inclusive. But if you look at the Technote, the "UPnP enabled" issue storms you with SSDP packets aimed at the UPnP multicast service address of 239.255.255.250, and that address alone.
So what gives?
Why were their symptoms different to this thread and the Technote?
Ethernet UPnP devices, when first introduced to the network, assign themselves an AutoIP address, or APIPA, if no DHCP Server is present, or none of its reserved private addresses are available. This is where you see a device with an IP address of 169.254.x.x. These APIPA assigned devices will continuously attempt to obtain a private address with the DHCP Server broadcasting ARP requests to see if potentially free private addresses are in use or not. In the meantime, whether using private or APIPA addressing, these devices will then use SSDP to advertise their services, or if applicable, listen for other available UPnP services. Also known as SSDP alive packets. So you will get a combination of both SSDP and ARP broadcasts during this particular phase.
So, because UPnP was enabled, the DHCP Server was continuously broadcasting ARP requests in an attempt to find a private IP address for some UPnP device that was present on the network. Once disabled, the UPnP device was no longer discoverable and so the DHCP Server desisted its attempts and the ARP requests disappeared.
The Wireshark filter they mention, of the Transport Layer UDP and Application Layer HTTP, would show up both ARP requests and SSDP alive packets, as the SSDP protocol uses HTTPU, which is an extension of the well known HTTP/1.1 protocol, which you see listed in the Wireshark screenshot in the Technote. More specifically, it uses HTTP
MU, which is a variant of HTTPU, and uses IP
Multicast. The
U standing for UDP.
So, in a nutshell...
UPnP uses the SSDP protocol to multicast device discovery and alive packets, using the Application Layer HTTP, over the Transport Layer UDP by utilizing the HTTPMU variant of the Hyper Text Transport Protocol, and as a knock on effect, UPnP devices that may be present will potentially flood the network with ARP requests for good measure.
I'm possibly the only one that noticed that difference between the two threads, but it did bug me enough to warrant explaining.
Regards,
George
