search

tomp2p / TomP2P

A P2P-based high performance key-value pair storage library
http://tomp2p.net
Apache License 2.0
438 stars 122 forks source link

UPnP port forwarding -- peer not listening to internal port set on the map port operation #40

Closed gsmachado closed 9 years ago

gsmachado commented 10 years ago

Either the peer also listens to a random internal port already set on the UPnP port map request operation, or TomP2P set the the port map request with the internal TCP/UDP port chosen by the peer (before making the UPnP port map request).

Nowadays, I think this is not being set, somehow. Please, investigate it.

remyers commented 9 years ago

I'm not sure if this is related. I have been having problems with UPnP not working with TomP2P and I have reason to believe it could be related to wepnp.

I created an issue over at the weupnp gh with the details. I wonder if using the PortMapper classes would be useful for TomP2P. Portmapper also uses the SBBI Router library as an alternative to weupnp and using SBBI portmapper works on my router (Linksys WRT610n), but weupnp doesn't.

If nothing else, it's a good way to test wepnp outside of TomP2P for anyone having WAN issues.

tbocek commented 9 years ago

On 08.11.2014 00:09, Richard Myers wrote:

I'm not sure if this is related. I have been having problems with UPnP not working with TomP2P and I have reason to believe it could be related to wepnp.

I created an issue over at the weupnp gh with the details. I wonder if using the PortMapper classes would be useful for TomP2P. Portmapper also uses the SBBI Router library as an alternative to weupnp and using SBBI portmapper works on my router (Linksys WRT610n), but weupnp doesn't.

Before using weupnp, I was maintaining an own version of the SBBI UPNP library. I had also a couple of issues, mainly releated to timeouts. But looking at the code, the weupnp code looks much cleaner than SBBI. If you could capture the traffic with wireshark, we could see what messages go over the wire. Ideally if you could capture a working version with SBBI and a non-working version with weupnp, then we might identify the problem. I think its either a timeout issue, or the parsing goes wrong due to some unforseen characters.

Regards,

Thomas

remyers commented 9 years ago

Hi Thomas, I'm not too familiar with wireshark, but I have recorded three sessions, one with weupnp (not working) and one with SBBI (working) using portmapper 1.95, and one with bitsquare (latest build) using tomp2p. Let me know if there are any options you'd like me to turn on. The bitsquare one might be harder to parse, I haven't looked for the uPnP initiation messages yet. The gateway should be 10.10.1.1 and host computer is 10.10.1.102 .

Thanks!

weupnp is here sbbi is here bitsquare uPnP failure

tbocek commented 9 years ago

Hi Richard,

I could open the pcap files and the SBBI version looks as it should be, a M-SEARCH messages with SSDP to IP 239.255.255.250, then a repyl, then again a GET /InternetGatewayDevice and so on.

The weupnp did not even send out the very first SSDP message. If you check the code in GatewayDiscover, line 119, this packet should go out, but it does not. Without digging into much details, I would say an exception occurs somewhere in that region, which gets silently dropped.

Can you set a breakpoint at line 112 in GatewayDiscover and see where it fails? (you can do this with bitsquare/tomp2p as its using weupnp as well)

Thanks,

Thomas

On 08.11.2014 23:54, Richard Myers wrote:

Hi Thomas, I'm not too familiar with wireshark, but I have recorded three sessions, one with weupnp (not working) and one with SBBI (working) using portmapper 1.95, and one with bitsquare (latest build) using tomp2p. Let me know if there are any options you'd like me to turn on. The bitsquare one might be harder to parse, I haven't looked for the uPnP initiation messages yet. The gateway should be 10.10.1.1 and host computer is 10.10.1.102 .

Thanks!

weupnp is here sbbi is here [bitsquare uPnP failure)(https://drive.google.com/file/d/0B3mH1-U7kxwHRUFxVGJBd0pfVlE/view?usp=sharing)

Reply to this email directly or view it on GitHub: https://github.com/tomp2p/TomP2P/issues/40#issuecomment-62282148

remyers commented 9 years ago

Probably related to #61 and can be closed. Sounds like Manfred managed to figure out that it was related to interface order.

tbocek commented 9 years ago

Most likely yes, the symptoms fit.