From owner-freebsd-net@FreeBSD.ORG Sun May 22 02:30: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 D08F4106564A for ; Sun, 22 May 2011 02:30:56 +0000 (UTC) (envelope-from jhall@socket.net) Received: from mf1.socket.net (mf1.socket.net [216.106.88.38]) by mx1.freebsd.org (Postfix) with ESMTP id B53368FC0A for ; Sun, 22 May 2011 02:30:56 +0000 (UTC) Received: from localhost (unknown [216.106.88.17]) by mf1.socket.net (Postfix) with SMTP id 4FDBA403EB for ; Sat, 21 May 2011 21:15:20 -0500 (CDT) To: freebsd-net@freebsd.org From: jhall@socket.net X-Apparently-from: jhall@mail.socket.net X-Remote-Host: 216.106.31.249 User-Agent: Socket WebMail Date: Sat, 21 May 2011 21:15:20 -0500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20110522023056.D08F4106564A@hub.freebsd.org> Subject: IPSec Routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jhall@socket.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 02:30:57 -0000 I posted a similar question to the FreeBSD questions forum earlier, but the answer I received has only confused me more. So, I am asking a similar question here. Please excuse me if this is considered a cross post. I am using IPSec in transport mode to connect to a vendor's router. The connection is established and I am able to see the tunnels are established in racoon by the IPsec-SA established: ESP/Tunnel messages. And, my vendor has confirmed the connection is up on their end. What I am not understanding is how to add routes correctly when using transport mode. I have added the proper incoming/outgoing information using setkey. When I display the information using setkey -DP, the routes appear correct. I have defined one outbound route for the local private network to the remote private network and vice versa. When I try to ping the remote network, I do not receive any responses. Running a traceroute, I see the packet bounced back and forth between the external interface and the loopback adapter on my FBSD box. I am connecting to a Juniper router running the JUNOS operating system. This is the first time I have connected two networks together using transport mode as opposed to tunnel mode and I am really confused as to what I should be doing. The handbook information seems to deal only with tunnel mode. Thanks for your help. Jay From owner-freebsd-net@FreeBSD.ORG Sun May 22 02:36: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 61EAE106566B for ; Sun, 22 May 2011 02:36:13 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 39AFD8FC15 for ; Sun, 22 May 2011 02:36:13 +0000 (UTC) Received: by pvg11 with SMTP id 11so2811852pvg.13 for ; Sat, 21 May 2011 19:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=YmNEzS2Zbhjor2ryrLnz799mmtLSrp2oQNAKPGQLqBE=; b=m1Cnc6s426QeRM+fNO9IVdER98ZPSati0K9eh+2Z4kxK47/EGxtGC299JqUKAgqnFh Xh7qNG/XXmt0HGvGYNmTfjKJel0FxWdJEfMbmQlQlpLQvrcv4TRNtHyPlw9veRQ6r99x npzdNPGS/ffWndi6T2sVBRon5AJV06jX3panU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=XNtgZ5fET1Nkm2Uu6CRzs3B7yF11NuzkZeCxyf5+r6iAVtISv44o/nC+wBLX018XEd yJY/W/08502+ghILYvi23Xrqgyrbq0hsRP1v8IjnD0kIxWZr/eX9O3Wg+G47I1A07BGH vicjRfvthQomh3gZu+X+QT0uba0HlnOgkf3cA= MIME-Version: 1.0 Received: by 10.68.17.232 with SMTP id r8mr1627244pbd.91.1306031772826; Sat, 21 May 2011 19:36:12 -0700 (PDT) Received: by 10.68.63.104 with HTTP; Sat, 21 May 2011 19:36:12 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 May 2011 19:36:12 -0700 Message-ID: From: Josh Carroll To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: aliases on em(4) do not work properly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 02:36:13 -0000 On Thu, May 19, 2011 at 3:12 PM, Josh Carroll wrote: > After upgrading my hardware, I now have two new em(4) in this box > running FreeBSD 8.2-RELEASE/amd64. One NIC is the onboard NIC on the > Asus P8Z68-V Pro board, the other is the Intel EXPI9301CTBLK > PCI-Express card. em0 is the internet-facing card and I have 4 aliases > in addition to the primary address (I have a /29 IP allocation from > Comcast Business Class). After this hardware upgrade, any connection > with a source address of one of the aliases on em0 does not work > properly, it just hangs. Here is my rc.conf entry for this interface: I just wanted to report that after a reboot, things seem to be working properly and I cannot reproduce the problem. I had also rebooted my cable modem when this shutdown occurred, so it's entirely possible the SMC D3G cable modem was at fault. If I can reproduce the problem, I'll post additional information/details, but for now it seems the problem was transient. Thanks! Josh From owner-freebsd-net@FreeBSD.ORG Sun May 22 08:01:21 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 5B6281065670 for ; Sun, 22 May 2011 08:01:21 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id CB2CC8FC0A for ; Sun, 22 May 2011 08:01:20 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id p4M81IJR047803 for ; Sun, 22 May 2011 11:01:18 +0300 (EEST) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id p4M81HEU047799 for freebsd-net@freebsd.org; Sun, 22 May 2011 11:01:17 +0300 (EEST) Date: Sun, 22 May 2011 11:01:17 +0300 From: Zeus V Panchenko To: freebsd-net@freebsd.org Message-ID: <20110522080117.GB36033@relay.ibs.dn.ua> Mail-Followup-To: freebsd-net@freebsd.org References: <20110522023056.D08F4106564A@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110522023056.D08F4106564A@hub.freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 X-Face: iVBORw0KGgoAAAANSUhEUgAAACoAAAAqBAMAAAA37dRoAAAAFVBMVEWjjoiZhHDWzcZuW1U wOT+RcGxziJxEN0lIAAABrklEQVQokV2STXLbMAyFQaraE3a5dzSTfR1IF7CQrM3QuECn9z9DH0 gxzgSyFvr88PBD0uJxoR6BE+e8LtRgohE5ZB50sODP/REbfUnte/z12+llCekLUSKenFIMke6Be WinE8H0RJHSN71rUQp64gFDmtDDhRk0zam3FzpNVFprhwPGaFo6oY9wDBJQ9Qz6EuKyROJjDGa+ uza4VOTa8iHlN58Yv5BF9+4BGl0LA5pUD5xKXg4aQlVZm0co3NKxCGxQpu3aC352Gv3DZONmwQd tkrlaylV3YSew7bWtwAZF/zi9jblmprPoL7ktzeFSxmarVNmWRi+Bmxg7Y7tbGtR8XZUxLTo86G thANsssetjp3POuBvMBRlw6jRa5pKN7yVlP+F2lyiZGSMf5hnSU6eAVupmtfjRcxy0momwpxDnz 06hwnOWvBnUdR8U2/KX7cq26u1Jy5xFZMPOVONRbRUrwey8Qar6cWgf12xSymQuVX0DfYd4R8kN Hg0qCtLeaYZcj8B90M2N0cEX1P0vKSxw7NLy/3X8Qeriusu66jNA37P4Mn5QRTG2hz4d9D/6E3a EX852nwAAAABJRU5ErkJggg== Subject: Re: IPSec Routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus@ibs.dn.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 08:01:21 -0000 jhall@socket.net (jhall@socket.net) [11.05.22 05:31] wrote: > What I am not understanding is how to add routes correctly when using > transport mode. I have added the proper incoming/outgoing information > using setkey. When I display the information using setkey -DP, the routes > appear correct. I have defined one outbound route for the local private > network to the remote private network and vice versa. > what tcpdump shows? is there firewall? -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-net@FreeBSD.ORG Sun May 22 08:24: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 6CD281065673 for ; Sun, 22 May 2011 08:24:02 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 26D958FC14 for ; Sun, 22 May 2011 08:24:01 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 112F8B0380D5 for ; Sun, 22 May 2011 03:58:18 -0400 (EDT) thread-index: AcwYVgDJwLgaoXTMT52NbXT3iWC6dg== 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); Sun, 22 May 2011 03:58:13 -0400 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Sun, 22 May 2011 02:58:12 -0500 Date: Sun, 22 May 2011 02:58:12 -0500 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Message-ID: <20110522075811.GC3240@verio.net> Content-Class: urn:content-classes:message Importance: normal Priority: normal Mail-Followup-To: freebsd-net@freebsd.org X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4841 References: <20110522023056.D08F4106564A@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline In-Reply-To: <20110522023056.D08F4106564A@hub.freebsd.org> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-12-10) X-OriginalArrivalTime: 22 May 2011 07:58:13.0447 (UTC) FILETIME=[00140D70:01CC1856] Subject: Re: IPSec Routing 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: Sun, 22 May 2011 08:24:02 -0000 jhall@socket.net wrote: > > I am using IPSec in transport mode to connect to a vendor's router. The > connection is established and I am able to see the tunnels are established > in racoon by the IPsec-SA established: ESP/Tunnel messages. And, my > vendor has confirmed the connection is up on their end. Wow, transport mode. I have only set up tunnels in tunnel mode, so I don't have any direct experience to relate, but I can make some educated guesses that might point you in the right direction. > What I am not understanding is how to add routes correctly when > using transport mode. I have added the proper incoming/outgoing > information using setkey. When I display the information using > setkey -DP, the routes appear correct. I have defined one outbound > route for the local private network to the remote private network and > vice versa. What you have set up using setkey is "policy", not "routing." Routing defines WHERE things will go, while policy defines HOW things should go (basically, whether or not the packet should be encapsulated, encrypted, etc.) Since the concepts of policy and routing are separated in FreeBSD, you will probably need to enter the information in a redundant fashion. That is, you will need to enter routes into your route table that will forward traffic towards your vendor. And since you are using transport mode, you'll have to hope that all the intervening routers between you and your vendor will also know to route things in that same direction, and how to route any replies back to you. > When I try to ping the remote network, I do not receive any > responses. Running a traceroute, I see the packet bounced back and > forth between the external interface and the loopback adapter on my > FBSD box. Since you didn't give any configuration information, it's hard to guess why you are seeing that behavior. > This is the first time I have connected two networks together using > transport mode as opposed to tunnel mode and I am really confused as > to what I should be doing. The handbook information seems to deal > only with tunnel mode. Tunnel mode is often preferred because it simplifies routing a great deal. In transport mode, the source and destination IP's are not changed in any way on the encrypted packet, so it is then left as an exercise for your system's route table (and other routers on the Internet) to determine how to route the now-encrypted packet towards a gateway that can decrypt it. This could be as simple as just specifying a route using "route add -net" with a proper gateway, and letting things go from there, or it could get terribly complicated. It all depends on the networking in between. If you were using tunnel mode, the encrypted packet would change its source and destination IP's, specifying your gateway as the source, and your vendor's gateway as the destination, so intervening routers would have no difficulty delivering the packet, or routing reply packets back to you. -- 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 Sun May 22 10:19: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 85D961065675 for ; Sun, 22 May 2011 10:19:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 08B368FC0A for ; Sun, 22 May 2011 10:19:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p4MAJAgu052859; Sun, 22 May 2011 20:19:11 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 22 May 2011 20:19:10 +1000 (EST) From: Ian Smith To: Doug Barton In-Reply-To: <4DD809C2.8080704@FreeBSD.org> Message-ID: <20110522183629.H60311@sola.nimnet.asn.au> References: <4DD809C2.8080704@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Matthew Bowman , freebsd-net@freebsd.org Subject: Re: Bridging + VLANS 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, 22 May 2011 10:19:13 -0000 On Sat, 21 May 2011, Doug Barton wrote: > On 05/21/2011 01:58, Matthew Bowman wrote: > > I have an uplink to my ISP on a 2 IP /30 network (1.1.1.0/30 in the > > diagram) > > No help for your actual problem, sorry. I just wanted to point out that 1/8 > has been assigned by IANA to APNIC, so it should not be used as a substitute > for RFC 1918 space. I'm assuming that you're just using it as a placeholder > for the real assignment, however I would argue that even that is a bad idea > since at minimum it's a bad example that others may draw poor conclusions > from. I was concerned about this too after noticing 1.x.x.x connections to our streamserver, knowing the ancient Linux firewall/router forces 1.1.1.1 as the address of the interface used for PPPoE - I guess that was common usage back when? - but see the APNIC bods are onto it, also noting that 1.0/16 and many/most 1.1 (other than 1.1.1/24) are already allocated: http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=1.1.1.1&submit=Go Just as well, as I had to address the ADSL bridge within 1.1.1/24 .. > Yours in pedantry, > > Doug 254 out of 256 ain't bad, Ian From owner-freebsd-net@FreeBSD.ORG Sun May 22 14:31: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 7520F106566C for ; Sun, 22 May 2011 14:31:07 +0000 (UTC) (envelope-from jhall@socket.net) Received: from mf1.socket.net (mf1.socket.net [216.106.88.38]) by mx1.freebsd.org (Postfix) with ESMTP id 59B618FC0A for ; Sun, 22 May 2011 14:31:06 +0000 (UTC) Received: from localhost (unknown [216.106.88.17]) by mf1.socket.net (Postfix) with SMTP id 2E01B403E9 for ; Sun, 22 May 2011 09:31:06 -0500 (CDT) To: freebsd-net@freebsd.org From: jhall@socket.net X-Apparently-from: jhall@mail.socket.net X-Remote-Host: 216.106.31.249 User-Agent: Socket WebMail References: <20110522120030.4B70510656D2@hub.freebsd.org> Date: Sun, 22 May 2011 09:31:06 -0500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20110522143107.7520F106566C@hub.freebsd.org> Subject: RE: IPSec Routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jhall@socket.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 14:31:07 -0000 >If you were using tunnel mode, the encrypted packet would change its >source and destination IP's, specifying your gateway as the source, and >your vendor's gateway as the destination, so intervening routers would >have no difficulty delivering the packet, or routing reply packets back >to you. This may be where my misunderstanding is coming from. Our vendor has not specified an internal IP address for the other end of the tunnel. They have given me an address to ping once the connection is up and running though. Is it possible to using tunneling mode without an internal IP address on the other gateway? My understanding of the protocol is that this is not possible. Thank you for your help. Jay From owner-freebsd-net@FreeBSD.ORG Sun May 22 19:48:48 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 379861065670 for ; Sun, 22 May 2011 19:48:48 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.49.45]) by mx1.freebsd.org (Postfix) with ESMTP id D804F8FC12 for ; Sun, 22 May 2011 19:48:47 +0000 (UTC) Received: by syn.atarininja.org (Postfix, from userid 1001) id 336B85C3B; Sun, 22 May 2011 15:30:07 -0400 (EDT) Date: Sun, 22 May 2011 15:30:07 -0400 From: Wesley Shields To: freebsd-net@FreeBSD.org Message-ID: <20110522193007.GA63178@atarininja.org> References: <201105192153.p4JLrvtH004172@red.freebsd.org> <20110521064847.GB23992@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110521064847.GB23992@lonesome.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: fwd: kern/157188: [libpcap] [patch] incorporate patch from upstream 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, 22 May 2011 19:48:48 -0000 I've updated the port to address this. The audit trail for this PR has a patch which touches more than just libpcap. I'm curious if anyone on this list has comments on it, and if any committer wants to commit it (at least the libpcap part, the others appear right to me). -- WXS On Sat, May 21, 2011 at 01:48:47AM -0500, Mark Linimon wrote: > Apparently affects both the port and src. > mcl > > On Thu, May 19, 2011 at 09:53:57PM +0000, Peter Losher wrote: > > > > >Number: 157188 > > >Category: misc > > >Synopsis: libpcap > > >Confidential: no > > >Severity: non-critical > > >Priority: medium > > >Responsible: freebsd-bugs > > >State: open > > >Quarter: > > >Keywords: > > >Date-Required: > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Thu May 19 22:00:27 UTC 2011 > > >Closed-Date: > > >Last-Modified: > > >Originator: Peter Losher > > >Release: 8.2-RELEASE > > >Organization: > > Internet Systems Consortium > > >Environment: > > FreeBSD freebsd8.lab.isc.org 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > >Description: > > One of our engineers @ISC discovered that there is a bug in the currently released version of libpcap (in base and in ports) that can be triggered when using an "ip6 protochain" filter. It's due to the fairly complicated BPF bytecode that libpcap generates for IPv6 header chasing combined with a sign extension bug when processing JA (jump absolute) opcodes. (JA is used to go backwards and without sign extension on 64 bit platforms the BPF interpreter incorrectly jumps forward... a lot.) > > > > >How-To-Repeat: > > root@freebsd8:~# tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6 protochain 58' > > reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet) > > Segmentation fault: 11 (core dumped) > > > > >Fix: > > There is a fix in the libpcap repository: > > > > https://github.com/mcr/libpcap/commit/ecdc5c0a7f7591a7cd4aff696e42757c677fbbf7 > > > > but the tcpdump-workers have been pretty tardy about putting out newer code, so it sits there stalled. > > > > With the patch applied, it all works well and you should see something like this: > > > > -=- > > $ tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6 protochain 58' > > reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet) > > 18:43:07.098489 IP6 fe80::208:7dff:feb7:2cca > ff02::1: HBH ICMP6, multicast listener queryv2 [gaddr ::], length 28 > > -=- > > > > >Release-Note: > > >Audit-Trail: > > >Unformatted: > > _______________________________________________ > > freebsd-bugs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun May 22 20:14:52 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 5D89C106564A for ; Sun, 22 May 2011 20:14:52 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) by mx1.freebsd.org (Postfix) with ESMTP id C5E488FC13 for ; Sun, 22 May 2011 20:14:51 +0000 (UTC) Received: from [IPv6:2001:470:28:140:24f5:b4af:c57c:abfe] ([IPv6:2001:470:28:140:24f5:b4af:c57c:abfe]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.4) with ESMTP id p4MKElGM047097 for ; Sun, 22 May 2011 23:14:47 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <4DD96EA4.4080504@ukr.net> Date: Sun, 22 May 2011 23:14:28 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-92.0 required=5.0 tests=FREEMAIL_FROM,FSL_RU_URL, RDNS_NONE,SPF_SOFTFAIL,TO_NO_BRKTS_DIRECT,T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [IPv6:2001:470:28:140::5]); Sun, 22 May 2011 23:14:49 +0300 (EEST) Subject: ipv6 receive via rtadvd 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, 22 May 2011 20:14:52 -0000 Why host for so long waiting for ipv6 addresses? To get faster, it is necessary or server restarted rtadvd or on host repeatedly triggering "ndp -i em1" Perhaps we need to explicitly specify some other options rtadvd? server: FreeBSD mary-teresa 8.2-STABLE FreeBSD 8.2-STABLE #0: Wed Apr 20 03:20:47 EEST 2011 vlad11@beastie.mydomain.local:/usr/obj/usr/src/sys/otrada.1 amd64 # cat /etc/rc.conf | grep rta rtadvd_enable="YES" rtadvd_interfaces="re0" host: FreeBSD vm1.local 8.2-STABLE FreeBSD 8.2-STABLE #0: Sun May 22 02:05:47 EEST 2011 root@:/usr/obj/usr/src/sys/virtualbox.1 amd64 # cat /etc/rc.conf | grep em1 ifconfig_em1="DHCP" ifconfig_em1_ipv6="inet6 accept_rtadv" # ifconfig em1 em1: flags=8843 metric 0 mtu 1500 options=9b ether 08:00:27:e0:c6:f6 inet6 fe80::a00:27ff:fee0:c6f6%em1 prefixlen 64 scopeid 0x3 inet 10.0.0.205 netmask 0xffffff00 broadcast 10.0.0.255 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active -- Vladislav V. Prodan VVP24-UANIC +380[67]4584408 +380[99]4060508 vlad11@jabber.ru From owner-freebsd-net@FreeBSD.ORG Mon May 23 10:36:25 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 DB90B1065674 for ; Mon, 23 May 2011 10:36:25 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 22DD28FC08 for ; Mon, 23 May 2011 10:36:24 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 169E6856256; Mon, 23 May 2011 12:16:41 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 23.2689] X-CRM114-CacheID: sfid-20110523_12164_6729532D X-CRM114-Status: Good ( pR: 23.2689 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon May 23 12:16:41 2011 X-DSPAM-Confidence: 0.9966 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4dda3409168371097648581 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, >+I, 0.00101, >+On, 0.00108, 0), 0.00144, On+Sun, 0.00156, kernel, 0.00171, wrote+>, 0.00193, On+Sat, 0.00225, wrote+>>, 0.00296, wrote+>>, 0.00296, ==+0), 0.00312, org>+wrote, 0.00330, it+>, 0.00330, On+Tue, 0.00351, to+0, 0.00374, to+0, 0.00374, controller, 0.00374, controller, 0.00374, >>+>, 0.00432, vendor, 0.00432, wrote, 0.00440, wrote, 0.00440, at+11, 0.00510, driver, 0.00622, driver, 0.00622, Sun, 0.00685, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 568C385624B; Mon, 23 May 2011 12:16:40 +0200 (CEST) Message-ID: <4DDA3407.8020200@fsn.hu> Date: Mon, 23 May 2011 12:16:39 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: pyunyh@gmail.com References: <708793006.292748.1295186099577.JavaMail.root@erie.cs.uoguelph.ca> <20110117005524.GA1305@michelle.cdnetworks.com> <20110118.093804.74673434.sthaug@nethelp.no> <20110207002235.GA1244@michelle.cdnetworks.com> In-Reply-To: <20110207002235.GA1244@michelle.cdnetworks.com> Content-Type: multipart/mixed; boundary="------------020101040807050706060604" Cc: freebsd-net@freebsd.org, rmacklem@uoguelph.ca, sthaug@nethelp.no, Ronald Klop Subject: Re: TSO ethernet frame errors on 8-STABLE, was: bogus 0 len IP packet 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, 23 May 2011 10:36:25 -0000 This is a multi-part message in MIME format. --------------020101040807050706060604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, On 02/07/11 01:22, Pyun YongHyeon wrote: > On Sun, Feb 06, 2011 at 11:54:49PM +0100, Ronald Klop wrote: >> On Sat, 22 Jan 2011 00:01:47 +0100, Ronald Klop >> wrote: >> >>> On Tue, 18 Jan 2011 09:38:04 +0100, wrote: >>> >>>>>> So, does anyone have an idea why the IP length field would be set to >>>>> 0 >>>>>> for these TCP/IP packets? >>>>>> >>>>>> Here's some info from Ronald w.r.t. his hardware. (All I can think >>>>> of is >>>>>> that he could try disabling TSO, etc?) >>>>>> >>>>>> Thanks in advance for any help with this, rick >>>>>> >>>>> It seems that issue came from TSO. Driver will set ip_len and >>>>> ip_sum field to 0 before passing the TCP segment to controller. >>>>> The failed length were 4446, 5858, 3034 and 4310 and the total >>>>> number of such frames are more than 35k within 90 seconds. Since >>>>> failed length 4310 is continuously repeated I guess there is edge >>>>> case where em(4) didn't free failed TCP segment for TSO. >>>>> I remember there was commit to HEAD(r217295) which could be related >>>>> with this issue. >>>> I'm seeing the same problem with Broadcom NetXtreme (bce) cards: >>>> >>>> bce0@pci0:3:0:0: class=0x020000 card=0x03421014 chip=0x164c14e4 >>>> rev=0x12 hdr=0x00 >>>> vendor = 'Broadcom Corporation' >>>> device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter >>>> (BCM5708)' >>>> class = network >>>> subclass = ethernet >>>> >>>> This is with 8.2-PRERELEASE. Turning off TSO (ifconfig bce0 -tso) >>>> removes the problem. >>>> >>>> Steinar Haug, Nethelp consulting, sthaug@nethelp.no >>>> _______________________________________________ >>>> 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" >>> I tried -tso and -txcsum in various combinations, but it didn't solve >>> the problem. I wil look for another brand of network card to try. But >>> this has to wait till monday when I'm at the office again. >> I also used another network card (rl0) and it has the same problem with >> NFS. I'm going to change some network cables to see if that helps. I have >> some hints that there might be something wrong with that. >> > Hmm, given that rl(4) also shows the issue it seems the issue could > be in TCP/IP stack, not in driver side. rl(4) is dumb device so > network stack should do segmentation and checksum computation. > I highly doubt the issue came from faulty cable since other users > also reported the same issue. > Unfortunately I have no clue yet and I was not able to reproduce it > on my box. I vaguely guess some code in kernel changed the ip_len > to 0 in the middle of transmission. Rick's captured traffic looks > normal except 0 ip_len given that controller is computing checksum > on the fly. If mbuf chain was corrupted(e.g. m_len == 0) driver > would have failed to send those frames. I can see something similar. Attached are two pcaps, with TSO enabled/disabled (net.inet.tcp.tso). NIC is: bce0: mem 0xfa000000-0xfbffffff irq 16 at device 0.0 on pci7 miibus0: on bce0 brgphy0: PHY 2 on miibus0 brgphy0: 1000baseSX-FDX, 2500baseSX-FDX, auto bce0: Ethernet address: 00:1f:29:cc:97:62 bce0: [ITHREAD] In a HP BL460c. The OS is a 8-STABLE/amd64, compiled two days ago. --------------020101040807050706060604 Content-Type: application/octet-stream; name="tso-disabled" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tso-disabled" 1MOyoQIABAAAAAAAAAAAAP//AAABAAAA6DLaTYsIAQBKAAAASgAAAAAfKcyXYgAdcNGtqwgA RQAAPMxnQABABmTlwKhEG8CoRAMjz5xIzgr0SAAAAACgAhbQEN0AAAIEBbQEAggKXFA4LwAA AAABAwMA6DLaTa4IAQBKAAAASgAAAAAdcNGtqwAfKcyXYggARQAAPD+UQABABvG4wKhEA8Co RBucSCPPtWwMb84K9EmgEv//oPAAAAIEBbQBAwMDBAIICpq0KhhcUDgv6DLaTbgKAQBCAAAA QgAAAAAfKcyXYgAdcNGtqwgARQAANMxoQABABmTswKhEG8CoRAMjz5xIzgr0SbVsDHCAEBbQ uOgAAAEBCApcUDgvmrQqGOgy2k1GDAEAewAAAHsAAAAAHynMl2IAHXDRrasIAEUAAG3MaUAA QAZkssCoRBvAqEQDI8+cSM4K9Em1bAxwgBgW0ECpAAABAQgKXFA4L5q0KhhHRVQgLyBIVFRQ LzEuMQ0KQ29ubmVjdGlvbjogQ2xvc2UNCkhvc3Q6IDE5Mi4xNjguNjguMw0KDQroMtpN04cB AOoFAADqBQAAAB1w0a2rAB8pzJdiCABFAAXcP5tAAEAG7BHAqEQDwKhEG5xII8+1bAxwzgr0 goAQIIYIYgAAAQEICpq0KjlcUDgvSFRUUC8xLjEgNDA0IE5vdCBGb3VuZA0KQ29udGVudC1U eXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMQ0KQ2FjaGUtQ29udHJvbDogbXVz dC1yZXZhbGlkYXRlLG5vLWNhY2hlLG5vLXN0b3JlDQpDb250ZW50LUxlbmd0aDogMTM2NQ0K Q29ubmVjdGlvbjogY2xvc2UNClNlcnZlcjogSmV0dHkoNi4xLjIxKQ0KDQo8aHRtbD4KPGhl YWQ+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PUlTTy04ODU5LTEiLz4KPHRpdGxlPkVycm9yIDQwNCBOT1RfRk9VTkQ8L3Rp dGxlPgo8L2hlYWQ+Cjxib2R5PjxoMj5IVFRQIEVSUk9SIDQwNDwvaDI+CjxwPlByb2JsZW0g YWNjZXNzaW5nIC8uIFJlYXNvbjoKPHByZT4gICAgTk9UX0ZPVU5EPC9wcmU+PC9wPjxociAv PjxpPjxzbWFsbD5Qb3dlcmVkIGJ5IEpldHR5Oi8vPC9zbWFsbD48L2k+PGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICDoMtpN4YcBAKgAAACoAAAAAB1w0a2rAB8pzJdiCABFAACaP5xAAEAG8VLA qEQDwKhEG5xII8+1bBIYzgr0goAYIIaMqgAAAQEICpq0KjlcUDgvICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCjxici8+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCgo8L2JvZHk+CjwvaHRtbD4K6DLaTQiIAQBCAAAAQgAAAAAdcNGt qwAfKcyXYggARQAAND+dQABABvG3wKhEA8CoRBucSCPPtWwSfs4K9IKAESCGqMkAAAEBCAqa tCo5XFA4L+gy2k1riQEAQgAAAEIAAAAAHynMl2IAHXDRrasIAEUAADTMakAAQAZk6sCoRBvA qEQDI8+cSM4K9IK1bBIYgBAh8KfDAAABAQgKXFA4Mpq0KjnoMtpNn4kBAEIAAABCAAAAAB8p zJdiAB1w0a2rCABFAAA0zGtAAEAGZOnAqEQbwKhEAyPPnEjOCvSCtWwSfoAQIfCnXQAAAQEI ClxQODKatCo56DLaTSWKAQBCAAAAQgAAAAAfKcyXYgAdcNGtqwgARQAANMxsQABABmTowKhE G8CoRAMjz5xIzgr0grVsEn+AESHwp1sAAAEBCApcUDgymrQqOegy2k1IigEAQgAAAEIAAAAA HXDRrasAHynMl2IIAEUAADQ/nkAAQAbxtsCoRAPAqEQbnEgjz7VsEn/OCvSDgBAghajGAAAB AQgKmrQqOVxQODI= --------------020101040807050706060604 Content-Type: application/octet-stream; name="tso-enabled" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tso-enabled" 1MOyoQIABAAAAAAAAAAAAP//AAABAAAASTHaTWdVBwBKAAAASgAAAAAfKcyXYgAVLFEmAAgA RQAAPJqVQAA6Bjy3wKikG8CoRAP2sZxIsuVNXQAAAACgAhbQNoQAAAIEBbQEAggKJj3XyAAA AAABAwMASTHaTYNVBwBKAAAASgAAAAAADAesdAAfKcyXYggARQAAPMqIQABABgbEwKhEA8Co pBucSPaxKXzN4LLlTV6gEv//okMAAAIEBbQBAwMDBAIICt8e1IAmPdfISTHaTT1aBwBCAAAA QgAAAAAfKcyXYgAVLFEmAAgARQAANJqWQAA6Bjy+wKikG8CoRAP2sZxIsuVNXil8zeGAEBbQ ujsAAAEBCAomPdfI3x7UgEkx2k3BWgcAewAAAHsAAAAAHynMl2IAFSxRJgAIAEUAAG2al0AA OgY8hMCopBvAqEQD9rGcSLLlTV4pfM3hgBgW0EH8AAABAQgKJj3XyN8e1IBHRVQgLyBIVFRQ LzEuMQ0KQ29ubmVjdGlvbjogQ2xvc2UNCkhvc3Q6IDE5Mi4xNjguNjguMw0KDQpJMdpN/F0H AFAGAABQBgAAAAAMB6x0AB8pzJdiCABFAAAAyolAAEAGAADAqEQDwKikG5xI9rEpfM3hsuVN l4AYIIbtTQAAAQEICt8e1IImPdfISFRUUC8xLjEgNDA0IE5vdCBGb3VuZA0KQ29udGVudC1U eXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMQ0KQ2FjaGUtQ29udHJvbDogbXVz dC1yZXZhbGlkYXRlLG5vLWNhY2hlLG5vLXN0b3JlDQpDb250ZW50LUxlbmd0aDogMTM2NQ0K Q29ubmVjdGlvbjogY2xvc2UNClNlcnZlcjogSmV0dHkoNi4xLjIxKQ0KDQo8aHRtbD4KPGhl YWQ+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PUlTTy04ODU5LTEiLz4KPHRpdGxlPkVycm9yIDQwNCBOT1RfRk9VTkQ8L3Rp dGxlPgo8L2hlYWQ+Cjxib2R5PjxoMj5IVFRQIEVSUk9SIDQwNDwvaDI+CjxwPlByb2JsZW0g YWNjZXNzaW5nIC8uIFJlYXNvbjoKPHByZT4gICAgTk9UX0ZPVU5EPC9wcmU+PC9wPjxociAv PjxpPjxzbWFsbD5Qb3dlcmVkIGJ5IEpldHR5Oi8vPC9zbWFsbD48L2k+PGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPGJyLz4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKCjwvYm9keT4KPC9o dG1sPgpJMdpNJF4HAEIAAABCAAAAAAAMB6x0AB8pzJdiCABFAAA0yopAAEAGBsrAqEQDwKik G5xI9rEpfNPvsuVNl4ARIIaqOgAAAQEICt8e1IMmPdfISTHaTW1hBwBCAAAAQgAAAAAfKcyX YgAVLFEmAAgARQAANJqYQAA6Bjy8wKikG8CoRAP2sZxIsuVNlyl804mAECHwqTgAAAEBCAom PdfI3x7Ugkkx2k2WYQcAQgAAAEIAAAAAHynMl2IAFSxRJgAIAEUAADSamUAAOgY8u8CopBvA qEQD9rGcSLLlTZcpfNPvgBAh8KjSAAABAQgKJj3XyN8e1IJJMdpNTmIHAEIAAABCAAAAAB8p zJdiABUsUSYACABFAAA0mppAADoGPLrAqKQbwKhEA/axnEiy5U2XKXzT8IARIfCozwAAAQEI CiY918jfHtSDSTHaTV5iBwBCAAAAQgAAAAAADAesdAAfKcyXYggARQAANMqMQABABgbIwKhE A8CopBucSPaxKXzT8LLlTZiAECCFqjkAAAEBCArfHtSEJj3XyA== --------------020101040807050706060604-- From owner-freebsd-net@FreeBSD.ORG Mon May 23 11:07: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 4A07F1065670 for ; Mon, 23 May 2011 11:07:04 +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 3945B8FC17 for ; Mon, 23 May 2011 11:07: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 p4NB74rB051741 for ; Mon, 23 May 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NB73ST051738 for freebsd-net@FreeBSD.org; Mon, 23 May 2011 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 May 2011 11:07:03 GMT Message-Id: <201105231107.p4NB73ST051738@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, 23 May 2011 11:07:04 -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/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157182 net [lagg] lagg interface not working together with epair o kern/156978 net [lagg][patch] Take lagg rlock before checking flags o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156493 net [msk] Marvell Yukon 2 device works only few seconds o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W 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/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 [patch] routed(8): if.c in routed fails to compile if 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/154600 net [tcp] [panic] Random kernel panics on tcp_output 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/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/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/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/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/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/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 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/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. 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/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/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 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/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/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/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/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t 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/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/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 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/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/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa 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/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/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 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 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 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] 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/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 361 problems total. From owner-freebsd-net@FreeBSD.ORG Mon May 23 17:19:30 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 5397E106564A for ; Mon, 23 May 2011 17:19:30 +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 2050D8FC14 for ; Mon, 23 May 2011 17:19:29 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5AA937300A; Mon, 23 May 2011 19:20:10 +0200 (CEST) Date: Mon, 23 May 2011 19:20:10 +0200 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20110523172010.GA540@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: strange performance receiving with ixgbe/82599 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, 23 May 2011 17:19:30 -0000 Jack, i am doing some experiments with a modified ixgbe driver, and i am seeing some strange performance numbers which I'd like to explain. My card uses the 82599 chip, monted on an x16 slot on an Asus motherboard. CPU is i7-870 @ 2.93GHz. Both -head and RELENG_8 exhibit the same behaviour. I am using a modified driver which essentially accesses the rings from userspace, sending or receiving frames as soon as there is room. On the transmit side, using 64 byte packets (60+4 CRC) i can saturate the link (measured 14.87-14.88 Mpps) with no problem with just one core at 1.33 GHz and 2 or 4 queues (one queue tops at 12Mpps, but that's not a big issue). On the receive side, i can sustain 14.2Mpps (on 2-4 queues) if the sender generates 68-byte packets (i.e. 64+4CRC), but as soon as i go to 63+4 or less, the receive rate drops to 11.5-11.6Mpps. CPU cycles abound, because the speed is unchanged down to 1.45GHz Any reason to explain that suddend drop with short (but legal) packet sizes ? The stats counters report a lot of "missed" packets, though i never see the receive rings become full. I was wondering if there is any minimum inter-packet time that the receiver side needs, but could not find any register that controls that. The rings have 2048 slots each, so even something slow happening when the rings wrap don't really explain such a huge (25% or so) loss level. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon May 23 17:43:12 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 F1B81106566C for ; Mon, 23 May 2011 17:43:12 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id D4D868FC0A for ; Mon, 23 May 2011 17:43:12 +0000 (UTC) Received: from [10.26.194.132] ([12.11.238.122]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 May 2011 10:43:12 -0700 From: Ben Hutchings To: Luigi Rizzo In-Reply-To: <20110523172010.GA540@onelab2.iet.unipi.it> References: <20110523172010.GA540@onelab2.iet.unipi.it> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Date: Mon, 23 May 2011 10:43:10 -0700 Message-ID: <1306172590.3456.75.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 May 2011 17:43:12.0364 (UTC) FILETIME=[E31382C0:01CC1970] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18152.004 X-TM-AS-Result: No--13.339900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: net@freebsd.org Subject: Re: strange performance receiving with ixgbe/82599 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, 23 May 2011 17:43:13 -0000 On Mon, 2011-05-23 at 19:20 +0200, Luigi Rizzo wrote: > Jack, > i am doing some experiments with a modified ixgbe driver, and i am > seeing some strange performance numbers which I'd like to explain. > > My card uses the 82599 chip, monted on an x16 slot on an Asus > motherboard. CPU is i7-870 @ 2.93GHz. Both -head and RELENG_8 > exhibit the same behaviour. I am using a modified driver which > essentially accesses the rings from userspace, sending or > receiving frames as soon as there is room. > > On the transmit side, using 64 byte packets (60+4 CRC) i can saturate > the link (measured 14.87-14.88 Mpps) with no problem with just one > core at 1.33 GHz and 2 or 4 queues (one queue tops at 12Mpps, > but that's not a big issue). > > On the receive side, i can sustain 14.2Mpps (on 2-4 queues) if the > sender generates 68-byte packets (i.e. 64+4CRC), but as soon as i > go to 63+4 or less, the receive rate drops to 11.5-11.6Mpps. > CPU cycles abound, because the speed is unchanged down to 1.45GHz > > Any reason to explain that suddend drop with short (but legal) > packet sizes ? [...] With 64-bit wide RAM, a DMA write of 64 bytes with 8-byte alignment covers exactly 8 memory words. However a DMA write of 63 bytes with 8-byte alignment at the start covers 7 full and one partial memory word. So a read-modify-write operation is required for the last word. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Mon May 23 22:51:02 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 AEE7D1065673; Mon, 23 May 2011 22:51:02 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A08A58FC0C; Mon, 23 May 2011 22:51: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 p4NMp209003407; Mon, 23 May 2011 22:51:02 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4NMp2V8003393; Mon, 23 May 2011 22:51:02 GMT (envelope-from yongari) Date: Mon, 23 May 2011 22:51:02 GMT Message-Id: <201105232251.p4NMp2V8003393@freefall.freebsd.org> To: cy6erGn0m@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/156493: [msk] Marvell Yukon 2 device works only few seconds 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, 23 May 2011 22:51:02 -0000 Synopsis: [msk] Marvell Yukon 2 device works only few seconds State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon May 23 22:49:55 UTC 2011 State-Changed-Why: Could you try latest msk(4) on your box? Recently I fixed a couple stability issues of msk(4). I think you can install 8.2-RELEASE and use msk(4) in HEAD. - Download if_msk.c/if_mskreg.h from HEAD. - Manually change all instances of pci_find_cap to pci_find_extcap() in if_msk.c would make it build on 8.2-RELEASE. - Install new kernel and shutdown the box - Make sure to cold-start(i.e. unplug your system's power cord and replug it after waiting 30 seconds) before rebooting Let me know whether that makes any difference. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon May 23 22:49:55 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=156493 From owner-freebsd-net@FreeBSD.ORG Tue May 24 08:53:00 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 31A301065670 for ; Tue, 24 May 2011 08:53:00 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id DE3C28FC15 for ; Tue, 24 May 2011 08:52:59 +0000 (UTC) Received: from conversation.bsdunix.ch (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 9099138D0 for ; Tue, 24 May 2011 08:34:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by conversation.bsdunix.ch (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ou0AlQdfCkdc for ; Tue, 24 May 2011 08:34:18 +0000 (UTC) Received: from Tom-iMac.local (dmhd.bsdunix.ch [82.220.17.25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTPSA id 95DAB38CD for ; Tue, 24 May 2011 08:34:18 +0000 (UTC) Message-ID: <4DDB6D8A.1090803@bsdunix.ch> Date: Tue, 24 May 2011 10:34:18 +0200 From: Thomas User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Subject: Is accept_rtadv enabled by default? 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, 24 May 2011 08:53:00 -0000 Hello Out of pure curiosity. Why is accept_rtadv enabled by default on a interface with ipv6? I did not define accept_rtadv in rc.conf nor is it enabled via sysctl. net.inet6.ip6.accept_rtadv is set to 0 (default) But it's enabled on my interface: nd6 options=3 root@gw:/etc# ifconfig em0 em0: flags=9843 metric 0 mtu 1500 options=209b ether 00:1b:21:1e:e0:58 inet 82.220.2.120 netmask 0xfffffe00 broadcast 82.220.3.255 inet6 fe80::21b:21ff:fe1e:e058%em0 prefixlen 64 scopeid 0x3 inet6 2001:1680:2:100:2:120:a:b prefixlen 64 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active I could not find any reference that ACCEPT_RTADV is enabled by default in the ifconfig man page. Is this a bug? I can disable it with ifconfig em0 inet6 -accept_rtadv and put -accept_rtadv in rc.conf. My system: 8.2-STABLE FreeBSD 8.2-STABLE #1: Mon May 2 10:08:30 UTC 2011 rc.conf: ipv6_enable="YES" ipv6_defaultrouter="2001:1680:2:100::1" ipv6_ifconfig_em0="2001:1680:2:100:2:120:a:b prefixlen 64" ipv6_firewall_enable="YES" ipv6_firewall_type="OPEN" sysctl ist set to 0: net.inet6.ip6.accept_rtadv: 0 Regards, Thomas From owner-freebsd-net@FreeBSD.ORG Tue May 24 09:27:05 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 20ABD106564A for ; Tue, 24 May 2011 09:27:05 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 582268FC08 for ; Tue, 24 May 2011 09:27:04 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p4O99SKP034317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 18:09:39 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p4O99Gdu027916; Tue, 24 May 2011 18:09:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 24 May 2011 18:09:01 +0900 (JST) Message-Id: <20110524.180901.205130608663171270.hrs@allbsd.org> To: freebsdlists@bsdunix.ch From: Hiroki Sato In-Reply-To: <4DDB6D8A.1090803@bsdunix.ch> References: <4DDB6D8A.1090803@bsdunix.ch> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_May_24_18_09_01_2011_319)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Tue, 24 May 2011 18:09:40 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: net@FreeBSD.org Subject: Re: Is accept_rtadv enabled by default? 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, 24 May 2011 09:27:05 -0000 ----Security_Multipart(Tue_May_24_18_09_01_2011_319)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas wrote in <4DDB6D8A.1090803@bsdunix.ch>: fr> Hello fr> fr> Out of pure curiosity. Why is accept_rtadv enabled by default on a fr> interface with ipv6? I did not define accept_rtadv in rc.conf nor is it fr> enabled via sysctl. net.inet6.ip6.accept_rtadv is set to 0 (default) An interface on FreeBSD 8.x accepts RAs only when net.inet6.ip6.accept_rtadv=1 *and* ACCEPT_RTADV is enabled at the same time. This has been the default behavior regarding RAs for a long time. A new thing on 8.x is that the interface option ACCEPT_RTADV is exposed in the ifconfig output. This flag was actually enabled by default prior to 8.x, too. -- Hiroki ----Security_Multipart(Tue_May_24_18_09_01_2011_319)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk3bda0ACgkQTyzT2CeTzy0bPACg1ZaOAf6I9aMBlcjwcH3S29/l LYEAoMNF+WLvt+gHP/8bZfdLA5OFgbEY =1n49 -----END PGP SIGNATURE----- ----Security_Multipart(Tue_May_24_18_09_01_2011_319)---- From owner-freebsd-net@FreeBSD.ORG Tue May 24 09:30:16 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 3AE57106566B; Tue, 24 May 2011 09:30:16 +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 139468FC19; Tue, 24 May 2011 09:30:16 +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 p4O9UFEZ015336; Tue, 24 May 2011 09:30:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4O9UFiC015327; Tue, 24 May 2011 09:30:15 GMT (envelope-from linimon) Date: Tue, 24 May 2011 09:30:15 GMT Message-Id: <201105240930.p4O9UFiC015327@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/157287: [re] re0: INVARIANTS panic (Memory modified after free) 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, 24 May 2011 09:30:16 -0000 Old Synopsis: re0: INVARIANTS panic (Memory modified after free) New Synopsis: [re] re0: INVARIANTS panic (Memory modified after free) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 24 09:29:55 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=157287 From owner-freebsd-net@FreeBSD.ORG Tue May 24 10:33:28 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 849AF1065670 for ; Tue, 24 May 2011 10:33:28 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 284D38FC13 for ; Tue, 24 May 2011 10:33:27 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p4OAXDfn035017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 19:33:24 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p4OAX1mp028681; Tue, 24 May 2011 19:33:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 24 May 2011 19:32:57 +0900 (JST) Message-Id: <20110524.193257.594201570588660278.hrs@allbsd.org> To: universite@ukr.net From: Hiroki Sato In-Reply-To: <4DD96EA4.4080504@ukr.net> References: <4DD96EA4.4080504@ukr.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_May_24_19_32_57_2011_378)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Tue, 24 May 2011 19:33:24 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: freebsd-net@FreeBSD.org Subject: Re: ipv6 receive via rtadvd 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, 24 May 2011 10:33:28 -0000 ----Security_Multipart(Tue_May_24_19_32_57_2011_378)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Vladislav V. Prodan" wrote in <4DD96EA4.4080504@ukr.net>: un> Why host for so long waiting for ipv6 addresses? un> To get faster, it is necessary or server restarted rtadvd or on host un> repeatedly triggering "ndp -i em1" un> un> Perhaps we need to explicitly specify some other options rtadvd? un> un> server: un> FreeBSD mary-teresa 8.2-STABLE FreeBSD 8.2-STABLE #0: Wed Apr 20 un> 03:20:47 EEST 2011 un> vlad11@beastie.mydomain.local:/usr/obj/usr/src/sys/otrada.1 amd64 un> un> # cat /etc/rc.conf | grep rta un> rtadvd_enable="YES" un> rtadvd_interfaces="re0" un> un> un> host: un> FreeBSD vm1.local 8.2-STABLE FreeBSD 8.2-STABLE #0: Sun May 22 un> 02:05:47 EEST 2011 root@:/usr/obj/usr/src/sys/virtualbox.1 amd64 un> un> # cat /etc/rc.conf | grep em1 un> ifconfig_em1="DHCP" un> ifconfig_em1_ipv6="inet6 accept_rtadv" All you need in rc.conf on 8.x is ipv6_enable="YES" instead of $ifconfig_IF_ipv6 for SLAAC ($ifconfig_IF_ipv6 should be noop on 8.x). The rtsol utility will be invoked and it should make the automatic address configuration faster. -- Hiroki ----Security_Multipart(Tue_May_24_19_32_57_2011_378)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk3biVkACgkQTyzT2CeTzy0nfgCg0SEmm5wmVuNUcpvpYEkKdYMb CGAAnivJPeq+LVvMm6ZkwqF8oGuTZFoB =q6E8 -----END PGP SIGNATURE----- ----Security_Multipart(Tue_May_24_19_32_57_2011_378)---- From owner-freebsd-net@FreeBSD.ORG Tue May 24 19:11: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 BDA041065673 for ; Tue, 24 May 2011 19:11:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E09A8FC12 for ; Tue, 24 May 2011 19:11:11 +0000 (UTC) Received: by pwj8 with SMTP id 8so4064557pwj.13 for ; Tue, 24 May 2011 12:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=pLSZYpc1HHGExR9O+kYJY3xZ3eMzZkI7YEbVU6/LRpA=; b=ZhS4KWxfSD10+zch3bIlk1wDhtZuZtrMyXjhNUItzNxyfIGCL5dWRVXFmTE95pos1o wcYMPJsxoOREKxrs4LG2tIyXtXPYqsEIn0/UyhPlbfzBVT7Gn8HxbVnNn9vgHNL4N63+ 4BAl8WcJP6Nme66lKvyQTPhghwdeRQ1R8gA2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=uIuK2yYZBPGCTOBVte4U2+UYoVFivaYZMw8/c8NX9ltPa4GUpD7/E4UZO6naeFHnvu oHG9gAepQIq6BXtOEKv6Q89+a74lSDrlFrlQM4fbiq+I5XofP49UDTRqT73CMWeeUsk5 /f2oSfrEWR6y43ASJ3SlDdUayHIyTfoIQYtQo= Received: by 10.68.18.201 with SMTP id y9mr3064578pbd.370.1306264270639; Tue, 24 May 2011 12:11:10 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 3sm5164545pbf.29.2011.05.24.12.11.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2011 12:11:09 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 24 May 2011 12:11:08 -0700 From: YongHyeon PYUN Date: Tue, 24 May 2011 12:11:08 -0700 To: linimon@freebsd.org Message-ID: <20110524191108.GH10984@michelle.cdnetworks.com> References: <201105240930.p4O9UFiC015327@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105240930.p4O9UFiC015327@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/157287: [re] re0: INVARIANTS panic (Memory modified after free) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 19:11:11 -0000 On Tue, May 24, 2011 at 09:30:15AM +0000, linimon@freebsd.org wrote: > Old Synopsis: re0: INVARIANTS panic (Memory modified after free) > New Synopsis: [re] re0: INVARIANTS panic (Memory modified after free) > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Tue May 24 09:29:55 UTC 2011 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=157287 > _______________________________________________ Because the size is 4092 I vaguely guess it was not caused by re(4). re(4) just uses either 2K or 9K clusters. Of course that does mean re(4) is bug free here. Given that submitter can see panic during booting which in turn means re(4) has little chance to run, it might not be re(4)'s fault. From owner-freebsd-net@FreeBSD.ORG Tue May 24 21:00:23 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 2C1CC1065670 for ; Tue, 24 May 2011 21:00:23 +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 11ED28FC0C for ; Tue, 24 May 2011 21:00:23 +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 p4OL0MUs050119 for ; Tue, 24 May 2011 21:00:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4OL0M3p050118; Tue, 24 May 2011 21:00:22 GMT (envelope-from gnats) Date: Tue, 24 May 2011 21:00:22 GMT Message-Id: <201105242100.p4OL0M3p050118@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Mark Linimon Cc: Subject: Re: kern/157287: [re] re0: INVARIANTS panic (Memory modified after free) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Linimon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 21:00:23 -0000 The following reply was made to PR kern/157287; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/157287: [re] re0: INVARIANTS panic (Memory modified after free) Date: Tue, 24 May 2011 15:55:17 -0500 ----- Forwarded message from YongHyeon PYUN ----- Date: Tue, 24 May 2011 12:11:08 -0700 From: YongHyeon PYUN To: linimon@freebsd.org Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/157287: [re] re0: INVARIANTS panic (Memory modified after free) User-Agent: Mutt/1.4.2.3i Because the size is 4092 I vaguely guess it was not caused by re(4). re(4) just uses either 2K or 9K clusters. Of course that does mean re(4) is bug free here. Given that submitter can see panic during booting which in turn means re(4) has little chance to run, it might not be re(4)'s fault. ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Wed May 25 02:38:52 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 611D1106564A for ; Wed, 25 May 2011 02:38:52 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id D83748FC0C for ; Wed, 25 May 2011 02:38:51 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p4P2cdBN043463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 May 2011 11:38:50 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p4P2cT80082960; Wed, 25 May 2011 11:38:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 25 May 2011 11:38:24 +0900 (JST) Message-Id: <20110525.113824.427376659208697618.hrs@allbsd.org> To: mrmullemeck@gmail.com From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_May_25_11_38_24_2011_588)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Wed, 25 May 2011 11:38:50 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: freebsd-net@FreeBSD.org Subject: Re: rtsol set IFF_UP when started - why? 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, 25 May 2011 02:38:52 -0000 ----Security_Multipart(Wed_May_25_11_38_24_2011_588)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit MrMulleMeck wrote in : mr> When rtsol(d) starts, it check the interface status (flags). If flags mr> are not (IFF_UP|IFF_RUNNING) rtsol concludes the interface is "not mr> active". However, immediately after this, rtsol will activate/set the mr> IFF_UP flag (if not set) causing DAD to start. Let say that the link mr> is not ready yet (but in a short period of time) when rtsold starts, mr> wouldn't this cause DAD to believe that the address is OK (no response mr> since RS messages are actually never sent over the wire)? DAD code assumes a link is ready when IFF_UP && IFF_DRV_RUNNING. In the case that a link is actually down even if IFF_DRV_RUNNING, DAD probing messages will be sent and can be lost. mr> What is the rationale (if any) for rtsol to set the IFF_UP flag? It mr> seems that rtsold will wait anyway for DAD later on? Simply because rtsol needs to activate the specified interface if it is down. As explained above, DAD code in the kernel will wait for IFF_DRV_RUNNING after IFF_UP. -- Hiroki ----Security_Multipart(Wed_May_25_11_38_24_2011_588)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk3ca6AACgkQTyzT2CeTzy0BqgCdH9kQUGSZ4I5CbruTaHrDigX9 /1oAn0BDZwbOvdghMXTwNNG18eZKr1wh =0+ON -----END PGP SIGNATURE----- ----Security_Multipart(Wed_May_25_11_38_24_2011_588)---- From owner-freebsd-net@FreeBSD.ORG Wed May 25 19:20:14 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 DCA5B106564A for ; Wed, 25 May 2011 19:20:13 +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 C1ADC8FC0A for ; Wed, 25 May 2011 19:20: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 p4PJKDUG008853 for ; Wed, 25 May 2011 19:20:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4PJKDii008852; Wed, 25 May 2011 19:20:13 GMT (envelope-from gnats) Date: Wed, 25 May 2011 19:20:13 GMT Message-Id: <201105251920.p4PJKDii008852@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Joerg Wunsch Cc: Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 19:20:14 -0000 The following reply was made to PR kern/157287; it has been noted by GNATS. From: Joerg Wunsch To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free) Date: Wed, 25 May 2011 21:17:30 +0200 Here's a stack trace: db> bt Tracing pid 0 tid 100000 td 0xc088c130 kdb_enter(c07f7e81,c07f7e81,c08173ce,c0c206f8,0,...) at kdb_enter+0x3a panic(c08173ce,c07ef54a,ffc,3403c04e,c6eec880,...) at panic+0x134 mtrash_ctor(c6eec000,1000,0,102,c6f10700,...) at mtrash_ctor+0x77 uma_zalloc_arg(c118a700,0,102,2,102,...) at uma_zalloc_arg+0x109 malloc(1000,c0849170,102,c077cabc,44,...) at malloc+0xe4 bus_dmamem_alloc(c6f10700,c6f230c8,c,c6f230c4,ffffffff,...) at bus_dmamem_alloc+0x8a re_attach(c6f10c00,c6e04860,c0842288,c07faafa,80000000,...) at re_attach+0x118a device_attach(c6f10c00,4,c07fa9dc,a79) at device_attach+0x36f device_probe_and_attach(c6f10c00,c6e5cb00,c0c20900,c0b57614,c6f10c80,...) at device_probe_and_attach+0x4e bus_generic_attach(c6f10c80,c6e2f160,1,c0b57050,0,...) at bus_generic_attach+0x19 acpi_pci_attach(c6f10c80,c6f10c80,ffffffff,c07faafa,80000000,...) at acpi_pci_attach+0x194 device_attach(c6f10c80,4,c07fa9dc,a79) at device_attach+0x36f device_probe_and_attach(c6f10c80,c6e4c380,c0c20998,c0b57944,c6e5cb00,...) at device_probe_and_attach+0x4e bus_generic_attach(c6e5cb00,c0b73688,3,c0c20988,c6e2f160,...) at bus_generic_attach+0x19 acpi_pcib_attach(c6e5cb00,c6f10dd0,3,c0c209b0,c6e2f160,...) at acpi_pcib_attach+0x194 acpi_pcib_pci_attach(c6e5cb00,c6e5cb00,ffffffff,c07faafa,80000000,...) at acpi_pcib_pci_attach+0x9d device_attach(c6e5cb00,4,c07fa9dc,a79) at device_attach+0x36f device_probe_and_attach(c6e5cb00,c6e42680,c0c20a64,c0b57614,c6e4c380,...) at device_probe_and_attach+0x4e bus_generic_attach(c6e4c380,c6e29900,1,c0b57050,0,...) at bus_generic_attach+0x19 acpi_pci_attach(c6e4c380,c6dfe860,c0842288,c07faafa,80000000,...) at acpi_pci_attach+0x194 device_attach(c6e4c380,4,c07fa9dc,a79) at device_attach+0x36f device_probe_and_attach(c6e4c380,c6dae600,c0c20afc,c0b57944,c6e42680,...) at device_probe_and_attach+0x4e bus_generic_attach(c6e42680,c0b73688,0,c0c20aec,c6e29900,...) at bus_generic_attach+0x19 acpi_pcib_attach(c6e42680,c6e544b4,0,c0c20b1c,2,...) at acpi_pcib_attach+0x194 acpi_pcib_acpi_attach(c6e42680,c6e0c860,c0842288,c07faafa,80000000,...) at acpi_pcib_acpi_attach+0x246 device_attach(c6e42680,4,c07fa9dc,a79) at device_attach+0x36f device_probe_and_attach(c6e42680,3,c0c20c18,c0b550d7,c6dae600,...) at device_probe_and_attach+0x4e bus_generic_attach(c6dae600,c0b72e09,100000,dff00000,3,...) at bus_generic_attach+0x19 acpi_attach(c6dae600,c6e00860,c0842288,c07faafa,80000000,...) at acpi_attach+0xc87 device_attach(c6dae600,4,c07fa9dc,a79) at device_attach+0x36f device_probe_and_attach(c6dae600,c6daec00,c0c20ca4,c0b6821e,c6daec00,...) at device_probe_and_attach+0x4e bus_generic_attach(c6daec00,a,c0b730be,0,c6cff435,...) at bus_generic_attach+0x19 nexus_acpi_attach(c6daec00,c6e1e060,c0842288,c07faafa,80000000,...) at nexus_acpi_attach+0x7e device_attach(c6daec00,4,c07fa9dc,a79) at device_attach+0x36f device_probe_and_attach(c6daec00,c6d2a600,c6d2a600,c6d00520,c6d2a600,...) at device_probe_and_attach+0x4e bus_generic_new_pass(c6d2a600,c6dad000,c08421b8,c6cdfd74,fffffff,...) at bus_generic_new_pass+0xc5 bus_set_pass(7fffffff,c0c20d5c,c077a80c,c07f9ced,c0c20d78,...) at bus_set_pass+0x81 root_bus_configure(c07f9ced,c0c20d78,c053425c,0,c1ec00,...) at root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at configure+0xc mi_startup() at mi_startup+0xac begin() at begin+0x2c (Taking a coredump for analysis in kgdb is not possible as the dump device has not been configured yet at that point.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-net@FreeBSD.ORG Wed May 25 20:40:11 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 73F68106566C for ; Wed, 25 May 2011 20:40:11 +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 64B268FC12 for ; Wed, 25 May 2011 20:40: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 p4PKeBPZ082922 for ; Wed, 25 May 2011 20:40:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4PKeB6B082921; Wed, 25 May 2011 20:40:11 GMT (envelope-from gnats) Date: Wed, 25 May 2011 20:40:11 GMT Message-Id: <201105252040.p4PKeB6B082921@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Joerg Wunsch Cc: Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:40:11 -0000 The following reply was made to PR kern/157287; it has been noted by GNATS. From: Joerg Wunsch To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free) Date: Wed, 25 May 2011 22:33:13 +0200 Some more analysis on the stack trace: re_attach+0x118a corresponds to re_allocmem(), line 1085: /* Allocate DMA'able memory for the RX ring */ error = bus_dmamem_alloc(sc->rl_ldata.rl_rx_list_tag, (void **)&sc->rl_ldata.rl_rx_list, BUS_DMA_WAITOK | BUS_DMA_COHERENT | BUS_DMA_ZERO, &sc->rl_ldata.rl_rx_list_map); callee bus_dmamem_alloc+0x8a is i386/i386/busdma_machdep.c, bus_dmamem_alloc() line 526: /* * XXX: * (dmat->alignment < dmat->maxsize) is just a quick hack; the exact * alignment guarantees of malloc need to be nailed down, and the * code below should be rewritten to take that into account. * * In the meantime, we'll warn the user if malloc gets it wrong. */ if ((dmat->maxsize <= PAGE_SIZE) && (dmat->alignment < dmat->maxsize) && dmat->lowaddr >= ptoa((vm_paddr_t)Maxmem)) { *vaddr = malloc(dmat->maxsize, M_DEVBUF, mflags); } else { I could not spot anything obvious though. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-net@FreeBSD.ORG Thu May 26 01:57:33 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 82B711065677 for ; Thu, 26 May 2011 01:57:33 +0000 (UTC) (envelope-from jhall@socket.net) Received: from mf1.socket.net (mf1.socket.net [216.106.88.38]) by mx1.freebsd.org (Postfix) with ESMTP id 61F628FC13 for ; Thu, 26 May 2011 01:57:33 +0000 (UTC) Received: from localhost (unknown [216.106.88.17]) by mf1.socket.net (Postfix) with SMTP id 722A540421; Wed, 25 May 2011 20:57:32 -0500 (CDT) To: remko@elvandar.org From: jhall@socket.net X-Apparently-from: jhall@mail.socket.net X-Remote-Host: 216.106.31.249 User-Agent: Socket WebMail References: <20110522120030.4B70510656D2@hub.freebsd.org> <20110522143107.7520F106566C@hub.freebsd.org> Date: Wed, 25 May 2011 20:57:32 -0500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20110526015733.82B711065677@hub.freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Re: IPSec Routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jhall@socket.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 01:57:34 -0000 ---------------------------------------------------- >From : Remko Lodder To : jhall@socket.net Subject : Re: IPSec Routing Date : Sun, 22 May 2011 21:12:24 +0200 > > Basically what happends is that an IPSEC tunnel looks like this > > > Internal_A -->> Internal FW A [ FW A] External FWA ---->>> [Internet] <<<---- External FWB [FW B] Internal FW B <<-- Internal_B > External FWA [ ------------ TUNNEL ---------] External FWB [also called Phase1] > Internal_A [------------------------------------------------------------------- TUNNEL ----------------------------------------------------------] Internal_B [Also called phase2] > > The external FW's talk to eachother and make a secure pipe. The internal networks / hosts, use the secure pipe to route traffic > between them. So basically the first TUNNEL line is a big pipe, and the second TUNNEL line is packets WITHIN that first tunnel line.. (complex?) > > Comment: > > A connection is setup between the external FWA and External FWB, so that you have a secure pipe between the firewalls > to exchange data. > > In some cases you talk to the external IP and it gets processed there and onwards. > > In other cases [more likely], you setup a secondary tunnel (phase2) which enables you to talk to internal hosts on the other end. > An IPSEC session is never established between internal IP ranges (if flowing over the internet, ofcourse within the network itself > it is entirely possible). > > The IPSEC session _does_ allow you to route and send traffic to an internal IP adres over the tunnel though. > > If you can shed some more light in what you mean I might be able to help. I have setup 1000's of tunnels between mostly commercial > grade firewalls but I might assist in getting a bit further. Thank you to everyone for their help. The connection is now up and running. Our vendor had an incorrect entry in their route table. Jay From owner-freebsd-net@FreeBSD.ORG Thu May 26 15:35:52 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 5261C106566B for ; Thu, 26 May 2011 15:35:52 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 28ABC8FC08 for ; Thu, 26 May 2011 15:35:51 +0000 (UTC) Received: by pzk27 with SMTP id 27so448359pzk.13 for ; Thu, 26 May 2011 08:35:51 -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=vTaGLy/e/1TIK6p+WphiO+MG3VoIo1NMmyCUWVYv/p4=; b=RPL2O94CdVfvxez1HVRQT6PkalcHrtDTIZ4bqnZMVyLwduhxCtn4DYunnwf49ir9Wq 0SWid1y0AisEARIRrGFnXD7kJAk9a1ctaTytaH+Zw2EKnwu+iVhIDTTmWWLOFYHgcz+B SVrk/vgfz1OhvAG4j+RNgoY9p0mc3GFq7VLx0= 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=DyjxE/gQTe/CwWKRat0MnlTmPhWnDFkpALX02P/5zdR9NQvZkqQcRKQ1cvQ8TsYCbH 8PKIURz0Df21/6CPHOQB5/teFo0veCUZhEhA1yfJZxZsHpxxsSxxH52pVuzRm+AUNku/ XhtmHyAEGG5eCFshVuSG0TBVkK4RFFAm6dYZI= MIME-Version: 1.0 Received: by 10.68.65.111 with SMTP id w15mr384743pbs.317.1306423652303; Thu, 26 May 2011 08:27:32 -0700 (PDT) Received: by 10.68.54.193 with HTTP; Thu, 26 May 2011 08:27:32 -0700 (PDT) In-Reply-To: <201105252040.p4PKeB6B082921@freefall.freebsd.org> References: <201105252040.p4PKeB6B082921@freefall.freebsd.org> Date: Thu, 26 May 2011 11:27:32 -0400 Message-ID: From: Arnaud Lacombe To: Joerg Wunsch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free) 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, 26 May 2011 15:35:52 -0000 Hi, On Wed, May 25, 2011 at 4:40 PM, Joerg Wunsch wrote: > The following reply was made to PR kern/157287; it has been noted by GNAT= S. > > From: Joerg Wunsch > To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@FreeBSD.org > Cc: > Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after fr= ee) > Date: Wed, 25 May 2011 22:33:13 +0200 > > =A0Some more analysis on the stack trace: > > =A0re_attach+0x118a corresponds to re_allocmem(), line 1085: > > =A0 =A0 =A0 =A0 /* Allocate DMA'able memory for the RX ring */ > > =A0 =A0 =A0 =A0 error =3D bus_dmamem_alloc(sc->rl_ldata.rl_rx_list_tag, > =A0 =A0 =A0 =A0 =A0 =A0 (void **)&sc->rl_ldata.rl_rx_list, > =A0 =A0 =A0 =A0 =A0 =A0 BUS_DMA_WAITOK | BUS_DMA_COHERENT | BUS_DMA_ZERO, > =A0 =A0 =A0 =A0 =A0 =A0 &sc->rl_ldata.rl_rx_list_map); > > =A0callee bus_dmamem_alloc+0x8a is i386/i386/busdma_machdep.c, > =A0bus_dmamem_alloc() line 526: > > =A0 =A0 =A0 =A0 /* > =A0 =A0 =A0 =A0 =A0* XXX: > =A0 =A0 =A0 =A0 =A0* (dmat->alignment < dmat->maxsize) is just a quick ha= ck; the exact > =A0 =A0 =A0 =A0 =A0* alignment guarantees of malloc need to be nailed dow= n, and the > =A0 =A0 =A0 =A0 =A0* code below should be rewritten to take that into acc= ount. > =A0 =A0 =A0 =A0 =A0* > =A0 =A0 =A0 =A0 =A0* In the meantime, we'll warn the user if malloc gets = it wrong. > =A0 =A0 =A0 =A0 =A0*/ > =A0 =A0 =A0 =A0 if ((dmat->maxsize <=3D PAGE_SIZE) && > =A0 =A0 =A0 =A0 =A0 =A0(dmat->alignment < dmat->maxsize) && > =A0 =A0 =A0 =A0 =A0 =A0 dmat->lowaddr >=3D ptoa((vm_paddr_t)Maxmem)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *vaddr =3D malloc(dmat->maxsize, M_DEVBUF= , mflags); > =A0 =A0 =A0 =A0 } else { > > =A0I could not spot anything obvious though. This would likely only be the trigger of the panic, following the inconsistency. Finding the previous owner of the memory chunk would give more clue, AFAIK, FreeBSD do record the IP of the last user of a memory chunk (as does Linux' kmemcheck), so that might not be trivial to find out. - Arnaud > > =A0-- > =A0cheers, J"org =A0 =A0 =A0 =A0 =A0 =A0 =A0 .-.-. =A0 --... ...-- =A0 -.= . . =A0DL8DTL > > =A0http://www.sax.de/~joerg/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0NIC: JW11-RIPE > =A0Never trust an operating system you don't have sources for. ;-) > _______________________________________________ > 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 May 26 16:00:28 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 4C2FC1065672 for ; Thu, 26 May 2011 16:00:28 +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 3BF3A8FC0C for ; Thu, 26 May 2011 16:00:28 +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 p4QG0STW083030 for ; Thu, 26 May 2011 16:00:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4QG0SNP083025; Thu, 26 May 2011 16:00:28 GMT (envelope-from gnats) Date: Thu, 26 May 2011 16:00:28 GMT Message-Id: <201105261600.p4QG0SNP083025@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Joerg Wunsch Cc: Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:00:28 -0000 The following reply was made to PR kern/157287; it has been noted by GNATS. From: Joerg Wunsch To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free) Date: Thu, 26 May 2011 17:54:24 +0200 As it turns out this might be related to something else that has been using that piece of memory before re(4) is activated, here are the boot messages for reference. Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #7: Wed May 25 08:21:28 MET DST 2011 j@uriah.heep.sax.de:/usr/obj/usr/src/sys/URIAH i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (1989.88-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40f32 Family = f Model = 43 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 4294967296 (4096 MB) avail memory = 3677511680 (3507 MB) ACPI APIC Table: <112007 APIC1437> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd0 at kbdmux0 acpi0: <112007 RSDT1437> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fec00000, fed40000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x2f00-0x2fff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xfdfff000-0xfdffffff irq 21 at device 2.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfdffec00-0xfdffecff irq 22 at device 2.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 hdac0: mem 0xfdff8000-0xfdffbfff irq 23 at device 7.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib1: at device 8.0 on pci0 pci1: on pcib1 sym0: <875> port 0xc000-0xc0ff mem 0xfe8ff800-0xfe8ff8ff,0xfe8fe000-0xfe8fefff irq 16 at device 8.0 on pci1 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: [ITHREAD] sym1: <875> port 0xb000-0xb0ff mem 0xfe8ff000-0xfe8ff0ff,0xfe8fd000-0xfe8fdfff irq 17 at device 8.1 on pci1 sym1: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: [ITHREAD] puc0: port 0xcc00-0xcc07,0xc880-0xc887,0xc800-0xc807,0xbc00-0xbc07,0xb880-0xb8bf irq 17 at device 9.0 on pci1 puc0: [FILTER] uart2: <16550 or compatible> on puc0 uart2: [FILTER] uart3: <16550 or compatible> on puc0 uart3: [FILTER] uart4: <16550 or compatible> on puc0 uart4: [FILTER] uart5: <16550 or compatible> on puc0 uart5: [FILTER] uart6: <16550 or compatible> on puc0 uart6: [FILTER] uart7: <16550 or compatible> on puc0 uart7: [FILTER] uart8: <16550 or compatible> on puc0 uart8: [FILTER] uart9: <16550 or compatible> on puc0 uart9: [FILTER] vgapci0: mem 0xfe8f8000-0xfe8fbfff,0xfc800000-0xfcffffff irq 18 at device 10.0 on pci1 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 9.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xf80-0xf87,0xf00-0xf03,0xe80-0xe87,0xe00-0xe03,0x9800-0x980f mem 0xfdffc000-0xfdffdfff irq 20 at device 10.0 on pci0 atapci1: [ITHREAD] atapci1: AHCI v1.10 controller with 4 3Gbps ports, PM supported ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 re0: port 0xd800-0xd8ff mem 0xfe9ff000-0xfe9fffff irq 19 at device 0.0 on pci3 re0: Using 1 MSI message re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:1d:92:89:9f:a3 re0: [ITHREAD] pcib4: at device 13.0 on pci0 pci4: on pcib4 pcib5: at device 14.0 on pci0 pci5: on pcib5 pcib6: mem 0xfeafe000-0xfeafffff irq 16 at device 0.0 on pci5 pci6: on pcib6 ahd0: port 0xe800-0xe8ff,0xe400-0xe4ff mem 0xfebfe000-0xfebfffff irq 16 at device 4.0 on pci6 ahd0: [ITHREAD] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133MHz, 512 SCBs acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 acpi_hpet0: iomem 0xfed00000-0xfed00fff irq 0,8 on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 atrtc0: port 0x70-0x71 on acpi0 orm0: at iomem 0xc0000-0xc7fff,0xd1000-0xd17ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) powernow0: on cpu0 powernow1: on cpu1 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 acd0: DVDR at ata0-master UDMA66 ad4: 152627MB at ata2-master UDMA100 SATA 3Gb/s hdac0: HDA Codec #0: Realtek ALC888 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 uhub0: 10 ports with 10 removable, self powered uhub1: 10 ports with 10 removable, self powered ugen1.2: at usbus1 uhub2: on usbus1 da1 at ahd0 bus 0 scbus0 target 4 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz DT, offset 63, 16bit) da1: Command Queueing enabled da1: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) da0 at ahd0 bus 0 scbus0 target 2 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit) da0: Command Queueing enabled da0: 35003MB (71687370 512 byte sectors: 255H 63S/T 4462C) SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 scbus3 target 0 lun 0 cd0: b 2R:e m4o vpaobrltes CwDi-tRhO M4 SrCeSmIo-v0a bdleev,i csee l fc dp0o:w e6r6e.d00 0MB/s transfers cd0: cd present [345505 x 2048 byte records] ugen0.2: at usbus0 uhub3: on usbus0 uhub3: 4 ports with 4 removable, self powered ugen0.3: at usbus0 ukbd0: on usbus0 kbd1 at ukbd0 ugen0.4: at usbus0 ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=0 ugen0.5: at usbus0 uhub4: on usbus0 uhub4: 4 ports with 4 removable, self powered ugen0.6: at usbus0 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 5 45 a0 0 0 1 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 20 0 0 4 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 4 0 0 4 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 4 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 80 0 0 4 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 20 0 0 4 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 4 0 0 4 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 4 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 80 0 0 4 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 10 0 0 1 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 4 0 0 1 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 20 0 0 1 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata0:0:0:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:64,0 (Illegal mode for this track) (cd0:ata0:0:0:0): cddone: got error 0x6 back Trying to mount root from ufs:/dev/gvinum/root -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-net@FreeBSD.ORG Fri May 27 08:51: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 0B4D0106564A for ; Fri, 27 May 2011 08:51:43 +0000 (UTC) (envelope-from zhanglinuxstar@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id BC9338FC0C for ; Fri, 27 May 2011 08:51:42 +0000 (UTC) Received: by yie12 with SMTP id 12so800997yie.13 for ; Fri, 27 May 2011 01:51:42 -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=QN+K+P0ZVvwuvyEm22MfOlTADCVLg3AQqOBGRwf6VsA=; b=ver490W0Ovp5mILO9YM0pFJ8PCGHpV4MXcbf+DzU02TPgiTiwaIipxRhD0xTQwiB6r qdF/egA2EkH4UhpxbGFw7tAqlkB4UVxrZ81HPwn6XiT+c2eNM0MgEbDFfsyE/bW8nzZV Tzk0oSmJwN+tIZGnldw/7q++lWvWrf9lx5/pU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fZ+kSBjve70fxXLQMwk+lrncqa7OyI0trg60a95dJPT0xOnDQGHqswSZvHDgDqVV0C 9Fm0ZXJf0XnfwThYHUI6WSMmd6WbBClpYLGYIQzWvt8qHRey4bj2r2hl0Vxq5iv5vtrQ gAzX0MBoylAApNTci9RSMFnMeJ3+LCkdl0A+s= MIME-Version: 1.0 Received: by 10.150.13.15 with SMTP id 15mr1811475ybm.103.1306484795594; Fri, 27 May 2011 01:26:35 -0700 (PDT) Received: by 10.151.50.21 with HTTP; Fri, 27 May 2011 01:26:35 -0700 (PDT) Date: Fri, 27 May 2011 16:26:35 +0800 Message-ID: From: linux JHON To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [HELP] sendto:No buffer space available 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, 27 May 2011 08:51:43 -0000 My machine has two net interface cards, fxp0 and acl0, but acl0 is down, only fxp0 is working. When I send raw packets through fxp0, it gives the error: sendto: No buffer space available. I have googled, but I found no answer. The netstat -m result is: 67/1223/1290 mbufs in use (current/cache/total) 64/340/404/25600 mbuf clusters in use (current/cache/total/max) 64/320 mbuf+clusters out of packet secondary zone in use (current/cache) 0/167/167/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 144K/1653K/1798K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/5/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines And the ifconfig gives that: alc0: flags=8802 metric 0 mtu 1500 options=c3198 ether xxxxxxxxxxxx media: Ethernet autoselect fxp0: flags=8843 metric 0 mtu 1500 options=4219b ether xxxxxxxxxxx inet xxxxxx netmask 0xffffff00 broadcast xxxxxxxx media: Ethernet autoselect (100baseTX ) status: active plip0: flags=8851 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3 The core code of sending packets is as follows: while (num_of_tries-- > 0) { if (sendto (s, datagram, iph->ip_len, 0, (struct sockaddr *) &servaddr, sizeof (servaddr)) < 0) { fprintf (stderr, "Error in sendto:%s\n", strerror(errno)); exit (1); } else { /*usleep(30);*/ if (ft == 0) { fprintf (stderr, "[****************]\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); ft = 1; } if ((numtries % modval) == 0) fprintf (stderr, "."); } } When I uncomment the sentence: usleep(30), the error disapears. But I want to send packets in high speed, what should I do? Btw, the packets are raw packets. So I thought maybe the kernel send some packets to the net interface card alc0 which doesn't work. How can I bind raw socket with device fxp0???? Thanks in advance. From owner-freebsd-net@FreeBSD.ORG Fri May 27 11:30:10 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 232F81065670 for ; Fri, 27 May 2011 11:30:10 +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 075828FC17 for ; Fri, 27 May 2011 11:30:10 +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 p4RBU9WF000398 for ; Fri, 27 May 2011 11:30:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4RBU9Xv000393; Fri, 27 May 2011 11:30:09 GMT (envelope-from gnats) Date: Fri, 27 May 2011 11:30:09 GMT Message-Id: <201105271130.p4RBU9Xv000393@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 11:30:10 -0000 The following reply was made to PR kern/157287; it has been noted by GNATS. From: Gleb Smirnoff To: Joerg Wunsch Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/157287: re0: INVARIANTS panic (Memory modified after free) Date: Fri, 27 May 2011 15:22:24 +0400 On Thu, May 26, 2011 at 05:54:24PM +0200, Joerg Wunsch wrote: J> As it turns out this might be related to something else that has been J> using that piece of memory before re(4) is activated, here are the J> boot messages for reference. You can try to add 'options DEBUG_MEMGUARD' to your kernel config, and add the 'vm.memguard.desc=devbuf' to your /boot/loader.conf. This may help to find place where memory is tampered after free. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri May 27 12:02:38 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 B18DB106568D for ; Fri, 27 May 2011 12:02:38 +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 723598FC29 for ; Fri, 27 May 2011 12:02:38 +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 0A90F46B2D; Fri, 27 May 2011 08:02:38 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A009D8A050; Fri, 27 May 2011 08:02:37 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Fri, 27 May 2011 07:45:19 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; 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: <201105270745.19869.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 27 May 2011 08:02:37 -0400 (EDT) Cc: linux JHON Subject: Re: [HELP] sendto:No buffer space available 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, 27 May 2011 12:02:38 -0000 On Friday, May 27, 2011 4:26:35 am linux JHON wrote: > My machine has two net interface cards, fxp0 and acl0, but acl0 is down, > only fxp0 is working. > > When I send raw packets through fxp0, it gives the error: sendto: No buffer > space available. > > I have googled, but I found no answer. The netstat -m result is: > > 67/1223/1290 mbufs in use (current/cache/total) > 64/340/404/25600 mbuf clusters in use (current/cache/total/max) > 64/320 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/167/167/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 144K/1653K/1798K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/5/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > And the ifconfig gives that: > > alc0: flags=8802 metric 0 mtu 1500 > > options=c3198 > ether xxxxxxxxxxxx > media: Ethernet autoselect > fxp0: flags=8843 metric 0 mtu 1500 > > options=4219b > ether xxxxxxxxxxx > inet xxxxxx netmask 0xffffff00 broadcast xxxxxxxx > media: Ethernet autoselect (100baseTX ) > status: active > plip0: flags=8851 metric 0 mtu > 1500 > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3 > > The core code of sending packets is as follows: > > while (num_of_tries-- > 0) > { > if (sendto > (s, datagram, iph->ip_len, 0, (struct sockaddr *) &servaddr, > sizeof (servaddr)) < 0) > { > fprintf (stderr, "Error in sendto:%s\n", strerror(errno)); > exit (1); > } > else > { > /*usleep(30);*/ > if (ft == 0) > { > fprintf (stderr, > > "[****************]\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); > ft = 1; > } > > if ((numtries % modval) == 0) > fprintf (stderr, "."); > > } > } > > When I uncomment the sentence: usleep(30), the error disapears. But I want > to send packets in high speed, what should I do? > > Btw, the packets are raw packets. So I thought maybe the kernel send some > packets to the net interface card alc0 which doesn't work. No, it is sending them all to fxp0, you are just giving it packets faster than it can transmit them. fxp is just a 10/100 device and a system with a modern CPU running your program should be able to swamp a 100mbits line rather easily. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri May 27 15:16:42 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 CF697106564A for ; Fri, 27 May 2011 15:16:42 +0000 (UTC) (envelope-from fsb@thefsb.org) Received: from smtp181.iad.emailsrvr.com (smtp181.iad.emailsrvr.com [207.97.245.181]) by mx1.freebsd.org (Postfix) with ESMTP id A82A18FC0C for ; Fri, 27 May 2011 15:16:42 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp48.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2E97C16838B for ; Fri, 27 May 2011 11:00:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp48.relay.iad1a.emailsrvr.com (Authenticated sender: fsb-AT-thefsb.org) with ESMTPSA id 304AB168861 for ; Fri, 27 May 2011 11:00:02 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 27 May 2011 10:59:59 -0400 From: Tom Worster To: Message-ID: Thread-Topic: Can net.inet.tcp.msl be set per interface? Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Can net.inet.tcp.msl be set per interface? 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, 27 May 2011 15:16:42 -0000 [[I asked this yesterday on -questions, probably the wrong list]] If a server has one interface to the Internet and another interface to a switch connecting to a few other servers, it seems TCP's MSL value might reasonably be set a lot lower on the private interface. I'm specifically thinking of a lot of short MySQL connections(*) between the servers on the private LAN. The average number of MySQL client connections in TIME_WAIT will be proportional to MSL. And, while the circumstances under which a long MSL would help anything are unimaginable on the LAN, they are not on the Internet. So can net.inet.tcp.msl be set per interface? (*) Or similar: Sphinx, memcached, perhaps. Tom From owner-freebsd-net@FreeBSD.ORG Sat May 28 00:30:42 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 DF6E3106564A; Sat, 28 May 2011 00:30:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id A8B378FC0A; Sat, 28 May 2011 00:30:42 +0000 (UTC) Received: by pvg11 with SMTP id 11so1246553pvg.13 for ; Fri, 27 May 2011 17:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=Gh1uGZTAG1DZpna/KsODrhc8ed83AVxR+oSvgNOWZnA=; b=XTog5OeYAvBaexSFhqAvNdmfkLNLRVtz/77u3BcG9wv1Si5k5qfiAm3bgAfnUL6NYq 5+9CDnEeSMdvXTD+Etuwq4AimivbJDB3py+AQwrmWxL+8k9xLYEi7Ow77uEoz114w5RP 7xxA2a1+FLq2aaJhW1z5cxwFj/O46A5jIok+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=raHww+BhrskDqQdesdpDNySFlkwjuP+NvxqPZCXkXY/0Qm5SvlVgs9+uFeCkQ2gdQL HfXUbRRP/oned+6uP+lP9lFCfJToabMnEeJBnlI1NdQaGy3NupawHQrn6ipnXqwuySNT y9Olhx2XAv4n9FgjnjT9AjPL5QalqnpZm3HOM= Received: by 10.68.14.102 with SMTP id o6mr1101528pbc.124.1306542642136; Fri, 27 May 2011 17:30:42 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n4sm890662pbj.8.2011.05.27.17.30.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2011 17:30:40 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 27 May 2011 17:30:40 -0700 From: YongHyeon PYUN Date: Fri, 27 May 2011 17:30:40 -0700 To: vanatubo@googlemail.com Message-ID: <20110528003040.GD22519@michelle.cdnetworks.com> References: <201105162024.p4GKOUjs086039@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105162024.p4GKOUjs086039@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, bug-followup@FreeBSD.org Subject: Re: kern/155636: [msk] msk driver locks marvel yukon 88E8057 NIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 00:30:43 -0000 On Mon, May 16, 2011 at 08:24:30PM +0000, yongari@freebsd.org wrote: > Synopsis: [msk] msk driver locks marvel yukon 88E8057 NIC > > State-Changed-From-To: open->feedback > State-Changed-By: yongari > State-Changed-When: Mon May 16 20:22:12 UTC 2011 > State-Changed-Why: > Would you show me dmesg output to identify which controller you have? > If you have Yukon Ultra2(88E8057 I guess), could you try patch at the > following URL? Let me know whether it makes any difference for you. > http://people.freebsd.org/~yongari/msk/msk.ultra2.diff > I've uploaded updated msk(4) at the following URL. http://people.freebsd.org/~yongari/msk/8.2R/if_msk.c http://people.freebsd.org/~yongari/msk/8.2R/if_mskreg.h Download two files above and rebuild msk(4) on 8.2-RELEASE. > > Responsible-Changed-From-To: freebsd-net->yongari > Responsible-Changed-By: yongari > Responsible-Changed-When: Mon May 16 20:22:12 UTC 2011 > Responsible-Changed-Why: > Grab. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=155636 From owner-freebsd-net@FreeBSD.ORG Sat May 28 13:10:01 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 44A31106564A for ; Sat, 28 May 2011 13:10:01 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E9A308FC14 for ; Sat, 28 May 2011 13:10:00 +0000 (UTC) Received: by vws18 with SMTP id 18so2642477vws.13 for ; Sat, 28 May 2011 06:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=P5ABuQJe0/XrDz4kOAHWJaTnQxV2JR6tszfEwQZX7HQ=; b=Cw2rUtFLa3E7horxpIOCqXGjGAiFc6TCaBm31YihdvPlApRq1a/DD9EtgxLOvchluu EPGkaTG/XlVuarY6dfMREED053W4L8KJft0D3RDbrcA349VmdO1gGygt2T36kjhukBMc oP/Cp3h3mio21fJl3MTv0JS16o5pIXtSyJYwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=nQn4eWLIvDBmRWVbx9KPmAu3YWd1BssGC6RH8PBch0nWg13f/kA7K/HcpUqDHJz7q1 UcKMZJoLmZc7UykUdlzt1esukGxsv49DdRAW3cJbWU+Cv1Fj/eyDK2G3Lh92zI72WKK5 X/9pqKY+oj1PikrIgIjRyzJcstIMTCkWiVsBw= MIME-Version: 1.0 Received: by 10.52.99.106 with SMTP id ep10mr4430529vdb.46.1306588200027; Sat, 28 May 2011 06:10:00 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.186.67 with HTTP; Sat, 28 May 2011 06:09:59 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 May 2011 15:09:59 +0200 X-Google-Sender-Auth: NGRLnxT78J33EZ4qGZ2357Vy5Rw Message-ID: From: "K. Macy" To: Tom Worster Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Can net.inet.tcp.msl be set per interface? 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, 28 May 2011 13:10:01 -0000 Unfortunately msl is a global variable: tcp_timer.c: int tcp_msl; SYSCTL_PROC(_net_inet_tcp, OID_AUTO, msl, CTLTYPE_INT|CTLFLAG_RW, &tcp_msl, 0, sysctl_msec_to_ticks, "I", "Maximum segment lifetime"); Sockets or rather inpcbs in timewait are maintained on a per-vnet list. Since tcp_twstart is called from tcp_do_segment in tcp_input.c it does actually have access to the mbuf triggering the state transition and thus the receiving interface. As far as I can tell, changing the behavior to what you're asking for would not be difficult. Cheers, Kip On Fri, May 27, 2011 at 4:59 PM, Tom Worster wrote: > [[I asked this yesterday on -questions, probably the wrong list]] > > If a server has one interface to the Internet and another interface to a > switch connecting to a few other servers, it seems TCP's MSL value might > reasonably be set a lot lower on the private interface. > > I'm specifically thinking of a lot of short MySQL connections(*) between > the > servers on the private LAN. The average number of MySQL client connections > in TIME_WAIT will be proportional to MSL. And, while the circumstances > under which a long MSL would help anything are unimaginable on the LAN, > they are not on the Internet. > > So can net.inet.tcp.msl be set per interface? > > (*) Or similar: Sphinx, memcached, perhaps. > > Tom > > > > _______________________________________________ > 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 Sat May 28 13:29:09 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 E0D35106566B for ; Sat, 28 May 2011 13:29:09 +0000 (UTC) (envelope-from fsb@thefsb.org) Received: from smtp191.iad.emailsrvr.com (smtp191.iad.emailsrvr.com [207.97.245.191]) by mx1.freebsd.org (Postfix) with ESMTP id B62DF8FC14 for ; Sat, 28 May 2011 13:29:09 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp29.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id F00DC14825C; Sat, 28 May 2011 09:29:08 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp29.relay.iad1a.emailsrvr.com (Authenticated sender: fsb-AT-thefsb.org) with ESMTPSA id 4C15B14822C; Sat, 28 May 2011 09:29:07 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Sat, 28 May 2011 09:29:03 -0400 From: Tom Worster To: "K. Macy" Message-ID: Thread-Topic: Can net.inet.tcp.msl be set per interface? In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Can net.inet.tcp.msl be set per interface? 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, 28 May 2011 13:29:10 -0000 Thanks, Kip, good to know. I partly understand what you said, especially the last sentence, which I rather like. As a next step I should ask the TCP cognoscenti if this kind of tuning is as wise as I imagine. Tom On 5/28/11 9:09 AM, "K. Macy" wrote: >Unfortunately msl is a global variable: > >tcp_timer.c: > >int tcp_msl; >SYSCTL_PROC(_net_inet_tcp, OID_AUTO, msl, CTLTYPE_INT|CTLFLAG_RW, > &tcp_msl, 0, sysctl_msec_to_ticks, "I", "Maximum segment lifetime"); > > >Sockets or rather inpcbs in timewait are maintained on a per-vnet >list. Since tcp_twstart is called from tcp_do_segment in tcp_input.c >it does actually have access to the mbuf triggering the state >transition and thus the receiving interface. As far as I can tell, >changing the behavior to what you're asking for would not be >difficult. > > >Cheers, >Kip > >On Fri, May 27, 2011 at 4:59 PM, Tom Worster wrote: >> [[I asked this yesterday on -questions, probably the wrong list]] >> >> If a server has one interface to the Internet and another interface to a >> switch connecting to a few other servers, it seems TCP's MSL value might >> reasonably be set a lot lower on the private interface. >> >> I'm specifically thinking of a lot of short MySQL connections(*) between >> the >> servers on the private LAN. The average number of MySQL client >>connections >> in TIME_WAIT will be proportional to MSL. And, while the circumstances >> under which a long MSL would help anything are unimaginable on the LAN, >> they are not on the Internet. >> >> So can net.inet.tcp.msl be set per interface? >> >> (*) Or similar: Sphinx, memcached, perhaps. >> >> Tom >> >> >> >> _______________________________________________ >> 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" >>