p2psp team mailing list archive

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

On Thu, Jul 23, 2015 at 10:32 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

>  Hi everyone,
>
> now continuous hello packets between peers are implemented as well, next
> thing is the port prediction for sequentially allocating NATs.
> When testing the code, I noticed that the SYMPP<->SYMPP combination "does
> not work", i.e. the peers (apart from monitor) do not receive packets from
> each other.
> Theoretically it should work like this:
>
>    - peer1, port 1234 sends "hello" to peer2, port 2345
>     - NAT entry is created at peer1, but packet does not reach peer2
>    because its NAT does not know peer1
>    - peer2, port 2345 sends "hello" to peer1, port 1234
>    - NAT entry is created at peer2, and packet reaches peer1 because a
>    NAT entry was created before
>
> But when testing this on the virtual machines, the peers (apart from
> monitor) sometimes (i.e. in some test runs) do not receive any packet from
> each other, although hello packets are sent continuously from both sides.
> When running the nts_tests program with a splitter and two peers, I get
> the same result, that sometimes the peers receive messages from each other,
> and in some test runs not.
> The NAT entries of exactly the same test (nts_tests) run twice are as
> follows (output of netstat-nat):
> NAT of peer 1 when the connection works:
>
> Proto NATed Address                  Destination Address            State
> udp   192.168.56.4:12252             192.168.57.6:12252
> ASSURED    # to splitter
> udp   192.168.56.4:12252             192.168.57.5:12252
> ASSURED    # to peer 2
>
> NAT of peer 2:
>
> Proto NATed Address                  Destination Address            State
> udp   192.168.58.5:12252             192.168.57.6:12252
> ASSURED    # to splitter
> udp   192.168.58.5:12252             192.168.57.4:12252
> ASSURED    # to peer 1
>
> NAT of peer 1 when the connection does not work:
>
> Proto NATed Address                  Destination Address            State
> udp   192.168.56.4:11242             192.168.57.6:11242
> ASSURED    # to splitter
> udp   192.168.56.4:11242             192.168.57.5:11242
> UNREPLIED  # to peer 2
>
> NAT of peer 2:
>
> Proto NATed Address                  Destination Address            State
> udp   192.168.58.5:11242             192.168.57.6:11242
> ASSURED    # to splitter
> udp   192.168.58.5:11242             192.168.57.4:11242
> UNREPLIED  # to peer 1
>
> So something seems to be wrong in the NAT simulation. As packets are sent
> continuously between the peers to the correct ports, either I completely
> overlooked something or there has to be a bug in the linux
> netfilter/masquerading modules. The python network stack or the virtual
> machines cannot be the reason because the issue is NAT type specific. What
> do you think about this?
>
>
Hi again,

could be a problem of network congestion (using UDP sometimes routers and
NAT devices drop packets if they arrive without pause)? Maybe a time-stamp
in the debug outputs (such as the one you sent in your previous email)
could help.

Sorry, now I have not any other idea ...

Regards,
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