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. More specifically, it uses HTTP MU, which is a variant of HTTPU, and uses IP Multicast. 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. Once disabled, the UPnP device was no longer discoverable and so the DHCP Server desisted its attempts and the ARP requests disappeared. 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. So you will get a combination of both SSDP and ARP broadcasts during this particular phase. 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. 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. This is where you see a device with an IP address of .x. Why were their symptoms different to this thread and the Technote?Įthernet 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. 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. 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. We went into the windows control panel and then services and de-selected it and rebooted the PV and it went away. It was Universal Plug and Play was enabled on the PV. 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. Approximately 49 ARP requests per second. We have one PanelView that is generating about 67% of all packets on it's subnet.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |