The ICSI Netalyzr Explored → Re: Blocked UPnP means that your network is broken?

What Netalyzr is pointing out here is an actual bug in your device's UPnP support: the UDP-based discovery process works in principle: the client learns the URL at which the device's UPnP profile can be retrieved. However, trying to do so yields an HTTP 404 error. This is broken UPnP support in your gateway device, which we flag accordingly.

My Router UPNP is working fine and i still get the same:

HTTP/1.0 404 Not Found
Content-Type: text/html
Content-Length: 112

HTTP/1.0 404 Not Found
HTTP/1.0 404 Not Found.

Which is a bit strange.

We have some thought on some tests which might work better. If you are willing, email netalyzr-help@icsi.berkeley.edu

We're trying to figure out in more detail why so many systems are failing the UPnP test by sending back 404s or other errors when we attempt to probe for more details.

The only place I can find where you did your UPnP test in my local PC firewall logs or any router log on my network, is in the local PC firewall log. I have reproduced the entries below:

Time                 Action    Severity Direction  Protocol Remote Host                                      Remote MAC         Remote Port  Local Host        Local MAC           Local Port  Application Name                         User    Domain  Security  Rule
 
04/28/2011 13:28:26  Blocked   10       Incoming   UDP      192.168.10.100                                   00-0F-B5-81-A6-C9  15580        239.255.255.250   01-00-5E-7F-FF-FA   1900                                                 myname  DCS_NET Normal    Block UPnP Traffic
04/28/2011 13:28:26  Allowed   10       Outgoing   UDP      239.255.255.250                                  01-00-5E-7F-FF-FA  1900         192.168.10.100    00-0F-B5-81-A6-C9   15580       C:\Program Files\SeaMonkey\seamonkey.exe myname  DCS_NET Normal    Ask all running apps
04/28/2011 13:28:26  Allowed   10       Outgoing   TCP      n3.netalyzr.icsi.berkeley.edu [174.129.176.88]   00-16-B6-86-E8-EE  80           192.168.10.100    00-0F-B5-81-A6-C9   15561       C:\Program Files\SeaMonkey\seamonkey.exe myname  DCS_NET Normal    Ask all running apps
 
 

The local PC firewall blocked the inbound UPnP traffic (as it should have). The only anomaly I can see is the device using MAC address 01-00-5E-7F-FF-FA which responded to your UPnP probe. I do not have a device with that MAC address on my network, and I will certainly be checking into how/where that response came from. You certainly did send an html request to my gateway router following your UPnP probe, but it was not my router who responded (and I do find that troubling, so thank you for finding a potential problem, even if it was not the problem your test was looking for).

I plan on running this test again later today and doing a full packet capture, but I can't do it right now as I have to leave for an appointment with a client. If someone from ICSI would like the results of that test and/or the captured packet, let me know.

We'd love to.

Please email netalyzr-help@icsi.berkeley.edu

We also have a beta test version which may help as well.

Thanks!

Sending you the packet captures probably won't be necessary.

Once I did the packet captures I could see that the UPnP response was coming from a recently installed Netgear WNR1002v2-VC wireless router that was supplied to me at no cost by my ISP Comcast (how could I refuse a free router?). It is a residential grade wireless router that I am only using as an access point. It seems that even though I disabled UPnP in its html setup menu, it was still responding to UPnP queries (it also seems that you get what you pay for).

After I temporarily disabled the LAN switch port that it used, I no longer got the UPnP broken message in the test results. My next step was to manually create a real UPnP block rule for my local PC firewalls instead of relying on the GUI menu check box that claimed to disable UPnP (but which obviously only disabled inbound UPnP traffic). With that rule in place, your test now tags my UPnP support as "Not found" instead of "Broken" even with the "Broken" Netgear WiFi router back on the network. "Not found" is good, if I had seen "Not found" in the original test I ran, this sub-thread would not even exist.

As for the 01-00-5e-7f-ff-fa MAC address, that appears to just be the default MAC address used for multi-cast UPnP (and also my ignorance showing because I had never really done anything with UPnP except to disable it). Now, thanks to your test I can really be sure that it is disabled.

Anyway, your test's conclusion that a device was incorrectly answering a UPnP probe was correct. It just was not the default gateway router that was replying. That my PC's firewall was blocking UPnP replies, but allowing outbound UPnP queries just added to the situation because your test could not see the replies from my WiFi router (which it should not have been sending anyway). Thanks for a good network test and the education on what the UPnP "Broken" test result actually meant (it helped me to tighten up my network security one more notch).

Thanks to all who helped, we've fixed the UPnP bug.

Thanks!