View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001609GNUnetNAT traversal librarypublic2010-10-11 15:062011-09-19 10:45
ReporterChristian Grothoff Assigned Tomilan  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Summary0001609: NAT library fails to handle unexpected UPnP responses gracefully
DescriptionHere is what I get from the test-nat code:
$ ./test-nat 
Oct 11 15:02:02 test-nat-26111 INFO Testing NAT library, timeout set to 60 seconds
Oct 11 15:02:02 test-nat-26111 INFO Requesting NAT redirection from address 131.159.20.35:2086...
Oct 11 15:02:03 UPnP DEBUG Sent 137 bytes to 239.255.255.250:1900
Oct 11 15:02:18 UPnP DEBUG Sent 132 bytes to 239.255.255.250:1900
Oct 11 15:02:23 UPnP DEBUG Sent 133 bytes to 239.255.255.250:1900
Oct 11 15:02:28 UPnP DEBUG Sent 101 bytes to 239.255.255.250:1900
Oct 11 15:02:28 UPnP DEBUG Received 306 bytes from 131.159.20.54:2894
Oct 11 15:02:28 UPnP DEBUG Found device http://131.159.20.54:49152/IPMIdevicedesc.xml when looking for type upnp:rootdevice
Oct 11 15:02:28 UPnP DEBUG Preparing to download device description from 'http://131.159.20.54:49152/IPMIdevicedesc.xml'
Oct 11 15:02:28 UPnP DEBUG Downloaded 1 records of size 791, download position: 791
Oct 11 15:02:28 UPnP DEBUG Download of device description `http://131.159.20.54:49152/IPMIdevicedesc.xml' completed.
Oct 11 15:02:28 UPnP DEBUG base_url = 
Oct 11 15:02:28 UPnP DEBUG WAN Device (Common interface config) :
 sevice_type = 
 control_url = 
 event_sub_url = 
 scpd_url = 
Oct 11 15:02:28 UPnP DEBUG WAN Connection Device (IP or PPP Connection):
 service_type = 
 control_url = 
 event_sub_url = 
 scpd_url = 
Oct 11 15:02:28 UPnP WARNING Invalid URL passed to UPNP_command(): 
Oct 11 15:02:28 UPnP DEBUG Found device: control_url: , service_type: 
Oct 11 15:02:28 UPnP DEBUG Found device: control_url: , service_type: 
Oct 11 15:02:28 UPnP DEBUG Found device: control_url: , service_type: 
Oct 11 15:02:28 NAT (UPnP) INFO Found Internet Gateway Device ""
Oct 11 15:02:29 UPnP WARNING Invalid URL passed to UPNP_command(): 
Oct 11 15:02:29 NAT (UPnP) INFO Port 2086 forwarded successfully
Oct 11 15:02:29 UPnP WARNING Invalid URL passed to UPNP_command(): 
Oct 11 15:02:29 test-nat-26111 DEBUG Response: Oct 11 15:02:29 NAT (UPnP) DEBUG UPNP_get_external_ip_address_ failed (error -1)
Oct 11 15:03:02 test-nat-26111 INFO Stopping NAT and quitting...
Oct 11 15:03:02 UPnP WARNING Invalid URL passed to UPNP_command(): 
Oct 11 15:03:02 test-nat-26111 DEBUG Response: Oct 11 15:03:02 NAT (UPnP) DEBUG UPNP_get_external_ip_address_ failed (error -1)
Additional InformationThe IPMI device descriptor that is returned by the address given above is:
$ cat IPMIdevicedesc.xml 
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
  <specVersion>
    <major>1</major>
    <minor>0</minor>
  </specVersion>
  <device>
    <deviceType>urn:schemas-upnp-org:device:management:1</deviceType>
    <friendlyName>SMCI_0:30:48:df:36:d5</friendlyName>
    <manufacturer>SMC Incorporated</manufacturer>
    <manufacturerURL>http://www.supermicro.com</manufacturerURL>
    <modelDescription>IPMI Console</modelDescription>
    <modelName>IPMI Console</modelName>
    <modelNumber>1.0</modelNumber>
    <modelURL>http://www.supermicro.com</modelURL>
    <serialNumber></serialNumber>
    <UDN>uuid:Upnp-IPMI-1_0-1234567890001</UDN>
    <UPC></UPC>
    <serviceList>
    </serviceList>
   <presentationURL>/</presentationURL>
</device>
</root>

While this is not a NAT (or even Router) that we're interested in, the code should tolerate the respective responses better (i.e. not try to send commands after getting an empty command URI).
TagsNo tags attached.

Activities

milan

2010-11-10 15:18

reporter   ~0004167

I think we should just remove src/nat/upnp-discover.c:
  "upnp:rootdevice",

This line means we'll try to discover any type of UPnP device if we didn't find a valid IGD, which is silly.

milan

2010-11-10 15:27

reporter   ~0004168

I committed the above fix in revision 13642. (It seems that there's still another issue, but it's not really related.)

Issue History

Date Modified Username Field Change
2010-10-11 15:06 Christian Grothoff New Issue
2010-10-11 15:06 Christian Grothoff Assigned To => milan
2010-10-11 15:06 Christian Grothoff Status new => assigned
2010-11-10 15:18 milan Note Added: 0004167
2010-11-10 15:27 milan Note Added: 0004168
2010-11-10 15:27 milan Status assigned => resolved
2010-11-10 15:27 milan Fixed in Version => Git master
2010-11-10 15:27 milan Resolution open => fixed
2010-12-23 23:50 Christian Grothoff Status resolved => closed
2011-09-19 10:45 Christian Grothoff Fixed in Version Git master => 0.9.0pre3
2011-09-19 10:45 Christian Grothoff Target Version => 0.9.0pre3