From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 01:48:09 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B61E106564A for ; Sun, 25 Apr 2010 01:48:09 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 29C018FC15 for ; Sun, 25 Apr 2010 01:48:08 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 0C285EC35C; Sat, 24 Apr 2010 21:48:08 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 24 Apr 2010 21:48:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=16Q6C7Q8vyNGPnIQOCvukAI/KX0=; b=X5Hugz7/Ndj8RGVqGnvtHP4Dzd62oMiisNiVEiQ/5kOWOmKiGISi2YGEiq3bOef05WNGtyGKQOkxLLbCkPchHtwZ4g62i5LvTl+v4IBYdDBd1tbDYsjwv5qKh6C1Yx9Cv8masMQ23kMVBlTTORxbvBIrwQUqB4TPRfTVV3B1dVI= X-Sasl-enc: tw7WIZ+vvFPpfkFL8/sU6HWCd1TZx3hePu/malr3kdSB 1272160087 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 960CD49593; Sat, 24 Apr 2010 21:48:07 -0400 (EDT) Message-ID: <4BD39F55.9040600@incunabulum.net> Date: Sun, 25 Apr 2010 02:48:05 +0100 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100406 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jake Baillie References: <0D51275610C0C04588FA911C811B687E02A51E50@be18.exg4.exghost.com> In-Reply-To: <0D51275610C0C04588FA911C811B687E02A51E50@be18.exg4.exghost.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: Traverse Solos 4-port ADSL card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 01:48:09 -0000 The way these things generally work is they have an ADSL2+ MAC in front, and a Realtek-like Ethernet chip on the PCI bus, with a little microcontroller and web interface. The multi-port ones don't; generally they use native encap. A Linux driver will certainly not work and need to be rewritten for BSD netnatm. I'm surprised the original vendor don't ship a BSD driver. It's difficult to spec out a project like this without looking at the driver. cheers BMS From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 16:55:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 083091065675 for ; Sun, 25 Apr 2010 16:55:10 +0000 (UTC) (envelope-from frederic.perrin@resel.fr) Received: from maisel-gw.enst-bretagne.fr (maisel-gw.enst-bretagne.fr [192.44.76.8]) by mx1.freebsd.org (Postfix) with ESMTP id 93B158FC19 for ; Sun, 25 Apr 2010 16:55:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by maisel-gw.enst-bretagne.fr (Postfix) with ESMTP id CF9FE1980A for ; Sun, 25 Apr 2010 18:37:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at resel.fr Received: from maisel-gw.enst-bretagne.fr ([127.0.0.1]) by localhost (mercure.adm.maisel.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoY0O3vGVADs for ; Sun, 25 Apr 2010 18:36:57 +0200 (CEST) Received: from girafe.home (ARennes-258-1-90-183.w90-25.abo.wanadoo.fr [90.25.25.183]) (Authenticated sender: fperrin) by maisel-gw.enst-bretagne.fr (Postfix) with ESMTPSA id E2ED219809 for ; Sun, 25 Apr 2010 18:36:56 +0200 (CEST) Date: Sun, 25 Apr 2010 18:38:25 +0200 From: =?UTF-8?B?RnLDqWTDqXJpYw==?= Perrin To: freebsd-net@freebsd.org Message-ID: <20100425183825.2ee419d3@girafe.home> X-Mailer: Claws Mail 3.7.5cvs43 (GTK+ 2.18.7; i386-unknown-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: IPv6 aliases: one doesn't work, the other do X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 16:55:10 -0000 Hello, I have a box running 8.0-RELEASE on i386. It has several jails, each one being given an IPv6 alias. I notice that some jails can be reached from the outside, others can't. Conversely, if I set as the source address alias1, nothing comes back; it I set as the source address alias2, it works as expected. The following transcript may be clearer: This is happening on papillon, the host (meaning not a jail), after a fresh reboot. ,---- | root@papillon:~# grep 'ipv6\|vr0' < /etc/rc.conf | ifconfig_vr0=3D"inet 91.121.77.72 netmask 255.255.255.0 broadcast 91.121.= 77.255" | ifconfig_vr0_alias0=3D"87.98.132.43 netmask 255.255.255.255" | ifconfig_vr0_alias1=3D"188.165.50.152 netmask 255.255.255.255" | ipv6_enable=3D"YES" | ipv6_network_interfaces=3D"vr0" | ipv6_defaultrouter=3D"2001:41d0:1:82ff:ff:ff:ff:ff" | ipv6_ifconfig_vr0=3D"2001:41d0:1:8248::1 prefixlen 56" | ipv6_ifconfig_vr0_alias0=3D"2001:41d0:1:8248::2" | ipv6_ifconfig_vr0_alias1=3D"2001:41d0:1:8248::3" | ipv6_ifconfig_vr0_alias2=3D"2001:41d0:1:8248::4" | ipv6_ifconfig_vr0_alias3=3D"2001:41d0:1:8248::5" `---- benoute.fr is a friend's box, located in the same datacenter as mine. If I use as source address ::3 or ::5, I get no answer, with the other aliases it works as expected. ,---- | root@papillon:~# traceroute6 -n -s 2001:41d0:1:8248::3 mail.benoute.fr | traceroute6 to mail.benoute.fr (2001:41d0:1:c1d7::1) from 2001:41d0:1:824= 8::3, 64 hops max, 12 byte packets | 1 * * * | 2 * * * | 3 * * * | 4 * * * | 5 * * * | ^C | root@papillon:~# traceroute6 -n -s 2001:41d0:1:8248::4 mail.benoute.fr | traceroute6 to mail.benoute.fr (2001:41d0:1:c1d7::1) from 2001:41d0:1:824= 8::4, 64 hops max, 12 byte packets | 1 * * * | 2 2001:41d0:1:c1d7::1 0.396 ms 0.301 ms 0.296 ms `---- Same thing, but using renater.fr (a French ISP peering directly with the datacenter that hosts my box): ,---- | root@papillon:~# traceroute6 -n -s 2001:41d0:1:8248::4 www.renater.fr | traceroute6 to www.renater.fr (2001:660:3001:4002::10) from 2001:41d0:1:8= 248::4, 64 hops max, 12 byte packets | 1 * | 2001:41d0:1:82ff:ff:ff:ff:ff 5.882 ms * | 2 2001:41d0::592 150.251 ms 7.933 ms * | 3 2001:41d0::522 220.006 ms 230.797 ms 229.390 ms | 4 2001:7f8:4e:2::103 4.636 ms 5.934 ms 4.331 ms | 5 2001:660:7903:e:1::2 4.877 ms 4.525 ms 4.401 ms | 6 2001:660:7903:a:2::2 4.387 ms 4.375 ms 4.362 ms | 7 2001:660:3000:1008:10:0:6:5051 4.867 ms !P 4.825 ms !P 5.083 ms !P | root@papillon:~# traceroute6 -n -s 2001:41d0:1:8248::3 www.renater.fr | traceroute6 to www.renater.fr (2001:660:3001:4002::10) from 2001:41d0:1:8= 248::3, 64 hops max, 12 byte packets | 1 * * * | 2 * * * | 3 * * * | 4 * * * | 5 *^C `---- If I go to gadget (a Linux host with IPv6 connectivity), I can ping some aliases, but no others. The aliases that pong correctly are the same as the ones I can successfully use as source addresses in traceroute6 to remote hosts. A 'tcpdump -i vr0 icmp6' on papillon while this is happening show that no packet is seen by papillon. ,---- | fperrin@gadget:~$ for i in $( seq 5); do echo -n "$i - "; ping6 -c1 2001:= 41d0:8248::$i|grep loss; done | 1 - 1 packets transmitted, 1 received, 0% packet loss, time 0ms | 2 - 1 packets transmitted, 1 received, 0% packet loss, time 0ms | 3 - 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time = 0ms | 4 - 1 packets transmitted, 1 received, 0% packet loss, time 0ms | 5 - 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time = 0ms `---- Even if my life depended on it, I couldn't explain why some aliases work, and not others. The only difference that I can see is that they have different jails (::2 runs httpd+postgres, ::3 has no listening d=C3=A6mons, ::4 runs named, ::5 runs postfix). Any possible pointers? --=20 Fred From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 17:20:03 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB7D01065674 for ; Sun, 25 Apr 2010 17:20:03 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 496228FC0C for ; Sun, 25 Apr 2010 17:20:03 +0000 (UTC) Received: from delta.allbsd.org (p4178-ipbf1907funabasi.chiba.ocn.ne.jp [114.146.127.178]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o3PHJdnV061502; Mon, 26 Apr 2010 02:19:49 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o3PHJXbR011448; Mon, 26 Apr 2010 02:19:36 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 26 Apr 2010 02:18:48 +0900 (JST) Message-Id: <20100426.021848.65039126.hrs@allbsd.org> To: frederic.perrin@resel.fr From: Hiroki Sato In-Reply-To: <20100425183825.2ee419d3@girafe.home> References: <20100425183825.2ee419d3@girafe.home> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Apr_26_02_18_48_2010_991)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 26 Apr 2010 02:19:55 +0900 (JST) X-Spam-Status: No, score=2.0 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, FORGED_RCVD_IP, MIMEQENC, QENCPTR2, RCVD_IN_PBL, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: IPv6 aliases: one doesn't work, the other do X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 17:20:03 -0000 ----Security_Multipart(Mon_Apr_26_02_18_48_2010_991)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fr=E9d=E9ric Perrin wrote in <20100425183825.2ee419d3@girafe.home>: fr> Hello, fr> = fr> I have a box running 8.0-RELEASE on i386. It has several jails, eac= h fr> one being given an IPv6 alias. I notice that some jails can be reac= hed fr> from the outside, others can't. Conversely, if I set as the source fr> address alias1, nothing comes back; it I set as the source address fr> alias2, it works as expected. The following transcript may be clear= er: fr> = fr> This is happening on papillon, the host (meaning not a jail), after= a fr> fresh reboot. Did you get the same results of traceroute6 lines even before setting up the jails, or only after it? I am interested in whether this symptom appears or not when just adding IPv6 aliases to vr0 and no jail. -- Hiroki ----Security_Multipart(Mon_Apr_26_02_18_48_2010_991)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkvUeXgACgkQTyzT2CeTzy1mcwCgz0/gZWqCuYi6OIdDttv8552B IH8AoNZQhtB6QPX+n7OxsaeTCEfLPbvi =XSec -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Apr_26_02_18_48_2010_991)---- From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 19:05:40 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B856C1065670; Sun, 25 Apr 2010 19:05:40 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF288FC0C; Sun, 25 Apr 2010 19:05:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3PJ5eQ6036360; Sun, 25 Apr 2010 19:05:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3PJ5e49036356; Sun, 25 Apr 2010 19:05:40 GMT (envelope-from linimon) Date: Sun, 25 Apr 2010 19:05:40 GMT Message-Id: <201004251905.o3PJ5e49036356@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146037: [panic] mpd + CoA = kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 19:05:40 -0000 Old Synopsis: mpd+CoA=kernel panic New Synopsis: [panic] mpd + CoA = kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Apr 25 19:05:20 UTC 2010 Responsible-Changed-Why: seems to be networking-related. http://www.freebsd.org/cgi/query-pr.cgi?pr=146037 From owner-freebsd-net@FreeBSD.ORG Sun Apr 25 20:51:45 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB2B21065670 for ; Sun, 25 Apr 2010 20:51:44 +0000 (UTC) (envelope-from frederic.perrin@resel.fr) Received: from maisel-gw.enst-bretagne.fr (maisel-gw.enst-bretagne.fr [192.44.76.8]) by mx1.freebsd.org (Postfix) with ESMTP id 715518FC1A for ; Sun, 25 Apr 2010 20:51:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by maisel-gw.enst-bretagne.fr (Postfix) with ESMTP id 76C5E1980A; Sun, 25 Apr 2010 22:51:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at resel.fr Received: from maisel-gw.enst-bretagne.fr ([127.0.0.1]) by localhost (mercure.adm.maisel.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su+z+juiwdBC; Sun, 25 Apr 2010 22:51:37 +0200 (CEST) Received: from girafe.home (ARennes-258-1-90-183.w90-25.abo.wanadoo.fr [90.25.25.183]) (Authenticated sender: fperrin) by maisel-gw.enst-bretagne.fr (Postfix) with ESMTPSA id 4DCAB19809; Sun, 25 Apr 2010 22:51:37 +0200 (CEST) Date: Sun, 25 Apr 2010 22:52:56 +0200 From: =?UTF-8?B?RnLDqWTDqXJpYw==?= Perrin To: Hiroki Sato , freebsd-net@FreeBSD.org Message-ID: <20100425225256.26ce3373@girafe.home> In-Reply-To: <20100426.021848.65039126.hrs@allbsd.org> References: <20100425183825.2ee419d3@girafe.home> <20100426.021848.65039126.hrs@allbsd.org> X-Mailer: Claws Mail 3.7.5cvs43 (GTK+ 2.18.7; i386-unknown-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/_bgvDHmkT0XuWKV8OIiEgqI"; protocol="application/pgp-signature" Cc: Subject: Re: IPv6 aliases: one doesn't work, the other do X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 20:51:45 -0000 --Sig_/_bgvDHmkT0XuWKV8OIiEgqI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le Lundi 26 =C3=A0 2:18, Hiroki Sato a =C3=A9crit : > Fr=C3=A9d=C3=A9ric Perrin wrote > in <20100425183825.2ee419d3@girafe.home>: >fr> I have a box running 8.0-RELEASE on i386. It has several jails, >fr> each one being given an IPv6 alias. I notice that some jails can >fr> be reached from the outside, others can't. Conversely, if I set >fr> as the source address alias1, nothing comes back; it I set as the >fr> source address alias2, it works as expected. The following >fr> transcript may be clearer: >fr>=20 >fr> This is happening on papillon, the host (meaning not a jail), >fr> after a fresh reboot. > > Did you get the same results of traceroute6 lines even before setting > up the jails, or only after it? I am interested in whether this > symptom appears or not when just adding IPv6 aliases to vr0 and no > jail. Sure. I just set ezjail_enable=3D"NO" and rebooted. And the result is... It looks like the aliases that don't work were juste shuffled around. (NB, in the previous run, the non-functionning aliases were ::3 and ::5. Now, only ::5 is broken. I seem to remember having issues with others, but as I don't use IPv6 very often, I didn't keep track of which aliases were working or not.) ,---- | papillon:~% traceroute6 -s 2001:41d0:1:8248::3 www.renater.fr=20 | traceroute6 to www.renater.fr (2001:660:3001:4002::10) from 2001:41d0:1:8= 248::3, 64 hops max, 12 byte packets | 1 2001:41d0:1:82ff:ff:ff:ff:ff 3.332 ms * 141.131 ms | 2 ipv6.th1-1-6k.routers.net 9.994 ms * 13.867 ms | 3 ipv6.th2-1-6k.routers.net 4.810 ms * 18.300 ms | 4 renater-th2.sfinx.tm.fr 5.476 ms 4.456 ms 4.232 ms | 5 te0-3-4-0-paris1-rtr-001.noc.renater.fr 4.670 ms 4.647 ms 4.450 ms | 6 te2-1-paris1-rtr-021.noc.renater.fr 4.412 ms 4.393 ms 4.353 ms | 7 gip-renater-vl300-gi8-15-paris1-rtr-021.noc.renater.fr 5.279 ms !P = 5.210 ms !P 5.190 ms !P | papillon:~% traceroute6 -n -s 2001:41d0:1:8248::5 www.renater.fr=20 | traceroute6 to www.renater.fr (2001:660:3001:4002::10) from 2001:41d0:1:8= 248::5, 64 hops max, 12 byte packets | 1 * * * | 2 * * * | 3 * * * | 4 * * * | ^C `---- And if I ping my server from a remote host (tweaked the ping6 options to have more samples while trying not to stress the network): ,---- | fperrin@gadget:~$ for i in $( seq 5); do echo -n "$i - "; ping6 -c10 -i30= 2001:41d0:1:8248::$i|grep loss; done | 1 - 10 packets transmitted, 10 received, 0% packet loss, time 270036ms | 2 - 10 packets transmitted, 10 received, 0% packet loss, time 270030ms | 3 - 10 packets transmitted, 10 received, 0% packet loss, time 270034ms | 4 - 10 packets transmitted, 10 received, 0% packet loss, time 270032ms | 5 - 10 packets transmitted, 0 received, +10 errors, 100% packet loss, tim= e 270030ms `---- I get the same results after starting the jails (with /usr/local/etc/rc.d/ezjail onestart). Oh, and keeping me in the Cc: list as you did is a good idea, I'm not subscribed to the list. --=20 Fred --Sig_/_bgvDHmkT0XuWKV8OIiEgqI Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvUq7IACgkQlSqR5GqTBENa7gCgx4Nn2qJ3m1bd55/161bcCxaI vhEAni/trb4h2+Y9MrX3U8SI0E7TNKYB =8+aT -----END PGP SIGNATURE----- --Sig_/_bgvDHmkT0XuWKV8OIiEgqI-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 04:38:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96FD51065673 for ; Mon, 26 Apr 2010 04:38:22 +0000 (UTC) (envelope-from gigabyte.tmn@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id A1E518FC16 for ; Mon, 26 Apr 2010 04:38:20 +0000 (UTC) Received: by ewy24 with SMTP id 24so3287468ewy.33 for ; Sun, 25 Apr 2010 21:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:cc:subject:mime-version:content-type :content-transfer-encoding; bh=frCVp/Pv+41imBubPHiG0yZqe3EqSYEC84TiC7if6t8=; b=D8pC7MpCJSGzQKFzbVaWG8SdI50IJHD3qOdyG5mdUvl4bAYign2NOkHDDcIrRHWNaT GzMhV1T/FNedKLLuXyaSQixQTvw/pFjQxtWlKCS0ehhiqLlSTqbCR38BXCqmHE7VaGWL a5hcKWlCY5xHhaoMLQ6bJauYs2SUl/vKF7nIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:cc:subject:mime-version :content-type:content-transfer-encoding; b=WPI7Mt7qUs9wMOvTb2Wvui9iDSQ0Gk/PWYh20177RUI9BJx8otI0BX4mELS4SSuN9u yt+PJ2b2buXq+P6EAPgV6NyVfOKnJJPgEu7t1nEUaxYlY7uRvrDXDbF1PYrEJvGWDOzK E7BeCuDjwFGM06k5kJnaE723OeAgwVjGQVtV4= Received: by 10.213.44.129 with SMTP id a1mr1885039ebf.37.1272256693777; Sun, 25 Apr 2010 21:38:13 -0700 (PDT) Received: from 93.dynamic-n38.in72.ru ([91.203.38.93]) by mx.google.com with ESMTPS id 16sm1823515ewy.3.2010.04.25.21.38.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Apr 2010 21:38:12 -0700 (PDT) Date: Mon, 26 Apr 2010 10:37:56 +0600 From: =?windows-1251?B?xOzo8vDo6SDH4Ozz8ODl4g==?= X-Priority: 3 (Normal) Message-ID: <324871118.20100426103756@gmail.com> To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: ukrzilla@gmail.com Subject: mpd+CoA=kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?xOzo8vDo6SDH4Ozz8ODl4g==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 04:38:22 -0000 How many traps you have? One? From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 06:11:29 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39946106566C for ; Mon, 26 Apr 2010 06:11:29 +0000 (UTC) (envelope-from gigabyte.tmn@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id BBA258FC12 for ; Mon, 26 Apr 2010 06:11:28 +0000 (UTC) Received: by ewy24 with SMTP id 24so3295552ewy.33 for ; Sun, 25 Apr 2010 23:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=0FnELo53jCjDbJne/mCbACbvmaBMl8P2RScQTaDSPNI=; b=j73KIIqrNv6fLE+sSiynamFsm+lK/J31T6gMmnwRbn4qpH5tS8+8YAbxuFKZC3JNcN j7pL/+p+HP01aIJR4kIpJici7q8RSrMxirqJf5y7dc5KixrSya3D/PzSdsqYceZQGKHR 1MgdHuXuTlcOSLzIaJxdeBWjopGo/j6Wx6QQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:cc:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=CNVfcQLfQdifEHH2R6ucc4c1m/7FGIa/y01dRRFiuyYli3hUr59iG1vPD4tJ+PouDm 3jxIycfrGrs6VXDEpLzdbzgYtSro57rSEK+hGRhPY5DR0XszK+FeheWDlvOI/N12NTGb PB4WcnUQf++SelqWVkyugkvYXtLulDOwHw250= Received: by 10.213.52.14 with SMTP id f14mr1394614ebg.49.1272262279274; Sun, 25 Apr 2010 23:11:19 -0700 (PDT) Received: from 93.dynamic-n38.in72.ru ([91.203.38.93]) by mx.google.com with ESMTPS id 15sm1862114ewy.12.2010.04.25.23.11.17 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Apr 2010 23:11:18 -0700 (PDT) Date: Mon, 26 Apr 2010 12:11:01 +0600 From: =?koi8-r?B?5M3J1NLJyiD6wc3V0sHF1w==?= X-Priority: 3 (Normal) Message-ID: <323546399.20100426121101@gmail.com> To: Denis Lamanov In-Reply-To: References: <324871118.20100426103756@gmail.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: mpd+CoA=kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?koi8-r?B?5M3J1NLJyiD6wc3V0sHF1w==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 06:11:29 -0000 And all traps points to ng= _path2noderef() ? DL> Many, every 2-3 days, 1 dump memory in FreeBSD 8.0-STABLE DL> dump memory in 7-STABLE I delete DL> Today will be more dump on VNP servers. DZ> How many traps you have? One? From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 08:21:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D2D51065670 for ; Mon, 26 Apr 2010 08:21:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 583AA8FC0C for ; Mon, 26 Apr 2010 08:21:26 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta04.emeryville.ca.mail.comcast.net with comcast id A8301e0021afHeLA488HsU; Mon, 26 Apr 2010 08:08:17 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.emeryville.ca.mail.comcast.net with comcast id A88G1e0033S48mS8d88Gvy; Mon, 26 Apr 2010 08:08:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2A7749B425; Mon, 26 Apr 2010 01:08:15 -0700 (PDT) Date: Mon, 26 Apr 2010 01:08:15 -0700 From: Jeremy Chadwick To: freebsd-rc@freebsd.org Message-ID: <20100426080815.GA41938@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org Subject: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 08:21:26 -0000 Foremost, sorry for the cross-post, but more eyes in this case means overall more discussion. Secondly, please keep me CC'd as I'm not on either -rc or -net. I recently proposed addition of a new script to the rc framework which verifies (using ping) that layer 3 network connectivity is up/functional before continuing on with daemons which require network access: http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html The overall response was positive, with full acknowledgement that this is indeed a hack -- yet necessary -- and that something more appropriate could probably be introduced into the base system to provide a much cleaner solution (launchd was mentioned). I'd like folks (particularly on -rc) to chime in here, and please see about adding this to the base system. Please note there's one typo in the script (a line which needs to be commented out) in my original post which I've since fixed in the version that's available via HTTP. Thank you! -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 08:39:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E42A91065677 for ; Mon, 26 Apr 2010 08:39:15 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp114.plus.mail.re1.yahoo.com (smtp114.plus.mail.re1.yahoo.com [69.147.102.77]) by mx1.freebsd.org (Postfix) with SMTP id 838028FC15 for ; Mon, 26 Apr 2010 08:39:15 +0000 (UTC) Received: (qmail 7165 invoked from network); 26 Apr 2010 08:12:35 -0000 Received: from [10.141.21.121] (se@80.187.149.48 with plain) by smtp114.plus.mail.re1.yahoo.com with SMTP; 26 Apr 2010 01:12:31 -0700 PDT X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: 4Z4wvW4VM1lFZcjXn.XL7cmr76RUFvNUuBbNFIu1iQ_Gd00 St19zCC46XnkOerZcd87PRuh0IiRy2SJg5G._DiiCNvvJMHpGIAkGS4v9x2T Gcl2Q1urv366CBmpMT3Mn4ZKRd_Z4aiQuTM68tBbFImdIhpttqpc2JLFJVpB 6tULHjIGwyv1rZdylgZjL.xkW0mRsiXaW3EQ4x6RMkFBbBA0HzMFLFfWLBIP Z7JgnKzNBVCpVCfgkmM8euySiMNzmf.NCXzwaEMFN31.hqFp_ewT6Z3cdpQ_ ac6hvaj0G96yDVNDZAWsGIIjXwhk9n1KP9lPNpah7VFaWTzCEUXiMDQK_Brv bRy_ct7hRwAGwNyqfm5uN.39a95HrV6o- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BD54AC7.7090301@FreeBSD.org> Date: Mon, 26 Apr 2010 10:11:51 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18 ThunderBrowse/3.2.2.1 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Marin Atanasov References: <4B28F841.1070900@skylinetele.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: "Li, Qing" , freebsd-stable@freebsd.org, "Prokofiev S.P." , freebsd-net@freebsd.org, Qing Li , freebsd-current@freebsd.org Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 08:39:16 -0000 Am 22.04.2010 20:43, schrieb Marin Atanasov: > Hello, > > Thanks a lot for the patch, Qing! > > It works fine. However I've noticed one thing, after I start mpd5 and > connect to my home network: > > kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize() > > Not very sure if this is something to worry about or not? There was a problem with the initialization order of network "domains", which caused kernel crashes with ISDN+INET6 some two years ago. The reason was, that there was an implicit assumption, that all domains were initialized when the network interfaces are initialized, with NULL dereferences if domains are added (and relevant to a device) after the device has been initialized. I debugged this problem and prepared a patch for discussion, which later was committed by Max Laier (if memory serves me right). The message was added in order to identify further situations, where network domains are added after network interfaces have been initialized. This message ought to be informational right now, since the interface init is repeated whenever a network domain is added as part of above mentioned patch. Init order should be fixed, if this message is printed for compiled in drivers, but in case of a kernel module (like netgraph) that adds a domain, it is unadvoidable that the init order is reversed. Perhaps the message should be made conditional on the start-up of the kernel not having finished, or it should be completely removed, since time has shown, that the init order is correct in general. I'll remove that message (or make it conditional on "bootverbose") unless there is opposition to this change ... Regards, STefan From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 08:59:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C8D6106564A for ; Mon, 26 Apr 2010 08:59:53 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 508BE8FC13 for ; Mon, 26 Apr 2010 08:59:52 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 283431856; Mon, 26 Apr 2010 10:59:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1272272388; x= 1274086788; bh=s2dqmsmP4aSwQFMGDx+dw/2/fpHSNH5+u7gnpii9kiI=; b=V 8WQI/YkCztRqdVGmvHlE768EoeEiW0uouVsw0pufswCehLtU9zMgvBgl+FJeo6xO eGybRVmGmT4A2pgEMq5Oifru3b77J0Z9Swn7UKSwTB98CdI7O1bfSP3tvAdHxqcO 3LQ/oDeXSlUQXgQiFBp+kz27662ZSRQEbivtp+MXtA= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0vFvJYKG5yRU; Mon, 26 Apr 2010 10:59:48 +0200 (CEST) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 42D971850; Mon, 26 Apr 2010 10:59:48 +0200 (CEST) Date: Mon, 26 Apr 2010 10:59:48 +0200 From: Guido Falsi To: Jeremy Chadwick Message-ID: <20100426085947.GB20779@megatron.madpilot.net> References: <20100426080815.GA41938@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100426080815.GA41938@icarus.home.lan> X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 08:59:53 -0000 On Mon, Apr 26, 2010 at 01:08:15AM -0700, Jeremy Chadwick wrote: > Foremost, sorry for the cross-post, but more eyes in this case means > overall more discussion. Secondly, please keep me CC'd as I'm not on > either -rc or -net. > > I recently proposed addition of a new script to the rc framework which > verifies (using ping) that layer 3 network connectivity is up/functional > before continuing on with daemons which require network access: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html > > The overall response was positive, with full acknowledgement that this > is indeed a hack -- yet necessary -- and that something more appropriate > could probably be introduced into the base system to provide a much > cleaner solution (launchd was mentioned). I did read the original thread, and like the idea. I myself have servers winth ntpd failing to configure tiself at boot due to this problem and was thinking of some hack to force the behaviour you suggest. So I obviously like your idea and would like to see this in the base system. Regarding launchd, I don't know much about it, but I do like the rc system and having the boot sequence managed by scripts one can easily modify to taste. I'd rather not modify this system with some daemon performing obscure tasks based on some configuration file. The flexibility given by scripts is imho, quite superior to any configurable daemon's. This is just my opinion, obviously. As stated I don't know much about launchd, and it is quite possible that I have misconceptions about it, so please don't flame me if I insulted it! Thank you for your effort and work to bring this to the masses! -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 10:05:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7137E1065672 for ; Mon, 26 Apr 2010 10:05:06 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from xen-smtp03.srv.cat (smtp03.srv.cat [212.36.74.233]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8B48FC08 for ; Mon, 26 Apr 2010 10:05:06 +0000 (UTC) Received: from jespasac.cdmon.com (155.Red-88-2-251.staticIP.rima-tde.net [88.2.251.155]) (Authenticated sender: jespasac@noverificar) by xen-smtp03.srv.cat (Postfix) with ESMTPSA id D1F23C05B5 for ; Mon, 26 Apr 2010 11:59:55 +0200 (CEST) Message-ID: <4BD5641A.2030300@minibofh.org> Date: Mon, 26 Apr 2010 11:59:54 +0200 From: Jordi Espasa Clofent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20100426080815.GA41938@icarus.home.lan> <20100426085947.GB20779@megatron.madpilot.net> In-Reply-To: <20100426085947.GB20779@megatron.madpilot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 10:05:06 -0000 > I did read the original thread, and like the idea. I myself have servers > winth ntpd failing to configure tiself at boot due to this problem and > was thinking of some hack to force the behaviour you suggest. If you use the OpenNTPd instead of classical ntpd one, you won't suffer this odd behaviour: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ntpd/ntp_dns.c -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 11:07:06 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 354E31065676 for ; Mon, 26 Apr 2010 11:07:06 +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 2278A8FC23 for ; Mon, 26 Apr 2010 11:07:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3QB76Ns004222 for ; Mon, 26 Apr 2010 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3QB75LS004220 for freebsd-net@FreeBSD.org; Mon, 26 Apr 2010 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Apr 2010 11:07:05 GMT Message-Id: <201004261107.o3QB75LS004220@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 11:07:06 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145918 net [ae] After spontaneous ae0 "watchdog timeout", "stray o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o kern/145621 net [bge] [panic] bge watchdog timeout --resetting -> cras o kern/145462 net [netgraph] [patch] panic kernel when ng_ipfw send ip p o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144898 net [wpi] [panic] wpi panics system o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o kern/144777 net [arp] proxyarp broken in 8.0 [regression] o kern/144755 net [iwi] [panic] iwi panic when issuing /etc/rc.d/netif r o kern/144724 net [bwn] if_bwn does not pass traffic when in PIO mode o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144680 net [em] em(4) problem with dual-port adapter o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to o kern/144561 net [ixgbe] [patch] ixgbe driver errors o kern/144529 net [sctp] sctp over ipv6 appears to not calculate checksu o kern/144505 net [bwn] [patch] Error in macro CALC_COEFF2. o kern/144494 net [ixgbe] ixgbe driver not built as module f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144206 net Marvell Yukon NIC not working under FreeBSD o kern/144000 net [tcp] setting TCP_MAXSEG by setsockopt() does not seem o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140597 net [netinet] [patch] implement Lost Retransmission Detect o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 412 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 13:52:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C99A106566B for ; Mon, 26 Apr 2010 13:52:37 +0000 (UTC) (envelope-from der@rusig.ru) Received: from signal-gate.rusig.ru (signal-gate.rusig.ru [83.242.169.118]) by mx1.freebsd.org (Postfix) with ESMTP id 54F678FC19 for ; Mon, 26 Apr 2010 13:52:12 +0000 (UTC) Received: from [192.9.200.232] (Derevyanko-xp.rusig.ru [192.9.200.232]) by signal-gate.rusig.ru (8.14.4/8.14.4) with ESMTP id o3QDXPuf007954; Mon, 26 Apr 2010 17:33:50 +0400 (MSD) (envelope-from der@rusig.ru) Message-ID: <4BD59625.8080000@rusig.ru> Date: Mon, 26 Apr 2010 17:33:25 +0400 From: =?KOI8-R?Q?=E1=CC=C5=CB=D3=C1=CE=C4=D2?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: freebsd-net@freebsd.org, cbuechler@gmail.com References: C9FFD553E47B40BEA6F85F3126E9A692@multiplay.co.uk Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.0 required=5.0 tests=T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on signal-gate.rusig.ru Cc: Subject: multi-homed systems stop answering ARP on local addresses w/ifconfig aliases X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 13:52:37 -0000 On Sun, May 17, 2009 at 4:35 PM, Steven Hartland > wrote: >/ Silly question but something else on the network isn't doing a arp spoof />/ attack is it? />/ / No, there isn't any ARP at all on that address on the network when this is a problem, verified with tcpdump. That also shouldn't impact the system's ability to talk to its own IPs. thanks for the response though! >/ ----- Original Message ----- From: "Chris Buechler" />/ > />/ To: > />/ Sent: Sunday, May 17, 2009 9:08 PM />/ Subject: multi-homed systems stop answering ARP on local addresses />/ w/ifconfig aliases />/ />/ />>/ There seems to be a regression between 6.x and 7.0 and 7.1 related to />>/ ifconfig aliases on multi-homed hosts. Not sure on anything newer than 7.1 />>/ (this is pfSense, we're just starting to test 7.2 builds). For periods of />>/ time, the system will stop answering ARP on some of its own addresses and />>/ hence anything on that network completely stops functioning. The same setup />>/ worked fine on 6.2. />>/ />>/ The particular system illustrated here is a router on part of an ISP's />>/ network. IPs are all public, in the info provided here they've been replaced />>/ with 10. IPs. The subnets on the inside interfaces are routed to the outside />>/ interface. When this problem occurs, the IPs assigned locally on the system />>/ will still respond from the Internet, but the system itself loses all />>/ connectivity with that subnet and nothing on that subnet can communicate />>/ with the host due to the lack of ARP. That makes some sense, I presume when />>/ routing to a locally assigned address via another interface, the system />>/ doesn't need ARP on the address to respond. But while it still responds from />>/ the Internet, even the host itself can't initiate a ping to that IP. It />>/ behaves the same whether pf is enabled or disabled. />>/ />>/ I see two similar issues in the past, one with a PR: />>/ http://www.freebsd.org/cgi/query-pr.cgi?pr=121437&cat= />>/ that's exactly the same issue, it's not limited to VLANs, any multi-homed />>/ host is affected. />>/ />>/ And another: />>/ http://thread.gmane.org/gmane.os.freebsd.stable/57125 />>/ />>/ fxp0 is the outside interface. It doesn't make any difference whether the />>/ ifconfig aliases are on the em0 or fxp1 interfaces, they both behave the />>/ same if they have any ifconfig aliases assigned. />>/ />>/ # ifconfig />>/ fxp0: flags=8843 metric 0 mtu 1500 />>/ options=8 />>/ ether 00:90:27:86:8b:9d />>/ inet6 fe80::290:27ff:fe86:8b9d%fxp0 prefixlen 64 scopeid 0x1 />>/ inet 10.11.185.146 netmask 0xfffffff8 broadcast 10.11.185.151 />>/ media: Ethernet 100baseTX />>/ status: active />>/ em0: flags=8843 metric 0 mtu 1500 />>/ options=9b />>/ ether 00:11:43:2c:62:03 />>/ inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 />>/ inet6 fe80::211:43ff:fe2c:6203%em0 prefixlen 64 scopeid 0x2 />>/ inet 10.13.40.1 netmask 0xffffff00 broadcast 10.13.40.255 />>/ inet 10.13.41.1 netmask 0xffffff00 broadcast 10.13.41.255 />>/ inet 10.13.42.1 netmask 0xffffff00 broadcast 10.13.42.255 />>/ inet 10.13.43.1 netmask 0xffffff00 broadcast 10.13.43.255 />>/ inet 10.13.44.1 netmask 0xffffff00 broadcast 10.13.44.255 />>/ inet 10.13.45.1 netmask 0xffffff00 broadcast 10.13.45.255 />>/ inet 10.13.46.1 netmask 0xffffff00 broadcast 10.13.46.255 />>/ inet 10.13.47.1 netmask 0xffffff00 broadcast 10.13.47.255 />>/ media: Ethernet autoselect (100baseTX ) />>/ status: active />>/ fxp1: flags=8843 metric 0 mtu 1500 />>/ options=8 />>/ ether 00:d0:b7:5d:25:9f />>/ inet 10.1.242.1 netmask 0xffffff00 broadcast 10.1.242.255 />>/ inet6 fe80::2d0:b7ff:fe5d:259f%fxp1 prefixlen 64 scopeid 0x3 />>/ inet 10.1.243.1 netmask 0xffffff00 broadcast 10.1.243.255 />>/ media: Ethernet autoselect (100baseTX ) />>/ status: active />>/ />>/ />>/ />>/ When the problem is occurring, you can't even ping the affected locally />>/ assigned addresses from the box itself: />>/ # ping 10.10.0.1 />>/ PING 10.10.0.1 (10.10.0.1): 56 data bytes />>/ ping: sendto: Network is unreachable />>/ ping: sendto: Network is unreachable />>/ ping: sendto: Network is unreachable />>/ />>/ And when trying to ping something on one of the affected attached subnets, />>/ you get: />>/ # ping 10.10.0.30 />>/ PING 10.10.0.30 (10.10.0.30): 56 data bytes />>/ ping: sendto: Invalid argument />>/ ping: sendto: Invalid argument />>/ />>/ />>/ In the logs, you get a flood of these messages: />>/ May 14 02:55:12 kernel: arpresolve: can't allocate route for 10.10.0.1 />>/ May 14 02:55:12 kernel: arplookup 10.10.0.1 failed: host is not on />>/ local network />>/ May 14 02:55:12 kernel: arpresolve: can't allocate route for 10.10.0.1 />>/ May 14 02:55:12 kernel: arplookup 10.10.0.1 failed: host is not on />>/ local network />>/ />>/ />>/ It happens both with the primary IP assigned to the interface, and the />>/ aliases assigned, but not all at once. Some of the addresses will continue />>/ to work when others are failing. Somehow it thinks IPs that are locally />>/ assigned are not on a local network... after a couple minutes, it just />>/ starts working again without making any changes or even touching the system. />>/ />>/ If I can provide any additional information, please let me know. />>/ />>/ thanks, />>/ Chris />>/ // //The same thing happened to me. FreeBSD 8.0-RELEASE, bge0-bge4, bge0 configured with two subnets. ARP for primary subnet dissappear randomly (~once a day). Do you have any resolution for this? Best Regards, Alexander Derevyanko / From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 16:00:31 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 818DF106567D for ; Mon, 26 Apr 2010 16:00:31 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 0C8E18FC08 for ; Mon, 26 Apr 2010 16:00:30 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so1713415fge.13 for ; Mon, 26 Apr 2010 09:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=fGtNmpOQsFfvi9j+H4y30D6cGTRtSe4/hRNVtoTt+pI=; b=uV6jAyBJG6BIcmqu2AeUvP4J8Sbo5lLvSBFKSuFxzZyPnFdUQO1XFmOGABMLICwhY1 xBecLHcDwjLiwoYDhgW2rzsnQKgirXfacG6YKgBDujzjNM15o34j+KOrxPVxrkvnJtMm VYf3eA+wkSf+FoflJRJ/vrdxew3N26F2vmiwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=oTFbVbK9VpOz+zMkpZd2iGsD1/X6IMlE0tq/vQQO5RpuWZlBkpjrH33m5b3wyN27xV At7bu2e+C7aNBoe30Y1TIoJqpPdey26y6Toqq4e+761LbcvD5qGX9lB5+AqQ76ymILQn WYe94yDM1GKKpzpV1OW7B/nqAM+1TQxRaor38= Received: by 10.87.67.25 with SMTP id u25mr7754178fgk.32.1272297621478; Mon, 26 Apr 2010 09:00:21 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id e11sm4632160fga.18.2010.04.26.09.00.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 09:00:13 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BD5B887.9070203@elischer.org> Date: Mon, 26 Apr 2010 09:00:07 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jeremy Chadwick References: <20100426080815.GA41938@icarus.home.lan> In-Reply-To: <20100426080815.GA41938@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 16:00:31 -0000 On 4/26/10 1:08 AM, Jeremy Chadwick wrote: > Foremost, sorry for the cross-post, but more eyes in this case means > overall more discussion. Secondly, please keep me CC'd as I'm not on > either -rc or -net. > > I recently proposed addition of a new script to the rc framework which > verifies (using ping) that layer 3 network connectivity is up/functional > before continuing on with daemons which require network access: a down side is that you can't boot if some OTHER machine is not up. > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html > > The overall response was positive, with full acknowledgement that this > is indeed a hack -- yet necessary -- and that something more appropriate > could probably be introduced into the base system to provide a much > cleaner solution (launchd was mentioned). there does need to be some dependency tracking to do with networks. maybe there acn be a selection of ways to pass that milestone.. (carrier detect, ping, incoming packets non-0) etc. my favourite is: INPUT_PACKETS=`netstat -i | awk "/${IP}/"'{print $5}'` if [ -n "${INPUT_PACKETS}" -a "${INPUT_PACKETS}" != "0" ] them echo "It's UP!" fi > > I'd like folks (particularly on -rc) to chime in here, and please see > about adding this to the base system. > > Please note there's one typo in the script (a line which needs to be > commented out) in my original post which I've since fixed in the version > that's available via HTTP. > > Thank you! > From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 16:03:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D662A106564A; Mon, 26 Apr 2010 16:03:00 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1648FC12; Mon, 26 Apr 2010 16:02:59 +0000 (UTC) Received: by fxm15 with SMTP id 15so126697fxm.13 for ; Mon, 26 Apr 2010 09:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yZnnSNr3LsoqlgjgNG2Mw1WfGJ1j6aB7j/XbS7MhCOU=; b=hnzjtoLDNF67QKKMPxNfImNQYoaIqH+GZaO5MtFxxvR1JpNn9mJo82x4/m5XdPWtWG ea2llOrTFc23OCbcABi7RN54HVX92uSLe3Z5H3zgW/lG+R6ksL6ozjEZ+kj9DJ/mFHwk V6Ctrqpc6nxX1+omhdaTJCVZsGaJUZPjfJhOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kRn972FUuk9ZwXdyCsqxHvEE9Cr1yuwM3p1T2XNUIdlzgAHVbQovB9scNr4VfISG9v /b5B69bO5FNJ0hbrHNSm+szgo/fGkvlv7HelobC8rj2xpKINKLeljji28CgtyMq7Miil POr2x/bjOA33noMX96KzwoLYrXo6QaR+/cvu4= Received: by 10.87.69.8 with SMTP id w8mr7730196fgk.58.1272297763037; Mon, 26 Apr 2010 09:02:43 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id 4sm6915980fge.13.2010.04.26.09.02.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 09:02:40 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BD5B91B.2050606@elischer.org> Date: Mon, 26 Apr 2010 09:02:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Stefan Esser References: <4B28F841.1070900@skylinetele.com> <4BD54AC7.7090301@FreeBSD.org> In-Reply-To: <4BD54AC7.7090301@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "Li, Qing" , freebsd-stable@freebsd.org, "Prokofiev S.P." , freebsd-net@freebsd.org, Qing Li , freebsd-current@freebsd.org, Marin Atanasov Subject: Re: net/mpd5, ppp, proxy-arp issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 16:03:01 -0000 On 4/26/10 1:11 AM, Stefan Esser wrote: > Am 22.04.2010 20:43, schrieb Marin Atanasov: >> Hello, >> >> Thanks a lot for the patch, Qing! >> >> It works fine. However I've noticed one thing, after I start mpd5 and >> connect to my home network: >> >> kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize() >> >> Not very sure if this is something to worry about or not? > > There was a problem with the initialization order of network "domains", > which caused kernel crashes with ISDN+INET6 some two years ago. The > reason was, that there was an implicit assumption, that all domains > were initialized when the network interfaces are initialized, with > NULL dereferences if domains are added (and relevant to a device) > after the device has been initialized. > > I debugged this problem and prepared a patch for discussion, which > later was committed by Max Laier (if memory serves me right). The > message was added in order to identify further situations, where > network domains are added after network interfaces have been > initialized. This message ought to be informational right now, since > the interface init is repeated whenever a network domain is added > as part of above mentioned patch. Init order should be fixed, if > this message is printed for compiled in drivers, but in case of a > kernel module (like netgraph) that adds a domain, it is unadvoidable > that the init order is reversed. > > Perhaps the message should be made conditional on the start-up of > the kernel not having finished, or it should be completely removed, > since time has shown, that the init order is correct in general. > > I'll remove that message (or make it conditional on "bootverbose") > unless there is opposition to this change ... please do.. it's an unavoidable thing that domains added after boot are done after boot completes :-) > Regards, STefan > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 16:46:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36BE3106566B for ; Mon, 26 Apr 2010 16:46:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1D4658FC15 for ; Mon, 26 Apr 2010 16:46:21 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta14.emeryville.ca.mail.comcast.net with comcast id ACYc1e0040x6nqcAEGmNk0; Mon, 26 Apr 2010 16:46:22 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta12.emeryville.ca.mail.comcast.net with comcast id AGmL1e0013S48mS8YGmMf9; Mon, 26 Apr 2010 16:46:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4FE519B425; Mon, 26 Apr 2010 09:46:18 -0700 (PDT) Date: Mon, 26 Apr 2010 09:46:18 -0700 From: Jeremy Chadwick To: Julian Elischer Message-ID: <20100426164618.GA55086@icarus.home.lan> References: <20100426080815.GA41938@icarus.home.lan> <4BD5B887.9070203@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD5B887.9070203@elischer.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 16:46:22 -0000 On Mon, Apr 26, 2010 at 09:00:07AM -0700, Julian Elischer wrote: > On 4/26/10 1:08 AM, Jeremy Chadwick wrote: > >Foremost, sorry for the cross-post, but more eyes in this case means > >overall more discussion. Secondly, please keep me CC'd as I'm not on > >either -rc or -net. > > > >I recently proposed addition of a new script to the rc framework which > >verifies (using ping) that layer 3 network connectivity is up/functional > >before continuing on with daemons which require network access: > > a down side is that you can't boot if some OTHER machine is not up. The boot-up process will still continue regardless if the ping check passed or failed. It just means that daemons/services attempting to use the network and *expect* connectivity to work may not function correctly (meaning: they'll behave just like they already do. ;-) ) I indirectly tried to cover the "if some other machine is not up" point in my initial post on -stable: "1) This script requires the $waitnetwork_ip box/router/whatever respond to ICMP ECHO requests. Please do not bikeshed on this point; we need something that works, and this requirement shouldn't be that bad to deal with (firewall/ACL-wise). For most folks (co-located in particular), this could be your default gateway, but you can use whatever you want." It would be possible to extend the script to loop through multiple IPs specified in $waitnetwork_ip (space-delimited); the first one to cause ping to exit with code 0 (ICMP ECHO reply seen) would therefore deem the network usable and continue on. > >http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html > > > >The overall response was positive, with full acknowledgement that this > >is indeed a hack -- yet necessary -- and that something more appropriate > >could probably be introduced into the base system to provide a much > >cleaner solution (launchd was mentioned). > > there does need to be some dependency tracking to do with networks. > maybe there acn be a selection of ways to pass that milestone.. > > (carrier detect, ping, incoming packets non-0) etc. > my favourite is: > > INPUT_PACKETS=`netstat -i | awk "/${IP}/"'{print $5}'` > if [ -n "${INPUT_PACKETS}" -a "${INPUT_PACKETS}" != "0" ] > them > echo "It's UP!" > fi This isn't the same thing as doing a ping check though. As I understand it, netstat -i shows you how many Ethernet packets have been seen -- that includes ARP. The intended goal of the script is to verify that a usable network connection exists -- usable in this case means "whatever host you device in $waitnetwork_ip responds to ICMP". If this is an Internet host (e.g. 4.2.2.1), then said IP responding to ICMP would indicate Internet connectivity is available. I think most users would fall into the latter class, not the "I want to verify my LAN connectivity is up and working, except the other box on my LAN is powered off..." class. Basically what I'm saying is that I fully acknowledge there's no absolute 100% failsafe method that's going to work for every single user's environment. My script's goal isn't to address every single problem/scenario -- just the most common one, and one I (we?) server administrators deal with regularly. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 21:18:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A65301065670 for ; Mon, 26 Apr 2010 21:18:08 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7515D8FC1B for ; Mon, 26 Apr 2010 21:18:08 +0000 (UTC) Received: by pvc21 with SMTP id 21so556839pvc.13 for ; Mon, 26 Apr 2010 14:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=eDbw3pkYcRnBq7ZbhcrVehE+1L6vPZQZU1IIjWzwuxc=; b=Em/WpJ7D0apnoCwtpaPxbpAv0Atk+PUeAzRh0qi3gIheBDH07Zz+tjJQh0dpwhULbz U26BaZkkElDrHah3f3SQFq9Ec1p/xOhgsvdTN5yaOZxH1nkn0Xzjqc4nrpEXEN3t6TcP k7smI4+Y6mCyvHxySh+YT+j9skwI51p3fAx68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VUFu+ROVJQ1XVWTgAYLMvcq4cN5tFaRk68eKOdy6kghwbV5LKHh4pSe9EM23X7/TYr rjhhNtw+RV6Qm4LOA9owSelnNa5fN6M4wgYEAtwb48gIj9p55YuMZO9tG1JNSasT7w44 95BKthCU10r/ffkBv4DfEG+WLSnG0GcjEcPAY= MIME-Version: 1.0 Received: by 10.141.213.36 with SMTP id p36mr4678135rvq.5.1272316683155; Mon, 26 Apr 2010 14:18:03 -0700 (PDT) Received: by 10.231.113.36 with HTTP; Mon, 26 Apr 2010 14:18:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Apr 2010 16:18:03 -0500 Message-ID: From: Brandon Gooch To: Jacques Fourie Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: m_copymdata() bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 21:18:08 -0000 On Tue, Apr 13, 2010 at 8:30 AM, Jacques Fourie wrote: > It seems as if the m_copymdata() function defined in uipc_mbuf.c has a > bug. It uses m_apply to copy data from the source mbuf to the target > but in the callback function m_bcopyxxx() the arguments are > interpreted in the wrong order. Swapping the 's' and 't' arguments in > the declaration of m_bcopyxxx() fixes the problem for me. Perhaps you should file a PR with an included patch: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html http://www.freebsd.org/send-pr.html Thanks! -Brandon From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 22:20:48 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62817106566B for ; Mon, 26 Apr 2010 22:20:48 +0000 (UTC) (envelope-from cbuechler@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9918FC18 for ; Mon, 26 Apr 2010 22:20:47 +0000 (UTC) Received: by qyk11 with SMTP id 11so15627582qyk.13 for ; Mon, 26 Apr 2010 15:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xqugpnAchEjOiDK96dfSM3raRD75F6AFvBEK41HZ94o=; b=wYrMyisjJBJ0rN2pywofvRKA+3+08s2m7aH3xPmJI5vrrsI7pplUO/7zHP+3H7PXM6 XJs0HLvlflZQVf8y/9mmM2WDtNfObeJDykjslK1lzoNUZnOEpXaHi7iOTJzzK3qXZmfM Ppl+4alwv7pmzaeLzqnkoZadfuGKT6b/RbOSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B/mVk4ZP9ucgP6twR4ZnSVTH5sAygOZNiuAjY2JxliseYIhWlp+U9z2jFSvauEiKiz L5kHMcqF7sdMmYhAeo0MQYquDYsaZHOej7aS8GkD53b3URwOco1PdAbtKhh5ooP5fyJQ SsZfWUSeNPru3sr9iX2sCqvbdN9XSZRLRYlwY= MIME-Version: 1.0 Received: by 10.229.14.157 with SMTP id g29mr5867212qca.57.1272318794585; Mon, 26 Apr 2010 14:53:14 -0700 (PDT) Received: by 10.229.53.136 with HTTP; Mon, 26 Apr 2010 14:53:14 -0700 (PDT) In-Reply-To: <4BD59625.8080000@rusig.ru> References: <4BD59625.8080000@rusig.ru> Date: Mon, 26 Apr 2010 17:53:14 -0400 Message-ID: From: Chris Buechler To: =?KOI8-R?B?4czFy9PBzsTS?= Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: multi-homed systems stop answering ARP on local addresses w/ifconfig aliases X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 22:20:48 -0000 2010/4/26 =E1=CC=C5=CB=D3=C1=CE=C4=D2 : > On Sun, May 17, 2009 at 4:35 PM, Steven Hartland > > wrote: >> >> / Silly question but something else on the network isn't doing a arp spo= of > > />/ attack is it? > />/ > / > No, there isn't any ARP at all on that address on the network when > this is a problem, verified with tcpdump. That also shouldn't impact > the system's ability to talk to its own IPs. > > thanks for the response though! > > >> / ----- Original Message ----- From: "Chris Buechler" > > />/ > > />/ To: > > />/ Sent: Sunday, May 17, 2009 9:08 PM > />/ Subject: multi-homed systems stop answering ARP on local addresses > />/ w/ifconfig aliases > />/ > />/ > />>/ There seems to be a regression between 6.x and 7.0 and 7.1 related t= o > />>/ ifconfig aliases on multi-homed hosts. Not sure on anything newer th= an > 7.1 > />>/ (this is pfSense, we're just starting to test 7.2 builds). For perio= ds > of > />>/ time, the system will stop answering ARP on some of its own addresse= s > and > />>/ hence anything on that network completely stops functioning. The sam= e > setup > />>/ worked fine on 6.2. > />>/ > />>/ The particular system illustrated here is a router on part of an ISP= 's > />>/ network. IPs are all public, in the info provided here they've been > replaced > />>/ with 10. IPs. The subnets on the inside interfaces are routed to the > outside > />>/ interface. When this problem occurs, the IPs assigned locally on the > system > />>/ will still respond from the Internet, but the system itself loses al= l > />>/ connectivity with that subnet and nothing on that subnet can > communicate > />>/ with the host due to the lack of ARP. That makes some sense, I presu= me > when > />>/ routing to a locally assigned address via another interface, the sys= tem > />>/ doesn't need ARP on the address to respond. But while it still respo= nds > from > />>/ the Internet, even the host itself can't initiate a ping to that IP.= It > />>/ behaves the same whether pf is enabled or disabled. > />>/ > />>/ I see two similar issues in the past, one with a PR: > />>/ http://www.freebsd.org/cgi/query-pr.cgi?pr=3D121437&cat=3D > > />>/ that's exactly the same issue, it's not limited to VLANs, any > multi-homed > />>/ host is affected. > />>/ > />>/ And another: > />>/ http://thread.gmane.org/gmane.os.freebsd.stable/57125 > />>/ > />>/ fxp0 is the outside interface. It doesn't make any difference whethe= r > the > />>/ ifconfig aliases are on the em0 or fxp1 interfaces, they both behave > the > />>/ same if they have any ifconfig aliases assigned. > />>/ > />>/ # ifconfig > />>/ fxp0: flags=3D8843 metric 0 = mtu > 1500 > />>/ =9A =9A =9A options=3D8 > />>/ =9A =9A =9A ether 00:90:27:86:8b:9d > />>/ =9A =9A =9A inet6 fe80::290:27ff:fe86:8b9d%fxp0 prefixlen 64 scopeid= 0x1 > />>/ =9A =9A =9A inet 10.11.185.146 netmask 0xfffffff8 broadcast 10.11.18= 5.151 > />>/ =9A =9A =9A media: Ethernet 100baseTX > />>/ =9A =9A =9A status: active > />>/ em0: flags=3D8843 metric 0 m= tu > 1500 > />>/ =9A =9A =9A options=3D9b > />>/ =9A =9A =9A ether 00:11:43:2c:62:03 > />>/ =9A =9A =9A inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 > />>/ =9A =9A =9A inet6 fe80::211:43ff:fe2c:6203%em0 prefixlen 64 scopeid = 0x2 > />>/ =9A =9A =9A inet 10.13.40.1 netmask 0xffffff00 broadcast 10.13.40.25= 5 > />>/ =9A =9A =9A inet 10.13.41.1 netmask 0xffffff00 broadcast 10.13.41.25= 5 > />>/ =9A =9A =9A inet 10.13.42.1 netmask 0xffffff00 broadcast 10.13.42.25= 5 > />>/ =9A =9A =9A inet 10.13.43.1 netmask 0xffffff00 broadcast 10.13.43.25= 5 > />>/ =9A =9A =9A inet 10.13.44.1 netmask 0xffffff00 broadcast 10.13.44.25= 5 > />>/ =9A =9A =9A inet 10.13.45.1 netmask 0xffffff00 broadcast 10.13.45.25= 5 > />>/ =9A =9A =9A inet 10.13.46.1 netmask 0xffffff00 broadcast 10.13.46.25= 5 > />>/ =9A =9A =9A inet 10.13.47.1 netmask 0xffffff00 broadcast 10.13.47.25= 5 > />>/ =9A =9A =9A media: Ethernet autoselect (100baseTX ) > />>/ =9A =9A =9A status: active > />>/ fxp1: flags=3D8843 metric 0 = mtu > 1500 > />>/ =9A =9A =9A options=3D8 > />>/ =9A =9A =9A ether 00:d0:b7:5d:25:9f > />>/ =9A =9A =9A inet 10.1.242.1 netmask 0xffffff00 broadcast 10.1.242.25= 5 > />>/ =9A =9A =9A inet6 fe80::2d0:b7ff:fe5d:259f%fxp1 prefixlen 64 scopeid= 0x3 > />>/ =9A =9A =9A inet 10.1.243.1 netmask 0xffffff00 broadcast 10.1.243.25= 5 > />>/ =9A =9A =9A media: Ethernet autoselect (100baseTX ) > />>/ =9A =9A =9A status: active > />>/ > />>/ > />>/ > />>/ When the problem is occurring, you can't even ping the affected loca= lly > />>/ assigned addresses from the box itself: > />>/ # ping 10.10.0.1 > />>/ PING 10.10.0.1 (10.10.0.1): 56 data bytes > />>/ ping: sendto: Network is unreachable > />>/ ping: sendto: Network is unreachable > />>/ ping: sendto: Network is unreachable > />>/ > />>/ And when trying to ping something on one of the affected attached > subnets, > />>/ you get: > />>/ # ping 10.10.0.30 > />>/ PING 10.10.0.30 (10.10.0.30): 56 data bytes > />>/ ping: sendto: Invalid argument > />>/ ping: sendto: Invalid argument > />>/ > />>/ > />>/ In the logs, you get a flood of these messages: > />>/ May 14 02:55:12 =9A =9Akernel: arpresolve: can't allocate route for > 10.10.0.1 > />>/ May 14 02:55:12 =9A =9Akernel: arplookup 10.10.0.1 failed: host is n= ot on > />>/ local network > />>/ May 14 02:55:12 =9A =9Akernel: arpresolve: can't allocate route for > 10.10.0.1 > />>/ May 14 02:55:12 =9A =9Akernel: arplookup 10.10.0.1 failed: host is n= ot on > />>/ local network > />>/ > />>/ > />>/ It happens both with the primary IP assigned to the interface, and t= he > />>/ aliases assigned, but not all at once. Some of the addresses will > continue > />>/ to work when others are failing. Somehow it thinks IPs that are loca= lly > />>/ assigned are not on a local network... after a couple minutes, it ju= st > />>/ starts working again without making any changes or even touching the > system. > />>/ > />>/ If I can provide any additional information, please let me know. > />>/ > />>/ thanks, > />>/ Chris > />>/ > // > > //The same thing happened to me. FreeBSD 8.0-RELEASE, bge0-bge4, bge0 > configured with two subnets. > ARP for primary subnet dissappear randomly (~once a day). > > > Do you have any resolution for this? > I've yet to test it on 8, but never got a resolution to the above described issue on 7.2. For the scenario where that box was deployed, parts of the functionality were replaced by a Linux box, and the part of the network where it resides was changed so IP aliases are not in use. From owner-freebsd-net@FreeBSD.ORG Mon Apr 26 23:52:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74FB9106566B for ; Mon, 26 Apr 2010 23:52:21 +0000 (UTC) (envelope-from erik@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3D18FC18 for ; Mon, 26 Apr 2010 23:52:21 +0000 (UTC) Received: from malcolm.berkeley.edu (localhost [127.0.0.1]) by malcolm.berkeley.edu (8.14.3/8.13.8m1) with ESMTP id o3QNqLek020524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Apr 2010 16:52:21 -0700 (PDT) (envelope-from erik@malcolm.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at malcolm.berkeley.edu Received: (from erik@localhost) by malcolm.berkeley.edu (8.14.3/8.13.3/Submit) id o3QNqKLq020523 for freebsd-net@freebsd.org; Mon, 26 Apr 2010 16:52:20 -0700 (PDT) (envelope-from erik) Date: Mon, 26 Apr 2010 16:52:20 -0700 From: Erik Klavon To: freebsd-net@freebsd.org Message-ID: <20100426235220.GA20501@malcolm.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (malcolm.berkeley.edu [127.0.0.1]); Mon, 26 Apr 2010 16:52:21 -0700 (PDT) Subject: ifa_free panic in 8 stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 23:52:21 -0000 Hi I have a dual processor, single core amd64 machine running a recent cvsup of 8 stable. On this development machine I use netgraph(3) to implement one to one NAT with one ng_nat(4) node. I use ipfw(8) rules to direct traffic to netgraph nodes as needed based on table entries using an ng_ipfw(4) node. When I load test ng_nat on the development system using iperf(1) running on the independent system, the development system panics after a couple of days as follows. panic: negative refcount 0xffffff0002a344d4 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 ifa_free() at ifa_free+0x5d ip_output() at ip_output+0x49d ip_forward() at ip_forward+0x199 ip_input() at ip_input+0x4cd ng_ipfw_rcvdata() at ng_ipfw_rcvdata+0xadVOP_STRATEGY: bp is not locked but should be KDB: enter: lock violation n[thread pid 17 tid 100042 ] Stopped at kdb_enter+0x3d: movq $0,0x6bb730(%rip) This panic is repeatable on this machine. I am unable to obtain a core dump after these panics; after I attempt to dump core using panic the system does not respond and must be power cycled. I first encountered this problem with 8.0p1. I've reproduced this problem with both em and bge interfaces. I've looked around in the functions mentioned in the backtrace, but haven't made any progress in identifying why this panic occurs. Please share any suggestions you think of for tracking down the source of this problem. My kernel is configured with options DEBUG=-g, KDB, DDB, KDB_TRACE, BREAK_TO_DEBUGGER, INVARIANTS, INVARIANT_SUPPORT, WITNESS, DEBUG_LOCKS, DEBUG_VFS_LOCKS, DIAGNOSTIC, SW_WATCHDOG, DEADLKRES, IPFIREWALL, IPFIREWALL_VERBOSE, IPFIREWALL_VERBOSE_LIMIT=100, IPFIREWALL_FORWARD, and IPDIVERT. I use the following ipfw(8) rules to direct traffic from the independent system to netgraph and vice versa. (x and y below replace the first two octets of the globally routable addresses I'm using in this test.) # direct traffic from the independent system into ng_nat 01100 netgraph tablearg ip from table(87) to any in # direct traffic from the internet into ng_nat 01110 netgraph tablearg ip from any to table(88) in via vlan615 # forward NATed traffic to the subnet's router if it isn't local 01120 fwd x.y.254.1 ip4 from x.y.254.0/25 to not x.y.254.0/25 in via vlan613 # pass traffic after it is NATed, so the default deny rule doesn't block it 01130 allow ip from any to table(87) 01140 allow ip from table(88) to any ipfw(8) table 87 contains the entry 10.10.0.10/32 200254017 and table 88 contains the entry x.y.254.17/32 100254017 The above two table entries direct traffic to the following ng_nat(4) node. Name: NAT0254017 Type: nat ID: 0000000b Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- in ipfw ipfw 00000001 100254017 out ipfw ipfw 00000001 200254017 This ng_nag(4) node was created using the following commands. ngctl mkpeer ipfw: nat 100254017 out ngctl name ipfw:100254017 NAT0254017 ngctl connect ipfw: NAT0254017: 200254017 in ngctl msg NAT0254017: setaliasaddr x.y.254.17 ngctl msg NAT0254017: redirectaddr { "local_addr=10.10.0.10" "alias_addr=x.y.254.17" 'description="Static NAT" } I've assigned the independent system the address 10.10.0.10 on vlan613 with a default router of 10.10.0.1. The development system's address on vlan613 is 10.10.0.1. Based on the above setup, traffic from the independent system is NATed by the development syste to IP address x.y.254.17. I use iperf -d -U -P 20 for the load testing with another system outside of the test setup acting as an iperf server. Erik From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 06:10:05 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0944106566B for ; Tue, 27 Apr 2010 06:10:04 +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 AD6FB8FC12 for ; Tue, 27 Apr 2010 06:10:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3R6A4VP039590 for ; Tue, 27 Apr 2010 06:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3R6A42N039589; Tue, 27 Apr 2010 06:10:04 GMT (envelope-from gnats) Date: Tue, 27 Apr 2010 06:10:04 GMT Message-Id: <201004270610.o3R6A42N039589@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: shelma shelmec Cc: Subject: Re: kern/144315: [ipfw] [panic] freebsd 8-stable reboot after add ipfw rules with netgraph ng_car X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shelma shelmec List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 06:10:05 -0000 The following reply was made to PR kern/144315; it has been noted by GNATS. From: shelma shelmec To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/144315: [ipfw] [panic] freebsd 8-stable reboot after add ipfw rules with netgraph ng_car Date: Tue, 27 Apr 2010 11:29:42 +0600 --00151747927a44169a0485312e62 Content-Type: text/plain; charset=ISO-8859-1 In last FreeBSD 8-stable system going to cycle panic reboot. I`m going back to FreeBSD 7-stable and panic repeat after add ipfw rules. shape# uname -a FreeBSD shape.hostelnet.ru 7.3-STABLE FreeBSD 7.3-STABLE #11: Mon Apr 26 19:18:38 YEKST 2010 shelma@shape.hostelnet.ru:/usr/obj/usr/src/sys/SHAPE i386 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0x80849207 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 Variable "fmt" is not available. #2 0x808494d9 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0x80bc6e0c in trap_fatal (frame=0x852cdacc, eva=12) at /usr/src/sys/i386/i386/trap.c:950 #4 0x80bc7090 in trap_pfault (frame=0x852cdacc, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:863 #5 0x80bc7a85 in trap (frame=0x852cdacc) at /usr/src/sys/i386/i386/trap.c:541 #6 0x80baa87b in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0x8089f476 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:539 #8 0x8099cf55 in ip_fragment (ip=0x85e40010, m_frag=0x852cdc00, mtu=1500, if_hwassist_flags=6, sw_csum=3841) at /usr/src/sys/netinet/ip_output.c:731 #9 0x8099dc66 in ip_output (m=0x85e3d900, opt=0x0, ro=0x852cdbd4, flags=1, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:570 #10 0x80960141 in ng_ipfw_rcvdata (hook=0x8629f500, item=0x861dd080) at /usr/src/sys/netgraph/ng_ipfw.c:247 #11 0x8094dd51 in ng_apply_item (node=0x8569b400, item=0x861dd080, rw=0) at /usr/src/sys/netgraph/ng_base.c:2336 #12 0x80950067 in ngthread (arg=0x0) at /usr/src/sys/netgraph/ng_base.c:3304 #13 0x808221f9 in fork_exit (callout=0x8094fe00 , arg=0x0, frame=0x852cdd38) at /usr/src/sys/kern/kern_fork.c:811 #14 0x80baa8f0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271 (kgdb) bt full #0 doadump () at pcpu.h:196 No locals. #1 0x80849207 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 _giantcnt = Variable "_giantcnt" is not available. --00151747927a44169a0485312e62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In last FreeBSD 8-stable system going to cycle panic reboot.
I`m going back to FreeBSD 7-stable and panic repeat after add ipfw rules.<= br>

shape# uname -a
FreeBSD shape.hostelnet.ru 7.3-STABLE FreeBSD 7.3-STABLE #11= : Mon Apr 26 19:18:38 YEKST 2010 shelma@shape.hostelnet.ru:/usr/obj/usr= /src/sys/SHAPE i386

(kgdb) bt
#0 doadump () at pcpu.h:196
#1 = 0x80849207 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:418Variable "fmt" is not available.
#2 0x808494d9 in panic (fm= t=3D) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0x80bc6e0c in trap_fatal (frame=3D0x852cdacc, eva=3D12)
at /usr/= src/sys/i386/i386/trap.c:950
#4 0x80bc7090 in trap_pfault (frame=3D0x85= 2cdacc, usermode=3D0, eva=3D12)
at /usr/src/sys/i386/i386/trap.c:863=
#5 0x80bc7a85 in trap (frame=3D0x852cdacc) at /usr/src/sys/i386/i386/t= rap.c:541
#6 0x80baa87b in calltrap () at /usr/src/sys/i386/i386/exception.s:166
= #7 0x8089f476 in m_copym (m=3D0x0, off0=3D1500, len=3D1480, wait=3D1)
= at /usr/src/sys/kern/uipc_mbuf.c:539
#8 0x8099cf55 in ip_fragment (i= p=3D0x85e40010, m_frag=3D0x852cdc00, mtu=3D1500,
if_hwassist_flags=3D6, sw_csum=3D3841) at /usr/src/sys/netinet/ip_outpu= t.c:731
#9 0x8099dc66 in ip_output (m=3D0x85e3d900, opt=3D0x0, ro=3D0x8= 52cdbd4, flags=3D1,
imo=3D0x0, inp=3D0x0) at /usr/src/sys/netinet/ip= _output.c:570
#10 0x80960141 in ng_ipfw_rcvdata (hook=3D0x8629f500, item=3D0x861dd080) at /usr/src/sys/netgraph/ng_ipfw.c:247
#11 0x8094dd51 in ng_apply_i= tem (node=3D0x8569b400, item=3D0x861dd080, rw=3D0)
at /usr/src/sys/n= etgraph/ng_base.c:2336
#12 0x80950067 in ngthread (arg=3D0x0) at /usr/src/sys/netgraph/ng_base.c:3= 304
#13 0x808221f9 in fork_exit (callout=3D0x8094fe00 <ngthread>, = arg=3D0x0,
frame=3D0x852cdd38) at /usr/src/sys/kern/kern_fork.c:811<= br>#14 0x80baa8f0 in fork_trampoline () at /usr/src/sys/i386/i386/exception= .s:271
(kgdb) bt full
#0 doadump () at pcpu.h:196
No locals.
#1 0x80849= 207 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:418
= _giantcnt =3D Variable "_giantcnt" is not available.
--00151747927a44169a0485312e62-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 16:59:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 333201065679; Tue, 27 Apr 2010 16:59:11 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id D86EC8FC18; Tue, 27 Apr 2010 16:59:10 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id o3RGvsmo067520; Tue, 27 Apr 2010 11:57:54 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id o3RGvsrP067519; Tue, 27 Apr 2010 11:57:54 -0500 (CDT) (envelope-from brooks) Date: Tue, 27 Apr 2010 11:57:54 -0500 From: Brooks Davis To: Jeremy Chadwick Message-ID: <20100427165753.GA58954@lor.one-eyed-alien.net> References: <20100426080815.GA41938@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <20100426080815.GA41938@icarus.home.lan> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 27 Apr 2010 11:57:55 -0500 (CDT) Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 16:59:11 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2010 at 01:08:15AM -0700, Jeremy Chadwick wrote: > Foremost, sorry for the cross-post, but more eyes in this case means > overall more discussion. Secondly, please keep me CC'd as I'm not on > either -rc or -net. >=20 > I recently proposed addition of a new script to the rc framework which > verifies (using ping) that layer 3 network connectivity is up/functional > before continuing on with daemons which require network access: >=20 > http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html >=20 > The overall response was positive, with full acknowledgement that this > is indeed a hack -- yet necessary -- and that something more appropriate > could probably be introduced into the base system to provide a much > cleaner solution (launchd was mentioned). >=20 > I'd like folks (particularly on -rc) to chime in here, and please see > about adding this to the base system. Given that this would fix the problems many users see in the current world order and that it's relativly unintrusive I think it's an ok thing to add. -- Brooks --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFL1xeRXY6L6fI4GtQRAg/aAKCTJTa3qPxZO9fbLGib487/DKPQOACeIUqt A5UyCnU9+nWyu7mGc7/M394= =ipaZ -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 17:15:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 590DC1065673 for ; Tue, 27 Apr 2010 17:15:45 +0000 (UTC) (envelope-from nlandys@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE3468FC18 for ; Tue, 27 Apr 2010 17:15:44 +0000 (UTC) Received: by vws11 with SMTP id 11so480151vws.13 for ; Tue, 27 Apr 2010 10:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=gSez5EUEm+uPGZwkaOrAzEpcoGSx3TGeiFmmcQmz+W8=; b=S2BeiS1d6quOtZ+Lk8PI1YpWvZGl7nma8SnuzGI1F2vPbfsUpX0wjmJZhyHWBflBoZ b9scRvTTNbDZxYeM7jDzsk1nMTThqw79lD2L29kVSt6ZPdbDSM5L8xEfpfM2um00VcMf YSL+BnXbkkv8pxDzRuisnZYlWEK3A6UxXeI9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=H4eUhbEmV+dF4Rw8TouH5SJKdYtiXFQ/OD27m2ZvUt7qt1lxHI9/LDplFIn/O+R9Xl U2bnbEjl7E1mhypoKiWmoESsh1qhInIVOEC8omSJjNMXxkggBJsol2Y/0IsuTu3KP0Gn VFEgAsDyG4QtBKTCMXYog5d9vG+RiXwyyl7Ak= MIME-Version: 1.0 Received: by 10.229.232.144 with SMTP id ju16mr7681044qcb.107.1272388538659; Tue, 27 Apr 2010 10:15:38 -0700 (PDT) Received: by 10.229.102.88 with HTTP; Tue, 27 Apr 2010 10:15:38 -0700 (PDT) In-Reply-To: <20100427165753.GA58954@lor.one-eyed-alien.net> References: <20100426080815.GA41938@icarus.home.lan> <20100427165753.GA58954@lor.one-eyed-alien.net> Date: Tue, 27 Apr 2010 10:15:38 -0700 Message-ID: From: Nerius Landys To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org, Jeremy Chadwick Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 17:15:45 -0000 > On Mon, Apr 26, 2010 at 01:08:15AM -0700, Jeremy Chadwick wrote: >> Foremost, sorry for the cross-post, but more eyes in this case means >> overall more discussion. Secondly, please keep me CC'd as I'm not on >> either -rc or -net. >> >> I recently proposed addition of a new script to the rc framework which >> verifies (using ping) that layer 3 network connectivity is up/functional >> before continuing on with daemons which require network access: >> >> http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html >> >> The overall response was positive, with full acknowledgement that this >> is indeed a hack -- yet necessary -- and that something more appropriate >> could probably be introduced into the base system to provide a much >> cleaner solution (launchd was mentioned). >> >> I'd like folks (particularly on -rc) to chime in here, and please see >> about adding this to the base system. > > Given that this would fix the problems many users see in the current > world order and that it's relativly unintrusive I think it's an ok thing > to add. I was having problems with services such as ntpd starting before the network came up on my server. I wrote a similar script in /usr/local/etc/rc.d/ that pings one of the root name servers for 100 seconds or until it responds, whichever comes first. It fixed my problem. So, yeah, a script to do this would be most welcome. From owner-freebsd-net@FreeBSD.ORG Tue Apr 27 19:34:06 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 970D5106564A for ; Tue, 27 Apr 2010 19:34:06 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 7E37E8FC18 for ; Tue, 27 Apr 2010 19:34:04 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L1J001G4VOQJ580@asmtp026.mac.com>; Tue, 27 Apr 2010 12:34:04 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004270164 From: Chuck Swiger In-reply-to: <20100426085947.GB20779@megatron.madpilot.net> Date: Tue, 27 Apr 2010 12:34:01 -0700 Message-id: References: <20100426080815.GA41938@icarus.home.lan> <20100426085947.GB20779@megatron.madpilot.net> To: Guido Falsi X-Mailer: Apple Mail (2.1078) Cc: "freebsd-net@freebsd.org Net" , freebsd-rc@freebsd.org Subject: Re: rc(8) script -- waiting for the network to become usable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 19:34:06 -0000 Hi, all-- On Apr 26, 2010, at 1:59 AM, Guido Falsi wrote: > Regarding launchd, I don't know much about it, but I do like the rc > system and having the boot sequence managed by scripts one can easily > modify to taste. I'd rather not modify this system with some daemon > performing obscure tasks based on some configuration file. The > flexibility given by scripts is imho, quite superior to any configurable > daemon's. Launchd is intended to replace the combination of init, rc startup scripts, (x)inetd, and cron/at. People who are happy with the traditional Unix distinctions between all of above (and/or do not care for XML plists) may not be fans of launchd. If you're using a Unix box in the traditional role of a server which is always on with permanent Internet connectivity, these traditional Unix mechanisms work just fine. Launchd is intended to deal with the opposite conditions (although it also works okay for permanent server roles, too); ie, it has scheduled jobs, but it will run ones which didn't execute at a particular time because the machine was asleep via StartInterval or StartCalendarInterval: StartCalendarInterval This optional key causes the job to be started every calendar interval as specified. Missing argu- ments are considered to be wildcard. The semantics are much like crontab(5). Unlike cron which skips job invocations when the computer is asleep, launchd will start the job the next time the com- puter wakes up. If multiple intervals transpire before the computer is woken, those events will be coalesced into one event upon wake from sleep. It also includes the notion of whether the machine has working network connectivity as an explicit condition which jobs can use to determine whether they should run or not. Wandering around with a laptop as you go into and out of range of wireless networks is a case which tends to require significant interaction from someone with root access to the box to restart things which should have gone down when there was no network and are in a silly state, whereas it's handled reasonably well by launchd-controlled stuff via KeepAlive / NetworkState: http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man5/launchd.plist.5.html I'm not in love with launchd, or XML plists, either, but it comes closer to resolving issues of running stuff on demand, keeping track of what's actively being used (and should be given a SIGTERM to have a chance to shutdown cleanly rather than a SIGKILL), tracking what needs to run under limited contexts (chroot, non-root userids, setrlimit() stuff, what has access to things like the window system or login window contexts, etc) than the alternatives do. For example, the /etc/rc.subr mechanism supports chroot & non-root users fine, but has no way I'm familiar with to indicate that something maybe should not be running if nobody is logged into the machine and it is sitting at xdm, gdm, or whatever's login screen. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 04:20:03 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AE82106566B for ; Wed, 28 Apr 2010 04:20: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 7634D8FC21 for ; Wed, 28 Apr 2010 04:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3S4K3aK009692 for ; Wed, 28 Apr 2010 04:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3S4K3hd009691; Wed, 28 Apr 2010 04:20:03 GMT (envelope-from gnats) Date: Wed, 28 Apr 2010 04:20:03 GMT Message-Id: <201004280420.o3S4K3hd009691@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jared Barneck Cc: Subject: Re: kern/131087: [ipw] [panic] ipw / iwi - no sent/received packets; iwi needs to be restarted; ipw / iwi causes kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jared Barneck List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 04:20:03 -0000 The following reply was made to PR kern/131087; it has been noted by GNATS. From: Jared Barneck To: bug-followup@FreeBSD.org, mariusz.gromada@wp.pl Cc: Subject: Re: kern/131087: [ipw] [panic] ipw / iwi - no sent/received packets; iwi needs to be restarted; ipw / iwi causes kernel panic Date: Tue, 27 Apr 2010 20:49:04 -0700 (PDT) Hello, I have an IBM T40, pretty much the same settings as above, though I have an Intel 2200BG. I installed 8 stable and when I try to configure my wireless my system just rebooted. I installed PCBSD 8 next which I believe uses FreeBSD 8-Release and the wireless worked without error. However, I just installed a snapshot of PC-BSD which is using FreeBSD 8-Stable and sure enough it happened again. So something is definitely causing a system crash with 8-Stable. Thanks, Jared Barneck http://rhyous.com From owner-freebsd-net@FreeBSD.ORG Wed Apr 28 16:31:40 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D6FD1065672 for ; Wed, 28 Apr 2010 16:31:40 +0000 (UTC) (envelope-from renchap@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 28F8F8FC1B for ; Wed, 28 Apr 2010 16:31:39 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so2829357fge.13 for ; Wed, 28 Apr 2010 09:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=j05WtZj2Gker+DybjlxLwInnC9OrzdnjFoi8jahFsHk=; b=pjPKP+AUE28hRs0TnMUlGPCKd+bArHYX9YJWu2/wMWp4baHNM7f3en81JpuuIL0klR 7dzmzpF2VW+/bbEQ9oiwVAkfThmXhmidK1Zun1scyFKfaqoaTEj/h4GcDU3fDgZ0+qEe Lqh8WBnl8o0p5ULGwmxDE2jSw4cUERML4C9+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iSMVw4EPik0v5vvWKaMw3Strxe3X9QnHGvXatchVbProP571LBYWalKjSJmxWfYB3t 3tCU7NZCAcEc9HUFYNUPPitP9PvEtPCWJoijyZEmDeQBO8D+m4SWZevBT+q31QMCB51h VxFRk/CDc/ePWBAo1L+0UrrkfF7OtEunQpMX0= MIME-Version: 1.0 Received: by 10.239.187.72 with SMTP id k8mr751965hbh.47.1272470958710; Wed, 28 Apr 2010 09:09:18 -0700 (PDT) Received: by 10.239.166.68 with HTTP; Wed, 28 Apr 2010 09:09:18 -0700 (PDT) Date: Wed, 28 Apr 2010 18:09:18 +0200 Message-ID: From: Renaud Chaput To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Missing SYN/ACK answers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 16:31:40 -0000 Hi, I am using a DL360 G6 server with an additional Intel network card on FreeBSD 8.0-REL-p2 as a loadbalancer. I use nginx as an SSL endpoint, and haproxy as an HTTP loadbalancer. One port of the intel card (em0) is on the internal LAN, and another (em1) on the public LAN. An external monitoring tool reported that sometimes HTTP requests were during 3, 6 or even 9 seconds, in place of the 10-20ms which we usually see. I ran some tests, and I seen that sometimes no SYN/ACK is sent by the loadbalancer, the clients sents another one after 3 seconds, and then a SYN/ACK is sent. Sometime, the client needs to send the SYN 2 or 3 times to have and answer. Here is a tcpdump example : 13:57:52.978784 IP mas91-4-88-189-56-133.fbx.proxad.net.58484 > www-1.reverse.fotolia.net.http: Flags [S], seq 842845757, win 5840, options [mss 1460,sackOK,TS val 24878682 ecr 0,nop,wscale 7], length 0 13:57:55.978314 IP mas91-4-88-189-56-133.fbx.proxad.net.58484 > www-1.reverse.fotolia.net.http: Flags [S], seq 842845757, win 5840, options [mss 1460,sackOK,TS val 24879432 ecr 0,nop,wscale 7], length 0 13:57:55.978335 IP www-1.reverse.fotolia.net.http > mas91-4-88-189-56-133.fbx.proxad.net.58484: Flags [S.], seq 3988398305, ack 842845758, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2223023194 ecr 24879432], length 0 ... This is an HTTP request done using curl. It seems that i can reproduce it more easily when there is more traffic on the server. When I run ab (Apache Bench) on this server, I see things like this : # ab2 -n 1000 -c 20 http://server/images/flags/zoneFlagSprite.png This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking server (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: nginx/0.6.32 Server Hostname: server Server Port: 80 Document Path: /images/flags/zoneFlagSprite.png Document Length: 1979 bytes Concurrency Level: 20 Time taken for tests: 8.252 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 2261000 bytes HTML transferred: 1979000 bytes Requests per second: 121.18 [#/sec] (mean) Time per request: 165.047 [ms] (mean) Time per request: 8.252 [ms] (mean, across all concurrent requests) Transfer rate: 267.56 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 8 90 418.2 26 3027 Processing: 16 74 39.0 62 580 Waiting: 9 43 36.0 31 579 Total: 27 164 416.5 91 3115 Percentage of the requests served within a certain time (ms) 50% 91 66% 105 75% 120 80% 135 90% 171 95% 210 98% 3021 99% 3057 100% 3115 (longest request) All requests are pretty fast, but 2% lasts more than 3s. The result is the same when i request nginx, or when i request an URL handled by haproxy directly. I tried some sysctl tuning, with no visible results : security.bsd.unprivileged_read_msgbuf=0 security.bsd.see_other_uids=0 net.inet.ip.portrange.hilast=59999 net.inet.ip.portrange.hifirst=40000 net.inet.ip.portrange.last=59999 net.inet.ip.portrange.first=40000 net.inet.icmp.icmplim=3000 net.inet.icmp.drop_redirect=1 net.inet.tcp.slowstart_flightsize=4 net.inet.tcp.inflight.enable=1 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=65536 net.inet.udp.maxdgram=65536 net.inet.udp.recvspace=65536 net.inet.tcp.rfc1323=1 net.inet.tcp.blackhole=2 net.inet.tcp.msl=10000 net.inet.udp.blackhole=1 I also have some packet loss on this server, on the internal LAN. The losses are on the last hop, so not due to network. I dont know if this can be related. I have the same server on another datacenters, with an independant network, and see the same problem. I dont understand how this can be related. I tried with pf disabled, and this does not solve the issue. Any ideas on how to debug and solve this ? Thanks, Renaud Chaput From owner-freebsd-net@FreeBSD.ORG Thu Apr 29 01:31:33 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C13EC106566B for ; Thu, 29 Apr 2010 01:31:33 +0000 (UTC) (envelope-from chris.anders@velsys.com) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by mx1.freebsd.org (Postfix) with ESMTP id 5402A8FC0C for ; Thu, 29 Apr 2010 01:31:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAEx52EuWZVG//2dsb2JhbACBPo8tjQ+9aoUOBA Received: from eth7872.sa.adsl.internode.on.net (HELO velmail03.velsys.local) ([150.101.81.191]) by ipmail04.adl6.internode.on.net with ESMTP; 29 Apr 2010 10:46:14 +0930 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Apr 2010 11:46:15 +1030 Message-ID: <9595F39E2D27654A9184E2F7476D0F17A2E246@velmail03.velsys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FreeBSD + carp on VMWare ESX thread-index: AcrnOZCG2FjbyzQhTTS/lUKvzVKpzg== From: "Chris Anders" To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: mgrooms@shrew.net Subject: FreeBSD + carp on VMWare ESX X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 01:31:33 -0000 Hi All, =20 I appear to be suffering the same problem as many others on the internet = with carp and vmware vsphere (ESX4) when running with redundant nics in = the default failover mode which connect to two separate switches. =20 I have found this old thread - = http://www.mail-archive.com/freebsd-net@freebsd.org/msg30562.html which = talks about the exact same issue with a patch submitted to the list from = Matthew Grooms which can be found here - = http://www.shrew.net/static/patches/esx-carp.diff =20 After applying the patch, recompiling and setting = net.inet.carp.drop_echoed=3D1 in /etc/sysctl.conf my problem was solved! =20 Is there any way that this patch could be applied upstream as this = vsphere setup is rather common where Cross-Stack EtherChannel cannot be = deployed which is the known work around for this issue. =20 I also tried the patch submitted by Ermal Lu=E7i which didn't work... =20 I did all my testing with freebsd8-current From owner-freebsd-net@FreeBSD.ORG Thu Apr 29 05:30:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0082106566C for ; Thu, 29 Apr 2010 05:30:04 +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 A5CD38FC0A for ; Thu, 29 Apr 2010 05:30:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3T5U4T2044550 for ; Thu, 29 Apr 2010 05:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3T5U44F044545; Thu, 29 Apr 2010 05:30:04 GMT (envelope-from gnats) Date: Thu, 29 Apr 2010 05:30:04 GMT Message-Id: <201004290530.o3T5U44F044545@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Slava@kraslan.ru" Cc: Subject: Re: kern/145728: [lagg] Stops working lagg between two servers. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Slava@kraslan.ru" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 05:30:04 -0000 The following reply was made to PR kern/145728; it has been noted by GNATS. From: "Slava@kraslan.ru" To: bug-followup@FreeBSD.org, tempo@kgs.ru Cc: Subject: Re: kern/145728: [lagg] Stops working lagg between two servers. Date: Thu, 29 Apr 2010 12:41:36 +0800 3 days ago has refreshed one of servers to 8.0-STABLE from *default date=2010.04.05.00.00.00, the situation is a bit now another. Watchdog is not present, but the interface from lagg is in a state lagg1: flags=8943 metric 0 mtu 1500 options=9b ether 00:1b:21:1b:19:5d media: Ethernet autoselect status: active laggproto lacp laggport: em4 flags=18 laggport: em1 flags=1c em4: flags=8943 metric 0 mtu 1500 options=9b ether 00:1b:21:1b:19:5d media: Ethernet 1000baseT (1000baseT ) status: active Has tried to make ifconfig lagg1 -laggport em4 and then ifconfig lagg1 laggport em4 has not helped. From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 06:44:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEF791065674 for ; Fri, 30 Apr 2010 06:44:25 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 868498FC08 for ; Fri, 30 Apr 2010 06:44:25 +0000 (UTC) Received: (qmail 69906 invoked by uid 0); 30 Apr 2010 06:44:24 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Apr 2010 06:44:24 -0000 Date: Fri, 30 Apr 2010 02:44:24 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: freebsd-net@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: 8.0 carp problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 06:44:25 -0000 On Wed, 21 Apr 2010, Charles Sprickman wrote: > Hello, > > I still need to gather more info when I visit the datacenter to reboot one of > the problematic hosts, but I wanted to verify my basic carp config here was > solid. Said machine has been booted and is also on a remote power switch now. This keeps happening. The other host running carp+dnscache has not had any problems. It has the same config, same pf.conf rules (both the internal interface and carp interfaces are skipped - "set skip on ..."). The other host has an em interface. More info inline... > I have two hosts that are running a recursing name server on our internal > network for other servers. Since failover from multiple entries in > resolv.conf is painfully slow, I decided to start using carp to deal with > possible dns failure by having pairs of boxes setup with carp in arpbalance > mode. Testing in vmware proved this works well... > > However, after about 18 hours, one of the carp hosts (with an fxp interface) > paniced. Then after coming back up after that, it hard locked - no serial > console response, no ping response on either internal or external interfaces. > The other carp host (em interface) continues to run with no issues. > > My config on each box is pretty simple: > > carp-1: > > (rc.conf) > ifconfig_fxp1="inet 192.168.1.107 netmask 255.255.255.0 media 100baseTX > mediaopt full-duplex" > # carp stuff - this sets up two vhids, required for arpbalance > cloned_interfaces="carp0 carp1" > ifconfig_carp0="vhid 1 pass foobar 192.168.1.254/24" > ifconfig_carp1="vhid 2 advskew 100 pass foobar 192.168.1.254/24" > > (sysctl.conf) > net.inet.carp.arpbalance=1 > net.inet.carp.preempt=1 > > carp-2: > > (rc.conf) > ifconfig_em0="inet 192.168.1.121 netmask 255.255.255.0 media 1000baseTX > mediaopt full-duplex" > # carp stuff - this sets up two vhids, required for arpbalance > cloned_interfaces="carp0 carp1" > ifconfig_carp0="vhid 1 advskew 100 pass foobar 192.168.1.254/24" > ifconfig_carp1="vhid 2 pass foobar 192.168.1.254/24" > > (sysctl.conf) > net.inet.carp.arpbalance=1 > net.inet.carp.preempt=1 > > When the carp-1 paniced, this is what I saw in carp-2's logs: > > Apr 20 22:32:40 h21 kernel: carp0: link state changed to UP > Apr 20 22:39:52 h21 kernel: carp0: incorrect hash > Apr 20 22:39:52 h21 kernel: carp1: incorrect hash > Apr 20 22:39:52 h21 kernel: arp: 00:00:5e:00:01:02 is using my IP address > 192.168.1.254 on em0! > Apr 20 22:39:54 h21 kernel: carp0: link state changed to DOWN > Apr 20 22:40:19 h21 kernel: carp0: link state changed to UP > > carp-1 managed to squirt this out on the console before locking up: > > fxp1: discard frame w/o leading ethernet header (len 4294967294 pkt len > 4294967294) > > I'm bringing this up here since I've seen some traffic on -stable lately > regarding issues with some of the intel nics. I figure carp is probably > doing some "interesting" things to create virtual macs and the like. > > The two nics I'm using are as follows. > > carp-1: > > fxp1: port 0xd000-0xd03f mem > 0xfe9fd000-0xfe9fdfff,0xfe600000-0xfe6fffff irq 21 at device 5.0 on pci0^M > miibus1: on fxp1 > inphy1: PHY 1 on miibus1 > inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp1: Ethernet address: 00:e0:81:03:b0:13 > fxp1: [ITHREAD] pciconf: fxp1@pci0:0:5:0: class=0x020000 card=0x100c8086 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet > carp-2: > > em0: port 0x3800-0x381f mem > 0xfc220000-0xfc23ffff,0xfc200000-0xfc21ffff irq 31 at device 4.0 on pci3 > em0: [FILTER] > em0: Ethernet address: 00:30:48:12:2d:60 pciconf: em0@pci0:3:4:0: class=0x020000 card=0x100d8086 chip=0x100d8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (LOM) (82544GC)' class = network subclass = ethernet > I've not fiddled with any settings on either nic beyond forcing media and > duplex - so if checksum offloading is enabled/disabled by default, that's > what I'd be using. fxp1 on carp-1 supports and enabled "rxcsum" by default. Disabling it has not stopped the panics. > I can supply more information if needed. I need to boot the locked box, > enable dumps, and get more info on the revision of the fxp nics on it. Dumps have been enabled, but don't seem to be working very well. One did write out a "core.txt" file which has some decent information: panic: page fault cpuid = 1 Uptime: 4d19h43m50s Physical memory: 2035 MB Dumping 269 MB: 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 [reading symbols from zfs.ko, opensolaris.ko, geom_mirror.ko, sym.ko, pflog.ko, pf.ko] #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0x80674117 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0x80674409 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0x808f3a5c in trap_fatal (frame=0xda1b9895, eva=0) at /usr/src/sys/i386/i386/trap.c:933 #4 0x808f3cc0 in trap_pfault (frame=0xda1b9895, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:846 #5 0x808f4679 in trap (frame=0xda1b9895) at /usr/src/sys/i386/i386/trap.c:528 #6 0x808d786b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0x86ec7905 in pf_test (dir=2, ifp=0x85694400, m0=0xda1b9a3c, eh=0x0, inp=0x86d83c08) at mbuf.h:997 #8 0x86ecf77c in pf_check_out (arg=0x0, m=0xda1b9a3c, ifp=0x85694400, dir=2, inp=0x86d83c08) at /usr/src/sys/modules/pf/../../contrib/pf/net/pf_ioctl.c:3686 #9 0x807264d8 in pfil_run_hooks (ph=Cannot access memory at address 0x401b4) at /usr/src/sys/net/pfil.c:81 Previous frame inner to this frame (corrupt stack?) (kgdb) [...] Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0x86ec7905 stack pointer = 0x28:0xda1b98d5 frame pointer = 0x28:0xda1b99dc 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 = 761 (dnscache) trap number = 12 panic: page fault cpuid = 1 Uptime: 4d19h43m50s Physical memory: 2035 MB Dumping 269 MB: 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 This file also contains ps -axl, vmstat, netstat, and a whole mess of other stuff. I can supply any of that. Looking for any recommendations on how to troubleshoot this. I have no idea if this is carp, fxp, or pf causing the issue. I'm leaning towards the fxp driver since the other host is not having any issues. Tonight while getting this info together and trying to run kgdb (/usr/src and /usr/obj are nfs mounted off of fxp1), I watched performance degrade horribly on that interface (nfs timeouts, ssh connection stalling). There were also occasional hangs on the serial console session when I attempted to run tcpdump on fxp1. Eventually connectivity failed on fxp1 until a reboot. pf was showing no blocked packets, netstat and the switch stats showed no errors or drops on the interface. Arp resolution started failing and nothing but a reboot brought the network back. Bringing the interface up/down, turning on/off rxcsum did not bring anything back. Can anyone point me in the right direction? Should I give any particular -stable snapshot a spin? An 8.1-beta (not sure if that was tagged yet)? I'd really appreciate any input on this... Thanks, Charles > Thanks, > > Charles > From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 15:10:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62878106566B for ; Fri, 30 Apr 2010 15:10:04 +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 396198FC0C for ; Fri, 30 Apr 2010 15:10:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3UFA4di029548 for ; Fri, 30 Apr 2010 15:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3UFA3tN029547; Fri, 30 Apr 2010 15:10:03 GMT (envelope-from gnats) Date: Fri, 30 Apr 2010 15:10:03 GMT Message-Id: <201004301510.o3UFA3tN029547@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Joey Mingrone Cc: Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joey Mingrone List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 15:10:04 -0000 The following reply was made to PR kern/144755; it has been noted by GNATS. From: Joey Mingrone To: bug-followup@FreeBSD.org, edwin@mavetju.org Cc: Subject: Re: kern/144755: [iwi] [panic] iwi panic when issuing /etc/rc.d/netif restart on 8-STABLE r205159 Date: Fri, 30 Apr 2010 11:43:22 -0300 I'm seeing this as well after an upgrade to 8.0-RELEASE-p2 from 7.2-RELEASE. From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 15:15:05 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12CCE106566B for ; Fri, 30 Apr 2010 15:15:05 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (gateway.netasq.com [91.212.116.2]) by mx1.freebsd.org (Postfix) with ESMTP id D1F988FC0A for ; Fri, 30 Apr 2010 15:15:03 +0000 (UTC) Received: from [10.2.1.5] (unknown [10.2.1.5]) by work.netasq.com (Postfix) with ESMTPSA id E74E6740003 for ; Fri, 30 Apr 2010 17:14:57 +0200 (CEST) From: Fabien Thomas Content-Type: text/plain; charset=us-ascii Message-Id: Date: Fri, 30 Apr 2010 17:15:02 +0200 To: FreeBSD Net Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: m_getjcl and packet zone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabient@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 15:15:05 -0000 Hi all, While doing some 10Gb benchmark i've found that m_getjcl does not = benefit from the packet zone. There is a ~ 80% increase in FPS when applying the following patch. 256B frame driver to driver / stable_8: - 3 765 066 FPS - 6 868 153 FPS with the patch applied. Is there a good reason to not commit this ? Fabien diff --git a/sys/sys/mbuf.h b/sys/sys/mbuf.h index 158edb4..95a44a4 100644 --- a/sys/sys/mbuf.h +++ b/sys/sys/mbuf.h @@ -523,6 +523,9 @@ m_getjcl(int how, short type, int flags, int size) struct mbuf *m, *n; uma_zone_t zone; + if (size =3D=3D MCLBYTES) + return m_getcl(how, type, flags); + args.flags =3D flags; args.type =3D type; From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 19:14:05 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C4BC1065672; Fri, 30 Apr 2010 19:14:05 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 648B68FC1D; Fri, 30 Apr 2010 19:14:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3UJE5Ug042203; Fri, 30 Apr 2010 19:14:05 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3UJE5e0042199; Fri, 30 Apr 2010 19:14:05 GMT (envelope-from linimon) Date: Fri, 30 Apr 2010 19:14:05 GMT Message-Id: <201004301914.o3UJE5e0042199@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146190: [ipsec][patch] NAT traversal does not work in transport mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 19:14:05 -0000 Synopsis: [ipsec][patch] NAT traversal does not work in transport mode Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Apr 30 19:13:57 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=146190 From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 19:30:13 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF06D106564A for ; Fri, 30 Apr 2010 19:30:13 +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 A5D458FC23 for ; Fri, 30 Apr 2010 19:30:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3UJUDu2050849 for ; Fri, 30 Apr 2010 19:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3UJUDk6050848; Fri, 30 Apr 2010 19:30:13 GMT (envelope-from gnats) Date: Fri, 30 Apr 2010 19:30:13 GMT Message-Id: <201004301930.o3UJUDk6050848@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Robert Huff Cc: Subject: Re: kern/143939: [ipfw] [em] ipfw nat and em interface rxcsum problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Robert Huff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 19:30:13 -0000 The following reply was made to PR kern/143939; it has been noted by GNATS. From: Robert Huff To: bug-followup@FreeBSD.org, dima_bsd@inbox.lv Cc: Subject: Re: kern/143939: [ipfw] [em] ipfw nat and em interface rxcsum problem Date: Fri, 30 Apr 2010 14:55:02 -0400 Thirded. This fixed it on: FreeBSD 9.0-CURRENT #0: Fri Apr 23 11:34:17 EDT 2010 amd64 From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 21:02:18 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADC41106566C for ; Fri, 30 Apr 2010 21:02:18 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7118FC1A for ; Fri, 30 Apr 2010 21:02:18 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o3UKN1gC093955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 13:23:02 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <4BDB3C31.4050709@sippysoft.com> Date: Fri, 30 Apr 2010 13:23:13 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "current@freebsd.org" , freebsd-net@FreeBSD.ORG Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 21:02:18 -0000 Hi, Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to set length of the outgoing packets queue. The default value for that parameter is only 50, which is pretty low especially for the cases when the system handles lot of small packets and can cause ENOBUFS in applications under the load. The following patch makes IFQ_MAXLEN a tunable. I am also tempted to bump the default value for IFQ_MAXLEN 10-fold, but would like to hear what do people think about it first. http://sobomax.sippysoft.com/IFQ_MAXLEN.diff -Maxim From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 21:09:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45FD8106566B for ; Fri, 30 Apr 2010 21:09:02 +0000 (UTC) (envelope-from Carl.Ellis@tenasys.com) Received: from tenasys.com (apps.tenasys.com [70.102.94.118]) by mx1.freebsd.org (Postfix) with ESMTP id 285678FC08 for ; Fri, 30 Apr 2010 21:09:02 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 30 Apr 2010 13:57:00 -0700 Message-ID: <9032C63D3598B548A932D19B5251BBC683496E@fava.TenAsys.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5227 Thread-Index: Acrop63+JoDoe/z2RCOjmwed0rNO3A== From: "Carl Ellis" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: RFC 5227 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 21:09:02 -0000 How much of rfc 5227 is supported by FreeBSD > 7.0? Any insight into plans for support? From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 21:29:02 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 637D3106566C for ; Fri, 30 Apr 2010 21:29:02 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grosbein.pp.ru [89.189.172.146]) by mx1.freebsd.org (Postfix) with ESMTP id A859E8FC0A for ; Fri, 30 Apr 2010 21:29:01 +0000 (UTC) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.4/8.14.4) with ESMTP id o3UL8TSt028836; Sat, 1 May 2010 04:08:30 +0700 (NOVST) (envelope-from eugen@grosbein.pp.ru) Message-ID: <4BDB46CD.80004@grosbein.pp.ru> Date: Sat, 01 May 2010 04:08:29 +0700 From: Eugene Grosbein User-Agent: Thunderbird 2.0.0.23 (X11/20091107) MIME-Version: 1.0 To: Maxim Sobolev References: <4BDB3C31.4050709@sippysoft.com> In-Reply-To: <4BDB3C31.4050709@sippysoft.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 21:29:02 -0000 Maxim Sobolev wrote: > Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to > set length of the outgoing packets queue. The default value for that > parameter is only 50, which is pretty low especially for the cases when > the system handles lot of small packets and can cause ENOBUFS in > applications under the load. The following patch makes IFQ_MAXLEN a > tunable. I am also tempted to bump the default value for IFQ_MAXLEN > 10-fold, but would like to hear what do people think about it first. I've not checked implementation yet, but idea is pretty useful. In fact, this ought be done years ago, imho. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 21:33:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 496321065674; Fri, 30 Apr 2010 21:33:45 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 113E18FC0C; Fri, 30 Apr 2010 21:33:44 +0000 (UTC) Received: by pvg3 with SMTP id 3so417528pvg.13 for ; Fri, 30 Apr 2010 14:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ihlNvhArHWH9lY2wHe8Ivv7flaRg2pdDQR+vEmsurOs=; b=rKSq8PeJD18CwauT1ZqNr1IKPEWM5PIvPEMKcd2eH+fTxKwDWsMQzMjt/6WSKBkQ5k yNt+1GIKeEDoB3ctV93DiCVYn4kGZi0m9LqT4sklPDM+Y50iXdzUV6H8P6XEOpaCoOwl 1Ku653lqHESVxXK6DGum6hhKGH29g++s5LeUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MxSuilOClrKTODpjkieHsthwy6BqT6aWWqBZf1v1lEt4G3b+PPxuKX/7ywhsFdaZHf kNz1rRuCYu5997xB2Kz8Iw6GNvxE247g5C1jBthqgMLh/oVwCj+pscp4SdZHq1Kd0m5r /zFLLdldJbWvve11RdDubxnTmiYC0TXX2gj94= Received: by 10.114.164.39 with SMTP id m39mr12425772wae.56.1272663222057; Fri, 30 Apr 2010 14:33:42 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id c14sm10627441waa.13.2010.04.30.14.33.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Apr 2010 14:33:41 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BDB4CAE.20006@elischer.org> Date: Fri, 30 Apr 2010 14:33:34 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Maxim Sobolev References: <4BDB3C31.4050709@sippysoft.com> In-Reply-To: <4BDB3C31.4050709@sippysoft.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.ORG, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 21:33:45 -0000 On 4/30/10 1:23 PM, Maxim Sobolev wrote: > Hi, > > Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to > set length of the outgoing packets queue. The default value for that > parameter is only 50, which is pretty low especially for the cases when > the system handles lot of small packets and can cause ENOBUFS in > applications under the load. The following patch makes IFQ_MAXLEN a > tunable. I am also tempted to bump the default value for IFQ_MAXLEN > 10-fold, but would like to hear what do people think about it first. > > http://sobomax.sippysoft.com/IFQ_MAXLEN.diff > > -Maxim > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" so just tunable? not a sysctl :-) patch could be a lot smaller if you defined IFQ_MAXLEN to be V_ifqmaxlen (do different vimages want a different value?) From owner-freebsd-net@FreeBSD.ORG Fri Apr 30 22:00:12 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE913106566B; Fri, 30 Apr 2010 22:00:11 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id A90028FC15; Fri, 30 Apr 2010 22:00:11 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o3UM08Ib094512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 15:00:09 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4BDB52F4.2010100@FreeBSD.org> Date: Fri, 30 Apr 2010 15:00:20 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Julian Elischer References: <4BDB3C31.4050709@sippysoft.com> <4BDB4CAE.20006@elischer.org> In-Reply-To: <4BDB4CAE.20006@elischer.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 22:00:12 -0000 Julian Elischer wrote: > On 4/30/10 1:23 PM, Maxim Sobolev wrote: >> Hi, >> >> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to >> set length of the outgoing packets queue. The default value for that >> parameter is only 50, which is pretty low especially for the cases when >> the system handles lot of small packets and can cause ENOBUFS in >> applications under the load. The following patch makes IFQ_MAXLEN a >> tunable. I am also tempted to bump the default value for IFQ_MAXLEN >> 10-fold, but would like to hear what do people think about it first. >> >> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff > > so just tunable? not a sysctl :-) The sysctl would require much bigger rewrite. As long as I understand the value is now cached in many instances of the ifnet structure, and some drivers even use their own queue length instead of IFQ_MAXLEN. Therefore, even if I make this parameter a sysctl one would have to destroy interface and create it again in order for the change to have an effect. Therefore, keeping it tunable would be less confusing. > patch could be a lot smaller if you defined IFQ_MAXLEN to be V_ifqmaxlen > (do different vimages want a different value?) I am not quite sure about that. AFAIK vimage is more high-level thing, while this parameter controls queue length between kernel and hardware interface driver. vimage lies above that. -Maxim From owner-freebsd-net@FreeBSD.ORG Sat May 1 09:10:55 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59BF6106564A; Sat, 1 May 2010 09:10:55 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC148FC13; Sat, 1 May 2010 09:10:54 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.175.212]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id o419Aq0T097389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 May 2010 02:10:53 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4BDBF028.5040505@FreeBSD.org> Date: Sat, 01 May 2010 02:11:04 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: gljennjohn@googlemail.com References: <4BDB3C31.4050709@sippysoft.com> <20100501105823.28ac1756@ernst.jennejohn.org> In-Reply-To: <20100501105823.28ac1756@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 09:10:55 -0000 Gary Jennejohn wrote: > On Fri, 30 Apr 2010 13:23:13 -0700 > Maxim Sobolev wrote: > >> Hi, >> >> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to >> set length of the outgoing packets queue. The default value for that >> parameter is only 50, which is pretty low especially for the cases when >> the system handles lot of small packets and can cause ENOBUFS in >> applications under the load. The following patch makes IFQ_MAXLEN a >> tunable. I am also tempted to bump the default value for IFQ_MAXLEN >> 10-fold, but would like to hear what do people think about it first. >> >> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff >> > > Seems like a good idea, although I don't see where ifqmaxlen is being > initialized. sys/net/if.c -Maxim From owner-freebsd-net@FreeBSD.ORG Sat May 1 09:20:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34ED6106564A; Sat, 1 May 2010 09:20:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id D86038FC0C; Sat, 1 May 2010 09:20:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 6268241C6A3; Sat, 1 May 2010 11:20:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id efeOcqrf7+pF; Sat, 1 May 2010 11:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id D3F8841C67B; Sat, 1 May 2010 11:20:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id F347D4448EC; Sat, 1 May 2010 09:17:05 +0000 (UTC) Date: Sat, 1 May 2010 09:17:04 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Maxim Sobolev In-Reply-To: <4BDB52F4.2010100@FreeBSD.org> Message-ID: <20100501091158.B23815@maildrop.int.zabbadoz.net> References: <4BDB3C31.4050709@sippysoft.com> <4BDB4CAE.20006@elischer.org> <4BDB52F4.2010100@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, Julian Elischer , "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 09:20:08 -0000 On Fri, 30 Apr 2010, Maxim Sobolev wrote: Hi, > Julian Elischer wrote: >> On 4/30/10 1:23 PM, Maxim Sobolev wrote: >>> Hi, >>> >>> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to >>> set length of the outgoing packets queue. The default value for that >>> parameter is only 50, which is pretty low especially for the cases when >>> the system handles lot of small packets and can cause ENOBUFS in >>> applications under the load. The following patch makes IFQ_MAXLEN a >>> tunable. I am also tempted to bump the default value for IFQ_MAXLEN >>> 10-fold, but would like to hear what do people think about it first. >>> >>> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff >> >> so just tunable? not a sysctl :-) > > The sysctl would require much bigger rewrite. As long as I understand the > value is now cached in many instances of the ifnet structure, and some > drivers even use their own queue length instead of IFQ_MAXLEN. Therefore, > even if I make this parameter a sysctl one would have to destroy interface > and create it again in order for the change to have an effect. Therefore, > keeping it tunable would be less confusing. > >> patch could be a lot smaller if you defined IFQ_MAXLEN to be V_ifqmaxlen >> (do different vimages want a different value?) > > I am not quite sure about that. AFAIK vimage is more high-level thing, while > this parameter controls queue length between kernel and hardware interface > driver. vimage lies above that. My leaning goes that it should be a global system boottime configuration and neither a sysctl nor a value per virtual network stack. If we'd want it to be anything else, like making a sysctl I'd prefer to have it global rather than having someone inside a virtual network stack as it basically restricts the usage of global resources (mbufs). If we can get it a sysctl and will have resources limits it will be easily converted into a per-vnet configuration. /bz -- Bjoern A. Zeeb See you when I see you. From owner-freebsd-net@FreeBSD.ORG Sat May 1 09:25:31 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B556106564A; Sat, 1 May 2010 09:25:31 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id F36518FC1F; Sat, 1 May 2010 09:25:30 +0000 (UTC) Received: by fxm15 with SMTP id 15so960311fxm.13 for ; Sat, 01 May 2010 02:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=YEmA4/lN/sEcNOOqlhiJPoX8QBPfaiaoMggK8MfDUm4=; b=LH1SfxPj761T3/hNiqTHtofebL2NXMEnY2OisnzHOtXENwB9Fko5dNPn2SXVyZx6o9 hF4a5ixuT4PzIs1Tud4QV1D0DJfiUYKyFFGEd38DROobft93ZoFP3S4nDul3zyeHScQv vJxcMLYV95wJ3gEnlyz9pfGdkq+7jE60IvrnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=eVJVOUJWDaxn4nRxr4InpIapgxinCg+FScET9LClhsWQuN752dD6gcAWd8Pj0Ntd9v jSUEHti3R9g502uPtdO20MwlrBi6I3AzxGY45E4qfZYpBVu6PfQeSfqAl03MUU/i4Fov J7zgcovtOWyKbSOkqGQB/gbXKCCSdi4t50WTU= Received: by 10.223.143.67 with SMTP id t3mr1954782fau.16.1272705926907; Sat, 01 May 2010 02:25:26 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE08B7.dip0.t-ipconnect.de [87.174.8.183]) by mx.google.com with ESMTPS id z15sm4650298fkz.21.2010.05.01.02.25.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 May 2010 02:25:26 -0700 (PDT) Date: Sat, 1 May 2010 11:25:24 +0200 From: Gary Jennejohn To: Maxim Sobolev Message-ID: <20100501112524.26c2fe5c@ernst.jennejohn.org> In-Reply-To: <4BDBF028.5040505@FreeBSD.org> References: <4BDB3C31.4050709@sippysoft.com> <20100501105823.28ac1756@ernst.jennejohn.org> <4BDBF028.5040505@FreeBSD.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 09:25:31 -0000 On Sat, 01 May 2010 02:11:04 -0700 Maxim Sobolev wrote: > Gary Jennejohn wrote: > > On Fri, 30 Apr 2010 13:23:13 -0700 > > Maxim Sobolev wrote: > > > >> Hi, > >> > >> Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to > >> set length of the outgoing packets queue. The default value for that > >> parameter is only 50, which is pretty low especially for the cases when > >> the system handles lot of small packets and can cause ENOBUFS in > >> applications under the load. The following patch makes IFQ_MAXLEN a > >> tunable. I am also tempted to bump the default value for IFQ_MAXLEN > >> 10-fold, but would like to hear what do people think about it first. > >> > >> http://sobomax.sippysoft.com/IFQ_MAXLEN.diff > >> > > > > Seems like a good idea, although I don't see where ifqmaxlen is being > > initialized. > > sys/net/if.c > Shame on me for not looking at the file itself! I only looked at the patch. -- Gary Jennejohn From owner-freebsd-net@FreeBSD.ORG Sat May 1 09:28:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AED18106566B; Sat, 1 May 2010 09:28:10 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 153508FC13; Sat, 1 May 2010 09:28:09 +0000 (UTC) Received: by fxm15 with SMTP id 15so961498fxm.13 for ; Sat, 01 May 2010 02:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=DEz01Ue3ca19vyyQpkXi9wC8ivXFLfDFMEQ3awPD+ts=; b=E8T+0FHN+/dHOwgnEifqg/+d6MdC2TR37x+O2g7wDypuWsIaxOQTB/+YjbM3jrIBZv WAi3ythaBeWINy7xe2wi/I3mmBCD5pbx+2p4AJQ2327F31ajRuBz0EJ0MWDAsWXmcztR /kS4+GR4JG73/r3yCPH1IVRcSJIHeo1fW+1EY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=WmXoTVWLR93rY2rQdwFlLqKIAaJqx3Jhxh9RmtBIsHotJmMC24QjtsRPkzDxgMbz7U RfYLlsujr8o6v7EuTJvo2ggNq6Q/NqEAPcSYvf7tYs1yGnznk5SSvgbeoycTK4P5qcSy sMzHNmLmwTvC2CJMM5du65wQs7e1c2zbyLVbU= Received: by 10.223.16.84 with SMTP id n20mr1955905faa.94.1272704305623; Sat, 01 May 2010 01:58:25 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE08B7.dip0.t-ipconnect.de [87.174.8.183]) by mx.google.com with ESMTPS id 35sm4614435fkt.37.2010.05.01.01.58.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 01 May 2010 01:58:24 -0700 (PDT) Date: Sat, 1 May 2010 10:58:23 +0200 From: Gary Jennejohn To: Maxim Sobolev Message-ID: <20100501105823.28ac1756@ernst.jennejohn.org> In-Reply-To: <4BDB3C31.4050709@sippysoft.com> References: <4BDB3C31.4050709@sippysoft.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.ORG, "current@freebsd.org" Subject: Re: Making IFQ_MAXLEN tunable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 09:28:10 -0000 On Fri, 30 Apr 2010 13:23:13 -0700 Maxim Sobolev wrote: > Hi, > > Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to > set length of the outgoing packets queue. The default value for that > parameter is only 50, which is pretty low especially for the cases when > the system handles lot of small packets and can cause ENOBUFS in > applications under the load. The following patch makes IFQ_MAXLEN a > tunable. I am also tempted to bump the default value for IFQ_MAXLEN > 10-fold, but would like to hear what do people think about it first. > > http://sobomax.sippysoft.com/IFQ_MAXLEN.diff > Seems like a good idea, although I don't see where ifqmaxlen is being initialized. -- Gary Jennejohn