Ruben,
Right with the default bind options that's the expected behavior. However, if each of the software that setup a bind socket with 'SO_REUSEADDR' option, it would mean that each 127.0.0.1:53, 192.1.1.1:53 and 0.0.0.0:53 are individual and unique bind set.
In this case, I believe that if the conference software Tony use also bind with 'SO_REUSEADDR', then it should work with elproxy since elproxy seemed to already use that option. Tony can strace (in Linux) his conference software to find out if it's setup with that option. -bn 0216331C
On Sun, May 6, 2018 at 12:26 AM, Ruben ON3RVH on3rvh@on3rvh.be wrote:
Hey Bao,
I’m not quite sure about that. But it is my understanding with a lot of packages that you cannot bind to 192.1.1.1:53 for example when 0.0.0.0:53 is bound to another service. Same with 127.0.0.1:53
Ruben - ON3RVH
On 6 May 2018, at 08:44, Bao Nguyen ngqbao@gmail.com wrote:
On Sat, May 5, 2018, 1:37 PM Ruben ON3RVH on3rvh@on3rvh.be wrote:
If they both use the same ports they cannot coexist on the same machine. Ports opened on a wildcard address cannot be used by other programs that want to open the same port on a specific address on the same machine
Ruben is this true with 'SO_REUSEADDR'? which I notice in elproxy.c has. With 'SO_REUSEADDR', the way I understand it is that it made "0.0.0.0:8100" and "192.168.0.1:8100" to not be "exactly" the same bind, whether without 'SO_REUSEADDR', "0.0.0.0:8100" and "192.168.0.1:8100" are indeed the same bind since the 0.0.0.0 cover all of 192.168.0.1. _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net