{"id":2849,"date":"2011-01-07T01:06:50","date_gmt":"2011-01-07T06:06:50","guid":{"rendered":"http:\/\/esr.ibiblio.org\/?p=2849"},"modified":"2014-03-17T20:05:43","modified_gmt":"2014-03-18T00:05:43","slug":"plug-and-pray-in-gps-land","status":"publish","type":"post","link":"http:\/\/esr.ibiblio.org\/?p=2849","title":{"rendered":"Plug and Pray in GPS-land"},"content":{"rendered":"<p>Welcome, ladies and gentlemen, to another darkly humorous tale of the <a href=\"http:\/\/esr.ibiblio.org\/?p=801\">seamy side of GPS interfacing<\/a>.  GPSD working with USB GPS mice has, when properly installed, lovely plug-and-play self-configuring behavior. That is, you plug a USB GPS into a USB port, the  hotplug system notifies the gpsd daemon that the GPS is available, the daemon records this fact&#8230;and subsequently when you start up any GPSD client application It Just Works.  Well, usually.  There&#8217;s a dangerous weakness in the machinery, and yesterday it came around and bit us in the ass.<\/p>\n<p><!--more--><\/p>\n<p>The root of the problem is a hole in the the USB standard.  For most other kinds of USB devices (printers, mice, mass storage, smart cards, hubs, what have you) there&#8217;s a defined device class code which gets presented to your USB subsystem; so, for example, your print spooler can enumerate all the USB printers attached to your system and ignore everything that isn&#8217;t a printer.   But the standard does not define a device class code for GPSes.<\/p>\n<p>If there were a GPS device class, and GPS manufacturers followed the standard, then GPSD&#8217;s hotplug rules could simply say &#8220;hand everything with that type to GPSD&#8221; and all would be happiness.  But there&#8217;s no such class, so we have to whitelist a bunch of vendor\/product IDs and assume that if the device presents one on this list, it&#8217;s a GPS.<\/p>\n<p>In truth, we&#8217;d probably have to do this even if there were a GPS device class.   You see, all the GPS mice we&#8217;ve ever seen are are lash-ups consisting of a receiver module that&#8217;s wedded by a sort of bastardized TTL version of RS-232 with an RS-232-to-USB adapter chip. The USB device class is presented down the wire to your PC by the adapter chip, which would have to be custom-modified to show something other than its <em>own<\/em> device class and vendor\/product ID.  These devices are produced on such thin margins that the vendors might not spend the extra pennies for the customization.<\/p>\n<p>In point of fact, USB to serial adapters don&#8217;t have their own USB class either (they return 0xFF for &#8220;Vendor Specific&#8221;).  So we have to whitelist the vendor\/product ID pairs of the USB adapter chips most commonly used in GPS mice; by far the most common of these, incidentally, is a doohickey called the Pacific Logic 2303.<\/p>\n<p>So here we are with our udev rules file that&#8217;s watching for a plugin event from anything on the whitelist.  The udev rule calls a Python script written by yours truly which launches a gpsd instance if one is not already running, then stuffs a notification up the daemon&#8217;s special control socket that said device might be a GPS.  Later, when a GPSD client app wants location data, the daemon will actually open every device on its stash list and attempt to recognize GPS information flooding from them (not a trivial process; the GPS information could arrive in any of 13 mutually incompatible formats, which are untangled from each other by a big honkin&#8217; state machine also written by yours truly).<\/p>\n<p>Astute readers will already see the problem.  We don&#8217;t actually have any guarantee that the thing behind any given whitelisted adapter is, in fact, a GPS.  But for six years this failure case remained theoretical.  Until yesterday.<\/p>\n<p>Yesterday, we got a plaintive bug report from a guy who was trying to mate a cute little Linux SBC called a <a href=\"http:\/\/www.gumstix.com\/\">Gumstix<\/a> with a GSM modem. A perfectly reasonable thing to do if you were, say, trying to remote-control some kind of instrumentation package over a GSM cell network.  Our guy complained that every time he plugged in one of his modems,  gpsd would spam a bunch of data at it.  This sometimes gave the modem indigestion.<\/p>\n<p>Well, guess what?  Both of the USB-to-serial adapters he tried using with his GSM modem were in our whitelist, and gpsd duly sent them the crapload of vendor-specific probe strings it uses to try to prod a GPS into returning an identifying response.  So our friend tried removing the GPSD package from the Gumstix, only to find that the KDE environment depends on it. FAIL.<\/p>\n<p>The workaround is to uninstall GPSD&#8217;s udev rules.  But now he&#8217;s going to have to peg GPSD&#8217;s version, or his modems will fall down go boom again right after his next upgrade pulls a new GPSD package installation and installs a new copy of our udev rules.<\/p>\n<p>This basically sucks all around.  And there&#8217;s no good fix.  And if there were one, the skeezy Pacific-Rim fly-by-nights who pump out the world&#8217;s production of GPS mice probably wouldn&#8217;t apply it.  Sigh&#8230;another wonderful day in the life of GPSD.<\/p>\n<p>UPDATE:  The person who reported the bug says I misunderstood his use case, though apparently not in an essential way.  <a href=\"http:\/\/fedetft.wordpress.com\/2011\/01\/07\/linux-today-too-much-plug-and-play\/\">You can read his description.<\/a><\/p>\n<p>UPDATE2: Ah, seems I conflated two bug reports from different people, one of which really did involve a Gumstix.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Welcome, ladies and gentlemen, to another darkly humorous tale of the seamy side of GPS interfacing. GPSD working with USB GPS mice has, when properly installed, lovely plug-and-play self-configuring behavior. That is, you plug a USB GPS into a USB port, the hotplug system notifies the gpsd daemon that the GPS is available, the daemon&hellip; <a class=\"more-link\" href=\"http:\/\/esr.ibiblio.org\/?p=2849\">Continue reading <span class=\"screen-reader-text\">Plug and Pray in GPS-land<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[32],"class_list":["post-2849","post","type-post","status-publish","format-standard","hentry","category-software","tag-gpsd","entry"],"_links":{"self":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts\/2849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2849"}],"version-history":[{"count":6,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts\/2849\/revisions"}],"predecessor-version":[{"id":5568,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts\/2849\/revisions\/5568"}],"wp:attachment":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2849"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}