Hi,

Below are a few suggestions, mainly related to the webGUI. None of 
these are of great importance, but I feel that they would all make 
working with m0n0wall easier in one way or another.

I don't presume that all these suggestions should necessarily be 
implemented straight away or even at all. This is mainly to test the 
waters and see how all of you feel about these ideas, I guess it will 
then be up to Manuel and other m0n0wall-developer gurus to decide 
which of these, if any, should be considered for implementation.

(WARNING: Looong read ahead, make yourself comfortable!)

= = =

Firmware upgrading
==================

Since m0n0wall is now able to check for new versions on the firmware 
page, I must assume it wouldn't be too much of a problem making it 
possible to have it download the image directly from the website as well.

I imagine that in case a new version is available, a button would be 
shown (next to the notice about the new firmware for instance), which 
when clicked would initiate a transfer of the image from the website 
directly to m0n0wall, instead of going through the extra steps of 
first saving the image locally, then uploading it to m0n0wall.

In case there is any concern about increased load on the m0n0.ch 
server because of this feature, I see no problem with imposing a steep 
bandwidth limit for these m0n0wall-initiated downloads, since there 
need not be any user intervention after the download has been started, 
as m0n0wall could simply perform the upgrade and then reboot 
automatically upon completion of the download.

Also, I think it would be prudent to include an option to disable the 
automatic version check, as some (more paranoid individuals) might not 
like the fact that m0n0wall contacts a server on the internet on its 
own. When disabled, a button for doing a manual version check could be 
shown on the firmware page.


Traffic shaper
==============

A "Disable" checkbox, like the one in the firewall rules, would make 
it much easier to test and manage the shaper rules.

Showing the "names" (unparsed comment field) of queues and pipes 
instead of their numbers, in the rule list as well as the queue list, 
would make it much easier to read these lists. In case no comment has 
been entered, the usual "Pipe #" could be shown instead.


Sorting
=======

I recently noticed that the "DHCP leases" list allow sorting according 
to the various columns. A similar sorting feature for the various 
other lists in the GUI (such as firewall rules, shaper rules, aliases, 
DNS overrides etc.) would be very nice (and, IMHO, much more useful in 
these places than the DHCP list).

= = =

The following suggestions aren't strictly mine, but rather inspired by 
suggestions I've seen on the list. I've included them here mainly to 
add my vote to them, but also since my idea of how some of them could 
or should be implemented might differ from the original idea:


Rule management
===============

To facilitate easy management and testing, it would be nice to have a 
way to quickly enable and disable rules without having to edit each 
rule seperatly.

I imagine a checkbox could be shown beside each rule in the list, 
allowing you to quickly change the "state" of any number of rules and 
then applying the changes.

The same would go for the shaper rules, should the suggestion about a 
"disable" checkbox for the shaper rules be implemented.

To avoid misunderstandings (not the least by new users), consider 
showing the "implicit" rule(s) in the firewall rule list (perhaps 
grayed out to diferentiate between these and the actual rules).

Also, it might be helpful if one could somehow enable a kind of 
"advanced view" in the rule list, making m0n0wall show the actual 
("low level") rules generated for each rule in the list (these should 
be grouped together with the "GUI rule" to which they belong so one 
knows where they come from).

I realise that this information can be found in status.php, but some 
of us aren't very good at interpreting this output, and also the main 
idea behind the above is to allow you to quickly make sure that a 
given rule in the GUI actually produces the expected set of actual 
(ipfilter?) rules.


Aliases
=======

First of all, I would like to reiterate a suggestion I made myself 
some time ago: There are a number of places where IP addresses or 
subnets can be entered, but where aliases aren't allowed (more or less 
everywhere outside the "Firewall" section).

It would be very nice to be able to use aliases in ALL places where an 
IP or subnet can be entered. The goal being that the ONLY place where 
actual IPs and subnets have to be used is the "Aliases" page.

This way, providing that aliases are used in all places, one could 
rest assured that regardless of what IP or subnet need to be changed, 
it would need to be done in one place only, and there would be no 
chance of forgetting to change it in some obscure place or other, with 
all the horrible scenarios such an oversight might otherwise lead to.

