New post

Programming | Oddity In TCP/IP Communications With SkySafari 6 Pro - SkySafari Shuts Down Connection


I have been playing around with writing an LX200 server that supports SkySafari, and I encountered a behavior on the SkSafari Pro 6 client side I cannot fully understand. Let me say beforehand that I am really defensive about my claims and my programming skills, but here is my problem. My server is a standard BSD socket style server written in C/C++, it accepts the standard commands of LX200, and it works fine with programs like KStars or SkyChart; I know that LX200 is a frail protocol, but after two weeks of tweaking around, I am pretty sure that I have done everything right (well, at least I do not know what could be wrong), I catch all errors and scan all socket states during program execution, and everything seems to be fine (and, as said before, it works with others). When using SkySafari Pro 6 on an Android 7 tablet, however, I am unable to establish a connection unless I do something very counterproductive and unconventional (more on that later on). This i going to get technical, so sorry for the tech lingo.

Here is my problem. I open up a server socket for listening, i am binding the address and start listening. when sky safari connects, i accept the connection and start receiving. I get the first command (request for right ascension- :GR#) and reply with the usual HH:MM:SS#. According to the Sky Safari log, this is received with error 0; sky safari sends two commands next, one for the speed and a request for declination - this is, for instance :RM#:GD# - this is sent without error. then, sky safari terminates the connection with error -13 (probably a timeout?). I am running the server on a topical raspberry pi 3+ with raspian stretch, but this has also happened when using other clients like an ESP32 microcontroller.

The only way to establish a flaky and instable connection is to call "accept" immediately again after my first write to SkySafari. this results in a very sluggish and instable connection, but then it works - somehow.

however, that is not the way a tcp/ip connection is meant to be, so i fired up wireshark to monitor the TCP/IP packets directly, and I found something strange. Here is what i get from KStars, where everything works - SYN is a request for synchronization, ACK is acknowledgment for incoming data from the TCP layer, PSH means PUSH - send data. Chitchat between KStars and the Server is like this
KStars                     LX200Server
               SYN >                              (request for connection from KStars to server)
              < SYN, ACK                      (server accepts)
              ACK >                               (TCP/IP layer of KStars computer says ok)
              PSH, ACK, :GR# >             (KStars wants RA)
              < ACK                               (server says ok ...)
              < PSH, ACK HH:MM:SS#   (... and server sends RA)
              ACK >                               (KStars says ok ...)
.. and the two exchange data happily ever after. KStars connects to server, server acknowledges, KStars sends request for Right Ascension, Server supplies it and so on; of course other requests than :GR# are handled as well

Now the same thing with SkySafari 6 Pro:
SkySafari                         LX200Server
              SYN >
              < SYN, ACK
              ACK >
              PSH, ACK, :GR# >
              < ACK
              < PSH, ACK HH:MM:SS#   (SkySafari gets the RA string form the server and accepts it according to the log with errro 0)
              FIN, ACK >                        (Sky Safari hangs up!!! this is not a reset - RST - due to an error, it just slams the receiver on the phone!)
              SYN >                               (SkySafari begs for an new connection ... may I say like a bad tempered girlfriend ;) ...)
              < SYN, ACK                      (TCP/layer of Server says ok ...)
              ACK >                               (SkySafari says ok)
              PSH, ACK :RM# >              (SkySafari sets motor speed, no reply expected from that command)
              < ACK                               (TCP/layer of Server says ok)
              PSH, ACK :GD# >              (SkySafari wants declination)
              < ACK                               (Server says ok but the client socket is no longer reading because of the FIN)
              < ACK                               (TCP/IP layer Server says ok)
... 3 seconds later SkySafari sends FIN with error -13 ... apparently a timeout.

Due to the FIN after the first read, the next SYN request can only be handled properly if I "accept" the incoming client again. however, there is no obvious reason for that behavior and accepting the SkySafari client after each write is neither canonical nor performant. It is apparently not an Android problem as I can also connect to the Server via a Telnet terminal from the tablet... 

Of course I am happy t share my code and wireshark output, and believe me - I am the last to accuse any other developer of a bug, but I am pretty sure that something is wrong here, isn't it? Does anyone have an idea or suggetion waht to do?

Thanks in advance!






  • 0
    Wolfgang Birkfellner


    Ok, commenting myself: I have not solved the problem, but I found a workaround. When setting the port for the server socket to SO_REUSEADDR, and by setting both the server and client port to SO_LINGER with 0s timeout, you can shutdown the client socket with with SHUT_RDWR immediately after each write, close it, and reassign the socket using "accept". that causes a lot of resets but the communication but seems stable at an update rate of 1/10 s ... not very elegant, still.

    yours wolfi

  • 0
    Wolfgang Birkfellner

    after unsuccessful contact with support, I would like to emphasize that - in my opinion - this is a massive bug in SkySafari. I am aware that many users blame the software of being buggy while the reason is simply incompatible hardware or setup errors. however, not too many people monitor network traffic. anyway - shutting down the client and requesting a new connection after a millisecond is certainly not the way a TCP connection is meant to be.

Please sign in to leave a comment.