Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows 10 20H2 Appears to Break SoapySDRServer --bind #288

Open
aolszowka opened this issue Jan 2, 2021 · 1 comment
Open

Windows 10 20H2 Appears to Break SoapySDRServer --bind #288

aolszowka opened this issue Jan 2, 2021 · 1 comment

Comments

@aolszowka
Copy link

tl;dr;

In my setup after upgrading to Windows 10 20H2 SoapySDRServer.exe --bind no longer appears to work (some firewall corner case is filtering this). I am working around this by explicitly declaring the interface to bind to like so: SoapySDRServer.exe --bind="0.0.0.0"

The Long

After experiencing a switch outage, I power cycled all my equipment, sadly this means I took the Windows 10 20H2 update on the Windows box I am using to host several Nooelec NESDR SMArt v4 devices. After the machine came back on I was no longer able to use CubicSDR to "see" the devices hosted on the Windows Machine.

After several hours of debugging and updating packages (I am now on the latest Windows PothosSDR-2020.12.28-vc14-x64) I believe that there is an issue with Windows and the way that SoapySDRServer.exe --bind behave.

Here is a truncated version that gets to the jist of this:

  1. Ran SoapySDRServer.exe --bind
  2. On my RaspberryPi I ran nmap 10.1.0.10 -Pn -p 55132 which returned the following:
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-02 21:07 UTC
Nmap scan report for xxxxx.localdomain (10.1.0.10)
Host is up.

PORT      STATE    SERVICE
55132/tcp filtered unknown
  1. What?! filtered - This would seem to indicate some type of Firewall Issue, but the Firewall should have already been configured from before the Windows update to allow SoapySDRServer through.
  2. Disabled Windows Firewall.
  3. Reran nmap 10.1.0.10 -Pn -p 55132 on the RPi
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-02 21:21 UTC
Nmap scan report for xxxxx.localdomain (10.1.0.10)
Host is up (0.00073s latency).

PORT      STATE  SERVICE
55132/tcp closed unknown
  1. WTF? closed? This makes zero sense!
  2. Kill SoapySDRServer, relaunch with SoapySDRServer.exe --bind="10.1.0.10"
  3. Reran nmap 10.1.0.10 -Pn -p 55132 on the RPi
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-02 21:23 UTC
Nmap scan report for xxxxx.localdomain (10.1.0.10)
Host is up (0.00090s latency).

PORT      STATE SERVICE
55132/tcp open  unknown
  1. Yeah that looks way better, lets turn the firewall back on
  2. Firewall back on, Reran nmap 10.1.0.10 -Pn -p 55132
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-02 21:26 UTC
Nmap scan report for xxxxx.localdomain (10.1.0.10)
Host is up (0.00082s latency).

PORT      STATE SERVICE
55132/tcp open  unknown
  1. Yeah that looks as I would have expected, the Firewall was previously configured correctly so what gives?
  2. Lets try messing with some of the binding arguments (unsure if this is expected to work): SoapySDRServer.exe --bind="0.0.0.0"
  3. Reran nmap 10.1.0.10 -Pn -p 55132 on the RPi
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-02 21:28 UTC
Nmap scan report for xxxxx.localdomain (10.1.0.10)
Host is up (0.00090s latency).

PORT      STATE SERVICE
55132/tcp open  unknown
  1. Yeah that is legit, lets try ONE MORE TIME SoapySDRServer.exe --bind
  2. Reran nmap 10.1.0.10 -Pn -p 55132 on the RPi
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-02 21:29 UTC
Nmap scan report for xxxxx.localdomain (10.1.0.10)
Host is up.

PORT      STATE    SERVICE
55132/tcp filtered unknown
  1. DUDE WHAT GIVES? My only idea is that this is something to do with IPv6, maybe there is some corner case in Windows Defender Firewall that is getting tripped out now? Whatever I'll just use the --bind="0.0.0.0" work around.
  2. Updates the Scheduled Task that runs this in the background on system startup with highest privilages without requiring user login.
  3. CubicSDR doesn't automagically detect this instance, I think it used to? (REEEEEEEEEE):
    image
  4. Reran nmap 10.1.0.10 -Pn -p 55132 on the RPi
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-02 21:53 UTC
Nmap scan report for xxxxx.localdomain (10.1.0.10)
Host is up (0.00083s latency).

PORT      STATE SERVICE
55132/tcp open  unknown
  1. Well it is open, if you connect to it manually, It works, but that stinks, but at least it is working now:
    image

I stopped digging after this, but if it would help to dig more let me know and I am willing to help to have someone else avoid this headache.

Thank you

@guruofquality
Copy link
Contributor

The discovery operates over a multi-cast protocol SSDP: https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol

On the client side, if you set the environment variable SOAPY_SDR_LOG_LEVEL to DEBUG, you should see prints about discovered servers.

It may also be worth watching wireshark with the filter for SSDP to see if its being blocked in or maybe out.

Both the client side of SoapyRemote should be requesting network servers to send, and on the server side, the server should be regularly sending out discovery info as well as replying to those requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants