I downloaded libupnp-1.6.6 while ago to see if I can emulate
an IGD on top of router that doesn't have UPnP on its own.
(It is like having a linux IGD on top of a linux system used as router. It is just that
in my case, the IGD-like daemon runs on a PC and a router is separate entity. It should be doable, I hope. (I intend to control the router via its console line or logging into it using
old-fashioned telnet. Even it turns impossible, it is interesting to learn how UPnP works under the desk so to speak.)
Anyway, I have downloaded document from upnp forum, which recently seems to have
merged with another organization. Anyway, in its document (a whole bunch is available
as one zip file), there are sample xml description of IGD device which I
copied and modified to create a sample IGD description.
See the original
- Single Download File for UPnP™ Documents
- Networking Internet Gateway:1
One problem I encountered is that IGD device consists of a few device
internally actually, and its description is very hierarchical unlike the simple
sample tv device and its controller in libupnp sample directory.
Its xml description has nested description.
root device -> list of service, another device -> another servicelist, etc.
To my surprise, when I tried to modify the the sample application to create
a sample device based on my xml description of IDG device, I found that
sample will never work if we use SampleUtil_* routines.
This is because the nested servicelist (at the second level, etc..) is not found
by the mimicked/modfiied tvDeviceStateTableInit (), which calls
SampleUtil_FindAndParseService (), but it in turn calls
SampleUtil_GetFirstServiceList( ) and as the name suggests
it only picks up the first list at the top-level and
never bother to try to see the servicelist of the nested Devices, for example.
As a result, for testing purposes, I had to flatten my xml description
by removing the nested root to create a very simplified (and yet maybe not
quite correct) IDG that has all the services in one flattened list at the top level.
Now, at least my program begin working.
Am I doing something incorrect?
Or is the SampleUtil_* functions meant to show
the handling in the simplistic cases and
never intended to handle complex device with nested devices and
services like real-world IDG?
It is a pity that a sample XML description (after suitably modifed
by inserting appropriate strings) in IDG document from UPNP
can not work with libupnp.
Any helpful tips to work with the XML sample from UPnP forum
will be appreciated.
(I had found a very simple generator program to produce a code snippet that handles
the setting of state variables and handles actions (obtaining input parameter values
and setting output values), etc. and
can be used with libupnp from a given xml description. But that
simple generator only works with simple xml descriptions of tv device and
didn't work with IDG sample xml description from UPnP.
When this generator didn't work, I looked into the code and realized
this nested device, servicelist problems. I wonder how others coop with
complex xml construct.
I did the following to fix the particular problem and it looks promizing.
I changed sample_util.c so that the serviceList is searched
until the desired service is found instead of just looking at
the first servicelist of the root device.
With the change, I could make a modified control point program (based on
upnp_*_ctrl) to understand the full xml description based on IDG spec from UPnP Forum.
Obviusly, the full-spec XML (not the flattened version) is required for IDG-compatibility
and before, portmapper-1.6.jar (a program to control portmapping available from
sourceforge.net:search upnp portmapping)
could not find the simulated IGD device, but with the
modification above and the full XML description, portmapper now
recognizes the IGD device again based on heavily modified
So a great progress.
I am going to post a patch for sample_util.c
The patch contains a few indentation changes, addition of
error message string (on top of the integer error code), etc in other places.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.