IPv6 listen no longer accept IPv4 incoming call

[jeandube]

An application listening on IPv6 using SRT 1.3.1 gets incoming IPv4 calls via IPv4mapped IPv6 addresses. This pas behavior no longer works with master branch (commit 3d159f0). Is swapped libsrt.so.1.3.1 to libsrt.so.1.3.2 I built from the master branch and my SRT caller can no longer connect. The ss command output in the attached file for 1.3.1 and 1.3.2 shows the different bindings for port 9945.
ipv6only.txt
Pull Request #608 was supposed to preserve backward compatibility by not setting IPV6ONLY if not requested by the application and keep system's default (sysctl net.ipv6.bindv6only) but it seems the code review missed the change of behavior (my bad).
I found this problem while preparing a pull request to fix an issue with SRTO_IPTOS and SRTO_IPTTL not set for IPv4 socket created for IPv4mapped IPv6 addresses.

[maxsharabayko]

As reported by @jeandube

I resuscitate my test program an could not reproduce the issue I found (if founded) with our product firmware.
Linked with same latest version of srt(3d159f) I could have an IPv4 client connected. (...)
We can safely say there is nothing wrong with the SRT code. Problem lies in the firmware or the tester.
I think we can just close issue 675.

So closing.

[jeandube]

I need to re-open this issue.
I had more careful test with our firmware using the share lib (while the test program uses the static lib). I had a gdb session and added a break point in CChannel::setIpV6Only. The break point was hit when the firsmware started meaning the V6ONLY option was not set to its initial default value.
api.cpp (line 1706):
if (s->m_pUDT->m_iIpV6Only != -1)
m.m_pChannel->setIpV6Only(s->m_pUDT->m_iIpV6Only);

Unfortunately I could not check the value of m_iIpV6Only in my gdb session.
If I just relink libsrt.so.1 to libsrt.so.1.3.1 and restart the firmware, or call this listener using IPv6, problem solved. The behavior is like a corrupted variable (if it was an uninitialized variable, the static lib and test program would most likely have the same problem. I cannot eliminate an errant pointer in the firmware outside the SRT lib but until the source of the problem is found I prefer to keep this issue open (but I am not allowed to). I don't know if static vs. shared has anything to do with it or if different program grab different uninitialized memory junk.

[jeandube]

Problem finally found in firmware, no SRT problem.