XR1000 Not responding appropriately to SSDP Service Request Packets

[EasyG0ing1]

Hello, I've been working on a Java program that relies on UPnP. And during my testing of the service using my XR1000 router, I noticed that the router almost never responds to standard SSDP broadcast packets requesting UPnP service information. So I decided to run some tests specifically to find out if this router responds to the broadcasts in accordance with the UPnP published standard and from what I see, it does not.

I created a small program to gather data on the routers actual responses to SSDP broadcasts. The program sends out one UDP broadcast SSDP packet every 5 seconds, then it records when the router sends a response. The results were that I would get a response sometimes right away, sometimes after several minutes and sometimes it would take over an hour to get a response.

I started my tests using the initial original release firmware for this router, then when I ran the test and collected the data for a few hours, I would then flash the firmware up to the next version and repeat the test and collect the data. I did this until I was on the latest firmware, which is just as bad as all the others.

I had opened a case on this (case number 46021027) but after painstakingly repeating myself several times and being tossed around to different tech support people, the last person asked me if I tried rebooting the router then closed my case. Which is just frustrating as all get out.

I've been a Network Engineer for 25 years and I know my way around a router and I know that this one has a problem.

When I did the same tests on a R7800, I got one response for EVERY SSDP packet that I sent out ... 

I need to know if this is a bug in the xR1000 firmware or is this unique to my router to where it might need to be replaced?

Thank you,

Mike Sims

[Netduma-Liam]

Thanks for letting us know, I suspect that this would be a problem with the firmware(s) itself rather than just your unit specifically. I'll look into it further and see how we can test this internally.

This wouldn't be an issue with DumaOS but rather NETGEAR's network settings, but we can still make them aware of it if we're able to reproduce it.

[EasyG0ing1]

You know ... I can't explain this, but it remains frustrating nonetheless...

I was re-working the test program that I use to send out the SSDP packet to record the responses from the router. I basically took out the SQL portion of it and added the ability to configure some options from the command line etc. I tested it and it was still giving me the same behavior where it would not respond to the SSDP packet until I had sent several of them (timed at 5 seconds apart) and the amount that I had to send before getting a response was never a consistent number, but I wanted to give you the source code that I wrote in Java as well as a compiled self running .EXE file that you could use to check the problem with your own hardware.

Once I had the code re-configured,  copied it to my Windows virtual machine to compile it into a windows EXE, but first I tested it from the IntelliJ IDE and it kept throwing an error when on the line of code that binds UDP to the NIC. So I went back into my Mac environment to look at the code and there was one line that I changed. I took this line:

socket = new DatagramSocket(new InetSocketAddress(port));

And I decided to break out the inside of the parentheses so I could see if the issue was related to the instantiation of the DatagramSocket or the creation of the InetSocketAddress object... so when I was done, the code looked like this:

InetSocketAddress address = new InetSocketAddress(port);
socket = new DatagramSocket(address);

Then I ran the code to test it, and I'll be damned if I was not now getting one response for every packet that I sent out. Of course there was no reason why that would happen simply from the change I made since the process of instantiating a class outside of the next line or doing it inside the passing of the argument - makes no difference to a compiler, the compiled code ends up looking the same, but breaking it out like I did provides me with one more line of troubleshooting so I can know which step it choked on...

So I decided to put the code back the way it was when it wasn't getting the expected responses from the router, and I did this using IntelliJ's code history feature where I simply restored the code to a point in time that was about 20 minutes into the past.

I ran the code... and I got one response for every packet I sent out.

Which means that even though I reverted the code back to the exact same code that I used which produced results that indicated the problem ... that code was now seeing one packet received for every SSDP packet sent out.

Which means the router is NOW working as it should.

And in the interest of being thorough, I power cycled the router, but when it botted back up, it booted up into a factory new config (no idea why, but these things can happen sometimes), so I went through the setup wizard and re-configured the router the way I had it, but it is still responding to the SSDP packets on a one for one basis which means everything is fine now.

And I cannot explain why. But ... as the saying goes ... don't look a gift horse in the mouth.

☺

Mike

[Netduma-Fraser]

Thanks a lot for the detailed information you've provided, I'll pass it onto our team to see if it's something we need to look at and if not we'll pass it onto NG directly.