Re: PROBLEM: Netfilter time matching matches all packets when time start and time stop is the same

[Henry Lee <henryronlee@gmail.com>]

On 08/02/2013 09:35 AM, Maciej Żenczykowski wrote:
> Does having timestart == timestop make any sense?
> Why would you want to do that?
>
> Perhaps make iptables reject such input?
>
> On Thu, Aug 1, 2013 at 4:24 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
>> On Wed, Jul 31, 2013 at 04:42:15PM +0800, Henry Lee wrote:
>>> diff --git a/net/netfilter/xt_time.c b/net/netfilter/xt_time.c
>>> index 0ae55a3..753573c 100644
>>> --- a/net/netfilter/xt_time.c
>>> +++ b/net/netfilter/xt_time.c
>>> @@ -192,7 +192,7 @@ time_mt(const struct sk_buff *skb, struct
>>> xt_action_param *par)
>>>
>>>       packet_time = localtime_1(&current_time, stamp);
>>>
>>> -   if (info->daytime_start < info->daytime_stop) {
>>> +   if (info->daytime_start <= info->daytime_stop) {
>>>           if (packet_time < info->daytime_start ||
>>>               packet_time > info->daytime_stop)
>>>               return false;
>>>
>> As far as I can see, this would cause only packets arriving at midnight
>> to match by default (i.e. without both --timestart and --timestop).
>>
>>                                                           Michal Kubecek
>>
Dear Mr Kubecek,
I can see that iptables uses 00:00:00 and 23:59:59 as the default value 
of timestart and timestop. In this case, even if both timestart and 
timestop are not defined by user, it still works correctly.
Of cause, if some other tools use 00:00:00 and 00:00:00 as the default, 
your concern will become a problem.

Dear Mr Żenczykowski,
I wouldn't use a timestart == timestop rule manually. But if I create 
iptables rules in a program or a script, this case may happen.
Rejecting this rule seems a little bit harsh, in my opinion, since it 
doesn't look so unacceptable.

Thank you both for your time.


Yours faithfully,
Henry Lee

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html