I recently upgraded to the latest 378 release build and ran into a problem that manifested itself as an inability to vpn into my home system via PPTP after the router had been running for several hours.
In reviewing the system log, there were suspicious messages regarding failed memory allocations and the inability to fork pptpctrl...
The main status web page indicated 63MB free memory.
The root of the problem was that a "bad" network device was sending WINS requests to the asus (which was configured to enable SMB sharing but NOT WINS). This resulted in nmbd logging error messages constantly, and the log file ultimately filled the /tmp file system. The solution was to enable WINS on the asus, even though I had no real need to do so.
The fact that /tmp /var was full was the root of the failure to fork as well as the DHCP failure to allocate 1028 bytes messages...
I see several possible improvements here: throttling the logging of repeated nmbd messages being one, as well as better error diagnostics, and automatic log file rotation or quotas on log file sizes...
Beyond this, it would seem reasonable to have the amount of /tmp filesystem freespace listed somewhere on the status pages, since the system behaves very badly if this file system fills up.
Hope this info helps someone, or improves the merlin software, (which is already very good IMHO).
-Rory
In reviewing the system log, there were suspicious messages regarding failed memory allocations and the inability to fork pptpctrl...
The main status web page indicated 63MB free memory.
The root of the problem was that a "bad" network device was sending WINS requests to the asus (which was configured to enable SMB sharing but NOT WINS). This resulted in nmbd logging error messages constantly, and the log file ultimately filled the /tmp file system. The solution was to enable WINS on the asus, even though I had no real need to do so.
The fact that /tmp /var was full was the root of the failure to fork as well as the DHCP failure to allocate 1028 bytes messages...
I see several possible improvements here: throttling the logging of repeated nmbd messages being one, as well as better error diagnostics, and automatic log file rotation or quotas on log file sizes...
Beyond this, it would seem reasonable to have the amount of /tmp filesystem freespace listed somewhere on the status pages, since the system behaves very badly if this file system fills up.
Hope this info helps someone, or improves the merlin software, (which is already very good IMHO).
-Rory
