bugGPSD - Bugs: bug #36425, GPSD should split out generic...

 
 

bug #36425: GPSD should split out generic serial device probing and do it properly

Submitted by:  tz <tz1>
Submitted on:  Mon 07 May 2012 04:03:15 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 15 May 2012 01:23:44 AM UTC, comment #5:

If you had been paying attention, you would know that GPSD never sends probe strings to USB devices that it has not already identified as GPSes. The most it ever does with unknown USB devices is sniff their data for a short time. And because it uses TIOCEXCL they won't even see garbled data; the worst thing that can happen is their device open might fail and need to be retried a few seconds later

This disposes of all your hyperbole about GPD being "malware" and "damage", which I have to say really didn't incline me to listen any further. You shoot yourself in the foot when you attack without knowing what you are talking about.

Your argument is really with the distro packagers, not with me. We provide udev-install and udev-uninstall productions; it is up to the package builders whether they fire udev-install on a default installation. If you think that default is wrong, go fight with them.

If you think you can build a better device-management solution, by all means do it. That would be more constructive than criticizing GPSD for adapting to common use cases as best it can under crappy conditions.

Eric S. Raymond <esr>
Project Administrator
Wed 09 May 2012 02:29:27 PM UTC, comment #4:

It is out of scope for GPSD, but that is why I'm suggesting forking it out as a separate project with some transition, since you consider it critical to probe for GPS units on any generic serial port and don't care about any other software, hardware, or project that this might damage or cause trouble.

If GPSD is turning into malware as far as serial ports are concerned, it is within scope. If you aren't going to create something that fixes the general case, then you need to fix GPSD at whatever level to make it easy to find and disable the bad behavior.

Probing generic serial ports for GPS might be a good default option but it should be a proper option.

If when I installed the Arduino environment, it would make a UDEV entry that would launch the environment any time a generic FTDI was inserted, I would consider that stupid even if it didn't grab the port and start sending junk out. I consider GPSD doing worse things at least equally stupid. You should do it properly - at least enough to mitigate damage - or not at all.

1. GPSD does not cache or learn and the probe is minimal dumb brute-force. If I insert a generic device 100 times but never a GPS, you probe the device each and every time. A second device will be probed even if there already is a running GPS attached. There is no intelligence to either the launch or the probe which is why I call it stupid.

2. You provide no easy, documented way to disable this. The behavior is not (easily?) found in GPSD OR ITS DOCUMENTATION, but buried in some system CONFIGURATION FILES not part of GPSD. GPSD does use configuration files, but not its own, it uses and alters the system configuration files instead.

3. The probes are long and intrusive and I don't think it puts the port back where it found it so it doesn't even clean up after itself.

4. It locks the port and holds it for a long time - several seconds - where I can't talk to it or launch anything. There are no quick "oh, it is NOT a GPS, lets exit" things at the top, so although it might figure out in 10mS it is not a GPS, you are going to spend 10 seconds trying every combination of baud rates and probes for every possible GPS with a generic chipset and not let go.

5. You've done this on a hunch, not on any statistical analysis - maybe it is only 5 noobs with cheapo GPS units v.s 1000 Arduino users (and they buy that to learn open source software and hardware so not everyone is a hacker, and I know a lot and it took me a long time to find and fix). There may be more critical hardware that breaks.

6. Even if I fix it today, if there is a package update, it will reinsert the offending lines (and maybe some new ones). There is no way of doing this as either a build or install option (exclude probes on generic devices). It doesn't even have memory across installs. If I manually alter a configuration file, it should keep my alterations or note that it is reverting them.

You consider the above a "smart" or elegant way of doing things?

tz <tz1>
Wed 09 May 2012 07:20:38 AM UTC, comment #3:

>Also, there should be a way to remove the stupid udev rules while leaving the proper ones intact.


Possibly. Which ones are you characterizing as "stupid"?

Eric S. Raymond <esr>
Project Administrator
Tue 08 May 2012 03:15:56 AM UTC, comment #2:

