exporter: add a global TCP port range

[Arthur031221]

Description

Picks up #1743 by @benjamin1313.

Exporters behind restrictive firewalls cannot limit their automatically allocated TCP ports. Add --port-range=START-END with randomized allocation and an error when the range is exhausted.

Addresses @jluebbe's global range of at least 1000 ports, @Bastian-Krause's CLI option, and @Emantor's start/end format.

Added allocation and CLI regression tests. Tested with python -m pytest -q tests/test_port_range.py.

Checklist

• Documentation for the feature
• Tests for the feature
• Add a section on how to use the feature to doc/usage.rst
• PR has been tested
• Man pages have been regenerated

@benjamin1313, I'm glad to close this if you'd rather finish yours.

Co-authored-by: Benjamin B. Frost 5191751+benjamin1313@users.noreply.github.com

[ozan956]

Hey @Arthur031221,

thanks for the PR.

Have you seen #1832? That issue describes essentially the same topology. The client is outside a firewall, the coordinator/exporter is behind it, and ser2net binds arbitrary ports.

Does the later guidance in #1832 supersede the earlier direction in #1743?

Could you clarify and document the concrete use case where the existing SSH proxy mechanism is insufficient? For example, is a direct client-to-exporter connection explicitly required?

Without such a distinction, this appears to introduce an alternative solution for a problem already covered by the supported proxy mechanism. Perhaps documenting --proxy / LG_PROXY would be sufficient instead.

[Arthur031221]

I should have followed the later SSH proxy guidance in #1832. On this PR's head, a local raw NetworkSerialPort round-trip through a real SSH server passed with LG_PROXY and the setter used by --proxy. I don't have a verified use case for direct client-to-exporter access, so I'm withdrawing the port-range proposal. The proxy documentation already describes this setup.

[ozan956]

Thanks for verifying this.

In that case, please feel free to close this PR. Since #1743 appears to target the same use case, we can reference this conclusion there as well and wait for the original author to confirm whether they have a distinct case where the SSH proxy is insufficient. If not, #1743 can probably be closed too.