Skip to content

QA Cafe ― Automate, validate, and deliver better broadband and connected devices

TR-069 Connection Request Timing

bugofthemonth
In CWMP, the CPE is always the initiator of sessions. It begins each session with a call to the Inform RPC, which contains EVENT codes that specify to the ACS the reason for the session.

One way the that ACS can entice a CPE to begin a session is with the Connection Request mechanism. In TR-069 Amendment 4 and earlier, this was done exclusively with HTTP, though an option for XMPP Connection Requests was added in Amendment 5.

In either case, the Connection Request is a stateful mechanism where the ACS sends the request to a URL specified by the CPE. The CPE authenticates that request to make sure it’s coming from the ACS it is assigned to. It then responds with a 200 OK or 204 No Content message to the ACS, and then initates a CWMP session with the ACS using the “6 CONNECTION REQUEST” event code.

The Problem

The problem arises when the the CPE tries to initiate the new session before it has responded to the Connection Request. While the ACS should expect the CPE to initiate a session for any reason, many ACS will try to keep track of (or cut down on) sessions by matching each session to a particular connection request. Starting a session before the Connection Request is confirmed may also trigger the ACS to think that it was not completed and initiate another Connection Request.

How is it supposed to work?

This functionality is also spelled out in a requirement in TR-069:

The CPE‘s response to a successfully authenticated Connection Request MUST use
either a ―200 (OK) or a ―204 (No Content) HTTP status code. The CPE MUST
send this response immediately upon successful authentication, prior to it initiating
the resulting Session. The length of the message-body in the HTTP response MUST
be zero.

Thus, the CPE is expected to respond to the Connection Request before initiating a CWMP session based on that Connection Request.