passt: New design and implementation with native Layer 4 sockets
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>
2021-02-16 07:25:09 +01:00
|
|
|
// SPDX-License-Identifier: AGPL-3.0-or-later
|
|
|
|
|
2020-07-20 16:41:49 +02:00
|
|
|
/* PASST - Plug A Simple Socket Transport
|
passt: Add PASTA mode, major rework
PASTA (Pack A Subtle Tap Abstraction) provides quasi-native host
connectivity to an otherwise disconnected, unprivileged network
and user namespace, similarly to slirp4netns. Given that the
implementation is largely overlapping with PASST, no separate binary
is built: 'pasta' (and 'passt4netns' for clarity) both link to
'passt', and the mode of operation is selected depending on how the
binary is invoked. Usage example:
$ unshare -rUn
# echo $$
1871759
$ ./pasta 1871759 # From another terminal
# udhcpc -i pasta0 2>/dev/null
# ping -c1 pasta.pizza
PING pasta.pizza (64.190.62.111) 56(84) bytes of data.
64 bytes from 64.190.62.111 (64.190.62.111): icmp_seq=1 ttl=255 time=34.6 ms
--- pasta.pizza ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 34.575/34.575/34.575/0.000 ms
# ping -c1 spaghetti.pizza
PING spaghetti.pizza(2606:4700:3034::6815:147a (2606:4700:3034::6815:147a)) 56 data bytes
64 bytes from 2606:4700:3034::6815:147a (2606:4700:3034::6815:147a): icmp_seq=1 ttl=255 time=29.0 ms
--- spaghetti.pizza ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 28.967/28.967/28.967/0.000 ms
This entails a major rework, especially with regard to the storage of
tracked connections and to the semantics of epoll(7) references.
Indexing TCP and UDP bindings merely by socket proved to be
inflexible and unsuitable to handle different connection flows: pasta
also provides Layer-2 to Layer-2 socket mapping between init and a
separate namespace for local connections, using a pair of splice()
system calls for TCP, and a recvmmsg()/sendmmsg() pair for UDP local
bindings. For instance, building on the previous example:
# ip link set dev lo up
# iperf3 -s
$ iperf3 -c ::1 -Z -w 32M -l 1024k -P2 | tail -n4
[SUM] 0.00-10.00 sec 52.3 GBytes 44.9 Gbits/sec 283 sender
[SUM] 0.00-10.43 sec 52.3 GBytes 43.1 Gbits/sec receiver
iperf Done.
epoll(7) references now include a generic part in order to
demultiplex data to the relevant protocol handler, using 24
bits for the socket number, and an opaque portion reserved for
usage by the single protocol handlers, in order to track sockets
back to corresponding connections and bindings.
A number of fixes pertaining to TCP state machine and congestion
window handling are also included here.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-07-17 08:34:53 +02:00
|
|
|
* for qemu/UNIX domain socket mode
|
|
|
|
*
|
|
|
|
* PASTA - Pack A Subtle Tap Abstraction
|
|
|
|
* for network namespace/tap device mode
|
2020-07-20 16:27:43 +02:00
|
|
|
*
|
2020-07-20 16:41:49 +02:00
|
|
|
* dhcp.c - Minimalistic DHCP server for PASST
|
2020-07-20 16:27:43 +02:00
|
|
|
*
|
passt: New design and implementation with native Layer 4 sockets
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>
2021-02-16 07:25:09 +01:00
|
|
|
* Copyright (c) 2020-2021 Red Hat GmbH
|
2020-07-20 16:27:43 +02:00
|
|
|
* Author: Stefano Brivio <sbrivio@redhat.com>
|
|
|
|
*/
|
|
|
|
|
2021-10-21 04:26:08 +02:00
|
|
|
#include <arpa/inet.h>
|
|
|
|
#include <net/if.h>
|
|
|
|
#include <netinet/if_ether.h>
|
|
|
|
#include <netinet/ip.h>
|
|
|
|
#include <netinet/udp.h>
|
2020-07-20 16:27:43 +02:00
|
|
|
#include <stddef.h>
|
2021-10-21 04:26:08 +02:00
|
|
|
#include <stdio.h>
|
2020-07-20 16:27:43 +02:00
|
|
|
#include <stdint.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <string.h>
|
treewide: Packet abstraction with mandatory boundary checks
Implement a packet abstraction providing boundary and size checks
based on packet descriptors: packets stored in a buffer can be queued
into a pool (without storage of its own), and data can be retrieved
referring to an index in the pool, specifying offset and length.
Checks ensure data is not read outside the boundaries of buffer and
descriptors, and that packets added to a pool are within the buffer
range with valid offset and indices.
This implies a wider rework: usage of the "queueing" part of the
abstraction mostly affects tap_handler_{passt,pasta}() functions and
their callees, while the "fetching" part affects all the guest or tap
facing implementations: TCP, UDP, ICMP, ARP, NDP, DHCP and DHCPv6
handlers.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-03-25 13:02:47 +01:00
|
|
|
#include <limits.h>
|
2021-10-21 04:26:08 +02:00
|
|
|
|
passt: Add PASTA mode, major rework
PASTA (Pack A Subtle Tap Abstraction) provides quasi-native host
connectivity to an otherwise disconnected, unprivileged network
and user namespace, similarly to slirp4netns. Given that the
implementation is largely overlapping with PASST, no separate binary
is built: 'pasta' (and 'passt4netns' for clarity) both link to
'passt', and the mode of operation is selected depending on how the
binary is invoked. Usage example:
$ unshare -rUn
# echo $$
1871759
$ ./pasta 1871759 # From another terminal
# udhcpc -i pasta0 2>/dev/null
# ping -c1 pasta.pizza
PING pasta.pizza (64.190.62.111) 56(84) bytes of data.
64 bytes from 64.190.62.111 (64.190.62.111): icmp_seq=1 ttl=255 time=34.6 ms
--- pasta.pizza ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 34.575/34.575/34.575/0.000 ms
# ping -c1 spaghetti.pizza
PING spaghetti.pizza(2606:4700:3034::6815:147a (2606:4700:3034::6815:147a)) 56 data bytes
64 bytes from 2606:4700:3034::6815:147a (2606:4700:3034::6815:147a): icmp_seq=1 ttl=255 time=29.0 ms
--- spaghetti.pizza ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 28.967/28.967/28.967/0.000 ms
This entails a major rework, especially with regard to the storage of
tracked connections and to the semantics of epoll(7) references.
Indexing TCP and UDP bindings merely by socket proved to be
inflexible and unsuitable to handle different connection flows: pasta
also provides Layer-2 to Layer-2 socket mapping between init and a
separate namespace for local connections, using a pair of splice()
system calls for TCP, and a recvmmsg()/sendmmsg() pair for UDP local
bindings. For instance, building on the previous example:
# ip link set dev lo up
# iperf3 -s
$ iperf3 -c ::1 -Z -w 32M -l 1024k -P2 | tail -n4
[SUM] 0.00-10.00 sec 52.3 GBytes 44.9 Gbits/sec 283 sender
[SUM] 0.00-10.43 sec 52.3 GBytes 43.1 Gbits/sec receiver
iperf Done.
epoll(7) references now include a generic part in order to
demultiplex data to the relevant protocol handler, using 24
bits for the socket number, and an opaque portion reserved for
usage by the single protocol handlers, in order to track sockets
back to corresponding connections and bindings.
A number of fixes pertaining to TCP state machine and congestion
window handling are also included here.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-07-17 08:34:53 +02:00
|
|
|
#include "util.h"
|
2021-10-21 04:26:08 +02:00
|
|
|
#include "checksum.h"
|
treewide: Packet abstraction with mandatory boundary checks
Implement a packet abstraction providing boundary and size checks
based on packet descriptors: packets stored in a buffer can be queued
into a pool (without storage of its own), and data can be retrieved
referring to an index in the pool, specifying offset and length.
Checks ensure data is not read outside the boundaries of buffer and
descriptors, and that packets added to a pool are within the buffer
range with valid offset and indices.
This implies a wider rework: usage of the "queueing" part of the
abstraction mostly affects tap_handler_{passt,pasta}() functions and
their callees, while the "fetching" part affects all the guest or tap
facing implementations: TCP, UDP, ICMP, ARP, NDP, DHCP and DHCPv6
handlers.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-03-25 13:02:47 +01:00
|
|
|
#include "packet.h"
|
2020-07-20 16:41:49 +02:00
|
|
|
#include "passt.h"
|
passt: New design and implementation with native Layer 4 sockets
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>
2021-02-16 07:25:09 +01:00
|
|
|
#include "tap.h"
|
2022-09-24 09:53:15 +02:00
|
|
|
#include "log.h"
|
2021-10-21 04:26:08 +02:00
|
|
|
#include "dhcp.h"
|
2020-07-20 16:27:43 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* struct opt - DHCP option
|
|
|
|
* @sent: Convenience flag, set while filling replies
|
|
|
|
* @slen: Length of option defined for server
|
|
|
|
* @s: Option payload from server
|
|
|
|
* @clen: Length of option received from client
|
|
|
|
* @c: Option payload from client
|
|
|
|
*/
|
|
|
|
struct opt {
|
|
|
|
int sent;
|
|
|
|
int slen;
|
2022-02-28 22:17:32 +01:00
|
|
|
uint8_t s[255];
|
2020-07-20 16:27:43 +02:00
|
|
|
int clen;
|
2022-02-28 22:17:32 +01:00
|
|
|
uint8_t c[255];
|
2020-07-20 16:27:43 +02:00
|
|
|
};
|
|
|
|
|
2021-10-05 21:15:01 +02:00
|
|
|
static struct opt opts[255];
|
|
|
|
|
2020-07-20 16:27:43 +02:00
|
|
|
#define DHCPDISCOVER 1
|
|
|
|
#define DHCPOFFER 2
|
|
|
|
#define DHCPREQUEST 3
|
|
|
|
#define DHCPDECLINE 4
|
|
|
|
#define DHCPACK 5
|
|
|
|
#define DHCPNAK 6
|
|
|
|
#define DHCPRELEASE 7
|
|
|
|
#define DHCPINFORM 8
|
|
|
|
#define DHCPFORCERENEW 9
|
2021-10-05 21:15:01 +02:00
|
|
|
|
2022-03-25 08:32:55 +01:00
|
|
|
#define OPT_MIN 60 /* RFC 951 */
|
|
|
|
|
2021-10-05 21:15:01 +02:00
|
|
|
/**
|
|
|
|
* dhcp_init() - Initialise DHCP options
|
|
|
|
*/
|
|
|
|
void dhcp_init(void)
|
|
|
|
{
|
|
|
|
opts[1] = (struct opt) { 0, 4, { 0 }, 0, { 0 }, }; /* Mask */
|
|
|
|
opts[3] = (struct opt) { 0, 4, { 0 }, 0, { 0 }, }; /* Router */
|
|
|
|
opts[51] = (struct opt) { 0, 4, { 0xff,
|
|
|
|
0xff,
|
|
|
|
0xff,
|
|
|
|
0xff }, 0, { 0 }, }; /* Lease time */
|
|
|
|
opts[53] = (struct opt) { 0, 1, { 0 }, 0, { 0 }, }; /* Type */
|
|
|
|
opts[54] = (struct opt) { 0, 4, { 0 }, 0, { 0 }, }; /* Server ID */
|
|
|
|
}
|
2020-07-20 16:27:43 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* struct msg - BOOTP/DHCP message
|
|
|
|
* @op: BOOTP message type
|
|
|
|
* @htype: Hardware address type
|
|
|
|
* @hlen: Hardware address length
|
|
|
|
* @hops: DHCP relay hops
|
|
|
|
* @xid: Transaction ID randomly chosen by client
|
|
|
|
* @secs: Seconds elapsed since beginning of acquisition or renewal
|
|
|
|
* @flags: DHCP message flags
|
|
|
|
* @ciaddr: Client IP address in BOUND, RENEW, REBINDING
|
|
|
|
* @yiaddr: IP address being offered or assigned
|
|
|
|
* @siaddr: Next server to use in bootstrap
|
|
|
|
* @giaddr: Relay agent IP address
|
|
|
|
* @chaddr: Client hardware address
|
|
|
|
* @sname: Server host name
|
|
|
|
* @file: Boot file name
|
|
|
|
* @magic: Magic cookie prefix before options
|
|
|
|
* @o: Options
|
|
|
|
*/
|
|
|
|
struct msg {
|
|
|
|
uint8_t op;
|
|
|
|
#define BOOTREQUEST 1
|
|
|
|
#define BOOTREPLY 2
|
|
|
|
uint8_t htype;
|
|
|
|
uint8_t hlen;
|
|
|
|
uint8_t hops;
|
|
|
|
uint32_t xid;
|
|
|
|
uint16_t secs;
|
|
|
|
uint16_t flags;
|
|
|
|
uint32_t ciaddr;
|
|
|
|
uint32_t yiaddr;
|
|
|
|
uint32_t siaddr;
|
|
|
|
uint32_t giaddr;
|
|
|
|
uint8_t chaddr[16];
|
|
|
|
uint8_t sname[64];
|
|
|
|
uint8_t file[128];
|
|
|
|
uint32_t magic;
|
|
|
|
uint8_t o[308];
|
|
|
|
} __attribute__((__packed__));
|
|
|
|
|
|
|
|
/**
|
|
|
|
* fill_one() - Fill a single option in message
|
|
|
|
* @m: Message to fill
|
|
|
|
* @o: Option number
|
|
|
|
* @offset: Current offset within options field, updated on insertion
|
|
|
|
*/
|
|
|
|
static void fill_one(struct msg *m, int o, int *offset)
|
|
|
|
{
|
|
|
|
m->o[*offset] = o;
|
|
|
|
m->o[*offset + 1] = opts[o].slen;
|
|
|
|
memcpy(&m->o[*offset + 2], opts[o].s, opts[o].slen);
|
|
|
|
|
|
|
|
opts[o].sent = 1;
|
|
|
|
*offset += 2 + opts[o].slen;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2021-03-26 12:19:56 +01:00
|
|
|
* fill() - Fill options in message
|
2020-07-20 16:27:43 +02:00
|
|
|
* @m: Message to fill
|
|
|
|
*
|
|
|
|
* Return: current size of options field
|
|
|
|
*/
|
|
|
|
static int fill(struct msg *m)
|
|
|
|
{
|
|
|
|
int i, o, offset = 0;
|
|
|
|
|
|
|
|
m->op = BOOTREPLY;
|
|
|
|
m->secs = 0;
|
|
|
|
|
|
|
|
for (o = 0; o < 255; o++)
|
|
|
|
opts[o].sent = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < opts[55].clen; i++) {
|
|
|
|
o = opts[55].c[i];
|
|
|
|
if (opts[o].slen)
|
|
|
|
fill_one(m, o, &offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (o = 0; o < 255; o++) {
|
|
|
|
if (opts[o].slen && !opts[o].sent)
|
|
|
|
fill_one(m, o, &offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
m->o[offset++] = 255;
|
|
|
|
m->o[offset++] = 0;
|
|
|
|
|
2022-03-25 08:32:55 +01:00
|
|
|
if (offset < OPT_MIN) {
|
|
|
|
memset(&m->o[offset], 0, OPT_MIN - offset);
|
|
|
|
offset = OPT_MIN;
|
2020-07-20 16:27:43 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
/**
|
|
|
|
* opt_dns_search_dup_ptr() - Look for possible domain name compression pointer
|
|
|
|
* @buf: Current option buffer with existing labels
|
|
|
|
* @cmp: Portion of domain name being added
|
|
|
|
* @len: Length of current option buffer
|
|
|
|
*
|
|
|
|
* Return: offset to corresponding compression pointer if any, -1 if not found
|
|
|
|
*/
|
2022-03-26 07:23:21 +01:00
|
|
|
static int opt_dns_search_dup_ptr(unsigned char *buf, const char *cmp,
|
|
|
|
size_t len)
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
for (i = 0; i < len; i++) {
|
|
|
|
if (buf[i] == 0 &&
|
|
|
|
len - i - 1 >= strlen(cmp) &&
|
|
|
|
!memcmp(buf + i + 1, cmp, strlen(cmp)))
|
|
|
|
return i;
|
|
|
|
|
|
|
|
if ((buf[i] & 0xc0) == 0xc0 &&
|
|
|
|
len - i - 2 >= strlen(cmp) &&
|
|
|
|
!memcmp(buf + i + 2, cmp, strlen(cmp)))
|
|
|
|
return i + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* opt_set_dns_search() - Fill data and set length for Domain Search option
|
|
|
|
* @c: Execution context
|
|
|
|
* @max_len: Maximum total length of option buffer
|
|
|
|
*/
|
2022-03-26 07:23:21 +01:00
|
|
|
static void opt_set_dns_search(const struct ctx *c, size_t max_len)
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
{
|
|
|
|
char buf[NS_MAXDNAME];
|
|
|
|
int i;
|
|
|
|
|
|
|
|
opts[119].slen = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < 255; i++)
|
|
|
|
max_len -= opts[i].slen;
|
|
|
|
|
|
|
|
for (i = 0; *c->dns_search[i].n; i++) {
|
|
|
|
unsigned int n;
|
2021-10-21 09:41:13 +02:00
|
|
|
int count = -1;
|
2022-03-26 07:23:21 +01:00
|
|
|
const char *p;
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
|
|
|
|
buf[0] = 0;
|
|
|
|
for (p = c->dns_search[i].n, n = 1; *p; p++) {
|
|
|
|
if (*p == '.') {
|
|
|
|
/* RFC 1035 4.1.4 Message compression */
|
2021-10-21 09:41:13 +02:00
|
|
|
count = opt_dns_search_dup_ptr(opts[119].s,
|
|
|
|
p + 1,
|
|
|
|
opts[119].slen);
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
|
2021-10-21 09:41:13 +02:00
|
|
|
if (count >= 0) {
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
buf[n++] = '\xc0';
|
2021-10-21 09:41:13 +02:00
|
|
|
buf[n++] = count;
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
break;
|
|
|
|
}
|
2021-10-20 00:05:11 +02:00
|
|
|
buf[n++] = '.';
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
} else {
|
|
|
|
buf[n++] = *p;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The compression pointer is also an end of label */
|
2021-10-21 09:41:13 +02:00
|
|
|
if (count < 0)
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
buf[n++] = 0;
|
|
|
|
|
|
|
|
if (n >= max_len)
|
|
|
|
break;
|
|
|
|
|
|
|
|
memcpy(opts[119].s + opts[119].slen, buf, n);
|
|
|
|
opts[119].slen += n;
|
|
|
|
max_len -= n;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < opts[119].slen; i++) {
|
|
|
|
if (!opts[119].s[i] || opts[119].s[i] == '.') {
|
|
|
|
opts[119].s[i] = strcspn((char *)opts[119].s + i + 1,
|
|
|
|
".\xc0");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-07-20 16:27:43 +02:00
|
|
|
/**
|
|
|
|
* dhcp() - Check if this is a DHCP message, reply as needed
|
|
|
|
* @c: Execution context
|
treewide: Packet abstraction with mandatory boundary checks
Implement a packet abstraction providing boundary and size checks
based on packet descriptors: packets stored in a buffer can be queued
into a pool (without storage of its own), and data can be retrieved
referring to an index in the pool, specifying offset and length.
Checks ensure data is not read outside the boundaries of buffer and
descriptors, and that packets added to a pool are within the buffer
range with valid offset and indices.
This implies a wider rework: usage of the "queueing" part of the
abstraction mostly affects tap_handler_{passt,pasta}() functions and
their callees, while the "fetching" part affects all the guest or tap
facing implementations: TCP, UDP, ICMP, ARP, NDP, DHCP and DHCPv6
handlers.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-03-25 13:02:47 +01:00
|
|
|
* @p: Packet pool, single packet with Ethernet buffer
|
2020-07-20 16:27:43 +02:00
|
|
|
*
|
|
|
|
* Return: 0 if it's not a DHCP message, 1 if handled, -1 on failure
|
|
|
|
*/
|
2022-03-26 07:23:21 +01:00
|
|
|
int dhcp(const struct ctx *c, const struct pool *p)
|
2020-07-20 16:27:43 +02:00
|
|
|
{
|
treewide: Packet abstraction with mandatory boundary checks
Implement a packet abstraction providing boundary and size checks
based on packet descriptors: packets stored in a buffer can be queued
into a pool (without storage of its own), and data can be retrieved
referring to an index in the pool, specifying offset and length.
Checks ensure data is not read outside the boundaries of buffer and
descriptors, and that packets added to a pool are within the buffer
range with valid offset and indices.
This implies a wider rework: usage of the "queueing" part of the
abstraction mostly affects tap_handler_{passt,pasta}() functions and
their callees, while the "fetching" part affects all the guest or tap
facing implementations: TCP, UDP, ICMP, ARP, NDP, DHCP and DHCPv6
handlers.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-03-25 13:02:47 +01:00
|
|
|
size_t mlen, len, offset = 0, opt_len, opt_off = 0;
|
|
|
|
struct ethhdr *eh;
|
|
|
|
struct iphdr *iph;
|
passt: Assorted fixes from "fresh eyes" review
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>
2021-02-21 11:33:38 +01:00
|
|
|
struct udphdr *uh;
|
|
|
|
unsigned int i;
|
|
|
|
struct msg *m;
|
|
|
|
|
treewide: Packet abstraction with mandatory boundary checks
Implement a packet abstraction providing boundary and size checks
based on packet descriptors: packets stored in a buffer can be queued
into a pool (without storage of its own), and data can be retrieved
referring to an index in the pool, specifying offset and length.
Checks ensure data is not read outside the boundaries of buffer and
descriptors, and that packets added to a pool are within the buffer
range with valid offset and indices.
This implies a wider rework: usage of the "queueing" part of the
abstraction mostly affects tap_handler_{passt,pasta}() functions and
their callees, while the "fetching" part affects all the guest or tap
facing implementations: TCP, UDP, ICMP, ARP, NDP, DHCP and DHCPv6
handlers.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-03-25 13:02:47 +01:00
|
|
|
eh = packet_get(p, 0, offset, sizeof(*eh), NULL);
|
|
|
|
offset += sizeof(*eh);
|
passt: Assorted fixes from "fresh eyes" review
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>
2021-02-21 11:33:38 +01:00
|
|
|
|
treewide: Packet abstraction with mandatory boundary checks
Implement a packet abstraction providing boundary and size checks
based on packet descriptors: packets stored in a buffer can be queued
into a pool (without storage of its own), and data can be retrieved
referring to an index in the pool, specifying offset and length.
Checks ensure data is not read outside the boundaries of buffer and
descriptors, and that packets added to a pool are within the buffer
range with valid offset and indices.
This implies a wider rework: usage of the "queueing" part of the
abstraction mostly affects tap_handler_{passt,pasta}() functions and
their callees, while the "fetching" part affects all the guest or tap
facing implementations: TCP, UDP, ICMP, ARP, NDP, DHCP and DHCPv6
handlers.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-03-25 13:02:47 +01:00
|
|
|
iph = packet_get(p, 0, offset, sizeof(*iph), NULL);
|
|
|
|
if (!eh || !iph)
|
|
|
|
return -1;
|
passt: Assorted fixes from "fresh eyes" review
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>
2021-02-21 11:33:38 +01:00
|
|
|
|
treewide: Packet abstraction with mandatory boundary checks
Implement a packet abstraction providing boundary and size checks
based on packet descriptors: packets stored in a buffer can be queued
into a pool (without storage of its own), and data can be retrieved
referring to an index in the pool, specifying offset and length.
Checks ensure data is not read outside the boundaries of buffer and
descriptors, and that packets added to a pool are within the buffer
range with valid offset and indices.
This implies a wider rework: usage of the "queueing" part of the
abstraction mostly affects tap_handler_{passt,pasta}() functions and
their callees, while the "fetching" part affects all the guest or tap
facing implementations: TCP, UDP, ICMP, ARP, NDP, DHCP and DHCPv6
handlers.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-03-25 13:02:47 +01:00
|
|
|
offset += iph->ihl * 4UL;
|
|
|
|
uh = packet_get(p, 0, offset, sizeof(*uh), &mlen);
|
|
|
|
offset += sizeof(*uh);
|
|
|
|
|
|
|
|
if (!uh)
|
|
|
|
return -1;
|
2020-07-20 16:27:43 +02:00
|
|
|
|
|
|
|
if (uh->dest != htons(67))
|
|
|
|
return 0;
|
|
|
|
|
2021-08-12 15:42:43 +02:00
|
|
|
if (c->no_dhcp)
|
|
|
|
return 1;
|
|
|
|
|
treewide: Packet abstraction with mandatory boundary checks
Implement a packet abstraction providing boundary and size checks
based on packet descriptors: packets stored in a buffer can be queued
into a pool (without storage of its own), and data can be retrieved
referring to an index in the pool, specifying offset and length.
Checks ensure data is not read outside the boundaries of buffer and
descriptors, and that packets added to a pool are within the buffer
range with valid offset and indices.
This implies a wider rework: usage of the "queueing" part of the
abstraction mostly affects tap_handler_{passt,pasta}() functions and
their callees, while the "fetching" part affects all the guest or tap
facing implementations: TCP, UDP, ICMP, ARP, NDP, DHCP and DHCPv6
handlers.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-03-25 13:02:47 +01:00
|
|
|
m = packet_get(p, 0, offset, offsetof(struct msg, o), &opt_len);
|
|
|
|
if (!m ||
|
|
|
|
mlen != ntohs(uh->len) - sizeof(*uh) ||
|
|
|
|
mlen < offsetof(struct msg, o) ||
|
2020-07-20 16:27:43 +02:00
|
|
|
m->op != BOOTREQUEST)
|
|
|
|
return -1;
|
|
|
|
|
treewide: Packet abstraction with mandatory boundary checks
Implement a packet abstraction providing boundary and size checks
based on packet descriptors: packets stored in a buffer can be queued
into a pool (without storage of its own), and data can be retrieved
referring to an index in the pool, specifying offset and length.
Checks ensure data is not read outside the boundaries of buffer and
descriptors, and that packets added to a pool are within the buffer
range with valid offset and indices.
This implies a wider rework: usage of the "queueing" part of the
abstraction mostly affects tap_handler_{passt,pasta}() functions and
their callees, while the "fetching" part affects all the guest or tap
facing implementations: TCP, UDP, ICMP, ARP, NDP, DHCP and DHCPv6
handlers.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-03-25 13:02:47 +01:00
|
|
|
offset += offsetof(struct msg, o);
|
|
|
|
|
|
|
|
while (opt_off + 2 < opt_len) {
|
|
|
|
uint8_t *olen, *type, *val;
|
|
|
|
|
|
|
|
type = packet_get(p, 0, offset + opt_off, 1, NULL);
|
|
|
|
olen = packet_get(p, 0, offset + opt_off + 1, 1, NULL);
|
|
|
|
if (!type || !olen)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
val = packet_get(p, 0, offset + opt_off + 2, *olen, NULL);
|
|
|
|
if (!val)
|
passt: Assorted fixes from "fresh eyes" review
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>
2021-02-21 11:33:38 +01:00
|
|
|
return -1;
|
|
|
|
|
treewide: Packet abstraction with mandatory boundary checks
Implement a packet abstraction providing boundary and size checks
based on packet descriptors: packets stored in a buffer can be queued
into a pool (without storage of its own), and data can be retrieved
referring to an index in the pool, specifying offset and length.
Checks ensure data is not read outside the boundaries of buffer and
descriptors, and that packets added to a pool are within the buffer
range with valid offset and indices.
This implies a wider rework: usage of the "queueing" part of the
abstraction mostly affects tap_handler_{passt,pasta}() functions and
their callees, while the "fetching" part affects all the guest or tap
facing implementations: TCP, UDP, ICMP, ARP, NDP, DHCP and DHCPv6
handlers.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-03-25 13:02:47 +01:00
|
|
|
memcpy(&opts[*type].c, val, *olen);
|
|
|
|
opt_off += *olen + 2;
|
passt: Assorted fixes from "fresh eyes" review
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>
2021-02-21 11:33:38 +01:00
|
|
|
}
|
2020-07-20 16:27:43 +02:00
|
|
|
|
|
|
|
if (opts[53].c[0] == DHCPDISCOVER) {
|
2021-03-18 07:49:08 +01:00
|
|
|
info("DHCP: offer to discover");
|
2020-07-20 16:27:43 +02:00
|
|
|
opts[53].s[0] = DHCPOFFER;
|
|
|
|
} else if (opts[53].c[0] == DHCPREQUEST) {
|
2021-03-18 07:49:08 +01:00
|
|
|
info("DHCP: ack to request");
|
2020-07-20 16:27:43 +02:00
|
|
|
opts[53].s[0] = DHCPACK;
|
|
|
|
} else {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2021-03-18 07:49:08 +01:00
|
|
|
info(" from %02x:%02x:%02x:%02x:%02x:%02x",
|
|
|
|
m->chaddr[0], m->chaddr[1], m->chaddr[2],
|
|
|
|
m->chaddr[3], m->chaddr[4], m->chaddr[5]);
|
2020-07-20 16:27:43 +02:00
|
|
|
|
2022-07-22 07:31:18 +02:00
|
|
|
m->yiaddr = c->ip4.addr;
|
|
|
|
memcpy(opts[1].s, &c->ip4.mask, sizeof(c->ip4.mask));
|
|
|
|
memcpy(opts[3].s, &c->ip4.gw, sizeof(c->ip4.gw));
|
|
|
|
memcpy(opts[54].s, &c->ip4.gw, sizeof(c->ip4.gw));
|
2020-07-20 16:27:43 +02:00
|
|
|
|
2021-08-26 14:34:24 +02:00
|
|
|
/* If the gateway is not on the assigned subnet, send an option 121
|
|
|
|
* (Classless Static Routing) adding a dummy route to it.
|
|
|
|
*/
|
2022-07-22 07:31:18 +02:00
|
|
|
if ((c->ip4.addr & c->ip4.mask) != (c->ip4.gw & c->ip4.mask)) {
|
2021-08-26 14:34:24 +02:00
|
|
|
/* a.b.c.d/32:0.0.0.0, 0:a.b.c.d */
|
|
|
|
opts[121].slen = 14;
|
|
|
|
opts[121].s[0] = 32;
|
2022-07-22 07:31:18 +02:00
|
|
|
memcpy(opts[121].s + 1, &c->ip4.gw, sizeof(c->ip4.gw));
|
|
|
|
memcpy(opts[121].s + 10, &c->ip4.gw, sizeof(c->ip4.gw));
|
2021-08-26 14:34:24 +02:00
|
|
|
}
|
|
|
|
|
2021-09-07 11:19:57 +02:00
|
|
|
if (c->mtu != -1) {
|
2021-08-12 15:42:43 +02:00
|
|
|
opts[26].slen = 2;
|
|
|
|
opts[26].s[0] = c->mtu / 256;
|
|
|
|
opts[26].s[1] = c->mtu % 256;
|
|
|
|
}
|
|
|
|
|
2022-07-22 07:31:18 +02:00
|
|
|
for (i = 0, opts[6].slen = 0; !c->no_dhcp_dns && c->ip4.dns[i]; i++) {
|
|
|
|
((uint32_t *)opts[6].s)[i] = c->ip4.dns[i];
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
opts[6].slen += sizeof(uint32_t);
|
|
|
|
}
|
|
|
|
|
conf, udp: Introduce basic DNS forwarding
For compatibility with libslirp/slirp4netns users: introduce a
mechanism to map, in the UDP routines, an address facing guest or
namespace to the first IPv4 or IPv6 address resulting from
configuration as resolver. This can be enabled with the new
--dns-forward option.
This implies that sourcing and using DNS addresses and search lists,
passed via command line or read from /etc/resolv.conf, is not bound
anymore to DHCP/DHCPv6/NDP usage: for example, pasta users might just
want to use addresses from /etc/resolv.conf as mapping target, while
not passing DNS options via DHCP.
Reflect this in all the involved code paths by differentiating
DHCP/DHCPv6/NDP usage from DNS configuration per se, and in the new
options --dhcp-dns, --dhcp-search for pasta, and --no-dhcp-dns,
--no-dhcp-search for passt.
This should be the last bit to enable substantial compatibility
between slirp4netns.sh and slirp4netns(1): pass the --dns-forward
option from the script too.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2022-02-18 04:03:53 +01:00
|
|
|
if (!c->no_dhcp_dns_search)
|
|
|
|
opt_set_dns_search(c, sizeof(m->o));
|
dhcp, ndp, dhcpv6: Support for multiple DNS servers, search list
Add support for a variable amount of DNS servers, including zero,
from /etc/resolv.conf, in DHCP, NDP and DHCPv6 implementations.
Introduce support for domain search list for DHCP (RFC 3397),
NDP (RFC 8106), and DHCPv6 (RFC 3646), also sourced from
/etc/resolv.conf.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-05-21 11:14:47 +02:00
|
|
|
|
|
|
|
uh->len = htons(len = offsetof(struct msg, o) + fill(m) + sizeof(*uh));
|
2020-07-20 16:27:43 +02:00
|
|
|
uh->source = htons(67);
|
|
|
|
uh->dest = htons(68);
|
2022-10-19 02:43:47 +02:00
|
|
|
csum_udp4(uh, c->ip4.gw, c->ip4.addr, uh + 1, len - sizeof(*uh));
|
2020-07-20 16:27:43 +02:00
|
|
|
|
|
|
|
iph->tot_len = htons(len += sizeof(*iph));
|
2022-07-22 07:31:18 +02:00
|
|
|
iph->daddr = c->ip4.addr;
|
|
|
|
iph->saddr = c->ip4.gw;
|
2022-10-19 02:43:48 +02:00
|
|
|
csum_ip4_header(iph);
|
2020-07-20 16:27:43 +02:00
|
|
|
|
|
|
|
len += sizeof(*eh);
|
|
|
|
memcpy(eh->h_dest, eh->h_source, ETH_ALEN);
|
|
|
|
memcpy(eh->h_source, c->mac, ETH_ALEN);
|
|
|
|
|
passt: Add PASTA mode, major rework
PASTA (Pack A Subtle Tap Abstraction) provides quasi-native host
connectivity to an otherwise disconnected, unprivileged network
and user namespace, similarly to slirp4netns. Given that the
implementation is largely overlapping with PASST, no separate binary
is built: 'pasta' (and 'passt4netns' for clarity) both link to
'passt', and the mode of operation is selected depending on how the
binary is invoked. Usage example:
$ unshare -rUn
# echo $$
1871759
$ ./pasta 1871759 # From another terminal
# udhcpc -i pasta0 2>/dev/null
# ping -c1 pasta.pizza
PING pasta.pizza (64.190.62.111) 56(84) bytes of data.
64 bytes from 64.190.62.111 (64.190.62.111): icmp_seq=1 ttl=255 time=34.6 ms
--- pasta.pizza ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 34.575/34.575/34.575/0.000 ms
# ping -c1 spaghetti.pizza
PING spaghetti.pizza(2606:4700:3034::6815:147a (2606:4700:3034::6815:147a)) 56 data bytes
64 bytes from 2606:4700:3034::6815:147a (2606:4700:3034::6815:147a): icmp_seq=1 ttl=255 time=29.0 ms
--- spaghetti.pizza ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 28.967/28.967/28.967/0.000 ms
This entails a major rework, especially with regard to the storage of
tracked connections and to the semantics of epoll(7) references.
Indexing TCP and UDP bindings merely by socket proved to be
inflexible and unsuitable to handle different connection flows: pasta
also provides Layer-2 to Layer-2 socket mapping between init and a
separate namespace for local connections, using a pair of splice()
system calls for TCP, and a recvmmsg()/sendmmsg() pair for UDP local
bindings. For instance, building on the previous example:
# ip link set dev lo up
# iperf3 -s
$ iperf3 -c ::1 -Z -w 32M -l 1024k -P2 | tail -n4
[SUM] 0.00-10.00 sec 52.3 GBytes 44.9 Gbits/sec 283 sender
[SUM] 0.00-10.43 sec 52.3 GBytes 43.1 Gbits/sec receiver
iperf Done.
epoll(7) references now include a generic part in order to
demultiplex data to the relevant protocol handler, using 24
bits for the socket number, and an opaque portion reserved for
usage by the single protocol handlers, in order to track sockets
back to corresponding connections and bindings.
A number of fixes pertaining to TCP state machine and congestion
window handling are also included here.
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
2021-07-17 08:34:53 +02:00
|
|
|
if (tap_send(c, eh, len, 0) < 0)
|
2020-07-20 16:27:43 +02:00
|
|
|
perror("DHCP: send");
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|