Mr. Harald,
Personally, I don't think it would be impossible, it would just take
a very long time ;-)
I think the basis for implementing a packet check wouldn't have to
involve any matches or anything. The simplest form of check would involve
the following:
1. Get source/dest/ports/ICMP data/etc from userspace
2. ip*_tables constructs an skb and fills in appropriate data
3. ip*_tables calls ip*t_do_table() with appropriate args
3. ip*_tables records results and returns it to userspace
However, like you said, if you wanted to deal with connection state,
packet limiting, or any other type of match, to better create the check
packet, you would be stuck.
Does the above sound feasible as a start? Or not?
Brad
Harald Welte wrote:
> On Mon, Jul 30, 2001 at 12:04:27AM +0200, Kevin Tappe wrote:
>
>> Hello,
>>
>> I just played a bit with new netfilter structure (I used the ipchains
>> modul before, but now I switch to iptables).
>> Keep up the good work!
>>
>> It's version 1.2.2.
>> When I use the -C option to test my rules the output is "Will be
>> implemented real soon. I promise." So when is real soon? Or is it
>> already in iptables (maybe in a CVS version?).
>
>
> This is actually an ironical message from Rusty's early development days,
> which is printed for all not-implemented functions.
>
> I will have it print a different message for future iptables versions, so
> people don't get confused about that.
>
> With regard to the check function:
>
> It will most likely never get implemented.
>
> The problem is, that in iptables the matches are _very_ dynamic. And the
> decision if a packet matches can be determined by lots of other factors
> outside the packet. just specifying source/destination doesn't tell you
> which state the connection of this packet is and not on how fast and how
> often you send that packet (limit match), ...
>
> sorry, but that's where flexibility makes certain old features impossible.
>
>> Thanks,
>> Kevin
>
Personally, I don't think it would be impossible, it would just take
a very long time ;-)
I think the basis for implementing a packet check wouldn't have to
involve any matches or anything. The simplest form of check would involve
the following:
1. Get source/dest/ports/ICMP data/etc from userspace
2. ip*_tables constructs an skb and fills in appropriate data
3. ip*_tables calls ip*t_do_table() with appropriate args
3. ip*_tables records results and returns it to userspace
However, like you said, if you wanted to deal with connection state,
packet limiting, or any other type of match, to better create the check
packet, you would be stuck.
Does the above sound feasible as a start? Or not?
Brad
Harald Welte wrote:
> On Mon, Jul 30, 2001 at 12:04:27AM +0200, Kevin Tappe wrote:
>
>> Hello,
>>
>> I just played a bit with new netfilter structure (I used the ipchains
>> modul before, but now I switch to iptables).
>> Keep up the good work!
>>
>> It's version 1.2.2.
>> When I use the -C option to test my rules the output is "Will be
>> implemented real soon. I promise." So when is real soon? Or is it
>> already in iptables (maybe in a CVS version?).
>
>
> This is actually an ironical message from Rusty's early development days,
> which is printed for all not-implemented functions.
>
> I will have it print a different message for future iptables versions, so
> people don't get confused about that.
>
> With regard to the check function:
>
> It will most likely never get implemented.
>
> The problem is, that in iptables the matches are _very_ dynamic. And the
> decision if a packet matches can be determined by lots of other factors
> outside the packet. just specifying source/destination doesn't tell you
> which state the connection of this packet is and not on how fast and how
> often you send that packet (limit match), ...
>
> sorry, but that's where flexibility makes certain old features impossible.
>
>> Thanks,
>> Kevin
>