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)
This undoes most of the changes made in 37233553a4 as the problem with the drops was only mitigated.
The actual fix for the dropped packets was in e989f475a1 and the invalid initialization was the root cause
