From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=reject dis=none) header.from=berkeley.edu Authentication-Results: passt.top; dkim=pass (2048-bit key; unprotected) header.d=berkeley.edu header.i=@berkeley.edu header.a=rsa-sha256 header.s=google header.b=aWL4Cg6v; dkim-atps=neutral Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by passt.top (Postfix) with ESMTPS id B67735A0265 for ; Sat, 25 Jul 2026 18:28:28 +0200 (CEST) Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-c1c4c7ddaf6so210936966b.3 for ; Sat, 25 Jul 2026 09:28:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784996908; cv=none; d=google.com; s=arc-20260327; b=Xxpw18s9yQVwY2YF/hUGcq7TALckz1+kO3dHPbd8lpZqEvflv/vHOoHy5tJN0wG89u Fyq5mofqwr+a7ZGcJ1xtz0HxaLazNG7Qw/8sCw7xDpaFZaRW4XEtUs0ibdNPLQcz53/A 0hIBoD3RR4hCSEsZWpOVKWokxW6OG+RphIvbZvT2f0FhWL4EZuQL82PoAZY2WEchzEPU 4AuJYv/ltTvDrg8dSHyMWu4T3VRF1usnts4d+OeSnAZdawBDmSETy/vp35+0/WjGMvsR CC51cqreLCsecB7U+sM177lhmXkRcMUYbymWpeoiXwXTQXIq4kFoMczdBQPYGgOLA+Xc MtGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=dif63trv1NUT2IsB0ckXhpDzqxeQDSOxWEjB2HlDGm8=; fh=MP6pDY7h4lyla7quOTgkRjeKcXyvTic0y98AGmvb8DU=; b=p2W789a96P9czh5WbTcMQZ4IezbGW0A5A61qQuFOEFucvYNy4eeoDl/JueOs3RwVT9 JEOqzsWeXSPdiSkuj+ftoWKD/1pdvKyeOT4HEHSKI+X1rFSP9tg48egluGjkk0JRsLMz yY8x9xLEfmfYDEynMtmoYOq1iuDCxotOAO3w9LxuoiignMMy+2malanyjuTLWZB1R1Cw 8lwZGI7u6rtdJf2+P8ShubK66LvqyMc10nr5ZEcyaECB3qGGC+XunEjONrwuT1JJFISK 7ANDI8R49O8zdpIulQYguQXMJErmX99zx8/MfL3Vehl6Hff7iZCmisg0rg2v7aMBcIy9 Lspw==; darn=passt.top ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berkeley.edu; s=google; t=1784996908; x=1785601708; darn=passt.top; h=content-type:to:subject:message-id:date:from:mime-version:from:to :cc:subject:date:message-id:reply-to:content-type; bh=dif63trv1NUT2IsB0ckXhpDzqxeQDSOxWEjB2HlDGm8=; b=aWL4Cg6v31DRiDJTVTCZjZoS1NMnVewYPnlNK0IkGrZoLF/ooBgHSW0+mENHIg6epu FgY+c1Edaco8uqp3iKD36G4Oj2LP+L1HgDZvIP2porEX3Vr1CQHSIqMnaUQA5ZKAY/17 o+41MH8n4GGIoweDuYDnTE3+9AtKOvJ3MEFvj22yGngI+pbSJ1lxmrul7U21r3cpzgHh Dvb029whamJgXRiaJLEhdZnLaLm2dWX0pKaqNYT/3Tmk4WOD0eMJWkWEX1yMg2mj7Ws2 KoetUmHksBpLoA3TnUg1D7FqVWzbB6RiXKiBL52ks9ftUV5GQq9RkG6oi4rXnQQnniaQ 7+VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784996908; x=1785601708; h=content-type:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=dif63trv1NUT2IsB0ckXhpDzqxeQDSOxWEjB2HlDGm8=; b=EIfEUXQEy2qAJgvRU1X+gTxtVAyD+NyPu/osEwFPC8DIwTrEJe6SqGMG28eL2hq8Pj cvvzGnlVK6IECBqxZsDkfXBsNmAKDKvMZtsHZFQL82uOwW4s441KS+jNagGykO8VOT2m epmDY2ZKutNtAhidMvz8SnOv2SF6efiVf0HKSYQPlTAQDUdd7xvhO2O5JYaBKXznN1lD pofLQmdW5BGK00neEaTwRE7ez85l7o4aqoQBXHgHxUP4Fua0jPOyacZModOMPPU1x22q a3HrizyoD4X5KNynUCuMAdswagBHsElPzojbPJ1e2se6mBffTdU4S9952hKJGAA/hQCp j5pQ== X-Gm-Message-State: AOJu0YyIwxUoUqdQQcBld1UZryu8d3se+VKLZNX7/7yu7ESBBrg+3QY9 +uwM+l7DkhYzbMrfUsRbMol0Gd2dwnlz5hvZKOOQJrpWwBOlBG2yNLbxK57k94RCc5wkEhMn2xD sILeeFmWNI9K/MGaCG0/04g0HqhKox5Q6IkGQVbtjIMt0rdnueFtgRw== X-Gm-Gg: AR+sD11MqcOAEp69SbxrAW7sAFAmgda6le3HzQDnUul8vF19VB6L5NKp+zlvp0oleh2 al7PuDcEDYQBzUdgoqSamzb4UsbwYhnB5m9yKEXZIKeNS1HkRRniUUmQoAG2waeuHPocGP+SnJA nNvm8lkwcBDESVDf6arWoFZ8raoVOKIKe53AVEld/vw20De2vOCyI9uhX0wq7Xq0bWw/uh9NX4r 3xO2L24hADQpFUE/7MKkUxAjWw7F1p48d9BM/LIm5nUYlxZp/g1rwUCTA75y2/DzHYUSqGIHGO0 FA3qd47PT2oQCBvRQLQZuSuT9GjInq/FhhUotD7wMHhGp5TVwFi2k/vb12QyjrGAmkjIxi8Ld03 I85DFNjr3fVMGdYJUWt07O7FArbQAKGVN3z8eAbSBBgK52KS4lEBNgDjdnkYfXxZUU2LsYQ== X-Received: by 2002:a17:906:4791:b0:c1c:2c92:fd60 with SMTP id a640c23a62f3a-c1f1eabd23amr134075466b.13.1784996906833; Sat, 25 Jul 2026 09:28:26 -0700 (PDT) MIME-Version: 1.0 From: Yuxi Liu Date: Sat, 25 Jul 2026 09:28:14 -0700 X-Gm-Features: AUfX_mwrY9Pjf4ZxO1lPF8UPbKidTjP98YKR8WkYMgEB78CLy6FUbA9SMpLJm-s Message-ID: Subject: [BUG] --map-guest-addr target resolved once at startup; host network change kills the mapping silently and permanently To: passt-dev@passt.top Content-Type: multipart/alternative; boundary="0000000000008fa6b9065771fab2" X-MailFrom: yuxi_liu@berkeley.edu X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: PP2AWVD7BDVHTRBDNL54JFCPWUIBT554 X-Message-ID-Hash: PP2AWVD7BDVHTRBDNL54JFCPWUIBT554 X-Mailman-Approved-At: Sat, 25 Jul 2026 21:28:50 +0200 X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000008fa6b9065771fab2 Content-Type: text/plain; charset="UTF-8" Hello, Bug report against pasta, as used by rootless podman for host.containers.internal. What happens ------------ Rootless container, default pasta networking (podman passes --no-map-gw --map-guest-addr 169.254.1.2), on a laptop. The laptop moves to a different network (hotel wifi, home, office). From that moment, every connection from the container to 169.254.1.2 times out. Forever. General outbound from the container keeps working, so the failure looks like the host service died. The host service is fine and answers on the host the whole time. Only recreating the container fixes the route. Why it happens -------------- --map-guest-addr forwards mapped traffic to the host's external address (commit 57b7bd2). pasta resolves that address once, at startup, and never again. After the host moves networks, pasta still connect()s to the launch-time address. Nobody owns that address anymore, the SYNs vanish, and no error is logged anywhere. pasta already runs a live netlink monitor in its event loop (RTMGRP_NEIGH, neighbour events). Host address changes are the one thing it reads once at startup and never watches afterward. Re-reading the current address needs no privilege: getifaddrs() works for any process. Reproduce --------- 1. Laptop on wifi network A. Run a rootless podman container with the default pasta network. Have any service listening on the host, say port 8191. 2. In the container: curl https://www.google.com/url?q=http://host.containers.internal:8191&source=gmail&ust=1785083212577000&sa=E -> answers. 3. Move the laptop to wifi network B. 4. Same curl -> timeout. Stays dead until the container is recreated. Versions: passt 0.0~git20250503.587980c-2 (Ubuntu 25.10), podman 5.4.2. Expected -------- One of: 1. pasta re-resolves the mapping target when the host's addresses change, or 2. the mapped route fails loudly (RST) instead of silently, or 3. the man page warns that the mapping dies permanently on host network change. Laptops are a mainstream platform for rootless podman. A silent, permanent route death on every wifi change is a serious defect for them. Workaround ---------- --map-guest-addr none --map-host-loopback 169.254.1.2 (via podman: --network=pasta:--map-guest-addr,none,--map-host-loopback,169.254.1.2). Mapped traffic then arrives on the host as 127.0.0.1, which the host owns on every network. This changes source semantics (connections appear to come from loopback), which is acceptable when you control both sides. Best regards, Yuxi Liu --0000000000008fa6b9065771fab2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Bug report against pa= sta, as used by rootless podman for
host.containers.internal.

