ipfw tracing

[Andrey V. Elsukov]

Julian Elischer wrote:
>> What you think about that?
>>
> Can you show some sample usage and output?

Sorry, i don't have patched ipfw on production servers and
can show only syntetic example.

Let us suppose that we have a lots of rules on the our gateway
(allow, deny, skipto, pipe, divert, etc).
And we have a task - permit an access from some host A to some
host B. This can be easy by adding a permit rule into some place
at the head of rules. But i got used to store some related rules
in the blocks and don't want to have a random sequences of rules.

The tracing is simple way to determine which a rules process our
packets. We add a tagging rule in the head of rules and begin
tracing.

Example:
# ipfw add 1 count tag 123 ip from any to 239.192.2.21
# sysctl net.inet.ip.fw.trace_tag=123
# tail -f /var/log/security
Oct 25 09:08:07 btr-nb kernel: ipfw: 1 Count UDP 172.21.81.221:1102 
239.192.2.21:4545 in via nve0
Oct 25 09:08:07 btr-nb kernel: ipfw: 1014 SkipTo 2050 UDP 
172.21.81.221:1102 239.192.2.21:4545 in via nve0
Oct 25 09:08:07 btr-nb kernel: ipfw: 65535 Deny UDP 172.21.81.221:1102 
239.192.2.21:4545 in via nve0
Oct 25 09:08:08 btr-nb kernel: ipfw: 1 Count UDP 172.21.81.222:1089 
239.192.2.21:4545 in via nve0
Oct 25 09:08:08 btr-nb kernel: ipfw: 1014 SkipTo 2050 UDP 
172.21.81.222:1089 239.192.2.21:4545 in via nve0
Oct 25 09:08:08 btr-nb kernel: ipfw: 65535 Deny UDP 172.21.81.222:1089 
239.192.2.21:4545 in via nve0

I think this feature can be usable, but needed some limiting..

-- 
WBR, Andrey V. Elsukov