Raspberry Pi 2 GPSD Not Running - raspberry-pi2

I am following this tutorial to hook up Adafruit's Ultimate GPS Breakout to my Raspberry Pi 2. I have carefully read each step.
When I run gpsmon /dev/ttyUSB0, it displays expected output with my location, speed, etc. When I run cgps -s, however, I get this message cgps: no gpsd running or network error: -4, can't create socket.
The really weird thing is that the GPSD seems to be failing. Here is me trying to start it:
pi#raspberrypi:~$ sudo service gpsd status
[FAIL] gpsd is not running ... failed!
pi#raspberrypi:~$ sudo service gpsd restart
[ ok ] Restarting GPS (Global Positioning System) daemon: gpsd.
pi#raspberrypi:~$ sudo service gpsd status
[FAIL] gpsd is not running ... failed!
pi#raspberrypi:~$ sudo service gpsd start
pi#raspberrypi:~$ sudo service gpsd status
[FAIL] gpsd is not running ... failed!
So, it is apparent that cgps is failing because GPSD is not starter. Any suggestions to get GPSD working?
EDIT
When I run sudo gpsd -N -D3 -F /var/run/gpsd.sock, I get this output:
gpsd:INFO: launching (Version 3.6)
gpsd:ERROR: can't bind to IPv4 port gpsd, Cannot assign requested address
gpsd:ERROR: can't create IPv6 socket
gpsd:DATA: command sockets creation failed, netlib errors -1, -1

Late answer. However I just bumped into this problem and found that my /etc/network/interfaces didn't exist. Thusly there was no loopback interface present. If interfaces doesn't exist, try creating it by running sudo nano /etc/network/interfaces and add:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
(Or as it suits your setup.)
Then run ifup -a and check if there's a new interface by running ifconfig. It should be somewhat like:
eth0 Link encap:Ethernet HWaddr b8:27:eb:16:bc:52
[...]
lo Link encap:Local Loopback
[...]
Hope it works for others as well.

For unrelated reasons, I reimaged my Pi, and the gps module is now working as expected. I don't know what was wrong last time, but it is working now.

Related

Unable to set correctly a firewall in mininet with sdn and opeflow ovs (UDP Version )

I'm experimenting with mininet in ubuntu 14 in order to create a basic firewall which blocks the udp packets from one host ( h1= 10.0.0.1 ) to another ( h4= 10.0.0.4 ).
Those hosts are in the same vlan and in different switchs (if that can be of any help). Also I would like to block it the udp packets which the destination port as 5001.
To do it so, i have launch two xterm in h1(in mininet) in order to check the ping is working correctly and also launch the packets to h4. xterm h1: "iperf -u -c10.0.0.4 -p 5001 -i 5 -b 200K -t 360".
In mininet I also have open a xterm h4 to set it up as a server listening in the port 5001. xterm h4: "iperf -s -u -p 5001 -i 5​".
When I guess the rule I have to introduce is this one "sh ovs-ofctl add-flow s1 udp_dst=5001,nw_proto=17,actions=drop"
But, it doesnt work due to the packets are still arriving. The ping works fine, but ( and here comes the main problem) the packet arrives at the server and it shouldn't.
Any help please?
Thank you very much
Here I leave you the screenshots of the network topology and also what I appear in the xterm windows.

`oc cluster up` fails during initial startup

I am trying out okd but it fails for me during the oc cluster up port check step. The debug output is not very verbose to be polite. Do you have an idea what to look for.
$ oc cluster up
Getting a Docker client ...
Checking if image openshift/origin-control-plane:v3.11 is available ...
Checking type of volume mount ...
Determining server IP ...
Checking if OpenShift is already running ...
Checking for supported Docker version (=>1.22) ...
Checking if insecured registry is configured properly in Docker ...
Checking if required ports are available ...
error: a port needed by OpenShift is not available
But the required ports 53 and 8443 are not taken
sudo netstat -tulpn | grep '\(:8443\|:53\)'
At least netstat returns nothing
Versions:
$ oc version
oc v3.11.0+0cbc58b
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO
and
CentOS Linux release 7.6.1810 (Core)
I have not been able to find out how to turn debugging on so that it is possible to see what it really checks for.
Has the user you are running the command as enough priveledges to open privileged ports (ports <1024) on your host machine?
try running cluster up as root or with sudo
yes I starting whole okd as root user

How to print GPS location to stdout (Ubuntu 16.04 / 18.04)?

