fix slirp4netns port forwarding with ranges

[Luap99]

The slirp4netns port forwarder was not updated to make use of the new
port format. This results in a problem when port ranges are used since
it does not read the range field from the port.

Update the logic to iterate through all ports with the range and
protocols. Also added a system test for port ranges with slirp4netns,
rootlesskit and the bridge network mode.

Fixes #13643

[mheon]

LGTM, would love to get this merged and backported for 4.0.3. @TomSweeneyRedHat This seems fairly significant, possibly worth an exception?

[mheon]

Actually, nevermind, it's exclusively slirp4netns, not rootlessport - less serious than I thought

[Luap99]

Yes this is only slirp4netns port forwarder, the default configuration with rootlessport will work.

[rhatdan]

/approve
/lgtm
/hold

[mheon]

Github appears to have frozen. @Luap99 Can you force-push?

[mheon]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Luap99, mheon, rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99,mheon,rhatdan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rhatdan]

@Luap99 could you force push to see if this triggers the CI?

[baude]

I reran these ubuntu tests several times. I'm thinking the failure is legit? Old slirp ?

[Luap99]

The problem is in the test, ubuntus ncat doesn't close the connection when it gets EOF so it will just hang.
Man I really hate that every distro uses a different ncat implementation. Somehow they managed that they all behave differently and use different cli flags :(

[edsantiago]

Doesn't work on my laptop (f35, root):

   #|     FAIL: ncat got data back (netmode=bridge port=5211)
   #| expected: 'TEZD7qnccS'
   #|   actual: 'Ncat: TIMEOUT.'

...but it works in CI, so LGTM I guess?

[Luap99]

@edsantiago Going for a long shot here but I think you have a cni/netavark conflict on you system. Assuming you run upgrade test before they will leave the cni-podman0 interface around which will conflict with the netavark interface.

[edsantiago]

That was my first thought, so I ran podman system reset, then confirmed that podman info|grep neta shows netavarkl.

Now that I look further, most of the 500-network tests fail. So it's clearly something broken on my end.

[Luap99]

@edsantiago check ip addr | grep cni and remove the cni interface.

[edsantiago]

Thank you! ip link del cni-podman0 and now all tests pass. I've added that to my troubleshooting reference.

[Luap99]

merge me

[mheon]

/lgtm

[mheon]

FYI, did not backport cleanly, so not in 4.0.3. I don't think this is a big deal.

[Luap99]

I can backport manually if you want?
Or you need to grab #13660 before this commit

[mheon]

Backported