Warning "Unrecognized command key" in TransferComplete message

Michael Ducharme mducharme at gmail.com
Fri Aug 10 13:02:25 EDT 2018


Hi Zaid, thanks for the patch. I will give it a shot. Can you point to 
where it says in the spec that it should handle that? I'd like to try to 
get them to fix it on their side if I can, but when I looked in the spec 
I could not find the reference. I would need to indicate what is wrong 
in the spec in order to convince them, since they seem to think it is 
some strange behavior of GenieACS. Here is the email I received from them:

*************************

Hello,

Regarding Config overwrite Download RPC, the procedure is the following,
1) Client sends HTTP post request TransferCompleted;
2) ACS receives the message and acknowledge the result;
3) In theory server could send HTTP response TransferCompleteResponse, 
when all information was accounted.

 From standard about such message sending:

An event is an indication that something of interest has happened that 
requires the CPE to
notify the ACS via an Inform request defined in Section A.3.3.1. The CPE 
MUST
attempt to deliver every event at least once. If the CPE is not 
currently in a Session with
the ACS, it MUST attempt to deliver events immediately; otherwise, it 
MUST attempt to
deliver them after the current Session terminates. The CPE MUST receive 
confirmation
from the ACS for it to consider an event successfully delivered. Once 
the CPE has
delivered an event successfully, the CPE MUST NOT send the same event 
again. On the
other hand, the ACS MUST be prepared to receive the same event more than 
once
because the ACS might have sent a response the CPE never receives.
For every type of event there is a policy that dictates if and when the 
CPE MUST retry
event delivery if a previous delivery attempt failed.

And from this,
TRANSFER COMPLETE is not being sent any more, and it committed once CPE 
received TransferCompleteResponse.
 From our point of view GeniaACS should handle those message in more 
proper way.

********************************************************

On 8/9/2018 1:52 AM, Zaid Abdulla wrote:
> On Mon, 2018-08-06 at 19:44 -0700, Michael Ducharme wrote:
>> I am trying to fix this on my own but have spent probably 16 hours
>> adding extra logging statements to try to figure out the flow in the
>> GenieACS code to see the correct place to patch this and am still
>> not sure, though I am still working on it.
> Try the attached patch (not tested). This assumes the CPE at least
> sends a DownloadResponse. If even that is too much to ask, try doing
> something similar but somewhere in sendAcsRequest function.
>
>>   In my case the manufacturer has shown no interest in fixing it since
>> they say the spec says that the ACS should handle the session being
>> closed improperly in that way.
> Not only does that not make sense, the spec actually says otherwise.
> IIRC it explicitly states that changes made during a session should be
> ignored if the session was not successfully closed.
>
>> Shouldn't GenieACS be able to handle this? If TransferComplete is
>> received, shouldn't that be good enough?
> The problem is that a reference to the original download wasn't saved
> in the database because DB sync happens at the end of the session.
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.genieacs.com
> http://lists.genieacs.com/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genieacs.com/pipermail/users/attachments/20180810/45111ec5/attachment.html>


More information about the Users mailing list