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