(Running v1.28.7482 MIPSR2-Toastman-RT K26 USB VPN)
I've noticed that after the router reboots, it forgets what DHCP clients it had a lease with, and if you are using Dnsmasq to access clients by name, it fails.
In most cases the clients themselves seem to reestablish the connection, presumably renewing the lease, and in theory Dnsmasq should then know about them by host name again, but it sometimes doesn't.
Searching turned up a changelog comment in the file a/release/src/router/dnsmasq/CHANGELOG.archive in the Tomato git repository:
+version 2.33 [...] + Add contrib/wrt/* which is an example implementation of an + external persistent lease database for *WRT distros with + the nvram command.
implying that some one addressed this issue with some user contributed code for Dnsmasq. I downloaded the latest Dnsmasq distribution, and took a look at contrib/wrt/README, which says:
This script can be used to implement persistent leases on openWRT, DD-WRT etc. Persistent leases are good: if the lease database is lost on a reboot, then it will eventually be restored as hosts renew their leases. Until a host renews (which may take hours/days) it will not exist in the DNS if dnsmasq's DDNS function is in use. *WRT systems remount all non-volatile fileystems read-only after boot, so the normal leasefile will not work. They do, however have NV storage[...] The principle is that leases are kept in NV variable with data corresponding to the line in a leasefile: dnsmasq_lease_192.168.1.56=3600 00:41:4a:05:80:74 192.168.1.56 * * By giving dnsmasq the leasefile-ro command, it no longer creates or writes a leasefile; responsibility for maintaining the lease database transfers to the lease change script. At startup, in leasefile-ro mode, dnsmasq will run "<lease_change_script> init" and read whatever that command spits out, expecting it to be in dnsmasq leasefile format. So the lease change script, given "init" as argv will suck existing leases out of the NVRAM and emit them from stdout in the correct format. The second part of the problem is keeping the NVRAM up-to-date: this is done by the lease-change script which dnsmasq runs when a lease is updated. When it is called with argv as "old", "add", or "del" it updates the relevant nvram entry. So, dnsmasq should be run as : dnsmasq --leasefile-ro --dhcp-script=/path/to/lease_update.sh or the same flags added to /etc/dnsmasq.conf
So clearly it is a genuine problem.
Anyone implemented this on Tomato?
Are there better ways to address this?
I'm mostly concerned with machines that have statically defined leases. I haven't used the GUI for that (Basic->DHCP). Instead I simply carried over custom Dnsmasq config lines like:
from a prior router and pasted them into Advanced->DHCP/DNS->"Dnsmasq Custom configuration". I'm wondering if using Basic->DHCP might behave differently and avoid this, or is it just writing equivalent Dnsmasq config directives that will behave identically?
About Tom Metro