p2psp team mailing list archive

[Max Mertens <max.mail@xxxxxxxxxx>]

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?


Nevertheless, I added new test result tables below. The entry marked in
bold red is the one that should work in the current implementation, but
results in a "no" because of the issue above.
The entry marked in green should work when the detection of sequential
port allocation is implemented.

Thanks,
Max



Previously possible combinations (branch nts, commit 0595dc3):

    Peer1\2 | fcn/rcn | prcn  | sympp | symsp | symrp
    ================================================
    fcn/rcn | yes     | yes   | no    | no    | yes
    prcn    | yes     | yes   | no    | no    | no
    sympp   | no      | yes   | no    | no    | no
    symsp   | no      | no    | no    | no    | no
    symrp   | yes     | no    | no    | no    | no


Currently possible combinations (branch nts, commit 8b28afa):

    Peer1\2 | fcn/rcn | prcn  | sympp | symsp | symrp
    ================================================
    fcn/rcn | yes     | yes   | yes   | yes   | yes
    prcn    | yes     | yes   | yes   | yes   | no
    sympp   | yes     | yes   | *no*    | *no*    | no
    symsp   | yes     | no    | no    | no    | no
    symrp   | yes     | no    | no    | no    | no


Theoretically possible combinations:

    Peer1\2 | fcn/rcn | prcn  | sympp | symsp | symrp
    ==================================================
    fcn/rcn | yes     | yes   | yes   | yes   | yes
    prcn    | yes     | yes   | yes   | yes   | no
    sympp   | yes     | yes   | *yes*   | *yes*   | no
    symsp   | yes     | (yes) | (yes) | (yes) | no
    symrp   | yes     | no    | no    | no    | no