Andrew Dunham 3df4df870b control/controlhttp: test that a control conn is healthy before using ... We've seen a bunch of cases where a captive portal or network with a firewall will allow a connection to the control server, successfully perform the Noise upgrade, but then fail immediately after trying to send any data on that now-upgraded connection. In many of these cases, we only see this behaviour on the plaintext connection over port 80. This interacts poorly with our controlhttp.Dialer's logic, which first tries to dial over port 80 (to avoid the overhead of double-encrypting, Noise and TLS), and only falls back to port 443/TLS if the connnection cannot be established or upgraded. In such cases, we'd essentially fail to connect to the control server entirely since we'd never fall back to port 443 (since the Noise upgrade succeeded) but we'd get an EOF when trying to do anything with that connection. This could be solved with the TS_FORCE_NOISE_443 envknob, but that's not a great experience for our users. Updates #13597 Signed-off-by: Andrew Dunham <andrew@du.nham.ca> Change-Id: I223dec0ae11b8f2946e3fb78dc49fcffc62470f3		2024-09-26 13:41:37 -04:00
..
noiseconn	control/controlhttp: test that a control conn is healthy before using	2024-09-26 13:41:37 -04:00
tooldeps	all: add test for package comments, fix, add comments as needed	2024-07-10 09:57:00 -07:00