On Mon, Aug 17, 2015 at 3:04 PM Max Mertens <[email protected]> wrote:
> Hi Vicente, > Hello Max! > > I tested the mobile internet, and apparently it implements a cone NAT > (probably a PRCN) so it has the same source port for every destination > endpoint. > This result has been surprising for me, but your are right. It seems that most mobile ISP uses a PRCN. I have run the test on my wife's network (Vodafone) and this is the result: ********************** *Here are the results of the test:* *UPnP Test (?):*No UPnP device found *STUN Test (?):*Port Address Restricted Cone NAT *UDP Binding Test (?):**Endpoint independent binding*, port prediction is easy*TCP Binding Test:**Endpoint independent binding*, port prediction is easy *UDP Mapping Test (?):*your external IP address was different from your local one *(NAT)*. Your external source ports were preserved on every connection.*TCP Mapping Test:*your external IP address was different from your local one *(NAT)* Your external source ports were preserved on every connection. *SIP ALG (?):*The initial SIP INVITE packet has not been modified on its way to our servers. *There is no SIP ALG involved**FTP ALG:*The initial FTP PORT command has been modified. Most probably, *your NAT implements a FTP-ALG* *UDP Hole Punching (?):*High TTL Test was *not successful*Low TTL Test was *successful*Silent Test was *not successful**TCP Hole Punching:*High TTL Test was *not successful*Silent Test was *not successful* *UDP Timeout (?):*Your UDP timeout is approx. 14 seconds This could be a problem if an application doesn't send enough keep alive packets. ********************** > As the connection was a bit slow, I had to increase the timeouts. With the > splitter and 2 monitor peers on the university server, one peer via DSL and > one peer via mobile internet, the NAT traversal between the peers worked. > When adding another peer in a virtual machine behind a SYMRP NAT > (unpredictable source port) to the team, the other peers could not connect > to it, as to be expected. > The free VPN services that I tried (and that were usable for tunneling the > hole networking) had symmetric NATs with random source ports, so a peer > could only connect to splitter, monitor peers and peers behind a FCN or RCN > NAT. > Do you suggest other testing combinations or methods? > > No, I can't imagine any other technique that could help with dealing with random-SYM NATs. Sorry. Maybe, some kind of try-and-if-it-fails-try-again method :-/ Well, this project has been a difficult one (it has a lot of research work and possible results). Therefore, the documentation is as important as (or even more than) the code. We (I and the rest of mentors of P2PSP) also think that your work could be published in a conference (such as the International Conference on Computer Communication and Networks <http://icccn.org/icccn15/>) or even a journal (an example could be: Computer Networks <http://www.sciencedirect.com/science/journal/13891286>), and we would delight if you collaborate with us in this task. What do you think (of course, this will not affect to our work/evaluation/results for the GSoC)? It would be great if it would be published in some way, as other P2P > software could also benefit from the NAT traversal methods; > Fantastic! > I would like to collaborate with you in this. > Last week I also thought about maybe putting the implemented methods into > a portable NAT traversal C library, to embed in P2P applications. > Yes, of course. > > The updated task list can be found here [1]; the only coding task left for > this week is the determination of the currently allocated source port for > incorporated peer behind a SYMSP NAT, which is needed if a new peer arrives > a long time after the last peer has arrived (so there could be many source > port skips). > > OK. > In the last days I added a script to setup a network with NATs in Linux > namespaces, which works much smoother than with VMs; also the test script > now supports parallel test runs. During testing, I created another script > that runs a team and filters/colorizes the output (as you saw in the > terminal recording); I would add that to the tools/ subdirectory, if you > could need this. > > I'm sure both tools will be help us in the future. Thanks! Best, Vicente. -- -- Vicente González Ruiz Depto de Informática Escuela Técnica Superior de Ingeniería Universidad de Almería Carretera Sacramento S/N 04120, La Cañada de San Urbano Almería, España e-mail: [email protected] http://www.ual.es/~vruiz tel: +34 950 015711 fax: +34 950 015486
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
