bugGPSD - Bugs: bug #53621, Invalid JSON generated for an...

 
 

bug #53621: Invalid JSON generated for an unreadable device

Submitter:  None
Submitted:  Thu 12 Apr 2018 09:40:46 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 26 Dec 2018 04:33:46 PM UTC, comment #1: 

Yup, that's a real bug all right. Fix pushed.

Eric S. Raymond <esr>
Group administrator
Thu 12 Apr 2018 09:40:46 AM UTC, original submission:  

When an unreadable device (i.e. device which reports an Input/output error when trying to cat its content) is added using a control socket and a list of devices is requested by sending a ?DEVICES; command to the gpsd via its telnet interface, an invalid JSON message is returned.

An example of the invalid message:
{"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyS1","activated":"2018-04-05T08:12:22.045Z","native":0,"bps":9600,"parity":"}]}
The parity data field is not correctly terminated by a " sign and the rest of the message (stopbits, cycle) is also missing.

An example of a valid message (for a readable device):
{"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyUSB0","driver":"NMEA0183","activated":"2018-04-05T08:13:04.198Z","flags":1,"native":0,"bps":19200,"parity":"N","stopbits":1,"cycle":1.00}]}

The issue was reproduced with gpsd 3.15 and 3.17 on SUSE Linux.

It seems that in the latest sources (commit 9429b1a5498e0e1ea68d5e53245c897dda52e5aa from 2018-03-29), variable device->gpsdata.dev.parity in function json_device_dump (in file gpsd_json.c) is set to 0. When the value 0 is appended (by function str_appendf) to variable "reply" (of type char*), function strlen(reply), which is called later in function str_rstrip_char, interprets the 0 as the end of the string and therefore does not return the full length of the reply.

I don't feel confident enough to come up with a solution, but here are my suggestions:

A possible solution might be to check whether it is possible to read from a device just after checking whether the device exists. If the device cannot be read, gpsd would refuse to add it (similarly to an unexistent device).

Another solution might be to append a character other than 0 when a device with an unknown parity is being printed in json_device_dump.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by esr (Posted a comment)
  •  

    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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-26 esr StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code