Re: [gpsd-dev] gpsd unnoticed of a remote IP gps brutally unplugged

[Eric S. Raymond]

Bruno Coudoin <address@hidden>:
> 
> Hi,
> 
> I am using gpsd with a remote TCP/IP gps serveur through 'gpsd://' (a
> CradlePoint IBR1100 router). In this case, if the remote gps is brutally
> unplugged from its power plug, gpsd stays unnoticed. It does try to
> reconnect but long after the gps server is back up (got a 5 hour
> occurrence).
> 
> In the traces I have this error which shows the 5 hours delay:
> GPS on gpsd://192.168.0.1:8889 returned error -1 (16332.187656 sec since
> data)
> 
> As it is, since we never talk to the device but only receive from it,
> and that the server cannot close or shutdown the socket, it is normal
> that at TCP level it goes unnoticed. One solution could be to add a TCP
> keepalive. Another option is to add a timeout when we don't get any
> traffic from a networked gps device.
> 
> Am I doing something wrong, is there an option to handle that case?
> 
> Bruno.
> 
> 

I don't understand what problem you are trying to solve.

GPSD is designed to recover from devices droping out and then returning.
In gpsd.c these definitions appear:

/*
 * Timeout policy.  We can't rely on clients closing connections
 * correctly, so we need timeouts to tell us when it's OK to
 * reclaim client fds.  COMMAND_TIMEOUT fends off programs
 * that open connections and just sit there, not issuing a WATCH or
 * doing anything else that triggers a device assignment.  Clients
 * in watcher or raw mode that don't read their data will get dropped
 * when throttled_write() fills up the outbound buffers and the
 * NOREAD_TIMEOUT expires.
 *
 * RELEASE_TIMEOUT sets the amount of time we hold a device
 * open after the last subscriber closes it; this is nonzero so a
 * client that does open/query/close will have time to come back and
 * do another single-shot query, if it wants to, before the device is
 * actually closed.  The reason this matters is because some Bluetooth
 * GPSes not only shut down the GPS receiver on close to save battery
 * power, they actually shut down the Bluetooth RF stage as well and
 * only re-wake it periodically to see if an attempt to raise the
 * device is in progress.  The result is that if you close the device
 * when it's powered up, a re-open can fail with EIO and needs to be
 * tried repeatedly.  Better to avoid this...
 *
 * DEVICE_REAWAKE says how long to wait before repolling after a zero-length
 * read. It's there so we avoid spinning forever on an EOF condition.
 *
 * DEVICE_RECONNECT sets interval on retries when (re)connecting to
 * a device.
 */
#define COMMAND_TIMEOUT         60*15
#define NOREAD_TIMEOUT          60*3
#define RELEASE_TIMEOUT         60
#define DEVICE_REAWAKE          0.01
#define DEVICE_RECONNECT        2

Is your issue that your local GPSD is waiting too long to try to reconnect with
the remote?  Be aware that this won;t happen at all unless someone is 
subscribed to the remote, eg. actually has a client session open.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>