1.8b Development

Lennard, great seeing this progress. I vote for grey Black.
Jakob

This took quite a lot of time but I'm really satisfied with the end result.

I've uploaded the changes to the repository. Waiting for the snapshot now.

Edit: Seems to work fine. Give it a try!
Edit 2: @jstrebel: I'd say black/grey looks best although grey/black focuses the attention to the "what's going to happen"-part of the job. I'd like to hear a few more opinions about that.

I thought it might be a good idea to explain how the scheduler works to fulfil it's task and what you should know about the invidiual jobs.

Scheduler:
The scheduler has an interval that can be defined on the webinterface. Every job that has to be executed within this interval will be added to a task list. This task list will be sorted (sleep time asc) and then executed one by one. After the list has been processed the program will sleep until the target time (last target time + interval) has been reached.
If the time gets changed and the difference is not greater than three hours the scheduler will continue as planned, meaning either rush through the loops or sleep until the new date has been reached.
If the difference is greater than three hours the scheduler will cancel the current loop and recalculate schedules with the new date/time.
This will prevent jobs from being skipped after for example the switch to daylight saving time/standard time and/or minor adjustments to the time (NTP client).
Jobs could be skipped during the restart of the scheduler which happens if you click "Apply" on the scheduler page of the webinterface.

Interface:
You can disable all interfaces thus you can lockout yourself completely from the webinterface apart from direct input (serial/vga). But you will still be able to reach every interface as you've set it up on the webinterface after a reboot. No changes of this job will be saved to the configuration file.
If every wlan has been disabled the parent interface will be brought down automatically to save power.
r503: Jobs with interfaces that have been unassigned or deactivated via webinterface will be deleted automatically.

Traffic Shaper:
Changes of this job will be saved to the configuration file. Rules/pipes/queues will be determined by their description. If two rules/pipes/queues have the same description they will both be modified. Rules/pipes/queues with no description will be ignored.
r502: For now: Be aware that if you change the description of a rule/pipe/queue you have to update the selected rule/pipe/queue of a job as well.
r503: If you change the description of a rule/pipe/queue or delete a rule/pipe/queue the matching jobs will be updated/deleted automatically.

Execute command:
As long as you don't call php or a php file you can execute pretty much any command you'd like to.

Regards,
Lennart

This scheduler looks amazing.  I am running m0n0wall on several production routers in cafes right now...I am seriously considering upgrading to the betas to test in these environments...mostly because of this scheduler.  I would be happy to report back on any bugs or issues..

Anyone see any reason why at this point, I shouldn't try these in my cafes?  My biggest reason is for the auto reboot once a while just to see how it helps deal with some of the slow-downs and captive-portal problems. We get a lot of clients!

Why don't you give it a try in a testing environment?

If the beta isn't stable enough for your purpose it shouldn't be hard to implement the scheduler into the 1.33 version. But for that we'd have to modify the image and I haven't given myself the time yet to figure out how the image can be modified.
The croen daemon itself hasn't been tested in a long run but I've simulated a million loops and checked for memory leaks with valgrind.

Hi,
i have tested the b499 and b500 versions heavily without any problems using Captive Portal functions (I did not use IPv6 and WLAN)
Give it a try. jakob