Except that you consider it "inscope" to add udev rules for devices that you have no knowledge if they are gps units or not. I read your post at a&d and I disagree. Because YOU PERSONALLY have not experienced a problem, you declare it a non-problem. If you wish to convince me otherwise, statistics or evidence, not just a hunch would help. If a half dozen noobs v.s.1000 arduino users are inconvienced, I think you should remove the bindings for the ambiguous udev entries.

In any case, you should DOCUMENT THE AGRESSIVE BEHAVIOR.

Also, there should be a way to remove the stupid udev rules while leaving the proper ones intact.

tz <tz1>
Tue 08 May 2012 01:46:17 AM UTC, comment #1:

This is out of scope for GPSD. As you half-recognize, you're talking about an entire new device-brokering infrastructure, effectively a DBUS/hald competitor. If you write it and get it deployed, GPSD will use it, but I am not going to try folding all that complexity into my hotplug agent. Nohow, no way.

And see http://esr.ibiblio.org/?p=4319&cpage=1#comment-380184 for why I think it's an overreaction to a non-problem. If you want to de-install GPSD's udev rules, just do that.

It may be worth noting that until fairly recently GPSD's hotplug agent was a Python program. For which I caught hell from the embedded folks...

Eric S. Raymond <esr>
Project Administrator
Mon 07 May 2012 04:03:15 PM UTC, original submission:

GPSD actively interferes with any other device which also happens to use the standard FTDI (and apparently CP2103) since it modifies the config file of UDEV so it owns everything.

I know of no studies, statistics, or anything else that can calculate the number of users who are inconvenienced by not having their cheap, non-compliant (they should get their own VID/PID) GPS units not instantly work without intervention v.s. the number of people plugging other things in and having everything break and have to hunt down the UDEV (it isn't in the manpage! or documented clearly - finding then hacking udev scripts is a pain even for hackers).

Note that bluetooth requires manual intervention and there has been no movement to suggest any SPP device paired should start GPSD to probe that - I don't think they would let you.

For things which are clearly known to be GPS units, it is reasonable for udev to launch gpsd using the port.

For generic devices, the probe code ought to be pulled out and be configurable, extensible, and scriptable. Maybe even just a python program. This "usbserialprobed" (or whatever you would prefer to call it) can then run, and do some detection. If it is an older arduino or something else, it can just exit. If it probes further, it might detect a modem (AT->OK), and either before or after it can attempt to detect the GPS units, and if they are indeed GPS units, launch gpsd properly, however if they are NOT, then they would do the appropriate thing. E.g. if they (passively) listen and see a NMEA stream, they can be sure it is a GPS. If it requires complex probing, maybe they should check for other devices first.

Right now I could provide a patch to search for some of these various alternate devices, but that would confuse and bloat the gpsd code and make things difficult to add or reconfigure - I would have to recompile gpsd itself for each new device.

This might remain a component within the gpsd project, but at least I could provide patches or perhaps create an easy override mechanism or a more elegant detection or probing mechanisms (If it didn't see a gps the last three times, maybe it should assume the FTDI is not attached to a GPS?). (usbserialprobed might be a system service that could be disabled, not launched from udev but signaled by udev if it is there, so it would be easy and obvious how to override it). It might also prompt or do some kind of notify if it doesn't find anything so it would only try the deep GPS probing once if it wasn't a GPS, or if it does find a GPS it might be able to remember the kind so probe much more quickly the second time.

Non Plug-and-Play probing (such as for a generic serial port and what might be attached) is a good idea. But it ought to be done properly, or at least there ought to be a way of doing it properly instead of being arrogant and nasty and every time such a device is inserted demand to grab onto the device and not let go until it is sure it isn't really a GPS.

tz <tz1>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by esr (Posted a comment)
  • -unavailable- added by tz1 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 23 May 2012 06:21:06 AM UTCesrOpen/ClosedOpen=>Closed
    Tue 08 May 2012 01:46:17 AM UTCesrStatusNone=>Invalid

    Back to the top


    Powered by Savane 3.1-cleanup1