HTTP/1.1 Digest authentication

Zaid Abdulla zaid at genieacs.com
Thu May 28 10:24:56 EDT 2015


On Thu, May 28, 2015, at 04:54 PM, Markus Mehlan wrote:
> Hi,
> 
> when I use the HTTP Digest authentication for a ConnectionRequest with
> HTTP/1.1 Header (./config/auth,json), the CPE must use the header 
> parameter "Connection: close" in the response, otherwise it doesn't 
> work. Why does Connection: keep-alive not work?
> A Test with curl was successful.
> curl -v --digest -u user:passsord 
> http://10.5.108.239:7777/651c50c244d715e78921a546532654b0

I'm struggling with a related issue as we speak. It may very well be the
exact same problem. Here's what I found:

1) The ACS sends connection request.

2) CPE replies with 401 and an authentication challenge and includes the
header "Connection: Keep-Alive".

3) The ACS generates the authentication header based on the given
challenge, and sends that using the already existing TCP connection.

The issue I found is that the device will disconnect the TCP connection
(by sending FIN) right after step 2. However, by the time the FIN packet
is received the ACS has already attempted to send the follow up request
(step 3) over the existing connection, and this results in a failure. By
the looks of it, it looks like a CPE problem that it sends a keep-alive
header and immedialty destroys the connection. This explains why it
works when the CPE sends "Connection: close" (haven't tested this
myself) as the ACS will be aware that the connection cannot be reused
and will open a new one.

A simple workaround is to wrap the following line in ap-functions.coffee
in a setTimeout() function to delay the response a little so that the
connection is already closed by the time the ACS send a follow up
request:

    callback(res.statusCode, authHeader)

I'm thinking of a less hacky workaround to implement. Ideas are welcome.

I've only had this problem with Tilgin devices. What is your device?

Zaid


More information about the Users mailing list