p2psp team mailing list archive

[Vicente Gonzalez <vicente.gonzalez.ruiz@xxxxxxxxx>]

On Mon, Aug 17, 2015 at 3:04 PM Max Mertens <max.mail@xxxxxxxxxx> 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: vruiz@xxxxxx
http://www.ual.es/~vruiz
tel: +34 950 015711
fax: +34 950 015486