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.
_______________________________________________
Users mailing list
[email protected]
http://lists.genieacs.com/mailman/listinfo/users
