# Firmware Upgrade error: Data model expectations? **URL:** \ **Category:** Uncategorized\ **Created:** [October 18, 2020, 6:48pm UTC](https://forum.genieacs.com/t/firmware-upgrade-error-data-model-expectations/1145 "2020-10-18T18:48:39Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![rhaberkorn](https://avatars.discourse-cdn.com/v4/letter/r/96bed5/32.png) [@rhaberkorn](https://forum.genieacs.com/u/rhaberkorn)\ **Post date:** [October 18, 2020, 6:48pm UTC](https://forum.genieacs.com/t/firmware-upgrade-error-data-model-expectations/1145/1 "2020-10-18T18:48:40Z")
Hello! I’m prototyping a new CPE daemon to communicate with GenieACS 1.2.2. Whenever I try to Commit a Firmware Upgrade, the following error is displayed: ![genieacs-error](https://canada1.discourse-cdn.com/flex035/uploads/genieacs/original/1X/a1839ab851d50aa97480ac0817741b0ae7237b32.png) Seems to be some generic Javascript error passed down without the stack trace. The file name is irrelevant and the upgrade won’t yet really do anything. However, the error is displayed before my CPE sends the next Inform request. So there is no “Download” and “TransferComplete” message exchange. I cannot find any mention of the errors in the logs. Testing with genieacs-sim, I can at least provoke the “Download” message exchange after initiating a Firmware Upgrade. My prototype differs in not yet exposing any datamodel, except for a “Foo.Bar” dummy parameter. The device, I’m developing this for, also will not expose a standard TR-069 (InternetGatewayDevice or Device) data model, but a custom one. I’m therefore suspecting that the reason of the failure lies in some implicit and undocumented expectation of how the data model has to look like. Does anybody know what this could be? Best regards, Robin ---
**Author:** ![rhaberkorn](https://avatars.discourse-cdn.com/v4/letter/r/96bed5/32.png) [@rhaberkorn](https://forum.genieacs.com/u/rhaberkorn)\ **Post date:** [October 27, 2020, 1:07am UTC](https://forum.genieacs.com/t/firmware-upgrade-error-data-model-expectations/1145/2 "2020-10-27T01:07:10Z")
PS: Since my daemon is going to be open sourced anyway, I can provide you with the source code (in C) of the prototype if this will be of any help. It doesn’t yet have any dependencies on any kind of device management database, so it should be straight forward to build. ---
**Author:** ![akcoder](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.genieacs.com/akcoder/32/11_2.png) [@akcoder](https://forum.genieacs.com/u/akcoder)\ **Post date:** [October 27, 2020, 3:36pm UTC](https://forum.genieacs.com/t/firmware-upgrade-error-data-model-expectations/1145/3 "2020-10-27T15:36:10Z")
What is in the CWMP logs when you are doing this? AFAIK, there is no undocumented expectation. Your device is expected to conform to TR-069 or TR-181 🙂. And that means your “device” should expose your parameters either under InternetGatewayDevice or Device. ---
**Author:** ![zaidka](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.genieacs.com/zaidka/32/9_2.png) [@zaidka](https://forum.genieacs.com/u/zaidka)\ **Post date:** [October 27, 2020, 5:42pm UTC](https://forum.genieacs.com/t/firmware-upgrade-error-data-model-expectations/1145/4 "2020-10-27T17:42:34Z")
Expanding on @akcoder’s comment, your client is not reporting these parameters which are needed to send a connection request to the client: ``` Device.ManagementServer.ConnectionRequestURL Device.ManagementServer.ConnectionRequestUsername Device.ManagementServer.ConnectionRequestPassword ``` ---
**Author:** ![rhaberkorn](https://avatars.discourse-cdn.com/v4/letter/r/96bed5/32.png) [@rhaberkorn](https://forum.genieacs.com/u/rhaberkorn)\ **Post date:** [October 29, 2020, 7:51pm UTC](https://forum.genieacs.com/t/firmware-upgrade-error-data-model-expectations/1145/5 "2020-10-29T19:51:07Z")
> [@akcoder](#): > > What is in the CWMP logs when you are doing this? I haven’t enabled those as the wiki states they will contain the message exchange and I got those via Wireshark. Would I expect to find anything additional of interest there? > [@](#): > > AFAIK, there is no undocumented expectation. Your device is expected to conform to TR-069 or TR-181 🙂. I didn’t know that. The website claims > [@](#): > > GenieACS can work with any device that supports the TR-069 protocol. It auto-discovers the device’s parameter tree (including vendor-specific parameters) **making no assumptions about the device’s data model.** ---
**Author:** ![rhaberkorn](https://avatars.discourse-cdn.com/v4/letter/r/96bed5/32.png) [@rhaberkorn](https://forum.genieacs.com/u/rhaberkorn)\ **Post date:** [October 29, 2020, 7:56pm UTC](https://forum.genieacs.com/t/firmware-upgrade-error-data-model-expectations/1145/6 "2020-10-29T19:56:52Z")
In other words, GenieACS cannot queue and perform firmware upgrades with the next CPE-initiated (periodic Inform) session? What if the CPE is behind a NAT gateway or firewall - do you rely on TR069 Annex K in situations like that? ---
**Author:** ![akcoder](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.genieacs.com/akcoder/32/11_2.png) [@akcoder](https://forum.genieacs.com/u/akcoder)\ **Post date:** [October 29, 2020, 8:08pm UTC](https://forum.genieacs.com/t/firmware-upgrade-error-data-model-expectations/1145/7 "2020-10-29T20:08:01Z")
> [@rhaberkorn](#): > > > [@akcoder](#): > > > > What is in the CWMP logs when you are doing this? > > I haven’t enabled those as the wiki states they will contain the message exchange and I got those via Wireshark. > Would I expect to find anything additional of interest there? The CWMP log is very, very different from the debug log. The CWMP log is going to tell you what the CWMP process is doing with a CPE. Ex: ```auto 2020-10-28T12:58:24.922Z [INFO] some_ip 3c9066-963168_OT142C_B-some_serial: ACS request; acsRequestId="1756f49b60d010e" acsRequestName="GetParameterValues" ``` ---
**Author:** ![akcoder](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.genieacs.com/akcoder/32/11_2.png) [@akcoder](https://forum.genieacs.com/u/akcoder)\ **Post date:** [October 29, 2020, 8:10pm UTC](https://forum.genieacs.com/t/firmware-upgrade-error-data-model-expectations/1145/8 "2020-10-29T20:10:33Z")
> [@rhaberkorn](#): > > I didn’t know that. The website claims > > > [@](#): > > > > GenieACS can work with any device that supports the TR-069 protocol. It auto-discovers the device’s parameter tree (including vendor-specific parameters) **making no assumptions about the device’s data model.** Yes, except by not exposing parameters **required** by the TR-069 protocol, your device is not compliant with the spec. ---
**Author:** ![zaidka](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.genieacs.com/zaidka/32/9_2.png) [@zaidka](https://forum.genieacs.com/u/zaidka)\ **Post date:** [October 30, 2020, 2:33am UTC](https://forum.genieacs.com/t/firmware-upgrade-error-data-model-expectations/1145/9 "2020-10-30T02:33:14Z")
> [@rhaberkorn](#): > > What if the CPE is behind a NAT gateway or firewall - do you rely on TR069 Annex K in situations like that? More or less. Though Annex K isn’t currently supported but Annex G is. For your developmenent work, you can patch Genie to make tasks remain queued until the next inform. Find the function `postTasks` in `lib/ui/api-functions.ts` and comment out the two lines with `deleteTask`. For anyone else reading this, I don’t recommend this in a production envionrment because there’s no way to see what tasks have been queued before. And for devices that are offline for extended periods of time the tasks may pile up in the database.