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?
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
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.
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.
Does the Zyxel CPE apply the file or just after a factory reset?
In other word, do costumer settings survive that operation.
As far I am informed, it’s possible to upload that file but not reset the device to that settings.
Similar to that described by zaidka about the mikrotik routers.
I have studied OpenRG, Sercomm, ASkey, Technicolor and some others CWMP client implementations and none of them sends a 0 BOOTSTRAP on after VCF transfer.
Of course, the vendor is free to apply VCF and reset the CWMP state. In that case 0 BOOTSTRAP is expected. For instance, a Technicolor VCF might explicitly contain a CWMP state reset command, if needed.
You already mentioned the cases in which the CWMP client is required to send 0 BOOTSTRAP agian and it is possible for a VCF to trigger any of these conditions. I’m thinkingm for instance, to ACS URL change after custom TLS certs deployment.
They shouldn’t persist after factory reset. On factory reset the bootstrap takes place again from scrtch and VCF are pushed once again.
This would make infrastructure changes much more difficult. An example of this is we are switching to doing everything using PTM encapsulation. Making this change simplifies the DSLAM configuration and means we can use VDSL with ADSL fallback.
If we had to worry about a CPE reverting its state on a factory reset, it would mean we could never fully switch over to PTM over VDSL/ADSL as the existing CPEs we have wouldn’t be able to connect when the techs/customer/support agent factory resets the CPE.
Every existing CPE we have in our infrastructure writes the new config file to non-volatile memory and this config becomes the new “custom” default.
Your CPE are not persisting VCFs, they support some out-of-firmware persistent configuration mechanism and they allow you to update such persistent content via CWMP VCF downloads. Nothing in CWMP spec is limiting what different vendors do with their own VCF format. I have seen a lot of different VCF formats and of course some vendors support updating such hard-defaults templates through them, but that’s not a matter of CWMP. Otherwise VCFs might be shell scripts (linux sh or some other custom one), certificates, binaries to run, containers to deploy, IPK packages, diagnostic payloads, or even empty files for speedtest purposes.
On factory reset, the CWMP state is gets reset too. Therefore the CWMP client won’t know about any previous VCF download event. Whether the current device firmware/configuration was flashed in factory or by any previous CWMP life doesn’t matter from a CWMP perspective. In other words, what you persist is not a VCF per se, but eventual VCF side-effects
Just think to VCFs as provisiong extensions for anything the CPE vendor didn’t manage to map into a native CWMP datamodel extension. Their existence is bound to a provisining sequence like any other SPV/GPV/SPA/… rpc, and your RPC calls are not persistent, i.e. they’re not re-executed by CWMP client after factory reset.
AFAIK there exist notghing like persisting an history of VCFs such that CWMP client would reapply them on bootstrap (or immediately before bootstrap).
I have run a test with an Zyxel CPE.
It did send the bootstrap event. But I have to say, I have changed the ACS URL with the new configuration file.
I had some issues with my genieacs 1.2.1 installation. So I have moved the CPE for the vendorfile update to an older genieacs instance. Then I rolled out the new configuration with the acs URL of the original ACS. (I will test if it is an Genieacs issue or an issue by my installation)
The CPE reported bootstrap to the ACS.
I also tried to factory reset the device. The Vendor Configuration File did not survive the reset.
The CPE I have tested with was a Zyxel VMG4005-B50A. As far as I am informed it is possible to convert the running configuration to the romd over the WebUI. Maby there is also a way over TR069
, because a vendors firmware never has defects in it…
yeah… those kind of request are not always welcomed by vendors.
.