From owner-freebsd-net@FreeBSD.ORG Sun Aug 26 05:12:54 2007 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 8F04B16A418 for ; Sun, 26 Aug 2007 05:12:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with SMTP id 375D013C459 for ; Sun, 26 Aug 2007 05:12:54 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 19663 invoked by uid 399); 26 Aug 2007 04:46:13 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 26 Aug 2007 04:46:13 -0000 X-Originating-IP: 127.0.0.1 Date: Sat, 25 Aug 2007 21:46:11 -0700 (PDT) From: Doug Barton To: Henri Hennebert In-Reply-To: <46CD8CD3.9090109@restart.be> Message-ID: References: <46CD8CD3.9090109@restart.be> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii Cc: freebsd-net@freebsd.org Subject: Re: Wrong order in rc.d (pf and ipv6) 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, 26 Aug 2007 05:12:54 -0000 On Thu, 23 Aug 2007, Henri Hennebert wrote: > Hello, > > I notice that after a reboot, my pf rules don't take the ipv6 address > (managed with ipv6_ifconfig_rl0="2001:...:1") into account. > > rcorder /etc/rc.d/* show that pf is started before network_ipv6, is it > normal? The consensus was that all firewalls should be started before all interfaces. That way a system will come up protected with no window of vulnerability. That said, I'm glad someone was able to help you fix your stuff. :) Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sun Aug 26 06:58:01 2007 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 BC18316A417 for ; Sun, 26 Aug 2007 06:58:01 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 457A713C428 for ; Sun, 26 Aug 2007 06:58:01 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 14315 invoked from network); 26 Aug 2007 01:58:01 -0500 Received: from 124-170-52-85.dyn.iinet.net.au (HELO localhost) (124.170.52.85) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Aug 2007 01:58:00 -0500 Date: Sun, 26 Aug 2007 16:57:57 +1000 From: Norberto Meijome To: FreeBSD Net ML Message-ID: <20070826165757.647ecc72@localhost> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Netgraph node to replace packet contents? 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, 26 Aug 2007 06:58:01 -0000 hi all, is there any already existing Netgraph node that would allow me to replace bytes in the data part of a packet? I'm talking about generic "foo" for "BAR" replacement, though different lengths would be good too. or maybe other tool can do this too? thanks! B _________________________ {Beto|Norberto|Numard} Meijome Without vision you may find that you make your way through life by bumping into things. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Sun Aug 26 12:50:09 2007 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 030C716A418 for ; Sun, 26 Aug 2007 12: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 CB40D13C45B for ; Sun, 26 Aug 2007 12:50:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7QCo8LG048591 for ; Sun, 26 Aug 2007 12:50:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7QCo8dc048586; Sun, 26 Aug 2007 12:50:08 GMT (envelope-from gnats) Date: Sun, 26 Aug 2007 12:50:08 GMT Message-Id: <200708261250.l7QCo8dc048586@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Frank Behrens" Cc: Subject: Re: kern/113359: panic sbdrop after ICMP6, packet too big X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Behrens List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2007 12:50:09 -0000 The following reply was made to PR kern/113359; it has been noted by GNATS. From: "Frank Behrens" To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: kern/113359: panic sbdrop after ICMP6, packet too big Date: Sun, 26 Aug 2007 14:26:35 +0200 The bug is probably a duplicate of PR 99779 and was fixed on RELENG_6 with src/sys/kern/uipc_socket.c: 1.280. From owner-freebsd-net@FreeBSD.ORG Sun Aug 26 14:05:16 2007 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 929C016A420 for ; Sun, 26 Aug 2007 14:05:16 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1643113C457 for ; Sun, 26 Aug 2007 14:05:15 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 28821471; Sun, 26 Aug 2007 15:55:14 +0300 Message-ID: <46D17813.8090205@FreeBSD.org> Date: Sun, 26 Aug 2007 15:54:43 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norberto Meijome References: <1188123847.00792375.1188111626@10.7.7.3> In-Reply-To: <1188123847.00792375.1188111626@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net ML Subject: Re: Netgraph node to replace packet contents? 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, 26 Aug 2007 14:05:16 -0000 Hi. Norberto Meijome wrote: > is there any already existing Netgraph node that would allow me to replace bytes in the data part of a packet? I'm talking about generic "foo" for "BAR" replacement, though different lengths would be good too. There is no such node. This is not an easy task to alter some abstract packet. Even in simpliest case you should take into account TCP/UDP checksumms. There could be problems with fragmented packets. In more complicated cases may be required other modifications. To replace string with different length one you should also correct packet length. It is possible for UDP (except for the not first packet fragments), but for TCP it is probably completely impossible without doing complete TCP proxying to modify sequence numbers. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Sun Aug 26 16:47:49 2007 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 27D1716A4CF for ; Sun, 26 Aug 2007 16:47:49 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id BD3A713C442 for ; Sun, 26 Aug 2007 16:47:48 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fk-out-0910.google.com with SMTP id b27so1641098fka for ; Sun, 26 Aug 2007 09:47:47 -0700 (PDT) Received: by 10.82.178.11 with SMTP id a11mr10797276buf.1188145187242; Sun, 26 Aug 2007 09:19:47 -0700 (PDT) Received: by 10.82.162.16 with HTTP; Sun, 26 Aug 2007 09:19:47 -0700 (PDT) Message-ID: Date: Sun, 26 Aug 2007 19:19:47 +0300 From: "Vlad GALU" To: "Norberto Meijome" In-Reply-To: <20070826165757.647ecc72@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070826165757.647ecc72@localhost> Cc: FreeBSD Net ML Subject: Re: Netgraph node to replace packet contents? 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, 26 Aug 2007 16:47:49 -0000 On 8/26/07, Norberto Meijome wrote: > hi all, > is there any already existing Netgraph node that would allow me to replace bytes in the data part of a packet? I'm talking about generic "foo" for "BAR" replacement, though different lengths would be good too. > > or maybe other tool can do this too? > ports/netsed + pf/ipf (for transparent proxying) Of course, the overhead is big. > thanks! > B > _________________________ > {Beto|Norberto|Numard} Meijome > > Without vision you may find that you make your way through life by bumping into things. > > I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. > _______________________________________________ > 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" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Sun Aug 26 17:53:55 2007 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 9E98F16A41B; Sun, 26 Aug 2007 17:53:55 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 79D6913C459; Sun, 26 Aug 2007 17:53:55 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7QHrtI9065055; Sun, 26 Aug 2007 17:53:55 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7QHrsT7065051; Sun, 26 Aug 2007 17:53:54 GMT (envelope-from remko) Date: Sun, 26 Aug 2007 17:53:54 GMT Message-Id: <200708261753.l7QHrsT7065051@freefall.freebsd.org> To: frank@pinky.sax.de, remko@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/113359: [ipv6] panic sbdrop after ICMP6, packet too big 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, 26 Aug 2007 17:53:55 -0000 Synopsis: [ipv6] panic sbdrop after ICMP6, packet too big State-Changed-From-To: open->closed State-Changed-By: remko State-Changed-When: Sun Aug 26 17:53:54 UTC 2007 State-Changed-Why: Duplicate of 99779, which was fixed on RELENG_6 with: src/sys/kern/uipc_socket.c: 1.280 (thanks frank for the feedback!) http://www.freebsd.org/cgi/query-pr.cgi?pr=113359 From owner-freebsd-net@FreeBSD.ORG Sun Aug 26 23:55:57 2007 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 DC87E16A419 for ; Sun, 26 Aug 2007 23:55:57 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 914A713C442 for ; Sun, 26 Aug 2007 23:55:57 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 14732 invoked from network); 26 Aug 2007 18:55:55 -0500 Received: from 124-170-104-118.dyn.iinet.net.au (HELO localhost) (124.170.104.118) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Aug 2007 18:55:54 -0500 Date: Mon, 27 Aug 2007 09:55:50 +1000 From: Norberto Meijome To: Alexander Motin Message-ID: <20070827095550.0be62785@localhost> In-Reply-To: <46D17813.8090205@FreeBSD.org> References: <1188123847.00792375.1188111626@10.7.7.3> <46D17813.8090205@FreeBSD.org> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Net ML Subject: Re: Netgraph node to replace packet contents? 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, 26 Aug 2007 23:55:57 -0000 On Sun, 26 Aug 2007 15:54:43 +0300 Alexander Motin wrote: > Hi. > > Norberto Meijome wrote: > > is there any already existing Netgraph node that would allow me to replace bytes in the data part of a packet? I'm talking about generic "foo" for "BAR" replacement, though different lengths would be good too. > > There is no such node. > > This is not an easy task to alter some abstract packet. Even in > simpliest case you should take into account TCP/UDP checksumms. Yes, of course. > There > could be problems with fragmented packets. In more complicated cases may > be required other modifications. yes..i had thought of this > > To replace string with different length one you should also correct > packet length. It is possible for UDP (except for the not first packet > fragments), but for TCP it is probably completely impossible without > doing complete TCP proxying to modify sequence numbers. yes, TCP keeps rearing its problematic head ;) Anyway, thanks a lot for the insights :) B _________________________ {Beto|Norberto|Numard} Meijome Law of Conservation of Perversity: we can't make something simpler without making something else more complex I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Sun Aug 26 23:56:24 2007 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 EEE5F16A541 for ; Sun, 26 Aug 2007 23:56:24 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id A332113C45A for ; Sun, 26 Aug 2007 23:56:24 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 14796 invoked from network); 26 Aug 2007 18:56:24 -0500 Received: from 124-170-104-118.dyn.iinet.net.au (HELO localhost) (124.170.104.118) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Aug 2007 18:56:24 -0500 Date: Mon, 27 Aug 2007 09:56:19 +1000 From: Norberto Meijome To: "Vlad GALU" Message-ID: <20070827095619.61b58c7e@localhost> In-Reply-To: References: <20070826165757.647ecc72@localhost> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Net ML Subject: Re: Netgraph node to replace packet contents? 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, 26 Aug 2007 23:56:25 -0000 On Sun, 26 Aug 2007 19:19:47 +0300 "Vlad GALU" wrote: > ports/netsed + pf/ipf (for transparent proxying) > Of course, the overhead is big. great, thanks , that may do - i may only need it for a proof of concept at this time. cheers, B _________________________ {Beto|Norberto|Numard} Meijome "I didn't attend the funeral, but I sent a nice letter saying I approved of it." Mark Twain I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 02:09:22 2007 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 F161916A41A for ; Mon, 27 Aug 2007 02:09:22 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from zombie.scms.waikato.ac.nz (mail.scms.waikato.ac.nz [130.217.241.36]) by mx1.freebsd.org (Postfix) with ESMTP id AC6BC13C46C for ; Mon, 27 Aug 2007 02:09:22 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from sorcerer.cs.waikato.ac.nz ([130.217.250.39]) by zombie.scms.waikato.ac.nz with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52) id 1IPTLb-0002wX-1i for freebsd-net@freebsd.org; Mon, 27 Aug 2007 13:24:55 +1200 Message-ID: <46D227E6.9070100@luckie.org.nz> Date: Mon, 27 Aug 2007 13:24:54 +1200 From: Matthew Luckie User-Agent: Thunderbird 2.0.0.6 (X11/20070804) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: BPF divide instruction 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, 27 Aug 2007 02:09:23 -0000 BPF includes a divide instruction. As best I can tell, libpcap does not ever output a BPF divide instruction, which indicates that use of the BPF divide instruction is probably going to be done with a BPF program created by hand. Can anyone provide any examples of a BPF program where a divide instruction is used? Thanks Matthew From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 03:51:10 2007 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 E5C2416A420; Mon, 27 Aug 2007 03:51:10 +0000 (UTC) (envelope-from SRS0=d1fe45abe319685a9442494ac1a0fc6804f994ad=439=es.net=oberman@es.net) Received: from postal1.es.net (postal4.es.net [IPv6:2001:400:6000:1::66]) by mx1.freebsd.org (Postfix) with ESMTP id 190BF13C46C; Mon, 27 Aug 2007 03:51:09 +0000 (UTC) (envelope-from SRS0=d1fe45abe319685a9442494ac1a0fc6804f994ad=439=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id GLA55804; Sun, 26 Aug 2007 20:51:04 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 06A0F45048; Sun, 26 Aug 2007 20:51:03 -0700 (PDT) To: Doug Barton In-Reply-To: Your message of "Sat, 25 Aug 2007 21:46:11 PDT." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1188186662_93527P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 26 Aug 2007 20:51:03 -0700 From: "Kevin Oberman" Message-Id: <20070827035103.06A0F45048@ptavv.es.net> Cc: Henri Hennebert , freebsd-net@freebsd.org Subject: Re: Wrong order in rc.d (pf and ipv6) 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, 27 Aug 2007 03:51:11 -0000 --==_Exmh_1188186662_93527P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sat, 25 Aug 2007 21:46:11 -0700 (PDT) > From: Doug Barton > Sender: owner-freebsd-net@freebsd.org > > On Thu, 23 Aug 2007, Henri Hennebert wrote: > > > Hello, > > > > I notice that after a reboot, my pf rules don't take the ipv6 address > > (managed with ipv6_ifconfig_rl0="2001:...:1") into account. > > > > rcorder /etc/rc.d/* show that pf is started before network_ipv6, is it > > normal? > > The consensus was that all firewalls should be started before all > interfaces. That way a system will come up protected with no window of > vulnerability. That may be consensus, but IPv6 simply can't be run in most environments if the end system can't communicate with NDP at startup time. The situation is essentially the same as trying to start IPv4 with no ARP. (And it is worse if the end system is going to auto-configure its address.) This is a bit of a security conundrum. It looks like a default hole in the firewalls for the critical NDP and maybe RDP will be needed. In the meantime I have had to set IPFIREWALL_DEFAULT_TO_ACCEPT for my systems running IPv6. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1188186662_93527P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG0komkn3rs5h7N1ERAqKiAJ93xh4DNijdxdLtZMRd/r49Lw6BXQCfUS+n Frw6oXnN6SoFbgxmCY7Cs9k= =EfxE -----END PGP SIGNATURE----- --==_Exmh_1188186662_93527P-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 11:08:29 2007 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 5D0D016A4C0 for ; Mon, 27 Aug 2007 11:08:29 +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 3F73E13C467 for ; Mon, 27 Aug 2007 11:08:29 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7RB8SMk020600 for ; Mon, 27 Aug 2007 11:08:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7RB8R1E020596 for freebsd-net@FreeBSD.org; Mon, 27 Aug 2007 11:08:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Aug 2007 11:08:27 GMT Message-Id: <200708271108.l7RB8R1E020596@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 you 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, 27 Aug 2007 11:08:29 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/115360 net [ipv6] IPv6 address and if_bridge don't play well toge 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/21998 net [socket] [patch] ident only for outgoing connections a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit 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/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not 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 IP v4 udp fragmented packet reject o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi 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 19 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network 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/95267 net packet drops periodically appear f 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 kern/103253 net inconsistent behaviour in arp reply of a bridge o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114095 net [carp] carp+pf delay with high state limit o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f 14 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 20:18:09 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 618) id 0367616A418; Mon, 27 Aug 2007 20:18:09 +0000 (UTC) To: freebsd-current@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Date: Mon, 27 Aug 2007 20:18:08 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070827201809.0367616A418@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: Subject: Bug in vr(4) driver 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, 27 Aug 2007 20:18:09 -0000 I recently started writing a driver for the Via Rhine family of chips for VxWorks (they turn up on various x86-based single board systems, and I figured it'd be nice to actually support them out of the box), and along the way, I noticed a subtle bug in the FreeBSD vr(4) driver. The vr_attach() routine unconditionally does this for all supported chips: /* * Windows may put the chip in suspend mode when it * shuts down. Be sure to kick it in the head to wake it * up again. */ VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); The problem is, the VR_STICKHW register is not valid on all Rhine devices. The VT86C100A chip, which is present on the D-Link DFE-530TX boards, doesn't support power management, and its register space is only 128 bytes wide. The VR_STICKHW register offset falls outside this range. This may go unnoticed in most scenarios, but if you happen to have another PCI device in your system which is assigned the register space immediately after that of the Rhine, the vr(4) driver will incorrectly stomp it. In my case, the BIOS on my test board decided to put the register space for my PRO/100 ethernet board right next to the Rhine, and the Rhine driver ended up clobbering the IMR register of the PRO/100 device. (Long story short: the board kept locking up on boot. Took me the better part of the morning suss out why.) The strictly correct thing to do would be to check the PCI config space to make sure the device supports the power management capability and only write to the VR_STICKHW register if it does. A less strictly correct but equally effective thing to do would be: /* * Windows may put the chips that support power management into * suspend mode when it shuts down. Be sure to kick it in the * head to wake it up again. */ if (pci_get_device(dev) != VIA_DEVICEID_RHINE) VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); This is basically the fix I put into my VxWorks driver. I suggest someone update the FreeBSD driver as well. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "If stupidity got us into this, why can't it get us out?" - Mandy ============================================================================= From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 23:05:27 2007 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 868B116A419 for ; Mon, 27 Aug 2007 23:05:27 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: from web43139.mail.sp1.yahoo.com (web43139.mail.sp1.yahoo.com [216.252.121.69]) by mx1.freebsd.org (Postfix) with SMTP id 5C15913C45D for ; Mon, 27 Aug 2007 23:05:27 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: (qmail 7036 invoked by uid 60001); 27 Aug 2007 23:05:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=AhdDDqa1OpfBDPXJGGQmGqkq15UQdaCMy9rQaz3v71ozgmmwO6RmNbmHr0QFGzyOZvVZHLmIAAUJ8Dq6eH3hpldEQuyPnQ6r3j2kOjyK7SHQSODelREfFP2R7Xck+pFzmFtosag77J2ctJBSzS1T8/ejWUqBEuFRUI6zrNlrrhY=; Received: from [69.147.84.254] by web43139.mail.sp1.yahoo.com via HTTP; Mon, 27 Aug 2007 16:05:26 PDT X-Mailer: YahooMailRC/651.48 YahooMailWebService/0.7.134 Date: Mon, 27 Aug 2007 16:05:26 -0700 (PDT) From: Weiguang Shi To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <954767.6972.qm@web43139.mail.sp1.yahoo.com> Subject: nc captures 1024 bytes 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, 27 Aug 2007 23:05:27 -0000 Hi,=0A=0AMy system is FreeBSD 6.2. I sent a UDP datagram of 1464 bytes to p= ort =0A1234 where nc was waiting=0A % nc -n -u -l 1234 >tt=0A=0AAfterwar= ds, the size of tt, however, was only 1024 bytes.=0A=0AI noticed this piec= e of code in nc=0A=0A341 if (uflag) {=0A342 = int rv, plen;=0A343 = char buf[8192];=0A344 struct sockaddr_sto= rage z;=0A345 =0A346 len =3D sizeof(z);=0A3= 47 plen =3D jflag ? 8192 : 1024;=0A348 = rv =3D recvfrom(s, buf, plen, MSG_PEEK,=0A349 = (struct sockaddr *)&z, &len);=0A350 = if (rv < 0)=0A351 = err(1, "recvfrom");=0A=0AWhy 1024 instead of something like 1500= -20-8=3D1472?=0A=0AThanks.=0AWei=0A=0A=0A=0A=0A =0A__________________= __________________________________________________________________=0AMoody = friends. Drama queens. Your life? Nope! - their life, your story. Play Sims= Stories at Yahoo! Games.=0Ahttp://sims.yahoo.com/ From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 23:37:42 2007 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 A81D816A468 for ; Mon, 27 Aug 2007 23:37:42 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: from web43132.mail.sp1.yahoo.com (web43132.mail.sp1.yahoo.com [216.252.121.62]) by mx1.freebsd.org (Postfix) with SMTP id 9336D13C442 for ; Mon, 27 Aug 2007 23:37:42 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: (qmail 94567 invoked by uid 60001); 27 Aug 2007 23:37:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=hfzwIeHl+NfUYunSP21KqwoNjhY7nD6JwNNWQorlPWsvjoFaVFnaP9JuLSFw5a2Pen5AzZAYC0c2DcqnLWAOpO4VtJXD43DKy38qhAzdP9knqlqDeIpQcd42IjtkRoTVPbPfbsGAx66ZJheQGXMPAMCE159B7XTOiVmVgFe5Qsc=; X-YMail-OSG: wus33TkVM1mMSXNJAapcmAk_JgIlFd78.8kcY0rhXwzhlbbx3CvRmys664VeqsMHbUzSfbgXjYbwE0ytSRUd8gmE1qTfmGmYOfF5E6qAICboq7kuK2Q8YOcnUQwsEQ-- Received: from [69.147.84.254] by web43132.mail.sp1.yahoo.com via HTTP; Mon, 27 Aug 2007 16:37:40 PDT X-Mailer: YahooMailRC/651.48 YahooMailWebService/0.7.134 Date: Mon, 27 Aug 2007 16:37:40 -0700 (PDT) From: Weiguang Shi To: Weiguang Shi , freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <43862.94241.qm@web43132.mail.sp1.yahoo.com> Cc: Subject: Re: nc captures 1024 bytes 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, 27 Aug 2007 23:37:42 -0000 To get the larger packets, I have to fix another hard-coded "1024" =0A=0A63= 0 readwrite(int nfd)=0A631 {=0A632 struct pollfd pfd[2];=0A633 = unsigned char buf[8192];=0A634 int n, wfd =3D fileno(stdin);=0A= 635 int lfd =3D fileno(stdout);=0A636 int plen;=0A637 =0A63= 8 plen =3D jflag ? 8192 : 1024;=0A639 =0A=0A----- Original Message = ----=0AFrom: Weiguang Shi =0ATo: freebsd-net@freebsd.org= =0ASent: Monday, August 27, 2007 4:05:26 PM=0ASubject: nc captures 1024 byt= es=0A=0AHi,=0A=0AMy system is FreeBSD 6.2. I sent a UDP datagram of 1464 by= tes to port =0A1234 where nc was waiting=0A % nc -n -u -l 1234 >tt=0A=0A= Afterwards, the size of tt, however, was only 1024 bytes.=0A=0AI noticed t= his piece of code in nc=0A=0A341 if (uflag) {=0A342= int rv, plen;=0A343 = char buf[8192];=0A344 struct sock= addr_storage z;=0A345 =0A346 len =3D sizeof= (z);=0A347 plen =3D jflag ? 8192 : 1024;=0A= 348 rv =3D recvfrom(s, buf, plen, MSG_PEEK,= =0A349 (struct sockaddr *)&z, &len);=0A= 350 if (rv < 0)=0A351 = err(1, "recvfrom");=0A=0AWhy 1024 instead of something l= ike 1500-20-8=3D1472?=0A=0AThanks.=0AWei=0A=0A=0A=0A=0A =0A__________= __________________________________________________________________________= =0AMoody friends. Drama queens. Your life? Nope! - their life, your story. = Play Sims Stories at Yahoo! Games.=0Ahttp://sims.yahoo.com/=0A_____________= __________________________________=0Afreebsd-net@freebsd.org mailing list= =0Ahttp://lists.freebsd.org/mailman/listinfo/freebsd-net=0ATo unsubscribe, = send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A=0A=0A=0A=0A=0A = =0A____________________________________________________________________= ________________=0AGot a little couch potato? =0ACheck out fun summer activ= ities for kids.=0Ahttp://search.yahoo.com/search?fr=3Doni_on_mail&p=3Dsumme= r+activities+for+kids&cs=3Dbz From owner-freebsd-net@FreeBSD.ORG Mon Aug 27 23:46:06 2007 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 5F14516A41B for ; Mon, 27 Aug 2007 23:46:06 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 1FC2513C45B for ; Mon, 27 Aug 2007 23:46:05 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (7tteuvfetalgfa2h@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l7RNk4xb028603; Mon, 27 Aug 2007 16:46:04 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l7RNk4Zh028602; Mon, 27 Aug 2007 16:46:04 -0700 (PDT) (envelope-from jmg) Date: Mon, 27 Aug 2007 16:46:04 -0700 From: John-Mark Gurney To: Weiguang Shi Message-ID: <20070827234604.GU99491@funkthat.com> Mail-Followup-To: Weiguang Shi , freebsd-net@freebsd.org References: <43862.94241.qm@web43132.mail.sp1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43862.94241.qm@web43132.mail.sp1.yahoo.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org Subject: Re: nc captures 1024 bytes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2007 23:46:06 -0000 Weiguang Shi wrote this message on Mon, Aug 27, 2007 at 16:37 -0700: > To get the larger packets, I have to fix another hard-coded "1024" This is also a performance problem on slower machines... nc should be fixed to use larger buffers, maybe to the tune of 64KB if not larger... W/ TSO, doing 64KB writes makes sense as it could send the entire segment off to the card... > 630 readwrite(int nfd) > 631 { > 632 struct pollfd pfd[2]; > 633 unsigned char buf[8192]; > 634 int n, wfd = fileno(stdin); > 635 int lfd = fileno(stdout); > 636 int plen; > 637 > 638 plen = jflag ? 8192 : 1024; > 639 > > ----- Original Message ---- > From: Weiguang Shi > To: freebsd-net@freebsd.org > Sent: Monday, August 27, 2007 4:05:26 PM > Subject: nc captures 1024 bytes > > Hi, > > My system is FreeBSD 6.2. I sent a UDP datagram of 1464 bytes to port > 1234 where nc was waiting > % nc -n -u -l 1234 >tt > > Afterwards, the size of tt, however, was only 1024 bytes. > > I noticed this piece of code in nc > > 341 if (uflag) { > 342 int rv, plen; > 343 char buf[8192]; > 344 struct sockaddr_storage z; > 345 > 346 len = sizeof(z); > 347 plen = jflag ? 8192 : 1024; > 348 rv = recvfrom(s, buf, plen, MSG_PEEK, > 349 (struct sockaddr *)&z, &len); > 350 if (rv < 0) > 351 err(1, "recvfrom"); > > Why 1024 instead of something like 1500-20-8=1472? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 01:03:22 2007 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 CDFB316A417 for ; Tue, 28 Aug 2007 01:03:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 86B8813C457 for ; Tue, 28 Aug 2007 01:03:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2327985waf for ; Mon, 27 Aug 2007 18:03:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=lUFpwrIcYX1wSsYUxMdi7zqkaGOVrhLJmxBNx7jNvFQKsJBgmcuMjc315dT5gJ1VYVPGrHiLAkuvhRUSooTEwcI97taud4qqGMs/Tjeo4BpeQx06O7fX2OFltuyos7pHFh7w8QLI0d+JtQV/ZckWjOhVMWfJVKsYTwq1xEZKoDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=K5UV9g2t3fOd9CRv7lZKMfI6fpeo0iCRa4TbzdgMT+6fRXucnC76bSxamDVQrmPu0xwgs5+vXm9S5eAL0itm8YhU+jlFImzBFjML75zzicZJXA0qjrMr82uOuNSqaS7r8Qjfk+jerr6SlWL52iXZ1IsJIHrPm/LXzMVTiAh89FA= Received: by 10.115.90.1 with SMTP id s1mr3236427wal.1188263001696; Mon, 27 Aug 2007 18:03:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id v37sm9883040wah.2007.08.27.18.03.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2007 18:03:20 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l7S13AP6085766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2007 10:03:11 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l7S13AFG085765; Tue, 28 Aug 2007 10:03:10 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 28 Aug 2007 10:03:10 +0900 From: Pyun YongHyeon To: Bill Paul Message-ID: <20070828010310.GA85263@cdnetworks.co.kr> References: <20070827201809.0367616A418@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20070827201809.0367616A418@hub.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Bug in vr(4) driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 01:03:22 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 27, 2007 at 08:18:08PM +0000, Bill Paul wrote: > > I recently started writing a driver for the Via Rhine family of chips > for VxWorks (they turn up on various x86-based single board systems, > and I figured it'd be nice to actually support them out of the box), > and along the way, I noticed a subtle bug in the FreeBSD vr(4) driver. > > The vr_attach() routine unconditionally does this for all supported > chips: > > /* > * Windows may put the chip in suspend mode when it > * shuts down. Be sure to kick it in the head to wake it > * up again. > */ > VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); > > The problem is, the VR_STICKHW register is not valid on all Rhine > devices. The VT86C100A chip, which is present on the D-Link DFE-530TX > boards, doesn't support power management, and its register space is > only 128 bytes wide. The VR_STICKHW register offset falls outside this > range. This may go unnoticed in most scenarios, but if you happen to have > another PCI device in your system which is assigned the register > space immediately after that of the Rhine, the vr(4) driver will > incorrectly stomp it. In my case, the BIOS on my test board decided > to put the register space for my PRO/100 ethernet board right next > to the Rhine, and the Rhine driver ended up clobbering the IMR register > of the PRO/100 device. (Long story short: the board kept locking up on > boot. Took me the better part of the morning suss out why.) > > The strictly correct thing to do would be to check the PCI config space > to make sure the device supports the power management capability and only > write to the VR_STICKHW register if it does. A less strictly correct > but equally effective thing to do would be: > > /* > * Windows may put the chips that support power management into > * suspend mode when it shuts down. Be sure to kick it in the > * head to wake it up again. > */ > if (pci_get_device(dev) != VIA_DEVICEID_RHINE) > VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); > > This is basically the fix I put into my VxWorks driver. I suggest someone > update the FreeBSD driver as well. > Hi, I don't have vr(4) hardwares(if I had I would have converted vr(4) to use bus_dma(9)). Would you review/test the attached patch? -- Regards, Pyun YongHyeon --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="vr.diff" Index: if_vr.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_vr.c,v retrieving revision 1.126 diff -u -r1.126 if_vr.c --- if_vr.c 23 Apr 2007 12:19:02 -0000 1.126 +++ if_vr.c 28 Aug 2007 01:00:34 -0000 @@ -90,6 +90,7 @@ #include +#include #include #define VR_USEIOSPACE @@ -513,6 +514,7 @@ struct ifnet *ifp; int error = 0, rid; struct vr_type *t; + int pmc; sc = device_get_softc(dev); sc->vr_dev = dev; @@ -591,7 +593,8 @@ * shuts down. Be sure to kick it in the head to wake it * up again. */ - VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); + if (pci_find_extcap(dev, PCIY_PMG, &pmc) == 0) + VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1)); /* Reset the adapter. */ vr_reset(sc); --9jxsPFA5p3P2qPhR-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 02:15:29 2007 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 00FE916A418 for ; Tue, 28 Aug 2007 02:15:29 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9F61913C46B for ; Tue, 28 Aug 2007 02:15:28 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:15:27 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:15:26 +0800 Received: from [172.23.17.9] ([172.23.17.9]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 10:15:26 +0800 Message-ID: <46D38543.4020507@zyxel.com.tw> Date: Tue, 28 Aug 2007 10:15:31 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2007 02:15:26.0600 (UTC) FILETIME=[4C3F0080:01C7E919] Subject: infinite loop in esp6_ctlinput()? 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, 28 Aug 2007 02:15:29 -0000 Dear all: When receiving a "packet too big" ICMP error message, FreeBSD will call the ctlinput() function of the upper protocol. If the preceding packet is an ESP IPv6 packet, then FreeBSD will call esp6_ctlinput(). In esp6_ctlinput(), pfctlinput2() will be executed to traverse all possible upper protocols, and call their registered ctlinput() function. However, that would call esp6_ctlinput() again since ESP is one of the upper protocols! Then an infinite loop occurs!! After comparing both IPSEC and FAST_IPSEC, the operations are exactly the same. Is it a bug? Best regards, Yi-Wen From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 05:48:52 2007 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 B1B3316A417 for ; Tue, 28 Aug 2007 05:48:52 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 547FF13C428 for ; Tue, 28 Aug 2007 05:48:51 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 13:48:50 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 13:48:50 +0800 Received: from [172.23.17.9] ([172.23.17.9]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 13:48:50 +0800 Message-ID: <46D3B747.1090903@zyxel.com.tw> Date: Tue, 28 Aug 2007 13:48:55 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: freebsd-net@freebsd.org References: <46D38543.4020507@zyxel.com.tw> In-Reply-To: X-OriginalArrivalTime: 28 Aug 2007 05:48:50.0655 (UTC) FILETIME=[1C0EBEF0:01C7E937] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: infinite loop in esp6_ctlinput()? 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, 28 Aug 2007 05:48:52 -0000 Since our device adopts the IPsec codes from BSD, our device will have infinite loop after receiving ICMP packet too big message. I am not sure whether BSD itself will have the problem or not (maybe needs further testing). In IPSEC, esp6_ctlinput() still calls pfctlinput2(), which is the root cause of the infinite loop. Best regards, Yi-Wen JINMEI Tatuya / ???? wrote: >At Tue, 28 Aug 2007 10:15:31 +0800, >blue wrote: > > > >>When receiving a "packet too big" ICMP error message, FreeBSD will call >>the ctlinput() function of the upper protocol. If the preceding packet >>is an ESP IPv6 packet, then FreeBSD will call esp6_ctlinput(). In >>esp6_ctlinput(), pfctlinput2() will be executed to traverse all possible >>upper protocols, and call their registered ctlinput() function. However, >>that would call esp6_ctlinput() again since ESP is one of the upper >>protocols! Then an infinite loop occurs!! >> >> > >From a quick look at the code, there's a slight difference between the >IPSEC (netinet6/esp_input.c) and FAST_IPSEC (netipsec/ipsec_input.c) >implementations. I suspect the loop doesn't occur at least for the >esp_input.c version. Did you actually see the loop for both, or are >you guessing from the code? > > > >>After comparing both IPSEC and FAST_IPSEC, the operations are exactly >>the same. Is it a bug? >> >> > >If it actually causes an infinite loop, it's a bug, of course. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > > From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 06:19:38 2007 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 0C56E16A417 for ; Tue, 28 Aug 2007 06:19:38 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.freebsd.org (Postfix) with ESMTP id CFF5B13C478 for ; Tue, 28 Aug 2007 06:19:37 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from jmb.local (unknown [IPv6:2001:200:0:ff10:217:f2ff:fe40:2857]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5B59173018; Tue, 28 Aug 2007 14:37:06 +0900 (JST) Date: Tue, 28 Aug 2007 14:36:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: blue In-Reply-To: <46D38543.4020507@zyxel.com.tw> References: <46D38543.4020507@zyxel.com.tw> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: infinite loop in esp6_ctlinput()? 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, 28 Aug 2007 06:19:38 -0000 At Tue, 28 Aug 2007 10:15:31 +0800, blue wrote: > When receiving a "packet too big" ICMP error message, FreeBSD will call=20 > the ctlinput() function of the upper protocol. If the preceding packet=20 > is an ESP IPv6 packet, then FreeBSD will call esp6_ctlinput(). In=20 > esp6_ctlinput(), pfctlinput2() will be executed to traverse all possible = > upper protocols, and call their registered ctlinput() function. However, = > that would call esp6_ctlinput() again since ESP is one of the upper=20 > protocols! Then an infinite loop occurs!! =46rom a quick look at the code, there's a slight difference between the IPSEC (netinet6/esp_input.c) and FAST_IPSEC (netipsec/ipsec_input.c) implementations. I suspect the loop doesn't occur at least for the esp_input.c version. Did you actually see the loop for both, or are you guessing from the code? > After comparing both IPSEC and FAST_IPSEC, the operations are exactly=20 > the same. Is it a bug? If it actually causes an infinite loop, it's a bug, of course. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 07:15:36 2007 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 A839416A420 for ; Tue, 28 Aug 2007 07:15:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 6EC3213C4DB for ; Tue, 28 Aug 2007 07:15:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id DFBAD26EC4; Tue, 28 Aug 2007 03:15:35 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 28 Aug 2007 03:15:35 -0400 X-Sasl-enc: 6h+QhbwaBWZxhhp+Zy5fGK/MTM1SvBnbAXB6UgzYp0FU 1188285335 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 6BB59B967; Tue, 28 Aug 2007 03:15:35 -0400 (EDT) Message-ID: <46D3CB96.5050109@FreeBSD.org> Date: Tue, 28 Aug 2007 08:15:34 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Weiguang Shi References: <954767.6972.qm@web43139.mail.sp1.yahoo.com> In-Reply-To: <954767.6972.qm@web43139.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: nc captures 1024 bytes 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, 28 Aug 2007 07:15:36 -0000 Looks like a netcat bug, if it doesn't tune buffers to the interface MTU. I'm not sure if nc has a 'de facto' maintainer however I believe it is something which was recently imported into the freebsd base system. Still, it is better to try to field patches with the upstream maintainer before filing a FreeBSD PR with your patches. regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 09:26:02 2007 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 500D616A421 for ; Tue, 28 Aug 2007 09:26:02 +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 C892F13C428 for ; Tue, 28 Aug 2007 09:26:01 +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 2C4F141C707; Tue, 28 Aug 2007 11:26:00 +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 UICBVl190Laz; Tue, 28 Aug 2007 11:25:59 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id C578541C729; Tue, 28 Aug 2007 11:25:59 +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 B068F444885; Tue, 28 Aug 2007 09:25:49 +0000 (UTC) Date: Tue, 28 Aug 2007 09:25:49 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: blue In-Reply-To: <46D3B747.1090903@zyxel.com.tw> Message-ID: <20070828092348.Y87821@maildrop.int.zabbadoz.net> References: <46D38543.4020507@zyxel.com.tw> <46D3B747.1090903@zyxel.com.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: infinite loop in esp6_ctlinput()? 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, 28 Aug 2007 09:26:02 -0000 On Tue, 28 Aug 2007, blue wrote: Hi, > Since our device adopts the IPsec codes from BSD, our device will have > infinite loop after receiving ICMP packet too big message. > I am not sure whether BSD itself will have the problem or not (maybe needs > further testing). In IPSEC, esp6_ctlinput() still calls pfctlinput2(), which > is the root cause of the infinite loop. you were talking about IPSEC vs. FAST_IPSEC so I guess you are on RELENG_6 or is that HEAD. Would be helpful to know where exactly (though I guess looking at the code I could find out). Is it the problem reported here[1] that you are describing? /bz [1] http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076478.html > Best regards, > > Yi-Wen > > JINMEI Tatuya / ???? wrote: > >> At Tue, 28 Aug 2007 10:15:31 +0800, >> blue wrote: >> >> >>> When receiving a "packet too big" ICMP error message, FreeBSD will call >>> the ctlinput() function of the upper protocol. If the preceding packet is >>> an ESP IPv6 packet, then FreeBSD will call esp6_ctlinput(). In >>> esp6_ctlinput(), pfctlinput2() will be executed to traverse all possible >>> upper protocols, and call their registered ctlinput() function. However, >>> that would call esp6_ctlinput() again since ESP is one of the upper >>> protocols! Then an infinite loop occurs!! >>> >> >> From a quick look at the code, there's a slight difference between the >> IPSEC (netinet6/esp_input.c) and FAST_IPSEC (netipsec/ipsec_input.c) >> implementations. I suspect the loop doesn't occur at least for the >> esp_input.c version. Did you actually see the loop for both, or are >> you guessing from the code? >> >> >>> After comparing both IPSEC and FAST_IPSEC, the operations are exactly the >>> same. Is it a bug? >>> >> >> If it actually causes an infinite loop, it's a bug, of course. >> >> JINMEI, Tatuya >> Communication Platform Lab. >> Corporate R&D Center, Toshiba Corp. >> jinmei@isl.rdc.toshiba.co.jp >> >> > > _______________________________________________ > 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" > -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 09:29:34 2007 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 0672416A418 for ; Tue, 28 Aug 2007 09:29:34 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 88C4213C457 for ; Tue, 28 Aug 2007 09:29:33 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id F03837C0AEF for ; Tue, 28 Aug 2007 11:29:31 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id XclnPzLLoH3T for ; Tue, 28 Aug 2007 11:29:31 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id A95D27BFCC4 for ; Tue, 28 Aug 2007 11:29:31 +0200 (CEST) Date: Tue, 28 Aug 2007 11:29:31 +0200 From: Gergely CZUCZY To: freebsd-net@freebsd.org Message-ID: <20070828092931.GA18240@harmless.hu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: mutt-ng/devel-r804 (FreeBSD) Subject: carp on multiple interfaces 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, 28 Aug 2007 09:29:34 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello This question just popped out of my head today when playing around with linux's LVS and keepalived. On a dual-carp scenario on two gateways when both the internal and the external IFs are carp(4)'d in a master-slave way and a link disconnects only on one side, would this trigger a carp failover of the other interface also? Like in the local side 10.0.0.{1,2} are the IF IPs and .3 is the carp IP, whereas the 1.2.3.{1,2,3} IPs are respectively the public IF and carp IPs. If the link on the IF of 1.2.3.1 goes DOWN, then the 1.2.3.3 should be failed over to the .2(slave) box, right? Now, on the local side still the .1(master) box has the carp'd IP because everything works fine in the LAN carp setup. This would turn out to be a tricky situation, because the local clients would get network-unreachable because the default local gateway had lost its outgoing connection, and the incoming connections would also time out because the clients would send the SYN+ACK replies over the master box, whereas that had lost its outgoing connection. Am i right that the FreeBSD carp(4) implementation has this issue? I don't have the opportunity to try this at the moment, but I'm interested in the way it would behave in a scenario like this. Had anyone met this already? Are there any workarounds/solutions for this? Thanks in advance Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owF1Vc+LHEUUXhPiocBDTh59iLCbZLp3ZjbKZiWM666TDC67C7skiKDUdL+ZLqe6 qlM/ZrYjQXIT9aDeRAmCZyEHBcFrvHjQg/4VC168iRdfVffsJgcZGJiq9773vfd9 r+bzFy6uXLj82+Mf3r322ZdfP/f983fGV0vvnJomJTdzoZJet9tLepv9691kg37k r2F/fGPzVcQJ9od/nP67o5VD5ZLjusItcHji1ivJhXodsoIbi+6md5Nkky3jdoWt tBVOaLUFQkmh8Ozu2HBlJ2iSt1Smc6GmW3DPa4d5UhmhHB9LZOw2SqkZOy6EpVu0 AQk+8NZBpasKc9DegZ5AWUOBPAenc17DokAFRKwmVMaN9iqHhXAFEAF/smph784R cDqcIVZcijnmKWMHCjjknssk46YCm6HiRmigim6hYcodLnhtG/SxJjhXIHXl0Cgu Ax4LBzSU5mA0tMANQkBbu35lNadYqlBySwGJlXyOQICRCA/UZiwXNtNKYeYslZV1 qK0VghU5dmChvaQWwyycEdMpGsqLXCdcSD1Hw2gUgQORo8tIbcIzBC6tHjC2J2aB cAyROiOOARh63TR8Pux1+g8i43A/GsLo0EZy6QaEkgWyWGx02AkzMMjjIfTSfroR szsbD5okwjBoK+qDZktthLDKj6XIGOEGzBbJpjBqKIf+46ib2tRIg9uDqUYLuwd3 9zvhUrHzmhtgiziTMcYRBD/QFMgFESbtr8UpXyG1TjpAIyvcgO3rRWdZ6KkhkLWk bNJ6a41GMQ+Kts3AmDQcHbIxZtxbUppq1SSHmpI0ZmZhQv5ezndve79pkrbCV2lj 4VZBb1Q0LvEk5jyomc1q4uE8Dw7vwLLEOclMCtoayxqIKTpQ6ELZxCuSgvaPFuaZ vBwn3EvX5rf2pXZyOrGOieAx76Y68G9dF2sHeRpnZ7p89nLZQfATOFFiQGBPF21p tnEWW6yjd/avbe+8Ta6oKMC2MtFFM+koEDs3FXdnPOF/eNLCbpcgGlWblIA3NIhv Hu0ulw5EWUksiVIcbCsmKSGs9ThgI8i1Wg3V5g1/elW0cV4JV0cbmbqJb+FLHbBI H1JvtFo2K0bPEuas1T3MWLi2/zFG4Lj3Z++JDFsYQFO4TU1yVYcVL9HFQ8YlDSGv B7DdbCJ9U0h0WPOU2XWrpW/kmGgTswbhjeSKPBhq5XOuMno9j0hCypd1h7FbaKZh FXfu++x+zUpaF6e3yEjxOM3i8Rv0ipcSrU0Lz1iS3Ox32V1EFSRz1GYKt+gHaW2B OFBnldFku7LVjNqzmLKPBxcvrYS/i+VfzeULT35a+faTrx6//95LV7/Y/Ys9Gv7z 4+mljz79eeXRy798c5r/Onj453cHL/7+ZP3vV/r3Hv4H =Y9Kb -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 09:44:31 2007 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 09EDF16A420 for ; Tue, 28 Aug 2007 09:44:31 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id A3AC013C461 for ; Tue, 28 Aug 2007 09:44:30 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id l7S9iUaS012534 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2007 11:44:30 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id l7S9iTo6030641; Tue, 28 Aug 2007 11:44:29 +0200 (MEST) Date: Tue, 28 Aug 2007 11:44:29 +0200 From: Daniel Hartmeier To: Gergely CZUCZY Message-ID: <20070828094429.GF18273@insomnia.benzedrine.cx> References: <20070828092931.GA18240@harmless.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070828092931.GA18240@harmless.hu> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: carp on multiple interfaces 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, 28 Aug 2007 09:44:31 -0000 On Tue, Aug 28, 2007 at 11:29:31AM +0200, Gergely CZUCZY wrote: > On a dual-carp scenario on two gateways when both the internal and > the external IFs are carp(4)'d in a master-slave way and a link > disconnects only on one side, would this trigger a carp failover > of the other interface also? See carp(4) net.inet.carp.preempt Allow virtual hosts to preempt each other. It is also used to failover carp interfaces as a group. When the option is enabled and one of the carp enabled physical interfaces goes down, advskew is changed to 240 on all carp inter- faces. See also the first example. Disabled by default. i.e. for your scenario you'd set preempt=1 so all interfaces failover together, to avoid the problem you describe (which otherwise would occur, yes). Daniel From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 09:45:42 2007 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 4140F16A418 for ; Tue, 28 Aug 2007 09:45:42 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id F2D5113C468 for ; Tue, 28 Aug 2007 09:45:41 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 136667C0AF5; Tue, 28 Aug 2007 11:45:41 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id ohNYKgD-Lsef; Tue, 28 Aug 2007 11:45:40 +0200 (CEST) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id A83487C0AF4; Tue, 28 Aug 2007 11:45:40 +0200 (CEST) Date: Tue, 28 Aug 2007 11:45:40 +0200 From: Gergely CZUCZY To: Daniel Hartmeier Message-ID: <20070828094540.GA20242@harmless.hu> References: <20070828092931.GA18240@harmless.hu> <20070828094429.GF18273@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <20070828094429.GF18273@insomnia.benzedrine.cx> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-net@freebsd.org Subject: Re: carp on multiple interfaces 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, 28 Aug 2007 09:45:42 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thanks for the answers. I must have missed that part of carp(4). On Tue, Aug 28, 2007 at 11:44:29AM +0200, Daniel Hartmeier wrote: > On Tue, Aug 28, 2007 at 11:29:31AM +0200, Gergely CZUCZY wrote: >=20 > > On a dual-carp scenario on two gateways when both the internal and > > the external IFs are carp(4)'d in a master-slave way and a link > > disconnects only on one side, would this trigger a carp failover > > of the other interface also? >=20 > See carp(4) >=20 > net.inet.carp.preempt Allow virtual hosts to preempt each other. = It > is also used to failover carp interfaces as a > group. When the option is enabled and one of > the carp enabled physical interfaces goes do= wn, > advskew is changed to 240 on all carp inter- > faces. See also the first example. Disabled > by default. >=20 > i.e. for your scenario you'd set preempt=3D1 so all interfaces failover > together, to avoid the problem you describe (which otherwise would > occur, yes). >=20 > Daniel Sincerely, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owGFVL+P1EYUPkAIyYDE8Q/kKU1At3a8vr0cLFrIccePKxAFh1BINTt+tkc3njEz 4zV7RSS6FCmiSAkFEqKBDgWkKE3aRBENDRIFfwRS/oO8seXlmmQty5LfvPne971f P54+tnJ09e2r375d++GnJ0deHn86XStr51QelszMhAqHcTwMkzgZJeEoTNaR82m8 sbkxjNPR5lfX3338c1srh8qFe/MKx+DwofuykkyoS8ALZiy6Se2y8ELQ++0IW2kr nNBqDEJJoXBxtmeYshma8JriOhUqH8ODWjtMw8oI5dhUYhDsFUztW8i0AVcg0I0G jY1gF8raOijYDKEU1mJK58xBxYwDnQFnpjo3Oh8FwW0FezUOYKvOIbkwgCSON4E8 h8PxaDROLm7dgrWYjAPYYUqghJsEUaJAA40hOuPgMvwPRnJxvD78hHEDTY5yDtv3 727f/2aBMEligmmBGKQ1k6EnCJajYkZo0ApcoyFnDhs2t9AUqGCqXdGqpmygUUyS /LSF8UbKfWfcvW6BGewlf5GSP0UpmSWH0EqfIgL1l8lMJdhvMVJhuVYKubMUnigT B60QrEhJaaNr6VMqLDgj8pyywdoIkDEh9QxNC0KZ9lyIKDm0NDPGqUzS6iu96ju4 4Nab6FHoIuE//iiqDGJZOX8AW1LqBmbCOMoTFNoSQaehd0HGiy5gBDAJdl2H998P SfB8oG6bRC8EdHIWpMmL3mVgudF1RYHv+QK10ivf3D4IlZJaNm3z7BOps2Vg/n5L or9aFXMrOKk+xCrX9En1JGjUYBkgS2d2HxvPhuZR5Z3gZBT74jIpD0kOl2G10Ump L1+bP882E4amDh+yspJIhzTfLfNlYNM5pJixWrqo7wEREYCf67muzadJoD/qYNok fcEn6ztDoPCe/qG0HGpDp3P0/TDwYtlMi7TlWhlN1EqPSMEtN2KKcK4pRN8/jbDY NTqBaM5rQpijPb+g2C2EILgjFEdDYz0IgsWAH9T8YB6URMPpMeSdOeKt+WtahqVE a6OiDoIw9HD3EAmNWhmti2hPKEENaUmZnC242m6JUSIsRsH3V44dX/Fbt1/Zq0cf n1159uvw0dp3zx+/eHfwx/vilzO/7/516vOVJyf+vrq9+kG/+fnkxuXPXt8+natb //wL =a79L -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 11:49:08 2007 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 6137216A417 for ; Tue, 28 Aug 2007 11:49:08 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 095AC13C428 for ; Tue, 28 Aug 2007 11:49:07 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 19:49:06 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 19:49:06 +0800 Received: from [172.23.17.9] ([172.23.17.9]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 19:49:05 +0800 Message-ID: <46D40BB7.4060100@zyxel.com.tw> Date: Tue, 28 Aug 2007 19:49:11 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <46D38543.4020507@zyxel.com.tw> <46D3B747.1090903@zyxel.com.tw> <20070828092348.Y87821@maildrop.int.zabbadoz.net> In-Reply-To: <20070828092348.Y87821@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2007 11:49:05.0768 (UTC) FILETIME=[6FAB3E80:01C7E969] Cc: freebsd-net@freebsd.org Subject: Re: infinite loop in esp6_ctlinput()? 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, 28 Aug 2007 11:49:08 -0000 Hi, According to the GDB backtrace, I think this is what I am talking about. Besides, this would result in infinite loop just by looking at the codes. However, the author seems knowing the problem, too. The comments in esp6_ctlinput() point out: /* * Although pfctlinput2 will call esp6_ctlinput(), there is * no possibility of an infinite loop of function calls, * because we don't pass the inner IPv6 header. */ I am not sure what the description means. The behavior of esp6_ctlinput() is the same in HEAD, too. Best regards, Yi-Wen Bjoern A. Zeeb wrote: > On Tue, 28 Aug 2007, blue wrote: > > Hi, > >> Since our device adopts the IPsec codes from BSD, our device will >> have infinite loop after receiving ICMP packet too big message. >> I am not sure whether BSD itself will have the problem or not (maybe >> needs further testing). In IPSEC, esp6_ctlinput() still calls >> pfctlinput2(), which is the root cause of the infinite loop. > > > you were talking about IPSEC vs. FAST_IPSEC so I guess you are on > RELENG_6 or is that HEAD. Would be helpful to know where exactly > (though I guess looking at the code I could find out). > > Is it the problem reported here[1] that you are describing? > > > /bz > > > [1] > http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076478.html > > >> Best regards, >> >> Yi-Wen >> >> JINMEI Tatuya / ???? wrote: >> >>> At Tue, 28 Aug 2007 10:15:31 +0800, >>> blue wrote: >>> >>> >>>> When receiving a "packet too big" ICMP error message, FreeBSD will >>>> call the ctlinput() function of the upper protocol. If the >>>> preceding packet is an ESP IPv6 packet, then FreeBSD will call >>>> esp6_ctlinput(). In esp6_ctlinput(), pfctlinput2() will be executed >>>> to traverse all possible upper protocols, and call their registered >>>> ctlinput() function. However, that would call esp6_ctlinput() again >>>> since ESP is one of the upper protocols! Then an infinite loop >>>> occurs!! >>>> >>> >>> From a quick look at the code, there's a slight difference between the >>> IPSEC (netinet6/esp_input.c) and FAST_IPSEC (netipsec/ipsec_input.c) >>> implementations. I suspect the loop doesn't occur at least for the >>> esp_input.c version. Did you actually see the loop for both, or are >>> you guessing from the code? >>> >>> >>>> After comparing both IPSEC and FAST_IPSEC, the operations are >>>> exactly the same. Is it a bug? >>>> >>> >>> If it actually causes an infinite loop, it's a bug, of course. >>> >>> JINMEI, Tatuya >>> Communication Platform Lab. >>> Corporate R&D Center, Toshiba Corp. >>> jinmei@isl.rdc.toshiba.co.jp >>> >>> >> >> _______________________________________________ >> 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 Tue Aug 28 15:33:58 2007 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 91AF016A41B for ; Tue, 28 Aug 2007 15:33:58 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC4813C46C for ; Tue, 28 Aug 2007 15:33:58 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from jmb.local (pc2.htonk-unet.ocn.ne.jp [60.32.109.194]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 803F77301E; Wed, 29 Aug 2007 00:28:56 +0900 (JST) Date: Wed, 29 Aug 2007 00:28:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: blue In-Reply-To: <46D40BB7.4060100@zyxel.com.tw> References: <46D38543.4020507@zyxel.com.tw> <46D3B747.1090903@zyxel.com.tw> <20070828092348.Y87821@maildrop.int.zabbadoz.net> <46D40BB7.4060100@zyxel.com.tw> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: infinite loop in esp6_ctlinput()? 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, 28 Aug 2007 15:33:58 -0000 At Tue, 28 Aug 2007 19:49:11 +0800, blue wrote: > According to the GDB backtrace, I think this is what I am talking about. > > Besides, this would result in infinite loop just by looking at the > codes. However, the author seems knowing the problem, too. The comments > in esp6_ctlinput() point out: > /* > * Although pfctlinput2 will call esp6_ctlinput(), there is > * no possibility of an infinite loop of function calls, > * because we don't pass the inner IPv6 header. > */ > > I am not sure what the description means. The behavior of > esp6_ctlinput() is the same in HEAD, too. This means that variable 'ip6' should be NULL for the second time esp6_ctlinput() is called in the esp_input.c ("non-FAST" IPSEC) version. It prevents the function calls from making an infinite loop. On the other hand, the ipsec_input.c (FAST_IPSEC) version only seems to check ip6ctlparam * ('d') is NULL, making the infinite sequence of calls possible. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 17:54:33 2007 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 50B3216A41A for ; Tue, 28 Aug 2007 17:54:33 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: from web43137.mail.sp1.yahoo.com (web43137.mail.sp1.yahoo.com [216.252.121.67]) by mx1.freebsd.org (Postfix) with SMTP id 20C4413C4A8 for ; Tue, 28 Aug 2007 17:54:32 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: (qmail 45401 invoked by uid 60001); 28 Aug 2007 17:54:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=grcUtWgg7/bTW9KMXtJSkDbwCahqrjclGHFcn0R7D76rg1Tc6iuBJpNYJuhRGPZ9TuQ1TyRuhQJ3Vbd4uSJBpYAeiDRU0SW4Omyhvjl6v8iIRkRcQ37EzXkgOSaqveuiBcOXRjbLaewlV5pWDxMh3rjs1+1yjOB3HQg6SMyDJp0=; Received: from [69.147.84.253] by web43137.mail.sp1.yahoo.com via HTTP; Tue, 28 Aug 2007 10:54:32 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Tue, 28 Aug 2007 10:54:32 -0700 (PDT) From: Weiguang Shi To: "Bruce M. Simpson" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <497562.45228.qm@web43137.mail.sp1.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: nc captures 1024 bytes 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, 28 Aug 2007 17:54:33 -0000 nc might be waiting on all the interfaces; enumerating MTUs and choosing th= e largest=0Asounds complicated, especially when some interfaces can be conf= igured to receive =0Ajumbo frames. Why not just use something like 64KB as = the other user=0Asuggested or something even larger?=0A=0A----- Original Me= ssage ----=0AFrom: Bruce M. Simpson =0ATo: Weiguang Shi =0ACc: freebsd-net@freebsd.org=0ASent: Tuesday, August 28,= 2007 12:15:34 AM=0ASubject: Re: nc captures 1024 bytes=0A=0ALooks like a n= etcat bug, if it doesn't tune buffers to the interface MTU.=0A=0AI'm not su= re if nc has a 'de facto' maintainer however I believe it is =0Asomething w= hich was recently imported into the freebsd base system.=0A=0AStill, it is = better to try to field patches with the upstream maintainer =0Abefore filin= g a FreeBSD PR with your patches.=0A=0Aregards,=0ABMS=0A___________________= ____________________________=0Afreebsd-net@freebsd.org mailing list=0Ahttp:= //lists.freebsd.org/mailman/listinfo/freebsd-net=0ATo unsubscribe, send any= mail to "freebsd-net-unsubscribe@freebsd.org"=0A=0A=0A=0A=0A=0A =0A_= ___________________________________________________________________________= ________=0ABuilding a website is a piece of cake. Yahoo! Small Business giv= es you all the tools to get online.=0Ahttp://smallbusiness.yahoo.com/webhos= ting From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 18:24:26 2007 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 A520816A41B for ; Tue, 28 Aug 2007 18:24:26 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1388613C491 for ; Tue, 28 Aug 2007 18:24:22 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 7D3A717390; Tue, 28 Aug 2007 11:53:33 -0500 (CDT) Date: Tue, 28 Aug 2007 11:53:33 -0500 From: "Christian S.J. Peron" To: freebsd-net@freebsd.org Message-ID: <20070828165333.GA14159@sub.vaned.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: [csjp@FreeBSD.org: Re: rtfree: 0xffffff00036fb1e0 has 1 refs] 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, 28 Aug 2007 18:24:26 -0000 I am not sure who has their hands in the routing code these days so I figured I would just forward this message off here. Does the following look reasonable? ----- Forwarded message from "Christian S.J. Peron" ----- From: "Christian S.J. Peron" To: Yuri Pankov Cc: freebsd-current@freebsd.org Date: Mon, 27 Aug 2007 18:59:03 -0500 Subject: Re: rtfree: 0xffffff00036fb1e0 has 1 refs Based on some comments in rtfree, we should only be calling rtfree if we are sure we own the last reference to the route. I am not sure this is the case in the stf/gif cases... Please try the attached patch and let me know if there are any ill effects. On Fri, Aug 24, 2007 at 12:17:26PM +0400, Yuri Pankov wrote: > Hi, > > I've recently started using he.net's ipv6 tunnel and getting this message: > rtfree: 0xffffff00036fb1e0 has 1 refs > > I've added kdb_backtrace() in route.c as Gleb Smirnoff suggested before. Here's > backtrace: > rtfree: 0xffffff00036fb1e0 has 1 refs > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > rtfree() at rtfree+0xba > gif_encapcheck4() at gif_encapcheck4+0x118 > gif_encapcheck() at gif_encapcheck+0xfd > encap4_input() at encap4_input+0xcc > ip_input() at ip_input+0xc0 > tunwrite() at tunwrite+0x1d5 > giant_write() at giant_write+0x51 > devfs_write_f() at devfs_write_f+0x9c > dofilewrite() at dofilewrite+0x85 > kern_writev() at kern_writev+0x4c > write() at write+0x54 > syscall() at syscall+0x1ce > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (4, FreeBSD ELF64, write), rip = 0x80125c35c, rsp = 0x7fffffffda18, > rbp = 0x60 --- > > > ifconfig: > gif0: flags=8051 metric 0 mtu 1280 > tunnel inet 194.186.18.14 --> 64.71.128.83 > inet6 fe80::20f:eaff:fe7d:f320%gif0 prefixlen 64 scopeid 0x5 > inet6 2001:470:1f03:2d5::2 --> 2001:470:1f03:2d5::1 prefixlen 128 > inet6 2001:470:1f01:725::1 prefixlen 64 > tun0: flags=8051 metric 0 mtu 1500 > inet6 fe80::20f:eaff:fe7d:f320%tun0 prefixlen 64 scopeid 0x6 > inet 194.186.18.14 --> 194.186.18.2 netmask 0xffffff00 > Opened by PID 458 > > > Yuri > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer Index: net/if_stf.c =================================================================== RCS file: /usr/ncvs/src/sys/net/if_stf.c,v retrieving revision 1.59 diff -u -r1.59 if_stf.c --- net/if_stf.c 22 Oct 2006 11:52:15 -0000 1.59 +++ net/if_stf.c 27 Aug 2007 23:51:19 -0000 @@ -607,10 +607,10 @@ (u_int32_t)ntohl(sin.sin_addr.s_addr)); #endif if (rt) - rtfree(rt); + RTFREE_LOCKED(rt); return -1; } - rtfree(rt); + RTFREE_LOCKED(rt); } return 0; Index: netinet/in_gif.c =================================================================== RCS file: /usr/ncvs/src/sys/netinet/in_gif.c,v retrieving revision 1.36 diff -u -r1.36 in_gif.c --- netinet/in_gif.c 10 May 2007 15:58:47 -0000 1.36 +++ netinet/in_gif.c 27 Aug 2007 23:48:04 -0000 @@ -374,10 +374,10 @@ (u_int32_t)ntohl(sin.sin_addr.s_addr)); #endif if (rt) - rtfree(rt); + RTFREE_LOCKED(rt); return 0; } - rtfree(rt); + RTFREE_LOCKED(rt); } return 32 * 2; _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 20:37:28 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEB9616A4AB; Tue, 28 Aug 2007 20:37:28 +0000 (UTC) (envelope-from mallman@icir.org) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by mx1.freebsd.org (Postfix) with ESMTP id CEAE213C461; Tue, 28 Aug 2007 20:37:28 +0000 (UTC) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l7SK6O7j024583; Tue, 28 Aug 2007 13:06:24 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id F0DE6EB691B; Tue, 28 Aug 2007 16:06:18 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D4E24291A00; Tue, 28 Aug 2007 16:06:00 -0400 (EDT) To: gnn@freebsd.org From: Mark Allman In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Zombie MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 28 Aug 2007 16:06:00 -0400 Sender: mallman@icir.org Message-Id: <20070828200600.D4E24291A00@lawyers.icir.org> Cc: net@freebsd.org Subject: Re: Canonical Packet Traces? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 20:37:29 -0000 --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline (1) We have released some traces from LBNL at: http://www.icir.org/enterprise-tracing/ (2) See datcat.org for an index. (3) The CRAWDAD traces from: http://crawdad.cs.dartmouth.edu/ allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG1IAoWyrrWs4yIs4RAg/PAKCVcnLoOalDRpkojmWLxXiAYi88LwCeLQO3 sv/qIoH4bgqosOvvlbDYmpM= =wSDI -----END PGP SIGNATURE----- --=_bOundary-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 20:49:03 2007 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 48F9916A496; Tue, 28 Aug 2007 20:49:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 06C3313C45E; Tue, 28 Aug 2007 20:49:02 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 8CDE92741C; Tue, 28 Aug 2007 16:49:02 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 28 Aug 2007 16:49:02 -0400 X-Sasl-enc: HjkJZtM8It+60oqyiJgC5pHi7aI4pffpedQ8G35KFTlO 1188334142 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 22CB923306; Tue, 28 Aug 2007 16:49:02 -0400 (EDT) Message-ID: <46D48A3D.6080901@FreeBSD.org> Date: Tue, 28 Aug 2007 21:49:01 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20070828165333.GA14159@sub.vaned.net> In-Reply-To: <20070828165333.GA14159@sub.vaned.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [csjp@FreeBSD.org: Re: rtfree: 0xffffff00036fb1e0 has 1 refs] 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, 28 Aug 2007 20:49:03 -0000 Christian S.J. Peron wrote: > I am not sure who has their hands in the routing code these days so > I figured I would just forward this message off here. Does the > following look reasonable? > I'm looking, but mostly with long range goggles on. Yes, this looks like the right change. rtalloc1() always returns an rtentry with the mutex for that rtentry held. regards BMS From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 20:52:49 2007 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 D12CC16A41B for ; Tue, 28 Aug 2007 20:52:49 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id A3F4813C468 for ; Tue, 28 Aug 2007 20:52:49 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 111ED274ED; Tue, 28 Aug 2007 16:52:49 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 28 Aug 2007 16:52:49 -0400 X-Sasl-enc: J006BneSLIxbnAMf9+4Qs85y7GIVWX54oHE8FeckAkmm 1188334368 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id D09613B5C; Tue, 28 Aug 2007 16:52:47 -0400 (EDT) Message-ID: <46D48B1E.80405@FreeBSD.org> Date: Tue, 28 Aug 2007 21:52:46 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Weiguang Shi References: <497562.45228.qm@web43137.mail.sp1.yahoo.com> In-Reply-To: <497562.45228.qm@web43137.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: nc captures 1024 bytes 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, 28 Aug 2007 20:52:49 -0000 Weiguang Shi wrote: > nc might be waiting on all the interfaces; enumerating MTUs and choosing the largest > sounds complicated, especially when some interfaces can be configured to receive > jumbo frames. Why not just use something like 64KB as the other user > suggested or something even larger? > That is the easy fix, yes. :^) If the socket's pcb laddr is bound to an IP, and IP to which it is bound stays on the same physical interface, then the MTU may easily be obtained. If it's INADDR_ANY, or you expect the IP to be dynamically reconfigured on another interface, then auto-tuning is not possible. regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 21:05:40 2007 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 3C83C16A418 for ; Tue, 28 Aug 2007 21:05:40 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id D499913C468 for ; Tue, 28 Aug 2007 21:05:39 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l7SKpPo1007188; Tue, 28 Aug 2007 15:51:25 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Tue, 28 Aug 2007 15:51:25 -0500 (CDT) From: "Sean C. Farley" To: freebsd-net@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-500783598-1188334285=:2740" X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.farley.org Cc: "Sean C. Farley" Subject: dhclient multiple aliases limitation 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, 28 Aug 2007 21:05:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-500783598-1188334285=:2740 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii I currently have a setup on a laptop where I have two aliases that I always want present. I would like to setup two aliases in /etc/dhclient.conf to handle having the Ethernet cable plugged in after boot, but dhclient has a limit of handling only one alias. /etc/rc.conf ifconfig_xl0="DHCP" ifconfig_xl0_alias0="inet 192.168.1.46 netmask 255.255.255.255" ifconfig_xl0_alias1="inet 192.168.6.46 netmask 255.255.255.0" The first address uses an alias-type netmask while the second is a private network I have for QEMU. I found that during PREINIT /sbin/dhclient-script is deleting the 192.168.1.46 address when it runs this: ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 broadcast 255.255.255.255 up A possible solution that works for me is to add an "alias" to this line. It appears to work, but I do not know if this would cause problems elsewhere or for other scenarios. Does anyone see any problems with this change? Sean P.S. Please Cc me since I am not on this list. -- scf@FreeBSD.org --0-500783598-1188334285=:2740 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dhclient-script.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: dhclient-script patch Content-Disposition: attachment; filename=dhclient-script.patch LS0tIC9zYmluL2RoY2xpZW50LXNjcmlwdAkyMDA2LTA1LTEyIDIyOjI0OjAw LjAwMDAwMDAwMCAtMDUwMA0KKysrIC9ldGMvZGhjbGllbnQtc2NyaXB0CTIw MDctMDgtMjggMTU6MjU6MzAuMDAwMDAwMDAwIC0wNTAwDQpAQCAtMjIzLDcg KzIyMyw3IEBADQogDQogUFJFSU5JVCkNCiAJZGVsZXRlX29sZF9hbGlhcw0K LQlpZmNvbmZpZyAkaW50ZXJmYWNlIGluZXQgMC4wLjAuMCBuZXRtYXNrIDAu MC4wLjAgYnJvYWRjYXN0IDI1NS4yNTUuMjU1LjI1NSB1cA0KKwlpZmNvbmZp ZyAkaW50ZXJmYWNlIGluZXQgMC4wLjAuMCBuZXRtYXNrIDAuMC4wLjAgYnJv YWRjYXN0IDI1NS4yNTUuMjU1LjI1NSBhbGlhcyB1cA0KIAk7Ow0KIA0KIEFS UENIRUNLfEFSUFNFTkQpDQo= --0-500783598-1188334285=:2740-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 21:13:56 2007 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 B2A3E16A420; Tue, 28 Aug 2007 21:13:56 +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 491A113C45B; Tue, 28 Aug 2007 21:13:56 +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.13.8/8.13.8) with ESMTP id l7SLDsje032485; Tue, 28 Aug 2007 16:13:54 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l7SLDsjO032484; Tue, 28 Aug 2007 16:13:54 -0500 (CDT) (envelope-from brooks) Date: Tue, 28 Aug 2007 16:13:54 -0500 From: Brooks Davis To: "Sean C. Farley" Message-ID: <20070828211354.GA31137@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 28 Aug 2007 16:13:55 -0500 (CDT) Cc: freebsd-net@freebsd.org Subject: Re: dhclient multiple aliases limitation 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, 28 Aug 2007 21:13:56 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2007 at 03:51:25PM -0500, Sean C. Farley wrote: > I currently have a setup on a laptop where I have two aliases that I > always want present. I would like to setup two aliases in > /etc/dhclient.conf to handle having the Ethernet cable plugged in after > boot, but dhclient has a limit of handling only one alias. >=20 > /etc/rc.conf > ifconfig_xl0=3D"DHCP" > ifconfig_xl0_alias0=3D"inet 192.168.1.46 netmask 255.255.255.255" > ifconfig_xl0_alias1=3D"inet 192.168.6.46 netmask 255.255.255.0" >=20 > The first address uses an alias-type netmask while the second is a > private network I have for QEMU. >=20 > I found that during PREINIT /sbin/dhclient-script is deleting the > 192.168.1.46 address when it runs this: >=20 > ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 broadcast 255.255.255.2= 55=20 > up >=20 > A possible solution that works for me is to add an "alias" to this line. > It appears to work, but I do not know if this would cause problems > elsewhere or for other scenarios. Does anyone see any problems with > this change? Off hand this sounds correct. We really want dhclient to leave any addresses other than ones it sets alone so always using alias directives is probably correct. -- Brooks > Sean >=20 > P.S. Please Cc me since I am not on this list. > --=20 > scf@FreeBSD.org Content-Description: dhclient-script patch > --- /sbin/dhclient-script 2006-05-12 22:24:00.000000000 -0500 > +++ /etc/dhclient-script 2007-08-28 15:25:30.000000000 -0500 > @@ -223,7 +223,7 @@ > =20 > PREINIT) > delete_old_alias > - ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 broadcast 255.255.255.= 255 up > + ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 broadcast 255.255.255.= 255 alias up > ;; > =20 > ARPCHECK|ARPSEND) > _______________________________________________ > 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" --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFG1JASXY6L6fI4GtQRAnMcAKDU9JDAOAuuXbaI6mUlzteWDx/07QCePzve d1akxJjvafNSup1bVIi77+I= =diYj -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 22:10:33 2007 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 1839816A41A; Tue, 28 Aug 2007 22:10:33 +0000 (UTC) (envelope-from jeff@sailorfej.net) Received: from mail.sailorfej.net (mail.sailorfej.net [66.93.72.123]) by mx1.freebsd.org (Postfix) with ESMTP id DB4FC13C45D; Tue, 28 Aug 2007 22:10:32 +0000 (UTC) (envelope-from jeff@sailorfej.net) Received: from [127.0.0.1] (c-67-160-132-255.hsd1.or.comcast.net [67.160.132.255]) (authenticated bits=0) by mail.sailorfej.net (8.13.8/8.13.8) with ESMTP id l7SLmvXx048981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2007 14:49:01 -0700 (PDT) (envelope-from jeff@sailorfej.net) Message-ID: <46D4983E.2050305@sailorfej.net> Date: Tue, 28 Aug 2007 14:48:46 -0700 From: Jeffrey Williams User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-jail@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.4 required=6.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.1.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on mail.sailorfej.net Cc: Subject: Running jails on multiple subnets with multiple interfaces 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, 28 Aug 2007 22:10:33 -0000 I have a server with two interfaces, I want to run the host and a couple of jails using one interface on one subnet (internal interface, private IP, behind NAT/firewall) and some other jails using the other interface on another subnet (external interface, public IP, DMZ). Now my understanding of the challenge in doing this, is that the network stack is not "virtualized" in the jails, so all the jails use the same routing table, and for obvious reasons only one default router. (also just for sake of clarity I don't want to enable routing between interfaces on the jail host) Now if I understand all this correctly, then what will happen is, if I set the default router to the internal networks exit router (the NAT/firewall), then the jails listening on the external interface will only be able to talk to their local subnet, and because the internal subnet won't exist for them they won't be able to connect to the network at large. If I set the default router to the external networks exit router (the DMZ perimeter firewall) then the host and jails listening on the internal network won't be able to be able to talk to the internet beyond the local nets, the jails because the external network doesn't exist for them, and the host because even though it can talk to both nets, the services are configured to only listen to the internal net, and the it will be trying to send all outgoing traffic to the public net, thus not creating and NAT table entries on the NAT/Firewall for the return connections. Is there anyway to achieve what I have trying to do? Thanks Jeffrey williams From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 23:13:55 2007 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 A3BDF16A418; Tue, 28 Aug 2007 23:13:55 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from conn-smtp.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB6413C4A5; Tue, 28 Aug 2007 23:13:55 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from mail.tcbug.org (mail.tcbug.org [208.42.70.163]) by conn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id D260A7903; Tue, 28 Aug 2007 17:43:14 -0500 (CDT) Received: by mail.tcbug.org (Postfix, from userid 1001) id 7A379342C9C; Tue, 28 Aug 2007 17:43:14 -0500 (CDT) Date: Tue, 28 Aug 2007 17:43:14 -0500 From: Josh Paetzel To: Jeffrey Williams Message-ID: <20070828224314.GB4446@tcbug.org> Mail-Followup-To: Jeffrey Williams , freebsd-jail@freebsd.org, freebsd-net@freebsd.org References: <46D4983E.2050305@sailorfej.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C311HLcnHV2CzHlo" Content-Disposition: inline In-Reply-To: <46D4983E.2050305@sailorfej.net> Cc: freebsd-net@freebsd.org, freebsd-jail@freebsd.org Subject: Re: Running jails on multiple subnets with multiple interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Josh Paetzel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2007 23:13:55 -0000 --C311HLcnHV2CzHlo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jeffrey Williams wrote: > I have a server with two interfaces, I want to run the host and a couple = of=20 > jails using one interface on one subnet (internal interface, private IP, = behind=20 > NAT/firewall) and some other jails using the other interface on another s= ubnet=20 > (external interface, public IP, DMZ). >=20 > Now my understanding of the challenge in doing this, is that the network = stack=20 > is not "virtualized" in the jails, so all the jails use the same routing = table,=20 > and for obvious reasons only one default router. (also just for sake of c= larity=20 > I don't want to enable routing between interfaces on the jail host) >=20 > Now if I understand all this correctly, then what will happen is, if I se= t the=20 > default router to the internal networks exit router (the NAT/firewall), t= hen=20 > the jails listening on the external interface will only be able to talk t= o=20 > their local subnet, and because the internal subnet won't exist for them = they=20 > won't be able to connect to the network at large. >=20 > If I set the default router to the external networks exit router (the DMZ= =20 > perimeter firewall) then the host and jails listening on the internal net= work=20 > won't be able to be able to talk to the internet beyond the local nets, t= he=20 > jails because the external network doesn't exist for them, and the host b= ecause=20 > even though it can talk to both nets, the services are configured to only= =20 > listen to the internal net, and the it will be trying to send all outgoin= g=20 > traffic to the public net, thus not creating and NAT table entries on the= =20 > NAT/Firewall for the return connections. >=20 > Is there anyway to achieve what I have trying to do? >=20 > Thanks > Jeffrey williams PF makes a very effective workaround to this with it's route-to option...effectively letting you bypass the routing table altogether and set up per IP behavior. For instance, I use it in the following scenario, where a box has two interfaces with public IPs and I don't want answers to connections on the 'secondary' interface to go out the default route. connection 1's router 192.168.1.1 em0 ip 192.168.1.2/24 connection 2's router 10.0.0.1 em1 ip 10.0.0.2/24 if connection 1 is the 'primary' link then set the default route to 192.168.1.1 and put the following rule in pf.conf pass out route-to (em1 10.0.0.1) from 10.0.0.2 to ! 10.0.0.0/24 If you were to give more concrete examples of your config I could probably help you out with a workable pf solution. --=20 Thanks, Josh Paetzel --C311HLcnHV2CzHlo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQFG1KUBJvkB8SevrssRAtSWAJ0RaJcQTthdu6m7EvKdsgdlgaXGfACgiUna gt1D/TcQzDwxawX3M1OpOLk= =KZ8Q -----END PGP SIGNATURE----- --C311HLcnHV2CzHlo-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 04:18:31 2007 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 5ACE116A417 for ; Wed, 29 Aug 2007 04:18:31 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2430013C45B for ; Wed, 29 Aug 2007 04:18:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l7T4I3sb013157; Tue, 28 Aug 2007 21:18:04 -0700 (PDT) Date: Wed, 29 Aug 2007 11:13:25 +0900 Message-ID: From: "George V. Neville-Neil" To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: References: <46D38543.4020507@zyxel.com.tw> <46D3B747.1090903@zyxel.com.tw> <20070828092348.Y87821@maildrop.int.zabbadoz.net> <46D40BB7.4060100@zyxel.com.tw> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Bjoern A. Zeeb" , blue , freebsd-net@freebsd.org Subject: Re: infinite loop in esp6_ctlinput()? 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, 29 Aug 2007 04:18:31 -0000 At Wed, 29 Aug 2007 00:28:47 +0900, jinmei wrote: > > At Tue, 28 Aug 2007 19:49:11 +0800, > blue wrote: > > > According to the GDB backtrace, I think this is what I am talking about. > > > > Besides, this would result in infinite loop just by looking at the > > codes. However, the author seems knowing the problem, too. The comments > > in esp6_ctlinput() point out: > > /* > > * Although pfctlinput2 will call esp6_ctlinput(), there is > > * no possibility of an infinite loop of function calls, > > * because we don't pass the inner IPv6 header. > > */ > > > > I am not sure what the description means. The behavior of > > esp6_ctlinput() is the same in HEAD, too. > > This means that variable 'ip6' should be NULL for the second time > esp6_ctlinput() is called in the esp_input.c ("non-FAST" IPSEC) > version. It prevents the function calls from making an infinite loop. > > On the other hand, the ipsec_input.c (FAST_IPSEC) version only seems > to check ip6ctlparam * ('d') is NULL, making the infinite sequence of > calls possible. I am now going over the code that Jinmei-san has kindly pointed out and will attempt a patch soon. I am also hoping to develop a reliable way to trigger this bug, based on the report from Pawel Worach on current@. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 05:25:43 2007 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 AD11A16A419 for ; Wed, 29 Aug 2007 05:25:43 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 9CA0E13C45D for ; Wed, 29 Aug 2007 05:25:43 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l7T5OCQP092987; Tue, 28 Aug 2007 22:24:12 -0700 (PDT) Date: Wed, 29 Aug 2007 14:24:05 +0900 Message-ID: From: "George V. Neville-Neil" To: "George V. Neville-Neil" In-Reply-To: References: <46D38543.4020507@zyxel.com.tw> <46D3B747.1090903@zyxel.com.tw> <20070828092348.Y87821@maildrop.int.zabbadoz.net> <46D40BB7.4060100@zyxel.com.tw> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org, blue , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: infinite loop in esp6_ctlinput()? 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, 29 Aug 2007 05:25:43 -0000 Hi, Please try the attached patch, which mimics exactly what the Kame code used to do. I have not fully tested it, but it builds and runs. I will need some time to reproduce the panic you saw on one of my boxes. If you can tell me the steps you took to get that to happen that would be great. Best, George ==== //depot/user/gnn/ipsec_seven/src/sys/netipsec/ipsec_input.c#1 - /home/gnn/user/gnn/ipsec_seven/src/sys/netipsec/ipsec_input.c ==== @@ -761,6 +761,11 @@ void esp6_ctlinput(int cmd, struct sockaddr *sa, void *d) { + struct ip6ctlparam *ip6cp = NULL; + struct mbuf *m = NULL; + struct ip6_hdr *ip6; + int off; + if (sa->sa_family != AF_INET6 || sa->sa_len != sizeof(struct sockaddr_in6)) return; @@ -768,10 +773,18 @@ return; /* if the parameter is from icmp6, decode it. */ - if (d != NULL) { - struct ip6ctlparam *ip6cp = (struct ip6ctlparam *)d; - struct mbuf *m = ip6cp->ip6c_m; - int off = ip6cp->ip6c_off; + if (d != NULL) { + ip6cp = (struct ip6ctlparam *)d; + m = ip6cp->ip6c_m; + ip6 = ip6cp->ip6c_ip6; + off = ip6cp->ip6c_off; + } else { + m = NULL; + ip6 = NULL; + off = 0; /* calm gcc */ + } + + if (ip6) { struct ip6ctlparam ip6cp1; From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 06:49:27 2007 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 0F62216A41B; Wed, 29 Aug 2007 06:49:27 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 673E713C46A; Wed, 29 Aug 2007 06:49:26 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 006B6EB32CD; Wed, 29 Aug 2007 14:49:22 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id Re8gZQvD3ooq; Wed, 29 Aug 2007 14:49:10 +0800 (CST) Received: from LI-Xins-MacBook.local (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 1E12FEB30E1; Wed, 29 Aug 2007 14:49:09 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:x-enigmail-version:openpgp:content-type; b=FsEmYsZNAdFXZmJVQWfolNW/yIf8chbh1uGQQKQ9H+D2mTs6TjqKNrdn2ugYUjsqH gItDtbda6CMRbTrYN4KMg== Message-ID: <46D516D9.4050007@delphij.net> Date: Wed, 29 Aug 2007 14:48:57 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: freebsd-net X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC7AC46FEA34DE35C9DBEE14E" Cc: Robert Watson , hshh Subject: Add socket related statistics to netstat(1)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 06:49:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC7AC46FEA34DE35C9DBEE14E Content-Type: multipart/mixed; boundary="------------080100020102070403070508" This is a multi-part message in MIME format. --------------080100020102070403070508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Here is a proof-of-concept patch that adds sockets related statistics to netstat(1)'s -m option, which could make SA's life easier. Inspired by a local user's suggestion. Comments? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------080100020102070403070508 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="socket.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="socket.diff" Index: mbuf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/netstat/mbuf.c,v retrieving revision 1.53 diff -u -p -r1.53 mbuf.c --- mbuf.c 16 Jul 2007 17:15:55 -0000 1.53 +++ mbuf.c 29 Aug 2007 06:45:26 -0000 @@ -1,4 +1,4 @@ -/* +/*- * Copyright (c) 1983, 1988, 1993 * The Regents of the University of California. * Copyright (c) 2005 Robert N. M. Watson @@ -58,6 +58,8 @@ __FBSDID("$FreeBSD: src/usr.bin/netstat/ #include #include "netstat.h" =20 +#define SOCKET_MEM_NAME "socket" + /* * Print mbuf statistics. */ @@ -70,6 +72,7 @@ mbpr(void *kvmd, u_long mbaddr) uintmax_t cluster_count, cluster_bytes, cluster_limit, cluster_free; uintmax_t cluster_failures, cluster_size; uintmax_t packet_count, packet_bytes, packet_free, packet_failures; + uintmax_t socket_count, socket_bytes, socket_limit, socket_free, socket= _failures; uintmax_t tag_count, tag_bytes; uintmax_t jumbop_count, jumbop_bytes, jumbop_limit, jumbop_free; uintmax_t jumbop_failures, jumbop_size; @@ -134,6 +137,18 @@ mbpr(void *kvmd, u_long mbaddr) packet_free =3D memstat_get_free(mtp); packet_failures =3D memstat_get_failures(mtp); =20 + mtp =3D memstat_mtl_find(mtlp, ALLOCATOR_UMA, SOCKET_MEM_NAME); + if (mtp =3D=3D NULL) { + warnx("memstat_mtl_find: zone %s not found", + SOCKET_MEM_NAME); + goto out; + } + socket_count =3D memstat_get_count(mtp); + socket_bytes =3D memstat_get_bytes(mtp); + socket_free =3D memstat_get_free(mtp); + socket_limit =3D memstat_get_countlimit(mtp); + socket_failures =3D memstat_get_failures(mtp); + mtp =3D memstat_mtl_find(mtlp, ALLOCATOR_UMA, MBUF_CLUSTER_MEM_NAME); if (mtp =3D=3D NULL) { warnx("memstat_mtl_find: zone %s not found", @@ -208,6 +223,9 @@ mbpr(void *kvmd, u_long mbaddr) "(current/cache)\n", packet_count, packet_free); =20 + printf("%ju/%ju/%ju/%ju socket UMA in use (current/cache/total/max)\n",= + socket_count, socket_free, socket_count + socket_free, socket_limit= ); + printf("%ju/%ju/%ju/%ju %juk (page size) jumbo clusters in use " "(current/cache/total/max)\n", jumbop_count, jumbop_free, jumbop_count + jumbop_free, @@ -280,6 +298,11 @@ mbpr(void *kvmd, u_long mbaddr) "mbuf+clusters)\n", mbuf_failures, cluster_failures, packet_failures); =20 + printf("%juK bytes allocated to socket\n", + socket_bytes / 1024); + + printf("%ju request for socket UMA denied\n", socket_failures); + printf("%ju/%ju/%ju requests for jumbo clusters denied " "(%juk/9k/16k)\n", jumbop_failures, jumbo9_failures, jumbo16_failures, jumbop_size / 1024); --------------080100020102070403070508-- --------------enigC7AC46FEA34DE35C9DBEE14E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1RbaOfuToMruuMARCjzaAJ9uSsxyQbXxvh5kEwK0fr2vd08MUACaAtWE GGkKi6DwIQA7a0p7FfzSW0w= =h9G5 -----END PGP SIGNATURE----- --------------enigC7AC46FEA34DE35C9DBEE14E-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 07:25:06 2007 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 46B6E16A417; Wed, 29 Aug 2007 07:25:06 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2409A13C48D; Wed, 29 Aug 2007 07:25:06 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 88304272E9; Wed, 29 Aug 2007 03:25:00 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 29 Aug 2007 03:25:00 -0400 X-Sasl-enc: ZDt3woj/brX/E5+kJlta7RYL0fCLJ05v3eIHM2vWwNhD 1188372300 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id C886F48C2; Wed, 29 Aug 2007 03:24:59 -0400 (EDT) Message-ID: <46D51F4A.1050004@FreeBSD.org> Date: Wed, 29 Aug 2007 08:24:58 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20070828165333.GA14159@sub.vaned.net> <46D48A3D.6080901@FreeBSD.org> In-Reply-To: <46D48A3D.6080901@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: [csjp@FreeBSD.org: Re: rtfree: 0xffffff00036fb1e0 has 1 refs] 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, 29 Aug 2007 07:25:06 -0000 BTW: Casual inspection with kscope suggests there is a similar=20 free-while-locked issue in nd6_ns_input() (netient6/nd6_nbr.c) and=20 in_arpinput() (netinet/if_ether.c). nd6_ns_input() references rt-=BBrt_gateway after rtfree(), a potential=20 race not to mention a use-after-free. I haven't checked Coverity for this, but it just doesn't look right. BMS From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 11:05:56 2007 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 2C29B16A419 for ; Wed, 29 Aug 2007 11:05:56 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from homos.ksn.ru (mx.ksn.ru [80.242.64.14]) by mx1.freebsd.org (Postfix) with ESMTP id 514B713C469 for ; Wed, 29 Aug 2007 11:05:54 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: (qmail 21530 invoked by uid 2529); 29 Aug 2007 17:38:55 +0700 Received: from antispam.localhost (localhost [127.0.0.1]) by mail2.ksn.ru (Postfix) with SMTP id 3E6B867827 for ; Wed, 29 Aug 2007 17:38:55 +0700 (NOVST) Received: from [80.242.66.33] (Eugene-Mogutov.officeip.ksn.ru [80.242.66.33]) by mail2.ksn.ru (Postfix) with ESMTP id D99D867829 for ; Wed, 29 Aug 2007 17:38:50 +0700 (NOVST) Message-ID: <46D54CC8.4020702@ngs.ru> Date: Wed, 29 Aug 2007 17:39:04 +0700 From: Ivan Alexandrovich User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-SpamTest-Info: Profile: Formal (1270/070803) X-SpamTest-Info: Profile: Detect Hard (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Archiving/Rejecting (2/030321) X-SpamTest-Version: SMTP-Filter Version 2.1.0 [0148], SpamtestISP/Release Subject: vlan stacking 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, 29 Aug 2007 11:05:56 -0000 Hi I'm wondering is anybody using double vlans ("q-in-q", "vlan stacking", any name you like) on production hosts? Does it play well with common ethernet device drivers in freebsd (concerning the frame size) - fxp, em, for example? Looks like that almost nobody mentions q-in-q in freebsd maillists/forums, except that nesting ng_vlan can be used to implement it. At the the end of the message there's an example of initialization sequence that we try to use. It's rather straightforward but maybe someone can criticize it or drop a hint how to do it the right way. Thanks, Ivan #rl0: creating 802.1q vlan 3555 and nested vlan 2555 ifconfig rl0 10.123.0.1 netmask 255.255.255.0 kldload ng_ether kldload ng_vlan ngctl mkpeer rl0: vlan lower downstream ngctl name rl0:lower vlanL1 ngctl connect rl0: vlanL1: upper nomatch ngctl mkpeer vlanL1: eiface vlan3555 ether ngctl msg vlanL1: addfilter '{ vlan=3555 hook="vlan3555" }' # the same mac address as for parent interface rl0 ifconfig ngeth0 link 00:c0:df:1f:22:de ifconfig ngeth0 10.124.0.1 netmask 255.255.255.0 ngctl mkpeer ngeth0: vlan lower downstream ngctl name ngeth0:lower vlanL2 ngctl connect ngeth0: vlanL2: upper nomatch ngctl mkpeer vlanL2: eiface vlan2555 ether ngctl msg vlanL2: addfilter '{ vlan=2555 hook="vlan2555" }' ifconfig ngeth1 link 00:c0:df:1f:22:de ifconfig ngeth1 10.125.0.1 netmask 255.255.255.0 ifconfig ngeth0 name spvid3555 ifconfig ngeth1 name dvlan2555 ifconfig rl0 promisc From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 11:14:20 2007 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 1374C16A419; Wed, 29 Aug 2007 11:14:20 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 84BCA13C458; Wed, 29 Aug 2007 11:14:19 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from onob2.irc.local ([192.168.2.10]) by mail1.cil.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 13:14:17 +0200 Message-ID: <46D5550C.6020209@ide.resurscentrum.se> Date: Wed, 29 Aug 2007 13:14:20 +0200 From: Jon Otterholm User-Agent: Thunderbird 2.0.0.0 (X11/20070614) MIME-Version: 1.0 To: freebsd-net@freebsd.org, Andrew Thompson Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 11:14:17.0374 (UTC) FILETIME=[BD4D5BE0:01C7EA2D] Cc: Subject: if_bridge and filtering on member 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: Wed, 29 Aug 2007 11:14:20 -0000 Hi. It seems that filtering on member interfaces are a bit buggy at the moment. For testing I tried to use the following 3 rules to block traffic using PF: The following works and blocks traffic: block log quick on bridge0 from xx.xx.xx.xx to any The following does not work: block log quick on em0.400 from xx.xx.xx.xx to any The following does not work either: block log quick on em0.400 from any to any su-2.05b# ifconfig bridge0 | more bridge0: flags=8843 mtu 1500 inet xx.xx.xx.xx netmask 0xfffffe00 broadcast xx.xx.xx.xx inet xx.xx.xx.xx netmask 0xffffff80 broadcast xx.xx.xx.xx ether XX:XX:XX:XX:XX:XX id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto stp maxaddr 500 timeout 1200 root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0 member: em0.400 flags=9c0 su-2.05b# sysctl net.link.bridge net.link.bridge.ipfw: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 0 su-2.05b# uname -a FreeBSD hostname.domain 6.2-STABLE FreeBSD 6.2-STABLE #6: Mon Aug 20 11:48:40 CEST 2007 Anything I missed? Accordingly to if_bridge(4) I am supposed to be able to block traffic on the interface it enters, on the bridge and on the interface it leaves. //JO From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 13:19:29 2007 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 DB09516A41B for ; Wed, 29 Aug 2007 13:19:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id BCA0C13C45A for ; Wed, 29 Aug 2007 13:19:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 29 Aug 2007 06:19:16 -0700 Received: from julian-mac.elischer.org (fibhost-122-174.fibernet.bacs-net.hu [85.66.122.174]) by idiom.com (Postfix) with ESMTP id 2B4EA1261F2; Wed, 29 Aug 2007 06:19:14 -0700 (PDT) Message-ID: <46D5724E.8020208@elischer.org> Date: Wed, 29 Aug 2007 06:19:10 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jeffrey Williams , freebsd-jail@freebsd.org, freebsd-net@freebsd.org References: <46D4983E.2050305@sailorfej.net> <20070828224314.GB4446@tcbug.org> In-Reply-To: <20070828224314.GB4446@tcbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Running jails on multiple subnets with multiple interfaces 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, 29 Aug 2007 13:19:29 -0000 Josh Paetzel wrote: > Jeffrey Williams wrote: >> I have a server with two interfaces, I want to run the host and a couple of >> jails using one interface on one subnet (internal interface, private IP, behind >> NAT/firewall) and some other jails using the other interface on another subnet >> (external interface, public IP, DMZ). >> >> Now my understanding of the challenge in doing this, is that the network stack >> is not "virtualized" in the jails, so all the jails use the same routing table, >> and for obvious reasons only one default router. (also just for sake of clarity >> I don't want to enable routing between interfaces on the jail host) >> >> Now if I understand all this correctly, then what will happen is, if I set the >> default router to the internal networks exit router (the NAT/firewall), then >> the jails listening on the external interface will only be able to talk to >> their local subnet, and because the internal subnet won't exist for them they >> won't be able to connect to the network at large. >> >> If I set the default router to the external networks exit router (the DMZ >> perimeter firewall) then the host and jails listening on the internal network >> won't be able to be able to talk to the internet beyond the local nets, the >> jails because the external network doesn't exist for them, and the host because >> even though it can talk to both nets, the services are configured to only >> listen to the internal net, and the it will be trying to send all outgoing >> traffic to the public net, thus not creating and NAT table entries on the >> NAT/Firewall for the return connections. >> >> Is there anyway to achieve what I have trying to do? >> >> Thanks >> Jeffrey williams > > PF makes a very effective workaround to this with it's route-to > option...effectively letting you bypass the routing table altogether > and set up per IP behavior. > > For instance, I use it in the following scenario, where a box has two > interfaces with public IPs and I don't want answers to connections on > the 'secondary' interface to go out the default route. ipfw can also do this using the fwd rule. in 7.x (and 6-stable) you can also do: ipfw table 1 add 1.2.3.4/28 2.2.2.2 <-- a specific route ipfw table 1 add 0.0.0.0/0 3.3.3.3 <-- a default route ipfw add 300 fwd tablearg ip from ${ADDRESS2} to table(1) out > > connection 1's router 192.168.1.1 > em0 ip 192.168.1.2/24 > > connection 2's router 10.0.0.1 > em1 ip 10.0.0.2/24 > > if connection 1 is the 'primary' link then set the default route to > 192.168.1.1 and put the following rule in pf.conf > > pass out route-to (em1 10.0.0.1) from 10.0.0.2 to ! 10.0.0.0/24 > > If you were to give more concrete examples of your config I could > probably help you out with a workable pf solution. > From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 13:25:53 2007 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 0F05516A418 for ; Wed, 29 Aug 2007 13:25:53 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id DCB3913C458 for ; Wed, 29 Aug 2007 13:25:52 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 7C1BA26473; Wed, 29 Aug 2007 09:25:50 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 29 Aug 2007 09:25:50 -0400 X-Sasl-enc: y3WwBGq2M61zZUqFg7fDdBJ2Z01zMdAq6Lb5Qcr/AdFQ 1188393950 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 10D2523363; Wed, 29 Aug 2007 09:25:49 -0400 (EDT) Message-ID: <46D573DD.3080709@FreeBSD.org> Date: Wed, 29 Aug 2007 14:25:49 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Ivan Alexandrovich References: <46D54CC8.4020702@ngs.ru> In-Reply-To: <46D54CC8.4020702@ngs.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vlan stacking 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, 29 Aug 2007 13:25:53 -0000 Ivan Alexandrovich wrote: > Hi > > I'm wondering is anybody using double vlans ("q-in-q", > "vlan stacking", any name you like) on production hosts? > Does it play well with common ethernet device drivers in freebsd > (concerning the frame size) - fxp, em, for example? > > Looks like that almost nobody mentions q-in-q in freebsd > maillists/forums, > except that nesting ng_vlan can be used to implement it. I'm sure you or someone else can come up with a creative solution for Q-in-Q or arbitrary nesting levels. It's not something I use, so, I pass. The mainline code doesn't support it without Netgraph; it would be necessary to allow vlan(4) to be nested. The ether_input() code demuxes 802.1q encapsulation but only 1 level. The reason for this is because the outer VLAN tag got moved into the mbuf pkthdr structure for if_bridge to be able to process it. I can't comment on the netgraph solution however. regards BMS From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 13:34:55 2007 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 E3CFD16A421 for ; Wed, 29 Aug 2007 13:34:55 +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 95BDC13C46E for ; Wed, 29 Aug 2007 13:34:55 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id F33596895; Wed, 29 Aug 2007 17:34:53 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id D0F8C688F; Wed, 29 Aug 2007 17:34:53 +0400 (MSD) Date: Wed, 29 Aug 2007 17:34:44 +0400 From: Igor Sysoev To: d@delphij.net Message-ID: <20070829133444.GH80424@rambler-co.ru> References: <46D516D9.4050007@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46D516D9.4050007@delphij.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-net , Robert Watson , hshh Subject: Re: Add socket related statistics to netstat(1)? 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, 29 Aug 2007 13:34:56 -0000 On Wed, Aug 29, 2007 at 02:48:57PM +0800, LI Xin wrote: > Here is a proof-of-concept patch that adds sockets related statistics to > netstat(1)'s -m option, which could make SA's life easier. Inspired by > a local user's suggestion. > > Comments? I think socket info should be groupped together: 2407/1058/3465 mbufs in use (current/cache/total) 1117/797/1914/98304 mbuf clusters in use (current/cache/total/max) 1117/90 mbuf+clusters out of packet secondary zone in use (current/cache) 761/417/1178/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 5879K/3526K/9406K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 15333/15537/30870/204800 socket UMA in use (current/cache/total/max) 5929K bytes allocated to socket 0 request for socket UMA denied 104/264/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 135834 requests for I/O initiated by sendfile 0 calls to protocol drain routines Second, I think socket memory calculation should include tcpcb, udpcb, inpcb, unpcb and probably tcptw items. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 14:11:05 2007 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 CCBA616A418 for ; Wed, 29 Aug 2007 14:11:05 +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 8397813C465 for ; Wed, 29 Aug 2007 14:11:05 +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 60A4747C10; Wed, 29 Aug 2007 09:39:57 -0400 (EDT) Date: Wed, 29 Aug 2007 14:39:57 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Igor Sysoev In-Reply-To: <20070829133444.GH80424@rambler-co.ru> Message-ID: <20070829143627.M35010@fledge.watson.org> References: <46D516D9.4050007@delphij.net> <20070829133444.GH80424@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net , d@delphij.net, hshh Subject: Re: Add socket related statistics to netstat(1)? 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, 29 Aug 2007 14:11:05 -0000 On Wed, 29 Aug 2007, Igor Sysoev wrote: > On Wed, Aug 29, 2007 at 02:48:57PM +0800, LI Xin wrote: > >> Here is a proof-of-concept patch that adds sockets related statistics to >> netstat(1)'s -m option, which could make SA's life easier. Inspired by a >> local user's suggestion. >> >> Comments? > > I think socket info should be groupped together: The netstat -m output is getting quite cluttered these days, isn't it. I wonder if we should be laying it out a bit more consistently, perhaps something like: current cache total max mbufs 2407 1058 3465 - mbuf clusters 1117 797 1914 98304 mbufs + clusters 1117 90 - - 4k jumbo clusters 761 417 1178 0 ... It's less compact but possibly quite a bit more readable... Robert N M Watson Computer Laboratory University of Cambridge > > 2407/1058/3465 mbufs in use (current/cache/total) > 1117/797/1914/98304 mbuf clusters in use (current/cache/total/max) > 1117/90 mbuf+clusters out of packet secondary zone in use (current/cache) > 761/417/1178/0 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) > 5879K/3526K/9406K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 15333/15537/30870/204800 socket UMA in use (current/cache/total/max) > 5929K bytes allocated to socket > 0 request for socket UMA denied > 104/264/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 135834 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > Second, I think socket memory calculation should include > tcpcb, udpcb, inpcb, unpcb and probably tcptw items. > > > -- > Igor Sysoev > http://sysoev.ru/en/ > _______________________________________________ > 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 Wed Aug 29 15:57:13 2007 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 ECD5B16A417; Wed, 29 Aug 2007 15:57:13 +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 A50E913C442; Wed, 29 Aug 2007 15:57:13 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 77EBA68F1; Wed, 29 Aug 2007 19:57:12 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 500B468CC; Wed, 29 Aug 2007 19:57:12 +0400 (MSD) Date: Wed, 29 Aug 2007 19:57:02 +0400 From: Igor Sysoev To: Robert Watson Message-ID: <20070829155702.GK80424@rambler-co.ru> References: <46D516D9.4050007@delphij.net> <20070829133444.GH80424@rambler-co.ru> <20070829143627.M35010@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070829143627.M35010@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-net , d@delphij.net, hshh Subject: Re: Add socket related statistics to netstat(1)? 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, 29 Aug 2007 15:57:14 -0000 On Wed, Aug 29, 2007 at 02:39:57PM +0100, Robert Watson wrote: > > On Wed, 29 Aug 2007, Igor Sysoev wrote: > > >On Wed, Aug 29, 2007 at 02:48:57PM +0800, LI Xin wrote: > > > >>Here is a proof-of-concept patch that adds sockets related statistics to > >>netstat(1)'s -m option, which could make SA's life easier. Inspired by a > >>local user's suggestion. > >> > >>Comments? > > > >I think socket info should be groupped together: > > The netstat -m output is getting quite cluttered these days, isn't it. I > wonder if we should be laying it out a bit more consistently, perhaps > something like: > > current cache total max > mbufs 2407 1058 3465 - > mbuf clusters 1117 797 1914 98304 > mbufs + clusters 1117 90 - - > 4k jumbo clusters 761 417 1178 0 > ... > > It's less compact but possibly quite a bit more readable... I agree - it's much better, however, someone may argue that it will break statistic scripts. May we should use anthor switch. > >2407/1058/3465 mbufs in use (current/cache/total) > >1117/797/1914/98304 mbuf clusters in use (current/cache/total/max) > >1117/90 mbuf+clusters out of packet secondary zone in use (current/cache) > >761/417/1178/0 4k (page size) jumbo clusters in use > >(current/cache/total/max) > >0/0/0/0 9k jumbo clusters in use (current/cache/total/max) > >0/0/0/0 16k jumbo clusters in use (current/cache/total/max) > >5879K/3526K/9406K bytes allocated to network (current/cache/total) > >0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > >0/0/0 requests for jumbo clusters denied (4k/9k/16k) > >15333/15537/30870/204800 socket UMA in use (current/cache/total/max) > >5929K bytes allocated to socket > >0 request for socket UMA denied > >104/264/6656 sfbufs in use (current/peak/max) > >0 requests for sfbufs denied > >0 requests for sfbufs delayed > >135834 requests for I/O initiated by sendfile > >0 calls to protocol drain routines > > > >Second, I think socket memory calculation should include > >tcpcb, udpcb, inpcb, unpcb and probably tcptw items. > > > > > >-- > >Igor Sysoev > >http://sysoev.ru/en/ > >_______________________________________________ > >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" > -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Wed Aug 29 15:59:09 2007 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 B00AC16A418; Wed, 29 Aug 2007 15:59:09 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (unknown [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id 6E35813C457; Wed, 29 Aug 2007 15:59:09 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1IQPwg-000Gba-2h; Wed, 29 Aug 2007 11:59:06 -0400 Date: Wed, 29 Aug 2007 11:59:06 -0400 From: Gary Palmer To: Robert Watson Message-ID: <20070829155906.GC970@in-addr.com> Mail-Followup-To: Robert Watson , Igor Sysoev , freebsd-net , d@delphij.net, hshh References: <46D516D9.4050007@delphij.net> <20070829133444.GH80424@rambler-co.ru> <20070829143627.M35010@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070829143627.M35010@fledge.watson.org> Cc: freebsd-net , Igor Sysoev , d@delphij.net, hshh Subject: Re: Add socket related statistics to netstat(1)? 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, 29 Aug 2007 15:59:09 -0000 On Wed, Aug 29, 2007 at 02:39:57PM +0100, Robert Watson wrote: > > On Wed, 29 Aug 2007, Igor Sysoev wrote: > > >On Wed, Aug 29, 2007 at 02:48:57PM +0800, LI Xin wrote: > > > >>Here is a proof-of-concept patch that adds sockets related statistics to > >>netstat(1)'s -m option, which could make SA's life easier. Inspired by a > >>local user's suggestion. > >> > >>Comments? > > > >I think socket info should be groupped together: > > The netstat -m output is getting quite cluttered these days, isn't it. I > wonder if we should be laying it out a bit more consistently, perhaps > something like: > > current cache total max > mbufs 2407 1058 3465 - > mbuf clusters 1117 797 1914 98304 > mbufs + clusters 1117 90 - - > 4k jumbo clusters 761 417 1178 0 > ... > > It's less compact but possibly quite a bit more readable... We'll need to leave the old format there for a while as there are probably quite a few programs depending on the old format out there. Maybe add -mh which has the user-friendly format Robert suggested? (the 'h' for "Human friendly") Gary > Robert N M Watson > Computer Laboratory > University of Cambridge > > > > >2407/1058/3465 mbufs in use (current/cache/total) > >1117/797/1914/98304 mbuf clusters in use (current/cache/total/max) > >1117/90 mbuf+clusters out of packet secondary zone in use (current/cache) > >761/417/1178/0 4k (page size) jumbo clusters in use > >(current/cache/total/max) > >0/0/0/0 9k jumbo clusters in use (current/cache/total/max) > >0/0/0/0 16k jumbo clusters in use (current/cache/total/max) > >5879K/3526K/9406K bytes allocated to network (current/cache/total) > >0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > >0/0/0 requests for jumbo clusters denied (4k/9k/16k) > >15333/15537/30870/204800 socket UMA in use (current/cache/total/max) > >5929K bytes allocated to socket > >0 request for socket UMA denied > >104/264/6656 sfbufs in use (current/peak/max) > >0 requests for sfbufs denied > >0 requests for sfbufs delayed > >135834 requests for I/O initiated by sendfile > >0 calls to protocol drain routines > > > >Second, I think socket memory calculation should include > >tcpcb, udpcb, inpcb, unpcb and probably tcptw items. > > > > > >-- > >Igor Sysoev > >http://sysoev.ru/en/ > >_______________________________________________ > >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 Wed Aug 29 23:31:21 2007 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 C337B16A418 for ; Wed, 29 Aug 2007 23:31:21 +0000 (UTC) (envelope-from sinet@siliconindia.net) Received: from siliconindia.org (mail.siliconindia.org [72.52.77.20]) by mx1.freebsd.org (Postfix) with ESMTP id AF58A13C45E for ; Wed, 29 Aug 2007 23:31:21 +0000 (UTC) (envelope-from sinet@siliconindia.net) Received: from siliconindia.org (localhost.localdomain [127.0.0.1]) by siliconindia.org (Postfix) with ESMTP id 407EE7504F for ; Wed, 29 Aug 2007 15:23:11 -0700 (PDT) Received: (from suresh@localhost) by siliconindia.org (8.13.1/8.13.1/Submit) id l7TMNBDa018450; Wed, 29 Aug 2007 15:23:11 -0700 X-Authentication-Warning: siliconindia.org: suresh set sender to sinet@siliconindia.net using -f To: freebsd-net@freebsd.org Date: Wed, 29 Aug 2007 15:23:11 -0700 From: Sonam Reddy Message-ID: <1babb552560c199643423714477af9dd@mail.siliconindia.org> X-Priority: 3 X-Mailer: PHPMailer [version 1.73] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Subject: I am inviting you to Join my Siliconinda network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sinet@siliconindia.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2007 23:31:21 -0000 Hi , I'd like to add you to my network on SiliconIndia. Once you join, you can see all my connections online and can contact them directly. It is a business network for your carrier, if you are thinking about your future and opportunities just pay a look, it’s easy to register and it can give you an edge that other don't have. Regards, Sonam Click on the link below to join the network of Sonam Reddy and start your own network: http://www.siliconindia.com/register.php?id=Rk7qPcvL (Please note: Membership is through invitation only) Your Invitation ID: Rk7qPcvL Note: If you encounter any problem while registration, please send an email to sinet@siliconindia.com. To subscribe to SI Dailydose e-newsletter click here http://www.siliconindia.com/newsletter/shownews.php ----------------------------------------------------------------------------------------- To unsubscribe from future mailing from SI, click here http://www.siliconindia.com/invitation/remove.php From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 08:33:08 2007 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 6D0AD16A41B for ; Thu, 30 Aug 2007 08:33:08 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 4396C13C46A for ; Thu, 30 Aug 2007 08:33:08 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so523450waf for ; Thu, 30 Aug 2007 01:32:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=LrI5Lb7uk4U4s/vFuU6s3dkkaOcvsZY/QAfxFhjpDsJ9bTVQIREAyH1x1XHyjBJu2sG4imh7Csdg8auZKchoMDBITenIBFYBfglVlD/Kdt8FfpSjP/aaFbftpupc7RbR3e3mNqGQbwhaaIuOUc6XlweEoPG2YCQkt939ZtMBGHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=r7JobPKsLLhsd2QgP9OZ78VCKhVAq3E7Sd+I/Z9xKMWokTA9klndoxZxDt3jXsDyZ+DjFkhYh+GFbdZ5Y2o4VtKSa6XeIEtRnhI5bPedvlk/kjVUWAy/hLQqiYL4zGqoOWLrV2nMRKimTDwh1DFHAWifLcC+wQrXCWJfzcl+pFU= Received: by 10.114.157.1 with SMTP id f1mr236738wae.1188461318848; Thu, 30 Aug 2007 01:08:38 -0700 (PDT) Received: by 10.114.58.6 with HTTP; Thu, 30 Aug 2007 01:08:38 -0700 (PDT) Message-ID: <61b573980708300108k69446e4epe390c5b2d4f35c0e@mail.gmail.com> Date: Thu, 30 Aug 2007 11:08:38 +0300 From: "Shteryana Shopova" Sender: shteryana@gmail.com To: bzeeb+freebsd+lor@zabbadoz.net MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 3dfb87558ad75028 Cc: freebsd-net@freebsd.org Subject: iwi(4)-related LOR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syrinx@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 08:33:08 -0000 Hi, I am getting the following LOR on my notebook - iwi0: mem 0xc8400000-0xc8400fff irq 21 at device 4.0 on pci2 iwi0: Ethernet address: 00:15:00:28:5c:dc iwi0: [ITHREAD] iwi0: link state changed to UP iwi0: link state changed to DOWN iwi0: link state changed to UP lock order reversal: 1st 0xc427000c ieee80211com (802.11 com lock) @ /usr/src/sys/net80211/ieee80211_scan.c:523 2nd 0xc4271400 iwi0 (network driver) @ /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1907 KDB: stack backtrace: db_trace_self_wrapper(c08f94ff,e25d8a90,c066448e,c08fb8a2,c4271400,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08fb8a2,c4271400,c3d02950,c426e91b,c426e044,...) at kdb_backtrace+0x29 witness_checkorder(c4271400,9,c426e044,773,c0997fb4,...) at witness_checkorder+0x6de _mtx_lock_flags(c4271400,0,c426e044,773,e25d8b08,...) at _mtx_lock_flags+0xbc iwi_start(c3d16800,c42711b4,e25d8bc8,c06ef074,c3d16800,...) at iwi_start+0xae if_start(c3d16800,0,c09064a9,17e,e25d8bac,...) at if_start+0x59 ieee80211_send_nulldata(c43e0000,38,c08faf85,6ce,c427000c) at ieee80211_send_nulldata+0x1f4 ieee80211_sta_pwrsave(c4270004,1,20b,e25d8c44,c3ff6000,...) at ieee80211_sta_pwrsave+0x201 scan_restart(c3ff6000,c4270004,c0906fd5,20b,c4270004,...) at scan_restart+0x96 ieee80211_bg_scan(c4270004,e25d8c84,c06ebf27,c4270004,e25d8c68,...) at ieee80211_bg_scan+0x10f ieee80211_scan_timeout(c4270004,e25d8c68,80246,c0993c64,e25d8c84,...) at ieee80211_scan_timeout+0x1c ieee80211_node_timeout(c4270004,0,c08f7dfb,ef,0,...) at ieee80211_node_timeout+0x17 softclock(0,0,c08f37b3,471,c3af31e4,...) at softclock+0x299 ithread_loop(c3a7ac50,e25d8d38,c08f3533,315,c3ab3558,...) at ithread_loop+0x1b5 fork_exit(c0611de0,c3a7ac50,e25d8d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe25d8d70, ebp = 0 --- That's on a fresh CURRENT (a couple of days old) and the latest version of if_iwi.c - $FreeBSD: src/sys/dev/iwi/if_iwi.c,v 1.56 2007/08/29 21:52:03$. Any suggestions are welcome. cheers, Shteryana From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 09:31:13 2007 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 A59A616A41A; Thu, 30 Aug 2007 09:31:13 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 2DD7B13C4A5; Thu, 30 Aug 2007 09:31:13 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 2EA3B1CC58; Thu, 30 Aug 2007 21:30:31 +1200 (NZST) Date: Thu, 30 Aug 2007 21:30:31 +1200 From: Andrew Thompson To: Shteryana Shopova Message-ID: <20070830093031.GA57339@heff.fud.org.nz> References: <61b573980708300108k69446e4epe390c5b2d4f35c0e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61b573980708300108k69446e4epe390c5b2d4f35c0e@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: bzeeb+freebsd+lor@zabbadoz.net, freebsd-net@freebsd.org Subject: Re: iwi(4)-related LOR 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, 30 Aug 2007 09:31:13 -0000 On Thu, Aug 30, 2007 at 11:08:38AM +0300, Shteryana Shopova wrote: > Hi, > > I am getting the following LOR on my notebook - > > iwi0: mem 0xc8400000-0xc8400fff irq 21 > at device 4.0 on pci2 > iwi0: Ethernet address: 00:15:00:28:5c:dc > iwi0: [ITHREAD] > iwi0: link state changed to UP > iwi0: link state changed to DOWN > iwi0: link state changed to UP > lock order reversal: > 1st 0xc427000c ieee80211com (802.11 com lock) @ > /usr/src/sys/net80211/ieee80211_scan.c:523 > 2nd 0xc4271400 iwi0 (network driver) @ > /usr/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1907 > KDB: stack backtrace: > db_trace_self_wrapper(c08f94ff,e25d8a90,c066448e,c08fb8a2,c4271400,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08fb8a2,c4271400,c3d02950,c426e91b,c426e044,...) at > kdb_backtrace+0x29 > witness_checkorder(c4271400,9,c426e044,773,c0997fb4,...) at > witness_checkorder+0x6de > _mtx_lock_flags(c4271400,0,c426e044,773,e25d8b08,...) at _mtx_lock_flags+0xbc > iwi_start(c3d16800,c42711b4,e25d8bc8,c06ef074,c3d16800,...) at iwi_start+0xae > if_start(c3d16800,0,c09064a9,17e,e25d8bac,...) at if_start+0x59 > ieee80211_send_nulldata(c43e0000,38,c08faf85,6ce,c427000c) at > ieee80211_send_nulldata+0x1f4 > > That's on a fresh CURRENT (a couple of days old) and the latest > version of if_iwi.c - $FreeBSD: src/sys/dev/iwi/if_iwi.c,v 1.56 > 2007/08/29 21:52:03$. Any suggestions are welcome. This one is known and is due to iwi(4) using a single lock rather than a seperate one for tx like ath does. As far as I know its not serious. Andrew From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 15:21:34 2007 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 B99C516A417 for ; Thu, 30 Aug 2007 15:21:34 +0000 (UTC) (envelope-from dailydose@siliconindia.org) Received: from siliconindia.org (mail.siliconindia.org [72.52.77.20]) by mx1.freebsd.org (Postfix) with ESMTP id A612013C481 for ; Thu, 30 Aug 2007 15:21:34 +0000 (UTC) (envelope-from dailydose@siliconindia.org) Received: from siliconindia.org (localhost.localdomain [127.0.0.1]) by siliconindia.org (Postfix) with ESMTP id AEF177513D for ; Thu, 30 Aug 2007 05:24:07 -0700 (PDT) Received: (from dailydose@localhost) by siliconindia.org (8.13.1/8.13.1/Submit) id l7UCO7da013094; Thu, 30 Aug 2007 05:24:07 -0700 To: freebsd-net@freebsd.org Date: Thu, 30 Aug 2007 05:24:07 -0700 From: si dailydose Message-ID: <134e0490fb0c7ad951d6d5b6c18a61bb@mail.siliconindia.org> X-Priority: 3 X-Mailer: PHPMailer [version 1.73] Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Tata Consultancy bags $140 Mn deal from BSNL/One in eight US residents poor, but Indian Americans better off/No area-wise limit on number of telecom operators X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dailydose@siliconindia.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 15:21:34 -0000 SiliconIndia Daily Dose | August 30 2007 >> TOP NEWS [1]Tata Consultancy bags $140 Mn deal from BSNL Indian IT bellwether Tata Consultancy Services (TCS) has bagged a deal worth $140 million from the state-run telecom giant Bharat Sanchar Nigam Ltd (BSNL). [2]One in eight US residents poor, but Indian Americans better off One in eight persons living in the world's richest nation is considered poor, but then in America the official poverty level for a family of four with two children is $20,444 per annum. Indian American families have an average income of $61,322. [3]No area-wise limit on number of telecom operators Keeping in mind the rising number of telecom users in the country, the Telecom Regulatory Authority of India (TRAI) Wednesday said there would be no limit on the number of service providers in a particular area. >> TECHNOLOGY [4]Cyberabad IT industry takes terror attacks in its stride The booming information technology industry in this city, second only to Bangalore, is concerned over the terror bombings but feels it will have no immediate impact on its growth or investments. [5]Over 42,000 Oracle professionals certified in India As part of its ongoing commitment to enhance the skills of IT professionals in the country, Oracle today announced that Oracle University has trained and certified over 42,000 Oracle Professionals in India. >> BUSINESS [6]TCS, Cognizant get nod for SEZs The government Thursday gave formal approval to Tata Consultancy Services (TCS), Cognizant Technologies and 18 others to set up special economic zones across the country. [7]Ashok Leyland joins hands with Nissan to make LCVs India's leading bus and truck maker Ashok Leyland Limited Wednesday joined hands with Japan's Nissan Motor Company to make light commercial vehicles (LCV). >> OTHER NEWS [8]New airport turban checks upset Sikhs in U.S. Sikh organisations in the U.S. have received dozens of complaints from community members saying they were told to remove their turbans at airports for security checks in the wake of a new rule. [9]The Leadership Summit with a Difference The siliconindia Leadership Summit is to be held in Bangalore on August 31st, 2007 and is sure to kick off an active dialogue amongst leaders in the Indian technology industry. On the spot registration for the summit is available tomorrow. >> BLOGS [10]Stock Advice India - [11]Sam Mittra No matter how small investment one makes...surely this will make him / her proud and rewarded......stocks are also known as silent wealth creator instruments too... MAGAZINE [12]Cover Story [13][aug_2007.jpg] GlobalLogic team has an audacious goal to dominate the global product development market. Read to know how the company is 'Built to Last' Leadership Summit [14]Siliconindia Leadership Summit Siliconindia Leadership Summit will kick off an active dialogue amongst leaders in the Indian technology industry. August 31, 3007. Bangalore [15]Click here for More Details SiliconIndia Books [16]The Man Who Divided India [17][mandivede.jpg] Even after the lapse of over fifty years, the question of how and why India was divided remains unresolved. [18]Buy Now [19]Ayurveda [20][Ayurveda_LHealth.jpg] Ayurveda treats not just the ailment but the whole person and emphasizes prevention of disease to avoid the need for cure... [21]Buy Now [22]Click Here If you are siliconindia network member and do not want to receive daily dose, please select "unsubscribe" from your setting page when you log in. If you are not a member,[23] visit here to stop receiving daily dose. References Visible links 1. http://www.siliconindia.com/shownews/36841 2. http://www.siliconindia.com/shownews/36843 3. http://www.siliconindia.com/shownews/36845 4. http://www.siliconindia.com/shownews/36846 5. http://www.siliconindia.com/shownews/36848 6. http://www.siliconindia.com/shownews/36842 7. http://www.siliconindia.com/shownews/36844 8. http://www.siliconindia.com/shownews/36847 9. http://www.siliconindia.com/shownews/36849 10. http://blogs.siliconindia.com/stockline 11. http://blogs.siliconindia.com/stockline 12. http://www.siliconindia.com/magazine/fullstory.php/RXCL108594358 13. http://www.siliconindia.com/magazine/fullstory.php/RXCL108594358 14. http://www.siliconindia.com/Leadership 15. http://www.siliconindia.com/Leadership 16. http://www.siliconindia.com/books/newbooks/booksdetails/1349 17. http://www.siliconindia.com/books/newbooks/booksdetails/1349 18. http://www.siliconindia.com/books/newbooks/booksdetails/1349 19. http://www.siliconindia.com/books/newbooks/booksdetails/561 20. http://www.siliconindia.com/books/newbooks/booksdetails/561 21. http://www.siliconindia.com/books/newbooks/booksdetails/561 22. http://a.tribalfusion.com/i.click?site=siliconindiacom&adSpace=ROS&size=728x90&requestID=1658934770 23. http://www.siliconindia.com/newsletter/remove.php Hidden links: 24. http://www.siliconindia.com/anniversary/ 25. http://www.chugh.com/ 26. http://www.india.amazon.com/ From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 16:28:13 2007 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 60A4916A418 for ; Thu, 30 Aug 2007 16:28:13 +0000 (UTC) (envelope-from sinet@siliconindia.org) Received: from siliconindia.org (mail.siliconindia.org [72.52.77.20]) by mx1.freebsd.org (Postfix) with ESMTP id 50EBB13C459 for ; Thu, 30 Aug 2007 16:28:13 +0000 (UTC) (envelope-from sinet@siliconindia.org) Received: from mail.siliconindia.org (siliconindia [72.52.77.20]) by siliconindia.org (Postfix) with ESMTP id 14C4175089 for ; Thu, 30 Aug 2007 08:08:22 -0700 (PDT) Date: Thu, 30 Aug 2007 08:08:22 -0700 To: freebsd-net@freebsd.org From: SINET Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.73] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Subject: Welcome to SI Network - Your Career, Your Country. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sinet@siliconindia.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2007 16:28:13 -0000 SiliconIndia - Tips to make best use of the network. Dear John , Thanks for becoming a SiliconIndia network. SiliconIndia site offers largest Content and Community networks for global professionals, entrepreneurs and students with interests in India. Your SiliconIndia Network account is activated, your account details are as follows: User ID/ Email: freebsd-net@freebsd.org Password: blubber Login at: http://www.siliconindia.com The following tips will help you to get the most out of SiliconIndia network Get networked: Using the My Network section in your account you can search the entire SiliconIndia member community and ask members to join your network. Messages: Once connected, you can interact with these members using messaging platform. Groups: Create you groups to discuss topics of your interest. Mentorship: Here is a chance for you to get featured on our homepage. Become a mentor to apprentice seeking guidance in career or academics or wish to guide another user to success in his/her professional life. We feature the active mentors on our homepage providing them visibility across the network. Blog: Here is another oppurtunity for you to be featured on SiliconIndia homepage. Blog on our site to publish your opinions, thoughts, experiences and discoveries to entire world wide web. Based on the content of a blog we will promote them on homepage to be read by thousands of visitors' each day. Thanks once again for signing up. Have fun while helping build a smarter India. SiliconIndia Team From owner-freebsd-net@FreeBSD.ORG Thu Aug 30 23:22:34 2007 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 1098D16A419 for ; Thu, 30 Aug 2007 23:22:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD6A13C469 for ; Thu, 30 Aug 2007 23:22:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so536874nfd for ; Thu, 30 Aug 2007 16:22:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=NRXMDVtnFFRDKlOd4KLtdfJh2QRGhbgeSt2IsZLshfKJtQH1bMI1x1FvSLx6wQy01U11Hfxeo8yp5AJ71om8AlF5yZJgZa7B74o931xH7s0kuAOSQUE0TwkitU57jhVYA0zfey25mU/0EhhZyMB6VX9n3OumpcrDLsEKSfWovYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=g55jH03ksvN1WPZ5hALMMxmBeMzKKeG7PxEHvNUZssbMkEjgYXPnGcnWJlftKM+FS3LzNzHGWJRJtI80JQzCmm7eEv7qruROKK7QGLdl5YYmu4ZbaXb6nAiBOcbXFFFv0e1wMMFBS066dyNlmzOWerABRDVs7TFf1oBNq44ziVI= Received: by 10.86.100.7 with SMTP id x7mr795685fgb.1188516152003; Thu, 30 Aug 2007 16:22:32 -0700 (PDT) Received: by 10.86.81.6 with HTTP; Thu, 30 Aug 2007 16:22:31 -0700 (PDT) Message-ID: <2a41acea0708301622j6b4eeab9h62576dcfd1325b0a@mail.gmail.com> Date: Thu, 30 Aug 2007 16:22:31 -0700 From: "Jack Vogel" To: "John Baldwin" , "Andre Oppermann" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: "freebsd-net@freebsd.org" Subject: vlan filtering 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, 30 Aug 2007 23:22:34 -0000 I was just working on a bug in the Oplin driver that had me look a bit more at VLAN code than I had previously. FreeBSD has apparently never used the hardware vlan filtering that our hardware can do, is there a systemic reason for this, or has the code lagged in its use of the system? I at least don't understand how the driver is supposed to get the vlan id to set in the filter, am I just unenlightened? :) If this is doable I can add code into em as well as ixgbe. Jack From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 05:28:57 2007 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 5025A16A418 for ; Fri, 31 Aug 2007 05:28:57 +0000 (UTC) (envelope-from praharshah123@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id D8EE513C458 for ; Fri, 31 Aug 2007 05:28:56 +0000 (UTC) (envelope-from praharshah123@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so855868waf for ; Thu, 30 Aug 2007 22:28:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=lWcZRkxn7fhqFZIvliy6TXVdKfk5B9boq8LafxJcTosNCFeLgxL+ceSYsHaEE0vvoWHVyFpiSzaaolkAXj4v1oX+9MvQ8m6ON1Pj6df2XeYZR7bik+1Kq/3vGx8qhRtb7OHJYDoSoDpEhIqewdwe6ty1stHyHbf/rdRfcvv60cM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=fCU1iSJgF6OTXbtUhZu0babj5rijcTqQXasDFywPEPSgPFgOipNO+M30n4jmHCyodwPbw81SmfmSmBhvcH+YkP1SR0+XDC3qhPjoxRC7BmAhRUfss3gNIXvs1VMgwvKaVtLAwC0o85VJISJpQArc1cFEaDdG3m9DBJUBsvZnIQI= Received: by 10.114.179.1 with SMTP id b1mr76043waf.1188536428352; Thu, 30 Aug 2007 22:00:28 -0700 (PDT) Received: by 10.114.36.9 with HTTP; Thu, 30 Aug 2007 22:00:28 -0700 (PDT) Message-ID: Date: Fri, 31 Aug 2007 10:30:28 +0530 From: "Prahar Shah" 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 Subject: Accessing device memory from user-land application process 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, 31 Aug 2007 05:28:57 -0000 Hi. I am writing a device driver in user-land process. I do a contigmalloc() to allocate the descriptor memory, do a vtophys() on it and mmap that memory in the user-land application process. I allocate buffers again using contigmalloc(), and mmap it within the same process. I pass on a buffer each to the device descriptor. And my packet reception works fine. While processing packets, once i reset the device (all device registers and related memory), and repopulate buffers into the descriptors, I occasionally find that while receiving a packet after reset, the buffer address that I read from the first descriptor is not the one that I gave to the descriptor after the reset. Instead, it turns out to be an older buffer address which as allocated to a descriptor which was supposed to be read next, prior to the reset. My doubt is, could this be a cache-coherency issue? Or could there be a chance that the device might be caching the buffer address available with the descriptors, and re-writing back to the descriptor after receiving the packet, and somehow these cached address are not flushed during a device reset? If i've missed any details, kindly let me know. Any help would be greatly appriciated -- Prahar Shah From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 10:28:11 2007 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 2ACDF16A417 for ; Fri, 31 Aug 2007 10:28:11 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id ECEEA13C46B for ; Fri, 31 Aug 2007 10:28:10 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 8997 invoked from network); 31 Aug 2007 05:27:33 -0500 Received: from 124-170-70-31.dyn.iinet.net.au (HELO localhost) (124.170.70.31) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 31 Aug 2007 05:27:32 -0500 Date: Fri, 31 Aug 2007 20:27:29 +1000 From: Norberto Meijome To: FreeBSD Net ML , FreeBSD Questions ML Message-ID: <20070831202729.7e4c0f7a@localhost> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: pf rdr + netsed : reinject loop... 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, 31 Aug 2007 10:28:11 -0000 Hello everyone, I need your help / insight here :) My setup, 2 VMs, XP (WinXP) and BSD (FreeBSD 6.2) [XP ,172.16.82.81 ] --- [172.16.82.81,em1 BSD A.B.C.D,em0] --- The Interweb ---- [Other_servers_galore] A.B.C.D is a public IP. [Other_servers_galore] represents all and any servers XP wants to talk to . I really don't know either port or IP of these servers. BSD is performing as gateway for XP , with NAT on em0 using pf. I want to replace certain bytes (FOO) in TCP packets between XP and [Other_servers_galore] for other bytes (BAR). Vlad Galu pointed out that net/netsed can help with this (with overhead, i know, this is only a test ). (Thanks again! ) so what I have setup : 1) pf.conf has : ---- ext_if="em0" int_if="em1" nat on $ext_if from $internal_net to any -> ($ext_if) rdr on $int_if proto tcp from 172.16.82.81 to any -> 127.0.0.1 port 10101 ----- 2) I run netsed in transparent proxy mode as : netsed tcp 10101 0 0 s/FOO/BAR --- The traffic from XP gets redirected just fine to netsed, which replaces the bytes just fine. BUT the changed packets (the output of netsed) get reinjected somewhere so that the rdr hits them again, sending them back to netsed ad infinitum. ( yes, i managed to hit a load of 700+ without anything ever leaving BSD ...quite cool) Now, netsed works just fine in that setup if I define the IP, eg : pf.conf : ext_if="em0" int_if="em1" nat on $ext_if from $internal_net to any -> ($ext_if) rdr on $int_if proto tcp from 172.16.82.81 to O.P.Q.R -> 127.0.0.1 port 10101 netsed : netsed tcp 10101 O.P.Q.R 0 s/FOO/BAR traffic goes to the external server O.P.Q.R ... but this was just a proof of concept, as I really can't tell the remote IPs in advance How do I modify this setup so that netsed packets aren't caught again by pf's rdr and sent back into netsed ? I'm happy to try other tools / setups... thanks for your time and any help you can provide :) B _________________________ {Beto|Norberto|Numard} Meijome "Great spirits have often encountered violent opposition from mediocre minds." Albert Einstein I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 10:31:18 2007 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 6374616A41B for ; Fri, 31 Aug 2007 10:31:18 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog14.obsmtp.com (s200aog14.obsmtp.com [207.126.144.128]) by mx1.freebsd.org (Postfix) with SMTP id 8AC2E13C4A6 for ; Fri, 31 Aug 2007 10:31:17 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Fri, 31 Aug 2007 10:27:37 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id AE0A518141C; Fri, 31 Aug 2007 10:51:52 +0100 (BST) Message-ID: <46D7E4B8.4030609@tomjudge.com> Date: Fri, 31 Aug 2007 10:51:52 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0708301622j6b4eeab9h62576dcfd1325b0a@mail.gmail.com> In-Reply-To: <2a41acea0708301622j6b4eeab9h62576dcfd1325b0a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Andre Oppermann , John Baldwin Subject: Re: vlan filtering 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, 31 Aug 2007 10:31:18 -0000 Jack Vogel wrote: > I was just working on a bug in the Oplin driver that had me look > a bit more at VLAN code than I had previously. > > FreeBSD has apparently never used the hardware vlan filtering > that our hardware can do, is there a systemic reason for this, > or has the code lagged in its use of the system? > > I at least don't understand how the driver is supposed to get > the vlan id to set in the filter, am I just unenlightened? :) > > If this is doable I can add code into em as well as ixgbe. > > Jack This isn't really directly related but could be important for some users. If you where to use this would the card handle Q in Q properly with the filter on or would there have to be some form of administrative option to turn the hardware filter on/off? Tom From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 10:35:28 2007 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 64E1216A468 for ; Fri, 31 Aug 2007 10:35:28 +0000 (UTC) (envelope-from magpasikat@yahoo.com) Received: from n8a.bullet.mail.re3.yahoo.com (n8a.bullet.mail.re3.yahoo.com [68.142.236.46]) by mx1.freebsd.org (Postfix) with SMTP id 2739D13C46B for ; Fri, 31 Aug 2007 10:35:28 +0000 (UTC) (envelope-from magpasikat@yahoo.com) Received: from [68.142.230.29] by n8.bullet.re3.yahoo.com with NNFMP; 31 Aug 2007 10:22:00 -0000 Received: from [66.196.101.133] by t2.bullet.re2.yahoo.com with NNFMP; 31 Aug 2007 10:22:00 -0000 Received: from [127.0.0.1] by rrr4.mail.re1.yahoo.com with NNFMP; 31 Aug 2007 10:22:00 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 757548.76608.bm@rrr4.mail.re1.yahoo.com Received: (qmail 8352 invoked by uid 60001); 31 Aug 2007 10:20:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=WCkYkJqpHLzAvxKqYIiINju67a7Rq6BW5aWZMW+Hh0AKAzR2h4lHinn6CtEs97PYNAKGHLqRMUFY5edJ9wGiTqvKQa3RUplJF34xE45R4OT1JST0o3/OvHZkWIiRCpV0xjoekN65KXe+TEhocQH7NwTEDnN5Mqp5iMvhkUC3fBY=; X-YMail-OSG: BKsEXiwVM1k0UsWMJ1DkTrE1BgrEK8GqBu21BSDnn01U2C4ZK3y1SLEqDQbgJSffbUsJmMbKHI09fAkVNASTdU2g3sv5yLNcn1eZ Received: from [58.71.34.138] by web44906.mail.sp1.yahoo.com via HTTP; Fri, 31 Aug 2007 03:20:55 PDT Date: Fri, 31 Aug 2007 03:20:55 -0700 (PDT) From: Martha Pasikatan To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <731920.7976.qm@web44906.mail.sp1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Panic experienced in ng_snd_item 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, 31 Aug 2007 10:35:28 -0000 Hi, The system panicked while I was running a program that uses netgraph heavily. This is the panic that showed. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff804fa6c4 stack pointer = 0x10:0xffffffffa5641b30 frame pointer = 0x10:0xffffffff9a6cb0a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock sio) trap number = 12 panic: page fault When I did list *0xffffffff804fa6c4, this is what appeared: 0xffffffff804fa6c4 is in ng_snd_item (/usr/src/sys/netgraph/ng_base.c:2172). 2167 2168 int 2169 ng_snd_item(item_p item, int flags) 2170 { 2171 hook_p hook = NGI_HOOK(item); 2172 node_p node = NGI_NODE(item); 2173 int queue, rw; 2174 struct ng_queue * ngq = &node->nd_input_queue; 2175 int error = 0; 2176 The backtrace shows #0 doadump () at pcpu.h:172 #1 0x0000000000000004 in ?? () #2 0xffffffff804326f7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff80432d91 in panic (fmt=0xffffff003dbbdbe0 "Xû=") at /usr/src/sys/kern/kern_shutdown.c:565 #4 0xffffffff8069726f in trap_fatal (frame=0xffffff003dbbdbe0, eva=18446742975233639256) at /usr/src/sys/amd64/amd64/trap.c:660 #5 0xffffffff8069758f in trap_pfault (frame=0xffffffffa5641a80, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:573 #6 0xffffffff80697843 in trap (frame= {tf_rdi = 0, tf_rsi = 0, tf_rdx = 582, tf_rcx = -1098475906080, tf_r8 = 1, tf_r9 = -1098475906080, tf_rax = 0, tf_rbx = 0, tf_rbp = -1704152928, tf_r10 = -2136924776, tf_r11 = 0, tf_r12 = 0, tf_r13 = 4, tf_r14 = 0, tf_r15 = -2142253296, tf_trapno = 12, tf_addr = 16, tf_flags = -1098475906080, tf_err = 0, tf_rip = -2142263612, tf_cs = 8, tf_rflags = 66178, tf_rsp = -1520166080, tf_ss = 0}) at /usr/src/sys/amd64/amd64/trap.c:352 #7 0xffffffff80682a2b in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #8 0xffffffff804fa6c4 in ng_snd_item (item=0x0, flags=0) at /usr/src/sys/netgraph/ng_base.c:2170 #9 0xffffffff804423d5 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:290 #10 0xffffffff80417e79 in ithread_loop (arg=0xffffff0000d0c960) at /usr/src/sys/kern/kern_intr.c:682 #11 0xffffffff80416617 in fork_exit (callout=0xffffffff80417d30 , arg=0xffffff0000d0c960, frame=0xffffffffa5641c50) at /usr/src/sys/kern/kern_fork.c:821 #12 0xffffffff80682d8e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:394 I was surprised to find the ng_send_item having a null item passed as a parameter. I believe it can't have been a call from NG_FWD_ITEM because it checks for the validity of the parameters passed to it. It is likely that the calling function was ng_callout_trampoline. Now, I'm at a loss as to where to proceed from here. Does anyone have an idea or clue as to what is causing this? Any help, suggestion, or advice is welcome. Matt --------------------------------- Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 11:33:59 2007 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 702A216A46B; Fri, 31 Aug 2007 11:33:59 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1AB7413C45E; Fri, 31 Aug 2007 11:33:53 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id l7VBXsBY017313 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2007 13:33:54 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id l7VBXrPP027532; Fri, 31 Aug 2007 13:33:53 +0200 (MEST) Date: Fri, 31 Aug 2007 13:33:53 +0200 From: Daniel Hartmeier To: Norberto Meijome Message-ID: <20070831113353.GA30807@insomnia.benzedrine.cx> References: <20070831202729.7e4c0f7a@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070831202729.7e4c0f7a@localhost> User-Agent: Mutt/1.5.12-2006-07-14 Cc: FreeBSD Net ML , FreeBSD Questions ML Subject: Re: pf rdr + netsed : reinject loop... 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, 31 Aug 2007 11:33:59 -0000 On Fri, Aug 31, 2007 at 08:27:29PM +1000, Norberto Meijome wrote: > rdr on $int_if proto tcp from 172.16.82.81 to any -> 127.0.0.1 port 10101 > netsed tcp 10101 0 0 s/FOO/BAR > The traffic from XP gets redirected just fine to netsed, which replaces the bytes just fine. BUT the changed packets (the output of netsed) get reinjected somewhere so that the rdr hits them again, sending them back to netsed ad infinitum. ( yes, i managed to hit a load of 700+ without anything ever leaving BSD ...quite cool) I'm pretty sure the endless loop you describe does not pass through pf, except for the first iteration. In the first iteration, pf replaces the destination address with 127.0.0.1, and the packet goes to netsed. netsed changes the payload, but leaves the destination address (127.0.0.1 now). It sends the packet out, and since the destination address is 127.0.0.1, it sends it to itself. Hence the loop, which does not involve pf any further (i.e. there's no 'redirecting again' or such, AFAICT). > rdr on $int_if proto tcp from 172.16.82.81 to O.P.Q.R -> 127.0.0.1 port 10101 > netsed tcp 10101 O.P.Q.R 0 s/FOO/BAR > > How do I modify this setup so that netsed packets aren't caught again by pf's rdr and sent back into netsed ? I'm happy to try other tools / setups... Two approaches are possible: a) You modify netsed so it will query pf about the original destination address (O.P.Q.R), and re-insert that before sending out its modified packet. The DIOCNATLOOK ioctl(2) call can be used for that, see pf(4) for details and e.g. the squid source (ports) for how it's used. b) Instead of replacing the destination address in pf with rdr, try leaving it as it is, but use route-to (lo0) to get the packet routed to the loopback interface. This would require netsed to listen on INADDR_ANY (or use a raw socket, I haven't checked its source code). Daniel From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 14:57:36 2007 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 3AB1316A41B for ; Fri, 31 Aug 2007 14:57:36 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id BE09213C442 for ; Fri, 31 Aug 2007 14:57:33 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 17669 invoked from network); 31 Aug 2007 08:10:23 -0500 Received: from 124-170-70-31.dyn.iinet.net.au (HELO localhost) (124.170.70.31) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 31 Aug 2007 08:10:21 -0500 Date: Fri, 31 Aug 2007 23:10:15 +1000 From: Norberto Meijome To: Daniel Hartmeier Message-ID: <20070831231015.29fa7b07@localhost> In-Reply-To: <20070831113353.GA30807@insomnia.benzedrine.cx> References: <20070831202729.7e4c0f7a@localhost> <20070831113353.GA30807@insomnia.benzedrine.cx> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net ML , FreeBSD Questions ML Subject: Re: pf rdr + netsed : reinject loop... 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, 31 Aug 2007 14:57:36 -0000 On Fri, 31 Aug 2007 13:33:53 +0200 Daniel Hartmeier wrote: > On Fri, Aug 31, 2007 at 08:27:29PM +1000, Norberto Meijome wrote: >=20 > > rdr on $int_if proto tcp from 172.16.82.81 to any -> 127.0.0.1 port 101= 01 > > netsed tcp 10101 0 0 s/FOO/BAR >=20 > > The traffic from XP gets redirected just fine to netsed, which replaces= the bytes just fine. BUT the changed packets (the output of netsed) get re= injected somewhere so that the rdr hits them again, sending them back to ne= tsed ad infinitum. ( yes, i managed to hit a load of 700+ without anything = ever leaving BSD ...quite cool) >=20 > I'm pretty sure the endless loop you describe does not pass through pf,=20 > except for the first iteration. In the first iteration, pf replaces the=20 > destination address with 127.0.0.1, and the packet goes to netsed.=20 > netsed changes the payload, but leaves the destination address > (127.0.0.1 now). It sends the packet out, and since the destination > address is 127.0.0.1, it sends it to itself. Hence the loop, which does > not involve pf any further (i.e. there's no 'redirecting again' or such, > AFAICT). I was just reaching the same conclusion after some strong coffee netsed's output is (part ) : --- Script started on Fri Aug 31 07:52:12 2007 [root@localhost /usr/home/luser]# netsed tcp 10101 0 0 s/FOO/BAR netsed 0.01b by Michal Zalewski [*] Parsing rule s/FOO/BAR ... [+] Loaded 1 rules... [+] Listening on port 10101/tcp. [+] Using dynamic (transparent proxy) forwarding. [+] Got incoming connection from 172.16.82.81:1178 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Got incoming connection from 127.0.0.1:51337 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client -> server packet. Applying rule s/FOO/BAR... [*] Done 1 replacements, forwarding packet of size 466 (orig 466). [+] Caught client -> server packet. [+] Got incoming connection from 127.0.0.1:53272 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [*] Forwarding untouched packet of size 466. [+] Got incoming connection from 127.0.0.1:56367 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client -> server packet. [*] Forwarding untouched packet of size 466. [+] Got incoming connection from 127.0.0.1:50565 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client -> server packet. [*] Forwarding untouched packet of size 466. [+] Got incoming connection from 127.0.0.1:61660 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client -> server packet. [*] Forwarding untouched packet of size 466. [+] Got incoming connection from 127.0.0.1:51520 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client -> server packet. [*] Forwarding untouched packet of size 466. [+] Got incoming connection from 127.0.0.1:63554 to 127.0.0.1:10101 [*] Forwarding connection to 127.0.0.1:10101 [+] Caught client -> server packet. [*] Forwarding untouched packet of size 466. --- =46rom another run, sockstat -4 shows (starting from bottom, which seem to ha= ve the starting connections): root netsed 3201 3 tcp4 *:10101 *:* root netsed 3201 4 tcp4 127.0.0.1:10101 127.0.0.1:64110 root netsed 3201 5 tcp4 127.0.0.1:55906 127.0.0.1:10101 root netsed 3200 3 tcp4 *:10101 *:* root netsed 3200 4 tcp4 127.0.0.1:10101 127.0.0.1:57224 root netsed 3200 5 tcp4 127.0.0.1:64110 127.0.0.1:10101 root netsed 3199 3 tcp4 *:10101 *:* root netsed 3199 4 tcp4 127.0.0.1:10101 127.0.0.1:55434 root netsed 3199 5 tcp4 127.0.0.1:57224 127.0.0.1:10101 root netsed 3198 3 tcp4 *:10101 *:* root netsed 3198 4 tcp4 127.0.0.1:10101 127.0.0.1:64816 root netsed 3198 5 tcp4 127.0.0.1:55434 127.0.0.1:10101 root netsed 3197 3 tcp4 *:10101 *:* root netsed 3197 4 tcp4 127.0.0.1:10101 127.0.0.1:61595 root netsed 3197 5 tcp4 127.0.0.1:64816 127.0.0.1:10101 root netsed 3196 3 tcp4 *:10101 *:* root netsed 3196 4 tcp4 127.0.0.1:10101 127.0.0.1:58293 root netsed 3196 5 tcp4 127.0.0.1:61595 127.0.0.1:10101 root netsed 3195 3 tcp4 *:10101 *:* root netsed 3195 4 tcp4 127.0.0.1:10101 172.16.82.81:1179 root netsed 3195 5 tcp4 127.0.0.1:58293 127.0.0.1:10101 root netsed 3194 3 tcp4 *:10101 *:* root netsed 3194 4 tcp4 127.0.0.1:10101 127.0.0.1:53543 --- so it does seem that one netsed is feeding the other...=20 This explains why using pf tags isn't helping here, probably for this reason I'm only now getting acquired in depth with PF (been using ipf and ipfw unt= il now... ) , so i'm sure that's not helping me either. >=20 > > rdr on $int_if proto tcp from 172.16.82.81 to O.P.Q.R -> 127.0.0.1 port= 10101 > > netsed tcp 10101 O.P.Q.R 0 s/FOO/BAR > >=20 > > How do I modify this setup so that netsed packets aren't caught again b= y pf's rdr and sent back into netsed ? I'm happy to try other tools / setup= s... >=20 > Two approaches are possible: >=20 > a) You modify netsed so it will query pf about the original destination > address (O.P.Q.R), and re-insert that before sending out its modified > packet. The DIOCNATLOOK ioctl(2) call can be used for that, see pf(4) > for details and e.g. the squid source (ports) for how it's used. I see... but i dont think i have the time to go down this path.I imagine th= ere isn't a way to generate a unique tag in pf and then rdr a second time (= on lo0 this time) after a lookup of the original destination (which got cha= nged for localhost:10101 in the first rdr...) >=20 > b) Instead of replacing the destination address in pf with rdr, try > leaving it as it is, but use route-to (lo0) to get the packet routed to > the loopback interface. This would require netsed to listen on > INADDR_ANY (or use a raw socket, I haven't checked its source code). hmm, netsed binds to a specific port (in my case, 10101) on all IPs of my machine. So I would have to bind it to INADDR_ANY on , say, lo0... =20 Thanks a lot for your thorough reply Daniel, much appreciated. _________________________ {Beto|Norberto|Numard} Meijome Two things have come out of Berkeley, Unix and LSD. It is uncertain which caused the other. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 15:11:22 2007 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 F3F6316A418 for ; Fri, 31 Aug 2007 15:11:21 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 9C07413C458 for ; Fri, 31 Aug 2007 15:11:21 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 25720 invoked from network); 31 Aug 2007 10:11:01 -0500 Received: from 124-170-70-31.dyn.iinet.net.au (HELO localhost) (124.170.70.31) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 31 Aug 2007 10:11:01 -0500 Date: Sat, 1 Sep 2007 01:10:55 +1000 From: Norberto Meijome To: Daniel Hartmeier Message-ID: <20070901011055.0ea76b88@localhost> In-Reply-To: <20070831113353.GA30807@insomnia.benzedrine.cx> References: <20070831202729.7e4c0f7a@localhost> <20070831113353.GA30807@insomnia.benzedrine.cx> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Net ML , FreeBSD Questions ML Subject: Re: pf rdr + netsed : reinject loop... 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, 31 Aug 2007 15:11:22 -0000 On Fri, 31 Aug 2007 13:33:53 +0200 Daniel Hartmeier wrote: > b) Instead of replacing the destination address in pf with rdr, try > leaving it as it is, but use route-to (lo0) to get the packet routed to > the loopback interface. This would require netsed to listen on > INADDR_ANY (or use a raw socket, I haven't checked its source code). Hi Daniel, I tried this but i only managed to lock up the BSD VM a couple of times (not even console access, so it was not just network affected). I am not sure if i've done this correctly .. pass in on $int_if route-to 127.0.0.1 proto tcp from 172.16.82.81 to O.P.Q.R tag ROUTED keep state is that ok ? ( tried also doing route-to 127.0.0.1 $external_addr with no visible change.) I have logging enabled specifically on lo0 , but i dont see any packets going through. I am not entirely sure how netsed will pick up this packets. I've had netsed listening on *:{port} and 127.0.0.1:{port} and it obviously didnt make any difference. Could you point me to any reference / sample of what you mean? thx again, B _________________________ {Beto|Norberto|Numard} Meijome I used to hate weddings; all the Grandmas would poke me and say, "You're next sonny!" They stopped doing that when i started to do it to them at funerals. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 16:28:36 2007 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 825FA16A417 for ; Fri, 31 Aug 2007 16:28:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 0685413C483 for ; Fri, 31 Aug 2007 16:28:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so701267nfd for ; Fri, 31 Aug 2007 09:28:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=UsLVlRnXRXte4iOvW0UesxhpAvkD0P+hAt0TRKXkcRg4g1OlLEY6l42zwnaNo3932azU97RVE3Xohu06t9vqEflKXk76hQs5tT9gZNWCv+2EpmIGF7eFyxyfa0aHlXo5NUfHNiTQsvnN3q9xGl9PpeC2l22FDTJYyn364AB3lvg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GOKfm5SJgs2bmtoTSzpMXig9heWeGPV8el08EikRHqhq7gXzw8Xs08g1OHMLXiOWab2mnf66EvDElUNfAlDeRfsWZUDDpPYWEwX4Guhiw3HZZKjq5WX0K3t8NRF09G60TV+MKvi8xxi8GyauIZjOz5NJQiq+kpcIOGxE8zWmDRM= Received: by 10.82.165.13 with SMTP id n13mr4013157bue.1188577314921; Fri, 31 Aug 2007 09:21:54 -0700 (PDT) Received: by 10.86.81.6 with HTTP; Fri, 31 Aug 2007 09:21:54 -0700 (PDT) Message-ID: <2a41acea0708310921ic12931bt86e76f3e9fbf5556@mail.gmail.com> Date: Fri, 31 Aug 2007 09:21:54 -0700 From: "Jack Vogel" To: "Tom Judge" In-Reply-To: <46D7E4B8.4030609@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0708301622j6b4eeab9h62576dcfd1325b0a@mail.gmail.com> <46D7E4B8.4030609@tomjudge.com> Cc: "freebsd-net@freebsd.org" , Andre Oppermann , John Baldwin Subject: Re: vlan filtering 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, 31 Aug 2007 16:28:36 -0000 On 8/31/07, Tom Judge wrote: > Jack Vogel wrote: > > I was just working on a bug in the Oplin driver that had me look > > a bit more at VLAN code than I had previously. > > > > FreeBSD has apparently never used the hardware vlan filtering > > that our hardware can do, is there a systemic reason for this, > > or has the code lagged in its use of the system? > > > > I at least don't understand how the driver is supposed to get > > the vlan id to set in the filter, am I just unenlightened? :) > > > > If this is doable I can add code into em as well as ixgbe. > > > > Jack > > This isn't really directly related but could be important for some > users. If you where to use this would the card handle Q in Q properly > with the filter on or would there have to be some form of administrative > option to turn the hardware filter on/off? I like flexibility, so having it be a feature that could be enabled or not seems like a good idea to me. Once I understand the situation we'll see. Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 16:37:50 2007 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 35A0F16A41A for ; Fri, 31 Aug 2007 16:37:50 +0000 (UTC) (envelope-from mallman@icir.org) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by mx1.freebsd.org (Postfix) with ESMTP id CAA9E13C480 for ; Fri, 31 Aug 2007 16:37:49 +0000 (UTC) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l7VFcmB9022294; Fri, 31 Aug 2007 08:38:48 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 85C92ED7F47; Fri, 31 Aug 2007 11:38:42 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C7D3E294405; Fri, 31 Aug 2007 11:38:15 -0400 (EDT) To: Randall Stewart From: Mark Allman In-Reply-To: <469CA4F3.4080302@cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Zombie MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 31 Aug 2007 11:38:15 -0400 Sender: mallman@icir.org Message-Id: <20070831153815.C7D3E294405@lawyers.icir.org> Cc: James Healy , freebsd-net@freebsd.org, Andrew Subject: Re: Odd congestion window behaviour [ was: Draft email to freebsd-net ] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 16:37:50 -0000 --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sorry, I am way behind. > IMO if you want to follow the true spirit of RFC3390 and RFC2581 then > yes.. you should ONLY use RFC3390 (or 2581) to set your initial > cwnd. > > I am adding Mark Allman on this to get his opinion.. Mark, here > is your big chance to chime in on something that has had your > name in comments in FreeBSD code for years... > > Basically let me referesh your memory in case you are not on > net@freebsd.org (or you can go look at the thread). > > Currently FreeBSD will dig into its hostcache and set the > cwnd of a new connection to the previous value with some constraints.. > > James posted these a fe days ago when noting funny behavior. > > I chimed in and said really IMO using the previous cwnd > of old connections is NOT a good idea.. (I can see using > the previous ssthresh.. but not cwnd).. and it is exactly > why our SCTP implementation DOES NOT do this.. > > What do you think Mark (since your name is in the comments > to justify this action).. I am not sure I follow this. The place where I know my name is (was) in the code is about spurious RTOs, not caching CC state between connections. In general, I think caching CC state between connections can be useful. But, one needs to be careful on how you do it and there is (as far as I know), no well vetted and specified way to cache CC state. I.e., if some connection uses a cwnd of X bytes and then ends and another connection comes along.... (a) Can that connection just use a cwnd of X bytes? (b) Does it matter how long after the first connection ends that the second connection is initiated? (c) If it matters, how long should we view the cwnd of X as being valid? (d) Should the value of X decay? (e) Should a TCP doing this be required to pace to mitigate the burstiness of simply starting with a big cwnd? Etc. So, it seems to me that there are really lots of questions that need to be carefully thought about and answered before one used such a scheme. That said, I do support the general concept and wish someone would write down some specifics that the community could agree to. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG2DXnWyrrWs4yIs4RAiGvAJ9KLopaXbhkRHQkXB4aNEMkeqSZjACfR63M pvwgCtQ1sno23Hx+Hf7Tnig= =RQ+6 -----END PGP SIGNATURE----- --=_bOundary-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 1 08:51:40 2007 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 BDD3B16A417 for ; Sat, 1 Sep 2007 08:51:40 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.130]) by mx1.freebsd.org (Postfix) with ESMTP id 30FD413C459 for ; Sat, 1 Sep 2007 08:51:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.1/8.14.1) with ESMTP id l818pcBE031380; Sat, 1 Sep 2007 12:51:38 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.1/8.14.1/Submit) id l818pcB9031379; Sat, 1 Sep 2007 12:51:38 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 1 Sep 2007 12:51:38 +0400 From: Gleb Smirnoff To: Weiguang Shi Message-ID: <20070901085138.GW21312@glebius.int.ru> Mail-Followup-To: Gleb Smirnoff , Weiguang Shi , maxim@freebsd.org, freebsd-net@freebsd.org References: <957582.10686.qm@web43133.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <957582.10686.qm@web43133.mail.sp1.yahoo.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: maxim@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: questions wrt ng_netflow X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 08:51:40 -0000 Weiguang, sorry for late answer, I'm too loaded with daytime job. On Thu, Aug 23, 2007 at 09:40:30AM -0700, Weiguang Shi wrote: W> I've been reading netlfow.c in FreeBSD-6.2 and this piece of code confuses me. W> 484 /* W> 485 * Go through hash and find our entry. If we encounter an W> 486 * entry, that should be expired, purge it. We do a reverse W> 487 * search since most active entries are first, and most W> 488 * searches are done on most active entries. W> 489 */ W> 490 TAILQ_FOREACH_REVERSE_SAFE(fle, &hsh->head, fhead, fle_hash, fle1) { W> 491 if (bcmp(&r, &fle->f.r, sizeof(struct flow_rec)) == 0) W> 492 break; W> 493 if ((INACTIVE(fle) && SMALL(fle)) || AGED(fle)) { W> 494 TAILQ_REMOVE(&hsh->head, fle, fle_hash); W> 495 expire_flow(priv, &item, fle, NG_QUEUE); W> 496 atomic_add_32(&priv->info.nfinfo_act_exp, 1); W> 497 } W> 498 } W> W> +-------------+ +--------+ +--------+ +--------+ +--------+ W> | Bucket Head |----->| RecA |----->| RecB |----->| RecC |----->| RecD | W> +-------------+ +--------+ +--------+ +--------+ +--------+ W> W> In the figure above, let's say our packet matches RecC. So before the W> match, RecD is examined to see if it's AGED, i.e., it's lasted for too W> long, or if it's too small and inactive. As the match is found, the W> code stops searching. W> W> First, isn't INACTIVE alone enough to expire a flow? Why must INACTIVE W> _and_ SMALL? No. Netflow engine tries to minimise number of export records sent, and avoid splitting one long flow into several records. Thus, if we have enough space in the cache, we keep inactive flows, because they can become active again. For example, a TCP ssh session, where you have stopped typing and are reading the text becomes inactive after some time passes. However, it will continue, when you start typeing again. We make an exclusion for SMALL flows, to avoid blowing the cache due to continuous internet scanning by worms: /* * 4 is a magical number: statistically number of 4-packet flows is * bigger than 5,6,7...-packet flows by an order of magnitude. Most UDP/ICMP * scans are 1 packet (~ 90% of flow cache). TCP scans are 2-packet in case * of reachable host and 4-packet otherwise. */ #define SMALL(fle) (fle->f.packets <= 4) W> RecA and RecB would not be examined for expiration but since they are W> to the beginning of the queue and therefore actually less recently W> accessed, they are more likely to be INACTIVE and could be more AGED. W> I must be missing something, but what justifies examining RecD but not W> RecA and RecB? Because we are in the interrupt thread. Our aim is to finish processing of one IP packet as fast as possible and return. Our aim is not to expire as much as possible. However we examine the flows that we have just bcmp()'ed. These entires are in the CPU's cache, so we can quickly check them. The periodic expiry routine goes through the TAILQ in opposite order, starting from head, so it accesses the oldest flows earlier. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sat Sep 1 09:46:05 2007 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 567E816A421; Sat, 1 Sep 2007 09:46:05 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 420D713C442; Sat, 1 Sep 2007 09:46:05 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5A6FF1A4D7C; Sat, 1 Sep 2007 02:11:29 -0700 (PDT) Date: Sat, 1 Sep 2007 02:11:29 -0700 From: Alfred Perlstein To: Max Laier Message-ID: <20070901091129.GI87451@elvis.mu.org> References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <200708222339.23287.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708222339.23287.max@love2party.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2007 09:46:05 -0000 * Max Laier [070822 14:38] wrote: > On Wednesday 22 August 2007, Bruce M. Simpson wrote: > [...] > > On the other hand, if you don't need to reference these constants in > > the kernel at all, and they will all exist beyond AF_MAX, then you can > > disregard what I've said and append them to the rest of the list. > > Please make sure to leave a bit of space between AF_MAX and your constants > so we could still grow AF_MAX if the need should ever arise. Hmm, that could work, but I think we have the same problem, we depend on AF_MAX. I could look into a more dynamic way of allocating... possibly. -Alfred