Forum

How to make nimble send SRT replies from correct IP address?

sa 2021-12-10 10:07:08 UTC in Nimble Streamer

It seems like nimble always sends SRT replies from fixed IP address, ignoring destination address in UDP requests.
Suppose, nimble is configured in this way:
"ip": "0.0.0.0",
"protocol": "srt",
"send_mode": "listen",
and SRT requests come from two network interfaces, or two IP addresses on the same interface.
Nimble will ignore destination IP address and send replies from default. Probably when it binds to sending socket, it uses 0.0.0.0 as source IP instead of destination IP of receiving socket.

The mandatory "bind address" in configuration (when you must choose from either 0.0.0.0 or specific IP) probably mean that developers don't realize how to manage this. Could we kindly ask them to learn and fix this?

Alexander 2021-12-10 12:34:03 UTC 

If 0.0.0.0 is used as a "Local IP" in an SRT listening rule for streaming - Nimble binds to all interfaces.
Also, it's not Nimble's task to care about routing to the particular remote IP address, it's up to the OS and its networking setup - networks that are regarded as directly accessible via a particular interface defined by its IP+mask settings / default route setting / static routes settings / etc.

If you need to bind to the particular interface/IPaddr - please use the desired locally available IPaddr in the SRT rule in its "Local IP" address field.

If you have more details to discuss regarding your case - please open a ticket here: https://wmspanel.com/help

Thanks.

sa 2021-12-10 16:08:48 UTC 

Indeed, nimble binds to "all interfaces", but then sends UDP replies with incorrect source IP (as choosen by OS instead of taken by nimble from destination IP of incoming SRT request).
Do you realize that your server can't serve requests to more than a single IP address (at server side)?

sa 2021-12-10 16:19:05 UTC 

I start nimble to listen for SRT at 0.0.0.0, port 10009.
Server has two IP addresses: A and B, client has C.
Server has routes to C from both A (default) and B, so that both commands succeed:

ping -I A C
and
ping -I B C

Then I start at client:
srt-ffplay srt://B:10009

and I see outgoing replies on the server by tcpdump:
A.10009 > C.46226: UDP, length 64

Which are obviously dropped by client, because replies are from A:10009 instead of expected B:10009.

sa 2021-12-11 10:58:08 UTC 

хттпс://stackoverflow.com/questions/9975251/changing-default-source-ip-for-udp-server-bind-with-inaddr-any

sa 2021-12-11 11:03:06 UTC 

Should we wait for fix soon? Or we better implement surrogate workaround (some complex iptables packet mangling with conntrack)?

Max 2021-12-11 16:43:49 UTC 

Please use iptables for setting routes for now, we can't provide any ETA for this request.

BTW did you try to setup separate UDP streaming setting for each interface instead of 0.0.0.0, did it work?

sa 2021-12-13 18:48:55 UTC 

Separate nimble instances (each listening on specific address) are working as expected.

Max 2021-12-13 19:39:46 UTC 

Do you mean separate settings for a single Nimble Streamer instance? Or you're running several Nimble instances on a single server?

sa 2021-12-13 22:58:50 UTC 

I tried separate processes, but I believe separate SRT outputs would work too.

Post a reply


Post a new question

Categories:

This website or its third-party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the Privacy Policy. If you want to know more or withdraw your consent to all or some of the cookies, please refer to the Privacy Policy.
By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies.