1.8b Development

[Services: Scheduler]

On version 1.8.1b532, in Services: Scheduler, in the Job(s) column:

Warning: Invalid argument supplied for foreach() in /usr/local/www/services_croen.php on line 213

(http://i.imgur.com/u903j.png)

If you don't want to look at the screenshot, it looks sorta like this:

Repeat	Job(s)	Description
,	Warning: Invalid argument supplied for foreach() in /usr/local/www/services_croen.php on line 213

All i did with the scheduler was enable it, realize no scheduling option could be triggered when a new IP was detected, and disabled the scheduler. Few days later i noticed this.

That only happens if a jobset is empty.
Have you changed something in your config.xml by hand? If not, I'd be happy if you could try to reproduce this problem.

I'll write some code that checks for empty jobsets and deletes them. However, I want to make sure that there is nothing wrong with the code at some other point.

By the way, what you are looking for is an event listener. However, you could tell us what you're trying to do and maybe there is a way it can be done with the scheduler.

[Edit]

That only happens if a jobset is empty.
Have you changed something in your config.xml by hand? If not, I'd be happy if you could try to reproduce this problem.

i definitely have not edited anything by hand. Edit: The problem is sitting here. But i presume you want me to find a way to make the problem stop happening, then start happening again?

By the way, what you are looking for is an event listener. However, you could tell us what you're trying to do and maybe there is a way it can be done with the scheduler.

i wanted to update TunnelBroker when i get a new IPv4 address.

At one time I had been looking for a way to have m0n0wall update my HE IPv6 tunnel when my IPv4 address changed. I asked for an enhancement to the Dynamic DNS service to accomplish this. This seemed like the proper place to do it.

However, my interest in this has waned because I changed ISPs from a PPPoE ADSL provider with dynamic IP that changed every time the connection bounced to a cable provider using DHCP that ties the IPv4 to the m0n0wall WAN MAC address and hence hasn't changed, not even once.

Edit:

I see by your IPv6 address you are also using a Hurricane Electric IPv6 tunnel.

If you have a Windows box, this free utility will update your tunnel endpoint when your IPv4 address changes.

http://www.iannet.org/apps/TunnelBrokerUpdate/

At one time I had been looking for a way to have m0n0wall update my HE IPv6 tunnel when my IPv4 address changed. I asked for an enhancement to the Dynamic DNS service to accomplish this. This seemed like the proper place to do it.

However, my interest in this has waned because I changed ISPs from a PPPoE ADSL provider with dynamic IP that changed every time the connection bounced to a cable provider using DHCP that ties the IPv4 to the m0n0wall WAN MAC address and hence hasn't changed, not even once.

Edit:

I see by your IPv6 address you are also using a Hurricane Electric IPv6 tunnel.

If you have a Windows box, this free utility will update your tunnel endpoint when your IPv4 address changes.

http://www.iannet.org/apps/TunnelBrokerUpdate/

i wrote my own; and it would be nice to not have to have something poll an ip, or have running on a separate PC that has to be running.

In any event, my bug report was about a bug in the beta.

[Edit]

i definitely have not edited anything by hand. Edit: The problem is sitting here. But i presume you want me to find a way to make the problem stop happening, then start happening again?

That's what I had in mind, yes. However, I can't locate the problem. Could you send me the "croen" part of your config.xml?

i wanted to update TunnelBroker when i get a new IPv4 address.

You could append something to /etc/rc.newwanip and/or to /etc/rc.newwanip6 but it would only last as long as your m0n0wall doesn't reboot.

Could you send me the "croen" part of your config.xml?

Code:

<croen>
<interval>10</interval>
<jobset/>
</croen>

Good luck!  

Thanks.

I've located the problem and added a corruption check to the scheduler in r534 r535.

Still, I don't know how the problem happened at the first place but a corruption check should have been there anyway.