From owner-freebsd-net@FreeBSD.ORG Sun Oct 11 18:05:16 2009 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 84B2B106566B; Sun, 11 Oct 2009 18:05:16 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id DC2998FC1F; Sun, 11 Oct 2009 18:05:15 +0000 (UTC) Received: by fxm22 with SMTP id 22so7681289fxm.36 for ; Sun, 11 Oct 2009 11:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=IqpitTUsRMfEDVpbS5tzWcYZJowps418AL4r1Ku8MJY=; b=DwgQ5j6GhJ0/JvcyJxbipEK7Hw4njJzknFc0ZZIO1r1TlPHNrikklzy+hXQuoDbGSP cnBfHRlTE5kNlq4lKmJWvLM49cxSiRGCqwc9sl9Wpsv97WCslJZyeh6DCD9V/bbo5XZs xb+KBNr2o/olOY74sQFvT9whreAh8WoTyE15Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=VFCF9Ka+h1QS3T7wf/Jl4ajD5n9lFk5TvTV0eQ2zsirTlkBjmVKgFljY3+WLD3u0w1 aahdiL7BylTZsBkbC+8pSCO71+ugNC6V47S7YHPssecn8vLBLzfsp71zVg7UqfNNt9Ej 2/ar0+6WWaFVz7V8EX8tkFZ/OBxri6A89EcHg= Received: by 10.87.66.2 with SMTP id t2mr4509321fgk.62.1255282902495; Sun, 11 Oct 2009 10:41:42 -0700 (PDT) Received: from localhost ([95.69.161.248]) by mx.google.com with ESMTPS id d4sm3370041fga.21.2009.10.11.10.41.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Oct 2009 10:41:38 -0700 (PDT) To: Eugene Grosbein References: <20090913042742.GA32897@svzserv.kemerovo.su> <4AAD12BE.1090600@vwsoft.com> <20090913171643.GA69039@svzserv.kemerovo.su> Organization: TOA Ukraine From: Mikolaj Golub Date: Sun, 11 Oct 2009 20:41:36 +0300 In-Reply-To: <20090913171643.GA69039@svzserv.kemerovo.su> (Eugene Grosbein's message of "Mon\, 14 Sep 2009 01\:16\:43 +0800") Message-ID: <86ocodzv3j.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: volker@vwsoft.com, Doug Barton , net@freebsd.org Subject: Re: host(1) coredumps 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, 11 Oct 2009 18:05:16 -0000 On Mon, 14 Sep 2009 01:16:43 +0800 Eugene Grosbein wrote: EG> On Sun, Sep 13, 2009 at 05:41:50PM +0200, volker@vwsoft.com wrote: >> > % host -l grosbein.pp.ru. ns2.rucable.net. >> > ; Transfer failed. >> > /usr/local/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2486: >> > REQUIRE((((sock) != ((void *)0)) && (((const isc__magic_t *)(sock))->magic >> > == ((('I') << 24 | ('O') << 16 | ('i') << 8 | ('o')))))) failed. >> > zsh: abort (core dumped) host -l grosbein.pp.ru. ns2.rucable.net. >> > >> > Shoud I send PR? >> Eugene, >> >> the attached patch works around the error for me. As this is contributed >> code, it should be fixed upstream (no need to file a PR). >> >> Volker >> >> --- contrib/bind9/bin/dig/dighost.c.orig 2009-09-13 14:24:13.000000000 +0000 >> +++ contrib/bind9/bin/dig/dighost.c 2009-09-13 14:31:52.000000000 +0000 EG> Indeed, the patch helps. Thank you. BTW, we have already had the pr about this problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/138061 IMO it would be nice to add the patch there. -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Sun Oct 11 19:31:35 2009 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 1E4B91065670 for ; Sun, 11 Oct 2009 19:31:35 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A67C18FC0C for ; Sun, 11 Oct 2009 19:31:34 +0000 (UTC) Received: (qmail 13781 invoked by uid 399); 11 Oct 2009 19:04:53 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 11 Oct 2009 19:04:53 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AD22C54.6070107@FreeBSD.org> Date: Sun, 11 Oct 2009 12:04:52 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Mikolaj Golub References: <20090913042742.GA32897@svzserv.kemerovo.su> <4AAD12BE.1090600@vwsoft.com> <20090913171643.GA69039@svzserv.kemerovo.su> <86ocodzv3j.fsf@kopusha.onet> In-Reply-To: <86ocodzv3j.fsf@kopusha.onet> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: volker@vwsoft.com, Eugene Grosbein , net@freebsd.org Subject: Re: host(1) coredumps 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, 11 Oct 2009 19:31:35 -0000 Mikolaj Golub wrote: > BTW, we have already had the pr about this problem. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/138061 > > IMO it would be nice to add the patch there. Normally that would be a good idea, but I've just adopted the PR and sent a link to it and the patch to the bind-users list. Assuming we get a thumbs up I'll take care of adding it to the port and the base. Thanks, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Sun Oct 11 19:40:20 2009 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 7F4B0106566B; Sun, 11 Oct 2009 19:40:20 +0000 (UTC) (envelope-from inpcb.harsha@gmail.com) Received: from mail-pz0-f104.google.com (mail-pz0-f104.google.com [209.85.222.104]) by mx1.freebsd.org (Postfix) with ESMTP id 544F88FC15; Sun, 11 Oct 2009 19:40:20 +0000 (UTC) Received: by pzk2 with SMTP id 2so38269pzk.27 for ; Sun, 11 Oct 2009 12:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=/RxWVwFUS5owVd6Ri/CahM5jQC4e/TygkwtAoUYCTao=; b=p72suf6ilsuy079BhTbe053MNHk6wLwXav5det3prOxxt6cS5vYTpwRA12vHSfJbuB mRp4TxqFIjsXGgYG3eVXu6MyufnXm+tpH409449odE/sM7hhfj1vxXBKmPdMnG0AMVU9 kvW9aQPbuNDh7Kl/9+yIkQ1u+wXeB9Lmq4SDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uW9vyJ4nMyUbaWixyxCSF4R+Dr7JwMQGmzU3zhAU1rC/zVUn2PKrqop3E1hXTVwGAJ Bhxy99PQv1vwBGi45fdiq3vtsnSTfATjmphFbr8s4E5kW6aqFW7gbrVDNL7iULLl5LlY BXYaoEGPwWV4cDEY+hqpRNJfXfW9H7Dt8kiIU= MIME-Version: 1.0 Received: by 10.141.1.12 with SMTP id d12mr336935rvi.268.1255289192721; Sun, 11 Oct 2009 12:26:32 -0700 (PDT) Date: Sun, 11 Oct 2009 12:26:31 -0700 Message-ID: From: Harsha Srinath To: net@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] 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, 11 Oct 2009 19:40:20 -0000 Hi all, I'm running an updated HEAD kernel and got a page fault in ifindex_alloc_locked() in if.c. I figured that the problem was caused by the (pluggable) network card of my laptop and found that during the initialization of the interface, cb_event_thread() takes the giant lock and up the call chain in if_alloc(), we call IFNET_WLOCK() and assert on the RW locks in ifindex_alloc_locked(). It is in the asset macro IFNET_WLOCK_ASSERT() I see the page fault. I looked up some recent related changes and noticed the following comment in one of the check-ins in- http://svn.freebsd.org/viewvc/base/head/sys/net/if.c "Break out allocation of new ifindex values from if_alloc() and if_vmove(), and centralize in a single function ifindex_alloc(). Assert the IFNET_WLOCK, and add missing IFNET_WLOCK in if_alloc(). This does not close all known races in this code." So I think I have hit one of those fault conditions. Apparently the giant lock code was removed and added back recently - http://svn.freebsd.org/viewvc/base/head/sys/dev/pccbb/pccbb.c I believe that the root cause is that ifnet_rw is a non sleepable exclusive RW lock and we have taken the exclusive sleep mutex Giant before that. Any pointers and suggestions are welcome. Many thanks, Harsha From owner-freebsd-net@FreeBSD.ORG Sun Oct 11 20:30:58 2009 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 49B0E1065672; Sun, 11 Oct 2009 20:30:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 246F68FC0A; Sun, 11 Oct 2009 20:30:58 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C582546B09; Sun, 11 Oct 2009 16:30:57 -0400 (EDT) Date: Sun, 11 Oct 2009 21:30:57 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Harsha Srinath In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, net@freebsd.org Subject: Re: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] 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, 11 Oct 2009 20:30:58 -0000 On Sun, 11 Oct 2009, Harsha Srinath wrote: > I'm running an updated HEAD kernel and got a page fault in > ifindex_alloc_locked() in if.c. I figured that the problem was caused by the > (pluggable) network card of my laptop and found that during the > initialization of the interface, cb_event_thread() takes the giant lock and > up the call chain in if_alloc(), we call IFNET_WLOCK() and assert on the RW > locks in ifindex_alloc_locked(). It is in the asset macro > IFNET_WLOCK_ASSERT() I see the page fault. > > I looked up some recent related changes and noticed the following comment in > one of the check-ins in- > http://svn.freebsd.org/viewvc/base/head/sys/net/if.c > > "Break out allocation of new ifindex values from if_alloc() and if_vmove(), > and centralize in a single function ifindex_alloc(). Assert the IFNET_WLOCK, > and add missing IFNET_WLOCK in if_alloc(). This does not close all known > races in this code." > > So I think I have hit one of those fault conditions. > > Apparently the giant lock code was removed and added back recently - > http://svn.freebsd.org/viewvc/base/head/sys/dev/pccbb/pccbb.c > > I believe that the root cause is that ifnet_rw is a non sleepable exclusive > RW lock and we have taken the exclusive sleep mutex Giant before that. > > Any pointers and suggestions are welcome. Hi Harsha-- Giant is a bit special in that the long-term sleep code in the kernel knows to drop it when sleeping, and re-acquire when waking up. So, unlike all other mutexes, it should be OK to hold it in this case, as Giant will simply get dropped if the kernel has to sleep waiting on a sleepable lock. This is because, historically in FreeBSD 3.x/4.x, the kernel was protected by a single spinlock, which would get released whenever the kernel stopped executing, such as during an I/O sleep. On the whole, Giant has disappeared from the modern kernel, but where it is used, it retains those curious historic properties. To break things down a bit further, IFNET_WLOCK is, itself, a bit special: notice that in FreeBSD 8, it's actually two locks, a sleep lock, and a mutex, which must both be acquired exclusively to ensure mutual exclusion. if_alloc() and associated calls are also sleepable because they perform potentially sleeping memory allocation (M_WAITOK), so it's an invariant of any code calling interface allocation that it must be able to tolerate a sleep. Do you have a copy of the stack trace and fault information handy? In my experience, a NULL pointer deref or other page fault in the locking code for a global lock is almost always corrupted thread state, perhaps due to tripping over another thread having locked a corrupted/freed/uninitialized lock. We might be able to track that down by tracing other threads that were in execution at the time of the panic. Robert From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 04:38:34 2009 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 E89B21065670; Mon, 12 Oct 2009 04:38:33 +0000 (UTC) (envelope-from inpcb.harsha@gmail.com) Received: from mail-pz0-f104.google.com (mail-pz0-f104.google.com [209.85.222.104]) by mx1.freebsd.org (Postfix) with ESMTP id B00E58FC19; Mon, 12 Oct 2009 04:38:33 +0000 (UTC) Received: by pzk2 with SMTP id 2so56608pzk.27 for ; Sun, 11 Oct 2009 21:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kg19ioURrVW8nlWRB8B7SDXkqF7azLwDeBAZWHD1rog=; b=AkhPO54KKrJMUDoxXDbWq7eQT8tGIY4wDD7ocCOTOgCLewTIH8W8bFCmcDQj6VcnDZ OmSKfg/c9T2nrWfLud/cBFpXKRFbR9RKmdbpw/6eImAvWC2RNMQqyYzJGmRYnQhLHOMm n1zpBRDLRf+hEuLbA0p99Tgy1DGMJoKZhuCYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CsesZlrKorw+PjmQVkxD7iXEMT9RU8W8SF0F0ASKAnnvN8flIBvhC8iFqhbFO5EBXl nkv+MhtJVb07zi28Vurv3p8CF4PVai75YzodaUNYl9G1/i3KMd0Z3tPKypAgQpYU8S5a EQ/b3D+Sm/E0lzafSeSyKRnwIa7Vb5+AFmXK0= MIME-Version: 1.0 Received: by 10.141.34.20 with SMTP id m20mr360036rvj.120.1255322313072; Sun, 11 Oct 2009 21:38:33 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Oct 2009 21:38:33 -0700 Message-ID: From: Harsha To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, net@freebsd.org Subject: Re: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] 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, 12 Oct 2009 04:38:34 -0000 Hi Robert, On Sun, Oct 11, 2009 at 1:30 PM, Robert Watson wrote: > Giant is a bit special in that the long-term sleep code in the kernel kno= ws > to drop it when sleeping, and re-acquire when waking up. =A0So, unlike al= l > other mutexes, it should be OK to hold it in this case, as Giant will sim= ply > get dropped if the kernel has to sleep waiting on a sleepable lock. =A0Th= is is > because, historically in FreeBSD 3.x/4.x, the kernel was protected by a > single spinlock, which would get released whenever the kernel stopped > executing, such as during an I/O sleep. =A0On the whole, Giant has disapp= eared > from the modern kernel, but where it is used, it retains those curious > historic properties. > > To break things down a bit further, IFNET_WLOCK is, itself, a bit special= : > notice that in FreeBSD 8, it's actually two locks, a sleep lock, and a > mutex, which must both be acquired exclusively to ensure mutual exclusion= . > if_alloc() and associated calls are also sleepable because they perform > potentially sleeping memory allocation (M_WAITOK), so it's an invariant o= f > any code calling interface allocation that it must be able to tolerate a > sleep. Thanks a lot for the clarification. I had assumed that the lock was non-sleepable looking at this log - Kernel page fault with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r =3D 0 (0xc0f63464) locked @ /usr/src/sys/net/if.c:409 > Do you have a copy of the stack trace and fault information handy? =A0In = my > experience, a NULL pointer deref or other page fault in the locking code = for > a global lock is almost always corrupted thread state, perhaps due to > tripping over another thread having locked a corrupted/freed/uninitialize= d > lock. =A0We might be able to track that down by tracing other threads tha= t > were in execution at the time of the panic. I just tried the textdump feature and I think its an awesome tool. Here is ddb.txt- http://docs.google.com/View?id=3Ddddwnxfj_0dh4x58hc And msgbuf.txt- http://docs.google.com/View?id=3Ddddwnxfj_1cnmrb8fw For some reason the output of show alllocks is not written into ddb.txt, though I have increased the buffer size to 2MB. Thanks, Harsha From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 09:26:43 2009 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 66105106566B for ; Mon, 12 Oct 2009 09:26:43 +0000 (UTC) (envelope-from aman.jassal@esigetel.fr) Received: from mail.esigetel.fr (venus.esigetel.fr [192.134.106.8]) by mx1.freebsd.org (Postfix) with ESMTP id E311E8FC0C for ; Mon, 12 Oct 2009 09:26:42 +0000 (UTC) Received: by mail.esigetel.fr (Postfix, from userid 65534) id 5B0B61023C; Mon, 12 Oct 2009 11:02:01 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on venus.esigetel.avon X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=unavailable version=3.1.8 Received: from localhost (localhost [127.0.0.1]) by mail.esigetel.fr (Postfix) with ESMTP id D611E10198 for ; Mon, 12 Oct 2009 11:02:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at esigetel.fr Received: from mail.esigetel.fr ([127.0.0.1]) by localhost (venus.esigetel.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUbB1S36NOHX for ; Mon, 12 Oct 2009 11:01:55 +0200 (CEST) Received: from webmail.esigetel.fr (neo.ecampus.avon [192.168.106.14]) by mail.esigetel.fr (Postfix) with ESMTP id 3FFC71016F for ; Mon, 12 Oct 2009 11:01:55 +0200 (CEST) Received: from 83.206.131.26 (proxying for unknown) by webmail.esigetel.fr with HTTP; Mon, 12 Oct 2009 11:01:55 +0200 (CEST) Message-ID: <8410.83.206.131.26.1255338115.squirrel@webmail.esigetel.fr> In-Reply-To: <4ACF5DA5.6060806@elischer.org> References: <4ACF5DA5.6060806@elischer.org> Date: Mon, 12 Oct 2009 11:01:55 +0200 (CEST) From: "JASSAL Aman" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Volunteer opportunity for Networking tasks 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, 12 Oct 2009 09:26:43 -0000 Dear all, I am interested in contributing to the networking tasks of the FreeBSD project. Having been on the freebsd-net mailing-list for about 6 months now (and freebsd-current more recently), I really want to make myself useful, and provide help in completing tasks on networking or wireless networking areas. I had been on the Networking Wikipage (this one : http://wiki.freebsd.org/Networking), which describes the current on-going tasks, I had been working over the last 2 weeks on rewriting some parts of netstat(1) (mainly the part dumping the routing table) to make it use sysctl rather than kvm. However after reading Mr.Gerzo's mail about the FreeBSD Status Reports from yesterday evening, which talked about libnetstat(), I'm starting to wonder whether whatever work I've done so far is actually worthwhile... I was thinking of getting some experience on board before volunteering for further work. There are a good few tasks mentionned on the Networking Wikipage that interest me a lot, so I'll just start working on something else if that work is no longer required for netstat :-). Please make me aware of any opportunities or tasks in which there is a need for more people, I'd be greatly honoured to provide help. -------------- Aman Jassal From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 11:06:58 2009 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 7787B106568D for ; Mon, 12 Oct 2009 11:06:58 +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 64B0F8FC18 for ; Mon, 12 Oct 2009 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9CB6wa7036488 for ; Mon, 12 Oct 2009 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9CB6v6V036484 for freebsd-net@FreeBSD.org; Mon, 12 Oct 2009 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Oct 2009 11:06:57 GMT Message-Id: <200910121106.n9CB6v6V036484@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, 12 Oct 2009 11:06:58 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net [libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138676 net [route] after buildworld not work local routes [regres f kern/138666 net [multicast] [panic] not working multicast through igmp o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138390 net [gif] [patch] NULL pointer dereference in gif_input() o kern/138378 net [altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138130 net [netinet] [patch] Resource leak in LibAliasRefreshModu o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 357 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 13:46:06 2009 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 3C47B1065672; Mon, 12 Oct 2009 13:46:06 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 133F28FC23; Mon, 12 Oct 2009 13:46:06 +0000 (UTC) Received: from lemongrass.sec.cl.cam.ac.uk (lemongrass.sec.cl.cam.ac.uk [128.232.18.47]) by cyrus.watson.org (Postfix) with ESMTPSA id DFFB146B1A; Mon, 12 Oct 2009 09:46:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: "Robert N. M. Watson" In-Reply-To: Date: Mon, 12 Oct 2009 14:46:03 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: To: Harsha X-Mailer: Apple Mail (2.1076) Cc: freebsd-current@freebsd.org, net@freebsd.org Subject: Re: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] 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, 12 Oct 2009 13:46:06 -0000 On 12 Oct 2009, at 05:38, Harsha wrote: > Thanks a lot for the clarification. > > I had assumed that the lock was non-sleepable looking at this log - > Kernel page fault with the following non-sleepable locks held: > exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0f63464) locked @ > /usr/src/sys/net/if.c:409 Looks like a NULL pointer dereference, so perhaps a more traditional bug -- could you convert ifindex_alloc_locked+0x71 to a line of code? You can do this using kgdb on the kernel symbols file, perhaps "l *ifindex_alloc_locked+0x71". Robert From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 14:41:53 2009 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 C5028106566B for ; Mon, 12 Oct 2009 14:41:53 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 5772C8FC0A for ; Mon, 12 Oct 2009 14:41:53 +0000 (UTC) Received: (qmail 48837 invoked by uid 1000); 12 Oct 2009 14:41:49 -0000 Date: Mon, 12 Oct 2009 10:41:49 -0400 From: Larry Baird To: freebsd-net@freebsd.org Message-ID: <20091012144149.GA39393@gta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: ARP changes 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, 12 Oct 2009 14:41:53 -0000 I know that arp has changed a lot in FreeBSD 8. I am wondering if one change was by design? In older versions of FreeBSD, if you ping a host that is on a local network but is down, after a few seconds ping displays: ping: sendto: Host is down ping: sendto: Host is down Using arp to display the arp table shows: host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] In FreeBSD 8, the incomplete arp entries don't show up. Ping never prints "Host is down'. The old behaviors can useful when trouble shooting local network problems. Is there a reason for the changes? -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 17:05:15 2009 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 C84BC10656C0 for ; Mon, 12 Oct 2009 17:05:15 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id B36FC8FC20 for ; Mon, 12 Oct 2009 17:05:15 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n9CH5EOB001726; Mon, 12 Oct 2009 10:05:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 10:05:04 -0700 Message-ID: In-Reply-To: <20091012144149.GA39393@gta.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP changes Thread-Index: AcpLSk5gBRb9dl1hR8CvSflY0ZlYDgAE71mA References: <20091012144149.GA39393@gta.com> From: "Li, Qing" To: "Larry Baird" , Cc: Subject: RE: ARP changes 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, 12 Oct 2009 17:05:15 -0000 Might be a regression issue. I will take a look and get back to you later today. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Larry Baird > Sent: Monday, October 12, 2009 7:42 AM > To: freebsd-net@freebsd.org > Subject: ARP changes >=20 > I know that arp has changed a lot in FreeBSD 8. I am wondering if one > change was by design? In older versions of FreeBSD, if you ping a host > that is on a local network but is down, after a few seconds ping > displays: > ping: sendto: Host is down > ping: sendto: Host is down >=20 > Using arp to display the arp table shows: > host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] >=20 > In FreeBSD 8, the incomplete arp entries don't show up. Ping never > prints "Host is down'. The old behaviors can useful when trouble > shooting local network problems. Is there a reason for the changes? >=20 >=20 > -- > ----------------------------------------------------------------------- > - > Larry Baird | http://www.gta.com > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 17:41:22 2009 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 9DDF8106568D for ; Mon, 12 Oct 2009 17:41:22 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3EA8FC13 for ; Mon, 12 Oct 2009 17:41:22 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n9CHfI9Q081109; Mon, 12 Oct 2009 13:41:19 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200910121741.n9CHfI9Q081109@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Oct 2009 13:41:36 -0400 To: "Li, Qing" , "Larry Baird" , From: Mike Tancsa In-Reply-To: References: <20091012144149.GA39393@gta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: RE: ARP changes 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, 12 Oct 2009 17:41:22 -0000 At 01:05 PM 10/12/2009, Li, Qing wrote: >Might be a regression issue. I will take a look and get back >to you later today. Actually, the behaviour is different on RELENG_6, RELENG_7 and RELENG_8. On RELENG_6, the negative entry is cached for some, on RELENG_7, less than 1 second and on RELENG_8, it never shows up at all ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 21:56:47 2009 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 1A811106566B; Mon, 12 Oct 2009 21:56:47 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E6B108FC14; Mon, 12 Oct 2009 21:56:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9CLuknS016224; Mon, 12 Oct 2009 21:56:46 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9CLukCD016220; Mon, 12 Oct 2009 21:56:46 GMT (envelope-from bz) Date: Mon, 12 Oct 2009 21:56:46 GMT Message-Id: <200910122156.n9CLukCD016220@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/116328: [bge]: Solid hang with bge 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: Mon, 12 Oct 2009 21:56:47 -0000 Synopsis: [bge]: Solid hang with bge interface Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Mon Oct 12 21:56:26 UTC 2009 Responsible-Changed-Why: Take for the moment. http://www.freebsd.org/cgi/query-pr.cgi?pr=116328 From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 21:57:14 2009 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 B449E1065697; Mon, 12 Oct 2009 21:57:14 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8C4C78FC1C; Mon, 12 Oct 2009 21:57:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9CLvENP016303; Mon, 12 Oct 2009 21:57:14 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9CLvEmX016299; Mon, 12 Oct 2009 21:57:14 GMT (envelope-from bz) Date: Mon, 12 Oct 2009 21:57:14 GMT Message-Id: <200910122157.n9CLvEmX016299@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/122252: [ipmi] [bge] IPMI problem with BCM5704 (does not work after driver loaded) 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, 12 Oct 2009 21:57:14 -0000 Synopsis: [ipmi] [bge] IPMI problem with BCM5704 (does not work after driver loaded) Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Mon Oct 12 21:57:02 UTC 2009 Responsible-Changed-Why: Take for the moment. http://www.freebsd.org/cgi/query-pr.cgi?pr=122252 From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 22:21:07 2009 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 33F5B1065676 for ; Mon, 12 Oct 2009 22:21:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 694F28FC0A for ; Mon, 12 Oct 2009 22:21:06 +0000 (UTC) Received: (qmail 7676 invoked by uid 399); 12 Oct 2009 22:21:05 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Oct 2009 22:21:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AD3ABD0.7010603@FreeBSD.org> Date: Mon, 12 Oct 2009 15:21:04 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Wacky DHCP values that work in windows but not in FreeBSD 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, 12 Oct 2009 22:21:07 -0000 Howdy, I usually have a wireless router connected directly to the AT&T/Yahoo DSL modem but last night I wanted to do some debugging so I plugged my laptop directly into the modem (after powering off the modem, etc.). The values I got back from DHCP not only don't make sense, they didn't work in FreeBSD at all. Dual-booting to Windows showed that the values I saw from DHCP were "correct," and somehow they managed to work. Taking a closer look at the router after I plugged it back in showed the same. Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 76.212.147.xxx Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 151.164.184.xxx DHCP Server . . . . . . . . . . . : 192.168.1.xxx DNS Servers . . . . . . . . . . . : 192.168.1.xxx Can anyone tell me how they managed to get this to work in Windows, and suggest where to look to get it working in FreeBSD? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 22:59:45 2009 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 70FC31065676 for ; Mon, 12 Oct 2009 22:59:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 5AE078FC12 for ; Mon, 12 Oct 2009 22:59:45 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 4DE83B647; Mon, 12 Oct 2009 15:59:45 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 9CEF12D6016; Mon, 12 Oct 2009 15:59:44 -0700 (PDT) Message-ID: <4AD3B4E3.2090406@elischer.org> Date: Mon, 12 Oct 2009 15:59:47 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Doug Barton References: <4AD3ABD0.7010603@FreeBSD.org> In-Reply-To: <4AD3ABD0.7010603@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD 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, 12 Oct 2009 22:59:45 -0000 Doug Barton wrote: > Howdy, > > I usually have a wireless router connected directly to the AT&T/Yahoo > DSL modem but last night I wanted to do some debugging so I plugged my > laptop directly into the modem (after powering off the modem, etc.). > > The values I got back from DHCP not only don't make sense, they didn't > work in FreeBSD at all. Dual-booting to Windows showed that the values > I saw from DHCP were "correct," and somehow they managed to work. > Taking a closer look at the router after I plugged it back in showed > the same. > > Dhcp Enabled. . . . . . . . . . . : Yes > Autoconfiguration Enabled . . . . : Yes > IP Address. . . . . . . . . . . . : 76.212.147.xxx > Subnet Mask . . . . . . . . . . . : 255.255.0.0 > Default Gateway . . . . . . . . . : 151.164.184.xxx huh? only way this could work would be if it was marked as "point to point" I think.. > DHCP Server . . . . . . . . . . . : 192.168.1.xxx > DNS Servers . . . . . . . . . . . : 192.168.1.xxx > > Can anyone tell me how they managed to get this to work in Windows, > and suggest where to look to get it working in FreeBSD? > > > Doug > From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 23:14:09 2009 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 72D791065692 for ; Mon, 12 Oct 2009 23:14:09 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in02.adhost.com (mail-in02.adhost.com [216.211.128.132]) by mx1.freebsd.org (Postfix) with ESMTP id 586248FC16 for ; Mon, 12 Oct 2009 23:14:09 +0000 (UTC) Received: from ad-exh01.adhost.lan (exchange.adhost.com [216.211.143.69]) by mail-in02.adhost.com (Postfix) with ESMTP id B0C3ECBCD43; Mon, 12 Oct 2009 16:14:06 -0700 (PDT) (envelope-from mksmith@adhost.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 16:14:06 -0700 Message-ID: <17838240D9A5544AAA5FF95F8D52031606D020C7@ad-exh01.adhost.lan> In-Reply-To: <4AD3B4E3.2090406@elischer.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wacky DHCP values that work in windows but not in FreeBSD Thread-Index: AcpLj71LV3bFMCbOToqf4x0x0nj2HgAAOKNQ References: <4AD3ABD0.7010603@FreeBSD.org> <4AD3B4E3.2090406@elischer.org> From: "Michael K. Smith - Adhost" To: "Julian Elischer" , "Doug Barton" Cc: freebsd-net@freebsd.org Subject: RE: Wacky DHCP values that work in windows but not in FreeBSD 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, 12 Oct 2009 23:14:09 -0000 > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Julian Elischer > Sent: Monday, October 12, 2009 4:00 PM > To: Doug Barton > Cc: freebsd-net@freebsd.org > Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD >=20 > Doug Barton wrote: > > Howdy, > > > > I usually have a wireless router connected directly to the AT&T/Yahoo > > DSL modem but last night I wanted to do some debugging so I plugged > my > > laptop directly into the modem (after powering off the modem, etc.). > > > > The values I got back from DHCP not only don't make sense, they > didn't > > work in FreeBSD at all. Dual-booting to Windows showed that the > values > > I saw from DHCP were "correct," and somehow they managed to work. > > Taking a closer look at the router after I plugged it back in showed > > the same. > > > > Dhcp Enabled. . . . . . . . . . . : Yes > > Autoconfiguration Enabled . . . . : Yes > > IP Address. . . . . . . . . . . . : 76.212.147.xxx > > Subnet Mask . . . . . . . . . . . : 255.255.0.0 > > Default Gateway . . . . . . . . . : 151.164.184.xxx >=20 > huh? >=20 > only way this could work would be if it was marked as "point to point" > I think.. That could be a primary IP address on an interface on which your 76 address is a sub interface. The interface will do proxy-arp when a traffic request comes in. Or something else! I'm not sure if this will work, but you could actually hard code your default gateway with a -hopcount 2 (or higher) and see if that works. I've not tried it on a live machine. Something like route add default 151.164.184.xxx -hopcount 5. You may have to delete the DHCP-assigned entry first. Regards, Mike From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 23:21:33 2009 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 AA0A01065676 for ; Mon, 12 Oct 2009 23:21:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE258FC15 for ; Mon, 12 Oct 2009 23:21:32 +0000 (UTC) Received: (qmail 7397 invoked by uid 399); 12 Oct 2009 23:21:32 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Oct 2009 23:21:32 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AD3B9FB.4010205@FreeBSD.org> Date: Mon, 12 Oct 2009 16:21:31 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: "Michael K. Smith - Adhost" References: <4AD3ABD0.7010603@FreeBSD.org> <4AD3B4E3.2090406@elischer.org> <17838240D9A5544AAA5FF95F8D52031606D020C7@ad-exh01.adhost.lan> In-Reply-To: <17838240D9A5544AAA5FF95F8D52031606D020C7@ad-exh01.adhost.lan> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD 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, 12 Oct 2009 23:21:33 -0000 Michael K. Smith - Adhost wrote: >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Julian Elischer >> Sent: Monday, October 12, 2009 4:00 PM >> To: Doug Barton >> Cc: freebsd-net@freebsd.org >> Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD >> >> Doug Barton wrote: >>> Howdy, >>> >>> I usually have a wireless router connected directly to the > AT&T/Yahoo >>> DSL modem but last night I wanted to do some debugging so I plugged >> my >>> laptop directly into the modem (after powering off the modem, etc.). >>> >>> The values I got back from DHCP not only don't make sense, they >> didn't >>> work in FreeBSD at all. Dual-booting to Windows showed that the >> values >>> I saw from DHCP were "correct," and somehow they managed to work. >>> Taking a closer look at the router after I plugged it back in showed >>> the same. >>> >>> Dhcp Enabled. . . . . . . . . . . : Yes >>> Autoconfiguration Enabled . . . . : Yes >>> IP Address. . . . . . . . . . . . : 76.212.147.xxx >>> Subnet Mask . . . . . . . . . . . : 255.255.0.0 >>> Default Gateway . . . . . . . . . : 151.164.184.xxx >> huh? >> >> only way this could work would be if it was marked as "point to point" >> I think.. > > That could be a primary IP address on an interface on which your 76 > address is a sub interface. Can you specify what you mean by 'that'? > The interface will do proxy-arp when a > traffic request comes in. Or something else! I'm not sure if this will > work, but you could actually hard code your default gateway with a > -hopcount 2 (or higher) and see if that works. I've not tried it on a > live machine. Something like route add default 151.164.184.xxx > -hopcount 5. You may have to delete the DHCP-assigned entry first. Ah, I didn't know about -hopcount, thanks. There was no default route installed at all when I booted. I tried 'route add default 151...' even though I was sure it wouldn't work, and I was not disappointed. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 23:25:58 2009 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 0F1C81065672 for ; Mon, 12 Oct 2009 23:25:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outl.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id E764F8FC0A for ; Mon, 12 Oct 2009 23:25:57 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id DE67CB4CBA; Mon, 12 Oct 2009 16:25:57 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 30CF92D6011; Mon, 12 Oct 2009 16:25:57 -0700 (PDT) Message-ID: <4AD3BB07.3070109@elischer.org> Date: Mon, 12 Oct 2009 16:25:59 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Doug Barton References: <4AD3ABD0.7010603@FreeBSD.org> <4AD3B4E3.2090406@elischer.org> <17838240D9A5544AAA5FF95F8D52031606D020C7@ad-exh01.adhost.lan> <4AD3B9FB.4010205@FreeBSD.org> In-Reply-To: <4AD3B9FB.4010205@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Michael K. Smith - Adhost" , freebsd-net@freebsd.org Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD 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, 12 Oct 2009 23:25:58 -0000 Doug Barton wrote: > Michael K. Smith - Adhost wrote: >>> -----Original Message----- >>> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >>> net@freebsd.org] On Behalf Of Julian Elischer >>> Sent: Monday, October 12, 2009 4:00 PM >>> To: Doug Barton >>> Cc: freebsd-net@freebsd.org >>> Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD >>> >>> Doug Barton wrote: >>>> Howdy, >>>> >>>> I usually have a wireless router connected directly to the >> AT&T/Yahoo >>>> DSL modem but last night I wanted to do some debugging so I plugged >>> my >>>> laptop directly into the modem (after powering off the modem, etc.). >>>> >>>> The values I got back from DHCP not only don't make sense, they >>> didn't >>>> work in FreeBSD at all. Dual-booting to Windows showed that the >>> values >>>> I saw from DHCP were "correct," and somehow they managed to work. >>>> Taking a closer look at the router after I plugged it back in showed >>>> the same. >>>> >>>> Dhcp Enabled. . . . . . . . . . . : Yes >>>> Autoconfiguration Enabled . . . . : Yes >>>> IP Address. . . . . . . . . . . . : 76.212.147.xxx >>>> Subnet Mask . . . . . . . . . . . : 255.255.0.0 >>>> Default Gateway . . . . . . . . . : 151.164.184.xxx >>> huh? >>> >>> only way this could work would be if it was marked as "point to point" >>> I think.. >> That could be a primary IP address on an interface on which your 76 >> address is a sub interface. > > Can you specify what you mean by 'that'? > >> The interface will do proxy-arp when a >> traffic request comes in. Or something else! I'm not sure if this will >> work, but you could actually hard code your default gateway with a >> -hopcount 2 (or higher) and see if that works. I've not tried it on a >> live machine. Something like route add default 151.164.184.xxx >> -hopcount 5. You may have to delete the DHCP-assigned entry first. > > Ah, I didn't know about -hopcount, thanks. There was no default route > installed at all when I booted. I tried 'route add default 151...' > even though I was sure it wouldn't work, and I was not disappointed. > > Doug > also not sure if you can add a -iface argument to make your default route include the correct interface . From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 23:33:42 2009 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 0FBA81065679 for ; Mon, 12 Oct 2009 23:33:42 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: from smtp2.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id AB7588FC0A for ; Mon, 12 Oct 2009 23:33:41 +0000 (UTC) Received: (qmail 1026 invoked from network); 12 Oct 2009 15:48:46 -0700 Received: by simscan 1.1.0 ppid: 1022, pid: 1023, t: 0.1476s scanners: regex: 1.1.0 attach: 1.1.0 spam: 3.1.7-deb X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on smtp2.surewest.net. X-Spam-Level: X-Spam-Status: No, score=0.0 required=13.5 tests=none autolearn=disabled version=3.1.7-deb X-Spam-CMAE-Analysis: v=1.0 c=1 a=uhA5l_12LWIA:10 a=h6qV8m-w2GIIE2HTDGsA:9 a=f-TNlR992FvsMLLEh8j7twJ-VtsA:4 Received: from unknown (HELO smtp.jim-liesl.org) (66.60.173.44) by smtp2 with SMTP; 12 Oct 2009 15:48:46 -0700 Received: from smtp.jim-liesl.org (localhost.static.surewest.net [127.0.0.1]) by smtp.jim-liesl.org (Postfix) with ESMTP id 934EB5DE6; Mon, 12 Oct 2009 16:06:54 -0700 (PDT) Received: from [127.0.0.1] (nano [192.168.1.20]) by smtp.jim-liesl.org (Postfix) with ESMTP id C9AA55DBB; Mon, 12 Oct 2009 16:06:39 -0700 (PDT) Message-ID: <4AD3B67F.4070906@jim-liesl.org> Date: Mon, 12 Oct 2009 16:06:39 -0700 From: security User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Julian Elischer References: <4AD3ABD0.7010603@FreeBSD.org> <4AD3B4E3.2090406@elischer.org> In-Reply-To: <4AD3B4E3.2090406@elischer.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD 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, 12 Oct 2009 23:33:42 -0000 Julian Elischer wrote: > Doug Barton wrote: >> Howdy, >> >> I usually have a wireless router connected directly to the AT&T/Yahoo >> DSL modem but last night I wanted to do some debugging so I plugged my >> laptop directly into the modem (after powering off the modem, etc.). >> >> The values I got back from DHCP not only don't make sense, they didn't >> work in FreeBSD at all. Dual-booting to Windows showed that the values >> I saw from DHCP were "correct," and somehow they managed to work. >> Taking a closer look at the router after I plugged it back in showed >> the same. >> >> Dhcp Enabled. . . . . . . . . . . : Yes >> Autoconfiguration Enabled . . . . : Yes >> IP Address. . . . . . . . . . . . : 76.212.147.xxx >> Subnet Mask . . . . . . . . . . . : 255.255.0.0 >> Default Gateway . . . . . . . . . : 151.164.184.xxx > > huh? > > only way this could work would be if it was marked as "point to point" > I think.. > >> DHCP Server . . . . . . . . . . . : 192.168.1.xxx >> DNS Servers . . . . . . . . . . . : 192.168.1.xxx >> >> Can anyone tell me how they managed to get this to work in Windows, >> and suggest where to look to get it working in FreeBSD? >> >> >> Doug >> ATT uses PPPoE on their modems. Did your router have any special PPPoE settings? jim From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 23:52:39 2009 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 BDF95106566B for ; Mon, 12 Oct 2009 23:52:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 522498FC15 for ; Mon, 12 Oct 2009 23:52:39 +0000 (UTC) Received: (qmail 24701 invoked by uid 399); 12 Oct 2009 23:52:38 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Oct 2009 23:52:38 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AD3C145.5080501@FreeBSD.org> Date: Mon, 12 Oct 2009 16:52:37 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: security References: <4AD3ABD0.7010603@FreeBSD.org> <4AD3B4E3.2090406@elischer.org> <4AD3B67F.4070906@jim-liesl.org> In-Reply-To: <4AD3B67F.4070906@jim-liesl.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD 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, 12 Oct 2009 23:52:39 -0000 security wrote: > ATT uses PPPoE on their modems. Did your router have any special PPPoE > settings? It's a two-piece thing, "their" modem and my wireless router. The wireless router and windows know what to do with the info they are handed from the modem, FreeBSD doesn't. Sorry if I wasn't clear, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Mon Oct 12 23:59:13 2009 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 5D0E81065676 for ; Mon, 12 Oct 2009 23:59:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0B27E8FC14 for ; Mon, 12 Oct 2009 23:59:12 +0000 (UTC) Received: (qmail 4231 invoked by uid 399); 12 Oct 2009 23:59:12 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Oct 2009 23:59:12 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AD3C2CC.8000607@FreeBSD.org> Date: Mon, 12 Oct 2009 16:59:08 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: volker@vwsoft.com References: <20090913042742.GA32897@svzserv.kemerovo.su> <4AAD12BE.1090600@vwsoft.com> In-Reply-To: <4AAD12BE.1090600@vwsoft.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig7DB70B8037AE66A409CF57B0" Cc: Eugene Grosbein , net@freebsd.org Subject: Re: host(1) coredumps 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, 12 Oct 2009 23:59:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7DB70B8037AE66A409CF57B0 Content-Type: multipart/mixed; boundary="------------030505000504020106040800" This is a multi-part message in MIME format. --------------030505000504020106040800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable volker@vwsoft.com wrote: > On 09/13/09 06:27, Eugene Grosbein wrote: >> Hi! >> >> For 8.0-BETA3: >> >> % host -l grosbein.pp.ru. ns2.rucable.net. >> ; Transfer failed. >> /usr/local/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket= =2Ec:2486: >> REQUIRE((((sock) !=3D ((void *)0)) && (((const isc__magic_t *)(sock))-= >magic >> =3D=3D ((('I') << 24 | ('O') << 16 | ('i') << 8 | ('o')))))) failed. >> zsh: abort (core dumped) host -l grosbein.pp.ru. ns2.rucable.net. >> >> Shoud I send PR? >> >> Eugene Grosbein >=20 > Eugene, >=20 > the attached patch works around the error for me. As this is contribute= d > code, it should be fixed upstream (no need to file a PR). Can Eugene, Volker, and anyone else affected by this please try this very-lightly-modified version of the patch and confirm that it works? If so, I will get this in ASAP. Doug --=20 Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ --------------030505000504020106040800 Content-Type: text/plain; name="dighost.c.diff2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="dighost.c.diff2" Index: dighost.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- dighost.c (revision 198000) +++ dighost.c (working copy) @@ -2604,10 +2604,12 @@ =20 if (sevent->result =3D=3D ISC_R_CANCELED) { debug("in cancel handler"); - isc_socket_detach(&query->sock); - sockcount--; - INSIST(sockcount >=3D 0); - debug("sockcount=3D%d", sockcount); + if (query->sock !=3D NULL) { + isc_socket_detach(&query->sock); + sockcount--; + INSIST(sockcount >=3D 0); + debug("sockcount=3D%d", sockcount); + } query->waiting_connect =3D ISC_FALSE; isc_event_free(&event); l =3D query->lookup; --------------030505000504020106040800-- --------------enig7DB70B8037AE66A409CF57B0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEAREDAAYFAkrTws8ACgkQyIakK9Wy8PsX9wCg8O0PlhSkUFsoWGAJ+cPKrYL7 ByQAmwTR4zx4601TSlAz7H/TtxEJ0vNm =HWxw -----END PGP SIGNATURE----- --------------enig7DB70B8037AE66A409CF57B0-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 13 00:07:08 2009 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 5E4651065694; Tue, 13 Oct 2009 00:07:08 +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 A79D78FC1D; Tue, 13 Oct 2009 00:07:07 +0000 (UTC) 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 n9D074Q8059643; Tue, 13 Oct 2009 08:07:04 +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 n9D074bK059642; Tue, 13 Oct 2009 08:07:04 +0800 (KRAST) (envelope-from eugen) Date: Tue, 13 Oct 2009 08:07:04 +0800 From: Eugene Grosbein To: Doug Barton Message-ID: <20091013000704.GA59405@svzserv.kemerovo.su> References: <20090913042742.GA32897@svzserv.kemerovo.su> <4AAD12BE.1090600@vwsoft.com> <4AD3C2CC.8000607@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD3C2CC.8000607@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: volker@vwsoft.com, net@FreeBSD.org Subject: Re: host(1) coredumps 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, 13 Oct 2009 00:07:08 -0000 On Mon, Oct 12, 2009 at 04:59:08PM -0700, Doug Barton wrote: > Can Eugene, Volker, and anyone else affected by this please try this > very-lightly-modified version of the patch and confirm that it works? > If so, I will get this in ASAP. Yes, it works too :-) Thanks. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Oct 13 00:36:01 2009 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 4953F1065679; Tue, 13 Oct 2009 00:36:01 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in03.adhost.com (mail-in03.adhost.com [216.211.128.133]) by mx1.freebsd.org (Postfix) with ESMTP id 194988FC19; Tue, 13 Oct 2009 00:36:01 +0000 (UTC) Received: from ad-exh01.adhost.lan (exchange.adhost.com [216.211.143.69]) by mail-in03.adhost.com (Postfix) with ESMTP id 846D8E04814; Mon, 12 Oct 2009 17:35:58 -0700 (PDT) (envelope-from mksmith@adhost.com) Received: from 192.168.111.253 ([192.168.111.253]) by ad-exh01.adhost.lan ([10.142.0.20]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Oct 2009 00:35:58 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 12 Oct 2009 17:35:57 -0700 From: "Michael K. Smith" To: Doug Barton Message-ID: Thread-Topic: Wacky DHCP values that work in windows but not in FreeBSD Thread-Index: AcpLnSEO0I4/8zqleUeF6XuBGOxrAg== In-Reply-To: <4AD3B9FB.4010205@FreeBSD.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: FreeBSD Net , Julian Elischer Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD 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, 13 Oct 2009 00:36:01 -0000 On 10/12/09 4:21 PM, "Doug Barton" wrote: > Michael K. Smith - Adhost wrote: >>> -----Original Message----- >>> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >>> net@freebsd.org] On Behalf Of Julian Elischer >>> Sent: Monday, October 12, 2009 4:00 PM >>> To: Doug Barton >>> Cc: freebsd-net@freebsd.org >>> Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD >>> >>> Doug Barton wrote: >>>> Howdy, >>>> >>>> I usually have a wireless router connected directly to the >> AT&T/Yahoo >>>> DSL modem but last night I wanted to do some debugging so I plugged >>> my >>>> laptop directly into the modem (after powering off the modem, etc.). >>>> >>>> The values I got back from DHCP not only don't make sense, they >>> didn't >>>> work in FreeBSD at all. Dual-booting to Windows showed that the >>> values >>>> I saw from DHCP were "correct," and somehow they managed to work. >>>> Taking a closer look at the router after I plugged it back in showed >>>> the same. >>>> >>>> Dhcp Enabled. . . . . . . . . . . : Yes >>>> Autoconfiguration Enabled . . . . : Yes >>>> IP Address. . . . . . . . . . . . : 76.212.147.xxx >>>> Subnet Mask . . . . . . . . . . . : 255.255.0.0 >>>> Default Gateway . . . . . . . . . : 151.164.184.xxx >>> huh? >>> >>> only way this could work would be if it was marked as "point to point" >>> I think.. >> >> That could be a primary IP address on an interface on which your 76 >> address is a sub interface. > > Can you specify what you mean by 'that'? Sure. In Cisco world Interface GigE0/0 Ip address 151.164.184.xxx 255.255.255.252 (or whatever the mask is) Ip addres 76.212.147.1 255.255.0.0 secondary They will use the primary IP address as the default. > >> The interface will do proxy-arp when a >> traffic request comes in. Or something else! I'm not sure if this will >> work, but you could actually hard code your default gateway with a >> -hopcount 2 (or higher) and see if that works. I've not tried it on a >> live machine. Something like route add default 151.164.184.xxx >> -hopcount 5. You may have to delete the DHCP-assigned entry first. > > Ah, I didn't know about -hopcount, thanks. There was no default route > installed at all when I booted. I tried 'route add default 151...' > even though I was sure it wouldn't work, and I was not disappointed. Heh. It probably complained because you weren't on the local network. As Julian mentioned, you may be able to add the -iface should help. Also, if you wanted to test, you could add yourself on the same subnet as the default gateway. Depending on what xxx is on the 151 net, you could add an interface address in the same subnet. As an example, if the address is 50, you could add 49 and a /30 subnet mask. Another trick would be to plug the windows box back in and do an 'arp -an' and find the MAC address for the 151 (if it's available). Then, you can manually add the arp to your FreeBSD box. Mike From owner-freebsd-net@FreeBSD.ORG Tue Oct 13 03:30:36 2009 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 21BBC1065672 for ; Tue, 13 Oct 2009 03:30:36 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id D54EF8FC15 for ; Tue, 13 Oct 2009 03:30:35 +0000 (UTC) Received: by ywh35 with SMTP id 35so31572680ywh.7 for ; Mon, 12 Oct 2009 20:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DzQodQCMGpiWMsFoFSzhnce09MZ8dfKHtX+Lc98oaxQ=; b=ZRbnGogV+ni4gHDBcRXluhTFnBfjDRUNlSb+m/bb2ca8BbJD30QAL266PHBeA9PV2o AEVssse234TOaO8k/tIoJ/gqhMUujWRl67+49lAcn8pDK2Nnm12GDYdQH+0vRLxGM68i Lwzvb+NL7z8+yQLYzDuQIHRx+PXqF9tKYZcII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Oe5lYWiItCyRFtf3nddeR3/qVaTcdPGOeJdToVsksvU8fP64Ac0gkwp1IlJuQCKzeP RUM9OAAEdSMSgvVRBCJeqBnQujQbwLaCHay8yWtt+QxWJsnmZ/matyrri2uDcV0IfVCJ kCRHEAWI33rYng4mSpAUnuvS/NE7Q385jrors= MIME-Version: 1.0 Received: by 10.101.113.12 with SMTP id q12mr6206019anm.124.1255404635108; Mon, 12 Oct 2009 20:30:35 -0700 (PDT) In-Reply-To: <4AD3ABD0.7010603@FreeBSD.org> References: <4AD3ABD0.7010603@FreeBSD.org> Date: Mon, 12 Oct 2009 23:30:35 -0400 Message-ID: <25ff90d60910122030r1f8511e9ued9535024fa3078a@mail.gmail.com> From: David Horn To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD 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, 13 Oct 2009 03:30:36 -0000 On Mon, Oct 12, 2009 at 6:21 PM, Doug Barton wrote: > Howdy, > > I usually have a wireless router connected directly to the AT&T/Yahoo > DSL modem but last night I wanted to do some debugging so I plugged my > laptop directly into the modem (after powering off the modem, etc.). > > The values I got back from DHCP not only don't make sense, they didn't > work in FreeBSD at all. Dual-booting to Windows showed that the values > I saw from DHCP were "correct," and somehow they managed to work. > Taking a closer look at the router after I plugged it back in showed > the same. > > =A0 =A0 =A0 =A0Dhcp Enabled. . . . . . . . . . . : Yes > =A0 =A0 =A0 =A0Autoconfiguration Enabled . . . . : Yes > =A0 =A0 =A0 =A0IP Address. . . . . . . . . . . . : 76.212.147.xxx > =A0 =A0 =A0 =A0Subnet Mask . . . . . . . . . . . : 255.255.0.0 > =A0 =A0 =A0 =A0Default Gateway . . . . . . . . . : 151.164.184.xxx > =A0 =A0 =A0 =A0DHCP Server . . . . . . . . . . . : 192.168.1.xxx > =A0 =A0 =A0 =A0DNS Servers . . . . . . . . . . . : 192.168.1.xxx > > Can anyone tell me how they managed to get this to work in Windows, > and suggest where to look to get it working in FreeBSD? > > > Doug > Without seeing the actual tcpdump of the dhcp packets, I would guess that this is the Classless Static Route option in DHCPv4 (option 121). See: http://www.rfc-editor.org/rfc/rfc3442.txt http://www.iana.org/assignments/bootp-dhcp-parameters/ But tcpdump before dhclient initialization of the interface should show what options are in play (I could be wrong on option 121) tcpdump -vvv -i em0 port bootpc Good Luck. ---Dave H From owner-freebsd-net@FreeBSD.ORG Tue Oct 13 05:31:57 2009 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 79924106568D for ; Tue, 13 Oct 2009 05:31:57 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0958FC08 for ; Tue, 13 Oct 2009 05:31:56 +0000 (UTC) Received: (qmail 13814 invoked by uid 399); 13 Oct 2009 05:31:56 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 13 Oct 2009 05:31:56 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AD410CB.2060105@FreeBSD.org> Date: Mon, 12 Oct 2009 22:31:55 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: David Horn References: <4AD3ABD0.7010603@FreeBSD.org> <25ff90d60910122030r1f8511e9ued9535024fa3078a@mail.gmail.com> In-Reply-To: <25ff90d60910122030r1f8511e9ued9535024fa3078a@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD 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, 13 Oct 2009 05:31:57 -0000 David Horn wrote: > Without seeing the actual tcpdump of the dhcp packets, I would guess > that this is the Classless Static Route option in DHCPv4 (option 121). Ok, I will give the tcpdump option a go as soon as I have a chance. Meanwhile, if this is in fact the case how would we make it work in FreeBSD? Is there a newer version of DHCP that handles this properly? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Oct 13 05:55:31 2009 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 C4D541065672; Tue, 13 Oct 2009 05:55:31 +0000 (UTC) (envelope-from dhorn2000@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6ACBB8FC14; Tue, 13 Oct 2009 05:55:31 +0000 (UTC) Received: by gxk6 with SMTP id 6so9033208gxk.13 for ; Mon, 12 Oct 2009 22:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WYiezTPziHQpaGPnnmYfpl87g/Pv433iq2AHUkumYX8=; b=Dx1BnrPBoGj5naXXTcn31X09W/l7RWIResW66GN0+AlNgSRgtWLDkhb0+n5/bddjkZ puA3271Hh6xx6gKiOdPZrfnaYE+PGEQKX0ZutEqRoLoNGlyh/vXmxyE0TVLZ6v+KH3P1 20q2o7O8WZ11I0oN//6r8ndP0WFNPAL2tWYMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QtyH5kXt/gc+wDnsu7YgPPQlOzN+/50MpNw7VOc/oflcLKgJSrvO8T3qA5w3tAb6Qn mwosrdj10cwuxyhuG8WNkrd4TiQcLFrybApBfXBXPPUemAr4p6EuxdqbENuF5TUMzUDX pwO9Y2/Fdl0ZxRT9pcnrAAgasPEva6vHvTSiU= MIME-Version: 1.0 Received: by 10.90.18.33 with SMTP id 33mr4086858agr.113.1255413330651; Mon, 12 Oct 2009 22:55:30 -0700 (PDT) In-Reply-To: <4AD410CB.2060105@FreeBSD.org> References: <4AD3ABD0.7010603@FreeBSD.org> <25ff90d60910122030r1f8511e9ued9535024fa3078a@mail.gmail.com> <4AD410CB.2060105@FreeBSD.org> Date: Tue, 13 Oct 2009 01:55:30 -0400 Message-ID: <25ff90d60910122255j5ccae96ar7c58488209768956@mail.gmail.com> From: David Horn To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Wacky DHCP values that work in windows but not in FreeBSD 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, 13 Oct 2009 05:55:31 -0000 On Tue, Oct 13, 2009 at 1:31 AM, Doug Barton wrote: > David Horn wrote: >> Without seeing the actual tcpdump of the dhcp packets, I would guess >> that this is the Classless Static Route option in DHCPv4 (option 121). > > Ok, I will give the tcpdump option a go as soon as I have a chance. > > Meanwhile, if this is in fact the case how would we make it work in > FreeBSD? Is there a newer version of DHCP that handles this properly? I thought that dhclient originated from ISC, but looking at the 4.1.1b2 ISC DHCP source and at the OpenBSD dhclient, I did not see option 121 handling in dhclient. The freebsd copy of both dhclient.c, and /sbin/dhclient-script there is code for handling this option. I guess the FreeBSD version split from the ISC version at some point, and option 121 handling was added (2+ years ago). As far as fixing/debugging, it all depends on the exact dhcp options and values. It might just be a tweak to /sbin/dhclient-script, or it may be more complicated. http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dhclient/dhclient.c Revision 1.21: download - view: text, markup, annotated - select for diffs Fri Feb 9 17:50:26 2007 UTC (2 years, 8 months ago) by emaste Branches: MAIN CVS tags: RELENG_7_BP, RELENG_7_0_BP, RELENG_7_0_0_RELEASE, RELENG_7_0 Branch point for: RELENG_7 Diff to: previous 1.20: preferred, colored Changes since revision 1.20: +68 -0 lines Implement RFC3442, the Classless Static Route option. The original DHCP specification includes a route option but it supports only class-based routes. RFC3442 adds support for specifying the netmask width for each static route. A variable length encoding is used to minimize the size of this option. PR: bin/99534 Submitted by: Andrey V. Elsukov Reviewed by: brooks ---Dave H From owner-freebsd-net@FreeBSD.ORG Tue Oct 13 08:20:04 2009 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 CD164106566B for ; Tue, 13 Oct 2009 08:20: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 BAF718FC0A for ; Tue, 13 Oct 2009 08:20:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9D8K4F6080739 for ; Tue, 13 Oct 2009 08:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9D8K42Y080738; Tue, 13 Oct 2009 08:20:04 GMT (envelope-from gnats) Date: Tue, 13 Oct 2009 08:20:04 GMT Message-Id: <200910130820.n9D8K42Y080738@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: kause lotski Cc: Subject: Re: kern/137317: [tcp] logs full of syncache problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kause lotski List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 08:20:04 -0000 The following reply was made to PR kern/137317; it has been noted by GNATS. From: kause lotski To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/137317: [tcp] logs full of syncache problems Date: Tue, 13 Oct 2009 00:43:36 -0700 (PDT) perhaps some more information would help: I'm experiencing this on two different boxes with totally different hardware, one located at datacenter and connected via LAN and second one that is sitting on ADSL line. I have tried all sysctl variables that I could find remotely related to this with no luck, tried compiling kernel with and without DUMMYNET This are kernel customizations I use: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options DUMMYNET options HZ=1000 # strongly recommended options IPDIVERT options IPSTEALTH #support for stealth forwarding options ACCEPT_FILTER_HTTP # Must be here or AcceptFilter won't work w/Apache2 options DEVICE_POLLING # Imporoves network driver performance options ZERO_COPY_SOCKETS device coretemp # On-die temperature sensor on Intel Core and newer CPUs Is it at least possible to turn of this checks for local IP's - it is most disturbing that I'm getting droped packets at apache jail to mysql jail communication? From owner-freebsd-net@FreeBSD.ORG Tue Oct 13 13:35:17 2009 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 4B9D61065696; Tue, 13 Oct 2009 13:35: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 1FF558FC08; Tue, 13 Oct 2009 13:35:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9DDZHSZ060199; Tue, 13 Oct 2009 13:35:17 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9DDZGV2060195; Tue, 13 Oct 2009 13:35:17 GMT (envelope-from linimon) Date: Tue, 13 Oct 2009 13:35:17 GMT Message-Id: <200910131335.n9DDZGV2060195@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/139559: [tun] several tun(4) interfaces can be created with same dst addr 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, 13 Oct 2009 13:35:17 -0000 Old Synopsis: several tun(4) interfaces can be created with same dst addr New Synopsis: [tun] several tun(4) interfaces can be created with same dst addr Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Oct 13 13:34:59 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139559 From owner-freebsd-net@FreeBSD.ORG Tue Oct 13 20:45:08 2009 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 09BB11065679 for ; Tue, 13 Oct 2009 20:45:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id A6B158FC0A for ; Tue, 13 Oct 2009 20:45:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2FFC841C667 for ; Tue, 13 Oct 2009 22:45:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id qb9v04Sl2gPq for ; Tue, 13 Oct 2009 22:45:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 8306941C650; Tue, 13 Oct 2009 22:45: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 14C9B4448E6 for ; Tue, 13 Oct 2009 20:42:22 +0000 (UTC) Date: Tue, 13 Oct 2009 20:42:21 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: freebsd-net@FreeBSD.org Message-ID: <20091013203302.N5956@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: testers for bge(4) needed (possible fix for ASF + hang) 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, 13 Oct 2009 20:45:08 -0000 Hi, this is believed to fix hangs upon boot when the interfaces are configured and ASF is enabled. As seen in the PRs, this is often observed on HP servers. In case you have a bge machine not affected by that it owuld be really helpful if you could test the change anyway to assure this doesn't break any of the several dozen chip revisions we couldn't test. The patch is also fetchable from http://people.freebsd.org/~bz/20091011-01-bge-asf.diff In case it doesn't apply to your older version of the driver cleanly let me know and I'll do a patch for your version as well. In case you find a regression with that let me know immediately with: uname -mr; dmesg | grep bge ; pciconf -lv | grep ^bge Thanks a lot. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ---------- Forwarded message ---------- Date: Tue, 13 Oct 2009 20:22:12 +0000 (UTC) From: Bjoern A. Zeeb To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r198049 - head/sys/dev/bge Author: bz Date: Tue Oct 13 20:22:12 2009 New Revision: 198049 URL: http://svn.freebsd.org/changeset/base/198049 Log: Immediately after clearing a pending callout that didn't make it due to the lock we hold, disable interrupts, and announce to the firmware that we are shutting down. Especially do this before disabling blocks. This makes some types of machines with asf enabled no longer hang upon boot, when we start configuring the interface. PR: i386/96382, kern/100410, kern/122252, kern/116328 Reported by: erwin Hardware provided by: TDC A/S Reviewed by: stas Tested by: stas Modified: head/sys/dev/bge/if_bge.c Modified: head/sys/dev/bge/if_bge.c ============================================================================== --- head/sys/dev/bge/if_bge.c Tue Oct 13 20:21:17 2009 (r198048) +++ head/sys/dev/bge/if_bge.c Tue Oct 13 20:22:12 2009 (r198049) @@ -4270,6 +4270,16 @@ bge_stop(struct bge_softc *sc) callout_stop(&sc->bge_stat_ch); + /* Disable host interrupts. */ + BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); + bge_writembx(sc, BGE_MBX_IRQ0_LO, 1); + + /* + * Tell firmware we're shutting down. + */ + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_STOP); + /* * Disable all of the receiver blocks. */ @@ -4309,16 +4319,6 @@ bge_stop(struct bge_softc *sc) BGE_CLRBIT(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE); } - /* Disable host interrupts. */ - BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); - bge_writembx(sc, BGE_MBX_IRQ0_LO, 1); - - /* - * Tell firmware we're shutting down. - */ - - bge_stop_fw(sc); - bge_sig_pre_reset(sc, BGE_RESET_STOP); bge_reset(sc); bge_sig_legacy(sc, BGE_RESET_STOP); bge_sig_post_reset(sc, BGE_RESET_STOP); From owner-freebsd-net@FreeBSD.ORG Wed Oct 14 11:10:03 2009 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 BEA9F1065676 for ; Wed, 14 Oct 2009 11:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 90B0C8FC24 for ; Wed, 14 Oct 2009 11:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9EBA3l3002280 for ; Wed, 14 Oct 2009 11:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9EBA3UQ002279; Wed, 14 Oct 2009 11:10:03 GMT (envelope-from gnats) Date: Wed, 14 Oct 2009 11:10:03 GMT Message-Id: <200910141110.n9EBA3UQ002279@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrey Simonenko Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Simonenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 11:10:03 -0000 The following reply was made to PR bin/131567; it has been noted by GNATS. From: Andrey Simonenko To: bug-followup@freebsd.org Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg Date: Wed, 14 Oct 2009 14:07:13 +0300 Updated version of the patch for regression/sockets/unix_cmsg has some optimizations and does not use SIGALRM. Can somebody verify whether it is possible to increase WARNS to higher level (I tested unix_cmsg on i386 and amd64 on 8.0-RC1 release)? diff -ruNp unix_cmsg.orig/README unix_cmsg/README --- unix_cmsg.orig/README 2006-05-29 21:40:55.000000000 +0300 +++ unix_cmsg/README 2009-10-14 13:31:06.000000000 +0300 @@ -1,7 +1,7 @@ $FreeBSD: src/tools/regression/sockets/unix_cmsg/README,v 1.1 2006/05/29 18:40:55 maxim Exp $ About unix_cmsg -================ +=============== This program is a collection of regression tests for ancillary (control) data for PF_LOCAL sockets (local domain or Unix domain sockets). There @@ -13,8 +13,8 @@ is correct in received message. Sometim messages to Server. It is better to change the owner of unix_cmsg to some safe user -(eg. nobody:nogroup) and set SUID and SGID bits, else some tests -can give correct results for wrong implementation. +(eg. nobody:nogroup) and set SUID and SGID bits, else some tests that +check credentials can give correct results for wrong implementation. Available options ================= @@ -24,13 +24,13 @@ Available options -h Output help message and exit. --t +-t socktype Run tests only for the given socket type: "stream" or "dgram". With this option it is possible to run only particular test, not all of them. -z Do not send real control data if possible. Struct cmsghdr{} - should be followed by real control data. It is not clear if + should be followed by real control data. It is not clear whether a sender should give control data in all cases (this is not documented and an arbitrary application can choose anything). @@ -90,6 +90,13 @@ For SOCK_STREAM sockets: message with data and control message with SCM_TIMESTAMP type followed by struct timeval{}. + 6: Check LOCAL_PEERCRED socket option + + This test does not use control data for PF_LOCAL sockets, but can be + implemented here. Client connects to Server. Both Client and Server + verify that credentials of the peer are correct using LOCAL_PEERCRED + socket option. + For SOCK_DGRAM sockets: ---------------------- @@ -110,7 +117,7 @@ For SOCK_DGRAM sockets: structure should contain correct information. 3: Sending cmsgcred, receiving sockcred - + Server creates datagram socket and set socket option LOCAL_CREDS for it. Client sends one message with data and control message with SOCK_CREDS type to Server. Server should receive one message with diff -ruNp unix_cmsg.orig/unix_cmsg.c unix_cmsg/unix_cmsg.c --- unix_cmsg.orig/unix_cmsg.c 2006-05-31 11:10:34.000000000 +0300 +++ unix_cmsg/unix_cmsg.c 2009-10-14 13:47:51.000000000 +0300 @@ -27,10 +27,12 @@ #include __FBSDID("$FreeBSD: src/tools/regression/sockets/unix_cmsg/unix_cmsg.c,v 1.2 2006/05/31 08:10:34 maxim Exp $"); -#include +#include #include #include +#include #include +#include #include #include @@ -38,16 +40,15 @@ __FBSDID("$FreeBSD: src/tools/regression #include #include #include +#include #include #include -#include #include #include #include #include #include #include -#include #include /* @@ -68,7 +69,7 @@ __FBSDID("$FreeBSD: src/tools/regression * * Each function which can block, is run under TIMEOUT, if timeout * occurs, then test function returns -2 or a client process exits - * with nonzero return code. + * with non-zero return code. */ #ifndef LISTENQ @@ -76,46 +77,76 @@ __FBSDID("$FreeBSD: src/tools/regression #endif #ifndef TIMEOUT -# define TIMEOUT 60 +# define TIMEOUT 5 #endif #define EXTRA_CMSG_SPACE 512 /* Memory for not expected control data. */ -static int t_cmsgcred(void), t_sockcred_stream1(void); -static int t_sockcred_stream2(void), t_cmsgcred_sockcred(void); -static int t_sockcred_dgram(void), t_timestamp(void); +static int t_cmsgcred(void); +static int t_sockcred_stream1(void); +static int t_sockcred_stream2(void); +static int t_cmsgcred_sockcred(void); +static int t_sockcred_dgram(void); +static int t_timestamp(void); +static int t_peercred(void); struct test_func { - int (*func)(void); /* Pointer to function. */ - const char *desc; /* Test description. */ + int (*func)(void); /* Pointer to function. */ + const char *desc; /* Test description. */ }; static struct test_func test_stream_tbl[] = { - { NULL, " 0: All tests" }, - { t_cmsgcred, " 1: Sending, receiving cmsgcred" }, - { t_sockcred_stream1, " 2: Receiving sockcred (listening socket has LOCAL_CREDS)" }, - { t_sockcred_stream2, " 3: Receiving sockcred (accepted socket has LOCAL_CREDS)" }, - { t_cmsgcred_sockcred, " 4: Sending cmsgcred, receiving sockcred" }, - { t_timestamp, " 5: Sending, receiving timestamp" }, - { NULL, NULL } + { .func = NULL, + .desc = "All tests" + }, + { .func = t_cmsgcred, + .desc = "Sending, receiving cmsgcred" + }, + { .func = t_sockcred_stream1, + .desc = "Receiving sockcred (listening socket has LOCAL_CREDS)" + }, + { .func = t_sockcred_stream2, + .desc = "Receiving sockcred (accepted socket has LOCAL_CREDS)" + }, + { .func = t_cmsgcred_sockcred, + .desc = "Sending cmsgcred, receiving sockcred" + }, + { .func = t_timestamp, + .desc = "Sending, receiving timestamp" + }, + { .func = t_peercred, + .desc = "Check LOCAL_PEERCRED socket option" + } }; +#define TEST_STREAM_TBL_SIZE \ + (sizeof(test_stream_tbl) / sizeof(test_stream_tbl[0])) + static struct test_func test_dgram_tbl[] = { - { NULL, " 0: All tests" }, - { t_cmsgcred, " 1: Sending, receiving cmsgcred" }, - { t_sockcred_dgram, " 2: Receiving sockcred" }, - { t_cmsgcred_sockcred, " 3: Sending cmsgcred, receiving sockcred" }, - { t_timestamp, " 4: Sending, receiving timestamp" }, - { NULL, NULL } + { .func = NULL, + .desc = "All tests" + }, + { .func = t_cmsgcred, + .desc = "Sending, receiving cmsgcred" + }, + { .func = t_sockcred_dgram, + .desc = "Receiving sockcred" + }, + { .func = t_cmsgcred_sockcred, + .desc = "Sending cmsgcred, receiving sockcred" + }, + { .func = t_timestamp, + .desc = "Sending, receiving timestamp" + } }; -#define TEST_STREAM_NO_MAX (sizeof(test_stream_tbl) / sizeof(struct test_func) - 2) -#define TEST_DGRAM_NO_MAX (sizeof(test_dgram_tbl) / sizeof(struct test_func) - 2) +#define TEST_DGRAM_TBL_SIZE \ + (sizeof(test_dgram_tbl) / sizeof(test_dgram_tbl[0])) -static const char *myname = "SERVER"; /* "SERVER" or "CLIENT" */ +static const char *myname; /* "SERVER" or "CLIENT" */ -static int debug = 0; /* 1, if -d. */ -static int no_control_data = 0; /* 1, if -z. */ +static int debug = 0; /* -d */ +static int no_control_data = 0; /* -z */ static u_int nfailed = 0; /* Number of failed tests. */ @@ -131,8 +162,6 @@ static char ipc_message[] = "hello"; static struct sockaddr_un servaddr; /* Server address. */ -static sigjmp_buf env_alrm; - static uid_t my_uid; static uid_t my_euid; static gid_t my_gid; @@ -156,32 +185,29 @@ static void logmsg(const char *, ...) __ static void logmsgx(const char *, ...) __printflike(1, 2); static void output(const char *, ...) __printflike(1, 2); -extern char *__progname; /* The name of program. */ - /* * Output the help message (-h switch). */ static void -usage(int quick) +usage(const int verbose) { - const struct test_func *test_func; + u_int i; - fprintf(stderr, "Usage: %s [-dhz] [-t ] [testno]\n", - __progname); - if (quick) + fprintf(stderr, "usage: %s [-dhz] [-t socktype] [testno]\n", + getprogname()); + if (!verbose) return; fprintf(stderr, "\n Options are:\n\ -d\t\t\tOutput debugging information\n\ -h\t\t\tOutput this help message and exit\n\ - -t \t\tRun test only for the given socket type:\n\ -\t\t\tstream or dgram\n\ + -t socktype\t\tRun test only for socket type: stream or dgram\n\ -z\t\t\tDo not send real control data if possible\n\n"); fprintf(stderr, " Available tests for stream sockets:\n"); - for (test_func = test_stream_tbl; test_func->desc != NULL; ++test_func) - fprintf(stderr, " %s\n", test_func->desc); + for (i = 0; i < TEST_STREAM_TBL_SIZE; ++i) + fprintf(stderr, " %u: %s\n", i, test_stream_tbl[i].desc); fprintf(stderr, "\n Available tests for datagram sockets:\n"); - for (test_func = test_dgram_tbl; test_func->desc != NULL; ++test_func) - fprintf(stderr, " %s\n", test_func->desc); + for (i = 0; i < TEST_DGRAM_TBL_SIZE; ++i) + fprintf(stderr, " %u: %s\n", i, test_dgram_tbl[i].desc); } /* @@ -195,7 +221,7 @@ output(const char *format, ...) va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "output: vsnprintf failed"); + err(EXIT_FAILURE, "output: vsnprintf failed"); write(STDOUT_FILENO, buf, strlen(buf)); va_end(ap); } @@ -210,18 +236,16 @@ logmsg(const char *format, ...) va_list ap; int errno_save; - errno_save = errno; /* Save errno. */ - + errno_save = errno; va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "logmsg: vsnprintf failed"); + err(EXIT_FAILURE, "logmsg: vsnprintf failed"); if (errno_save == 0) output("%s: %s\n", myname, buf); else output("%s: %s: %s\n", myname, buf, strerror(errno_save)); va_end(ap); - - errno = errno_save; /* Restore errno. */ + errno = errno_save; } /* @@ -235,33 +259,47 @@ logmsgx(const char *format, ...) va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "logmsgx: vsnprintf failed"); + err(EXIT_FAILURE, "logmsgx: vsnprintf failed"); output("%s: %s\n", myname, buf); va_end(ap); } /* - * Run tests from testno1 to testno2. + * Run tests for the given socket type. */ static int -run_tests(u_int testno1, u_int testno2) +run_tests(const int type, u_int testno1) { - const struct test_func *test_func; - u_int i, nfailed1; + const struct test_func *tf; + u_int i, nfailed1, testno2; - output("Running tests for %s sockets:\n", sock_type_str); - test_func = (sock_type == SOCK_STREAM ? - test_stream_tbl : test_dgram_tbl) + testno1; + sock_type = type; + if (type == SOCK_STREAM) { + sock_type_str = "SOCK_STREAM"; + tf = test_stream_tbl; + i = TEST_STREAM_TBL_SIZE - 1; + } else { + sock_type_str = "SOCK_DGRAM"; + tf = test_dgram_tbl; + i = TEST_DGRAM_TBL_SIZE - 1; + } + if (testno1 == 0) { + testno1 = 1; + testno2 = i; + } else + testno2 = testno1; + output("Running tests for %s sockets:\n", sock_type_str); nfailed1 = 0; - for (i = testno1; i <= testno2; ++test_func, ++i) { - output(" %s\n", test_func->desc); - switch (test_func->func()) { + for (i = testno1, tf += testno1; i <= testno2; ++tf, ++i) { + output(" %u: %s\n", i, tf->desc); + switch (tf->func()) { case -1: ++nfailed1; break; case -2: - logmsgx("some system error occurred, exiting"); + logmsgx("some system error or timeout occurred, " + "exiting"); return (-1); } } @@ -284,38 +322,40 @@ run_tests(u_int testno1, u_int testno2) return (0); } -/* ARGSUSED */ -static void -sig_alrm(int signo __unused) -{ - siglongjmp(env_alrm, 1); -} - /* * Initialize signals handlers. */ static void sig_init(void) { - struct sigaction sa; + struct sigaction sigact; + + sigact.sa_handler = SIG_IGN; + sigact.sa_flags = 0; + sigemptyset(&sigact.sa_mask); + if (sigaction(SIGPIPE, &sigact, (struct sigaction *)NULL) < 0) + err(EXIT_FAILURE, "sigaction(SIGPIPE)"); +} - sa.sa_handler = SIG_IGN; - sigemptyset(&sa.sa_mask); - sa.sa_flags = 0; - if (sigaction(SIGPIPE, &sa, (struct sigaction *)NULL) < 0) - err(EX_OSERR, "sigaction(SIGPIPE)"); - - sa.sa_handler = sig_alrm; - if (sigaction(SIGALRM, &sa, (struct sigaction *)NULL) < 0) - err(EX_OSERR, "sigaction(SIGALRM)"); +static int +fork_client(void) +{ + client_pid = fork(); + if (client_pid == 0) + myname = "CLIENT"; + else if (client_pid == (pid_t)-1) { + logmsg("fork"); + return (-1); + } + return (0); } int main(int argc, char *argv[]) { const char *errstr; - int opt, dgramflag, streamflag; - u_int testno1, testno2; + u_int testno; + int opt, rv, dgramflag, streamflag; dgramflag = streamflag = 0; while ((opt = getopt(argc, argv, "dht:z")) != -1) @@ -324,141 +364,162 @@ main(int argc, char *argv[]) debug = 1; break; case 'h': - usage(0); - return (EX_OK); + usage(1); + return (EXIT_SUCCESS); case 't': if (strcmp(optarg, "stream") == 0) streamflag = 1; else if (strcmp(optarg, "dgram") == 0) dgramflag = 1; else - errx(EX_USAGE, "wrong socket type in -t option"); + errx(EXIT_FAILURE, "option -t: wrong " + "socket type"); break; case 'z': no_control_data = 1; break; case '?': default: - usage(1); - return (EX_USAGE); + usage(0); + return (EXIT_FAILURE); } if (optind < argc) { if (optind + 1 != argc) - errx(EX_USAGE, "too many arguments"); - testno1 = strtonum(argv[optind], 0, UINT_MAX, &errstr); + errx(EXIT_FAILURE, "too many arguments"); + testno = strtonum(argv[optind], 0, UINT_MAX, &errstr); if (errstr != NULL) - errx(EX_USAGE, "wrong test number: %s", errstr); + errx(EXIT_FAILURE, "wrong test number: %s", errstr); } else - testno1 = 0; + testno = 0; if (dgramflag == 0 && streamflag == 0) dgramflag = streamflag = 1; - if (dgramflag && streamflag && testno1 != 0) - errx(EX_USAGE, "you can use particular test, only with datagram or stream sockets"); + if (dgramflag && streamflag && testno != 0) + errx(EXIT_FAILURE, "you can use particular test, only " + "with datagram or stream sockets"); if (streamflag) { - if (testno1 > TEST_STREAM_NO_MAX) - errx(EX_USAGE, "given test %u for stream sockets does not exist", - testno1); + if (testno >= TEST_STREAM_TBL_SIZE) + errx(EXIT_FAILURE, "given test %u for stream " + "sockets does not exist", testno); } else { - if (testno1 > TEST_DGRAM_NO_MAX) - errx(EX_USAGE, "given test %u for datagram sockets does not exist", - testno1); + if (testno >= TEST_DGRAM_TBL_SIZE) + errx(EXIT_FAILURE, "given test %u for datagram " + "sockets does not exist", testno); } my_uid = getuid(); my_euid = geteuid(); my_gid = getgid(); my_egid = getegid(); - switch (my_ngids = getgroups(sizeof(my_gids) / sizeof(my_gids[0]), my_gids)) { + my_ngids = getgroups(sizeof(my_gids) / sizeof(my_gids[0]), my_gids); + switch (my_ngids) { case -1: - err(EX_SOFTWARE, "getgroups"); + err(EXIT_FAILURE, "getgroups"); /* NOTREACHED */ case 0: - errx(EX_OSERR, "getgroups returned 0 groups"); + errx(EXIT_FAILURE, "getgroups returned no groups"); } sig_init(); if (mkdtemp(tempdir) == NULL) - err(EX_OSERR, "mkdtemp"); + err(EXIT_FAILURE, "mkdtemp"); - if (streamflag) { - sock_type = SOCK_STREAM; - sock_type_str = "SOCK_STREAM"; - if (testno1 == 0) { - testno1 = 1; - testno2 = TEST_STREAM_NO_MAX; - } else - testno2 = testno1; - if (run_tests(testno1, testno2) < 0) - goto failed; - testno1 = 0; - } - - if (dgramflag) { - sock_type = SOCK_DGRAM; - sock_type_str = "SOCK_DGRAM"; - if (testno1 == 0) { - testno1 = 1; - testno2 = TEST_DGRAM_NO_MAX; - } else - testno2 = testno1; - if (run_tests(testno1, testno2) < 0) - goto failed; - } + myname = "SERVER"; + rv = EXIT_SUCCESS; + if (streamflag) + if (run_tests(SOCK_STREAM, testno) < 0) + rv = EXIT_FAILURE; + if (dgramflag && rv == EXIT_SUCCESS) + if (run_tests(SOCK_DGRAM, testno) < 0) + rv = EXIT_FAILURE; if (rmdir(tempdir) < 0) { logmsg("rmdir(%s)", tempdir); - return (EX_OSERR); + rv = EXIT_FAILURE; } - return (nfailed ? EX_OSERR : EX_OK); + return (nfailed > 0 ? EXIT_FAILURE : rv); +} -failed: - if (rmdir(tempdir) < 0) - logmsg("rmdir(%s)", tempdir); - return (EX_OSERR); +/* + * Close socket descriptor, if sock_path is not equal to NULL, + * then unlink the given path. + */ +static int +close_socket(const char *sock_path, const int fd) +{ + int rv; + + if (close(fd) < 0) { + logmsg("close_socket: close"); + rv = -1; + } else + rv = 0; + if (sock_path != NULL) + if (unlink(sock_path) < 0) { + logmsg("close_socket: unlink(%s)", sock_path); + rv = -1; + } + return (rv); } /* * Create PF_LOCAL socket, if sock_path is not equal to NULL, then - * bind() it. Return socket address in addr. Return file descriptor + * bind() it. Return socket address in *un. Return file descriptor * or -1 if some error occurred. */ static int -create_socket(char *sock_path, size_t sock_path_len, struct sockaddr_un *addr) +create_socket(char *sock_path, const size_t sock_path_len, + struct sockaddr_un *un) { - int rv, fd; + struct timeval tv; + int fd; - if ((fd = socket(PF_LOCAL, sock_type, 0)) < 0) { - logmsg("create_socket: socket(PF_LOCAL, %s, 0)", sock_type_str); + fd = socket(PF_LOCAL, sock_type, 0); + if (fd < 0) { + logmsg("create_socket: socket(PF_LOCAL, %s, 0)", + sock_type_str); return (-1); } + tv.tv_sec = TIMEOUT; + tv.tv_usec = 0; + if (setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)) < 0 || + setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof(tv)) < 0) { + logmsg("create_socket: setsockopt(SO_RCVTIMEO/SO_SNDTIMEO)"); + goto failed; + } + if (sock_path != NULL) { - if ((rv = snprintf(sock_path, sock_path_len, "%s/%s", - tempdir, myname)) < 0) { + int rv; + + rv = snprintf(sock_path, sock_path_len, "%s/%s", tempdir, + myname); + if (rv < 0) { logmsg("create_socket: snprintf failed"); goto failed; } if ((size_t)rv >= sock_path_len) { - logmsgx("create_socket: too long path name for given buffer"); + logmsgx("create_socket: too long path name for " + "given buffer"); goto failed; } - - memset(addr, 0, sizeof(addr)); - addr->sun_family = AF_LOCAL; - if (strlen(sock_path) >= sizeof(addr->sun_path)) { - logmsgx("create_socket: too long path name (>= %lu) for local domain socket", - (u_long)sizeof(addr->sun_path)); + if (strlen(sock_path) >= sizeof(un->sun_path)) { + logmsgx("create_socket: too long path name (>= %zu) " + "for local domain socket", sizeof(un->sun_path)); goto failed; } - strcpy(addr->sun_path, sock_path); - if (bind(fd, (struct sockaddr *)addr, SUN_LEN(addr)) < 0) { + memset(un, 0, sizeof(un)); + un->sun_family = PF_LOCAL; + strcpy(un->sun_path, sock_path); + un->sun_len = SUN_LEN(un); + + if (bind(fd, (struct sockaddr *)un, un->sun_len) < 0) { logmsg("create_socket: bind(%s)", sock_path); goto failed; } @@ -473,43 +534,49 @@ failed: } /* - * Call create_socket() for server listening socket. - * Return socket descriptor or -1 if some error occurred. + * Create server socket. */ static int create_server_socket(void) { - return (create_socket(serv_sock_path, sizeof(serv_sock_path), &servaddr)); -} + int fd; -/* - * Create unbound socket. - */ -static int -create_unbound_socket(void) -{ - return (create_socket((char *)NULL, 0, (struct sockaddr_un *)NULL)); + fd = create_socket(serv_sock_path, sizeof(serv_sock_path), &servaddr); + if (fd < 0) + return (-1); + + if (sock_type == SOCK_STREAM) { + int val; + + if (listen(fd, LISTENQ) < 0) { + logmsg("create_server_socket: listen"); + goto failed; + } + val = fcntl(fd, F_GETFL, 0); + if (val < 0) { + logmsg("create_server_socket: fcntl(F_GETFL)"); + goto failed; + } + if (fcntl(fd, F_SETFL, val | O_NONBLOCK) < 0) { + logmsg("create_server_socket: fcntl(F_SETFL)"); + goto failed; + } + } + + return (fd); + +failed: + (void)close_socket(serv_sock_path, fd); + return (-1); } /* - * Close socket descriptor, if sock_path is not equal to NULL, - * then unlink the given path. + * Create client socket. */ static int -close_socket(const char *sock_path, int fd) +create_client_socket(void) { - int error = 0; - - if (close(fd) < 0) { - logmsg("close_socket: close"); - error = -1; - } - if (sock_path != NULL) - if (unlink(sock_path) < 0) { - logmsg("close_socket: unlink(%s)", sock_path); - error = -1; - } - return (error); + return (create_socket((char *)NULL, 0, (struct sockaddr_un *)NULL)); } /* @@ -524,7 +591,7 @@ connect_server(int fd) * If PF_LOCAL listening socket's queue is full, then connect() * returns ECONNREFUSED immediately, do not need timeout. */ - if (connect(fd, (struct sockaddr *)&servaddr, sizeof(servaddr)) < 0) { + if (connect(fd, (struct sockaddr *)&servaddr, servaddr.sun_len) < 0) { logmsg("connect_server: connect(%s)", serv_sock_path); return (-1); } @@ -533,34 +600,23 @@ connect_server(int fd) } /* - * sendmsg() with timeout. + * sendmsg() wrapper. */ static int -sendmsg_timeout(int fd, struct msghdr *msg, size_t n) +send_message(const int fd, const struct msghdr *msg, const size_t n) { ssize_t nsent; - dbgmsg(("sending %lu bytes", (u_long)n)); - - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sendmsg_timeout: cannot send message to %s (timeout)", serv_sock_path); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("sending %zu bytes", n)); nsent = sendmsg(fd, msg, 0); - - (void)alarm(0); - if (nsent < 0) { - logmsg("sendmsg_timeout: sendmsg"); + logmsg("send_message: sendmsg"); return (-1); } - if ((size_t)nsent != n) { - logmsgx("sendmsg_timeout: sendmsg: short send: %ld of %lu bytes", - (long)nsent, (u_long)n); + logmsgx("send_message: sendmsg: short send: " + "%zd of %zu bytes", nsent, n); return (-1); } @@ -568,63 +624,73 @@ sendmsg_timeout(int fd, struct msghdr *m } /* - * accept() with timeout. + * accept() wrapper. */ static int -accept_timeout(int listenfd) +accept_connection(const int listenfd) { - int fd; + fd_set rset; + struct timeval tv; + int fd, rv, val; dbgmsg(("accepting connection")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("accept_timeout: cannot accept connection (timeout)"); + FD_ZERO(&rset); + FD_SET(listenfd, &rset); + tv.tv_sec = TIMEOUT; + tv.tv_usec = 0; + rv = select(listenfd + 1, &rset, (fd_set *)NULL, (fd_set *)NULL, &tv); + if (rv < 0) { + logmsg("accept_connection: select"); + return (-1); + } + if (rv == 0) { + logmsgx("accept_connection: select timeout"); return (-1); } - - (void)alarm(TIMEOUT); fd = accept(listenfd, (struct sockaddr *)NULL, (socklen_t *)NULL); - - (void)alarm(0); - if (fd < 0) { - logmsg("accept_timeout: accept"); + logmsg("accept_connection: accept"); return (-1); } + val = fcntl(fd, F_GETFL, 0); + if (val < 0) { + logmsg("accept_connection: fcntl(F_GETFL)"); + goto failed; + } + if (fcntl(fd, F_SETFL, val & ~O_NONBLOCK) < 0) { + logmsg("accept_connection: fcntl(F_SETFL)"); + goto failed; + } + return (fd); + +failed: + if (close(fd) < 0) + logmsg("accept_connection: close"); + return (-1); } /* - * recvmsg() with timeout. + * recvmsg() wrapper. */ static int -recvmsg_timeout(int fd, struct msghdr *msg, size_t n) +recv_message(const int fd, struct msghdr *msg, const size_t n) { ssize_t nread; - dbgmsg(("receiving %lu bytes", (u_long)n)); - - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("recvmsg_timeout: cannot receive message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("receiving %zu bytes", n)); nread = recvmsg(fd, msg, MSG_WAITALL); - - (void)alarm(0); - if (nread < 0) { - logmsg("recvmsg_timeout: recvmsg"); + logmsg("recv_message: recvmsg"); return (-1); } - if ((size_t)nread != n) { - logmsgx("recvmsg_timeout: recvmsg: short read: %ld of %lu bytes", - (long)nread, (u_long)n); + logmsgx("recv_message: recvmsg: short read: " + "%zd of %zu bytes", nread, n); return (-1); } @@ -632,35 +698,23 @@ recvmsg_timeout(int fd, struct msghdr *m } /* - * Wait for synchronization message (1 byte) with timeout. + * Wait for synchronization message (1 byte). */ static int -sync_recv(int fd) +sync_recv(const int fd) { ssize_t nread; char buf; dbgmsg(("waiting for sync message")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sync_recv: cannot receive sync message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); - nread = read(fd, &buf, 1); - - (void)alarm(0); - if (nread < 0) { logmsg("sync_recv: read"); return (-1); } - if (nread != 1) { - logmsgx("sync_recv: read: short read: %ld of 1 byte", - (long)nread); + logmsgx("sync_recv: read: short read: %zd of 1 byte", nread); return (-1); } @@ -668,34 +722,22 @@ sync_recv(int fd) } /* - * Send synchronization message (1 byte) with timeout. + * Send synchronization message (1 byte). */ static int -sync_send(int fd) +sync_send(const int fd) { ssize_t nsent; dbgmsg(("sending sync message")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sync_send: cannot send sync message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); - nsent = write(fd, "", 1); - - (void)alarm(0); - if (nsent < 0) { logmsg("sync_send: write"); return (-1); } - if (nsent != 1) { - logmsgx("sync_send: write: short write: %ld of 1 byte", - (long)nsent); + logmsgx("sync_send: write: short write: %zd of 1 byte", nsent); return (-1); } @@ -711,36 +753,29 @@ wait_client(void) int status; pid_t pid; - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("wait_client: cannot get exit status of client PID %ld (timeout)", - (long)client_pid); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("waiting for a client")); pid = waitpid(client_pid, &status, 0); - - (void)alarm(0); - if (pid == (pid_t)-1) { logmsg("wait_client: waitpid"); return (-1); } if (WIFEXITED(status)) { - if (WEXITSTATUS(status) != 0) { - logmsgx("wait_client: exit status of client PID %ld is %d", - (long)client_pid, WEXITSTATUS(status)); + if (WEXITSTATUS(status) != EXIT_SUCCESS) { + logmsgx("wait_client: exit status of client PID %ld " + "is %d", (long)client_pid, WEXITSTATUS(status)); return (-1); } } else { if (WIFSIGNALED(status)) - logmsgx("wait_client: abnormal termination of client PID %ld, signal %d%s", - (long)client_pid, WTERMSIG(status), WCOREDUMP(status) ? " (core file generated)" : ""); + logmsgx("wait_client: abnormal termination of client " + "PID %ld, signal %d%s", (long)client_pid, + WTERMSIG(status), WCOREDUMP(status) ? + " (core file generated)" : ""); else - logmsgx("wait_client: termination of client PID %ld, unknown status", - (long)client_pid); + logmsgx("wait_client: termination of client PID %ld, " + "unknown status", (long)client_pid); return (-1); } @@ -752,24 +787,24 @@ wait_client(void) * has (my_ngids - 1) supplementary GIDs of current process. */ static int -check_groups(const gid_t *gids, int n) +check_groups(const gid_t *gids, const int n) { + int i, j, rv; char match[NGROUPS_MAX] = { 0 }; - int error, i, j; if (n != my_ngids - 1) { - logmsgx("wrong number of groups %d != %d (returned from getgroups() - 1)", - n, my_ngids - 1); - error = -1; + logmsgx("wrong number of groups %d != %d (returned from " + "getgroups() - 1)", n, my_ngids - 1); + rv = -1; } else - error = 0; + rv = 0; for (i = 0; i < n; ++i) { for (j = 1; j < my_ngids; ++j) { if (gids[i] == my_gids[j]) { if (match[j]) { logmsgx("duplicated GID %lu", (u_long)gids[i]); - error = -1; + rv = -1; } else match[j] = 1; break; @@ -777,15 +812,16 @@ check_groups(const gid_t *gids, int n) } if (j == my_ngids) { logmsgx("unexpected GID %lu", (u_long)gids[i]); - error = -1; + rv = -1; } } for (j = 1; j < my_ngids; ++j) if (match[j] == 0) { - logmsgx("did not receive supplementary GID %u", my_gids[j]); - error = -1; + logmsgx("did not receive supplementary GID %lu", + (u_long)my_gids[j]); + rv = -1; } - return (error); + return (rv); } /* @@ -793,7 +829,7 @@ check_groups(const gid_t *gids, int n) * to server and exit. */ static void -t_cmsgcred_client(u_int n) +t_cmsgcred_client(const u_int n) { union { struct cmsghdr cm; @@ -802,16 +838,19 @@ t_cmsgcred_client(u_int n) struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - int fd; u_int i; + int fd, rv; assert(n == 1 || n == 2); - if ((fd = create_unbound_socket()) < 0) + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -834,20 +873,16 @@ t_cmsgcred_client(u_int n) for (i = 0; i < n; ++i) { dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; } - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); - + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd)) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -856,30 +891,29 @@ failed: * socket for stream sockets or simply socket for datagram sockets. */ static int -t_cmsgcred_server(int fd1) +t_cmsgcred_server(const int fd1) { - char buf[IPC_MESSAGE_SIZE]; union { struct cmsghdr cm; - char control[CMSG_SPACE(sizeof(struct cmsgcred)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(sizeof(struct cmsgcred)) + + EXTRA_CMSG_SPACE]; } control_un; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - const struct cmsgcred *cmcredptr; - socklen_t controllen; - int error, error2, fd2; + const struct cmsgcred *cmcred; u_int i; + int fd2, rv; + char buf[IPC_MESSAGE_SIZE]; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); } else fd2 = fd1; - error = 0; - - controllen = sizeof(control_un.control); + rv = 0; for (i = 0; i < 2; ++i) { iov[0].iov_base = buf; @@ -890,29 +924,31 @@ t_cmsgcred_server(int fd1) msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = controllen; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - controllen = CMSG_SPACE(sizeof(struct cmsgcred)); - - if (recvmsg_timeout(fd2, &msg, sizeof(buf)) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + break; + } if (msg.msg_flags & MSG_CTRUNC) { - logmsgx("#%u control data was truncated, MSG_CTRUNC flag is on", - i); - goto next_error; + logmsgx("#%u control data was truncated, MSG_CTRUNC " + "flag is on", i); + goto next; } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("#%u msg_controllen %u < %lu (sizeof(struct cmsghdr))", - i, (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); - goto next_error; + logmsgx("#%u msg_controllen %u < %zu " + "(sizeof(struct cmsghdr))", i, + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); + goto next; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); - goto next_error; + goto next; } dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, @@ -921,166 +957,147 @@ t_cmsgcred_server(int fd1) if (cmptr->cmsg_level != SOL_SOCKET) { logmsgx("#%u cmsg_level %d != SOL_SOCKET", i, cmptr->cmsg_level); - goto next_error; + goto next; } if (cmptr->cmsg_type != SCM_CREDS) { logmsgx("#%u cmsg_type %d != SCM_CREDS", i, cmptr->cmsg_type); - goto next_error; + goto next; } if (cmptr->cmsg_len != CMSG_LEN(sizeof(struct cmsgcred))) { - logmsgx("#%u cmsg_len %u != %lu (CMSG_LEN(sizeof(struct cmsgcred))", - i, (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(sizeof(struct cmsgcred))); - goto next_error; + logmsgx("#%u cmsg_len %u != %zu " + "(CMSG_LEN(sizeof(struct cmsgcred))", i, + (u_int)cmptr->cmsg_len, + CMSG_LEN(sizeof(struct cmsgcred))); + goto next; } - cmcredptr = (const struct cmsgcred *)CMSG_DATA(cmptr); + cmcred = (struct cmsgcred *)CMSG_DATA(cmptr); - error2 = 0; - if (cmcredptr->cmcred_pid != client_pid) { + if (cmcred->cmcred_pid != client_pid) { logmsgx("#%u cmcred_pid %ld != %ld (PID of client)", - i, (long)cmcredptr->cmcred_pid, (long)client_pid); - error2 = 1; + i, (long)cmcred->cmcred_pid, (long)client_pid); + goto next; } - if (cmcredptr->cmcred_uid != my_uid) { - logmsgx("#%u cmcred_uid %lu != %lu (UID of current process)", - i, (u_long)cmcredptr->cmcred_uid, (u_long)my_uid); - error2 = 1; - } - if (cmcredptr->cmcred_euid != my_euid) { - logmsgx("#%u cmcred_euid %lu != %lu (EUID of current process)", - i, (u_long)cmcredptr->cmcred_euid, (u_long)my_euid); - error2 = 1; - } - if (cmcredptr->cmcred_gid != my_gid) { - logmsgx("#%u cmcred_gid %lu != %lu (GID of current process)", - i, (u_long)cmcredptr->cmcred_gid, (u_long)my_gid); - error2 = 1; + if (cmcred->cmcred_uid != my_uid) { + logmsgx("#%u cmcred_uid %lu != %lu (UID of current " + "process)", i, (u_long)cmcred->cmcred_uid, + (u_long)my_uid); + goto next; + } + if (cmcred->cmcred_euid != my_euid) { + logmsgx("#%u cmcred_euid %lu != %lu (EUID of current " + "process)", i, (u_long)cmcred->cmcred_euid, + (u_long)my_euid); + goto next; + } + if (cmcred->cmcred_gid != my_gid) { + logmsgx("#%u cmcred_gid %lu != %lu (GID of current " + "process)", i, (u_long)cmcred->cmcred_gid, + (u_long)my_gid); + goto next; } - if (cmcredptr->cmcred_ngroups == 0) { + if (cmcred->cmcred_ngroups == 0) { logmsgx("#%u cmcred_ngroups = 0, this is wrong", i); - error2 = 1; - } else { - if (cmcredptr->cmcred_ngroups > NGROUPS_MAX) { - logmsgx("#%u cmcred_ngroups %d > %u (NGROUPS_MAX)", - i, cmcredptr->cmcred_ngroups, NGROUPS_MAX); - error2 = 1; - } else if (cmcredptr->cmcred_ngroups < 0) { - logmsgx("#%u cmcred_ngroups %d < 0", - i, cmcredptr->cmcred_ngroups); - error2 = 1; - } else { - dbgmsg(("#%u cmcred_ngroups = %d", i, - cmcredptr->cmcred_ngroups)); - if (cmcredptr->cmcred_groups[0] != my_egid) { - logmsgx("#%u cmcred_groups[0] %lu != %lu (EGID of current process)", - i, (u_long)cmcredptr->cmcred_groups[0], (u_long)my_egid); - error2 = 1; - } - if (check_groups(cmcredptr->cmcred_groups + 1, cmcredptr->cmcred_ngroups - 1) < 0) { - logmsgx("#%u cmcred_groups has wrong GIDs", i); - error2 = 1; - } - } + goto next; } - - if (error2) - goto next_error; - - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("#%u control data has extra header", i); - goto next_error; + if (cmcred->cmcred_ngroups > NGROUPS_MAX) { + logmsgx("#%u cmcred_ngroups %d > %u (NGROUPS_MAX)", + i, cmcred->cmcred_ngroups, NGROUPS_MAX); + goto next; + } + if (cmcred->cmcred_ngroups < 0) { + logmsgx("#%u cmcred_ngroups %d < 0", i, + cmcred->cmcred_ngroups); + goto next; + } + + dbgmsg(("#%u cmcred_ngroups = %d", i, cmcred->cmcred_ngroups)); + if (cmcred->cmcred_groups[0] != my_egid) { + logmsgx("#%u cmcred_groups[0] %lu != %lu (EGID of " + "current process)", i, + (u_long)cmcred->cmcred_groups[0], (u_long)my_egid); + goto next; + } + if (check_groups(cmcred->cmcred_groups + 1, + cmcred->cmcred_ngroups - 1) < 0) { + logmsgx("#%u cmcred_groups has wrong GIDs", i); + goto next; + } + + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("#%u control data has extra header, this is " + "wrong", i); + goto next; } - continue; -next_error: - error = -1; +next: + rv = -1; } if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_cmsgcred(void) { - int error, fd; + int fd, rv; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_cmsgcred_client(2); } - if ((error = t_cmsgcred_server(fd)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_cmsgcred_server(fd); if (wait_client() < 0) - goto failed; - - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } /* * Send two messages with data to server and exit. */ static void -t_sockcred_client(int type) +t_sockcred_client(const int type) { struct msghdr msg; struct iovec iov[1]; - int fd; u_int i; + int fd, rv; assert(type == 0 || type == 1); - if ((fd = create_unbound_socket()) < 0) + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; if (type == 1) if (sync_recv(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -1094,19 +1111,15 @@ t_sockcred_client(int type) msg.msg_flags = 0; for (i = 0; i < 2; ++i) - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; - - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -1117,234 +1130,219 @@ failed: * 1, then set LOCAL_CREDS option for accepted stream socket. */ static int -t_sockcred_server(int type, int fd1, u_int n) +t_sockcred_server(const int type, const int fd1, const u_int n) { - char buf[IPC_MESSAGE_SIZE]; union { struct cmsghdr cm; - char control[CMSG_SPACE(SOCKCREDSIZE(NGROUPS_MAX)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(SOCKCREDSIZE(NGROUPS_MAX)) + + EXTRA_CMSG_SPACE]; } control_un; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; const struct sockcred *sockcred; - int error, error2, fd2, optval; u_int i; + int fd2, rv, optval; + char buf[IPC_MESSAGE_SIZE]; assert(n == 1 || n == 2); assert(type == 0 || type == 1); + rv = -2; + if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); if (type == 1) { optval = 1; - if (setsockopt(fd2, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { - logmsg("setsockopt(LOCAL_CREDS) for accepted socket"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + if (setsockopt(fd2, 0, LOCAL_CREDS, &optval, + sizeof(optval)) < 0) { + logmsg("setsockopt(LOCAL_CREDS) for accepted " + "socket"); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } if (sync_send(fd2) < 0) - goto failed; + goto done; } } else fd2 = fd1; - error = 0; + rv = 0; for (i = 0; i < n; ++i) { iov[0].iov_base = buf; - iov[0].iov_len = sizeof buf; + iov[0].iov_len = sizeof(buf); msg.msg_name = NULL; msg.msg_namelen = 0; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = sizeof control_un.control; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - if (recvmsg_timeout(fd2, &msg, sizeof buf) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + break; + } if (msg.msg_flags & MSG_CTRUNC) { - logmsgx("control data was truncated, MSG_CTRUNC flag is on"); - goto next_error; + logmsgx("control data was truncated, MSG_CTRUNC flag " + "is on"); + goto next; } + dbgmsg(("#%u msg_controllen = %u", i, + (u_int)msg.msg_controllen)); + if (i != 0 && sock_type == SOCK_STREAM) { if (msg.msg_controllen != 0) { - logmsgx("second message has control data, this is wrong for stream sockets"); - goto next_error; + logmsgx("second message has control data, " + "this is wrong for stream sockets"); + goto next; } - dbgmsg(("#%u msg_controllen = %u", i, - (u_int)msg.msg_controllen)); continue; } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("#%u msg_controllen %u < %lu (sizeof(struct cmsghdr))", - i, (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); - goto next_error; + logmsgx("#%u msg_controllen %u < %zu " + "(sizeof(struct cmsghdr))", i, + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); + goto next; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); - goto next_error; + goto next; } - dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, - (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); + dbgmsg(("#%u cmsg_len = %u", i, (u_int)cmptr->cmsg_len)); if (cmptr->cmsg_level != SOL_SOCKET) { logmsgx("#%u cmsg_level %d != SOL_SOCKET", i, cmptr->cmsg_level); - goto next_error; + goto next; } if (cmptr->cmsg_type != SCM_CREDS) { logmsgx("#%u cmsg_type %d != SCM_CREDS", i, cmptr->cmsg_type); - goto next_error; + goto next; } if (cmptr->cmsg_len < CMSG_LEN(SOCKCREDSIZE(1))) { - logmsgx("#%u cmsg_len %u != %lu (CMSG_LEN(SOCKCREDSIZE(1)))", - i, (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(SOCKCREDSIZE(1))); - goto next_error; + logmsgx("#%u cmsg_len %u != %zu " + "(CMSG_LEN(SOCKCREDSIZE(1)))", i, + (u_int)cmptr->cmsg_len, CMSG_LEN(SOCKCREDSIZE(1))); + goto next; } - sockcred = (const struct sockcred *)CMSG_DATA(cmptr); + sockcred = (struct sockcred *)CMSG_DATA(cmptr); - error2 = 0; if (sockcred->sc_uid != my_uid) { - logmsgx("#%u sc_uid %lu != %lu (UID of current process)", - i, (u_long)sockcred->sc_uid, (u_long)my_uid); - error2 = 1; + logmsgx("#%u sc_uid %lu != %lu (UID of current " + "process)", i, (u_long)sockcred->sc_uid, + (u_long)my_uid); + goto next; } if (sockcred->sc_euid != my_euid) { - logmsgx("#%u sc_euid %lu != %lu (EUID of current process)", - i, (u_long)sockcred->sc_euid, (u_long)my_euid); - error2 = 1; + logmsgx("#%u sc_euid %lu != %lu (EUID of current " + "process)", i, (u_long)sockcred->sc_euid, + (u_long)my_euid); + goto next; } if (sockcred->sc_gid != my_gid) { - logmsgx("#%u sc_gid %lu != %lu (GID of current process)", - i, (u_long)sockcred->sc_gid, (u_long)my_gid); - error2 = 1; + logmsgx("#%u sc_gid %lu != %lu (GID of current " + "process)", i, (u_long)sockcred->sc_gid, + (u_long)my_gid); + goto next; } if (sockcred->sc_egid != my_egid) { - logmsgx("#%u sc_egid %lu != %lu (EGID of current process)", - i, (u_long)sockcred->sc_gid, (u_long)my_egid); - error2 = 1; + logmsgx("#%u sc_egid %lu != %lu (EGID of current " + "process)", i, (u_long)sockcred->sc_gid, + (u_long)my_egid); + goto next; } if (sockcred->sc_ngroups > NGROUPS_MAX) { logmsgx("#%u sc_ngroups %d > %u (NGROUPS_MAX)", i, sockcred->sc_ngroups, NGROUPS_MAX); - error2 = 1; - } else if (sockcred->sc_ngroups < 0) { - logmsgx("#%u sc_ngroups %d < 0", - i, sockcred->sc_ngroups); - error2 = 1; - } else { - dbgmsg(("#%u sc_ngroups = %d", i, sockcred->sc_ngroups)); - if (check_groups(sockcred->sc_groups, sockcred->sc_ngroups) < 0) { - logmsgx("#%u sc_groups has wrong GIDs", i); - error2 = 1; - } + goto next; + } + if (sockcred->sc_ngroups < 0) { + logmsgx("#%u sc_ngroups %d < 0", i, + sockcred->sc_ngroups); + goto next; } - if (error2) - goto next_error; - - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("#%u control data has extra header, this is wrong", - i); - goto next_error; + dbgmsg(("#%u sc_ngroups = %d", i, sockcred->sc_ngroups)); + if (check_groups(sockcred->sc_groups, + sockcred->sc_ngroups) < 0) { + logmsgx("#%u sc_groups has wrong GIDs", i); + goto next; } + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("#%u control data has extra header, this is " + "wrong", i); + goto next; + } continue; -next_error: - error = -1; +next: + rv = -1; } - -done_close: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: +done: if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int -t_sockcred(int type) +t_sockcred(const int type) { - int error, fd, optval; + int fd, rv, optval; assert(type == 0 || type == 1); - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; if (type == 0) { optval = 1; - if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { + if (setsockopt(fd, 0, LOCAL_CREDS, &optval, + sizeof(optval)) < 0) { logmsg("setsockopt(LOCAL_CREDS) for %s socket", - sock_type == SOCK_STREAM ? "stream listening" : "datagram"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + sock_type_str); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } } - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_sockcred_client(type); } - if ((error = t_sockcred_server(type, fd, 2)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_sockcred_server(type, fd, 2); if (wait_client() < 0) - goto failed; - -done_close: - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } static int @@ -1368,59 +1366,39 @@ t_sockcred_dgram(void) static int t_cmsgcred_sockcred(void) { - int error, fd, optval; + int fd, rv, optval; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; optval = 1; - if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { - logmsg("setsockopt(LOCAL_CREDS) for %s socket", - sock_type == SOCK_STREAM ? "stream listening" : "datagram"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof(optval)) < 0) { + logmsg("setsockopt(LOCAL_CREDS) for %s socket", sock_type_str); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_cmsgcred_client(1); } - if ((error = t_sockcred_server(0, fd, 1)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_sockcred_server(0, fd, 1); if (wait_client() < 0) - goto failed; - -done_close: - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } /* @@ -1437,13 +1415,16 @@ t_timestamp_client(void) struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - int fd; + int fd, rv; + + rv = EXIT_FAILURE; - if ((fd = create_unbound_socket()) < 0) + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -1454,7 +1435,7 @@ t_timestamp_client(void) msg.msg_iovlen = 1; msg.msg_control = control_un.control; msg.msg_controllen = no_control_data ? - sizeof(struct cmsghdr) :sizeof control_un.control; + sizeof(struct cmsghdr) : sizeof(control_un.control); msg.msg_flags = 0; cmptr = CMSG_FIRSTHDR(&msg); @@ -1466,19 +1447,15 @@ t_timestamp_client(void) dbgmsg(("msg_controllen = %u, cmsg_len = %u", (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; - - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -1486,40 +1463,44 @@ failed: * type followed by struct timeval{} from client. */ static int -t_timestamp_server(int fd1) +t_timestamp_server(const int fd1) { union { struct cmsghdr cm; - char control[CMSG_SPACE(sizeof(struct timeval)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(sizeof(struct timeval)) + + EXTRA_CMSG_SPACE]; } control_un; - char buf[IPC_MESSAGE_SIZE]; - int error, fd2; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; const struct timeval *timeval; + int fd2, rv; + char buf[IPC_MESSAGE_SIZE]; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); } else fd2 = fd1; iov[0].iov_base = buf; - iov[0].iov_len = sizeof buf; + iov[0].iov_len = sizeof(buf); msg.msg_name = NULL; msg.msg_namelen = 0; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = sizeof control_un.control;; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - if (recvmsg_timeout(fd2, &msg, sizeof buf) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + goto done; + } - error = -1; + rv = -1; if (msg.msg_flags & MSG_CTRUNC) { logmsgx("control data was truncated, MSG_CTRUNC flag is on"); @@ -1527,12 +1508,13 @@ t_timestamp_server(int fd1) } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("msg_controllen %u < %lu (sizeof(struct cmsghdr))", - (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); + logmsgx("msg_controllen %u < %zu (sizeof(struct cmsghdr))", + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); goto done; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); goto done; } @@ -1551,80 +1533,195 @@ t_timestamp_server(int fd1) } if (cmptr->cmsg_len != CMSG_LEN(sizeof(struct timeval))) { - logmsgx("cmsg_len %u != %lu (CMSG_LEN(sizeof(struct timeval))", - (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(sizeof(struct timeval))); + logmsgx("cmsg_len %u != %zu (CMSG_LEN(sizeof(struct timeval))", + (u_int)cmptr->cmsg_len, CMSG_LEN(sizeof(struct timeval))); goto done; } - timeval = (const struct timeval *)CMSG_DATA(cmptr); + timeval = (struct timeval *)CMSG_DATA(cmptr); - dbgmsg(("timeval tv_sec %jd, tv_usec %jd", + dbgmsg(("timeval tv_sec %"PRIdMAX", tv_usec %"PRIdMAX, (intmax_t)timeval->tv_sec, (intmax_t)timeval->tv_usec)); - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("control data has extra header"); + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("control data has extra header, this is wrong"); goto done; } - error = 0; - + rv = 0; done: if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_timestamp(void) { - int error, fd; + int fd, rv; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) + if (close_socket((char *)NULL, fd) < 0) _exit(1); t_timestamp_client(); } - if ((error = t_timestamp_server(fd)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_timestamp_server(fd); if (wait_client() < 0) + rv = -2; +done: + if (close_socket(serv_sock_path, fd) < 0) + rv = -2; + return (rv); +} + +/* + * Verify that xucred structure has correct credentials. + */ +static int +check_xucred(const struct xucred *xucred, const socklen_t len) +{ + if (len != sizeof(*xucred)) { + logmsgx("option value size %zu != %zu (sizeof(struct xucred))", + (size_t)len, sizeof(*xucred)); + return (-1); + } + if (xucred->cr_version != XUCRED_VERSION) { + logmsgx("cr_version %u != %d (XUCRED_VERSION)", + xucred->cr_version, XUCRED_VERSION); + return (-1); + } + if (xucred->cr_uid != my_euid) { + logmsgx("cr_uid %lu != %lu (EUID of current process)", + (u_long)xucred->cr_uid, (u_long)my_euid); + return (-1); + } + if (xucred->cr_ngroups == 0) { + logmsgx("cr_ngroups = 0, this is wrong"); + return (-1); + } + if (xucred->cr_ngroups > NGROUPS) { + logmsgx("cr_ngroups %hu > %d (NGROUPS)", + xucred->cr_ngroups, NGROUPS); + return (-1); + } + if (xucred->cr_groups[0] != my_egid) { + logmsgx("cr_groups[0] %lu != %lu (EGID of current process)", + (u_long)xucred->cr_groups[0], (u_long)my_egid); + return (-1); + } + if (check_groups(xucred->cr_groups + 1, xucred->cr_ngroups - 1) < 0) { + logmsgx("cr_groups has wrong GIDs"); + return (-1); + } + return (0); +} + +/* + * Connect to server and set LOCAL_PEERCRED socket option for connected + * socket. Verify that credentials of the peer are correct. + */ +static void +t_peercred_client(void) +{ + struct xucred xucred; + socklen_t len; + int fd, rv; + + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); + if (connect_server(fd) < 0) + goto done; + + len = sizeof(xucred); + if (getsockopt(fd, 0, LOCAL_PEERCRED, &xucred, &len) < 0) { + logmsg("getsockopt(LOCAL_PEERCRED)"); + goto done; } - return (error); + if (check_xucred(&xucred, len) < 0) + goto done; +done: + rv = close_socket((char *)NULL, fd) < 0 ? EXIT_FAILURE : EXIT_SUCCESS; failed: + _exit(rv); +} + +/* + * Accept connection from client and set LOCAL_PEERCRED socket option for + * connected socket. Verify that credentials of the peer are correct. + */ +static int +t_peercred_server(const int fd1) +{ + struct xucred xucred; + socklen_t len; + int fd2, rv; + + fd2 = accept_connection(fd1); + if (fd2 < 0) + return (-2); + + len = sizeof(xucred); + if (getsockopt(fd2, 0, LOCAL_PEERCRED, &xucred, &len) < 0) { + logmsg("getsockopt(LOCAL_PEERCRED)"); + rv = -2; + goto done; + } + + if (check_xucred(&xucred, len) < 0) { + rv = -1; + goto done; + } + + rv = 0; +done: + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); +} + +static int +t_peercred(void) +{ + int fd, rv; + + fd = create_server_socket(); + if (fd < 0) + return (-2); + + rv = -2; + + if (fork_client() < 0) + goto done; + + if (client_pid == 0) { + if (close_socket((char *)NULL, fd) < 0) + _exit(1); + t_peercred_client(); + } + + rv = t_peercred_server(fd); + + if (wait_client() < 0) + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } diff -ruNp unix_cmsg.orig/unix_cmsg.t unix_cmsg/unix_cmsg.t --- unix_cmsg.orig/unix_cmsg.t 2006-05-29 21:40:55.000000000 +0300 +++ unix_cmsg/unix_cmsg.t 2009-10-14 02:56:49.000000000 +0300 @@ -23,14 +23,15 @@ run() done } -echo "1..15" +echo "1..16" for desc in \ "Sending, receiving cmsgcred" \ "Receiving sockcred (listening socket has LOCAL_CREDS) # TODO" \ "Receiving sockcred (accepted socket has LOCAL_CREDS) # TODO" \ "Sending cmsgcred, receiving sockcred # TODO" \ - "Sending, receiving timestamp" + "Sending, receiving timestamp" \ + "Check LOCAL_PEERCRED socket option" do n=`expr ${n} + 1` run ${n} stream "" ${n} "STREAM ${desc}" @@ -48,10 +49,10 @@ do run ${n} dgram "" ${i} "DGRAM ${desc}" done -run 10 stream -z 1 "STREAM Sending, receiving cmsgcred (no control data)" -run 11 stream -z 4 "STREAM Sending cmsgcred, receiving sockcred (no control data) # TODO" -run 12 stream -z 5 "STREAM Sending, receiving timestamp (no control data)" +run 11 stream -z 1 "STREAM Sending, receiving cmsgcred (no control data)" +run 12 stream -z 4 "STREAM Sending cmsgcred, receiving sockcred (no control data) # TODO" +run 13 stream -z 5 "STREAM Sending, receiving timestamp (no control data)" -run 13 dgram -z 1 "DGRAM Sending, receiving cmsgcred (no control data)" -run 14 dgram -z 3 "DGRAM Sending cmsgcred, receiving sockcred (no control data) # TODO" -run 15 dgram -z 4 "DGRAM Sending, receiving timestamp (no control data)" +run 14 dgram -z 1 "DGRAM Sending, receiving cmsgcred (no control data)" +run 15 dgram -z 3 "DGRAM Sending cmsgcred, receiving sockcred (no control data) # TODO" +run 16 dgram -z 4 "DGRAM Sending, receiving timestamp (no control data)" From owner-freebsd-net@FreeBSD.ORG Wed Oct 14 14:40:04 2009 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 EC20C106566B for ; Wed, 14 Oct 2009 14: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 C0D368FC1D for ; Wed, 14 Oct 2009 14:40:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9EEe4p5088581 for ; Wed, 14 Oct 2009 14:40:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9EEe4nn088580; Wed, 14 Oct 2009 14:40:04 GMT (envelope-from gnats) Date: Wed, 14 Oct 2009 14:40:04 GMT Message-Id: <200910141440.n9EEe4nn088580@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Burt Rosenberg Cc: Subject: Re: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Burt Rosenberg List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 14:40:05 -0000 The following reply was made to PR kern/130628; it has been noted by GNATS. From: Burt Rosenberg To: bug-followup@freebsd.org, Joe Marcus Clarke Cc: Subject: Re: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R Date: Wed, 14 Oct 2009 10:31:45 -0400 --000e0cd6c8b6adc3e40475e605f0 Content-Type: text/plain; charset=ISO-8859-1 The patch which helped, but did not entirely fix the lock is not in 7.2-p4, i386. Furthermore, we now have a deadlock on an NFS mount between a free bsd 7.2-p3 and a Linux 2.6.18-164.el5 SMP i686 athlon i386, in this situation there is a cisco ASA 5220 between linux and freebsd boxes, and we run tcp nfs. On Thu, Sep 3, 2009 at 2:40 PM, Burt Rosenberg wrote: > It seems that : > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/130628 > > appears in 7.2-R-p3; With this kernel, against Fedora 8 distros: > > Linux prism09.cs.miami.edu 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST > 2008 x86_64 x86_64 x86_64 GNU/Linux > > which are using NFS (tcp) to mount homedirs form the freebsd server to the > fedora client, > server will become unresponsive from the network during graphical login of > a client. > > Applying the patch given in the article > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/130628 seems at present to > fix the problem. Under a 7.2-R-p3, we can manifest the problem in a few > minutes, and under said kernel with patches as described in the article, and > as provided by diffs against the current source, we have not yet seen the > problem. > > When the problem appears, the sever cannot be pinged, an other network > connections are halted. > > On the server, for instance, top shows: > > Proc, state, pri > -------------------- > pc.lockd *tcpin -68 > nfsd - 4 > rpcbind select 44 > ntpd select 44 > nfsd select 44 > ... etc... > > > Also, > > ./lockd restart > Stopping lockd. > Waiting for PIDS: 1114, 1114, 1114, 1114,.... > > kill -9 1114 also ineffective. > > So it seems to be something spinning in lockd. > > I think this is a serious issue and would like to see it resolved. Our > setup is available if you would like to send instrumented code. I attach > diffs. > > > > --000e0cd6c8b6adc3e40475e605f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The patch which helped, but did not entirely fix the lock is not in 7.2-p4,= i386.

Furthermore, we now have a deadlock on an NFS mount between a= free bsd 7.2-p3 and a Linux 2.6.18-164.el5 SMP i686 athlon i386,

in this situation there is a=A0 cisco ASA 5220 between linux and freebsd bo= xes, and we run tcp nfs.



On Thu, = Sep 3, 2009 at 2:40 PM, Burt Rosenberg <burt@cs.miami.edu> wrote:
It seems that :=A0
http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/130= 628

appears in 7.2-R-p3; With this kernel, against Fedora 8 distros:

Linux prism0= 9.cs.miami.edu 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST 2008 x86_= 64 x86_64 x86_64 GNU/Linux

which are using NFS (tcp) to mount homedi= rs form the freebsd server to the fedora client,
server will become unresponsive from the network during graphical login of = a client.

Applying the patch given in the article http:/= /www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/130628 seems at present to = fix the problem. Under a 7.2-R-p3, we can manifest the problem in a few min= utes, and under said kernel with patches as described in the article, and a= s provided by diffs against the current source, we have not yet seen the pr= oblem.

When the problem appears, the sever cannot be pinged, an other network = connections are halted.

On the server, for instance, top shows:
=
Proc, state, pri
--------------------
pc.lockd=A0=A0 *tcpin=A0=A0 -68
nfsd=A0=A0=A0=A0=A0=A0= =A0=A0=A0 -=A0=A0=A0=A0=A0=A0 4
rpcbind=A0= =A0=A0=A0 select=A0=A0 44
ntpd=A0=A0=A0=A0=A0=A0= =A0 select=A0=A0 44
nfsd=A0=A0=A0=A0=A0=A0= =A0 select=A0=A0 44
... etc...

Also,

./lo= ckd restart
Stopping lockd.
Waiting for PIDS: 1114,= 1114, 1114, 1114,....

kill -9 1114 also ineffective.

So it seems to be something s= pinning in lockd.

I think this is a serious issue and would like to see it resolved. Our = setup is available if you would like to send instrumented code. I attach di= ffs.




--000e0cd6c8b6adc3e40475e605f0-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 14 18:59:57 2009 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 BED85106566C for ; Wed, 14 Oct 2009 18:59:57 +0000 (UTC) (envelope-from bjmccann@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 7D5EA8FC21 for ; Wed, 14 Oct 2009 18:59:57 +0000 (UTC) Received: by ywh35 with SMTP id 35so266103ywh.7 for ; Wed, 14 Oct 2009 11:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=L+FspA0kismnueQ6K9UKYf1qenMYkJ8ec4wLA2UTIkU=; b=NS3MYgCQDOMhJlpxNt5vr28A7hSFysLWn4hwXpGDZqrx3TlOL3ZhaqL656UbFHQMHq +vJsmS4E0kOVvIMK0stFhBn4p5JVLySBsU9e6S8HutL24kdkm2Cp0OSx6r/o2Ohdeo3w 0c4r+GtrMzdzjDU4S5stMK+jrMOe24Q+7l2mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KlTH3VvOvr6+araOVqnEsRNmwUHgzh0GLAgocQBzeWCwM6+ijnnE+u+txTaeao4fiM rJ3HTRJfZtPRADK/8UVp8hPz9Hh72n4z+fsCRwZpOIkrw70QqNf4If0tYgWsm94lLW+A zOcIrTXQ4Tp60IbRrQw0KYL1NcSdy2L6c+700= MIME-Version: 1.0 Received: by 10.150.44.12 with SMTP id r12mr15355671ybr.211.1255544846317; Wed, 14 Oct 2009 11:27:26 -0700 (PDT) Date: Wed, 14 Oct 2009 14:27:26 -0400 Message-ID: <2b5f066d0910141127j29fd2753wb231dceb9f1c3409@mail.gmail.com> From: Brian McCann To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: sys/dev/mii/brgphy.c patch 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, 14 Oct 2009 18:59:57 -0000 Hi all. I've had a problem using the bce driver on an IBM HS21 blade, using a Nortel L3-7 switch. This problem was documented quite a while ago according to http://www.freebsd.org/cgi/query-pr.cgi?pr=118238. I took the patch provided in there, and applied it to FreeBSD 7.1 and it worked great. I maxed out a 100Mbps LAN connection...so no bandwidth hit either. I know 8.0 is in the RC phase...is there any chance that this simple patch can be put into 8.0? If you have any questions on what I did or more details on my setup, please don't hesitate to ask! Thanks! --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" From owner-freebsd-net@FreeBSD.ORG Wed Oct 14 20:22:06 2009 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 2909610656B8 for ; Wed, 14 Oct 2009 20:22:06 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id B084A8FC1D for ; Wed, 14 Oct 2009 20:22:05 +0000 (UTC) Received: from lstewart-laptop.caia.swin.edu.au (216-239-45-4.google.com [216.239.45.4]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n9EKLq9u084048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Oct 2009 07:21:56 +1100 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4AD632D8.1070402@freebsd.org> Date: Wed, 14 Oct 2009 13:21:44 -0700 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.23 (X11/20090909) MIME-Version: 1.0 To: Bernhard Schmidt References: <20091009170839.142800@gmx.net> <200910092003.57367.bschmidt@techwires.net> In-Reply-To: <200910092003.57367.bschmidt@techwires.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-net@freebsd.org, Lutz Bichler , daniel@roe.ch Subject: Re: Intel WiFi 5100/5300 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, 14 Oct 2009 20:22:06 -0000 Bernhard Schmidt wrote: > On Friday 09 October 2009 19:08:39 Lutz Bichler wrote: >> Hi, >> >> does anybody know what happened to the attempts to support Intel WiFi >> 5100/5300 interfaces in the iwn-driver? Are any patches available which >> could be used to start working on support for these interfaces? > > I'm curious too, as I'm playing with idea to start porting the latest changes > to if_iwn from OpenBSD. Already started with adding the 5000 series firmware to > iwnfw... > Most recent effort to port Intel 5100 support that I'm aware of was done by Daniel Roethlisberger (cc'd). He has the work kicking around in a private svn repo. No idea what state it's in though. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Oct 14 23:33:51 2009 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 2636B106566B; Wed, 14 Oct 2009 23:33:51 +0000 (UTC) (envelope-from daniel@roe.ch) Received: from calvin.ustdmz.roe.ch (calvin.ustdmz.roe.ch [IPv6:2001:41e0:ff17:face::26]) by mx1.freebsd.org (Postfix) with ESMTP id 88D2D8FC1B; Wed, 14 Oct 2009 23:33:50 +0000 (UTC) Received: from roe (ssh-from [2001:41e0:ff17:babe::101]) by calvin.ustdmz.roe.ch (envelope-from ) with LOCAL id 1MyDLo-000HQL-WF ; Thu, 15 Oct 2009 01:33:49 +0200 Date: Thu, 15 Oct 2009 01:33:48 +0200 From: Daniel Roethlisberger To: freebsd-net@freebsd.org Message-ID: <20091014233348.GA66756@calvin.ustdmz.roe.ch> Mail-Followup-To: freebsd-net@freebsd.org, Lawrence Stewart , Bernhard Schmidt , Lutz Bichler , Vassilis Laganakos , Brandon Gooch References: <20091009170839.142800@gmx.net> <200910092003.57367.bschmidt@techwires.net> <4AD632D8.1070402@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD632D8.1070402@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Brandon Gooch , Lawrence Stewart , Vassilis Laganakos , Lutz Bichler , Bernhard Schmidt Subject: Re: Intel WiFi 5100/5300 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, 14 Oct 2009 23:33:51 -0000 Lawrence Stewart 2009-10-14: > Bernhard Schmidt wrote: > > On Friday 09 October 2009 19:08:39 Lutz Bichler wrote: > > > does anybody know what happened to the attempts to support > > > Intel WiFi 5100/5300 interfaces in the iwn-driver? Are any > > > patches available which could be used to start working on > > > support for these interfaces? > > > > I'm curious too, as I'm playing with idea to start porting > > the latest changes to if_iwn from OpenBSD. Already started > > with adding the 5000 series firmware to iwnfw... > > Most recent effort to port Intel 5100 support that I'm aware of > was done by Daniel Roethlisberger (cc'd). He has the work > kicking around in a private svn repo. No idea what state it's > in though. I haven't had a chance to work on this for some time. A bunch of other folks are interested and/or working on it. I've added two of the most recently active ones to the Cc: list. The code in my svn repo [1] is not up to date with all the 802.11 changes in -current. Status is still that scanning works, but associating (tx actually) fails with a firmware exception. Brandon has made some progress on why this is happening, but no real fix yet I think. [1] https://svn.roe.ch/iwn/trunk -- Daniel Roethlisberger http://daniel.roe.ch/ From owner-freebsd-net@FreeBSD.ORG Thu Oct 15 01:00:57 2009 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 B7CFB1065672; Thu, 15 Oct 2009 01:00:57 +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 8F34D8FC1C; Thu, 15 Oct 2009 01:00:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9F10vbT027660; Thu, 15 Oct 2009 01:00:57 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9F10vqk027647; Thu, 15 Oct 2009 01:00:57 GMT (envelope-from linimon) Date: Thu, 15 Oct 2009 01:00:57 GMT Message-Id: <200910150100.n9F10vqk027647@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/139565: [ipfilter] ipfilter ioctl SIOCDELST broken 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, 15 Oct 2009 01:00:57 -0000 Old Synopsis: ipfilter ioctl SIOCDELST broken New Synopsis: [ipfilter] ipfilter ioctl SIOCDELST broken Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Oct 15 01:00:16 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139565 From owner-freebsd-net@FreeBSD.ORG Thu Oct 15 01:13:44 2009 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 EF962106566B; Thu, 15 Oct 2009 01:13:44 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id D61E88FC1A; Thu, 15 Oct 2009 01:13:44 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n9F1DiO9000091; Wed, 14 Oct 2009 18:13:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 18:12:41 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP Changes Thread-Index: AcpNNJf6RjDjdETRRwma32MIH3lQ0Q== From: "Li, Qing" To: , Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: ARP Changes 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, 15 Oct 2009 01:13:45 -0000 > > I know that arp has changed a lot in FreeBSD 8. I am wondering if one > change was by design? In older versions of FreeBSD, if you ping a = host > that is on a local network but is down, after a few seconds ping = displays: > ping: sendto: Host is down > ping: sendto: Host is down > This turned out to be a regression bug. A wrong variable is used and the incomplete entry was timing out too fast. So the ARP probe = continues indefinitely ... =20 > > Using arp to display the arp table shows: > > host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] I wasn't returning incomplete entries, but now I am ... I have a patch for both issues, but I need to clean up the code because that wrong variable is used elsewhere in the same module. I should be able to commit a permanent fix by tomorrow. -- Qing From owner-freebsd-net@FreeBSD.ORG Thu Oct 15 03:49:51 2009 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 14828106566C; Thu, 15 Oct 2009 03:49:51 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 744E68FC0C; Thu, 15 Oct 2009 03:49:50 +0000 (UTC) Received: by ewy18 with SMTP id 18so463789ewy.43 for ; Wed, 14 Oct 2009 20:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=krLOro4aJGRo2+WQbCGB8rluPQE1/sW45GpQy8mx4Sk=; b=SLcic5HgOAhtw2F23LDw59lcm6cHT6KUzd8kQlpsaQSpXUoaBuMplGvtE34yV1E5hw 9MyCRQpRIqKApd9aS0pQxWBWFEWpZiHzJZZ95mzntnSNIuwuhn7D9UbY35Ih1KeoKG0f 4Aj+HnvwES2+q1ZMrIWYUZyRY+IyOxX+4te/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Xw4dsIc2aCCb998ULgmrFK3sFP0QN5bNZN/0bUBiY6DDWAwRYG2/gHD3PFm+CGRuIp HuiwxG8Eypt02q54zo1CNdwJ8JklNEgMS8zKDYcQ9ipmMPXDzWv6htcQdtqIqEgQeaVi EDHxXU5JufifqBho2iGnvLdPPoVMrqC1AYoSg= MIME-Version: 1.0 Received: by 10.211.128.6 with SMTP id f6mr11328639ebn.15.1255576797503; Wed, 14 Oct 2009 20:19:57 -0700 (PDT) In-Reply-To: <20091014233348.GA66756@calvin.ustdmz.roe.ch> References: <20091009170839.142800@gmx.net> <200910092003.57367.bschmidt@techwires.net> <4AD632D8.1070402@freebsd.org> <20091014233348.GA66756@calvin.ustdmz.roe.ch> Date: Thu, 15 Oct 2009 03:19:57 +0000 Message-ID: <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> From: Brandon Gooch To: freebsd-net@freebsd.org, Lawrence Stewart , Bernhard Schmidt , Lutz Bichler , Vassilis Laganakos , Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Intel WiFi 5100/5300 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, 15 Oct 2009 03:49:51 -0000 On Wed, Oct 14, 2009 at 11:33 PM, Daniel Roethlisberger wro= te: > Lawrence Stewart 2009-10-14: >> Bernhard Schmidt wrote: >> > On Friday 09 October 2009 19:08:39 Lutz Bichler wrote: >> > > does anybody know what happened to the attempts to support >> > > Intel WiFi 5100/5300 interfaces in the iwn-driver? Are any >> > > patches available which could be used to start working on >> > > support for these interfaces? >> > >> > I'm curious too, as I'm playing with idea to start porting >> > the latest changes to if_iwn from OpenBSD. Already started >> > with adding the 5000 series firmware to iwnfw... >> >> Most recent effort to port Intel 5100 support that I'm aware of >> was done by Daniel Roethlisberger (cc'd). He has the work >> kicking around in a private svn repo. No idea what state it's >> in though. > > I haven't had a chance to work on this for some time. =A0A bunch of > other folks are interested and/or working on it. =A0I've added two > of the most recently active ones to the Cc: list. > > The code in my svn repo [1] is not up to date with all the 802.11 > changes in -current. =A0Status is still that scanning works, but > associating (tx actually) fails with a firmware exception. > Brandon has made some progress on why this is happening, but no > real fix yet I think. > > [1] https://svn.roe.ch/iwn/trunk > > -- > Daniel Roethlisberger > http://daniel.roe.ch/ > Hi everyone. Yes, it's true that I've found SOMETHING, although I'm still investigating why that something is happening in the first place. I'm having to work on it in between "real life", so that means I need the working, current driver in tree most of the time. I have a 5300 in another computer I'm planning on hacking around on in the near future so I can have both a 4965 and 5000 series test environment. Right now, I'm reading through these: man -k ieee80211 ...and friends. I don't know much about the technology, so I decided to start over from the beginning, making this whole "iwn driver update" more of a "learn FreeBSD's IEEE802.11 layer" thing (a long-term project). So, yeah, I'll share more as I get it :) -Brandon From owner-freebsd-net@FreeBSD.ORG Thu Oct 15 06:16:06 2009 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 324FF106566B for ; Thu, 15 Oct 2009 06:16:06 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mx01.netsrc.de (mx01.netsrc.de [89.107.71.100]) by mx1.freebsd.org (Postfix) with ESMTP id D1AAD8FC21 for ; Thu, 15 Oct 2009 06:16:05 +0000 (UTC) Received: from jessie.localnet (unknown [212.185.121.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.netsrc.de (Postfix) with ESMTP id 1D82F192FD9; Thu, 15 Oct 2009 08:16:04 +0200 (CEST) From: Bernhard Schmidt To: Brandon Gooch Date: Thu, 15 Oct 2009 08:15:57 +0200 User-Agent: KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.1; i686; ; ) References: <20091009170839.142800@gmx.net> <20091014233348.GA66756@calvin.ustdmz.roe.ch> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> In-Reply-To: <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200910150815.58174.bschmidt@techwires.net> Cc: freebsd-net@freebsd.org, Vassilis Laganakos , Lutz Bichler , Lawrence Stewart Subject: Re: Intel WiFi 5100/5300 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, 15 Oct 2009 06:16:06 -0000 Hi, Just to let you know, I started working on that myself and was finally able to get a connection and make traffic yesterday :) I'm still having issues scanning 5Ghz channels though.. anyways, I'll post updates on sunday. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Oct 15 06:25:58 2009 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 987951065670; Thu, 15 Oct 2009 06:25:58 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id BA1CA8FC21; Thu, 15 Oct 2009 06:25:57 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n9F6Puki027688; Wed, 14 Oct 2009 23:25:57 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 23:17:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP Changes Thread-Index: AcpNNJf6RjDjdETRRwma32MIH3lQ0QAKpMwR References: From: "Li, Qing" To: "Li, Qing" , , , Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: RE: ARP Changes 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, 15 Oct 2009 06:25:58 -0000 I have committed the fix into the -current branch, svn r198111. Please give it a try and I plan to MFC the patch into 8.0 release branch in 3 days. Thank you for the report. -- Qing -----Original Message----- From: owner-freebsd-current@freebsd.org on behalf of Li, Qing Sent: Wed 10/14/2009 6:12 PM To: lab@gta.com; qingli@freebsd.org Cc: freebsd-net@freebsd.org; freebsd-current@freebsd.org Subject: Re: ARP Changes =20 > > I know that arp has changed a lot in FreeBSD 8. I am wondering if one > change was by design? In older versions of FreeBSD, if you ping a = host > that is on a local network but is down, after a few seconds ping = displays: > ping: sendto: Host is down > ping: sendto: Host is down > This turned out to be a regression bug. A wrong variable is used and the incomplete entry was timing out too fast. So the ARP probe = continues indefinitely ... =20 > > Using arp to display the arp table shows: > > host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] I wasn't returning incomplete entries, but now I am ... I have a patch for both issues, but I need to clean up the code because that wrong variable is used elsewhere in the same module. I should be able to commit a permanent fix by tomorrow. -- Qing _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Oct 15 08:13:32 2009 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 CA6D41065672 for ; Thu, 15 Oct 2009 08:13:32 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx39.mail.ru (mx39.mail.ru [94.100.176.53]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6438FC0C for ; Thu, 15 Oct 2009 08:13:32 +0000 (UTC) Received: from [217.25.27.27] (port=4198 helo=[217.25.27.27]) by mx39.mail.ru with asmtp id 1MyLSe-000I7I-00 for freebsd-net@freebsd.org; Thu, 15 Oct 2009 12:13:24 +0400 Message-ID: <4AD6D99E.10805@mail.ru> Date: Thu, 15 Oct 2009 13:13:18 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Subject: Re: dummynet dropping too many packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rihad List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 08:13:32 -0000 For now we've mostly disabled dummynet and the drops have stopped, thanks to some extra unused bandwidth we have. But this isn't a real solution, of course, so this weekend I'm going to try the suggestion made by Robert Watson: > In the driver init code in if_bce, the following code appears: > > ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > IFQ_SET_READY(&ifp->if_snd); > > Which evaluates to a architecture-specific value due to varying pagesize. You might just try forcing it to 1024. But I've looked in /sys/dev/bce/if_bcereg.h of our FreeBSD 7.1 source code and found this: #define TX_PAGES 2 #define TOTAL_TX_BD_PER_PAGE (BCM_PAGE_SIZE / sizeof(struct tx_bd)) #define USABLE_TX_BD_PER_PAGE (TOTAL_TX_BD_PER_PAGE - 1) #define TOTAL_TX_BD (TOTAL_TX_BD_PER_PAGE * TX_PAGES) #define USABLE_TX_BD (USABLE_TX_BD_PER_PAGE * TX_PAGES) #define MAX_TX_BD (TOTAL_TX_BD - 1) meaning that USABLE_TX_BD is expected to be smaller than MAX_TX_BD. What if MAX_TX_BD is itself way smaller than 1024, which I'll eventually set ifq_drv_maxlen to? Can a driver guru please comment on this? In a few days I'm going to try it anyway, and if the system locks up I'll just revert back to the original code, and order a darn expensive Intel 10 Gige card, but it won't hurt to ask beforehand. TIA From owner-freebsd-net@FreeBSD.ORG Thu Oct 15 12:36:49 2009 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 86D221065670 for ; Thu, 15 Oct 2009 12:36:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 627EE8FC18 for ; Thu, 15 Oct 2009 12:36:49 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id EAF6846B2D; Thu, 15 Oct 2009 08:36:48 -0400 (EDT) Date: Thu, 15 Oct 2009 13:36:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: rihad In-Reply-To: <4AD6D99E.10805@mail.ru> Message-ID: References: <4AD6D99E.10805@mail.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets 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, 15 Oct 2009 12:36:49 -0000 On Thu, 15 Oct 2009, rihad wrote: > meaning that USABLE_TX_BD is expected to be smaller than MAX_TX_BD. What if > MAX_TX_BD is itself way smaller than 1024, which I'll eventually set > ifq_drv_maxlen to? Can a driver guru please comment on this? In a few days > I'm going to try it anyway, and if the system locks up I'll just revert back > to the original code, and order a darn expensive Intel 10 Gige card, but it > won't hurt to ask beforehand. Depending on your tolerance for experimentalism, it might be useful to use DTrace to confirm our interpretation of events. The way I'd do this is to add an instrumentation point (using SDT) to the points where the statistics of interest are getting bumped, and then profile using DTrace for a bit with the following script: the:event:name:here { @data[stack()] = count(); } Let it run for 30-60 seconds, and you should get back a report on the frequency of each possible code path to generate the statistic. We believe that the drops are a result of bursts of packets from dummynet, in which case the dominant trace should be to dummynet timers. It would be interesting to see if that's right. If I get a chance, I'll spend a few minutes today looking at a more general patch to make it easy to use DTrace with network stack error points. Robert From owner-freebsd-net@FreeBSD.ORG Thu Oct 15 16:15:39 2009 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 1FE141065695; Thu, 15 Oct 2009 16:15:39 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx34.mail.ru (mx34.mail.ru [94.100.176.48]) by mx1.freebsd.org (Postfix) with ESMTP id D090E8FC14; Thu, 15 Oct 2009 16:15:38 +0000 (UTC) Received: from [217.25.27.27] (port=8869 helo=[217.25.27.27]) by mx34.mail.ru with asmtp id 1MySzJ-000D3b-00; Thu, 15 Oct 2009 20:15:37 +0400 Message-ID: <4AD74AA8.1030203@mail.ru> Date: Thu, 15 Oct 2009 21:15:36 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Robert Watson References: <4AD6D99E.10805@mail.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets 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, 15 Oct 2009 16:15:39 -0000 Robert Watson wrote: > > On Thu, 15 Oct 2009, rihad wrote: > >> meaning that USABLE_TX_BD is expected to be smaller than MAX_TX_BD. >> What if MAX_TX_BD is itself way smaller than 1024, which I'll >> eventually set ifq_drv_maxlen to? Can a driver guru please comment on >> this? In a few days I'm going to try it anyway, and if the system >> locks up I'll just revert back to the original code, and order a darn >> expensive Intel 10 Gige card, but it won't hurt to ask beforehand. > > Depending on your tolerance for experimentalism, it might be useful to > use DTrace to confirm our interpretation of events. The way I'd do this > is to add an instrumentation point (using SDT) to the points where the > statistics of interest are getting bumped, and then profile using DTrace > for a bit with the following script: > > the:event:name:here > { > @data[stack()] = count(); > } > > Let it run for 30-60 seconds, and you should get back a report on the > frequency of each possible code path to generate the statistic. We > believe that the drops are a result of bursts of packets from dummynet, > in which case the dominant trace should be to dummynet timers. It would > be interesting to see if that's right. > Thanks, but as I haven't ever played with DTrace before, but for the sake of FreeBSD and for our own sake, could you or someone else provide me with a step-by-step tutorial on how to do exactly that? I hear GENERIC kernel lacks DTrace support, so I must rebuild it with KDTRACE_HOOKS enabled? Does such support hurt normal performance while dtrace is not being used? I'm a bit afraid of experimenting on a production box belonging to a business I do not own. Meanwhile today I've emailed David Christensen mentioned in the bce source code, asking him if it's ok to change that value. > If I get a chance, I'll spend a few minutes today looking at a more > general patch to make it easy to use DTrace with network stack error > points. > > Robert > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 16 00:52:27 2009 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 C5AE4106566B; Fri, 16 Oct 2009 00:52:27 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2F77B8FC13; Fri, 16 Oct 2009 00:52:26 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so347392eyd.9 for ; Thu, 15 Oct 2009 17:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yhCWWecvtI+Y+Fe7xpcRw5TmBhUeWD+SdJ9q3CGWOc0=; b=F0JMMKyJQCuf/ax0tx1qRW86dq5lIQbFeLjPIzSPpdKye+6IF5rHgq3TToc/VNnw6F hyegrJ++/C+SUzQF/1Ffe2bcvf3ZCvRtaOqALW0KX/81gLaIOkXwgs0mZ+lO726nyXlr pxBucdEhBrWgjWZEW6pj11vP5Y+VIxkDZ2F4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lu6Py7xJ43+aT3a5wjL0/cQD2iZk6HcmqRmGZssoFpdzcZ/SzheKF6NBuxQ32AWiK6 wWy4tJreNdbfzDVsZUWzyHZu61QplUOsZV91tbyppuXcY54zXjQb/niJAMsgYyJPpnpH wvCZ6Ge52nCn+9Ns6xug+G6UDh1Cytpfy/OwI= MIME-Version: 1.0 Received: by 10.211.160.1 with SMTP id m1mr85998ebo.50.1255654346146; Thu, 15 Oct 2009 17:52:26 -0700 (PDT) In-Reply-To: <200910150815.58174.bschmidt@techwires.net> References: <20091009170839.142800@gmx.net> <20091014233348.GA66756@calvin.ustdmz.roe.ch> <179b97fb0910142019u455995a4s2cdcf8ba744d98bf@mail.gmail.com> <200910150815.58174.bschmidt@techwires.net> Date: Fri, 16 Oct 2009 00:52:26 +0000 Message-ID: <179b97fb0910151752o28cc87d4g5d9450b556b71307@mail.gmail.com> From: Brandon Gooch To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Vassilis Laganakos , Lutz Bichler , Lawrence Stewart Subject: Re: Intel WiFi 5100/5300 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, 16 Oct 2009 00:52:27 -0000 On Thu, Oct 15, 2009 at 6:15 AM, Bernhard Schmidt wrote: > Hi, > > Just to let you know, I started working on that myself and was finally ab= le to > get a connection and make traffic yesterday :) I'm still having issues sc= anning > 5Ghz channels though.. anyways, I'll post updates on =A0sunday. > > -- > Bernhard > That's great! BTW, which chip are you working with? Are you planning on pushing back your updates to Daniel's SVN repo? -Brandon From owner-freebsd-net@FreeBSD.ORG Fri Oct 16 06:30:44 2009 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 CC1BF106566B; Fri, 16 Oct 2009 06:30:44 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mx01.netsrc.de (mx01.netsrc.de [89.107.71.100]) by mx1.freebsd.org (Postfix) with ESMTP id 8A33C8FC12; Fri, 16 Oct 2009 06:30:44 +0000 (UTC) Received: from jessie.localnet (unknown [212.185.121.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.netsrc.de (Postfix) with ESMTP id A971C192FD9; Fri, 16 Oct 2009 08:30:42 +0200 (CEST) From: Bernhard Schmidt To: freebsd-net@freebsd.org Date: Fri, 16 Oct 2009 08:30:37 +0200 User-Agent: KMail/1.12.1 (Linux/2.6.30-2-686; KDE/4.3.1; i686; ; ) References: <20091009170839.142800@gmx.net> <200910150815.58174.bschmidt@techwires.net> <179b97fb0910151752o28cc87d4g5d9450b556b71307@mail.gmail.com> In-Reply-To: <179b97fb0910151752o28cc87d4g5d9450b556b71307@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200910160830.37821.bschmidt@techwires.net> Cc: Brandon Gooch , Lawrence Stewart , Lutz Bichler , Vassilis Laganakos Subject: Re: Intel WiFi 5100/5300 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, 16 Oct 2009 06:30:44 -0000 On Friday 16 October 2009 02:52:26 Brandon Gooch wrote: > On Thu, Oct 15, 2009 at 6:15 AM, Bernhard Schmidt > > wrote: > > Hi, > > > > Just to let you know, I started working on that myself and was finally > > able to get a connection and make traffic yesterday :) I'm still having > > issues scanning 5Ghz channels though.. anyways, I'll post updates on > > sunday. > > > > -- > > Bernhard > > That's great! > > BTW, which chip are you working with? Are you planning on pushing back > your updates to Daniel's SVN repo? I'm working with a 5100 currently, I do also have a 5300 and 4965 to test. As I did start from scratch (didn't know about the repo at that point) the diff against that it is probably quite large, have to check that though. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Fri Oct 16 21:07:26 2009 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 80FA6106566B for ; Fri, 16 Oct 2009 21:07:26 +0000 (UTC) (envelope-from mgaron@pleora.com) Received: from mail-09.primus.ca (mail15.primus.ca [216.254.141.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4658FC16 for ; Fri, 16 Oct 2009 21:07:26 +0000 (UTC) Received: from [76.70.36.70] (helo=argon) by mail-09.primus.ca with esmtpa (Exim 4.69) (envelope-from ) id 1MytZa-0008Da-02 for freebsd-net@freebsd.org; Fri, 16 Oct 2009 16:38:50 -0400 From: "Martin Garon" To: Date: Fri, 16 Oct 2009 16:38:52 -0400 Organization: Pleora Technologies Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpOoKvtm2oxPjcbRZ66MlBiTedK3Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Authenticated: pleora036 - (argon) [76.70.36.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Native support for AutoIP (aka LLA, RFC 3927). 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, 16 Oct 2009 21:07:26 -0000 Hi, I need to implement AutoIP in my embedded FW that uses a snapshot of FreeBSD 4.4 network stack. I could not find any support for it in the latest development cvs tree. Any chance it is somewhere that I missed? If there is no support, anyone could suggest a good approach to this? I am thinking porting libpcap in order to access the data link layer to intercept/inject some ARP packets. All comments welcomed, Regards, --Martin mgaron AT pleora DOT com From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 05:22:31 2009 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 D85C81065679 for ; Sat, 17 Oct 2009 05:22:31 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx74.mail.ru (mx74.mail.ru [94.100.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id 973248FC13 for ; Sat, 17 Oct 2009 05:22:31 +0000 (UTC) Received: from [217.25.27.27] (port=60158 helo=[217.25.27.27]) by mx74.mail.ru with asmtp id 1Mz1kK-000CuI-00; Sat, 17 Oct 2009 09:22:28 +0400 Message-ID: <4AD95493.40200@mail.ru> Date: Sat, 17 Oct 2009 10:22:27 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: rihad References: <4AD6D99E.10805@mail.ru> In-Reply-To: <4AD6D99E.10805@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets 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, 17 Oct 2009 05:22:31 -0000 rihad wrote: > For now we've mostly disabled dummynet and the drops have stopped, > thanks to some extra unused bandwidth we have. But this isn't a real > solution, of course, so this weekend I'm going to try the suggestion > made by Robert Watson: > > > In the driver init code in if_bce, the following code appears: > > > > ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; > > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > > IFQ_SET_READY(&ifp->if_snd); > > > > Which evaluates to a architecture-specific value due to varying > pagesize. You might just try forcing it to 1024. > In a few days I'm going to try it anyway, and if the system locks up > I'll just revert back to the original code > > TIA > Just rebooted with the "ifp->if_snd.ifq_drv_maxlen = 1024;" kernel, all ok so far. There's currenlty only 1000 or so entries in the ipfw table and around 350-400 net mbps load, so I'll wait a few hours for the numbers to grow to >2000 and 460-480 respectively and see if the drops still occur. P.S.: BTW, there's a small admin-type inconsistency in FreeBSD 7.1: /etc/rc.firewall gets executed before values set by /etc/sysctl.conf are in effect, so "queue 2000" isn't allowed in ipfw pipe rules (as net.inet.ip.dummynet.pipe_slot_limit is only 100 by default), so the rules are silently failing without any trace in the log files - I only saw the errors at the console. From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 05:28:09 2009 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 6610F1065693 for ; Sat, 17 Oct 2009 05:28:09 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx34.mail.ru (mx34.mail.ru [94.100.176.48]) by mx1.freebsd.org (Postfix) with ESMTP id 248B28FC23 for ; Sat, 17 Oct 2009 05:28:09 +0000 (UTC) Received: from [217.25.27.27] (port=45252 helo=[217.25.27.27]) by mx34.mail.ru with asmtp id 1Mz1pn-00025N-00 for freebsd-net@freebsd.org; Sat, 17 Oct 2009 09:28:07 +0400 Message-ID: <4AD955E7.2000501@mail.ru> Date: Sat, 17 Oct 2009 10:28:07 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> In-Reply-To: <4AD95493.40200@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Subject: Re: dummynet dropping too many packets 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, 17 Oct 2009 05:28:09 -0000 rihad wrote: > so the rules are silently failing without any trace in the log files > - I only saw the errors at the console. > It turns out to be quite easy to fix the logging: from /etc/syslog.conf: # uncomment this to log all writes to /dev/console to /var/log/console.log #console.info /var/log/console.log but the sysctl->ipfw rc inconsistency there still is. From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 06:28:55 2009 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 169101065670; Sat, 17 Oct 2009 06:28:55 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx34.mail.ru (mx34.mail.ru [94.100.176.48]) by mx1.freebsd.org (Postfix) with ESMTP id C64108FC0A; Sat, 17 Oct 2009 06:28:53 +0000 (UTC) Received: from [217.25.27.27] (port=26012 helo=[217.25.27.27]) by mx34.mail.ru with asmtp id 1Mz2mZ-0009Jx-00; Sat, 17 Oct 2009 10:28:51 +0400 Message-ID: <4AD96422.1040008@mail.ru> Date: Sat, 17 Oct 2009 11:28:50 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: rihad References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> In-Reply-To: <4AD95493.40200@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: dummynet dropping too many packets 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, 17 Oct 2009 06:28:55 -0000 rihad wrote: > rihad wrote: >> For now we've mostly disabled dummynet and the drops have stopped, >> thanks to some extra unused bandwidth we have. But this isn't a real >> solution, of course, so this weekend I'm going to try the suggestion >> made by Robert Watson: >> >> > In the driver init code in if_bce, the following code appears: >> > >> > ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD; >> > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); >> > IFQ_SET_READY(&ifp->if_snd); >> > >> > Which evaluates to a architecture-specific value due to varying >> pagesize. You might just try forcing it to 1024. > >> In a few days I'm going to try it anyway, and if the system locks up >> I'll just revert back to the original code > >> TIA >> > > Just rebooted with the "ifp->if_snd.ifq_drv_maxlen = 1024;" kernel, all > ok so far. There's currenlty only 1000 or so entries in the ipfw table > and around 350-400 net mbps load, so I'll wait a few hours for the > numbers to grow to >2000 and 460-480 respectively and see if the drops > still occur. > The change definitely helped! There are now more than 3200 users online, 460-500 mbps net traffic load, and normally 10-60 (up to 150 once or twice) consistent drops per second as opposed to several hundred up to 1000-1500 packets dropped per second before the rebuild. What's interesting is that the drops now began only after the ipfw table had around 3000 entries, not 2000 like before, so the change definitely helped. Just how high can maxlen be? Should I try 2048? 4096? From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 08:14:46 2009 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 3A1D41065670 for ; Sat, 17 Oct 2009 08:14:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outs.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 230F78FC0C for ; Sat, 17 Oct 2009 08:14:45 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 43FFDCBC50; Sat, 17 Oct 2009 01:14:45 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (unknown [67.100.89.137]) by idiom.com (Postfix) with ESMTP id CDD892D601C; Sat, 17 Oct 2009 01:14:44 -0700 (PDT) Message-ID: <4AD97CF7.6020602@elischer.org> Date: Sat, 17 Oct 2009 01:14:47 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: rihad References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> <4AD96422.1040008@mail.ru> In-Reply-To: <4AD96422.1040008@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: dummynet dropping too many packets 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, 17 Oct 2009 08:14:46 -0000 rihad wrote: >> > The change definitely helped! There are now more than 3200 users online, > 460-500 mbps net traffic load, and normally 10-60 (up to 150 once or > twice) consistent drops per second as opposed to several hundred up to > 1000-1500 packets dropped per second before the rebuild. What's > interesting is that the drops now began only after the ipfw table had > around 3000 entries, not 2000 like before, so the change definitely > helped. Just how high can maxlen be? Should I try 2048? 4096? is Hz still 4000? From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 09:21:53 2009 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 4C855106566B for ; Sat, 17 Oct 2009 09:21:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 28CA08FC14 for ; Sat, 17 Oct 2009 09:21:53 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 9F2B346B17; Sat, 17 Oct 2009 05:21:52 -0400 (EDT) Date: Sat, 17 Oct 2009 10:21:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: rihad In-Reply-To: <4AD95493.40200@mail.ru> Message-ID: References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets 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, 17 Oct 2009 09:21:53 -0000 On Sat, 17 Oct 2009, rihad wrote: > P.S.: BTW, there's a small admin-type inconsistency in FreeBSD 7.1: > /etc/rc.firewall gets executed before values set by /etc/sysctl.conf are in > effect, so "queue 2000" isn't allowed in ipfw pipe rules (as > net.inet.ip.dummynet.pipe_slot_limit is only 100 by default), so the rules > are silently failing without any trace in the log files - I only saw the > errors at the console. This is awkward to fix for sysctls, because the firewall module may not be loaded until the firewall stage of the boot process, so the sysctl wouldn't take effect (and perhaps this is what you're seeing, in fact?). Some sysctls have associated loader tunables, which you can set in /boot/loader.conf (and affect configuration when the module is loaded), but it looks like that isn't true for net.inet.ip.dummynet.pipe_slot_limit. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 09:24:10 2009 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 03ABF106566B for ; Sat, 17 Oct 2009 09:24:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D31998FC1D for ; Sat, 17 Oct 2009 09:24:09 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 69C5F46B17; Sat, 17 Oct 2009 05:24:09 -0400 (EDT) Date: Sat, 17 Oct 2009 10:24:09 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: rihad In-Reply-To: <4AD96422.1040008@mail.ru> Message-ID: References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> <4AD96422.1040008@mail.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets 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, 17 Oct 2009 09:24:10 -0000 On Sat, 17 Oct 2009, rihad wrote: >> Just rebooted with the "ifp->if_snd.ifq_drv_maxlen = 1024;" kernel, all ok >> so far. There's currenlty only 1000 or so entries in the ipfw table and >> around 350-400 net mbps load, so I'll wait a few hours for the numbers to >> grow to >2000 and 460-480 respectively and see if the drops still occur. > > The change definitely helped! There are now more than 3200 users online, > 460-500 mbps net traffic load, and normally 10-60 (up to 150 once or twice) > consistent drops per second as opposed to several hundred up to 1000-1500 > packets dropped per second before the rebuild. What's interesting is that > the drops now began only after the ipfw table had around 3000 entries, not > 2000 like before, so the change definitely helped. Just how high can maxlen > be? Should I try 2048? 4096? Sure, those should both be safe to use in your configuration, although as the numbers get higher, potential kernel memory use increases, as does the risk of starvation for clusters. Keep an eye on "netstat -m" errors to see if you are reaching configured resouce limits (which you've probably increased already). Robert From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 10:00:18 2009 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 5FB2E1065695 for ; Sat, 17 Oct 2009 10:00:18 +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 4F66E8FC0A for ; Sat, 17 Oct 2009 10:00:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9HA0HjB044288 for ; Sat, 17 Oct 2009 10:00:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9HA0HFB044281; Sat, 17 Oct 2009 10:00:17 GMT (envelope-from gnats) Date: Sat, 17 Oct 2009 10:00:17 GMT Message-Id: <200910171000.n9HA0HFB044281@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "O.Herold" Cc: Subject: Re: kern/137776: [rum] panic in rum(4) driver on 8.0-BETA2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "O.Herold" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 10:00:18 -0000 The following reply was made to PR kern/137776; it has been noted by GNATS. From: "O.Herold" To: bug-followup@freebsd.org, flz@freebsd.org Cc: Subject: Re: kern/137776: [rum] panic in rum(4) driver on 8.0-BETA2 Date: Sat, 17 Oct 2009 11:38:35 +0200 Hi, there is a fix for this kind of bug. I tried it myself (FreeBSD 8.0 RC1) and it works like a charm. I had a stable connection without any panic (the first one since using if_rum driver in FreeBSD; see the PRs) for several hours while downloading and installing different packages on a new system. http://lists.freebsd.org/pipermail/freebsd-current/2009-October/012659.html Would be nice to see this fix in stable, I think it's too late for the release. Cheers, Oliver Herold -- F!XMBR:http://www.fixmbr.de From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 13:49:12 2009 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 18B9F1065692; Sat, 17 Oct 2009 13:49:12 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx39.mail.ru (mx39.mail.ru [94.100.176.53]) by mx1.freebsd.org (Postfix) with ESMTP id C94348FC25; Sat, 17 Oct 2009 13:49:11 +0000 (UTC) Received: from [217.25.27.27] (port=12009 helo=[217.25.27.27]) by mx39.mail.ru with asmtp id 1Mz9ef-00083A-00; Sat, 17 Oct 2009 17:49:10 +0400 Message-ID: <4AD9CB54.2020608@mail.ru> Date: Sat, 17 Oct 2009 18:49:08 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Julian Elischer References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> <4AD96422.1040008@mail.ru> <4AD97CF7.6020602@elischer.org> In-Reply-To: <4AD97CF7.6020602@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: dummynet dropping too many packets 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, 17 Oct 2009 13:49:12 -0000 Julian Elischer wrote: > rihad wrote: > >>> >> The change definitely helped! There are now more than 3200 users >> online, 460-500 mbps net traffic load, and normally 10-60 (up to 150 >> once or twice) consistent drops per second as opposed to several >> hundred up to 1000-1500 packets dropped per second before the rebuild. >> What's interesting is that the drops now began only after the ipfw >> table had around 3000 entries, not 2000 like before, so the change >> definitely helped. Just how high can maxlen be? Should I try 2048? 4096? > > is Hz still 4000? > No, I've set it to 2000 as per recommendations for HZ in NOTES. Should I try 4000? 6000? 8000? Or maybe just increase the bce queue length and rebuild? :) From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 14:02:16 2009 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 7B602106566C for ; Sat, 17 Oct 2009 14:02:16 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx38.mail.ru (mx38.mail.ru [94.100.176.52]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4A18FC16 for ; Sat, 17 Oct 2009 14:02:16 +0000 (UTC) Received: from [217.25.27.27] (port=20701 helo=[217.25.27.27]) by mx38.mail.ru with asmtp id 1Mz9rK-000PEa-00 for freebsd-net@freebsd.org; Sat, 17 Oct 2009 18:02:14 +0400 Message-ID: <4AD9CE66.3010800@mail.ru> Date: Sat, 17 Oct 2009 19:02:14 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> In-Reply-To: <4AD95493.40200@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Subject: Re: dummynet dropping too many packets 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, 17 Oct 2009 14:02:16 -0000 rihad wrote: > Just rebooted with the "ifp->if_snd.ifq_drv_maxlen = 1024;" kernel, all > ok so far. There's currenlty only 1000 or so entries in the ipfw table > and around 350-400 net mbps load, so I'll wait a few hours for the > numbers to grow to >2000 and 460-480 respectively and see if the drops > still occur. > I'm not sure of anything now... It's 7 p.m. here, and during this busy time of day in terms of network use there are 350-500 up to 600 drops per second at around 530-550 mbps net load. This is roughly equivalent to 2-7 mbps dropped on output. It might be better than before. Next thing I'll try is bce queue maxlen 1024 -> 2048, and HZ 2000 again "back" to 4000. From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 15:01:11 2009 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 69EBE1065695; Sat, 17 Oct 2009 15:01:11 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx74.mail.ru (mx74.mail.ru [94.100.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id 25D488FC14; Sat, 17 Oct 2009 15:01:11 +0000 (UTC) Received: from [217.25.27.27] (port=23978 helo=[217.25.27.27]) by mx74.mail.ru with asmtp id 1MzAmL-0007yI-00; Sat, 17 Oct 2009 19:01:09 +0400 Message-ID: <4AD9DC34.50600@mail.ru> Date: Sat, 17 Oct 2009 20:01:08 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Robert Watson References: <4AD6D99E.10805@mail.ru> <4AD95493.40200@mail.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets 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, 17 Oct 2009 15:01:11 -0000 Robert Watson wrote: > > On Sat, 17 Oct 2009, rihad wrote: > >> P.S.: BTW, there's a small admin-type inconsistency in FreeBSD 7.1: >> /etc/rc.firewall gets executed before values set by /etc/sysctl.conf >> are in effect, so "queue 2000" isn't allowed in ipfw pipe rules (as >> net.inet.ip.dummynet.pipe_slot_limit is only 100 by default), so the >> rules are silently failing without any trace in the log files - I only >> saw the errors at the console. > > This is awkward to fix for sysctls, because the firewall module may not > be loaded until the firewall stage of the boot process, so the sysctl > wouldn't take effect (and perhaps this is what you're seeing, in fact?). > Well, my kernel is built with IPFIREWALL enabled, so ipfw module is unneeded and doesn't get loaded automatically. I rather still think it's the order of execution that matters. For that matter I've worked around the problem for now by setting the sysctls explicitly in /etc/rc.firewall right before configuring the pipes: /sbin/sysctl net.inet.ip.dummynet.hash_size=512 /sbin/sysctl net.inet.ip.dummynet.pipe_slot_limit=2000 and commented them out in /etc/sysctl.conf with an XXX Now I see that this is also the reason why setting net.inet.ip.dummynet.hash_size in sysctl.conf had no effect on the hash table size at the time of creation of the pipes. > Some sysctls have associated loader tunables, which you can set in > /boot/loader.conf (and affect configuration when the module is loaded), > but it looks like that isn't true for net.inet.ip.dummynet.pipe_slot_limit. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > From owner-freebsd-net@FreeBSD.ORG Sat Oct 17 21:54:59 2009 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 0A5CD1065670 for ; Sat, 17 Oct 2009 21:54:59 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 930808FC22 for ; Sat, 17 Oct 2009 21:54:58 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-233-13.belrs3.nsw.optusnet.com.au [122.106.233.13]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n9HLstM5002070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Oct 2009 08:54:56 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n9HLss5M018373; Sun, 18 Oct 2009 08:54:54 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n9HLssVO018372; Sun, 18 Oct 2009 08:54:54 +1100 (EST) (envelope-from peter) Date: Sun, 18 Oct 2009 08:54:54 +1100 From: Peter Jeremy To: rihad Message-ID: <20091017215454.GG38569@server.vk2pj.dyndns.org> References: <4AC8A76B.3050502@mail.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PyMzGVE0NRonI6bs" Content-Disposition: inline In-Reply-To: <4AC8A76B.3050502@mail.ru> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets 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, 17 Oct 2009 21:54:59 -0000 --PyMzGVE0NRonI6bs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Oct-04 18:47:23 +0500, rihad wrote: >Hi, we have around 500-600 mbit/s traffic flowing through a 7.1R Dell=20 >PowerEdge w/ 2 GigE bce cards. There are currently around 4 thousand ISP= =20 >users online limited by dummynet pipes of various speeds. According to=20 >netstat -s output around 500-1000 packets are being dropped every second= =20 >(this accounts for wasting around 7-12 mbit/s worth of traffic according= =20 >to systat -ifstat): This has been a most interesting thread. A couple of comments: Traffic shaping only works cleanly on TCP flows - UDP has no feedback mechanism and so will not automatically throttle to fit into the available bandwidth, potentially leading to high packet drops within dummynet. Is it possible that some of your customers are heavily using UDP? Have you tried allowing just UDP traffic to bypass the pipes to see if this has any effect on drop rate? The pipe lists you posted showed that virtually all the packet drops are associated with one or two IP addresses. If this is really true, rather than a measurement artifact, you might find it useful to tcpdump those addresses and see if there's anything unusual in the data being passed. Also, if you monitor the pipe lists following a cold start, do those addresses appear early and just not show any packet loss until the total number of users builds up or do they not appear until later and immediately show packet loss? Looking at how 'output packets dropped due to no bufs, etc.' is counted (ipstat.ips_odropped), if you run 'netstat -id', do you see a large number of drops on bce1 (consistent with the "output packets dropped" counts) or not? This will help narrow down the codepath being followed by dropped packets. Since the problem only appears to manifest when table(0) exceeds 2000 entries, have you considered splitting (at least temporarily) that table (and possibly table(2)) into two (eg table(0) and table(4))? This would help rule out an (unlikely) problem with table sizes. Doin so would require the application to split the users across both tables (eg round-robin or based on one of the bits in the IP address) and then duplicating the relevant ipfw rules - eg: 01060 pipe tablearg ip from any to table(0) out recv bce0 xmit bce1 01061 pipe tablearg ip from any to table(4) out recv bce0 xmit bce1 01070 allow ip from any to table(0) out recv bce0 xmit bce1 01071 allow ip from any to table(4) out recv bce0 xmit bce1 (And I agree that re-arranging rules to reduce the number of repeated tests should improve ipfw efficiency). The symptoms keep making me think "lock contention" - but I'm not sure how to measure that cheaply (AFAIK, LOCK_PROFILING is comparatively expensive). Finally, are you running i386 or amd64? --=20 Peter Jeremy --PyMzGVE0NRonI6bs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkraPS4ACgkQ/opHv/APuIdPIQCfRqOAHSoTEimaRPAwpLe59072 OxAAn3NdQEeZPIRzV3SWLwyBZ2+KBnFl =MChw -----END PGP SIGNATURE----- --PyMzGVE0NRonI6bs--