Key Pages: [ Rope Home Page | Basics (tutorial) | Language Reference | Download ]

IpTables Rope - Time And Date Handling

NB: The features described on this page were added to Rope on 14th Feb 2005, and so do not work with releases before that date.

The Rope lanaguage allows you to include the notion of time into your IP packet inspection rules. You can determine the unix system's time counter by inspecting the $kernel_time register. The value contained there follows the normal unix convention: it is the number of seconds that have elapsed since the unix "epoch" - ie: midnight on Jan 1st 1970 (GMT).

If you wish, you can also gain access to the time stamp associated with the arrival of the packet itself. This is held in $packet_time. However - note that these values are highly likely to be the same.

Making Sense Of The Time Value

You will probably want to break this time count down into the more normal "human" way of talking about time - namely: hours, minutes and seconds since midnight, or the year, the month, the day of the month or even: the day of the week. All of these things are possible.

The first thing you need to do is pass the time value you get from $kernel_time (or $packet_time) to the localtime action. This gives you back a string which holds all the information you want - but not in a format that you're going to like. For example, if I run the following script as I write this page ..

$kernel_time println
$kernel_time localtime hexdump

this is what I see..

1108742472
00000000 : 0c 00 01 00 10 00 12 00 01 00 69 00 05 00       : '..........i...'

The first line (the number) shows the number of seconds since the epoch, and the second lines shows how the broken-down time is represented in the string I get back from "localtime". Not much use eh?

Actually, this is more useful than it at first appears. We can now take the string we have got back, and use the actions that start "tm_" (like tm_year) to get at the actual values of interest.

For example:

$kernel_time localtime tm_hour println

gives the hours component of the current time. See the tm_hour page for more information about this, and similar actions.

Here's a more useful example..

$kernel_time println
$kernel_time localtime hexdump
$kernel_time localtime $t put
println( "Time is " $t tm_hour ":" $t tm_min ":" $t tm_sec )

If I run the above script, I get something like this..

1108742833
00000000 : 0d 00 07 00 10 00 12 00 01 00 69 00 05 00       : '..........i...'
Time is 16:7:13

This is getting more useful now. If you look carefully, you'll even be able to see how long the last few sentances took me write (I dont win prizes for my typing speed!). What you cant tell is that I wrote this while sitting in a train at Zurich station, waiting to get to the airport to catch my flight home.

Here Be Dragons

Be careful with some of these "tm_" actions - they follow the conventions established by the popular C programing language: some of which are counter-intuitive.

For example: Its February 2005, but let's see what we get with this script..

$kernel_time localtime $t put
println( $t tm_mon ":" $t tm_year )

This prints..

1:105

But - February is normally considered to be month 2 - so why are we getting a value of 1? Well - that's C for you. Lists of things in C normally start at number zero - so January is month 0, February is 1, March is 2 - etc.

And what about the year of 105? Consider that C was designed before anyone thought of the Y2K bug. So everyone spoke about "85" as being 1985 - and we all understood it. But where do go from "99" (meaning 1999)? I suppose (and so does C) that we just carry on giving numbers that are 1900 less than the actual year. So 2005 comes up as 105. Just add 1900 to it, and you'll get there.