In places where aliases CAN be used (in- or excluding the above), it 
would be nice for these to occur in a dropdown for quick selection as 
well as preventing the possibility of typos (and/or forgetfulness!) It 
should of course still be possible to enter these manually.

= = =

Finally I have one other suggestion, which is perhaps a bit off topic, 
since it isn't related to the webGUI (not strictly anyway):

Some of you may remember my suggestion for some way of interfacing 
with m0n0wall without going through the GUI. This would be to allow 
people (such as I) to produce various binary "clients" capable of 
interacting with m0n0wall (such as for monitoring or time-based rule 
changes etc.)

I fully understand why this was considered somewhat out of the scope 
of m0n0wall. However, I would like to suggest a less complicated 
alternative, which would both make the above "clients" possible (to 
some extent at least) AND provide an easy way for m0n0wall 
administrators to automate and/or script various tasks:

By means of a PHP page, a little like the exec.php, it could be made 
possible to affect certain changes and actions in m0n0wall, normally 
done through the webGUI, by way of some parameters given directly in 
the URL for the PHP page.

This would only be for such things as enabling and disabling rules, 
changing the IP of an alias, enabling and disabling various features 
(traffic shaper, DHCP and such) and other things that one might want 
to either automate, be able to do quickly, or have done by a client 
program.

It would make this post much longer than it alread is, if I were to 
try to explain this idea thoroughly, so I'll jsut provide a few 
examples, and let you fill in the blanks:

A user wanting to be able to quickly open and close access to the WAN, 
could do so by first making a topmost rule on the WAN interface that 
will block all traffic. Then two "internet shortcuts" (or similar) 
could be made with URLs along the following lines:

http://user:pwd at m0n0 dot mydom/do.php?action=toggle_rule&id=1&state=enabled

and

http://user:pwd at m0n0 dot mydom/do.php?action=toggle_rule&id=1&state=disabled


A user wanting to implement time-based rule changes, could do so by 
having a cron job (or similar) execute a number of URLs similar to the 
ones above at various times.

A (perhaps somewhat ambitious) user, wanting to make a small tray util 
showing the current load on the various interfaces, could do so by 
sending an URL along these lines to m0n0wall:

http://user:pwd at m0n0 dot mydom/do.php?action=get_stats&type=interface&id=wan

Which would then cause m0n0wall to return a small XML document 
containing some relevant interface statistics that the program could 
parse and display in a nice graph or whatever.


I hope you get the general idea by now. The syntax and specific 
commands and their arguments are of course just something I've grabbed 
out of the air. The idea is to mainly provide functionality already 
present in m0n0wall, thus keeping it relativly simple to produce the 
PHP script that parses the URL and then call the apropriate function(s).

This alone would provide a very powerful alternative (read: script 
friendly) interface for m0n0wall. Add to this the ability to return 
XML formatted responses (such as the interface stats in the last 
example), and very complex interactions will be possible between 
m0n0wall and anything from a simple shell script to a large database 
application. In fact, anything capable of making a http request by 
some means, would be able to interact with m0n0wall in this way, 
either making changes to its configuration or polling for various 
information.

While I guess there are a number of other ways to achieve this 
functionality (such as SNMP or a SSH based CLI), there are a number of 
advantages when doing it this way:

- Security isn't an issue, as this is inherent in the http/https 
protocols and is already in place for the webGUI.

- There is virtually no additional overhead nor any need for any 
additional binaries.

- Most of the code is probably already present for the webGUI. Only 
the "do.php" (or whatever it should be called) script to be 
implemented, and this should mainly be a matter of some code parsing 
the URL and then calling various existing PHP scripts.

- It is in line with the design philosophy of m0n0wall, namely that 
PHP should be used for everything.

- It should be very easy to maintain. Typically no special care would 
need to be taken, at least until it is decided that some new GUI 
feature should be accessible in this manner as well. Even then it is a 
simple matter of adding a few lines to do.php, making it recognise the 
new command(s) and calling the corrosponding function(s) which have 
already been implemented for the GUI.

= = =

Well, that's it folks! (For now at least.)

Let's hear what you think?


Regards,

Adam.

P.S. Sorry for wasting so much of your time. I'm afraid I have a 
problem with expressing myself in short sentences ;)