From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 15 11:08:14 2007 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.org Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3DE916A5BC for ; Mon, 15 Jan 2007 11:08:14 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id A7E6A13C44B for ; Mon, 15 Jan 2007 11:08:14 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l0FB8EoQ031725 for ; Mon, 15 Jan 2007 11:08:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0FB8Dtp031721 for freebsd-ipfw@FreeBSD.org; Mon, 15 Jan 2007 11:08:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Jan 2007 11:08:13 GMT Message-Id: <200701151108.l0FB8Dtp031721@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 15 Jan 2007 11:08:14 -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 conf/78762 ipfw [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewal o bin/80913 ipfw [patch] /sbin/ipfw2 silently discards MAC addr arg wit o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 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] add a facility to modify DF bit of the o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet 14 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] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port 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 kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature 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 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 20 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 15 12:40:25 2007 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1807C16A47C for ; Mon, 15 Jan 2007 12:40:25 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id EECC513C45A for ; Mon, 15 Jan 2007 12:40:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l0FCeNks042058 for ; Mon, 15 Jan 2007 12:40:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0FCeNUV042057; Mon, 15 Jan 2007 12:40:23 GMT (envelope-from gnats) Date: Mon, 15 Jan 2007 12:40:23 GMT Message-Id: <200701151240.l0FCeNUV042057@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Olexandr Davydenko Cc: Subject: Re: kern/106534: [ipfw] [panic] ipfw + dummynet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Olexandr Davydenko List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 12:40:25 -0000 The following reply was made to PR kern/106534; it has been noted by GNATS. From: Olexandr Davydenko To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/106534: [ipfw] [panic] ipfw + dummynet Date: Mon, 15 Jan 2007 14:20:22 +0200 Similar problem with ipfw + dummynet and 132 pipes for traffic shaping: sometimes panic when trafshow run and put interface in promiscuous mode or in any another time. FreeBSD 6.1-RELEASE-p10 #1: Wed Oct 4 12:46:05 EEST 2006 root@xxx:/server/OBJ/server/SRC/RELENG_6_1/sys/xxx # ifconfig fxp0: flags=8843 mtu 1500 options=48 ether 00:90:27:10:33:b4 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8843 mtu 1500 options=48 ether 00:30:48:22:58:79 media: Ethernet 100baseTX status: active fxp2: flags=8843 mtu 1500 options=48 ether 00:30:48:22:58:7a media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 kgdb output: 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 trap 12: page fault while in kernel mode fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc0516ffb stack pointer = 0x28:0xcbd36b60 frame pointer = 0x28:0xcbd36b84 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 (swi4: clock sio) trap number = 12 panic: page fault Uptime: 29d17h3m30s Dumping 254 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 254MB (65024 pages) 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04e1b65 in boot (howto=260) at /server/SRC/RELENG_6_1/sys/kern/kern_shutdown.c:402 #2 0xc04e1dfc in panic (fmt=0xc063e3b0 "%s") at /server/SRC/RELENG_6_1/sys/kern/kern_shutdown.c:558 #3 0xc06254fc in trap_fatal (frame=0xcbd36b20, eva=12) at /server/SRC/RELENG_6_1/sys/i386/i386/trap.c:836 #4 0xc0625263 in trap_pfault (frame=0xcbd36b20, usermode=0, eva=12) at /server/SRC/RELENG_6_1/sys/i386/i386/trap.c:744 #5 0xc0624ec1 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1014294700, tf_esi = 320, tf_ebp = -875336828, tf_isp = -875336884, tf_ebx = -1014294784, tf_edx = 0, tf_ecx = -1026586592, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068404741, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -875336824}) at /server/SRC/RELENG_6_1/sys/i386/i386/trap.c:434 #6 0xc06153ba in calltrap () at /server/SRC/RELENG_6_1/sys/i386/i386/exception.s:139 #7 0xc0516ffb in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /server/SRC/RELENG_6_1/sys/kern/uipc_mbuf.c:400 #8 0xc056bff8 in ip_fragment (ip=0xc2cf8820, m_frag=0xcbd36c3c, mtu=-1014294784, if_hwassist_flags=0, sw_csum=1) at /server/SRC/RELENG_6_1/sys/netinet/ip_output.c:975 #9 0xc056bc9e in ip_output (m=0xc33a1c00, opt=0xc1d8e000, ro=0xcbd36c08, flags=1, imo=0x0, inp=0x0) at /server/SRC/RELENG_6_1/sys/netinet/ip_output.c:804 #10 0xc055ef71 in dummynet_send (m=0xc33a1c00) at /server/SRC/RELENG_6_1/sys/netinet/ip_dummynet.c:771 #11 0xc055ef04 in dummynet (unused=0x0) at /server/SRC/RELENG_6_1/sys/netinet/ip_dummynet.c:753 #12 0xc04edc97 in softclock (dummy=0x0) at /server/SRC/RELENG_6_1/sys/kern/kern_timeout.c:290 #13 0xc04cc391 in ithread_execute_handlers (p=0xc1d97830, ie=0xc1d95600) at /server/SRC/RELENG_6_1/sys/kern/kern_intr.c:684 #14 0xc04cc4a8 in ithread_loop (arg=0xc1d83780) at /server/SRC/RELENG_6_1/sys/kern/kern_intr.c:767 #15 0xc04cb300 in fork_exit (callout=0xc04cc454 , arg=0xc1d83780, frame=0xcbd36d38) at /server/SRC/RELENG_6_1/sys/kern/kern_fork.c:805 #16 0xc061541c in fork_trampoline () at /server/SRC/RELENG_6_1/sys/i386/i386/exception.s:208 (kgdb) up 7 #7 0xc0516ffb in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /server/SRC/RELENG_6_1/sys/kern/uipc_mbuf.c:400 400 if (off < m->m_len) (kgdb) list 395 MBUF_CHECKSLEEP(wait); 396 if (off == 0 && m->m_flags & M_PKTHDR) 397 copyhdr = 1; 398 while (off > 0) { 399 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); 400 if (off < m->m_len) 401 break; 402 off -= m->m_len; 403 m = m->m_next; 404 } (kgdb) quit -- WBR, Davidenko Alexandr From owner-freebsd-ipfw@FreeBSD.ORG Tue Jan 16 16:40:52 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C67CF16A40F for ; Tue, 16 Jan 2007 16:40:52 +0000 (UTC) (envelope-from tony@crosswinds.net) Received: from out-mx1.crosswinds.net (out-mx1.crosswinds.net [216.18.117.38]) by mx1.freebsd.org (Postfix) with ESMTP id A58A913C45D for ; Tue, 16 Jan 2007 16:40:52 +0000 (UTC) (envelope-from tony@crosswinds.net) Received: from admin.crosswinds.net (out-mx1.crosswinds.net [216.18.117.38]) by out-mx1.crosswinds.net (Postfix) with ESMTP id C08C92E722 for ; Tue, 16 Jan 2007 11:21:13 -0500 (EST) Received: by admin.crosswinds.net (Postfix, from userid 1001) id B691C403D; Tue, 16 Jan 2007 11:21:13 -0500 (EST) Date: Tue, 16 Jan 2007 11:21:13 -0500 From: Tony Holmes To: freebsd-ipfw@freebsd.org Message-ID: <20070116162113.GA29639@crosswinds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Forwarding with Packet Rewriting 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, 16 Jan 2007 16:40:52 -0000 Hi all, I have what should be a simple problem but due to lack of sleep I can't get it and need a solution asap. I have a freebsd 4.11 firewall with ipfw and divert/natd in it. All I want to do is rewrite packets destined to IP a.b.c.d 25 to IP a.b.c.e 25 and rewrite them on the way out. a.b.c.d and a.b.c.e are not on the local machines - but are on the local subnets. NATD is looking to use the local interface and that's where my tiredness is coming in. How can I do a simple tranparent rewrite like that. -- Tony Holmes Ph: (416) 993-1219 Founder and Senior Systems Architect Crosswinds Internet Communications Inc. From owner-freebsd-ipfw@FreeBSD.ORG Tue Jan 16 19:26:48 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C999216A407 for ; Tue, 16 Jan 2007 19:26:48 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id B287E13C465 for ; Tue, 16 Jan 2007 19:26:48 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l0GILX5H025691; Tue, 16 Jan 2007 10:21:33 -0800 (PST) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id C21B61009A; Tue, 16 Jan 2007 10:21:33 -0800 (PST) X-AuditID: 11807124-a44eebb000006d75-0e-45ad17adf52e Received: from [17.214.13.96] (unknown [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay6.apple.com (Apple SCV relay) with ESMTP id AD67810085; Tue, 16 Jan 2007 10:21:33 -0800 (PST) In-Reply-To: <20070116162113.GA29639@crosswinds.net> References: <20070116162113.GA29639@crosswinds.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 16 Jan 2007 10:21:33 -0800 To: Tony Holmes X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-ipfw@freebsd.org Subject: Re: Forwarding with Packet Rewriting 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, 16 Jan 2007 19:26:48 -0000 On Jan 16, 2007, at 8:21 AM, Tony Holmes wrote: > I have a freebsd 4.11 firewall with ipfw and divert/natd in it. > > All I want to do is rewrite packets destined to IP a.b.c.d 25 to > IP a.b.c.e 25 and rewrite them on the way out. a.b.c.d and a.b.c.e > are not on the local machines - but are on the local subnets. If you are dealing with external connections to a.b.c.d which pass through the router running IPFW & natd, then you want to use the redirect_address directive (see "man natd"). If a.b.c isn't one of the RFC-1918 unroutable subnets, but a normal routable IP, you'll have to also toggle the unregistered_only option. On the other hand, if you are trying to deal with subnet-local traffic which does not need to pass through the IPFW/natd router, then you'll either need to use ICMP redirects to indicate that traffic to the old IP should go to the new IP (if you are not using the old IP anymore and no machine will go there until you fix whatever uses the old IP to use the new IP instead). If you have machines at both a.b.c.d & a.b.c.e *and* a.b.c.d is not running anything on port 25, you can use SSH port forwarding, netcat, or something like the plug-gw port forwarding mechanisms to forward the traffic over. If you have machines at both a.b.c.d & a.b.c.e and both are listening on port 25, and the traffic is local, then I don't know of any solution short of changing the callers to use the new IP. -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Tue Jan 16 19:48:52 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 642BC16A412 for ; Tue, 16 Jan 2007 19:48:52 +0000 (UTC) (envelope-from aronesimi@yahoo.com) Received: from web58611.mail.re3.yahoo.com (web58611.mail.re3.yahoo.com [68.142.236.209]) by mx1.freebsd.org (Postfix) with SMTP id 1736113C448 for ; Tue, 16 Jan 2007 19:48:51 +0000 (UTC) (envelope-from aronesimi@yahoo.com) Received: (qmail 70875 invoked by uid 60001); 16 Jan 2007 19:22:10 -0000 Message-ID: <20070116192210.70873.qmail@web58611.mail.re3.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=hLSQeud79OOP2/x16WnDl5RpqoS+xppAiG46l26+s3flWaiyS1p4YPWWJbUg/z3xr4+RW/U8+WsaxQO55oLn5CwS2RxermpGrZzCpBCDdZlHoeR2jBSHgTUHsqhVBOhVTpJEQVsV6IzdtwWDg6JVEVRh1CPeV8Mdiobg+KX/CIA=; X-YMail-OSG: 7xuA3SgVM1n3SuZMhgTtBGq1PHkGxGF3pKxIVKcb Received: from [69.146.20.104] by web58611.mail.re3.yahoo.com via HTTP; Tue, 16 Jan 2007 11:22:10 PST Date: Tue, 16 Jan 2007 11:22:10 -0800 (PST) From: Arone Silimantia To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 16 Jan 2007 22:18:20 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: "proper" method of changing dummynet limit ? 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, 16 Jan 2007 19:48:52 -0000 Hello, I currently implement a dummynet rate limit, after boot up, with this sequence: sysctl -w net.inet.ip.fw.one_pass=0 ipfw pipe 1 config bw 10Mbit/s ipfw add 10000 pipe 1 all from any to any Easy. My question is, if I want to change the rate from 10 Mbit/s to 20 Mbit/s, do I just reissue the 'ipfw pipe' command: ipfw pipe 1 config bw 20Mbit/s while leaving the ipf rule in place ? Or should I tear down rule 10000 first, and tear down the pipe, and start from scratch ? Is it safe to just reissue the pipe command on the fly like that ? --------------------------------- Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster. From owner-freebsd-ipfw@FreeBSD.ORG Tue Jan 16 23:31:19 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D29A016A494 for ; Tue, 16 Jan 2007 23:31:19 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 40D6813C441 for ; Tue, 16 Jan 2007 23:31:19 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.8/8.13.8) with ESMTP id l0GN0dVr083966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jan 2007 02:00:39 +0300 (MSK) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.8/8.13.8/Submit) id l0GN0dmp083965; Wed, 17 Jan 2007 02:00:39 +0300 (MSK) (envelope-from oleg) Date: Wed, 17 Jan 2007 02:00:39 +0300 From: Oleg Bulyzhin To: Olexandr Davydenko Message-ID: <20070116230039.GA83503@lath.rinet.ru> References: <200701151240.l0FCeNUV042057@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701151240.l0FCeNUV042057@freefall.freebsd.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-ipfw@freebsd.org Subject: Re: kern/106534: [ipfw] [panic] ipfw + dummynet 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, 16 Jan 2007 23:31:19 -0000 On Mon, Jan 15, 2007 at 12:40:23PM +0000, Olexandr Davydenko wrote: > The following reply was made to PR kern/106534; it has been noted by GNATS. > > From: Olexandr Davydenko > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/106534: [ipfw] [panic] ipfw + dummynet > Date: Mon, 15 Jan 2007 14:20:22 +0200 > > Similar problem with ipfw + dummynet and 132 pipes for traffic shaping: > sometimes panic when trafshow run and put interface in promiscuous > mode or in any another time. > > FreeBSD 6.1-RELEASE-p10 #1: Wed Oct 4 12:46:05 EEST 2006 > root@xxx:/server/OBJ/server/SRC/RELENG_6_1/sys/xxx > > # ifconfig > fxp0: flags=8843 mtu 1500 > options=48 > ether 00:90:27:10:33:b4 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=8843 mtu 1500 > options=48 > ether 00:30:48:22:58:79 > media: Ethernet 100baseTX > status: active > fxp2: flags=8843 mtu 1500 > options=48 > ether 00:30:48:22:58:7a > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > kgdb output: > 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 trap 12: page fault while in kernel mode > fault virtual address = 0xc > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0516ffb > stack pointer = 0x28:0xcbd36b60 > frame pointer = 0x28:0xcbd36b84 > 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 (swi4: clock sio) > trap number = 12 > panic: page fault > Uptime: 29d17h3m30s > Dumping 254 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 254MB (65024 pages) 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:165 > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc04e1b65 in boot (howto=260) at /server/SRC/RELENG_6_1/sys/kern/kern_shutdown.c:402 > #2 0xc04e1dfc in panic (fmt=0xc063e3b0 "%s") at /server/SRC/RELENG_6_1/sys/kern/kern_shutdown.c:558 > #3 0xc06254fc in trap_fatal (frame=0xcbd36b20, eva=12) at /server/SRC/RELENG_6_1/sys/i386/i386/trap.c:836 > #4 0xc0625263 in trap_pfault (frame=0xcbd36b20, usermode=0, eva=12) > at /server/SRC/RELENG_6_1/sys/i386/i386/trap.c:744 > #5 0xc0624ec1 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1014294700, tf_esi = 320, tf_ebp = -875336828, tf_isp = -875336884, tf_ebx = -1014294784, tf_edx = 0, tf_ecx = -1026586592, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068404741, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -875336824}) > at /server/SRC/RELENG_6_1/sys/i386/i386/trap.c:434 > #6 0xc06153ba in calltrap () at /server/SRC/RELENG_6_1/sys/i386/i386/exception.s:139 > #7 0xc0516ffb in m_copym (m=0x0, off0=1500, len=1480, wait=1) > at /server/SRC/RELENG_6_1/sys/kern/uipc_mbuf.c:400 > #8 0xc056bff8 in ip_fragment (ip=0xc2cf8820, m_frag=0xcbd36c3c, mtu=-1014294784, if_hwassist_flags=0, > sw_csum=1) at /server/SRC/RELENG_6_1/sys/netinet/ip_output.c:975 > #9 0xc056bc9e in ip_output (m=0xc33a1c00, opt=0xc1d8e000, ro=0xcbd36c08, flags=1, imo=0x0, inp=0x0) > at /server/SRC/RELENG_6_1/sys/netinet/ip_output.c:804 > #10 0xc055ef71 in dummynet_send (m=0xc33a1c00) at /server/SRC/RELENG_6_1/sys/netinet/ip_dummynet.c:771 > #11 0xc055ef04 in dummynet (unused=0x0) at /server/SRC/RELENG_6_1/sys/netinet/ip_dummynet.c:753 > #12 0xc04edc97 in softclock (dummy=0x0) at /server/SRC/RELENG_6_1/sys/kern/kern_timeout.c:290 > #13 0xc04cc391 in ithread_execute_handlers (p=0xc1d97830, ie=0xc1d95600) > at /server/SRC/RELENG_6_1/sys/kern/kern_intr.c:684 > #14 0xc04cc4a8 in ithread_loop (arg=0xc1d83780) at /server/SRC/RELENG_6_1/sys/kern/kern_intr.c:767 > #15 0xc04cb300 in fork_exit (callout=0xc04cc454 , arg=0xc1d83780, frame=0xcbd36d38) > at /server/SRC/RELENG_6_1/sys/kern/kern_fork.c:805 > #16 0xc061541c in fork_trampoline () at /server/SRC/RELENG_6_1/sys/i386/i386/exception.s:208 > (kgdb) up 7 > #7 0xc0516ffb in m_copym (m=0x0, off0=1500, len=1480, wait=1) > at /server/SRC/RELENG_6_1/sys/kern/uipc_mbuf.c:400 > 400 if (off < m->m_len) > (kgdb) list > 395 MBUF_CHECKSLEEP(wait); > 396 if (off == 0 && m->m_flags & M_PKTHDR) > 397 copyhdr = 1; > 398 while (off > 0) { > 399 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); > 400 if (off < m->m_len) > 401 break; > 402 off -= m->m_len; > 403 m = m->m_next; > 404 } > (kgdb) quit > > > > -- > WBR, > Davidenko Alexandr > _______________________________________________ > 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" As i can see kernel dies trying to fit packet into interface with negative mtu. Would be fine to dump ro->ro_rt->rt_ifp structure. (Do some 'up' commands until you are in ip_output, then print ro->ro_rt->rt_ifp). -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 17 16:13:35 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B74016A412 for ; Wed, 17 Jan 2007 16:13:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id C355613C4B7 for ; Wed, 17 Jan 2007 16:13:34 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l0HFx82A001537; Wed, 17 Jan 2007 09:59:09 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l0HFx8F8001536; Wed, 17 Jan 2007 09:59:08 -0600 (CST) (envelope-from brooks) Date: Wed, 17 Jan 2007 09:59:08 -0600 From: Brooks Davis To: Arone Silimantia Message-ID: <20070117155908.GA1333@lor.one-eyed-alien.net> References: <20070116192210.70873.qmail@web58611.mail.re3.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <20070116192210.70873.qmail@web58611.mail.re3.yahoo.com> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 17 Jan 2007 09:59:09 -0600 (CST) Cc: freebsd-ipfw@freebsd.org Subject: Re: "proper" method of changing dummynet limit ? 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, 17 Jan 2007 16:13:35 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 16, 2007 at 11:22:10AM -0800, Arone Silimantia wrote: > Hello, >=20 > I currently implement a dummynet rate limit, after boot up, with this seq= uence: >=20 > sysctl -w net.inet.ip.fw.one_pass=3D0 > ipfw pipe 1 config bw 10Mbit/s > ipfw add 10000 pipe 1 all from any to any >=20 > Easy. >=20 > My question is, if I want to change the rate from 10 Mbit/s to 20 Mbit/s,= do I just reissue the 'ipfw pipe' command: >=20 > ipfw pipe 1 config bw 20Mbit/s >=20 > while leaving the ipf rule in place ? Or should I tear down rule 10000 f= irst, and tear down the pipe, and start from scratch ? >=20 > Is it safe to just reissue the pipe command on the fly like that ? Just changing the pipe config works for me on a mirror server that updates the max inbound bandwidth hourly. -- Brooks --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFrkfMXY6L6fI4GtQRAqifAKDflF+yDqgYh3iT7LBknH4Tk+DeuQCgwz6h 6Gcu5bSExrd4wtbbvrOmEIE= =z05C -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 17 22:40:19 2007 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73BE516A521 for ; Wed, 17 Jan 2007 22:40:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id A3E4A13C45B for ; Wed, 17 Jan 2007 22:40:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l0HMeI2Q046887 for ; Wed, 17 Jan 2007 22:40:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0HMeIVN046886; Wed, 17 Jan 2007 22:40:18 GMT (envelope-from gnats) Date: Wed, 17 Jan 2007 22:40:18 GMT Message-Id: <200701172240.l0HMeIVN046886@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Oleg Bulyzhin Cc: Subject: Re: kern/106534: [ipfw] [panic] ipfw + dummynet X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oleg Bulyzhin List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 22:40:19 -0000 The following reply was made to PR kern/106534; it has been noted by GNATS. From: Oleg Bulyzhin To: Olexandr Davydenko Cc: freebsd-ipfw@freebsd.org Subject: Re: kern/106534: [ipfw] [panic] ipfw + dummynet Date: Wed, 17 Jan 2007 02:00:39 +0300 On Mon, Jan 15, 2007 at 12:40:23PM +0000, Olexandr Davydenko wrote: > The following reply was made to PR kern/106534; it has been noted by GNATS. > > From: Olexandr Davydenko > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/106534: [ipfw] [panic] ipfw + dummynet > Date: Mon, 15 Jan 2007 14:20:22 +0200 > > Similar problem with ipfw + dummynet and 132 pipes for traffic shaping: > sometimes panic when trafshow run and put interface in promiscuous > mode or in any another time. > > FreeBSD 6.1-RELEASE-p10 #1: Wed Oct 4 12:46:05 EEST 2006 > root@xxx:/server/OBJ/server/SRC/RELENG_6_1/sys/xxx > > # ifconfig > fxp0: flags=8843 mtu 1500 > options=48 > ether 00:90:27:10:33:b4 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=8843 mtu 1500 > options=48 > ether 00:30:48:22:58:79 > media: Ethernet 100baseTX > status: active > fxp2: flags=8843 mtu 1500 > options=48 > ether 00:30:48:22:58:7a > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > kgdb output: > 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 trap 12: page fault while in kernel mode > fault virtual address = 0xc > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0516ffb > stack pointer = 0x28:0xcbd36b60 > frame pointer = 0x28:0xcbd36b84 > 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 (swi4: clock sio) > trap number = 12 > panic: page fault > Uptime: 29d17h3m30s > Dumping 254 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 254MB (65024 pages) 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:165 > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc04e1b65 in boot (howto=260) at /server/SRC/RELENG_6_1/sys/kern/kern_shutdown.c:402 > #2 0xc04e1dfc in panic (fmt=0xc063e3b0 "%s") at /server/SRC/RELENG_6_1/sys/kern/kern_shutdown.c:558 > #3 0xc06254fc in trap_fatal (frame=0xcbd36b20, eva=12) at /server/SRC/RELENG_6_1/sys/i386/i386/trap.c:836 > #4 0xc0625263 in trap_pfault (frame=0xcbd36b20, usermode=0, eva=12) > at /server/SRC/RELENG_6_1/sys/i386/i386/trap.c:744 > #5 0xc0624ec1 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1014294700, tf_esi = 320, tf_ebp = -875336828, tf_isp = -875336884, tf_ebx = -1014294784, tf_edx = 0, tf_ecx = -1026586592, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068404741, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -875336824}) > at /server/SRC/RELENG_6_1/sys/i386/i386/trap.c:434 > #6 0xc06153ba in calltrap () at /server/SRC/RELENG_6_1/sys/i386/i386/exception.s:139 > #7 0xc0516ffb in m_copym (m=0x0, off0=1500, len=1480, wait=1) > at /server/SRC/RELENG_6_1/sys/kern/uipc_mbuf.c:400 > #8 0xc056bff8 in ip_fragment (ip=0xc2cf8820, m_frag=0xcbd36c3c, mtu=-1014294784, if_hwassist_flags=0, > sw_csum=1) at /server/SRC/RELENG_6_1/sys/netinet/ip_output.c:975 > #9 0xc056bc9e in ip_output (m=0xc33a1c00, opt=0xc1d8e000, ro=0xcbd36c08, flags=1, imo=0x0, inp=0x0) > at /server/SRC/RELENG_6_1/sys/netinet/ip_output.c:804 > #10 0xc055ef71 in dummynet_send (m=0xc33a1c00) at /server/SRC/RELENG_6_1/sys/netinet/ip_dummynet.c:771 > #11 0xc055ef04 in dummynet (unused=0x0) at /server/SRC/RELENG_6_1/sys/netinet/ip_dummynet.c:753 > #12 0xc04edc97 in softclock (dummy=0x0) at /server/SRC/RELENG_6_1/sys/kern/kern_timeout.c:290 > #13 0xc04cc391 in ithread_execute_handlers (p=0xc1d97830, ie=0xc1d95600) > at /server/SRC/RELENG_6_1/sys/kern/kern_intr.c:684 > #14 0xc04cc4a8 in ithread_loop (arg=0xc1d83780) at /server/SRC/RELENG_6_1/sys/kern/kern_intr.c:767 > #15 0xc04cb300 in fork_exit (callout=0xc04cc454 , arg=0xc1d83780, frame=0xcbd36d38) > at /server/SRC/RELENG_6_1/sys/kern/kern_fork.c:805 > #16 0xc061541c in fork_trampoline () at /server/SRC/RELENG_6_1/sys/i386/i386/exception.s:208 > (kgdb) up 7 > #7 0xc0516ffb in m_copym (m=0x0, off0=1500, len=1480, wait=1) > at /server/SRC/RELENG_6_1/sys/kern/uipc_mbuf.c:400 > 400 if (off < m->m_len) > (kgdb) list > 395 MBUF_CHECKSLEEP(wait); > 396 if (off == 0 && m->m_flags & M_PKTHDR) > 397 copyhdr = 1; > 398 while (off > 0) { > 399 KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); > 400 if (off < m->m_len) > 401 break; > 402 off -= m->m_len; > 403 m = m->m_next; > 404 } > (kgdb) quit > > > > -- > WBR, > Davidenko Alexandr > _______________________________________________ > 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" As i can see kernel dies trying to fit packet into interface with negative mtu. Would be fine to dump ro->ro_rt->rt_ifp structure. (Do some 'up' commands until you are in ip_output, then print ro->ro_rt->rt_ifp). -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ _______________________________________________ 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"