On Thu, Jul 23, 2015 at 10:32 PM Max Mertens <[email protected]> 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: [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
