search

pothosware / SoapyRemote

Use any Soapy SDR remotely
https://github.com/pothosware/SoapyRemote/wiki
Boost Software License 1.0
122 stars 22 forks source link

SoapyServerListener::accept() SoapyServerListener::close() #71

Open kbtang88 opened 5 years ago

kbtang88 commented 5 years ago

i'm getting this

Detached kernel driver Found Rafael Micro R820T tuner Reattached kernel driver SoapyServerListener::close() SoapyServerListener::accept([::ffff:0.0.0.0]:63433) SoapyServerListener::close() SoapyServerListener::accept([::ffff:0.0.0.0]:63664) SoapyServerListener::close() SoapyServerListener::accept([::ffff:0.0.0.0]:63665) SoapyServerListener::close() SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv(header) FAIL: recv() [104: Connection reset by peer] SoapyServerListener::close()

SoapyServerListener::close()

i'm not getting to work on cubicsdr

guruofquality commented 5 years ago

SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv(header) FAIL: recv() [104: Connection reset by peer]

What is happening on the client side? This could be the client segfaulting, and hence, the server gets abruptly disconnected. A stack trace of the crash might help, for exampling running cubicsdr in gdb.

kbtang88 commented 5 years ago

Soapyremote is on clan and my MacBook is on another vlan. It's trying to connecting it but cubricsdr sometime crash.

On Thu, 16 May 2019, 15:12 Josh Blum, notifications@github.com wrote:

SoapyServerListener::handlerLoop() FAIL: SoapyRPCUnpacker::recv(header) FAIL: recv() [104: Connection reset by peer]

What is happening on the client side? This could be the client segfaulting, and hence, the server gets abruptly disconnected. A stack trace of the crash might help, for exampling running cubicsdr in gdb.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pothosware/SoapyRemote/issues/71?email_source=notifications&email_token=AJCRT6MDUQ5LVTLGT3XJ3N3PVVTVZA5CNFSM4HNLDVNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVR57OA#issuecomment-493084600, or mute the thread https://github.com/notifications/unsubscribe-auth/AJCRT6IAH4RN2XLPASTNPPDPVVTVZANCNFSM4HNLDVNA .

iw5ejm commented 5 years ago

same thing here, running soapyserver on raspbian (ubuntu 18 based), cubicsdr on macos 10.14.4


######################################################
## Soapy Server -- Use any Soapy SDR remotely
######################################################

c3bcc448-3a3b-15a3-8567-1f66007f0100
Launching the server... tcp://192.168.1.227:1234
Server bound to 192.168.1.227:1234
Launching discovery server... 
Press Ctrl+C to stop the server
SoapyServerListener::accept(192.168.1.164:62213)
SoapyServerListener::close()
SoapyServerListener::accept(192.168.1.164:62215)
SoapyServerListener::close()
SoapyServerListener::accept(192.168.1.164:62217)
SoapyServerListener::close()
guruofquality commented 5 years ago

Just so everyone knows, the client or server hanging up on a connection is a super generic error which probably means the connection was lost or the application crashed for any number of reasons.

To actually fix something, one would need a backtrace of the crash, or a log of debug prints, something pointing to the last function that was called, what its parameters were. This could be a bug in SoapyRemote client, or for that matter in cubicsdr itself.