What is your experience with vendor config files?

We are testing out a new CPE in our environment (Zyxel VMG4927). Every other CPE I’ve ever tested sends a 0 BOOTSTRAP event when a new config file is received by the CPE (either via the web GUI or via cwmp download). Except this Zyxel I’m testing.

I cannot find anything in the related specs that specify if a 0 BOOTSTRAP event is supposed to be sent on receiving a new configuration file. I did find this:

The specific conditions that MUST result in the BOOTSTRAP EventCode are:

  • First time connection of the CPE to the ACS from the factory.
  • First time connection of the CPE to the ACS after a factory reset.
  • First time connection of the CPE to the ACS after the ACS URL has been modified in any way.

So what is everyone elses experience? If your CPE exhibits this same behavior, how have you worked around it?

Hi akcoder,

I’m working with Mikrotik and vendor config files are very important for what we are doing. This is what the cwmp access log looks like when I push a config file

2020-09-17T14:59:55.726Z [INFO] MASKEDIP MASKEDDEVICEID: Inform; informEvent=“6 CONNECTION REQUEST” informRetryCount=0
2020-09-17T14:59:55.745Z [INFO] MASKEDIP MASKEDDEVICEID: ACS request; acsRequestId=“" acsRequestName=“Download” acsRequestCommandKey="
2020-09-17T14:59:56.107Z [INFO] MASKEDIP MASKEDDEVICEID: Inform; informEvent=“7 TRANSFER COMPLETE,M Download” informRetryCount=0
2020-09-17T14:59:56.126Z [INFO] MASKEDIP MASKEDDEVICEID: CPE request; cpeRequestName=“TransferComplete” cpeRequestCommandKey="***"
2020-09-17T15:00:27.136Z [ERROR] MASKEDIP: Session timeout; sessionTimestamp=1600354796100 deviceId=“MASKEDDEVICEID
2020-09-17T15:01:13.012Z [INFO] MASKEDIP MASKEDDEVICEID: Inform; informEvent=“0 BOOTSTRAP,1 BOOT” informRetryCount=2

Thank you for that. Thats pretty much what every other CPE I’ve used does. 0 BOOTSTRAP,1 BOOT.

I filed an issue with Zyxel, I expect in a day or so they will blame the ACS :smiley:, because a vendors firmware never has defects in it…

:joy: yeah… those kind of request are not always welcomed by vendors.

You can also send them the official TR-069 docs https://www.broadband-forum.org/download/TR-069_Amendment-2.pdf . Page 34 talks about BOOTSTRAP event. After all, it’s not just “what every other vendor does”, it’s the behavior specified on the protocol. And the vendor proposed himself to be compliant to it.

Good luck on that

lol. Funny enough, I actually read that document yesterday to gain some clarity on the issue before i posted to the forum. Unfortunately, the doc does not specifically call out that a 0 BOOTSTRAP event is required on a config file change.

The specific conditions that MUST result in the BOOTSTRAP EventCode are:

  • First time connection of the CPE to the ACS from the factory.
  • First time connection of the CPE to the ACS after a factory reset.
  • First time connection of the CPE to the ACS after the ACS URL has been modified in any way.

In every other CPE I’ve used, uploading a new config causes the CPE to perform a factory reset after applying the new config, which thereby triggers the second condition.

It’s not entirely clear to me how vendor config files ought to work. Should they persist after factory reset? I know Mikrotik devices can use a special config file (ending with .alter IIRC) that’s essentially just a list of commands to be executed on the device so it may not overwrite all user configuration nor does it persist after factory reset. So I’m not surprised the spec doesn’t say much about all that.

I recall having to deal with a similar issue before. What I ended up doing is create a preset that’s triggered on “7 TRANSFER COMPLETE” event. And in the script I check the file name or type of the most recent instance under Downloads.* and decide accordingly.

Interesting idea, I hadn’t thought of that. Thank you.

The way SmartRG and Comtrend CPEs work is when you a new config file is downloaded it writes it becomes the new default for factory reset.