6 May
2018
6 May
'18
2:39 p.m.
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(a)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(a)gmail.com> wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net On Sat, May 5, 2018, 1:37 PM Ruben ON3RVH
<on3rvh(a)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(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net