From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top, Paul Holzinger <pholzing@redhat.com>
Subject: Re: [PATCH 17/22] fwd: Split notion of "our tap address" from gateway for IPv4
Date: Tue, 20 Aug 2024 21:56:24 +0200 [thread overview]
Message-ID: <20240820215624.5ec8e221@elisabeth> (raw)
In-Reply-To: <20240816054004.1335006-18-david@gibson.dropbear.id.au>
On Fri, 16 Aug 2024 15:39:58 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> ip4.gw conflates 3 conceptually different things, which (for now) have the
> same value:
> 1. The router/gateway address as seen by the guest
> 2. An address to NAT to the host with --no-map-gw isn't specified
> 3. An address to use as source when nothing else makes sense
>
> Case 3 occurs in two situations:
>
> a) for our DHCP responses - since they come from passt internally there's
> no naturally meaningful address for them to come from
> b) for forwarded connections coming from an address that isn't guest
> accessible (localhost or the guest's own address).
>
> (b) occurs even with --no-map-gw, and the expected behaviour of forwarding
> local connections requires it.
>
> For IPv6 role (3) is now taken by ip6.our_tap_ll (which usually has the
> same value as ip6.gw). For future flexibility we may want to make this
> "address of last resort" different from the gateway address, so split them
> logically for IPv4 as well.
>
> Specifically, add a new ip4.our_tap_addr field for the address with this
> role, and initialise it to ip4.gw for now. Unlike IPv6 where we can always
> get a link-local address, we might not be able to get a (non 0.0.0.0)
> address here. In that case we have to disable DHCP
It's not entirely clear to me in which case we would not be able to
get any address, but at least RFC 2131 doesn't have a problem with this:
diff --git a/dhcp.c b/dhcp.c
index aa9f59d..3de8a6e 100644
--- a/dhcp.c
+++ b/dhcp.c
@@ -282,6 +282,7 @@ int dhcp(const struct ctx *c, const struct pool *p)
struct in_addr mask;
unsigned int i;
struct msg *m;
+ struct in_addr zeroes = { 0 };
eh = packet_get(p, 0, offset, sizeof(*eh), NULL);
offset += sizeof(*eh);
@@ -378,7 +379,7 @@ int dhcp(const struct ctx *c, const struct pool *p)
opt_set_dns_search(c, sizeof(m->o));
dlen = offsetof(struct msg, o) + fill(m);
- tap_udp4_send(c, c->ip4.gw, 67, c->ip4.addr, 68, m, dlen);
+ tap_udp4_send(c, zeroes, 67, c->ip4.addr, 68, m, dlen);
return 1;
}
and:
$ ./pasta -p dhcp.pcap
Saving packet capture to dhcp.pcap
# dhclient
# tshark -r dhcp.pcap
Running as user "root" and group "root". This could be dangerous.
1 0.000000 :: → ff02::16 ICMPv6 90 Multicast Listener Report Message v2
2 0.016265 0.0.0.0 → 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0x75759d11
3 0.016361 0.0.0.0 → 88.198.0.164 DHCP 342 DHCP Offer - Transaction ID 0x75759d11
4 0.016479 0.0.0.0 → 255.255.255.255 DHCP 342 DHCP Request - Transaction ID 0x75759d11
5 0.016493 0.0.0.0 → 88.198.0.164 DHCP 342 DHCP ACK - Transaction ID 0x75759d11
[...]
so this could be a reasonable fallback.
> and forwarding of
> inbound connections with guest-inaccessible source addresses.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> conf.c | 7 ++++++-
> dhcp.c | 4 ++--
> fwd.c | 10 +++++++---
> passt.h | 2 ++
> 4 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/conf.c b/conf.c
> index 954f20ea..9f962fc8 100644
> --- a/conf.c
> +++ b/conf.c
> @@ -660,6 +660,8 @@ static unsigned int conf_ip4(unsigned int ifi,
>
> ip4->addr_seen = ip4->addr;
>
> + ip4->our_tap_addr = ip4->gw;
> +
> if (MAC_IS_ZERO(mac)) {
> int rc = nl_link_get_mac(nl_sock, ifi, mac);
> if (rc < 0) {
> @@ -1666,7 +1668,10 @@ void conf(struct ctx *c, int argc, char **argv)
> die("External interface not usable");
>
> if (c->ifi4 && IN4_IS_ADDR_UNSPECIFIED(&c->ip4.gw))
> - c->no_map_gw = c->no_dhcp = 1;
> + c->no_map_gw = 1;
> +
> + if (c->ifi4 && IN4_IS_ADDR_UNSPECIFIED(&c->ip4.our_tap_addr))
> + c->no_dhcp = 1;
>
> if (c->ifi6 && IN6_IS_ADDR_UNSPECIFIED(&c->ip6.gw))
> c->no_map_gw = 1;
> diff --git a/dhcp.c b/dhcp.c
> index acc5b03e..a935dc94 100644
> --- a/dhcp.c
> +++ b/dhcp.c
> @@ -347,7 +347,7 @@ int dhcp(const struct ctx *c, const struct pool *p)
> mask.s_addr = htonl(0xffffffff << (32 - c->ip4.prefix_len));
> memcpy(opts[1].s, &mask, sizeof(mask));
> memcpy(opts[3].s, &c->ip4.gw, sizeof(c->ip4.gw));
> - memcpy(opts[54].s, &c->ip4.gw, sizeof(c->ip4.gw));
> + memcpy(opts[54].s, &c->ip4.our_tap_addr, sizeof(c->ip4.our_tap_addr));
Nit: this was supposed to look like a table, so it would be nice to add
extra whitespace in the lines above this one.
--
Stefano
next prev parent reply other threads:[~2024-08-20 19:56 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-16 5:39 [PATCH 00/22] RFC: Allow configuration of special case NATs David Gibson
2024-08-16 5:39 ` [PATCH 01/22] treewide: Use "our address" instead of "forwarding address" David Gibson
2024-08-18 15:44 ` Stefano Brivio
2024-08-19 1:28 ` David Gibson
2024-08-16 5:39 ` [PATCH 02/22] util: Helper for formatting MAC addresses David Gibson
2024-08-18 15:44 ` Stefano Brivio
2024-08-19 1:29 ` David Gibson
2024-08-16 5:39 ` [PATCH 03/22] treewide: Rename MAC address fields for clarity David Gibson
2024-08-18 15:45 ` Stefano Brivio
2024-08-19 1:36 ` David Gibson
2024-08-16 5:39 ` [PATCH 04/22] treewide: Use struct assignment instead of memcpy() for IP addresses David Gibson
2024-08-18 15:45 ` Stefano Brivio
2024-08-19 1:38 ` David Gibson
2024-08-16 5:39 ` [PATCH 05/22] conf: Use array indices rather than pointers for DNS array slots David Gibson
2024-08-16 5:39 ` [PATCH 06/22] conf: More accurately count entries added in get_dns() David Gibson
2024-08-16 5:39 ` [PATCH 07/22] conf: Move DNS array bounds checks into add_dns[46] David Gibson
2024-08-16 5:39 ` [PATCH 08/22] conf: Move adding of a nameserver from resolv.conf into subfunction David Gibson
2024-08-16 5:39 ` [PATCH 09/22] conf: Correct setting of dns_match address in add_dns6() David Gibson
2024-08-16 5:39 ` [PATCH 10/22] conf: Treat --dns addresses as guest visible addresses David Gibson
2024-08-16 5:39 ` [PATCH 11/22] conf: Remove incorrect initialisation of addr_ll_seen David Gibson
2024-08-16 5:39 ` [PATCH 12/22] util: Correct sock_l4() binding for link local addresses David Gibson
2024-08-20 0:14 ` Stefano Brivio
2024-08-20 1:29 ` David Gibson
2024-08-16 5:39 ` [PATCH 13/22] treewide: Change misleading 'addr_ll' name David Gibson
2024-08-20 0:15 ` Stefano Brivio
2024-08-20 1:30 ` David Gibson
2024-08-16 5:39 ` [PATCH 14/22] Clarify which addresses in ip[46]_ctx are meaningful where David Gibson
2024-08-16 5:39 ` [PATCH 15/22] Initialise our_tap_ll to ip6.gw when suitable David Gibson
2024-08-16 5:39 ` [PATCH 16/22] fwd: Helpers to clarify what host addresses aren't guest accessible David Gibson
2024-08-20 19:56 ` Stefano Brivio
2024-08-21 1:40 ` David Gibson
2024-08-16 5:39 ` [PATCH 17/22] fwd: Split notion of "our tap address" from gateway for IPv4 David Gibson
2024-08-20 19:56 ` Stefano Brivio [this message]
2024-08-21 1:56 ` David Gibson
2024-08-16 5:39 ` [PATCH 18/22] Don't take "our" MAC address from the host David Gibson
2024-08-16 5:40 ` [PATCH 19/22] conf, fwd: Split notion of gateway/router from guest-visible host address David Gibson
2024-08-20 19:56 ` Stefano Brivio
2024-08-21 1:59 ` David Gibson
2024-08-16 5:40 ` [PATCH 20/22] conf: Allow address remapped to host to be configured David Gibson
2024-08-20 19:56 ` Stefano Brivio
2024-08-21 2:23 ` David Gibson
2024-08-16 5:40 ` [PATCH 21/22] fwd: Distinguish translatable from untranslatable addresses on inbound David Gibson
2024-08-16 5:40 ` [PATCH 22/22] fwd, conf: Allow NAT of the guest's assigned address David Gibson
2024-08-20 19:56 ` Stefano Brivio
2024-08-21 2:28 ` David Gibson
2024-08-16 14:45 ` [PATCH 00/22] RFC: Allow configuration of special case NATs Paul Holzinger
2024-08-16 15:03 ` Stefano Brivio
2024-08-17 8:01 ` David Gibson
2024-08-19 8:46 ` David Gibson
2024-08-19 9:27 ` Stefano Brivio
2024-08-19 9:52 ` David Gibson
2024-08-19 13:01 ` Stefano Brivio
2024-08-20 0:42 ` David Gibson
2024-08-20 20:39 ` Stefano Brivio
2024-08-21 2:51 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240820215624.5ec8e221@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
--cc=pholzing@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).