Connection reset by peer

[dcarter]

I'm running on OS X, and find that rtlamr will only run for a few minutes before either freezing up, or exiting with a "connection reset by peer" message. Both processes are on the same machine.

I started down the path of creating a watchdog script to kill & restart both rtl_tcp & rtlamr if no log entries written in some number of minutes, but thought there might be a better approach.

Is it possible that my sample rate needs to be lowered?

Or is there a way to modify the error handling in recv.go to retry after receiving this error from the call to rcvr.Read()?

Seems that it would be simplified if rtlamr used libsdr directly rather than in a separate process, but I'm a complete Go beginner, and don't really understand the motivation behind this design decision.

[bemasher]

The decision to not depend on librtlsdr was easy since the error handling in the library is pretty poor and using cgo to wrap it prevents cross-compilation, not to mention the necessity of the user to have a c-compiler setup (which rules out windows users without a painful setup). Using rtl_tcp is a win-win since we get almost the same control and remote access for free with the only expense of making the user handle two processes instead of only one.

Which side is producing that error? rtl_tcp or rtlamr? I haven't been able to do much testing on OS X but in the little testing i did do, i suspect the primary problem is rtl_tcp's interaction with the network stack since I reproduced a few of the same flavor of errors using other applications to connect to rtl_tcp. If you can provide logs that would be helpful.

[dcarter]

I will do some more testing & better document the issue. I believe there were probably some situations where each produced an error. What logs would be most useful?

[bemasher]

Any logs you can provide will be useful. Preferably both applications.

[dcarter]

Okay, I did a clean install of rtl-sdr & rtlamr on my home-automation MacBook Pro, which is configured to never sleep, and left it running when I left the house this morning. Will check to see what log info I have later today.

Also, it appears that cgo blocking cross-compiles has been resolved? golang/go#4714

[bemasher]

The fix only allows cross-compilation with cgo in use, it doesn't mean that it will succeed for all platforms. Adding an external build dependency is just not something I'm prepared to deal with or support.

[dcarter]

On the MacBook that is configured to never sleep, the 2 processes have run without error now for about 3 days. I did find this error message on the MacBook where I originally had this set up. I don't know for a fact, but I think this error probably occurred when the system went to sleep or when it woke back up.

18:53:10.433463 recv.go:133: Error reading samples: read tcp 127.0.0.1:1234: connection reset by peer

Would it be reasonable to add a retry loop in this particular error situation? Perhaps with a retry count command line parameter.

[bemasher]

Unfortunately, I believe this particular error is unrecoverable without rtlamr controlling instantiation of rtl_tcp which I would like to avoid.

I don't know what the OS X equivalent to this would be but using systemd to instantiate the services and to automatically restart them upon failure would work nicely. I believe OS X's closest solution is launchd, so you might look into that.