bugGPSD - Bugs: bug #36409, GPSD fails to start get GPS data...

 
 

bug #36409: GPSD fails to start get GPS data from tcp://location:port

Submitter:  Jiři Pinkava <pinky>
Submitted:  Sat 05 May 2012 11:18:42 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 27 Apr 2018 10:30:08 PM UTC, comment #11: 

Bug near the lexer.  cgps sends this to the slave gpsd:

"?WATCH={\"enable\":true,\"json\":tru"...

But the slave gpsd passes this on to the master gpsd:

gpsd:IO: SER: => GPS: ?
gpsd:IO: SER: => GPS: WATCH={"enable":true,"json":true};\x0a

The first recognized as an empty command:

gpsd:IO: <= GPS: {"class":"ERROR","message":"Unrecognized request ''"}

The second ignored sinec it has no ?

Gary E. Miller <garyemiller>
Group administrator
Fri 27 Apr 2018 08:55:11 PM UTC, comment #10: 

I have a gpsd master/slave setup.  Then a cgps connects to the slave, and I get this in the slave gpsd logs:

gpsd:PROG: device 0 (fd=5, path gpsd://wally) already active.
gpsd:IO: SER: => GPS: ?
gpsd:IO: SER: => GPS: WATCH={"enable":true,"json":true};\x0a
gpsd:CLIENT: => client(0): {"class":"DEVICES","devices":[{"class":"DEVICE","path":"gpsd://wally","driver":"JSON slave driver","activated":"2018-04-27T20:45:51.908Z"}]}\x0d\x0a{"class":"WATCH","enable":true,"json":true,"nmea":false,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}\x0d\x0a
gpsd:IO: <= GPS: {"class":"ERROR","message":"Unrecognized request ''"}
gpsd:PROG: JSON, passing through {"class":"ERROR","message":"Unrecognized request ''"}
gpsd:DATA: packet type 19 from gpsd://wally with {ONLINE|PACKET|PASSTHROUGH}
gpsd:CLIENT: => client(0): {"class":"ERROR","message":"Unrecognized request ''"}\x0d\x0a

So, two bugs in here.

Gary E. Miller <garyemiller>
Group administrator
Fri 27 Apr 2018 08:01:06 PM UTC, comment #9: 

The original reporter never confirmed the fix.  I can confirm it is broken now.

The slave gpsd never sends a WATCH to the master gpsd, so the master gpsd never sends data to the slave.

The test case here did not use a master gpsd, only a 'socat' remote to send data.

Gary E. Miller <garyemiller>
Group administrator
Tue 12 Nov 2013 11:41:02 AM UTC, comment #8: 

Now definitely fixed, and with a regression test.

Eric S. Raymond <esr>
Group administrator
Sun 03 Nov 2013 09:21:32 PM UTC, comment #7: 

Alas, that fix broke operation on SiRF-IIIs

Fix will be trickier than I thought.

Eric S. Raymond <esr>
Group administrator
Sun 29 Sep 2013 06:35:30 PM UTC, comment #6: 

I found a way to make the lexer more tolerant of noise and interrupted packets. The reository head version passes your test now.

Eric S. Raymond <esr>
Group administrator
Tue 21 May 2013 03:33:49 PM UTC, comment #5: 

When I run that test script with a simple netcat to watch what it outputs, the server process stalls after emitting partial output:

esr@snark:~/software/gpsd$ python tcp_test.py &
[1] 19611
esr@snark:~/software/gpsd$ netcat -d 127.0.0.1 50100
,1.7,-30.40,M,-13.9,M,,*7D
$GPGGA,',1.7,-30.40,M,-13.9,M,,*7D\r\n$GPGGA,'
19322'19322'
1.00,'1.00,'
'2037.'
2037.72792,N,08'72792,N,08'
704.08478,W,1,04,1.7,-30.40,M,-13.9,M,,*7D
$GPGSA,A,3,10,28,09,13,,,,,,,,,03.4,01.7,03.0*00
$GPGSV,3,1,12,28,14,150,41,09,15,254,41,10,43,192,47,13,06,081,36*7A
$GPGSV,3,2,12,02,56,323,,04,41,024,,12,31,317,,17,31,085,*72
$GPGSV,3,3,12,05,15,318,,24,02,246,,33,08,096,,35,45,118,*7D
$GPRMC,193221.00,A,2037.7279,N,08704.0848,W,00.1,201.8,231207,01,W,A*2D
$GPZDA,193223.00,23,12,2007,00,00*69
esr@snark:~/software/gpsd$

Try this to see if a real-world test works:

gpsd -D 4 -N -n tcp://85.218.136.122:6000

Eric S. Raymond <esr>
Group administrator
Wed 01 May 2013 09:49:59 AM UTC, comment #4: 

Just for compleetness, to run test case use:

python2 tcp_test.py &
gpsd -n -N -D4 tcp://127.0.0.1:50100

Jiři Pinkava <pinky>
Thu 10 May 2012 10:33:36 AM UTC, comment #3: 

Please use python2 to run test or comment/uncomment the few lines to switch to python3

Jiři Pinkava <pinky>
Tue 08 May 2012 12:25:27 PM UTC, comment #2: 

I've writen simple TCP test in python which relilably reproduces my observations. Would you be so king to try if it is reproducible for you now?

The reproducibility depends on timing, you may adjust interval variable to 0.0001 or 0.01.

gpsd -n -N -D8 tcp://localhost:50100

I will try to investigate it my-self, but does not want to hunt ghosts and thus need confirmation.

(file #25817)

Jiři Pinkava <pinky>
Tue 08 May 2012 07:52:42 AM UTC, comment #1: 

The packet sniffer is already written on the assumption that packet boundaries don't correspond to read boundaries and it may have to do multiple reads to get full packets. It's not just sockets that have this challenge.

I'm not necessarily saying your diagnosis is wrong, but if it's right there must be some reason we don't see a lot of dropped fragments from non-socket (i.e. serial) devices.

I can't reproduce your problem, so you're going to have to investigate it yourself, and begin by really understanding how the packet sniffer's sliding packet queue works and how it interacts with the polling loop. Start by reading packet.c.

Thwn try gradually increasing the -D debbug level. That might shake out enough information to tell us what's going on.

Eric S. Raymond <esr>
Group administrator
Sat 05 May 2012 11:18:42 PM UTC, original submission:  

Just trying redirect GPS data from serial port trought network into GPSd. On the source (Openmoko Frerunner) i run socat:

socat TCP-LISTEN:50000,bind=0.0.0.0,fork OPEN:/dev/ttySAC1

on the other side:

./gpsd -n -N -D4 tcp://192.168.0.201:50000

The problem is that in TCP stream broke NMEA messages into spieces ignoring \r\n borders (in extreme case message might be recieved char by char) and one call of packet_get may read only part of NMEA message. This usuanly happend when multiple large messages follow eg. first call of read get something like:

"12595,N,01423.45433,E,180002.00,A,A*68\x0d\x0a$GPZDA,1800022"

First part end of one incomplete message, second is begining of other.
The first scrap is is discarded, but the second part is also detected as broken message and gpsd_poll refuse to continue.

The solution is probably provide way for parser to request to read more data if packet seems to be incomplete.

Jiři Pinkava <pinky>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #25817:  tcp_test.py added by pinky (2KiB - text/x-python)
file #25797:  gpsd_D8.log added by pinky (8KiB - text/x-log - GPSD log for TCP with long NMEA messages)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by garyemiller (Posted a comment)
  • -email is unavailable- added by esr (Posted a comment)
  • -email is unavailable- added by pinky (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-27 garyemiller StatusFixed Confirmed
    2013-11-22 esr Open/ClosedOpen Closed
    2013-11-12 esr StatusIn Progress Fixed
    2013-11-03 esr StatusFixed In Progress
    2013-09-29 esr StatusNeed Info Fixed
    2012-09-10 esr SummaryGPSD faisl to start get GPS data from tcp://location:port GPSD fails to start get GPS data from tcp://location:port
    2012-05-08 pinky Attached File- Added tcp_test.py, #25817
    2012-05-08 esr StatusNone Need Info
    2012-05-05 pinky Attached File- Added gpsd_D8.log, #25797

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code