Warning "Unrecognized command key" in TransferComplete message

[Michael Ducharme]

We are having a similar problem, not Unrecognized command key, but the 
problem on our side appears to be that the session does not get closed 
after the TransferComplete due to the device rebooting to apply the 
config. The result is the same: even though the TransferComplete is 
received, Timeout Operation kicks in and GenieACS assumes that the 
transfer did not go successfully and resends, causing a loop of sending 
the config to the client.

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. 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. Shouldn't 
GenieACS be able to handle this? If TransferComplete is received, 
shouldn't that be good enough?

Would really appreciate some feedback from Zaid on this.


On 8/2/2018 12:13 PM, Zaid Abdulla wrote:
> On Thu, 2018-08-02 at 20:45 +0200, Oliver Kraitschy wrote:
>> Well, the client is the same on all routers. So I'm wondering why the
>> issue doesn't exist on all routers. Some timing problem?
> I have no clue. I've learned not to make assumptions about clients'
> behavior :)
>
>>> Look for timeout errors in logs. Otherwise check the debug log and
>>> make
>>> sure the command key in the Download and TransferComplete requests
>>> match.
>> And if they don't?
> First thing I'd do is reach out to the manufacturer. For a (hopefully
> temporary) work around you'd have to patch your genieacs installaiton.
>