[BUG] Caller should no connect on himself

[bpolic]

Bug Description
Caller can connect on himself.

To Reproduce
Steps to reproduce the behavior:

1. Build a SRT Library
2. Use some Linux machine (IP = "xx.xx.xx.xx")
3. Run: ./srt-xtransmit receive "srt://xx.xx.xx.xx:8200?latency=500&bind=:8200" -v
4. Current behavior ":SRT 0x595D131 ASYNC Connected to srt://xx.xx.xx.xx:8200"

Expected behavior
Caller should no connect on himself.

Desktop (please provide the following information):

• OS: Linux
• SRT Version 1.3.4 - 1.5.1

[ethouris]

Well, that doesn't look good. And I thought this problem is only with rendezvous. Let's not forget that it might be obvious if you connect to your exact address, but not exactly when you are connecting to "yourself" by a second IP address configured for your machine and you listen on all IP addresses on given port.

> ./srt-test-live udp://:5007 srt://sullust:5050?port=5050 -v
SRT parameters specified:

        port = '5050'

Opening SRT target caller(blocking, backlog=1) on sullust:5050
Connecting to sullust:5050 ...  connected.
Setting SND blocking mode: true timeout=0
ENCRYPTION status: UNSECURED (SND:UNSECURED RCV:UNSECURED) PBKEYLEN=0
OPTIONS: maxbw=-1 rcvlatency=120 blocking{rcv=true snd=true} snddropdelay=0 packetfilter=
STARTING TRANSMISSION: 'udp://:5007' --> 'srt://sullust:5050?port=5050'
[. << ...  << 1316  ->  (#1 %466311573  4E513081) .] sent
[. << ...  << 1316  ->  (#2 %466311574  7889142E) .] sent
[. << ...  << 1316  ->  (#3 %466311575  D1232783) .] sent
[. << ...  << 1316  ->  (#4 %466311576  130489F2) .] sent
[. << ...  << 1316  ->  (#5 %466311577  C20E7303) .] sent
[. << ...  << 1316  ->  (#6 %466311578  9932D5DD) .] sent
[. << ...  << 1316  ->  (#7 %466311579  45AA215F) .] sent
[. << ...  << 1316  ->  (#8 %466311580  668E7C6C) .] sent
[. << ...  << 1316  ->  (#9 %466311581  6CBADE75) .] sent
[. << ...  << 1316  ->  (#10 %466311582  3299B363) .] sent
[. << ...  << 1316  ->  (#11 %466311583  1268A05E) .] sent
[. << ...  << 1316  ->  (#12 %466311584  8F8837FF) .] sent
[. << ...  << 1316  ->  (#13 %466311585  06DBB695) .] sent
[. << ...  << 1316  ->  (#14 %466311586  BC1F52A5) .] sent
[. << ...  << 1316  ->  (#15 %466311587  35C4B09C) .] sent
[. << ...  << 1316  ->  (#16 %466311588  85E19273) .] sent
[. << ...  << 1316  ->  (#17 %466311589  8F5C7D47) .] sent
[. << ...  << 940  ->  (#18 %466311590  10EB8DEA) .] sent
[. << ...  << 1316  ->  (#19 %466311591  47D25384) .] sent
[. << ...  << 1316  ->  (#20 %466311592  BA1919DB) .] sent
[. << ... 17:01:50.185692/SRT:RcvQ:w1*E:SRT.cn: @979977986: HSREQ/rcv: With HSv4 version >= 1.3.0 is not acceptable.
17:01:50.185789/SRT:RcvQ:w1*E:SRT.cn: @979977986: HSREQ/rcv: With HSv4 version >= 1.3.0 is not acceptable.
17:01:50.185843/SRT:RcvQ:w1*E:SRT.cn: @979977986: HSREQ/rcv: With HSv4 version >= 1.3.0 is not acceptable.
17:01:50.185881/SRT:RcvQ:w1*E:SRT.cn: @979977986: HSREQ/rcv: With HSv4 version >= 1.3.0 is not acceptable.
 << 1316  ->  (#21 %466311593  90B9A613) .] sent
[. << ... 17:01:50.186250/SRT:RcvQ:w1*E:SRT.cn: @979977986: HSREQ/rcv: With HSv4 version >= 1.3.0 is not acceptable.
17:01:50.186294/SRT:RcvQ:w1*E:SRT.cn: @979977986: HSREQ/rcv: With HSv4 version >= 1.3.0 is not acceptable.
 << 1316  ->  (#22 %466311594  F072ECCC) .] sent
[. << ... 17:01:50.186682/SRT:RcvQ:w1*E:SRT.cn: @979977986: HSREQ/rcv: With HSv4 version >= 1.3.0 is not acceptable.
17:01:50.186749/SRT:RcvQ:w1*E:SRT.cn: @979977986: HSREQ/rcv: With HSv4 version >= 1.3.0 is not acceptable.
 << 564  ->  (#23 %466311595  76299BBD) .] sent
[. << ... 17:01:50.186893/SRT:RcvQ:w1*E:SRT.cn: @979977986: HSREQ/rcv: With HSv4 version >= 1.3.0 is not acceptable.
17:01:50.186937/SRT:RcvQ:w1*E:SRT.cn: @979977986: HSREQ/rcv: With HSv4 version >= 1.3.0 is not acceptable.
 << 376  ->  (#24 %466311596  2732C94F) .] sent
[. << ...  << 1316  ->  (#25 %466311597  40522986) .] sent
[. << ...  << 1316  ->  (#26 %466311598  15F90111) .] sent

Not sure what should be done about it. Last time when I tried to fix the rendezvous case of connecting to self (and resulting with having cookie draw) my fix was rejected due to some security concerns.

[ethouris]

I found and updated the old fix #377, although it is made with additional check on the application level only.

[bpolic]

Retested after fix, working as expected