From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 01:38:19 2008 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 B7DFF1065676 for ; Sun, 24 Aug 2008 01:38:19 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (mail.inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 334F98FC0A for ; Sun, 24 Aug 2008 01:38:19 +0000 (UTC) (envelope-from rik@inse.ru) Received: from www.inse.ru (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTPSA id A6F9733C57; Sun, 24 Aug 2008 05:38:17 +0400 (MSD) Message-ID: <48B0B813.8010606@localhost.inse.ru> Date: Sun, 24 Aug 2008 05:23:31 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Max Laier References: <48B07DC5.2030203@localhost.inse.ru> <20080823231407.GA76471@onelab2.iet.unipi.it> <48B09ACD.1050600@localhost.inse.ru> <200808240149.56698.max@love2party.net> In-Reply-To: <200808240149.56698.max@love2party.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Luigi Rizzo Subject: Re: [Fwd: IPFW PATCH: make the IPFW_DEFUALT_RULE number constant non private] 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, 24 Aug 2008 01:38:19 -0000 Max Laier wrote: > On Sunday 24 August 2008 01:18:37 Roman Kurakin wrote: > >> Luigi Rizzo wrote: >> >>> On Sun, Aug 24, 2008 at 02:03:50AM +0400, Roman Kurakin wrote: >>> ... >>> >>> >>>>> unless the tools you have in mind already include ip_fw.h (in which >>>>> case the change is harmless and I have no objection), i think it would >>>>> be better to export the value in a sysctl and let the tools fetch it >>>>> from there, so they do not need to include the header. >>>>> >>>> In fact, I am talking about ipfw(8) and natd(8). The first one uses >>>> hard-coded value, the last one >>>> pass rulenumbers to libalias(3) without a check, libalias(3) flushes >>>> >>> ... >>> >>> >>>> IIRC the natd(8) doesn't include ip_fw.h, but I do not see why it would >>>> be better to export >>>> this value via sysctl, not compiled in via #include<> for it. The only >>>> >>> because ip_fw.h has a lot of stuff in it which in turn is likely >>> to require more headers to build correctly. This is unnecessary bloat >>> at compile time, and also less practical than the sysctl-based approach >>> because it requires a binary update if the value ever changes. >>> >>> Besides, implementing the sysctl does not require to change the >>> headers (thus saving rebuilds of the objects that depend on it), >>> is one line in one file (ip_fw2.c) in the kernel, and one line to >>> call sysctlbyname() in each of the userland program, which you'd >>> need to change anyways; and because both ipfw(8) and natd(8) already >>> use sysctl/sysctlbyname to read/write other similar values from the >>> kernel, you are more consistent with the existing code and don't >>> even need additional headers. >>> >> Agreed, but including ip_fw.h for natd.c does not require any additional >> headers. >> All that needed looks like already there. >> If some one point me to other utilities that need to be fixed I'll also >> a sysctl for them. >> These two already include enough of netinet includes, so if you not >> strictly against adding >> just one more include for natd, I'll prefer not to add a sysctl by right >> now. >> > > There is no guarantee that the kernel or ipfw module you are running was built > with the installed ip_fw.h or that IPFW_DEFAULT_RULE wasn't defined > differently in the build environment. So a sysctl (or the like) is the *only* > Very strange situation. In such case we have a very buggy code that could be broken by such cases in many places, cause we can't trust even kernel headers. But if you insist I'll do it via sysctl. > correct approach. Please fix it for real and don't just slap band-aid at it. > Nice catch, by the way! > It is bad luck. I always hit problems than I lack of time setting up smth. All problems where they are not expected I mine ;-) Now time to sleep until I didn't catch other problems :-))) rik >> rik >> >> >>> At runtime the sysctl is obviously more expensive than reading a >>> hardwired constant, but still a whole lot cheaper than the subsequent >>> action (adding a rule to the firewall) so one won't notice. >>> >>> cheers >>> luigi >>> _______________________________________________ >>> 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" >>> >> _______________________________________________ >> 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 Sun Aug 24 02:16:08 2008 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 D8B361065673 for ; Sun, 24 Aug 2008 02:16:08 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id B07E98FC19 for ; Sun, 24 Aug 2008 02:16:08 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1794744rvf.43 for ; Sat, 23 Aug 2008 19:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=CU0bhbHhOBt0tMbjhf8rxTwvm9/WREWI5Ab3c9SIQek=; b=KtEmHxZarlfqLDs35sFptPXwF/zjaZwd18EnFqPpXpDmyfMbHt8TpYztGzivEHqcJN Lh1JrAU9NT7KfX9MjSN6lWVfvNBuvSC254kFMISvVjnZ4bOLr1e7KdOJTRKuWBkGUH36 tyIwdBYoAOkMnQuK847aV6Qjiwb6EBvfNqT2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=gWkwXAJH8ckI4Wqbndg0SMFPkl4bdzK7ZCTazkhCZNTMtFUpQShOSJxQhyn8++h32D D+p6cdPLu1oTozJ12djA7tDy+RDbYcHux8rkLSlnswHb18mp0cdN9QZ6iBXTYrY9KSs1 RilHgZzm20TfACoVsiUu1lubUIwqWVnAqZzp8= Received: by 10.141.171.6 with SMTP id y6mr1373206rvo.143.1219544168238; Sat, 23 Aug 2008 19:16:08 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Sat, 23 Aug 2008 19:16:08 -0700 (PDT) Message-ID: <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> Date: Sat, 23 Aug 2008 19:16:08 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Mike Tancsa" In-Reply-To: <200808221922.m7MJMcUN091064@lava.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> X-Google-Sender-Auth: 28ddd8c6630e17db Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 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, 24 Aug 2008 02:16:08 -0000 Can you help me out a bit with your workload? tcp_offload_connect(...) needs to determine which interface an address corresponds to see if that interface supports TCP offload. The code does the exact same thing as ip_output does except it doesn't have the inpcb locked (which isn't used as part of the route lookup). Julian has worked in this code most recently, maybe he has some idea what is going on. -Kip On Fri, Aug 22, 2008 at 12:22 PM, Mike Tancsa wrote: > At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: > >> can you make sure you have this? >> >> http://svn.freebsd.org/changeset/base/181596 > > Hi, > I do. I am running a GENERIC kernel but with inet6 disabled from yesterday > > 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 > > and with the patch below as TOE seems to be broken for my workload > > > # diff -u sys/netinet/tcp_offload.c sys/netinet/tcp_offload.c.disable > --- sys/netinet/tcp_offload.c 2008-08-01 13:47:27.000000000 -0400 > +++ sys/netinet/tcp_offload.c.disable 2008-08-22 15:16:50.000000000 -0400 > @@ -58,6 +58,8 @@ > struct rtentry *rt; > int error; > > + return (EINVAL); > + > /* > * Look up the route used for the connection to > * determine if it uses an interface capable of > > I can try changing to ipfw and see if that makes a difference ? But the RST > doesnt sound like a pf issue no ? I would have thought it would just > blackhole the packet. > > ---Mike > _______________________________________________ > 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 Sun Aug 24 02:20:16 2008 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 5FE8B106566B; Sun, 24 Aug 2008 02:20:16 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 26DBF8FC08; Sun, 24 Aug 2008 02:20:16 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7O2KDr7001582; Sat, 23 Aug 2008 22:20:13 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7O2KDHA097983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Aug 2008 22:20:13 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808240220.m7O2KDHA097983@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 23 Aug 2008 22:20:17 -0400 To: "Kip Macy" From: Mike Tancsa In-Reply-To: <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.co m> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 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, 24 Aug 2008 02:20:16 -0000 At 10:16 PM 8/23/2008, Kip Macy wrote: >Can you help me out a bit with your workload? Hi, A lot of incoming tcp connections on em0,em1,lo0 for smtp connections. A lot of inbound and outbound udp connections for local DNS for the box and its neighbours on em0,em1 and a lot of tcp connections for clamav on em1 The problem quickly manifests itself so its pretty easy to see ---Mike From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 03:12:38 2008 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 6DDAD106575D; Sun, 24 Aug 2008 03:12:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 20CD88FC12; Sun, 24 Aug 2008 03:12:37 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7O3Cahp004191; Sat, 23 Aug 2008 23:12:36 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7O3CZS0098145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Aug 2008 23:12:35 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808240312.m7O3CZS0098145@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 23 Aug 2008 23:12:39 -0400 To: "Kip Macy" From: Mike Tancsa In-Reply-To: <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.co m> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 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, 24 Aug 2008 03:12:38 -0000 At 10:16 PM 8/23/2008, Kip Macy wrote: >Can you help me out a bit with your workload? > >tcp_offload_connect(...) needs to determine which interface an address >corresponds to see if that interface supports TCP offload. The code >does the exact same thing as ip_output does except it doesn't have the >inpcb locked (which isn't used as part of the route lookup). This is the only RELENG_7 box that I have where it routes tcp packets asymmetrically, so that sounds like it might be the portion that is badly interacting. The server has just one default gateway, which is out em0, but clients all over the net will connect to IP addresses aliased on lo0 and to the one IP on em1. But all connections exit out em0 other than connected routes of course. ---Mike >Julian has worked in this code most recently, maybe he has some idea >what is going on. > >-Kip > > >On Fri, Aug 22, 2008 at 12:22 PM, Mike Tancsa wrote: > > At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: > > > >> can you make sure you have this? > >> > >> http://svn.freebsd.org/changeset/base/181596 > > > > Hi, > > I do. I am running a GENERIC kernel but with inet6 disabled from yesterday > > > > 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 > > > > and with the patch below as TOE seems to be broken for my workload > > > > > > # diff -u sys/netinet/tcp_offload.c sys/netinet/tcp_offload.c.disable > > --- sys/netinet/tcp_offload.c 2008-08-01 13:47:27.000000000 -0400 > > +++ sys/netinet/tcp_offload.c.disable 2008-08-22 15:16:50.000000000 -0400 > > @@ -58,6 +58,8 @@ > > struct rtentry *rt; > > int error; > > > > + return (EINVAL); > > + > > /* > > * Look up the route used for the connection to > > * determine if it uses an interface capable of > > > > I can try changing to ipfw and see if that makes a difference ? But the RST > > doesnt sound like a pf issue no ? I would have thought it would just > > blackhole the packet. > > > > ---Mike > > _______________________________________________ > > 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 Sun Aug 24 05:38:41 2008 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 E1720106566B for ; Sun, 24 Aug 2008 05:38:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id CAE1E8FC14 for ; Sun, 24 Aug 2008 05:38:41 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 1529E2374; Sat, 23 Aug 2008 22:38:42 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D90442D6092; Sat, 23 Aug 2008 22:38:40 -0700 (PDT) Message-ID: <48B0F3E0.5080003@elischer.org> Date: Sat, 23 Aug 2008 22:38:40 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Joe Mays References: <000501c9054d$cb43ab00$441818d8@launchpad02> In-Reply-To: <000501c9054d$cb43ab00$441818d8@launchpad02> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Fw: Kernel Panic in SCTP 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, 24 Aug 2008 05:38:42 -0000 Joe Mays wrote: > Just thought I'd put this out there again. Is there anyone who was > involved in the SCTP installation on list? yes, rrs@freebsd.org is but I think he's "away" for a while. > >> Hello. >> >> We've recently written an extensive software system that uses SCTP > as a >> critical component. We've started to run into an issue where the box > kenel >> panics after throwing an error message from sctp_timer.c that says > "Our list >> is out of order? Out of order list". Can anyone here shed light on > what's >> going on, or give us a clue how to debug this? >> >> http://fxr.watson.org/fxr/source/netinet/sctp_timer.c#L645 > > Joe Mays > > _______________________________________________ > 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 Sun Aug 24 05:52:35 2008 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 68E93106564A for ; Sun, 24 Aug 2008 05:52:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0EE8FC13 for ; Sun, 24 Aug 2008 05:52:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 85A4C2379; Sat, 23 Aug 2008 22:52:35 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 877F72D604B; Sat, 23 Aug 2008 22:52:34 -0700 (PDT) Message-ID: <48B0F722.3050005@elischer.org> Date: Sat, 23 Aug 2008 22:52:34 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Mike Tancsa References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> In-Reply-To: <200808240312.m7O3CZS0098145@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , Kip Macy , freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 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, 24 Aug 2008 05:52:35 -0000 Mike Tancsa wrote: > At 10:16 PM 8/23/2008, Kip Macy wrote: >> Can you help me out a bit with your workload? >> >> tcp_offload_connect(...) needs to determine which interface an address >> corresponds to see if that interface supports TCP offload. The code >> does the exact same thing as ip_output does except it doesn't have the >> inpcb locked (which isn't used as part of the route lookup). > > This is the only RELENG_7 box that I have where it routes tcp packets > asymmetrically, so that sounds like it might be the portion that is > badly interacting. The server has just one default gateway, which is out > em0, but clients all over the net will connect to IP addresses aliased > on lo0 and to the one IP on em1. But all connections exit out em0 other > than connected routes of course. > > ---Mike > >> Julian has worked in this code most recently, maybe he has some idea >> what is going on. >> huh? wha? I haven't been following this thread.. what's up? >> -Kip >> >> >> On Fri, Aug 22, 2008 at 12:22 PM, Mike Tancsa wrote: >> > At 03:12 PM 8/22/2008, Bjoern A. Zeeb wrote: >> > >> >> can you make sure you have this? >> >> >> >> http://svn.freebsd.org/changeset/base/181596 >> > >> > Hi, >> > I do. I am running a GENERIC kernel but with inet6 disabled from >> yesterday >> > >> > 7.0-STABLE #0: Thu Aug 21 10:27:04 EDT 2008 >> > >> > and with the patch below as TOE seems to be broken for my workload >> > >> > >> > # diff -u sys/netinet/tcp_offload.c sys/netinet/tcp_offload.c.disable >> > --- sys/netinet/tcp_offload.c 2008-08-01 13:47:27.000000000 -0400 >> > +++ sys/netinet/tcp_offload.c.disable 2008-08-22 >> 15:16:50.000000000 -0400 >> > @@ -58,6 +58,8 @@ >> > struct rtentry *rt; >> > int error; >> > >> > + return (EINVAL); >> > + >> > /* >> > * Look up the route used for the connection to >> > * determine if it uses an interface capable of >> > >> > I can try changing to ipfw and see if that makes a difference ? But >> the RST >> > doesnt sound like a pf issue no ? I would have thought it would just >> > blackhole the packet. >> > >> > ---Mike >> > _______________________________________________ >> > 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" >> > > > _______________________________________________ > 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 Sun Aug 24 05:55:48 2008 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 3F9761065681 for ; Sun, 24 Aug 2008 05:55:48 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2D68FC3A for ; Sun, 24 Aug 2008 05:55:47 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1859967rvf.43 for ; Sat, 23 Aug 2008 22:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=xKTWfneHZ2P/qlVKwKkepEXVqxGO3YQOVdlElPO+pxY=; b=G9NcXSnYwe0C3yGbqFiPmccupmWnGRP3+x5K6GeLKgBh9kzZw0BLo57WTU/votPIeP ckUpEy4V5Y1Fps3S4MEHuOvV2q4cKRLrjNyRCZnr2Oe5hNTvQBVfdbW8fy9uq6RYeU4W ufbzSJDRnL2R9wS6j73ZFkQIeE3fPjE45gSe8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Aun0fTIkEwfYCnwpoTzIwGnfjiQ+PXrbrXlt8h4eHm7zjYyoH57mGSmXMTsBUAl+wx wfT+a0xcdBaftIopQ8ddruLgnNp3Gn3cOAsl9Js0WaGSRxUjUq5qTw1e8VRP+OtbkVDI V/tfssTWZuB7Ya7g3mWtzF0zl443RZDGmSG/Q= Received: by 10.141.49.6 with SMTP id b6mr1439908rvk.89.1219557347164; Sat, 23 Aug 2008 22:55:47 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Sat, 23 Aug 2008 22:55:47 -0700 (PDT) Message-ID: <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> Date: Sat, 23 Aug 2008 22:55:47 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Julian Elischer" In-Reply-To: <48B0F722.3050005@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> X-Google-Sender-Auth: 2fc70bd142617819 Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org, Mike Tancsa Subject: Re: strange TCP issue on RELENG_7 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, 24 Aug 2008 05:55:48 -0000 On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer wrote: > Mike Tancsa wrote: >> >> At 10:16 PM 8/23/2008, Kip Macy wrote: >>> >>> Can you help me out a bit with your workload? >>> >>> tcp_offload_connect(...) needs to determine which interface an address >>> corresponds to see if that interface supports TCP offload. The code >>> does the exact same thing as ip_output does except it doesn't have the >>> inpcb locked (which isn't used as part of the route lookup). >> >> This is the only RELENG_7 box that I have where it routes tcp packets >> asymmetrically, so that sounds like it might be the portion that is badly >> interacting. The server has just one default gateway, which is out em0, but >> clients all over the net will connect to IP addresses aliased on lo0 and to >> the one IP on em1. But all connections exit out em0 other than connected >> routes of course. >> >> ---Mike >> >>> Julian has worked in this code most recently, maybe he has some idea >>> what is going on. >>> > > huh? wha? I haven't been following this thread.. what's up? > Julian - see previous e-mails, the arp cache gets messed up as a result of calling rtalloc in tcp_offload.c - which is done to determine which interface will be used for connection. Any thoughts on why it may end up with dozens of bogus entries? -Kip From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 05:59:11 2008 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 2254C106567E for ; Sun, 24 Aug 2008 05:59:11 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 041138FC19 for ; Sun, 24 Aug 2008 05:59:10 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A6AEE2478; Sat, 23 Aug 2008 22:59:11 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3B60D2D60BF; Sat, 23 Aug 2008 22:59:10 -0700 (PDT) Message-ID: <48B0F8AD.1090601@elischer.org> Date: Sat, 23 Aug 2008 22:59:09 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Kip Macy References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> In-Reply-To: <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org, Mike Tancsa Subject: Re: strange TCP issue on RELENG_7 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, 24 Aug 2008 05:59:11 -0000 Kip Macy wrote: > On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer wrote: >> Mike Tancsa wrote: >>> At 10:16 PM 8/23/2008, Kip Macy wrote: >>>> Can you help me out a bit with your workload? >>>> >>>> tcp_offload_connect(...) needs to determine which interface an address >>>> corresponds to see if that interface supports TCP offload. The code >>>> does the exact same thing as ip_output does except it doesn't have the >>>> inpcb locked (which isn't used as part of the route lookup). >>> This is the only RELENG_7 box that I have where it routes tcp packets >>> asymmetrically, so that sounds like it might be the portion that is badly >>> interacting. The server has just one default gateway, which is out em0, but >>> clients all over the net will connect to IP addresses aliased on lo0 and to >>> the one IP on em1. But all connections exit out em0 other than connected >>> routes of course. >>> >>> ---Mike >>> >>>> Julian has worked in this code most recently, maybe he has some idea >>>> what is going on. >>>> >> huh? wha? I haven't been following this thread.. what's up? >> > Julian - see previous e-mails, the arp cache gets messed up as a > result of calling rtalloc in tcp_offload.c - which is done to > determine which interface will be used for connection. Any thoughts on > why it may end up with dozens of bogus entries? > > -Kip has anyone tried the same scenario on -current? From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 06:05:33 2008 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 BE832106567B for ; Sun, 24 Aug 2008 06:05:33 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 86E2A8FC0C for ; Sun, 24 Aug 2008 06:05:33 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1862888rvf.43 for ; Sat, 23 Aug 2008 23:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=GyP2Oc7kJJiMuXVH73VBzg/f+YQWNTjkrCD8DXxR6YQ=; b=vPwWOO/ZLebzscP9mesJvHnqa3w1MpAHkqGlz6HPcp/fkqNQWVSZVmYp6frfO6wgX3 jhjo0kmINnyPrPraAKfyxoyj6Qbb6MLgyv6c+tWUsnuvg0RW0ynPuGGM+jVj42U2eBdL pP+/NH+9Br/p12S0MFVvNFQgdqQxiZK6Z+SBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=BMZxBvOZuQ8OW/xVjIamKymSfAen/jJ/74whtjnDS6jO1jU0sgzzx9Vr9UfWQUeaJe kBKzek2bLORWfSJ/6FL4/gVhuyGQb9PHbIgZa/9B81l0uOsY84jnL1w7ZqG5RTwkdgZ+ GWyxkYiiWVTJgA97yukp9/cdHwzXSAZdp7bqc= Received: by 10.140.135.19 with SMTP id i19mr1445307rvd.70.1219557933197; Sat, 23 Aug 2008 23:05:33 -0700 (PDT) Received: by 10.141.101.21 with HTTP; Sat, 23 Aug 2008 23:05:33 -0700 (PDT) Message-ID: <3c1674c90808232305s42cc9187k58e195d5092261e1@mail.gmail.com> Date: Sat, 23 Aug 2008 23:05:33 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Julian Elischer" In-Reply-To: <48B0F8AD.1090601@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> <48B0F8AD.1090601@elischer.org> X-Google-Sender-Auth: dfc3fcc510062e69 Cc: "Bjoern A. Zeeb" , Mike Tancsa , freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 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, 24 Aug 2008 06:05:33 -0000 Yes, he has the same issue. -Kip On Sat, Aug 23, 2008 at 10:59 PM, Julian Elischer wrote: > Kip Macy wrote: >> >> On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer >> wrote: >>> >>> Mike Tancsa wrote: >>>> >>>> At 10:16 PM 8/23/2008, Kip Macy wrote: >>>>> >>>>> Can you help me out a bit with your workload? >>>>> >>>>> tcp_offload_connect(...) needs to determine which interface an address >>>>> corresponds to see if that interface supports TCP offload. The code >>>>> does the exact same thing as ip_output does except it doesn't have the >>>>> inpcb locked (which isn't used as part of the route lookup). >>>> >>>> This is the only RELENG_7 box that I have where it routes tcp packets >>>> asymmetrically, so that sounds like it might be the portion that is >>>> badly >>>> interacting. The server has just one default gateway, which is out em0, >>>> but >>>> clients all over the net will connect to IP addresses aliased on lo0 and >>>> to >>>> the one IP on em1. But all connections exit out em0 other than >>>> connected >>>> routes of course. >>>> >>>> ---Mike >>>> >>>>> Julian has worked in this code most recently, maybe he has some idea >>>>> what is going on. >>>>> >>> huh? wha? I haven't been following this thread.. what's up? >>> >> Julian - see previous e-mails, the arp cache gets messed up as a >> result of calling rtalloc in tcp_offload.c - which is done to >> determine which interface will be used for connection. Any thoughts on >> why it may end up with dozens of bogus entries? >> >> -Kip > > has anyone tried the same scenario on -current? > > > _______________________________________________ > 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 Sun Aug 24 06:18:45 2008 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 9C42F1065670 for ; Sun, 24 Aug 2008 06:18:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outr.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id 786668FC17 for ; Sun, 24 Aug 2008 06:18:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 65EF22476; Sat, 23 Aug 2008 23:18:45 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 789022D601A; Sat, 23 Aug 2008 23:18:44 -0700 (PDT) Message-ID: <48B0FD43.2090705@elischer.org> Date: Sat, 23 Aug 2008 23:18:43 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Kip Macy References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> <48B0F8AD.1090601@elischer.org> <3c1674c90808232305s42cc9187k58e195d5092261e1@mail.gmail.com> In-Reply-To: <3c1674c90808232305s42cc9187k58e195d5092261e1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , Mike Tancsa , freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 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, 24 Aug 2008 06:18:45 -0000 Kip Macy wrote: > Yes, he has the same issue. > -Kip > > > On Sat, Aug 23, 2008 at 10:59 PM, Julian Elischer wrote: >> Kip Macy wrote: >>> On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer >>> wrote: >>>> Mike Tancsa wrote: >>>>> At 10:16 PM 8/23/2008, Kip Macy wrote: >>>>>> Can you help me out a bit with your workload? >>>>>> >>>>>> tcp_offload_connect(...) needs to determine which interface an address >>>>>> corresponds to see if that interface supports TCP offload. The code >>>>>> does the exact same thing as ip_output does except it doesn't have the >>>>>> inpcb locked (which isn't used as part of the route lookup). >>>>> This is the only RELENG_7 box that I have where it routes tcp packets >>>>> asymmetrically, so that sounds like it might be the portion that is >>>>> badly >>>>> interacting. The server has just one default gateway, which is out em0, >>>>> but >>>>> clients all over the net will connect to IP addresses aliased on lo0 and >>>>> to >>>>> the one IP on em1. But all connections exit out em0 other than >>>>> connected >>>>> routes of course. >>>>> >>>>> ---Mike >>>>> >>>>>> Julian has worked in this code most recently, maybe he has some idea >>>>>> what is going on. >>>>>> >>>> huh? wha? I haven't been following this thread.. what's up? >>>> >>> Julian - see previous e-mails, the arp cache gets messed up as a >>> result of calling rtalloc in tcp_offload.c - which is done to >>> determine which interface will be used for connection. Any thoughts on >>> why it may end up with dozens of bogus entries? >>> >>> -Kip >> has anyone tried the same scenario on -current? ok so it might be related to the MRT code... I assume he only has one Routing table.. Theoretically it shoudl work the same as before if N==1 but I can imagine a case where it didn't. especially if arp and interffaces are involved.. Mike, can you give me a repro example? >> >> >> _______________________________________________ >> 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 Sun Aug 24 07:28:31 2008 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 5539F1065687 for ; Sun, 24 Aug 2008 07:28:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 00FFF8FC0C for ; Sun, 24 Aug 2008 07:28:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7O7RGrr011462 for ; Sun, 24 Aug 2008 01:27:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 24 Aug 2008 01:27:50 -0600 (MDT) Message-Id: <20080824.012750.-1186539247.imp@bsdimp.com> To: net@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Aug_24_01_27_50_2008_997)--" Content-Transfer-Encoding: 7bit Cc: Subject: Code review request 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, 24 Aug 2008 07:28:31 -0000 ----Next_Part(Sun_Aug_24_01_27_50_2008_997)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've been shepherding this patch in my p4 tree for a long time. It removes the obsolete support for other systems in if_spppsubr.c. Is there a reason I shouldn't commit this? Warner ----Next_Part(Sun_Aug_24_01_27_50_2008_997)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=sppp Index: if_spppsubr.c =================================================================== --- if_spppsubr.c (revision 182085) +++ if_spppsubr.c (working copy) @@ -23,38 +23,22 @@ #include -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 #include "opt_inet.h" #include "opt_inet6.h" #include "opt_ipx.h" -#endif -#ifdef NetBSD1_3 -# if NetBSD1_3 > 6 -# include "opt_inet.h" -# include "opt_inet6.h" -# include "opt_iso.h" -# endif -#endif - #include #include #include #include #include #include -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 #include -#endif #include #include #include -#if defined (__OpenBSD__) -#include -#else #include -#endif #include #include @@ -65,10 +49,6 @@ #include #include -#if defined (__NetBSD__) || defined (__OpenBSD__) -#include /* XXX for softnet */ -#endif - #include #include @@ -82,11 +62,7 @@ #include #endif -#if defined (__FreeBSD__) || defined (__OpenBSD__) -# include -#else -# include -#endif +#include #ifdef IPX #include @@ -95,12 +71,7 @@ #include -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 -# define IOCTL_CMD_T u_long -#else -# define IOCTL_CMD_T int -#endif - +#define IOCTL_CMD_T u_long #define MAXALIVECNT 3 /* max. alive packets */ /* @@ -261,13 +232,8 @@ void (*scr)(struct sppp *sp); }; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 && __FreeBSD_version < 501113 -#define SPP_FMT "%s%d: " -#define SPP_ARGS(ifp) (ifp)->if_name, (ifp)->if_unit -#else #define SPP_FMT "%s: " #define SPP_ARGS(ifp) (ifp)->if_xname -#endif #define SPPP_LOCK(sp) \ do { \ @@ -1422,11 +1388,7 @@ ++sp->pp_loopcnt; /* Generate new local sequence number */ -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 sp->pp_seq[IDX_LCP] = random(); -#else - sp->pp_seq[IDX_LCP] ^= time.tv_sec ^ time.tv_usec; -#endif break; } sp->pp_loopcnt = 0; @@ -2671,11 +2633,7 @@ if (magic == ~sp->lcp.magic) { if (debug) log(-1, "magic glitch "); -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 sp->lcp.magic = random(); -#else - sp->lcp.magic = time.tv_sec + time.tv_usec; -#endif } else { sp->lcp.magic = magic; if (debug) @@ -2856,11 +2814,7 @@ if (sp->lcp.opts & (1 << LCP_OPT_MAGIC)) { if (! sp->lcp.magic) -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 sp->lcp.magic = random(); -#else - sp->lcp.magic = time.tv_sec + time.tv_usec; -#endif opt[i++] = LCP_OPT_MAGIC; opt[i++] = 6; opt[i++] = sp->lcp.magic >> 24; @@ -4383,15 +4337,7 @@ /* Compute random challenge. */ ch = (u_long *)sp->myauth.challenge; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 read_random(&seed, sizeof seed); -#else - { - struct timeval tv; - microtime(&tv); - seed = tv.tv_sec ^ tv.tv_usec; - } -#endif ch[0] = seed ^ random(); ch[1] = seed ^ random(); ch[2] = seed ^ random(); @@ -4900,17 +4846,7 @@ * aliases don't make any sense on a p2p link anyway. */ si = 0; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) -#elif defined(__NetBSD__) || defined (__OpenBSD__) - for (ifa = TAILQ_FIRST(&ifp->if_addrlist); - ifa; - ifa = TAILQ_NEXT(ifa, ifa_list)) -#else - for (ifa = ifp->if_addrlist; - ifa; - ifa = ifa->ifa_next) -#endif if (ifa->ifa_addr->sa_family == AF_INET) { si = (struct sockaddr_in *)ifa->ifa_addr; sm = (struct sockaddr_in *)ifa->ifa_netmask; @@ -4949,17 +4885,7 @@ * aliases don't make any sense on a p2p link anyway. */ si = 0; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) -#elif defined(__NetBSD__) || defined (__OpenBSD__) - for (ifa = TAILQ_FIRST(&ifp->if_addrlist); - ifa; - ifa = TAILQ_NEXT(ifa, ifa_list)) -#else - for (ifa = ifp->if_addrlist; - ifa; - ifa = ifa->ifa_next) -#endif { if (ifa->ifa_addr->sa_family == AF_INET) { @@ -4972,17 +4898,6 @@ if (ifa && si) { int error; -#if defined(__NetBSD__) && __NetBSD_Version__ >= 103080000 - struct sockaddr_in new_sin = *si; - - new_sin.sin_addr.s_addr = htonl(src); - error = in_ifinit(ifp, ifatoia(ifa), &new_sin, 1); - if(debug && error) - { - log(LOG_DEBUG, SPP_FMT "sppp_set_ip_addr: in_ifinit " - " failed, error=%d\n", SPP_ARGS(ifp), error); - } -#else /* delete old route */ error = rtinit(ifa, (int)RTM_DELETE, RTF_HOST); if(debug && error) @@ -5004,7 +4919,6 @@ log(LOG_DEBUG, SPP_FMT "sppp_set_ip_addr: rtinit ADD failed, error=%d", SPP_ARGS(ifp), error); } -#endif } } @@ -5029,17 +4943,7 @@ * aliases don't make any sense on a p2p link anyway. */ si = 0; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) -#elif defined(__NetBSD__) || defined (__OpenBSD__) - for (ifa = ifp->if_addrlist.tqh_first; - ifa; - ifa = ifa->ifa_list.tqe_next) -#else - for (ifa = ifp->if_addrlist; - ifa; - ifa = ifa->ifa_next) -#endif if (ifa->ifa_addr->sa_family == AF_INET6) { si = (struct sockaddr_in6 *)ifa->ifa_addr; sm = (struct sockaddr_in6 *)ifa->ifa_netmask; @@ -5092,15 +4996,7 @@ */ sin6 = NULL; -#if defined(__FreeBSD__) && __FreeBSD__ >= 3 TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) -#elif defined(__NetBSD__) || defined (__OpenBSD__) - for (ifa = ifp->if_addrlist.tqh_first; - ifa; - ifa = ifa->ifa_list.tqe_next) -#else - for (ifa = ifp->if_addrlist; ifa; ifa = ifa->ifa_next) -#endif { if (ifa->ifa_addr->sa_family == AF_INET6) { ----Next_Part(Sun_Aug_24_01_27_50_2008_997)---- From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 11:21:12 2008 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 61B0F1065685; Sun, 24 Aug 2008 11:21:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 12AFD8FC1A; Sun, 24 Aug 2008 11:21:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m7OBL7oM019033; Sun, 24 Aug 2008 07:21:07 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m7OBL4Pn000366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Aug 2008 07:21:05 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200808241121.m7OBL4Pn000366@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 24 Aug 2008 07:21:09 -0400 To: Julian Elischer , Kip Macy From: Mike Tancsa In-Reply-To: <48B0FD43.2090705@elischer.org> References: <200808221719.m7MHJY25090566@lava.sentex.ca> <20080822191146.T66593@maildrop.int.zabbadoz.net> <200808221922.m7MJMcUN091064@lava.sentex.ca> <3c1674c90808231916l2c92a8e4sae0f191af31b5870@mail.gmail.com> <200808240312.m7O3CZS0098145@lava.sentex.ca> <48B0F722.3050005@elischer.org> <3c1674c90808232255s30a6fce7ma8e081e935a6adbc@mail.gmail.com> <48B0F8AD.1090601@elischer.org> <3c1674c90808232305s42cc9187k58e195d5092261e1@mail.gmail.com> <48B0FD43.2090705@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: strange TCP issue on RELENG_7 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, 24 Aug 2008 11:21:12 -0000 At 02:18 AM 8/24/2008, Julian Elischer wrote: >ok so it might be related to the MRT code... > >I assume he only has one Routing table.. Yes, just one routing table >Theoretically it shoudl work the same as before if N==1 >but I can imagine a case where it didn't. >especially if arp and interffaces are involved.. > >Mike, can you give me a repro example? I am not sure how, but it happens on this machine within seconds of all its applications starting up. I am speculating it has to do with the fact the machine has multiple public interfaces as well as IPs aliased to lo0 so that packets will come in em1 destined for em1 and lo0, but will always go out em0 ? The same for the kernel from HEAD shows the same behaviour. The problem started with the tcp offload code http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044468.html has more details ---Mike From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 11:35:07 2008 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 B8E901065671 for ; Sun, 24 Aug 2008 11:35:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7EC8FC1C for ; Sun, 24 Aug 2008 11:35:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id B464541C5D9; Sun, 24 Aug 2008 13:35:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id qSQoDZZNiokU; Sun, 24 Aug 2008 13:35:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 6174A41C5CD; Sun, 24 Aug 2008 13:35:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 6FFF344487F; Sun, 24 Aug 2008 11:31:54 +0000 (UTC) Date: Sun, 24 Aug 2008 11:31:53 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@freebsd.org Message-ID: <20080824111925.X66593@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: [CFT/R] IPv4 source address selection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2008 11:35:07 -0000 Hi, I have a patch, that was inspired by work from Y!, to do porper IPv4 source address selection for unbound sockets (with multi-IP jails). You can temporary find it here: http://people.freebsd.org/~bz/20080823-01-in_pcbladdr.diff People running my latest jail patches have been ``testing'' this without really knowing the last weeks. In case you wonder why, in the jail case, I loop over the ifa first before simply falling back to the primary jail IP (which is the only jail IP as in HEAD) -- this is because with the upcoming jail patches I have to check if any of possibly lots of IPs match any IP on an interface and only if none matches I have to fall back to the 'primary' jail IP. So the code has been prepared for upcoming changes already. Feel free to test it and report problems or unexpected behavior. Unless someone is going to cry it'll hit HEAD in a few days. /bz PS: in case you review this properly (not only glance at it or test it) let me know so I can punish you in the Reviewed by: line;-) -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 11:35:38 2008 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 6BC6A1065679 for ; Sun, 24 Aug 2008 11:35:38 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (mail.inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 12AA38FC20 for ; Sun, 24 Aug 2008 11:35:37 +0000 (UTC) (envelope-from rik@inse.ru) Received: from www.inse.ru (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTPSA id D7F3A33C57; Sun, 24 Aug 2008 15:18:46 +0400 (MSD) Message-ID: <48B14019.80901@localhost.inse.ru> Date: Sun, 24 Aug 2008 15:03:53 +0400 From: Roman Kurakin User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: "M. Warner Losh" References: <20080824.012750.-1186539247.imp@bsdimp.com> In-Reply-To: <20080824.012750.-1186539247.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Code review request 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, 24 Aug 2008 11:35:38 -0000 M. Warner Losh wrote: > I've been shepherding this patch in my p4 tree for a long time. It > removes the obsolete support for other systems in if_spppsubr.c. Is > there a reason I shouldn't commit this? > It was there to ease the keeping code in sync with other systems. Please ask Joerg Wunsch before removal. rik > Warner > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Sun Aug 24 11:35:39 2008 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 711F1106567A for ; Sun, 24 Aug 2008 11:35:39 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 373F58FC1B for ; Sun, 24 Aug 2008 11:35:38 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 0C56815A910; Sun, 24 Aug 2008 07:35:38 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 24 Aug 2008 07:35:38 -0400 X-Sasl-enc: jfr4LIZqVU6upFHjp/Zb4qKApjreZjn0Bs1iADm8p+gd 1219577736 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8C7BED71B; Sun, 24 Aug 2008 07:35:30 -0400 (EDT) Message-ID: <48B14773.9060907@FreeBSD.org> Date: Sun, 24 Aug 2008 12:35:15 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: "M. Warner Losh" References: <20080824.012750.-1186539247.imp@bsdimp.com> In-Reply-To: <20080824.012750.-1186539247.imp@bsdimp.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Code review request 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, 24 Aug 2008 11:35:39 -0000 M. Warner Losh wrote: > I've been shepherding this patch in my p4 tree for a long time. It > removes the obsolete support for other systems in if_spppsubr.c. Is > there a reason I shouldn't commit this? > Looks fine to me. From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 13:12:23 2008 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 8CB7C106564A; Sun, 24 Aug 2008 13:12:23 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB4F8FC19; Sun, 24 Aug 2008 13:12:23 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 6BADD159743; Sun, 24 Aug 2008 08:56:35 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 24 Aug 2008 08:56:35 -0400 X-Sasl-enc: 0OdIekMWhXtD5HwLZN4AdFIsUsojpZ7XCO0rzotZld9B 1219582593 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id B9E2C4204; Sun, 24 Aug 2008 08:56:27 -0400 (EDT) Message-ID: <48B15A6E.5060000@FreeBSD.org> Date: Sun, 24 Aug 2008 13:56:14 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20080824111925.X66593@maildrop.int.zabbadoz.net> In-Reply-To: <20080824111925.X66593@maildrop.int.zabbadoz.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD current mailing list Subject: Re: [CFT/R] IPv4 source address selection 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, 24 Aug 2008 13:12:23 -0000 Bjoern A. Zeeb wrote: > Hi, > > I have a patch, that was inspired by work from Y!, to do porper > IPv4 source address selection for unbound sockets (with multi-IP > jails). Hi, This kinda overlaps with some other ideas I'd like to see go in. It looks good and if it's already been tested, it should probably go in anyway as it disentangles the logic and puts it in a separate function. I'm thinking we may wish to use criteria other than interface or jailed socket to select source address. I should point out though that we picked some stuff up from KAME to do source address selection but it's not in the IPv4 stack. cheers BMS From owner-freebsd-net@FreeBSD.ORG Sun Aug 24 16:22:55 2008 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 59D8C106567A for ; Sun, 24 Aug 2008 16:22:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E9D7C8FC2C for ; Sun, 24 Aug 2008 16:22:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7OGL9af023425; Sun, 24 Aug 2008 10:21:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 24 Aug 2008 10:21:44 -0600 (MDT) Message-Id: <20080824.102144.-705600373.imp@bsdimp.com> To: rik@inse.ru From: "M. Warner Losh" In-Reply-To: <48B14019.80901@localhost.inse.ru> References: <20080824.012750.-1186539247.imp@bsdimp.com> <48B14019.80901@localhost.inse.ru> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: Code review request 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, 24 Aug 2008 16:22:55 -0000 In message: <48B14019.80901@localhost.inse.ru> Roman Kurakin writes: : M. Warner Losh wrote: : > I've been shepherding this patch in my p4 tree for a long time. It : > removes the obsolete support for other systems in if_spppsubr.c. Is : > there a reason I shouldn't commit this? : > : It was there to ease the keeping code in sync with other systems. : Please ask Joerg Wunsch before removal. Yea, I knew that history. But there's been a lot of hacking on this file, and the ifdef's are for other systems that were contemporaneous with FreeBSD 3.0, but nothing newer. Plus the FreeBSDisms that are newer haven't been ifdef'd. Warner From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 06:26:18 2008 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 6BB381065675; Mon, 25 Aug 2008 06:26:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 27A558FC14; Mon, 25 Aug 2008 06:26:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7P6Mkco032343; Mon, 25 Aug 2008 00:22:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 25 Aug 2008 00:23:16 -0600 (MDT) Message-Id: <20080825.002316.-1548243307.imp@bsdimp.com> To: net@freebsd.org, arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug_25_00_23_16_2008_044)--" Content-Transfer-Encoding: 7bit Cc: Subject: Code review 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, 25 Aug 2008 06:26:18 -0000 ----Next_Part(Mon_Aug_25_00_23_16_2008_044)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I did this a few years ago when trying to track down a problem with some realtek network chips that I was having problems with at Timing Solutions. I'd like to get this into the tree, since it was helpful then. Comments? Warner ----Next_Part(Mon_Aug_25_00_23_16_2008_044)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rl.diff" diff -ur src/sys/pci/if_rl.c newcard/src/sys/pci/if_rl.c --- src/sys/pci/if_rl.c 2008-08-23 22:21:15.000000000 -0600 +++ newcard/src/sys/pci/if_rl.c 2008-08-23 22:26:09.000000000 -0600 @@ -1253,18 +1253,120 @@ } static void +rl_twister_update(struct rl_softc *sc) +{ + uint16_t linktest; + static const uint32_t param[4][4] = { + {0xcb39de43, 0xcb39ce43, 0xfb38de03, 0xcb38de43}, + {0xcb39de43, 0xcb39ce43, 0xcb39ce83, 0xcb39ce83}, + {0xcb39de43, 0xcb39ce43, 0xcb39ce83, 0xcb39ce83}, + {0xbb39de43, 0xbb39ce43, 0xbb39ce83, 0xbb39ce83} + }; + + /* + * Tune the so-called twister registers of the RTL8139. These + * are used to compensate for impendence mismatches. The + * method for tuning these registes is undocumented and the + * following proceedure is collected from public sources. + */ + switch (sc->rl_twister) + { + case CHK_LINK: + /* + * If we have a sufficent link, then we can proceed in + * the state machine to the next stage. If not, then + * disable further tuning after writing sane defaults. + */ + if (CSR_READ_2(sc, RL_CSCFG) & RL_CSCFG_LINK_OK) { + CSR_WRITE_2(sc, RL_CSCFG, RL_CSCFG_LINK_DOWN_OFF_CMD); + sc->rl_twister = FIND_ROW; + } else { + CSR_WRITE_2(sc, RL_CSCFG, RL_CSCFG_LINK_DOWN_CMD); + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_CBL_TEST); + CSR_WRITE_4(sc, RL_PARA78, RL_PARA78_DEF); + CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_DEF); + sc->rl_twister = DONE; + } + break; + case FIND_ROW: + /* + * Read how long it took to see the echo to find the tuning + * row to use. + */ + linktest = CSR_READ_2(sc, RL_CSCFG) & RL_CSCFG_STATUS; + if (linktest == RL_CSCFG_ROW3) + sc->rl_twist_row = 3; + else if (linktest == RL_CSCFG_ROW2) + sc->rl_twist_row = 2; + else if (linktest == RL_CSCFG_ROW1) + sc->rl_twist_row = 1; + else + sc->rl_twist_row = 0; + sc->rl_twist_col = 0; + sc->rl_twister = SET_PARAM; + break; + case SET_PARAM: + if (sc->rl_twist_col == 0) + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_RESET); + CSR_WRITE_4(sc, RL_PARA7C, + param[sc->rl_twist_row][sc->rl_twist_col]); + if (++sc->rl_twist_col == 4) { + if (sc->rl_twist_row == 3) + sc->rl_twister = RECHK_LONG; + else + sc->rl_twister = DONE; + } + break; + case RECHK_LONG: + /* + * For long cables, we have to double check to make sure we + * don't mistune. + */ + linktest = CSR_READ_2(sc, RL_CSCFG) & RL_CSCFG_STATUS; + if (linktest == RL_CSCFG_ROW3) + sc->rl_twister = DONE; + else { + CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_RETUNE); + sc->rl_twister = RETUNE; + } + break; + case RETUNE: + /* Retune for a shorter cable (try column 2) */ + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_CBL_TEST); + CSR_WRITE_4(sc, RL_PARA78, RL_PARA78_DEF); + CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_DEF); + CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_RESET); + sc->rl_twist_row--; + sc->rl_twist_col = 0; + sc->rl_twister = SET_PARAM; + break; + + case DONE: + break; + } + +} + +static void rl_tick(void *xsc) { struct rl_softc *sc = xsc; struct mii_data *mii; + int ticks; RL_LOCK_ASSERT(sc); mii = device_get_softc(sc->rl_miibus); mii_tick(mii); + if (sc->rl_twister != DONE) + rl_twister_update(sc); + if (sc->rl_twister != DONE) + ticks = hz / 10; + else + ticks = hz; rl_watchdog(sc); - callout_reset(&sc->rl_stat_callout, hz, rl_tick, sc); + callout_reset(&sc->rl_stat_callout, ticks, rl_tick, sc); } #ifdef DEVICE_POLLING @@ -1490,6 +1592,13 @@ rl_stop(sc); /* + * Reset twister register tuning state. The twister registers + * and their tuning are undocumented, but are necessary to cope + * with bad links. rl_twister = DONE here will disable this entirely. + */ + sc->rl_twister = CHK_LINK; + + /* * Init our MAC address. Even though the chipset * documentation doesn't mention it, we need to enter "Config * register write enable" mode to modify the ID registers. diff -ur src/sys/pci/if_rlreg.h newcard/src/sys/pci/if_rlreg.h --- src/sys/pci/if_rlreg.h 2008-08-23 22:21:15.000000000 -0600 +++ newcard/src/sys/pci/if_rlreg.h 2008-08-23 22:26:09.000000000 -0600 @@ -309,6 +309,27 @@ #define RL_CMD_RESET 0x0010 /* + * Twister register values. These are completely undocumented and derived + * from public sources. + */ +#define RL_CSCFG_LINK_OK 0x0400 +#define RL_CSCFG_CHANGE 0x0800 +#define RL_CSCFG_STATUS 0xf000 +#define RL_CSCFG_ROW3 0x7000 +#define RL_CSCFG_ROW2 0x3000 +#define RL_CSCFG_ROW1 0x1000 +#define RL_CSCFG_LINK_DOWN_OFF_CMD 0x03c0 +#define RL_CSCFG_LINK_DOWN_CMD 0xf3c0 + +#define RL_NWAYTST_RESET 0 +#define RL_NWAYTST_CBL_TEST 0x20 + +#define RL_PARA78 0x78 +#define RL_PARA78_DEF 0x78fa8388 +#define RL_PARA7C 0x7C +#define RL_PARA7C_DEF 0xcb38de43 +#define RL_PARA7C_RETUNE 0xfb38de03 +/* * EEPROM control register */ #define RL_EE_DATAOUT 0x01 /* Data out */ @@ -801,6 +822,8 @@ bus_addr_t rl_tx_list_addr; }; +enum rl_twist { DONE, CHK_LINK, FIND_ROW, SET_PARAM, RECHK_LONG, RETUNE }; + struct rl_softc { struct ifnet *rl_ifp; /* interface info */ bus_space_handle_t rl_bhandle; /* bus space handle */ @@ -830,6 +853,9 @@ uint32_t rl_rxlenmask; int rl_testmode; int rl_if_flags; + enum rl_twist rl_twister; + int rl_twist_row; + int rl_twist_col; int suspended; /* 0 = normal 1 = suspended */ #ifdef DEVICE_POLLING int rxcycles; @@ -850,6 +876,8 @@ #define RL_FLAG_LINK 0x8000 }; + + #define RL_LOCK(_sc) mtx_lock(&(_sc)->rl_mtx) #define RL_UNLOCK(_sc) mtx_unlock(&(_sc)->rl_mtx) #define RL_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->rl_mtx, MA_OWNED) ----Next_Part(Mon_Aug_25_00_23_16_2008_044)---- From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 09:40:07 2008 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 BE2651065679 for ; Mon, 25 Aug 2008 09:40:07 +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 B8ED98FC22 for ; Mon, 25 Aug 2008 09:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7P9e7ad017644 for ; Mon, 25 Aug 2008 09:40:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7P9e7Gj017643; Mon, 25 Aug 2008 09:40:07 GMT (envelope-from gnats) Date: Mon, 25 Aug 2008 09:40:07 GMT Message-Id: <200808250940.m7P9e7Gj017643@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/126561: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2008 09:40:07 -0000 The following reply was made to PR kern/126561; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/126561: commit references a PR Date: Mon, 25 Aug 2008 09:30:59 +0000 (UTC) dfr 2008-08-25 09:30:27 UTC FreeBSD src repository Modified files: sys/nlm nlm_prot_server.c Log: SVN rev 182153 on 2008-08-25 09:30:27Z by dfr Add a missing return statement in nlm4_unlock_msg_4_svc which prevented it from returning a reply message in most cases. This in turn caused interoperability problems with Mac OS X clients. PR: 126561 Submitted by: Richard.Conto at gmail.com MFC after: 1 week Revision Changes Path 1.4 +1 -0 src/sys/nlm/nlm_prot_server.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 10:10:04 2008 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 DAF561065680 for ; Mon, 25 Aug 2008 10:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D63A38FC1E for ; Mon, 25 Aug 2008 10:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7PAA4mH018659 for ; Mon, 25 Aug 2008 10:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7PAA4Mk018658; Mon, 25 Aug 2008 10:10:04 GMT (envelope-from gnats) Date: Mon, 25 Aug 2008 10:10:04 GMT Message-Id: <200808251010.m7PAA4Mk018658@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Artis Caune" Cc: Subject: Re: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Artis Caune List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2008 10:10:04 -0000 The following reply was made to PR kern/126714; it has been noted by GNATS. From: "Artis Caune" To: bug-followup@freebsd.org Cc: slawek.zak@gmail.com Subject: Re: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address Date: Mon, 25 Aug 2008 13:05:55 +0300 Same for me, but when I rename carp interface to original name, everything works. When you change carp0 name to new_name, ifconfig will: - announce that carp0 is gone (departure) - copy new_name to if_xname - announce that new_name has arrived carp check only departure events. When you change name of carp interface, mac address also change: from 00:00:5e:00:01:08 to 70:31:00:00:5e:00 (for me) And because new mac address is no longer CARP mac address, carp_forus() fail, M_PROMISC flag is not cleared and frame is discarded. If you need change names at run time and not in rc.conf, then you should reinitialize carp interface: # ifconfig new_name vhid 1 pass testpass 192.168.0.2/24 or set promisc flag on em0/em1 :) btw, don't change name to "carp" or your box will panic. p.s. if you change name to underlying em0/em1/lagg/vlan interface, you should also reinitialize carp interface or you will see: carp_input: packet received on non-carp interface: bce0 -- regards, Artis Caune <----. CCNA <----|==================== <----' didii FreeBSD From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 11:06:54 2008 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 C3682106568B for ; Mon, 25 Aug 2008 11:06:54 +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 C527B8FC16 for ; Mon, 25 Aug 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7PB6sap027832 for ; Mon, 25 Aug 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7PB6sjo027828 for freebsd-net@FreeBSD.org; Mon, 25 Aug 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Aug 2008 11:06:54 GMT Message-Id: <200808251106.m7PB6sjo027828@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, 25 Aug 2008 11:06:54 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o bin/125922 net [patch] Deadlock in arp(8) o kern/126075 net [in] Network: internet control accesses beyond end of o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126742 net [panic] kernel panic when sending file via ng_ubt(4) 105 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125816 net [carp] [bridge] carp stuck in init when using bridge i o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/126339 net [ipw] ipw driver drops the connection o kern/126695 net rtfree messages and network disruption upon use of if_ 61 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 11:47:19 2008 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 134F31065676 for ; Mon, 25 Aug 2008 11:47:19 +0000 (UTC) (envelope-from vako2000@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.227]) by mx1.freebsd.org (Postfix) with ESMTP id CEAA38FC1D for ; Mon, 25 Aug 2008 11:47:18 +0000 (UTC) (envelope-from vako2000@gmail.com) Received: by qb-out-0506.google.com with SMTP id e34so2464772qbe.35 for ; Mon, 25 Aug 2008 04:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-mailer:reply-to :organization:x-priority:message-id:to:subject:mime-version :content-type:content-transfer-encoding; bh=WLYGXH5KQhMmu9z/EKVHtV8tKCjBVtSTcuDqAy4Cd94=; b=dgP9mdTzPxQOHILWFdURo020S/pQRLThot/amezxCRDSi7QnznDN6fYsSCHsvBLtaX gEILZSSkyYm7Aqo/P++Gq9oT/hyJ2CaDm/YWN71/pEUoPzc9oojpTXvj0IShHnmkBYzf zHxqblUJW1iPG1b/RkWeGeCM968eN49Sys36g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-mailer:reply-to:organization:x-priority:message-id:to :subject:mime-version:content-type:content-transfer-encoding; b=gEu2ClvVB495Ph4QuC8gzxpB+p+Q4Lr7430fNxZPz83LdHYne9oJKhlyTyZ6LVTgvW efIc4yMD1LDhpdYJodmPnpsX7+XPIK4Sm7iVb0x/MH9htCQNm+sR0DeGQiDO0mRq4PLq yJLy8aK1x9agAArozq9KLt38uTjtf+lay9QcQ= Received: by 10.103.170.13 with SMTP id x13mr2812348muo.27.1219663977965; Mon, 25 Aug 2008 04:32:57 -0700 (PDT) Received: from KOSHEL ( [88.205.248.102]) by mx.google.com with ESMTPS id e8sm25216189muf.6.2008.08.25.04.32.56 (version=SSLv3 cipher=OTHER); Mon, 25 Aug 2008 04:32:57 -0700 (PDT) Date: Mon, 25 Aug 2008 17:32:53 +0600 From: vako2000 X-Mailer: The Bat! (v3.65.03) Professional Organization: qw X-Priority: 3 (Normal) Message-ID: <61656705.20080825173253@gmail.com> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vako2000 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2008 11:47:19 -0000 Hello freebsd-net i like freeBSD -- Best regards, vako2000 mailto:vako2000@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 12:40:07 2008 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 26EB3106567F for ; Mon, 25 Aug 2008 12:40:07 +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 1691A8FC12 for ; Mon, 25 Aug 2008 12:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7PCe6Xa040996 for ; Mon, 25 Aug 2008 12:40:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7PCe6nS040994; Mon, 25 Aug 2008 12:40:06 GMT (envelope-from gnats) Date: Mon, 25 Aug 2008 12:40:06 GMT Message-Id: <200808251240.m7PCe6nS040994@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Alexey Pelykh" Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexey Pelykh List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2008 12:40:07 -0000 The following reply was made to PR kern/124127; it has been noted by GNATS. From: "Alexey Pelykh" To: bug-followup@FreeBSD.org, skylord@linkline.ru Cc: Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering Date: Mon, 25 Aug 2008 15:01:09 +0300 Also, DLink 560T. Same problem. NIC freezes on workloads at > 3.0Mbytes/sec dmesg | grep "msk" mskc0: port 0xd800-0xd8ff mem 0xfe9fc000-0xfe9fffff irq 16 at device 0.0 on pci1 msk0: on mskc0 miibus0: on msk0 mskc0: [ITHREAD] mskc0: port 0xd800-0xd8ff mem 0xfe9fc000-0xfe9fffff irq 16 at device 0.0 on pci1 msk0: on mskc0 miibus0: on msk0 mskc0: [ITHREAD] mskc0: port 0xd800-0xd8ff mem 0xfe9fc000-0xfe9fffff irq 16 at device 0.0 on pci1 msk0: on mskc0 miibus0: on msk0 mskc0: [FILTER] msk0: link state changed to UP pciconf -lv mskc0@pci0:1:0:0: class=0x020000 card=0x4b001186 chip=0x4b001186 rev=0x13 hdr=0x00 vendor = 'D-Link System Inc' device = 'DGE-560T PCIe Gigabit Ethernet Adapter' class = network subclass = ethernet uname -a: FreeBSD taburetka 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #17: Sun Aug 10 01:10:09 EEST 2008 root@taburetka:/usr/obj/usr/src/sys/taburetka_7_0.2008-25-07 i386 From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 13:28:38 2008 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 7A8B21065686 for ; Mon, 25 Aug 2008 13:28:38 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by mx1.freebsd.org (Postfix) with ESMTP id 26A6B8FC28 for ; Mon, 25 Aug 2008 13:28:37 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so957978wra.27 for ; Mon, 25 Aug 2008 06:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=odpQ64ETIDmEBFaWX4Ab2++EdGPYNXOCnuDZr7dAlPg=; b=E+QFzF7/vPSf16g7J3kfzTpluh+WqDxRqVMVFXjEodQbTnijxRLSmkF4eIiIPySKdU Tl8OokhFG+UTACAij5y97dnG8GbS0IoTKV/60+6z6QF2fCPbXFkR6AUiLYdK/3S9yefs 7vlfStXb8VY8hF2X+dlYqiAWQgLWMWyRfMeiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=X3l6BYK/419xtVpk6ufT2HRChwD9NdHb/CJHXWaHtWk3HOPl1+DS2ROsTb/za1ROQ0 mRzGuE6xXh7nYjHcja+Q77rx60bBe+QpEMnl6HNr9WoIEHgPPyqChfAmH93eniSjdTKs nSyQ0P6dwJFdyh2qIpvCbcmxxr6OzU1MFvlnA= Received: by 10.90.53.1 with SMTP id b1mr5352861aga.37.1219670917199; Mon, 25 Aug 2008 06:28:37 -0700 (PDT) Received: by 10.90.96.4 with HTTP; Mon, 25 Aug 2008 06:28:37 -0700 (PDT) Message-ID: Date: Mon, 25 Aug 2008 17:28:37 +0400 From: pluknet To: Alex In-Reply-To: <200808230830.m7N8U5aH081332@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808230830.m7N8U5aH081332@freefall.freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) 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, 25 Aug 2008 13:28:38 -0000 2008/8/23 Alex : > this should work. i simply replaced the lines with a single dot (".") in it with "DOT". You have a truncated mail maybe because of '.' treated as a special symbol that means "end of body" in SMTP. > Unread portion of the kernel message buffer: > sblastmbufchk: sb_mb 0xc91a5300 sb_mbtail 0 last 0xc91a5300 > packet tree: > 0xc91a5300 > panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:794 > cpuid = 0 > Syncing disks, buffers remaining... 7171 7168 7168 7168 7168 7168 7168 7167 7169 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 > Giving up on 7167 buffers > Uptime: 2d18h9m43s > Physical memory: 2030 MB > Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 > Dump complete > panic: 5 vncache entries remaining > cpuid = 0 > Uptime: 2d18h9m47s > Physical memory: 2030 MB > Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 > > #0 doadump () at pcpu.h:195 > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc04daa4e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 > #3 0xc07d73e4 in pfs_vncache_unload () at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs_vncache.c:102 > #4 0xc07d6515 in pfs_modevent (mod=0xc54b8280, evt=2, arg=0x0) at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs.c:438 > #5 0xc04cd318 in module_shutdown (arg1=0x0, arg2=) at /usr/src/sys/kern/kern_module.c:105 > #6 0xc04daaef in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:421 > #7 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 > #8 0xc052d79b in sblastmbufchk (sb=0x0, file=0xc06838ad "/usr/src/sys/kern/uipc_sockbuf.c", line=794) at /usr/src/sys/kern/uipc_sockbuf.c:425 > #9 0xc052eed0 in sbcompress (sb=0xc8cb11f0, m=0x0, n=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:794 > #10 0xc052eff0 in sbappendrecord_locked (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:599 > #11 0xc052f041 in sbappendrecord (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:610 > #12 0xc5a2f8fe in ng_btsocket_l2cap_input (context=0x0, pending=1) at /usr/src/sys/modules/netgraph/bluetooth/socket/../../../../netgraph/bluetooth/socket/ng_btsocket_l2cap.c:1458 > #13 0xc050cd1b in taskqueue_run (queue=0xc556b500) at /usr/src/sys/kern/subr_taskqueue.c:282 > #14 0xc050cf53 in taskqueue_swi_giant_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:336 > #15 0xc04be975 in ithread_loop (arg=0xc55d7160) at /usr/src/sys/kern/kern_intr.c:1088 > #16 0xc04bc258 in fork_exit (callout=0xc04be7b0 , arg=0xc55d7160, frame=0xe5b12d38) at /usr/src/sys/kern/kern_fork.c:781 > #17 0xc06348b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 > --- crash ends here --- > > --- ARUNDEL begins here --- > cpu I686_CPU > ident ARUNDEL > #maxusers 10 > makeoptions DEBUG=-g > #makeoptions CONF_CFLAGS=-fno-builtin > #options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table > #options CPU_SUSP_HLT > #options CPU_UPGRADE_HW_CACHE > #options CPU_FASTER_5X86_FPU > options ATA_STATIC_ID > > #options MSDOSFS > #options CD9660 > #options USB_DEBUG > #options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN > #options HZ=100 > > #options PREEMPTION > #options IPI_PREEMPTION > > options SCHED_4BSD #4BSD scheduler > #options SCHED_ULE > options INET #InterNETworking > options FFS #Berkeley Fast Filesystem > options SOFTUPDATES #Enable FFS soft updates support > options UFS_DIRHASH #Improve performance on big directories > options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] > options COMPAT_43TTY #Compatible with BSD 4.3 [KEEP THIS!] > options COMPAT_FREEBSD4 #Compatible with FreeBSD4 > options COMPAT_FREEBSD5 #Compatible with FreeBSD5 > options COMPAT_FREEBSD6 #Compatible with FreeBSD6 > > options SC_HISTORY_SIZE=1000 #number of history buffer lines > #options KDB #Compile with kernel debugger related code > #options KDB_TRACE #Print a stack trace of the current thread on the console for a panic. > #options KTRACE #ktrace(1) support > #options DDB > options INVARIANTS > options INVARIANT_SUPPORT > options SOCKBUF_DEBUG > options WITNESS > options WITNESS_SKIPSPIN > options SYSVSHM #SYSV-style shared memory > options SYSVMSG #SYSV-style message queues > options SYSVSEM #SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > options KBD_INSTALL_CDEV #install a CDEV entry in /dev > options UKBD_DFLT_KEYMAP #specify the built-in keymap > makeoptions UKBD_DFLT_KEYMAP="german.iso" > #options AUTO_EOI_1 > #options AUTO_EOI_2 > #options ADAPTIVE_GIANT # Giant mutex is adaptive. > #options STOP_NMI # Stop CPUS using NMI instead of IPI > > > options SMP # Symmetric MultiProcessor Kernel > device apic # I/O APIC > > > #devices > device eisa > device pci > device ata > device atadisk > device atapicd > device usb > device uhci > device ehci > device vga > device sc > device ukbd > device ulpt > device ath > device ath_hal > device ath_rate_sample > device wlan > device cpufreq > device coretemp > > #pseudo devices > device loop > device ether > device pty > --- ARUNDEL ends here --- Looks like it was triggered by the SOCKBUF_DEBUG kernel option. I will try to reproduce it this evening as I'm user of ng_ubt(4). wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 19:02:10 2008 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 679F41065683; Mon, 25 Aug 2008 19:02:10 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id F15878FC08; Mon, 25 Aug 2008 19:02:08 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 6317C33CBC; Mon, 25 Aug 2008 21:02:07 +0200 (SAST) Date: Mon, 25 Aug 2008 21:02:07 +0200 From: John Hay To: gnn@FreeBSD.org Message-ID: <20080825190207.GA73478@zibbi.meraka.csir.co.za> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Luigi Rizzo , "Bruce M. Simpson" , net@FreeBSD.org Subject: Re: Small patch to multicast code... 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, 25 Aug 2008 19:02:10 -0000 On Fri, Aug 22, 2008 at 03:03:30PM -0700, gnn@FreeBSD.org wrote: > At Fri, 22 Aug 2008 22:43:39 +0100, > Bruce M. Simpson wrote: > > > > gnn@FreeBSD.org wrote: > > > Somehow the data that the device needs to do the proper checksum > > > offload is getting trashed here. Now, since it's clear we need a > > > writable packet structure so that we don't trash the original, I'm > > > wondering if the m_pullup() will be sufficient. > > > > > > > If it's serious enough to break UDP checksumming on the wire, perhaps we > > should just swallow the mbuf allocator heap churn and do the m_dup() for > > now, but slap in a big comment about why it's there. > > I think if none of us finds a better way before early next week that's > what I'll do so that this at least works in 7.1. I think we and others have been hitting this problem: kern/119635: [em] Bad UDP packet checksum with em(4) and rxcsum/txcsum enabled http://www.freebsd.org/cgi/query-pr.cgi?pr=119635 I'll try out your patch. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 19:17:45 2008 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 DF58A106566C for ; Mon, 25 Aug 2008 19:17:45 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1EE8FC12 for ; Mon, 25 Aug 2008 19:17:45 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so1041736wra.27 for ; Mon, 25 Aug 2008 12:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=KIC2bom9yBrqvkADP82vHBA6yIsik5JPOzpTPwG7LM4=; b=jvjnzUgyRO5Ubi6EmJR2tu/PgQQmyDZG+ENx9zZCStKyiAT9G4Dv/x4FbaEQHYglTT KAMzXx6l4wMMqdRg5v3yuOWJ4tetWML028Vdb3Aa+8UGMgfpNSt+1SGZWBS478cxvcdQ IaohhNKsYoBFyEgRPUVJDsuoQ4fnG6Xp6kDYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=OPKNIGmIgrZuy3cRvYcpuFblq8VxwEQqd8/OxtTJ4hDIwdc8P0dcfFhy4etwcv+JcR FZOuvF/B/Qa0tKyasfCr8+b8Xcxssxfr8pcyWejdeHZr77gxYU+RnxR3fF9m5ZsZekyy zxxbpgnxv2cikZ+FTYZbIsPpmIAMafv6DCDV0= Received: by 10.90.91.9 with SMTP id o9mr5796936agb.35.1219691864015; Mon, 25 Aug 2008 12:17:44 -0700 (PDT) Received: by 10.90.96.4 with HTTP; Mon, 25 Aug 2008 12:17:44 -0700 (PDT) Message-ID: Date: Mon, 25 Aug 2008 23:17:44 +0400 From: pluknet To: Alex In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808230830.m7N8U5aH081332@freefall.freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: kern/126742: [panic] kernel panic when sending file via ng_ubt(4) 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, 25 Aug 2008 19:17:46 -0000 2008/8/25 pluknet : > 2008/8/23 Alex : >> this should work. i simply replaced the lines with a single dot (".") in it with "DOT". > > You have a truncated mail maybe because of '.' treated as a special > symbol that means "end of body" in SMTP. > >> Unread portion of the kernel message buffer: >> sblastmbufchk: sb_mb 0xc91a5300 sb_mbtail 0 last 0xc91a5300 >> packet tree: >> 0xc91a5300 >> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:794 >> cpuid = 0 >> Syncing disks, buffers remaining... 7171 7168 7168 7168 7168 7168 7168 7167 7169 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 7167 >> Giving up on 7167 buffers >> Uptime: 2d18h9m43s >> Physical memory: 2030 MB >> Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 >> Dump complete >> panic: 5 vncache entries remaining >> cpuid = 0 >> Uptime: 2d18h9m47s >> Physical memory: 2030 MB >> Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 >> >> #0 doadump () at pcpu.h:195 >> in pcpu.h >> (kgdb) bt >> #0 doadump () at pcpu.h:195 >> #1 0xc04daa4e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 >> #2 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 >> #3 0xc07d73e4 in pfs_vncache_unload () at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs_vncache.c:102 >> #4 0xc07d6515 in pfs_modevent (mod=0xc54b8280, evt=2, arg=0x0) at /usr/src/sys/modules/pseudofs/../../fs/pseudofs/pseudofs.c:438 >> #5 0xc04cd318 in module_shutdown (arg1=0x0, arg2=) at /usr/src/sys/kern/kern_module.c:105 >> #6 0xc04daaef in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:421 >> #7 0xc04dac7c in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:572 >> #8 0xc052d79b in sblastmbufchk (sb=0x0, file=0xc06838ad "/usr/src/sys/kern/uipc_sockbuf.c", line=794) at /usr/src/sys/kern/uipc_sockbuf.c:425 >> #9 0xc052eed0 in sbcompress (sb=0xc8cb11f0, m=0x0, n=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:794 >> #10 0xc052eff0 in sbappendrecord_locked (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:599 >> #11 0xc052f041 in sbappendrecord (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:610 >> #12 0xc5a2f8fe in ng_btsocket_l2cap_input (context=0x0, pending=1) at /usr/src/sys/modules/netgraph/bluetooth/socket/../../../../netgraph/bluetooth/socket/ng_btsocket_l2cap.c:1458 >> #13 0xc050cd1b in taskqueue_run (queue=0xc556b500) at /usr/src/sys/kern/subr_taskqueue.c:282 >> #14 0xc050cf53 in taskqueue_swi_giant_run (dummy=0x0) at /usr/src/sys/kern/subr_taskqueue.c:336 >> #15 0xc04be975 in ithread_loop (arg=0xc55d7160) at /usr/src/sys/kern/kern_intr.c:1088 >> #16 0xc04bc258 in fork_exit (callout=0xc04be7b0 , arg=0xc55d7160, frame=0xe5b12d38) at /usr/src/sys/kern/kern_fork.c:781 >> #17 0xc06348b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 >> --- crash ends here --- >> >> --- ARUNDEL begins here --- >> cpu I686_CPU >> ident ARUNDEL >> #maxusers 10 >> makeoptions DEBUG=-g >> #makeoptions CONF_CFLAGS=-fno-builtin >> #options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table >> #options CPU_SUSP_HLT >> #options CPU_UPGRADE_HW_CACHE >> #options CPU_FASTER_5X86_FPU >> options ATA_STATIC_ID >> >> #options MSDOSFS >> #options CD9660 >> #options USB_DEBUG >> #options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN >> #options HZ=100 >> >> #options PREEMPTION >> #options IPI_PREEMPTION >> >> options SCHED_4BSD #4BSD scheduler >> #options SCHED_ULE >> options INET #InterNETworking >> options FFS #Berkeley Fast Filesystem >> options SOFTUPDATES #Enable FFS soft updates support >> options UFS_DIRHASH #Improve performance on big directories >> options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] >> options COMPAT_43TTY #Compatible with BSD 4.3 [KEEP THIS!] >> options COMPAT_FREEBSD4 #Compatible with FreeBSD4 >> options COMPAT_FREEBSD5 #Compatible with FreeBSD5 >> options COMPAT_FREEBSD6 #Compatible with FreeBSD6 >> >> options SC_HISTORY_SIZE=1000 #number of history buffer lines >> #options KDB #Compile with kernel debugger related code >> #options KDB_TRACE #Print a stack trace of the current thread on the console for a panic. >> #options KTRACE #ktrace(1) support >> #options DDB >> options INVARIANTS >> options INVARIANT_SUPPORT >> options SOCKBUF_DEBUG >> options WITNESS >> options WITNESS_SKIPSPIN >> options SYSVSHM #SYSV-style shared memory >> options SYSVMSG #SYSV-style message queues >> options SYSVSEM #SYSV-style semaphores >> options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions >> options KBD_INSTALL_CDEV #install a CDEV entry in /dev >> options UKBD_DFLT_KEYMAP #specify the built-in keymap >> makeoptions UKBD_DFLT_KEYMAP="german.iso" >> #options AUTO_EOI_1 >> #options AUTO_EOI_2 >> #options ADAPTIVE_GIANT # Giant mutex is adaptive. >> #options STOP_NMI # Stop CPUS using NMI instead of IPI >> >> >> options SMP # Symmetric MultiProcessor Kernel >> device apic # I/O APIC >> >> >> #devices >> device eisa >> device pci >> device ata >> device atadisk >> device atapicd >> device usb >> device uhci >> device ehci >> device vga >> device sc >> device ukbd >> device ulpt >> device ath >> device ath_hal >> device ath_rate_sample >> device wlan >> device cpufreq >> device coretemp >> >> #pseudo devices >> device loop >> device ether >> device pty >> --- ARUNDEL ends here --- > > Looks like it was triggered by the SOCKBUF_DEBUG kernel option. > I will try to reproduce it this evening as I'm user of ng_ubt(4). > I did some debugging and found some fuzzy code in sbappendrecord_locked(). >> #10 0xc052eff0 in sbappendrecord_locked (sb=0xc8cb11f0, m0=0xc91a5300) at /usr/src/sys/kern/uipc_sockbuf.c:599 sb->sb_mb and m0 both point to the same address 0xc91a5300. - sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) { struct mbuf *m; SOCKBUF_LOCK_ASSERT(sb); if (m0 == 0) return; m = sb->sb_mb; - m also points to the same address 0xc91a5300 now (as sb->sb_mb and m0 do). - if (m) while (m->m_nextpkt) m = m->m_nextpkt; - Does nothing because m->m_nextpkt is NULL in the first iteration. - sballoc(sb, m0); SBLASTRECORDCHK(sb); SBLINKRECORD(sb, m0); - Does effectively nothing or non-relevant. - if (m) m->m_nextpkt = m0; else sb->sb_mb = m0; - m and m->m_nextpkt both point to the same address 0xc91a5300 now. - m = m0->m_next; - But hey! m0->m_next is NULL. Eventually sbcompress(sb, m, m0) is called with m == NULL and it fails in the SBLASTMBUFCHK check then. wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 19:40:40 2008 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 3D8271065671; Mon, 25 Aug 2008 19:40:40 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id BCB0F8FC13; Mon, 25 Aug 2008 19:40:39 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 89E9C33CD8; Mon, 25 Aug 2008 21:40:38 +0200 (SAST) Date: Mon, 25 Aug 2008 21:40:38 +0200 From: John Hay To: gnn@FreeBSD.org Message-ID: <20080825194038.GA75840@zibbi.meraka.csir.co.za> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080825190207.GA73478@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.1i Cc: "Bruce M. Simpson" , Luigi Rizzo , net@FreeBSD.org Subject: Re: Small patch to multicast code... 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, 25 Aug 2008 19:40:40 -0000 On Mon, Aug 25, 2008 at 09:02:07PM +0200, John Hay wrote: > On Fri, Aug 22, 2008 at 03:03:30PM -0700, gnn@FreeBSD.org wrote: > > At Fri, 22 Aug 2008 22:43:39 +0100, > > Bruce M. Simpson wrote: > > > > > > gnn@FreeBSD.org wrote: > > > > Somehow the data that the device needs to do the proper checksum > > > > offload is getting trashed here. Now, since it's clear we need a > > > > writable packet structure so that we don't trash the original, I'm > > > > wondering if the m_pullup() will be sufficient. > > > > > > > > > > If it's serious enough to break UDP checksumming on the wire, perhaps we > > > should just swallow the mbuf allocator heap churn and do the m_dup() for > > > now, but slap in a big comment about why it's there. > > > > I think if none of us finds a better way before early next week that's > > what I'll do so that this at least works in 7.1. > > I think we and others have been hitting this problem: > > kern/119635: [em] Bad UDP packet checksum with em(4) and rxcsum/txcsum enabled > http://www.freebsd.org/cgi/query-pr.cgi?pr=119635 > > I'll try out your patch. I have tried it and it does fix my problem. RIP2 over multicast works again. :-) John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Aug 25 20:04:44 2008 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 517821065678; Mon, 25 Aug 2008 20:04:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DDE2E8FC0A; Mon, 25 Aug 2008 20:04:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7PK4Y8K043991; Mon, 25 Aug 2008 16:04:34 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 25 Aug 2008 10:37:10 -0400 User-Agent: KMail/1.9.7 References: <20080825.002316.-1548243307.imp@bsdimp.com> In-Reply-To: <20080825.002316.-1548243307.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808251037.11126.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 25 Aug 2008 16:04:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8087/Mon Aug 25 14:40:37 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: "M. Warner Losh" , net@freebsd.org Subject: Re: Code review 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, 25 Aug 2008 20:04:44 -0000 On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: > I did this a few years ago when trying to track down a problem with > some realtek network chips that I was having problems with at Timing > Solutions. I'd like to get this into the tree, since it was helpful > then. > > Comments? When you are running a faster tick I think want to only call the mii and watchdog stuff once a second still. I know this will break the tx watchdog for example. Since it's kind of tricky to manage that I think you should just use a separate timer for the twister stuff. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Aug 26 07:25:53 2008 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 D996B1065671; Tue, 26 Aug 2008 07:25:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9CB928FC0A; Tue, 26 Aug 2008 07:25:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m7Q7NRZ5057765; Tue, 26 Aug 2008 01:23:27 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 26 Aug 2008 01:23:57 -0600 (MDT) Message-Id: <20080826.012357.1973601375.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200808251037.11126.jhb@freebsd.org> References: <20080825.002316.-1548243307.imp@bsdimp.com> <200808251037.11126.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Code review 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, 26 Aug 2008 07:25:54 -0000 In message: <200808251037.11126.jhb@freebsd.org> John Baldwin writes: : On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: : > I did this a few years ago when trying to track down a problem with : > some realtek network chips that I was having problems with at Timing : > Solutions. I'd like to get this into the tree, since it was helpful : > then. : > : > Comments? : : When you are running a faster tick I think want to only call the mii and : watchdog stuff once a second still. I know this will break the tx watchdog : for example. Since it's kind of tricky to manage that I think you should : just use a separate timer for the twister stuff. Is this in general, or do you have a specific problem in mind with the rl change? In general, we're not transmitting during this exercise and it happens only once... Is it worth the extra hair? Warner From owner-freebsd-net@FreeBSD.ORG Tue Aug 26 08:04:07 2008 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 82FEB1065677; Tue, 26 Aug 2008 08:04:07 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 014708FC39; Tue, 26 Aug 2008 08:04:06 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 0231A1B10F15; Tue, 26 Aug 2008 09:47:57 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, J_CHICKENPOX_66 autolearn=no version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id BA37B1B10F0F; Tue, 26 Aug 2008 09:47:53 +0200 (CEST) Message-ID: <48B3B52A.9080400@moneybookers.com> Date: Tue, 26 Aug 2008 10:47:54 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.16 (X11/20080813) MIME-Version: 1.0 To: gnn@freebsd.org References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <20080822194200.GC63527@onelab2.iet.unipi.it> In-Reply-To: Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.93.3/8089/Tue Aug 26 02:28:51 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: "Bruce M. Simpson" , Luigi Rizzo , net@freebsd.org Subject: Re: Small patch to multicast code... 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, 26 Aug 2008 08:04:07 -0000 Greetings, gnn@freebsd.org wrote: > At Fri, 22 Aug 2008 21:42:00 +0200, > Luigi Rizzo wrote: > >> On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote: >> >>> gnn@FreeBSD.org wrote: >>> >>>> I gather you mean that a fast link on which also we're looping back >>>> the packet will be an issue? Since this packet is only going into the >>>> simloop() routine. >>>> >>>> >>> We end up calling if_simloop() from a few "interesting" places, in >>> particular the kernel PIM packet handler. >>> >>> In this particular case we're going to take a full mbuf chain copy every >>> time we send a packet which needs to be looped back to userland. >>> >> ... >> >>> In the case of ip_mloopback(), somehow we are stomping on a read-only >>> copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine >>> according to the documented uses of mbuf(9), although as Luigi pointed >>> out, most likely we need to look at the upper-layer protocol too, e.g. >>> where UDP checksums are also being offloaded. >>> >> in fact, george, if you have an easy way to reproduce the error, >> could you see if reverting your change and instead adding >> sizeof(struct udphdr) to the length argument in the call to m_pullup() >> fixes the problem ? >> > > I don't have sample code I can give but it's simple to set up and > test. > > On machine A set up a sender and a listener for the same multicast > group/port. > > On machine B set up a listener. > > Send from A with the listener on. B should see nothing and its "bad > checksums" counter should increase. > > Turn off listener on A. > > Send again, B should get the packet. > Hm this looks very much like the showstopper when trying to use jboss in cluster environment. The nodes are replicating their data using multicast udp. I'll try this patch to see will the cluster work now under FreeBSD. > If you listen to the traffic with tcpdump on a 3rd machine you'll see > that the checksum is constant, even if the data in the packet, like > the ports, is not. > > Your ethernet cards have to have hardware checksum offloading. I'm > using em/igb in 7-STABLE. > em cards and here. Jboss in cluster creates lot of traffic when under pressure, so I wander how this patch will affect performance. > Best, > George > _______________________________________________ > 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" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Tue Aug 26 11:28:31 2008 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 EBD931065681 for ; Tue, 26 Aug 2008 11:28:31 +0000 (UTC) (envelope-from unss27rugby@www2.ac-rouen.fr) Received: from dallas.ac-rouen.fr (smtp.ac-rouen.fr [194.167.196.131]) by mx1.freebsd.org (Postfix) with ESMTP id 95A628FC26 for ; Tue, 26 Aug 2008 11:28:31 +0000 (UTC) (envelope-from unss27rugby@www2.ac-rouen.fr) Received: from dallas.ac-rouen.fr (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5542734D80 for ; Tue, 26 Aug 2008 13:01:41 +0200 (CEST) Received: from www2.ac-rouen.fr (hanoi.ac-rouen.fr [194.167.110.10]) by dallas.ac-rouen.fr (Postfix) with ESMTP id 80E5D34CC3 for ; Tue, 26 Aug 2008 12:59:07 +0200 (CEST) Received: by www2.ac-rouen.fr (Postfix, from userid 65902) id A861144DB8; Tue, 26 Aug 2008 12:58:34 +0200 (CEST) To: freebsd-net@freebsd.org From: Halifax Online Content-Transfer-Encoding: 8bit Message-Id: <20080826105834.A861144DB8@www2.ac-rouen.fr> Date: Tue, 26 Aug 2008 12:58:34 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Halifax Online Alert 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, 26 Aug 2008 11:28:32 -0000 [hx_print.gif] Dear Customer, Due to our MID-YEARLY upgrade, we kindly request you to update your online banking details, do not hesitate to fill all the requested information(s) in the link below and reconfirm your online account details. Note: there is an error in your SECURITY QUESTION and ANSWER in your file with our organisation that need to be updated. Failure to re-confirm your online banking details may leads to temporarily suspension from accessing your account online. [1]https://www.halifax-online.co.uk/_mem_bin/formslogin.asp We use the latest security measures to ensure that your online banking maintaining by our financial institution is well safe and secured according to our banking system Thank you for banking with us. Halifax Online Help Desk Information on protecting yourself from fraud, please review the Security Tips in our Security Center. References 1. http://atp-primrosebordeaux.com/cms/templates/css/www.halifax.co.uk/www.halifax.co.uk/www.halifax.co.uk/_mem_new/_mem_new/index.html From owner-freebsd-net@FreeBSD.ORG Tue Aug 26 14:29:02 2008 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 A7C56106567B; Tue, 26 Aug 2008 14:29:02 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 5602F8FC1F; Tue, 26 Aug 2008 14:29:02 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7QET05c016076; Tue, 26 Aug 2008 07:29:01 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7QESKR9062236; Tue, 26 Aug 2008 07:28:20 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (209.249.190.254.available.above.net [209.249.190.254] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7QESJJi077291; Tue, 26 Aug 2008 07:28:19 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Tue, 26 Aug 2008 10:28:16 -0400 Message-ID: From: "George V. Neville-Neil" To: John Hay In-Reply-To: <20080825194038.GA75840@zibbi.meraka.csir.co.za> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.00 () [Tag at 5.00] X-CanItPRO-Stream: default X-Canit-Stats-ID: 1350338 - 67705b21ab5c X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: "Bruce M. Simpson" , Luigi Rizzo , net@FreeBSD.org Subject: Re: Small patch to multicast code... 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, 26 Aug 2008 14:29:02 -0000 At Mon, 25 Aug 2008 21:40:38 +0200, John Hay wrote: > > I have tried it and it does fix my problem. RIP2 over multicast works > again. :-) Good to hear. I'm waiting on a bit more feedback but I think I'll be checking this in soon, with a big comment talking about the performance implications etc. Best, George From owner-freebsd-net@FreeBSD.ORG Tue Aug 26 15:12:09 2008 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 7F49C1065678 for ; Tue, 26 Aug 2008 15:12:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 46B988FC12 for ; Tue, 26 Aug 2008 15:12:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 32DA641C648; Tue, 26 Aug 2008 16:55:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id BXHBOuxRzpeC; Tue, 26 Aug 2008 16:55:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id DB10041C63C; Tue, 26 Aug 2008 16:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 897A64448E6; Tue, 26 Aug 2008 14:50:33 +0000 (UTC) Date: Tue, 26 Aug 2008 14:50:33 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: "George V. Neville-Neil" In-Reply-To: Message-ID: <20080826144130.S66593@maildrop.int.zabbadoz.net> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@FreeBSD.org Subject: Re: Small patch to multicast code... 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, 26 Aug 2008 15:12:09 -0000 On Tue, 26 Aug 2008, George V. Neville-Neil wrote: Hi, > At Mon, 25 Aug 2008 21:40:38 +0200, > John Hay wrote: >> >> I have tried it and it does fix my problem. RIP2 over multicast works >> again. :-) > > Good to hear. I'm waiting on a bit more feedback but I think I'll be > checking this in soon, with a big comment talking about the > performance implications etc. So wait a second; what was the m_pullup vs. m_dup thing? Has anyone actually tried that? I mean using a sledgehammer if a mitten would be enough is kind of .. uhm. You get it. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Tue Aug 26 18:02:53 2008 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 982581065675; Tue, 26 Aug 2008 18:02:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id EFF648FC15; Tue, 26 Aug 2008 18:02:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m7QI2giQ056781; Tue, 26 Aug 2008 14:02:43 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "M. Warner Losh" Date: Tue, 26 Aug 2008 10:33:42 -0400 User-Agent: KMail/1.9.7 References: <20080825.002316.-1548243307.imp@bsdimp.com> <200808251037.11126.jhb@freebsd.org> <20080826.012357.1973601375.imp@bsdimp.com> In-Reply-To: <20080826.012357.1973601375.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808261033.43091.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 26 Aug 2008 14:02:43 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8093/Tue Aug 26 12:01:30 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Code review 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, 26 Aug 2008 18:02:53 -0000 On Tuesday 26 August 2008 03:23:57 am M. Warner Losh wrote: > In message: <200808251037.11126.jhb@freebsd.org> > John Baldwin writes: > : On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: > : > I did this a few years ago when trying to track down a problem with > : > some realtek network chips that I was having problems with at Timing > : > Solutions. I'd like to get this into the tree, since it was helpful > : > then. > : > > : > Comments? > : > : When you are running a faster tick I think want to only call the mii and > : watchdog stuff once a second still. I know this will break the tx watchdog > : for example. Since it's kind of tricky to manage that I think you should > : just use a separate timer for the twister stuff. > > Is this in general, or do you have a specific problem in mind with the > rl change? In general, we're not transmitting during this exercise > and it happens only once... Is it worth the extra hair? Worried more about the general case. Is mii_tick() going to be ok with being invoked more often? Also, if you are only doing this during attach or interface up, it might be simpler to have a private timer (shoot, if it's during attach the 'struct callout' can be on the stack) just for this bit. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Aug 26 19:43:05 2008 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 17A70106567E for ; Tue, 26 Aug 2008 19:43:05 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id D5E228FC19 for ; Tue, 26 Aug 2008 19:43:04 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7QJh0Al036787; Tue, 26 Aug 2008 12:43:03 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7QJgtH3025388; Tue, 26 Aug 2008 12:42:55 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (209.249.190.254.available.above.net [209.249.190.254] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7QJgtYP007064; Tue, 26 Aug 2008 12:42:55 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Tue, 26 Aug 2008 15:42:54 -0400 Message-ID: From: gnn@FreeBSD.org To: "Bjoern A. Zeeb" In-Reply-To: <20080826144130.S66593@maildrop.int.zabbadoz.net> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1353637 - e5d7f640476c X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: net@FreeBSD.org Subject: Re: Small patch to multicast code... 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, 26 Aug 2008 19:43:05 -0000 At Tue, 26 Aug 2008 14:50:33 +0000 (UTC), Bjoern A. Zeeb wrote: > > On Tue, 26 Aug 2008, George V. Neville-Neil wrote: > > Hi, > > > At Mon, 25 Aug 2008 21:40:38 +0200, > > John Hay wrote: > >> > >> I have tried it and it does fix my problem. RIP2 over multicast works > >> again. :-) > > > > Good to hear. I'm waiting on a bit more feedback but I think I'll be > > checking this in soon, with a big comment talking about the > > performance implications etc. > > So wait a second; what was the m_pullup vs. m_dup thing? Has anyone > actually tried that? I mean using a sledgehammer if a mitten would be > enough is kind of .. uhm. You get it. Perhaps I'm confused, I've been off dealing with other issues for a few days, but m_pullup doesn't make a copy of the packet or its fields, only makes sure that it's contiguous in memory. Am I wrong in that? Since the bug is that two pieces of code modify the same data, in ways that interfere, I'm not sure how we can avoid making a copy. It might be nice to limit the copy, but we'd still need two copies, one for the loopback device and one for the real device. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 00:56:15 2008 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 5B66B1065671; Wed, 27 Aug 2008 00:56:15 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id ED84C8FC13; Wed, 27 Aug 2008 00:56:14 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m7R0uD4C033229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2008 17:56:13 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48B4A62D.3080300@freebsd.org> Date: Tue, 26 Aug 2008 17:56:13 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: gnn@freebsd.org References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: "Bjoern A. Zeeb" , net@freebsd.org Subject: Re: Small patch to multicast code... 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, 27 Aug 2008 00:56:15 -0000 gnn@freebsd.org wrote: > At Tue, 26 Aug 2008 14:50:33 +0000 (UTC), > Bjoern A. Zeeb wrote: > >> On Tue, 26 Aug 2008, George V. Neville-Neil wrote: >> >> Hi, >> >> >>> At Mon, 25 Aug 2008 21:40:38 +0200, >>> John Hay wrote: >>> >>>> I have tried it and it does fix my problem. RIP2 over multicast works >>>> again. :-) >>>> >>> Good to hear. I'm waiting on a bit more feedback but I think I'll be >>> checking this in soon, with a big comment talking about the >>> performance implications etc. >>> >> So wait a second; what was the m_pullup vs. m_dup thing? Has anyone >> actually tried that? I mean using a sledgehammer if a mitten would be >> enough is kind of .. uhm. You get it. >> > > Perhaps I'm confused, I've been off dealing with other issues for a > few days, but m_pullup doesn't make a copy of the packet or its > fields, only makes sure that it's contiguous in memory. Am I wrong in that? > > Since the bug is that two pieces of code modify the same data, in ways > that interfere, I'm not sure how we can avoid making a copy. It might > be nice to limit the copy, but we'd still need two copies, one for the > loopback device and one for the real device. > > pull the headers up. copy just the headers. no deep copy. Sam From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 04:06:01 2008 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 A35BF106567A; Wed, 27 Aug 2008 04:06:01 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 61ED28FC21; Wed, 27 Aug 2008 04:06:01 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7R460D9061135; Tue, 26 Aug 2008 21:06:01 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7R45S8k030656; Tue, 26 Aug 2008 21:05:28 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (cpe-68-175-68-135.nyc.res.rr.com [68.175.68.135]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7R45SKS033475; Tue, 26 Aug 2008 21:05:28 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Wed, 27 Aug 2008 00:05:26 -0400 Message-ID: From: gnn@freebsd.org To: Sam Leffler In-Reply-To: <48B4A62D.3080300@freebsd.org> References: <20080821203519.GA51534@onelab2.iet.unipi.it> <48AE23FF.9070009@FreeBSD.org> <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1357148 - e5c6aacd74a7 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: net@freebsd.org Subject: Re: Small patch to multicast code... 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, 27 Aug 2008 04:06:01 -0000 At Tue, 26 Aug 2008 17:56:13 -0700, Sam Leffler wrote: > > gnn@freebsd.org wrote: > > At Tue, 26 Aug 2008 14:50:33 +0000 (UTC), > > Bjoern A. Zeeb wrote: > > > >> On Tue, 26 Aug 2008, George V. Neville-Neil wrote: > >> > >> Hi, > >> > >> > >>> At Mon, 25 Aug 2008 21:40:38 +0200, > >>> John Hay wrote: > >>> > >>>> I have tried it and it does fix my problem. RIP2 over multicast works > >>>> again. :-) > >>>> > >>> Good to hear. I'm waiting on a bit more feedback but I think I'll be > >>> checking this in soon, with a big comment talking about the > >>> performance implications etc. > >>> > >> So wait a second; what was the m_pullup vs. m_dup thing? Has anyone > >> actually tried that? I mean using a sledgehammer if a mitten would be > >> enough is kind of .. uhm. You get it. > >> > > > > Perhaps I'm confused, I've been off dealing with other issues for a > > few days, but m_pullup doesn't make a copy of the packet or its > > fields, only makes sure that it's contiguous in memory. Am I wrong in that? > > > > Since the bug is that two pieces of code modify the same data, in ways > > that interfere, I'm not sure how we can avoid making a copy. It might > > be nice to limit the copy, but we'd still need two copies, one for the > > loopback device and one for the real device. > > > > > pull the headers up. copy just the headers. no deep copy. > I'm confused, if it's these lines that are screwed up: /* If needed, compute the checksum and mark it as valid. */ if (copym->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { in_delayed_cksum(copym); copym->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; copym->m_pkthdr.csum_flags |= CSUM_DATA_VALID | CSUM_PSEUDO_HDR; copym->m_pkthdr.csum_data = 0xffff; in particular that last line, then how does pulling up the header help? That's not part of the packet, that's the checksum data in the pkthdr itself. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 04:52:50 2008 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 055501065753; Wed, 27 Aug 2008 04:52:50 +0000 (UTC) (envelope-from imp@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B3B9F8FC13; Wed, 27 Aug 2008 04:52:49 +0000 (UTC) (envelope-from imp@FreeBSD.org) Received: from freefall.freebsd.org (imp@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7R4qiPZ051931; Wed, 27 Aug 2008 04:52:44 GMT (envelope-from imp@freefall.freebsd.org) Received: (from imp@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7R4qiSN051927; Tue, 26 Aug 2008 22:52:44 -0600 (MDT) (envelope-from imp) Date: Tue, 26 Aug 2008 22:52:44 -0600 (MDT) Message-Id: <200808270452.m7R4qiSN051927@freefall.freebsd.org> To: Danovitsch@Vitsch.net, imp@FreeBSD.org, freebsd-net@FreeBSD.org From: imp@FreeBSD.org Cc: Subject: Re: kern/77913: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) 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, 27 Aug 2008 04:52:50 -0000 Synopsis: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) State-Changed-From-To: open->patched State-Changed-By: imp State-Changed-When: Tue Aug 26 22:52:32 MDT 2008 State-Changed-Why: Committed to head. http://www.freebsd.org/cgi/query-pr.cgi?pr=77913 From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 05:00:04 2008 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 B2CAD1065680 for ; Wed, 27 Aug 2008 05:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 817B28FC14 for ; Wed, 27 Aug 2008 05:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7R5041S052142 for ; Wed, 27 Aug 2008 05:00:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7R504Pv052140; Wed, 27 Aug 2008 05:00:04 GMT (envelope-from gnats) Date: Wed, 27 Aug 2008 05:00:04 GMT Message-Id: <200808270500.m7R504Pv052140@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/77913: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2008 05:00:04 -0000 The following reply was made to PR kern/77913; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/77913: commit references a PR Date: Wed, 27 Aug 2008 04:53:30 +0000 (UTC) imp 2008-08-27 04:52:27 UTC FreeBSD src repository Modified files: sys/dev/pccard pccarddevs sys/dev/wi if_wi_pccard.c Log: SVN rev 182236 on 2008-08-27 04:52:27Z by imp The APDL-325 is a Wireless LAN pcmcia adapter that sits inside some Billion Access Points. Fix wi(4) to recognise the adapter. PR: 77913 Submitted by: Daan Vreeken [PA4DAN] MFC after: 3 days Revision Changes Path 1.135 +1 -0 src/sys/dev/pccard/pccarddevs 1.62 +1 -0 src/sys/dev/wi/if_wi_pccard.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 05:00:07 2008 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 B249A1065670 for ; Wed, 27 Aug 2008 05:00:07 +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 80EED8FC1D for ; Wed, 27 Aug 2008 05:00:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7R5073b052247 for ; Wed, 27 Aug 2008 05:00:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7R507e6052246; Wed, 27 Aug 2008 05:00:07 GMT (envelope-from gnats) Date: Wed, 27 Aug 2008 05:00:07 GMT Message-Id: <200808270500.m7R507e6052246@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/77913: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2008 05:00:07 -0000 The following reply was made to PR kern/77913; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/77913: commit references a PR Date: Wed, 27 Aug 2008 04:56:01 +0000 (UTC) imp 2008-08-27 04:55:37 UTC FreeBSD src repository Modified files: share/man/man4 wi.4 Log: SVN rev 182238 on 2008-08-27 04:55:37Z by imp Add recent ELSA additions to wi(4), plus make sure the list matches the driver for ELSA. PR: 77913 Submitted by: Daan Vreeken MFC after: 3 days Revision Changes Path 1.79 +3 -0 src/share/man/man4/wi.4 _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 06:32:24 2008 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 30AF61065670; Wed, 27 Aug 2008 06:32:24 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E12198FC16; Wed, 27 Aug 2008 06:32:23 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7R6WN2i067315; Wed, 27 Aug 2008 06:32:23 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7R6WNOO067311; Wed, 27 Aug 2008 06:32:23 GMT (envelope-from remko) Date: Wed, 27 Aug 2008 06:32:23 GMT Message-Id: <200808270632.m7R6WNOO067311@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/126874: [vlan]: Zebra problem if ifconfig vlanX destroy 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, 27 Aug 2008 06:32:24 -0000 Old Synopsis: Zebra problem if ifconfig vlanX destroy New Synopsis: [vlan]: Zebra problem if ifconfig vlanX destroy Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Aug 27 06:31:52 UTC 2008 Responsible-Changed-Why: Move to the -net list. http://www.freebsd.org/cgi/query-pr.cgi?pr=126874 From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 11:14:33 2008 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 D5B6F1065676 for ; Wed, 27 Aug 2008 11:14:33 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from hatert.nijmegen.internl.net (mailrelay1.nijmegen.internl.net [217.149.192.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9948FC1B for ; Wed, 27 Aug 2008 11:14:33 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtp20.nijmegen.internl.net by hatert.nijmegen.internl.net via smtp20.nijmegen.internl.net [217.149.192.18] with ESMTP for id m7R97bwD001138 (8.13.6/2.04); Wed, 27 Aug 2008 11:07:37 +0200 (MEST) Received: from mail.bsd4all.org (113-9.bbned.dsl.internl.net [82.215.9.113]) by smtp20.nijmegen.internl.net (8.13.8/2.04) with ESMTP id m7R97Y1w026107 for ; Wed, 27 Aug 2008 11:07:34 +0200 (CEST) Received: from localhost (mailgw [192.168.1.12]) by mail.bsd4all.org (Postfix) with ESMTP id 1EEE65083D for ; Wed, 27 Aug 2008 11:07:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from mail.bsd4all.org ([192.168.1.1]) by localhost (fwgw.homebrew.bsd4all.org [192.168.1.12]) (amavisd-new, port 10024) with ESMTP id qDav9xaVmWed for ; Wed, 27 Aug 2008 11:07:25 +0200 (CEST) Received: from bsd4all.org (adexlinge10 [192.168.10.16]) by mail.bsd4all.org (Postfix) with ESMTP id D92CA50834 for ; Wed, 27 Aug 2008 11:07:24 +0200 (CEST) Received: from 128.221.197.21 ([128.221.197.21]) by adexlinge10.LINGE10.local ([192.168.10.16]) with Microsoft Exchange Server HTTP-DAV ; Wed, 27 Aug 2008 09:07:23 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 27 Aug 2008 11:07:23 +0200 From: Peter BLOK To: Message-ID: Thread-Topic: Signal quality/strength of FreeBSD hostap vs. commercial products Thread-Index: AckIJFElgoeYhFmlPkOatfeZz+oMug== Mime-version: 1.0 X-Mailman-Approved-At: Wed, 27 Aug 2008 11:27:24 +0000 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Signal quality/strength of FreeBSD hostap vs. commercial products 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, 27 Aug 2008 11:14:33 -0000 Hi, I am trying to build a FreeBSD wireless router for a while and I noticed that the signal strength is always substantial lower compared to common available wireless routers. At first I thought it was due to the wireless card I used, but I have tried several different ones and several different antennas, but it doesn=B9t come close to common routers. Strangely enough when I started to use an adhoc connection, the signal strength reported was as good as a common router. For clients I have used different cards as well as Windoze and MACOSX. Setting of txpower doesn=B9t do anything. Any explanations? Peter From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 11:37:46 2008 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 932B31065683; Wed, 27 Aug 2008 11:37:46 +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 6329F8FC1F; Wed, 27 Aug 2008 11:37:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7RBbkcu023179; Wed, 27 Aug 2008 11:37:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7RBbk7F023175; Wed, 27 Aug 2008 11:37:46 GMT (envelope-from linimon) Date: Wed, 27 Aug 2008 11:37:46 GMT Message-Id: <200808271137.m7RBbk7F023175@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/126822: wpa_supplicant(8): WPA PSK does not work in adhoc mode. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2008 11:37:46 -0000 Old Synopsis: wpa_supplicant - WPA PSK does not work in adhoc mode. New Synopsis: wpa_supplicant(8): WPA PSK does not work in adhoc mode. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 27 11:37:04 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126822 From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 19:18:17 2008 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 8005A1065670; Wed, 27 Aug 2008 19:18:17 +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 5E1BF8FC14; Wed, 27 Aug 2008 19:18:17 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7RJIHeF062784; Wed, 27 Aug 2008 19:18:17 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7RJIHlR062780; Wed, 27 Aug 2008 19:18:17 GMT (envelope-from linimon) Date: Wed, 27 Aug 2008 19:18:17 GMT Message-Id: <200808271918.m7RJIHlR062780@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/126895: [patch] [ral] Add antenna selection (marked as TBD) 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, 27 Aug 2008 19:18:17 -0000 Synopsis: [patch] [ral] Add antenna selection (marked as TBD) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 27 19:17:53 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126895 From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 21:40:04 2008 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 1644D1065670 for ; Wed, 27 Aug 2008 21:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D009E8FC17 for ; Wed, 27 Aug 2008 21:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7RLe3gu076506 for ; Wed, 27 Aug 2008 21:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7RLe33F076505; Wed, 27 Aug 2008 21:40:03 GMT (envelope-from gnats) Date: Wed, 27 Aug 2008 21:40:03 GMT Message-Id: <200808272140.m7RLe33F076505@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Dimitry Andric Cc: Subject: Re: kern/125502: [ral] ifconfig ral0 scan produces no output unless in shared mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dimitry Andric List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2008 21:40:04 -0000 The following reply was made to PR kern/125502; it has been noted by GNATS. From: Dimitry Andric To: bug-followup@FreeBSD.org, chelton30@gmail.com Cc: Subject: Re: kern/125502: [ral] ifconfig ral0 scan produces no output unless in shared mode Date: Wed, 27 Aug 2008 23:36:46 +0200 The ral I've got here on RELENG_7 is a mini-PCI card: ral0: mem 0xdfef8000-0xdfefffff irq 18 at device 2.0 on pci2 ral0: MAC/BBP RT2561C, RF RT5225 ral0: Ethernet address: 00:12:0e:61:48:e4 ral0: [ITHREAD] I've got exactly the same as the original submitter: "ifconfig ral0 scan" keeps busy forever, and never returns, if authmode is open. When I set authmode to shared, it scans within a few seconds, usually. When turning on +scan+auth+debug+assoc, I get the following for authmode shared: ral0: scan_next: chan 2g -> 1g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 1 ral0: scan_next: chan 1g -> 6g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 6 ral0: scan_next: chan 6g -> 11g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 11 ral0: scan_next: chan 11g -> 7g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 7 ral0: scan_next: chan 7g -> 13g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 13 ral0: scan_next: chan 13g -> 52a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 52 ral0: scan_next: chan 52a -> 56a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 56 ral0: scan_next: chan 56a -> 60a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 60 ral0: scan_next: chan 60a -> 64a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 64 ral0: scan_next: chan 64a -> 36a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 36 ral0: scan_next: chan 36a -> 40a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 40 ral0: scan_next: chan 40a -> 44a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 44 ral0: ieee80211_start_scan: active scan already in progress ral0: scan_next: chan 44a -> 48a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 48 ral0: scan_next: chan 48a -> 2g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 2 ral0: received probe_resp from 00:90:4c:60:04:00 rssi 27 [00:90:4c:60:04:00] new probe_resp on chan 2 (bss chan 2) "slackernet" [00:90:4c:60:04:00] caps 0x411 bintval 100 erp 0x0 ral0: ieee80211_add_scan: chan 2g min dwell met (8236357 > 8236355) ral0: received beacon from 00:90:4c:60:04:00 rssi 27 [00:90:4c:60:04:00] new beacon on chan 2 (bss chan 2) "slackernet" [00:90:4c:60:04:00] caps 0x411 bintval 100 erp 0x0 ral0: scan_next: chan 2g -> 3g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 3 ral0: scan_next: chan 3g -> 4g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 4 ral0: received probe_resp from 00:1b:2f:de:86:1e rssi 17 ral0: received beacon from 00:1b:2f:de:86:1e rssi 17 ral0: scan_next: chan 4g -> 5g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 5 ral0: received probe_resp from 00:1b:2f:de:86:1e rssi 15 [00:1b:2f:de:86:1e] new probe_resp on chan 5 (bss chan 5) "pipi" [00:1b:2f:de:86:1e] caps 0x431 bintval 100 erp 0x0 ral0: ieee80211_add_scan: chan 5g min dwell met (8236845 > 8236843) ral0: received beacon from 00:1b:2f:de:86:1e rssi 15 [00:1b:2f:de:86:1e] new beacon on chan 5 (bss chan 5) "pipi" [00:1b:2f:de:86:1e] caps 0x431 bintval 100 erp 0x0 ral0: scan_next: chan 5g -> 8g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 8 ral0: scan_next: chan 8g -> 9g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 9 ral0: scan_next: chan 9g -> 10g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 10 ral0: scan_next: chan 10g -> 12g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 12 ral0: scan_next: chan 12g -> 14g [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 14 ral0: scan_next: chan 14g -> 149a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 149 ral0: scan_next: chan 149a -> 153a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 153 ral0: scan_next: chan 153a -> 157a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 157 ral0: scan_next: chan 157a -> 161a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 161 ral0: scan_next: chan 161a -> 100a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 100 ral0: scan_next: chan 100a -> 104a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 104 ral0: scan_next: chan 104a -> 108a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 108 ral0: scan_next: chan 108a -> 112a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 112 ral0: scan_next: chan 112a -> 116a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 116 ral0: scan_next: chan 116a -> 120a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 120 ral0: scan_next: chan 120a -> 124a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 124 ral0: scan_next: chan 124a -> 128a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 128 ral0: scan_next: chan 128a -> 132a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 132 ral0: scan_next: chan 132a -> 136a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 136 ral0: scan_next: chan 136a -> 140a [active, dwell min 20 max 200] ral0: [ff:ff:ff:ff:ff:ff] send probe req on channel 140 ral0: macaddr bssid chan rssi rate flag wep essid - 00:90:4c:60:04:00 00:90:4cral0: received beacon from 00:90:4c:60:04:00 rssi 27 [00:90:4c:60:04:00] new beacon on chan 2 (bss chan 2) "slackernet" [00:90:4c:60:04:00] caps 0x411 bintval 100 erp 0x0 :60:04:00 2 30 54M ess wep! "slackernet" - 00:1b:2f:de:86:1e 00:1b:2f:de:86:1e 5 16 54M ess wep! "pipi" ral0: ieee80211_add_scan: chan 2g min dwell met (8241192 > 8240968) ral0: scan_next: done, restart [ticks 8241200, dwell min 20 scanend 2155701896] ...and this in an endless loop, of course. But the ifconfig *does* return. When authmode is open, I get exactly the same messages, but ifconfig doesn't return. The last thing it appears to do, according to ktrace, is to read from a socket: ... 2544 ifconfig CALL __sysctl(0xbfbfe2c0,0x6,0,0xbfbfe2d8,0,0) 2544 ifconfig RET __sysctl 0 2544 ifconfig CALL __sysctl(0xbfbfe2c0,0x6,0x8102000,0xbfbfe2d8,0,0) 2544 ifconfig RET __sysctl 0 2544 ifconfig CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_IP) 2544 ifconfig RET socket 3 2544 ifconfig CALL socket(PF_ROUTE,SOCK_RAW,0) 2544 ifconfig RET socket 4 2544 ifconfig CALL ioctl(0x3,SIOCS80211,0xbfbfe290) 2544 ifconfig RET ioctl 0 2544 ifconfig CALL read(0x4,0xbfbfda90,0x800) and here it hangs, until interrupted. From owner-freebsd-net@FreeBSD.ORG Thu Aug 28 00:30:32 2008 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 A852E1065670 for ; Thu, 28 Aug 2008 00:30:32 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by mx1.freebsd.org (Postfix) with ESMTP id 382468FC13 for ; Thu, 28 Aug 2008 00:30:31 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so99425fkk.11 for ; Wed, 27 Aug 2008 17:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent :sender; bh=bGO3OiYY+XkZXhHNgHu21Io9C1CQkbPolHD2ig/156Y=; b=hPup3/7QRKc7qnDHQqejTEwzy48wiwYnp7PgL4jnt3Hh0/VUIllF3ZBXut5tGH4oSc SGmBZCrE7iJExms8KTAa9Q0zoG3c9b1jU/9nQZdMxrAnQoTI3nC9+efenMWWcnoANGYs N7lL95qbXGsUn/cNEy6PUoKLfcR+bO5tbSkzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent:sender; b=nS4J1w2FclWzkWSLliR4/ziLzJipu67NWdh3GRZqhaixD8p8B2U3OI8bL/Fh87qiN3 v2KIx1EVwfu8CTc3gopK2RNOR0BUoOy7uyZdyEHP2xEcEbXjnCjIAWcqbjEjk5hdzTt4 LgL4US3345fJQ1FU1XN+x8VzeWxo3mpH1NwNU= Received: by 10.181.22.8 with SMTP id z8mr842366bki.78.1219883430809; Wed, 27 Aug 2008 17:30:30 -0700 (PDT) Received: from alpha.local ( [83.144.140.92]) by mx.google.com with ESMTPS id u14sm1039503gvf.6.2008.08.27.17.30.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Aug 2008 17:30:30 -0700 (PDT) Received: by alpha.local (Postfix, from userid 1001) id 30343497; Thu, 28 Aug 2008 01:29:19 +0100 (WEST) Date: Thu, 28 Aug 2008 01:29:19 +0100 From: Rui Paulo To: freebsd-current@freebsd.org, freebsd-mobile@freebsd.org, freebsd-net@freebsd.org Message-ID: <20080828002919.GA54169@alpha.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Rui Paulo Cc: Subject: HEADS UP: ath_hal updated to 0.10.5.10 -- PLEASE TEST 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, 28 Aug 2008 00:30:32 -0000 Hi, We've updated ath_hal in HEAD to 0.10.5.10. This supports a couple of new chips, namely those on the Asus Eee PC, MacBooks and other laptops. If you have an Atheros or Atheros based card, I really wanted you to test it. We were unable to test this in several Atheros chipsets, so if you find a regression, please contact me or Sam Leffler (sam@freebsd.org) ASAP. So, please give it a try :-) Unfortuntely, this will only make 7.1 if the release date slips. So, don't expect this to be MFCed any time soon. Thanks, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Thu Aug 28 11:00:16 2008 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 58A2D1065697 for ; Thu, 28 Aug 2008 11:00:16 +0000 (UTC) (envelope-from slawek.zak@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id DED558FC16 for ; Thu, 28 Aug 2008 11:00:15 +0000 (UTC) (envelope-from slawek.zak@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so254834fgb.35 for ; Thu, 28 Aug 2008 04:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/o4TF4UxUUYzBQT2iZ+yYVzGhL68c9wfCFCp0ioAK/Q=; b=LGWcS8w7zqkeqmC8rNDneVaa+RuDFbYtdN82BYqYnQNBtCiSly0OhyTjC8OyKAQzi1 UvyF29VLHuSHbx2tB1PObraskM9Nl3Qvz2dmT37rOu60vj4dqw250bi8TOIyIY3LTHCV uelBrqZDkTvQIJU7eevvKivdqPHqWsu1d5MDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=VA9eFH/Ouxzqtol4CzMvM0IsANnkkdVetrY4w1J2UiYjMrnqwHlEdp0aiwH4nOO/jz MTCLz3lmMLFWCpUpqALUinJgRR+WKMu34LWECyiyBXOQ5zmJ7w5z4FcDze6Tj1/N9A+j rD+VbZ3zlSN0yV9+HSxqeaQoc4x3g1epX70E8= Received: by 10.180.234.2 with SMTP id g2mr1863047bkh.54.1219921214384; Thu, 28 Aug 2008 04:00:14 -0700 (PDT) Received: by 10.180.250.12 with HTTP; Thu, 28 Aug 2008 04:00:14 -0700 (PDT) Message-ID: <787bbe1c0808280400r7933f520t97f862eb8232ac49@mail.gmail.com> Date: Thu, 28 Aug 2008 13:00:14 +0200 From: "Slawek Zak" To: "Artis Caune" In-Reply-To: <200808251010.m7PAA4Mk018658@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808251010.m7PAA4Mk018658@freefall.freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address 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, 28 Aug 2008 11:00:16 -0000 Hey Artis, Thank you. It really works indeeed :) I haven't thought of such a workaround :) Regards, /S On Mon, Aug 25, 2008 at 12:10 PM, Artis Caune wrote: > The following reply was made to PR kern/126714; it has been noted by GNATS. > > From: "Artis Caune" > To: bug-followup@freebsd.org > Cc: slawek.zak@gmail.com > Subject: Re: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address > Date: Mon, 25 Aug 2008 13:05:55 +0300 > > Same for me, but when I rename carp interface to original name, > everything works. > > > > > When you change carp0 name to new_name, ifconfig will: > - announce that carp0 is gone (departure) > - copy new_name to if_xname > - announce that new_name has arrived > > carp check only departure events. > > When you change name of carp interface, mac address also change: > from 00:00:5e:00:01:08 to 70:31:00:00:5e:00 (for me) > > And because new mac address is no longer CARP mac address, > carp_forus() fail, M_PROMISC flag is not cleared and frame is > discarded. > > > > > If you need change names at run time and not in rc.conf, then you > should reinitialize carp interface: > # ifconfig new_name vhid 1 pass testpass 192.168.0.2/24 > or set promisc flag on em0/em1 :) > > btw, don't change name to "carp" or your box will panic. > > p.s. > if you change name to underlying em0/em1/lagg/vlan interface, you > should also reinitialize carp interface or you will see: > carp_input: packet received on non-carp interface: bce0 > > > > > -- > regards, > Artis Caune > > <----. CCNA > <----|==================== > <----' didii FreeBSD > _______________________________________________ > 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 Aug 28 11:39:00 2008 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 046641065678 for ; Thu, 28 Aug 2008 11:39:00 +0000 (UTC) (envelope-from randall@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:203:6dff:fe1a:4ddc]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD768FC15 for ; Thu, 28 Aug 2008 11:38:59 +0000 (UTC) (envelope-from randall@lakerest.net) Received: from [10.1.1.54] ([10.1.1.54]) (authenticated bits=0) by lakerest.net (8.14.1/8.14.1) with ESMTP id m7SBcslf020048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Aug 2008 07:38:55 -0400 (EDT) (envelope-from randall@lakerest.net) DKIM-Signature: a=rsa-sha1; c=simple/simple; d=lakerest.net; s=mail; t=1219923535; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=2U87uDr//IcuNizRV9ffatrbrClmDZHjtNCzZDxzd7SoRZOQH+b8hLm DPZEbbcnPBrMw19j6iNuvwKZqeZ37wA== Message-Id: <0ED8CE06-588C-4A04-BE8D-CCD8DA2C945D@lakerest.net> From: Randy Stewart To: sazzadur rahman In-Reply-To: <82bdb5ec0807021137m7819153rbc0631ab6f310d0e@mail.gmail.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 28 Aug 2008 07:38:54 -0400 References: <7059EA19D7837E44A3BA7DAB464944B37FDA715193@XMAIL5.sooner.net.ou.edu> <48060748.1090807@cisco.com> <82bdb5ec0807021137m7819153rbc0631ab6f310d0e@mail.gmail.com> X-Mailer: Apple Mail (2.926) Cc: freebsd-net , atiq@ou.edu, "Rahman, Md Sazzadur" Subject: Re: A query regarding SCTP congestion control 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, 28 Aug 2008 11:39:00 -0000 Remember a lot has changed between the book and now. 1) The initial window is now different 2) labc variable may influence how the cwnd responds are just 2 off the top of my head. You also may want to use a local trace buffer (as I mentioned earlier) =20= since turning KTR on really really skew's things time wise.. its a resource =20= pig. We added the local trace buffer for this very reason. Contact me directly if you need guidance on this. Also you may want to pick up the latest update that I just put up on www.sctp.org It gets the 7.0 stack current to 8.0's code.. .and there have been at least 1 CC fix in the last few months.. R On Jul 2, 2008, at 2:37 PM, sazzadur rahman wrote: > Hello, > I need to get SCTP congestion window data for research purpose. I =20 > collected > cwnd data from SCTP sender running on FreeBSD 7.0 machine by using KTR > kernel log. After that, I tried to plot cwnd vs. time and generated =20= > graph. > But I am unable to explain the graph and it is very different =20 > compared to > the graph as shown in the book "Stream Control Transmission Protocol > (SCTP)", a reference guide by Randall R. Stewart, page 187 and TCP > congestion window. An typical entry from the log looks like: > > 749199232185105 Net:0xc7703000 at cwnd_event (SACK) cwnd:25140 =20 > flight:0 pq:0 > atpc:72 needpc:235 (tsn:0,sendcnt:191,strcnt:191) > > I have used 749199232185105 in x axis as time and cwnd:25140 in y =20 > axis. I > have attached the image file of the graph herewith this mail. > >> =46rom the log, I found that cwnd varies very frequently accross =20 >> time. Does > anyone have any idea regarding this issue? > Please let me know if you have any questions further. > > Thanks in advance. > > Best regards, > Md Sazzadur Rahman > Graduate Student, > School of Computer Science, > University of Oklahoma, > Norman, Oklahoma, USA > > Steps for getting kernel log > > ------------------------------------------ > > 1. Add options: > > options KTR > > options KTR_ENTRIES=3D65536 > > options KTR_MASK=3DKTR_SUBSYS > > > 2. Recompile kernel > > config CUSTOM_KERNEL_9_6 > > cd ../compile/ CUSTOM_KERNEL_9_6 > > make cleandepend;make depend; > > make all install > > 3. Tried to enable trace point by: > > Sysctl -w "net.inet.sctp.log_level=3D0x00000004" > > 4. run SCTP sender. > > 5. pull out data: > > Ktrdump =96q =96t =96o file_name > > Prtcwndlog =96l filename > cwnd.txt > > --------------------------------------------------- > > > > On Wed, Apr 16, 2008 at 9:03 AM, Randall Stewart =20 > wrote: > >> Rahman, Md Sazzadur wrote: >> >>> Hi, I would like to get the values of SCTP congestion control >>> algorithm variables (cwnd, ssthresh, flightsize and pba) from any >>> SCTP based application in runtime for research purpose. Does any API >>> exist in SCTP for that? Do I need to dig the SCTP code in kernel to >>> get the values? >>> >> >> There is a socket option to get the cwnd. >> >> However, I think what you really want is some of the researchish >> tracing stuff that SCTP provides. >> >> You can actually get a real time trace of the cwnd/flight etc via the >> various logging functions. >> >> You basically must compile this as an option.. have to go look >> at the options.. >> >> And then you can either use ktrace (which I don't recommend since >> it turns on to much overhead in the kernel) or you can >> use SCTP_LOCAL_TRACE_BUF >> >> This will put it into a piece of memory only for SCTP and >> not turn on all the other ktrace points. >> >> After you enable the logging in your compile you must turn >> on the logging level.. >> >> SCTP_CWND_LOGGING_ENABLE >> >> woudl be my recommendation. >> >> It gives you a real time up/down growth of the cwnd/flight/rwnd >> >> I think I wrote a "how to" somewhere.. let me go look.. >> >> R >> >> >> >>> I will appreciate any help in this regard. >>> >>> Best Regards, Md Sazzadur Rahman Graduate Student, School of =20 >>> Computer >>> Science, University of Oklahoma, Norman, Oklahoma, USA >>> >>> _______________________________________________ = freebsd-net@freebsd.orgmailing=20 >>> list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net To =20 >>> unsubscribe, >>> send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> >> >> -- >> Randall Stewart >> NSSTG - Cisco Systems Inc. >> 803-345-0369 803-317-4952 (cell) >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-=20 >> unsubscribe@freebsd.org" >> > _______________________________________________ > 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" ----- Randall Stewart randall@lakerest.net From owner-freebsd-net@FreeBSD.ORG Thu Aug 28 16:42:58 2008 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 11E50106567E; Thu, 28 Aug 2008 16:42:58 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DBCEF8FC26; Thu, 28 Aug 2008 16:42:57 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7SGgv2V011303; Thu, 28 Aug 2008 16:42:57 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7SGgvqR011299; Thu, 28 Aug 2008 16:42:57 GMT (envelope-from gavin) Date: Thu, 28 Aug 2008 16:42:57 GMT Message-Id: <200808281642.m7SGgvqR011299@freefall.freebsd.org> To: read@midland.com.ua, gavin@FreeBSD.org, freebsd-net@FreeBSD.org, gavin@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/102344: [ipf] Some packets do not pass through network 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: Thu, 28 Aug 2008 16:42:58 -0000 Synopsis: [ipf] Some packets do not pass through network interface State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Aug 28 16:40:54 UTC 2008 State-Changed-Why: Feedback timeout (1 year today). To submitter: if you do still see this issue and can provide the required information, we can reopen the PR. Responsible-Changed-From-To: freebsd-net->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Aug 28 16:40:54 UTC 2008 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=102344 From owner-freebsd-net@FreeBSD.ORG Thu Aug 28 17:36:56 2008 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 0BCA21065674; Thu, 28 Aug 2008 17:36:56 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D42428FC12; Thu, 28 Aug 2008 17:36:55 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7SHatbI017021; Thu, 28 Aug 2008 17:36:55 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7SHatd6017017; Thu, 28 Aug 2008 17:36:55 GMT (envelope-from gavin) Date: Thu, 28 Aug 2008 17:36:55 GMT Message-Id: <200808281736.m7SHatd6017017@freefall.freebsd.org> To: zaphod@fsklaw.com, gavin@FreeBSD.org, freebsd-net@FreeBSD.org, gavin@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: conf/122858: [nsswitch.conf] nsswitch in 7.0 is f*cked up 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, 28 Aug 2008 17:36:56 -0000 Synopsis: [nsswitch.conf] nsswitch in 7.0 is f*cked up State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Aug 28 17:33:46 UTC 2008 State-Changed-Why: Feedfback timeout (~3 months). Looks like it was a config error, but without feedback we'll never know. Responsible-Changed-From-To: freebsd-net->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Aug 28 17:33:46 UTC 2008 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=122858 From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 03:18:30 2008 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 504C51065678 for ; Fri, 29 Aug 2008 03:18:30 +0000 (UTC) (envelope-from jacoblowens@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id CAA288FC1A for ; Fri, 29 Aug 2008 03:18:29 +0000 (UTC) (envelope-from jacoblowens@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so191671eyi.7 for ; Thu, 28 Aug 2008 20:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=lEF6lMtwAwVkh+E9IS85u4GMOWpHjdipRtM+Og3g2sE=; b=QckgbFnaTh9RZiut49p5AEbg414VVaD6Q6V3X242VrQZjncyEwLjXB7eAE5lLHq49U b6WhMUSPRB/GAsaAczgxE1WmnMJZ1W+WekuX4VWta7lGTu0BR65er5Wm+ODBlFV192Ca hUszCr5y6ZIcGEmRKJEfp7pit4U7wUI9C86I0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=ajPO+VbpV7R0zH61aX3EDLnKvTtdycctAonA6wRXi9EL3RoCiexSrebmP4DH2oq6RQ BbjemUlXAclwOYcjz1KpCzYkCbMPCdh/pQnz+AnAKPiKRfzIr/FhWZ2BPQXknrExfk8t jCCf1wREVaCk3B8vYHocLZF5TiANb0MLa1p0g= Received: by 10.210.71.12 with SMTP id t12mr887388eba.36.1219979908147; Thu, 28 Aug 2008 20:18:28 -0700 (PDT) Received: by 10.210.116.9 with HTTP; Thu, 28 Aug 2008 20:18:28 -0700 (PDT) Message-ID: Date: Thu, 28 Aug 2008 22:18:28 -0500 From: "Jacob Owens" To: freebsd-net@freebsd.org In-Reply-To: <20080813044809.GD58659@cdnetworks.co.kr> MIME-Version: 1.0 References: <20080809082539.GC42339@cdnetworks.co.kr> <20080812013739.GB54362@cdnetworks.co.kr> <20080813044809.GD58659@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: lagg failover not automatic 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, 29 Aug 2008 03:18:30 -0000 To resolve the issue, Pyun first had my patch amphy.c , then the dc driver. The DC patch fixed my issue. Here is what i had to do: 1. save attached patch to /tmp 2. #cd /usr/src 3. #patch -p0 < /tmp/dc.patch 4. rebuild/install kernel and reboot. i used instructions from here: http://www.freebsdmadeeasy.com/tutorials/freebsd/recompiling-the-kernel-in-freebsd.php THANK YOU to Pyun YongHyeon and the freebsd-net group for helping me with this issue!!! Save the text below and save as dc.patch. (The first line is 'index: sys/dev/dc......' ,Last line is ' * When the init.....' Index: sys/dev/dc/if_dc.c =================================================================== --- sys/dev/dc/if_dc.c (revision 181654) +++ sys/dev/dc/if_dc.c (working copy) @@ -2868,6 +2868,12 @@ ifp = sc->dc_ifp; mii = device_get_softc(sc->dc_miibus); + /* + * XXX Can cause autonegotiation failure on certain models + * as DC21143 overdrive mii_ticks. + */ + mii_tick(mii); + if (sc->dc_flags & DC_REDUCED_MII_POLL) { if (sc->dc_flags & DC_21143_NWAY) { r = CSR_READ_4(sc, DC_10BTSTAT); @@ -2881,19 +2887,15 @@ sc->dc_link = 0; mii_mediachg(mii); } - if (sc->dc_link == 0) - mii_tick(mii); } else { r = CSR_READ_4(sc, DC_ISR); if ((r & DC_ISR_RX_STATE) == DC_RXSTATE_WAIT && sc->dc_cdata.dc_tx_cnt == 0) { - mii_tick(mii); if (!(mii->mii_media_status & IFM_ACTIVE)) sc->dc_link = 0; } } - } else - mii_tick(mii); + } /* * When the init routine completes, we expect to be able to send On Tue, Aug 12, 2008 at 11:48 PM, Pyun YongHyeon wrote: > > On Tue, Aug 12, 2008 at 08:49:20AM -0500, Jacob Owens wrote: > > pyun, > > > > Thank you! I am not familiar with patching freebsd. i tried: > > > > # patch < amphy.diff > > > > then it asked me to pick a file.i entered: /sys/dev/mii/amphy.c > > > > then i recompiled my kernel. I don't know if the patch was applied > > correctly. either way, it didn't change anything. > > > > Thanks for testing! I've checked dc(4) and link state checking code > in the driver looks questionable. So I made a patch but I don't > know whether it helps or not. The patch can even break establishing > link so you should be very careful before applying the patch and > should not apply the patch if you have no physical acesss to the > hardware. Would you give it a try? > > Note, I'm not familiar with dc(4) and dc(4) supports too many > variants. It seems that each controller needs different workaround > to overcome its hardware limitation. Link state handling seems to > be one of reason why dc(4) didn't periodically invoke link state > check clock. I would be on vacation from Aug 14 for a week so don't > expect quick reply. > > # You can apply the patch with the following command. > 1. save attached patch to /tmp > 2. #cd /usr/src > 3. #patch -p0 < /tmp/dc.patch > 4. rebuild/install kernel and reboot. > > -- > Regards, > Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 03:46:15 2008 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 560DA1065681 for ; Fri, 29 Aug 2008 03:46:15 +0000 (UTC) (envelope-from jlin2918@yahoo.com) Received: from web58308.mail.re3.yahoo.com (web58308.mail.re3.yahoo.com [68.142.236.161]) by mx1.freebsd.org (Postfix) with SMTP id D9C788FC18 for ; Fri, 29 Aug 2008 03:46:14 +0000 (UTC) (envelope-from jlin2918@yahoo.com) Received: (qmail 73204 invoked by uid 60001); 29 Aug 2008 03:19:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=yb+3vR5Np4PWLytDUamjganLY0B6iUxHTta2R496vABKW84LYQ5yMd4i2c9I2JfO/BPGOSgOoQZZQv3LJY1H4cn5BzzgKvBFN72WDyirvVeLrl8dSxnLPRm0iZCM2wBuOcFAEkHnoO9U8Xy5T2/iqfjHzDK/J9sj+MfPHkDAzIg=; X-YMail-OSG: kBpwlOkVM1kJ6.OTMbfMJ05pNEAsPOT3awtaFH2SO0_HBVindw39j3kQ3DZ90mOY103WVN0BGK33CBiAyZpZ_TNPg1AHO3Jr3ZP4y6FcGVzbOgJnObhv502Vt7OBsZc- Received: from [84.62.151.33] by web58308.mail.re3.yahoo.com via HTTP; Thu, 28 Aug 2008 20:19:32 PDT X-Mailer: YahooMailWebService/0.7.218.2 Date: Thu, 28 Aug 2008 20:19:32 -0700 (PDT) From: John Lingate To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <325689.70498.qm@web58308.mail.re3.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Quagga OSPF binds to wrong interface on FreeBSD 7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jlin2918@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 03:46:15 -0000 This bug was reported around the release of FreeBSD 7, but does not seem to= have made any progress.=20 http://bugzilla.quagga.net/show_bug.cgi?id=3D420 Is this because the sockopt.c.diff patch is correct, which isn't entirely c= lear from the following comments, or is there some other solution to this p= roblem?=A0 Thanks! =0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 03:59:02 2008 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 42C88106564A for ; Fri, 29 Aug 2008 03:59:02 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 92FE38FC19 for ; Fri, 29 Aug 2008 03:59:01 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m7T3wwDt084955; Fri, 29 Aug 2008 11:58:58 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m7T3ww7t084953; Fri, 29 Aug 2008 11:58:58 +0800 (KRAST) (envelope-from eugen) Date: Fri, 29 Aug 2008 11:58:58 +0800 From: Eugene Grosbein To: John Lingate Message-ID: <20080829035858.GA83708@svzserv.kemerovo.su> References: <325689.70498.qm@web58308.mail.re3.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <325689.70498.qm@web58308.mail.re3.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Quagga OSPF binds to wrong interface on FreeBSD 7 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, 29 Aug 2008 03:59:02 -0000 On Thu, Aug 28, 2008 at 08:19:32PM -0700, John Lingate wrote: > This bug was reported around the release of FreeBSD 7, but does not seem to have made any progress. > > http://bugzilla.quagga.net/show_bug.cgi?id=420 > > Is this because the sockopt.c.diff patch is correct, which isn't entirely clear from the following comments, or is there some other solution to this problem?  Thanks! You should contact with ports/net/quagga maintainer to push temporary patch into Ports Tree until quagga developers settle with something working. This always was most productive way for us. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 06:56:13 2008 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 5DC701065670 for ; Fri, 29 Aug 2008 06:56:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 1380D8FC1C for ; Fri, 29 Aug 2008 06:56:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 32359249A; Thu, 28 Aug 2008 23:56:13 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 654E42D603A; Thu, 28 Aug 2008 23:56:12 -0700 (PDT) Message-ID: <48B79D91.7040303@elischer.org> Date: Thu, 28 Aug 2008 23:56:17 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: jlin2918@yahoo.com References: <325689.70498.qm@web58308.mail.re3.yahoo.com> In-Reply-To: <325689.70498.qm@web58308.mail.re3.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Quagga OSPF binds to wrong interface on FreeBSD 7 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, 29 Aug 2008 06:56:13 -0000 John Lingate wrote: > This bug was reported around the release of FreeBSD 7, but does not seem to have made any progress. > > http://bugzilla.quagga.net/show_bug.cgi?id=420 > > Is this because the sockopt.c.diff patch is correct, which isn't > entirely clear from the following comments, or is there some other > solution to this problem? Thanks! the change in quesiton is in the QUAGGA code not in the BSD code. > > > > > _______________________________________________ > 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 Fri Aug 29 10:28:34 2008 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 037D01065670 for ; Fri, 29 Aug 2008 10:28:34 +0000 (UTC) (envelope-from jlin2918@yahoo.com) Received: from web58301.mail.re3.yahoo.com (web58301.mail.re3.yahoo.com [68.142.236.154]) by mx1.freebsd.org (Postfix) with SMTP id B6E6A8FC13 for ; Fri, 29 Aug 2008 10:28:33 +0000 (UTC) (envelope-from jlin2918@yahoo.com) Received: (qmail 42499 invoked by uid 60001); 29 Aug 2008 10:28:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=UH51RIo1e+i0iZKrVRxqDiycV1pbiR7aRve1jlOpoxnlpoWtO9V0/a1Katr0EWIYQKIkeNjoyxi4MPi0T4zwD1FAQ6P5r2uQJtmbE6aQsU+HPur401CLh58ztAICkZ1b+PTEPq5SKQkpxMOF7x64LDa9lqA+wtAe7oyDsgHE60g=; Received: from [217.227.116.127] by web58301.mail.re3.yahoo.com via HTTP; Fri, 29 Aug 2008 03:28:32 PDT X-Mailer: YahooMailWebService/0.7.218.2 Date: Fri, 29 Aug 2008 03:28:32 -0700 (PDT) From: John Lingate To: Julian Elischer MIME-Version: 1.0 Message-ID: <886514.39448.qm@web58301.mail.re3.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Quagga OSPF binds to wrong interface on FreeBSD 7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jlin2918@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 10:28:34 -0000 --- On Thu, 8/28/08, Julian Elischer wrote: From: Julian Elischer Subject: Re: Quagga OSPF binds to wrong interface on FreeBSD 7 To: jlin2918@yahoo.com Cc: freebsd-net@freebsd.org Date: Thursday, August 28, 2008, 11:56 PM John Lingate wrote: > This bug was reported around the release of FreeBSD 7, but does not seem to have made any progress.=20 >=20 > http://bugzilla.quagga.net/show_bug.cgi?id=3D420 >=20 > Is this because the sockopt.c.diff patch is correct, which isn't > entirely clear from the following comments, or is there some other > solution to this problem? Thanks! the change in quesiton is in the QUAGGA code not in the BSD code. Well, obviously.=A0 However, there are also links to changes that can be ma= de to the BSD code, and apparently this whole issue was precipitated by a c= hange to the BSD kernel interface for multicast. There does not appear to be a consensus as to what the correct fix is, and = the patch in question has not been integrated on the Quagga end after 9 mon= ths.=A0 As best I can make out, it seems like the sockopt.c.diff patch (for= Quagga) might be correct, but then it is not clear why this isn't being in= cluded with Quagga. It seemed reasonable to ask for an opinion from people who might understand= the code, history, RFC's, and nuances better than I.=A0=20 That's why I asked about correctness of the patch, or whether another fix w= as more appropriate.=A0 A patch to the Quagga code isn't necessarily correc= t just because it's a patch to the Quagga code, just as a patch to FreeBSD = isn't necessarily correct just because it's a patch to FreeBSD. =0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 10:53:36 2008 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 509BD1065671 for ; Fri, 29 Aug 2008 10:53:36 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id C93738FC0C for ; Fri, 29 Aug 2008 10:53:35 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so242239eyi.7 for ; Fri, 29 Aug 2008 03:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent :sender; bh=ASyh2yA0Zr5+tYQHu40NWo6OOaKX76eZjkbLyjeWM5k=; b=Gx5Ltb50ibeYwNunUg7KH0umCdGs+8ukh9s4njhUCGx+XtJUAb9Px8fb+1XdglRYl6 K0ZJFrhiQHs/dkwLXXEHuQti0IAbizgd+/qmGcNLDV6ZMMz4gewz3Ee6LmIPnpUDZUw7 5qvn0ayJbV2J0kH53RLiiHU+VQx8YdehlUoag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent:sender; b=Y9luuWUPDw61nU5Bztp6aZo4HHEyXDQHG6jOUTCVe67t8H80l2C/dc3u+szcZjhSQs ITAUD3rsHtDSN8oM5ptr1AxIL/2V8pchNlCBfIyZabWFTpLHTdgEZYgNbY2kd9xXtMOz tPv3z1dSgRVCC71ho+umaxgOukM9v0Itgh5qU= Received: by 10.210.144.3 with SMTP id r3mr1438971ebd.56.1220007215471; Fri, 29 Aug 2008 03:53:35 -0700 (PDT) Received: from alpha.local ( [83.144.140.92]) by mx.google.com with ESMTPS id 7sm2098592eyb.1.2008.08.29.03.53.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Aug 2008 03:53:34 -0700 (PDT) Received: by alpha.local (Postfix, from userid 1001) id 7BA50D4E; Fri, 29 Aug 2008 11:52:28 +0100 (WEST) Date: Fri, 29 Aug 2008 11:52:28 +0100 From: Rui Paulo To: freebsd-net@freebsd.org Message-ID: <20080829105228.GD1468@alpha.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Sender: Rui Paulo Subject: TCP Anomaly Detector project 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, 29 Aug 2008 10:53:36 -0000 Hi, Now that tcpad (TCP Anomaly Detector) is, at least, barely usable, I decided to talk about it. First of all, the wiki page http://wiki.freebsd.org/RuiPaulo/TCPAnomaly talks all about the rationale behind it and how it works. For your convenience, I'll post it here too: "tcpad listens for TCP packets on the wire and builds a virtual TCP stack for each TCP endpoint. This means that, for example, if you run tcpad on a gateway, tcpad will monitor every connection between the hosts behind the gateway, the hosts reachable by the gateway (usually the Internet) and the connections to/from the gateway itself. After the initial packets, tcpad has built a virtual TCP stack for each endpoint. [...] Along with this virtual TCP stack, tcpad monitors for abnormalities within the transmitted packets. For further inspection, tcpad keeps every TCP packet in memory and then dumps it into a pcap file. If you suspect a bug in a TCP stack or tcpad itself, you can boot tcpdump(1) or wireshark(1) and see the packet stream for yourself." Now, a warning about it: tcpad is still in pre-beta phase, so if you want to try it out, please be aware that it may crash, may hurt a butterfly or just make your life miserable. In other words, no warranty ;-) If you have great interest in TCP, this is the project you've been looking for to help. ;-) I'm pretty sure that I need a couple more hands to make this project rock solid in the short term, so your help is very appreciated. On the wiki page you should find every information to get you working with tcpad. If you need more help, you can contact me. Thanks for reading. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 16:26:09 2008 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 508791065680; Fri, 29 Aug 2008 16:26:09 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 091108FC14; Fri, 29 Aug 2008 16:26:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5A2B173098; Fri, 29 Aug 2008 18:28:53 +0200 (CEST) Date: Fri, 29 Aug 2008 18:28:53 +0200 From: Luigi Rizzo To: Sam Leffler Message-ID: <20080829162853.GB46693@onelab2.iet.unipi.it> References: <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B4A62D.3080300@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: gnn@freebsd.org, net@freebsd.org, "Bjoern A. Zeeb" Subject: Re: Small patch to multicast code... 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, 29 Aug 2008 16:26:09 -0000 On Tue, Aug 26, 2008 at 05:56:13PM -0700, Sam Leffler wrote: > gnn@freebsd.org wrote: > >At Tue, 26 Aug 2008 14:50:33 +0000 (UTC), > >Bjoern A. Zeeb wrote: > > > >>On Tue, 26 Aug 2008, George V. Neville-Neil wrote: > >> > >>Hi, > >> > >> > >>>At Mon, 25 Aug 2008 21:40:38 +0200, > >>>John Hay wrote: > >>> > >>>>I have tried it and it does fix my problem. RIP2 over multicast works > >>>>again. :-) > >>>> > >>>Good to hear. I'm waiting on a bit more feedback but I think I'll be > >>>checking this in soon, with a big comment talking about the > >>>performance implications etc. > >>> > >>So wait a second; what was the m_pullup vs. m_dup thing? Has anyone > >>actually tried that? I mean using a sledgehammer if a mitten would be > >>enough is kind of .. uhm. You get it. > >> > > > >Perhaps I'm confused, I've been off dealing with other issues for a > >few days, but m_pullup doesn't make a copy of the packet or its > >fields, only makes sure that it's contiguous in memory. Am I wrong in > >that? > > > >Since the bug is that two pieces of code modify the same data, in ways > >that interfere, I'm not sure how we can avoid making a copy. It might > >be nice to limit the copy, but we'd still need two copies, one for the > >loopback device and one for the real device. > > > > > pull the headers up. copy just the headers. no deep copy. and to be more explicit - the result of m_pullup is that the number of bytes specified as m_pullup argument are in a private piece of memory -- the 'data' region within the mbuf -- so you can freely play with them without trouble. That is why i suggested to just increase the argument to m_pullup by the size of the udp header so one can overwrite the checksum within the mbuf without touching the shared part in the cluster (if any). cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 16:32:11 2008 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 B676110656C1; Fri, 29 Aug 2008 16:32:11 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9AA8FC2E; Fri, 29 Aug 2008 16:32:11 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m7TGWAEH061060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 09:32:11 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48B8248A.3060103@freebsd.org> Date: Fri, 29 Aug 2008 09:32:10 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Luigi Rizzo References: <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> In-Reply-To: <20080829162853.GB46693@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: gnn@freebsd.org, net@freebsd.org, "Bjoern A. Zeeb" Subject: Re: Small patch to multicast code... 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, 29 Aug 2008 16:32:11 -0000 Luigi Rizzo wrote: > On Tue, Aug 26, 2008 at 05:56:13PM -0700, Sam Leffler wrote: > >> gnn@freebsd.org wrote: >> >>> At Tue, 26 Aug 2008 14:50:33 +0000 (UTC), >>> Bjoern A. Zeeb wrote: >>> >>> >>>> On Tue, 26 Aug 2008, George V. Neville-Neil wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>>> At Mon, 25 Aug 2008 21:40:38 +0200, >>>>> John Hay wrote: >>>>> >>>>> >>>>>> I have tried it and it does fix my problem. RIP2 over multicast works >>>>>> again. :-) >>>>>> >>>>>> >>>>> Good to hear. I'm waiting on a bit more feedback but I think I'll be >>>>> checking this in soon, with a big comment talking about the >>>>> performance implications etc. >>>>> >>>>> >>>> So wait a second; what was the m_pullup vs. m_dup thing? Has anyone >>>> actually tried that? I mean using a sledgehammer if a mitten would be >>>> enough is kind of .. uhm. You get it. >>>> >>>> >>> Perhaps I'm confused, I've been off dealing with other issues for a >>> few days, but m_pullup doesn't make a copy of the packet or its >>> fields, only makes sure that it's contiguous in memory. Am I wrong in >>> that? >>> >>> Since the bug is that two pieces of code modify the same data, in ways >>> that interfere, I'm not sure how we can avoid making a copy. It might >>> be nice to limit the copy, but we'd still need two copies, one for the >>> loopback device and one for the real device. >>> >>> >>> >> pull the headers up. copy just the headers. no deep copy. >> > > and to be more explicit - the result of m_pullup is that > the number of bytes specified as m_pullup argument are in > a private piece of memory -- the 'data' region within the mbuf -- so > you can freely play with them without trouble. > > That is why i suggested to just increase the argument to m_pullup > by the size of the udp header so one can overwrite the checksum > within the mbuf without touching the shared part in the cluster > (if any). > Hmm, never considered the m_pullup guaranteed a private copy (but I see it in the code). The original semantics were just that the data was contiguous. Sam From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 16:38:59 2008 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 9D4BE1065698; Fri, 29 Aug 2008 16:38:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 55D318FC23; Fri, 29 Aug 2008 16:38:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 13F5F73098; Fri, 29 Aug 2008 18:41:45 +0200 (CEST) Date: Fri, 29 Aug 2008 18:41:45 +0200 From: Luigi Rizzo To: Sam Leffler Message-ID: <20080829164145.GA47030@onelab2.iet.unipi.it> References: <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> <48B8248A.3060103@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B8248A.3060103@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: "Bjoern A. Zeeb" , gnn@freebsd.org, net@freebsd.org Subject: Re: Small patch to multicast code... 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, 29 Aug 2008 16:38:59 -0000 On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote: > Luigi Rizzo wrote: ... > >and to be more explicit - the result of m_pullup is that > >the number of bytes specified as m_pullup argument are in > >a private piece of memory -- the 'data' region within the mbuf -- so > >you can freely play with them without trouble. > > > >That is why i suggested to just increase the argument to m_pullup > >by the size of the udp header so one can overwrite the checksum > >within the mbuf without touching the shared part in the cluster > >(if any). > > > > Hmm, never considered the m_pullup guaranteed a private copy (but I see > it in the code). The original semantics were just that the data was > contiguous. funny, i thought the guarantee of a writable copy was also part of the original semantics :) cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 19:05:07 2008 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 33B18106568B for ; Fri, 29 Aug 2008 19:05:07 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id B71F78FC18 for ; Fri, 29 Aug 2008 19:05:06 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [IPv6:2002:508f:c668::21e:52ff:fe71:c926] (unknown [IPv6:2002:508f:c668:0:21e:52ff:fe71:c926]) by mail-n.franken.de (Postfix) with ESMTP id E86B71C0C0BCA; Fri, 29 Aug 2008 21:05:03 +0200 (CEST) From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Joseph Mays In-Reply-To: <006e01c90462$339fb320$0a2118d8@engineering01> X-Priority: 3 References: <006e01c90462$339fb320$0a2118d8@engineering01> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 29 Aug 2008 21:05:02 +0200 X-Mailer: Apple Mail (2.926) Cc: FreeBSD Net , Randall Stewart Subject: Re: Kernel Panic in SCTP 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, 29 Aug 2008 19:05:07 -0000 Hi Joe, are you able to provide enough information such that I can reproduce this problem? Best regards Michael On Aug 22, 2008, at 4:20 PM, Joseph Mays wrote: > Hello. > > We've recently written an extensive software system that uses SCTP > as a critical component. We've started to run into an issue where > the box kenel panics after throwing an error message from > sctp_timer.c that says "Our list is out of order? Out of order > list". Can anyone here shed light on what's going on, or give us a > clue how to debug this? > > http://fxr.watson.org/fxr/source/netinet/sctp_timer.c#L645 > > Joe Mays > > _______________________________________________ > 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 Fri Aug 29 19:17:30 2008 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 204431065679; Fri, 29 Aug 2008 19:17:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id EAC0F8FC1B; Fri, 29 Aug 2008 19:17:29 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m7TJHS9N090093; Fri, 29 Aug 2008 12:17:29 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m7TJGx2W048810; Fri, 29 Aug 2008 12:16:59 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (209.249.190.254.available.above.net [209.249.190.254] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m7TJGwn8093416; Fri, 29 Aug 2008 12:16:59 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Fri, 29 Aug 2008 15:16:58 -0400 Message-ID: From: gnn@freebsd.org To: Luigi Rizzo In-Reply-To: <20080829162853.GB46693@onelab2.iet.unipi.it> References: <48AF08B7.4090804@FreeBSD.org> <48AF330B.4010802@FreeBSD.org> <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.2.50 (i386-apple-darwin9.4.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1390829 - 7145746690f6 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: "Bjoern A. Zeeb" , Sam Leffler , net@freebsd.org Subject: Re: Small patch to multicast code... 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, 29 Aug 2008 19:17:30 -0000 At Fri, 29 Aug 2008 18:28:53 +0200, Luigi Rizzo wrote: > > and to be more explicit - the result of m_pullup is that > the number of bytes specified as m_pullup argument are in > a private piece of memory -- the 'data' region within the mbuf -- so > you can freely play with them without trouble. > > That is why i suggested to just increase the argument to m_pullup > by the size of the udp header so one can overwrite the checksum > within the mbuf without touching the shared part in the cluster > (if any). I tried various versions of that, but then I noticed that I also had to save out the pkthdr structure as well. Did you come up with a faster workable patch? For now I'm going to commit the patch I sent originally. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 20:55:24 2008 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 50DB21065676 for ; Fri, 29 Aug 2008 20:55:24 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 847598FC1D for ; Fri, 29 Aug 2008 20:55:23 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id m7TKZbUA083523; Fri, 29 Aug 2008 22:35:37 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id m7TKZbvB083522; Fri, 29 Aug 2008 22:35:37 +0200 (CEST) (envelope-from marius) Date: Fri, 29 Aug 2008 22:35:37 +0200 From: Marius Strobl To: Jacob Owens Message-ID: <20080829203537.GA83446@alchemy.franken.de> References: <20080809082539.GC42339@cdnetworks.co.kr> <20080812013739.GB54362@cdnetworks.co.kr> <20080813044809.GD58659@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: lagg failover not automatic 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, 29 Aug 2008 20:55:24 -0000 On Thu, Aug 28, 2008 at 10:18:28PM -0500, Jacob Owens wrote: > To resolve the issue, Pyun first had my patch amphy.c , then the dc driver. > The DC patch fixed my issue. Here is what i had to do: > > 1. save attached patch to /tmp > 2. #cd /usr/src > 3. #patch -p0 < /tmp/dc.patch > 4. rebuild/install kernel and reboot. i used instructions from here: > http://www.freebsdmadeeasy.com/tutorials/freebsd/recompiling-the-kernel-in-freebsd.php > > THANK YOU to Pyun YongHyeon and the freebsd-net group for helping me with > this issue!!! > > Save the text below and save as dc.patch. (The first line is 'index: > sys/dev/dc......' ,Last line is ' * When the init.....' > > Index: sys/dev/dc/if_dc.c > =================================================================== > --- sys/dev/dc/if_dc.c (revision 181654) > +++ sys/dev/dc/if_dc.c (working copy) > @@ -2868,6 +2868,12 @@ > ifp = sc->dc_ifp; > mii = device_get_softc(sc->dc_miibus); > > + /* > + * XXX Can cause autonegotiation failure on certain models > + * as DC21143 overdrive mii_ticks. > + */ > + mii_tick(mii); > + > if (sc->dc_flags & DC_REDUCED_MII_POLL) { > if (sc->dc_flags & DC_21143_NWAY) { > r = CSR_READ_4(sc, DC_10BTSTAT); > @@ -2881,19 +2887,15 @@ > sc->dc_link = 0; > mii_mediachg(mii); > } > - if (sc->dc_link == 0) > - mii_tick(mii); > } else { > r = CSR_READ_4(sc, DC_ISR); > if ((r & DC_ISR_RX_STATE) == DC_RXSTATE_WAIT && > sc->dc_cdata.dc_tx_cnt == 0) { > - mii_tick(mii); > if (!(mii->mii_media_status & IFM_ACTIVE)) > sc->dc_link = 0; > } > } > - } else > - mii_tick(mii); > + } > > /* > * When the init routine completes, we expect to be able to send For the records, a more appropriate fix (the above patch just lets dc(4) bypasse the DC_REDUCED_MII_POLL handling completely) was commited as r182461. Marius From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 22:12:37 2008 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 650DE1065672; Fri, 29 Aug 2008 22:12:37 +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 3D9F68FC29; Fri, 29 Aug 2008 22:12:37 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m7TMCbLu020019; Fri, 29 Aug 2008 22:12:37 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m7TMCbnC020015; Fri, 29 Aug 2008 22:12:37 GMT (envelope-from linimon) Date: Fri, 29 Aug 2008 22:12:37 GMT Message-Id: <200808292212.m7TMCbnC020015@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/126945: [carp] CARP interface destruction with ifconfig destroy causes kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 22:12:37 -0000 Old Synopsis: CARP interface destruction with ifconfig destroy causes kernel panic New Synopsis: [carp] CARP interface destruction with ifconfig destroy causes kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Aug 29 22:12:16 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=126945 From owner-freebsd-net@FreeBSD.ORG Fri Aug 29 23:03:53 2008 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 17A141065678; Fri, 29 Aug 2008 23:03:53 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id C66038FC1B; Fri, 29 Aug 2008 23:03:52 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id C33382BD50; Sat, 30 Aug 2008 10:35:52 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2coYI1CYrOx; Sat, 30 Aug 2008 10:35:49 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sat, 30 Aug 2008 10:35:47 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id E689111430; Sat, 30 Aug 2008 10:35:46 +1200 (NZST) Date: Fri, 29 Aug 2008 15:35:46 -0700 From: Andrew Thompson To: Luigi Rizzo Message-ID: <20080829223546.GG98483@citylink.fud.org.nz> References: <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> <48B8248A.3060103@freebsd.org> <20080829164145.GA47030@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080829164145.GA47030@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: "Bjoern A. Zeeb" , Sam Leffler , net@freebsd.org, gnn@freebsd.org Subject: Re: Small patch to multicast code... 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, 29 Aug 2008 23:03:53 -0000 On Fri, Aug 29, 2008 at 06:41:45PM +0200, Luigi Rizzo wrote: > On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote: > > Luigi Rizzo wrote: > ... > > >and to be more explicit - the result of m_pullup is that > > >the number of bytes specified as m_pullup argument are in > > >a private piece of memory -- the 'data' region within the mbuf -- so > > >you can freely play with them without trouble. > > > > > >That is why i suggested to just increase the argument to m_pullup > > >by the size of the udp header so one can overwrite the checksum > > >within the mbuf without touching the shared part in the cluster > > >(if any). > > > > > > > Hmm, never considered the m_pullup guaranteed a private copy (but I see > > it in the code). The original semantics were just that the data was > > contiguous. > > funny, i thought the guarantee of a writable copy was also part > of the original semantics :) The bridge code does a deep copy of the packet for each interface it broadcasts on due the firewall code modifying the headers. It sounds like this should just be a copy+pullup instead. Andrew From owner-freebsd-net@FreeBSD.ORG Sat Aug 30 04:35:16 2008 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 94A07106564A; Sat, 30 Aug 2008 04:35:16 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3EE488FC18; Sat, 30 Aug 2008 04:35:16 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m7U4ZEwH065379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2008 21:35:14 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <48B8CE01.6010604@freebsd.org> Date: Fri, 29 Aug 2008 21:35:13 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Andrew Thompson References: <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> <48B8248A.3060103@freebsd.org> <20080829164145.GA47030@onelab2.iet.unipi.it> <20080829223546.GG98483@citylink.fud.org.nz> In-Reply-To: <20080829223546.GG98483@citylink.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: "Bjoern A. Zeeb" , net@freebsd.org, Luigi Rizzo , gnn@freebsd.org Subject: Re: Small patch to multicast code... 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, 30 Aug 2008 04:35:16 -0000 Andrew Thompson wrote: > On Fri, Aug 29, 2008 at 06:41:45PM +0200, Luigi Rizzo wrote: > >> On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote: >> >>> Luigi Rizzo wrote: >>> >> ... >> >>>> and to be more explicit - the result of m_pullup is that >>>> the number of bytes specified as m_pullup argument are in >>>> a private piece of memory -- the 'data' region within the mbuf -- so >>>> you can freely play with them without trouble. >>>> >>>> That is why i suggested to just increase the argument to m_pullup >>>> by the size of the udp header so one can overwrite the checksum >>>> within the mbuf without touching the shared part in the cluster >>>> (if any). >>>> >>>> >>> Hmm, never considered the m_pullup guaranteed a private copy (but I see >>> it in the code). The original semantics were just that the data was >>> contiguous. >>> >> funny, i thought the guarantee of a writable copy was also part >> of the original semantics :) >> > > The bridge code does a deep copy of the packet for each interface it > broadcasts on due the firewall code modifying the headers. It sounds > like this should just be a copy+pullup instead. > > I'd not do that. I think there are paths that assume the deep copy. Right now the network code is very poor honoring read-only-ness of mbuf chains. To get this right we need to do a good audit. I know I hit issues when doing some tricks w/ marking rx buffers read-only to avoid cache flushes. netbsd trys to be more pedantic but still has problems too. Sam From owner-freebsd-net@FreeBSD.ORG Sat Aug 30 09:59:31 2008 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 37B051065671; Sat, 30 Aug 2008 09:59:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 01C218FC12; Sat, 30 Aug 2008 09:59:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A110146B92; Sat, 30 Aug 2008 05:59:30 -0400 (EDT) Date: Sat, 30 Aug 2008 10:59:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sam Leffler In-Reply-To: <48B8CE01.6010604@freebsd.org> Message-ID: References: <20080825190207.GA73478@zibbi.meraka.csir.co.za> <20080825194038.GA75840@zibbi.meraka.csir.co.za> <20080826144130.S66593@maildrop.int.zabbadoz.net> <48B4A62D.3080300@freebsd.org> <20080829162853.GB46693@onelab2.iet.unipi.it> <48B8248A.3060103@freebsd.org> <20080829164145.GA47030@onelab2.iet.unipi.it> <20080829223546.GG98483@citylink.fud.org.nz> <48B8CE01.6010604@freebsd.org> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bjoern A. Zeeb" , gnn@freebsd.org, Luigi Rizzo , Andrew Thompson , net@freebsd.org Subject: Re: Small patch to multicast code... 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, 30 Aug 2008 09:59:31 -0000 On Fri, 29 Aug 2008, Sam Leffler wrote: >> The bridge code does a deep copy of the packet for each interface it >> broadcasts on due the firewall code modifying the headers. It sounds like >> this should just be a copy+pullup instead. > > I'd not do that. I think there are paths that assume the deep copy. Right > now the network code is very poor honoring read-only-ness of mbuf chains. > To get this right we need to do a good audit. I know I hit issues when > doing some tricks w/ marking rx buffers read-only to avoid cache flushes. > netbsd trys to be more pedantic but still has problems too. This strikes me as an extremely tricky thing to get right as bugs manifest in very subtle ways. The IP output path makes lots of assumptions about being able to continue to write to outgoing headers for the purposes of deferred checksum calculation, NAT, IPSEC, fragmentation, encapsulation, etc. IP multicast loopback is just one of the rare edge cases where, if exercised, we currently deterministically discover this, but presumably there's more to come as parallelism continues to increase. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sat Aug 30 14:04:27 2008 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 2422E1065677 for ; Sat, 30 Aug 2008 14:04:27 +0000 (UTC) (envelope-from maddog2k@maddog2k.net) Received: from smtp.fiqz.com (smtp.fiqz.com [IPv6:2001:898:2000:8::132]) by mx1.freebsd.org (Postfix) with ESMTP id 81E788FC08 for ; Sat, 30 Aug 2008 14:04:26 +0000 (UTC) (envelope-from maddog2k@maddog2k.net) Received: from coredump (maddog2k.xs4all.nl [80.126.100.65]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.fiqz.com (Postfix) with ESMTP id D91383380B1 for ; Sat, 30 Aug 2008 16:00:00 +0200 (CEST) Message-ID: <001c01c90aa9$3b069e10$6ac8a8c0@lan.dejong.biz> From: "Wouter de Jong" To: Date: Sat, 30 Aug 2008 16:03:50 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: IPv6 on Carp interfaces not supported ? 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, 30 Aug 2008 14:04:27 -0000 Hi, Is IPv6 supported on Carp interfaces on FreeBSD 7.0-RELEASE ? I've spent quite some time to get it working... but I don't = succeed...the carp-address will never ping nor route. What do I do ? Basic IPv6 : machine1: sysctl -w net.inet6.ip6.forwarding=3D1 ifconfig bge0 inet6 2001:a:b:c::2/64 route -n add -inet6 default 2001:a:b:c::fffe machine2: sysctl -w net.inet6.ip6.forwarding=3D1 ifconfig bge0 inet6 2001:a:b:c::3/64 route -n add -inet6 default 2001:a:b:c::fffe Both addresses are pingable, and when I use either of=20 them on other machines as gateway, they route fine. So now carp : machine1: ifconfig carp1 create ifconfig carp1 vhid 30 pass mekmitasdigoat=20 ifconfig carp1 inet6 2001:a:b:c::1/64 machine2: ifconfig carp1 create ifconfig carp1 vhid 30 advskew 100 pass mekmitasdigoat=20 ifconfig carp1 inet6 2001:a:b:c::1/64 carp goes succesfully to master on one machine, and to backup on = another. However..... i can't ping the virtual address 2001:a:b:c::1 from either = machine1 or machine2. Nor can other PC's ping it or use it as a gateway. Am i forgetting something ? IPv4 carp works as a charm on these machines.... Regards, Wouter de Jong