I discovered a bug in m0n0wall's XML parser that could lead to field
values that have their beginning truncated in some cases. An updated
version has been released (pb11r401); I urge everybody to upgrade.
The bug was due to the fact that the config.xml file is read in chunks of
4096 bytes. If such a chunk boundary fell exactly into a cdata section
(the text between starting and ending tag, i.e. the actual value of the
configuration variable), the cData handler was called twice but did not
check if it was already called on that tag (and concatenate the two
strings instead of overwriting the older with the newer one).
Example: on my m0n0wall, one filter rule displayed the destination network
as ".1.1" instead of "192.168.1.1" (the chunk boundary was exactly after
168). In another case, a domain name in the DNS forwarder override list
was saved as "on1.net" instead of "neon1.net".
After you update, make sure to check the configuration for such truncated
fields and correct them! If a field was read like that and you modified
the configuration thereafter, it has been written in the truncated state
to the config.xml file, so upgrading alone won't fix it.
I'm sorry for any inconvenience this may have caused.
On a side note, I tried to upgrade to PHP 4.3.2 today. After carefully
reading the changelog and checking for changes that could have
implications for m0n0wall, I figured that there were none and went ahead.
Sure enough, while the boot scripts still worked, the webGUI wouldn't work
anymore ("No input file specified."). I compared the code
(sapi/cgi/cgi_main.c, to be precise) and found that PHP 4.3.2 does no
longer accept the input filename via the command line in CGI mode, but
instead insists on getting it via the PATH_TRANSLATED or SCRIPT_FILENAME
environment variables - which thttpd does not set (they're optional as per
the CGI 1.1 spec anyway). Since I couldn't find a quick fix, I decided to
stay at 4.3.1 until the PHP folks themselves either decide that that
change was too radical, or replace thttpd with some other webserver that
does it "properly". thttpd has always worked fine for me, though, so I
don't want to upgrade unless I have to.