From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 01:11:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 738B01065680 for ; Sun, 20 Jul 2008 01:11:24 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 41F728FC1F for ; Sun, 20 Jul 2008 01:11:24 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1007504rvf.43 for ; Sat, 19 Jul 2008 18:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ayihkqJkJVBlKprGBC3YzIAeLhVRfVCRVI9bySnZjCo=; b=THOmdSaV3qUTpgACRfRQEs69b/AAt6bXKF0f06A9iciUOo2If5aII6kAorTdTxZShX RkixLiEoOuTiFxtF+o85QIbYP524bWaFkTUTNh9nnF4p57Pz2OckmXXc8nRZxUiQahDm WPoTqbejdlFmnE+/SdXx2D49AGMBhPKZU0roA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LCeBdlU2VcOO6MYTKW1QwTNY/iCCN5K1Ha4B19eND1qZusA02TZpnEyGjwB09LTZTL rzxmo8/t4MSH1ifw94TtadH5NrKePGPVxgU7db9patcOM158SVrzrskaz/6Ijr3eUHjA jNroSwanqng3I2+Joqt4jm9q7j/JwHzuOYU2M= Received: by 10.141.128.19 with SMTP id f19mr1003544rvn.107.1216516283941; Sat, 19 Jul 2008 18:11:23 -0700 (PDT) Received: by 10.141.123.2 with HTTP; Sat, 19 Jul 2008 18:11:23 -0700 (PDT) Message-ID: Date: Sat, 19 Jul 2008 18:11:23 -0700 From: "Kip Macy" To: "Brian McGinty" In-Reply-To: <601bffc40807112344n7a683f81y516f540e24d87389@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4867420D.7090406@gtcomm.net> <486A9A0E.6060308@elischer.org> <486B41D5.3060609@gtcomm.net> <4871E85C.8090907@freebsd.org> <48726422.7050703@gtcomm.net> <200807080107.m6817XxO021966@lava.sentex.ca> <601bffc40807081346q454c1f40td47a0f54806d8a8c@mail.gmail.com> <601bffc40807112344n7a683f81y516f540e24d87389@mail.gmail.com> Cc: FreeBSD Net , Paul , Andre Oppermann , Mike Tancsa Subject: Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 01:11:24 -0000 On Fri, Jul 11, 2008 at 11:44 PM, Brian McGinty wrote: >> Hi Brian >> I very much doubt that this is ceteris paribus. This is 384 random IPs >> -> 384 random IP addresses with a flow lookup for each packet. Also, >> I've read through igb on Linux - it has a lot of optimizations that >> the FreeBSD driver lacks and I have yet to implement. > > Hey Kip, > when will you push the optimization into FreeBSD? Hi Brian, I'm hoping to get to it some time in August. I'm a bit behind in my contracts at the moment. FYI: I'm actually able to forward 2.3Mpps between 2 10Gig interfaces on an 8-core system. I'm hoping to push it up to 3Mpps. Thanks, Kip From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 02:17:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D33D106566C for ; Sun, 20 Jul 2008 02:17:46 +0000 (UTC) (envelope-from brian.mcginty@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id CDE8E8FC08 for ; Sun, 20 Jul 2008 02:17:45 +0000 (UTC) (envelope-from brian.mcginty@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so528599wfg.7 for ; Sat, 19 Jul 2008 19:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=8UKJ2+vEdA5F1ZZ9+jKiGIRA3/VIfEpzVtgGrElg8/Y=; b=DzG3H78a5/Ae+T5kg6Ndi42BoAJu//zPziVQpzemr1f3OG/H5KSoZXc6lJ79cX4I88 Tf3KiYU1CsFKOopxwL94p3Aqkd3SpjkM2ZHWLF8WH+jvrHAfdOpp6+80NsdiXYU6iL0E JlpiRFHHnkhnuZubVe7tTMB+xnnaOSA3tfj8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=dEq5puBokT1nGU7VVSDX+Q5OQmquKhyDF4/9Evit236AaP4gqDtyFey0QcMtZdTfQa icaJ4hZag+b0U7A2HEbOkuIxL+0lzmDa6YNborlFAECUqL77Maz7pKR8aLg4eCe7Ibmz 12ZJQrXQRlxuB5wpoyR1vwZGvyLER52XU4wqE= Received: by 10.142.187.8 with SMTP id k8mr707451wff.226.1216520265283; Sat, 19 Jul 2008 19:17:45 -0700 (PDT) Received: by 10.142.199.4 with HTTP; Sat, 19 Jul 2008 19:17:45 -0700 (PDT) Message-ID: <601bffc40807191917g131bacao6485376365304f55@mail.gmail.com> Date: Sat, 19 Jul 2008 19:17:45 -0700 From: "Brian McGinty" To: "Kip Macy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4867420D.7090406@gtcomm.net> <486B41D5.3060609@gtcomm.net> <4871E85C.8090907@freebsd.org> <48726422.7050703@gtcomm.net> <200807080107.m6817XxO021966@lava.sentex.ca> <601bffc40807081346q454c1f40td47a0f54806d8a8c@mail.gmail.com> <601bffc40807112344n7a683f81y516f540e24d87389@mail.gmail.com> Cc: FreeBSD Net , Paul Subject: Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 02:17:46 -0000 G'day Kip, > I'm hoping to get to it some time in August. I'm a bit behind in my > contracts at the moment. A few weeks ago, I did a quick comparison of the driver between FreeBSD and Linux, and found quite a few differences that's worth pulling over. The guy from Intel working on FreeBSD, Jack?, is he the one that does this sort of sync-up of the drivers between the two distribution, or you? There's been a lot of changes recently, including full support for multiple Rx/Tx queues that significantly ups the ante on performance. FreeBSD doesn't support multiple Rx/Tx, or does something half arsed. > FYI: I'm actually able to forward 2.3Mpps between 2 10Gig interfaces > on an 8-core system. I'm hoping to push it up to 3Mpps. Is this no-loss number, and how did you test it? I don't have throughput numbers for the Oplin. I'm waiting to get some time on the Ixia at work to generate performance numbers for 1G and 10G for all packet sizes, on FreeBSD and Linux, on a 16 core system, and blast it to the list. I expect Linux to do 2-3 times better :-) Later, Brian From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 02:28:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99E7A106566B for ; Sun, 20 Jul 2008 02:28:06 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 600E48FC12 for ; Sun, 20 Jul 2008 02:28:06 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1020714rvf.43 for ; Sat, 19 Jul 2008 19:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=mSU3BTn0mvS2K91/nfJ/xPFfPMh30MpFuZ10yFA7EuE=; b=m4mFyR5008p7SgjDRqiVZrvhZ+rzByreMDCuMbfwZHPL0KAUPAq3DVBUSi6F7K0qj7 vxy1IAnNHacRXJR2MMFcl2GEeU9e3dcZmkCejyQv0r8PG4244ZwcaR9CEoomhLXOqOTY C+EfKj0b6Q+URAJm5WBr8wMmCM9c5vp+PeHSk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=byHFqZK5Gt3m7SUleSs56pGclZRrWVF3G5WJW5BNnOXKQfzuOn/SkEOqdBUHj/AAe6 SlttxyzMTJP8NnZSCrUmLjYF0OjRYyrQdkW+pxNJlQelDQys5g04Ci6GaYaPNNirgdWf 2nPimSfAAcN50slZ/9kbBPRH7GTueAw9T6/Ww= Received: by 10.140.201.15 with SMTP id y15mr1035220rvf.33.1216520885887; Sat, 19 Jul 2008 19:28:05 -0700 (PDT) Received: by 10.141.123.2 with HTTP; Sat, 19 Jul 2008 19:28:05 -0700 (PDT) Message-ID: Date: Sat, 19 Jul 2008 19:28:05 -0700 From: "Kip Macy" To: "Brian McGinty" In-Reply-To: <601bffc40807191917g131bacao6485376365304f55@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4867420D.7090406@gtcomm.net> <4871E85C.8090907@freebsd.org> <48726422.7050703@gtcomm.net> <200807080107.m6817XxO021966@lava.sentex.ca> <601bffc40807081346q454c1f40td47a0f54806d8a8c@mail.gmail.com> <601bffc40807112344n7a683f81y516f540e24d87389@mail.gmail.com> <601bffc40807191917g131bacao6485376365304f55@mail.gmail.com> Cc: FreeBSD Net , Paul Subject: Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 02:28:06 -0000 On Sat, Jul 19, 2008 at 7:17 PM, Brian McGinty wrote: > G'day Kip, > >> I'm hoping to get to it some time in August. I'm a bit behind in my >> contracts at the moment. > > A few weeks ago, I did a quick comparison of the driver between > FreeBSD and Linux, and found quite a few differences that's worth > pulling over. The guy from Intel working on FreeBSD, Jack?, is he the > one that does this sort of sync-up of the drivers between the two > distribution, or you? There's been a lot of changes recently, > including full support for multiple Rx/Tx queues that significantly > ups the ante on performance. FreeBSD doesn't support multiple Rx/Tx, > or does something half arsed. This is on a variant of RELENG_6 FreeBSD with a recent version of ULE and running the Checkpoint firewall. It also uses the full number of queues available to igb (4) and #queues == #cores (8 in this case) for ixgbe. The drivers in CVS have some bugs that I have fixed in this FreeBSD variant. FreeBSD's CVS version of the Intel drivers definitely lags Linux in terms of some optimizations. Even my version doesn't have some of the linux optimizations. >> FYI: I'm actually able to forward 2.3Mpps between 2 10Gig interfaces >> on an 8-core system. I'm hoping to push it up to 3Mpps. This is testing with an IXIA I don't currently have zero loss numbers. This is not fully loaded. However, ixgbe spews out pause frames when rx gets backed up so losses never get much above 0.1%. > Is this no-loss number, and how did you test it? I don't have > throughput numbers for the Oplin. I'm waiting to get some time on the > Ixia at work to generate performance numbers for 1G and 10G for all > packet sizes, on FreeBSD and Linux, on a 16 core system, and blast it > to the list. I expect Linux to do 2-3 times better :-) Sure, if you don't care about packet reordering. On their own box Checkpoint claims that Linux is currently able to do 20% better than we are seeing. Even they don't claim 200% - 300%. I know people who are switching off of Linux for memcache because they simply can't make it perform. So you're mileage really varies depending on the workload. I'm not sure where you get your numbers from. I would really like to get a hold of this magical Linux distribution to do a side by side comparison on the same workload. A 200% - 300% performance delta would definitely justify switching. Thanks, Kip From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 13:25:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5337106567C for ; Sun, 20 Jul 2008 13:25:13 +0000 (UTC) (envelope-from luigi.iannone@uclouvain.be) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by mx1.freebsd.org (Postfix) with ESMTP id 0954F8FC29 for ; Sun, 20 Jul 2008 13:25:12 +0000 (UTC) (envelope-from luigi.iannone@uclouvain.be) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= mime-version:to:message-id:content-type:cc:subject:from:date; q= dns/txt; s=selucl; bh=HqPu6ES/hDsXpPR86kQRa5ovtl0=; b=iYNLI9Dxp7 Ej85JAy3hqUEGZ9if811J0itSPTozmQUqyyz/YwOjkQjfb8OYjOxp/HLmQL32TWk uLCLBYqShVRseBRASJFBHNhLJVjOgEop7YlfDKcGqE6jMXwUhHKpabIIxDpEm1QS 1a7ABE+ffK0qo5UNTVMFo7Ek8KUByYeyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=mime-version:to: message-id:content-type:cc:subject:from:date; q=dns; s=selucl; b= BLzVLK6gVbpO8e9NTQjQNpV5uavmTGah35nMlhrCTktz3ZQl2PIAuZ+Go6dnRf0k /+X0ptk2bObwOtMGN74R4WSiOzFAHo8NyRlRTa4m0N5fLU1cfEvkNK+KK/82tcvf fWR7goxuNjzkBLK1WYLZnvKN0RL+3LH6BRI5vueZ+j8= Received: from [130.104.228.72] (unknown [130.104.228.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: iannone@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP; Sun, 20 Jul 2008 15:08:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v753.1) To: freebsd-net@freebsd.org Message-Id: From: Luigi Iannone Date: Sun, 20 Jul 2008 15:08:14 +0200 X-Mailer: Apple Mail (2.753.1) X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-MailScanner-ID: 7F04FE99FD.6F060 X-SGSI-MailScanner: Found to be clean X-SGSI-From: luigi.iannone@uclouvain.be X-SGSI-Spam-Status: No Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Bonaventure Subject: OpenLISP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 13:25:13 -0000 Hello FreeBSD Networking Community, During the last years, there have been many discussions about the scalability of the Internet architecture notably within the IRTF RRG. With IPv6, thanks to its huge addressing space, it is possible to design protocols and mechanisms that are more scalable and more powerful than with IPv4. A typical example is the multihoming problem. This problem occurs when a site is attached to several Internet Service providers. With IPv4, the classical solution is for the site to obtain one IPv4 prefix and advertise it by using BGP. This solution works and traffic engineering is possible, but unfortunately, it contributes to a significant growth of the BGP routing tables in the global Internet. Approaches to better scale the Internet architecture are being discussed, notably within the Routing Research Group of the Internet Research Task Force. Several of these approaches rely on separating the two roles of IP addresses: the locator role and the identifier role. In today's IPv4 Internet, IPv4 addresses are used both to indicate the location in the Internet topology of a host (the locator role) and to terminate the transport flows on end-hosts (the identifier role). This means that it is difficult to change the IP address of a host without disrupting transport flows. The techniques that separate identifiers from locators take a different approach. First, an identifier is attached to each end- host. This identifier is used to terminate the transport flows. Second, each identifier may be reachable through multiple locators and a mapping mechanism is used to map an identifier (or a set of identifiers) onto a set of locators. This improves the scalability of the routing system as only the locators need to be distributed by BGP provided, of course, that the mapping system remains scalable. Furthermore, separating identifiers and locators has several additional benefits in terms of path diversity and performance. Some approaches propose to attach locators to hosts while other prefer to attach locators only to routers. The latter approach is the solution chosen by the proponents of the Locator/Identifier Separation Protocol (LISP). LISP is a router-based solution to solve the scaling problems of the Internet architecture that is currently being developed by Cisco. There are still many open questions concerning notably the mapping between identifiers and locators. To allow researchers and network operators to experiment with LISP, the IP Networking Lab of UCLouvain releases OpenLISP. OpenLISP is the first publicly available implementation of LISP on the FreeBSD kernel. OpenLISP was designed and implemented by Luigi Iannone. You can find more details about OpenLISP from http://inl.info.ucl.ac.be Any feedback from the FreeBSD Networking community is more than welcome. Best regards, Luigi Iannone luigi.iannone@uclouvain.be From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 18:33:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 865491065671 for ; Sun, 20 Jul 2008 18:33:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 788758FC1B for ; Sun, 20 Jul 2008 18:33:00 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B15F323E8; Sun, 20 Jul 2008 11:33:00 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D629E2D603A; Sun, 20 Jul 2008 11:32:59 -0700 (PDT) Message-ID: <488384E5.3060608@elischer.org> Date: Sun, 20 Jul 2008 11:33:09 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Luigi Iannone References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Olivier Bonaventure Subject: Re: OpenLISP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 18:33:00 -0000 Luigi Iannone wrote: > Hello FreeBSD Networking Community, > hello to you too :-) > The latter approach is the solution chosen by the proponents of the > Locator/Identifier Separation Protocol (LISP). LISP is a router-based > solution to solve the scaling problems of the Internet architecture that > is currently being developed by Cisco. Couldn't possibly come up with a better acronym? "lisp" is kinda taken.. are there any documents with PICTURES you can recommend to us? Does this connect at all with SCTP's capacity to multihome? jelische@cisco.com From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 18:45:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 896EB1065681 for ; Sun, 20 Jul 2008 18:45:53 +0000 (UTC) (envelope-from luigi.iannone@uclouvain.be) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by mx1.freebsd.org (Postfix) with ESMTP id 0F01D8FC17 for ; Sun, 20 Jul 2008 18:45:52 +0000 (UTC) (envelope-from luigi.iannone@uclouvain.be) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= in-reply-to:references:mime-version:content-type:message-id:cc: from:subject:date:to; q=dns/txt; s=selucl; bh=hu96y0RKWytaZEBSWc 9qqkHy9nw=; b=sZI/l5I5nJ+5Er+bn+UoyYd4cr4grheCMsUWKZF7NbKB7gpAli 7xPby069Llo964M/bjscrasugoxlGUK3cICaazytcOopZDxtalUwRR+iwGiB5I96 O6BZinpY1thklnTSH0UhiCZcxhp6570WbjaBxHgxrP+BjOEtF0Rduob/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=in-reply-to: references:mime-version:content-type:message-id:cc:from:subject: date:to; q=dns; s=selucl; b=Ah2xghYrHKsoHVQLTogoeGiIcaF4ei1Ey+vc XM89sF6yysUdbijbZZyrAFUiqYIAZQHM9k/SZG4G586P4h2MWfF9/i6I4FHpJQy/ Op8s4QenrkOt/FrBMQih9cudZ0UbU+863T36cJRq8zXkUDKt8uyUZ9fHY/U5A1xH b9TUoeI= Received: from [88.82.43.254] (unknown [88.82.43.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: iannone@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP; Sun, 20 Jul 2008 20:45:15 +0200 (CEST) In-Reply-To: <488384E5.3060608@elischer.org> References: <488384E5.3060608@elischer.org> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Luigi Iannone Date: Sun, 20 Jul 2008 20:44:39 +0200 To: Julian Elischer X-Mailer: Apple Mail (2.753.1) X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-MailScanner-ID: CB8321C6DD0.CD3E4 X-SGSI-MailScanner: Found to be clean X-SGSI-From: luigi.iannone@uclouvain.be X-SGSI-Spam-Status: No Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Olivier Bonaventure Subject: Re: OpenLISP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 18:45:53 -0000 Hi, Le 20-juil.-08 =E0 20:33, Julian Elischer a =E9crit : > Luigi Iannone wrote: >> Hello FreeBSD Networking Community, > > hello to you too :-) > > >> The latter approach is the solution chosen by the proponents of =20 >> the Locator/Identifier Separation Protocol (LISP). LISP is a =20 >> router-based solution to solve the scaling problems of the =20 >> Internet architecture that is currently being developed by Cisco. > > Couldn't possibly come up with a better acronym? "lisp" is kinda =20 > taken.. > > are there any documents with PICTURES you can recommend to us? > Well, the official document can be found here: http://www.ietf.org/internet-drafts/draft-farinacci-lisp-08.txt If you want some _pictures_ you can get a look here: http://rosie.ripe.net/ripe/meetings/ripe-56/presentations/uploads/=20 Tuesday/Plenary%2016:00/upl/Fuller-LISP_Intro_and_Update.gNyX.pps > Does this connect at all with SCTP's capacity to multihome? > Not really. As far as I know SCTP is an end-to-end solution, where =20 end-to-end stand for end-hosts. LISP is meant to be deployed mainly on border routers of stub domains. Cheers Luigi > > > jelische@cisco.com Luigi Iannone luigi.iannone@uclouvain.be From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 18:51:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C625D106567E for ; Sun, 20 Jul 2008 18:51:06 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 62C638FC19 for ; Sun, 20 Jul 2008 18:51:06 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-000-042.pools.arcor-ip.net [88.66.0.42]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1KKdzs3PT6-0000ak; Sun, 20 Jul 2008 20:51:05 +0200 Received: (qmail 65794 invoked from network); 20 Jul 2008 18:51:04 -0000 Received: from myhost.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 20 Jul 2008 18:51:04 -0000 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sun, 20 Jul 2008 20:51:04 +0200 User-Agent: KMail/1.9.9 References: <488384E5.3060608@elischer.org> In-Reply-To: <488384E5.3060608@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807202051.04431.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19xmhRWnB6+uU4Bgeaq/XF+tHUME0rxZSHAzAX LNuc7XF0Z7Rjq6NnUpKpLWeD5u7FFkUxbZ4K5/gfB89iVeIXLF GrCMM7h8WiiBRWbktx+0Q== Cc: Luigi Iannone , Olivier Bonaventure , Julian Elischer Subject: Re: OpenLISP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 18:51:06 -0000 On Sunday 20 July 2008 20:33:09 Julian Elischer wrote: > Luigi Iannone wrote: > > Hello FreeBSD Networking Community, > > hello to you too :-) > > > The latter approach is the solution chosen by the proponents of the > > Locator/Identifier Separation Protocol (LISP). LISP is a router-based > > solution to solve the scaling problems of the Internet architecture > > that is currently being developed by Cisco. > > Couldn't possibly come up with a better acronym? "lisp" is kinda > taken.. > > are there any documents with PICTURES you can recommend to us? The draft is quite readable: http://tools.ietf.org/html/draft-farinacci-lisp-08 > Does this connect at all with SCTP's capacity to multihome? (AFAIK) Not at all. They try to solve similar problems (or at least there is some intersection). A word about the implementation. The interception mechanism for LISP tunneled packets in ip_input/forward is *horrible*! Some of that is due to the design, but I believe it can be implemented much cleaner if you were to use the pfil(9) API. I'd really like to avoid putting this kind of stuff into the main ip code as it hurts readability a lot. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 19:00:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD4FE1065672 for ; Sun, 20 Jul 2008 19:00:31 +0000 (UTC) (envelope-from luigi.iannone@uclouvain.be) Received: from smtp1.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3D98FC12 for ; Sun, 20 Jul 2008 19:00:31 +0000 (UTC) (envelope-from luigi.iannone@uclouvain.be) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= in-reply-to:references:mime-version:content-type:message-id:cc: from:subject:date:to; q=dns/txt; s=selucl; bh=K6xIp2y0N0NN58rCKW WX5MazPYA=; b=TJyMV/1GA24pv4zscjeuVq9jAaxFYNB/65KXGSgS1lzo+jC/u8 FvVVuiYq7SD+zYvj5uGNtaBpqIz3B0CeWyPL5ghbhTB0q0fVlpt47RWGdvqJrE+j Ms/EHWZO6cmzMsvlNdmFvqSk4pSXoSlwK6T1GEksuQWN0NQ1a67S3dzq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=in-reply-to: references:mime-version:content-type:message-id:cc:from:subject: date:to; q=dns; s=selucl; b=LJuaXXabY7TF4AqOWpvWnU3hcIsxHU3LG6cn s3sANdF/QRzpnR1UGQoOc3pqWGNrC0IHuiELGaMe3mRpe+4qxclEsXh96OvWJ2je j/dHwusbg7aYXbkeZPxyrHLEj6FMVmzRFqPbizzuS7/uDfFXRkcLGPpgDDb3jZFZ Mjlea1A= Received: from [88.82.43.254] (unknown [88.82.43.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: iannone@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP; Sun, 20 Jul 2008 20:59:34 +0200 (CEST) In-Reply-To: <200807202051.04431.max@love2party.net> References: <488384E5.3060608@elischer.org> <200807202051.04431.max@love2party.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <4711A2FE-DFB4-44C0-9FA6-D69BD1B05C2E@uclouvain.be> From: Luigi Iannone Date: Sun, 20 Jul 2008 20:59:04 +0200 To: Max Laier X-Mailer: Apple Mail (2.753.1) X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-MailScanner-ID: 02C7FE961C.73FD5 X-SGSI-MailScanner: Found to be clean X-SGSI-From: luigi.iannone@uclouvain.be X-SGSI-Spam-Status: No Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Olivier Bonaventure , Julian Elischer Subject: Re: OpenLISP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 19:00:31 -0000 > Hi, > A word about the implementation. The interception mechanism for LISP > tunneled packets in ip_input/forward is *horrible*! Some of that > is due > to the design, but I believe it can be implemented much cleaner if you > were to use the pfil(9) API. I'd really like to avoid putting this > kind > of stuff into the main ip code as it hurts readability a lot. > Thanks for the hint I'll get a look at that. Cheers Luigi > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > _______________________________________________ > 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" Luigi Iannone luigi.iannone@uclouvain.be From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 19:49:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9513C1065675 for ; Sun, 20 Jul 2008 19:49:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 87E3B8FC08 for ; Sun, 20 Jul 2008 19:49:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B0D862497; Sun, 20 Jul 2008 12:49:27 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 593602D6014; Sun, 20 Jul 2008 12:49:26 -0700 (PDT) Message-ID: <488396CE.1060008@elischer.org> Date: Sun, 20 Jul 2008 12:49:34 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Luigi Iannone References: <488384E5.3060608@elischer.org> <200807202051.04431.max@love2party.net> <4711A2FE-DFB4-44C0-9FA6-D69BD1B05C2E@uclouvain.be> In-Reply-To: <4711A2FE-DFB4-44C0-9FA6-D69BD1B05C2E@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , Olivier Bonaventure , freebsd-net@freebsd.org Subject: Re: OpenLISP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 19:49:27 -0000 Luigi Iannone wrote: >> > > Hi, > > >> A word about the implementation. The interception mechanism for LISP >> tunneled packets in ip_input/forward is *horrible*! Some of that is due >> to the design, but I believe it can be implemented much cleaner if you >> were to use the pfil(9) API. I'd really like to avoid putting this kind >> of stuff into the main ip code as it hurts readability a lot. >> > > Thanks for the hint I'll get a look at that. my head hurts after reading that :-) I think I only 'got' half of it.. I'll read it again later.. The aim of this is to reduce routing table size and allow multihoming with the destination being able to suggest to a remote sight how to route back to it right? > > Cheers > > Luigi > > From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 19:58:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36E63106564A for ; Sun, 20 Jul 2008 19:58:00 +0000 (UTC) (envelope-from luigi.iannone@uclouvain.be) Received: from smtp2.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by mx1.freebsd.org (Postfix) with ESMTP id B4EF48FC19 for ; Sun, 20 Jul 2008 19:57:59 +0000 (UTC) (envelope-from luigi.iannone@uclouvain.be) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= in-reply-to:references:mime-version:content-type:message-id:cc: from:subject:date:to; q=dns/txt; s=selucl; bh=49agBH1YqfqhasyjHy IhtRLY0E0=; b=sl7zFXBScqY4G/5+CjHTBPJrj/pRiyNIzySU6tqv95Uv35G1pZ a0svr+hCMfz+x2nM2hIvJEnFyJDcJf6jHfdXcX4AUtT0cNOXQ6yh0ACrF5Muddtp 9XEt+CMnbRpQzM819yAFuWekXcfx/zSokMcMnDTYCh1Nlzchn81kEaeMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=in-reply-to: references:mime-version:content-type:message-id:cc:from:subject: date:to; q=dns; s=selucl; b=KHe+pLS4GlTsNNcDDK/UdtCEZ94BdtAoNQLa NetQs8w4Zeg4EtxgagfzP0eNhuiCFqvOrHt3zwdS0dWqOT5jX6brRHLwFC9t1zhl 6NCLrklysIjSy5M9SjDS+pkRJrOwSGSAzL7E3SupiWqP4lMtrqsZBhS6RskirE+4 nky0z5Q= Received: from [88.82.43.254] (unknown [88.82.43.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: iannone@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTP; Sun, 20 Jul 2008 21:57:09 +0200 (CEST) In-Reply-To: <488396CE.1060008@elischer.org> References: <488384E5.3060608@elischer.org> <200807202051.04431.max@love2party.net> <4711A2FE-DFB4-44C0-9FA6-D69BD1B05C2E@uclouvain.be> <488396CE.1060008@elischer.org> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Luigi Iannone Date: Sun, 20 Jul 2008 21:56:34 +0200 To: Julian Elischer X-Mailer: Apple Mail (2.753.1) X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-MailScanner-ID: C5768EB46C.9A1EA X-SGSI-MailScanner: Found to be clean X-SGSI-From: luigi.iannone@uclouvain.be X-SGSI-Spam-Status: No Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Max Laier , Olivier Bonaventure , freebsd-net@freebsd.org Subject: Re: OpenLISP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 19:58:00 -0000 Le 20-juil.-08 =E0 21:49, Julian Elischer a =E9crit : > Luigi Iannone wrote: >>> >> Hi, >>> A word about the implementation. The interception mechanism for =20 >>> LISP tunneled packets in ip_input/forward is *horrible*! Some of =20= >>> that is due to the design, but I believe it can be implemented =20 >>> much cleaner if you were to use the pfil(9) API. I'd really like =20= >>> to avoid putting this kind of stuff into the main ip code as it =20 >>> hurts readability a lot. >>> >> Thanks for the hint I'll get a look at that. > > my head hurts after reading that :-) > > I think I only 'got' half of it.. > I'll read it again later.. > The aim of this is to reduce routing table size and allow multihoming > You got it. > with the destination being able to suggest to a remote sight how to =20= > route back to it right? > or at least suggest where to go through ... L. > >> Cheers >> Luigi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" Luigi Iannone luigi.iannone@uclouvain.be From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 22:38:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD9EC1065672 for ; Sun, 20 Jul 2008 22:38:34 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by mx1.freebsd.org (Postfix) with ESMTP id 79FF38FC24 for ; Sun, 20 Jul 2008 22:38:34 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so815502fkk.11 for ; Sun, 20 Jul 2008 15:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=4eqxpHak8req/ssgqzBn1zk21GjOaxXFo5erfKrbC6s=; b=piQ/hm0sZoOoJcG+X72Kc1vrcKhi4ZOpPISXAxijaqoocBuV0LbwCjsaE517FzwIPc jUp64hvh7So5/xbSAtqvM3oUKxhOp1pSJA+SxWwNjgA0TrOwJYnxuDhSVygyH7VqSFD+ 1P98mTvrL4fgAb55o7YhfawOEYljAHzlJdiQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=E1I/bXixxMloL95XJC0dAkNu6o9S2rXysGp649okXDfIhr+FTN+vMjPliN3kdveBUh UztAoeGJ/jABnlb+3Zu8KuAzzFQu1OkOQI//5+SKWBXFB9bT3ACEkie/g8fS5igpZD66 0r1miZMKPfzBryckxjeBKSbOJayzTlIXN14Lk= Received: by 10.125.138.7 with SMTP id q7mr194935mkn.167.1216592071721; Sun, 20 Jul 2008 15:14:31 -0700 (PDT) Received: by 10.125.139.12 with HTTP; Sun, 20 Jul 2008 15:14:31 -0700 (PDT) Message-ID: <3c1674c90807201514o5bafba72r6be84de6e37a5525@mail.gmail.com> Date: Sun, 20 Jul 2008 15:14:31 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 162f2d32343d237e Subject: moving sockbuf in to its own header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 22:38:35 -0000 TOE drivers need to be able to directly enqueue data in to a socket buffer and thus benefit from having knowledge of sockbuf internals. However, there is no need for them to know about other socket definitions. Thus I would like to move sockbuf and accompanying definitions to their own header. This is a fairly straightforward change so I don't really see the need to wait more than a few days for feedback: http://www.fsmware.com/sockbuf.h.diff From owner-freebsd-net@FreeBSD.ORG Sun Jul 20 23:07:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36C4A1065671 for ; Sun, 20 Jul 2008 23:07:30 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 178EB8FC18 for ; Sun, 20 Jul 2008 23:07:30 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1280002rvf.43 for ; Sun, 20 Jul 2008 16:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=FSCyjLR9Aj28zHWL1wR1Krew2tfVvqkBnJ8ujLOMCjc=; b=RNSsmVGl4GLgZGNxO8oeezMui0IS5j1F6PE/6WMYA7EsfK12xAapZFD/gez6Kn1mV3 8eLO0kzMG57ea8wctpT1iVHLU+s/WMRoLDSZSd4HXobTpEB7ACkByJNEi1nfVpLeov17 DQkAyZ6MxH69cXGma9pnagPx2Qu7Aou2vqGCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=FQmnFdnBs1eDgxIE8tqpJNoQYdiWXBzEnnU47ioLLdlJZHN6+cQdz4ms0uv17rB6q1 HLiQv1/G0QtpSrCfh9wlXOfaFkKjRzkg2E9nyJl0sXdWH6jCoO9ko2lZKdBUtVAUClA+ kFZgfh277C1Ejc4Q5NKlGns28TzSStFV4EXWQ= Received: by 10.140.157.1 with SMTP id f1mr1474771rve.220.1216595249620; Sun, 20 Jul 2008 16:07:29 -0700 (PDT) Received: by 10.141.123.2 with HTTP; Sun, 20 Jul 2008 16:07:29 -0700 (PDT) Message-ID: Date: Sun, 20 Jul 2008 16:07:29 -0700 From: "Kip Macy" To: "Kip Macy" In-Reply-To: <3c1674c90807201514o5bafba72r6be84de6e37a5525@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c1674c90807201514o5bafba72r6be84de6e37a5525@mail.gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: moving sockbuf in to its own header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2008 23:07:30 -0000 Actually, I'd like to re-factor multiple parts of socketvar in to separate files. Please provide feedback on the following: http://www.fsmware.com/socketvar_refactor.diff Thanks, Kip On Sun, Jul 20, 2008 at 3:14 PM, Kip Macy wrote: > TOE drivers need to be able to directly enqueue data in to a socket > buffer and thus benefit from having knowledge of sockbuf internals. > However, there is no need for them to know about other socket > definitions. Thus I would like to move sockbuf and accompanying > definitions to their own header. > > This is a fairly straightforward change so I don't really see the need > to wait more than a few days for feedback: > > http://www.fsmware.com/sockbuf.h.diff > _______________________________________________ > 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 Jul 21 08:31:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 781831065671 for ; Mon, 21 Jul 2008 08:31:13 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6AC8FC18 for ; Mon, 21 Jul 2008 08:31:13 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 5C4A63F7B; Mon, 21 Jul 2008 10:31:10 +0200 (CEST) Date: Mon, 21 Jul 2008 10:31:10 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20080721083110.GA21786@zen.inc> References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487EC62A.3070301@freebsd.org> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 08:31:13 -0000 On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote: [...] > Please test/review the following patch against HEAD: > > http://people.freebsd.org/~sam/nat_t-20080616.patch I have tested the RELENG7 version of the patch, and it works well. But I noticed a misplaced #endif at the beginning of udp_ctloutput(), which will generate problems if INET6 is not defined: if (sopt->sopt_level != IPPROTO_UDP) { #ifdef INET6 if (INP_CHECK_SOCKAF(so, AF_INET6)) { INP_WUNLOCK(inp); error = ip6_ctloutput(so, sopt); #endif } else { INP_WUNLOCK(inp); error = ip_ctloutput(so, sopt); #ifdef INET6 } #endif return (error); } The code should be: if (sopt->sopt_level != IPPROTO_UDP) { #ifdef INET6 if (INP_CHECK_SOCKAF(so, AF_INET6)) { INP_WUNLOCK(inp); error = ip6_ctloutput(so, sopt); } else { #endif INP_WUNLOCK(inp); error = ip_ctloutput(so, sopt); #ifdef INET6 } #endif return (error); } Yvan. From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 09:30:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 935501065674 for ; Mon, 21 Jul 2008 09:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3B7CE8FC1C for ; Mon, 21 Jul 2008 09:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C09CC41C752; Mon, 21 Jul 2008 11:30:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Uo44VxQI04Yl; Mon, 21 Jul 2008 11:30:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 3B9AA41C6A1; Mon, 21 Jul 2008 11:30: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 7510544487F; Mon, 21 Jul 2008 09:26:15 +0000 (UTC) Date: Mon, 21 Jul 2008 09:26:15 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Sam Leffler In-Reply-To: <487EC62A.3070301@freebsd.org> Message-ID: <20080721085325.B57089@maildrop.int.zabbadoz.net> References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, vanhu_bsd@zeninc.net, Larry Baird Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 09:30:07 -0000 On Wed, 16 Jul 2008, Sam Leffler wrote: Hi, > Please test/review the following patch against HEAD: > > http://people.freebsd.org/~sam/nat_t-20080616.patch > > This adds only the kernel portion of the NAT-T support; you must provide the > user-level code from another place. > > The main difference from the patches floating around are in the ctloutput > path (adding proper locking for HEAD) and decap of ESP-in-UDP frames. > Assuming folks are ok w/ these changes I'll commit to HEAD. Once this stuff > goes in we can look at getting the user-mode mods into the tree. I have skipped through the patch. My main concern at the moment is the API (pfkey stuff) to userland as Yvan had stated in <20080626075307.GA1401@zen.inc>. I know that at the moment there seems to be one public (pseudo) reference implementation this all works together but there might be/are other people not using libipsec from ipsec-tools. The point is changing the API once this hits the tree will be hard to detect at a later point if at all (unless with a __FreeBSD_version or (another) library version bump/sym versioning). We are still missing other things I think not mentioned elswhere like partial checksum recalculation. I still wonder if we'd have all the information (at the right place) in the kernel so we could easily add support for that at a later time w/o having to change APIs again. Considering that it seems noone using this patch in products has implemented this .. I dunno. It's something that is already mentioned in the introduction of RFC 3947 and in 3.1.2. of 3948 and thus should be very obvious to anyone ever seriously thought of finishing a proper more than "it works for me" version of the patch. Some minor things I had seen not reported so far: I have seen two printfs that should be changed to proper logging, ... /NAT-T OA present s,bave,have, in "...in the SPD: This means we bave a non-generated" but maybe change the entire comment. "non-generated SPD" is kind of wrong wording. I'd happily go through another patch once the missing/to be corrected things were addressed. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 11:06:59 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D729E106564A for ; Mon, 21 Jul 2008 11:06:59 +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 AADCA8FC18 for ; Mon, 21 Jul 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6LB6xlF031948 for ; Mon, 21 Jul 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6LB6x0X031944 for freebsd-net@FreeBSD.org; Mon, 21 Jul 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Jul 2008 11:06:59 GMT Message-Id: <200807211106.m6LB6x0X031944@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 11:06:59 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net [patch] changing interface ipaddress doesn't seem to w s kern/39937 net ipstealth issue s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau f kern/102344 net [ipf] Some packets do not pass through network interfa o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122685 net It is not visible passing packets in tcpdump o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f conf/122858 net [nsswitch.conf] nsswitch in 7.0 is f*cked up o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123172 net [bce] Watchdog timeout problems with if_bce f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123617 net [tcp] breaking connection when client downloading file o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel 94 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem o kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123892 net [tap] [patch] No buffer space available p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o bin/124004 net ifconfig(8): Cannot assign both an IP and a MAC addres o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/125181 net [ndis] [patch] with wep enters kdb.enter.unknown, pani o kern/125239 net [gre] kernel crash when using gre o kern/125258 net [socket] socket's SO_REUSEADDR option does not work f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in 57 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 13:57:58 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7DE61065684; Mon, 21 Jul 2008 13:57:58 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0AA8FC12; Mon, 21 Jul 2008 13:57:58 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6LDvwZf049997; Mon, 21 Jul 2008 13:57:58 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6LDvwPB049993; Mon, 21 Jul 2008 13:57:58 GMT (envelope-from gavin) Date: Mon, 21 Jul 2008 13:57:58 GMT Message-Id: <200807211357.m6LDvwPB049993@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/125816: [carp] [bridge] carp stuck in init when using bridge 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, 21 Jul 2008 13:57:58 -0000 Old Synopsis: carp stuck in init when using bridge interface New Synopsis: [carp] [bridge] carp stuck in init when using bridge interface Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Jul 21 13:53:12 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). Hopefully somebody can establish if this is an issue with carp or with bridge. http://www.freebsd.org/cgi/query-pr.cgi?pr=125816 From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 14:13:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABB53106566B for ; Mon, 21 Jul 2008 14:13:30 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4688FC17 for ; Mon, 21 Jul 2008 14:13:30 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id C636A3F7B; Mon, 21 Jul 2008 16:13:27 +0200 (CEST) Date: Mon, 21 Jul 2008 16:13:27 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20080721141327.GA24677@zen.inc> References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> <20080721083110.GA21786@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080721083110.GA21786@zen.inc> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 14:13:30 -0000 On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote: > On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote: > [...] > > Please test/review the following patch against HEAD: > > > > http://people.freebsd.org/~sam/nat_t-20080616.patch > > I have tested the RELENG7 version of the patch, and it works well. > > > But I noticed a misplaced #endif at the beginning of udp_ctloutput(), > which will generate problems if INET6 is not defined: [....] After some more testing, I found another issue: in udp4_espdecap(), when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should not be discarded, but just returned for normal processing. And I also have doubts about a change in udp_ctloutput(), in the switch statement which process optval and searches for an UDP_ENCAP_ESPINUDP* flag. The way you changed it forces a flags cleanup anytime. I don't see why someone would set both UDP_ENCAP_ESPINUDP and UDP_ENCAP_ESPINUDP_NON_IKE, but as I was tracking down a problem, I changed it again to be processed "the old way" to ensure it was not the source of the issue. Sam, did you have a good reason to change that part of the code, or was it mostly to have a more compliant coding style ? Updated patches are available for HEAD, RELENG7 and RELENG63 (yeah :-) here: http://people.freebsd.org/~vanhu/NAT-T/ Please all notice that there is still the word "test" in patches names..... Yvan. From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 14:27:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4ED91065670 for ; Mon, 21 Jul 2008 14:27:00 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8383C8FC3A for ; Mon, 21 Jul 2008 14:26:59 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id AD3643F7B; Mon, 21 Jul 2008 16:26:57 +0200 (CEST) Date: Mon, 21 Jul 2008 16:26:57 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20080721142657.GB24677@zen.inc> References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> <20080721085325.B57089@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080721085325.B57089@maildrop.int.zabbadoz.net> User-Agent: All mail clients suck. This one just sucks less. Cc: Larry Baird Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 14:27:00 -0000 [Larry, I kept you in an explicit CC, even if I guess you suscribed to the list] On Mon, Jul 21, 2008 at 09:26:15AM +0000, Bjoern A. Zeeb wrote: > On Wed, 16 Jul 2008, Sam Leffler wrote: > > Hi, Hi. [...] > My main concern at the moment is the API (pfkey stuff) to userland as > Yvan had stated in <20080626075307.GA1401@zen.inc>. It is also one of my main concerns actually. > I know that at the moment there seems to be one public (pseudo) reference > implementation this all works together but there might be/are other > people not using libipsec from ipsec-tools. Well, people who use another libipsec are expected to "just" not see NAT-T extensions. The only "real issue" is that, actually, NAT-T ports are sent though sockaddr structs, when RFC 2367 says that zeroing ports MUST be done (section 2.3.3). There is already an open ticket on ipsec-tools side to cleanup that part of the code on userland's size of PFKey interface, and I hope it will be done for 0.8.0 release (sorry, no release date for now). As soon as I'll have a working patch on userland, I'll do the work on FreeBSD's kernel side. I hope everything will be done within a few weeks, but I already know that we'll have backward compatibility issues with various kernels (ipsec-tools runs at least on FreeBSD, NetBSD, Linux and MacOSX). Yvan. From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 15:20:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD2851065670 for ; Mon, 21 Jul 2008 15:20:57 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8088FC14 for ; Mon, 21 Jul 2008 15:20:57 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m6LFKs9w021931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 08:20:55 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4884A956.5060108@freebsd.org> Date: Mon, 21 Jul 2008 08:20:54 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> <20080721085325.B57089@maildrop.int.zabbadoz.net> In-Reply-To: <20080721085325.B57089@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org, vanhu_bsd@zeninc.net, Larry Baird Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 15:20:57 -0000 Bjoern A. Zeeb wrote: > On Wed, 16 Jul 2008, Sam Leffler wrote: > > Hi, > >> Please test/review the following patch against HEAD: >> >> http://people.freebsd.org/~sam/nat_t-20080616.patch >> >> This adds only the kernel portion of the NAT-T support; you must >> provide the user-level code from another place. >> >> The main difference from the patches floating around are in the >> ctloutput path (adding proper locking for HEAD) and decap of >> ESP-in-UDP frames. Assuming folks are ok w/ these changes I'll commit >> to HEAD. Once this stuff goes in we can look at getting the >> user-mode mods into the tree. > > I have skipped through the patch. > > My main concern at the moment is the API (pfkey stuff) to userland as > Yvan had stated in <20080626075307.GA1401@zen.inc>. > > I know that at the moment there seems to be one public (pseudo) reference > implementation this all works together but there might be/are other > people not using libipsec from ipsec-tools. > > The point is changing the API once this hits the tree will be hard to > detect at a later point if at all (unless with a __FreeBSD_version or > (another) library version bump/sym versioning). > > > We are still missing other things I think not mentioned elswhere like > partial checksum recalculation. Please send me your specific issues; I haven't seen any comments about "partial checksum recalculations". > I still wonder if we'd have all the information (at the right place) in > the kernel so we could easily add support for that at a later time > w/o having to change APIs again. Considering that it seems noone using > this patch in products has implemented this .. I dunno. > It's something that is already mentioned in the introduction of RFC 3947 > and in 3.1.2. of 3948 and thus should be very obvious to anyone ever > seriously thought of finishing a proper more than "it works for me" > version of the patch. I don't see any of the above blocking this work going in. Forcing people to maintain out-of-tree patches for years because of vague concerns is unproductive. This code is used by at least 2 vendors shipping products. > > > Some minor things I had seen not reported so far: > > I have seen two printfs that should be changed to proper logging, ... > /NAT-T OA present > > s,bave,have, in "...in the SPD: This means we bave a non-generated" > but maybe change the entire comment. "non-generated SPD" is kind of > wrong wording. > > > I'd happily go through another patch once the missing/to be corrected > things were addressed. > Please apply your changes to the p4 branch or fix 'em when the code hits CVS. I've see no concrete rationale for holding this work out. Sam From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 15:33:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5DC3106566C for ; Mon, 21 Jul 2008 15:33:57 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 872FE8FC14 for ; Mon, 21 Jul 2008 15:33:57 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m6LFXvBs022086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 08:33:57 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4884AC65.7020605@freebsd.org> Date: Mon, 21 Jul 2008 08:33:57 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> <20080721083110.GA21786@zen.inc> <20080721141327.GA24677@zen.inc> In-Reply-To: <20080721141327.GA24677@zen.inc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 15:33:58 -0000 VANHULLEBUS Yvan wrote: > On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote: > >> On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote: >> [...] >> >>> Please test/review the following patch against HEAD: >>> >>> http://people.freebsd.org/~sam/nat_t-20080616.patch >>> >> I have tested the RELENG7 version of the patch, and it works well. >> >> >> But I noticed a misplaced #endif at the beginning of udp_ctloutput(), >> which will generate problems if INET6 is not defined: >> > [....] > > > After some more testing, I found another issue: in udp4_espdecap(), > when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should > not be discarded, but just returned for normal processing. > Please edit the sam_nat_t branch in p4 or send a patch I can apply. > And I also have doubts about a change in udp_ctloutput(), in the > switch statement which process optval and searches for an > UDP_ENCAP_ESPINUDP* flag. > > The way you changed it forces a flags cleanup anytime. > I don't see why someone would set both UDP_ENCAP_ESPINUDP and > UDP_ENCAP_ESPINUDP_NON_IKE, but as I was tracking down a problem, I > changed it again to be processed "the old way" to ensure it was not > the source of the issue. > Sorry but I'm not clear on what you are saying. The code changed the behaviour of setting udp encapsulation so that only one of UDP_ENCAP_ESPINUDP and UDP_ENCAP_ESPINUDP_NON_IKE can be set a time. The original code from you permitted both flags to be set but the code that handled the encap/decap assumed only one was set. > Sam, did you have a good reason to change that part of the code, or > was it mostly to have a more compliant coding style ? > See above. > > Updated patches are available for HEAD, RELENG7 and RELENG63 (yeah :-) > here: > http://people.freebsd.org/~vanhu/NAT-T/ > > Please all notice that there is still the word "test" in patches > names..... > Sorry again I don't understand what you write. Sam > > > Yvan. > _______________________________________________ > 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 Jul 21 15:42:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FE101065670 for ; Mon, 21 Jul 2008 15:42:34 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3445F8FC0A for ; Mon, 21 Jul 2008 15:42:34 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m6LFgVSi022159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 08:42:34 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4884AE67.4020204@freebsd.org> Date: Mon, 21 Jul 2008 08:42:31 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> <20080721085325.B57089@maildrop.int.zabbadoz.net> <20080721142657.GB24677@zen.inc> In-Reply-To: <20080721142657.GB24677@zen.inc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org, Larry Baird Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 15:42:34 -0000 VANHULLEBUS Yvan wrote: > [Larry, I kept you in an explicit CC, even if I guess you suscribed to > the list] > > On Mon, Jul 21, 2008 at 09:26:15AM +0000, Bjoern A. Zeeb wrote: > >> On Wed, 16 Jul 2008, Sam Leffler wrote: >> >> Hi, >> > > Hi. > > > [...] > >> My main concern at the moment is the API (pfkey stuff) to userland as >> Yvan had stated in <20080626075307.GA1401@zen.inc>. >> > > It is also one of my main concerns actually. > > > >> I know that at the moment there seems to be one public (pseudo) reference >> implementation this all works together but there might be/are other >> people not using libipsec from ipsec-tools. >> > > Well, people who use another libipsec are expected to "just" not see > NAT-T extensions. > > The only "real issue" is that, actually, NAT-T ports are sent though > sockaddr structs, when RFC 2367 says that zeroing ports MUST be done > (section 2.3.3). > > > There is already an open ticket on ipsec-tools side to cleanup that > part of the code on userland's size of PFKey interface, and I hope > it will be done for 0.8.0 release (sorry, no release date for now). > > As soon as I'll have a working patch on userland, I'll do the work on > FreeBSD's kernel side. I hope everything will be done within a few > weeks, but I already know that we'll have backward compatibility > issues with various kernels (ipsec-tools runs at least on FreeBSD, > NetBSD, Linux and MacOSX). > With regard to changing the kernel API. First, this is HEAD and api's can change. I intentionally have said nothing about MFC and didn't touch user code. Getting the support into the kernel enables use and testing which was the point of getting the logjam broken so full NAT-T support can ship w/ 8.0. I committed to get everything necessary in the tree in time for 8.0 but now that you have direct access to freebsd's repo I think that's less important. Sam From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 17:36:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A7A0106564A for ; Mon, 21 Jul 2008 17:36:13 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id BE6C18FC1B for ; Mon, 21 Jul 2008 17:36:12 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.11.16.99] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 21 Jul 2008 10:36:00 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id AEF742B1; Mon, 21 Jul 2008 10:36:00 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.11.18.52]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 9BD7E2B0 for ; Mon, 21 Jul 2008 10:36:00 -0700 (PDT) Received: from mail-irva-13.broadcom.com (mail-irva-13.broadcom.com [10.11.16.103]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id HAE72293; Mon, 21 Jul 2008 10:35:46 -0700 (PDT) Received: from NT-IRVA-0752.brcm.ad.broadcom.com (nt-irva-0752 [10.8.194.67]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 399F974CFF for ; Mon, 21 Jul 2008 10:35:46 -0700 (PDT) Received: from IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) by NT-IRVA-0752.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 10:35:45 -0700 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Mon, 21 Jul 2008 10:36:37 -0700 From: "David Christensen" To: "freebsd-net@freebsd.org" Date: Mon, 21 Jul 2008 10:36:36 -0700 Thread-Topic: Status of Multi-Queue (RSS) Support in -CURRENT Thread-Index: AcjrWFLU/Pg4Sj08Ro6yxrTIRUwiiA== Message-ID: <5D267A3F22FD854F8F48B3D2B52381932678025873@IRVEXCHCCR01.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jul 2008 17:35:46.0091 (UTC) FILETIME=[351EA7B0:01C8EB58] X-WSS-ID: 649A168A3D096736950-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Status of Multi-Queue (RSS) Support in -CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 17:36:13 -0000 I'm working on implementing multi-queue support for a 10Gb device on FreeBSD and I wanted to find out the current state of the OS with regards to supporting this. It seems that support for multiple receive queues can be done today since most of the routing is done in hardware but the transmit side is a different story. I've seen some things in the cxgb driver that suggest changes to the OS (such as a m_pkthdr.rss_hash field) but I don't see any OS code to back that usage model up. What's the state of the art in multi-queue support for FreeBSD? Dave From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 18:27:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 988B01065675; Mon, 21 Jul 2008 18:27:04 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (shrew.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 54E2B8FC08; Mon, 21 Jul 2008 18:27:04 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id E79E279E30E; Mon, 21 Jul 2008 13:27:03 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 67507-06; Mon, 21 Jul 2008 18:27:03 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id 91C2E79E307; Mon, 21 Jul 2008 13:27:03 -0500 (CDT) Received: from [10.22.200.30] ([10.22.200.30]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m6LIR0bq070726; Mon, 21 Jul 2008 13:27:00 -0500 (CDT) (envelope-from mgrooms@shrew.net) Message-ID: <4884D4F9.4050707@shrew.net> Date: Mon, 21 Jul 2008 13:27:05 -0500 From: Matthew Grooms User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: vanhu@freebsd.org, Sam Leffler References: <4884C28F.4020402@shrew.net> In-Reply-To: <4884C28F.4020402@shrew.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 18:27:04 -0000 On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote: > > After some more testing, I found another issue: in udp4_espdecap(), > when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should > not be discarded, but just returned for normal processing. > I noticed this too. But the only situation that I could think of where a valid ISAKMP packet will be smaller than this is a NAT-T keep-alive. These are handled previously in the code path so I don't think there is an issue from a functional standpoint. > And I also have doubts about a change in udp_ctloutput(), in the > switch statement which process optval and searches for an > UDP_ENCAP_ESPINUDP* flag. > > The way you changed it forces a flags cleanup anytime. > I don't see why someone would set both UDP_ENCAP_ESPINUDP and > UDP_ENCAP_ESPINUDP_NON_IKE, but as I was tracking down a problem, I > changed it again to be processed "the old way" to ensure it was not > the source of the issue. > It should be disallowed as in Sams patch. Allowing them to be mixed would cause problems using any of the patches I have seen. There is no way to distinguish between a Draft 00/01 ISAKMP packet and an RFC ESP packet without matching the port value to a SAD NAT-T mapping. And as you mentioned, I also don't see why anyone would try to set them both. There should never be a situation where you need to evaluate a NON-ESP NAT-T marker on an ISAKMP socket, only NON-ISAKMP markers. On a related note, I noticed the patch unconditionally uses a source port of 500 when processing outbound Draft 00/01 packets. Should this value be obtained from the SAD NAT-T mapping to support an IKE daemon bound to a non standard port? Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 19:16:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37E771065678 for ; Mon, 21 Jul 2008 19:16:39 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6F76C8FC0A for ; Mon, 21 Jul 2008 19:16:37 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from albator.zen.inc (unknown [192.168.1.5]) by smtp.zeninc.net (smtpd) with ESMTP id A8DA33F7B for ; Mon, 21 Jul 2008 21:16:35 +0200 (CEST) Received: by albator.zen.inc (Postfix, from userid 1000) id B9E5E73265; Mon, 21 Jul 2008 21:16:35 +0200 (CEST) Date: Mon, 21 Jul 2008 21:16:35 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20080721191635.GA2846@zen.inc> References: <4884C28F.4020402@shrew.net> <4884D4F9.4050707@shrew.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4884D4F9.4050707@shrew.net> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 19:16:39 -0000 On Mon, Jul 21, 2008 at 01:27:05PM -0500, Matthew Grooms wrote: > On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote: >> >> After some more testing, I found another issue: in udp4_espdecap(), >> when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should >> not be discarded, but just returned for normal processing. >> > > I noticed this too. But the only situation that I could think of where a > valid ISAKMP packet will be smaller than this is a NAT-T keep-alive. > These are handled previously in the code path so I don't think there is > an issue from a functional standpoint. That's what I also supposed when I noticed that, but I was tracking down a negociation problem (as an initiator, responder's first exchange in Main mode was seen on tcpdump but not on racoon's log), and it has been solved by fixing that part of the code.... [...] > It should be disallowed as in Sams patch. Allowing them to be mixed > would cause problems using any of the patches I have seen. There is no > way to distinguish between a Draft 00/01 ISAKMP packet and an RFC ESP > packet without matching the port value to a SAD NAT-T mapping. And as > you mentioned, I also don't see why anyone would try to set them both. > There should never be a situation where you need to evaluate a NON-ESP > NAT-T marker on an ISAKMP socket, only NON-ISAKMP markers. Yes. As I said, I was tracking down a problem on a gate which used to run for a long time with previous patches, so every difference was suspect for me :-) > On a related note, I noticed the patch unconditionally uses a source > port of 500 when processing outbound Draft 00/01 packets. Should this > value be obtained from the SAD NAT-T mapping to support an IKE daemon > bound to a non standard port? It should really really not happen..... but yes, it would be cleaner to get it from SAD than setting 500 anytime. Yvan. From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 19:30:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38C411065684; Mon, 21 Jul 2008 19:30:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id D7BC68FC16; Mon, 21 Jul 2008 19:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3984241C75B; Mon, 21 Jul 2008 21:30:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id n0RjyMe0HP8n; Mon, 21 Jul 2008 21:30:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id B717D41C6A1; Mon, 21 Jul 2008 21:30: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 BDC8644487F; Mon, 21 Jul 2008 19:26:40 +0000 (UTC) Date: Mon, 21 Jul 2008 19:26:40 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Sam Leffler In-Reply-To: <4884A956.5060108@freebsd.org> Message-ID: <20080721180626.V57089@maildrop.int.zabbadoz.net> References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> <20080721085325.B57089@maildrop.int.zabbadoz.net> <4884A956.5060108@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, vanhu_bsd@zeninc.net, Larry Baird Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 19:30:08 -0000 On Mon, 21 Jul 2008, Sam Leffler wrote: Hi Sam, >> We are still missing other things I think not mentioned elswhere like >> partial checksum recalculation. > > Please send me your specific issues; I haven't seen any comments about > "partial checksum recalculations". So what has kept you from reading the RFCs for the patch you were working on? "It works for me" does not mean "It's right and all done". /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 20:39:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B64171065682 for ; Mon, 21 Jul 2008 20:39:53 +0000 (UTC) (envelope-from rehsack@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.freebsd.org (Postfix) with ESMTP id 27EBB8FC18 for ; Mon, 21 Jul 2008 20:39:52 +0000 (UTC) (envelope-from rehsack@web.de) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate01.web.de (Postfix) with ESMTP id 91981E8E238F for ; Mon, 21 Jul 2008 22:39:51 +0200 (CEST) Received: from [87.149.238.94] (helo=waldorf.muppets.liwing.de) by smtp08.web.de with esmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1KL2Ah-0004OZ-00 for freebsd-net@freebsd.org; Mon, 21 Jul 2008 22:39:51 +0200 Message-ID: <4884F401.4050103@web.de> Date: Mon, 21 Jul 2008 20:39:29 +0000 From: Jens Rehsack User-Agent: Thunderbird 2.0.0.14 (X11/20080703) MIME-Version: 1.0 To: FreeBSD Net Content-Type: multipart/mixed; boundary="------------090500060505080409030307" Sender: rehsack@web.de X-Sender: rehsack@web.de X-Provags-ID: V01U2FsdGVkX19bu71dSQpFRC3V5yDVtFNclFDAANUwKg2PojR8 YC069RJ4bcragEiyCrgh3v+/4636EYCb7v8W69voQXRGoi29gZ OdvhosWrE= X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: lo0 not in ioctl( SIOCGIFCONF ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 20:39:53 -0000 This is a multi-part message in MIME format. --------------090500060505080409030307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, maybe this question is better asked in this list ... I was searching why ports/net/p5-Net-Interface was not working as expected and found some reasons. Most of them I can answer by implementing some test code as attached, but now I'm wondering why em0 is shown twice and lo0 is not included. The same situation on another machine .. --- BEGIN ifconfig -a (waldorf) em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:15:17:10:84:6c inet 10.62.10.3 netmask 0xffffff00 broadcast 10.62.10.255 media: Ethernet autoselect (100baseTX ) status: active em1: flags=8802 metric 0 mtu 1500 options=19b ether 00:15:17:10:84:6d media: Ethernet autoselect status: no carrier lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 --- END ifconfig -a (waldorf) ./netif em0 em0 em1 --- BEGIN ifconfig -a (STINGRAY) ifconfig -a fxp0: flags=8843 metric 0 mtu 1500 options=8 ether 00:a0:c9:ce:c8:64 inet 10.62.10.12 netmask 0xffffff00 broadcast 10.62.10.255 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8843 metric 0 mtu 1500 options=8 ether 00:a0:c9:ce:db:83 media: Ethernet autoselect (100baseTX ) status: active pflog0: flags=141 metric 0 mtu 33204 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 vlan0: flags=8843 metric 0 mtu 1500 ether 00:a0:c9:ce:db:83 media: Ethernet autoselect (100baseTX ) status: active vlan: 7 parent interface: fxp1 tun0: flags=8051 metric 0 mtu 1492 inet 87.149.231.190 --> 217.0.119.167 netmask 0xffffffff Opened by PID 27503 --- END ifconfig -a (STINGRAY) ./netif32 fxp0 fxp0 fxp1 Why aren't lo0, vlan0 and tun0 not included? What can I do to get these entries (portable way, please). Best regards, Jens --------------090500060505080409030307-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 20:47:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2170E106564A for ; Mon, 21 Jul 2008 20:47:42 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id EDACD8FC21 for ; Mon, 21 Jul 2008 20:47:40 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m6LKmKmI004752; Mon, 21 Jul 2008 15:48:20 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m6LKmKfO004751; Mon, 21 Jul 2008 15:48:20 -0500 (CDT) (envelope-from brooks) Date: Mon, 21 Jul 2008 15:48:20 -0500 From: Brooks Davis To: Jens Rehsack Message-ID: <20080721204820.GE1699@lor.one-eyed-alien.net> References: <4884F401.4050103@web.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VdOwlNaOFKGAtAAV" Content-Disposition: inline In-Reply-To: <4884F401.4050103@web.de> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Net Subject: Re: lo0 not in ioctl( SIOCGIFCONF ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 20:47:42 -0000 --VdOwlNaOFKGAtAAV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Hi, >=20 > maybe this question is better asked in this list ... >=20 > I was searching why ports/net/p5-Net-Interface was not working as > expected and found some reasons. Most of them I can answer by implementing > some test code as attached, but now I'm wondering why em0 is shown twice > and lo0 is not included. > The same situation on another machine .. The attachment didn't make it through. -- Brooks On Mon, Jul 21, 2008 at 08:39:29PM +0000, Jens Rehsack wrote: >=20 > --- BEGIN ifconfig -a (waldorf) > em0: flags=3D8843 metric 0 mtu 15= 00 > options=3D19b > ether 00:15:17:10:84:6c > inet 10.62.10.3 netmask 0xffffff00 broadcast 10.62.10.255 > media: Ethernet autoselect (100baseTX ) > status: active > em1: flags=3D8802 metric 0 mtu 1500 > options=3D19b > ether 00:15:17:10:84:6d > media: Ethernet autoselect > status: no carrier > lo0: flags=3D8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > --- END ifconfig -a (waldorf) > ./netif > em0 > em0 > em1 >=20 > --- BEGIN ifconfig -a (STINGRAY) > ifconfig -a > fxp0: flags=3D8843 metric 0 mtu 1= 500 > options=3D8 > ether 00:a0:c9:ce:c8:64 > inet 10.62.10.12 netmask 0xffffff00 broadcast 10.62.10.255 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=3D8843 metric 0 mtu 1= 500 > options=3D8 > ether 00:a0:c9:ce:db:83 > media: Ethernet autoselect (100baseTX ) > status: active > pflog0: flags=3D141 metric 0 mtu 33204 > lo0: flags=3D8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > vlan0: flags=3D8843 metric 0 mtu = 1500 > ether 00:a0:c9:ce:db:83 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 7 parent interface: fxp1 > tun0: flags=3D8051 metric 0 mtu 1492 > inet 87.149.231.190 --> 217.0.119.167 netmask 0xffffffff > Opened by PID 27503 > --- END ifconfig -a (STINGRAY) > ./netif32 > fxp0 > fxp0 > fxp1 >=20 > Why aren't lo0, vlan0 and tun0 not included? What can I do to get these > entries (portable way, please). >=20 > Best regards, > Jens >=20 >=20 > _______________________________________________ > 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" --VdOwlNaOFKGAtAAV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIhPYUXY6L6fI4GtQRAi3/AJ0cUNkiQBo0+UTqikNlCJoIq2VMrwCdHJCT WUebNOrE/K/6Ds5bZ8CDuaI= =0/kM -----END PGP SIGNATURE----- --VdOwlNaOFKGAtAAV-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 21:27:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C469A1065671 for ; Mon, 21 Jul 2008 21:27:15 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 8D04F8FC1B for ; Mon, 21 Jul 2008 21:27:15 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so1820657rvf.43 for ; Mon, 21 Jul 2008 14:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2Xv53JrgjmNth5tSvc0BW2XbmPhGrLntskigZGBKLHo=; b=kqBWlmCOtLiM3E7J2fQtMYN1puxPqxRlu6/P30FvHG6mFsN7nmPXQy4R6qGTpv8VfD 1qlaBQQRAvmTpm8A6Cz9DQpGTFKv5tK7U0x7npu5Zo+FlISJMSgtQcr+c5hSeT6zjnda vC2rXjYgg5N9wreQVgKtODJhr1CeEqWnyksRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DIx2VMmCbD1Wxm8/lehaze7biwGTJdvBm2DMQFrPj7gkN1ZsUAlD9VphnbGM3TKtKi LnQy3c089uF3HodDzm6iAKHJDYsZW9G+M8YCCIp3xrKBFMS3Nf+bcXGl4tmIrPg2DpzC AVY6KWv4D2unQucZbSfIRsYTM2o5PohOYTRes= Received: by 10.141.115.6 with SMTP id s6mr2091976rvm.224.1216675635152; Mon, 21 Jul 2008 14:27:15 -0700 (PDT) Received: by 10.141.123.2 with HTTP; Mon, 21 Jul 2008 14:27:15 -0700 (PDT) Message-ID: Date: Mon, 21 Jul 2008 14:27:15 -0700 From: "Kip Macy" To: "David Christensen" In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381932678025873@IRVEXCHCCR01.corp.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D267A3F22FD854F8F48B3D2B52381932678025873@IRVEXCHCCR01.corp.ad.broadcom.com> Cc: "freebsd-net@freebsd.org" Subject: Re: Status of Multi-Queue (RSS) Support in -CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 21:27:15 -0000 On Mon, Jul 21, 2008 at 10:36 AM, David Christensen wrote: > I'm working on implementing multi-queue support for a 10Gb > device on FreeBSD and I wanted to find out the current state > of the OS with regards to supporting this. It seems that > support for multiple receive queues can be done today since > most of the routing is done in hardware but the transmit > side is a different story. I've seen some things in the > cxgb driver that suggest changes to the OS (such as a > m_pkthdr.rss_hash field) but I don't see any OS code to > back that usage model up. What's the state of the art > in multi-queue support for FreeBSD? Unfortunately nothing has gone in yet. Robert has a prototype interface and I *think* that he may have come around to accepting my approach. The right way to integrate QoS and multi-queue cleanly isn't 100% obvious. I think it isn't unreasonable to expect that the new interfaces will go in in time for 7.2 but 7.1 is basically impossible at this point given that the freeze will be happening in the next month. Thanks, Kip From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 21:31:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81A73106566B for ; Mon, 21 Jul 2008 21:31:03 +0000 (UTC) (envelope-from rehsack@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.freebsd.org (Postfix) with ESMTP id 367598FC14 for ; Mon, 21 Jul 2008 21:31:03 +0000 (UTC) (envelope-from rehsack@web.de) Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate01.web.de (Postfix) with ESMTP id 4D0FDE8E1CDB; Mon, 21 Jul 2008 23:31:02 +0200 (CEST) Received: from [87.149.238.94] (helo=waldorf.muppets.liwing.de) by smtp06.web.de with esmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1KL2yD-0000WE-00; Mon, 21 Jul 2008 23:31:01 +0200 Message-ID: <4884FFFF.9090908@web.de> Date: Mon, 21 Jul 2008 21:30:39 +0000 From: Jens Rehsack User-Agent: Thunderbird 2.0.0.14 (X11/20080703) MIME-Version: 1.0 To: Brooks Davis References: <4884F401.4050103@web.de> <20080721204820.GE1699@lor.one-eyed-alien.net> In-Reply-To: <20080721204820.GE1699@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: rehsack@web.de X-Sender: rehsack@web.de X-Provags-ID: V01U2FsdGVkX1/G6Fp/9rh5WPFd7QisvRe1SrH26ieRZ1Hxvxud 2ys5p/jfr/iV46iiDPZv47U8ofNrI+klq3HWjqgs4UDl1wplKL OSmbUESrU= Cc: FreeBSD Net Subject: Re: lo0 not in ioctl( SIOCGIFCONF ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 21:31:03 -0000 Brooks Davis wrote: >> Hi, >> >> maybe this question is better asked in this list ... >> >> I was searching why ports/net/p5-Net-Interface was not working as >> expected and found some reasons. Most of them I can answer by implementing >> some test code as attached, but now I'm wondering why em0 is shown twice >> and lo0 is not included. >> The same situation on another machine .. > > The attachment didn't make it through. > > -- Brooks Copy&Paste starts here ... #include #include #include #include #include #include #include #include #ifndef _SIZEOF_ADDR_IFREQ #define _SIZEOF_ADDR_IFREQ(ifr) \ ((ifr).ifr_addr.sa_len > sizeof(struct sockaddr) ? \ (sizeof(struct ifreq) - sizeof(struct sockaddr) + \ (ifr).ifr_addr.sa_len) : sizeof(struct ifreq)) #endif int main() { struct ifconf ifc; struct ifreq *ifr, *lifr; int fd; unsigned int n; fd = socket( AF_INET, SOCK_STREAM, 0 ); bzero(&ifc, sizeof(ifc)); n = 3; ifr = calloc( ifc.ifc_len, sizeof(*ifr) ); do { n *= 2; ifr = realloc( ifr, sizeof(*ifr) * n ); bzero( ifr, sizeof(*ifr) * n ); ifc.ifc_req = ifr; ifc.ifc_len = n * sizeof(*ifr); } while( ( ioctl( fd, SIOCGIFCONF, &ifc ) == -1 ) || ( ifc.ifc_len == n * sizeof(*ifr)) ); lifr = (struct ifreq *)&ifc.ifc_buf[ifc.ifc_len]; while (ifr < lifr) { printf( "%s\n", ifr->ifr_name ); ifr = (struct ifreq *)(((char *)ifr) + _SIZEOF_ADDR_IFREQ(*ifr)); } return 0; } From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 22:23:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5966D1065678 for ; Mon, 21 Jul 2008 22:23:37 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id CB9778FC16 for ; Mon, 21 Jul 2008 22:23:36 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m6LMOGha005479; Mon, 21 Jul 2008 17:24:16 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m6LMOGKQ005478; Mon, 21 Jul 2008 17:24:16 -0500 (CDT) (envelope-from brooks) Date: Mon, 21 Jul 2008 17:24:16 -0500 From: Brooks Davis To: Jens Rehsack Message-ID: <20080721222416.GG1699@lor.one-eyed-alien.net> References: <4884F401.4050103@web.de> <20080721204820.GE1699@lor.one-eyed-alien.net> <4884FFFF.9090908@web.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y+xroYBkGM9OatJL" Content-Disposition: inline In-Reply-To: <4884FFFF.9090908@web.de> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Net Subject: Re: lo0 not in ioctl( SIOCGIFCONF ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 22:23:37 -0000 --Y+xroYBkGM9OatJL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2008 at 09:30:39PM +0000, Jens Rehsack wrote: > Brooks Davis wrote: >>> Hi, >>>=20 >>> maybe this question is better asked in this list ... >>>=20 >>> I was searching why ports/net/p5-Net-Interface was not working as >>> expected and found some reasons. Most of them I can answer by implement= ing >>> some test code as attached, but now I'm wondering why em0 is shown twice >>> and lo0 is not included. >>> The same situation on another machine .. >>=20 >> The attachment didn't make it through. >>=20 >> -- Brooks >=20 > Copy&Paste starts here ... > #include > #include > #include > #include > #include > #include > #include > #include >=20 > #ifndef _SIZEOF_ADDR_IFREQ > #define _SIZEOF_ADDR_IFREQ(ifr) \ > ((ifr).ifr_addr.sa_len > sizeof(struct sockaddr) ? \ > (sizeof(struct ifreq) - sizeof(struct sockaddr) + \ > (ifr).ifr_addr.sa_len) : sizeof(struct ifreq)) > #endif >=20 > int > main() > { > struct ifconf ifc; > struct ifreq *ifr, *lifr; > int fd; > unsigned int n; >=20 > fd =3D socket( AF_INET, SOCK_STREAM, 0 ); > bzero(&ifc, sizeof(ifc)); > n =3D 3; > ifr =3D calloc( ifc.ifc_len, sizeof(*ifr) ); > do > { > n *=3D 2; > ifr =3D realloc( ifr, sizeof(*ifr) * n ); > bzero( ifr, sizeof(*ifr) * n ); > ifc.ifc_req =3D ifr; > ifc.ifc_len =3D n * sizeof(*ifr); > } while( ( ioctl( fd, SIOCGIFCONF, &ifc ) =3D=3D -1 ) || ( ifc.if= c_len=20 > =3D=3D n * sizeof(*ifr)) ); There are several problems with this loop. First, icoctl won't return an error in the overflow case because that's not how SIOCGIFCONF works. SIOCGIFCONF is badly designed in a number of ways, but that's how it is. Second, checking that the array is completely full isn't at all reliable because what is returned is actually ifreq structures which might or might not vary in length as they contain addresses. Thus you need <=3D. Third, you should start by allocating a significant amount of space. Yes, your algorithm is O(sqrt(n)), but allocating a larger value has effectively no cost so you might as well save some system calls on average. > lifr =3D (struct ifreq *)&ifc.ifc_buf[ifc.ifc_len]; > > while (ifr < lifr) > { > printf( "%s\n", ifr->ifr_name ); > ifr =3D (struct ifreq *)(((char *)ifr) + _SIZEOF_ADDR_IFREQ(*ifr)= ); > } This loop has two problems. First, the ifr's are variable length so you immediately go off into the weeds. Second, there is at least one per interface and one per address so you to keep track of the last interface name and not repeat them. -- Brooks >=20 > return 0; > } > _______________________________________________ > 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" >=20 --Y+xroYBkGM9OatJL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIhQyQXY6L6fI4GtQRAoifAJ46MILVTny+Nd4S8sUcQ8CcJjrw0gCfRnQV F1kAkRd2NHvWg6uLiVfSNpg= =91SQ -----END PGP SIGNATURE----- --Y+xroYBkGM9OatJL-- From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 22:37:48 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E958106564A; Mon, 21 Jul 2008 22:37:48 +0000 (UTC) (envelope-from rehsack@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.freebsd.org (Postfix) with ESMTP id AD23C8FC16; Mon, 21 Jul 2008 22:37:47 +0000 (UTC) (envelope-from rehsack@web.de) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate02.web.de (Postfix) with ESMTP id 5CA60E6AF2AF; Tue, 22 Jul 2008 00:36:56 +0200 (CEST) Received: from [87.149.238.94] (helo=waldorf.muppets.liwing.de) by smtp08.web.de with esmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1KL400-00024s-00; Tue, 22 Jul 2008 00:36:56 +0200 Message-ID: <48850F72.90204@web.de> Date: Mon, 21 Jul 2008 22:36:34 +0000 From: Jens Rehsack User-Agent: Thunderbird 2.0.0.14 (X11/20080703) MIME-Version: 1.0 To: Brooks Davis References: <4884F401.4050103@web.de> <20080721204820.GE1699@lor.one-eyed-alien.net> <4884FFFF.9090908@web.de> <20080721222416.GG1699@lor.one-eyed-alien.net> In-Reply-To: <20080721222416.GG1699@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: rehsack@web.de X-Sender: rehsack@web.de X-Provags-ID: V01U2FsdGVkX19cVSb72bhnq2LlCXeug4W2Hiz0y7l631i6o9Zg kQHCzE+2oRsuA7LkQ2DKOA3TZtD37dKv9hl3DWJXOcNxvgUQNY H2wrvydn0= Cc: FreeBSD Net Subject: Re: lo0 not in ioctl( SIOCGIFCONF ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 22:37:48 -0000 Brooks Davis wrote: > On Mon, Jul 21, 2008 at 09:30:39PM +0000, Jens Rehsack wrote: >> Brooks Davis wrote: >>>> Hi, >>>> >>>> maybe this question is better asked in this list ... >>>> >>>> I was searching why ports/net/p5-Net-Interface was not working as >>>> expected and found some reasons. Most of them I can answer by implementing >>>> some test code as attached, but now I'm wondering why em0 is shown twice >>>> and lo0 is not included. >>>> The same situation on another machine .. >>> The attachment didn't make it through. >>> >>> -- Brooks >> Copy&Paste starts here ... >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> #ifndef _SIZEOF_ADDR_IFREQ >> #define _SIZEOF_ADDR_IFREQ(ifr) \ >> ((ifr).ifr_addr.sa_len > sizeof(struct sockaddr) ? \ >> (sizeof(struct ifreq) - sizeof(struct sockaddr) + \ >> (ifr).ifr_addr.sa_len) : sizeof(struct ifreq)) >> #endif >> >> int >> main() >> { >> struct ifconf ifc; >> struct ifreq *ifr, *lifr; >> int fd; >> unsigned int n; >> >> fd = socket( AF_INET, SOCK_STREAM, 0 ); >> bzero(&ifc, sizeof(ifc)); >> n = 3; >> ifr = calloc( ifc.ifc_len, sizeof(*ifr) ); >> do >> { >> n *= 2; >> ifr = realloc( ifr, sizeof(*ifr) * n ); >> bzero( ifr, sizeof(*ifr) * n ); >> ifc.ifc_req = ifr; >> ifc.ifc_len = n * sizeof(*ifr); >> } while( ( ioctl( fd, SIOCGIFCONF, &ifc ) == -1 ) || ( ifc.ifc_len >> == n * sizeof(*ifr)) ); > > There are several problems with this loop. First, icoctl won't return > an error in the overflow case because that's not how SIOCGIFCONF works. > SIOCGIFCONF is badly designed in a number of ways, but that's how it > is. Second, checking that the array is completely full isn't at all > reliable because what is returned is actually ifreq structures which > might or might not vary in length as they contain addresses. Thus you > need <=. Third, you should start by allocating a significant amount of > space. Yes, your algorithm is O(sqrt(n)), but allocating a larger > value has effectively no cost so you might as well save some system calls > on average. Thanks - that was the information I miss. I'll try tomorrow (it's slightly late here) and send back the result. Using <= should produce an endless loop, but maybe checking if ifc.ifc_len <= (n/2) * sizeof(*ifr) could bring wanted results ... >> lifr = (struct ifreq *)&ifc.ifc_buf[ifc.ifc_len]; >> >> while (ifr < lifr) > { >> printf( "%s\n", ifr->ifr_name ); >> ifr = (struct ifreq *)(((char *)ifr) + _SIZEOF_ADDR_IFREQ(*ifr)); >> } > > This loop has two problems. First, the ifr's are variable length so you > immediately go off into the weeds. The _SIZEOF_ADDR_IFREQ macro should handle that correctly, shouldn't it? > Second, there is at least one per > interface and one per address so you to keep track of the last interface > name and not repeat them. Good point - if it's sure in this order, this is a good way to handle it. > -- Brooks /Jens From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 22:45:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19BAD1065672 for ; Mon, 21 Jul 2008 22:45:39 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 874348FC12 for ; Mon, 21 Jul 2008 22:45:38 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m6LMkIgJ005701; Mon, 21 Jul 2008 17:46:18 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m6LMkI2W005700; Mon, 21 Jul 2008 17:46:18 -0500 (CDT) (envelope-from brooks) Date: Mon, 21 Jul 2008 17:46:18 -0500 From: Brooks Davis To: Jens Rehsack Message-ID: <20080721224618.GH1699@lor.one-eyed-alien.net> References: <4884F401.4050103@web.de> <20080721204820.GE1699@lor.one-eyed-alien.net> <4884FFFF.9090908@web.de> <20080721222416.GG1699@lor.one-eyed-alien.net> <48850F72.90204@web.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8sldprk+5E/pDEv" Content-Disposition: inline In-Reply-To: <48850F72.90204@web.de> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Net Subject: Re: lo0 not in ioctl( SIOCGIFCONF ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 22:45:39 -0000 --a8sldprk+5E/pDEv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 21, 2008 at 10:36:34PM +0000, Jens Rehsack wrote: > Brooks Davis wrote: >> On Mon, Jul 21, 2008 at 09:30:39PM +0000, Jens Rehsack wrote: >>> Brooks Davis wrote: >>>>> Hi, >>>>>=20 >>>>> maybe this question is better asked in this list ... >>>>>=20 >>>>> I was searching why ports/net/p5-Net-Interface was not working as >>>>> expected and found some reasons. Most of them I can answer by impleme= nting >>>>> some test code as attached, but now I'm wondering why em0 is shown tw= ice >>>>> and lo0 is not included. >>>>> The same situation on another machine .. >>>> The attachment didn't make it through. >>>>=20 >>>> -- Brooks >>> Copy&Paste starts here ... >>> #include >>> #include >>> #include >>> #include >>> #include >>> #include >>> #include >>> #include >>>=20 >>> #ifndef _SIZEOF_ADDR_IFREQ >>> #define _SIZEOF_ADDR_IFREQ(ifr) \ >>> ((ifr).ifr_addr.sa_len > sizeof(struct sockaddr) ? \ >>> (sizeof(struct ifreq) - sizeof(struct sockaddr) + \ >>> (ifr).ifr_addr.sa_len) : sizeof(struct ifreq)) >>> #endif >>>=20 >>> int >>> main() >>> { >>> struct ifconf ifc; >>> struct ifreq *ifr, *lifr; >>> int fd; >>> unsigned int n; >>>=20 >>> fd =3D socket( AF_INET, SOCK_STREAM, 0 ); >>> bzero(&ifc, sizeof(ifc)); >>> n =3D 3; >>> ifr =3D calloc( ifc.ifc_len, sizeof(*ifr) ); >>> do >>> { >>> n *=3D 2; >>> ifr =3D realloc( ifr, sizeof(*ifr) * n ); >>> bzero( ifr, sizeof(*ifr) * n ); >>> ifc.ifc_req =3D ifr; >>> ifc.ifc_len =3D n * sizeof(*ifr); >>> } while( ( ioctl( fd, SIOCGIFCONF, &ifc ) =3D=3D -1 ) || (=20 >>> ifc.ifc_len =3D=3D n * sizeof(*ifr)) ); >>=20 >> There are several problems with this loop. First, icoctl won't return >> an error in the overflow case because that's not how SIOCGIFCONF works. >> SIOCGIFCONF is badly designed in a number of ways, but that's how it >> is. Second, checking that the array is completely full isn't at all >> reliable because what is returned is actually ifreq structures which >> might or might not vary in length as they contain addresses. Thus you >> need <=3D. Third, you should start by allocating a significant amount of >> space. Yes, your algorithm is O(sqrt(n)), but allocating a larger >> value has effectively no cost so you might as well save some system calls >> on average. >=20 > Thanks - that was the information I miss. I'll try tomorrow (it's slightl= y=20 > late here) and send back the result. > Using <=3D should produce an endless loop, but maybe checking if ifc.ifc_= len=20 > <=3D (n/2) * sizeof(*ifr) could bring wanted results ... Oops, you're right. Actually, the condition to check is probably (n*sizeof(*ifr) - ifc.ifc_len < sizeof(*ifr)). Actually, since the size of the returned values aren't actually a multiple of sizeof(*ifr), I'd probably switch to allocating a multiple of 4k. >>> lifr =3D (struct ifreq *)&ifc.ifc_buf[ifc.ifc_len]; >>>=20 >>> while (ifr < lifr) > { >>> printf( "%s\n", ifr->ifr_name ); >>> ifr =3D (struct ifreq *)(((char *)ifr) + _SIZEOF_ADDR_IFREQ(*if= r)); >>> } >>=20 >> This loop has two problems. First, the ifr's are variable length so you >> immediately go off into the weeds. >=20 > The _SIZEOF_ADDR_IFREQ macro should handle that correctly, shouldn't it? Right here as well. >> Second, there is at least one per >> interface and one per address so you to keep track of the last interface >> name and not repeat them. >=20 > Good point - if it's sure in this order, this is a good way to handle it. It is in the current implementation and it's hard to imaging that we'd break that. -- Brooks >> -- Brooks >=20 > /Jens >=20 --a8sldprk+5E/pDEv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIhRG5XY6L6fI4GtQRAl1OAJ9/invMMLU4Ciuqk1VyV1U6z+m5zgCeIr+i 7tpMuvd086cG1D5KmdwIVH4= =uCUk -----END PGP SIGNATURE----- --a8sldprk+5E/pDEv-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 00:03:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C58C41065676; Tue, 22 Jul 2008 00:03:24 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (shrew.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 92A3F8FC15; Tue, 22 Jul 2008 00:03:24 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id 7987B79E30E; Mon, 21 Jul 2008 19:03:24 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 87696-08; Tue, 22 Jul 2008 00:03:23 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id 7D50779E307; Mon, 21 Jul 2008 19:03:23 -0500 (CDT) Received: from [10.22.200.30] ([10.22.200.30]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m6M03LT8072777; Mon, 21 Jul 2008 19:03:21 -0500 (CDT) (envelope-from mgrooms@shrew.net) Message-ID: <488523D0.30300@shrew.net> Date: Mon, 21 Jul 2008 19:03:28 -0500 From: Matthew Grooms User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: vanhu@freebsd.org References: <488515FF.2020309@shrew.net> <48851B00.1060600@shrew.net> In-Reply-To: <48851B00.1060600@shrew.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 00:03:24 -0000 > > I noticed this too. But the only situation that I could think of where a > > valid ISAKMP packet will be smaller than this is a NAT-T keep-alive. > > These are handled previously in the code path so I don't think there is > > an issue from a functional standpoint. > > That's what I also supposed when I noticed that, but I was tracking > down a negotiation problem (as an initiator, responder's first > exchange in Main mode was seen on tcpdump but not on racoon's log), > and it has been solved by fixing that part of the code.... > Sounds reasonable. > > On a related note, I noticed the patch unconditionally uses a source > > port of 500 when processing outbound Draft 00/01 packets. Should this > > value be obtained from the SAD NAT-T mapping to support an IKE daemon > > bound to a non standard port? > > It should really really not happen..... but yes, it would be cleaner > to get it from SAD than setting 500 anytime. > Well, its really really supported by all the IKE daemons I have seen in the ports collection. Someone is bound to try this and then spend a lot of time scratching their head. If this situation can be easily avoided, it should be. -Matthew From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 00:55:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A656F106566C; Tue, 22 Jul 2008 00:55:22 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (shrew.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 73C778FC0C; Tue, 22 Jul 2008 00:55:22 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id A651B79E30E; Mon, 21 Jul 2008 19:55:22 -0500 (CDT) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 09928-07; Tue, 22 Jul 2008 00:55:22 +0000 (UTC) Received: from hole.shrew.net (cpe-70-113-206-103.austin.res.rr.com [70.113.206.103]) by shrew.net (Postfix) with ESMTP id 3D8B779E307; Mon, 21 Jul 2008 19:55:22 -0500 (CDT) Received: from [10.22.200.30] ([10.22.200.30]) by hole.shrew.net (8.14.2/8.14.2) with ESMTP id m6M0tK3w073079; Mon, 21 Jul 2008 19:55:20 -0500 (CDT) (envelope-from mgrooms@shrew.net) Message-ID: <48853000.9060902@shrew.net> Date: Mon, 21 Jul 2008 19:55:28 -0500 From: Matthew Grooms User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sam Leffler References: <488525A4.2090707@shrew.net> In-Reply-To: <488525A4.2090707@shrew.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 00:55:22 -0000 > > We are still missing other things I think not mentioned elswhere like > > partial checksum recalculation. > > Please send me your specific issues; I haven't seen any comments about > "partial checksum recalculations". > I've never heard of this term used before with regard to NAT-T ( and neither has google ). He must be referring to section 3.1.2 of RFC 3948 "Transport Mode Decapsulation NAT Procedure" which describes checksum recalculation. -Matthew From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 02:37:24 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAAB01065674; Tue, 22 Jul 2008 02:37:24 +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 975A18FC13; Tue, 22 Jul 2008 02:37:24 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6M2bO3S018213; Tue, 22 Jul 2008 02:37:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6M2bO4R018209; Tue, 22 Jul 2008 02:37:24 GMT (envelope-from linimon) Date: Tue, 22 Jul 2008 02:37:24 GMT Message-Id: <200807220237.m6M2bO4R018209@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/125845: [netinet] [patch] tcp_lro_rx() should make use of hardware IP cksum assistance when available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 02:37:24 -0000 Old Synopsis: tcp_lro_rx() should make use of hardware IP cksum assistance when available New Synopsis: [netinet] [patch] tcp_lro_rx() should make use of hardware IP cksum assistance when available Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jul 22 02:37:07 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125845 From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 07:16:48 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A50441065679; Tue, 22 Jul 2008 07:16:48 +0000 (UTC) (envelope-from rehsack@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.freebsd.org (Postfix) with ESMTP id 31C528FC20; Tue, 22 Jul 2008 07:16:47 +0000 (UTC) (envelope-from rehsack@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate02.web.de (Postfix) with ESMTP id B7874E6B53BD; Tue, 22 Jul 2008 09:16:46 +0200 (CEST) Received: from [87.149.238.59] (helo=waldorf.muppets.liwing.de) by smtp05.web.de with esmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1KLC74-0001Hj-00; Tue, 22 Jul 2008 09:16:46 +0200 Message-ID: <48858948.9020403@web.de> Date: Tue, 22 Jul 2008 07:16:24 +0000 From: Jens Rehsack User-Agent: Thunderbird 2.0.0.14 (X11/20080703) MIME-Version: 1.0 To: Brooks Davis References: <4884F401.4050103@web.de> <20080721204820.GE1699@lor.one-eyed-alien.net> <4884FFFF.9090908@web.de> <20080721222416.GG1699@lor.one-eyed-alien.net> <48850F72.90204@web.de> <20080721224618.GH1699@lor.one-eyed-alien.net> In-Reply-To: <20080721224618.GH1699@lor.one-eyed-alien.net> Content-Type: multipart/mixed; boundary="------------050202000507030102060902" Sender: rehsack@web.de X-Sender: rehsack@web.de X-Provags-ID: V01U2FsdGVkX19c5FGype9FmIOxGiRGqw/C7U3jblmBY27iB7i6 YuMfpn7jFO0MjddkLyFTxMIqltJQZfthE3ennQLRIsSJLq3H4P vrnP1ydgM= X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net Subject: Re: SOLVED: lo0 not in ioctl( SIOCGIFCONF ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 07:16:48 -0000 This is a multi-part message in MIME format. --------------050202000507030102060902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brooks Davis wrote: > On Mon, Jul 21, 2008 at 10:36:34PM +0000, Jens Rehsack wrote: >> Brooks Davis wrote: >>> On Mon, Jul 21, 2008 at 09:30:39PM +0000, Jens Rehsack wrote: >>>> Brooks Davis wrote: >>>>>> Hi, >>>>>> >>>>>> maybe this question is better asked in this list ... >>>>>> >>>>>> I was searching why ports/net/p5-Net-Interface was not working as >>>>>> expected and found some reasons. Most of them I can answer by implementing >>>>>> some test code as attached, but now I'm wondering why em0 is shown twice >>>>>> and lo0 is not included. >>>>>> The same situation on another machine .. >>>>> The attachment didn't make it through. >>>>> >>>>> -- Brooks >>>> Copy&Paste starts here ... >>>> #include >>>> #include >>>> #include >>>> #include >>>> #include >>>> #include >>>> #include >>>> #include >>>> >>>> #ifndef _SIZEOF_ADDR_IFREQ >>>> #define _SIZEOF_ADDR_IFREQ(ifr) \ >>>> ((ifr).ifr_addr.sa_len > sizeof(struct sockaddr) ? \ >>>> (sizeof(struct ifreq) - sizeof(struct sockaddr) + \ >>>> (ifr).ifr_addr.sa_len) : sizeof(struct ifreq)) >>>> #endif >>>> >>>> int >>>> main() >>>> { >>>> struct ifconf ifc; >>>> struct ifreq *ifr, *lifr; >>>> int fd; >>>> unsigned int n; >>>> >>>> fd = socket( AF_INET, SOCK_STREAM, 0 ); >>>> bzero(&ifc, sizeof(ifc)); >>>> n = 3; >>>> ifr = calloc( ifc.ifc_len, sizeof(*ifr) ); >>>> do >>>> { >>>> n *= 2; >>>> ifr = realloc( ifr, sizeof(*ifr) * n ); >>>> bzero( ifr, sizeof(*ifr) * n ); >>>> ifc.ifc_req = ifr; >>>> ifc.ifc_len = n * sizeof(*ifr); >>>> } while( ( ioctl( fd, SIOCGIFCONF, &ifc ) == -1 ) || ( >>>> ifc.ifc_len == n * sizeof(*ifr)) ); >>> There are several problems with this loop. First, icoctl won't return >>> an error in the overflow case because that's not how SIOCGIFCONF works. >>> SIOCGIFCONF is badly designed in a number of ways, but that's how it >>> is. Second, checking that the array is completely full isn't at all >>> reliable because what is returned is actually ifreq structures which >>> might or might not vary in length as they contain addresses. Thus you >>> need <=. Third, you should start by allocating a significant amount of >>> space. Yes, your algorithm is O(sqrt(n)), but allocating a larger >>> value has effectively no cost so you might as well save some system calls >>> on average. >> Thanks - that was the information I miss. I'll try tomorrow (it's slightly >> late here) and send back the result. >> Using <= should produce an endless loop, but maybe checking if ifc.ifc_len >> <= (n/2) * sizeof(*ifr) could bring wanted results ... > > Oops, you're right. Actually, the condition to check is probably > (n*sizeof(*ifr) - ifc.ifc_len < sizeof(*ifr)). Actually, since the size > of the returned values aren't actually a multiple of sizeof(*ifr), I'd > probably switch to allocating a multiple of 4k. Actually, because there're very different sizes of sockaddr's (sockaddr_in, sockaddr_in6, ...), I require at least a page must be left over. Because of other OS may support return of errors in overflow, I didn't remove the check - finally it must run on AIX, Windows and Linux, too. >>>> lifr = (struct ifreq *)&ifc.ifc_buf[ifc.ifc_len]; >>>> >>>> while (ifr < lifr) > { >>>> printf( "%s\n", ifr->ifr_name ); >>>> ifr = (struct ifreq *)(((char *)ifr) + _SIZEOF_ADDR_IFREQ(*ifr)); >>>> } >>> This loop has two problems. First, the ifr's are variable length so you >>> immediately go off into the weeds. >> The _SIZEOF_ADDR_IFREQ macro should handle that correctly, shouldn't it? > > Right here as well. Finally - I must enhance this using SA_LEN if available to support systems without sa_len member support. I'll try it in office with our linux machines there, because I don't have any penguins at home ;) >>> Second, there is at least one per >>> interface and one per address so you to keep track of the last interface >>> name and not repeat them. >> Good point - if it's sure in this order, this is a good way to handle it. > > It is in the current implementation and it's hard to imaging that we'd > break that. By the way, because I'm looking for interfaces, I skip everything which is no AF_LINK - should work, too (and does for my test-machines ...). Final question: would it make sense to submit a patch against ports/net/p5-Net-Interface using this knowledge to unbreak the port, or must I submit the patch to CPAN and hope, that it will be committed fastly? /Jens --------------050202000507030102060902-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 09:52:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 550B3106567C for ; Tue, 22 Jul 2008 09:52:35 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 033548FC1A for ; Tue, 22 Jul 2008 09:52:34 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 006B53F7B; Tue, 22 Jul 2008 11:52:30 +0200 (CEST) Date: Tue, 22 Jul 2008 11:52:30 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20080722095230.GA14962@zen.inc> References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> <20080721083110.GA21786@zen.inc> <20080721141327.GA24677@zen.inc> <4884AC65.7020605@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4884AC65.7020605@freebsd.org> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 09:52:35 -0000 On Mon, Jul 21, 2008 at 08:33:57AM -0700, Sam Leffler wrote: > VANHULLEBUS Yvan wrote: [....] > >After some more testing, I found another issue: in udp4_espdecap(), > >when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should > >not be discarded, but just returned for normal processing. > > > > Please edit the sam_nat_t branch in p4 or send a patch I can apply. As Perforce is really really new for me, here is the patch: --- sys/netinet/udp_usrreq.c Tue Jul 22 11:04:30 2008 +++ sys/netinet/udp_usrreq.c Mon Jul 21 21:30:52 2008 @@ -797,8 +797,8 @@ udp_ctloutput(struct socket *so, struct if (INP_CHECK_SOCKAF(so, AF_INET6)) { INP_WUNLOCK(inp); error = ip6_ctloutput(so, sopt); -#endif } else { +#endif INP_WUNLOCK(inp); error = ip_ctloutput(so, sopt); #ifdef INET6 @@ -846,7 +846,9 @@ udp_ctloutput(struct socket *so, struct case SOPT_GET: switch (sopt->sopt_name) { case UDP_ENCAP: +#ifdef IPSEC_NAT_T optval = inp->inp_flags & INP_ESPINUDP_ALL; +#endif INP_WUNLOCK(inp); error = sooptcopyout(sopt, &optval, sizeof optval); break; @@ -1236,11 +1238,9 @@ udp4_espdecap(struct socket *so, struct } else { uint64_t marker; - if (payload <= sizeof(uint64_t) + sizeof(struct esp)) { - udpstat.udps_hdrops++; /* XXX? */ - m_freem(m); - return NULL; /* discard */ - } + if (payload <= sizeof(uint64_t) + sizeof(struct esp)) + return m; /* NB: no decap */ + bcopy(data + off, &marker, sizeof(uint64_t)); if (marker != 0) return m; /* NB: no decap */ <<< end of diff There is an extra #ifdef, which I noticed yesterday when I tried to compile using a wrong kernel conf file (without NAT_T support). [...] > The original code from you permitted both flags to be set but the code > that handled the encap/decap assumed only one was set. > > >Sam, did you have a good reason to change that part of the code, or > >was it mostly to have a more compliant coding style ? > > See above. Ok, removed from my sources ang got back to your version of that code. > >Updated patches are available for HEAD, RELENG7 and RELENG63 (yeah :-) > >here: > >http://people.freebsd.org/~vanhu/NAT-T/ > > > >Please all notice that there is still the word "test" in patches > >names..... > > > > Sorry again I don't understand what you write. That was for other people who may be interested in those patches. Yvan. From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 14:29:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B38B10656C1 for ; Tue, 22 Jul 2008 14:29:20 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 59C358FC23 for ; Tue, 22 Jul 2008 14:29:20 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m6METFDj001070; Tue, 22 Jul 2008 07:29:15 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m6MESCuL005157; Tue, 22 Jul 2008 07:28:12 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (209.249.190.254.available.above.net [209.249.190.254] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m6MESBce002322; Tue, 22 Jul 2008 07:28:11 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Tue, 22 Jul 2008 10:28:10 -0400 Message-ID: From: gnn@freebsd.org To: "Kip Macy" In-Reply-To: References: <3c1674c90807201514o5bafba72r6be84de6e37a5525@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 1020527 - 7f1435c81e0b X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: freebsd-net@freebsd.org, Kip Macy Subject: Re: moving sockbuf in to its own header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 14:29:20 -0000 At Sun, 20 Jul 2008 16:07:29 -0700, Kip Macy wrote: > > Actually, I'd like to re-factor multiple parts of socketvar in to > separate files. > > Please provide feedback on the following: > > http://www.fsmware.com/socketvar_refactor.diff > Looks good to me. Best, George From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 15:18:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA901065682 for ; Tue, 22 Jul 2008 15:18:08 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6803C8FC27 for ; Tue, 22 Jul 2008 15:18:08 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m6MFIlVt011804; Tue, 22 Jul 2008 10:18:47 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m6MFIlsI011803; Tue, 22 Jul 2008 10:18:47 -0500 (CDT) (envelope-from brooks) Date: Tue, 22 Jul 2008 10:18:47 -0500 From: Brooks Davis To: Jens Rehsack Message-ID: <20080722151847.GI1699@lor.one-eyed-alien.net> References: <4884F401.4050103@web.de> <20080721204820.GE1699@lor.one-eyed-alien.net> <4884FFFF.9090908@web.de> <20080721222416.GG1699@lor.one-eyed-alien.net> <48850F72.90204@web.de> <20080721224618.GH1699@lor.one-eyed-alien.net> <48858948.9020403@web.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FUFe+yI/t+r3nyH4" Content-Disposition: inline In-Reply-To: <48858948.9020403@web.de> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Net Subject: Re: SOLVED: lo0 not in ioctl( SIOCGIFCONF ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 15:18:09 -0000 --FUFe+yI/t+r3nyH4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 22, 2008 at 07:16:24AM +0000, Jens Rehsack wrote: > Brooks Davis wrote: >> On Mon, Jul 21, 2008 at 10:36:34PM +0000, Jens Rehsack wrote: >>> Brooks Davis wrote: >>>> On Mon, Jul 21, 2008 at 09:30:39PM +0000, Jens Rehsack wrote: >>>>> Brooks Davis wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> maybe this question is better asked in this list ... >>>>>>>=20 >>>>>>> I was searching why ports/net/p5-Net-Interface was not working as >>>>>>> expected and found some reasons. Most of them I can answer by imple= menting >>>>>>> some test code as attached, but now I'm wondering why em0 is shown = twice >>>>>>> and lo0 is not included. >>>>>>> The same situation on another machine .. >>>>>> The attachment didn't make it through. >>>>>>=20 >>>>>> -- Brooks >>>>> Copy&Paste starts here ... >>>>> #include >>>>> #include >>>>> #include >>>>> #include >>>>> #include >>>>> #include >>>>> #include >>>>> #include >>>>>=20 >>>>> #ifndef _SIZEOF_ADDR_IFREQ >>>>> #define _SIZEOF_ADDR_IFREQ(ifr) \ >>>>> ((ifr).ifr_addr.sa_len > sizeof(struct sockaddr) ? \ >>>>> (sizeof(struct ifreq) - sizeof(struct sockaddr) + \ >>>>> (ifr).ifr_addr.sa_len) : sizeof(struct ifreq)) >>>>> #endif >>>>>=20 >>>>> int >>>>> main() >>>>> { >>>>> struct ifconf ifc; >>>>> struct ifreq *ifr, *lifr; >>>>> int fd; >>>>> unsigned int n; >>>>>=20 >>>>> fd =3D socket( AF_INET, SOCK_STREAM, 0 ); >>>>> bzero(&ifc, sizeof(ifc)); >>>>> n =3D 3; >>>>> ifr =3D calloc( ifc.ifc_len, sizeof(*ifr) ); >>>>> do >>>>> { >>>>> n *=3D 2; >>>>> ifr =3D realloc( ifr, sizeof(*ifr) * n ); >>>>> bzero( ifr, sizeof(*ifr) * n ); >>>>> ifc.ifc_req =3D ifr; >>>>> ifc.ifc_len =3D n * sizeof(*ifr); >>>>> } while( ( ioctl( fd, SIOCGIFCONF, &ifc ) =3D=3D -1 ) || (=20 >>>>> ifc.ifc_len =3D=3D n * sizeof(*ifr)) ); >>>> There are several problems with this loop. First, icoctl won't return >>>> an error in the overflow case because that's not how SIOCGIFCONF works. >>>> SIOCGIFCONF is badly designed in a number of ways, but that's how it >>>> is. Second, checking that the array is completely full isn't at all >>>> reliable because what is returned is actually ifreq structures which >>>> might or might not vary in length as they contain addresses. Thus you >>>> need <=3D. Third, you should start by allocating a significant amount= of >>>> space. Yes, your algorithm is O(sqrt(n)), but allocating a larger >>>> value has effectively no cost so you might as well save some system ca= lls >>>> on average. >>> Thanks - that was the information I miss. I'll try tomorrow (it's=20 >>> slightly late here) and send back the result. >>> Using <=3D should produce an endless loop, but maybe checking if=20 >>> ifc.ifc_len <=3D (n/2) * sizeof(*ifr) could bring wanted results ... >>=20 >> Oops, you're right. Actually, the condition to check is probably >> (n*sizeof(*ifr) - ifc.ifc_len < sizeof(*ifr)). Actually, since the size >> of the returned values aren't actually a multiple of sizeof(*ifr), I'd >> probably switch to allocating a multiple of 4k. >=20 > Actually, because there're very different sizes of sockaddr's (sockaddr_i= n,=20 > sockaddr_in6, ...), I require at least a page must be left over. > Because of other OS may support return of errors in overflow, I didn't=20 > remove the check - finally it must run on AIX, Windows and Linux, too. >=20 >>>>> lifr =3D (struct ifreq *)&ifc.ifc_buf[ifc.ifc_len]; >>>>>=20 >>>>> while (ifr < lifr) > { >>>>> printf( "%s\n", ifr->ifr_name ); >>>>> ifr =3D (struct ifreq *)(((char *)ifr) + _SIZEOF_ADDR_IFREQ(*= ifr)); >>>>> } >>>> This loop has two problems. First, the ifr's are variable length so y= ou >>>> immediately go off into the weeds. >>> The _SIZEOF_ADDR_IFREQ macro should handle that correctly, shouldn't it? >>=20 >> Right here as well. >=20 > Finally - I must enhance this using SA_LEN if available to support system= s=20 > without sa_len member support. I'll try it in office with our linux=20 > machines there, because I don't have any penguins at home ;) >=20 >>>> Second, there is at least one per >>>> interface and one per address so you to keep track of the last interfa= ce >>>> name and not repeat them. >>> Good point - if it's sure in this order, this is a good way to handle i= t. >>=20 >> It is in the current implementation and it's hard to imaging that we'd >> break that. >=20 > By the way, because I'm looking for interfaces, I skip everything which i= s=20 > no AF_LINK - should work, too (and does for my test-machines ...). >=20 > Final question: would it make sense to submit a patch against=20 > ports/net/p5-Net-Interface using this knowledge to unbreak the port, or= =20 I'd suggest doing both. We want it fixed in CPAN, but having it be useful = on FreeBSD would also be good. -- Brooks > /Jens > #include > #include > #include > #include > #include > #include > #include > #include > #include >=20 > /* FIXME use SA_LEN for systems like Linux */ > #ifndef _SIZEOF_ADDR_IFREQ > #define _SIZEOF_ADDR_IFREQ(ifr) \ > ((ifr).ifr_addr.sa_len > sizeof(struct sockaddr) ? \ > (sizeof(struct ifreq) - sizeof(struct sockaddr) + \ > (ifr).ifr_addr.sa_len) : sizeof(struct ifreq)) > #endif >=20 > int > main() > { > struct ifconf ifc; > struct ifreq *ifr, *lifr; > int fd; > unsigned int n; >=20 > fd =3D socket( AF_INET, SOCK_STREAM, 0 ); > bzero(&ifc, sizeof(ifc)); > n =3D 1; > ifr =3D calloc( ifc.ifc_len, sizeof(*ifr) ); > do > { > n *=3D 2; > ifr =3D realloc( ifr, PAGE_SIZE * n ); > bzero( ifr, PAGE_SIZE * n ); > ifc.ifc_req =3D ifr; > ifc.ifc_len =3D n * PAGE_SIZE; > } while( ( ioctl( fd, SIOCGIFCONF, &ifc ) =3D=3D -1 ) || ( ifc.if= c_len >=3D ( (n-1) * PAGE_SIZE)) ); >=20 > lifr =3D (struct ifreq *)&ifc.ifc_buf[ifc.ifc_len]; >=20 > while (ifr < lifr) > { > struct sockaddr *sa =3D &ifr->ifr_ifru.ifru_addr; > if( AF_LINK =3D=3D sa->sa_family ) > { > printf( "%s\n", ifr->ifr_name ); > } > ifr =3D (struct ifreq *)(((char *)ifr) + _SIZEOF_ADDR_IFREQ(*ifr)= ); > } >=20 > return 0; > } --FUFe+yI/t+r3nyH4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFIhfpXXY6L6fI4GtQRAtBRAKDhEpvRIkATfsa4HChBrxA20NSqZwCfUAyz 09yOhimYruPEua5tDSjX4IU= =omn2 -----END PGP SIGNATURE----- --FUFe+yI/t+r3nyH4-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 15:37:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06EAB1065679 for ; Tue, 22 Jul 2008 15:37:50 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id D0D818FC0A for ; Tue, 22 Jul 2008 15:37:49 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m6MFbkuk031027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 08:37:47 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4885FECA.6000502@freebsd.org> Date: Tue, 22 Jul 2008 08:37:46 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> <20080721085325.B57089@maildrop.int.zabbadoz.net> <4884A956.5060108@freebsd.org> <20080721180626.V57089@maildrop.int.zabbadoz.net> In-Reply-To: <20080721180626.V57089@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org, vanhu_bsd@zeninc.net, Larry Baird Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 15:37:50 -0000 Bjoern A. Zeeb wrote: > On Mon, 21 Jul 2008, Sam Leffler wrote: > > Hi Sam, > >>> We are still missing other things I think not mentioned elswhere like >>> partial checksum recalculation. >> >> Please send me your specific issues; I haven't seen any comments >> about "partial checksum recalculations". > > So what has kept you from reading the RFCs for the patch you were > working on? "It works for me" does not mean "It's right and all done". > Nothing; so far as I can see your comments are irrelevant and unless you're willing to spell out the specific concerns you have I'm not giving them much weight. As I said when I got involved in this discussion I've wanted NA-T support in FreeBSD for a long time. I've tried several ways to make this happen but now am actively putting my time into making it happen. If you don't want to participate that's fine. Otherwise please provide constructive help. Again, remember this work is going in HEAD and all the changes are conditionally compiled. Sam From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 15:41:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DD24106568B; Tue, 22 Jul 2008 15:41:13 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 53E5F8FC16; Tue, 22 Jul 2008 15:41:13 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m6MFfCnn031054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 08:41:13 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4885FF98.4090507@freebsd.org> Date: Tue, 22 Jul 2008 08:41:12 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <20080630040103.94730.qmail@mailgate.gta.com> <486A45AB.2080609@freebsd.org> <487EC62A.3070301@freebsd.org> <20080721083110.GA21786@zen.inc> <20080721141327.GA24677@zen.inc> <4884AC65.7020605@freebsd.org> <20080722095230.GA14962@zen.inc> In-Reply-To: <20080722095230.GA14962@zen.inc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 15:41:13 -0000 VANHULLEBUS Yvan wrote: > On Mon, Jul 21, 2008 at 08:33:57AM -0700, Sam Leffler wrote: > >> VANHULLEBUS Yvan wrote: >> > [....] > >>> After some more testing, I found another issue: in udp4_espdecap(), >>> when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should >>> not be discarded, but just returned for normal processing. >>> >>> >> Please edit the sam_nat_t branch in p4 or send a patch I can apply. >> > > As Perforce is really really new for me, here is the patch: > > --- sys/netinet/udp_usrreq.c Tue Jul 22 11:04:30 2008 > +++ sys/netinet/udp_usrreq.c Mon Jul 21 21:30:52 2008 > @@ -797,8 +797,8 @@ udp_ctloutput(struct socket *so, struct > if (INP_CHECK_SOCKAF(so, AF_INET6)) { > INP_WUNLOCK(inp); > error = ip6_ctloutput(so, sopt); > -#endif > } else { > +#endif > INP_WUNLOCK(inp); > error = ip_ctloutput(so, sopt); > #ifdef INET6 > @@ -846,7 +846,9 @@ udp_ctloutput(struct socket *so, struct > case SOPT_GET: > switch (sopt->sopt_name) { > case UDP_ENCAP: > +#ifdef IPSEC_NAT_T > optval = inp->inp_flags & INP_ESPINUDP_ALL; > +#endif > INP_WUNLOCK(inp); > error = sooptcopyout(sopt, &optval, sizeof optval); > break; > @@ -1236,11 +1238,9 @@ udp4_espdecap(struct socket *so, struct > } else { > uint64_t marker; > > - if (payload <= sizeof(uint64_t) + sizeof(struct esp)) { > - udpstat.udps_hdrops++; /* XXX? */ > - m_freem(m); > - return NULL; /* discard */ > - } > + if (payload <= sizeof(uint64_t) + sizeof(struct esp)) > + return m; /* NB: no decap */ > + > bcopy(data + off, &marker, sizeof(uint64_t)); > if (marker != 0) > return m; /* NB: no decap */ > > > <<< end of diff > > There is an extra #ifdef, which I noticed yesterday when I tried to > compile using a wrong kernel conf file (without NAT_T support). > Please send patches as attachments so I can apply them directly. I have hand-transcribed the above. Thank you. Sam From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 17:44:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 361B6106567A for ; Tue, 22 Jul 2008 17:44:46 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.freebsd.org (Postfix) with ESMTP id F15C48FC19 for ; Tue, 22 Jul 2008 17:44:45 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from dyn006158.edvz.uni-linz.ac.at (dyn006158.edvz.uni-linz.ac.at [140.78.6.158]) by emailsecure.uni-linz.ac.at (Postfix) with ESMTP id 752D9228022 for ; Tue, 22 Jul 2008 19:13:09 +0200 (CEST) Message-ID: <48861525.5060104@jku.at> Date: Tue, 22 Jul 2008 19:13:09 +0200 From: Ferdinand Goldmann Organization: Johannes Kepler University User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <487C9457.5080609@bsdunix.ch> <2A7CBD67-7532-4B13-82DD-A6EF5DEAA6BD@bsdunix.ch> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: FD_SETSIZE (too many open file descriptors) + BIND X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ferdinand.goldmann@jku.at List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 17:44:46 -0000 Hi there, I just upgraded a FreeBSD 6.x machine to FreeBSD 6.3-STABLE, and now I'm seeing this same problem which has already been reported in different postings: named[51769]: socket: too many open file descriptors last message repeated 147 times Obvously it is hitting the 1024 limit: # sockstat |grep -c named 979 I tried recompiling BIND with -DFD_SETSIZE=4096 by adding it to the CFLAGS in /usr/src/usr.sbin/named/Makefile, doing a make cleandepend; make depend; make named; and installing the new named binary in /usr/sbin. So far, the annoying limit still seems to be there. Am I missing something? So, in short: How can one raise the @@#$!## limit of FD_SETSIZE in FreeBSD? Is it still necessary to recompile the kernel, too, as some ancient postings I found suggest? TIA & regards, Ferdinand From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 19:09:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5ECA1065681 for ; Tue, 22 Jul 2008 19:09:21 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.freebsd.org (Postfix) with ESMTP id AFA3D8FC12 for ; Tue, 22 Jul 2008 19:09:21 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from [81.10.209.143] (cm209-143.liwest.at [81.10.209.143]) by emailsecure.uni-linz.ac.at (Postfix) with ESMTP id ACD77228022 for ; Tue, 22 Jul 2008 21:09:20 +0200 (CEST) Message-ID: <48863060.10909@jku.at> Date: Tue, 22 Jul 2008 21:09:20 +0200 From: Ferdinand Goldmann Organization: Johannes Kepler University User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <487C9457.5080609@bsdunix.ch> <2A7CBD67-7532-4B13-82DD-A6EF5DEAA6BD@bsdunix.ch> <48861525.5060104@jku.at> In-Reply-To: <48861525.5060104@jku.at> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FD_SETSIZE (too many open file descriptors) + BIND X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ferdinand.goldmann@jku.at List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 19:09:22 -0000 Ferdinand Goldmann wrote: > Hi there, > > I just upgraded a FreeBSD 6.x machine to FreeBSD 6.3-STABLE, and now I'm > seeing this same problem which has already been reported in different > postings: > > named[51769]: socket: too many open file descriptors > last message repeated 147 times I am following up to my own posting, which was kind of stupid really because I obviously made some mistakes. I have now done the following: # cd /usr/src/lib/bind Edited config.mk: CFLAGS+= -DVERSION='"${BIND_VERSION}"' -DFD_SETSIZE=4096 recompiled bind library and named according to advisory on freebsd-security: # make obj && make depend && make && make install # cd /usr/src/usr.sbin/named # make obj && make depend && make && make install I'm crossing my fingers, but it seems to have done the trick. Monitoring system usage with sockstat, I have seen values of almost up to 1400 being used by named without the 'too many open file descriptors' appearing in the logs. Sorry for my slightly nervous previous posting ... Regards, Ferdinand From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 21:02:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FFDE106564A for ; Tue, 22 Jul 2008 21:02:11 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (mail.telesweet.net [194.110.252.6]) by mx1.freebsd.org (Postfix) with ESMTP id 329BC8FC23 for ; Tue, 22 Jul 2008 21:02:11 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 3181810C6B2 for ; Tue, 22 Jul 2008 23:46:33 +0300 (EEST) X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.071, BAYES_00=-2.599] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.telesweet.net (Postfix) with ESMTPS id 65E7110C6B0 for ; Tue, 22 Jul 2008 23:46:30 +0300 (EEST) Message-ID: <4886474D.5030300@samoylyk.sumy.ua> Date: Tue, 22 Jul 2008 23:47:09 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Subject: proxy-arp & mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 21:02:11 -0000 Dear Community, I'm using proxy-arp for public ips for our clients in order to give them internet access using pptp-tunnels with mpd: # cat /usr/local/etc/mpd5/mpd.conf | grep arp set iface enable proxy-arp # uname -a FreeBSD xxx.xxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue May 13 06:54:41 EEST 2008 root@xxx.xxxxxx.xxx:/usr/obj/usr/src/sys/XXX amd64 Sometimes I see hanged arps: root 72148 0.0 0.0 2564 788 ?? S 9:33PM 0:20.69 /usr/sbin/arp -S xx.xxx.xxx.xx 0:e:c:70:c6:4c pub where xx.xxx.xxx.xx is public ip address In such moments clients can't connect to pptp-server (e.g., Error 800 for Windowz clients). Why does that happen? How can I prevent such situations? Thank you! -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 21:05:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF8FD1065672 for ; Tue, 22 Jul 2008 21:05:32 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (mail.telesweet.net [194.110.252.6]) by mx1.freebsd.org (Postfix) with ESMTP id A01BE8FC12 for ; Tue, 22 Jul 2008 21:05:32 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id C3E0410C6BF for ; Wed, 23 Jul 2008 00:05:31 +0300 (EEST) X-Spam-Flag: NO X-Spam-Score: -4.332 X-Spam-Level: X-Spam-Status: No, score=-4.332 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.067, BAYES_00=-2.599] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id 8F6C210C6C2 for ; Wed, 23 Jul 2008 00:04:43 +0300 (EEST) Message-ID: <48864B6C.9030404@samoylyk.sumy.ua> Date: Wed, 23 Jul 2008 00:04:44 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4886474D.5030300@samoylyk.sumy.ua> In-Reply-To: <4886474D.5030300@samoylyk.sumy.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: proxy-arp & mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 21:05:33 -0000 Oleksandr Samoylyk ÐÉÛÅÔ: > Dear Community, > > I'm using proxy-arp for public ips for our clients in order to give them > internet access using pptp-tunnels with mpd: > > # cat /usr/local/etc/mpd5/mpd.conf | grep arp > set iface enable proxy-arp > > # uname -a > FreeBSD xxx.xxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue May 13 > 06:54:41 EEST 2008 root@xxx.xxxxxx.xxx:/usr/obj/usr/src/sys/XXX amd64 > > Sometimes I see hanged arps: > > root 72148 0.0 0.0 2564 788 ?? S 9:33PM 0:20.69 > /usr/sbin/arp -S xx.xxx.xxx.xx 0:e:c:70:c6:4c pub > > where xx.xxx.xxx.xx is public ip address as well: root 58831 0.0 0.0 2564 788 ?? S 11:58PM 0:01.04 /usr/sbin/arp -d xx.xxx.xxx.xx > In such moments clients can't connect to pptp-server (e.g., Error 800 > for Windowz clients). > > Why does that happen? How can I prevent such situations? > > > Thank you! > -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Jul 22 23:57:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EB881065673 for ; Tue, 22 Jul 2008 23:57:35 +0000 (UTC) (envelope-from anumita@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by mx1.freebsd.org (Postfix) with ESMTP id AAFF18FC0A for ; Tue, 22 Jul 2008 23:57:34 +0000 (UTC) (envelope-from anumita@gmail.com) Received: by mu-out-0910.google.com with SMTP id i2so1380270mue.3 for ; Tue, 22 Jul 2008 16:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type; bh=oSyR78y5hebDNE3mKR4rPkH3QXiGBHqqLkOvwyYZoNo=; b=LdNnB5DmxKmU3iG7SULvP+igix9OaXoyFLcWsJwA9zHeFFx0gd87H7TsRNH+1j2xg0 Vqi5h61Pz+KFc2ZLo2A4hSGJ7HhAcL5F1EwNRkwDowREbX6+dUg6qkWP+Cjiy6xIHAYE Gk9rRGTNpx3eAhF9OrQS7U09dEv9OTRdDWHdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=Hk1PXUialgKHjAFlglHmZzFtifuw8hSlucyHYRG4LTHXKCgEyOTTQntIK188QWVbHF hK5sCR0KzZPMQ0gVxL352K51foRpWJNwqkndciQltyAzxdLJxXAhz0TbKFOBobxfkS7Z MBGFTdr6Tm/DeqyLShEqpxo7X5oD5i/3X4vAI= Received: by 10.103.239.10 with SMTP id q10mr4094962mur.82.1216769429280; Tue, 22 Jul 2008 16:30:29 -0700 (PDT) Received: by 10.103.23.17 with HTTP; Tue, 22 Jul 2008 16:30:29 -0700 (PDT) Message-ID: <2ddbdfa20807221630j77001ddfvd83dcd0f8c279a7d@mail.gmail.com> Date: Tue, 22 Jul 2008 16:30:29 -0700 From: "Anumita Biswas" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: anumita@gmail.com Subject: FreeBSD tcp backoff problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2008 23:57:35 -0000 Hi, I work on a stack which is derived from FreeBSD. We have found a problem in the stack which shows up on TCP connections that do not use timestamps as follows. TCP backs off its retransmissions exponentially even though forward progress is being made. Appliance(our stack) sends data Client sends ack, but appliance does not receive it Appliance times out and resends packet Client sends ack, Appliance receives this ack This sequence continues. But each time the timeout goes up as 16, 32, 64, 64, 64 etc. Since each retransmitted packet is acked, the appliance should not continue to back off. The problem seems to be that t_rxtshift is not being reset when the ack is received. Normally t_rxtshift will be set to zero in tcp_xmit_timer() which is called from tcp_input() when a packet with a valid round trip time is received. When times stamps are not being used, as is the case with this connection, tcp_xmit_timer() is only called if t_rtttime is non-zero. However, it is set to zero when the retransmission timeout happens. Thus, tcp_xmit_timers() is never called during the sequence of packets shown above. So like in this case: if (tlen == 0) { if (SEQ_GT(th->th_ack, tp->snd_una) && SEQ_LEQ(th->th_ack, tp->snd_max) && tp->snd_cwnd >= tp->snd_wnd && ((!tcp_do_newreno && !tp->sack_enable && tp->t_dupacks < tcprexmtthresh) || ((tcp_do_newreno || tp->sack_enable) && ... etc. ... */ if ((to.to_flags & TOF_TS) != 0 && to.to_tsecr) { tcp_xmit_timer(tp, ticks - to.to_tsecr + 1); } else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) { tcp_xmit_timer(tp, ticks - tp->t_rtttime); } Since timestamps are not in use, and tp->t_rtttime is 0 as we just had a retransmission, we don't bring down tp->t_rxtshift to 0. There is a comment in the code subsequently, /* * If all outstanding data are acked, stop * retransmit timer, otherwise restart timer * using current (possibly backed-off) value. * If process is waiting for space, * wakeup/selwakeup/signal. If data * are ready to send, let tcp_output * decide between more output or persist. which seems to indicate that we should use possibly backed off value when restarting the retransmit timer. But we dont do that when timestamps are in use. So the comment is confusing. But when timestamps are not in use, t_rxtshift is not brought down to 0. Would it make sense to correct the comment and introduce an else condition here: if ((to.to_flags & TOF_TS) != 0 && to.to_tsecr) { tcp_xmit_timer(tp, ticks - to.to_tsecr + 1); } else if (tp->t_rtttime && SEQ_GT(th->th_ack, tp->t_rtseq)) { tcp_xmit_timer(tp, ticks - tp->t_rtttime); } else { tp->t_rxtshift = 0; } We might need a similar change when we receive more than 3 dupacks in tcp_input and don't call tcp_xmit_timer(). Though I don't know if in that case, tp->t_rtttime will be 0. I also dont know if we should be initializing anything else besides tp->t_rxtshift in this else part. Any comments on this would be appreciated. thanks, Anumita. From owner-freebsd-net@FreeBSD.ORG Wed Jul 23 07:49:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 143E51065676 for ; Wed, 23 Jul 2008 07:49:53 +0000 (UTC) (envelope-from damien.deville@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id D52ED8FC44 for ; Wed, 23 Jul 2008 07:49:52 +0000 (UTC) (envelope-from damien.deville@netasq.com) Received: from barbar.netasq.com (unknown [10.0.0.126]) by netasq.netasq.com (Postfix) with ESMTP id 79CB421E06; Wed, 23 Jul 2008 09:32:34 +0200 (CEST) Message-ID: <4886DE83.5080100@netasq.com> Date: Wed, 23 Jul 2008 09:32:19 +0200 From: Damien Deville User-Agent: Thunderbird 2.0.0.14 (X11/20080610) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <4886474D.5030300@samoylyk.sumy.ua> <48864B6C.9030404@samoylyk.sumy.ua> In-Reply-To: <48864B6C.9030404@samoylyk.sumy.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: proxy-arp & mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: damien.deville@netasq.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 07:49:53 -0000 Hi, we are facing a similar issue with arp blocked in sbwait state. Here is a way to reproduce it: - add a bunch of arp entries in your arp table (best is around 255 entries). - launch two arp -a -d in parallel ('arp -a -d & arp -a -d &') Both processes will be in concurence to access the table. One process will successfully nuke all entries of the arp table, the other one will be blocked in rtmsg function on the read while executing a RTM_GET or RTM_DELETE command after some time. By instrumenting arp we noticed that it happened when both process access to the same entry. Here is a backtrace of the blocked arp on FreeBSD 7.0 (gdb) bt #0 0x28158f81 in read () from /lib/libc.so.7 #1 0x08049091 in rtmsg () #2 0x08049b44 in delete () #3 0x0804a1fd in nuke_entry () #4 0x08049a77 in search () #5 0x08049e75 in main () I can reproduce this on FreeBSD 4.11, 6.2 and 6.3, and FreeBSD 7.0. Damien Deville Oleksandr Samoylyk wrote: > Oleksandr Samoylyk ÐÉÛÅÔ: >> Dear Community, >> >> I'm using proxy-arp for public ips for our clients in order to give >> them internet access using pptp-tunnels with mpd: >> >> # cat /usr/local/etc/mpd5/mpd.conf | grep arp >> set iface enable proxy-arp >> >> # uname -a >> FreeBSD xxx.xxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue May 13 >> 06:54:41 EEST 2008 root@xxx.xxxxxx.xxx:/usr/obj/usr/src/sys/XXX >> amd64 >> >> Sometimes I see hanged arps: >> >> root 72148 0.0 0.0 2564 788 ?? S 9:33PM 0:20.69 >> /usr/sbin/arp -S xx.xxx.xxx.xx 0:e:c:70:c6:4c pub >> >> where xx.xxx.xxx.xx is public ip address > > as well: > > root 58831 0.0 0.0 2564 788 ?? S 11:58PM 0:01.04 > /usr/sbin/arp -d xx.xxx.xxx.xx > > > >> In such moments clients can't connect to pptp-server (e.g., Error 800 >> for Windowz clients). >> >> Why does that happen? How can I prevent such situations? >> >> >> Thank you! >> > > -- Damien Deville R&D engineer damien.deville@netasq.com http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Wed Jul 23 15:15:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29A9F106564A for ; Wed, 23 Jul 2008 15:15:10 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from dire.wubethiopia.com (j071.v.rootbsd.net [208.79.82.223]) by mx1.freebsd.org (Postfix) with ESMTP id 195D38FC13 for ; Wed, 23 Jul 2008 15:15:09 +0000 (UTC) (envelope-from mtm@wubethiopia.com) Received: from rogue.mike.lan (unknown [213.55.70.173]) by dire.wubethiopia.com (Postfix) with ESMTPSA id F1D394FD9EE2 for ; Wed, 23 Jul 2008 14:59:08 +0000 (UTC) Message-ID: <48874891.2070201@wubethiopia.com> Date: Wed, 23 Jul 2008 18:04:49 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.12 (X11/20080323) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: stalled connections on recent -current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 15:15:10 -0000 Hi, I'm wondering if anyone has seen stalled connections to cvsup servers recently. I've tried updating my mirror from several different cvsup servers, but the connection always stalls sometime in the middle of the update process and eventually fails with the following message in my cvsup log file: TreeList failed: Network write failure: Connection timed out This is what netstat -f inet looks like during the stall: mtm@rogue ~% netstat -f inet Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 32544 192.168.0.98.32829 sanmateo.ecn.pur.cvsup ESTABLISHED tcp4 0 0 192.168.0.98.22775 xxx.xxx.xxx.xxx .ssh ESTABLISHED This started happening after I upgraded the system (which was a couple of months old) to one from around July 16th. Unfortunately I don't have the old kernel to confirm that this is indeed a kernel bug. Any suggestions as to how to debug this? Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Wed Jul 23 15:20:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70E7F106566B for ; Wed, 23 Jul 2008 15:20:57 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (mail.telesweet.net [194.110.252.6]) by mx1.freebsd.org (Postfix) with ESMTP id 221798FC1D for ; Wed, 23 Jul 2008 15:20:57 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 6199010C14A; Wed, 23 Jul 2008 18:20:54 +0300 (EEST) X-Spam-Flag: NO X-Spam-Score: -4.304 X-Spam-Level: X-Spam-Status: No, score=-4.304 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.095, BAYES_00=-2.599] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.telesweet.net (Postfix) with ESMTPS id 963D810C084; Wed, 23 Jul 2008 18:20:48 +0300 (EEST) Message-ID: <48874C7C.5070402@samoylyk.sumy.ua> Date: Wed, 23 Jul 2008 18:21:32 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: damien.deville@netasq.com References: <4886474D.5030300@samoylyk.sumy.ua> <48864B6C.9030404@samoylyk.sumy.ua> <4886DE83.5080100@netasq.com> In-Reply-To: <4886DE83.5080100@netasq.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: proxy-arp & mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 15:20:57 -0000 Damien Deville wrote: > Hi, > > we are facing a similar issue with arp blocked in sbwait state. > > Here is a way to reproduce it: > - add a bunch of arp entries in your arp table (best is around 255 > entries). > - launch two arp -a -d in parallel ('arp -a -d & arp -a -d &') > > Both processes will be in concurence to access the table. One process > will successfully nuke all entries of the arp table, the other one will > be blocked in rtmsg function on the read while executing a RTM_GET or > RTM_DELETE command after some time. By instrumenting arp we noticed that > it happened when both process access to the same entry. > > Here is a backtrace of the blocked arp on FreeBSD 7.0 > > (gdb) bt > #0 0x28158f81 in read () from /lib/libc.so.7 > #1 0x08049091 in rtmsg () > #2 0x08049b44 in delete () > #3 0x0804a1fd in nuke_entry () > #4 0x08049a77 in search () > #5 0x08049e75 in main () > > I can reproduce this on FreeBSD 4.11, 6.2 and 6.3, and FreeBSD 7.0. Any workaround so far? -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Jul 23 15:29:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C69B51065674 for ; Wed, 23 Jul 2008 15:29:55 +0000 (UTC) (envelope-from damien.deville@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 9186B8FC1A for ; Wed, 23 Jul 2008 15:29:55 +0000 (UTC) (envelope-from damien.deville@netasq.com) Received: from barbar.netasq.com (unknown [10.0.0.126]) by netasq.netasq.com (Postfix) with ESMTP id 6219C226D6; Wed, 23 Jul 2008 17:29:54 +0200 (CEST) Message-ID: <48874E63.7070603@netasq.com> Date: Wed, 23 Jul 2008 17:29:39 +0200 From: Damien Deville User-Agent: Thunderbird 2.0.0.14 (X11/20080610) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <4886474D.5030300@samoylyk.sumy.ua> <48864B6C.9030404@samoylyk.sumy.ua> <4886DE83.5080100@netasq.com> <48874C7C.5070402@samoylyk.sumy.ua> In-Reply-To: <48874C7C.5070402@samoylyk.sumy.ua> Content-Type: multipart/mixed; boundary="------------090808070204070709050008" Cc: freebsd-net@freebsd.org Subject: Re: proxy-arp & mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: damien.deville@netasq.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 15:29:55 -0000 This is a multi-part message in MIME format. --------------090808070204070709050008 Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Hi, after some more tests here is what i came to (patch provided is for freebsd 6.3 but can be adapted for other versions): it is a dirty hack and might not be the right solution but it is working in the case i described earlier and i hope it will help discussing the issue. It seems that the process that block read all entries available in the PF_ROUTE socket, do not find the one it is looking for and ends blocked on the PF_ROUTE socket as no more entries are available after reading and entry with rtm->rtm_pid == 0 and rtm->rtm_seq == 0. Damien Oleksandr Samoylyk wrote: > Damien Deville wrote: >> Hi, >> >> we are facing a similar issue with arp blocked in sbwait state. >> >> Here is a way to reproduce it: >> - add a bunch of arp entries in your arp table (best is around 255 >> entries). >> - launch two arp -a -d in parallel ('arp -a -d & arp -a -d &') >> >> Both processes will be in concurence to access the table. One process >> will successfully nuke all entries of the arp table, the other one >> will be blocked in rtmsg function on the read while executing a >> RTM_GET or RTM_DELETE command after some time. By instrumenting arp we >> noticed that it happened when both process access to the same entry. >> >> Here is a backtrace of the blocked arp on FreeBSD 7.0 >> >> (gdb) bt >> #0 0x28158f81 in read () from /lib/libc.so.7 >> #1 0x08049091 in rtmsg () >> #2 0x08049b44 in delete () >> #3 0x0804a1fd in nuke_entry () >> #4 0x08049a77 in search () >> #5 0x08049e75 in main () >> >> I can reproduce this on FreeBSD 4.11, 6.2 and 6.3, and FreeBSD 7.0. > > Any workaround so far? > -- Damien Deville R&D engineer damien.deville@netasq.com http://www.netasq.com NETASQ - We secure IT --------------090808070204070709050008 Content-Type: text/plain; name="arp.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="arp.diff" --- arp.c.orig 2006-10-21 07:43:29.000000000 +0200 +++ arp.c 2008-07-23 10:41:44.000000000 +0200 @@ -706,17 +706,28 @@ l = rtm->rtm_msglen; rtm->rtm_seq = ++seq; rtm->rtm_type = cmd; if ((rlen = write(s, (char *)&m_rtmsg, l)) < 0) { if (errno != ESRCH || cmd != RTM_DELETE) { warn("writing to routing socket"); return (NULL); } } do { l = read(s, (char *)&m_rtmsg, sizeof(m_rtmsg)); + if ( l > 0 && rtm->rtm_seq == 0 && rtm->rtm_pid == 0 ) + return (NULL); /* something weird happened */ } while (l > 0 && (rtm->rtm_seq != seq || rtm->rtm_pid != pid)); if (l < 0) warn("read from routing socket"); return (rtm); } --------------090808070204070709050008-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 23 21:09:01 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33DA0106567C; Wed, 23 Jul 2008 21:09:01 +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 16D638FC0A; Wed, 23 Jul 2008 21:09:01 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6NL90wk021814; Wed, 23 Jul 2008 21:09:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6NL90YI021810; Wed, 23 Jul 2008 21:09:00 GMT (envelope-from linimon) Date: Wed, 23 Jul 2008 21:09:00 GMT Message-Id: <200807232109.m6NL90YI021810@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/125906: [vap] second hostap interface (wlan1) unable to send traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 21:09:01 -0000 Synopsis: [vap] second hostap interface (wlan1) unable to send traffic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 23 21:08:52 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125906 From owner-freebsd-net@FreeBSD.ORG Wed Jul 23 22:40:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ECC51065671 for ; Wed, 23 Jul 2008 22:40: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 769858FC14 for ; Wed, 23 Jul 2008 22:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6NMe3vt030981 for ; Wed, 23 Jul 2008 22:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6NMe3GH030980; Wed, 23 Jul 2008 22:40:03 GMT (envelope-from gnats) Date: Wed, 23 Jul 2008 22:40:03 GMT Message-Id: <200807232240.m6NMe3GH030980@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Stephan Eisvogel Cc: Subject: Re: kern/125816: [carp] [bridge] carp stuck in init when using bridge interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephan Eisvogel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 22:40:03 -0000 The following reply was made to PR kern/125816; it has been noted by GNATS. From: Stephan Eisvogel To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/125816: [carp] [bridge] carp stuck in init when using bridge interface Date: Thu, 24 Jul 2008 00:37:18 +0200 This doesn't work on rev 180768 of 8-CURRENT that I just checked out of SVN as well. The bridge's carp interface won't leave INIT. Platform btw is an alix board by pc engines. From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 02:46:35 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5B4A1065671; Thu, 24 Jul 2008 02:46:35 +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 746E38FC1C; Thu, 24 Jul 2008 02:46:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6O2kZwF052056; Thu, 24 Jul 2008 02:46:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6O2kZXi052052; Thu, 24 Jul 2008 02:46:35 GMT (envelope-from linimon) Date: Thu, 24 Jul 2008 02:46:35 GMT Message-Id: <200807240246.m6O2kZXi052052@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/125914: [ath] [panic] ath driver causes kernel panic in 7-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 02:46:35 -0000 Old Synopsis: Ath driver causes kernel panic in 7-STABLE New Synopsis: [ath] [panic] ath driver causes kernel panic in 7-STABLE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 24 02:46:20 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125914 From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 05:21:50 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A49641065673; Thu, 24 Jul 2008 05:21:50 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1508FC0C; Thu, 24 Jul 2008 05:21:50 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from freefall.freebsd.org (sam@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6O5LoA0070586; Thu, 24 Jul 2008 05:21:50 GMT (envelope-from sam@freefall.freebsd.org) Received: (from sam@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6O5LoVw070582; Thu, 24 Jul 2008 05:21:50 GMT (envelope-from sam) Date: Thu, 24 Jul 2008 05:21:50 GMT Message-Id: <200807240521.m6O5LoVw070582@freefall.freebsd.org> To: sam@FreeBSD.org, freebsd-net@FreeBSD.org, sam@FreeBSD.org From: sam@FreeBSD.org Cc: Subject: Re: kern/125906: [vap] second hostap interface (wlan1) unable to send traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 05:21:50 -0000 Synopsis: [vap] second hostap interface (wlan1) unable to send traffic Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Thu Jul 24 05:21:31 UTC 2008 Responsible-Changed-Why: I promised to look at this http://www.freebsd.org/cgi/query-pr.cgi?pr=125906 From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 05:25:26 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A0941065678; Thu, 24 Jul 2008 05:25:26 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2068FC19; Thu, 24 Jul 2008 05:25:26 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from freefall.freebsd.org (sam@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6O5PQ7i070688; Thu, 24 Jul 2008 05:25:26 GMT (envelope-from sam@freefall.freebsd.org) Received: (from sam@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6O5PQfe070684; Thu, 24 Jul 2008 05:25:26 GMT (envelope-from sam) Date: Thu, 24 Jul 2008 05:25:26 GMT Message-Id: <200807240525.m6O5PQfe070684@freefall.freebsd.org> To: smallhand@crawblog.com, sam@FreeBSD.org, freebsd-net@FreeBSD.org, sam@FreeBSD.org From: sam@FreeBSD.org Cc: Subject: Re: kern/125914: [ath] [panic] ath driver causes kernel panic in 7-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 05:25:26 -0000 Synopsis: [ath] [panic] ath driver causes kernel panic in 7-STABLE State-Changed-From-To: open->feedback State-Changed-By: sam State-Changed-When: Thu Jul 24 05:22:10 UTC 2008 State-Changed-Why: need network setup information and information on how to reproduce the problem The line number pointed at indicates you are doing tx fragmentation which is highly unlikely--either that or your code does not match the kernel. Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Thu Jul 24 05:22:10 UTC 2008 Responsible-Changed-Why: need network setup information and information on how to reproduce the problem The line number pointed at indicates you are doing tx fragmentation which is highly unlikely--either that or your code does not match the kernel. http://www.freebsd.org/cgi/query-pr.cgi?pr=125914 From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 07:54:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 976A4106566C; Thu, 24 Jul 2008 07:54:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 148098FC18; Thu, 24 Jul 2008 07:54:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A48B146C7F; Thu, 24 Jul 2008 03:54:20 -0400 (EDT) Date: Thu, 24 Jul 2008 08:54:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kip Macy In-Reply-To: Message-ID: <20080724084240.C63347@fledge.watson.org> References: <3c1674c90807201514o5bafba72r6be84de6e37a5525@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Kip Macy Subject: Re: moving sockbuf in to its own header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 07:54:21 -0000 On Sun, 20 Jul 2008, Kip Macy wrote: > Actually, I'd like to re-factor multiple parts of socketvar in to separate > files. > > Please provide feedback on the following: > > http://www.fsmware.com/socketvar_refactor.diff This seems like a fairly disruptive change from the perpective of managing future MFCs, and likewise makes it quite a bit harder to diff branches and make sure things haven't been missed. That said, I'm not entirely opposed to it, since I think this decomposition is a fairly reasonable one. Do make sure you've done a complete make universe to hit all the user consumers, such as netstat, etc, that grub around in the kernel parts and make sure there are no surprises. A few comments: - Please propagate the copyright/license from socketvar.h to all derived new files. - You seem to have a lot of extra blank lines -- generally speaking, at most one blank line between pieces of code/comments/etc is required. - The new include files seem not to have forward declarations of the structs referenced from other structures, so in practice you may find that including one requires including the others. Fixing this is easy and, at the very least, non-harmful. It would also lay the way towards not doing nested includes of various includes from socketvar.h in the future. - One of the elements of the BSD style(9) I don't like is the tab between "struct" and "structname" for fields in older structures. Perhaps this is why I notice that it isn't there in the new struct sockbuf line in struct socket, and likewise xsockbuf in xsocket :-) If you do make this change, check in with Peter about whether we now prefer the use of svn copy. Robert N M Watson Computer Laboratory University of Cambridge > > Thanks, > Kip > > > On Sun, Jul 20, 2008 at 3:14 PM, Kip Macy wrote: >> TOE drivers need to be able to directly enqueue data in to a socket >> buffer and thus benefit from having knowledge of sockbuf internals. >> However, there is no need for them to know about other socket >> definitions. Thus I would like to move sockbuf and accompanying >> definitions to their own header. >> >> This is a fairly straightforward change so I don't really see the need >> to wait more than a few days for feedback: >> >> http://www.fsmware.com/sockbuf.h.diff >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 07:56:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B7ED1065673 for ; Thu, 24 Jul 2008 07:56:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 538448FC1A for ; Thu, 24 Jul 2008 07:56:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 02E6246C53; Thu, 24 Jul 2008 03:56:49 -0400 (EDT) Date: Thu, 24 Jul 2008 08:56:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Makonnen In-Reply-To: <48874891.2070201@wubethiopia.com> Message-ID: <20080724085515.W63347@fledge.watson.org> References: <48874891.2070201@wubethiopia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: stalled connections on recent -current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 07:56:49 -0000 On Wed, 23 Jul 2008, Mike Makonnen wrote: > I'm wondering if anyone has seen stalled connections to cvsup servers > recently. I've tried updating my mirror from several different cvsup > servers, but the connection always stalls sometime in the middle of the > update process and eventually fails with the following message in my cvsup > log file: TreeList failed: Network write failure: Connection timed out > > This is what netstat -f inet looks like during the stall: > > mtm@rogue ~% netstat -f inet > Active Internet connections > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp4 0 32544 192.168.0.98.32829 sanmateo.ecn.pur.cvsup ESTABLISHED > tcp4 0 0 192.168.0.98.22775 xxx.xxx.xxx.xxx .ssh ESTABLISHED > > This started happening after I upgraded the system (which was a couple of > months old) to one from around July 16th. Unfortunately I don't have the old > kernel to confirm that this is indeed a kernel bug. > > Any suggestions as to how to debug this? I think I'd always start with tcpdump and see if it's at all obvious what is going on. In particular, it would be good to see if any ACKs are coming from sanmateo.ecn.pur.whatever:cvsup, and if so, what their window advertisements look like. It also doesn't hurt to confirm the state of local processes/threads attached to the socket, perhaps using procstat -k. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 08:57:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2F5C106566C for ; Thu, 24 Jul 2008 08:57:25 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1247C8FC19 for ; Thu, 24 Jul 2008 08:57:24 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so2027083fkk.11 for ; Thu, 24 Jul 2008 01:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=jxDRyaHaIl0yUGNfl2I70y+k/JG/f9bME7EBKylL3Tg=; b=QmIdCI1B6Zyq78C2wa7YngXSB+tlkTOBdx48CUOuYR9H4gHrQ74sFHp96CiJAlRbrC doXCmTNtEPK6XRTQieaD0z6wtfBy6lD2cfZyVuoE86SJ7cP3M2H9zS87WA0rsvvV4E+q dQqly9hpHtqOZVpdVpaephWhE5JrdOcUArQAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=TKdHUfotyJeIn0RLF3FuqycddYFBihJWJ7wCjVwwnHg4I3iTXBuYvfxVIKg9okqGnQ PnSo26AoJBOCB/mg7y2shjkPQQae4QsULoodsRMDQp1FI8WrC3t+5obuzCAai1m9VCr9 1ZfMylVwmXo622/SSE7L2tLnLRf1H7Ojony34= Received: by 10.125.142.5 with SMTP id u5mr47037mkn.126.1216889843213; Thu, 24 Jul 2008 01:57:23 -0700 (PDT) Received: by 10.125.139.12 with HTTP; Thu, 24 Jul 2008 01:57:23 -0700 (PDT) Message-ID: <3c1674c90807240157l58c935c2r945d894193502b1f@mail.gmail.com> Date: Thu, 24 Jul 2008 01:57:23 -0700 From: "Kip Macy" Sender: mat.macy@gmail.com To: "Robert Watson" In-Reply-To: <20080724084240.C63347@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c1674c90807201514o5bafba72r6be84de6e37a5525@mail.gmail.com> <20080724084240.C63347@fledge.watson.org> X-Google-Sender-Auth: 71f50d4084d7f9bc Cc: freebsd-net@freebsd.org Subject: Re: moving sockbuf in to its own header X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 08:57:25 -0000 Thanks for the follow-up. On Thu, Jul 24, 2008 at 12:54 AM, Robert Watson wrote: > > On Sun, 20 Jul 2008, Kip Macy wrote: > >> Actually, I'd like to re-factor multiple parts of socketvar in to separate >> files. >> >> Please provide feedback on the following: >> >> http://www.fsmware.com/socketvar_refactor.diff > > This seems like a fairly disruptive change from the perpective of managing > future MFCs, and likewise makes it quite a bit harder to diff branches and > make sure things haven't been missed. That said, I'm not entirely opposed > to it, since I think this decomposition is a fairly reasonable one. Do make > sure you've done a complete make universe to hit all the user consumers, > such as netstat, etc, that grub around in the kernel parts and make sure > there are no surprises. A few comments: > > - Please propagate the copyright/license from socketvar.h to all derived new > files. > - You seem to have a lot of extra blank lines -- generally speaking, at most > one blank line between pieces of code/comments/etc is required. > - The new include files seem not to have forward declarations of the structs > referenced from other structures, so in practice you may find that > including > one requires including the others. Fixing this is easy and, at the very > least, non-harmful. It would also lay the way towards not doing nested > includes of various includes from socketvar.h in the future. > - One of the elements of the BSD style(9) I don't like is the tab between > "struct" and "structname" for fields in older structures. Perhaps this is > why I notice that it isn't there in the new struct sockbuf line in struct > socket, and likewise xsockbuf in xsocket :-) > > If you do make this change, check in with Peter about whether we now prefer > the use of svn copy. > > Robert N M Watson > Computer Laboratory > University of Cambridge > >> >> Thanks, >> Kip >> >> >> On Sun, Jul 20, 2008 at 3:14 PM, Kip Macy wrote: >>> >>> TOE drivers need to be able to directly enqueue data in to a socket >>> buffer and thus benefit from having knowledge of sockbuf internals. >>> However, there is no need for them to know about other socket >>> definitions. Thus I would like to move sockbuf and accompanying >>> definitions to their own header. >>> >>> This is a fairly straightforward change so I don't really see the need >>> to wait more than a few days for feedback: >>> >>> http://www.fsmware.com/sockbuf.h.diff >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 14:28:26 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 907221065670; Thu, 24 Jul 2008 14:28:26 +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 88E3B8FC12; Thu, 24 Jul 2008 14:28:26 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6OESQX1045482; Thu, 24 Jul 2008 14:28:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6OESQUj045478; Thu, 24 Jul 2008 14:28:26 GMT (envelope-from linimon) Date: Thu, 24 Jul 2008 14:28:26 GMT Message-Id: <200807241428.m6OESQUj045478@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/125922: [patch] Deadlock in arp(8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 14:28:26 -0000 Old Synopsis: [patch] Deadlock in arp New Synopsis: [patch] Deadlock in arp(8) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 24 14:28:08 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125922 From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 15:14:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B552106566B for ; Thu, 24 Jul 2008 15:14:41 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4D2168FC12 for ; Thu, 24 Jul 2008 15:14:41 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 90B6F5ED9; Thu, 24 Jul 2008 18:57:47 +0400 (MSD) Date: Thu, 24 Jul 2008 18:56:10 +0400 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20080724145610.GA57814@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Julian Elischer Subject: FIB MFC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 15:14:41 -0000 Julian, thank you for FIB. I have tried in on FreeBSD-7. I've found that ipfw does not know about setfib: ipfw: invalid action setfib Therefore I've added missing part from CURRENT. Then I have tried the following configuration: vlan1: 10.0.0.100 vlan2: 192.168.1.100 route add default 10.0.0.1 setfib 1 route add default 192.168.1.1 ipfw add setfib 1 ip from any to any in via vlan2 I expected that outgoing packets of TCP connection established via vlan2 will be routed to 192.168.1.1, but this did not happen. The packets went to 10.0.0.1 via vlan1: tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD Can TCP connection inherit FIB from first SYN packet or not ? -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 15:33:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EF201065671 for ; Thu, 24 Jul 2008 15:33:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED908FC13 for ; Thu, 24 Jul 2008 15:33:35 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 653DD2370; Thu, 24 Jul 2008 08:33:35 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3A3562D6042; Thu, 24 Jul 2008 08:33:34 -0700 (PDT) Message-ID: <4888A0B5.4060302@elischer.org> Date: Thu, 24 Jul 2008 08:33:09 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Igor Sysoev References: <20080724145610.GA57814@rambler-co.ru> In-Reply-To: <20080724145610.GA57814@rambler-co.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FIB MFC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 15:33:35 -0000 Igor Sysoev wrote: > Julian, thank you for FIB. I have tried in on FreeBSD-7. > > I've found that ipfw does not know about setfib: > ipfw: invalid action setfib > Oh I have not finished MFC.. will finish today.. the svn server crashed last night .. :-/ (or at least went very strange) while I was working on this so I went to bed. > Therefore I've added missing part from CURRENT. > Then I have tried the following configuration: > > vlan1: 10.0.0.100 > vlan2: 192.168.1.100 > > route add default 10.0.0.1 > setfib 1 route add default 192.168.1.1 > ipfw add setfib 1 ip from any to any in via vlan2 > > I expected that outgoing packets of TCP connection established > via vlan2 will be routed to 192.168.1.1, but this did not happen. > The packets went to 10.0.0.1 via vlan1: no, while this doesmake sense, the fib is only used for outgoing packets and the fib of local sockets is set by the process that opens the socket. (either with setfib(2) or sockopt(SETFIB)) I was thinking that it might be possible to tag a socket to accept the fib of the packet coming in, but if we do this, we should decide API to label a socket in this way.. It is a n execellent idea however, and I don't know why I didn't do it already.. > > tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD > tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD > tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD > > Can TCP connection inherit FIB from first SYN packet or not ? no but it is a good idea. > > From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 16:33:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25A42106567C for ; Thu, 24 Jul 2008 16:33:07 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id DBDAC8FC08 for ; Thu, 24 Jul 2008 16:33:06 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 8FB6262A1; Thu, 24 Jul 2008 20:33:05 +0400 (MSD) Date: Thu, 24 Jul 2008 20:31:28 +0400 From: Igor Sysoev To: Julian Elischer Message-ID: <20080724163128.GE57814@rambler-co.ru> References: <20080724145610.GA57814@rambler-co.ru> <4888A0B5.4060302@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4888A0B5.4060302@elischer.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org Subject: Re: FIB MFC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 16:33:07 -0000 On Thu, Jul 24, 2008 at 08:33:09AM -0700, Julian Elischer wrote: > Igor Sysoev wrote: > >Julian, thank you for FIB. I have tried in on FreeBSD-7. > > > >I've found that ipfw does not know about setfib: > >ipfw: invalid action setfib > > > > Oh I have not finished MFC.. > will finish today.. > > the svn server crashed last night .. :-/ > (or at least went very strange) while I was working on this so I > went to bed. > > > > >Therefore I've added missing part from CURRENT. > >Then I have tried the following configuration: > > > >vlan1: 10.0.0.100 > >vlan2: 192.168.1.100 > > > >route add default 10.0.0.1 > >setfib 1 route add default 192.168.1.1 > >ipfw add setfib 1 ip from any to any in via vlan2 > > > >I expected that outgoing packets of TCP connection established > >via vlan2 will be routed to 192.168.1.1, but this did not happen. > >The packets went to 10.0.0.1 via vlan1: > > no, while this doesmake sense, the fib is only used for outgoing > packets and the fib of local sockets is set by the process that opens > the socket. (either with setfib(2) or sockopt(SETFIB)) > > I was thinking that it might be possible to tag a socket to accept the > fib of the packet coming in, but if we do this, we should decide > API to label a socket in this way.. I think it should be sysctl to globaly enable TCP FIB inheritance. API is already exists: sockopt(SO_SETFIB) for listening socket. > It is a n execellent idea however, and I don't know why I didn't > do it already.. > > > > >tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD > >tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD > >tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD > > > >Can TCP connection inherit FIB from first SYN packet or not ? > > no but it is a good idea. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 16:44:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5BAE1065684 for ; Thu, 24 Jul 2008 16:44:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outa.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id 96E638FC24 for ; Thu, 24 Jul 2008 16:44:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id CAAF62411; Thu, 24 Jul 2008 09:44:40 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id E41DD2D6049; Thu, 24 Jul 2008 09:44:39 -0700 (PDT) Message-ID: <4888B15F.7060704@elischer.org> Date: Thu, 24 Jul 2008 09:44:15 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Igor Sysoev References: <20080724145610.GA57814@rambler-co.ru> <4888A0B5.4060302@elischer.org> <20080724163128.GE57814@rambler-co.ru> In-Reply-To: <20080724163128.GE57814@rambler-co.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FIB MFC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 16:44:40 -0000 Igor Sysoev wrote: > On Thu, Jul 24, 2008 at 08:33:09AM -0700, Julian Elischer wrote: > >> I was thinking that it might be possible to tag a socket to accept the >> fib of the packet coming in, but if we do this, we should decide >> API to label a socket in this way.. > > I think it should be sysctl to globaly enable TCP FIB inheritance. > API is already exists: sockopt(SO_SETFIB) for listening socket. But a socket ALWAYS has a fib, even if you do nothing because every process has a fib (usually 0) so you need a new bit of state somewhere that means "inherit". (I guess in the socket flags). Possibly the FIB value of -1 when applied on a socket option might signify that behaviour. (thus save us a new sockopt). But such a value would revert to that of the process if the socket was not used as a listen socket. (or clear itself). I have some MRT unhansements in hte pipeline and will include this if I can. BTW could you send me the diff for ipfw(8)? I'll compare it with the one I'm about to commit. > >> It is an excellent idea however, and I don't know why I didn't >> do it already.. >> >>> tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD >>> tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD >>> tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD >>> >>> Can TCP connection inherit FIB from first SYN packet or not ? >> no but it is a good idea. > > From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 16:52:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC12F1065671 for ; Thu, 24 Jul 2008 16:52:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id AD09F8FC16 for ; Thu, 24 Jul 2008 16:52:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 84FB22414; Thu, 24 Jul 2008 09:52:43 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 22C422D6034; Thu, 24 Jul 2008 09:52:43 -0700 (PDT) Message-ID: <4888B342.10204@elischer.org> Date: Thu, 24 Jul 2008 09:52:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Igor Sysoev References: <20080724145610.GA57814@rambler-co.ru> <4888A0B5.4060302@elischer.org> <20080724163128.GE57814@rambler-co.ru> <4888B15F.7060704@elischer.org> In-Reply-To: <4888B15F.7060704@elischer.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FIB MFC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 16:52:43 -0000 Julian Elischer wrote: > Igor Sysoev wrote: >> On Thu, Jul 24, 2008 at 08:33:09AM -0700, Julian Elischer wrote: >> > > >>> I was thinking that it might be possible to tag a socket to accept >>> the fib of the packet coming in, but if we do this, we should decide >>> API to label a socket in this way.. >> >> I think it should be sysctl to globaly enable TCP FIB inheritance. >> API is already exists: sockopt(SO_SETFIB) for listening socket. > > But a socket ALWAYS has a fib, even if you do nothing > because every process has a fib (usually 0) > so you need a new bit of state somewhere that means "inherit". > (I guess in the socket flags). alternatively a process characteristic, so that naive programs can be made to act that way. (inheritted by the sockets). > > Possibly the FIB value of -1 when applied on a socket option might > signify that behaviour. (thus save us a new sockopt). > But such a value would revert to that of the process if the socket was > not used as a listen socket. (or clear itself). > > I have some MRT unhansements in hte pipeline and will include this if > I can. > > BTW could you send me the diff for ipfw(8)? > I'll compare it with the one I'm about to commit. > > >> >>> It is an excellent idea however, and I don't know why I didn't >>> do it already.. >>> >>>> tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD >>>> tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD >>>> tcp4 0 0 192.168.1.100.80 XXXXXXXXXX SYN_RCVD >>>> >>>> Can TCP connection inherit FIB from first SYN packet or not ? >>> no but it is a good idea. >> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 18:01:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 820ED1065674 for ; Thu, 24 Jul 2008 18:01:25 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 45F088FC19 for ; Thu, 24 Jul 2008 18:01:25 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id DFCB85F04; Thu, 24 Jul 2008 22:01:23 +0400 (MSD) Date: Thu, 24 Jul 2008 21:59:46 +0400 From: Igor Sysoev To: Julian Elischer Message-ID: <20080724175946.GA60773@rambler-co.ru> References: <20080724145610.GA57814@rambler-co.ru> <4888A0B5.4060302@elischer.org> <20080724163128.GE57814@rambler-co.ru> <4888B15F.7060704@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4888B15F.7060704@elischer.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org Subject: Re: FIB MFC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 18:01:25 -0000 On Thu, Jul 24, 2008 at 09:44:15AM -0700, Julian Elischer wrote: > Igor Sysoev wrote: > >On Thu, Jul 24, 2008 at 08:33:09AM -0700, Julian Elischer wrote: > > > > > >>I was thinking that it might be possible to tag a socket to accept the > >>fib of the packet coming in, but if we do this, we should decide > >>API to label a socket in this way.. > > > >I think it should be sysctl to globaly enable TCP FIB inheritance. > >API is already exists: sockopt(SO_SETFIB) for listening socket. > > But a socket ALWAYS has a fib, even if you do nothing > because every process has a fib (usually 0) > so you need a new bit of state somewhere that means "inherit". > (I guess in the socket flags). I see. > Possibly the FIB value of -1 when applied on a socket option might > signify that behaviour. (thus save us a new sockopt). > But such a value would revert to that of the process if the socket was > not used as a listen socket. (or clear itself). -1 is good variant. > I have some MRT unhansements in hte pipeline and will include this if > I can. > > BTW could you send me the diff for ipfw(8)? > I'll compare it with the one I'm about to commit. This is exactly your already commited 1.108.2.9 -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Jul 24 23:42:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 082851065673 for ; Thu, 24 Jul 2008 23:42:56 +0000 (UTC) (envelope-from babolo@cicuta.babolo.ru) Received: from ints.mail.pike.ru (ints.mail.pike.ru [85.30.199.194]) by mx1.freebsd.org (Postfix) with ESMTP id 346A28FC1E for ; Thu, 24 Jul 2008 23:42:54 +0000 (UTC) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 27079 invoked from network); 24 Jul 2008 23:42:53 -0000 Received: from cicuta.babolo.ru (85.30.229.5) by ints.mail.pike.ru with SMTP; 24 Jul 2008 23:42:53 -0000 Received: (nullmailer pid 32649 invoked by uid 136); Thu, 24 Jul 2008 23:42:49 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <48874C7C.5070402@samoylyk.sumy.ua> To: Oleksandr Samoylyk Date: Fri, 25 Jul 2008 03:42:49 +0400 (MSD) From: .@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1216942969.767893.32648.nullmailer@cicuta.babolo.ru> Cc: freebsd-net@freebsd.org, damien.deville@netasq.com Subject: Re: proxy-arp & mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2008 23:42:56 -0000 [ Charset KOI8-U unsupported, converting... ] > Damien Deville wrote: > > Hi, > > > > we are facing a similar issue with arp blocked in sbwait state. > > > > Here is a way to reproduce it: > > - add a bunch of arp entries in your arp table (best is around 255 > > entries). > > - launch two arp -a -d in parallel ('arp -a -d & arp -a -d &') > > > > Both processes will be in concurence to access the table. One process > > will successfully nuke all entries of the arp table, the other one will > > be blocked in rtmsg function on the read while executing a RTM_GET or > > RTM_DELETE command after some time. By instrumenting arp we noticed that > > it happened when both process access to the same entry. > > > > Here is a backtrace of the blocked arp on FreeBSD 7.0 > > > > (gdb) bt > > #0 0x28158f81 in read () from /lib/libc.so.7 > > #1 0x08049091 in rtmsg () > > #2 0x08049b44 in delete () > > #3 0x0804a1fd in nuke_entry () > > #4 0x08049a77 in search () > > #5 0x08049e75 in main () > > > > I can reproduce this on FreeBSD 4.11, 6.2 and 6.3, and FreeBSD 7.0. > > Any workaround so far? Another dirty hack http://free.babolo.ru/patch/src.usr.sbin.arp.patch (for FreeBSD 4) http://free.babolo.ru/patch6/src.usr.sbin.arp.patch (for FreeBSD 6) http://free.babolo.ru/patch7/src.usr.sbin.arp.patch (for FreeBSD 7) From owner-freebsd-net@FreeBSD.ORG Fri Jul 25 20:33:46 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC1461065676; Fri, 25 Jul 2008 20:33:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8BD418FC13; Fri, 25 Jul 2008 20:33:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6PKXkpH037244; Fri, 25 Jul 2008 20:33:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6PKXkJQ037240; Fri, 25 Jul 2008 20:33:46 GMT (envelope-from linimon) Date: Fri, 25 Jul 2008 20:33:46 GMT Message-Id: <200807252033.m6PKXkJQ037240@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/125920: [arp] Kernel Routing Table loses Ethernet LInk status for vlan, but not for alias X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2008 20:33:46 -0000 Old Synopsis: Kernel Routing Table loses Ethernet LInk status for vlan, but not for alias New Synopsis: [arp] Kernel Routing Table loses Ethernet LInk status for vlan, but not for alias Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 25 20:33:01 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125920 From owner-freebsd-net@FreeBSD.ORG Sat Jul 26 14:50:09 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 262D61065672 for ; Sat, 26 Jul 2008 14:50:09 +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 168358FC08 for ; Sat, 26 Jul 2008 14:50:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m6QEo3rr079320 for ; Sat, 26 Jul 2008 14:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m6QEo32V079319; Sat, 26 Jul 2008 14:50:03 GMT (envelope-from gnats) Date: Sat, 26 Jul 2008 14:50:03 GMT Message-Id: <200807261450.m6QEo32V079319@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Stephan Eisvogel Cc: Subject: Re: kern/125816: [carp] [bridge] carp stuck in init when using bridge interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephan Eisvogel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 14:50:09 -0000 The following reply was made to PR kern/125816; it has been noted by GNATS. From: Stephan Eisvogel To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/125816: [carp] [bridge] carp stuck in init when using bridge interface Date: Sat, 26 Jul 2008 16:40:08 +0200 For the ADHS crowd: Using a bridge as carped device adds ~900ms to configured advertising interval. A chap from bsdforums has sent me a note that layer 2 failover is best done with spanning tree and not carp but as I explained I am not trying to cluster filtering bridges but cluster routers that happen to have a bridge sitting on top (in my case an Ethernet 10/100 vr(4) and an Atheros card ath(4) bridged to create a wireless access point). I am back to 7-STABLE and also now have carpdev patch by max in kernel which I just merged into fib changes of julian. Because if it's broken why not brake it some more while at it... Using another PC with wireshark as reference I measured the inter packet gap of the announcements when carping the bridge and a setting of advbase 1 advskew 0 delivers 1.950s intervals instead of 1.000s as expected. When I up the advbase value to 3 the master will announce every 3.950s so the effect appears to be an offset and not multiplicative. It also does not appear to matter how many devices are attached to the bridge. The moment I set the carped interface to a physical interface announcement interval will come down to the correct 3.010s interval. I measured ping delay to exclude the possibility of the Alix' hardware timer running at wrong speed but inter packet gap was very near 1s for a default ping. I'll be trying to nail the thinko or bug and submit a patch but because I never tweaked the carp or bridge code don't bet on it... From owner-freebsd-net@FreeBSD.ORG Sat Jul 26 16:28:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22F4E106567C for ; Sat, 26 Jul 2008 16:28:45 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 743AD8FC1E for ; Sat, 26 Jul 2008 16:28:43 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m6QGSf5E012966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 Jul 2008 18:28:41 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m6QGSbV2091705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jul 2008 18:28:37 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m6QGSbXa075625; Sat, 26 Jul 2008 18:28:37 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m6QGSbk4075624; Sat, 26 Jul 2008 18:28:37 +0200 (CEST) (envelope-from ticso) Date: Sat, 26 Jul 2008 18:28:37 +0200 From: Bernd Walter To: freebsd-net@freebsd.org Message-ID: <20080726162836.GB75357@cicely7.cicely.de> References: <20080718135931.GA48087@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080718135931.GA48087@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.128, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Bernd Walter Subject: (syncookckie bug?) Re: TCP zombie connections with 7-RELEASE and STABLE from 15th june X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2008 16:28:45 -0000 After sysctl net.inet.tcp.syncookies=0 the problem is not reproduceable anymore. But of course I'm not entirely happy with disabling syncookies, so this is not a good workaround. On Fri, Jul 18, 2008 at 03:59:31PM +0200, Bernd Walter wrote: > 14:45:58.109631 IP 213.83.6.106.3270 > 85.159.14.110.443: S 470580731:470580731(0) win 32768 > 14:45:58.109753 IP 85.159.14.110.443 > 213.83.6.106.3270: S 1364510055:1364510055(0) ack 470580732 win 65535 > 14:45:58.114324 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 1 win 33304 > 14:45:59.816810 IP 213.83.6.106.3270 > 85.159.14.110.443: F 1:1(0) ack 1 win 33304 > 14:45:59.816900 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 2 win 8326 > 14:45:59.818445 IP 85.159.14.110.443 > 213.83.6.106.3270: F 1:1(0) ack 2 win 8326 > 14:45:59.822859 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.415401 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 1 win 0 > 14:46:00.420082 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.420139 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.424772 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.424847 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.429065 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.429089 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.433247 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.433305 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.437641 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.437700 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.442408 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.442445 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.447231 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.447291 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.451525 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.451587 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.455957 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.456024 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.460666 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.460732 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:00.465092 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:00.465150 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > [...] > 14:46:31.182624 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:31.182978 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:31.183006 IP 85.159.14.110.443 > 213.83.6.106.3270: . ack 1 win 65535 > 14:46:31.183146 IP 85.159.14.110.443 > 213.83.6.106.3270: F 1:1(0) ack 1 win 65535 > 14:46:31.183173 IP 85.159.14.110.443 > 213.83.6.106.3270: F 1:1(0) ack 1 win 65535 > 14:46:31.184038 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:31.184124 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:31.184157 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:31.184740 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:31.185174 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:31.186762 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:31.187366 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:31.187380 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > 14:46:31.187573 IP 213.83.6.106.3270 > 85.159.14.110.443: . ack 2 win 33303 > > 443 is a self written server, but it also happens with port 80 and > sslproxy. > The client is a telnet, which disconnects directly after connecting, > so the disconnect is initiated from the client, which seems to be > important for this problem to trigger. > > You can see that the FIN handshake completes and netstat on the > client box shows the connection in TIME_WAIT. > The server however has the connection still in ESTABLISHED state. > > What happens in the application code looks quite silly. > I do a typical accept loop and then I process the data in a > new thread. > After my thread terminates and closes it's filedescriptor the select > loop accepts the old connection again. > This doesn't happen in every case but almost always. > Finally after 30 seconds without data to read my newly created thread > closes the zombie connection again. > > The question is why accept returns me a filedescriptor for a connection > which was already returned and should have been closed? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.