Error: socket hang up


I’m experiencing an error: socket hang up when I use the ‘summon’ button on the GUI. When I look at the debug log everything looks correct with the exception of the error. The device checks in after the error message but none of the geneieacs processing occurs (setting values, etc), I’m guessing due to the error.

The odd part is this looks like some kind of timing error or node.js TCP stack ‘feature’ as Postman exhibits the same behaviour but curl and python (requests lib) work just fine (i.e. they both return 200 and not the hangup error). I’ve verified the exchange is correct using Wireshark (i.e. there is actually an HTTP 200 being returned by the device in the TCP stream) so everything on the network side and digest auth. algorithm is working as it should.

Is there a timing parameter I need to adjust and/or what else could be causing this issue?



genieacs version 1.2.1 running on ubuntu 20.04 (raspberry pi 4 with 8G RAM)

If I have to guess I’d say that the HTTP response from CPE is not terminated properly. Did you try opening the URL from a web browser?

I used curl (which I think should be the same ?) and it returns HTTP 200 (and I can see the same HTTP 200 in the Wireshark capture). I’m not entirely certain how I would try this via a browser as I need to provide digest authentication (i.e. calculate the response). Is there a browser extension available that will do this?


Web browsers support Digest authentication. You’ll be prompted to enter the username and password.

There you go, learned something new.

Going directly to the URL from the browser appears to work just fine (no error reported) but I’d think that would be the case as curl works okay. Is there something else I can check (timeout value or some other config option)?


Can you share a Wireshark capture? Need to verify that the response from the CPE is a valid HTTP message.

Here’s a screen shot of the Wireshark with the response ‘highlighted’.


The response is missing Transfer-Encoding or Content-Length headers. Definitely not a valid HTTP response.

Thanks for the diagnosis - I’ll have to follow up with the tr-69 agent authors. Any ideas on why curl/web browser are okay with the response?


I think they may be more lenient when it comes to issues like this.