Wha= t happens
------------
Rootless container, default pasta networking (= podman passes
--no-map-gw --map-guest-addr 169.254.1.2), on a laptop. Th= e laptop
moves to a different network (hotel wifi, home, office). From t= hat
moment, every connection from the container to 169.254.1.2 times out= .
Forever. General outbound from the container keeps working, so the
= failure looks like the host service died. The host service is fine and
a= nswers on the host the whole time. Only recreating the container
fixes t= he route.

Why it happens
--------------
--map-guest-addr forwa= rds mapped traffic to the host's external
address (commit 57b7bd2). = pasta resolves that address once, at
startup, and never again. After the= host moves networks, pasta still
connect()s to the launch-time address.= Nobody owns that address
anymore, the SYNs vanish, and no error is logg= ed anywhere.

pasta already runs a live netlink monitor in its event = loop
(RTMGRP_NEIGH, neighbour events). Host address changes are the one<= br>thing it reads once at startup and never watches afterward. Re-readingthe current address needs no privilege: getifaddrs() works for any
pro= cess.

Reproduce
---------
1. Laptop on wifi network A. Run a r= ootless podman container with the
default pasta network. Have any ser= vice listening on the host,
say port 8191.
2. In the container: cu= rl https://www.google.com/url?q=3Dhttp://host.containers.internal:8191= &source=3Dgmail&ust=3D1785083212577000&sa=3DE
-> a= nswers.
3. Move the laptop to wifi network B.
4. Same curl -> time= out. Stays dead until the container is recreated.

Versions: passt 0.= 0~git20250503.587980c-2 (Ubuntu 25.10),
podman 5.4.2.

Expected--------
One of:
1. pasta re-resolves the mapping target when the ho= st's addresses
change, or
2. the mapped route fails loudly (RS= T) instead of silently, or
3. the man page warns that the mapping dies p= ermanently on host
network change.

Laptops are a mainstream pl= atform for rootless podman. A silent,
permanent route death on every wif= i change is a serious defect for
them.

Workaround
------------map-guest-addr none --map-host-loopback 169.254.1.2 (via podman:
--n= etwork=3Dpasta:--map-guest-addr,none,--map-host-loopback,169.254.1.2).
M= apped traffic then arrives on the host as 127.0.0.1, which the host
owns= on every network. This changes source semantics (connections
appear to = come from loopback), which is acceptable when you control
both sides.
Best regards,
Yuxi Liu
--0000000000008fa6b9065771fab2--