LoTW Manual Sync fails during upload step

[slashTPA]

Description
Recently the manual sync in Cloudlog consistently fails with a generic "Upload failed" message in the GUI.

After troubleshooting the local environment on an Ubuntu server running Cloudlog 2.8.14, I was able to narrow down the exact behavior of the failure.

Debugging Steps Taken & Findings:
Network & TLS: A direct connection test via curl -Iv https://lotw.arrl.org/ shows that the TLSv1.3 handshake completes successfully from the server. The connection itself is fine.

LoTW Download/Import: The import mechanism works perfectly. Manually uploaded QSOs (via local desktop TQSL) are fetched and matched correctly by Cloudlog during the manual sync.

Log Analysis: Enabling log_threshold = 2 revealed that Cloudlog triggers the download query but truncates/fails on the upload. I noticed a potential typo in the logged fetch URL (.../lotwuser/lotwreport.adi... missing the hyphen), though the download still processes.

File Generation vs. Upload: Cloudlog is successfully generating the signed .tq8 file in the uploads/lotw/ folder with a fresh timestamp (e.g., dg5cw-2026-06-23-15-14-47-cloudlog.tq8). Even though the .tq8 file is successfully created by Cloudlog's internal OpenSSL routine, the final HTTP POST transmission to the ARRL upload endpoint fails silently and triggers the "Upload failed" UI message.

Conclusion
The local cryptographic signing and file creation work fine, but the actual upload payload is rejected or misrouted. It seems Cloudlog needs an update to adjust to new ARRL upload API specs (?).

Environment:

Cloudlog Version: 2.8.14
OS: Ubuntu 24.04 / Apache 2.4.58 / PHP 8.x
OpenSSL / Native PHP LotW signing (no local TQSL binary used)

[magicbug]

Test PHP's cURL directly against https://lotw.arrl.org/lotw/upload — the CLI curl and PHP's cURL extension can differ in their CA bundles, proxy config, and SSL settings.

Check PHP's CA certificate bundle — if PHP's bundle is stale or pointing to the wrong file, TLS verification can fail even when the command-line curl works.

Check open_basedir restrictions — Apache PHP configs sometimes restrict filesystem access, which could cause realpath() or the file read to silently fail when building the upload payload.

Manually POST a .tq8 file with curl -v and inspect the full response body — the code looks for the specific string , so any deviation (login redirect, CAPTCHA, error page, changed acknowledgement string) would trigger "Upload Failed".

Check for proxy environment variables — system-level http_proxy/https_proxy variables affect PHP's cURL but not necessarily the command-line curl test the user ran.

I am not seeing any other reported issues for LoTW not uploading in fact 100+ that i host for people are working just fine so this has to be a configuration issue

[slashTPA]

Hi Peter,

Thanks for the hints! I ran the tests as requested, and it turns out this is not a PHP or Cloudlog configuration issue after all.

Even using the standard command-line curl to manually POST the compiled .tq8 payload file directly from the server shell results in a consistent HTTP 1.1 408 Request Timeout from the ARRL server. This happens on both endpoints (/lotw/upload and /lotw-user/upload).

Here is the full verbose output from the CLI curl test:

POST /lotw-user/upload HTTP/1.1
Host: lotw.arrl.org
User-Agent: curl/8.5.0
Content-Length: 4194
Content-Type: multipart/form-data; boundary=------------------------8gGpfBYGFjPcgnN4aOvq31

• We are completely uploaded and fine
  < HTTP/1.1 408 Request Timeout
  < Date: Tue, 23 Jun 2026 17:20:51 GMT
  < Server: Apache/2.4.62 (Red Hat Enterprise Linux) OpenSSL/3.2.2
  < Content-Length: 221
  < Connection: close
  < Content-Type: text/html; charset=iso-8859-1

<title>408 Request Timeout</title>

Request Timeout

Server timeout waiting for the HTTP request from the client.

As you can see, the TLS 1.3 handshake is perfectly fine, and the payload is completely transmitted (We are completely uploaded and fine). However, the ARRL's Apache server hangs indefinitely and forcefully closes the connection with a 408 Timeout instead of responding with the expected acknowledgment string.

Since your hosted instances work fine, it seems the ARRL's upstream infrastructure/WAF is silently dropping or stalling requests originating specifically from my server's IP range or hosting provider during a POST request.

I will close this issue/ticket here as it's clearly an upstream routing or infrastructure issue on the ARRL side blocking my VPS. Thanks for point me to the manual POST test!

[slashTPA]

Update / Solved:

It's working perfectly now! The root cause was an asymmetric network MTU issue caused by my portable setup environment (running Cloudlog inside a UTM virtual machine on a laptop, tethered to an iPhone cellular hotspot).

The initial 408 Request Timeout happened because the VM interface was strictly set to a standard MTU of 1500. While small download chunks passed through, the larger outbound .tq8 POST payload packets exceeded the carrier's MTU limit and disappeared into a black hole. This caused the connection to stall until the ARRL server dropped it.

After clamping the VM network interface down to a mobile-friendly MTU:

Bash
ip link set dev enp0s1 mtu 1300
The packet fragmentation issue disappeared instantly. The manual LoTW sync via the Cloudlog web interface now processes and completes successfully within seconds.

Apologies for the noise, and thank you very much for pointing me in the right direction to test the raw payload via CLI! I'm closing this issue.