Hi,
my device is a measurement device for internet services
(Ethernet/Voip/IPTV). The device requests the VOIP configuration
from the ACS.
My problem was, that the device has closed the read-socket after
each response from the ACS. So the "keep-alive" took no effect
and the ACS sent the FIN. BTW HTTP/1.1 uses "Connection: keep-alive"
by default.
I fixed that and now it works as expected.
Best greetings,
Markus
Am 28.05.2015 um 16:24 schrieb Zaid Abdulla:
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
_______________________________________________
Users mailing list
[email protected]
http://lists.genieacs.com/mailman/listinfo/users
