| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The doc said timeservice=yes forced gpsd option -n, which it
did not. That option also force building of ntpshmmon, cgps and
gpsmon, even if disabled by gpsdclients=no.
So it essentually did nothing when used per the clockmaker script.
|
|
|
|
| |
Yeah, an OCD thing to do.
|
|
|
|
|
| |
Also, remove sime header inclusions discovered to be unnecessary during
the change.
|
|
|
|
|
| |
Outide of one Mac portability shim, anyway. Associated select(2) calls
become pselect(2) calls.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This is to prevent a conflict with Boost version 1.67.
No functional change.
|
|
|
|
|
|
|
| |
SHM() output got broken in 1744cd9f87006c85492edf1f476e054bdb744ea1.
many thanks to Paul Theodoropoulos <paul@anastrophe.com> for tracking
this down.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The gpsd command parser was splitting the ? from commands (WATCH, POLL,
etc.), and then sending the ? to the gpsd master in a separate packet.
But the gpsd is not buffering network data, so failing to recognize
The two packets of ? and WATCH as one complete command. Adding full
buffering to the gpsd master looks a lot harder than just sending
the ?WATCH in one packet. Also leading to some code simplification
in the gpsd slave. Been broken since 2013 at least.
Many thanks to Virgin Orbit for the support finding and fixing this.
|
| |
|
|
|
|
| |
New ?DEVICE:{"hexdata":"data" option.
|
|
|
|
| |
Thanks to Virgin Orbit for their support on this patch.
|
| |
|
|
|
|
|
| |
Their man page says _POSIX_C_SOURCE >= 200112L should work. It did
not.
|
|
|
|
| |
Almost 20 years after C99, Ubuntu still does not use it as default...
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
-r allows gpsd to use the time from a GPS even if the GPS has no valid
fix. This is useful on devices like the Raspberry Pi that have not
battery backed RTC, but have a GPS with a battery backed RTC.
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
|
|
|
|
|
|
|
| |
Error messages related to daemonization failures had incorrect
spelling.
TESTED:
Ran "scons build-all" on OSX.
|
|
|
|
|
|
|
|
|
|
| |
Certain definitions (in this case, setgroups) need _BSD_SOURCE in
older glibc versions, but _DEFAULT_SOURCE in newer versions. The
recommended approach for compatibility across glibc versions (from
feature_test_macros(7)) is to define both.
TESTED:
Now builds without warnings on Ubuntu 14, CentOS 7, and Fedora 25.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This defines a new function os_daemon() (in os_compat.c), which is
either the old replacement daemon() renamed, or a wrapper around the
actual daemon() call. This allows any issues related to daemon()
(which exist on some platforms) to be dealt with in one place. No
such changes are present yet, so platforms giving warnings for the use
of daemon() continue to do so, but now only in the compilation of
os_compat.c. Unfortunately, the current build procedure typically
compiles os_compat.c multiple times, so the warnings still appear
multiple times.
TESTED:
Ran "scons build-all check" on OSX 10.9, OSX 10.12, Ubuntu 14, and
FreeBSD 10.3.
|
| |
|
|
|
|
|
|
| |
When FreeBSD turns on POSIX it disables BSd extenstions, with no
possible workaraound. So just don;t ask for POSIX when then
insanity becomes visible.
|
| |
|
|
|
|
| |
Oh what a tangled web...
|
|
|
|
|
| |
Sad, C99 did not actually standardize the defines to invoke
the standard.
|
|
|
|
| |
vsnprintf() and strlcmp() are happier now.
|
| |
|
|
|
|
| |
uint is now unsigned int.
|
|
|
|
| |
I sure hope I did not drop a zero anywhere...
|
|
|
|
| |
NMEA time can be wildly random with no fix.
|
|
|
|
|
|
|
| |
This used to hang: gpsd -n /dev/ttyXXX
Now it exits with an error.
Signed-off-by: Gary E. Miller <gem@rellim.com>
|
| |
|
| |
|
|
|
|
|
| |
NTPTIME is from the serial stream, it never had anything to
do with PPS and it just confused everyone.
|
|
|
|
|
|
|
|
|
| |
This applies to not just PPS, but all NTP reportable
time. Even with a valid fix, the frist 3 times may be off.
Don't send bad time to ntp/chrony.
Move the definition into gpsd.h to be widely available not
depending on scons options.
|
|
|
|
|
|
|
|
| |
Some GPS send GPGSV (sats in view) every 5 seconds by GPGSA (sats
used) every second. gpsd was sending SKY only on GPGSV, so the
more frequent updates to used sats were getting lost. Now send
updates on GPGSA and GPGSV changes. The sat view is now more up to
date.
|
|
|
|
| |
I have seen up to about 490 in RTCM3.
|
| |
|
|
|
|
|
|
|
|
| |
...to mark that the device has a good time even if it does not report
a position fix. Used by the OnCore driver, e.g. when in position hold
mode.
scons check passes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OSX versions earlier than 10.6 fail to define IPV6_TCLASS, causing the
compile of gpsd.c to fail. There is already a fallback definition for
Gnu/Hurd. The attached patch:
1) Extends the existing Gnu/Hurd fallback definition to include a case
for OSX. This is currently based on _APPLE_. Basing it on Darwin might
be more appropriate, but that would need to be tested.
2) Duplicates this fallback setup in netlib.c, where it was missing.
3) Adds an ifdef to gpsd.c so that other cases that fail to define
IPV6_TCLASS will simply omit the IPTOS_LOWDELAY setup, rather than
failing to build. It's not entirely clear that sweeping the problem
under the rug is preferable to getting an error and having the builder
figure out what to do, but it is consistent with netlib.c, which
includes a similar ifdef.
The patch is originally from jeremyhu@macports.org, updated for 3.14
by ryandesign@macports.org, and then updated by me for 3.16.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...when terminated.
Perttu Salmela writes:
gpsd is started and terminated:
gpsd:INFO: launching (Version 3.15~dev)
gpsd:INFO: listening on port gpsd
gpsd:PROG: NTP: shmat(0,0,0) succeeded, segment 0
gpsd:PROG: NTP: shmat(32769,0,0) succeeded, segment 1
gpsd:PROG: NTP: shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTP: shmat(98307,0,0) succeeded, segment 3
gpsd:PROG: NTP: shmat(131076,0,0) succeeded, segment 4
gpsd:PROG: NTP: shmat(163845,0,0) succeeded, segment 5
gpsd:PROG: NTP: shmat(196614,0,0) succeeded, segment 6
gpsd:PROG: NTP: shmat(229383,0,0) succeeded, segment 7
gpsd:PROG: successfully connected to the DBUS system bus
gpsd:PROG: shmget(0x47505344, 8928, 0666) for SHM export succeeded
gpsd:PROG: shmat() for SHM export succeeded, segment 262152
gpsd:INFO: stashing device /dev/ttymxc2 at slot 0
gpsd:INFO: running with effective group ID 0
gpsd:INFO: running with effective user ID 0
gpsd:INFO: startup at 2015-10-31T11:04:55.000Z (1446289495)
^C*** buffer overflow detected ***: ./gpsd terminated
Aborted (core dumped)
This does not happen when gpsd is started with '-n' no-wait option. If
started with '-n' device is opened fine and gpsd is terminated fine.
The problem seems to be that function gpsd.c:gps_add_device sets
devp->gpsdata.gps_fd = UNALLOCATED_FD (=-1) if no-wait ('-n') flag is
not set. Next, in the main function around line 2166:
case AWAIT_NOT_READY:
for (device = devices; device < devices + MAX_DEVICES; device++)
if (allocated_device(device) && FD_ISSET(device->gpsdata.gps_fd, &efds)) {
FD_ISSET macro is called with invalid FD (-1). Adding the FD validity
check before FD_ISSET fixes the crash:
if (allocated_device(device) &&
(0 <= device->gpsdata.gps_fd && device->gpsdata.gps_fd < FD_SETSIZE) &&
FD_ISSET(device->gpsdata.gps_fd, &efds)) {
It is still a bit unclear for me should free_device(device) be called
even if FD is invalid.
The issue occurs on embedded arm platform and may depend on
implementation of FD_ISSET macro. The man page says "POSIX requires fd
to be a valid file descriptor". I can see that FD_ISSET is called in
couple of places elsewhere and FD validity is checked there.
The issue does not happen if client is connected. E.g. if gpspipe is
run and thereafter gpsd is terminated. This is expected since in such
case the FD must be valid as gpsd connects to device.
Output with proposed fix is:
gpsd:INFO: launching (Version 3.15~dev)
gpsd:INFO: listening on port gpsd
gpsd:PROG: NTP: shmat(0,0,0) succeeded, segment 0
gpsd:PROG: NTP: shmat(32769,0,0) succeeded, segment 1
gpsd:PROG: NTP: shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTP: shmat(98307,0,0) succeeded, segment 3
gpsd:PROG: NTP: shmat(131076,0,0) succeeded, segment 4
gpsd:PROG: NTP: shmat(163845,0,0) succeeded, segment 5
gpsd:PROG: NTP: shmat(196614,0,0) succeeded, segment 6
gpsd:PROG: NTP: shmat(229383,0,0) succeeded, segment 7
gpsd:PROG: successfully connected to the DBUS system bus
gpsd:PROG: shmget(0x47505344, 8928, 0666) for SHM export succeeded
gpsd:PROG: shmat() for SHM export succeeded, segment 262152
gpsd:INFO: stashing device /dev/ttymxc2 at slot 0
gpsd:INFO: running with effective group ID 0
gpsd:INFO: running with effective user ID 0
gpsd:INFO: startup at 2015-10-31T11:31:19.000Z (1446291079)
^Cgpsd:WARN: received terminating signal 2.
gpsd:WARN: exiting.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modified version of a patch by "Brian T (gmail)" <btuchten@gmail.com>.
He reports:
Using GPSd 3.14, if it is told to read TTY device, and then a USB GPS device
is added, and then the USB device is removed, GPSd exits. I had seen others
talk about this but never found an answer. The work around I found was the
attached patch. I had it as a new command line option, but removed that
part after reading the hacking guidelines.
Tested this way:
Device on /dev/ttyS4
gpsdctl add /dev/ttyUSB1
GPSd can be seen polling both devices
Physically remove USB device
GPSd continues processing ttyS4, removes ttyUSB1
Device on /dev/ttyS4
Add device on /dev/ttyUSB1
gpsdctl remove /dev/ttyS4
Physically remove USB device
GPSd waits on select()
gpsdctl add /dev/ttyS4
GPSd starts processing ttyS4, removes ttyUSB1
Insert USB device
gpsdctl add /dev/ttyUSB1
GPSd polls both devices
I did notice that if USB1 is the last device left in the list, and the USB is
pulled, GPSd does not syslog the message it was removed until a new device
(like ttyS4) is added back in. Then the syslog message shows up.
The reason for this is some embedded cellular modules have embedded GPS.
Sometimes the modules reset without notice, so the device is gone from the USB
stack before a udev script can catch it and send a "gpsdctl remove xxxx", and
then GPSd exits.
|
|
|
|
|
|
|
|
|
|
|
| |
When no fix present, GPS serial time, which is usually useless, was
still sent to ntpshm and chrony sockets.
Garmin was guarding the time properly, but no other driver. NMEA driver
used to do this until commit a9f44d1cb9db5a27832782bbe2685e66433c6d3a
in 2013. Other drivers had this bug a longer time.
This shows up the need for time regression testing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d1965788249d7e22cdde4021d452cf0dc6c6b9bd.
This breaks my build on Gentoo running gcc 4.9.2
libgps_shm.c: In function 'int gps_shm_read(gps_data_t*)':
libgps_shm.c:122:12: error: no match for 'operator=' (operand types are
'gps_data_t' and 'volatile gps_data_t')
noclobber = shared->gpsdata;
^
libgps_shm.c:122:12: note: candidate is:
In file included from gpsd.h:350:0,
from libgps_shm.c:30:
gps.h:1918:8: note: gps_data_t& gps_data_t::operator=(const gps_data_t&)
struct gps_data_t {
^
gps.h:1918:8: note: no known conversion for argument 1 from 'volatile
gps_data_t' to 'const gps_data_t&'
|
| |
|