aboutgitcodebugslistschat
path: root/tcp.c
Commit message (Collapse)AuthorAgeFilesLines
* tcp: Introduce hash table for socket lookup for packets from tapStefano Brivio2021-03-171-35/+169
| | | | | | | | | | | | | | | Replace the dummy, full array scan implementation, by a hash table based on SipHash, with chained hashing for collisions. This table is also statically allocated, and it's simply an array of socket numbers. Connection entries are chained by pointers in the connection entry itself, which now also contains socket number and hash bucket index to keep removal reasonably fast. New entries are inserted at the head of the chain, that is, the most recently inserted entry is directly mapped from the bucket. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* tcp: Ignore out-of-order ACKs from tap instead of resetting connectionStefano Brivio2021-03-171-22/+11
| | | | | | | | | | | | | | | | | | | | We might receive out-of-order ACK packets from the tap device, just like any other packet. I guess I've been overcautious and regarded it as a condition we can't recover from, but all that happens is that we have already seen a higher ACK sequence number, which means that data has been already received and discarded from the buffer. We have to ignore the lower sequence number we receive later, though, because that would force the buffer bookkeeping into throwing away more data than expected. Drop the ACK sequence assignment from tcp_tap_handler(), which was redundant, and let tcp_sock_consume() take exclusive care of that. Now that tcp_sock_consume() can never fail, make it a void, and drop checks from callers. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* tcp: Add siphash implementation for initial sequence numbersStefano Brivio2021-03-171-7/+71
| | | | | | | | | | | | | Implement siphash routines for initial TCP sequence numbers (12 bytes input for IPv4, 36 bytes input for IPv6), and while at it, also functions we'll use later on for hash table indices and TCP timestamp offsets (with 8, 20, 32 bytes of input). Use these to set the initial sequence number, according to RFC 6528, for connections originating either from the tap device or from sockets. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* passt: Assorted fixes from "fresh eyes" reviewStefano Brivio2021-02-211-351/+325
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A bunch of fixes not worth single commits at this stage, notably: - make buffer, length parameter ordering consistent in ARP, DHCP, NDP handlers - strict checking of buffer, message and option length in DHCP handler (a malicious client could have easily crashed it) - set up forwarding for IPv4 and IPv6, and masquerading with nft for IPv4, from demo script - get rid of separate slow and fast timers, we don't save any overhead that way - stricter checking of buffer lengths as passed to tap handlers - proper dequeuing from qemu socket back-end: I accidentally trashed messages that were bundled up together in a single tap read operation -- the length header tells us what's the size of the next frame, but there's no apparent limit to the number of messages we get with one single receive - rework some bits of the TCP state machine, now passive and active connection closes appear to be robust -- introduce a new FIN_WAIT_1_SOCK_FIN state indicating a FIN_WAIT_1 with a FIN flag from socket - streamline TCP option parsing routine - track TCP state changes to stderr (this is temporary, proper debugging and syslogging support pending) - observe that multiplying a number by four might very well change its value, and this happens to be the case for the data offset from the TCP header as we check if it's the same as the total length to find out if it's a duplicated ACK segment - recent estimates suggest that the duration of a millisecond is closer to a million nanoseconds than a thousand of them, this trend is now reflected into the timespec_diff_ms() convenience routine Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
* passt: New design and implementation with native Layer 4 socketsStefano Brivio2021-02-161-0/+1367
This is a reimplementation, partially building on the earlier draft, that uses L4 sockets (SOCK_DGRAM, SOCK_STREAM) instead of SOCK_RAW, providing L4-L2 translation functionality without requiring any security capability. Conceptually, this follows the design presented at: https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Networking.md The most significant novelty here comes from TCP and UDP translation layers. In particular, the TCP state and translation logic follows the intent of being minimalistic, without reimplementing a full TCP stack in either direction, and synchronising as much as possible the TCP dynamic and flows between guest and host kernel. Another important introduction concerns addressing, port translation and forwarding. The Layer 4 implementations now attempt to bind on all unbound ports, in order to forward connections in a transparent way. While at it: - the qemu 'tap' back-end can't be used as-is by qrap anymore, because of explicit checks now introduced in qemu to ensure that the corresponding file descriptor is actually a tap device. For this reason, qrap now operates on a 'socket' back-end type, accounting for and building the additional header reporting frame length - provide a demo script that sets up namespaces, addresses and routes, and starts the daemon. A virtual machine started in the network namespace, wrapped by qrap, will now directly interface with passt and communicate using Layer 4 sockets provided by the host kernel. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>