Re: ipt_time fixes (resend, sorry)

[Brad Fisher <brad@info-link.net>]

Brad Fisher wrote:

> Krzysztof Oledzki wrote:
>
>>
>> -        packet_local_time = skb->stamp.tv_sec;
>> +    /* We might not have a timestamp, get one */
>> +    if (skb->stamp.tv_sec == 0)
>> +        do_gettimeofday((struct timeval *)&skb->stamp);
>>
>>      /* First we make sure we are in the date start-stop boundaries */
>> -    if ((packet_local_time < info->date_start) || (packet_local_time 
>> > info->date_stop))
>> +    if ((skb->stamp.tv_sec < info->date_start) || (skb->stamp.tv_sec 
>> > info->date_stop))
>>          return 0; /* We are outside the date boundaries */
>>
> I'd like to see the above like become:
>
> +    if ((skb->stamp.tv_sec >= info->date_start) && (skb->stamp.tv_sec 
> <= info->date_stop))
>         return 0; /* We are outside the date boundaries */
>
> This will have the same logic in most situations, and fix a problem 
> with the time match where you need 2 rules to match something like all 
> times between 20:00-04:00 (ie. the start time is "greater" than the 
> end time).  I've used something similar for years and enjoy not 
> needing multiple rules for this.  I also have a patch (and I believe 
> I've submitted it in the past) for grabbing the kernel time if no time 
> is known (and with that patch, or what's being discussed here, I 
> believe the time match should work in any chain).
>
> -Brad Fisher
>
>
> !DSPAM:41e7f37a167171105578672!
>

Sorry for the additional spam :(
 
The check should be changed to something like the following:

+      if (info->date_start <= info->date_stop) {
+              /* normal order: start <= stop */
+              if ((skb->stamp.tv_sec < info->date_start) || 
(skb->stamp.tv_sec > info->date_stop))
+                        return 0;
+        } else {
+              /* reversed order: stop < start */
+                if ((skb->stamp.tv_sec < info->date_start) && 
(skb->stamp.tv_sec > info->date_stop))
+                        return 0;
+        }

Sorry about the previous crap :)  Anyway, this only adds one more if 
test per packet, which in my opintion is acceptable when the alternative 
is an additional rule.

-Brad