HG8245Q – ONT HTTP Digest authentication issue
Issue Description
In our GPON network we use TR069 to manage the ONTs. We have observed a weird behavior with the ONTs. HG8245Q
HTTP Digest authentication issue: Some ONTs do not http authorization challenge in the first 401 un-authorized reply to ACS HTTP Get
The issue is: the ACS tries to connect to the ONT via ‘connection request’. At this point the ONT is supposed to send back HTTP 401 unauthorized response and along with it the send challenge message. This is what the ONT is not doing.
The ONT send this back message in a second reply but not in the first one. Please see the attached file ‘double_unauthorized.docx’.
The correct response should be what is in the attached file ‘success_huawei.docx’
We have other issues with the ONTs as well which I will be raising in separate tickets
We have tried upgrading the firmware to the one ending with 155 and it have made things worse with some parameters.
Can someone please have a look at this?
ONT model: HG8245Q2
ONT firmware: V3R017C10S100
HTTP Digest authentication issue: Some ONTs do not http authorization challenge in the first 401 un-authorized reply to ACS HTTP Get
The issue is: the ACS tries to connect to the ONT via ‘connection request’. At this point the ONT is supposed to send back HTTP 401 unauthorized response and along with it the send challenge message. This is what the ONT is not doing.
The ONT send this back message in a second reply but not in the first one. Please see the attached file ‘double_unauthorized.docx’.
The correct response should be what is in the attached file ‘success_huawei.docx’
We have other issues with the ONTs as well which I will be raising in separate tickets
We have tried upgrading the firmware to the one ending with 155 and it have made things worse with some parameters.
Can someone please have a look at this?
ONT model: HG8245Q2
ONT firmware: V3R017C10S100
Solution
From the package customer send to us, we find that ACS close the connect after 9s, and cause this issue. But something changed a bit, details as below:
1. in the tcp stream 32, ACS query the radio instance from 00:40:29 to 00:40:54, whole operation takes about 25s, it is OK.
2. the tcp stream 32 operation is not finished, but at 00:40:30 ACS send query to ONT(tcp stream 33), now ONT is handling the tcp stream 32, do not reply ACS at once, ACS wait for 9s, then close this connection(00:40:39). ACS is abnormal.
3. The TR069 protocol specifies that the condition for ACS to end the session: it needs to wait at least 30 seconds. The end of the conversation in 5 seconds does not meet the requirements of the standard.
Solution:
1. every connection ACS should wait for 30s(now the second connection ACS wait for 9s, then close the connection);
2. or ACS do the query operation one by one, do not query in parallel.
1. in the tcp stream 32, ACS query the radio instance from 00:40:29 to 00:40:54, whole operation takes about 25s, it is OK.
2. the tcp stream 32 operation is not finished, but at 00:40:30 ACS send query to ONT(tcp stream 33), now ONT is handling the tcp stream 32, do not reply ACS at once, ACS wait for 9s, then close this connection(00:40:39). ACS is abnormal.
3. The TR069 protocol specifies that the condition for ACS to end the session: it needs to wait at least 30 seconds. The end of the conversation in 5 seconds does not meet the requirements of the standard.
Solution:
1. every connection ACS should wait for 30s(now the second connection ACS wait for 9s, then close the connection);
2. or ACS do the query operation one by one, do not query in parallel.