gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Opening port for remote access to gpsd


From: Stein, S. Joshua
Subject: RE: Opening port for remote access to gpsd
Date: Thu, 23 Jul 2020 20:39:58 +0000

Hello Gary,

With help from some others, I have found the solution. I will add the details 
you asked for below just to wrap this up.

TL;DR: Modify the gpsd.socket (for me, located at 
/lib/systemd/system/gpsd.socket) file as follows:
Change line: 
ListenStream=127.0.0.1:2947
To
ListenStream=0.0.0.0:2947

And make sure the '-G' option is specified in gpsd default file (for me, 
located at /etc/default/gpsd):
# Other options you want to pass to gpsd
GPSD_OPTIONS="-G"

Making those two changes brought me to the solution of being able to attach to 
the daemon from a remote machine.

-----------------------------------------------------------------

In any event, in order to be as transparent as possible, I will answer Gary's 
questions below:

>-----Original Message-----
>From: gpsd-users <gpsd-users-bounces+josh=anl.gov@nongnu.org> On Behalf Of 
>Gary E. Miller
>Sent: Wednesday, July 22, 2020 2:58 PM
>To: gpsd-users@nongnu.org
>Subject: Re: Opening port for remote access to gpsd
>
>Yo S. Joshua!
>
>On Wed, 22 Jul 2020 15:31:37 +0000
>"Stein, S. Joshua" <josh@anl.gov> wrote:
>
>> I have an application wherein a GPS unit is attached to a Raspian 
>> machine. I have gpsd running and receiving info from the GPS on 
>> /dev/ttyUSB0. Connection to the daemon works fine on localhost.

>A common configuration.  But what distro?  distro version? gpsd version?

cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"

gpsd -V
gpsd: 3.17 (revision 3.17)


>> I would like to connect to that same daemon from a remote machine 
>> using the HOST kwarg when instantiating the gps object. As it stands 
>> now, this will fail since the daemon is set up to only listen to 
>> localhost.

>A common default, but this is your distro defaults, not gpsd defaults.

>> So I change the arguments which fire off gpsd and add the ‘-G’ flag.

>Uh?  Change what?  Where?

>What is your entire set of options?

Apologies on not being clearer here - I changed the file /etc/default/gpsd and 
added "-G" as follows:
GPSD_OPTIONS="-G"

That is the only option specified at this time

>> Upon reboot, I see that gpsd has been invoked properly:
>> 
>> ● gpsd.service - GPS (Global Positioning System) Daemon

>If you call using gpsd under systemd(umb) "proper".  I do not.

Understood. My organization uses systemd, so my hands are tied in this regard.

>Did you use "-n"?  Do you know gpsd is really running?  Run these two, as 
>root, and report back:
>
>   # pstree -paul | fgrep gpsd
>   # netstat -apn | fgrep 2947

I do not use -n as it did not come that way in my disto (via the default). 
Note that this came to me via "pip install gps" as of about a week ago
I know that gpsd is indeed running as I can connect to it locally. 
Below is the output for the commands you asked for:

pi@raspberrypi:/lib/systemd/system $ pstree -paul | fgrep gpsd
  |-gpsd,344,gpsd -G /dev/ttyUSB0
  |               |-grep,633 -F --color=auto gpsd
pi@raspberrypi:/lib/systemd/system $ netstat -apn | fgrep 2947
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:2947            0.0.0.0:*               LISTEN      
-
tcp        0   2706 192.168.1.121:2947      192.168.1.211:60618     ESTABLISHED 
-
tcp6       0      0 ::1:2947                :::*                    LISTEN      
-

** NOTE ** The above output shows the configuration after I changed the socket 
configuration file, so includes the 0.0.0.0 address as well as the (currently) 
connected client.

>> However when I attempt to connect remotely, I am prevented from doing 
>> so (ConnectionRefusedError).

>Before connecting from client, you need to know the daemon is running 
>"properly" on the host.

Which it was except for the "blocked" socket for remote connections

>> If I kill the daemon process (gpsd.socket and gpsd.service) and then 
>> invoke gpsd from the command line with:
>> >gpsd -G \dev\ttyUSB0

>You forgot -n

As I stated above, the disto I received via pip install did not specify the 
'-n' option. I did not think it necessary, so did not add. I'm still not sure 
why I want the daemon to continually poll the GPS or why that would make a 
difference to my specific issue.

>> I am able to connect remotely just fine. So it appears the issue is 
>> with how systemd (systemctl) is firing off the daemon

>Yup.  And the systemd files you are using are NOT part of gpsd, so we have no 
>idea what your unnamed distro did wrong.

So apparently what it did wrong was to specify a gpsd.socket "ListenStream" 
parameter to localhost only.

>> I then tried changing the SocketMode parameter within the gpsd.socket 
>> file from:

>Nor would I expect it to.  You are tying to use TCP to connect remotely, not a 
>socket.  Sockets are local only.

I'm not sure what you mean by "sockets are local only". The socket in this case 
(for TCP connections) is an endpoint for the connection defined by the ip 
address and the port. 

>> I realize this issue is likely one of my incomplete understanding of 
>> the systemd/systemctl process for handling sockets

>Thinking of this as a socket problem is one of your mistakes.

I disagree, but that is likely just a matter of semantics. The term socket and 
port get mangled depending on the transport layer being utilized.

>> but my hope in
>> posting here is that someone else has encountered this issue and can 
>> point me to the “AHA!” moment.

>I don't use sysytemd(unmber) with gpsd and recommend against it.  It causes 
>much grief, as a search of the list archives will show you.

As stated above, I am bound by our admin practices to adopt the systemctl 
(systemd) architecture. In all honesty, I've found it pretty nice overall. This 
was my first foray into the socket configuration however and appreciate the 
opinions.

>We can't debug what we cant see, so provide us your gpsd.service and config 
>file.

For clarity, here are my systemd config files:

pi@raspberrypi:/lib/systemd/system $ cat gpsdctl@.service
[Unit]
Description=Manage %I for GPS daemon
Requires=gpsd.socket
BindsTo=dev-%i.device
After=dev-%i.device

[Service]
Type=oneshot
Environment="GPSD_SOCKET=/var/run/gpsd.sock"
EnvironmentFile=-/etc/default/gpsd
EnvironmentFile=-/etc/sysconfig/gpsd
RemainAfterExit=yes
ExecStart=/bin/sh -c "[ \"$USBAUTO\" = true ] && /usr/sbin/gpsdctl add /dev/%I 
|| :"
ExecStop=/bin/sh -c "[ \"$USBAUTO\" = true ] && /usr/sbin/gpsdctl remove 
/dev/%I || :"


pi@raspberrypi:/lib/systemd/system $ cat gpsd.service
[Unit]
Description=GPS (Global Positioning System) Daemon
Requires=gpsd.socket
# Needed with chrony SOCK refclock
After=chronyd.service

[Service]
Type=forking
EnvironmentFile=-/etc/default/gpsd
ExecStart=/usr/sbin/gpsd $GPSD_OPTIONS $DEVICES

[Install]
WantedBy=multi-user.target
Also=gpsd.socket


pi@raspberrypi:/lib/systemd/system $ cat gpsd.socket
[Unit]
Description=GPS (Global Positioning System) Daemon Sockets

[Socket]
ListenStream=/var/run/gpsd.sock
ListenStream=[::1]:2947
ListenStream=0.0.0.0:2947
SocketMode=0600

[Install]
WantedBy=sockets.target


pi@raspberrypi:/etc/default $ cat gpsd
# Default settings for the gpsd init script and the hotplug wrapper.

# Start the gpsd daemon automatically at boot time
START_DAEMON="true"

# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="true"

# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES="/dev/ttyUSB0"

# Other options you want to pass to gpsd
GPSD_OPTIONS="-G"


>Before you send that, have you read the doc on this?

>https://gpsd.io/troubleshooting.html#systemdtroubleshooting

Yes, I had read that.

>RGDS
>GARY
>---------------------------------------------------------------------------
>Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>       gem@rellim.com  Tel:+1 541 382 8588
>
>           Veritas liberabit vos. -- Quid est veritas?
>   "If you can't measure it, you can't improve it." - Lord Kelvin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]