I'm a complete newbie with GPS devices on Linux.
I have a GlobalSat G-STAR IV USB device and I would just like to get the GPS location (lat, long) printed to stdout. How can I achieve that? I'm reading about gpsd, but not sure how to get the actual location. The documentation seems old.
Any common tools etc for this?
It seems that with
$ sudo stty -F /dev/ttyUSB0 4800
$ sudo cat /dev/ttyUSB0
I can read some NMEA(?) data from the device:
$GPGGA,113935.199,,,,,0,00,,,M,0.0,M,,0000*5B
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPRMC,113935.199,V,,,,,,,100918,,,N*41
$GPGGA,113936.186,,,,,0,00,,,M,0.0,M,,0000*56
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPRMC,113936.186,V,,,,,,,100918,,,N*4C
$GPGGA,113937.185,,,,,0,00,,,M,0.0,M,,0000*54
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPRMC,113937.185,V,,,,,,,100918,,,N*4E
$GPGGA,113938.200,,,,,0,00,,,M,0.0,M,,0000*55
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
I still don't see $GPGLL that should contain the location..?
Edit: I also get this:
$ sudo gpsd /dev/ttyUSB0 -N
gpsd:ERROR: can't bind to IPv4 port gpsd, Address already in use
gpsd:ERROR: maybe gpsd is already running!
gpsd:ERROR: can't bind to IPv6 port gpsd, Address already in use
gpsd:ERROR: maybe gpsd is already running!
I have killed all gpsd instances and deleted the socket, but still getting that..
The output you posted from sudo cat /dev/ttyUSB0 is what you would expect for a GPS module, which does not (yet) have a fix, i.e. it does not have enough information to calculate its current position (+other information).
The only information provided by the messages is the current time of day, 11h39m35s, etc. Out of the messages you receive from your GPS module, not only the $GPGLL message can tell you about your location, but also the $GPGGA and $GPRMC messages that you do receive. If your module had a fix, you would not see several commas in a row but actual values in between.
More details about the format of the different messages can be found in this overview.
What is the likely root cause for the missing GPS fix (assuming your hardware + antenna are fine)?
You have just started using this module fresh from the factory and it needs some time to get ahold of its coordinates. The time to first fix for such a brand new device can be up to 15 minutes.
The GPS signal strength is not strong enough at the location of your module.
Therefore my advice:
Make sure that at your location, the GPS signal from the satellites is strong enough. Ideally by moving outdoors.
When your module has never had a fix before, give your module some time. Wait for up to 20 minutes.
GPSD:
GPSD, if installed, is normally started automatically, when you plug in a GPS module. You can check the current status with
systemctl status gpsd.service
systemctl status gpsd.socket
If active, the gpsd deamon reads out the GPS-data coming via the serial interface and provides it to other applications via a socket on a specific port (default: port 2947). In that case the serial port is not accessible anymore by serial monitors.
Steps to make this device work were:
# Switch the device to NMEA mode
sudo gpsctl -f -n /dev/ttyUSB0
# Set baudrate to 4800
sudo stty -F /dev/ttyUSB0 4800
# Start gpsd
gpsd -S 4000 /dev/ttyUSB0
Now create a TCP/IP socket connection to localhost:4000 and say ?WATCH={"enable":true,"json":true}; or use libgps etc:
http://www.catb.org/gpsd/client-howto.html

GPSD not getting a good fix

