If a socket netdev parameter is already passed, don't touch the command
line. If it's not, add it, taking the id= reference from a netdev=
parameter, if any.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
The name-guessing loop should iterate over names, not single
characters. Also add /usr/libexec/qemu-kvm as full path for
execvp(): execvp() won't find it if it's not in $PATH, which
is the reason why it shouldn't be under /usr/libexec/, but this
seems to be the case for some current version of Fedora.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Once passt forks to background, it should be guaranteed that the UNIX
domain socket is available, otherwise, if qemu is started right after
it, it might fail to connect.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
It might be impractical to pass options to qrap when using libvirt,
because the <emulator/> tag expects a path to an executable, without
further arguments.
If the first argument is not a plausible socket number, and the
second argument is not a valid executable, look up a qemu command
from a list of possible names, then start it patching the command line
to include the -netdev fd= parameter corresponding to the AF_UNIX
domain socket we just opened.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
If net.ipv4.ping_group_range doesn't include our PID, we'll fail
to open sockets for ICMP and ICMPv6 echo. Warn instead of
exiting, this is not fatal.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Multiple arrays, one for each address, were needed with a single
fprintf(). Now that it's replaced by info(), we can have just one
for each protocol version.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
With glibc, we can't reliably build a static binary with
getprotobynumber(), which is currently used with -DDEBUG.
Replace that with a small array of protocol strings.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
This is in preparation for scatter-gather IO on the UDP receive path:
save a getsockname() syscall by setting a flag if we get the numbering
of all bound sockets in a strict sequence (expected, in practice) and
repurpose the tap buffer to be also a socket receive buffer, passing
it down to protocol handlers.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
As we support UDP forwarding for packets that are sent to local
ports, we actually need some kind of connection tracking for UDP.
While at it, this commit introduces a number of vaguely related fixes
for issues observed while trying this out. In detail:
- implement an explicit, albeit minimalistic, connection tracking
for UDP, to allow usage of ephemeral ports by the guest and by
the host at the same time, by binding them dynamically as needed,
and to allow mapping address changes for packets with a loopback
address as destination
- set the guest MAC address whenever we receive a packet from tap
instead of waiting for an ARP request, and set it to broadcast on
start, otherwise DHCPv6 might not work if all DHCPv6 requests time
out before the guest starts talking IPv4
- split context IPv6 address into address we assign, global or site
address seen on tap, and link-local address seen on tap, and make
sure we use the addresses we've seen as destination (link-local
choice depends on source address). Similarly, for IPv4, split into
address we assign and address we observe, and use the address we
observe as destination
- introduce a clock_gettime() syscall right after epoll_wait() wakes
up, so that we can remove all the other ones and pass the current
timestamp to tap and socket handlers -- this is additionally needed
by UDP to time out bindings to ephemeral ports and mappings between
loopback address and a local address
- rename sock_l4_add() to sock_l4(), no semantic changes intended
- include <arpa/inet.h> in passt.c before kernel headers so that we
can use <netinet/in.h> macros to check IPv6 address types, and
remove a duplicate <linux/ip.h> inclusion
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Seen with iperf3 server on tap side: connection state is SOCK_SYN_SENT,
we haven't got an ACK from the tap yet (that's why we're not in
ESTABLISHED), but a data packet comes. Don't read this data until we
reach the ESTABLISHED state, by keeping EPOLLIN disabled until that
point.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
...on a second thought, this won't really help with veth, and
actually causes a significant overhead as we get EPOLLERR whenever
another process is tapping on the traffic.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Avoid a bunch of syscalls on forwarding paths by:
- storing minimum and maximum file descriptor numbers for each
protocol, fall back to SO_PROTOCOL query only on overlaps
- allocating a larger receive buffer -- this can result in more
coalesced packets than sendmmsg() can take (UIO_MAXIOV, i.e. 1024),
so make sure we don't exceed that within a single call to protocol
tap handlers
- nesting the handling loop in tap_handler() in the receive loop,
so that we have better chances of filling our receive buffer in
fewer calls
- skipping the recvfrom() in the UDP handler on EPOLLERR -- there's
nothing to be done in that case
and while at it:
- restore the 20ms timer interval for periodic (TCP) events, I
accidentally changed that to 100ms in an earlier commit
- attempt using SO_ZEROCOPY for UDP -- if it's not available,
sendmmsg() will succeed anyway
- fix the handling of the status code from sendmmsg(), if it fails,
we'll try to discard the first message, hence return 1 from the
UDP handler
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Otherwise, buffers for UNIX domain sockets are limited to about
200KB. This makes performance testing a bit more consistent.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
It looks like some versions of ISC's IPv6 dhclient not only discard
the DNS Recursive Name Server option if other options (Domain Search
List? FQDN?) are absent, but they also drop existing entries
configured via SLAAC from /etc/resolv.conf.
Don't pass option 23 until I figure this out, it's anyway redundant
as we pass DNS information via SLAAC (RFC 8106).
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
This is symmetric with tap operation and addressing model, and
allows again to reach the guest behind the tap interface by
contacting the local address.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Receive packets in batches from AF_UNIX, check if they can be sent
with a single syscall, and batch them up with sendmmsg() in case.
A bit rudimentary, currently only implemented for UDP, but it seems
to work.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
dhcpv6_opt() needs to subtract option length _before_ returning,
so that callers can conveniently pass the remaining length on
subsequent calls.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
The NotOnLink status code needs to be appended to the existing IA
content, because if we omit the requested addresses in the reply,
ISC's dhclient handles it as a NoAddrsAvail response.
Also fix length accounting (we would send a bunch of zeroes after
the IA otherwise), and print an informational message with the
requested address, if it's not appropriate for the link.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
This implementation, similarly to the IPv4 DHCP one, hands out a
single address, which is the same as the upstream address for the
host.
This avoids the need for address translation as long as the client
runs a DHCPv6 client. The NDP "Managed" flag is now set in Router
Advertisements.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
For simplicity, we just send all available options, so there's no
distinction between forced and requested option anymore.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
...and mention it in the README.
While at it, remove useless escaping in the README, and fix
indentation in the syslog message with the qemu command line
example.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
...otherwise, both IPv4 and IPv6 are considered disabled, and nothing
works anymore.
While at it, don't fork to background on debug builds, and log to
stderr too in that case.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Default value for /proc/sys/fs/nr_open is 2^20, which is more than
enough: set this hard limit as current (soft) limit on start, and
drop the 'ulimit -n' from the demo script.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
...and, while at it, a second patch to fail when connect() fails in turn
with EINVAL. These two patches haven't been sent upstream yet.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
It's nice to be able to confirm connectivity using ICMP or ICMPv6
echo requests, and "ping" sockets on Linux (IPPROTO_ICMP datagram)
allow us to do that without any special capability.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
We don't need to keep small data as static variables, move the only
small variable we have so far to the new struct.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
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>
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>
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>
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>
