Skip to content
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

Add a way of limiting the range of the ephemeral ports that are bound to by gather_candidates #47

Open
gregvish opened this issue Aug 6, 2021 · 7 comments

Comments

@gregvish
Copy link

gregvish commented Aug 6, 2021

Hi!

Inside get_component_candidates under the Connection class, the local UDP ports are randomly selected by the kernel, since 0 is provided as the port to create_datagram_endpoint. I have a use-case where I need this port range to be limited. Indeed, it's possible to limit it on the whole machine, by setting the /proc/sys/net/ipv4/ip_local_port_range under Linux. However, I need this to be controllable at a more fine grained level.

Could an addition of some kind of allowed_port_range flag be considered? In the implementation, this would require manually trying to bind to ports in the range until success.

Thanks!

@jlaine
Copy link
Collaborator

jlaine commented Sep 1, 2021

I'm curious about what your use case for this is?

Could you try submitting a PR which adds one or more keyword arguments to gather()?

@gregvish
Copy link
Author

gregvish commented Sep 3, 2021

The use case is essentially a Matrix bridge (bot) that forwards cellular voice calls from a GSM modem to a Matrix chatroom. Matrix uses WebRTC for calls.
The bot usually sits behind a residential connection (where the GSM modem is physically located), that is, behind a NAT that can be controlled via a web interface or UPnP (to define port forwarding). The other side of the connection is the user, who can be anywhere (assume a CGNAT of some kind).
In my mind, it should be far more reliable to offer the option of setting up manual port forwarding on the bot side. This way there is basically no need to fully rely on STUN. To do this, it is necessary to define a small port range that will be port-forwarded, and thus to limit the local ports to be selected from this pre-defined range.

When I have more time for this project, I'll get back here with a PR. Thanks!

@sirf
Copy link

sirf commented Sep 23, 2022

This would also make is much easier to run in a docker container where all ports must be published in advance.

@jlaine
Copy link
Collaborator

jlaine commented Oct 16, 2022

Any chance of a PR for this?

@sirf
Copy link

sirf commented Oct 26, 2022

I took a stab at an implementation #63

@sirf
Copy link

sirf commented Nov 9, 2022

@gregvish any opinion on #63 ?
Does it cover all your issues?

@gregvish
Copy link
Author

Looks like what I wanted at the time, as far as I recall. Thanks! I haven't been around to this stuff in a long time now, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants