-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document port forwarding behaviors between different port forwarders #22221
Comments
I've just been advised to run |
After doing some packet capture, it turns out to be something I didn't expect. From what I can make out, either intentionally or unintentionally, This is likely something that was always wrong on the Java side, but that used to accidentally work on pre- If I switch to just using |
The |
The big switch in podman 5.0 is from slirp4netns to pasta for the default rootless network stack. If you switch containers.conf to point at slirp4netns, does your problem go away? @Luap99 PTAL |
It does, yes. Setting |
The new behaviour is better (more expressive), for what it's worth. I would consider the old behaviour to be a bug. |
This makes port publications more explicit with regards to which addresses should be bound. Additionally, it fixes some issues caused by the move from slirp4netns to pasta as the podman default: The old behaviour in podman when told to publish on address :: was to publish on all IPv6 AND IPv4 addresses. The new behaviour for pasta is to only publish IPv6 (which is arguably what slirp4netns should have been doing). This also adds optional debug logging, and more configuration for readiness checks. Affects: containers/podman#22221 Fix: #3
By the way, as far as I know, the current version of slirp4netns can't actually forward IPv6 ports, see rootless-containers/slirp4netns#253 -- so that might be the reason. |
We do not use the slirp4netns port forwarder by default with slirpo4netns, instead we use rootlessport |
Aah, right. Anyway, should we leave the current behaviour with pasta as it is? I also think it's desirable (same as #22221 (comment)). It has the downside of being inconsistent with rootlessport, but then again, slirp4netns and rootlessport behave differently anyway with e.g. NAT and changing the source address. I would be tempted to say that it's not entirely Podman's job to define what |
yes what pasta is doing is good, consistent and IMO the least surprising behaviour. It is a shame that these things ever work so slightly different in these corner cases but I don't think it is worth trying to make them behave the same. But these rootlessport quirks are definitely something we should document in some form. |
I agree, what pasta is doing right now is the right behaviour as far as I'm concerned. The behaviour as it is now allows for expressing all of the following:
This evidently wasn't quite doable before. You might get more or less than you asked for depending on how you asked. |
A friendly reminder that this issue had no activity for 30 days. |
@io7m is there anything we still want to change here? Or can this ticket be closed? |
We need to update the documentation on how port forwarding works with no ip given, And to be clear it is a lot to test: This all needs to get tested and then work out which things are considered bugs we should fix and then document the findings in the man page. I retitle the issue to make this clear. |
Issue Description
I maintain a small Java library used to start containers using
podman
for the purposes of integration testing.Yesterday, I inadvertently upgraded to
podman 5.0.0
as part of a system upgrade, and suddenly multiple tests are failing in the test suites of various projects. I've tracked it down to something I'm finding completely inexplicable:I can start
podman
from a Java program, and be unable to connect to the container from the Java program. However, at the same time the program and container are running, I can connect to the container just fine usingnc
. I can even have the Java program startnc
and tell it to connect to the container and it will work fine.I've managed to put together a repro case that can be found here: https://github.com/io7m/podmanbug-20240330/blob/master/src/main/java/com/io7m/podmanbug/Main.java
Assuming you have a JDK 21+ implementation installed, you can:
This has been working fine for months, and the only thing that changed in the setup was a move from Podman 4.* to Podman 5.0.0. I was advised in the Matrix channel to report it here.
Steps to reproduce the issue
Steps to reproduce the issue
podman run
.nc
process that will connect just fine!Describe the results you received
I consistently see connection failures from the Java program:
And yet, with
nc
:Describe the results you expected
I should be able to connect to a TCP port bound to
[::]
.podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
Local machine running Arch Linux:
Additional information
No response
The text was updated successfully, but these errors were encountered: