On Sat, Mar 10, 2007 at 01:37:01AM +0000, Michael Rogers wrote: > Matthew Toseland wrote: > > That's another interesting point: port rewriting. Right now we don't > > take any steps to identify our external port number, apart from using it > > as well as our real port number if we hear it from successful connectees. > > STUNT uses the following trick, based on the fact that most NATs > increase the external port number by 0, 1 or 2 for successive mappings > with the same internal address and port number: > > * Contact first STUNT server, learn external port p1 > * Contact second STUNT server, learn external port p2 > * Predicted port for next connection = p2 + (p2 - p1) > * Peers exchange their predicted ports out of band, then try to connect
For a symmetric NAT? Nice. > > This might also work with STUN - I'm not sure whether UDP mappings are > allocated in the same way but I don't see why they wouldn't be. However, > the predicted port doesn't stay fresh for very long unless p1 = p2 (full > cone), so it might not be very useful unless the peers have a > low-latency channel to exchange predicted ports (eg a mutual friend's node). p1 = p2 on anything except symmetric iirc. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20070310/4780ee3f/attachment.pgp>
