Alex, Some firewall do not let UDP in or out. The advantage with TCP is even if you have a very restricted firewall on one side, the outbound connection will look like a normal tcp open to it and it will allow the connection to form.
True, we just do not want another application to use that port. But we do use the native tcp stack in the connection setup so we do not have to generate all the packets. Jeff -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Pevzner Sent: Friday, December 15, 2006 4:20 PM To: theory and practice of decentralized computer networks Subject: [p2p-hackers] Re: A new approach to NAT/Firewall traversal Jeff Capone wrote: > Actually, 2 simultanous opens rarely works from what we have seen > since it is unlikely that the SYN packets from both sides will make it > through. It is possible, that on one side, since a SYN when out, the > SYN from the other side may make it in, but that is not typically the > case. So to gurantee that the SYN makes it in, we send it through the > out of band channel and inject it into the adapter so the TCP layer > thinks it actually made it through the firewall. The OS TCP layer > will even send the SYN-ACK. Once the control information is passed > through to the TCP stack of the OS, it will not see any of the actual > traffic, just keep alive traffic. Our stack will manage the traffic at this point forward. I just wonder, if you have your own TCP stack, why bother with sending the proper SYN packets to the OS-native TCP stack? You might simply use TCP "as UDP" to fool the routers. I mean, you might use TCP packets (generated and processed by your own stack) as UDP packets usually used, and you only need to maintain the valid SYN/ACK/FIN flags and sequence numbers to make router an illusion that it sees the normal TCP stream. At this case there is only one interference with the native TCP stack: you must reserve TCP port numbers in the native stack, that are actually used by your software. This is very easy to do, though... _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
