Re[2]: kern/156770: [ipfw] [dummynet] [patch]: performance improvement and several extensions
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
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
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"