Upnp not properly portwarding - Errors 714 and 718

[UrbenLegend]

When trying to send a file (or anything else that requires upnp in pidgin), this message occurs in the debug log: ****************************************************************

(15:04:28) oscar: Calculating checksum of C:\Documents and Settings\Username\Desktop\Test2.txt
(15:04:28) oscar: Checksum of C:\Documents and Settings\Username\Desktop\Test2.txt calculated
(15:04:28) network: Listening on port: 5190
(15:04:28) util: requested to fetch (http://192.168.2.1:5431/uuid:00115009-e606-0011-5009-e6060232016c/WANPPPConnection:1), full=0, user_agent=((null)), http11=1
(15:04:28) dnsquery: Performing DNS lookup for 192.168.2.1
(15:04:28) dnsquery: IP resolved for 192.168.2.1
(15:04:28) proxy: Attempting connection to 192.168.2.1
(15:04:28) proxy: Connecting to 192.168.2.1:5431 with no proxy
(15:04:28) proxy: Connection in progress
(15:04:28) proxy: Connected to 192.168.2.1:5431.
(15:04:28) util: Request: 'POST /uuid:00115009-e606-0011-5009-e6060232016c/WANPPPConnection:1 HTTP/1.1
HOST: 192.168.2.1:5431
SOAPACTION: "urn:schemas-upnp-org:service:WANPPPConnection:1#AddPortMapping"
CONTENT-TYPE: text/xml ; charset="utf-8"
CONTENT-LENGTH: 647

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <s:Body>
  <u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1">
   <NewRemoteHost></NewRemoteHost>
   <NewExternalPort>5190</NewExternalPort>
   <NewProtocol>TCP</NewProtocol>
   <NewInternalPort>5190</NewInternalPort>
   <NewInternalClient>192.168.2.2</NewInternalClient>
   <NewEnabled>1</NewEnabled>
   <NewPortMappingDescription>PURPLE_UPNP_PORT_FORWARD</NewPortMappingDescription>
   <NewLeaseDuration>0</NewLeaseDuration>
  </u:AddPortMapping>
 </s:Body>
</s:Envelope>'
(15:04:28) util: Response headers: 'HTTP/1.1 500 Internal Server Error
DATE: Thu, 01 Jan 1970 05:39:06 GMT
Connection: Keep-Alive
Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0
Content-Length: 470
Content-Type: text/xml; charset="utf-8"
EXT:
'
(15:04:28) util: parsed 470
(15:05:09) upnp: purple_upnp_set_port_mapping(): Failed HTTP_OK
HTTP/1.1 500 Internal Server Error
DATE: Thu, 01 Jan 1970 05:39:06 GMT
Connection: Keep-Alive
Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0
Content-Length: 470
Content-Type: text/xml; charset="utf-8"
EXT:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <s:Body>
  <s:Fault>
   <faultcode>s:Client</faultcode>
   <faultstring>UPnPError</faultstring>
   <detail>
    <UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
     <errorCode>718</errorCode>
     <errorDescription>ConflictInMappingEntry</errorDescription>
    </UPnPError>
   </detail>
  </s:Fault>
 </s:Body>
</s:Envelope>

(15:05:09) network: Couldn't create UPnP mapping
(15:05:09) util: requested to fetch (http://192.168.2.1:5431/uuid:00115009-e606-0011-5009-e6060232016c/WANPPPConnection:1), full=0, user_agent=((null)), http11=1
(15:05:09) dnsquery: Performing DNS lookup for 192.168.2.1
(15:05:09) dnsquery: IP resolved for 192.168.2.1
(15:05:09) proxy: Attempting connection to 192.168.2.1
(15:05:09) proxy: Connecting to 192.168.2.1:5431 with no proxy
(15:05:09) proxy: Connection in progress
(15:05:09) proxy: Connected to 192.168.2.1:5431.
(15:05:09) util: Request: 'POST /uuid:00115009-e606-0011-5009-e6060232016c/WANPPPConnection:1 HTTP/1.1
HOST: 192.168.2.1:5431
SOAPACTION: "urn:schemas-upnp-org:service:WANPPPConnection:1#DeletePortMapping"
CONTENT-TYPE: text/xml ; charset="utf-8"
CONTENT-LENGTH: 411
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <s:Body>
  <u:DeletePortMapping xmlns:u="urn:schemas-upnp-org:service:WANPPPConnection:1">
   <NewRemoteHost></NewRemoteHost>
   <NewExternalPort>5190</NewExternalPort>
   <NewProtocol>UDP</NewProtocol>
  </u:DeletePortMapping>
 </s:Body>
</s:Envelope>'

(15:05:09) util: Response headers: 'HTTP/1.1 500 Internal Server Error
DATE: Thu, 01 Jan 1970 05:39:47 GMT
Connection: Keep-Alive
Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0
Content-Length: 466
Content-Type: text/xml; charset="utf-8"
EXT:

\Username\Application Data\.purple
(15:05:39) upnp: purple_upnp_set_port_mapping(): Failed HTTP_OK
HTTP/1.1 500 Internal Server Error
DATE: Thu, 01 Jan 1970 05:39:47 GMT
Connection: Keep-Alive
Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0
Content-Length: 466
Content-Type: text/xml; charset="utf-8"
EXT:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <s:Body>
  <s:Fault>
   <faultcode>s:Client</faultcode>
   <faultstring>UPnPError</faultstring>
   <detail>
    <UPnPError xmlns="urn:schemas-upnp-org:control-1-0">
     <errorCode>714</errorCode>
     <errorDescription>NoSuchEntryInArray</errorDescription>
    </UPnPError>
   </detail>
  </s:Fault>
 </s:Body>
</s:Envelope>

(15:05:39) network: Couldn't create UPnP mapping
(15:05:39) stun: using server 
(15:05:40) oscar: Sent message to (censored).
(15:05:59) oscar: Incoming rendezvous message of type 32, user (censored), status 0
(15:05:59) oscar: Remote user wants to try a different connection method

*************************************************************************** For some users, this results in a failure to send files, but for others a secondary server is used to send the file. This happens to many users that I know of. My router is a Belkin F5D7230-4 wireless g router.

[datallah]

I think this is what is happening:

• Pidgin->Router: Forward TCP connections on port 5190 to the local machine
• Router->Pidgin: Error! That port is already forwarded
• Pidgin->Router: Delete existing request to forward UDP connections on port 5190
• Router->Pidgin: Error! That port isn't currently being forwarded.

I think if we fix the "delete" to specify the correct connection protocol, that may fix the issue.

[datallah@…]

(In [aa651fe1eac8c4bd79a37a2fdfb5e528dc759b07]) Store the socket_type in the PurpleNetworkListenData? correctly so that callback functions can use it correctly. Fixes #2933.