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:
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?
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
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)?
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
ping -I B C
Then I start at client:
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.
Should we wait for fix soon? Or we better implement surrogate workaround (some complex iptables packet mangling with conntrack)?
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?
Separate nimble instances (each listening on specific address) are working as expected.
Do you mean separate settings for a single Nimble Streamer instance? Or you're running several Nimble instances on a single server?
I tried separate processes, but I believe separate SRT outputs would work too.
and required to achieve the purposes illustrated in the
If you want to know more or withdraw your consent to all or some of the cookies, please
refer to the