From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 03:17:39 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F7C106566B for ; Sun, 23 Mar 2008 03:17:39 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 770EB8FC14 for ; Sun, 23 Mar 2008 03:17:39 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 22 Mar 2008 22:49:02 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.8.6-GA) with ESMTP id JUI70074; Sat, 22 Mar 2008 22:49:02 -0400 (EDT) Received: from 209-6-22-188.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.188]) by smtp01.lnh.mail.rcn.net with ESMTP; 22 Mar 2008 23:50:12 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18405.50481.878438.534290@jerusalem.litteratus.org> Date: Sat, 22 Mar 2008 22:49:21 -0400 To: ipfw@freebsd.org X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) Cc: roberthuff@rcn.com Subject: new NAT method ?? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2008 03:17:39 -0000 (I am not subscribed; please "CC:" me.) I have been told that for 7.0+, network address translation involving ipfw no longer uses natd(8). Is this so? If it is, where do I find documentation on the new correct way to do things? (Online Handbook says nothing; nor does my on-disk version.) (I've searched the ipfw@ archives back to June and found nothing.) Respectfully, Robert Huff From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 14:25:50 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92CD3106564A for ; Sun, 23 Mar 2008 14:25:50 +0000 (UTC) (envelope-from vladone@spaingsm.com) Received: from thunder.lsstelecom.ro (thunder.lsstelecom.ro [194.117.236.32]) by mx1.freebsd.org (Postfix) with ESMTP id C1CC58FC17 for ; Sun, 23 Mar 2008 14:25:49 +0000 (UTC) (envelope-from vladone@spaingsm.com) Received: (qmail 18060 invoked by uid 1007); 23 Mar 2008 16:25:45 +0200 Received: from 6.112.158.88.radiocom.ro (HELO ?127.0.0.1?) (vladone@spaingsm.com@88.158.112.6) by mail.lsstelecom.ro with AES256-SHA encrypted SMTP; 23 Mar 2008 16:25:45 +0200 Message-ID: <47E6686B.9000708@spaingsm.com> Date: Sun, 23 Mar 2008 16:25:47 +0200 From: Fratiman Vladut User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: cpu temperature in freebsd 7.x X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2008 14:25:50 -0000 I want to measure cpu temperature, using sysctl variables, but don't see any option. #sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.C000 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2200 dev.cpu.0.freq_levels: 2200/65000 2000/54632 1800/45314 1000/21153 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.C001 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/0 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% some suggestion? mbmon and healthd not work for me. From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 15:40:05 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3461A106564A for ; Sun, 23 Mar 2008 15:40:05 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id DBB318FC19 for ; Sun, 23 Mar 2008 15:40:04 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-84-221-247-188.cust-adsl.tiscali.it [84.221.247.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 8C27111AE6C; Sun, 23 Mar 2008 16:40:03 +0100 (CET) Received: (from piso@localhost) by southcross.wired.org (8.14.2/8.14.1/Submit) id m2NFePnj029845; Sun, 23 Mar 2008 16:40:25 +0100 (CET) (envelope-from piso) Date: Sun, 23 Mar 2008 16:40:24 +0100 From: Paolo Pisati To: Robert Huff Message-ID: <20080323154024.GA29537@tin.it> References: <18405.50481.878438.534290@jerusalem.litteratus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18405.50481.878438.534290@jerusalem.litteratus.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: ipfw@freebsd.org Subject: Re: new NAT method ?? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2008 15:40:05 -0000 On Sat, Mar 22, 2008 at 10:49:21PM -0400, Robert Huff wrote: > > (I am not subscribed; please "CC:" me.) > I have been told that for 7.0+, network address translation > involving ipfw no longer uses natd(8). > Is this so? > If it is, where do I find documentation on the new correct way > to do things? no, natd is there and works fine. in kernel nat for ipfw was just added, for more info see ipfw man page. -- bye, P. From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 23 18:52:16 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 540D31065670 for ; Sun, 23 Mar 2008 18:52:16 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 89BE28FC2B for ; Sun, 23 Mar 2008 18:52:15 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JdVIP-0004g8-AF for freebsd-ipfw@freebsd.org; Sun, 23 Mar 2008 18:51:53 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Mar 2008 18:51:53 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Mar 2008 18:51:53 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.devel.ipfw Date: Sun, 23 Mar 2008 18:51:43 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 358 Message-ID: X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: All User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-hackers@freebsd.org Subject: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2008 18:52:16 -0000 Hi! [Sorry if it is too late for SoC, but I was unexpectedly busy last 3 days and couldn't finish this text earlier.] This is a proposal for ipfw improving ideas and architectural changes. Some of them are independent of each other and could be implemented without ABI breaking in STABLE, but, whether all of these will be a SoC 2008 candidate or not, should be finally implemented in FreeBSD. The only question is what should be corrected, so please discuss it :) This text also includes slightly changed and/or generalized ideas from: http://lists.freebsd.org/pipermail/freebsd-ipfw/2007-April/002931.html All syntax examples are only to give idea, this should be discussed. 1. Major changings (ABI breaking is necesary). 1.1. Dynamic rules reorganizing. Description: Current ipfw's dynamic rules are not suitable for several advanced tricks. For example, it is not possible to use saved information about current state of connection in the firewall rules elsewhere, and it is not possible to change that state from firewall also. Wanted features: * Ability to create/delete dynamic rule in any state via some API or ABI from all parts of system: userland, ipfw rules, other kernel modules. This can be useful for: a) Creating dynamic rule in the middle of connection, not only setup: ipfw add pipe 1 ip from any to any tagged 412 keep-state-middle This allows to change handling of connection after some event, e.g. L7 filtering by ng_bpf + ng_tag discovered that a connection belongs to some class by analyzing packet payload, and from now on connection should go directly with dynamic rules, but never sent again to expensive L7 processing. Currently you can use just "keep-state" for this, but ipfw will not see SYN's and rule will be subject to sysctl net.inet.ip.fw.dyn_rst_lifetime - by default expires after 1 second, which is undesirable for many cases. b) Ability to save/load dynamic rules in userland with files, e.g., to continue after reboot. c) Ability to exchange with rules state with other machine with ipfw, e.g., two firewalls in a CARP failover. d) Creation of rule with specified state and parameter before actual connection would be established. E.g. imagine a by-default-closed firewall with a netgraph(4) module analyzing FTP control connection and giving commands to ipfw to open dynamic "holes" for data connections, thus elimanating current practice of opening ports in the entire range 1024-65535 (insecure, yes). One can think about providing direct exchange between libalias(3)'s alias_link and ipfw dynamic rules, but that's a subject for further research. * Additional fields in dynamic rules to keep arbitrary info for specific connection, and opcodes for loading and storing that values from other parts of firewall or elsewhere. This will allow to implement a pf(4)'s "scrub" maximum TTL enforcing on connection, but not only that - generic data storage allows any future extensions. * Ability to change dynamic rule's parent rule "on the fly" (just changing a pointer to which static rule's ACTION_PTR to jump, yes). The latter will allow aforementioned distinguishing of connection packets before/after L7 processing in the case where packets are always classified to flows before any processing takes place - that example with "keep-state-middle" assumed that main firewall is stateless, only L7-matched packets are subject to be dynamic. And this allows to reassign an action for dynamic rule: ... ipfw add 100 check-state ... ipfw add 200 skipto 500 ip from any to any keep-state ... ipfw add 500 netgraph 41 ip from any to any ipfw add 600 change-parent 800 ip from any to any tagged 412 ipfw add 700 allow ip from any to any ipfw add 800 pipe 1 ip from any to any * More types for dynamic rules system would allow not only "keep-state" and "limit", but rather be extensible to something more. E.g., current "limit" rules just drop packets if limit is reached - but user possibly wants an option to process them with another rule afterwards. Possible implementation: * For arbitrary info: add a union of one uint32_t or two uint16_t's or four uint8_t's two each dynamic rules and operations to load/store those values (or may be an uint64_t and two uin32_t's and so on?..). Also add one void* to allow to store more data if one needs to. * Make a special netgraph node (or extend ng_ipfw) which will broadcast every change in dynamic rules to all it's hooks (how many to bundle into one mbuf should be customizable). Every input with structs of the same format will result in addition or deletion of dynamic rules in ipfw. A netgraph node method of work provides flexible and extensible way to manipulate dynamic rules: you can connect to it protocol-trackers which will insert rules for secondary connection (e.g. FTP); you can connect to it userland tool which will log all dynamic rule changing or will do load/save of rules in a file; you can connect to it an ng_ksocket(4) node with UDP to broadcast to someone or TCP to connect to another machine with the same setup to provide CARP failover. Note that node should not do delivery/retransmission checks as pfsync(4) does, because this is a task for someone other (to keep modularity), but two such nodes on different machines connected to each other should provide automatic rules synchronizing without additional actions after initial setup. 1.2. Userland (and other subsystems) interaction, modularity, rulesets. Description: Currently /sbin/ipfw2 is a custom-made parser which communicates with the kernel via setsockopt() calls. It is sometimes hard to extend with new features due to complex code. Using a socket instead a /dev entry means you always need to be root (uid 0) to both read firewall configuration and to change it. In-kernel protocol is also sometimes hard to extend, while some addional entire-ruleset features are useful. Wanted features: * Parser's code (sbin/ipfw2.c) should be reviewed and possibly rewritten using lex(1)/yacc(1). Syntax is ocmplicated, however, and it may be not possible to not implement all of it exactly. This should be further investigated. * It may be desirable to give some other user ability to at least read config and may be to write, as /dev/bpf* permissions allow it for tcpdump(1). * Device entry could also improve modularity: currently to add a new IP_FW_* socket option, you have to modify netinet/raw_ip.c, which means you can't just recompile /sbin/ipfw and ipfw kernel module. * The same applies to other ipfw-related facilities: dummynet, divert, NAT. It can be good to keep them configurable by some other means rather than tweaking raw_ip.c. It can be useful to separate dummynet and divert to it's own facilities to be able to use them without ipfw, e.g., from netgraph(4). Related to this is a problem with IPSEC interaction - if you use it with divert(4) on output, then on return from divert packets will be IPSEC'ed again because in ip_output() IPSEC is called before pfil(9). It could be useful to add an option for user (in addition to existing behaviour, to not break POLA) to call IPSEC processing from specified place in ruleset just like all others: ipfw add ipsec ip from any to any out * As patch about using rule counters is currently discussed in ipfw@, it is useful to add ability to change rule counters to arbitrary values rather than providing the only "zero" action. This is closely related with an option of restore ipfw's static ruleset without losing counter values. Currently you can save "ipfw list" to file, do an "awk '{print "add " $0}'" on it and then load it again (e.g. after reboot). It must be possible to do the same with "ipfw show". Syntax example for providing counters with "ipfw add" - all cases are distinguishable (current syntax allow only first two): ipfw add allow ip from any to any # select next rule number ipfw add 100 allow ip from any to any # exact rule number specified ipfw add 1234 76845 allow ip from any to any # counters without rulenum ipfw add 100 1234 76845 allow ip from any to any # rulenum and counters * Static ruleset loading and saving is closely related with ruleset precompilation and atomic commits. Imagine a rulesets with thousands of rules: if a packet arrives in the middle of ruleset updating, strange effects can occur. Of course, you can achieve the same results with sets, by disabling new set and atomically swapping them later, but that is not always comfortable. Precomplilation of the whole ruleset and then atomically installing it ("transaction commit") requires an implementation which will also allow saving and loading precompiled ruleset in binary form - good for routers where 20K-rules script can be processed for several minutes. * Precompiled binary rules can also be used for the same rule setting from both other kernel subsytems and other machines (CARP again). Thus, generic binary rule format/protocol (not only for /dev) might be invented. Moreover, compiled ruleset format may be different from current linked list, which has disadvantages of both initial "skipto" (and planned "call/return", see next section) and disabled-set-rules are still traversed. Precompiled form of opcodes-only allows to do quick jumps, easy running of cross-rule optimizations (and even possibility to compile ipfw opcodes to machine code like BPF_JITTER for bpf(4) for more speed). This has disadvantages of separate rule counters keeping and not-so-transparent need for user to recompile every time, so should be further investigated. * About several rulesets, for different interfaces (or hacks like per-interface setting of rule number to jump to on it): I think that this is unnecessary and unfriendly to user - having one rulesets is simpler, and you usually need common checks on packets. So "commit" precompiled rules, "call/return" actions (see next section) and stack virtualization via "vimage" should serve all practical purposes. Possible implementation: General view is clear from features description. One also can think about netgraph(4) node for this (again) and/or something like shared memory pages between kernel and userland, to not allocate memory in kernel twice for big rulesets. 2. Independent (minor) changes, which can be possible without ABI breakage. 2.1. call/return rule actions. Description of feature: A "skipto" rule is known as a useful tool to optimize packet flow through ruleset, also able to assign several actions to a dynamic rule (because dynamic rule on match simply jumps to action part of parent rule). But it can only jump forward, not backwards, for the same reason as bpf(4) assember instruction: to prevent infinite loops in packet flow which will cause machine to hang network operations. This can be addressed by introducing a pair of instructions, call and return, which remembers position to return in the stack of some kind. Because return is always done to the next rule after calling one (by number, as with divert/skipto), it is guaranteed that infinite loops can't occur, even in case of calling one rule many times by simply proceeding to next rule after stcak overflow. Thus call/return pair allows to organize some kind of subroutines, with the trick that issuing actual number lets to jump to the middle of subroutine, as in assembly language: ipfw add 100 call 600 ip from any to any in recv $internal ipfw add 100 call 700 ip from any to any in recv $external ... ipfw add 500 allow ip from any to any ipfw add 600 deny ip from any to any not antispoof ipfw add 700 deny tcp from any to any 135,445 ipfw add 900 return // for both those calls It should be noted again that calls are made by rule numbers, so in the following example the first "call 700" will pass control to rule 301, not second rule 300. ipfw add 300 call 700 ... ipfw add 300 call 800 ... ipfw add 301 count ip ... Allowing to use "tablearg" in "call" would be very useful. Parser should allow both version of "return", with some conditions (ususal rule body) and without them (like "check-state"). Possible implementation: Relatively easy. Allocate a mbuf tag for a stack of uint16_t rule numbers and a stack top pointer on first "call" for mbuf. The only thing to care are divert etc. calls, and distinguishing input and output passes (firewall can be called several times for each), thus stack underflow and overflow should be carefully analyzed. May be two tag types, one for input and one for output. It is difficult, however, to get this performing well, because of linked-list nature of ruleset and inability to cache pointer to skip destination, as done with "skipto" currently, because there can be several locations (even tablearg). Possible solutions may be to keep a cache to, say, 256 points in the list (rulenum / 256) to reduce looking after this point (effectively equivalent to hash on rulenum). Or to have compiled rulesets where offset to jump is easily calculated (see previous section). 2.2. Tables and tableargs. Tables are very powerful way to both increase processing speed and conveniently reduce rule maintaing cost for user, especially with tableargs. Tables, however, are currently limited to IPv4 addresses/masks as keys and uint32_t's as values. Table keys should be extended to another data types: IPv6 addresses, interface name strings: ipfw add allow ip from any to table6(1) in recv stringtable(2) or ipfw call tablearg ip from any to any via stringtable(3) The latter will be very handy for routers with e.g. 2000 VLAN or ng* interfaces, with separate client and rules for each. Tableargs should also be expanded to 16 bytes, to be able to store IPv6 address ot uint64_t for checking e.g. in rule counters. It is questionable whether tableargs could also be short (< 16 bytes) strings like interfaces' names. Due to implementation difficulties of distinguishing whether action parameter is a valid value or a tablearg (you usualyy have only one invalid value out ouf 65536 which is get assigned as tablearg indicator), I suggest adding operations like "settablearg" which will set tablearg without actual table used, e.g., from saved arbitrary info from dynamic rules (see section 1.1) or even packet header. So, values for "computed goto" or something like registers still be used by tablearg (just generalizing definition of table), or, at least this should be so in opcode level - user could be present with some other keyword, but I don't see any point in hiding this details. Number of tables of all types should be configurable via sysctl or at least loader tunable rather than current hradcoded number (128). 2.3. Time limit counter. An opcode for a token bucket and/or leaky bucket should be introduced. This will have a one counter changed with timer and other changed by actual packets. We currently have O_LOG opcode looking similar to this, but O_LOG has nothing to deal with timer. Proposed opcode must be useful at least for limiting a number of connections per second, but any other possible use is appreciated, from simplest shaping without dummynet to more exotic like counter "price" coefficinets allowing to build an in-kernel billing solely on ipfw counters. It is questionable where values of counters should be stored, due to locking optimising - directly, as with O_LOG, or separately addressable space like tables. 2.4. Action rules and parameters. Change ACTION_PTR handling in kernel and preparing in compiler to allow actions and their parameters to be placed in any order (except for opcodes where order is required, e.g. prob). This would easily allow placing several opcodes of the same type to action part, e.g.: ipfw add count tag 1 tag 2 tag 3 ip from any to any and using actions and their parameters interchangeably, like having a rule without actual action opcode (only parameter instead), e.g. use "tag" or "altq" as action too (equals to "count"). 2.5. Just to mention: modip, counter limits, fragments. These patches are already currently discussed in ipfw@, but included here just to not forget. These are "modip" action, allowing to modify IP header (DSCP, ToS, TTL) and corresponding match rule options, and a rule option to match when rule counters are less then specified number packets or bytes (possibly from dynamic rule's counters), may be a tablearg. This is also related with mentioned in section 1.2 ability to control rule counters. Adding a few keywords for O_FRAG more fragment matching (not only non-first fragment), e.g. for sending to specialized netgraph(4) reassembling module, is also desirable. That's all for today. Any comments, additions, corrections are welcome! -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 08:40:03 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A3A6106564A for ; Mon, 24 Mar 2008 08:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 071608FC2B for ; Mon, 24 Mar 2008 08:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2O8e2au075372 for ; Mon, 24 Mar 2008 08:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2O8e27h075371; Mon, 24 Mar 2008 08:40:02 GMT (envelope-from gnats) Date: Mon, 24 Mar 2008 08:40:02 GMT Message-Id: <200803240840.m2O8e27h075371@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Alexander Shulikov" Cc: Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Shulikov List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 08:40:03 -0000 The following reply was made to PR kern/121955; it has been noted by GNATS. From: "Alexander Shulikov" To: bug-followup@FreeBSD.org, shulikov@gmail.com Cc: Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd Date: Mon, 24 Mar 2008 10:07:14 +0200 I receive new dump with mpd-4.4 and FreeBSD 7.0-RELEASE: # kgdb /usr/obj/usr/src/sys/kkk/kernel.debug /var/crash/vmcore.2 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc062ffa1 esp = 0xe3fedf40 ebp = 0xe3fee264 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 Uptime: 3m19s Physical memory: 1015 MB Dumping 62 MB: (CTRL-C to abort) (CTRL-C to abort) 47 (CTRL-C to abort) 31 15 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc055a0b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc055a379 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07ac2ab in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:928 #4 0xc062ffa1 in ipfw_chk (args=0xe3fee27c) at /usr/src/sys/netinet/ip_fw2.c:2303 #5 0xc0634771 in ipfw_check_out (arg=0x0, m0=0xe3fee380, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/netinet/ip_fw_pfil.c:251 #6 0xc05f99f8 in pfil_run_hooks (ph=0xc0870ea0, mp=0xe3fee410, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/net/pfil.c:78 #7 0xc0638ee2 in ip_output (m=0xc3f82600, opt=0x0, ro=0xe3fee3e4, flags=1, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:438 #8 0xc0628cf6 in dummynet_send (m=0xc3f82600) at /usr/src/sys/netinet/ip_dummynet.c:840 #9 0xc062b23c in dummynet_io (m=0xc3f82600, dir=1, fwa=0xe3fee578) at /usr/src/sys/netinet/ip_dummynet.c:1373 #10 0xc063489e in ipfw_check_out (arg=0x0, m0=0xe3fee67c, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/netinet/ip_fw_pfil.c:289 #11 0xc05f99f8 in pfil_run_hooks (ph=0xc0870ea0, mp=0xe3fee70c, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/net/pfil.c:78 #12 0xc0638ee2 in ip_output (m=0xc3f82600, opt=0x0, ro=0xe3fee6e0, flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:438 #13 0xc069aa55 in tcp_respond (tp=0x0, ipgen=0xc3f96031, th=0xc3f96045, m=0xc3f82600, ack=2416490148, seq=0, flags=Variable "flags" is not available. ) at /usr/src/sys/netinet/tcp_subr.c:572 #14 0xc0692ab6 in tcp_dropwithreset (m=0xc3f82600, th=0xc3f96045, tp=0x0, tlen=1, rstreason=3) at /usr/src/sys/netinet/tcp_input.c:2470 #15 0xc0695933 in tcp_input (m=0xc3f82600, off0=20) at /usr/src/sys/netinet/tcp_input.c:851 #16 0xc06375e8 in ip_input (m=0xc3f82600) at /usr/src/sys/netinet/ip_input.c:665 #17 0xc05f8195 in netisr_dispatch (num=2, m=0xc3f82600) at /usr/src/sys/net/netisr.c:185 #18 0xc0628d22 in dummynet_send (m=0xc3f82600) at /usr/src/sys/netinet/ip_dummynet.c:846 #19 0xc062b23c in dummynet_io (m=0xc3f82600, dir=2, fwa=0xe3feea08) at /usr/src/sys/netinet/ip_dummynet.c:1373 #20 0xc06345b7 in ipfw_check_in (arg=0x0, m0=0xe3feeb0c, ifp=0xc3c6bc00, dir=1, inp=0x0) at /usr/src/sys/netinet/ip_fw_pfil.c:163 #21 0xc05f99f8 in pfil_run_hooks (ph=0xc0870ea0, mp=0xe3feeb64, ifp=0xc3c6bc00, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:78 #22 0xc0637121 in ip_input (m=0xc3f82600) at /usr/src/sys/netinet/ip_input.c:417 #23 0xc05f8195 in netisr_dispatch (num=2, m=0xc3f82600) at /usr/src/sys/net/netisr.c:185 #24 0xc060d2c4 in ng_iface_rcvdata (hook=0xc3ee6400, item=0xc40917c0) at /usr/src/sys/netgraph/ng_iface.c:757 #25 0xc060704d in ng_apply_item (node=0xc4097b00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #26 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #27 0xc060704d in ng_apply_item (node=0xc4791c00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #28 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #29 0xc060c049 in ng_car_rcvdata (hook=0xc429d900, item=0xc40917c0) at /usr/src/sys/netgraph/ng_car.c:368 #30 0xc060704d in ng_apply_item (node=0xc4791d00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #31 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #32 0xc060704d in ng_apply_item (node=0xc4791c00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #33 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 ---Type to continue, or q to quit--- #34 0xc061a58d in ng_tcpmss_rcvdata (hook=0xc43ca800, item=0xc40917c0) at /usr/src/sys/netgraph/ng_tcpmss.c:346 #35 0xc060704d in ng_apply_item (node=0xc474b800, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #36 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #37 0xc06029df in ng_netflow_rcvdata (hook=0xc42e2200, item=0xc40917c0) at /usr/src/sys/netgraph/netflow/ng_netflow.c:469 #38 0xc060704d in ng_apply_item (node=0xc4287100, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #39 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #40 0xc0602cbc in ng_netflow_rcvdata (hook=0xc43c7c80, item=0xc40917c0) at /usr/src/sys/netgraph/netflow/ng_netflow.c:600 #41 0xc060704d in ng_apply_item (node=0xc4287100, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #42 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #43 0xc06129fe in ng_ppp_proto_recv (node=0xc409db00, item=0xc40917c0, proto=33, linkNum=0) at /usr/src/sys/netgraph/ng_ppp.c:930 #44 0xc0612af8 in ng_ppp_hcomp_recv (node=0xc409db00, item=0xc40917c0, proto=33, linkNum=0) at /usr/src/sys/netgraph/ng_ppp.c:1030 #45 0xc0612c93 in ng_ppp_comp_recv (node=0xc409db00, item=0xc40917c0, proto=33, linkNum=0) at /usr/src/sys/netgraph/ng_ppp.c:1149 #46 0xc0612d83 in ng_ppp_crypt_recv (node=0xc409db00, item=0xc40917c0, proto=33, linkNum=0) at /usr/src/sys/netgraph/ng_ppp.c:1249 #47 0xc0615ea4 in ng_ppp_rcvdata (hook=0xc4070480, item=0xc40917c0) at /usr/src/sys/netgraph/ng_ppp.c:1504 #48 0xc060704d in ng_apply_item (node=0xc409db00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #49 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #50 0xc0618354 in ng_pptpgre_rcvdata (hook=0xc43c7b80, item=0xc40917c0) at /usr/src/sys/netgraph/ng_pptpgre.c:748 #51 0xc060704d in ng_apply_item (node=0xc474be00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #52 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #53 0xc060fa60 in ng_ksocket_incoming2 (node=0xc4784000, hook=0x0, arg1=0xc42aaad4, waitflag=1) at /usr/src/sys/netgraph/ng_ksocket.c:1149 #54 0xc0609278 in ng_apply_item (node=0xc4784000, item=0xc4091280, rw=1) at /usr/src/sys/netgraph/ng_base.c:2559 #55 0xc0609643 in ngintr () at /usr/src/sys/netgraph/ng_base.c:3403 #56 0xc05f83f2 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:254 #57 0xc053d2db in ithread_loop (arg=0xc3b04280) at /usr/src/sys/kern/kern_intr.c:1036 #58 0xc053a0d9 in fork_exit (callout=0xc053d130 , arg=0xc3b04280, frame=0xe3fefd38) at /usr/src/sys/kern/kern_fork.c:781 #59 0xc0794390 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 08:50:11 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A5C810656BF for ; Mon, 24 Mar 2008 08:50:11 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 39A9C8FC13 for ; Mon, 24 Mar 2008 08:50:09 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2437624fgg.35 for ; Mon, 24 Mar 2008 01:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=aAeA/SIZ0+jSPmTyKwgX28t6hNXH3IlPZjPAO9JMixU=; b=bBGQpicDg6/fEye5kadJjzyM7XNjeUPkXPPdP4p5W3Kr1iBbheD460XZmc4SYH/5hZWY5/FsiJPA4A2fbzpUs5FujP0smiphH/IigzO8gcEQVuOtMpp2r0a8wz1PXVZ4YAuMBu2yTtzZ6XbYWircZyiv5dM6h9gHqBuVelGIbXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=kVrCNqJzPCIugLWitu0QnqA977Fq+ZsEK4HITuA4nxYX1OrdwyIEJR8+G5+adla8or6+/jT7YUeoHW7AmGotVsH5kM0SDwZlr9bYictoBgTJI8VnYHozbPbRb0LMq0k3nukOTSrCjQPPh4hQfeu5gFHPzSsd6MKJ7eBw0ES64f4= Received: by 10.82.161.19 with SMTP id j19mr16720188bue.12.1206347004941; Mon, 24 Mar 2008 01:23:24 -0700 (PDT) Received: by 10.82.154.1 with HTTP; Mon, 24 Mar 2008 01:23:24 -0700 (PDT) Message-ID: <18292fe60803240123o66d161d9l188f2e4b7dcd610b@mail.gmail.com> Date: Mon, 24 Mar 2008 10:23:24 +0200 From: "Alexander Shulikov" To: freebsd-ipfw@FreeBSD.org In-Reply-To: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> MIME-Version: 1.0 References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 08:50:11 -0000 For bug kern/121955: ([ipfw] [panic] freebsd 7.0 panic with mpd) I receive new dump with mpd-4.4 and FreeBSD 7.0-RELEASE: # kgdb /usr/obj/usr/src/sys/kkk/kernel.debug /var/crash/vmcore.2 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal double fault: eip = 0xc062ffa1 esp = 0xe3fedf40 ebp = 0xe3fee264 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 Uptime: 3m19s Physical memory: 1015 MB Dumping 62 MB: (CTRL-C to abort) (CTRL-C to abort) 47 (CTRL-C to abort) 31 15 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc055a0b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc055a379 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07ac2ab in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:928 #4 0xc062ffa1 in ipfw_chk (args=0xe3fee27c) at /usr/src/sys/netinet/ip_fw2.c:2303 #5 0xc0634771 in ipfw_check_out (arg=0x0, m0=0xe3fee380, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/netinet/ip_fw_pfil.c:251 #6 0xc05f99f8 in pfil_run_hooks (ph=0xc0870ea0, mp=0xe3fee410, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/net/pfil.c:78 #7 0xc0638ee2 in ip_output (m=0xc3f82600, opt=0x0, ro=0xe3fee3e4, flags=1, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:438 #8 0xc0628cf6 in dummynet_send (m=0xc3f82600) at /usr/src/sys/netinet/ip_dummynet.c:840 #9 0xc062b23c in dummynet_io (m=0xc3f82600, dir=1, fwa=0xe3fee578) at /usr/src/sys/netinet/ip_dummynet.c:1373 #10 0xc063489e in ipfw_check_out (arg=0x0, m0=0xe3fee67c, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/netinet/ip_fw_pfil.c:289 #11 0xc05f99f8 in pfil_run_hooks (ph=0xc0870ea0, mp=0xe3fee70c, ifp=0xc3c6bc00, dir=2, inp=0x0) at /usr/src/sys/net/pfil.c:78 #12 0xc0638ee2 in ip_output (m=0xc3f82600, opt=0x0, ro=0xe3fee6e0, flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:438 #13 0xc069aa55 in tcp_respond (tp=0x0, ipgen=0xc3f96031, th=0xc3f96045, m=0xc3f82600, ack=2416490148, seq=0, flags=Variable "flags" is not available. ) at /usr/src/sys/netinet/tcp_subr.c:572 #14 0xc0692ab6 in tcp_dropwithreset (m=0xc3f82600, th=0xc3f96045, tp=0x0, tlen=1, rstreason=3) at /usr/src/sys/netinet/tcp_input.c:2470 #15 0xc0695933 in tcp_input (m=0xc3f82600, off0=20) at /usr/src/sys/netinet/tcp_input.c:851 #16 0xc06375e8 in ip_input (m=0xc3f82600) at /usr/src/sys/netinet/ip_input.c:665 #17 0xc05f8195 in netisr_dispatch (num=2, m=0xc3f82600) at /usr/src/sys/net/netisr.c:185 #18 0xc0628d22 in dummynet_send (m=0xc3f82600) at /usr/src/sys/netinet/ip_dummynet.c:846 #19 0xc062b23c in dummynet_io (m=0xc3f82600, dir=2, fwa=0xe3feea08) at /usr/src/sys/netinet/ip_dummynet.c:1373 #20 0xc06345b7 in ipfw_check_in (arg=0x0, m0=0xe3feeb0c, ifp=0xc3c6bc00, dir=1, inp=0x0) at /usr/src/sys/netinet/ip_fw_pfil.c:163 #21 0xc05f99f8 in pfil_run_hooks (ph=0xc0870ea0, mp=0xe3feeb64, ifp=0xc3c6bc00, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:78 #22 0xc0637121 in ip_input (m=0xc3f82600) at /usr/src/sys/netinet/ip_input.c:417 #23 0xc05f8195 in netisr_dispatch (num=2, m=0xc3f82600) at /usr/src/sys/net/netisr.c:185 #24 0xc060d2c4 in ng_iface_rcvdata (hook=0xc3ee6400, item=0xc40917c0) at /usr/src/sys/netgraph/ng_iface.c:757 #25 0xc060704d in ng_apply_item (node=0xc4097b00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #26 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #27 0xc060704d in ng_apply_item (node=0xc4791c00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #28 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #29 0xc060c049 in ng_car_rcvdata (hook=0xc429d900, item=0xc40917c0) at /usr/src/sys/netgraph/ng_car.c:368 #30 0xc060704d in ng_apply_item (node=0xc4791d00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #31 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #32 0xc060704d in ng_apply_item (node=0xc4791c00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #33 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 ---Type to continue, or q to quit--- #34 0xc061a58d in ng_tcpmss_rcvdata (hook=0xc43ca800, item=0xc40917c0) at /usr/src/sys/netgraph/ng_tcpmss.c:346 #35 0xc060704d in ng_apply_item (node=0xc474b800, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #36 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #37 0xc06029df in ng_netflow_rcvdata (hook=0xc42e2200, item=0xc40917c0) at /usr/src/sys/netgraph/netflow/ng_netflow.c:469 #38 0xc060704d in ng_apply_item (node=0xc4287100, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #39 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #40 0xc0602cbc in ng_netflow_rcvdata (hook=0xc43c7c80, item=0xc40917c0) at /usr/src/sys/netgraph/netflow/ng_netflow.c:600 #41 0xc060704d in ng_apply_item (node=0xc4287100, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #42 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #43 0xc06129fe in ng_ppp_proto_recv (node=0xc409db00, item=0xc40917c0, proto=33, linkNum=0) at /usr/src/sys/netgraph/ng_ppp.c:930 #44 0xc0612af8 in ng_ppp_hcomp_recv (node=0xc409db00, item=0xc40917c0, proto=33, linkNum=0) at /usr/src/sys/netgraph/ng_ppp.c:1030 #45 0xc0612c93 in ng_ppp_comp_recv (node=0xc409db00, item=0xc40917c0, proto=33, linkNum=0) at /usr/src/sys/netgraph/ng_ppp.c:1149 #46 0xc0612d83 in ng_ppp_crypt_recv (node=0xc409db00, item=0xc40917c0, proto=33, linkNum=0) at /usr/src/sys/netgraph/ng_ppp.c:1249 #47 0xc0615ea4 in ng_ppp_rcvdata (hook=0xc4070480, item=0xc40917c0) at /usr/src/sys/netgraph/ng_ppp.c:1504 #48 0xc060704d in ng_apply_item (node=0xc409db00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #49 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #50 0xc0618354 in ng_pptpgre_rcvdata (hook=0xc43c7b80, item=0xc40917c0) at /usr/src/sys/netgraph/ng_pptpgre.c:748 #51 0xc060704d in ng_apply_item (node=0xc474be00, item=0xc40917c0, rw=0) at /usr/src/sys/netgraph/ng_base.c:2483 #52 0xc0609cb9 in ng_snd_item (item=0xc40917c0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2411 #53 0xc060fa60 in ng_ksocket_incoming2 (node=0xc4784000, hook=0x0, arg1=0xc42aaad4, waitflag=1) at /usr/src/sys/netgraph/ng_ksocket.c:1149 #54 0xc0609278 in ng_apply_item (node=0xc4784000, item=0xc4091280, rw=1) at /usr/src/sys/netgraph/ng_base.c:2559 #55 0xc0609643 in ngintr () at /usr/src/sys/netgraph/ng_base.c:3403 #56 0xc05f83f2 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:254 #57 0xc053d2db in ithread_loop (arg=0xc3b04280) at /usr/src/sys/kern/kern_intr.c:1036 #58 0xc053a0d9 in fork_exit (callout=0xc053d130 , arg=0xc3b04280, frame=0xe3fefd38) at /usr/src/sys/kern/kern_fork.c:781 #59 0xc0794390 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 10:11:24 2008 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC58B1065674 for ; Mon, 24 Mar 2008 10:11:24 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp3.yandex.ru (smtp3.yandex.ru [213.180.223.87]) by mx1.freebsd.org (Postfix) with ESMTP id 260868FC1A for ; Mon, 24 Mar 2008 10:11:23 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:5887 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S4747727AbYCXKLS (ORCPT ); Mon, 24 Mar 2008 13:11:18 +0300 X-Yandex-Spam: 1 X-Yandex-Front: smtp3 X-Yandex-TimeMark: 1206353478 X-MsgDayCount: 3 X-Comment: RFC 2476 MSA function at smtp3.yandex.ru logged sender identity as: bu7cher Message-ID: <47E77E43.4020109@yandex.ru> Date: Mon, 24 Mar 2008 13:11:15 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Alexander Shulikov References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <18292fe60803240123o66d161d9l188f2e4b7dcd610b@mail.gmail.com> In-Reply-To: <18292fe60803240123o66d161d9l188f2e4b7dcd610b@mail.gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@FreeBSD.org Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 10:11:24 -0000 Alexander Shulikov wrote: > For bug kern/121955: ([ipfw] [panic] freebsd 7.0 panic with mpd) > I receive new dump with mpd-4.4 and FreeBSD 7.0-RELEASE: Did you reset sysctl variable `net.inet.ip.fw.one_pass` into zero? There is well known double panic with dummynet, when packet re injected into pipe again and again. Check your rules. -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 10:27:28 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 255BA1065678 for ; Mon, 24 Mar 2008 10:27:28 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id B23248FC14 for ; Mon, 24 Mar 2008 10:27:27 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from nbc.matik.com.br (nbc.matik.com.br [200.152.88.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m2OARQJu031455; Mon, 24 Mar 2008 07:27:26 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Mon, 24 Mar 2008 07:27:05 -0300 User-Agent: KMail/1.9.9 References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <18292fe60803240123o66d161d9l188f2e4b7dcd610b@mail.gmail.com> <47E77E43.4020109@yandex.ru> In-Reply-To: <47E77E43.4020109@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803240727.05809.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: "Andrey V. Elsukov" , Alexander Shulikov Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 10:27:28 -0000 On Monday 24 March 2008 07:11:15 Andrey V. Elsukov wrote: > Alexander Shulikov wrote: > > For bug kern/121955: ([ipfw] [panic] freebsd 7.0 panic with mpd) > > I receive new dump with mpd-4.4 and FreeBSD 7.0-RELEASE: > > Did you reset sysctl variable `net.inet.ip.fw.one_pass` into zero? > There is well known double panic with dummynet, when packet re > injected into pipe again and again. Check your rules. what do you mean? By setting to 0 the packages are not re-injected into the= =20 pipe but go through other existing rules after the matching pipe, or not? =2D-=20 Atenciosamente, J.M. Respons=E1vel Plant=E3o Site Support Matik Infomatik Internet Technology (18)3551.8155 =A0(18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 11:07:07 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 169F1106571C for ; Mon, 24 Mar 2008 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 14F268FC2E for ; Mon, 24 Mar 2008 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2OB76u1087813 for ; Mon, 24 Mar 2008 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2OB76d3087809 for freebsd-ipfw@FreeBSD.org; Mon, 24 Mar 2008 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Mar 2008 11:07:06 GMT Message-Id: <200803241107.m2OB76d3087809@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 11:07:07 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/121955 ipfw [ipfw] [panic] freebsd 7.0 panic with mpd 16 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/111713 ipfw [dummynet] [request] Too few dummynet queue slots o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor s kern/121807 ipfw [request] TCP and UDP port_table in ipfw 29 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 11:08:16 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFDA21065678 for ; Mon, 24 Mar 2008 11:08:16 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp4.yandex.ru (smtp4.yandex.ru [213.180.223.136]) by mx1.freebsd.org (Postfix) with ESMTP id 391C48FC17 for ; Mon, 24 Mar 2008 11:08:15 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([77.72.136.145]:40947 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S737739AbYCXLIH (ORCPT ); Mon, 24 Mar 2008 14:08:07 +0300 X-Yandex-Spam: 1 X-Yandex-Front: smtp4 X-Yandex-TimeMark: 1206356887 X-MsgDayCount: 6 X-Comment: RFC 2476 MSA function at smtp4.yandex.ru logged sender identity as: bu7cher Message-ID: <47E78B92.4020907@yandex.ru> Date: Mon, 24 Mar 2008 14:08:02 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: AT Matik References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <18292fe60803240123o66d161d9l188f2e4b7dcd610b@mail.gmail.com> <47E77E43.4020109@yandex.ru> <200803240727.05809.asstec@matik.com.br> In-Reply-To: <200803240727.05809.asstec@matik.com.br> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Alexander Shulikov Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 11:08:17 -0000 AT Matik wrote: > what do you mean? By setting to 0 the packages are not re-injected into the > pipe but go through other existing rules after the matching pipe, or not? When you reset net.inet.ip.fw.one_pass to zero, packets return back into ipfw to the next rule after dummynet/netgraph. And if you have similar rules packets will be passed into dummynet/netgraph again. This is example how to get double fault (from mail archive): ifconfig em0 192.168.0.2/24 kldload ipfw kldload dummynet sysctl net.inet.ip.fw.one_pass=0 ipfw pipe 2 config bw 0 ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ipfw add 2 pipe 2 ip from any to any ping 192.168.0.1 -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 11:53:42 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB61B1065671 for ; Mon, 24 Mar 2008 11:53:42 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE208FC13 for ; Mon, 24 Mar 2008 11:53:41 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so1657133rvb.43 for ; Mon, 24 Mar 2008 04:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; bh=Ma8J3Gz5W7f7eYu5ltN/SM1/2gKY6jUS/nVITGKmkJ0=; b=K/biZs0vIALuiIsfMlQ04H/M6y0bQN7ZwrXIziNiF+B7IyQcUqZGx7ChHZeWltR6HjgJ+ETjPvHcVTCT9WGdtxUHbtNObd+T3uBdTxFhl4J3wkN+ZwOV+eWHl6JCaxl+AfshGeotBb7X9hLxI18cbYLeqW4Qnj8VI2Le3u/YtoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; b=KT2N2SY4sJX3A6kIkBp0VsDk6ZecQiLkz1mOVBy8UL5MszHrbCC0ZPPbo3eI/62MEqQB61xjIkHe/ODddYCieKOIL7hBHZY6Ael+6uUdnyGQ9IC2feJkMAgCcihkJ95Jo9kZsxmg6uzdPlnDavngvv/I6bV1y4GpahvmBFO51lw= Received: by 10.141.142.15 with SMTP id u15mr2041089rvn.238.1206359612013; Mon, 24 Mar 2008 04:53:32 -0700 (PDT) Received: from island.freebsd.org ( [201.25.194.19]) by mx.google.com with ESMTPS id l22sm10866554wrl.34.2008.03.24.04.53.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Mar 2008 04:53:31 -0700 (PDT) Message-ID: <47E79636.1000909@FreeBSD.org> Date: Mon, 24 Mar 2008 08:53:26 -0300 Organization: FreeBSD User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=53E4CFA8 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig68C51D89D2EA2978728F1F6B" From: Marcelo Araujo Cc: freebsd-ipfw@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 11:53:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig68C51D89D2EA2978728F1F6B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Vadim Goncharov wrote: > > 2.5. Just to mention: modip, counter limits, fragments. > > These patches are already currently discussed in ipfw@, but included > here just to not forget. These are "modip" action, allowing to modify I= P > header (DSCP, ToS, TTL) and corresponding match rule options, and a rul= e > option to match when rule counters are less then specified number > packets or bytes (possibly from dynamic rule's counters), may be > a tablearg. This is also related with mentioned in section 1.2 ability > to control rule counters. > > Adding a few keywords for O_FRAG more fragment matching (not only > non-first fragment), e.g. for sending to specialized netgraph(4) > reassembling module, is also desirable. > > > That's all for today. Any comments, additions, corrections are welcome!= > > =20 For remember to all, I work around of modip action stilly, I stoped my work during last week, but I work again in it. Work status: 1) We have modip action implemented: island# ipfw add modip ipfw: need modip [DF|TOS|IPPRE|DSCP]:code arg 2) Both DF and IPPRE works perfect: island# ipfw show 00010 371 36133 modip ippre:immediate ip from any to any 00011 52 5035 modip df:0 ip from any to any 3) DSCP: With the DSCP I've some errors but I believe that I fix it on this week. 4) ToS: I start the work on the next week. The patch: http://people.freebsd.org/~araujo/logs/ipfw-modip20080324.diff= Best Regards, --=20 Marcelo Araujo (__) araujo@FreeBSD.org \\\'',) http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) --------------enig68C51D89D2EA2978728F1F6B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFH55Y6ovxJd1Pkz6gRAhUqAKCVpZfYvydqItLJBJTuCF9DY+wLdACgmmFG DgswIh3yibFXEUaA68uzRq8= =4XZQ -----END PGP SIGNATURE----- --------------enig68C51D89D2EA2978728F1F6B-- From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 14:22:13 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C7BD1065672 for ; Mon, 24 Mar 2008 14:22:13 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id F0BB98FC27 for ; Mon, 24 Mar 2008 14:22:12 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m2OEMCZ3051780; Mon, 24 Mar 2008 11:22:12 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Mon, 24 Mar 2008 11:21:33 -0300 User-Agent: KMail/1.9.7 References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <200803240727.05809.asstec@matik.com.br> <47E78B92.4020907@yandex.ru> In-Reply-To: <47E78B92.4020907@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803241121.34059.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: "Andrey V. Elsukov" , Alexander Shulikov Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 14:22:13 -0000 On Monday 24 March 2008 08:08:02 Andrey V. Elsukov wrote: > AT Matik wrote: > > what do you mean? By setting to 0 the packages are not re-injected into > > the pipe but go through other existing rules after the matching pipe, or > > not? > > When you reset net.inet.ip.fw.one_pass to zero, packets return back > into ipfw to the next rule after dummynet/netgraph. And if you have > similar rules packets will be passed into dummynet/netgraph again. > > This is example how to get double fault (from mail archive): > jaaa well but that is the famous bw 0 example which is not valid, as by its= elf=20 certainly an invalid config, not connected to the existing problem the=20 reporter has I guess Jo=E3o > ifconfig em0 192.168.0.2/24 > kldload ipfw > kldload dummynet > sysctl net.inet.ip.fw.one_pass=3D0 > ipfw pipe 2 config bw 0 > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ipfw add 2 pipe 2 ip from any to any > ping 192.168.0.1 =2D-=20 Atenciosamente, J.M. Respons=E1vel Plant=E3o Site Support Matik Infomatik Internet Technology (18)3551.8155 =A0(18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 14:51:48 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C650106564A for ; Mon, 24 Mar 2008 14:51:48 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id C3D328FC15 for ; Mon, 24 Mar 2008 14:51:47 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so3908709fka.11 for ; Mon, 24 Mar 2008 07:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=bJo/HqgOS+UqfhycZPSQsU8/bCCRdoEZcY6Dld4to8g=; b=WjwducvWFx8IzRwSMs3Nz3Y9vFFDMHS2dbEy/nZgSZOdF3+nlTDyq3Be5FwJSx9eVW+tjwm14lGxeGrZ0nUhdw0iwByftTuqF/i1jaYDpAsf2BcEUob473LS6Ii4ELJswNUw5CKB/3dv21TF5+SCWaZTeFXchLlRTHa3yKLI62o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BtuQ2AWiou2x5J6+x9gsYJP/9MhRLb9FA38GjTT/h+kjnNTcFP45f5UF5QNKW3OgrwvV8CKLm2nNJMJAi0QGyy4TBOML5yfEvNE5B4qZNtyxpbWQdO1xYj7BxkM28W49JD6McSI0eG7VHa4BZD+tcWNJs15La1vOH5QLQBdWDtA= Received: by 10.82.167.9 with SMTP id p9mr17742586bue.7.1206370304989; Mon, 24 Mar 2008 07:51:44 -0700 (PDT) Received: by 10.82.154.1 with HTTP; Mon, 24 Mar 2008 07:51:44 -0700 (PDT) Message-ID: <18292fe60803240751w4b3afa31n5e8d469462da6175@mail.gmail.com> Date: Mon, 24 Mar 2008 16:51:44 +0200 From: "Alexander Shulikov" To: freebsd-ipfw@freebsd.org In-Reply-To: <200803241121.34059.asstec@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <200803240727.05809.asstec@matik.com.br> <47E78B92.4020907@yandex.ru> <200803241121.34059.asstec@matik.com.br> Cc: AT Matik , bu7cher@yandex.ru Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 14:51:48 -0000 IyBzeXNjdGwgLWEgfCBncmVwIG9uZV9wYXNzCm5ldC5pbmV0LmlwLmZ3Lm9uZV9wYXNzOiAwCgpZ ZXMgLSBpdCBlcSAwLiBCdXQgSSBuZWVkIGl0IGZvciBuZXh0IHNpdHVhdGlvbjogYWxsIG5ldCBJ IG5lZWQgc2hhcGUKYXQgb25lIHNwZWVkLCBidXQgaW52aWRpZHVhbCBpcCBhZGRyZXNzZXMgdG8g YW5vdGhlciBzcGVlZC4KRm9yIGV4YW1wbGUsCmlwZncgcGlwZSAxIGNvbmZpZyBidyAxME1iaXQv cyBxdWV1ZSAxMDAKaXBmdyBwaXBlIDIgY29uZmlnIGJ3IDEwTWJpdC9zIHF1ZXVlIDEwMAppcGZ3 IGFkZCBwaXBlIDEgaXAgZnJvbSAxOTIuMTY4LjEuMC8yNCB0byBhbnkKaXBmdyBhZGQgcGlwZSAy IGlwIGZyb20gYW55IHRvIDE5Mi4xNjguMS4wLzI0CmlwZncgcGlwZSAzIGNvbmZpZyBidyAxTWJp dC9zIHF1ZXVlIDEwMAppcGZ3IHBpcGUgNCBjb25maWcgYncgMU1iaXQvcyBxdWV1ZSAxMDAKaXBm dyBhZGQgcGlwZSAzIGlwIGZyb20gMTkyLjE2OC4xLjEvMzIgdG8gYW55CmlwZncgYWRkIHBpcGUg NCBpcCBmcm9tIGFueSB0byAxOTIuMTY4LjEuMS8zMgouLi4uLi4KCgpBbHNvIHRoaXMgY29uZmln dXJhdGlvbiB3b3JrIGluIEZyZWVCU0QgNi4yLiAoTWF5IGJlIGluIDYuMiBzbWFsbGVyIGNhbGwg dHJlZT8pCgoKMjAwOC8zLzI0LCBBVCBNYXRpayA8YXNzdGVjQG1hdGlrLmNvbS5icj46Cj4gT24g TW9uZGF5IDI0IE1hcmNoIDIwMDggMDg6MDg6MDIgQW5kcmV5IFYuIEVsc3Vrb3Ygd3JvdGU6Cj4g ID4gQVQgTWF0aWsgd3JvdGU6Cj4gID4gPiB3aGF0IGRvIHlvdSBtZWFuPyBCeSBzZXR0aW5nIHRv IDAgdGhlIHBhY2thZ2VzIGFyZSBub3QgcmUtaW5qZWN0ZWQgaW50bwo+ICA+ID4gdGhlIHBpcGUg YnV0IGdvIHRocm91Z2ggb3RoZXIgZXhpc3RpbmcgcnVsZXMgYWZ0ZXIgdGhlIG1hdGNoaW5nIHBp cGUsIG9yCj4gID4gPiBub3Q/Cj4gID4KPiAgPiBXaGVuIHlvdSByZXNldCBuZXQuaW5ldC5pcC5m dy5vbmVfcGFzcyB0byB6ZXJvLCBwYWNrZXRzIHJldHVybiBiYWNrCj4gID4gaW50byBpcGZ3IHRv IHRoZSBuZXh0IHJ1bGUgYWZ0ZXIgZHVtbXluZXQvbmV0Z3JhcGguIEFuZCBpZiB5b3UgaGF2ZQo+ ICA+IHNpbWlsYXIgcnVsZXMgcGFja2V0cyB3aWxsIGJlIHBhc3NlZCBpbnRvIGR1bW15bmV0L25l dGdyYXBoIGFnYWluLgo+ICA+Cj4gID4gVGhpcyBpcyBleGFtcGxlIGhvdyB0byBnZXQgZG91Ymxl IGZhdWx0IChmcm9tIG1haWwgYXJjaGl2ZSk6Cj4gID4KPgo+Cj4gamFhYSB3ZWxsIGJ1dCB0aGF0 IGlzIHRoZSBmYW1vdXMgYncgMCBleGFtcGxlIHdoaWNoIGlzIG5vdCB2YWxpZCwgYXMgYnkgaXRz ZWxmCj4gIGNlcnRhaW5seSBhbiBpbnZhbGlkIGNvbmZpZywgbm90IGNvbm5lY3RlZCB0byB0aGUg ZXhpc3RpbmcgcHJvYmxlbSB0aGUKPiAgcmVwb3J0ZXIgaGFzIEkgZ3Vlc3MKPgo+ICBKb8Ojbwo+ Cj4KPgo+Cj4gID4gaWZjb25maWcgZW0wIDE5Mi4xNjguMC4yLzI0Cj4gID4ga2xkbG9hZCBpcGZ3 Cj4gID4ga2xkbG9hZCBkdW1teW5ldAo+ICA+IHN5c2N0bCBuZXQuaW5ldC5pcC5mdy5vbmVfcGFz cz0wCj4gID4gaXBmdyBwaXBlIDIgY29uZmlnIGJ3IDAKPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBp cCBmcm9tIGFueSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBh bnkKPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiBpcGZ3IGFk ZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBm cm9tIGFueSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkK PiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAy IHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9t IGFueSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAg PiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAyIHBp cGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFu eSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiBp cGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAyIHBpcGUg MiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0 byBhbnkKPiAgPiBwaW5nIDE5Mi4xNjguMC4xCj4KPiAgLS0KPgo+Cj4gQXRlbmNpb3NhbWVudGUs IEouTS4KPiAgUmVzcG9uc8OhdmVsIFBsYW50w6NvIFNpdGUgU3VwcG9ydCBNYXRpawo+ICBJbmZv bWF0aWsgSW50ZXJuZXQgVGVjaG5vbG9neQo+ICAoMTgpMzU1MS44MTU1ICAoMTgpODExMi43MDA3 Cj4gIGh0dHA6Ly9pbmZvLm1hdGlrLmNvbS5icgo+Cj4KPgo+Cj4KPgo+Cj4gIEEgbWVuc2FnZW0g Zm9pIHNjYW5lYWRhIHBlbG8gc2lzdGVtYSBkZSBlLW1haWwgZSBwb2RlIHNlciBjb25zaWRlcmFk YSBzZWd1cmEuCj4gIFNlcnZpY2UgZm9ybmVjaWRvIHBlbG8gRGF0YWNlbnRlciBNYXRpayAgaHR0 cHM6Ly9kYXRhY2VudGVyLm1hdGlrLmNvbS5icgo+Cg== From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 14:57:58 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29DEA106564A for ; Mon, 24 Mar 2008 14:57:58 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp10.yandex.ru (smtp10.yandex.ru [213.180.223.92]) by mx1.freebsd.org (Postfix) with ESMTP id 66D5F8FC27 for ; Mon, 24 Mar 2008 14:57:57 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:64478 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S5866852AbYCXO5r (ORCPT ); Mon, 24 Mar 2008 17:57:47 +0300 X-Yandex-Spam: 1 X-Yandex-Front: smtp10 X-Yandex-TimeMark: 1206370667 X-MsgDayCount: 10 X-Comment: RFC 2476 MSA function at smtp10.yandex.ru logged sender identity as: bu7cher Message-ID: <47E7C169.8070101@yandex.ru> Date: Mon, 24 Mar 2008 17:57:45 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: AT Matik References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <200803240727.05809.asstec@matik.com.br> <47E78B92.4020907@yandex.ru> <200803241121.34059.asstec@matik.com.br> In-Reply-To: <200803241121.34059.asstec@matik.com.br> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Alexander Shulikov Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 14:57:58 -0000 AT Matik wrote: > jaaa well but that is the famous bw 0 example which is not valid, as by itself > certainly an invalid config, not connected to the existing problem the > reporter has I guess bw 0 is valid example. It's default value. It means unlimited bandwidth. -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 14:58:38 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D97EB1065671 for ; Mon, 24 Mar 2008 14:58:38 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 539108FC1F for ; Mon, 24 Mar 2008 14:58:38 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m2OEwckC054506; Mon, 24 Mar 2008 11:58:38 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: "Alexander Shulikov" Date: Mon, 24 Mar 2008 11:58:00 -0300 User-Agent: KMail/1.9.7 References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <200803241121.34059.asstec@matik.com.br> <18292fe60803240751w4b3afa31n5e8d469462da6175@mail.gmail.com> In-Reply-To: <18292fe60803240751w4b3afa31n5e8d469462da6175@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803241158.00240.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-ipfw@freebsd.org, bu7cher@yandex.ru Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 14:58:39 -0000 On Monday 24 March 2008 11:51:44 Alexander Shulikov wrote: > # sysctl -a | grep one_pass > net.inet.ip.fw.one_pass: 0 > > Yes - it eq 0. But I need it for next situation: all net I need shape > at one speed, but invididual ip addresses to another speed. > For example, > ipfw pipe 1 config bw 10Mbit/s queue 100 > ipfw pipe 2 config bw 10Mbit/s queue 100 > ipfw add pipe 1 ip from 192.168.1.0/24 to any > ipfw add pipe 2 ip from any to 192.168.1.0/24 > ipfw pipe 3 config bw 1Mbit/s queue 100 > ipfw pipe 4 config bw 1Mbit/s queue 100 > ipfw add pipe 3 ip from 192.168.1.1/32 to any > ipfw add pipe 4 ip from any to 192.168.1.1/32 that should work, I have similar setups running fine the /32 mask you should not need but I am missing the in/out definition in= =20 your rules > ...... > > > Also this configuration work in FreeBSD 6.2. (May be in 6.2 smaller call > tree?) > > 2008/3/24, AT Matik : > > On Monday 24 March 2008 08:08:02 Andrey V. Elsukov wrote: > > > AT Matik wrote: > > > > what do you mean? By setting to 0 the packages are not re-injected > > > > into the pipe but go through other existing rules after the matchi= ng > > > > pipe, or not? > > > > > > When you reset net.inet.ip.fw.one_pass to zero, packets return back > > > into ipfw to the next rule after dummynet/netgraph. And if you have > > > similar rules packets will be passed into dummynet/netgraph again. > > > > > > This is example how to get double fault (from mail archive): > > > > jaaa well but that is the famous bw 0 example which is not valid, as by > > itself certainly an invalid config, not connected to the existing probl= em > > the reporter has I guess > > > > Jo=C3=A3o > > > > > ifconfig em0 192.168.0.2/24 > > > kldload ipfw > > > kldload dummynet > > > sysctl net.inet.ip.fw.one_pass=3D0 > > > ipfw pipe 2 config bw 0 > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ipfw add 2 pipe 2 ip from any to any > > > ping 192.168.0.1 > > > > -- > > > > > > Atenciosamente, J.M. > > Respons=C3=A1vel Plant=C3=A3o Site Support Matik > > Infomatik Internet Technology > > (18)3551.8155 (18)8112.7007 > > http://info.matik.com.br > > > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > > segura. Service fornecido pelo Datacenter Matik=20 > > https://datacenter.matik.com.br =2D-=20 Atenciosamente, J.M. Respons=C3=A1vel Plant=C3=A3o Site Support Matik Infomatik Internet Technology (18)3551.8155 =C2=A0(18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 15:11:48 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E6431065677 for ; Mon, 24 Mar 2008 15:11:48 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7E9618FC3A for ; Mon, 24 Mar 2008 15:11:47 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so3917978fka.11 for ; Mon, 24 Mar 2008 08:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=7Ht3O9EVrvEU8qtHYbQ3XIgTpD3VBlC0+JnDCJXUToI=; b=P0nKyB71wYGnWoav8OJDuh9vHLC2WIsaSaEOVnwmKtd4gX3oXhNy36v29MAT3nW/CuMId1x5TOHv3n6hR7hnkRnONsrtpIW5OR3AaDGXqRjWxmXL7JTOHJIp12OLmZUMEVx0rM8oCkHZwgjAiAMZxgpi3XAgsOX9fv/AGi5S7xc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iEnQB1UiC4yj/ucAfafD++XSqakhnQ5dsrzmApDsB3GJFL9YX6YJdurGNA9KKahW2gMKxYyg+bBjx63FTaDwrl5mnjXl2cWROYMRUhKUccBQsqKSOo5m01qdx5FHQdFakhPN+UTV1YHMiiL4ATps58dl5Ai1ggXxoK7fYah+fyE= Received: by 10.82.170.2 with SMTP id s2mr17678204bue.30.1206371504286; Mon, 24 Mar 2008 08:11:44 -0700 (PDT) Received: by 10.82.154.1 with HTTP; Mon, 24 Mar 2008 08:11:44 -0700 (PDT) Message-ID: <18292fe60803240811j651decf7hd808373324f06948@mail.gmail.com> Date: Mon, 24 Mar 2008 17:11:44 +0200 From: "Alexander Shulikov" To: freebsd-ipfw@freebsd.org In-Reply-To: <200803241158.00240.asstec@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <200803241121.34059.asstec@matik.com.br> <18292fe60803240751w4b3afa31n5e8d469462da6175@mail.gmail.com> <200803241158.00240.asstec@matik.com.br> Cc: AT Matik , bu7cher@yandex.ru Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 15:11:48 -0000 SW4gcmVhbCBzY3JpcHQgSSBoYXZlIGluIGFuZCBvdXQuIEJ1dCBzb21lIGlwJ3MgZm9yIHRoZSBz YW1lIHNwZWVkIEkKYWRkIGluIHRhYmxlLCBhbmQgdGhlbiBkbzoKIyA1MTIvMTI4CiR7ZndjbWR9 IHBpcGUgMzU3IGNvbmZpZyBidyAxMjhLYml0L3MgcXVldWUgMTAwIG1hc2sgc3JjLWlwIDB4ZmZm ZmZmZmYKJHtmd2NtZH0gcGlwZSAzNTggY29uZmlnIGJ3IDUxMktiaXQvcyBxdWV1ZSAxMDAgbWFz ayBkc3QtaXAgMHhmZmZmZmZmZgoke2Z3Y21kfSBhZGQgcGlwZSAzNTcgaXAgZnJvbSAidGFibGUo MykiIHRvIGFueSBpbgoke2Z3Y21kfSBhZGQgcGlwZSAzNTggaXAgZnJvbSBhbnkgdG8gInRhYmxl KDMpIiBvdXQKCklQcyBmb3IgaW5kaXZpZHVhbCBzcGVlZCBhZGRlZCBhcyBpbiBleGFtcGxlIGlu IHByZXZpb3VzIGxldHRlciwgYnV0CndpdGggaW4vb3V0LgoKQnV0IHdoYXQgY2FuIEkgZG8gZm9y IHJlc29sdmUgdGhpcyBwcm9ibGVtLiBOb3cgSSBoYXZlIHNlcnZlciB3aXRoCkZyZWVCU0QgNi4y IGFuZCBjb3B5IG9mIHRoaXMgY29uZmlncyAtIGFuZCBhbGwgd29ya3MgZmluZS4gb19PCgoyMDA4 LzMvMjQsIEFUIE1hdGlrIDxhc3N0ZWNAbWF0aWsuY29tLmJyPjoKPiBPbiBNb25kYXkgMjQgTWFy Y2ggMjAwOCAxMTo1MTo0NCBBbGV4YW5kZXIgU2h1bGlrb3Ygd3JvdGU6Cj4gID4gIyBzeXNjdGwg LWEgfCBncmVwIG9uZV9wYXNzCj4gID4gbmV0LmluZXQuaXAuZncub25lX3Bhc3M6IDAKPiAgPgo+ ICA+IFllcyAtIGl0IGVxIDAuIEJ1dCBJIG5lZWQgaXQgZm9yIG5leHQgc2l0dWF0aW9uOiBhbGwg bmV0IEkgbmVlZCBzaGFwZQo+ICA+IGF0IG9uZSBzcGVlZCwgYnV0IGludmlkaWR1YWwgaXAgYWRk cmVzc2VzIHRvIGFub3RoZXIgc3BlZWQuCj4gID4gRm9yIGV4YW1wbGUsCj4gID4gaXBmdyBwaXBl IDEgY29uZmlnIGJ3IDEwTWJpdC9zIHF1ZXVlIDEwMAo+ICA+IGlwZncgcGlwZSAyIGNvbmZpZyBi dyAxME1iaXQvcyBxdWV1ZSAxMDAKPiAgPiBpcGZ3IGFkZCBwaXBlIDEgaXAgZnJvbSAxOTIuMTY4 LjEuMC8yNCB0byBhbnkKPiAgPiBpcGZ3IGFkZCBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gMTkyLjE2 OC4xLjAvMjQKPiAgPiBpcGZ3IHBpcGUgMyBjb25maWcgYncgMU1iaXQvcyBxdWV1ZSAxMDAKPiAg PiBpcGZ3IHBpcGUgNCBjb25maWcgYncgMU1iaXQvcyBxdWV1ZSAxMDAKPiAgPiBpcGZ3IGFkZCBw aXBlIDMgaXAgZnJvbSAxOTIuMTY4LjEuMS8zMiB0byBhbnkKPiAgPiBpcGZ3IGFkZCBwaXBlIDQg aXAgZnJvbSBhbnkgdG8gMTkyLjE2OC4xLjEvMzIKPgo+Cj4KPgo+IHRoYXQgc2hvdWxkIHdvcmss IEkgaGF2ZSBzaW1pbGFyIHNldHVwcyBydW5uaW5nIGZpbmUKPiAgdGhlIC8zMiBtYXNrIHlvdSBz aG91bGQgbm90IG5lZWQgYnV0IEkgYW0gbWlzc2luZyB0aGUgaW4vb3V0IGRlZmluaXRpb24gaW4K PiAgeW91ciBydWxlcwo+Cj4KPgo+Cj4KPiAgPiAuLi4uLi4KPiAgPgo+ICA+Cj4gID4gQWxzbyB0 aGlzIGNvbmZpZ3VyYXRpb24gd29yayBpbiBGcmVlQlNEIDYuMi4gKE1heSBiZSBpbiA2LjIgc21h bGxlciBjYWxsCj4gID4gdHJlZT8pCj4gID4KPiAgPiAyMDA4LzMvMjQsIEFUIE1hdGlrIDxhc3N0 ZWNAbWF0aWsuY29tLmJyPjoKPiAgPiA+IE9uIE1vbmRheSAyNCBNYXJjaCAyMDA4IDA4OjA4OjAy IEFuZHJleSBWLiBFbHN1a292IHdyb3RlOgo+ICA+ID4gID4gQVQgTWF0aWsgd3JvdGU6Cj4gID4g PiAgPiA+IHdoYXQgZG8geW91IG1lYW4/IEJ5IHNldHRpbmcgdG8gMCB0aGUgcGFja2FnZXMgYXJl IG5vdCByZS1pbmplY3RlZAo+ICA+ID4gID4gPiBpbnRvIHRoZSBwaXBlIGJ1dCBnbyB0aHJvdWdo IG90aGVyIGV4aXN0aW5nIHJ1bGVzIGFmdGVyIHRoZSBtYXRjaGluZwo+ICA+ID4gID4gPiBwaXBl LCBvciBub3Q/Cj4gID4gPiAgPgo+ICA+ID4gID4gV2hlbiB5b3UgcmVzZXQgbmV0LmluZXQuaXAu Zncub25lX3Bhc3MgdG8gemVybywgcGFja2V0cyByZXR1cm4gYmFjawo+ICA+ID4gID4gaW50byBp cGZ3IHRvIHRoZSBuZXh0IHJ1bGUgYWZ0ZXIgZHVtbXluZXQvbmV0Z3JhcGguIEFuZCBpZiB5b3Ug aGF2ZQo+ICA+ID4gID4gc2ltaWxhciBydWxlcyBwYWNrZXRzIHdpbGwgYmUgcGFzc2VkIGludG8g ZHVtbXluZXQvbmV0Z3JhcGggYWdhaW4uCj4gID4gPiAgPgo+ICA+ID4gID4gVGhpcyBpcyBleGFt cGxlIGhvdyB0byBnZXQgZG91YmxlIGZhdWx0IChmcm9tIG1haWwgYXJjaGl2ZSk6Cj4gID4gPgo+ ICA+ID4gamFhYSB3ZWxsIGJ1dCB0aGF0IGlzIHRoZSBmYW1vdXMgYncgMCBleGFtcGxlIHdoaWNo IGlzIG5vdCB2YWxpZCwgYXMgYnkKPiAgPiA+IGl0c2VsZiBjZXJ0YWlubHkgYW4gaW52YWxpZCBj b25maWcsIG5vdCBjb25uZWN0ZWQgdG8gdGhlIGV4aXN0aW5nIHByb2JsZW0KPiAgPiA+IHRoZSBy ZXBvcnRlciBoYXMgSSBndWVzcwo+ICA+ID4KPiAgPiA+ICBKb8Ojbwo+ICA+ID4KPiAgPiA+ICA+ IGlmY29uZmlnIGVtMCAxOTIuMTY4LjAuMi8yNAo+ICA+ID4gID4ga2xkbG9hZCBpcGZ3Cj4gID4g PiAgPiBrbGRsb2FkIGR1bW15bmV0Cj4gID4gPiAgPiBzeXNjdGwgbmV0LmluZXQuaXAuZncub25l X3Bhc3M9MAo+ICA+ID4gID4gaXBmdyBwaXBlIDIgY29uZmlnIGJ3IDAKPiAgPiA+ICA+IGlwZncg YWRkIDIgcGlwZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBl IDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9t IGFueSB0byBhbnkKPiAgPiA+ICA+IGlwZncgYWRkIDIgcGlwZSAyIGlwIGZyb20gYW55IHRvIGFu eQo+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gPiAg PiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiA+ICA+IGlwZncgYWRk IDIgcGlwZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIg aXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFu eSB0byBhbnkKPiAgPiA+ICA+IGlwZncgYWRkIDIgcGlwZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gPiAgPiBp cGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiA+ICA+IGlwZncgYWRkIDIg cGlwZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAg ZnJvbSBhbnkgdG8gYW55Cj4gID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0 byBhbnkKPiAgPiA+ICA+IGlwZncgYWRkIDIgcGlwZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gPiAgPiBwaW5n IDE5Mi4xNjguMC4xCj4gID4gPgo+ICA+ID4gIC0tCj4gID4gPgo+ICA+ID4KPiAgPiA+IEF0ZW5j aW9zYW1lbnRlLCBKLk0uCj4gID4gPiAgUmVzcG9uc8OhdmVsIFBsYW50w6NvIFNpdGUgU3VwcG9y dCBNYXRpawo+ICA+ID4gIEluZm9tYXRpayBJbnRlcm5ldCBUZWNobm9sb2d5Cj4gID4gPiAgKDE4 KTM1NTEuODE1NSAgKDE4KTgxMTIuNzAwNwo+ICA+ID4gIGh0dHA6Ly9pbmZvLm1hdGlrLmNvbS5i cgo+ICA+ID4KPiAgPiA+Cj4gID4gPgo+ICA+ID4KPiAgPiA+Cj4gID4gPgo+ICA+ID4KPiAgPiA+ ICBBIG1lbnNhZ2VtIGZvaSBzY2FuZWFkYSBwZWxvIHNpc3RlbWEgZGUgZS1tYWlsIGUgcG9kZSBz ZXIgY29uc2lkZXJhZGEKPiAgPiA+IHNlZ3VyYS4gU2VydmljZSBmb3JuZWNpZG8gcGVsbyBEYXRh Y2VudGVyIE1hdGlrCj4gID4gPiBodHRwczovL2RhdGFjZW50ZXIubWF0aWsuY29tLmJyCj4KPgo+ IC0tCj4KPgo+ICBBdGVuY2lvc2FtZW50ZSwgSi5NLgo+ICBSZXNwb25zw6F2ZWwgUGxhbnTDo28g U2l0ZSBTdXBwb3J0IE1hdGlrCj4gIEluZm9tYXRpayBJbnRlcm5ldCBUZWNobm9sb2d5Cj4gICgx OCkzNTUxLjgxNTUgICgxOCk4MTEyLjcwMDcKPiAgaHR0cDovL2luZm8ubWF0aWsuY29tLmJyCj4K Pgo+Cj4KPgo+Cj4KPiAgQSBtZW5zYWdlbSBmb2kgc2NhbmVhZGEgcGVsbyBzaXN0ZW1hIGRlIGUt bWFpbCBlIHBvZGUgc2VyIGNvbnNpZGVyYWRhIHNlZ3VyYS4KPiAgU2VydmljZSBmb3JuZWNpZG8g cGVsbyBEYXRhY2VudGVyIE1hdGlrICBodHRwczovL2RhdGFjZW50ZXIubWF0aWsuY29tLmJyCj4K From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 15:46:43 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02BBC1065673 for ; Mon, 24 Mar 2008 15:46:43 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 684CC8FC38 for ; Mon, 24 Mar 2008 15:46:42 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2562830fgg.35 for ; Mon, 24 Mar 2008 08:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=J/gvWQgmbXLpf61zbHpKatAT0QueNV4E6ixUKuttV+4=; b=tuYk7e+scgjOFPpgs6gAFluU9/ql+u/ztRtG5gEbzQz2oW8NRSVXx7QQFAzfwLH6qeegfHlDQrNX2eBk4bZGESfteEBD+aXV+1Bw/+czV0gvjCx+A8P8ZmHCb3Mmkhyx10K2M0Qe4rq+jVsV4U2vbM1OrZjFdyQFE/1PYqktK/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kf7KUG7XTAbhkSY1M1abCn2XiTJZ/6zo9LTl+VO8JkrfUsDjuDzIarG46boFOLyLrMWUV0CCn33++IwpSsKSVJFRI+fI5wPH8aT8mINCRlyNqjPDL95Cn7bhf1vhYE1AtTdAy772ZQ7iUMj9QEpgdixV7uRyZwstz/AbIBfKq1k= Received: by 10.82.124.10 with SMTP id w10mr17842281buc.18.1206373601325; Mon, 24 Mar 2008 08:46:41 -0700 (PDT) Received: by 10.82.154.1 with HTTP; Mon, 24 Mar 2008 08:46:41 -0700 (PDT) Message-ID: <18292fe60803240846i7095a367lfe7a104e32210ef1@mail.gmail.com> Date: Mon, 24 Mar 2008 17:46:41 +0200 From: "Alexander Shulikov" To: freebsd-ipfw@freebsd.org In-Reply-To: <18292fe60803240811j651decf7hd808373324f06948@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <200803241121.34059.asstec@matik.com.br> <18292fe60803240751w4b3afa31n5e8d469462da6175@mail.gmail.com> <200803241158.00240.asstec@matik.com.br> <18292fe60803240811j651decf7hd808373324f06948@mail.gmail.com> Cc: AT Matik , bu7cher@yandex.ru Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 15:46:43 -0000 SW50ZXJlc3RpbmcgY2hhbmdlbG9nIGluIGN2czoKClJldmlzaW9uIDEuMTE0OiBkb3dubG9hZCAt IHZpZXc6IHRleHQsIG1hcmt1cCwgYW5ub3RhdGVkIC0gc2VsZWN0IGZvciBkaWZmcwpUdWUgRGVj IDI1IDA5OjM2OjUxIDIwMDcgVVRDICgyIG1vbnRocywgNCB3ZWVrcyBhZ28pIGJ5IG9sZWcKQnJh bmNoZXM6IE1BSU4KRGlmZiB0bzogcHJldmlvdXMgMS4xMTM6IHByZWZlcnJlZCwgY29sb3JlZApD aGFuZ2VzIHNpbmNlIHJldmlzaW9uIDEuMTEzOiArMjIgLTcgbGluZXMKCldvcmthcm91bmQgcC0+ bnVtYnl0ZXMgb3ZlcmZsb3csIHdoaWNoIGNhbiByZXN1bHQgaW4gaW5maW5pdGUgbG9vcCBpbnNp ZGUKZHVtbXluZXQgbW9kdWxlIChwcmVyZXF1aXNpdGUgaXMgdXNpbmcgcXVldWVzIHdpdGggImZh dCIgcGlwZSkuCgpQUjoJCWtlcm4vMTEzNTQ4CgoKMjAwOC8zLzI0LCBBbGV4YW5kZXIgU2h1bGlr b3YgPHNodWxpa292QGdtYWlsLmNvbT46Cj4gSW4gcmVhbCBzY3JpcHQgSSBoYXZlIGluIGFuZCBv dXQuIEJ1dCBzb21lIGlwJ3MgZm9yIHRoZSBzYW1lIHNwZWVkIEkKPiAgYWRkIGluIHRhYmxlLCBh bmQgdGhlbiBkbzoKPiAgIyA1MTIvMTI4Cj4gICR7ZndjbWR9IHBpcGUgMzU3IGNvbmZpZyBidyAx MjhLYml0L3MgcXVldWUgMTAwIG1hc2sgc3JjLWlwIDB4ZmZmZmZmZmYKPiAgJHtmd2NtZH0gcGlw ZSAzNTggY29uZmlnIGJ3IDUxMktiaXQvcyBxdWV1ZSAxMDAgbWFzayBkc3QtaXAgMHhmZmZmZmZm Zgo+ICAke2Z3Y21kfSBhZGQgcGlwZSAzNTcgaXAgZnJvbSAidGFibGUoMykiIHRvIGFueSBpbgo+ ICAke2Z3Y21kfSBhZGQgcGlwZSAzNTggaXAgZnJvbSBhbnkgdG8gInRhYmxlKDMpIiBvdXQKPgo+ ICBJUHMgZm9yIGluZGl2aWR1YWwgc3BlZWQgYWRkZWQgYXMgaW4gZXhhbXBsZSBpbiBwcmV2aW91 cyBsZXR0ZXIsIGJ1dAo+ICB3aXRoIGluL291dC4KPgo+ICBCdXQgd2hhdCBjYW4gSSBkbyBmb3Ig cmVzb2x2ZSB0aGlzIHByb2JsZW0uIE5vdyBJIGhhdmUgc2VydmVyIHdpdGgKPiAgRnJlZUJTRCA2 LjIgYW5kIGNvcHkgb2YgdGhpcyBjb25maWdzIC0gYW5kIGFsbCB3b3JrcyBmaW5lLiBvX08KPgo+ Cj4gIDIwMDgvMy8yNCwgQVQgTWF0aWsgPGFzc3RlY0BtYXRpay5jb20uYnI+Ogo+ICA+IE9uIE1v bmRheSAyNCBNYXJjaCAyMDA4IDExOjUxOjQ0IEFsZXhhbmRlciBTaHVsaWtvdiB3cm90ZToKPiAg PiAgPiAjIHN5c2N0bCAtYSB8IGdyZXAgb25lX3Bhc3MKPiAgPiAgPiBuZXQuaW5ldC5pcC5mdy5v bmVfcGFzczogMAo+ICA+ICA+Cj4gID4gID4gWWVzIC0gaXQgZXEgMC4gQnV0IEkgbmVlZCBpdCBm b3IgbmV4dCBzaXR1YXRpb246IGFsbCBuZXQgSSBuZWVkIHNoYXBlCj4gID4gID4gYXQgb25lIHNw ZWVkLCBidXQgaW52aWRpZHVhbCBpcCBhZGRyZXNzZXMgdG8gYW5vdGhlciBzcGVlZC4KPiAgPiAg PiBGb3IgZXhhbXBsZSwKPiAgPiAgPiBpcGZ3IHBpcGUgMSBjb25maWcgYncgMTBNYml0L3MgcXVl dWUgMTAwCj4gID4gID4gaXBmdyBwaXBlIDIgY29uZmlnIGJ3IDEwTWJpdC9zIHF1ZXVlIDEwMAo+ ICA+ICA+IGlwZncgYWRkIHBpcGUgMSBpcCBmcm9tIDE5Mi4xNjguMS4wLzI0IHRvIGFueQo+ICA+ ICA+IGlwZncgYWRkIHBpcGUgMiBpcCBmcm9tIGFueSB0byAxOTIuMTY4LjEuMC8yNAo+ICA+ICA+ IGlwZncgcGlwZSAzIGNvbmZpZyBidyAxTWJpdC9zIHF1ZXVlIDEwMAo+ICA+ICA+IGlwZncgcGlw ZSA0IGNvbmZpZyBidyAxTWJpdC9zIHF1ZXVlIDEwMAo+ICA+ICA+IGlwZncgYWRkIHBpcGUgMyBp cCBmcm9tIDE5Mi4xNjguMS4xLzMyIHRvIGFueQo+ICA+ICA+IGlwZncgYWRkIHBpcGUgNCBpcCBm cm9tIGFueSB0byAxOTIuMTY4LjEuMS8zMgo+ICA+Cj4gID4KPiAgPgo+ICA+Cj4gID4gdGhhdCBz aG91bGQgd29yaywgSSBoYXZlIHNpbWlsYXIgc2V0dXBzIHJ1bm5pbmcgZmluZQo+ICA+ICB0aGUg LzMyIG1hc2sgeW91IHNob3VsZCBub3QgbmVlZCBidXQgSSBhbSBtaXNzaW5nIHRoZSBpbi9vdXQg ZGVmaW5pdGlvbiBpbgo+ICA+ICB5b3VyIHJ1bGVzCj4gID4KPiAgPgo+ICA+Cj4gID4KPiAgPgo+ ICA+ICA+IC4uLi4uLgo+ICA+ICA+Cj4gID4gID4KPiAgPiAgPiBBbHNvIHRoaXMgY29uZmlndXJh dGlvbiB3b3JrIGluIEZyZWVCU0QgNi4yLiAoTWF5IGJlIGluIDYuMiBzbWFsbGVyIGNhbGwKPiAg PiAgPiB0cmVlPykKPiAgPiAgPgo+ICA+ICA+IDIwMDgvMy8yNCwgQVQgTWF0aWsgPGFzc3RlY0Bt YXRpay5jb20uYnI+Ogo+ICA+ICA+ID4gT24gTW9uZGF5IDI0IE1hcmNoIDIwMDggMDg6MDg6MDIg QW5kcmV5IFYuIEVsc3Vrb3Ygd3JvdGU6Cj4gID4gID4gPiAgPiBBVCBNYXRpayB3cm90ZToKPiAg PiAgPiA+ICA+ID4gd2hhdCBkbyB5b3UgbWVhbj8gQnkgc2V0dGluZyB0byAwIHRoZSBwYWNrYWdl cyBhcmUgbm90IHJlLWluamVjdGVkCj4gID4gID4gPiAgPiA+IGludG8gdGhlIHBpcGUgYnV0IGdv IHRocm91Z2ggb3RoZXIgZXhpc3RpbmcgcnVsZXMgYWZ0ZXIgdGhlIG1hdGNoaW5nCj4gID4gID4g PiAgPiA+IHBpcGUsIG9yIG5vdD8KPiAgPiAgPiA+ICA+Cj4gID4gID4gPiAgPiBXaGVuIHlvdSBy ZXNldCBuZXQuaW5ldC5pcC5mdy5vbmVfcGFzcyB0byB6ZXJvLCBwYWNrZXRzIHJldHVybiBiYWNr Cj4gID4gID4gPiAgPiBpbnRvIGlwZncgdG8gdGhlIG5leHQgcnVsZSBhZnRlciBkdW1teW5ldC9u ZXRncmFwaC4gQW5kIGlmIHlvdSBoYXZlCj4gID4gID4gPiAgPiBzaW1pbGFyIHJ1bGVzIHBhY2tl dHMgd2lsbCBiZSBwYXNzZWQgaW50byBkdW1teW5ldC9uZXRncmFwaCBhZ2Fpbi4KPiAgPiAgPiA+ ICA+Cj4gID4gID4gPiAgPiBUaGlzIGlzIGV4YW1wbGUgaG93IHRvIGdldCBkb3VibGUgZmF1bHQg KGZyb20gbWFpbCBhcmNoaXZlKToKPiAgPiAgPiA+Cj4gID4gID4gPiBqYWFhIHdlbGwgYnV0IHRo YXQgaXMgdGhlIGZhbW91cyBidyAwIGV4YW1wbGUgd2hpY2ggaXMgbm90IHZhbGlkLCBhcyBieQo+ ICA+ICA+ID4gaXRzZWxmIGNlcnRhaW5seSBhbiBpbnZhbGlkIGNvbmZpZywgbm90IGNvbm5lY3Rl ZCB0byB0aGUgZXhpc3RpbmcgcHJvYmxlbQo+ICA+ICA+ID4gdGhlIHJlcG9ydGVyIGhhcyBJIGd1 ZXNzCj4gID4gID4gPgo+ICA+ICA+ID4gIEpvw6NvCj4gID4gID4gPgo+ICA+ICA+ID4gID4gaWZj b25maWcgZW0wIDE5Mi4xNjguMC4yLzI0Cj4gID4gID4gPiAgPiBrbGRsb2FkIGlwZncKPiAgPiAg PiA+ICA+IGtsZGxvYWQgZHVtbXluZXQKPiAgPiAgPiA+ICA+IHN5c2N0bCBuZXQuaW5ldC5pcC5m dy5vbmVfcGFzcz0wCj4gID4gID4gPiAgPiBpcGZ3IHBpcGUgMiBjb25maWcgYncgMAo+ICA+ICA+ ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gID4gPiAgPiBp cGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiAgPiA+ICA+IGlwZncgYWRk IDIgcGlwZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBl IDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBm cm9tIGFueSB0byBhbnkKPiAgPiAgPiA+ICA+IGlwZncgYWRkIDIgcGlwZSAyIGlwIGZyb20gYW55 IHRvIGFueQo+ICA+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55 Cj4gID4gID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiAg PiA+ICA+IGlwZncgYWRkIDIgcGlwZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ICA+ID4gID4g aXBmdyBhZGQgMiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gID4gPiAgPiBpcGZ3IGFk ZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiAgPiA+ICA+IGlwZncgYWRkIDIgcGlw ZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAg ZnJvbSBhbnkgdG8gYW55Cj4gID4gID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFu eSB0byBhbnkKPiAgPiAgPiA+ICA+IGlwZncgYWRkIDIgcGlwZSAyIGlwIGZyb20gYW55IHRvIGFu eQo+ICA+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4g ID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiAgPiA+ICA+ IHBpbmcgMTkyLjE2OC4wLjEKPiAgPiAgPiA+Cj4gID4gID4gPiAgLS0KPiAgPiAgPiA+Cj4gID4g ID4gPgo+ICA+ICA+ID4gQXRlbmNpb3NhbWVudGUsIEouTS4KPiAgPiAgPiA+ICBSZXNwb25zw6F2 ZWwgUGxhbnTDo28gU2l0ZSBTdXBwb3J0IE1hdGlrCj4gID4gID4gPiAgSW5mb21hdGlrIEludGVy bmV0IFRlY2hub2xvZ3kKPiAgPiAgPiA+ICAoMTgpMzU1MS44MTU1ICAoMTgpODExMi43MDA3Cj4g ID4gID4gPiAgaHR0cDovL2luZm8ubWF0aWsuY29tLmJyCj4gID4gID4gPgo+ICA+ICA+ID4KPiAg PiAgPiA+Cj4gID4gID4gPgo+ICA+ICA+ID4KPiAgPiAgPiA+Cj4gID4gID4gPgo+ICA+ICA+ID4g IEEgbWVuc2FnZW0gZm9pIHNjYW5lYWRhIHBlbG8gc2lzdGVtYSBkZSBlLW1haWwgZSBwb2RlIHNl ciBjb25zaWRlcmFkYQo+ICA+ICA+ID4gc2VndXJhLiBTZXJ2aWNlIGZvcm5lY2lkbyBwZWxvIERh dGFjZW50ZXIgTWF0aWsKPiAgPiAgPiA+IGh0dHBzOi8vZGF0YWNlbnRlci5tYXRpay5jb20uYnIK PiAgPgo+ICA+Cj4gID4gLS0KPiAgPgo+ICA+Cj4gID4gIEF0ZW5jaW9zYW1lbnRlLCBKLk0uCj4g ID4gIFJlc3BvbnPDoXZlbCBQbGFudMOjbyBTaXRlIFN1cHBvcnQgTWF0aWsKPiAgPiAgSW5mb21h dGlrIEludGVybmV0IFRlY2hub2xvZ3kKPiAgPiAgKDE4KTM1NTEuODE1NSAgKDE4KTgxMTIuNzAw Nwo+ICA+ICBodHRwOi8vaW5mby5tYXRpay5jb20uYnIKPiAgPgo+ICA+Cj4gID4KPiAgPgo+ICA+ Cj4gID4KPiAgPgo+ICA+ICBBIG1lbnNhZ2VtIGZvaSBzY2FuZWFkYSBwZWxvIHNpc3RlbWEgZGUg ZS1tYWlsIGUgcG9kZSBzZXIgY29uc2lkZXJhZGEgc2VndXJhLgo+ICA+ICBTZXJ2aWNlIGZvcm5l Y2lkbyBwZWxvIERhdGFjZW50ZXIgTWF0aWsgIGh0dHBzOi8vZGF0YWNlbnRlci5tYXRpay5jb20u YnIKPiAgPgo+Cg== From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 17:12:30 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4A331065671 for ; Mon, 24 Mar 2008 17:12:30 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id DBD1A8FC21 for ; Mon, 24 Mar 2008 17:12:29 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m2OHCVs4065089; Mon, 24 Mar 2008 14:12:31 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Mon, 24 Mar 2008 14:11:51 -0300 User-Agent: KMail/1.9.7 References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <200803241158.00240.asstec@matik.com.br> <18292fe60803240811j651decf7hd808373324f06948@mail.gmail.com> In-Reply-To: <18292fe60803240811j651decf7hd808373324f06948@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803241411.51930.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: bu7cher@yandex.ru, Alexander Shulikov Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 17:12:30 -0000 On Monday 24 March 2008 12:11:44 Alexander Shulikov wrote: > In real script I have in and out. But some ip's for the same speed I > add in table, and then do: > # 512/128 > ${fwcmd} pipe 357 config bw 128Kbit/s queue 100 mask src-ip 0xffffffff > ${fwcmd} pipe 358 config bw 512Kbit/s queue 100 mask dst-ip 0xffffffff > ${fwcmd} add pipe 357 ip from "table(3)" to any in > ${fwcmd} add pipe 358 ip from any to "table(3)" out > > IPs for individual speed added as in example in previous letter, but > with in/out. > > But what can I do for resolve this problem. Now I have server with > FreeBSD 6.2 and copy of this configs - and all works fine. o_O > well I use the above different, first I define the pipe and second the bw anyway I do not use tables also seems you use long queues so may be you like to tune=20 net.inet.ip.intr_queue_maxlen and mbuf of your machine > 2008/3/24, AT Matik : > > On Monday 24 March 2008 11:51:44 Alexander Shulikov wrote: > > > # sysctl -a | grep one_pass > > > net.inet.ip.fw.one_pass: 0 > > > > > > Yes - it eq 0. But I need it for next situation: all net I need shape > > > at one speed, but invididual ip addresses to another speed. > > > For example, > > > ipfw pipe 1 config bw 10Mbit/s queue 100 > > > ipfw pipe 2 config bw 10Mbit/s queue 100 > > > ipfw add pipe 1 ip from 192.168.1.0/24 to any > > > ipfw add pipe 2 ip from any to 192.168.1.0/24 > > > ipfw pipe 3 config bw 1Mbit/s queue 100 > > > ipfw pipe 4 config bw 1Mbit/s queue 100 > > > ipfw add pipe 3 ip from 192.168.1.1/32 to any > > > ipfw add pipe 4 ip from any to 192.168.1.1/32 > > > > that should work, I have similar setups running fine > > the /32 mask you should not need but I am missing the in/out definition > > in your rules > > > > > ...... > > > > > > > > > Also this configuration work in FreeBSD 6.2. (May be in 6.2 smaller > > > call tree?) > > > > > > 2008/3/24, AT Matik : > > > > On Monday 24 March 2008 08:08:02 Andrey V. Elsukov wrote: > > > > > AT Matik wrote: > > > > > > what do you mean? By setting to 0 the packages are not > > > > > > re-injected into the pipe but go through other existing rules > > > > > > after the matching pipe, or not? > > > > > > > > > > When you reset net.inet.ip.fw.one_pass to zero, packets return > > > > > back into ipfw to the next rule after dummynet/netgraph. And if > > > > > you have similar rules packets will be passed into > > > > > dummynet/netgraph again. > > > > > > > > > > This is example how to get double fault (from mail archive): > > > > > > > > jaaa well but that is the famous bw 0 example which is not valid, = as > > > > by itself certainly an invalid config, not connected to the existi= ng > > > > problem the reporter has I guess > > > > > > > > Jo=E3o > > > > > > > > > ifconfig em0 192.168.0.2/24 > > > > > kldload ipfw > > > > > kldload dummynet > > > > > sysctl net.inet.ip.fw.one_pass=3D0 > > > > > ipfw pipe 2 config bw 0 > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > ping 192.168.0.1 > > > > > > > > -- > > > > > > > > > > > > Atenciosamente, J.M. > > > > Respons=E1vel Plant=E3o Site Support Matik > > > > Infomatik Internet Technology > > > > (18)3551.8155 (18)8112.7007 > > > > http://info.matik.com.br > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser > > > > considerada segura. Service fornecido pelo Datacenter Matik > > > > https://datacenter.matik.com.br > > > > -- > > > > > > Atenciosamente, J.M. > > Respons=E1vel Plant=E3o Site Support Matik > > Infomatik Internet Technology > > (18)3551.8155 (18)8112.7007 > > http://info.matik.com.br > > > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > > segura. Service fornecido pelo Datacenter Matik=20 > > https://datacenter.matik.com.br =2D-=20 Atenciosamente, J.M. Respons=E1vel Plant=E3o Site Support Matik Infomatik Internet Technology (18)3551.8155 =A0(18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 17:33:59 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B5FF1065671 for ; Mon, 24 Mar 2008 17:33:59 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAC08FC23 for ; Mon, 24 Mar 2008 17:33:57 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m2OHXwn0066674; Mon, 24 Mar 2008 14:33:58 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: "Alexander Shulikov" Date: Mon, 24 Mar 2008 14:33:18 -0300 User-Agent: KMail/1.9.7 References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <18292fe60803240811j651decf7hd808373324f06948@mail.gmail.com> <18292fe60803240846i7095a367lfe7a104e32210ef1@mail.gmail.com> In-Reply-To: <18292fe60803240846i7095a367lfe7a104e32210ef1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803241433.18898.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-ipfw@freebsd.org, bu7cher@yandex.ru Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 17:33:59 -0000 On Monday 24 March 2008 12:46:41 Alexander Shulikov wrote: > Interesting changelog in cvs: > > Revision 1.114: download - view: text, markup, annotated - select for dif= fs > Tue Dec 25 09:36:51 2007 UTC (2 months, 4 weeks ago) by oleg > Branches: MAIN > Diff to: previous 1.113: preferred, colored > Changes since revision 1.113: +22 -7 lines > > Workaround p->numbytes overflow, which can result in infinite loop inside > dummynet module (prerequisite is using queues with "fat" pipe). > > PR: kern/113548 nice, this was in december right and after this date the problem still ocur= res=20 with dynamic pipes (mask src|dst-ip 0xfffffff) > > 2008/3/24, Alexander Shulikov : > > In real script I have in and out. But some ip's for the same speed I > > add in table, and then do: > > # 512/128 > > ${fwcmd} pipe 357 config bw 128Kbit/s queue 100 mask src-ip 0xffffffff > > ${fwcmd} pipe 358 config bw 512Kbit/s queue 100 mask dst-ip 0xffffffff > > ${fwcmd} add pipe 357 ip from "table(3)" to any in > > ${fwcmd} add pipe 358 ip from any to "table(3)" out > > > > IPs for individual speed added as in example in previous letter, but > > with in/out. > > > > But what can I do for resolve this problem. Now I have server with > > FreeBSD 6.2 and copy of this configs - and all works fine. o_O > > > > 2008/3/24, AT Matik : > > > On Monday 24 March 2008 11:51:44 Alexander Shulikov wrote: > > > > # sysctl -a | grep one_pass > > > > net.inet.ip.fw.one_pass: 0 > > > > > > > > Yes - it eq 0. But I need it for next situation: all net I need > > > > shape at one speed, but invididual ip addresses to another speed. > > > > For example, > > > > ipfw pipe 1 config bw 10Mbit/s queue 100 > > > > ipfw pipe 2 config bw 10Mbit/s queue 100 > > > > ipfw add pipe 1 ip from 192.168.1.0/24 to any > > > > ipfw add pipe 2 ip from any to 192.168.1.0/24 > > > > ipfw pipe 3 config bw 1Mbit/s queue 100 > > > > ipfw pipe 4 config bw 1Mbit/s queue 100 > > > > ipfw add pipe 3 ip from 192.168.1.1/32 to any > > > > ipfw add pipe 4 ip from any to 192.168.1.1/32 > > > > > > that should work, I have similar setups running fine > > > the /32 mask you should not need but I am missing the in/out > > > definition in your rules > > > > > > > ...... > > > > > > > > > > > > Also this configuration work in FreeBSD 6.2. (May be in 6.2 small= er > > > > call tree?) > > > > > > > > 2008/3/24, AT Matik : > > > > > On Monday 24 March 2008 08:08:02 Andrey V. Elsukov wrote: > > > > > > AT Matik wrote: > > > > > > > what do you mean? By setting to 0 the packages are not > > > > > > > re-injected into the pipe but go through other existing > > > > > > > rules after the matching pipe, or not? > > > > > > > > > > > > When you reset net.inet.ip.fw.one_pass to zero, packets retu= rn > > > > > > back into ipfw to the next rule after dummynet/netgraph. And > > > > > > if you have similar rules packets will be passed into > > > > > > dummynet/netgraph again. > > > > > > > > > > > > This is example how to get double fault (from mail archive): > > > > > > > > > > jaaa well but that is the famous bw 0 example which is not vali= d, > > > > > as by itself certainly an invalid config, not connected to the > > > > > existing problem the reporter has I guess > > > > > > > > > > Jo=C3=A3o > > > > > > > > > > > ifconfig em0 192.168.0.2/24 > > > > > > kldload ipfw > > > > > > kldload dummynet > > > > > > sysctl net.inet.ip.fw.one_pass=3D0 > > > > > > ipfw pipe 2 config bw 0 > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > ping 192.168.0.1 > > > > > > > > > > -- > > > > > > > > > > > > > > > Atenciosamente, J.M. > > > > > Respons=C3=A1vel Plant=C3=A3o Site Support Matik > > > > > Infomatik Internet Technology > > > > > (18)3551.8155 (18)8112.7007 > > > > > http://info.matik.com.br > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser > > > > > considerada segura. Service fornecido pelo Datacenter Matik > > > > > https://datacenter.matik.com.br > > > > > > -- > > > > > > > > > Atenciosamente, J.M. > > > Respons=C3=A1vel Plant=C3=A3o Site Support Matik > > > Infomatik Internet Technology > > > (18)3551.8155 (18)8112.7007 > > > http://info.matik.com.br > > > > > > > > > > > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considera= da > > > segura. Service fornecido pelo Datacenter Matik=20 > > > https://datacenter.matik.com.br =2D-=20 Atenciosamente, J.M. Respons=C3=A1vel Plant=C3=A3o Site Support Matik Infomatik Internet Technology (18)3551.8155 =C2=A0(18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 17:53:40 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B19F1065672 for ; Mon, 24 Mar 2008 17:53:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id D97B48FC1B for ; Mon, 24 Mar 2008 17:53:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 24 Mar 2008 13:34:16 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id BB3C82D6004; Mon, 24 Mar 2008 10:53:38 -0700 (PDT) Message-ID: <47E7EAA8.7020101@elischer.org> Date: Mon, 24 Mar 2008 10:53:44 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: araujo@FreeBSD.org References: <47E79636.1000909@FreeBSD.org> In-Reply-To: <47E79636.1000909@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vadim_nuclight@mail.ru, freebsd-ipfw@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 17:53:40 -0000 here are some of my ideas for ipfw changes: 1/ redo locking so that packets do not have to get locks on the structure... I have several ideas on this 2/ allow separate firewalls to be used at different parts of the network stack (i.e allow multiple taboe sto co-exist) 3/ possibly keeping per CPU stats.. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 19:08:14 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B5EE106566B for ; Mon, 24 Mar 2008 19:08:14 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4A02B8FC1B for ; Mon, 24 Mar 2008 19:08:12 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so4024902fka.11 for ; Mon, 24 Mar 2008 12:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=tBkzDhcdedU3TuMStrsTcQyKcOViiD5l4c8cvDYvlV8=; b=gzpE+i0ELnY9U6kCV2N7/lYUev9xdK/1DtJQTOAld2PwW0azv5v8vJ4IG7WtiNr4eH27E+A28HR0wxboqqyWFDR5sSF7lP8OX5skjb5yFt1clp04gpBl1FrwsnaVkFY5HlNtBVMyyjtPxctHBRqz9DxypE/A1tFyeSDs9bgeFpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l7vKYHGVT6NBf7yAO/N+uwcPb+dP8iIQFF4qZeFSfv3SKgBt3PO3S8TaEJhkgmCWy2g1Mdn9GhGn3AV/jKmINRiSODWI0Q3YkudbzCoZ5N02bXjBsLH3W2qSQ6V/9PFFvWpwAfde9yggE8yEuBCnBkNibU1nt/IaDQ1QhXkZJ90= Received: by 10.82.115.8 with SMTP id n8mr16136099buc.10.1206385690695; Mon, 24 Mar 2008 12:08:10 -0700 (PDT) Received: by 10.82.154.1 with HTTP; Mon, 24 Mar 2008 12:08:10 -0700 (PDT) Message-ID: <18292fe60803241208i248ffeachf12c49aee3ab2756@mail.gmail.com> Date: Mon, 24 Mar 2008 21:08:10 +0200 From: "Alexander Shulikov" To: freebsd-ipfw@freebsd.org In-Reply-To: <200803241411.51930.asstec@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <200803241158.00240.asstec@matik.com.br> <18292fe60803240811j651decf7hd808373324f06948@mail.gmail.com> <200803241411.51930.asstec@matik.com.br> Cc: AT Matik , bu7cher@yandex.ru Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 19:08:14 -0000 QnkgZGVmYXVsdCBJIGhhdmU6CiMgc3lzY3RsIGtlcm4uaXBjLm5tYmNsdXN0ZXJzCmtlcm4uaXBj Lm5tYmNsdXN0ZXJzOiAyNTYwMAojIHN5c2N0bCBuZXQuaW5ldC5pcC5pbnRyX3F1ZXVlX21heGxl bgpuZXQuaW5ldC5pcC5pbnRyX3F1ZXVlX21heGxlbjogNTAKCldoYXQgcmFuZ2Ugb2YgdmFsdWUg aXMgb3B0aW1hbCB0byB0cnk/CkFsc28gSSBhZGQgdG8gbG9hZGVyLmNvbmY6Cmtlcm4ubWF4dXNl cnM9MTUzNgprZXJuLmlwYy5tYXhwaXBla3ZhPTMyMDAwMDAwCm5ldC5ncmFwaC5tYXhhbGxvYz0y MDQ4CihidXQgaXQgd2FzIGFkZGVkIGFmdGVyIHBhbmljJ3MpCgpPdGhlciB0aGluZywgdGhhdCBJ IHdhbnQgdG8gdHJ5IC0gbmV0Lmlzci5kaXJlY3QgLT4gMD8gTWF5IGJlIGl0CnRlbXByb3Jhcnkg cmVzb2x2ZWQgcHJvYmxlbSwgYmVjYXVzZSBwYWNrZXQgd2lsbCBiZSBnb2luZyB0byBxdWV1ZSBm b3IKcHJvY2Vzc2luZy4KCjIwMDgvMy8yNCwgQVQgTWF0aWsgPGFzc3RlY0BtYXRpay5jb20uYnI+ Ogo+IE9uIE1vbmRheSAyNCBNYXJjaCAyMDA4IDEyOjExOjQ0IEFsZXhhbmRlciBTaHVsaWtvdiB3 cm90ZToKPiAgPiBJbiByZWFsIHNjcmlwdCBJIGhhdmUgaW4gYW5kIG91dC4gQnV0IHNvbWUgaXAn cyBmb3IgdGhlIHNhbWUgc3BlZWQgSQo+ICA+IGFkZCBpbiB0YWJsZSwgYW5kIHRoZW4gZG86Cj4g ID4gIyA1MTIvMTI4Cj4gID4gJHtmd2NtZH0gcGlwZSAzNTcgY29uZmlnIGJ3IDEyOEtiaXQvcyBx dWV1ZSAxMDAgbWFzayBzcmMtaXAgMHhmZmZmZmZmZgo+ICA+ICR7ZndjbWR9IHBpcGUgMzU4IGNv bmZpZyBidyA1MTJLYml0L3MgcXVldWUgMTAwIG1hc2sgZHN0LWlwIDB4ZmZmZmZmZmYKPiAgPiAk e2Z3Y21kfSBhZGQgcGlwZSAzNTcgaXAgZnJvbSAidGFibGUoMykiIHRvIGFueSBpbgo+ICA+ICR7 ZndjbWR9IGFkZCBwaXBlIDM1OCBpcCBmcm9tIGFueSB0byAidGFibGUoMykiIG91dAo+ICA+Cj4g ID4gSVBzIGZvciBpbmRpdmlkdWFsIHNwZWVkIGFkZGVkIGFzIGluIGV4YW1wbGUgaW4gcHJldmlv dXMgbGV0dGVyLCBidXQKPiAgPiB3aXRoIGluL291dC4KPiAgPgo+ICA+IEJ1dCB3aGF0IGNhbiBJ IGRvIGZvciByZXNvbHZlIHRoaXMgcHJvYmxlbS4gTm93IEkgaGF2ZSBzZXJ2ZXIgd2l0aAo+ICA+ IEZyZWVCU0QgNi4yIGFuZCBjb3B5IG9mIHRoaXMgY29uZmlncyAtIGFuZCBhbGwgd29ya3MgZmlu ZS4gb19PCj4gID4KPgo+Cj4KPiB3ZWxsIEkgdXNlIHRoZSBhYm92ZSBkaWZmZXJlbnQsIGZpcnN0 IEkgZGVmaW5lIHRoZSBwaXBlIGFuZCBzZWNvbmQgdGhlIGJ3Cj4gIGFueXdheSBJIGRvIG5vdCB1 c2UgdGFibGVzCj4KPiAgYWxzbyBzZWVtcyB5b3UgdXNlIGxvbmcgcXVldWVzIHNvIG1heSBiZSB5 b3UgbGlrZSB0byB0dW5lCj4gIG5ldC5pbmV0LmlwLmludHJfcXVldWVfbWF4bGVuIGFuZCBtYnVm IG9mIHlvdXIgbWFjaGluZQo+Cj4KPgo+Cj4gID4gMjAwOC8zLzI0LCBBVCBNYXRpayA8YXNzdGVj QG1hdGlrLmNvbS5icj46Cj4gID4gPiBPbiBNb25kYXkgMjQgTWFyY2ggMjAwOCAxMTo1MTo0NCBB bGV4YW5kZXIgU2h1bGlrb3Ygd3JvdGU6Cj4gID4gPiAgPiAjIHN5c2N0bCAtYSB8IGdyZXAgb25l X3Bhc3MKPiAgPiA+ICA+IG5ldC5pbmV0LmlwLmZ3Lm9uZV9wYXNzOiAwCj4gID4gPiAgPgo+ICA+ ID4gID4gWWVzIC0gaXQgZXEgMC4gQnV0IEkgbmVlZCBpdCBmb3IgbmV4dCBzaXR1YXRpb246IGFs bCBuZXQgSSBuZWVkIHNoYXBlCj4gID4gPiAgPiBhdCBvbmUgc3BlZWQsIGJ1dCBpbnZpZGlkdWFs IGlwIGFkZHJlc3NlcyB0byBhbm90aGVyIHNwZWVkLgo+ICA+ID4gID4gRm9yIGV4YW1wbGUsCj4g ID4gPiAgPiBpcGZ3IHBpcGUgMSBjb25maWcgYncgMTBNYml0L3MgcXVldWUgMTAwCj4gID4gPiAg PiBpcGZ3IHBpcGUgMiBjb25maWcgYncgMTBNYml0L3MgcXVldWUgMTAwCj4gID4gPiAgPiBpcGZ3 IGFkZCBwaXBlIDEgaXAgZnJvbSAxOTIuMTY4LjEuMC8yNCB0byBhbnkKPiAgPiA+ICA+IGlwZncg YWRkIHBpcGUgMiBpcCBmcm9tIGFueSB0byAxOTIuMTY4LjEuMC8yNAo+ICA+ID4gID4gaXBmdyBw aXBlIDMgY29uZmlnIGJ3IDFNYml0L3MgcXVldWUgMTAwCj4gID4gPiAgPiBpcGZ3IHBpcGUgNCBj b25maWcgYncgMU1iaXQvcyBxdWV1ZSAxMDAKPiAgPiA+ICA+IGlwZncgYWRkIHBpcGUgMyBpcCBm cm9tIDE5Mi4xNjguMS4xLzMyIHRvIGFueQo+ICA+ID4gID4gaXBmdyBhZGQgcGlwZSA0IGlwIGZy b20gYW55IHRvIDE5Mi4xNjguMS4xLzMyCj4gID4gPgo+ICA+ID4gdGhhdCBzaG91bGQgd29yaywg SSBoYXZlIHNpbWlsYXIgc2V0dXBzIHJ1bm5pbmcgZmluZQo+ICA+ID4gIHRoZSAvMzIgbWFzayB5 b3Ugc2hvdWxkIG5vdCBuZWVkIGJ1dCBJIGFtIG1pc3NpbmcgdGhlIGluL291dCBkZWZpbml0aW9u Cj4gID4gPiBpbiB5b3VyIHJ1bGVzCj4gID4gPgo+ICA+ID4gID4gLi4uLi4uCj4gID4gPiAgPgo+ ICA+ID4gID4KPiAgPiA+ICA+IEFsc28gdGhpcyBjb25maWd1cmF0aW9uIHdvcmsgaW4gRnJlZUJT RCA2LjIuIChNYXkgYmUgaW4gNi4yIHNtYWxsZXIKPiAgPiA+ICA+IGNhbGwgdHJlZT8pCj4gID4g PiAgPgo+ICA+ID4gID4gMjAwOC8zLzI0LCBBVCBNYXRpayA8YXNzdGVjQG1hdGlrLmNvbS5icj46 Cj4gID4gPiAgPiA+IE9uIE1vbmRheSAyNCBNYXJjaCAyMDA4IDA4OjA4OjAyIEFuZHJleSBWLiBF bHN1a292IHdyb3RlOgo+ICA+ID4gID4gPiAgPiBBVCBNYXRpayB3cm90ZToKPiAgPiA+ICA+ID4g ID4gPiB3aGF0IGRvIHlvdSBtZWFuPyBCeSBzZXR0aW5nIHRvIDAgdGhlIHBhY2thZ2VzIGFyZSBu b3QKPiAgPiA+ICA+ID4gID4gPiByZS1pbmplY3RlZCBpbnRvIHRoZSBwaXBlIGJ1dCBnbyB0aHJv dWdoIG90aGVyIGV4aXN0aW5nIHJ1bGVzCj4gID4gPiAgPiA+ICA+ID4gYWZ0ZXIgdGhlIG1hdGNo aW5nIHBpcGUsIG9yIG5vdD8KPiAgPiA+ICA+ID4gID4KPiAgPiA+ICA+ID4gID4gV2hlbiB5b3Ug cmVzZXQgbmV0LmluZXQuaXAuZncub25lX3Bhc3MgdG8gemVybywgcGFja2V0cyByZXR1cm4KPiAg PiA+ICA+ID4gID4gYmFjayBpbnRvIGlwZncgdG8gdGhlIG5leHQgcnVsZSBhZnRlciBkdW1teW5l dC9uZXRncmFwaC4gQW5kIGlmCj4gID4gPiAgPiA+ICA+IHlvdSBoYXZlIHNpbWlsYXIgcnVsZXMg cGFja2V0cyB3aWxsIGJlIHBhc3NlZCBpbnRvCj4gID4gPiAgPiA+ICA+IGR1bW15bmV0L25ldGdy YXBoIGFnYWluLgo+ICA+ID4gID4gPiAgPgo+ICA+ID4gID4gPiAgPiBUaGlzIGlzIGV4YW1wbGUg aG93IHRvIGdldCBkb3VibGUgZmF1bHQgKGZyb20gbWFpbCBhcmNoaXZlKToKPiAgPiA+ICA+ID4K PiAgPiA+ICA+ID4gamFhYSB3ZWxsIGJ1dCB0aGF0IGlzIHRoZSBmYW1vdXMgYncgMCBleGFtcGxl IHdoaWNoIGlzIG5vdCB2YWxpZCwgYXMKPiAgPiA+ICA+ID4gYnkgaXRzZWxmIGNlcnRhaW5seSBh biBpbnZhbGlkIGNvbmZpZywgbm90IGNvbm5lY3RlZCB0byB0aGUgZXhpc3RpbmcKPiAgPiA+ICA+ ID4gcHJvYmxlbSB0aGUgcmVwb3J0ZXIgaGFzIEkgZ3Vlc3MKPiAgPiA+ICA+ID4KPiAgPiA+ICA+ ID4gIEpvw6NvCj4gID4gPiAgPiA+Cj4gID4gPiAgPiA+ICA+IGlmY29uZmlnIGVtMCAxOTIuMTY4 LjAuMi8yNAo+ICA+ID4gID4gPiAgPiBrbGRsb2FkIGlwZncKPiAgPiA+ICA+ID4gID4ga2xkbG9h ZCBkdW1teW5ldAo+ICA+ID4gID4gPiAgPiBzeXNjdGwgbmV0LmluZXQuaXAuZncub25lX3Bhc3M9 MAo+ICA+ID4gID4gPiAgPiBpcGZ3IHBpcGUgMiBjb25maWcgYncgMAo+ICA+ID4gID4gPiAgPiBp cGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiA+ICA+ID4gID4gaXBmdyBh ZGQgMiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gPiAgPiA+ICA+IGlwZncgYWRkIDIg cGlwZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ID4gID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUg MiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiA+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAg ZnJvbSBhbnkgdG8gYW55Cj4gID4gPiAgPiA+ICA+IGlwZncgYWRkIDIgcGlwZSAyIGlwIGZyb20g YW55IHRvIGFueQo+ICA+ID4gID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0 byBhbnkKPiAgPiA+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55 Cj4gID4gPiAgPiA+ICA+IGlwZncgYWRkIDIgcGlwZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ ID4gID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiA+ICA+ ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gPiAgPiA+ICA+ IGlwZncgYWRkIDIgcGlwZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ID4gID4gPiAgPiBpcGZ3 IGFkZCAyIHBpcGUgMiBpcCBmcm9tIGFueSB0byBhbnkKPiAgPiA+ICA+ID4gID4gaXBmdyBhZGQg MiBwaXBlIDIgaXAgZnJvbSBhbnkgdG8gYW55Cj4gID4gPiAgPiA+ICA+IGlwZncgYWRkIDIgcGlw ZSAyIGlwIGZyb20gYW55IHRvIGFueQo+ICA+ID4gID4gPiAgPiBpcGZ3IGFkZCAyIHBpcGUgMiBp cCBmcm9tIGFueSB0byBhbnkKPiAgPiA+ICA+ID4gID4gaXBmdyBhZGQgMiBwaXBlIDIgaXAgZnJv bSBhbnkgdG8gYW55Cj4gID4gPiAgPiA+ICA+IHBpbmcgMTkyLjE2OC4wLjEKPiAgPiA+ICA+ID4K PiAgPiA+ICA+ID4gIC0tCj4gID4gPiAgPiA+Cj4gID4gPiAgPiA+Cj4gID4gPiAgPiA+IEF0ZW5j aW9zYW1lbnRlLCBKLk0uCj4gID4gPiAgPiA+ICBSZXNwb25zw6F2ZWwgUGxhbnTDo28gU2l0ZSBT dXBwb3J0IE1hdGlrCj4gID4gPiAgPiA+ICBJbmZvbWF0aWsgSW50ZXJuZXQgVGVjaG5vbG9neQo+ ICA+ID4gID4gPiAgKDE4KTM1NTEuODE1NSAgKDE4KTgxMTIuNzAwNwo+ICA+ID4gID4gPiAgaHR0 cDovL2luZm8ubWF0aWsuY29tLmJyCj4gID4gPiAgPiA+Cj4gID4gPiAgPiA+Cj4gID4gPiAgPiA+ Cj4gID4gPiAgPiA+Cj4gID4gPiAgPiA+Cj4gID4gPiAgPiA+Cj4gID4gPiAgPiA+Cj4gID4gPiAg PiA+ICBBIG1lbnNhZ2VtIGZvaSBzY2FuZWFkYSBwZWxvIHNpc3RlbWEgZGUgZS1tYWlsIGUgcG9k ZSBzZXIKPiAgPiA+ICA+ID4gY29uc2lkZXJhZGEgc2VndXJhLiBTZXJ2aWNlIGZvcm5lY2lkbyBw ZWxvIERhdGFjZW50ZXIgTWF0aWsKPiAgPiA+ICA+ID4gaHR0cHM6Ly9kYXRhY2VudGVyLm1hdGlr LmNvbS5icgo+ICA+ID4KPiAgPiA+IC0tCj4gID4gPgo+ICA+ID4KPiAgPiA+ICBBdGVuY2lvc2Ft ZW50ZSwgSi5NLgo+ICA+ID4gIFJlc3BvbnPDoXZlbCBQbGFudMOjbyBTaXRlIFN1cHBvcnQgTWF0 aWsKPiAgPiA+ICBJbmZvbWF0aWsgSW50ZXJuZXQgVGVjaG5vbG9neQo+ICA+ID4gICgxOCkzNTUx LjgxNTUgICgxOCk4MTEyLjcwMDcKPiAgPiA+ICBodHRwOi8vaW5mby5tYXRpay5jb20uYnIKPiAg PiA+Cj4gID4gPgo+ICA+ID4KPiAgPiA+Cj4gID4gPgo+ICA+ID4KPiAgPiA+Cj4gID4gPiAgQSBt ZW5zYWdlbSBmb2kgc2NhbmVhZGEgcGVsbyBzaXN0ZW1hIGRlIGUtbWFpbCBlIHBvZGUgc2VyIGNv bnNpZGVyYWRhCj4gID4gPiBzZWd1cmEuIFNlcnZpY2UgZm9ybmVjaWRvIHBlbG8gRGF0YWNlbnRl ciBNYXRpawo+ICA+ID4gaHR0cHM6Ly9kYXRhY2VudGVyLm1hdGlrLmNvbS5icgo+Cj4KPiAtLQo+ Cj4KPiAgQXRlbmNpb3NhbWVudGUsIEouTS4KPiAgUmVzcG9uc8OhdmVsIFBsYW50w6NvIFNpdGUg U3VwcG9ydCBNYXRpawo+ICBJbmZvbWF0aWsgSW50ZXJuZXQgVGVjaG5vbG9neQo+ICAoMTgpMzU1 MS44MTU1ICAoMTgpODExMi43MDA3Cj4gIGh0dHA6Ly9pbmZvLm1hdGlrLmNvbS5icgo+Cj4KPgo+ Cj4KPgo+Cj4gIEEgbWVuc2FnZW0gZm9pIHNjYW5lYWRhIHBlbG8gc2lzdGVtYSBkZSBlLW1haWwg ZSBwb2RlIHNlciBjb25zaWRlcmFkYSBzZWd1cmEuCj4gIFNlcnZpY2UgZm9ybmVjaWRvIHBlbG8g RGF0YWNlbnRlciBNYXRpayAgaHR0cHM6Ly9kYXRhY2VudGVyLm1hdGlrLmNvbS5icgo+Cg== From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 19:42:17 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 530F8106566B for ; Mon, 24 Mar 2008 19:42:17 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8DDAF8FC13 for ; Mon, 24 Mar 2008 19:42:16 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m2OJgHUm077073; Mon, 24 Mar 2008 16:42:17 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: "Alexander Shulikov" Date: Mon, 24 Mar 2008 16:41:37 -0300 User-Agent: KMail/1.9.7 References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <200803241411.51930.asstec@matik.com.br> <18292fe60803241208i248ffeachf12c49aee3ab2756@mail.gmail.com> In-Reply-To: <18292fe60803241208i248ffeachf12c49aee3ab2756@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803241641.37884.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-ipfw@freebsd.org, bu7cher@yandex.ru Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 19:42:17 -0000 On Monday 24 March 2008 16:08:10 Alexander Shulikov wrote: > By default I have: > # sysctl kern.ipc.nmbclusters > kern.ipc.nmbclusters: 25600 hard to say, do you checked netstat -m if you get to your limit? If you get= =20 there set it higher > # sysctl net.inet.ip.intr_queue_maxlen > net.inet.ip.intr_queue_maxlen: 50 seems to be the default try 128, 256, 512 > > What range of value is optimal to try? > Also I add to loader.conf: > kern.maxusers=3D1536 I guess maxusers does not help for your setup and probably you should let t= he=20 system selftune itself > kern.ipc.maxpipekva=3D32000000 > net.graph.maxalloc=3D2048 > (but it was added after panic's) > I believe both do not help anything for ipfw > Other thing, that I want to try - net.isr.direct -> 0? May be it > temprorary resolved problem, because packet will be going to queue for > processing. > I guess this does not help dummynet either > 2008/3/24, AT Matik : > > On Monday 24 March 2008 12:11:44 Alexander Shulikov wrote: > > > In real script I have in and out. But some ip's for the same speed I > > > add in table, and then do: > > > # 512/128 > > > ${fwcmd} pipe 357 config bw 128Kbit/s queue 100 mask src-ip 0xffffff= ff > > > ${fwcmd} pipe 358 config bw 512Kbit/s queue 100 mask dst-ip 0xffffff= ff > > > ${fwcmd} add pipe 357 ip from "table(3)" to any in > > > ${fwcmd} add pipe 358 ip from any to "table(3)" out > > > > > > IPs for individual speed added as in example in previous letter, but > > > with in/out. > > > > > > But what can I do for resolve this problem. Now I have server with > > > FreeBSD 6.2 and copy of this configs - and all works fine. o_O > > > > well I use the above different, first I define the pipe and second the = bw > > anyway I do not use tables > > > > also seems you use long queues so may be you like to tune > > net.inet.ip.intr_queue_maxlen and mbuf of your machine > > > > > 2008/3/24, AT Matik : > > > > On Monday 24 March 2008 11:51:44 Alexander Shulikov wrote: > > > > > # sysctl -a | grep one_pass > > > > > net.inet.ip.fw.one_pass: 0 > > > > > > > > > > Yes - it eq 0. But I need it for next situation: all net I need > > > > > shape at one speed, but invididual ip addresses to another spee= d. > > > > > For example, > > > > > ipfw pipe 1 config bw 10Mbit/s queue 100 > > > > > ipfw pipe 2 config bw 10Mbit/s queue 100 > > > > > ipfw add pipe 1 ip from 192.168.1.0/24 to any > > > > > ipfw add pipe 2 ip from any to 192.168.1.0/24 > > > > > ipfw pipe 3 config bw 1Mbit/s queue 100 > > > > > ipfw pipe 4 config bw 1Mbit/s queue 100 > > > > > ipfw add pipe 3 ip from 192.168.1.1/32 to any > > > > > ipfw add pipe 4 ip from any to 192.168.1.1/32 > > > > > > > > that should work, I have similar setups running fine > > > > the /32 mask you should not need but I am missing the in/out > > > > definition in your rules > > > > > > > > > ...... > > > > > > > > > > > > > > > Also this configuration work in FreeBSD 6.2. (May be in 6.2 > > > > > smaller call tree?) > > > > > > > > > > 2008/3/24, AT Matik : > > > > > > On Monday 24 March 2008 08:08:02 Andrey V. Elsukov wrote: > > > > > > > AT Matik wrote: > > > > > > > > what do you mean? By setting to 0 the packages are not > > > > > > > > re-injected into the pipe but go through other existing > > > > > > > > rules after the matching pipe, or not? > > > > > > > > > > > > > > When you reset net.inet.ip.fw.one_pass to zero, packets > > > > > > > return back into ipfw to the next rule after > > > > > > > dummynet/netgraph. And if you have similar rules packets > > > > > > > will be passed into > > > > > > > dummynet/netgraph again. > > > > > > > > > > > > > > This is example how to get double fault (from mail archive= ): > > > > > > > > > > > > jaaa well but that is the famous bw 0 example which is not > > > > > > valid, as by itself certainly an invalid config, not connected > > > > > > to the existing problem the reporter has I guess > > > > > > > > > > > > Jo=C3=A3o > > > > > > > > > > > > > ifconfig em0 192.168.0.2/24 > > > > > > > kldload ipfw > > > > > > > kldload dummynet > > > > > > > sysctl net.inet.ip.fw.one_pass=3D0 > > > > > > > ipfw pipe 2 config bw 0 > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ipfw add 2 pipe 2 ip from any to any > > > > > > > ping 192.168.0.1 > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > Atenciosamente, J.M. > > > > > > Respons=C3=A1vel Plant=C3=A3o Site Support Matik > > > > > > Infomatik Internet Technology > > > > > > (18)3551.8155 (18)8112.7007 > > > > > > http://info.matik.com.br > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser > > > > > > considerada segura. Service fornecido pelo Datacenter Matik > > > > > > https://datacenter.matik.com.br > > > > > > > > -- > > > > > > > > > > > > Atenciosamente, J.M. > > > > Respons=C3=A1vel Plant=C3=A3o Site Support Matik > > > > Infomatik Internet Technology > > > > (18)3551.8155 (18)8112.7007 > > > > http://info.matik.com.br > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser > > > > considerada segura. Service fornecido pelo Datacenter Matik > > > > https://datacenter.matik.com.br > > > > -- > > > > > > Atenciosamente, J.M. > > Respons=C3=A1vel Plant=C3=A3o Site Support Matik > > Infomatik Internet Technology > > (18)3551.8155 (18)8112.7007 > > http://info.matik.com.br > > > > > > > > > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > > segura. Service fornecido pelo Datacenter Matik=20 > > https://datacenter.matik.com.br =2D-=20 Atenciosamente, J.M. Respons=C3=A1vel Plant=C3=A3o Site Support Matik Infomatik Internet Technology (18)3551.8155 =C2=A0(18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 20:00:46 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1322D106566C for ; Mon, 24 Mar 2008 20:00:46 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by mx1.freebsd.org (Postfix) with ESMTP id 897058FC14 for ; Mon, 24 Mar 2008 20:00:45 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so3887252mue.6 for ; Mon, 24 Mar 2008 13:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BmEQb1fPn31/Lups8b9rrjLpdD5Lo6J7f2bkntNw8vs=; b=pevSYriu479wYzUJppXemApXeNvoVKjcM1Adc3qQ/05sXyjGJQh/qf8EYQtGl5fCjY/6l1nbJrbs88ofn1JXzGPp/IrglrVU84EgWRN69UYIuYbOC7azqZqno/rVx+bY0CpOHsUOEtMoAKxtEYxfjEYauddBpjK74mg4G1V/oW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ix60hL41tbhcOdjN/5ftx2iz3P+yiKzf6/islUw7wScYpH9oMgxvViKTMChCE8x064EU4yzhyVSBkQ3uhSaIQsZBNKe1xCSAkxscsultmvYZEom1Uhw3XKmzUWUZOIW4hs/Oi0eOh0d4fD7mFKgY/rJOeD3Z/jkDuEte6QqRdto= Received: by 10.82.124.10 with SMTP id w10mr18490845buc.18.1206388843638; Mon, 24 Mar 2008 13:00:43 -0700 (PDT) Received: by 10.82.154.1 with HTTP; Mon, 24 Mar 2008 13:00:43 -0700 (PDT) Message-ID: <18292fe60803241300r62066ba7l94d2dd7079e099c8@mail.gmail.com> Date: Mon, 24 Mar 2008 22:00:43 +0200 From: "Alexander Shulikov" To: freebsd-ipfw@freebsd.org In-Reply-To: <18292fe60803241257w2fffa9e1sea57a1687a200732@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <200803241411.51930.asstec@matik.com.br> <18292fe60803241208i248ffeachf12c49aee3ab2756@mail.gmail.com> <200803241641.37884.asstec@matik.com.br> <18292fe60803241257w2fffa9e1sea57a1687a200732@mail.gmail.com> Cc: AT Matik , bu7cher@yandex.ru Subject: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 20:00:46 -0000 2008/3/24, AT Matik : > On Monday 24 March 2008 16:08:10 Alexander Shulikov wrote: > > By default I have: > > # sysctl kern.ipc.nmbclusters > > kern.ipc.nmbclusters: 25600 > > > hard to say, do you checked netstat -m if you get to your limit? If you get > there set it higher When It works - there is alright. But when panic - I can't to see it. > > Other thing, that I want to try - net.isr.direct -> 0? May be it > > temprorary resolved problem, because packet will be going to queue for > > processing. > > > > > I guess this does not help dummynet either > Alexander Motin (mpd server and partially netgraph developer) say thing, that probably trouble in depth of stack. And may be net.isr.direct=0 will help to process packets from queue, but not at the arrival time. Or no? Andrey and AT Matik: Can we talk via jabber or icq? (for decrease traffic in conference, but send in conference result) From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 24 20:42:48 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEA151065671 for ; Mon, 24 Mar 2008 20:42:48 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1F28FC22 for ; Mon, 24 Mar 2008 20:42:47 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m2OKgn9X081606; Mon, 24 Mar 2008 17:42:49 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Mon, 24 Mar 2008 17:42:09 -0300 User-Agent: KMail/1.9.7 References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <18292fe60803241257w2fffa9e1sea57a1687a200732@mail.gmail.com> <18292fe60803241300r62066ba7l94d2dd7079e099c8@mail.gmail.com> In-Reply-To: <18292fe60803241300r62066ba7l94d2dd7079e099c8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803241742.09329.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: bu7cher@yandex.ru, Alexander Shulikov Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 20:42:48 -0000 On Monday 24 March 2008 17:00:43 Alexander Shulikov wrote: > 2008/3/24, AT Matik : > > On Monday 24 March 2008 16:08:10 Alexander Shulikov wrote: > > > By default I have: > > > # sysctl kern.ipc.nmbclusters > > > kern.ipc.nmbclusters: 25600 > > > > hard to say, do you checked netstat -m if you get to your limit? If you > > get there set it higher > > When It works - there is alright. But when panic - I can't to see it. > I guess it will not grow so fast from one moment to another > > > Other thing, that I want to try - net.isr.direct -> 0? May be it > > > temprorary resolved problem, because packet will be going to queue > > > for processing. > > > > I guess this does not help dummynet either > > Alexander Motin (mpd server and partially netgraph developer) say > thing, that probably trouble in depth of stack. > And may be net.isr.direct=3D0 will help to process packets from queue, > but not at the arrival time. Or no? I can not answer this for sure but trying it out is for free :) but it will= =20 not help here I guess Even if I believe the problem is in ipfw you probably should try to isolate= if=20 it is in any means related to mpd, probably you can run your ppp from anoth= er=20 server and run ipfw only on this one, after that you know more you are with 7-R or 7-Stable? > > > Andrey and AT Matik: my name is Jo=C3=A3o, this is my company email address > Can we talk via jabber or icq? (for decrease traffic in conference, > but send in conference result) > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > segura. Service fornecido pelo Datacenter Matik=20 > https://datacenter.matik.com.br =2D-=20 Atenciosamente, J.M. Respons=C3=A1vel Plant=C3=A3o Site Support Matik Infomatik Internet Technology (18)3551.8155 =C2=A0(18)8112.7007 http://info.matik.com.br A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 25 06:19:18 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB161106564A for ; Tue, 25 Mar 2008 06:19:18 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 2FFC78FC3B for ; Tue, 25 Mar 2008 06:19:17 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2828913fgg.35 for ; Mon, 24 Mar 2008 23:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=b9dLdopolYHriy0tmAWCXdqyz7QFNpJtpJhxsuSFxgs=; b=WJEarABPoNGwrdmYiz6afijwbKZNU1NRv3k+j89SPcGKZAkNany2u9LjnVoVewzOdj96yZQiLJwQXwHI0ToqJUzAGST+VGzmDU1pOB3D9pyBiFtQcAYmVNuX5f5NVJ5gQoO0weBEauFVkRNSeGw0X3xEXdh3N2mNo2fkLsIykUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RDs6RRu4sV3+TuSqmwLrTNPq+7u+vDIuCQd+njEn/SApJ+RLjxsmtjCPYBONUmGGQEL6M1gJSzCxv9j+4RpwRLe40bPlQnaEdwJ58f4hp/+AKdCRPS4iaEMGSeDqRfXmXQ3J3G4ThtdXW3vb8USSVo50S0G+0OGRJA1ku2P3cw4= Received: by 10.82.113.6 with SMTP id l6mr19959877buc.20.1206425956780; Mon, 24 Mar 2008 23:19:16 -0700 (PDT) Received: by 10.82.154.1 with HTTP; Mon, 24 Mar 2008 23:19:16 -0700 (PDT) Message-ID: <18292fe60803242319v1a543524pd540ddb17a96ce26@mail.gmail.com> Date: Tue, 25 Mar 2008 08:19:16 +0200 From: "Alexander Shulikov" To: freebsd-ipfw@freebsd.org In-Reply-To: <200803241742.09329.asstec@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <18292fe60803241257w2fffa9e1sea57a1687a200732@mail.gmail.com> <18292fe60803241300r62066ba7l94d2dd7079e099c8@mail.gmail.com> <200803241742.09329.asstec@matik.com.br> Cc: AT Matik , bu7cher@yandex.ru Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 06:19:18 -0000 PiBJIGNhbiBub3QgYW5zd2VyIHRoaXMgZm9yIHN1cmUgYnV0IHRyeWluZyBpdCBvdXQgaXMgZm9y IGZyZWUgOikgYnV0IGl0IHdpbGwKPiAgbm90IGhlbHAgaGVyZSBJIGd1ZXNzCj4KPiAgRXZlbiBp ZiBJIGJlbGlldmUgdGhlIHByb2JsZW0gaXMgaW4gaXBmdyB5b3UgcHJvYmFibHkgc2hvdWxkIHRy eSB0byBpc29sYXRlIGlmCj4gIGl0IGlzIGluIGFueSBtZWFucyByZWxhdGVkIHRvIG1wZCwgcHJv YmFibHkgeW91IGNhbiBydW4geW91ciBwcHAgZnJvbSBhbm90aGVyCj4gIHNlcnZlciBhbmQgcnVu IGlwZncgb25seSBvbiB0aGlzIG9uZSwgYWZ0ZXIgdGhhdCB5b3Uga25vdyBtb3JlCj4KPiAgeW91 IGFyZSB3aXRoIDctUiBvciA3LVN0YWJsZT8KCkkgdXNlIEZyZWVCU0QgNy4wLVJFTEVBU0UuIEFu ZCBkb24ndCB3YW50IHVzZSBzdGFibGUsIGJlY2F1c2UgaXQgaXMKaGlnaCBwcm9iYWJpbGl0eSB0 byBnZXQgZHVtcCBvbiBhbm90aGVyIHByb2JsZW1zLiA6KQpPbiBGcmlkYXkgSSBzaGFsbCB0cnkg dGhlIGNvbnNpZGVyZWQgdmFyaWFudHMgYW5kIHdyaXRlIHJlc3VsdHMuCgo+ICA+IEFuZHJleSBh bmQgQVQgTWF0aWs6Cj4KPiAgbXkgbmFtZSBpcyBKb8OjbywgdGhpcyBpcyBteSBjb21wYW55IGVt YWlsIGFkZHJlc3MKClNvcnJ5Lgo= From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 25 09:28:07 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27342106564A for ; Tue, 25 Mar 2008 09:28:07 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id C50708FC1B for ; Tue, 25 Mar 2008 09:28:06 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so1094839anc.13 for ; Tue, 25 Mar 2008 02:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wTj8dp6qtPHt5Sks2V46KZxTzdL4ITIWdRSCwW2Qt7M=; b=Ljbbroesza9zDIcEPK0ki3uVRCOyizPIMFBI7S/do+jLPjL9AsN9A0pl3gPktSRifs1gj/I3rDX70HzlixpAu3n/ZgnkywOA1Z19anCSKRAHXbs58wccszoix99rFHxsMek0/w/8tIL5b0v+rsG8JtOGnaO2KrSnwkiZd6CF2rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fP5kYfkURienz60K4HuUFphfV9c9Ddhj4s1Z7OQT+f10+xlbCoFw7jufWJco0RN/WK1Em7FG+XDx2D0SVwAuwRLZuEK8QHfcNm1cDZ3rT8CcB05OBd9RUehjlmZMrh7nFbJigH/X1Yd4EVk9fkj/UyAjnmpzWn9qNmrC3B7VxVk= Received: by 10.100.140.1 with SMTP id n1mr20440751and.70.1206435784460; Tue, 25 Mar 2008 02:03:04 -0700 (PDT) Received: by 10.100.8.19 with HTTP; Tue, 25 Mar 2008 02:03:04 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 17:03:04 +0800 From: "Sepherosa Ziehau" To: "Julian Elischer" In-Reply-To: <47E7EAA8.7020101@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> Cc: vadim_nuclight@mail.ru, freebsd-ipfw@freebsd.org, araujo@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 09:28:07 -0000 On Tue, Mar 25, 2008 at 1:53 AM, Julian Elischer wrote: > 3/ possibly keeping per CPU stats.. This probably is the trickest part, not difficult for non-fastforward case. But if fastforward is enabled, I could only imagine full cross-cpu states duplication. Best Regards, sephe -- Live Free or Die From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 25 09:28:42 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9EEA1065671 for ; Tue, 25 Mar 2008 09:28:42 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6FC8FC40 for ; Tue, 25 Mar 2008 09:28:41 +0000 (UTC) (envelope-from shulikov@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2889529fgg.35 for ; Tue, 25 Mar 2008 02:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Gw904kfFbVYLG+SXV2XI4M6mIqudfWM0287a+FAtTPM=; b=Fr8cygJNFOK8K597MHkFLy2Hq0ez6WhEQfNxDllvToyTVM1sObY668uatF/1Y8XMswKo8aKv6L/gmBDzv/FeEyURyicbgnR3PIn439O9FuR62DeUWRBevURIFUisdjMuDXhmryWFvXtaoYx7bmZurgWc00fYNF4b04YDMTGO+To= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=avFp43RImI1qUxtP2FZWw639vlu5j9pzS2m3GatkWhNR2c2FVtuUPXYheVF+JUfYaEbFyZT6/fU6/cgek0f0lcDKdOS3hEShb6J5iDikOwmHHzREW4Xejt3M6pvo/36qa/zVUjmRpKvu4YeHc/Hlxa3mhIGCAaqhH8rnBvmibyo= Received: by 10.82.189.9 with SMTP id m9mr20429659buf.13.1206437320326; Tue, 25 Mar 2008 02:28:40 -0700 (PDT) Received: by 10.82.154.1 with HTTP; Tue, 25 Mar 2008 02:28:40 -0700 (PDT) Message-ID: <18292fe60803250228t314070dcl94faca5b745dd043@mail.gmail.com> Date: Tue, 25 Mar 2008 11:28:40 +0200 From: "Alexander Shulikov" To: freebsd-ipfw@freebsd.org In-Reply-To: <18292fe60803242319v1a543524pd540ddb17a96ce26@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <18292fe60803240107v1462a87v4222790745844d5d@mail.gmail.com> <18292fe60803241257w2fffa9e1sea57a1687a200732@mail.gmail.com> <18292fe60803241300r62066ba7l94d2dd7079e099c8@mail.gmail.com> <200803241742.09329.asstec@matik.com.br> <18292fe60803242319v1a543524pd540ddb17a96ce26@mail.gmail.com> Cc: AT Matik , bu7cher@yandex.ru Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 09:28:42 -0000 I did tuning, that was in my other letters (net.isr.direct=0, tuning in /boot/loader.conf) And received panic after 12 minutes: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xf2a9864 fault code = supervisor read, page not present instruction pointer = 0x20:0xc7d1a95f stack pointer = 0x28:0xed8ccae4 frame pointer = 0x28:0xed8ccbd8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi1: net) trap number = 12 panic: page fault cpuid = 0 Uptime: 12m14s Physical memory: 1015 MB Dumping 67 MB: (CTRL-C to abort) 52 36 20 4 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc055a0b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc055a379 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07ac59c in trap_fatal (frame=0xed8ccaa4, eva=254449764) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc07ac800 in trap_pfault (frame=0xed8ccaa4, usermode=0, eva=254449764) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc07ad182 in trap (frame=0xed8ccaa4) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc079431b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc7d1a95f in ?? () Previous frame inner to this frame (corrupt stack?) Also I fix ipfw.sh and remove all queues from it. Used only pipes. From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 25 10:03:29 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91FA41065671; Tue, 25 Mar 2008 10:03:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5AAC98FC1F; Tue, 25 Mar 2008 10:03:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0130046C1B; Tue, 25 Mar 2008 05:45:42 -0400 (EDT) Date: Tue, 25 Mar 2008 09:45:41 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sepherosa Ziehau In-Reply-To: Message-ID: <20080325094400.I6905@fledge.watson.org> References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: vadim_nuclight@mail.ru, freebsd-ipfw@freebsd.org, Julian Elischer , freebsd-hackers@freebsd.org, araujo@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 10:03:29 -0000 On Tue, 25 Mar 2008, Sepherosa Ziehau wrote: > On Tue, Mar 25, 2008 at 1:53 AM, Julian Elischer wrote: >> 3/ possibly keeping per CPU stats.. > > This probably is the trickest part, not difficult for non-fastforward case. > But if fastforward is enabled, I could only imagine full cross-cpu states > duplication. FWIW, there is decreasing difference between IP fast forwarding and regular IP processing in FreeBSD 7.x, as we perform direct dispatch by default, so it's not just the fast forward case where full input parallelism is possible for the firewall, and parallel firewall processing has occurred for output since 5.3. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 25 15:52:39 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 271791065683 for ; Tue, 25 Mar 2008 15:52:39 +0000 (UTC) (envelope-from shulikov@i.ua) Received: from web01.mi6.kiev.ua (web01.mi6.kiev.ua [91.198.36.2]) by mx1.freebsd.org (Postfix) with ESMTP id AF8788FC1E for ; Tue, 25 Mar 2008 15:52:38 +0000 (UTC) (envelope-from shulikov@i.ua) Received: from web03.mi6 ([10.0.0.4] helo=web03.mi6.kiev.ua) by web01.mi6.kiev.ua with esmtp (Exim 4.43) id 1JeB8Z-0006eZ-72 for freebsd-ipfw@freebsd.org; Tue, 25 Mar 2008 17:32:31 +0200 Received: from web by web03.mi6.kiev.ua with local (Exim 4.43) id 1JeB8g-0006eu-W6 for freebsd-ipfw@freebsd.org; Tue, 25 Mar 2008 17:32:39 +0200 To: freebsd-ipfw@freebsd.org Date: Tue, 25 Mar 2008 17:32:38 +0200 From: Alexander Shulikov MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=windows-1251 Content-Transfer-Encoding: QUOTED-PRINTABLE X-User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.8.1.12) Gecko/20080203 SUSE/2.0.0.12-0.1 Firefox/2.0.0.12 X-Sender-IP: 193.108.38.14 X-Mailer: I.UA Mail System Message-Id: Subject: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 15:52:39 -0000 After I set net.isr.direct=3D0 and others: net.inet.ip.fw.one_pass=3D0 net.inet.ip.fw.autoinc_step=3D1 net.isr.direct=3D0 net.inet.ip.intr_queue_maxlen=3D1024 net.inet.ip.dummynet.hash_size=3D256 net.inet.ip.dummynet.expire=3D0 net.inet.ip.dummynet.max_chain_len=3D64 net.graph.maxdgram=3D128000 net.graph.recvspace=3D128000 net.inet.tcp.sendspace=3D131070 net.inet.tcp.recvspace=3D131070 kern.ipc.somaxconn=3D8192 kern.ipc.maxsockbuf=3D2097152 server panic after 10-15 minutes, against 3-5. But in kernel dump now: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xe2 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc7d1aff0 stack pointer =3D 0x28:0xed8ccae0 frame pointer =3D 0x28:0xed8ccbd8 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (swi1: net) trap number =3D 12 panic: page fault cpuid =3D 0 Uptime: 3h14m51s Physical memory: 1015 MB Dumping 70 MB: (CTRL-C to abort) 55 (CTRL-C to abort) 39 23 7 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc05629c7 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 09 #2 0xc0562c89 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc07b4f3c in trap_fatal (frame=3D0xed8ccaa0, eva=3D226) at /usr/src/sy= s/i386/i386/trap.c:899 #4 0xc07b51a0 in trap_pfault (frame=3D0xed8ccaa0, usermode=3D0, eva=3D226)= at /usr/src/sys/i386/i386/trap.c:812 #5 0xc07b5b22 in trap (frame=3D0xed8ccaa0) at /usr/src/sys/i386/i386/trap.= c:490 #6 0xc079ccbb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc7d1aff0 in ?? () Previous frame inner to this frame (corrupt stack?) In ipfw I use tables, that then added to pipe, that configured with mask 0x= ffffffff. I have similar server with load much smaller under FreeBSD 7.0-RC3, but wit= h similar configuration (used ipfw+tables+pipes, pf, mpd5), but in mpd I do= n't using ng_car. May be using ng_car and dummynet together is corrupt? -- =F0=E5=EA=EB=E0=EC=E0 --------------------------------------------------= --------- =CD=E0=F3=F7=E8=EC =EA=E0=E6=E4=EE=E3=EE =E7=E0=F0=E0=E1=E0=F2=FB=E2=E0=F2= =FC =ED=E0 =EA=EE=EB=E5=E1=E0=ED=E8=FF=F5 =EA=F3=F0=F1=EE=E2 =E2=E0=EB=FE= =F2. =C7=E0=EF=E8=F1=FC =ED=E0 =E1=E5=F1=EF=EB=E0=F2=ED=FB=E9 =F1=E5=EC=E8=ED=E0= =F0 http://www.fxclub.org/condition_howtrade_freeseminar/ From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 26 08:49:32 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26DE3106564A for ; Wed, 26 Mar 2008 08:49:32 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A6D3C8FC36 for ; Wed, 26 Mar 2008 08:49:31 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JeRK6-0008HJ-8X for freebsd-ipfw@freebsd.org; Wed, 26 Mar 2008 08:49:30 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Mar 2008 08:49:30 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Mar 2008 08:49:30 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.devel.ipfw Date: Wed, 26 Mar 2008 08:49:12 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 57 Message-ID: References: <47E79636.1000909@FreeBSD.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Marcelo Araujo User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 08:49:32 -0000 Hi Marcelo Araujo! On Mon, 24 Mar 2008 08:53:26 -0300; Marcelo Araujo wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate': >> 2.5. Just to mention: modip, counter limits, fragments. >> >> These patches are already currently discussed in ipfw@, but included >> here just to not forget. These are "modip" action, allowing to modify IP >> header (DSCP, ToS, TTL) and corresponding match rule options, and a rule >> option to match when rule counters are less then specified number >> packets or bytes (possibly from dynamic rule's counters), may be >> a tablearg. This is also related with mentioned in section 1.2 ability >> to control rule counters. >> >> Adding a few keywords for O_FRAG more fragment matching (not only >> non-first fragment), e.g. for sending to specialized netgraph(4) >> reassembling module, is also desirable. > For remember to all, I work around of modip action stilly, I stoped my > work during last week, but I work again in it. > Work status: > 1) We have modip action implemented: > island# ipfw add modip > ipfw: need modip [DF|TOS|IPPRE|DSCP]:code arg > 2) Both DF and IPPRE works perfect: > island# ipfw show > 00010 371 36133 modip ippre:immediate ip from any to any > 00011 52 5035 modip df:0 ip from any to any > 3) DSCP: > With the DSCP I've some errors but I believe that I fix it on this week. > 4) ToS: > I start the work on the next week. > The patch: http://people.freebsd.org/~araujo/logs/ipfw-modip20080324.diff= Looked at the patch. Some line are changed e.g. in NAT definitions without any visible changes, strange. Also, you're adding 7 opcode in the kernel, 2 for match and 5 for setting, while having single "modip" action in userland. In the case of significantly changing compilation rulesm, etc., we may need many new opcodes so we should not waste them. For example, your O_IPTOSPRE is redundant because we already have O_IPPRECEDENCE which compiler could utilize while retainig more ABI compatibility. I can correct and extend your patch for DSCP/TTL/any bytes (not forgetting credits, of course), if you're too busy... -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 26 08:55:12 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C953D106564A for ; Wed, 26 Mar 2008 08:55:12 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 842AD8FC2E for ; Wed, 26 Mar 2008 08:55:12 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JeRPT-0000Gc-S1 for freebsd-ipfw@freebsd.org; Wed, 26 Mar 2008 08:55:03 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Mar 2008 08:55:03 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Mar 2008 08:55:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.devel.ipfw Date: Wed, 26 Mar 2008 08:51:59 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 24 Message-ID: References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Julian Elischer User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 08:55:12 -0000 Hi Julian Elischer! On Mon, 24 Mar 2008 10:53:44 -0700; Julian Elischer wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate': > here are some of my ideas for ipfw changes: > 1/ redo locking so that packets do not have to get locks on the > structure... I have several ideas on this Currently the main need for locking arises for rule byte/packet counters. The easiest short-term solution > 2/ allow separate firewalls to be used at different parts of the > network stack (i.e allow multiple taboe sto co-exist) Umm, could you explain it a little?.. > 3/ possibly keeping per CPU stats.. How that would be represented to user? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 26 12:17:58 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3E05106564A for ; Wed, 26 Mar 2008 12:17:58 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id 968E38FC12 for ; Wed, 26 Mar 2008 12:17:58 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so1269919anc.13 for ; Wed, 26 Mar 2008 05:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; bh=2E+K1OiPuhppx/jgA7oWBwJ9gpc3xQIVbP+UGZVDbqI=; b=OeiJfvDZPtCjOl/cLcGBdiQ7OFzVKJAFQM5uMBfElNT8GY/3LELPdVnNpMyKXdgWT9JGGzpnq3abH/S0fzYJBR97BAxpavQU3y96PJ1ERekanghjSkvXn+R2oqlIDxPbSWSuPdbZDSKObYk4jjLkhUaaEfsUN0hWOnu0t1wndwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; b=Z21UJ73JzkzC/CJoILjv7mCzGLt3htvOVQfFBARuDneiqqZhrblEuV/2+oadJVgc8W/7Jo723WZJCd2aYQlrt+PHQdso/F9VJ1/H3rIZamh3a9bBn7cheC7uwnSix+1S+fMM1WZbDHbE9cjgyU+wk55o6uPUTX7V+GVIWBt7zVI= Received: by 10.100.225.19 with SMTP id x19mr21822777ang.5.1206533877834; Wed, 26 Mar 2008 05:17:57 -0700 (PDT) Received: from island.freebsd.org ( [200.247.114.5]) by mx.google.com with ESMTPS id c23sm15775511ana.15.2008.03.26.05.17.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Mar 2008 05:17:56 -0700 (PDT) Message-ID: <47EA3EEC.2040007@FreeBSD.org> Date: Wed, 26 Mar 2008 09:17:48 -0300 Organization: FreeBSD User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <47E79636.1000909@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=53E4CFA8 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF38EA32A2BFA59820860D170" From: Marcelo Araujo Cc: freebsd-ipfw@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 12:17:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF38EA32A2BFA59820860D170 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Vadim Goncharov wrote: > > Looked at the patch. Some line are changed e.g. in NAT definitions with= out any > visible changes, strange. > > Also, you're adding 7 opcode in the kernel, 2 for match and 5 for setti= ng, > while having single "modip" action in userland. In the case of signific= antly > changing compilation rulesm, etc., we may need many new opcodes so we s= hould > not waste them. For example, your O_IPTOSPRE is redundant because we al= ready > have O_IPPRECEDENCE which compiler could utilize while retainig more AB= I > compatibility. > > I can correct and extend your patch for DSCP/TTL/any bytes (not forgett= ing > credits, of course), if you're too busy... > > =20 Of course, I've interest in any external support, because I need to finish my degree project and I'm a bit busy. Any help are welcome and please feel free to re-work the patch. Just like the really the most important thing is the *modip*, I'm happy that you work within this idea.= I'd like to see *modip* committed. I continue to my research and if I've some time to work with ipfw or another mechanism that have some relation with my project degree, I'll ma= ke. Best Regards, --=20 Marcelo Araujo (__) araujo@FreeBSD.org \\\'',) http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) --------------enigF38EA32A2BFA59820860D170 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFH6j7wovxJd1Pkz6gRAsRtAJ4iFpSbKPiW8fIH6ynJ4wi5JZTU/wCfW3F0 qxGd8431PJTvgvZg3eQ7Ilk= =P/KB -----END PGP SIGNATURE----- --------------enigF38EA32A2BFA59820860D170-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 26 16:38:11 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50140106564A; Wed, 26 Mar 2008 16:38:11 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3958FC14; Wed, 26 Mar 2008 16:38:11 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2QGcB4u006535; Wed, 26 Mar 2008 16:38:11 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2QGcB77006531; Wed, 26 Mar 2008 16:38:11 GMT (envelope-from remko) Date: Wed, 26 Mar 2008 16:38:11 GMT Message-Id: <200803261638.m2QGcB77006531@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/122109: ipfw nat traceroute problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 16:38:11 -0000 Synopsis: ipfw nat traceroute problem Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: remko Responsible-Changed-When: Wed Mar 26 16:38:03 UTC 2008 Responsible-Changed-Why: reassign to ipfw http://www.freebsd.org/cgi/query-pr.cgi?pr=122109 From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 26 17:31:14 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34F0A1065671 for ; Wed, 26 Mar 2008 17:31:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outq.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 21D218FC24 for ; Wed, 26 Mar 2008 17:31:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 26 Mar 2008 13:17:41 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id A6DEA2D600D; Wed, 26 Mar 2008 10:31:12 -0700 (PDT) Message-ID: <47EA8860.3060709@elischer.org> Date: Wed, 26 Mar 2008 10:31:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 17:31:14 -0000 Vadim Goncharov wrote: > Hi Julian Elischer! > > On Mon, 24 Mar 2008 10:53:44 -0700; Julian Elischer wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate': > >> here are some of my ideas for ipfw changes: > >> 1/ redo locking so that packets do not have to get locks on the >> structure... I have several ideas on this > > Currently the main need for locking arises for rule byte/packet counters. The > easiest short-term solution The main need for locking is that the rules can be changed while a processor is traversing the rule set. > >> 2/ allow separate firewalls to be used at different parts of the >> network stack (i.e allow multiple taboe sto co-exist) there are many places that ipfw is currently callable from. ip_input(), ip_output(), ether_demux(), if_brige, ether_output() it would be interesting tobe able to have differnt firewalls in these places (possibly per interface) so that state (e.g. keep_state) can be kept seprately for one place then from another. for example you may not want the result of 'keep state' on an external interface to necessarily affect what happens to packets from the same session when viewed traversing an internal interface. Currently on my more complex ipfw rule sets I break the rule sets out so that packets in different places traverse different rules but it would be nice to have it explicitly supported. > > Umm, could you explain it a little?.. > >> 3/ possibly keeping per CPU stats.. > > How that would be represented to user? it wouldn't.. you'd add them together before presenting them. but every time a packet changes a counter that is shared, there is a chance that it is being altered by another processor, so if you have fine grained locking in ipfw, you really should use atomic adds, which are slow, or accept possibl collisions (which might be ok) but still cause a lot of cross cpu TLB flushing. > From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 26 20:32:25 2008 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47A7E1065674; Wed, 26 Mar 2008 20:32:25 +0000 (UTC) (envelope-from piso@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 22E158FC14; Wed, 26 Mar 2008 20:32:25 +0000 (UTC) (envelope-from piso@FreeBSD.org) Received: from freefall.freebsd.org (piso@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2QKWPpi032415; Wed, 26 Mar 2008 20:32:25 GMT (envelope-from piso@freefall.freebsd.org) Received: (from piso@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2QKWOWZ032411; Wed, 26 Mar 2008 20:32:25 GMT (envelope-from piso) Date: Wed, 26 Mar 2008 20:32:25 GMT Message-Id: <200803262032.m2QKWOWZ032411@freefall.freebsd.org> To: piso@FreeBSD.org, freebsd-ipfw@FreeBSD.org, piso@FreeBSD.org From: piso@FreeBSD.org Cc: Subject: Re: kern/122109: ipfw nat traceroute problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 20:32:25 -0000 Synopsis: ipfw nat traceroute problem Responsible-Changed-From-To: freebsd-ipfw->piso Responsible-Changed-By: piso Responsible-Changed-When: Wed Mar 26 20:32:04 UTC 2008 Responsible-Changed-Why: Mine. http://www.freebsd.org/cgi/query-pr.cgi?pr=122109 From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 27 05:52:42 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 030D6106564A for ; Thu, 27 Mar 2008 05:52:42 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id B425F8FC16 for ; Thu, 27 Mar 2008 05:52:41 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jel2S-0004yl-3a for freebsd-ipfw@freebsd.org; Thu, 27 Mar 2008 05:52:36 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 05:52:36 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 05:52:36 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Date: Thu, 27 Mar 2008 05:52:22 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 20 Message-ID: References: <47E79636.1000909@FreeBSD.org> <47EA3EEC.2040007@FreeBSD.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Marcelo Araujo User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 05:52:42 -0000 Hi Marcelo Araujo! On Wed, 26 Mar 2008 09:17:48 -0300; Marcelo Araujo wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate': > Of course, I've interest in any external support, because I need to > finish my degree project and I'm a bit busy. Any help are welcome and > please feel free to re-work the patch. Just like the really the most > important thing is the *modip*, I'm happy that you work within this idea.= > I'd like to see *modip* committed. > I continue to my research and if I've some time to work with ipfw or > another mechanism that have some relation with my project degree, I'll ma= > ke. OK, I'll take it. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 27 06:50:05 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A5DD1065671 for ; Thu, 27 Mar 2008 06:50:05 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 25D688FC24 for ; Thu, 27 Mar 2008 06:50:05 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Jelw2-00076q-K8 for freebsd-ipfw@freebsd.org; Thu, 27 Mar 2008 06:50:02 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 06:50:02 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 06:50:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.devel.ipfw Date: Thu, 27 Mar 2008 06:46:54 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 68 Message-ID: References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> <47EA8860.3060709@elischer.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Julian Elischer User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 06:50:05 -0000 Hi Julian Elischer! On Wed, 26 Mar 2008 10:31:12 -0700; Julian Elischer wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate': >>> here are some of my ideas for ipfw changes: >> >>> 1/ redo locking so that packets do not have to get locks on the >>> structure... I have several ideas on this >> >> Currently the main need for locking arises for rule byte/packet counters. The >> easiest short-term solution > The main need for locking is that the rules can be changed while a > processor is traversing the rule set. Oh, I haven't finished the letter. I wanted to say that easiest short-term solution would be splitting main ruleset lock into 2 locks: one for ruleset and one for counters, and wrap the only "f->*cnt +=" with that locks. >>> 2/ allow separate firewalls to be used at different parts of the >>> network stack (i.e allow multiple taboe sto co-exist) > there are many places that ipfw is currently callable from. > ip_input(), ip_output(), ether_demux(), if_brige, ether_output() > it would be interesting tobe able to have differnt firewalls in these > places (possibly per interface) so that state (e.g. keep_state) > can be kept seprately for one place then from another. > for example you may not want the result of 'keep state' on an > external interface to necessarily affect what happens to > packets from the same session when viewed traversing an internal > interface. > Currently on my more complex ipfw rule sets I break the rule sets out > so that packets in different places traverse different rules > but it would be nice to have it explicitly supported. Good. That should be added to proposal in part of creation of dynamic rules in any state: by default all-shared dynamic rules should be used (to preserve POLA), and an option in rule can be specified for a specific pass/layer. >> Umm, could you explain it a little?.. >> >>> 3/ possibly keeping per CPU stats.. >> >> How that would be represented to user? > it wouldn't.. you'd add them together before presenting them. > but every time a packet changes a counter that is shared, there is a > chance that it is being altered by another processor, so if you have > fine grained locking in ipfw, you really should use atomic adds, > which are slow, or accept possibl collisions (which might be ok) > but still cause a lot of cross cpu TLB flushing. Looked at the code... oh... I was wrong above with splitting for two locks into second for counters. It merely doen't exist and counters can get corrupted just now :-) The idea to keep separate per-CPU counters *could* be just reasonable, but as O_COUNTERLIMIT is likely to be introduced, it will need to access to already combined values, which now can be just for every packet, thus invalidating whole idea. The possible solution can again lie in ruleset compiled to single area of opcodes rather than linked list. In this case counters can be made a separate from opcodes array of int64's which will be contiguous and much smaller than current opcodes/counters mix, so chances for cache misses/flushes will be much smaller too. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 27 09:15:22 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D147A1065673; Thu, 27 Mar 2008 09:15:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A58998FC13; Thu, 27 Mar 2008 09:15:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id EBB7346B8F; Thu, 27 Mar 2008 05:15:21 -0400 (EDT) Date: Thu, 27 Mar 2008 09:15:21 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <47EA8860.3060709@elischer.org> Message-ID: <20080327090909.T34007@fledge.watson.org> References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> <47EA8860.3060709@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: vadim_nuclight@mail.ru, freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 09:15:23 -0000 On Wed, 26 Mar 2008, Julian Elischer wrote: > it wouldn't.. you'd add them together before presenting them. but every time > a packet changes a counter that is shared, there is a chance that it is > being altered by another processor, so if you have fine grained locking in > ipfw, you really should use atomic adds, which are slow, or accept possibl > collisions (which might be ok) but still cause a lot of cross cpu TLB > flushing. In malloc(9) and uma(9), we maintain per-CPU stats, coalescing only for presentation, relying on soft critical sections rather than locks to pretect consistency. What's worth remembering, however, is that recent multicore machines have significantly optimized the cost of atomic operations on cache lines held for write by the current CPU, and so the cost of locking has dramatically fallen in the last few years. This re-emphasizes the importance of careful cacheline management for per-CPU data structures (particularly, don't put data written by multiple CPUs in the same cacheline if you want the benefits of per-CPU access). Where read-write locking is the best model, Stephan's recent work on rmlocks looks quite promising. In my micro-benchmarks, on recent hardware it performs extremely well on SMP for read locks, but still requires optimization for UP-compiled kernels. For stats and writable structures, such as per-CPU caches, rmlocks aren't very helpful, but when compared with replicating infrequently written data structures across many CPUs, rwlocks/rmlocks offer a much simpler and less error-prone programming model. We need to see more optimization and measurement done on rmlocks for 8.x, and the lack of full priority propagation for rwlocks has to be kept in mind. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 27 17:37:39 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F7D21065672 for ; Thu, 27 Mar 2008 17:37:39 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B78338FC25 for ; Thu, 27 Mar 2008 17:37:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 27041 invoked from network); 27 Mar 2008 16:20:24 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Mar 2008 16:20:24 -0000 Message-ID: <47EBD520.8050305@freebsd.org> Date: Thu, 27 Mar 2008 18:10:56 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Robert Watson References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> <20080325094400.I6905@fledge.watson.org> In-Reply-To: <20080325094400.I6905@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-hackers@freebsd.org, araujo@freebsd.org, vadim_nuclight@mail.ru, freebsd-ipfw@freebsd.org, Julian Elischer Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 17:37:39 -0000 Robert Watson wrote: > > On Tue, 25 Mar 2008, Sepherosa Ziehau wrote: > >> On Tue, Mar 25, 2008 at 1:53 AM, Julian Elischer >> wrote: >> >>> 3/ possibly keeping per CPU stats.. >> >> >> This probably is the trickest part, not difficult for non-fastforward >> case. But if fastforward is enabled, I could only imagine full >> cross-cpu states duplication. > > > FWIW, there is decreasing difference between IP fast forwarding and > regular IP processing in FreeBSD 7.x, as we perform direct dispatch by > default, so it's not just the fast forward case where full input > parallelism is possible for the firewall, and parallel firewall > processing has occurred for output since 5.3. The regular forwarding path still does a (partial) copy of each packet it forwards. This is done for the ICMP redirect functionality. Additionally it has a much larger I-cache footprint due to the full ip_input(), ip_forward() and ip_output() functions being executed. Yes, the delta is shrinking but still quite big. I think regular forwarding still hits the wall at around 300-350kpps whereas fastforward can do 500kpps up to 1mpps with a good hardware base. -- Andre From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 28 11:16:09 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A91E106566B for ; Fri, 28 Mar 2008 11:16:09 +0000 (UTC) (envelope-from shulikov@i.ua) Received: from xray2.mi6.kiev.ua (xray2.mi6.kiev.ua [91.198.36.8]) by mx1.freebsd.org (Postfix) with ESMTP id 3C96D8FC27 for ; Fri, 28 Mar 2008 11:16:08 +0000 (UTC) (envelope-from shulikov@i.ua) Received: from localhost ([127.0.0.1] helo=xray2.mi6.kiev.ua) by xray2.mi6.kiev.ua with esmtp (Exim 4.63) (envelope-from ) id 1JfCZ3-0000Gj-Ij for freebsd-ipfw@freebsd.org; Fri, 28 Mar 2008 13:16:05 +0200 Received: (from web@localhost) by xray2.mi6.kiev.ua (8.13.8/8.13.8/Submit) id m2SBG5tU001031; Fri, 28 Mar 2008 13:16:05 +0200 Message-Id: <200803281116.m2SBG5tU001031@xray2.mi6.kiev.ua> X-Authentication-Warning: xray2.mi6.kiev.ua: web set sender to shulikov@i.ua using -f To: freebsd-ipfw@freebsd.org Date: Fri, 28 Mar 2008 13:16:05 +0200 From: Alexander Shulikov MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=windows-1251 Content-Transfer-Encoding: QUOTED-PRINTABLE X-User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.8.1.13) Gecko/20080316 SUSE/2.0.0.13-1.1 Firefox/2.0.0.13 X-Sender-IP: 193.108.38.14 X-Mailer: I.UA Mail System Subject: Re: kern/121955: [ipfw] [panic] freebsd 7.0 panic with mpd X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 11:16:09 -0000 Trouble fixed by updating to FreeBSD 7.0-STABLE. Now: # uptime 1:14PM up 4:41, 2 users, load averages: 0.00, 0.00, 0.00 Let's look, that will be further. -- =F0=E5=EA=EB=E0=EC=E0 --------------------------------------------------= --------- =CD=E0=F3=F7=E8=EC =EA=E0=E6=E4=EE=E3=EE =E7=E0=F0=E0=E1=E0=F2=FB=E2=E0=F2= =FC =ED=E0 =EA=EE=EB=E5=E1=E0=ED=E8=FF=F5 =EA=F3=F0=F1=EE=E2 =E2=E0=EB=FE= =F2. =C7=E0=EF=E8=F1=FC =ED=E0 =E1=E5=F1=EF=EB=E0=F2=ED=FB=E9 =F1=E5=EC=E8=ED=E0= =F0 http://www.fxclub.org/condition_howtrade_freeseminar/ From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 28 17:51:21 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DF47106566B for ; Fri, 28 Mar 2008 17:51:21 +0000 (UTC) (envelope-from jay@jcornwall.me.uk) Received: from vps1.jcornwall.me.uk (vps1.jcornwall.me.uk [193.227.111.74]) by mx1.freebsd.org (Postfix) with ESMTP id 2088A8FC18 for ; Fri, 28 Mar 2008 17:51:21 +0000 (UTC) (envelope-from jay@jcornwall.me.uk) Received: from [82.70.152.17] (82-70-152-17.dsl.in-addr.zen.co.uk [82.70.152.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vps1.jcornwall.me.uk (Postfix) with ESMTP id B824B520037 for ; Fri, 28 Mar 2008 17:35:53 +0000 (GMT) Message-ID: <47ED2C79.5080601@jcornwall.me.uk> Date: Fri, 28 Mar 2008 17:35:53 +0000 From: "Jay L. T. Cornwall" User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: IPFW / if_bridge / NAT X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 17:51:21 -0000 Hi, I have a FreeBSD 7.0 machine bridging two segments of a network: vr0 <---> bridge0 <---> vr1 bridge0 has both unregistered and public IP aliases. In addition to bridging, I need the machine to perform NAT on packets originating from an unregistered subnet (192.168.1.0/24) outbound on interface vr1 to a public IP and back again. No NAT'ing should occur behind vr1. I initially tried to set this up with ipfw diverting packets to natd like this: divert natd any from any to any via vr1 This seemed to NAT packets outbound correctly, but the replies were never NAT'd back to the private IPs. I believe the presence of the bridge affects ipfw's ability to divert the appropriate packets. This configuration partly works: divert natd any from 192.168.1.0/24 to any divert natd any from any to However NAT'ing then predictably occurs behind interface vr1 which causes internal routing problems. None of my attempts to NAT directly on the bridge0 interface managed to perform any packet rewriting at all. This may be a problem with my sysctl settings, many of which I'm unsure about: net.link.bridge.pfil_onlyip: 0 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.ipfw: 0 net.link.bridge.ipfw_arp: 0 net.inet.ip.fw.one_pass: 1 Is anyone able to suggest a IPFW/bridge/configuration that will NAT only across the vr1 interface of the if_bridged network? Thanks, -- Jay L. T. Cornwall http://www.jcornwall.me.uk/ From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 28 19:45:32 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7843106564A for ; Fri, 28 Mar 2008 19:45:32 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id B6BC68FC19 for ; Fri, 28 Mar 2008 19:45:32 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id DAA1B1A0007B0 for ; Fri, 28 Mar 2008 12:13:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id D4p7s4LL3EFo for ; Fri, 28 Mar 2008 12:13:28 -0700 (PDT) Received: from coal.local (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 74EFE1A00D30E for ; Fri, 28 Mar 2008 11:18:21 -0700 (PDT) From: Freddie Cash Organization: School District 73 To: freebsd-ipfw@freebsd.org Date: Fri, 28 Mar 2008 11:18:20 -0700 User-Agent: KMail/1.9.7 References: <47ED2C79.5080601@jcornwall.me.uk> In-Reply-To: <47ED2C79.5080601@jcornwall.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803281118.20653.fjwcash@gmail.com> Subject: Re: IPFW / if_bridge / NAT X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 19:45:32 -0000 On March 28, 2008 10:35 am Jay L. T. Cornwall wrote: > Hi, > > I have a FreeBSD 7.0 machine bridging two segments of a network: > > vr0 <---> bridge0 <---> vr1 > > bridge0 has both unregistered and public IP aliases. In addition to > bridging, I need the machine to perform NAT on packets originating from > an unregistered subnet (192.168.1.0/24) outbound on interface vr1 to a > public IP and back again. No NAT'ing should occur behind vr1. > > I initially tried to set this up with ipfw diverting packets to natd > like this: > divert natd any from any to any via vr1 > > This seemed to NAT packets outbound correctly, but the replies were > never NAT'd back to the private IPs. I believe the presence of the > bridge affects ipfw's ability to divert the appropriate packets. This > configuration partly works: > divert natd any from 192.168.1.0/24 to any > divert natd any from any to Have you tried restricting your rules to only the vr1 interfaces, with configured directly on vr1: divert natd ip from 192.168.1.0/24 to any out xmit vr1 divert natd ip from any to in recv vr1 -- Freddie Cash fjwcash@gmail.com From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 28 21:27:29 2008 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 458D7106566C for ; Fri, 28 Mar 2008 21:27:29 +0000 (UTC) (envelope-from jay@jcornwall.me.uk) Received: from vps1.jcornwall.me.uk (vps1.jcornwall.me.uk [193.227.111.74]) by mx1.freebsd.org (Postfix) with ESMTP id 09D968FC1E for ; Fri, 28 Mar 2008 21:27:28 +0000 (UTC) (envelope-from jay@jcornwall.me.uk) Received: from [82.70.152.17] (82-70-152-17.dsl.in-addr.zen.co.uk [82.70.152.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vps1.jcornwall.me.uk (Postfix) with ESMTP id D0953520037 for ; Fri, 28 Mar 2008 21:27:27 +0000 (GMT) Message-ID: <47ED62BF.4070100@jcornwall.me.uk> Date: Fri, 28 Mar 2008 21:27:27 +0000 From: "Jay L. T. Cornwall" User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <47ED2C79.5080601@jcornwall.me.uk> <200803281118.20653.fjwcash@gmail.com> In-Reply-To: <200803281118.20653.fjwcash@gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: IPFW / if_bridge / NAT X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 21:27:29 -0000 Freddie Cash wrote: >> This seemed to NAT packets outbound correctly, but the replies were >> never NAT'd back to the private IPs. I believe the presence of the >> bridge affects ipfw's ability to divert the appropriate packets. This >> configuration partly works: >> divert natd any from 192.168.1.0/24 to any >> divert natd any from any to > Have you tried restricting your rules to only the vr1 interfaces, with > configured directly on vr1: > > divert natd ip from 192.168.1.0/24 to any out xmit vr1 > divert natd ip from any to in recv vr1 Ah, there are recv/xmit semantics as well as in/out. I need to read the man page more thoroughly! However, this doesn't seem to work. It has the same symptoms as a single 'any to any via vr1' diversion: outbound packets are rewritten correctly (verified at the destination) but the replies are never rewritten. 00601 3 180 divert 8668 ip from 192.168.1.0/24 to any out xmit vr1 00602 0 0 divert 8668 ip from any to in recv vr1 Nothing ever reaches the second rule. I think the bridge changes ipfw filtering properties, because the simple 'any to any via vr1' is mentioned a lot in the literature. It just doesn't work here? -- Jay L. T. Cornwall http://www.jcornwall.me.uk/