Firmware Upgrade error: Data model expectations?

[rhaberkorn]

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:

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

[rhaberkorn]

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.

[akcoder]

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.

[zaidka]

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

[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?

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.

[rhaberkorn]

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?

[akcoder]

@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:

2020-10-28T12:58:24.922Z [INFO] some_ip 3c9066-963168_OT142C_B-some_serial: ACS request; acsRequestId="1756f49b60d010e" acsRequestName="GetParameterValues"

[akcoder]

@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.

[zaidka]

@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.