I have a GPS module connected to a Raspberry Pi via USB.
For some reason I can't seem to get a fix using:
cgps
it doesn't seem to get a fix and terminates.
I've also tried:
sudo killall gpsd
sudo gpsd /dev/ttyUSB0 -F /var/run/gpsd.sock
and then tried cgps again, but that doesn't seem to work either.
I even tried:
sudo nano /etc/default/gpsd
and changed the line:
GPSD_OPTIONS=""
to:
GPSD_OPTIONS="/dev/ttyACM0"
which apparently worked for others around the web, but after a reboot, that didn't work either.
But for some reason when I do:
gpsmon /dev/ttyUSB0
I get a full readout of data; lat, lon, Sats, altitude, ext.
Is there a way to output gpsmon /dev/ttyUSB0 sentences to a text file?
Also, why can't I obtain a fix using cgps or something similar?
gpsd is a beautiful application to simplify gps use, but it can be a little confusing.
If you're using a Rasbian, or some apt based package system it is best to configure it with sudo dpkg-reconfigure gpsd to avoid complications (tyqos), but isn't necessary. We have preferences for, but you may not,
autostart,
-n Don't wait for a client
-G to listen on all addresses,
-b Broken-device-safety mode, and
autofind
The resultant configuration file looks like
# Default settings for gpsd.
# Please do not edit this file directly - use `dpkg-reconfigure gpsd' to
# change the options.
START_DAEMON="true"
GPSD_OPTIONS="-n -G -b"
DEVICES=""
USBAUTO="true"
GPSD_SOCKET="/var/run/gpsd.sock"
The primary stumbling block with this approach while gpsd is running in this fashion is it will grab the gps before you can. Attempts to independently and directly access the device /dev/whatever will fail as busy.
If you wish to go that route, for whatever reason, before doing anything else, make sure gpsd is not running.
sudo killall gpsd
and remove any sockets gpsd might have left behind,
sudo rm /var/run/gpsd.sock
Check the location of your gps by attaching it and tracking where it went with dmesg | tail. It will look something like
[67338.935645] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[67338.935650] usb 1-1.2: Product: USB-Serial Controller
[67338.935653] usb 1-1.2: Manufacturer: Prolific Technology Inc.
[67338.936154] pl2303 1-1.2:1.0: pl2303 converter detected
[67338.937953] usb 1-1.2: pl2303 converter now attached to ttyUSB1
[67339.806917] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[67339.807306] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[67340.018016] pps_ldisc: PPS line discipline registered
[67340.018321] pps pps0: new PPS source usbserial1
[67340.018330] pps pps0: source "/dev/ttyUSB1" added
Then you can check for output with sudo cat /dev/ttyUSB1...or whatever, but you could do that with gpsd running. (You can also pump this into a text file sudo cat /dev/ttyUSB1 > gps_dump.txt, or your gpsmon /dev/ttyUSB0 >gps_dump.txt, but there are more elegant solutions.)
The flip side of the confusion is no gps output from the gpsd because it isn't running or configured 'properly'. (either turned off, not started, or pointing to the wrong device). A few application will tell you it's not running, many just sit in silence without any data. I know of none that will tell you gpsd has been manually set to the wrong device.
If you have killed gpsd, or do not have it automagically start, ensure that it is running with sudo /etc/init.d/gpsd restart
Unless you're doing something odd with odd hardware most cases will spit back data with gpsd in these settings, sparing the need for diagnostic settings.
However, bear in mind cgps will timeout if there is no fix. Check your skyview, and Time To First Fix. xgps, on the other hand, is more resilient for failures and provides clues for the absence, or quality of data. If you have an X server, xgps is actually my preferred test for "is it working". If you don't, but have your Pi on a network (xgps 192.168.0.6, or whatever, because the other machine has gpsd-client installed). Another option is to ssh -X user#192.168.0.6 and then execute xgps)
Telneting into gpsd, while interesting, is another tier diagnostic, as are others.
And finally, a shameless plug for a Python client for gpsd (gps3.py) as means to access the data from a gpsd. It still is alpha, but it doesn't import historical cruft.
You may be binding to the wrong serial. You discover the serial for your GPS device by navigating to the folder below without the device plugged in, then refreshing with the device plugged in.
cd /dev/
ls
My device is called "ttyACM0"
Install the requisite packages.
sudo apt-get install gpsd gpsd-clients python-gps
Stop Daemons
sudo systemctl stop gpsd.socket
sudo systemctl disable gpsd.socket
Expose Service to public ports and localhost
vim /lib/systemd/system/gpsd.socket
Change 127.0.0.1 to 0.0.0.0
Stop GPSD services
sudo killall gpsd
Bind service to serial device
sudo gpsd /dev/ttyACM0 -F /var/run/gpsd.sock
Show GPS Data
gpsmon
This video shows step by step how to do what you are looking for.
How to install GPS on RaspberryPi
https://www.youtube.com/watch?v=A1zmhxcUOxw

KVM/Bridge: No Route To Host

I've setup a VM on Fedora 17 with KVM and have configured a bridge network for the KVM. Both the host and the VM use manual IP configuration, with the host's IP as 192.168.0.2, the VM's 192.168.0.10.
From the VM I can connect to the host without any problems, but from the host I can't SSH to the VM,even though I still can ping the KVM from the host. Trying to ssh just gives me the result "no route to host".
Oh, I have iptables disabled so I don't think this is the problem of the firewall.
Also ensure that the kernel is configure for ip forwarding:
$ sudo sysctl -a | grep net.ipv4.ip_forward
net.ipv4.ip_forward = 1
It should have a value of 1, not 0. If needed, enable with these commands:
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf
There are two ways :
* Using proxy tunnel to create a channel for host from guest :
From guest run following command :
ssh -L 2000:localhost_ip:2000 username#hostip
explore ssh man to get the inside.
* Difficult to setup, but proper configuration while running guest :
follow
http://www.cse.iitd.ernet.in/~prathmesh/random.html#Connecting_qemu_guest_to_real_network