From owner-freebsd-net@FreeBSD.ORG Sun Mar 20 12:19:50 2011 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 C007F1065670; Sun, 20 Mar 2011 12:19:50 +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 96E348FC12; Sun, 20 Mar 2011 12:19:50 +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 p2KCJoVp023991; Sun, 20 Mar 2011 12:19:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2KCJosN023987; Sun, 20 Mar 2011 12:19:50 GMT (envelope-from linimon) Date: Sun, 20 Mar 2011 12:19:50 GMT Message-Id: <201103201219.p2KCJosN023987@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155714: [zyd] [panic] zyd_bulk_write_callback panic in 8.2-RELEASE [regression] 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, 20 Mar 2011 12:19:50 -0000 Old Synopsis: zyd_bulk_write_callback panic in 8.2-RELEASE New Synopsis: [zyd] [panic] zyd_bulk_write_callback panic in 8.2-RELEASE [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 20 12:19:05 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=155714 From owner-freebsd-net@FreeBSD.ORG Sun Mar 20 18:23:57 2011 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 7A9E8106566C for ; Sun, 20 Mar 2011 18:23:57 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by mx1.freebsd.org (Postfix) with ESMTP id 460288FC1A for ; Sun, 20 Mar 2011 18:23:57 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IzPATvPQzcpW55W5AkfCxrGXvSqk8MVBG3c3cjR7bqmh92J4hHPaIimm0ucIcuJW; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Q1N4q-0006r5-A5; Sun, 20 Mar 2011 14:10:08 -0400 Message-ID: <4D8642FF.6050400@earthlink.net> Date: Sun, 20 Mar 2011 14:10:07 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Eugene M. Zheganin" References: <4D8370AB.1070000@zhegan.in> <20110318.195636.74687196.sthaug@nethelp.no> <4D846A9C.7000705@zhegan.in> In-Reply-To: <4D846A9C.7000705@zhegan.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79d80d49b1114234bc57ecb9275300861c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: freebsd-net@freebsd.org Subject: Re: ipv6, stateful config and non-default prefixlen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 18:23:57 -0000 On 03/19/2011 04:34 AM, Eugene M. Zheganin wrote: > Hi. > > On 18.03.2011 23:56, sthaug@nethelp.no wrote: >> Are you using IA_PD or IA_NA on your DHCPv6 server? > Since I didn't configure anything on a DHCPv6 server about PD, I > assume I'm using NA. > >> rtadvd can give you the default router. >> >> DHCPv6 IA_NA gives you a single /128 address and no netmask. >> >> DHCPv6 IA_PD gives you a prefix (with the netmask of your choice), but >> I don't know whether FreeBSD can (easily) use this. > I don't see a relation between these 2 things. Prefix delegation is > used to assign prefixes to client _routers_, without knowing about the > topology. I'm configuring a _workstation_. I don't need a prefix to > assign addresses to other computers, I don't have a network behind > this workstation, I need to know about my prefix, and I have that > information in ndp cache, although it is somehow useless. > >> As mentioned, DHCPv6 IA_PD gives you a prefix. And ISC dhclient can ask >> for it, see the the -P option. > "The Prefix Delegation options provide a mechanism for > automateddelegation of IPv6 prefixes using the Dynamic Host > Configuration Protocol (DHCP). This mechanism is intended for > delegating a long-lived prefix from a delegating router to a > requesting router, acrossan administrative boundary, where the > delegating router does not require knowledge about the topology of the > links in the network to which the prefixes will be assigned." And > that's from RFC. > >> If you use DHCPv6 IA_NA, you receive a single /128 address (it is /128 >> by definition, the DHCP answer doesn't include a netmask). > That seems to be a mistake. Look what explanation I found in the ietf > maillist: > > "Interface addresses are completely SEPARATE from routing > information.Please do NOT confuse the two. This has been a source of > confusion formany IPv6 implementors who know IPv4.The configuration of > addresses for an interface MUST NOT be tied to the configuration of > prefix information for routing. Just because a prefix is on a link, > does not mean the interface necessarily has an address for that prefix > (it may have none, 1, or many). Just because an interface has an > address, does not mean that the system has any prefix information for > a prefix that "contains" that address. Prefix information and > addresses assigned to interfaces are completely separate." > > So it's just an address. Not a /128, just an address. > >> You should *not* expect to reach other computers on the link >> through such a /128 >> address > So, in other words, DHCPv6 is useless. No, I don't think so. I have a > bunch of windows on the same link, working with the same DHCPv6 > server, and doing just fine. And that's sad, because I used to think > that FreeBSD is always a queen of the network, far ahead of the > non-truly-networked OS bunch. I'm still hoping that this /64 prefix > issue is related to my low knowledge. > > P.S. And I know that autoconfiguration won't work on a link with /120. > And of course, THAT is the reason why I'm using the DHCPv6. > > Eugene. > _______________________________________________ > 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" > How does a router that is using dhclient to get delegated a address prefix from an upstream router obtain its default route, since dhcpv6 can't provide a default route. And since it is a router it can't get its default route from router advertisements from the upstream router? -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Sun Mar 20 18:58:56 2011 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 3EA13106566C for ; Sun, 20 Mar 2011 18:58:56 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id BB1CD8FC0A for ; Sun, 20 Mar 2011 18:58:55 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id p2KIwub2012137 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 20 Mar 2011 19:58:56 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id p2KIwut9005305; Sun, 20 Mar 2011 19:58:56 +0100 (MET) Date: Sun, 20 Mar 2011 19:58:56 +0100 From: Daniel Hartmeier To: Viktor Petersson Message-ID: <20110320185856.GA7703@insomnia.benzedrine.cx> References: <00612801-A0F4-4EDC-9BED-3364A86E4F9C@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00612801-A0F4-4EDC-9BED-3364A86E4F9C@gmail.com> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: Possible CARP 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: Sun, 20 Mar 2011 18:58:56 -0000 On Fri, Mar 18, 2011 at 04:43:59PM +0100, Viktor Petersson wrote: > Mar 7 14:42:57 nas0 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) This could mean that the master is receiving its own CARP advertisements back, and, thinking they come from another host, backs off. CARP advertisements are sent through the physical interface to a broadcast MAC address (01:00:5e:00:x:y) and the broadcast IP address 224.0.0.18. A real physical switch will forward that frame to all ports except the one it was received on, i.e. the frame will not be sent back to the sender. You mention a virtual enviroment, so maybe the switch is virtual, too, and behaves differently. You can check by tcpdump'ing on the physical interface of the master. You should see each advertisement once (going out, but tcpdump doesn't indicate the direction). Look at the IP IDs, if you see each ID twice, you're getting the broadcasts back. I think newer versions of CARP (in OpenBSD) contain an explicit check to detect this case (it can be thought of as a form of replay attack), which could be ported. But there might also be a setting in Qemu's virtual switch, that deals with such broadcasts. HTH, Daniel From owner-freebsd-net@FreeBSD.ORG Sun Mar 20 20:08:43 2011 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 03264106566C for ; Sun, 20 Mar 2011 20:08:43 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 33AE78FC0A for ; Sun, 20 Mar 2011 20:08:41 +0000 (UTC) Received: (qmail 77105 invoked from network); 20 Mar 2011 20:08:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 20 Mar 2011 20:08:39 -0000 Date: Sun, 20 Mar 2011 21:08:39 +0100 (CET) Message-Id: <20110320.210839.74676285.sthaug@nethelp.no> To: sclark46@earthlink.net From: sthaug@nethelp.no In-Reply-To: <4D8642FF.6050400@earthlink.net> References: <20110318.195636.74687196.sthaug@nethelp.no> <4D846A9C.7000705@zhegan.in> <4D8642FF.6050400@earthlink.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ipv6, stateful config and non-default prefixlen 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, 20 Mar 2011 20:08:43 -0000 > How does a router that is using dhclient to get delegated a address > prefix from an upstream router obtain its default route, since dhcpv6 > can't provide a default route. > And since it is a router it can't get its default route from router > advertisements from the upstream router? It behaves both as a host and as a router: - As a host it receives a default route from RA from its upstream router - and it can also receive an address (IA_NA) or a prefix (IA_PD) using DHCPv6. - As a router it can send RA on its LAN segment(s), and it can also act as a DHCPv6 server. In principle it could subdivide a prefix obtained with DHCPv6 IA_PD (for instance a /56) into suitable /64 prefixes and announce these on separate LAN segments - thgough I don't know of any boxes that do this automagically today. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Mon Mar 21 03:24:04 2011 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 617221065676; Mon, 21 Mar 2011 03:24:04 +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 3C4A48FC13; Mon, 21 Mar 2011 03:24: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 p2L3O48h042252; Mon, 21 Mar 2011 03:24:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2L3O4c5042248; Mon, 21 Mar 2011 03:24:04 GMT (envelope-from linimon) Date: Mon, 21 Mar 2011 03:24:04 GMT Message-Id: <201103210324.p2L3O4c5042248@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155420: [vlan] adding vlan break existent vlan 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, 21 Mar 2011 03:24:04 -0000 Old Synopsis: adding vlan break existent vlan New Synopsis: [vlan] adding vlan break existent vlan Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 21 03:23:42 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=155420 From owner-freebsd-net@FreeBSD.ORG Mon Mar 21 09:43:24 2011 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 6A202106566B for ; Mon, 21 Mar 2011 09:43:24 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 24EC08FC18 for ; Mon, 21 Mar 2011 09:43:23 +0000 (UTC) Received: by qwc9 with SMTP id 9so4385629qwc.13 for ; Mon, 21 Mar 2011 02:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=PeYyDGqYylHfG8xi9xEcTzVxwpdd8cD1U0hz5bu8ceg=; b=CWCgixNhUwXXWToLw2HZo0/XgphSXG1NBqmUSU/sPmLeiBBTchFBdR9Lq+d0KbO0iJ 0+fP71xKo6hoi2yeXCN/DXUySiWKdFuHAtos+1JqhZB1s5M+7hSjsoWgKmcSclYpxcae NOppAFhOUc0fXaArpAE/tHOlBuqPvOaeS8s4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tDdFcJdYvZYDbIhLex49yVuY+BsCWCwp9aKXikIYa76WjbKTP9F5efONaEiL6k5HsJ mwoi5fI8m5iuEAPcwiLWk7nMZx1nWbGCv+Ro0e6f/hxKLfMtslHLmCNWNoDIfaN1oyoM hLb1Qro0p0xDuWOli68K4E9/cY2InTHAe+7E8= MIME-Version: 1.0 Received: by 10.229.45.147 with SMTP id e19mr3051939qcf.75.1300700603412; Mon, 21 Mar 2011 02:43:23 -0700 (PDT) Received: by 10.229.232.146 with HTTP; Mon, 21 Mar 2011 02:43:23 -0700 (PDT) Date: Mon, 21 Mar 2011 12:43:23 +0300 Message-ID: From: Sergey Kandaurov To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Subject: panic in dummynet 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, 21 Mar 2011 09:43:24 -0000 Hi. This is a 8.1 box, not very much loaded. It has two simple dummynet rules. That's the first time it panics there. Any hints? db> x/s *panicstr 0: *** error reading from address 0 *** db> bt Tracing pid 0 tid 100116 td 0xffffff000ab057c0 m_copym() at m_copym+0x37 ip_fragment() at ip_fragment+0x132 ip_output() at ip_output+0xeef dummynet_send() at dummynet_send+0x14c dummynet_task() at dummynet_task+0x1b7 taskqueue_run() at taskqueue_run+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8399222d30, rbp = 0 --- -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Mon Mar 21 11:07:02 2011 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 E44231065675 for ; Mon, 21 Mar 2011 11:07:02 +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 D42658FC16 for ; Mon, 21 Mar 2011 11:07:02 +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 p2LB726o086059 for ; Mon, 21 Mar 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2LB72RB086055 for freebsd-net@FreeBSD.org; Mon, 21 Mar 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Mar 2011 11:07:02 GMT Message-Id: <201103211107.p2LB72RB086055@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, 21 Mar 2011 11:07:03 -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/155714 net [zyd] [panic] zyd_bulk_write_callback panic in 8.2-REL o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155636 net [msk] msk driver locks marvel yukon 88E8057 NIC o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155555 net [netinet] [patch] Panic in in_scrubprefix() during 'if o kern/155498 net [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [routed] [patch] if.c in routed fails to compile if ti o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154831 net [arp] [patch] arp sysctl setting log_arp_permanent_mod o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154676 net [netgraph] [panic] HEAD, 8.1-RELEASE panic after some o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154567 net [ath] ath(4) lot of bad series(0) o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154284 net [ath] Modern ath wifi cards (such as AR9285) have miss o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/154006 net [tcp] [patch] tcp "window probe" bug on 64bit o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153671 net [em] [panic] 8.2-PRERELEASE repeatable kernel in if_em o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153255 net [panic] 8.2-PRERELEASE repeatable kernel panic under h o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152360 net [dummynet] [panic] Crash related to dummynet. o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o bin/150642 net netstat(1) doesn't print anything for SCTP sockets o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. o kern/144987 net [wpi] [panic] injecting packets with wlaninject using f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi 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 conf/144700 net [rc.d] async dhclient breaks stuff for too many people 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 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length 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] [request] allow Atheros watchdog timeout 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/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/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143034 net [panic] system reboots itself in tcp code [regression] 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/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 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph 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/140346 net [wlan] High bandwidth use causes loss of wlan connecti 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/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 p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) 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/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/138620 net [lagg] [patch] lagg port bpf-writes blocked 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/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 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/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/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/135502 net [periodic] Warning message raised by rtfree function i 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/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/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... 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/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/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run 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/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 bin/131365 net route(8): route add changes interpretation of network 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 f 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/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 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/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/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/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 o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic o kern/125501 net [ath] atheros cardbus driver hangs f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa f kern/125332 net [ath] [panic] crash under any non-tiny networking unde 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/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. 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 kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one 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 conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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 f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge 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/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 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net 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/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi 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/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 o kern/118727 net [netgraph] [patch] [request] add new ng_pf module 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/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/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 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/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 bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! 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/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] f 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/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 o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack 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 f 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 s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu 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/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k 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/86427 net [lor] Deadlock with FASTIPSEC and nat 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 p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip 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 o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if 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 a kern/71474 net [route] route lookup does not skip interfaces marked d 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 o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic 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/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 393 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 21 13:01:13 2011 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 C280B1065677; Mon, 21 Mar 2011 13:01:13 +0000 (UTC) (envelope-from pluknet@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9BAD58FC17; Mon, 21 Mar 2011 13:01: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 p2LD1DLW098568; Mon, 21 Mar 2011 13:01:13 GMT (envelope-from pluknet@freefall.freebsd.org) Received: (from pluknet@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2LD1Dlg098559; Mon, 21 Mar 2011 13:01:13 GMT (envelope-from pluknet) Date: Mon, 21 Mar 2011 13:01:13 GMT Message-Id: <201103211301.p2LD1Dlg098559@freefall.freebsd.org> To: pluknet@FreeBSD.org, freebsd-net@FreeBSD.org, pluknet@FreeBSD.org From: pluknet@FreeBSD.org Cc: Subject: Re: kern/155555: [netinet] [patch] Panic in in_scrubprefix() during 'ifconfig delete' 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, 21 Mar 2011 13:01:13 -0000 Synopsis: [netinet] [patch] Panic in in_scrubprefix() during 'ifconfig delete' Responsible-Changed-From-To: freebsd-net->pluknet Responsible-Changed-By: pluknet Responsible-Changed-When: Mon Mar 21 13:00:46 UTC 2011 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=155555 From owner-freebsd-net@FreeBSD.ORG Mon Mar 21 17:01:06 2011 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 7EBA61065670 for ; Mon, 21 Mar 2011 17:01:06 +0000 (UTC) (envelope-from andrei.manescu@ivorde.ro) Received: from mail.ivorde.ro (mail.ivorde.ro [82.76.71.249]) by mx1.freebsd.org (Postfix) with ESMTP id BEFCE8FC17 for ; Mon, 21 Mar 2011 17:01:05 +0000 (UTC) Comment: DomainKeys? See http://domainkeys.sourceforge.net/ DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ivorde.ro; b=n750Glg0ITE08Zvhh0eL9KK9CxiAfOI/HThjUpH3UUs7DJKbzXCimMM2ZnsvVz0M2CSORVFz75O6aIMw42fea5v0ySuzBD62wFfYfYKgejDlboqlaQue0spoSp0TU3Wd; h=Received:Received:Received:Received:MIME-Version:Date:From:To:Subject:Reply-To:Message-ID:X-Sender:User-Agent:Content-Type; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=ivorde.ro; h=mime-version :date:from:to:subject:reply-to:message-id:content-type; s= default; bh=aU9yh8vnQ+6sFsQigFwyUZQto/Y=; b=vmcLM+BcJLOn0I6FPxIE 0Ne5VBAEe7Y0AgScTSITkchInDSdUaFjgC99l4aiN12g/NDUxz1oW2w+Ng2P6CiA EI/+SoHf5dZsGYI7HivkC8TZHMPlmyPtcFHopnfic7mQ Received: (qmail 81838 invoked by uid 0); 21 Mar 2011 18:30:45 +0200 Received: from azguard.ivorde.ro by mail.ivorde.ro (envelope-from , uid 1001) with qmail-scanner-2.08st (clamdscan: 0.97/12664. spamassassin: 3.2.5. perlscan: 2.08st. Clear:RC:1(10.1.1.22):. Processed in 0.11474 secs); 21 Mar 2011 16:30:45 -0000 Received: from azguard.ivorde.ro (10.1.1.22) by mail.ivorde.ro with SMTP; 21 Mar 2011 18:30:44 +0200 Received: from mail.ivorde.ro (www.flashleasing.ro [192.168.1.10]) (Authenticated sender: andrei.manescu@ivorde.ro) by azguard.ivorde.ro (Postfix) with ESMTPA id 718D5820BC for ; Mon, 21 Mar 2011 18:34:26 +0200 (EET) MIME-Version: 1.0 Date: Mon, 21 Mar 2011 18:30:44 +0200 From: Andrei Manescu - Ivorde To: Message-ID: X-Sender: andrei.manescu@ivorde.ro User-Agent: excy.nl mail Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: tcp/ip stack sending icmp "ttl exceeded in traffic" back through gre \w ipsec-esp encryption tunnels. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrei@ivorde.ro List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:01:06 -0000 Hello, I was following up on this old thread "ICMP Error transmission/response over IPSec tunnels [1]" as I'm running into a similar issue on 7.4-STABLE: Problem: RouterA and RouterB in the following diagram are FreeBSD 6.4-STABLE and 7.4-STABLE running a gre tunnel and ipsec transport mode encryption on top of it. None of them send an icmp error "TTL Exceeded in traffic" when the TTL of the packet reaches 0 after they decrement it. Code: hostA----RouterA--GRE-inside-IPSEC/ESP/transport---RouterB---hostB Packets sent from hostA to hostB with a TTL2 that should have an ICMP "TTL exceeded in traffic" returned by RouterB have no effect. Of course, TTL3 packets are being returned by hostB through RouterB and back through the tunnel. Any plans from tcp/ip stack developers regarding this behavior ? -- Regards, Andrei Manescu Links: ------ [1] http://groups.google.com/group/mailing.freebsd.net/browse_thread/thread/1e121c81e44c88b4/9927ce8abc6d7de9 From owner-freebsd-net@FreeBSD.ORG Tue Mar 22 03:30:59 2011 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 C5839106566C for ; Tue, 22 Mar 2011 03:30:59 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 846558FC08 for ; Tue, 22 Mar 2011 03:30:59 +0000 (UTC) Received: by iwn33 with SMTP id 33so8379024iwn.13 for ; Mon, 21 Mar 2011 20:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:in-reply-to :message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type; bh=/M3gFO+9LXII5fxJCksMYwZDFbkDf9plAd7u4oQ49GY=; b=aGGA3HLScL0JX6FjbzEFx92tstt4uACNOpiHS/ttx8hzcXAcxA5TvqJEom0m6LGoRM 9GjUMOVcDJSmzCM9XxLsOZT/Vc2A+nGFU2paRJJD7sl77AOnBi6ufrFsz0T+zxhLFt0f ERwqKnZ0GZZJqFeubx29Jg4/4sW4yJd07BaRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=Jk4SEjAUAk/lp9vQYhwAdIov+wqo694tb5LGpm6P/y3IpiB4m5DEWOqYOlzmKIloq5 UoojG74QFt/+/cNrs6jvzhuZVroOI0aAyAapV/J+h8jnhHWxDr/Duy9ReATAslb/RnqS 6sElyk4KGsmpxq41H7wSmkYjcVvsAc+W6+b+k= Received: by 10.43.57.80 with SMTP id wf16mr7893377icb.332.1300762811001; Mon, 21 Mar 2011 20:00:11 -0700 (PDT) Received: from disbatch.dataix.local ([99.181.148.152]) by mx.google.com with ESMTPS id u9sm4086377ibe.36.2011.03.21.20.00.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2011 20:00:08 -0700 (PDT) Sender: "J. Hellenthal" Date: Mon, 21 Mar 2011 23:00:00 -0400 From: "J. Hellenthal" To: Matt Smith In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: IPv6 policy based source routing 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, 22 Mar 2011 03:30:59 -0000 On Tue, 15 Mar 2011 10:37, matt.xtaz@ wrote: > On 15 March 2011 11:39, Matt Smith wrote: >> >> Hi, I have a question about source routing I hope you can help me with. > > I have been doing some more research into this and it appears the > proper way to accomplish what I want is to set > net.inet6.ip6.use_deprecated to 0 and then deprecate the IPv6 address > on the gif0 interface by setting the preferred lifetime to zero. This > apparently makes the source address selection algorithm choose the > alternative address on vr0. I can do the first part but I can't figure > out how to do the second part. Any ideas surrounding this? > > The windows command to do this is: "netsh interface ipv6 set address > IP6Tunnel preferredlifetime=0s" so I need a > FreeBSD equivalent of this command. Does such a thing exist? I've had > a quick search through the ifconfig man page etc but nothing jumps out > at me. > Hi Matt, Unofficially not sure if you have already checked into this so I am not sure if it is really a solution to your problem but may be a step forward. Check out the man page for ip6addrctl(8) that allows you to set a precedence for each prefix/route. The default output of ip6addrctl(8) can be dumped into /etc/ip6addrctl.conf where it will also be parsed and restored upon reboot. -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN From owner-freebsd-net@FreeBSD.ORG Tue Mar 22 05:38:26 2011 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 8380C106566C for ; Tue, 22 Mar 2011 05:38:26 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB188FC14 for ; Tue, 22 Mar 2011 05:38:25 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id 607AA1FF00ED for ; Tue, 22 Mar 2011 01:11:34 -0400 (EDT) Thread-Index: AcvoT5ufwaBwAotiQw6RugeYzzPmxA== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.2.53]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Mar 2011 01:11:30 -0400 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Tue, 22 Mar 2011 00:11:29 -0500 Content-Transfer-Encoding: 7bit Date: Tue, 22 Mar 2011 00:11:29 -0500 From: "David DeSimone" Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Importance: normal Priority: normal To: Message-ID: <20110322051128.GM9636@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-reply-to: Precedence: bulk User-Agent: Mutt/1.5.20 (2009-12-10) X-OriginalArrivalTime: 22 Mar 2011 05:11:31.0056 (UTC) FILETIME=[9AFD8F00:01CBE84F] Subject: Re: tcp/ip stack sending icmp "ttl exceeded in traffic" back through gre \w ipsec-esp encryption tunnels. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 05:38:26 -0000 Andrei Manescu - Ivorde wrote: > > Problem: RouterA and RouterB in the following > diagram are FreeBSD 6.4-STABLE and 7.4-STABLE running a gre tunnel and > ipsec transport mode encryption on top of it. > > None of them send an icmp > error "TTL Exceeded in traffic" when the TTL of the packet reaches 0 after > they decrement it. Code: > > hostA----RouterA--GRE-inside-IPSEC/ESP/transport---RouterB---hostB > > Packets > sent from hostA to hostB with a TTL2 that should have an ICMP "TTL > exceeded in traffic" returned by RouterB have no effect. Isn't this by design? An ICMP reply might be sent to an unrelated router hop, meaning there is no security association for it. Since that ICMP reply will contain the the header of the expired packet, sending that reply will take a packet that was encrypted, and send part of it back, unencrypted. This could potentially provide an attacker with some known plaintext with which to attack your VPN's encryption keys. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Tue Mar 22 09:19:58 2011 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 165FA106564A for ; Tue, 22 Mar 2011 09:19:58 +0000 (UTC) (envelope-from matt.xtaz@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id B756B8FC08 for ; Tue, 22 Mar 2011 09:19:57 +0000 (UTC) Received: by qwc9 with SMTP id 9so5382643qwc.13 for ; Tue, 22 Mar 2011 02:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IQpR/SqES+lpO2FMocHTD63QWNR8bDSyH2hSuC+vpdY=; b=wzdABt2kFaeHWqMRcDqF6+yr9mXrSfcg4w4OpizrpuVFpdxvp7563ays0F/CN1FLZJ wjgbozawbufiyu6UisnDReU360F/1rkByQy92SpRDmoBThi3Y2SBAdH7TathkFJ/P4oU 94DELiySqBG8xQfL5lngqdM7CRAwXRcrh4imQ= 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=BindiGiJhc1WsgKqx/EUtsIE7m/thi3Gvwszexbf/7/1oIHsiCx3jW5858DAUKKRgT m7kZUDoPeobUAhbJm+B/ozckhUeIpycr7KI9KH/k97QYczgEhH983BVNVDqn06O1dW0L 7v4MqLCM7pA7RuK+q4h3Lf77akqKd2r5X3nu4= MIME-Version: 1.0 Received: by 10.224.180.208 with SMTP id bv16mr4445709qab.268.1300785595541; Tue, 22 Mar 2011 02:19:55 -0700 (PDT) Received: by 10.229.70.140 with HTTP; Tue, 22 Mar 2011 02:19:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Mar 2011 09:19:55 +0000 Message-ID: From: Matt Smith To: "J. Hellenthal" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: IPv6 policy based source routing 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, 22 Mar 2011 09:19:58 -0000 On 22 March 2011 03:00, J. Hellenthal wrote: > > Hi Matt, > > Unofficially not sure if you have already checked into this so I am not s= ure if it is really a solution to your problem but may be a step forward. C= heck out the man page for ip6addrctl(8) that allows you to set a precedence= for each prefix/route. The default output of ip6addrctl(8) can be dumped i= nto /etc/ip6addrctl.conf where it will also be parsed and restored upon reb= oot. > This does indeed look like exactly what I was after however I can't seem to get it to do anything unless I'm using it wrong. root@tao[~]# ip6addrctl show Prefix Prec Label Use ::1/128 50 0 0 ::/0 40 1 155126 2002::/16 30 2 0 ::/96 20 3 0 ::ffff:0.0.0.0/96 10 4 0 The IP on vr0 is 2a01:348:294::1/64 and the IP on gif0 is 2a01:348:6:45c::2/128. Right now if I ping6 ipv6.google.com I get this PING6(56=3D40+8+8 bytes) 2a01:348:6:45c::2 --> 2a00:1450:8002::67 so it's sourcing traffic from the gif0 IP. I assume in that list the higher the precedence the higher the priority so I ran "ip6addrctl add 2a01:348:294::/64 45 5". This makes no difference. Traffic still comes from the gif0 IP. I also tried adding the gif0 prefix with "ip6addrctl add 2a01:348:6:45c::2/128 44 6" to make it lower but same effect. In case I got the precedence the wrong way round I tried reversing it. Same effect. So I guess I'm not using it correctly. Can you enlighten me as to what I'm doing wrong with it? Matt. From owner-freebsd-net@FreeBSD.ORG Tue Mar 22 13:24:40 2011 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 1C8811065670; Tue, 22 Mar 2011 13:24:40 +0000 (UTC) (envelope-from Albert.Shih@obspm.fr) Received: from spock-ext.obspm.fr (spock-ext.obspm.fr [145.238.186.3]) by mx1.freebsd.org (Postfix) with ESMTP id A77D68FC1C; Tue, 22 Mar 2011 13:24:39 +0000 (UTC) Received: from obspm.fr (pcjas.obspm.fr [145.238.184.233]) by spock-ext.obspm.fr (8.14.3/8.14.3/DIO Observatoire de Paris - 15/04/10) with ESMTP id p2MDEZdb001814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Mar 2011 14:14:37 +0100 Date: Tue, 22 Mar 2011 14:14:35 +0100 From: Albert Shih To: freebsd-jail@freebsd.org Message-ID: <20110322131435.GA5792@obspm.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (spock-ext.obspm.fr [145.238.186.20]); Tue, 22 Mar 2011 14:14:37 +0100 (CET) X-Virus-Scanned: clamav-milter 0.97 at spock-ext.obspm.fr X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: setfib mount 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, 22 Mar 2011 13:24:40 -0000 Hi all Sorry for the cross-posting. I don't known which list is the best. I'm using freebsd-jail since 5.x and yesterday I upgrading (from 7.3 to 7.4). I've see the setfib working now pretty well with the jail. So I using two routing table. One for the host, one for the jails. But I don't known why the NFS mount (on the host off course) didn't use the 0 routing table. So when I try to execute the mount the connection start from the second interface. If I do setfib 0 mount every thing work fine. I don't known if it's a bug. If it's strange(for me) feature how can I tell /etc/fstab to do that ? Regards. -- Albert SHIH DIO batiment 15 Observatoire de Paris Meudon 5 Place Jules Janssen 92195 Meudon Cedex Téléphone : 01 45 07 76 26/06 86 69 95 71 Heure local/Local time: mar 22 mar 2011 14:09:24 CET From owner-freebsd-net@FreeBSD.ORG Tue Mar 22 16:46:29 2011 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 AE3B31065670 for ; Tue, 22 Mar 2011 16:46:29 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2655E8FC0A for ; Tue, 22 Mar 2011 16:46:27 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id p2MGk3De021103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2011 01:46:09 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 23 Mar 2011 01:46:03 +0900 Message-ID: From: Hajimu UMEMOTO To: Matt Smith In-Reply-To: References: User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (i386-portbld-freebsd8.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Wed_Mar_23_01:46:02_2011-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Wed, 23 Mar 2011 01:46:10 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org Subject: Re: IPv6 policy based source routing 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, 22 Mar 2011 16:46:29 -0000 --Multipart_Wed_Mar_23_01:46:02_2011-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Tue, 22 Mar 2011 09:19:55 +0000 >>>>> Matt Smith said: matt> This does indeed look like exactly what I was after however I can't matt> seem to get it to do anything unless I'm using it wrong. matt> root@tao[~]# ip6addrctl show matt> Prefix Prec Label Use matt> ::1/128 50 0 0 matt> ::/0 40 1 155126 matt> 2002::/16 30 2 0 matt> ::/96 20 3 0 matt> ::ffff:0.0.0.0/96 10 4 0 matt> The IP on vr0 is 2a01:348:294::1/64 and the IP on gif0 is matt> 2a01:348:6:45c::2/128. Right now if I ping6 ipv6.google.com I get this matt> PING6(56=40+8+8 bytes) 2a01:348:6:45c::2 --> 2a00:1450:8002::67 so matt> it's sourcing traffic from the gif0 IP. I assume in that list the matt> higher the precedence the higher the priority so I ran "ip6addrctl add matt> 2a01:348:294::/64 45 5". This makes no difference. Traffic still comes matt> from the gif0 IP. matt> I also tried adding the gif0 prefix with "ip6addrctl add matt> 2a01:348:6:45c::2/128 44 6" to make it lower but same effect. In case matt> I got the precedence the wrong way round I tried reversing it. Same matt> effect. matt> So I guess I'm not using it correctly. Can you enlighten me as to what matt> I'm doing wrong with it? Unfortunately, RFC 3484 doesn't work well for your situation because of the existence of Rule 5 which prefers outgoing interface. This rule is annoying for some situation such as BGP peering which requires a global address to an interface. I'm using the attached patches to ignore this rule, intentionally. It breaks RFC 3484, though. Sincerely, --Multipart_Wed_Mar_23_01:46:02_2011-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="no_prefer_iface.diff" Content-Transfer-Encoding: 7bit Index: sys/netinet6/in6_src.c diff -u -p sys/netinet6/in6_src.c.orig sys/netinet6/in6_src.c --- sys/netinet6/in6_src.c.orig 2009-10-25 10:10:29.000000000 +0900 +++ sys/netinet6/in6_src.c 2009-11-10 15:48:38.092822205 +0900 @@ -364,10 +364,12 @@ in6_selectsrc(struct sockaddr_in6 *dstso */ /* Rule 5: Prefer outgoing interface */ - if (ia_best->ia_ifp == ifp && ia->ia_ifp != ifp) - NEXT(5); - if (ia_best->ia_ifp != ifp && ia->ia_ifp == ifp) - REPLACE(5); + if (!(ND_IFINFO(ifp)->flags & ND6_IFF_NO_PREFER_IFACE)) { + if (ia_best->ia_ifp == ifp && ia->ia_ifp != ifp) + NEXT(5); + if (ia_best->ia_ifp != ifp && ia->ia_ifp == ifp) + REPLACE(5); + } /* * Rule 6: Prefer matching label Index: sys/netinet6/nd6.c diff -u -p sys/netinet6/nd6.c.orig sys/netinet6/nd6.c Index: sys/netinet6/nd6.h diff -u sys/netinet6/nd6.h.orig sys/netinet6/nd6.h --- sys/netinet6/nd6.h.orig 2009-10-25 10:10:29.000000000 +0900 +++ sys/netinet6/nd6.h 2009-11-10 15:39:48.733878468 +0900 @@ -84,6 +84,7 @@ * DAD failure. (XXX: not ND-specific) */ #define ND6_IFF_DONT_SET_IFROUTE 0x10 +#define ND6_IFF_NO_PREFER_IFACE 0x80 /* XXX: not related to ND. */ #define ND6_CREATE LLE_CREATE #define ND6_EXCLUSIVE LLE_EXCLUSIVE Index: usr.sbin/ndp/ndp.8 diff -u usr.sbin/ndp/ndp.8.orig usr.sbin/ndp/ndp.8 --- usr.sbin/ndp/ndp.8.orig 2009-10-25 10:10:29.000000000 +0900 +++ usr.sbin/ndp/ndp.8 2009-11-10 16:24:24.739126446 +0900 @@ -196,6 +196,15 @@ selection, see the .Pa IMPLEMENTATION file supplied with the KAME kit. +.It Ic no_prefer_iface +The address on the outgoing interface is preferred by source addess +selection rule. +If this flag is set, stop treating the address on the +.Ar interface +as special even when the +.Ar interface +is outgoing interface. +The default value of this flag is off. .It Ic disabled Disable IPv6 operation on the interface. When disabled, the interface discards any IPv6 packets Index: usr.sbin/ndp/ndp.c diff -u -p usr.sbin/ndp/ndp.c.orig usr.sbin/ndp/ndp.c --- usr.sbin/ndp/ndp.c.orig 2009-10-25 10:10:29.000000000 +0900 +++ usr.sbin/ndp/ndp.c 2009-11-10 15:35:50.217958241 +0900 @@ -1007,6 +1007,9 @@ ifinfo(ifname, argc, argv) #ifdef ND6_IFF_PREFER_SOURCE SETFLAG("prefer_source", ND6_IFF_PREFER_SOURCE); #endif +#ifdef ND6_IFF_NO_PREFER_IFACE + SETFLAG("no_prefer_iface", ND6_IFF_NO_PREFER_IFACE); +#endif SETVALUE("basereachable", ND.basereachable); SETVALUE("retrans", ND.retrans); SETVALUE("curhlim", ND.chlim); @@ -1080,6 +1083,10 @@ ifinfo(ifname, argc, argv) if ((ND.flags & ND6_IFF_PREFER_SOURCE)) printf("prefer_source "); #endif +#ifdef ND6_IFF_NO_PREFER_IFACE + if ((ND.flags & ND6_IFF_NO_PREFER_IFACE)) + printf("no_prefer_iface "); +#endif } putc('\n', stdout); #undef ND --Multipart_Wed_Mar_23_01:46:02_2011-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ifconfig-no_prefer_iface.diff" Content-Transfer-Encoding: 7bit Index: sbin/ifconfig/af_inet6.c diff -u -p sbin/ifconfig/af_inet6.c.orig sbin/ifconfig/af_inet6.c --- sbin/ifconfig/af_inet6.c.orig 2009-12-13 21:12:12.409876457 +0900 +++ sbin/ifconfig/af_inet6.c 2009-12-13 21:12:20.039603812 +0900 @@ -506,6 +506,8 @@ static struct cmd inet6_cmds[] = { DEF_CMD("-nud", -ND6_IFF_PERFORMNUD, setnd6flags), DEF_CMD("prefer_source",ND6_IFF_PREFER_SOURCE, setnd6flags), DEF_CMD("-prefer_source",-ND6_IFF_PREFER_SOURCE,setnd6flags), + DEF_CMD("no_prefer_iface",ND6_IFF_NO_PREFER_IFACE,setnd6flags), + DEF_CMD("-no_prefer_iface",-ND6_IFF_NO_PREFER_IFACE,setnd6flags), DEF_CMD_ARG("pltime", setip6pltime), DEF_CMD_ARG("vltime", setip6vltime), DEF_CMD("eui64", 0, setip6eui64), Index: sbin/ifconfig/af_nd6.c diff -u -p sbin/ifconfig/af_nd6.c.orig sbin/ifconfig/af_nd6.c --- sbin/ifconfig/af_nd6.c.orig 2009-12-06 18:16:27.248083649 +0900 +++ sbin/ifconfig/af_nd6.c 2009-12-06 18:16:27.417250681 +0900 @@ -58,7 +58,7 @@ static const char rcsid[] = #define MAX_SYSCTL_TRY 5 #define ND6BITS "\020\001PERFORMNUD\002ACCEPT_RTADV\003PREFER_SOURCE" \ "\004IFDISABLED\005DONT_SET_IFROUTE\006AUTO_LINKLOCAL" \ - "\020DEFAULTIF" + "\010NO_PREFER_IFACE\020DEFAULTIF" static int isnd6defif(int); void setnd6flags(const char *, int, int, const struct afswtch *); Index: sbin/ifconfig/ifconfig.8 diff -u sbin/ifconfig/ifconfig.8.orig sbin/ifconfig/ifconfig.8 --- sbin/ifconfig/ifconfig.8.orig 2009-12-06 18:16:27.252090244 +0900 +++ sbin/ifconfig/ifconfig.8 2009-12-06 18:16:27.436270414 +0900 @@ -644,6 +644,13 @@ .It Cm -prefer_source Clear a flag .Cm prefer_source . +.It Cm no_prefer_iface +Set a flag to not prefer address on the interface as candidates of the +source address for outgoing packets, even when the interface is +outgoing interface. +.It Cm -no_prefer_iface +Clear a flag +.Cm no_prefer_iface . .El .Pp The following parameters are specific to cloning --Multipart_Wed_Mar_23_01:46:02_2011-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Wed_Mar_23_01:46:02_2011-1-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 22 17:17:02 2011 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 96A40106564A for ; Tue, 22 Mar 2011 17:17:02 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id DBFE08FC08 for ; Tue, 22 Mar 2011 17:17:01 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id p2MHGrNN030675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2011 02:16:54 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 23 Mar 2011 02:16:53 +0900 Message-ID: From: Hajimu UMEMOTO To: Matt Smith In-Reply-To: References: User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.2 (i386-portbld-freebsd8.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Wed, 23 Mar 2011 02:16:54 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org Subject: Re: IPv6 policy based source routing 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, 22 Mar 2011 17:17:02 -0000 Hi, >>>>> On Tue, 15 Mar 2011 14:37:20 +0000 >>>>> Matt Smith said: matt> I have been doing some more research into this and it appears the matt> proper way to accomplish what I want is to set matt> net.inet6.ip6.use_deprecated to 0 and then deprecate the IPv6 address matt> on the gif0 interface by setting the preferred lifetime to zero. This matt> apparently makes the source address selection algorithm choose the matt> alternative address on vr0. I can do the first part but I can't figure matt> out how to do the second part. Any ideas surrounding this? matt> The windows command to do this is: "netsh interface ipv6 set address matt> IP6Tunnel preferredlifetime=0s" so I need a matt> FreeBSD equivalent of this command. Does such a thing exist? I've had matt> a quick search through the ifconfig man page etc but nothing jumps out matt> at me. It's Rule 3 of RFC 3484 which avoids deprecated addresses. If this solves your problem, you can do it by the following command: ifconfig gif0 inet6 deprecated Please note that you don't need to set net.inet6.ip6.use_deprecated to 0 for this purpose. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Mar 22 17:25:23 2011 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 482A7106564A for ; Tue, 22 Mar 2011 17:25:23 +0000 (UTC) (envelope-from matt.xtaz@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0149D8FC08 for ; Tue, 22 Mar 2011 17:25:22 +0000 (UTC) Received: by vxc34 with SMTP id 34so6564839vxc.13 for ; Tue, 22 Mar 2011 10:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KbPX5lUGtAtjkSIarNabFkhdYRYO3fc9b5Ehft0QiXg=; b=PUU5+wmyhpVQaVkBq8EIStriA+LwlH8YCNnE/IVoibwK6KLyVhWC2XS3xWqoJbdx7H 5LBMf9ace/vMYCs/RZRM+72yL9UXAW2dzL8WeZgdqLvVyH/WLs8DF2dkvnKvM6piRyhv yq2rupGiHfm2W5gbCxPx0nKdunNQLuFKury4Q= 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=BxG933SkP5S9qYVsBzSXtUups2eahfuIWOpBVaGtds/F46fWVHxIJUGa4oFnYtGuzq yN6dGGWT2OzWFbClGhRnx8DSF9aO4R9FqS/veJewgb3n83s/NtwcZzjEfKStH7ms3OtF B9V2UD78N30+O+3og7akActC0DrdqSIxsDvWQ= MIME-Version: 1.0 Received: by 10.52.177.233 with SMTP id ct9mr4413879vdc.110.1300814722059; Tue, 22 Mar 2011 10:25:22 -0700 (PDT) Received: by 10.220.81.71 with HTTP; Tue, 22 Mar 2011 10:25:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Mar 2011 17:25:21 +0000 Message-ID: From: Matt Smith To: Hajimu UMEMOTO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: IPv6 policy based source routing 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, 22 Mar 2011 17:25:23 -0000 On 22 March 2011 17:16, Hajimu UMEMOTO wrote: > It's Rule 3 of RFC 3484 which avoids deprecated addresses. > If this solves your problem, you can do it by the following command: > > =A0 =A0 =A0 =A0ifconfig gif0 inet6 deprecated > > Please note that you don't need to set net.inet6.ip6.use_deprecated to > 0 for this purpose. root@tao[~]# ifconfig gif0 inet6 2a01:348:6:45c::2 deprecated root@tao[~]# ping6 ipv6.google.com PING6(56=3D40+8+8 bytes) 2a01:348:294::1 --> 2a00:1450:8002::93 Perfect! That does exactly what I wanted. Traffic is sourced from the other IP address now. Thank you for this. I was about to try and apply the patch that you posted but this does the trick. Regards, Matt. From owner-freebsd-net@FreeBSD.ORG Tue Mar 22 20:39:26 2011 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 76270106564A for ; Tue, 22 Mar 2011 20:39:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA7A8FC16 for ; Tue, 22 Mar 2011 20:39:26 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p2MKdKmK072102 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Mar 2011 13:39:24 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D890905.9010000@freebsd.org> Date: Tue, 22 Mar 2011 13:39:33 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Albert Shih References: <20110322131435.GA5792@obspm.fr> In-Reply-To: <20110322131435.GA5792@obspm.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-jail@freebsd.org Subject: Re: setfib mount 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, 22 Mar 2011 20:39:26 -0000 On 3/22/11 6:14 AM, Albert Shih wrote: > Hi all > > Sorry for the cross-posting. I don't known which list is the best. > > I'm using freebsd-jail since 5.x and yesterday I upgrading (from 7.3 to > 7.4). > > I've see the setfib working now pretty well with the jail. So I using two > routing table. One for the host, one for the jails. > > But I don't known why the NFS mount (on the host of course) didn't use the > 0 routing table. So when I try to execute the mount the connection start > from the second interface. If I do > > setfib 0 mount > > every thing work fine. > > I don't known if it's a bug. If it's strange(for me) feature how can I tell > /etc/fstab to do that ? does your jail mount anything? > Regards. From owner-freebsd-net@FreeBSD.ORG Wed Mar 23 01:02:12 2011 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 12486106567E; Wed, 23 Mar 2011 01:02:12 +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 DDF958FC12; Wed, 23 Mar 2011 01:02:11 +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 p2N12BGW010310; Wed, 23 Mar 2011 01:02:11 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2N12BNA010306; Wed, 23 Mar 2011 01:02:11 GMT (envelope-from linimon) Date: Wed, 23 Mar 2011 01:02:11 GMT Message-Id: <201103230102.p2N12BNA010306@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155772: ifconfig(8): ioctl (SIOCAIFADDR): File exists on directly connected networks 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, 23 Mar 2011 01:02:12 -0000 Old Synopsis: ifconfig: ioctl (SIOCAIFADDR): File exists on directly connected networks New Synopsis: ifconfig(8): ioctl (SIOCAIFADDR): File exists on directly connected networks Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 23 01:01:17 UTC 2011 Responsible-Changed-Why: Not sure how to classify this one, but give it a shot anyways. http://www.freebsd.org/cgi/query-pr.cgi?pr=155772 From owner-freebsd-net@FreeBSD.ORG Wed Mar 23 10:05:07 2011 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 D6B7D1065675; Wed, 23 Mar 2011 10:05:07 +0000 (UTC) (envelope-from Albert.Shih@obspm.fr) Received: from spock-ext.obspm.fr (spock-ext.obspm.fr [145.238.186.3]) by mx1.freebsd.org (Postfix) with ESMTP id 64ABB8FC15; Wed, 23 Mar 2011 10:05:07 +0000 (UTC) Received: from obspm.fr (pcjas.obspm.fr [145.238.184.233]) by spock-ext.obspm.fr (8.14.3/8.14.3/DIO Observatoire de Paris - 15/04/10) with ESMTP id p2NA543O018560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Mar 2011 11:05:06 +0100 Date: Wed, 23 Mar 2011 11:05:04 +0100 From: Albert Shih To: Julian Elischer Message-ID: <20110323100504.GA8779@obspm.fr> References: <20110322131435.GA5792@obspm.fr> <4D890905.9010000@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4D890905.9010000@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.4 (spock-ext.obspm.fr [145.238.186.20]); Wed, 23 Mar 2011 11:05:06 +0100 (CET) X-Virus-Scanned: clamav-milter 0.97 at spock-ext.obspm.fr X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, freebsd-jail@freebsd.org Subject: Re: setfib mount 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, 23 Mar 2011 10:05:08 -0000 Le 22/03/2011 à 13:39:33-0700, Julian Elischer a écrit > On 3/22/11 6:14 AM, Albert Shih wrote: > > Hi all > > > > Sorry for the cross-posting. I don't known which list is the best. > > > > I'm using freebsd-jail since 5.x and yesterday I upgrading (from 7.3 to > > 7.4). > > > > I've see the setfib working now pretty well with the jail. So I using two > > routing table. One for the host, one for the jails. > > > > But I don't known why the NFS mount (on the host of course) didn't use the > > 0 routing table. So when I try to execute the mount the connection start > > from the second interface. If I do > > > > setfib 0 mount > > > > every thing work fine. > > > > I don't known if it's a bug. If it's strange(for me) feature how can I tell > > /etc/fstab to do that ? > > does your jail mount anything? > No. The mount is on the host. Regards. JAS -- Albert SHIH DIO batiment 15 Observatoire de Paris Meudon 5 Place Jules Janssen 92195 Meudon Cedex Téléphone : 01 45 07 76 26/06 86 69 95 71 Heure local/Local time: mer 23 mar 2011 11:00:34 CET From owner-freebsd-net@FreeBSD.ORG Wed Mar 23 12:17:07 2011 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 D3709106564A for ; Wed, 23 Mar 2011 12:17:07 +0000 (UTC) (envelope-from petersson@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 648A68FC15 for ; Wed, 23 Mar 2011 12:17:07 +0000 (UTC) Received: by fxm11 with SMTP id 11so8780419fxm.13 for ; Wed, 23 Mar 2011 05:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=2iLrnOF5WlU6PvzMrZaWC1eNTLwcY4TJK299KoQVLNo=; b=yB7xvH6VqRl38URrD25jdupZCbg9zw66nJA0wj5ArojCr402Tj8dl5zs8cWCtL2CMn dmi9ljcpuZnUn8ib+umvyi6Ksv0uhArQufB5ntjA5kB7leE/Tf6ZCpAvsbjtWmj5m371 Pnrf+6RCBY6M94W1XIgsfz7IQaoKeAe1jbrKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=QuT01QOEWEh6gD0izrkPGb/SartMNBcOPjRXgwpeZWpr7Qd28bcNIC01QjWby1mww7 lmiI7Qmg0ghi2JlKS5o1j/T5hDe5m6vTOxGclTsunpQ6aE5WGbPyFlE7o5yW9DX3POde 4niSDXLzvTiRJoENfAHAL2Npvz/owxc11DBO0= Received: by 10.223.6.11 with SMTP id 11mr7918030fax.100.1300882625543; Wed, 23 Mar 2011 05:17:05 -0700 (PDT) Received: from [10.0.0.20] ([62.182.216.5]) by mx.google.com with ESMTPS id j11sm3411536faa.44.2011.03.23.05.17.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2011 05:17:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Viktor Petersson In-Reply-To: <20110320185856.GA7703@insomnia.benzedrine.cx> Date: Wed, 23 Mar 2011 13:17:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00612801-A0F4-4EDC-9BED-3364A86E4F9C@gmail.com> <20110320185856.GA7703@insomnia.benzedrine.cx> To: Daniel Hartmeier X-Mailer: Apple Mail (2.1082) Cc: freebsd-net@freebsd.org Subject: Re: Possible CARP 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: Wed, 23 Mar 2011 12:17:08 -0000 On Mar 20, 2011, at 7:58 PM, Daniel Hartmeier wrote: > On Fri, Mar 18, 2011 at 04:43:59PM +0100, Viktor Petersson wrote: >=20 >> Mar 7 14:42:57 nas0 kernel: carp0: MASTER -> BACKUP (more = frequent advertisement received) >=20 > This could mean that the master is receiving its own CARP = advertisements > back, and, thinking they come from another host, backs off. >=20 > CARP advertisements are sent through the physical interface to a > broadcast MAC address (01:00:5e:00:x:y) and the broadcast IP address > 224.0.0.18. >=20 > A real physical switch will forward that frame to all ports except the > one it was received on, i.e. the frame will not be sent back to the > sender. >=20 > You mention a virtual enviroment, so maybe the switch is virtual, too, > and behaves differently. You can check by tcpdump'ing on the physical > interface of the master. You should see each advertisement once (going > out, but tcpdump doesn't indicate the direction). Look at the IP IDs, = if > you see each ID twice, you're getting the broadcasts back. >=20 > I think newer versions of CARP (in OpenBSD) contain an explicit check = to > detect this case (it can be thought of as a form of replay attack), > which could be ported. >=20 > But there might also be a setting in Qemu's virtual switch, that deals > with such broadcasts. >=20 > HTH, > Daniel Thank you for the analysis Daniel. You're dead on. The node did indeed = receive its own broadcast package back.=20 Unfortunately that didn't really resolve the problem.=20 Matthew Grooms did however reach out to me with a patch that did resolve = the problem that he wrote for VMware ESX, which apparently is having the same issue.=20 The patch, along with instructions can be found here: http://www.mail-archive.com/freebsd-net@freebsd.org/msg30562.html It would be great if someone could merge that fix into the main branch.=20= Thanks for all the help guys!. Regards, Viktor= From owner-freebsd-net@FreeBSD.ORG Thu Mar 24 06:29:02 2011 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 5974D106567E; Thu, 24 Mar 2011 06:29:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2D72D8FC1F; Thu, 24 Mar 2011 06:29:01 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p2O6SwGJ082080 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 23 Mar 2011 23:29:00 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4D8AE4BC.4080900@freebsd.org> Date: Wed, 23 Mar 2011 23:29:16 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Albert Shih References: <20110322131435.GA5792@obspm.fr> <4D890905.9010000@freebsd.org> <20110323100504.GA8779@obspm.fr> In-Reply-To: <20110323100504.GA8779@obspm.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-jail@freebsd.org Subject: Re: setfib mount 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, 24 Mar 2011 06:29:02 -0000 On 3/23/11 3:05 AM, Albert Shih wrote: > Le 22/03/2011 à 13:39:33-0700, Julian Elischer a écrit >> On 3/22/11 6:14 AM, Albert Shih wrote: >>> Hi all >>> >>> Sorry for the cross-posting. I don't known which list is the best. >>> >>> I'm using freebsd-jail since 5.x and yesterday I upgrading (from 7.3 to >>> 7.4). >>> >>> I've see the setfib working now pretty well with the jail. So I using two >>> routing table. One for the host, one for the jails. >>> >>> But I don't known why the NFS mount (on the host of course) didn't use the >>> 0 routing table. So when I try to execute the mount the connection start >>> from the second interface. If I do >>> >>> setfib 0 mount >>> >>> every thing work fine. >>> ssh vps1 >> does your jail mount anything? >> > No. > > The mount is on the host. so then I too am not sure why the mount itself would use the second FIB. is it possible that some of the mounting is being done automatically by rc scripts using /etc/fstab in the jail? > Regards. > > JAS From owner-freebsd-net@FreeBSD.ORG Thu Mar 24 09:02:04 2011 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 F145F106566B for ; Thu, 24 Mar 2011 09:02:04 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id A54AE8FC16 for ; Thu, 24 Mar 2011 09:02:04 +0000 (UTC) Received: by qwc9 with SMTP id 9so7231005qwc.13 for ; Thu, 24 Mar 2011 02:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=/IjFbM2dJj9onfw74aUdzFc9NIjdYUi3i0DdZYFITMc=; b=b47+9XOtlU7HPwn0IV2a34+E+6tQHjRY4zVaOcF3qaBjnfQSaO/IBs3VyK02hXgpyd TK9PN1CToVXank8TaJv5O1zt5LzbXxu0UP0ig9yPQOw1ZlFdlQiQLUCiuoo+obbjn/3V lUsdAEe0qYmRtocCVxwRrWPBXQYUQi4HQg9CI= 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 :content-type:content-transfer-encoding; b=EdLZYA02INJTN5HBWzOoYBegdBjgTkdmQlIm0M6w1Nu2GO5s4PMOm2Y8lamQ0J0Nhm Ww9AIFA88BsPVgc3D33w3L16Pdm0mYHefbVUrhcUXc+h7bNc/WzNogTrDK34RRxVp8Vn xXY0IfgfeyXDQJMGpZYNNpZuvnUahLHi66TrQ= MIME-Version: 1.0 Received: by 10.229.45.147 with SMTP id e19mr6835578qcf.75.1300957323964; Thu, 24 Mar 2011 02:02:03 -0700 (PDT) Received: by 10.229.232.146 with HTTP; Thu, 24 Mar 2011 02:02:03 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Mar 2011 12:02:03 +0300 Message-ID: From: Sergey Kandaurov To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: panic in dummynet 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, 24 Mar 2011 09:02:05 -0000 On 21 March 2011 12:43, Sergey Kandaurov wrote: > Hi. > > This is a 8.1 box, not very much loaded. > It has two simple dummynet rules. > That's the first time it panics there. Any hints? > > db> x/s *panicstr > 0: =A0 =A0 =A0*** error reading from address 0 *** > db> bt > Tracing pid 0 tid 100116 td 0xffffff000ab057c0 > m_copym() at m_copym+0x37 > ip_fragment() at ip_fragment+0x132 > ip_output() at ip_output+0xeef > dummynet_send() at dummynet_send+0x14c > dummynet_task() at dummynet_task+0x1b7 > taskqueue_run() at taskqueue_run+0x93 > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff8399222d30, rbp =3D 0 --- > Hmm.. Another crash today. Looks like it might be due to race with bce intr handler. Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x18 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80611587 stack pointer =3D 0x28:0xffffff82b41da960 frame pointer =3D 0x28:0xffffff82b41da9c0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 0 (dummynet) db> bt Tracing pid 0 tid 100121 td 0xffffff00094177c0 m_copym() at m_copym+0x37 ip_fragment() at ip_fragment+0x132 ip_output() at ip_output+0xeef dummynet_send() at dummynet_send+0x14c dummynet_task() at dummynet_task+0x1b7 taskqueue_run() at taskqueue_run+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x46 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff82b41dad30, rbp =3D 0 --- cpuid =3D 0 curthread =3D 0xffffff00094177c0: pid 0 "dummynet" cpuid =3D 1 curthread =3D 0xffffff00029a23e0: pid 12 "irq257: bce1" cpuid =3D 2 curthread =3D 0xffffff00026fc3e0: pid 12 "swi4: clock" 100039 Run CPU 1 [irq257: bce1] 100038 RunQ [irq256: bce0] 100012 Run CPU 2 [swi4: clock] db> bt 100039 Tracing pid 12 tid 100039 td 0xffffff00029a23e0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x175 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip =3D 0xffffffff805c62e4, rsp =3D 0xffffff8000052fe0, rbp = =3D 0xfffff f82b155d7b0 --- callout_lock() at callout_lock+0x54 callout_reset_on() at callout_reset_on+0x43 tcp_do_segment() at tcp_do_segment+0x508 tcp_input() at tcp_input+0xd22 ip_input() at ip_input+0xad netisr_dispatch_src() at netisr_dispatch_src+0x7e ether_demux() at ether_demux+0x14d ether_input() at ether_input+0x17b ether_demux() at ether_demux+0x6f ether_input() at ether_input+0x17b bce_intr() at bce_intr+0x3b0 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff82b155dd30, rbp =3D 0 --- db> bt 100038 Tracing pid 12 tid 100038 td 0xffffff00029a27c0 sched_switch() at sched_switch+0xea mi_switch() at mi_switch+0x16f ithread_loop() at ithread_loop+0x1d0 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff82b1554d30, rbp =3D 0 --- db> bt 100012 Tracing pid 12 tid 100012 td 0xffffff00026fc3e0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x175 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip =3D 0xffffffff808a8270, rsp =3D 0xffffff8000059fe0, rbp =3D 0xffffff80000c9bd0 --- Xinvlpg() at Xinvlpg ithread_loop() at ithread_loop+0x142 fork_exit() at fork_exit+0x118 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff80000c9d30, rbp =3D 0 --- --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Thu Mar 24 09:31:14 2011 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 5B96E106564A for ; Thu, 24 Mar 2011 09:31:14 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E34798FC14 for ; Thu, 24 Mar 2011 09:31:13 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 8DBB073098; Thu, 24 Mar 2011 10:45:30 +0100 (CET) Date: Thu, 24 Mar 2011 10:45:30 +0100 From: Luigi Rizzo To: Sergey Kandaurov Message-ID: <20110324094530.GA93955@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net Subject: Re: panic in dummynet 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, 24 Mar 2011 09:31:14 -0000 On Thu, Mar 24, 2011 at 12:02:03PM +0300, Sergey Kandaurov wrote: > On 21 March 2011 12:43, Sergey Kandaurov wrote: > > Hi. > > > > This is a 8.1 box, not very much loaded. > > It has two simple dummynet rules. > > That's the first time it panics there. Any hints? > > > > db> x/s *panicstr > > 0: ? ? ?*** error reading from address 0 *** > > db> bt > > Tracing pid 0 tid 100116 td 0xffffff000ab057c0 > > m_copym() at m_copym+0x37 > > ip_fragment() at ip_fragment+0x132 > > ip_output() at ip_output+0xeef > > dummynet_send() at dummynet_send+0x14c > > dummynet_task() at dummynet_task+0x1b7 > > taskqueue_run() at taskqueue_run+0x93 > > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > > fork_exit() at fork_exit+0x118 > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xffffff8399222d30, rbp = 0 --- > > > > Hmm.. Another crash today. > Looks like it might be due to race with bce intr handler. it is possible, but i wonder if this is a device-specific issue. Otherwise this kind of race would be present in every machine using dummynet -- all packets delayed by dummynet are sent out from the taskqueue using the above path. cheers luigi > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80611587 > stack pointer = 0x28:0xffffff82b41da960 > frame pointer = 0x28:0xffffff82b41da9c0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (dummynet) > > db> bt > Tracing pid 0 tid 100121 td 0xffffff00094177c0 > m_copym() at m_copym+0x37 > ip_fragment() at ip_fragment+0x132 > ip_output() at ip_output+0xeef > dummynet_send() at dummynet_send+0x14c > dummynet_task() at dummynet_task+0x1b7 > taskqueue_run() at taskqueue_run+0x93 > taskqueue_thread_loop() at taskqueue_thread_loop+0x46 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff82b41dad30, rbp = 0 --- > > cpuid = 0 > curthread = 0xffffff00094177c0: pid 0 "dummynet" > cpuid = 1 > curthread = 0xffffff00029a23e0: pid 12 "irq257: bce1" > cpuid = 2 > curthread = 0xffffff00026fc3e0: pid 12 "swi4: clock" > > 100039 Run CPU 1 [irq257: bce1] > 100038 RunQ [irq256: bce0] > 100012 Run CPU 2 [swi4: clock] > > db> bt 100039 > Tracing pid 12 tid 100039 td 0xffffff00029a23e0 > cpustop_handler() at cpustop_handler+0x40 > ipi_nmi_handler() at ipi_nmi_handler+0x30 > trap() at trap+0x175 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip = 0xffffffff805c62e4, rsp = 0xffffff8000052fe0, rbp = 0xfffff > f82b155d7b0 --- > callout_lock() at callout_lock+0x54 > callout_reset_on() at callout_reset_on+0x43 > tcp_do_segment() at tcp_do_segment+0x508 > tcp_input() at tcp_input+0xd22 > ip_input() at ip_input+0xad > netisr_dispatch_src() at netisr_dispatch_src+0x7e > ether_demux() at ether_demux+0x14d > ether_input() at ether_input+0x17b > ether_demux() at ether_demux+0x6f > ether_input() at ether_input+0x17b > bce_intr() at bce_intr+0x3b0 > intr_event_execute_handlers() at intr_event_execute_handlers+0xfd > ithread_loop() at ithread_loop+0x8e > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff82b155dd30, rbp = 0 --- > > db> bt 100038 > Tracing pid 12 tid 100038 td 0xffffff00029a27c0 > sched_switch() at sched_switch+0xea > mi_switch() at mi_switch+0x16f > ithread_loop() at ithread_loop+0x1d0 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff82b1554d30, rbp = 0 --- > > db> bt 100012 > Tracing pid 12 tid 100012 td 0xffffff00026fc3e0 > cpustop_handler() at cpustop_handler+0x40 > ipi_nmi_handler() at ipi_nmi_handler+0x30 > trap() at trap+0x175 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip = 0xffffffff808a8270, rsp = 0xffffff8000059fe0, rbp > = 0xffffff80000c9bd0 --- > Xinvlpg() at Xinvlpg > ithread_loop() at ithread_loop+0x142 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff80000c9d30, rbp = 0 --- > > > -- > wbr, > pluknet > _______________________________________________ > 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 Thu Mar 24 10:00:05 2011 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 A92C9106566C for ; Thu, 24 Mar 2011 10:00:05 +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 87B9B8FC13 for ; Thu, 24 Mar 2011 10:00: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 p2OA05Aw069212 for ; Thu, 24 Mar 2011 10:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2OA05It069204; Thu, 24 Mar 2011 10:00:05 GMT (envelope-from gnats) Date: Thu, 24 Mar 2011 10:00:05 GMT Message-Id: <201103241000.p2OA05It069204@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Vladimir Kutakov Cc: Subject: Re: kern/155597: [panic] Kernel panics with "sbdrop" message X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vladimir Kutakov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 10:00:05 -0000 The following reply was made to PR kern/155597; it has been noted by GNATS. From: Vladimir Kutakov To: bug-followup@FreeBSD.org, vova@ashmanov.com Cc: Subject: Re: kern/155597: [panic] Kernel panics with "sbdrop" message Date: Thu, 24 Mar 2011 12:35:34 +0300 We are looking into this problem a bit. The panic is reproducible easily by means of big http trafic. We ran apache benchmark on 3 next servers: ab -c40 -n20000000 'http://thehost/somesmallfile'. After just some minutes panic occurs. However, after decreasing hw.igb.num_queues to 4 (default value is 8), it occurs only after 2 hours. Finally, the server with hw.igb.num_queues=1 works good already 7 days. It seems that some problem happens during parallel tcp processing. -- WBR, Vladimir mailto:vova@ashmanov.com From owner-freebsd-net@FreeBSD.ORG Thu Mar 24 18:07:56 2011 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 53C571065672 for ; Thu, 24 Mar 2011 18:07:56 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 1F70F8FC0C for ; Thu, 24 Mar 2011 18:07:55 +0000 (UTC) Received: from pool-141-154-217-103.bos.east.verizon.net ([141.154.217.103] helo=homobox.opal.com) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Q2owt-000Bnb-7x for freebsd-net@freebsd.org; Thu, 24 Mar 2011 18:07:55 +0000 Received: from opal.com (localhost [IPv6:::1]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id p2OI7qgb051365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Mar 2011 14:07:53 -0400 (EDT) (envelope-from fbsd@opal.com) Received: from shibato.opal.com ([2001:470:8cb8:3:221:63ff:fe5a:c9a7] helo=shibato.opal.com) with IPv6:587 by opal.com; 24 Mar 2011 14:07:52 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 141.154.217.103 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18L7OoTH4oHP3fnEGkBYMZ1 Date: Thu, 24 Mar 2011 14:07:52 -0400 From: "J.R. Oldroyd" To: freebsd-net@freebsd.org Message-ID: <20110324140752.071ed024@shibato.opal.com> In-Reply-To: <20110317134514.5f9d52de@shibato.opal.com> References: <20110317134514.5f9d52de@shibato.opal.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: CFT: IPv6 DNS autoconfiguration (RFC6106 RDNSS and DNSSL) 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, 24 Mar 2011 18:07:56 -0000 On Thu, 17 Mar 2011 13:45:14 -0400, "J.R. Oldroyd" wrote: > > I have implemented IPv6 DNS autoconfiguration using the method > described in RFC6106 which describes RDNSS and DNSSL options on > ICMPv6 router advertisements. > I see this has been downloaded a bunch of times in the last week. Any discussion? Suggestions for improvement? If not, I will file a PR to have this committed. -jr From owner-freebsd-net@FreeBSD.ORG Thu Mar 24 19:25:47 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 75DBD106564A for ; Thu, 24 Mar 2011 19:25:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 707A014D935 for ; Thu, 24 Mar 2011 19:21:25 +0000 (UTC) Message-ID: <4D8B99B4.4070404@FreeBSD.org> Date: Thu, 24 Mar 2011 12:21:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: The tale of a TCP 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: Thu, 24 Mar 2011 19:25:47 -0000 http://blogmal.42.org/tidbits/tcp-bug.story $someone really needs to take a look at this. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Thu Mar 24 19:25:48 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1351A1065673 for ; Thu, 24 Mar 2011 19:25:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D40B614DB41 for ; Thu, 24 Mar 2011 19:25:47 +0000 (UTC) Message-ID: <4D8B9ABB.50004@FreeBSD.org> Date: Thu, 24 Mar 2011 12:25:47 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110319 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: The tale of a TCP 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: Thu, 24 Mar 2011 19:25:48 -0000 http://blogmal.42.org/tidbits/tcp-bug.story $someone really needs to take a look at this. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Thu Mar 24 19:51:15 2011 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 DF363106564A; Thu, 24 Mar 2011 19:51:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B626B8FC15; Thu, 24 Mar 2011 19:51:15 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4FF9F46B03; Thu, 24 Mar 2011 15:51:15 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DFD3C8A027; Thu, 24 Mar 2011 15:51:14 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Thu, 24 Mar 2011 15:51:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110311; KDE/4.5.5; amd64; ; ) References: <4D8B99B4.4070404@FreeBSD.org> In-Reply-To: <4D8B99B4.4070404@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103241551.14405.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 24 Mar 2011 15:51:15 -0400 (EDT) Cc: Doug Barton Subject: Re: The tale of a TCP 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: Thu, 24 Mar 2011 19:51:16 -0000 On Thursday, March 24, 2011 3:21:24 pm Doug Barton wrote: > http://blogmal.42.org/tidbits/tcp-bug.story > > $someone really needs to take a look at this. :) This is the same bug I reported back in February in this e-mail: http://lists.freebsd.org/pipermail/freebsd-net/2011-February/027892.html His patch may be the more correct fix though. I have two other TCP bugs also awaiting review that I posted on the same day. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Mar 24 20:15:59 2011 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 3B59A106564A; Thu, 24 Mar 2011 20:15:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 12C538FC16; Thu, 24 Mar 2011 20:15:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BA82346B52; Thu, 24 Mar 2011 16:15:58 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 52CDE8A01B; Thu, 24 Mar 2011 16:15:58 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Thu, 24 Mar 2011 16:15:57 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110311; KDE/4.5.5; amd64; ; ) References: <4D8B99B4.4070404@FreeBSD.org> <201103241551.14405.jhb@freebsd.org> In-Reply-To: <201103241551.14405.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103241615.57852.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 24 Mar 2011 16:15:58 -0400 (EDT) Cc: sec@42.org, Doug Barton Subject: Re: The tale of a TCP 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: Thu, 24 Mar 2011 20:15:59 -0000 On Thursday, March 24, 2011 3:51:14 pm John Baldwin wrote: > On Thursday, March 24, 2011 3:21:24 pm Doug Barton wrote: > > http://blogmal.42.org/tidbits/tcp-bug.story > > > > $someone really needs to take a look at this. :) > > This is the same bug I reported back in February in this e-mail: > > http://lists.freebsd.org/pipermail/freebsd-net/2011-February/027892.html > > His patch may be the more correct fix though. I have two other TCP bugs also > awaiting review that I posted on the same day. Actually, I retract that a bit. I saw the problem with window updates for an established connection and his proposed change doesn't cover that. Also, I think the root problem is that tp->rcv_wnd is calculated incorrectly in this case. However, I'd be curious to see if the patch from my original e-mail fixes the issue first. Otherwise, something like this may apply instead: Index: tcp_input.c =================================================================== --- tcp_input.c (revision 219911) +++ tcp_input.c (working copy) @@ -1694,7 +1694,10 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, win = sbspace(&so->so_rcv); if (win < 0) win = 0; - tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); + if (SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt)) + tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); + else + tp->rcv_wnd = win; /* Reset receive buffer auto scaling when not in bulk receive mode. */ tp->rfbuf_ts = 0; I think that will fix tp->rcv_wnd to be correct in this case thus fixing further uses of it. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Mar 24 23:02:36 2011 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 7802A1065691; Thu, 24 Mar 2011 23:02:36 +0000 (UTC) (envelope-from sec@42.org) Received: from ice.42.org (v6.42.org [IPv6:2001:608:9::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2C5448FC18; Thu, 24 Mar 2011 23:02:36 +0000 (UTC) Received: by ice.42.org (Postfix, from userid 1000) id 1FCFC2841D; Fri, 25 Mar 2011 00:02:35 +0100 (CET) Date: Fri, 25 Mar 2011 00:02:35 +0100 From: Stefan `Sec` Zehl To: John Baldwin Message-ID: <20110324230235.GB90901@ice.42.org> X-Current-Backlog: 3848 messages References: <4D8B99B4.4070404@FreeBSD.org> <201103241551.14405.jhb@freebsd.org> <201103241615.57852.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103241615.57852.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i I-love-doing-this: really X-Modeline: vim:set ts=8 sw=4 smarttab tw=72 si noic notitle: Accept-Languages: de, en X-URL: http://sec.42.org/ Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: The tale of a TCP 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: Thu, 24 Mar 2011 23:02:36 -0000 Hi, I just subscribed to this list, so sorry if I missed some previous discussion on this. On Thu, Mar 24, 2011 at 16:15 -0400, John Baldwin wrote: [...] > Otherwise, something like this may apply instead: > > Index: tcp_input.c > =================================================================== > --- tcp_input.c (revision 219911) > +++ tcp_input.c (working copy) > @@ -1694,7 +1694,10 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, > win = sbspace(&so->so_rcv); > if (win < 0) > win = 0; > - tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); > + if (SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt)) > + tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); > + else > + tp->rcv_wnd = win; > > /* Reset receive buffer auto scaling when not in bulk receive mode. */ > tp->rfbuf_ts = 0; > > I think that will fix tp->rcv_wnd to be correct in this case thus fixing > further uses of it. I just quickly tested it on my bug scenario, and it still generates adv=-1 in tcp_output That is because win=65536, which is bigger than the actually advertised window (65535, the max that can be advertised without window scaling). CU, Sec -- To paraphrase RFC1925: Time, talent, willingness: Pick any two. From owner-freebsd-net@FreeBSD.ORG Fri Mar 25 12:25:14 2011 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 3EA9C1065675; Fri, 25 Mar 2011 12:25:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CCC208FC2D; Fri, 25 Mar 2011 12:25:13 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8205846B59; Fri, 25 Mar 2011 08:25:13 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BD9BB8A02A; Fri, 25 Mar 2011 08:25:12 -0400 (EDT) From: John Baldwin To: "Stefan `Sec` Zehl" Date: Fri, 25 Mar 2011 08:25:10 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110311; KDE/4.5.5; amd64; ; ) References: <4D8B99B4.4070404@FreeBSD.org> <201103241615.57852.jhb@freebsd.org> <20110324230235.GB90901@ice.42.org> In-Reply-To: <20110324230235.GB90901@ice.42.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103250825.10674.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 25 Mar 2011 08:25:12 -0400 (EDT) Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: The tale of a TCP 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: Fri, 25 Mar 2011 12:25:14 -0000 On Thursday, March 24, 2011 7:02:35 pm Stefan `Sec` Zehl wrote: > Hi, > > I just subscribed to this list, so sorry if I missed some previous > discussion on this. > > On Thu, Mar 24, 2011 at 16:15 -0400, John Baldwin wrote: > [...] > > Otherwise, something like this may apply instead: > > > > Index: tcp_input.c > > =================================================================== > > --- tcp_input.c (revision 219911) > > +++ tcp_input.c (working copy) > > @@ -1694,7 +1694,10 @@ tcp_do_segment(struct mbuf *m, struct tcphdr *th, > > win = sbspace(&so->so_rcv); > > if (win < 0) > > win = 0; > > - tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); > > + if (SEQ_GEQ(tp->rcv_adv, tp->rcv_nxt)) > > + tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); > > + else > > + tp->rcv_wnd = win; > > > > /* Reset receive buffer auto scaling when not in bulk receive mode. */ > > tp->rfbuf_ts = 0; > > > > I think that will fix tp->rcv_wnd to be correct in this case thus fixing > > further uses of it. > > I just quickly tested it on my bug scenario, and it still generates > adv=-1 in tcp_output > > That is because win=65536, which is bigger than the actually advertised > window (65535, the max that can be advertised without window scaling). Ah, ok. Can you try this patch first (without the other)? If it doesn't work then we can refine the patch above further. Index: tcp_output.c =================================================================== --- tcp_output.c (revision 215582) +++ tcp_output.c (working copy) @@ -928,7 +928,8 @@ if (recwin < (long)(so->so_rcv.sb_hiwat / 4) && recwin < (long)tp->t_maxseg) recwin = 0; - if (recwin < (long)(tp->rcv_adv - tp->rcv_nxt)) + if (SEQ_GT(tp->rcv_adv, tp->rcv_nxt) && + recwin < (long)(tp->rcv_adv - tp->rcv_nxt)) recwin = (long)(tp->rcv_adv - tp->rcv_nxt); if (recwin > (long)TCP_MAXWIN << tp->rcv_scale) recwin = (long)TCP_MAXWIN << tp->rcv_scale; -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Mar 25 19:41:11 2011 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 CCAA9106564A; Fri, 25 Mar 2011 19:41:11 +0000 (UTC) (envelope-from sec@42.org) Received: from ice.42.org (v6.42.org [IPv6:2001:608:9::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7FCD88FC0A; Fri, 25 Mar 2011 19:41:11 +0000 (UTC) Received: by ice.42.org (Postfix, from userid 1000) id AE50B28419; Fri, 25 Mar 2011 20:41:09 +0100 (CET) Date: Fri, 25 Mar 2011 20:41:09 +0100 From: Stefan `Sec` Zehl To: John Baldwin Message-ID: <20110325194109.GB25392@ice.42.org> Mail-Followup-To: John Baldwin , freebsd-net@freebsd.org, Doug Barton References: <4D8B99B4.4070404@FreeBSD.org> <201103241615.57852.jhb@freebsd.org> <20110324230235.GB90901@ice.42.org> <201103250825.10674.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103250825.10674.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i I-love-doing-this: really X-Modeline: vim:set ts=8 sw=4 smarttab tw=72 si noic notitle: Accept-Languages: de, en X-URL: http://sec.42.org/ Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: The tale of a TCP 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: Fri, 25 Mar 2011 19:41:11 -0000 Hi, On Fri, Mar 25, 2011 at 08:25 -0400, John Baldwin wrote: > Ah, ok. Can you try this patch first (without the other)? If it doesn't > work then we can refine the patch above further. I tried it completely unpatched and with your new patch. In both cases that if() statement is not taken. Instrumenting this part of the code with printf()s shows that recwin is 65536 right after your patched if, but reduced to 65535 by the next statment. | if (recwin > (long)TCP_MAXWIN << tp->rcv_scale) | recwin = (long)TCP_MAXWIN << tp->rcv_scale; That's the same effect as in the the affected adv calculation: % long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - % (tp->rcv_adv - tp->rcv_nxt); recwin is 65535, but the min limits it to 65535. CU, Sec -- But anyway, once I did that, it ran fine! Accelerated, full-screen. Then I remembered I don't like Quake :-) From owner-freebsd-net@FreeBSD.ORG Fri Mar 25 20:40:17 2011 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 CA61D106566B; Fri, 25 Mar 2011 20:40:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A1B3F8FC0C; Fri, 25 Mar 2011 20:40:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2F9B046B09; Fri, 25 Mar 2011 16:40:17 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B07288A01B; Fri, 25 Mar 2011 16:40:16 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org, Doug Barton Date: Fri, 25 Mar 2011 16:40:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110311; KDE/4.5.5; amd64; ; ) References: <4D8B99B4.4070404@FreeBSD.org> <201103250825.10674.jhb@freebsd.org> <20110325194109.GB25392@ice.42.org> In-Reply-To: <20110325194109.GB25392@ice.42.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103251640.16147.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 25 Mar 2011 16:40:16 -0400 (EDT) Cc: Subject: Re: The tale of a TCP 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: Fri, 25 Mar 2011 20:40:17 -0000 On Friday, March 25, 2011 3:41:09 pm Stefan `Sec` Zehl wrote: > Hi, > > On Fri, Mar 25, 2011 at 08:25 -0400, John Baldwin wrote: > > Ah, ok. Can you try this patch first (without the other)? If it doesn't > > work then we can refine the patch above further. > > I tried it completely unpatched and with your new patch. In both cases > that if() statement is not taken. > > Instrumenting this part of the code with printf()s shows that recwin is > 65536 right after your patched if, but reduced to 65535 by the next > statment. > > | if (recwin > (long)TCP_MAXWIN << tp->rcv_scale) > | recwin = (long)TCP_MAXWIN << tp->rcv_scale; > > That's the same effect as in the the affected adv calculation: > > % long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - > % (tp->rcv_adv - tp->rcv_nxt); > > recwin is 65535, but the min limits it to 65535. Reading some more. I'm trying to understand the breakage in your case. You are saying that FreeBSD is the sender, who has data to send, yet is not sending any window probes because it never starts the persist timer when the initial window is zero? Is that correct? And the problem is that the code that uses 'adv' to determine if it sound send a window update to the remote end is falsely succeeding due to the overflow causing tcp_output() to 'goto send' but that it then fails to send any data because it thinks the remote window is full? So one thing I don't quite follow is how you are having rcv_nxt > rcv_adv. I saw this when the other side would send a window probe, and then the receiving side would take the -1 remaining window and explode it into the maximum window size when it ACKd. Are you seeing the other end of the connection send a window probe, but FreeBSD is not setting the persist timer so that it will send its own window probes? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Mar 25 21:01:36 2011 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 06D5F106564A; Fri, 25 Mar 2011 21:01:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D26F98FC08; Fri, 25 Mar 2011 21:01:35 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 832FD46B09; Fri, 25 Mar 2011 17:01:35 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 195D38A01B; Fri, 25 Mar 2011 17:01:35 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Fri, 25 Mar 2011 17:01:34 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110311; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201103251701.34576.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 25 Mar 2011 17:01:35 -0400 (EDT) Cc: Jim , Robert Watson Subject: Re: why use INP_WLOCK instead of INP_RLOCK 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, 25 Mar 2011 21:01:36 -0000 On Tuesday, February 01, 2011 12:54:33 am Jim wrote: > Hi All, > > I am not sure if anybody has asked it before. I could not find answer by > doing rough search on Internet, if it is duplicate question, sorry in > advance. > > My question is that, for getting socket options in tcp_ctloutput() in > tcp_usrreq.c, why do we need to do lock with INP_WLOCK(inp) as setting > socket options does. Why do we just use INP_RLOCK(inp), as it looks not > changing anything in tcp control block? > > Thank you for your kindly answer. I think mostly it is just because no one has bothered to change it. Realistically it probably won't make any noticable difference unless your workload consists of doing lots of calls to getsockopt() but not sending any actual traffic on the associated sockets. :) (Almost all of the other operations on a TCP connection require a write lock on the pcb.) -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Mar 25 21:38:13 2011 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 50FF31065670; Fri, 25 Mar 2011 21:38:13 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2C31E8FC14; Fri, 25 Mar 2011 21:38:13 +0000 (UTC) Received: from [192.168.2.112] (host86-147-11-178.range86-147.btcentralplus.com [86.147.11.178]) by cyrus.watson.org (Postfix) with ESMTPSA id 1ABF346B55; Fri, 25 Mar 2011 17:38:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <201103251701.34576.jhb@freebsd.org> Date: Fri, 25 Mar 2011 21:38:10 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <997B5A3A-8AC7-42F5-BE43-64B6CB4E2A25@freebsd.org> References: <201103251701.34576.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1082) Cc: freebsd-net@freebsd.org, Jim Subject: Re: why use INP_WLOCK instead of INP_RLOCK 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, 25 Mar 2011 21:38:13 -0000 On 25 Mar 2011, at 21:01, John Baldwin wrote: > On Tuesday, February 01, 2011 12:54:33 am Jim wrote: >> I am not sure if anybody has asked it before. I could not find answer = by >> doing rough search on Internet, if it is duplicate question, sorry in >> advance. >>=20 >> My question is that, for getting socket options in tcp_ctloutput() in >> tcp_usrreq.c, why do we need to do lock with INP_WLOCK(inp) as = setting >> socket options does. Why do we just use INP_RLOCK(inp), as it looks = not >> changing anything in tcp control block? >=20 > I think mostly it is just because no one has bothered to change it. =20= > Realistically it probably won't make any noticable difference unless = your=20 > workload consists of doing lots of calls to getsockopt() but not = sending any=20 > actual traffic on the associated sockets. :) (Almost all of the other=20= > operations on a TCP connection require a write lock on the pcb.) Just to reiterate John's point here: the critical performance paths for = TCP both require the inpcb lock to be held exclusively (input and = output), and socket options are typically called from the same user = thread doing I/O, meaning that acquiring read locks instead of write = locks is unlikely to make any measurable difference. However, in = principle I believe most if not all getsockopt()'s in TCP should be fine = with just a read lock, and for socket options used with UDP, there might = well be some benefit to using a read lock, since most UDP operations use = read locks and note write locks on the inpcb. I should further note that Jeff Roberson has some exciting in-progress = work to reduce transmit-input contention on the inpcb that appears to = make quite a noticeable difference in improving TCP performance. We = don't have much global lock contention currently when in the steady = state, but the per-connection locks do get heavily contended. His work = is similar to some work done in the Linux stack a year or two ago to = defer input processing to the user thread rather than contending on the = inpcb lock, if it's already held. Hopefully we'll see the results of = that work in 9.0, and possibly backported to 8.x. I also have a large pending patchset adding connection group support, = and aligning software lookup tables with hardware work distribution via = RSS, which is due to go in before 9.0. Robert= From owner-freebsd-net@FreeBSD.ORG Sat Mar 26 01:42:31 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5454106564A for ; Sat, 26 Mar 2011 01:42:31 +0000 (UTC) (envelope-from sean@chittenden.org) Received: from mail01.lax1.stackjet.com (mon01.lax1.stackjet.com [174.136.104.178]) by mx1.freebsd.org (Postfix) with ESMTP id A71078FC17 for ; Sat, 26 Mar 2011 01:42:31 +0000 (UTC) Received: from somehost-30.sv2.equinix.net (unknown [64.191.195.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sean@chittenden.org) by mail01.lax1.stackjet.com (Postfix) with ESMTPSA id 5682B3E88D8 for ; Fri, 25 Mar 2011 18:26:47 -0700 (PDT) From: Sean Chittenden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Mar 2011 18:26:46 -0700 Message-Id: To: net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: Subject: PR kern/155772 (&& maybe kern/155555)... 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, 26 Mar 2011 01:42:31 -0000 [ Please keep me CC'ed ] Hello. It looks like I'm running in to kern/155772. The ticket was = sparse on details so here's how to reproduce the problem: I have two routers using openospfd && bgpd: br1 <-- igb0 -> br2 | | | igb1 | igb1 | | ----+--------------+---- 10.1.1.0/24 br1: ifconfig igb1 inet 10.1.1.2 netmask 255.255.255.0 br2: ifconfig igb1 inet 10.1.1.3 netmask 255.255.255.0 When I restart ospfd on br2 (not reload), *br1* looses its connectivity = to all directly connected routes (both igb0 and igb1). If I perform a = `route -n get 10.1.1.10` on br1, route(8) returns the right information = for igb1, however when I ping 10.1.1.10 from br1, I get a network not = reachable message. `ifconfig igb1` returns the right information as = well. If I re-add the IP address via `ifconfig igb1 inet 10.1.1.2 = netmask 255.255.255.255` I am able to reach the 10.1.1.0/24 network. = It's like the FIB information is being removed for directly connected = routes when ospfd updates br1's FIB. I've actually observed the same = behavior when retracting statically connected routes via openbgpd as = well (while attempting to trace the root of this problem, I configured = an iBGP session to use a "next-hop self" rule and observed an identical = behavior, same with quagga too). I was thinking this was related to kern/155555 but I don't think that's = the direct problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D155555 If anyone has patches or ideas, let me know. I have plenty of details if = anyone's interested, but this seems so easy to reproduce or like a = glaring regression. It feels very much like a refcount for routes isn't = being incremented along the way or that some piece of logic is removing = all matching routes, not just the routes learned from a routing = protocol. On a similar, but unrelated note of carp(4), I ran in to the problem = described in the following post during the initial setup of these two = routers: http://lists.freebsd.org/pipermail/freebsd-net/2011-March/028349.html This happened because br2's default route was pointing to br1, br1 was = receiving its own carp packets while br2 was forwarding them back. = Recompiling with MROUTING and enabling igmpproxy(8) seemed to fix the = problem. Thanks in advance. -sc PS This one also bit me during turn up: = http://www.freebsd.org/cgi/query-pr.cgi?pr=3D155030 PPS And, if you had a downstream hosts that have pf(4) enabled and had = their default route set to 10.1.1.2, once you changed the default route = to 10.1.1.1 or 10.1.1.3, all of the hosts that had pf(4) on them had to = have their firewall rules reloaded (e.g. /etc/rc.d/pf reload) to reflect = this changed default route. In previous 7.X, pf(4) picked up this change = without needing to reload the rules. -- Sean Chittenden sean@chittenden.org From owner-freebsd-net@FreeBSD.ORG Sat Mar 26 14:02:14 2011 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 C642F106568F; Sat, 26 Mar 2011 14:02:14 +0000 (UTC) (envelope-from sec@42.org) Received: from ice.42.org (v6.42.org [IPv6:2001:608:9::1]) by mx1.freebsd.org (Postfix) with ESMTP id 75AFE8FC22; Sat, 26 Mar 2011 14:02:14 +0000 (UTC) Received: by ice.42.org (Postfix, from userid 1000) id 531CF28419; Sat, 26 Mar 2011 15:02:12 +0100 (CET) Date: Sat, 26 Mar 2011 15:02:12 +0100 From: Stefan `Sec` Zehl To: John Baldwin Message-ID: <20110326140212.GB45402@ice.42.org> Mail-Followup-To: John Baldwin , freebsd-net@freebsd.org, Doug Barton References: <4D8B99B4.4070404@FreeBSD.org> <201103250825.10674.jhb@freebsd.org> <20110325194109.GB25392@ice.42.org> <201103251640.16147.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103251640.16147.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i I-love-doing-this: really X-Modeline: vim:set ts=8 sw=4 smarttab tw=72 si noic notitle: Accept-Languages: de, en X-URL: http://sec.42.org/ Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: The tale of a TCP 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: Sat, 26 Mar 2011 14:02:14 -0000 Hi again, On Fri, Mar 25, 2011 at 16:40 -0400, John Baldwin wrote: > Reading some more. I'm trying to understand the breakage in your case. > > You are saying that FreeBSD is the sender, who has data to send, yet is not > sending any window probes because it never starts the persist timer when the > initial window is zero? Is that correct? Yes. The receiver never sends a window update on its own, but when probed will "admit" to a bigger window. > And the problem is that the code that uses 'adv' to determine if it > sound send a window update to the remote end is falsely succeeding due > to the overflow causing tcp_output() to 'goto send' but that it then > fails to send any data because it thinks the remote window is full? Yes, as far as I remember (I did that part of debugging 2 Months ago, when I submitted the PR %-) that's what happens. > So one thing I don't quite follow is how you are having rcv_nxt > > rcv_adv. I saw this when the other side would send a window probe, > and then the receiving side would take the -1 remaining window and > explode it into the maximum window size when it ACKd. No, it's not rcv_nxt > rcv_adv. It's (rcv_adv - rcv_nxt) > min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) My sample case has (rcv_adv - rcv_nxt) = 65536, but (TCP_MAXWIN << tp->rcv_scale) = 65535 (as there is no window scaling in effect) > Are you seeing the other end of the connection send a window probe, but > FreeBSD is not setting the persist timer so that it will send its own window > probes? No, the dump looks like this: | 10.42.0.25.44852 > 10.42.0.2.1516: Flags [S], | seq 3339144437, win 65535, options [...], length 0 FreeBSD sending the first SYN. [rcv_adv=0, rcv_nxt=0] | 10.42.0.2.1516 > 10.42.0.25.44852: Flags [S.], | seq 42, ack 3339144438, win 0, length 0 The other end SYN|ACKing with a window size of 0. | 10.42.0.25.44852 > 10.42.0.2.1516: Flags [.], | seq 1, ack 1, win 65535, length 0 FreeBSD ACKing, and (correctly) sending no data. [rcv_adv=67779, rcv_nxt=43], thus resulting in adv=-1/0xffffffff At this point amd64 hangs 'forever' as the opposite side doesn't send any packets on its own. On i386 the persist timer is started, and we get: | 10.42.0.25.44852 > 10.42.0.2.1516: Flags [.], | seq 1:2, ack 1, win 65535, length 1 A window probe [a few seconds later] | 10.42.0.2.1516 > 10.42.0.25.44852: Flags [.], | seq 1, ack 2, win 70, length 0 At which point the remote side admits to having the window open which results in the connection working fine after that. CU, Sec -- I know that you believe that you understand what you think I said. But I am not sure you realize, that what you heared is not what i meant. From owner-freebsd-net@FreeBSD.ORG Sat Mar 26 22:43:41 2011 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 A49EB106566B for ; Sat, 26 Mar 2011 22:43:41 +0000 (UTC) (envelope-from sec@42.org) Received: from ice.42.org (v6.42.org [IPv6:2001:608:9::1]) by mx1.freebsd.org (Postfix) with ESMTP id 588998FC0A for ; Sat, 26 Mar 2011 22:43:41 +0000 (UTC) Received: by ice.42.org (Postfix, from userid 1000) id 8A0C828419; Sat, 26 Mar 2011 23:43:40 +0100 (CET) Date: Sat, 26 Mar 2011 23:43:40 +0100 From: Stefan `Sec` Zehl To: freebsd-net@freebsd.org Message-ID: <20110326224340.GB23803@ice.42.org> Mail-Followup-To: freebsd-net@freebsd.org References: <4D8B99B4.4070404@FreeBSD.org> <201103250825.10674.jhb@freebsd.org> <20110325194109.GB25392@ice.42.org> <201103251640.16147.jhb@freebsd.org> <20110326140212.GB45402@ice.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110326140212.GB45402@ice.42.org> User-Agent: Mutt/1.4.2.3i I-love-doing-this: really X-Modeline: vim:set ts=8 sw=4 smarttab tw=72 si noic notitle: Accept-Languages: de, en X-URL: http://sec.42.org/ Subject: Re: The tale of a TCP 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: Sat, 26 Mar 2011 22:43:41 -0000 Hi, > On Fri, Mar 25, 2011 at 16:40 -0400, John Baldwin wrote: > > And the problem is that the code that uses 'adv' to determine if it > > sound send a window update to the remote end is falsely succeeding due > > to the overflow causing tcp_output() to 'goto send' but that it then > > fails to send any data because it thinks the remote window is full? On a whim I wanted to find out, how often that overflow is triggered in normal operation, and whipped up a quick counter-sysctl. --- sys/netinet/tcp_output.c.org 2011-01-04 19:27:00.000000000 +0100 +++ sys/netinet/tcp_output.c 2011-03-26 18:49:30.000000000 +0100 @@ -87,6 +87,11 @@ extern struct mbuf *m_copypack(); #endif +VNET_DEFINE(int, adv_neg) = 0; +SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, adv_neg, CTLFLAG_RD, + &VNET_NAME(adv_neg), 1, + "How many times adv got negative"); + VNET_DEFINE(int, path_mtu_discovery) = 1; SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, path_mtu_discovery, CTLFLAG_RW, &VNET_NAME(path_mtu_discovery), 1, @@ -573,6 +578,10 @@ long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - (tp->rcv_adv - tp->rcv_nxt); + if(min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) < + (tp->rcv_adv - tp->rcv_nxt)) + adv_neg++; + if (adv >= (long) (2 * tp->t_maxseg)) goto send; if (2 * adv >= (long) so->so_rcv.sb_hiwat) I booted my main (web/shell) box with (only) this patch: 11:36PM up 3:50, 1 user, load averages: 2.29, 1.51, 0.73 net.inet.tcp.adv_neg: 2466 That's approximately once every 5 seconds. That's way more often than I suspected. CU, Sec -- I wish there was a knob on the TV to turn up the intelligence. There's a knob called "brightness", but it doesn't seem to work.