I'm having some trouble with the time parameter for a banned client in the restrict.cfg of Freesco 0.4.1. What I want to achive is to ban internet access to one of the clients on my network between the hours of 11pm and 6am.

I have the following line in my etc/restrict.cfg file:

bl,00:02:8a:98:f8:47,2300,600

I find that this works, as long as the router is already running when 11pm comes around. I don't leave my computers running permanently, I switch them off when they are not in use - including the router. The problem occurs when the router is switched on and boots during the "banned" time.

For example, if the router is switched on at 8pm, then after 11pm the client computer can no longer access the internet (until 6am the following morning). No problem there. However, if I switch the router on at, say, 11:30pm, then the client has full access to the internet! So it appears something goes wrong if the router boots during the time that the client must be banned.

I noticed that if I browse to the web control panel, the current time is given at the top of the page. For example, the following is shown:

The current time on the first line was correct, 12:27 WST on 26 Feb, at the time of opening the control panel. But notice the next two lines: "System is up since 19:41 WST on Feb26, up time 1:46". For a start, this is impossible - how can the system be up since a time AFTER the current time today? Further, if the router was booted 1 hour and 46 minutes ago, and the current time is 12:27, then the boot time should be 10:41 WST (not 19:41). Somehow the indicated time of boot is 7 hours ahead of the actual time of booting.

Note that the time zone where I live is GMT +9 hours (Western Australia Standard Time). I do have the time zone file "perth" in my /TMZ directory.

I may be wrong here, but it seems to me this could be the reason why the router is allowing access to the client if it boots during the "banned" time. Maybe it is working on the incorrect time of booting - even though the current time is obviously corrected soon after - presumably by the synchronize function of the http control/time server.

I don't know why the time of booting appears to be incorrect. I did check the current time in the BIOS CMOS memory of the router PC, and that is correct.

There is and has always been several unresolvable issue when using the timezone files. This is due to the fact that FREESCO does not actually mount a drive until it is already running Linux. Therefor the boot time is always used from the BIOS up until the drive is mounted and then it uses the timezone offset to change it up until the system time synchronizes with a time server and makes the proper corrections. This means that from the point the drive is mounted until it is synchronized the time is incorrect. This is not usually a problem because most boxes do not get rebooted very often. But in the boot sequence the synchronization is a little bit late for several important operations that can take place and in particular the firewall which would ban an internal client the first time it runs with the wrong time and the trigger to restart the firewall only happens at the specified times automatically.

There are two different ways to solve this problem on your system. The first is to remove the timezone file and use the static time offset as +0900 in the control time server. You also can add a firewall restart in the rc_user file start section so the firewall gets reset after the time is synchronized.

I removed the time zone file from the /TMZ directory, and set the time offset to a fixed +0900 hours, and now the correct boot time is shown on the control panel.

However, the client machine can still access the internet if the router is booted during the "banned" time. So I put the "restart" command in the rc_user file, and now it works as expected - the client has no internet access during the specified times.

One other point: I noticed that during boot of the router, at the point where it shows on the monitor "NAT and firewalling is enabled..." sometimes next to it appears "Done", and sometimes it shows "Memory fault".

When "Memory fault" is displayed, everything still appears to work OK. So I'm not sure if this is a real fault or a false message.

I have run MemTest 86 on the router, and it passed all tests. I am running the system from RAM (read-only floppy disk).

This random error was showing up previously, before I put the "restart" into the rc_user file, so it seems to be nothing to do with that.

There are a lot of processes going on in the background even when it is showing that it is starting the NAT firewall and in some configurations such as PPPoE and PPtP types of connections the system connection may actually not be completely up when the firewall is being enabled. This can cause the firewall to have to finish the original process and one or more new processes into the background which could conceivably cause a memory fault on some systems, in particular when MAC addresses are used and the system must decode the MAC to an IP. Which I have attempted to hide most of the firewall juggling into the background so it doesn't complicate the visual aspect of booting. But "memory fault" screen outputs can not be prevented from being shown. You should however see these processes displayed in the system messages file with what has triggered each event such as the firewall being restarted by a new IP or from the banlist and it may even be doing both.So most likely the memory fault is what is preventing the system from blocking that MAC address from having access. But also be aware that using MAC addresses to block Internet access has it's own set of complications. Such as immediate blocking does not happen because the system only scans for MAC addresses every 30 seconds. So allowing or blocking by MAC address other than exactly at the specified times can take the client being online for up to 30 seconds before it is triggered. Which this is not usually an issue because most machines take longer than 30 seconds from activating there network before they are ready to go online.

But I think at present you have resolved the problem in the best manner possible and I have noted the issue for the next release of FREESCO so this issue will not be as prevalent. The new v0.4.2 when it is released will automatically restart the firewall if a timezone file is detected at the very end of the booting process so that any time based firewall rules will be activated correctly.

As described above due to the circumstances of your configuration you have hit upon every problematic aspect of the system all at once. All of these issues have been addressed previously to minimize there nature and fix them under most circumstances. But rebooting is the most complicated of them all and it will be better in v0.4.2

It also would be helful to me to see your exact configuration with a report.txt so that I can hopefully see what parts of the system can be improved for these circumstances.

If you are afraid that you might make a mistake. The chances are high that you will never learn anything.

Lightning,You are right about the firewall starting whilst a PPPoE connection is still being established - I do use PPPoE in my system, and often the "Memory fault" message pops up whilst the ADSL modem is still negotiating with the service provider.

It's not a problem at all for me if access blocking is delayed by 30 seconds or so.

My Report.txt is attached. Note that I usually set the option "Run in ram" to "yes", I temporarily turned this off so that I could save the Report.txt file on the floppy.