N0RUA
Hi all,
Lately my openspot's been unable to stay connected to a reflector for more than a minute or two, announcing "openspot disconnected", "openspot connecting" etc over and over.
This happens on big D-Star reflectors like REF001C, 30C, but also smaller local ones like 19B and 53A - so I can't see the fact that the reflectors are overloaded being the case here. I saw other threads about reflectors being overloaded due to people staying at home, but I'm not convinced this is the issue with the smaller reflectors.
I CAN stay connected to XRF313A, but I have yet to hear traffic. Essentially, I haven't heard anything on the REF reflectors in a while now, since I can't stay connected.
I haven't made any network changes here at home, and I've left automatic firmware updates on, so my openspot 2 is totally up to date. My D-Star registration seems to check out, so I'm completely stumped. I've tried tethering the openspot to my phone and I get similar results.
Any ideas before I try a firmware reload, or rollback?
Edit: It looks like older firmwares aren't even available... is it even possible to roll back to an older firmware on the openspot2?
N0RUA
Here's the log from the serial port when the openspot gets disconnected. In this case I am connected to REF053A:
nvmm: net check
nvmm: net check ok (23 ms)
ref: got ccs ping
ccs: sending pong
ref: rx timeout
ref: init reconnect
spk: starting voice announcement
spk: playing locally: OSDC
spk: loading code pair OS
nvmm-csd: looking up callsign CQCQCQ
nvmm-csd: ignoring special callsign CQCQCQ
ref: uninitialized
ref: initializing
ref: waiting for connect ack
ref: sending config
ref: waiting for config ack
ref: connected
ccs: sending connect packet
ccs: sending pong
ref: incoming header module mismatch (rx: D should be: A)
ref: incoming header module mismatch (rx: D should be: A)
ref: got ping, replying
ref: incoming header module mismatch (rx: D should be: A)
spk: loading code pair DC
ref: incoming header module mismatch (rx: D should be: A)
ref: incoming header module mismatch (rx: D should be: A)
ref: got ping, replying
spk: sending terminator
nvmm-csd: looking up callsign CQCQCQ
nvmm-csd: ignoring special callsign CQCQCQ
spk: starting voice announcement
ref: incoming header module mismatch (rx: D should be: A)
ref: incoming header module mismatch (rx: D should be: A)
ref: got ping, replying
ref: incoming header module mismatch (rx: D should be: A)
spk: requesting remote play: OSCTARAEAF000503PA
spk-remote: got first packet
nvmm-csd: looking up callsign CQCQCQ
nvmm-csd: ignoring special callsign CQCQCQ
ref: got ccs ping
ccs: sending pong
N0RUA
Finally, my openspot seems to randomly decide to forget its settings and go back to the "Quick Start" screen after no intervention by myself.
I'm able to stay connected to YSF reflectors just fine. I'm extremely confused.
HA2NON
The Quick Setup screen pops up automatically, if the currently active connector is the Null connector, or you open it specifically by using it's URL.
Your log shows that the reason of the disconnect is RX timeout, which means the server did not answer for the keepalive request in RX timeout seconds, which is 30 by default. This usually happens if the server has connectivity issues, or the link between you and the server has issues, or your internet connection has issues. Try using another server, or increase the RX timeout seconds from 30 to 60 for example.
N0RUA
Thanks for the reply, I appreciate it.
I did adjust the timeout, and if i change it to 60, or even 120, it seems to get disconnected right on that schedule.
I've tried several other reflectors: 1C, 30C, 19B, 53A, and they all exhibit the same problem.
I hopped on XRF725 (can't recall which module) with someone and they couldn't hear me when I transmitted.
I've also tried with a zumspot running pi-star, and the exact same problems arise, which indicates that it's some sort of strange networking problem. Not getting any audio through to the reflector is odd, even if I transmit well before the 30 second (or 60, or 120) timeout.
As I mentioned, the same behavior happens when I'm tethered to my phone through the cell network, but I also have a hard time believing all those reflectors are inflicted by the same networking issue.
My other idea is to go try a friend's wifi network and see if the problems persist.
N0RUA
Alright, I think this is definitive:
With permission, I used a friend's callsign to test. I put his callsign into the "callsign" field of the D-Star connector screen. Not only am I able to stay connected to reflectors, I am actually hearing traffic.
When I change the callsign back to my own, it goes back to disconnecting and not passing traffic.
This tells me that there's something wrong or misconfigured entirely within the D-Star network related to my callsign.