1.8b Development

I would like to add a few more "jobs" in the future if you are ok with it. First of all "Enable/Disable Wireless" because some people like to disable wireless during the night.

Sure, that sounds like a useful option! I guess in order to do that, one would have to loop through the (physical) interfaces matching $g['wireless_regex'] and do an "ifconfig down" on them to make them stop transmitting. Not sure whether everything will spring back to life without a restart of hostapd etc. when you simply "ifconfig up" them again though.

Edit: By the way. I've just seen that the dhclient is spamming the syslog at reconnect.

I think that's OK - it's sending a RELEASE when terminating and then all the DHCP messages to obtain a lease again when it restarts; for me it's correct and fine if it logs them.

Sure, that sounds like a useful option! I guess in order to do that, one would have to loop through the (physical) interfaces matching $g['wireless_regex'] and do an "ifconfig down" on them to make them stop transmitting. Not sure whether everything will spring back to life without a restart of hostapd etc. when you simply "ifconfig up" them again though.

Thanks - I will have a look at it!

I think that's OK - it's sending a RELEASE when terminating and then all the DHCP messages to obtain a lease again when it restarts; for me it's correct and fine if it logs them.

If I release and renew the lease manually using the interfaces page it doesn't spam the syslog. However, using the scheduler to reconnect it will spam the syslog.
This happens sometimes (I can't see any pattern) when I click on "Release" at the interface status page: http://www.abload.de/img/1unkyu.png

One more thing: Is it possible for me to commit directly into the repository (regarding changes to the scheduler and/or "jobs")?

I'm just in the final stage of adding the possibility to disable and enable wireless through the scheduler. With these two new jobs I'd like to add the possibility to "undo" things that have been done with the scheduler. Because of that I'd really like to have a new icon that distinctively shows the user he can undo something with a click. I was thinking of something like this but of course that would be completely alien to the m0n0wall theme.

Sadly, I am absolutely useless in making icons. Have you made the icons yourself, Manuel? And if yes could you make a simple "undo" icon? For now I will just create a link but it looks a bit odd.

Edit: I've uploaded my changes to the repository. Thanks for providing me an account!

Sadly, I am absolutely useless in making icons. Have you made the icons yourself, Manuel? And if yes could you make a simple "undo" icon? For now I will just create a link but it looks a bit odd.

I've just created/commited an undo icon. I'm not terribly proud of it, but I think it serves the purpose

I've just created/commited an undo icon. I'm not terribly proud of it, but I think it serves the purpose

Looks good to me. Thanks!

I've run a test over night on my alix box with wireless in hostap mode and two wireless configurations on one wireless card. The script works as expected but yesterday there was a kernel error that popped up after the script upped the wireless interfaces (everything seemed to work fine though): "ifa_add_loopback_route: insertion failed". I couldn't reproduce the problem. Maybe you have a clue?

Hi all,

thanks for that extension. Or to be precise: This new part of m0n0wall ;-) It is really useful to plan the forced disconnect!

I have one suggestion though: There should be some kind of indicator if the time one sets in the sheduler is AM, PM or the 24hours format.

Other than that: Genious ;-)

All the best

Hi all,

thanks for that extension. Or to be precise: This new part of m0n0wall ;-) It is really useful to plan the forced disconnect!

I have one suggestion though: There should be some kind of indicator if the time one sets in the sheduler is AM, PM or the 24hours format.

Other than that: Genious ;-)

All the best

First of all I'm glad you like it!

I've changed the description to: "Enter the time in the following format: hh:mm (24-hour notation)". I forgot about that but I should've known better as someone who lives in the UK. I'll commit the change with the next update.

Regards,
Lennart

Hey guys.

Just to give you an update: I'm going to do some major changes to the scheduler because I'm not pleased with the way it's calling an instance of php every loop interval. The daemon will still call a php script to execute a job but that's because then I am able to use existing functions of m0n0wall.
In addition there will only be one daemon running at a time so we can save some precious memory.
I will replace the "Enable/Disable Wireless" job with a new type of job that is capable of disabling/enabling specific interfaces. For example if you have a guest wlan and a personal wlan you will be able to disable only one of them. You could also disable an optional interface, wan, lan, etc.

Regards,
Lennart

Hey... again!

Major changes take their time but now I've finished writing the new daemon. I'd be very happy if someone would have a look at the code (link posted below) before I commit it to the repository. Valgrind says there are no memory leaks and I'm running some long-term tests on a m0n0wall VM right now.
Let's be realistic: It will probably take another week until I've finished updating the php files.

There are 3 files in the archive. croen.c is the new daemon, croen.conf is the config file for the new daemon and croen_exec_debug.c is a simple program that sleeps for a second and logs temp data of the new daemon. Understanding the conf file is probably easy. The only thing that isn't really obvious is the last digit of "weekly" (Monday = 1, ..., Sunday = 7) and "monthly" (1 = first day of the month) jobs.
If the cmdprefix is "/usr/local/bin/croen_exec_debug /etc/croen_jobs/", the cmdpostfix is ".cjob" and the job is called "test_once" the following command will be executed: "/usr/local/bin/croen_exec_debug /etc/croen_jobs/test_once.cjob". Be aware that spaces at the end of the line will be trimmed - not perfect, I know.
Edit: I've found a small bug and fixed it. In addition the program will now skip a loop and recalculate the target time if the time has been changed by more than +/-2 hours (instead of +/-12 hours).

Regards,
Lennart

My question is simple, why the need to re-implement a cron engin when BSD already has one that has been working just fine for decades? 

Good question! To me this was the logical step towards a better working version of my scheduler. In addition my intention was to write a really simple scheduler. But yes I've noticed that it unintentionally became more and more similar to cron. It's still different though.

I work for a WISP in the US which has over 40 monowall based APs. One problem we have is the ACK and slot timings will for whatever reason revert back to some default setting. It is great to see someone finally working on a scheduler. Do you you think it would be possible to set the wireless card timings using your scheduler? Right now, we run a cron job on a linux machine which sets the correct timings hourly to each ap. Here is what we are changing for example:
/sbin/sysctl dev.ath.0.slottime=41
/sbin/sysctl dev.ath.0.acktimeout=85
/sbin/sysctl dev.ath.0.ctstimeout=85

Another wish would be being able to set the timings in a web gui.

By the way, has anyone tested wireless N yet with the new betas?

It's definitely possible. As your problem is a bit special I think it would be overkill to write a job for these particular settings. What I could do, and I think this is a good idea, is to allow to schedule custom commands like yours.
It will take some time though because right now I'm doing a lot of major changes to the scheduler.
By the way: Have you reported this issue?

Another update:
I'm rewriting the php files so you can schedule multiple jobs at once to save another bit of memory. I will also add the possibility to schedule "every x minute" jobs.

Here is a picture of the current status: http://www.abload.de/img/gui12vy92.png
More to come soon.

Edit:
A full list of current possible actions and how the webinterface will look like: http://www.abload.de/img/gui2yuj6j.png
Rules, queues and pipes will be determined by their description name. If a rule/queue/pipe has the same name as another rule/queue/pipe both will be disabled/enabled/modified.
Oh, and if someone has a better description for "Every x minute" I'd be really grateful.

Hey guys,

Here is a simple design question: I'd like you to have a look at the following pictures and reply which version you would prefer. I'm also open to other ideas.
Black/Red: http://www.abload.de/img/gui32dbs4.png
Grey/Black: http://www.abload.de/img/gui4owa3w.png
Black/Grey: http://www.abload.de/img/gui5kyx72.png