Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Custom config files
Clone this wiki locally
The services executed by the router such as minidlna or dnsmasq relies on dynamically-generated config files. There are various methods through which you can interact with these config files to customize them.
Enabling support for custom configs
Starting with 378.50, this functionality is disabled by default. To enable it, go to Administration -> System, then enable it under the JFFS section.
If you accidentally lock yourself out of your router due to a bugged custom config, a factory default reset will let you regain access to your router
Replacing or appending content to config files
You can append content to various configuration files that are created by the firmware, or even completely replace them with custom config files you have created. Those config override files must be stored in /jffs/configs/. To have a config file appended to the one created by the firmware, simply add ".add" at the end of the filename taken from the list below. For example:
will be added at the end of the dnsmasq configuration file that is created by the firmware, while:
would completely replace it.
Note that replacing a config file with your own implies that you properly fill in all the fields usually dynamically created by the firmware. Since some of these entries require dynamic parameters, you might be better using the postconf scripts added in 374.36 (see the postconf scripts section below).
The list of available config overrides:
- exports (only exports.add supported)
- fstab (only fstab supported, remember to create mount point through init-start first if it doesn't exist!)
- group, gshadow, passwd, shadow (only .add versions supported)
- hosts (for /etc/hosts)
- nanorc (no .add support) - as documented here (External page). 384.3 or newer.
- profile (shell profile, only profile.add supported)
- upnp (for miniupnpd)
Also, you can put your own OpenVPN ccd files in the following directories:
The content of these will be copied to their respective server instance's ccd directory when the server is started.
A lot of the configuration scripts used by the router services (such as dnsmasq) are dynamically generated by the firmware. This makes it hard for advanced users to apply modifications to these, short of entirely replacing the config file.
Postconf scripts are the solution to that. Those scripts are executed after the router has generated a configuration script, but before the related service gets started. This means you can use those scripts to manipulate the configuration script, using tools such as "sed" for example. You can also use these scripts for any other type of action that you wish to execute just before the daemon gets started (for instance, modifying a firewall rule, logging some sort of notification, etc...)
Postconf scripts must be stored in /jffs/scripts/ . The path/filename of the target config file is passed as argument to the postconf script.
The list of available postconf scripts is:
- adisk.postconf (Time Machine)
- afpd.postconf (Time Machine)
- avahi-daemon.postconf (Time Machine)
- openvpnclient1.postconf (1 through 5)
- openvpnserver1.postconf (1 or 2)
To make things easier for novice users who don't want to learn the arcane details of using "sed", a script providing support functions is available. The following dnsmasq.postconf script demonstrates how to modify the maximum number of leases in the dnsmasq configuration:
#!/bin/sh CONFIG=$1 source /usr/sbin/helper.sh pc_replace "dhcp-lease-max=253" "dhcp-lease-max=100" $CONFIG
The following functions are currently available through helper.sh:
pc_replace "original string" "new string" "config filename" pc_insert "string to locate" "string to insert after" "config filename" pc_append "string to append" "config filename" pc_delete "string within line to delete" "config filename"
Note that postconf scripts are blocking the firmware while they run, to ensure the service only gets started once the script is done. Make sure those scripts do exit properly, or the router will be stuck during boot, requiring a factory default reset to recover it.