Library does not support discovery of ASUS Wireless Router RT-AC87U.

Jan 5, 2015 at 6:24 PM
Tried adjusting some of my code for my new router, but it does not want to discover it so I can add UPnP settings. (http://www.asus.com/us/Networking/RTAC87U/)

It does enumerate the right service:
urn:schemas-upnp-org:service:Layer3Forwarding:1
urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
urn:schemas-upnp-org:service:WANIPConnection:1

WANIPConnection being the correct one as it points to (WANIPCn.xml) which contains the AddPortMapping etc that is needed (discovered by sniffing).

Whenever the
ServiceDescription lsdDesc = service.Description(true);
is run, it only returns null.

The Test app that follows the code also returns null her and fails with a NullReferenceException.

Also tried a few other programs made by others using the same library. They all fail getting the info.

UPnPWizard works (http://www.xldevelopment.net/upnpwiz.php).

So is it an error in the ManagedUPnP or a weakness in the unmanaged library used?
Coordinator
Jan 6, 2015 at 6:40 AM
Edited Jan 6, 2015 at 6:41 AM
Hello Zewolf5,

The fact that a lot of UPnP frameworks aren't working with it tells me that it is more likely that the device itself is not adhering to the UPnP standards properly, and maybe UPnPWizard has extra code added for this non-compliant behaviour.

You will need to debug the service.Description() call and determine exactly what is causing the issue, of course I can't help you with this without having the device connected to my network so I can debug it. More than likely it is a problem with the device description URL, or possibly the control URL, maybe the URL is not formatted properly.

I would need a lot more information including full logging from the demo application, without this of course I have no information to work from at all.

For me to even look at this I would need the following:
  • The root description XML file
  • The service and device description XML files
  • The logs form the demo application which is picking the data up
  • And an investigation done by you of the "service.Description()" call with information as to what is actual;y causing the problem.
Additional info which might help if you can provide it would be all HTTP traffic relevant to the UPnP communication.

Thanks.
Jan 6, 2015 at 6:43 AM
Edited Jan 6, 2015 at 5:21 PM
Thanks for the reply. I will start to look into this when I get back from work. I am using this library to let the kids share "LAN Minecraft" with their friends.

UPDATE:
Here are the logfiles and other files + screenshot and full wireshark of UPnP wizards activity when being opened. (should contain all the descriptions): http://halsvik.net/downloads/upnp_logfiles.zip

Will see if I can debug out why it can not find the Description() as that function only gets an object from a collection/dictionary.
Jan 6, 2015 at 5:54 PM
Edited Jan 6, 2015 at 9:28 PM
Can it be because all of the 3 devices has the same ID?

<UDN>uuid:a497661b-0a9e-49ef-b5dd-8ee6fc1889b1</UDN>

.FindDevice gets the info using that ID, and it returns the first? Just trying to grasp stuff by debugging it.

or is it when it does:
lddDevice.DeviceServices.TryGetValue(service.Id, out ldsdDesc); 
where service.Id is "urn:upnp-org:serviceId:WANIPConn1". The dictionary it checks only contains 1 item: Key = "urn:upnp-org:serviceId:Layer3Forwarding1"

I am thinking it has something do to with recursive devices...? I really have no experience here to know whats normal or not.

lddDevice.ToString() ->
Device: RT-AC87U (urn:schemas-upnp-org:device:InternetGatewayDevice:1) (UDN:uuid:a497661b-0a9e-49ef-b5dd-8ee6fc1889b1)
{
    Service: urn:upnp-org:serviceId:Layer3Forwarding1 (urn:schemas-upnp-org:service:Layer3Forwarding:1)
}
{
    Device: WANDevice (urn:schemas-upnp-org:device:WANDevice:1) (UDN:uuid:a497661b-0a9e-49ef-b5dd-8ee6fc1889b1)
    {
        Service: urn:upnp-org:serviceId:WANCommonIFC1 (urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1)
    }
    {
        Device: WANConnectionDevice (urn:schemas-upnp-org:device:WANConnectionDevice:1) (UDN:uuid:a497661b-0a9e-49ef-b5dd-8ee6fc1889b1)
        {
            Service: urn:upnp-org:serviceId:WANIPConn1 (urn:schemas-upnp-org:service:WANIPConnection:1)
        }
    }
}
UPDATE:
Got it to work with a hack.
                    DeviceDescription lddDevice = rootDescription.FindDevice(device.UniqueDeviceName);
                    lddDevice = lddDevice.Devices[0].Devices[0];
Since I do not know the whole dynamics of the code here, I leave it to you to explain why that hack is my solution :)

If it is because of the not-so-unique device IDs, a more robust(?) workaround is a rootDescription.FindService(guidId, serviceId) which will check for that service within any hits on the Device id?

So removing all the logging this code works instead of a hack:
        public static DeviceServiceDescription DeviceServiceDescription(
            this IUPnPService service, IUPnPDevice device, RootDescription rootDescription)
        {
            if (rootDescription != null)
            {
                return DeviceServiceDescriptionMultiDevices(service, rootDescription.Device);
            }
            return null;
        }

        public static DeviceServiceDescription DeviceServiceDescriptionMultiDevices(
           IUPnPService service, DeviceDescription device)
        {
            DeviceServiceDescription ldsdDesc = null;

            device.DeviceServices.TryGetValue(service.Id, out ldsdDesc);

            if (ldsdDesc == null)
            {
                foreach (var item in device.Devices)
                {
                    if (item.Key == device.UDN)
                    {
                        ldsdDesc = DeviceServiceDescriptionMultiDevices(service, item.Value);
                        if (ldsdDesc != null) break;
                    }
                }
            }
            return ldsdDesc;
        }
It might still be hacky, but you would know best here. It is at least a work around for this kind of situation, and unless it breaks anything it should make the code more robust.
Coordinator
Jan 7, 2015 at 10:05 AM
Hello Zewolf5,

Yes, it will definitely be because the devices have the same UDN, in fact, I found this problem with another Router device I had a couple of years ago (Netgear DG834Gv1). However, I was able to fix this by getting a firmware update, is there a new firmware available for your router?

As you found out you can get around it by checking the device URN, to ensure you get the right device, I will look into this and see if I can add some functions for future use, however, as you have found out, it really is something that needs to be fixed with the firmware on the hardware device itself.

Thanks for this great investigation.
Jan 8, 2015 at 12:47 AM
Bought it a few weeks ago, and there was no new firmwares at that time. As long as my workaround works, I am happy, or rather, the kids are happy to share their LAN games with their friends.