Why does curl intermittently return (56) after HTTP/1.1 200 OK from a UBUS JSON-RPC endpoint?

For Developers
1

I'm working with an embedded Linux AP that exposes a UBUS JSON-RPC API (uhttpd/rpcd).

The login request is:

curl -v -k \
  -H "Content-Type: application/json" \
  -d '{"id":1,"jsonrpc":"2.0","method":"call","params":["00000000000000000000000000000000","session","login",{"username":"admin","password":"***"}]}' \
  https://192.168.4.8/ubus

My expected flow is:

session.login
    ↓
receive ubus_rpc_session
    ↓
controller.core.get_clients_range

Running the same command repeatedly with the same payload and credentials produces inconsistent results.

A successful run returns:

> POST /ubus HTTP/1.1

< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Content-Type: application/json

{"jsonrpc":"2.0","result":[0,{"ubus_rpc_session":"..."}]}

A failed run returns:

> POST /ubus HTTP/1.1
> Host: 192.168.4.8
> Content-Type: application/json
> Content-Length: 154

< HTTP/1.1 200 OK
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: application/json

curl: (56) Error

In the failed case, curl reports that all 154 request bytes were uploaded, but no response body is received before the connection closes.

This is reproducible. Running the same command repeatedly gives roughly:

  • ~40 failures
  • ~10 successes

When the login succeeds, I immediately call controller.core.get_clients_range using the returned ubus_rpc_session. That second request can also fail with the same curl: (56) error.

Additional observations:

  • The AP is reachable (no packet loss while pinging).
  • The same JSON-RPC calls work from Postman.
  • The same calls also work from my browser application (Vite/Svelte) communicating with the AP.
  • The intermittent failures are observed in my curl-based test environment.

it important to note i do not have ssh acces to the grandstream GWN7660LR AP
and i have tried modifying the curl tags in numerous ways that include --trace-ascii
\

Warning: --trace-ascii overrides an earlier trace/verbose option
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   154    0     0  100   154      0   1469 --:--:-- --:--:-- --:--:--  1480
curl: (56) Error

My question is: given that the server responds with HTTP/1.1 200 OK but the response body is mostly never delivered, what server-side or HTTP-level conditions would typically cause curl: (56) in this situation?