Wigle upload fails with SSL memory allocation error on Cardputer Adv

[pfefferle]

Problem

Wigle file uploads fail with "SSL - Memory allocation failed" error on M5Stack Cardputer Adv.

Error Output

Wigle upload: file=260114_211403_wardriving.csv size=2027
Free heap: 59020
Largest free block: 31732
PSRAM size: 0
[ssl_client.cpp:36] _handle_error(): [start_ssl_client():303]: (-32512) SSL - Memory allocation failed
[NetworkClientSecure.cpp:159] connect(): start_ssl_client: connect failed: -32512
Connection failed!

Root Cause

The SSL handshake requires ~50KB of contiguous memory, but the heap is fragmented:

• Total free heap: ~59KB
• Largest contiguous block: ~31KB

The Cardputer Adv does not have PSRAM, so SSL cannot use external memory for its buffers.

Proposed Solution

Reduce SSL buffer sizes in the bruce_esp32-arduino-libs sdkconfig:

CONFIG_MBEDTLS_SSL_IN_CONTENT_LEN=4096
CONFIG_MBEDTLS_SSL_OUT_CONTENT_LEN=4096

This would reduce SSL memory requirements by ~24KB.

[bmorcelli]

I fixed most of the memory issues last week. Maybe it's working on Beta

[pfefferle]

I will give it a try! Thanks for answering even after I closed it!

[pfefferle]

Have the same issues on Dev. I try to debug it a bit more.

[pfefferle]

Update: Further debugging on dev branch

Tested on the dev branch. The SSL memory issue is resolved - the connection succeeds and file data is transmitted. However, the upload fails:

Current behavior

Upload: filename=260114_211403_wardriving.csv, filesize=2027, boundary=BRUCE1938713868
Content-Length: 2180
File transfer complete, waiting for response...
Client connected: 0, available: 0
Server response length: 0
Server response: 
Upload success: NO

The file data is transmitted, but the server closes the connection without sending a response. The upload is not successful - the data does not appear on Wigle.

Bug found: Content-Length calculation was incorrect

The send_upload_headers() function in wigle.cpp had an incorrect Content-Length calculation. The multipart body overhead was calculated as 90 bytes, but the actual overhead is 95 bytes.

Issue: The original code comment said Content-Type: text/csv\r\n = 19 but it's actually 24 bytes (22 chars + CRLF).

Fix: Changed the constant from 90 to 95:

// Content-Type: text/csv\r\n = 24 (was incorrectly 19)
// Total overhead = 2*boundary.len + filename.len + 95 (was 90)
int content_length = filesize + 2 * boundary.length() + filename.length() + 95;

Validated: Multipart format is correct

Tested with curl using a manually crafted multipart body that exactly mimics what Bruce sends:

# Manually crafted Bruce-style multipart body
{
  printf -- "--%s\r\n" "$boundary"
  printf "Content-Disposition: form-data; name=\"file\"; filename=\"%s\"\r\n" "$filename"
  printf "Content-Type: text/csv\r\n"
  printf "\r\n"
  cat /tmp/test_wigle.csv
  printf "\r\n"
  printf -- "--%s--\r\n" "$boundary"
  printf "\r\n"
} > /tmp/bruce_body.bin

curl -X POST "https://api.wigle.net/api/v2/file/upload" \
  -H "Authorization: Basic <token>" \
  -H "User-Agent: bruce.wardriving" \
  -H "Connection: close" \
  -H "Content-Type: multipart/form-data; boundary=$boundary" \
  --data-binary @/tmp/bruce_body.bin

Result: {"success":true,...} - upload works with the same format Bruce uses.

Conclusion

The multipart format and Content-Length calculation (after the fix) are correct. The issue is likely in the ESP32 WiFiClientSecure transmission, not the request format. Possible causes:

• SSL buffer/timing issues specific to ESP32
• Connection being dropped during or after transmission
• Server receiving incomplete data despite ESP32 reporting transfer complete