SoapySDRServer --bind doesn't listen on all IPs about soapyremote HOT 7 CLOSED

I sometimes notice similar connection problems.
If you use netstat (Debian net-tools package) you get

$ netstat -tulpn |grep Soapy
tcp6       0      0 :::55132                :::*                    LISTEN      1169/SoapySDRServer
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           1169/SoapySDRServer
udp6       0      0 :::1900                 :::*                                1169/SoapySDRServer

the [::] address also supports IPv4. You can confirm this with e.g. socat tcp:REMOTEIP:55132 - which for me connects and shows the IPv4-mapped IPv6 address in the SoapyRemote output: SoapyServerListener::accept([::ffff:LOCALIP]:59523).
Perhaps you can test that and see if the bind is really the problem?

from soapyremote.

netstat output is analogous to that of lsof. It doesn't matter if I socat, telnet or use a Soapy client, it's not accepting connections on the IPv4 address unless I pass an argument to --bind when starting the server. When it is listening on IPv4, it shows the client's IPv4 address "normally" rather than as a pseudo IPv6 address.

from soapyremote.

The port 1900 stuff is SSDP, and there is also an avahi build option which will essentially do the same thing. It looks like calls to "registerService" for SSDP and MDNS do not respect the bind option if its only v4. So that should be fixed but its not the issue here.

By default the server binds to the unspecified address "::". And I think this is supposed to be the universal way to bind a tcp server to listen for ipv6 and v4 on all interfaces. For the life of this project, this is the first time I have heard of this. After-all, almost anyone using this has probably bound with no server args and connected via ipv4.

That said, when connecting with ipv4 when its bound to "::" I see prints like SoapyServerListener::accept([::ffff:192.168.1.242]:43492) whereas on ipv4 "0.0.0.0", its SoapyServerListener::accept(192.168.1.242:43630) So something about this pseudo-addressing, or whatever supports it, is broken for you -- and I would like to figure out why. Just to document the fix, or change the code accordingly.

Do you have anything interesting in ifconfig? What is your OS (linux flavor, version, etc)

Just curious, what happens when you bind normally (no options) and request to use an ipv6 address (https://github.com/pothosware/SoapyRemote/wiki#the-remoteipver-key) SoapySDRUtil --find="remote:ipver=6"

from soapyremote.

Debian SID, kernel 4.19. The interface in use is "interesting" in the sense that it's a bridged interface but I doubt that would have any effect. Checking other listening services, apache2 listens "only" on v4 but definitely works for v4 and v6 clients. sshd listens on each and works with both.

from soapyremote.

SoapySDRUtil --find="remote:ipver=6"
...
Found device 2
available = Yes
driver = remote
label = Dexatek DK DVB-T Dongle (Logilink VG0002A) :: 00000991
manufacturer = Realtek
product = DVB-T Dongle
remote = tcp://[fe80::219:99ff:fef4:bbd3%10]:55132
remote:driver = rtlsdr
rtl = 0
serial = 00000991
tuner = Fitipower FC0013

That IP is the link-local IP on the expected interface.

from soapyremote.

It looks like the trick to getting both ip versions to show in netstat is setting "IPV6_V6ONLY" on the socket for ipv6 and then binding another socket to v4. So without the special option and extra socket, netstat will only show tcp6, but it will support ipv4 normally.

Binding both IPV6_V6ONLY=1

tcp        0      0 0.0.0.0:55132           0.0.0.0:*               LISTEN     
tcp6       0      0 [::]:55132              [::]:*                  LISTEN   

ipv6 IPV6_V6ONLY = 0

tcp6       0      0 [::]:55132              [::]:*                  LISTEN

Major TCP based socket applications like SSH probably use two sockets and IPV6_V6ONLY to be portable on platforms without ipv4 mapped ipv6 addresses (like OpenBSD). That said, I'm not sure why IPv4-mapped IPv6 is broken for you.

Perhaps its turned off, can you check sysctl? On Linux systems, address mapping is controlled by a sysctl knob called net.ipv6.bindv6only; it is set to zero (enabling address mapping) by default.

• Reference https://lwn.net/Articles/688462/

Other references:

• https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzab6/xacceptboth.htm

    /********************************************************************/
      /* After the socket descriptor is created, a bind() function gets a */
      /* unique name for the socket.  In this example, the user sets the  */
      /* address to in6addr_any, which (by default) allows connections to */
      /* be established from any IPv4 or IPv6 client that specifies port  */
      /* 3005. (that is, the bind is done to both the IPv4 and IPv6 TCP/IP    */
      /* stacks).  This behavior can be modified using the IPPROTO_IPV6   */
      /* level socket option IPV6_V6ONLY if required.                      */
      /********************************************************************/

• https://serverfault.com/questions/755765/httpd-listening-in-ipv6-according-netstat-but-reacheable-in-ipv4

I believe that on Linux, binding to [::] (IPv6) results in receiving both IPv6 and IPv4 traffic (by default). I believe these are referred to as IPv4-mapped IPv6 addresses. netstat simply shows the IPv6 entry only, because there's technically only a single bind, that happens to support both IPv4 and IPv6.
It's possible for software to not use IPv4-mapped IPv6 addresses and bind to both 0.0.0.0 and [::] separately and hence show up twice in netstat, but it's a design choice on the part of the developers.

from soapyremote.

Well, whaddya know...sysctl net.ipv6.bindv6only=0 is the fix! Clients are now shown as v6-mapped-v4 addresses as well.
Seems like I have an /etc/sysctl.d/bindv6only.conf and according to this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560238
this was briefly the default in Debian Testing in 2009.

from soapyremote.