When a lot of monodirection traffic is sent, p2p can be hard to
enstablish because a reply is needed in order to start the registration.
Now a sending peer can query the peer information via the supernode.
This is based on the following commits:
- 1236f37a70
- ad2d416510
- 5348671299
- b2806dcde8
The edge received packets from the supernode and thought that the other
peer was still active, but the other peer had dropped the p2p connection
due to refresh
If A is directly available and B is NATted and B sends the first message to A via the supernode S,
A will try to register to B via the port used by B to talk to S. This will not work as B is NAT-ted,
so A must discard such pending registration as soon as it receives a P2P Registration from B.
- The edge structure is now opaque
- The configuration is now exposed via an API
- Code cleanup: using multiple transops at once is not supported anymore
This implements the changes discussed in #68 and #72.
This breaks compatibility with the previous AES implementation.
This also fixes two problems reported by valgrind:
==4887== Invalid write of size 2
==4887== at 0x483E9DB: memmove (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4887== by 0x10E37F: setup_aes_key (transform_aes.c:378)
==4887== by 0x10E451: add_aes_key (transform_aes.c:401)
==4887== by 0x10ED10: transop_aes_setup_psk (transform_aes.c:580)
==4887== by 0x10A547: main (benchmark.c:92)
==4887== Address 0x4d574a0 is 0 bytes after a block of size 16 alloc'd
==4887== at 0x4839B65: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4887== by 0x10E337: setup_aes_key (transform_aes.c:374)
==4887== by 0x10E451: add_aes_key (transform_aes.c:401)
==4887== by 0x10ED10: transop_aes_setup_psk (transform_aes.c:580)
==4887== by 0x10A547: main (benchmark.c:92)
==13057== Use of uninitialised value of size 8
==13057== at 0x49023B3: ??? (in /usr/lib/libcrypto.so.1.1)
==13057== by 0x490346A: AES_cbc_encrypt (in /usr/lib/libcrypto.so.1.1)
==13057== by 0x11270A: transop_encode_aes (transform_aes.c:230)
==13057== by 0x10F5CD: send_packet2net (edge_utils.c:1224)
==13057== by 0x10F813: readFromTAPSocket (edge_utils.c:1278)
==13057== by 0x1106A8: run_edge_loop (edge_utils.c:1596)
==13057== by 0x10B9F7: main (edge.c:701)
edge detects it and bypsses the supernode
deri@Lucas-iMac.local 132> ping 192.168.254.126
PING 192.168.254.126 (192.168.254.126): 56 data bytes
64 bytes from 192.168.254.126: icmp_seq=0 ttl=64 time=84.314 ms <<== via supernode
64 bytes from 192.168.254.126: icmp_seq=1 ttl=64 time=0.989 ms <<== local network announce detected
64 bytes from 192.168.254.126: icmp_seq=2 ttl=64 time=0.642 ms
64 bytes from 192.168.254.126: icmp_seq=3 ttl=64 time=0.727 ms
^C
--- 192.168.254.126 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.642/21.668/84.314/36.169 ms
