On 03/11/2022 00:47, Gary E. Miller wrote:
So I setup 2 test hosts. One send NMEA with socat this way:
Thank you for investing so much time in this damn issue !! Let's hope
we can get to a solution..
And I see input to gpsd stop, but the connection does not drop,
because the
default Linux tcp timeout is two hours.
Actually before I was blocking server side, but I have now done
exactly the same as your test...
After around 15 mins I see this server side:
root@TSB-1650:~# date
Thu Nov 3 10:44:56 UTC 2022
root@TSB-1650:~# ps aux|grep socat
root 15077 0.0 0.1 4304 1864 pts/0 S 09:37 0:00 socat
EXEC:gpspipe -B -r TCP-LISTEN:2948,reuseaddr,fork
root 27631 0.1 0.1 4304 1428 pts/0 S 10:42 0:00 socat
EXEC:gpspipe -B -r TCP-LISTEN:2948,reuseaddr,fork
root 28647 0.0 0.1 2092 1160 pts/0 S+ 10:45 0:00 grep
socat
root@TSB-1650:~# 2022/11/03 10:58:00 socat[27631] E write(7,
0x7f696da8, 366): Connection timed out
I reenable the feed:
# iptables -D INPUT -p tcp --source-port 2948 -j DROP
If I wait 15 mins (after the socat timeout) then gpsd doesn't seem to
recover
What do you get when you do this on the client:
client ~ # ls /proc/sys/net/ipv4/tcp_keepalive* -l
-rw-r--r-- 1 root root 0 Nov 2 17:43
/proc/sys/net/ipv4/tcp_keepalive_intvl
-rw-r--r-- 1 root root 0 Nov 2 17:43
/proc/sys/net/ipv4/tcp_keepalive_probes
-rw-r--r-- 1 root root 0 Nov 2 17:43
/proc/sys/net/ipv4/tcp_keepalive_time
client ~ # cat /proc/sys/net/ipv4/tcp_keepalive*
75
9
7200
I checked this on client and server and see exactly the same debian
defaults as you
I've redone the 2 tests (kill socat with recovery and block client
side where gpsd doesn't recover) at log lvl 10 as you suggest.
New debug logs attached separately as broke the 400k limit
Thanks again
Nick