dummynet patch
Can someone make an patch for dummynet, so an user can't get maximum bandwith. Queue work great for sharing same bandwidth, but an user can get much banditdth if is not used but anothers. So is wonderfull if i can put an paramaters for queue (like for pipe), to limit bandwidth: For example: ipfw pipe 1 congig bw 1mbit/s ipfw queue 1 config weight 10 pipe 1 bw 128kbits/s ipfw queue 1 config weight 15 pipe 1 bw 256kbits/s This mean that i have two queue that share same pipe. Bandwidth is given accordint with their weight but no more that value indicated by "bw" parameter. In my example queue 1 can get more than 128 kbits/s. In this mode bandwidth is well splited but an user can't get all bandidth if is alone on network. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dummynet patch
Hi, > Can someone make an patch for dummynet, so an user can't get maximum > bandwith. Queue work great for sharing same bandwidth, but an user can > get much banditdth if is not used but anothers. > So is wonderfull if i can put an paramaters for queue (like for pipe), > to limit bandwidth: > For example: > ipfw pipe 1 congig bw 1mbit/s > ipfw queue 1 config weight 10 pipe 1 bw 128kbits/s > ipfw queue 1 config weight 15 pipe 1 bw 256kbits/s > > This mean that i have two queue that share same pipe. Bandwidth is > given accordint with their weight but no more that value indicated by > "bw" parameter. In my example queue 1 can get more than 128 kbits/s. > In this mode bandwidth is well splited but an user can't get all > bandidth if is alone on network. You can just set net.inet.ip.fw.one_pass to 0 and use more pipes to limit the maximum bandwidth. Let's say you want to limit the whole pipe to 1MBits/s and then limit user with UID 1001 to 128 KBits/s on your external interface fxp0 : % sysctl -w net.inet.ip.fw.one_pass=0 # First skip to the end of the rules if we're not on the outgoing # path through fxp0. % ipfw add 100 skipto 65000 all from any to any not xmit fxp0 # Limit user 1001 max bandwidth. % ipfw pipe 1001 config bw 128KBits/s % ipfw add 200 pipe 1001 all from any to any # System-wipe policy. % ipfw pipe 1 config bw 1MBits/s % ipfw queue 11 config weight 10 pipe 1 % ipfw queue 12 config weight 20 pipe 2 % ipfw add 210 queue 11 ... % ipfw add 220 queue 12 ... -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dummynet patch
Hi, > Yes, thanks! But is a little redundant and confused to pass packets to > multiple pipe and queue. Isn't more elegant to put an option on queue > that limit maximum bandwitdth to that queue (like "bw" option for pipe)? > I dont know programming (not well), but i think that, can do the job, > if is put an supplementary condition, to verify if bandwidth > allocated for that queue is less or great than an "bw" parameter. > An queue declaration like: > ipfw queue 1 config weight 10 pipe 1 bw 128kbits/s > ipfw queue 2 config weight 20 pipe 1 bw 256kbits/s > is more clear and efficiently. > This mean that an queue receive bandwidth according with they weight > but no more that value indicated by "bw" parameter. > Someone with experience and that know code for dummynet, can make easy > (i think) an patch for that. Many folks are reluctant to add syntactic sugar on IPFW when it does not add any functionnality. I think I am too : if we add every shorthand that one can think of, ipfw would become a real mess. Furthermore, pipes and queues are two distinct objects which have different semantics. Pipes are used to emulate a physical network link, with two main properties : bandwidth and delay, while queues provide WF2Q+ policy (see ipfw(8) manpage). Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dummynet patch
On Tue, Sep 20, 2005 at 07:20:26PM +0300, vladone wrote:
> I know what is WF2Q, but still dont see what is the problem for wich
> dont't exist a possibility to limit bandwidth that is given to a
> queue, with queue settings.
it not implemented because there is an equivalently efficient
mechanism which is first pass packets through a shaper
and then to the WF2Q "queue".
say you want to select on src-ip:
sysctl net.inet.ip.fw.one_pass=0
// misc stuff that sends your traffic to rule 4500
(1) ipfw add 4500 pipe 1 ip from any to any
ipfw add 4501 queue 2 ip from any to any
ipfw add 4502 allow ip from any to any
(2) ipfw pipe 1 config bw 300kbit/s mask src-ip 0x
ipfw queue 2 config weight 10 pipe 3 mask src-ip 0x
ipfw pipe 3 config bw 1Mbit/s
and there you have 1mbit total, 300k max per flow.
if you think your proposed scheme (which saves lines 1 and 2
from the configuration, but part of line 2 must be folded back
into the next line) is more efficient, implement it and measure it.
My take is that it saves maybe 5-10us/packet on 500MHz class boxes.
To me, it is not worth the effort in terms of added code
complexity.
cheers
luigi
> And exist a precedent, "queue" paramater that exist for pipe and
> queue.
> For example, if a "bw" parameter is not used for queue, then bandwidth
> is given only acording with they weight, so use this option who want,
> like anothers parameters ("dst-ip, mask, queue, even weight").
> And my suggestion isn't a caprice.
> For example: if i have multiple users, that acces internet throught an
> freebsd gateway. How split bandwidth?
> I have two clear solutions:
> 1. assign for each host an pipe. But i dont know if in this mode, in
> conditions of heavy traffic, bandwidth is well splited. Is possibil
> for an user to take more bandwidth (according with his pipe), and
> another user remain without bandwidth.
> 2. share total bandwidth, to different hosts, with queue. This is more
> efficient but have a little problem. If an user is alone on traffic
> can get all bandwith. For this reason, i want (and i think many
> admins) an possibility to limit bandwidth that is given to a queue.
>
> I don't think that passing packets to multiple pipe and queue is e
> efficiently for traffic flow.
> My sugestion about "bw" parameter for queue is only for convenience. U
> can named how you want, so i dont see problem about "... pipes and queues are
> two distinct objects which have
> different semantics."
>
> ___
> freebsd-ipfw@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dummynet patch
Hi,
> I know what is WF2Q, but still dont see what is the problem for wich
> dont't exist a possibility to limit bandwidth that is given to a
> queue, with queue settings.
> And exist a precedent, "queue" paramater that exist for pipe and
> queue.
> For example, if a "bw" parameter is not used for queue, then bandwidth
> is given only acording with they weight, so use this option who want,
> like anothers parameters ("dst-ip, mask, queue, even weight").
> And my suggestion isn't a caprice.
> For example: if i have multiple users, that acces internet throught an
> freebsd gateway. How split bandwidth?
> I have two clear solutions:
> 1. assign for each host an pipe. But i dont know if in this mode, in
> conditions of heavy traffic, bandwidth is well splited. Is possibil
> for an user to take more bandwidth (according with his pipe), and
> another user remain without bandwidth.
> 2. share total bandwidth, to different hosts, with queue. This is more
> efficient but have a little problem. If an user is alone on traffic
> can get all bandwith. For this reason, i want (and i think many
> admins) an possibility to limit bandwidth that is given to a queue.
>
> I don't think that passing packets to multiple pipe and queue is e
> efficiently for traffic flow.
> My sugestion about "bw" parameter for queue is only for convenience. U
> can named how you want, so i dont see problem about "... pipes and queues are
> two distinct objects which have
> different semantics."
You definitely want to use ALTQ, which is available since RELENG_5.
Dummynet is not designed to achieve traffic management, its intent
is to emulate a network.
ALTQ will allow you to share bandwidth in a very fair way, such as
you describe here.
Regards,
--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: dummynet patch
Yes, thanks! But is a little redundant and confused to pass packets to multiple pipe and queue. Isn't more elegant to put an option on queue that limit maximum bandwitdth to that queue (like "bw" option for pipe)? I dont know programming (not well), but i think that, can do the job, if is put an supplementary condition, to verify if bandwidth allocated for that queue is less or great than an "bw" parameter. An queue declaration like: ipfw queue 1 config weight 10 pipe 1 bw 128kbits/s ipfw queue 2 config weight 20 pipe 1 bw 256kbits/s is more clear and efficiently. This mean that an queue receive bandwidth according with they weight but no more that value indicated by "bw" parameter. Someone with experience and that know code for dummynet, can make easy (i think) an patch for that. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: dummynet patch
I know what is WF2Q, but still dont see what is the problem for wich
dont't exist a possibility to limit bandwidth that is given to a
queue, with queue settings.
And exist a precedent, "queue" paramater that exist for pipe and
queue.
For example, if a "bw" parameter is not used for queue, then bandwidth
is given only acording with they weight, so use this option who want,
like anothers parameters ("dst-ip, mask, queue, even weight").
And my suggestion isn't a caprice.
For example: if i have multiple users, that acces internet throught an
freebsd gateway. How split bandwidth?
I have two clear solutions:
1. assign for each host an pipe. But i dont know if in this mode, in
conditions of heavy traffic, bandwidth is well splited. Is possibil
for an user to take more bandwidth (according with his pipe), and
another user remain without bandwidth.
2. share total bandwidth, to different hosts, with queue. This is more
efficient but have a little problem. If an user is alone on traffic
can get all bandwith. For this reason, i want (and i think many
admins) an possibility to limit bandwidth that is given to a queue.
I don't think that passing packets to multiple pipe and queue is e
efficiently for traffic flow.
My sugestion about "bw" parameter for queue is only for convenience. U
can named how you want, so i dont see problem about "... pipes and queues are
two distinct objects which have
different semantics."
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: dummynet patch
Thanks for reply Luigi! I want to implements, but i dont know programming so good to modify dummynet code. My sugestions is because i love dummynet, i think that work great, but need some improvements, to be more adaptable to different situations. For moment will utilize, passing packets to multiple pipe or queue, but for future, if is possibil, please make some changes. Altq is not perfect, because he don't divides proportional bandwidth, only priority that is not very clear what mean. Dummynet is beautiful for this option in queue (weight). This is the reason for what i work with freebsd and not with linux (altq is like htb). I'm fan dummynet!! :) ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/156770: [ipfw] [dummynet] [patch]: performance improvement and several extensions
Synopsis: [ipfw] [dummynet] [patch]: performance improvement and several extensions Responsible-Changed-From-To: freebsd-net->freebsd-ipfw Responsible-Changed-By: ae Responsible-Changed-When: Tue May 3 11:42:34 UTC 2011 Responsible-Changed-Why: Seems it is related to ipfw. http://www.freebsd.org/cgi/query-pr.cgi?pr=156770 ___ 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
The following reply was made to PR kern/156770; it has been noted by GNATS. From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= To: bug-follo...@freebsd.org, al...@alter.org.ua Cc: Subject: Re: kern/156770: [ipfw] [dummynet] [patch]: performance improvement and several extensions Date: Sat, 28 Jan 2012 17:58:56 +0200 Hi, Team. Do you plan to port this patch to FreeBSD-10 or 9? It will be veri nice especially this feature: # it is possible to use bmap instead of port list. It gives performance benefit when you have large list of services. Lookup time doesn't depend on list size. Rather useful to QoS game traffic. ___ 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 Sat, Jan 28, 2012 at 04:00:28PM +, ??? ??? wrote: > The following reply was made to PR kern/156770; it has been noted by GNATS. > > From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= > To: bug-follo...@freebsd.org, al...@alter.org.ua > Cc: > Subject: Re: kern/156770: [ipfw] [dummynet] [patch]: performance improvement > and several extensions > Date: Sat, 28 Jan 2012 17:58:56 +0200 > > Hi, Team. > > Do you plan to port this patch to FreeBSD-10 or 9? > It will be veri nice > > especially this feature: > # it is possible to use bmap instead of port list. It gives performance > benefit when you have large list of services. Lookup time doesn't depend on > list size. Rather useful to QoS game traffic. not as is. Way too many pieces, many are interesting, from the description some of them are already in. If someone can submit smaller patches for the individual features (such as port maps, fast tags etc) then i can certainly consider adding some of them. ___ 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
The following reply was made to PR kern/156770; it has been noted by GNATS. From: Alter To: bug-follo...@freebsd.org, Alter Cc: Subject: Re: kern/156770: [ipfw] [dummynet] [patch]: performance improvement and several extensions Date: Thu, 14 Jun 2012 17:11:18 +0200 Hello bug-followup, I've made unified diff for this patch: http://alter.org.ua/soft/fbsd/ipfw/ipfw.72.20120614u.patch.gz About porting: seems, I'll port it to 8.x soon. Also, there were some discussions about various features of this patch and dividing it into separate patches (one for each feature). What I can do almost immediately is making single patch with some subset of new features. Even with some additional sysctls or #define's (to enable/disable feature). I just need to know the final decision and feature list. -- Best regards, Alter mailto: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"
Re: kern/156770: [ipfw] [dummynet] [patch]: performance improvement and several extensions
The following reply was made to PR kern/156770; it has been noted by GNATS. From: "Alexander V. Chernikov" To: bug-follo...@freebsd.org, al...@alter.org.ua Cc: Subject: Re: kern/156770: [ipfw] [dummynet] [patch]: performance improvement and several extensions Date: Fri, 15 Jun 2012 16:35:56 +0400 Hello Alexandr! I'm afraid singe huge patch for legacy release is not the promising start. Since development model assumes new code being committed to -current first, you should probably port these features to -current (it does not differ from 8-STABLE much). It is also much easier to discuss/import features by small chunks instead of single huge change, so splitting every feature into separate diff is possibly a good thing to do. Please note that some of functionality (skipto tablearg, interface tables are already implemented in a different way). Personally for me index table for fast skipto/pipes, mapped tables and io_fast patch looks very promising, so we can discuss directly if you're interested. ___ 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
Synopsis: [ipfw] [dummynet] [patch]: performance improvement and several extensions Responsible-Changed-From-To: freebsd-ipfw->melifaro Responsible-Changed-By: melifaro Responsible-Changed-When: Sun Jul 1 15:54:17 UTC 2012 Responsible-Changed-Why: Take http://www.freebsd.org/cgi/query-pr.cgi?pr=156770 ___ 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 Sun, Jul 01, 2012 at 03:54:35PM +, melif...@freebsd.org wrote: > Synopsis: [ipfw] [dummynet] [patch]: performance improvement and several > extensions > > Responsible-Changed-From-To: freebsd-ipfw->melifaro > Responsible-Changed-By: melifaro > Responsible-Changed-When: Sun Jul 1 15:54:17 UTC 2012 > Responsible-Changed-Why: > Take > > http://www.freebsd.org/cgi/query-pr.cgi?pr=156770 Alex, please any ipfw-related patch through me before committing. On this specific PR i have some comments and several concerns. First, as mentioned in the thread, some specific features (e.g. ftags) might be of interest, but the fact that this is a single monolitic patch make it hard to apply and review. Especially, at least judging from the description, i believe some of the changes replicate features that were already inserted around 2009 and later (in then-head). On the negative side: - documentation on new features is completely absent. Just a brief mention in the manpage of ftag/funtag, a short comment in a C source code. - the way some features are implemented is through adding new IOCTLs, which is the wrong way of doing things. In the 2009 rewrite (ipfw3) i tried to use a single ioctl which carries tagged messages for the various requests (similar to the microinstructions which make up a rule) so the code is easier to extend without breaking ABIs. Please follow the new style if you need to add commands. - can you please split the patch in individual components, and make sure that they not replicate functions already existent (or if they do, are they an improvement) ? I am especially referring to indexed skipto - a large number of changes to the userspace code replaces errx() with return my_err(...) . I might agree on the principle, but I'd like to see a few notes on why this change is required, and whether it can be applied independently of the others. cheers luigi ___ 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 01.07.2012 23:09, Luigi Rizzo wrote: On Sun, Jul 01, 2012 at 03:54:35PM +, melif...@freebsd.org wrote: Synopsis: [ipfw] [dummynet] [patch]: performance improvement and several extensions Responsible-Changed-From-To: freebsd-ipfw->melifaro Responsible-Changed-By: melifaro Responsible-Changed-When: Sun Jul 1 15:54:17 UTC 2012 Responsible-Changed-Why: Take http://www.freebsd.org/cgi/query-pr.cgi?pr=156770 Alex, Not sure if you're speaking to me, since both submitter and I are Alexanders :) However I'll try to answer some of the questions. please any ipfw-related patch through me before committing. On this specific PR i have some comments and several concerns. First, as mentioned in the thread, some specific features (e.g. ftags) might be of interest, but the fact that this is a single monolitic patch make it hard to apply and review. Especially, at least judging from the description, i believe some of the changes replicate features that were already inserted around 2009 and later (in then-head). We already got private discussion resulting in preparation of some most interesting (at least to me) parts of code to be split into different patches and remade to work on -current. Particularly I'm interested in rule indexes mostly. On the negative side: - documentation on new features is completely absent. Just a brief mention in the manpage of ftag/funtag, a short comment in a C source code. - the way some features are implemented is through adding new IOCTLs, which is the wrong way of doing things. In the 2009 rewrite (ipfw3) i tried to use a single ioctl which carries tagged messages for the various requests (similar to the microinstructions which make up a rule) so the code is easier to extend without breaking ABIs. Please follow the new style if you need to add commands. IP_FW3 is already used in ipv6 tables code, so there are some ipfw(8) and kernel code to reuse. - can you please split the patch in individual components, and make sure that they not replicate functions already existent (or if they do, are they an improvement) ? I am especially referring to indexed skipto - a large number of changes to the userspace code replaces errx() with return my_err(...) . I might agree on the principle, but I'd like to see a few notes on why this change is required, and whether it can be applied independently of the others. cheers luigi ___ 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"
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"
Re: kern/143621: [ipfw] [dummynet] [patch] dummynet and vnet use results in panic
Old Synopsis: [patch] dummynet and vnet use results in panic New Synopsis: [ipfw] [dummynet] [patch] dummynet and vnet use results in panic Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 7 05:33:05 UTC 2010 Responsible-Changed-Why: Patch is actually against ipfw, so over to that mailing list, although perhaps it should get to n...@. http://www.freebsd.org/cgi/query-pr.cgi?pr=143621 ___ 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"
