You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Ran SoapySDRServer.exe --bind
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
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.
Disabled Windows Firewall.
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
WTF? closed? This makes zero sense!
Kill SoapySDRServer, relaunch with SoapySDRServer.exe --bind="10.1.0.10"
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
Yeah that looks way better, lets turn the firewall back on
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
Yeah that looks as I would have expected, the Firewall was previously configured correctly so what gives?
Lets try messing with some of the binding arguments (unsure if this is expected to work): SoapySDRServer.exe --bind="0.0.0.0"
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
Yeah that is legit, lets try ONE MORE TIME SoapySDRServer.exe --bind
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
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.
Updates the Scheduled Task that runs this in the background on system startup with highest privilages without requiring user login.
CubicSDR doesn't automagically detect this instance, I think it used to? (REEEEEEEEEE):
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
Well it is open, if you connect to it manually, It works, but that stinks, but at least it is working now:
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
The text was updated successfully, but these errors were encountered:
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.
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 thatSoapySDRServer.exe --bind
behave.Here is a truncated version that gets to the jist of this:
SoapySDRServer.exe --bind
nmap 10.1.0.10 -Pn -p 55132
which returned the following: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.nmap 10.1.0.10 -Pn -p 55132
on the RPiclosed
? This makes zero sense!SoapySDRServer.exe --bind="10.1.0.10"
nmap 10.1.0.10 -Pn -p 55132
on the RPinmap 10.1.0.10 -Pn -p 55132
SoapySDRServer.exe --bind="0.0.0.0"
nmap 10.1.0.10 -Pn -p 55132
on the RPiSoapySDRServer.exe --bind
nmap 10.1.0.10 -Pn -p 55132
on the RPi--bind="0.0.0.0"
work around.nmap 10.1.0.10 -Pn -p 55132
on the RPiI 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
The text was updated successfully, but these errors were encountered: