I am programming for a embedded system. When this system boots up it reads from a configuration file some data and execute rules to put the system state according to the configuration read. This configuration is dependent on the environment/requeriments of each customer and can be managed via management interfaces (as a Web interface).

Let me explain myself better: this embedded system is a home router (CPE) for ISPs. The configuration for the router is stored in a flash partition, and there is a default configuration file stored in the file system that is included in the firmware image. One of this ISPs has requested us to release a new firmware which should include a different configuration for one of the network interfaces used by the router.

The problem is this ISP does not want to perform a reset to default configuration file in his customers CPEs to not loose the configuration that each customer has saved on it (as the ESSID for the WLAN interface). The ISP wants the firmware to be able to connect using the new requirement for the network interface once the CPE has been upgraded.

One of my co-workers has proposed this: when the new firmware boots up, it checks if the interface exist in the CPE configuration and if not it adds it during boot time to the configuration file.

I would like to explain them (ISP and co-worker) using good reasons why the configuration file should not be modified at run time except by the management interfaces.

  • 4
    So... you're firmly of the opinion that something should not be done, but you don't have any reasons you can express? Okay, devil's advocate: Can you explain to us why you think it shouldn't? Commented Oct 5, 2014 at 17:41
  • 1
    How do I explain ${something} to ${someone}?
    – user22815
    Commented Aug 21, 2015 at 12:40

1 Answer 1


As this is basically the "Magic Number"-s '++' variant, a lot of the same arguments hold (or should, at least). To make a few of my immediate considerations fully verbal:

  • Adding magic code for the purpose of changing a value is a high-maintenance procedure. Any change to the operation requires code-searches, verifications, re-compiles and re-flashing, whereas changing that value directly does not.
  • Adding magic code can increase vulnerability. If done as a quick addition it can (read: will) either cause untested and/or unpredicted paths of execution, if it has to bind the interface this may even cause a short period of unprotected access with the addition of one single oversight, depending on the entire code of course.
  • It's not good value for money. If you manage to eliminate the first two as arguments, you are spending a lot of time of a dedicated high-level developer on adding and changing features for problems that can be solved easier and cheaper.
  • There are better alternatives to the problem posed.

My alternative, as per point 4: Design, add and test a module that can make a single incremental change to the configuration, using the same authentication and encryption you are using for other safe interfacing to the devices. Allowing the internals to copy-over the current configuration, but only changing that one configuration in the process, all locally, possibly in a non-responsive mode. This is an actual new feature, which if you design it well can remain safe, execution proven for all situations and can be used by a much lower-wage worker to reconfigure unrestricted parts of the set-up in years to come.

Of course you need to set some manner of boundaries as to what can be modified if you want the end-customer to remain safe in the knowledge nobody can reset their WiFi or router passwords to something else.

All that said, my personal experience with ISPs and 9 out of 10 of the companies that build their firmware in general is similar to yours: The ideology of "just throw this in there and compile" still reigns. This is in fact a large driving force these days in choosing my ISP, over cost and speed, as I prefer reliability.

Working with others in embedded systems can be a mine-field :-)

  • Regarding your alternative, the problem is that the ISP is requesting to change the configuration for a current feature. This is, the configuration for a current network interface. For instance current WAN interface encapsulation could be an Ethernet interface with VLAN header and this VLAN header is set with VLAN ID = 3. Now ISP want it to be a VLAN header with VLAN ID = 1.
    – MABC
    Commented Oct 6, 2014 at 22:42
  • If it is something that can be solved by a "return to factory settings", in properly designed embedded software it should be something that can be changed by a dedicated and protected module within the same software able to "return to factory settings". Of course with restrictions, maybe even just those settings that affect the world-side. In fact, several designs for devices like this already include a configuration section separate from everything else just for world-side config, which can often even only be changed by the world-side-provider.
    – Asmyldof
    Commented Oct 7, 2014 at 14:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.