Re[2]: kern/156770: [ipfw] [dummynet] [patch]: performance improvement and several extensions

2012-07-02 Thread Alter
Hello Luigi,

Seems, Alex answered most of you questions

LR> On the negative side:
LR> - documentation on new features is completely absent. Just a brief mention
LR>   in the manpage of ftag/funtag, a short comment in a C source code.

# Fast ipfw tagging (ftag) - you can assign up to 32 ftags on packet.
All ftags are stored in single memory block as bitmap. Are faster than
usual tags, those allocate separate memory block for each tag.  

# Local ipfw tagging (ltag) - you can assign up to 32 ltags on packet.
Ltags are not preserved when packet leaves ipfw ruleset (e.g. is sent
to another interface, diverted or passed through pipe). The benefit is
performance - ltag does not require memory allocation at all.

(from http://alter.org.ua/soft/fbsd/ipfw/)

LR> - a large number of changes to the userspace code replaces errx()
LR>   with return my_err(...) . I might agree on the principle, but
LR>   I'd like to see a few notes on why this change is required,
LR>   and whether it can be applied independently of the others.

This change is required to let -q work properly in all cases.
Because of inclompete error handling ipfw may eventually exit
when processing incorrect rule regardless of -q option.
Such behavior seems to be dangerous, especially when dealing to remote
servers and auto-generated rulesets.
E.g. ruleset may become invalid because of removal of some interface
from system. Also, incorrect update of external config file (used for
ruleset generation) may lead system to inacessible state.

my_err() either calls errx() (without -q) or returns proper error code
for handling in callee (with -q)

-- 
Best regards,
 Altermailto:al...@alter.org.ua

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"


Current problem reports assigned to freebsd-ipfw@FreeBSD.org

2012-07-02 Thread FreeBSD bugmaster
Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

o kern/169206  ipfw   [ipfw] ipfw does not flush entries in table
o conf/167822  ipfw   [ipfw] [patch] start script doesn't load firewall_type
o kern/166406  ipfw   [ipfw] ipfw does not set ALTQ identifier for ipv6 traf
o kern/165190  ipfw   [ipfw] [lo] [patch] loopback interface is not marking 
f kern/163873  ipfw   [ipfw] ipfw fwd does not work with 'via interface' in 
o kern/158066  ipfw   [ipfw] ipfw + netgraph + multicast = multicast packets
o kern/157796  ipfw   [ipfw] IPFW in-kernel NAT nat loopback / Default Route
o kern/157689  ipfw   [ipfw] ipfw nat config does not accept nonexistent int
f kern/155927  ipfw   [ipfw] ipfw stops to check packets for compliance with
o bin/153252   ipfw   [ipfw][patch] ipfw lockdown system in subsequent call 
o kern/153161  ipfw   [ipfw] does not support specifying rules with ICMP cod
o kern/152113  ipfw   [ipfw] page fault on 8.1-RELEASE caused by certain amo
o kern/148827  ipfw   [ipfw] divert broken with in-kernel ipfw
o kern/148689  ipfw   [ipfw] antispoof wrongly triggers on link local IPv6 a
o kern/148430  ipfw   [ipfw] IPFW schedule delete broken.
o kern/148091  ipfw   [ipfw] ipfw ipv6 handling broken.
o kern/143973  ipfw   [ipfw] [panic] ipfw forward option causes kernel reboo
o kern/143621  ipfw   [ipfw] [dummynet] [patch] dummynet and vnet use result
o kern/137346  ipfw   [ipfw] ipfw nat redirect_proto is broken
o kern/137232  ipfw   [ipfw] parser troubles
o kern/135476  ipfw   [ipfw] IPFW table breaks after adding a large number o
o kern/129036  ipfw   [ipfw] 'ipfw fwd' does not change outgoing interface n
p kern/128260  ipfw   [ipfw] [patch] ipfw_divert damages IPv6 packets
o kern/127230  ipfw   [ipfw] [patch] Feature request to add UID and/or GID l
f kern/122963  ipfw   [ipfw] tcpdump does not show packets redirected by 'ip
s kern/121807  ipfw   [request] TCP and UDP port_table in ipfw
o kern/121122  ipfw   [ipfw] [patch] add support to ToS IP PRECEDENCE fields
o kern/116009  ipfw   [ipfw] [patch] Ignore errors when loading ruleset from
o bin/104921   ipfw   [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a
o kern/104682  ipfw   [ipfw] [patch] Some minor language consistency fixes a
o kern/103454  ipfw   [ipfw] [patch] [request] add a facility to modify DF b
o kern/103328  ipfw   [ipfw] [request] sugestions about ipfw table
o kern/102471  ipfw   [ipfw] [patch] add tos and dscp support
o kern/97951   ipfw   [ipfw] [patch] ipfw does not tie interface details to 
o kern/95084   ipfw   [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v
o kern/86957   ipfw   [ipfw] [patch] ipfw mac logging
o bin/83046ipfw   [ipfw] ipfw2 error: "setup" is allowed for icmp, but s
o kern/82724   ipfw   [ipfw] [patch] [request] Add setnexthop and defaultrou
o bin/78785ipfw   [patch] ipfw(8) verbosity locks machine if /etc/rc.fir
o bin/65961ipfw   [ipfw] ipfw2 memory corruption inside add()
o kern/60719   ipfw   [ipfw] Headerless fragments generate cryptic error mes
s kern/55984   ipfw   [ipfw] [patch] time based firewalling support for ipfw
o kern/48172   ipfw   [ipfw] [patch] ipfw does not log size and flags
o kern/46159   ipfw   [ipfw] [patch] [request] ipfw dynamic rules lifetime f
a kern/26534   ipfw   [ipfw] Add an option to ipfw to log gid/uid of who cau

45 problems total.

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"


Re: kern/156770: [ipfw] [dummynet] [patch]: performance improvement and several extensions

2012-07-02 Thread Luigi Rizzo
On Mon, Jul 02, 2012 at 01:24:09PM +0200, Alter wrote:
> Hello Luigi,
> 
> Seems, Alex answered most of you questions
> 
> LR> On the negative side:
> LR> - documentation on new features is completely absent. Just a brief mention
> LR>   in the manpage of ftag/funtag, a short comment in a C source code.
> 
> # Fast ipfw tagging (ftag) - you can assign up to 32 ftags on packet.
> All ftags are stored in single memory block as bitmap. Are faster than
> usual tags, those allocate separate memory block for each tag.  
> 
> # Local ipfw tagging (ltag) - you can assign up to 32 ltags on packet.
> Ltags are not preserved when packet leaves ipfw ruleset (e.g. is sent
> to another interface, diverted or passed through pipe). The benefit is
> performance - ltag does not require memory allocation at all.
> 
> (from http://alter.org.ua/soft/fbsd/ipfw/)

i understand that the features are nice, however you need to add
explanations in the manpage and in the code, not just in this email.
Same goes for the rest of the features.

So, let's restart the discussion once you have a patch that is
referred to HEAD and has the various features split and documented.


> LR> - a large number of changes to the userspace code replaces errx()
> LR>   with return my_err(...) . I might agree on the principle, but
> LR>   I'd like to see a few notes on why this change is required,
> LR>   and whether it can be applied independently of the others.
> 
> This change is required to let -q work properly in all cases.
> Because of inclompete error handling ipfw may eventually exit
> when processing incorrect rule regardless of -q option.

ok, that is a good change but then you should again separate the
error handling patch from the one adding new features.

> Such behavior seems to be dangerous, especially when dealing to remote
> servers and auto-generated rulesets.
> E.g. ruleset may become invalid because of removal of some interface
> from system. Also, incorrect update of external config file (used for
> ruleset generation) may lead system to inacessible state.

the previous two sentences have nothing to do with syntax checking
(which is all the frontend can do).


> my_err() either calls errx() (without -q) or returns proper error code
> for handling in callee (with -q)

cheers
luigi

> -- 
> Best regards,
>  Altermailto:al...@alter.org.ua
> 
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"