Timeout connecting to adept

[nottledim]

There’s a few topics about this but none quite address my issue: I’m get a continuous supply of these in my logs:

[piaware] 2021/02/15 16:56:47 Connecting to FlightAware adept server at 70.42.6.198/1200
[piaware] 2021/02/15 16:56:47 Connection with adept server at 70.42.6.198/1200 established
[piaware] 2021/02/15 16:57:02 Connection attempt with adept server at 70.42.6.198/1200 timed out
[piaware] 2021/02/15 16:57:02 reconnecting in 51 seconds...

I can telnet and connect with nc but the connection always terminates after 20-40s with a timeout. Why does the connection keep failing?

I’m using docker images from mikenye not rPi.

[obj]

@nottledim

Why does the connection keep failing?

You have a problem with your networking.

[nottledim]

I’d never have thought. Any idea what it might be? It pings, traceroutes etc. If I connect then should there be a message or reply or something to test it?

[obj]

Port 1200 expects TLS, you could use openssl s_client to connect and see if at least the TLS handshake is completing. But if nc is timing out then you’re not even getting that far. Step 1 is to work out why TCP is broken; perhaps a firewall problem?

[nottledim]

Thanks, that’s helpful. s_client connects and returns certificates and all that but there is a verification error: Verification error: self signed certificate in certificate chain. Connection remains open for 60s. Is all that expected?

This is on host computer not from docker container. That’s harder to test

[nottledim]

Here’s a workaround for the reference book:

https://github.com/moby/moby/issues/22297

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

That’s on docker host. It’s because docker is not handling MTU on interfaces correctly (I think)

Anyway bodge or not, I’m on line again

[obj]

@nottledim

Verification error: self signed certificate in certificate chain . Connection remains open for 60s. Is all that expected?

That’s normal; we’re using an internal CA chain (shipped with piaware itself) that s_client won’t know about by default.

@nottledim

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Ugh, path MTU again, that really is the Achilles heel of TCP.

[nottledim]

I’ve spent days trying to sort my network out. I’ve no idea what went wrong but I know a lot more about MTU than I did. C’est la vie. Thanks for your help.