From owner-freebsd-net@FreeBSD.ORG Sun Jun 10 10:04:49 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5375C16A421; Sun, 10 Jun 2007 10:04:49 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 2A20013C44B; Sun, 10 Jun 2007 10:04:49 +0000 (UTC) (envelope-from maxim@FreeBSD.org) Received: from freefall.freebsd.org (maxim@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5AA4nNs098106; Sun, 10 Jun 2007 10:04:49 GMT (envelope-from maxim@freefall.freebsd.org) Received: (from maxim@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5AA4m9x098102; Sun, 10 Jun 2007 10:04:48 GMT (envelope-from maxim) Date: Sun, 10 Jun 2007 10:04:48 GMT From: Maxim Konovalov Message-Id: <200706101004.l5AA4m9x098102@freefall.freebsd.org> To: kena@vodka-pomme.net, maxim@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/113457: [ipv6] deadlock occurs if a tunnel goes down while there are tcp6 connections opened 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, 10 Jun 2007 10:04:49 -0000 Synopsis: [ipv6] deadlock occurs if a tunnel goes down while there are tcp6 connections opened State-Changed-From-To: open->closed State-Changed-By: maxim State-Changed-When: Sun Jun 10 10:04:13 UTC 2007 State-Changed-Why: The submitter reports he can't reproduce the problem any more. http://www.freebsd.org/cgi/query-pr.cgi?pr=113457 From owner-freebsd-net@FreeBSD.ORG Sun Jun 10 10:57:37 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4441E16A41F for ; Sun, 10 Jun 2007 10:57:37 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0D4D813C455 for ; Sun, 10 Jun 2007 10:57:36 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [192.168.1.3] (p5481DA78.dip.t-dialin.net [84.129.218.120]) by mail-n.franken.de (Postfix) with ESMTP id 9DE158006DAA for ; Sun, 10 Jun 2007 12:27:58 +0200 (CEST) (KNF-authenticated sender: macmic) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: net@freebsd.org From: Michael Tuexen Date: Sun, 10 Jun 2007 12:28:06 +0200 X-Mailer: Apple Mail (2.752.3) Cc: Subject: Enabling of SCTP in FreeBSD 7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2007 10:57:37 -0000 Dear all, I would like to bring up the question if it is a good idea to enable SCTP in FreeBSD 7 by default. I think that for people not using SCTP it does not hurt, for people using SCTP it is a great help, because they do not have to compile a kernel on their own. Linux and Solaris are now delivered with SCTP support enabled. FreeBSD does have the SCTP implementation with the most advanced features and it is a nice platform for people writing SCTP applications. So is it possible to enable SCTP by default? Best regards Michael From owner-freebsd-net@FreeBSD.ORG Sun Jun 10 14:09:32 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 594C516A468; Sun, 10 Jun 2007 14:09:32 +0000 (UTC) (envelope-from cognet@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3029213C44C; Sun, 10 Jun 2007 14:09:32 +0000 (UTC) (envelope-from cognet@FreeBSD.org) Received: from freefall.freebsd.org (cognet@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5AE9W1I017376; Sun, 10 Jun 2007 14:09:32 GMT (envelope-from cognet@freefall.freebsd.org) Received: (from cognet@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5AE9TY7017372; Sun, 10 Jun 2007 14:09:29 GMT (envelope-from cognet) Date: Sun, 10 Jun 2007 14:09:29 GMT From: Olivier Houchard Message-Id: <200706101409.l5AE9TY7017372@freefall.freebsd.org> To: kena@vodka-pomme.net, cognet@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/113457: [ipv6] deadlock occurs if a tunnel goes down while there are tcp6 connections opened 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, 10 Jun 2007 14:09:32 -0000 Synopsis: [ipv6] deadlock occurs if a tunnel goes down while there are tcp6 connections opened State-Changed-From-To: closed->open State-Changed-By: cognet State-Changed-When: Sun Jun 10 14:08:04 UTC 2007 State-Changed-Why: The problem still happens after all. http://www.freebsd.org/cgi/query-pr.cgi?pr=113457 From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 03:03:42 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 059AB16A468; Mon, 11 Jun 2007 03:03:42 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id D082713C457; Mon, 11 Jun 2007 03:03:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5B33fN6076457; Mon, 11 Jun 2007 03:03:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5B33f1F076453; Mon, 11 Jun 2007 03:03:41 GMT (envelope-from linimon) Date: Mon, 11 Jun 2007 03:03:41 GMT From: Mark Linimon Message-Id: <200706110303.l5B33f1F076453@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/113548: [dummynet] [patch] system hangs with dummynet queues 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, 11 Jun 2007 03:03:42 -0000 Old Synopsis: [dummynet] system hangs with dummynet queues New Synopsis: [dummynet] [patch] system hangs with dummynet queues Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 11 03:02:20 UTC 2007 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=113548 From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 11:08:50 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47D6616A400 for ; Mon, 11 Jun 2007 11:08:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1FCC513C46E for ; Mon, 11 Jun 2007 11:08:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5BB8nTE026686 for ; Mon, 11 Jun 2007 11:08:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5BB8mIo026682 for freebsd-net@FreeBSD.org; Mon, 11 Jun 2007 11:08:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Jun 2007 11:08:48 GMT Message-Id: <200706111108.l5BB8mIo026682@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, 11 Jun 2007 11:08:50 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- 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/113359 net [ipv6] panic sbdrop after ICMP6, packet too big o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113548 net [dummynet] [patch] system hangs with dummynet queues 16 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] IP Encapsulation mask_match() returns wrong o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112612 net [lo] Traffic via additional lo(4) interface shows up o o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/112710 net [re] if_re driver detects incorrect b243a405a405 MAC a o kern/112886 net [broadcom]: Wifi card not detected 14 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 14:06:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3967016A41F for ; Mon, 11 Jun 2007 14:06:54 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id E36DE13C448 for ; Mon, 11 Jun 2007 14:06:53 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:MIME-Version:Content-Type:Content-Disposition:Sender:X-Spam-Status:Subject; b=KRre2SSByMvAD96JjY1gdNtE6/dyqOSMuAueLSTEnF1yOwzB1Fqm7smXI24otgb5fAc3Di2PjLrSZDCbYPvv+5MotXGRzLqF7iLXh7IRZnyx+NT8C+VhADH866+NOlQZ+x4w/xXDEt8VuX/PExN/E5jvEwn/kQ+rLDvKZfx2Rzs=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HxkXh-0009fy-Aw; Mon, 11 Jun 2007 18:06:49 +0400 Date: Mon, 11 Jun 2007 18:06:44 +0400 From: Eygene Ryabinkin To: freebsd-net@freebsd.org Message-ID: <20070611140644.GH86872@void.codelabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_40 Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-current@freebsd.org, yongari@freebsd.org Subject: nfe(4) strangeness on the 7-CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 14:06:54 -0000 Good day. I had recently upgraded my amd64 box to the 7-CURRENT and started using nfe(4) instead of nve(4), because the latter was almost unusable on the moderate traffic flow from the amd64 box to some other machine due to the watchdog timeouts. But the stock nfe(4) was not good too: it provoked some kernel crashes. So, I resorted to the nfe(4) driver from http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html Things are working, but I have many kernel messages like this: ----- TCP: [third_local_machine]:65385 to [second_local_machine]:443 tcpflags 0x4; tcp_input : Listen socket: Spurious RST, segment rejected TCP: [127.0.0.1]:61775 to [127.0.0.1]:40001 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) TCP: [third_local_machine]:63851 to [second_local_machine]:443 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [third_local_machine]:62901 to [second_local_machine]:443 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [third_local_machine]:55359 to [second_local_machine]:443 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [209.132.176.167]:60779 to [first_local_machine]:25 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [69.147.83.53]:54604 to [first_local_machine]:25 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [third_local_machine]:63187 to [second_local_machine]:443 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [209.132.176.167]:38662 to [first_local_machine]:25 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [209.132.176.167]:38662 to [first_local_machine]:25 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected TCP: [127.0.0.1]:60500 to [127.0.0.1]:40001 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) ----- I would count this as the hardware or driver failures, but the messages for the 127.0.0.1 shows that this is not related to the packet corruption in the NIC driver. And SSH transfers are working fine, so if there would be packet corruption, then it will broke SSH MAC layer. The motherboard is ASUS M2NPV-VM. The device itself is detected as ----- nfe0: port 0xc800-0xc807 mem 0xfe02b000-0xfe02bfff irq 22 at device 20.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:18:f3:97:38:85 nfe0: [FILTER] ----- The kernel signature is '7.0-CURRENT FreeBSD 7.0-CURRENT #3: Fri Jun 8 06:26:42 MSD 2007'. The non-default part of my -CURRENT is the usb4bsd stack instead of the stock one. But I had the same error messages without usb4bsd. Should I just relax and ignore the messages, or this is the sign of the brokenness? Thank you! -- Eygene From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 19:09:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2564A16A400 for ; Mon, 11 Jun 2007 19:09:17 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 85AC013C489 for ; Mon, 11 Jun 2007 19:09:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 92582 invoked from network); 11 Jun 2007 18:22:58 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jun 2007 18:22:58 -0000 Message-ID: <466D9DDE.6090302@freebsd.org> Date: Mon, 11 Jun 2007 21:09:18 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eygene Ryabinkin References: <20070611140644.GH86872@void.codelabs.ru> In-Reply-To: <20070611140644.GH86872@void.codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, freebsd-current@freebsd.org, yongari@freebsd.org Subject: Re: nfe(4) strangeness on the 7-CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 19:09:17 -0000 Eygene Ryabinkin wrote: > Good day. > > I had recently upgraded my amd64 box to the 7-CURRENT and started > using nfe(4) instead of nve(4), because the latter was almost > unusable on the moderate traffic flow from the amd64 box to some > other machine due to the watchdog timeouts. > > But the stock nfe(4) was not good too: it provoked some kernel > crashes. So, I resorted to the nfe(4) driver from > http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html > > Things are working, but I have many kernel messages like this: > ----- > TCP: [third_local_machine]:65385 to [second_local_machine]:443 tcpflags 0x4; tcp_input > : Listen socket: Spurious RST, segment rejected > TCP: [127.0.0.1]:61775 to [127.0.0.1]:40001 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) > TCP: [third_local_machine]:63851 to [second_local_machine]:443 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [third_local_machine]:62901 to [second_local_machine]:443 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [third_local_machine]:55359 to [second_local_machine]:443 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [209.132.176.167]:60779 to [first_local_machine]:25 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [69.147.83.53]:54604 to [first_local_machine]:25 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [third_local_machine]:63187 to [second_local_machine]:443 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [209.132.176.167]:38662 to [first_local_machine]:25 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [209.132.176.167]:38662 to [first_local_machine]:25 tcpflags 0x4; tcp_input: Listen socket: Spurious RST, segment rejected > TCP: [127.0.0.1]:60500 to [127.0.0.1]:40001 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) > ----- > I would count this as the hardware or driver failures, but the > messages for the 127.0.0.1 shows that this is not related to the > packet corruption in the NIC driver. And SSH transfers are working > fine, so if there would be packet corruption, then it will broke > SSH MAC layer. > > The motherboard is ASUS M2NPV-VM. The device itself is detected > as > ----- > nfe0: port 0xc800-0xc807 mem 0xfe02b000-0xfe02bfff irq 22 at device 20.0 on pci0 > miibus0: on nfe0 > e1000phy0: PHY 1 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto > nfe0: Ethernet address: 00:18:f3:97:38:85 > nfe0: [FILTER] > ----- > The kernel signature is '7.0-CURRENT FreeBSD 7.0-CURRENT #3: Fri Jun 8 > 06:26:42 MSD 2007'. > > The non-default part of my -CURRENT is the usb4bsd stack instead > of the stock one. But I had the same error messages without usb4bsd. > > Should I just relax and ignore the messages, or this is the sign > of the brokenness? These messages are unrelated to your hardware. There you can relax. We have a bug in the TCP FSM state transitions which I'm currently tracking down that indirectly causes the log messages. You don't have to worry about it for your case. TCP connections work fine. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 21:10:14 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85F6F16A41F for ; Mon, 11 Jun 2007 21:10:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3098F13C4BF for ; Mon, 11 Jun 2007 21:10:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5BLADqb077496 for ; Mon, 11 Jun 2007 21:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5BLADEe077495; Mon, 11 Jun 2007 21:10:13 GMT (envelope-from gnats) Date: Mon, 11 Jun 2007 21:10:13 GMT Message-Id: <200706112110.l5BLADEe077495@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Cristian KLEIN Cc: Subject: Re: kern/113548: [dummynet] [patch] system hangs with dummynet queues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cristian KLEIN List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 21:10:14 -0000 The following reply was made to PR kern/113548; it has been noted by GNATS. From: Cristian KLEIN To: bug-followup@FreeBSD.org, littlesavage@orionet.ru Cc: Subject: Re: kern/113548: [dummynet] [patch] system hangs with dummynet queues Date: Mon, 11 Jun 2007 23:35:21 +0300 I think the problem occurs because you use ipfw tags. As far as I know, ipfw tags are stored as mbuf_tags(9). Dummynet uses mbuf tags too to mark it's own packets. However, I suspect that in dn_tag_get(), dummynet incorrectly assumes it is the only one using mbuf_tags(9). Could you please apply the following patch? Also, could you test whether removing "tag 1" from ipfw rules has any impact? --- ip_dummynet.c.orig Sat Jul 29 11:24:12 2006 +++ ip_dummynet.c Mon Jun 11 23:27:34 2007 @@ -412,7 +412,7 @@ static struct dn_pkt_tag * dn_tag_get(struct mbuf *m) { - struct m_tag *mtag = m_tag_first(m); + struct m_tag *mtag = m_tag_find(m, PACKET_TAG_DUMMYNET, NULL); KASSERT(mtag != NULL && mtag->m_tag_cookie == MTAG_ABI_COMPAT && mtag->m_tag_id == PACKET_TAG_DUMMYNET, -- +-------------------------------------+ | Cristian KLEIN | | Network Engineer | | Communication Center | | Technical University of Cluj-Napoca | +-------------------------------------+ | Tel: +40-264-401247, int. 247 | | WWW: http://www.cc.utcluj.ro | +-------------------------------------+ From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 02:43:26 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D682316A46D for ; Tue, 12 Jun 2007 02:43:26 +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 A8FA113C45A for ; Tue, 12 Jun 2007 02:43:26 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from nm-pptp229.isl.rdc.toshiba.co.jp (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4EC7473021; Tue, 12 Jun 2007 11:43:25 +0900 (JST) Date: Tue, 12 Jun 2007 11:42:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bruce M. Simpson" In-Reply-To: <46523DDA.30300@icsi.berkeley.edu> References: <200705131837.l4DIbFNw022595@freefall.freebsd.org> <46523DDA.30300@icsi.berkeley.edu> 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: freebsd-net@FreeBSD.org Subject: Re: kern/108197: [ipv6] IPv6-related crash if if_delmulti 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, 12 Jun 2007 02:43:26 -0000 At Tue, 22 May 2007 01:48:26 +0100, "Bruce M. Simpson" wrote: > > Responsible-Changed-From-To: freebsd-net->bms > > Responsible-Changed-By: andre > > Responsible-Changed-When: Sun May 13 18:36:25 UTC 2007 > > Responsible-Changed-Why: > > Send over to BMS. He's active in that area and may have fixed the bug already. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=108197 > > Sorry, but I have no time to look at this at the moment. Is someone else > free to look at it? > The fix probably needs to be borrowed from the IPv4 code which adds an > address to an interface. Recent changes to the head and [56] STABLE *may* fix the problem. These just fix memory leak while the symptom rather seems to indicate use-after-free, so I'm not sure if these really solve the problem; however, the fix indeed affects (either good or bad) the same code path that caused the problem shown in the PR, so it may happen to fix this problem via some non trivial side effect. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 03:27:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DD5F16A400; Tue, 12 Jun 2007 03:27:03 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 5232C13C45B; Tue, 12 Jun 2007 03:27:03 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=GZCcE2FlKnlcvIItKIu6Ul8NKLerxRjhwdBDUD7kOU4dpbN9Es85dveb1Mpg0abnzrBROw3CCmFpUgxdAw2EdzY8p/wJDGubZHdwI4selpNo98bLozLiKFyN9yqT0iWR5fuTQeRy2myJ0BkypTE5IS0ukvLOPuEe6JrwCPBsIzk=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Hxx25-000AjF-NT; Tue, 12 Jun 2007 07:27:01 +0400 Date: Tue, 12 Jun 2007 07:26:56 +0400 From: Eygene Ryabinkin To: Andre Oppermann Message-ID: <20070612032656.GJ86872@void.codelabs.ru> References: <20070611140644.GH86872@void.codelabs.ru> <466D9DDE.6090302@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <466D9DDE.6090302@freebsd.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, freebsd-current@freebsd.org, yongari@freebsd.org Subject: Re: nfe(4) strangeness on the 7-CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 03:27:03 -0000 Andre, good day. Mon, Jun 11, 2007 at 09:09:18PM +0200, Andre Oppermann wrote: > These messages are unrelated to your hardware. There you can relax. > We have a bug in the TCP FSM state transitions which I'm currently > tracking down that indirectly causes the log messages. You don't > have to worry about it for your case. TCP connections work fine. OK, thank you! -- Eygene From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 03:34:38 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEF7416A400; Tue, 12 Jun 2007 03:34:38 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 5CE4913C489; Tue, 12 Jun 2007 03:34:38 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=jm4lJ6YZh02IbvcRAlsMw8o+M4o+9Knl0VIUQ9RQ4jyzANLCdJoYgWOqCBQ7MjVTGcMWJZyc8Rx7U0xD9vGmAgDrufZfOfcOgslCx+1tcehdffG2BLEUvr0/WEHdAjeXH6+cnsN7OwQZURz6NimAVKODlGNhRJvcK1vryyujffw=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Hxx9R-000AkO-Hm; Tue, 12 Jun 2007 07:34:37 +0400 Date: Tue, 12 Jun 2007 07:34:32 +0400 From: Eygene Ryabinkin To: Andre Oppermann Message-ID: <20070612033432.GK86872@void.codelabs.ru> References: <20070611140644.GH86872@void.codelabs.ru> <466D9DDE.6090302@freebsd.org> <20070612032656.GJ86872@void.codelabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070612032656.GJ86872@void.codelabs.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, freebsd-current@freebsd.org, yongari@freebsd.org Subject: Re: nfe(4) strangeness on the 7-CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 03:34:39 -0000 Me again. Tue, Jun 12, 2007 at 07:26:56AM +0400, Eygene Ryabinkin wrote: > Mon, Jun 11, 2007 at 09:09:18PM +0200, Andre Oppermann wrote: > > These messages are unrelated to your hardware. There you can relax. > > We have a bug in the TCP FSM state transitions which I'm currently > > tracking down that indirectly causes the log messages. You don't > > have to worry about it for your case. TCP connections work fine. > > OK, thank you! Just checked my netstat output and spotted weird lines: ----- tcp4 0 0 127.0.0.1.* 127.0.0.1.40001 CLOSED tcp4 0 0 127.0.0.1.* 127.0.0.1.40001 CLOSED ----- Can they be related to the bug you mentioned? -- Eygene From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 14:29:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0260B16A400 for ; Tue, 12 Jun 2007 14:29:53 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id A4A0A13C48A for ; Tue, 12 Jun 2007 14:29:52 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Tue, 12 Jun 2007 10:19:50 -0400 id 00056415.466EAB86.000099FE Date: Tue, 12 Jun 2007 10:19:49 -0400 From: Bill Moran To: freebsd-net@freebsd.org Message-Id: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Weird "ignoring syn" problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 14:29:53 -0000 This one has got me pretty befuddled. We're seeing some really odd behaviour with FreeBSD ignoring SYN packets. I've been trying to diagnose this for a couple of weeks now, and my current guess is that there's something wrong with the em driver. Here's a narrowed down list of what I've ruled out: *) I've done my best to eliminate other network components as the problem. My theory at this point is that it can't possibly be any other network hardware, based on the tcpdump show below. *) The problem occurred on both FreeBSD 6.1 and FreeBSD 6.2-p3. *) The problem does not appear to be tied to CPU usage -- the CPU is nearly idle when the problem occurs. *) I can now reproduce it pretty easily, so I'll know when it's fixed. *) The system exhibiting the problem is running 15 jails, but they are idle 95% of the time. The problem initially occurred inside one of the jails, but I just recreated it outside the jail (on the host) and it's _easier_ to reproduce outside the jail. *) The problem occurred with both GENERIC, and the SMP kernel (this is a dual-CPU, hyperthreaded system) *) I've tested and the behavior occurs both with a dynamically generated file (from PHP) or from a static file. The nature of the beast is that we've got a SOAP application running under Apache and PHP. This application is subject to many requests in rapid succession, such that load can be simulated by the following loop: while true; do fetch http://192.168.121.250/test.php; done The problem is that occasionally, the Apache server machine just ignores SYN packets. Take the following tcpdump output for example: 13:34:17.312296 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 13:34:20.312398 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 13:34:23.512626 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 This is the _only_ traffic on port 80 during the test. It looks like the kernel has ignored the initial syn packet and two duplicates. I've seen it take as long as 45 seconds to establish a connection, and this causes ugly performance problems, as well as frequent timeouts on the client end. The only clue I've found so far is this output from netstat -s. 153099 syncache entries added 6184 retransmitted 6491 dupsyn 0 dropped 150923 completed 0 bucket overflow 0 cache overflow 235 reset 1941 stale 0 aborted 0 badack 0 unreach 0 zone failures Unfortunately, I've been unable to determine how to fix the problem. Any advice is welcome. Details: Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE-p3 #2: Thu Jun 7 21:37:54 UTC 2007 root@is00:/usr/obj/usr/src/sys/SMP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20100000 Logical CPUs per core: 2 real memory = 2147221504 (2047 MB) avail memory = 2096107520 (1999 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 10 ioapic2: WARNING: intbase 64 != expected base 56 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 amr0: mem 0xd80f0000-0xd80fffff,0xdfde0000-0xdfdfffff irq 46 at device 14.0 on pci2 amr0: delete logical drives supported by controller amr0: Firmware 521X, BIOS H430, 256MB RAM pcib3: at device 0.2 on pci1 pci3: on pcib3 em0: port 0xecc0-0xecff mem 0xdfbe0000-0xdfbfffff irq 37 at device 11.0 on pci3 em0: Ethernet address: 00:04:23:c8:ff:f4 em1: port 0xec80-0xecbf mem 0xdfbc0000-0xdfbdffff irq 38 at device 11.1 on pci3 em1: Ethernet address: 00:04:23:c8:ff:f5 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 5.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 em2: port 0xdcc0-0xdcff mem 0xdf8e0000-0xdf8fffff irq 64 at device 7.0 on pci6 em2: Ethernet address: 00:13:72:4f:71:23 pcib7: at device 0.2 on pci5 pci7: on pcib7 em3: port 0xccc0-0xccff mem 0xdf6e0000-0xdf6fffff irq 65 at device 8.0 on pci7 em3: Ethernet address: 00:13:72:4f:71:24 pcib8: at device 6.0 on pci0 pci8: on pcib8 uhci0: port 0xace0-0xacff irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xacc0-0xacdf irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xaca0-0xacbf irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xdff00000-0xdff003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered uhub4: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 uhub4: multiple transaction translators uhub4: 2 ports with 2 removable, self powered pcib9: at device 30.0 on pci0 pci9: on pcib9 pci9: at device 5.0 (no driver attached) pci9: at device 5.1 (no driver attached) pci9: at device 5.2 (no driver attached) atapci0: port 0xbcf0-0xbcf7,0xbce4-0xbce7,0xbcd8-0xbcdf,0xbcd0-0xbcd3,0xbc70-0xbc7f mem 0xdf3fec00-0xdf3fecff irq 23 at device 6.0 on pci9 ata2: on atapci0 ata3: on atapci0 pci9: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci1 ata1: on atapci1 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xec000-0xeffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: Dell DRAC4, rev 1.10/0.00, addr 2, iclass 3/1 kbd2 at ukbd0 ums0: Dell DRAC4, rev 1.10/0.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. Timecounters tick every 1.000 msec acd0: CDROM at ata0-master UDMA33 device_attach: afd0 attach returned 6 acd1: CDROM at ata2-slave PIO3 amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 34680MB (71024640 sectors) RAID 1 (optimal) SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/amrd0s1a -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 15:19:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6893516A400 for ; Tue, 12 Jun 2007 15:19:58 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 1546213C468 for ; Tue, 12 Jun 2007 15:19:57 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Tue, 12 Jun 2007 11:19:57 -0400 id 00056412.466EB99D.0000AE42 Date: Tue, 12 Jun 2007 11:19:55 -0400 From: Bill Moran To: Bill Moran Message-Id: <20070612111955.7eeaca5a.wmoran@collaborativefusion.com> In-Reply-To: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> References: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Weird "ignoring syn" problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 15:19:58 -0000 Brief update to add another item to the list of things I've tried: *) The problem occurs whether the em device is polling or not. In response to Bill Moran : > > This one has got me pretty befuddled. > > We're seeing some really odd behaviour with FreeBSD ignoring SYN packets. > I've been trying to diagnose this for a couple of weeks now, and my current > guess is that there's something wrong with the em driver. Here's a narrowed > down list of what I've ruled out: > *) I've done my best to eliminate other network components as the problem. > My theory at this point is that it can't possibly be any other network > hardware, based on the tcpdump show below. > *) The problem occurred on both FreeBSD 6.1 and FreeBSD 6.2-p3. > *) The problem does not appear to be tied to CPU usage -- the CPU is nearly > idle when the problem occurs. > *) I can now reproduce it pretty easily, so I'll know when it's fixed. > *) The system exhibiting the problem is running 15 jails, but they are > idle 95% of the time. The problem initially occurred inside one of > the jails, but I just recreated it outside the jail (on the host) and > it's _easier_ to reproduce outside the jail. > *) The problem occurred with both GENERIC, and the SMP kernel (this is a > dual-CPU, hyperthreaded system) > *) I've tested and the behavior occurs both with a dynamically generated > file (from PHP) or from a static file. > > The nature of the beast is that we've got a SOAP application running under > Apache and PHP. This application is subject to many requests in rapid > succession, such that load can be simulated by the following loop: > > while true; do fetch http://192.168.121.250/test.php; done > > The problem is that occasionally, the Apache server machine just ignores > SYN packets. Take the following tcpdump output for example: > > 13:34:17.312296 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > 13:34:20.312398 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > 13:34:23.512626 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > > This is the _only_ traffic on port 80 during the test. It looks like the > kernel has ignored the initial syn packet and two duplicates. I've seen it > take as long as 45 seconds to establish a connection, and this causes > ugly performance problems, as well as frequent timeouts on the client end. > The only clue I've found so far is this output from netstat -s. > > 153099 syncache entries added > 6184 retransmitted > 6491 dupsyn > 0 dropped > 150923 completed > 0 bucket overflow > 0 cache overflow > 235 reset > 1941 stale > 0 aborted > 0 badack > 0 unreach > 0 zone failures > > Unfortunately, I've been unable to determine how to fix the problem. Any > advice is welcome. > > Details: > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 6.2-RELEASE-p3 #2: Thu Jun 7 21:37:54 UTC 2007 > root@is00:/usr/obj/usr/src/sys/SMP > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.71-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 > Features=0xbfebfbff > Features2=0x641d> > AMD Features=0x20100000 > Logical CPUs per core: 2 > real memory = 2147221504 (2047 MB) > avail memory = 2096107520 (1999 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 8 > ioapic1: Changing APIC ID to 9 > ioapic1: WARNING: intbase 32 != expected base 24 > ioapic2: Changing APIC ID to 10 > ioapic2: WARNING: intbase 64 != expected base 56 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 32-55 on motherboard > ioapic2 irqs 64-87 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 0.0 on pci1 > pci2: on pcib2 > amr0: mem 0xd80f0000-0xd80fffff,0xdfde0000-0xdfdfffff irq 46 at device 14.0 on pci2 > amr0: delete logical drives supported by controller > amr0: Firmware 521X, BIOS H430, 256MB RAM > pcib3: at device 0.2 on pci1 > pci3: on pcib3 > em0: port 0xecc0-0xecff mem 0xdfbe0000-0xdfbfffff irq 37 at device 11.0 on pci3 > em0: Ethernet address: 00:04:23:c8:ff:f4 > em1: port 0xec80-0xecbf mem 0xdfbc0000-0xdfbdffff irq 38 at device 11.1 on pci3 > em1: Ethernet address: 00:04:23:c8:ff:f5 > pcib4: at device 4.0 on pci0 > pci4: on pcib4 > pcib5: at device 5.0 on pci0 > pci5: on pcib5 > pcib6: at device 0.0 on pci5 > pci6: on pcib6 > em2: port 0xdcc0-0xdcff mem 0xdf8e0000-0xdf8fffff irq 64 at device 7.0 on pci6 > em2: Ethernet address: 00:13:72:4f:71:23 > pcib7: at device 0.2 on pci5 > pci7: on pcib7 > em3: port 0xccc0-0xccff mem 0xdf6e0000-0xdf6fffff irq 65 at device 8.0 on pci7 > em3: Ethernet address: 00:13:72:4f:71:24 > pcib8: at device 6.0 on pci0 > pci8: on pcib8 > uhci0: port 0xace0-0xacff irq 16 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0xacc0-0xacdf irq 19 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0xaca0-0xacbf irq 18 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem 0xdff00000-0xdff003ff irq 23 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub3: 6 ports with 6 removable, self powered > uhub4: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 > uhub4: multiple transaction translators > uhub4: 2 ports with 2 removable, self powered > pcib9: at device 30.0 on pci0 > pci9: on pcib9 > pci9: at device 5.0 (no driver attached) > pci9: at device 5.1 (no driver attached) > pci9: at device 5.2 (no driver attached) > atapci0: port 0xbcf0-0xbcf7,0xbce4-0xbce7,0xbcd8-0xbcdf,0xbcd0-0xbcd3,0xbc70-0xbc7f mem 0xdf3fec00-0xdf3fecff irq 23 at device 6.0 on pci9 > ata2: on atapci0 > ata3: on atapci0 > pci9: at device 13.0 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 > ata0: on atapci1 > ata1: on atapci1 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FAST] > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcafff,0xec000-0xeffff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ukbd0: Dell DRAC4, rev 1.10/0.00, addr 2, iclass 3/1 > kbd2 at ukbd0 > ums0: Dell DRAC4, rev 1.10/0.00, addr 2, iclass 3/1 > ums0: 3 buttons and Z dir. > Timecounters tick every 1.000 msec > acd0: CDROM at ata0-master UDMA33 > device_attach: afd0 attach returned 6 > acd1: CDROM at ata2-slave PIO3 > amr0: delete logical drives supported by controller > amrd0: on amr0 > amrd0: 34680MB (71024640 sectors) RAID 1 (optimal) > SMP: AP CPU #3 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > Trying to mount root from ufs:/dev/amrd0s1a > > > -- > Bill Moran > Collaborative Fusion Inc. > http://people.collaborativefusion.com/~wmoran/ > > wmoran@collaborativefusion.com > Phone: 412-422-3463x4023 > _______________________________________________ > 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" > > > > > > -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 15:39:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E51216A46B for ; Tue, 12 Jun 2007 15:39:42 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9DBF913C4B7 for ; Tue, 12 Jun 2007 15:39:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 2663 invoked from network); 12 Jun 2007 14:53:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Jun 2007 14:53:14 -0000 Message-ID: <466EBE3E.3050105@freebsd.org> Date: Tue, 12 Jun 2007 17:39:42 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Bill Moran References: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> In-Reply-To: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Weird "ignoring syn" problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 15:39:42 -0000 Bill Moran wrote: > This one has got me pretty befuddled. > > We're seeing some really odd behaviour with FreeBSD ignoring SYN packets. > I've been trying to diagnose this for a couple of weeks now, and my current > guess is that there's something wrong with the em driver. Here's a narrowed > down list of what I've ruled out: > *) I've done my best to eliminate other network components as the problem. > My theory at this point is that it can't possibly be any other network > hardware, based on the tcpdump show below. > *) The problem occurred on both FreeBSD 6.1 and FreeBSD 6.2-p3. > *) The problem does not appear to be tied to CPU usage -- the CPU is nearly > idle when the problem occurs. > *) I can now reproduce it pretty easily, so I'll know when it's fixed. > *) The system exhibiting the problem is running 15 jails, but they are > idle 95% of the time. The problem initially occurred inside one of > the jails, but I just recreated it outside the jail (on the host) and > it's _easier_ to reproduce outside the jail. > *) The problem occurred with both GENERIC, and the SMP kernel (this is a > dual-CPU, hyperthreaded system) > *) I've tested and the behavior occurs both with a dynamically generated > file (from PHP) or from a static file. > > The nature of the beast is that we've got a SOAP application running under > Apache and PHP. This application is subject to many requests in rapid > succession, such that load can be simulated by the following loop: > > while true; do fetch http://192.168.121.250/test.php; done > > The problem is that occasionally, the Apache server machine just ignores > SYN packets. Take the following tcpdump output for example: > > 13:34:17.312296 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > 13:34:20.312398 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > 13:34:23.512626 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > > This is the _only_ traffic on port 80 during the test. It looks like the > kernel has ignored the initial syn packet and two duplicates. I've seen it > take as long as 45 seconds to establish a connection, and this causes > ugly performance problems, as well as frequent timeouts on the client end. > The only clue I've found so far is this output from netstat -s. > > 153099 syncache entries added > 6184 retransmitted > 6491 dupsyn > 0 dropped > 150923 completed > 0 bucket overflow > 0 cache overflow > 235 reset > 1941 stale > 0 aborted > 0 badack > 0 unreach > 0 zone failures > > Unfortunately, I've been unable to determine how to fix the problem. Any > advice is welcome. Before we go into more detail: a) the em(4) driver is most likely totally unrelated to this b) you may run out of socket on the client side and reuse them too fast. Try to lower net.inet.ip.portrange.first to 30,000 or so. c) related to (b) you may have a lot of connections in TIME_WAIT on the server catching not really stray packets. Try it with net.inet.tcp.nolocaltimewait=1 d) if the above didn't help then it'd be very helpful to test against a server with FreeBSD-current (the future 7.0) on it. In -current we've got detailed logging of LISTEN socket failures that allow rapid analysis of the problem. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 16:00:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B67B16A400 for ; Tue, 12 Jun 2007 16:00:49 +0000 (UTC) (envelope-from winterny@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id CA68613C480 for ; Tue, 12 Jun 2007 16:00:48 +0000 (UTC) (envelope-from winterny@gmail.com) Received: by nz-out-0506.google.com with SMTP id 14so1438453nzn for ; Tue, 12 Jun 2007 09:00:43 -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:content-transfer-encoding:content-disposition; b=uZ5f8G/NzYl6SqHy3/oDkRrMU3YuSi8K05yI6H7fn202UzJxkgNFggh/MbtWVZy66P3VTcFA1eT9vdmBZMNBtqX7+YbFMidqRdTSMCA0tSPMzgbbhys/yd//WE+glRuEapvc8+2mu+ttA/jo5o1lj+WaOc76/IRVUydNCfplRXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dcohko/OXMydUL2so7oWm5e1I8nNY8Chh+Rpfj7g2zJKaTqLpqTAgYfqaMvGk7hMpmKQcIHgEBaqMIDcpvhaITO3Vu02Nyx/S+bOgWg2BOyBK6S6vLa2STcASnqrIu3+GiZmOHGY+08s6S6wnE5IvSOf4X11sU28VtY5X8pamqo= Received: by 10.142.103.6 with SMTP id a6mr344944wfc.1181662481623; Tue, 12 Jun 2007 08:34:41 -0700 (PDT) Received: by 10.143.44.9 with HTTP; Tue, 12 Jun 2007 08:34:41 -0700 (PDT) Message-ID: Date: Tue, 12 Jun 2007 11:34:41 -0400 From: "Stephan Koenig" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Tuning if_bge for high packet rates (receive descriptors/transmit descriptors?) 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, 12 Jun 2007 16:00:49 -0000 Hello, We have some servers that have a very high packet rate in a normal production mode, and require polling to keep the CPU load reasonable. We have Kern.HZ=4000, and even still, have some dropped packets. On our servers that use the intel "em" driver, we have tuned the drivers as following, by default, if_em.h has: #define EM_MIN_TXD 80 #define EM_MAX_TXD_82543 256 #define EM_MAX_TXD 4096 #define EM_DEFAULT_TXD EM_MAX_TXD_82543 #define EM_MIN_RXD 80 #define EM_MAX_RXD_82543 256 #define EM_MAX_RXD 4096 #define EM_DEFAULT_RXD EM_MAX_RXD_82543 We have changed EM_DEFAULT_TXD and EM_DEFAULT_RXD to 4096 -- This solved the problem on these servers. The question is now what to do on our servers with Broadcom "bge" series cards. Does anyone know how to tune this driver in a similar matter? Thanks, --Stephan From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 17:13:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95E8616A400 for ; Tue, 12 Jun 2007 17:13:22 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 5CBA713C45B for ; Tue, 12 Jun 2007 17:13:22 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Tue, 12 Jun 2007 13:13:21 -0400 id 00056405.466ED431.0000C091 Date: Tue, 12 Jun 2007 13:13:20 -0400 From: Bill Moran To: Andre Oppermann Message-Id: <20070612131320.c120cd00.wmoran@collaborativefusion.com> In-Reply-To: <466EBE3E.3050105@freebsd.org> References: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> <466EBE3E.3050105@freebsd.org> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Weird "ignoring syn" problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 17:13:22 -0000 In response to Andre Oppermann : > > Before we go into more detail: > > a) the em(4) driver is most likely totally unrelated to this Are you saying it's more likely to be a tcp stack problem? As an experiment, I tried to reproduce it over the loopback and was unable to, which points back toward the em driver ... > b) you may run out of socket on the client side and reuse them > too fast. Try to lower net.inet.ip.portrange.first to 30,000 > or so. I find that unlikely. The problem usually occurs reliably after less than 200 connections, and frequently after less than 50. > c) related to (b) you may have a lot of connections in TIME_WAIT > on the server catching not really stray packets. Try it with > net.inet.tcp.nolocaltimewait=1 That's the default. Also, I see no change in the behaviour of TIME_WAIT states (based on the output of netstat -f inet) no matter what I change that value to. And, just to finish out the debugging steps, the problem occurs with nolocaltimewait set to both 0 and 1. > d) if the above didn't help then it'd be very helpful to test > against a server with FreeBSD-current (the future 7.0) on > it. In -current we've got detailed logging of LISTEN socket > failures that allow rapid analysis of the problem. This will take some time. Also, I'm not seeing the problem on other, similar hardware. I'm considering swapping out that NIC to see if it might be buggy HW. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 17:15:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D54A16A41F for ; Tue, 12 Jun 2007 17:15:32 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B042813C484 for ; Tue, 12 Jun 2007 17:15:31 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 3659 invoked from network); 12 Jun 2007 16:29:03 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Jun 2007 16:29:03 -0000 Message-ID: <466ED4B4.30909@freebsd.org> Date: Tue, 12 Jun 2007 19:15:32 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eygene Ryabinkin References: <20070611140644.GH86872@void.codelabs.ru> <466D9DDE.6090302@freebsd.org> <20070612032656.GJ86872@void.codelabs.ru> <20070612033432.GK86872@void.codelabs.ru> In-Reply-To: <20070612033432.GK86872@void.codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: shigeaki@f.csce.kyushu-u.ac.jp, freebsd-net@freebsd.org, freebsd-current@freebsd.org, yongari@freebsd.org Subject: Re: nfe(4) strangeness on the 7-CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 17:15:32 -0000 Eygene Ryabinkin wrote: > Me again. > > Tue, Jun 12, 2007 at 07:26:56AM +0400, Eygene Ryabinkin wrote: >> Mon, Jun 11, 2007 at 09:09:18PM +0200, Andre Oppermann wrote: >>> These messages are unrelated to your hardware. There you can relax. >>> We have a bug in the TCP FSM state transitions which I'm currently >>> tracking down that indirectly causes the log messages. You don't >>> have to worry about it for your case. TCP connections work fine. >> OK, thank you! > > Just checked my netstat output and spotted weird lines: > ----- > tcp4 0 0 127.0.0.1.* 127.0.0.1.40001 CLOSED > tcp4 0 0 127.0.0.1.* 127.0.0.1.40001 CLOSED > ----- > Can they be related to the bug you mentioned? Yes, this looks related. Do these line stick around or do they go away after some time? -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 18:20:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2787416A46D for ; Tue, 12 Jun 2007 18:20:48 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.freebsd.org (Postfix) with ESMTP id DB7B713C4AE for ; Tue, 12 Jun 2007 18:20:47 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id A53A91CC2B; Tue, 12 Jun 2007 14:03:49 -0400 (EDT) Date: Tue, 12 Jun 2007 14:03:49 -0400 From: Adam McDougall To: Bill Moran Message-ID: <20070612180349.GN23144@egr.msu.edu> References: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-net@freebsd.org Subject: Re: Weird "ignoring syn" problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 18:20:48 -0000 On Tue, Jun 12, 2007 at 10:19:49AM -0400, Bill Moran wrote: This one has got me pretty befuddled. We're seeing some really odd behaviour with FreeBSD ignoring SYN packets. I've been trying to diagnose this for a couple of weeks now, and my current guess is that there's something wrong with the em driver. Here's a narrowed down list of what I've ruled out: *) I've done my best to eliminate other network components as the problem. My theory at this point is that it can't possibly be any other network hardware, based on the tcpdump show below. *) The problem occurred on both FreeBSD 6.1 and FreeBSD 6.2-p3. *) The problem does not appear to be tied to CPU usage -- the CPU is nearly idle when the problem occurs. *) I can now reproduce it pretty easily, so I'll know when it's fixed. *) The system exhibiting the problem is running 15 jails, but they are idle 95% of the time. The problem initially occurred inside one of the jails, but I just recreated it outside the jail (on the host) and it's _easier_ to reproduce outside the jail. *) The problem occurred with both GENERIC, and the SMP kernel (this is a dual-CPU, hyperthreaded system) *) I've tested and the behavior occurs both with a dynamically generated file (from PHP) or from a static file. The nature of the beast is that we've got a SOAP application running under Apache and PHP. This application is subject to many requests in rapid succession, such that load can be simulated by the following loop: while true; do fetch http://192.168.121.250/test.php; done The problem is that occasionally, the Apache server machine just ignores SYN packets. Take the following tcpdump output for example: 13:34:17.312296 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 13:34:20.312398 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 13:34:23.512626 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 This is the _only_ traffic on port 80 during the test. It looks like the kernel has ignored the initial syn packet and two duplicates. I've seen it take as long as 45 seconds to establish a connection, and this causes ugly performance problems, as well as frequent timeouts on the client end. The only clue I've found so far is this output from netstat -s. Does the Apache server have a firewall of any sort? (Could be making unexpected decisions there, even not part of a fw rule) Try net.inet.ip.portrange.randomized=0 on the client? (If this is the problem, we would probably see a reused port if you had a tcpdump of a few minutes if started after waiting for several minutes of "silence") Are both systems on the same subnet? If not, can/have you tried that? Can you show tcpdump output using -e on the requests that aren't answered as well as an example that IS answered? (I have seen routers mess up the MAC addresses for the source and destination and if I kept staring at layer 3 data all day I might never have seen the problem) Better yet, can you post files containing tcpdump output using -w of an entire session that ideally contains failed attempts that eventually work? That way people could look at a broader picture and perhaps pick up on something subtle. Its worth comparing a SYN that works, directly with a SYN that doesn't work. From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 21:20:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0BA416A400; Tue, 12 Jun 2007 21:20:03 +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 A18CC13C469; Tue, 12 Jun 2007 21:20:03 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (1fppi54w6txcf5ed@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l5CKjFO1035315; Tue, 12 Jun 2007 13:45:15 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l5CKjEXB035314; Tue, 12 Jun 2007 13:45:14 -0700 (PDT) (envelope-from jmg) Date: Tue, 12 Jun 2007 13:45:14 -0700 From: John-Mark Gurney To: Bill Moran Message-ID: <20070612204514.GS4602@funkthat.com> Mail-Followup-To: Bill Moran , Andre Oppermann , freebsd-net@freebsd.org References: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> <466EBE3E.3050105@freebsd.org> <20070612131320.c120cd00.wmoran@collaborativefusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070612131320.c120cd00.wmoran@collaborativefusion.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, Andre Oppermann Subject: Re: Weird "ignoring syn" problem 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: Tue, 12 Jun 2007 21:20:03 -0000 Bill Moran wrote this message on Tue, Jun 12, 2007 at 13:13 -0400: > > b) you may run out of socket on the client side and reuse them > > too fast. Try to lower net.inet.ip.portrange.first to 30,000 > > or so. > > I find that unlikely. The problem usually occurs reliably after less > than 200 connections, and frequently after less than 50. I've found that durning load testing, that I regularly run into the icmp limit limiting the rst's sent to completely close connections to web servers... 200 is the default limit per second... Increasing net.inet.icmp.icmplim would change this.. Note that even though it says icmp, it limits TCP RST's... -- 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 Jun 12 23:08:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B175D16A469 for ; Tue, 12 Jun 2007 23:08:52 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from mail.monkeybrains.net (mail1.monkeybrains.net [208.69.40.8]) by mx1.freebsd.org (Postfix) with ESMTP id 850A913C45E for ; Tue, 12 Jun 2007 23:08:52 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from monchichi.monkeybrains.net (adsl-75-36-247-158.dsl.pltn13.sbcglobal.net [75.36.247.158]) (authenticated bits=0) by mail.monkeybrains.net (8.13.7/8.13.7) with ESMTP id l5CMinFC092919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Jun 2007 15:44:49 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <466F21DA.20001@monkeybrains.net> Date: Tue, 12 Jun 2007 15:44:42 -0700 From: Rudy Rucker User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on mail.monkeybrains.net X-Virus-Status: Clean Subject: CARP on backup doesn't relinquish MASTER 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, 12 Jun 2007 23:08:52 -0000 I noticed that if I reboot a server that is the MASTER, the carp0 on the BACKUP box goes into MASTER mode and stays that way -- even when the real master machine has finished rebooting. Is this a desired trait to prevent CARP from switching IPs out of control? Any how, I wrote a cronjob that runs once an hour on the slave. If if finds itself in the MASTER mode on a carp device, it up/down's the interface to get it back into the BACKUP mode. Rudy #!/bin/sh # ------------------------------------------------------------------------------ # should_be_backup_carp.sh # ------------------------------------------------------------------------------ # Check to make sure a carp device is in the backup state. # Run this as an hourly CRON on the 'backup' machine. # # If the Backup machine is found in the 'MASTER' state, this script will cycle # the CARP device in an attempt to let the other device regain MASTER status. # (for some reason, when the MASTER reboots, it does not reassert itself as # the MASTER on my system.) # # If you accidentally install this script on the MASTER server, you will get # some not so good results. :) # # THIS SOFTWARE IS PROVIDED BY Rudy ``AS IS'' AND WARRANTIES ARE DISCLAIMED. # Rudy Rucker, Jr. - 2007 # Usage: # Check carp0 (default) only: # 0 * * * * /path/should_be_backup_carp.sh # Check multiple devices: # 0 * * * * /path/should_be_backup_carp.sh carp0 carp2 ... # ------------------------------------------------------------------------------ if [ -n "$1" ]; then for D in $@; do _DEV=$D export _DEV $0 done exit; fi DEV=${_DEV:=carp0} #DEBUG=YES STATE=`/sbin/ifconfig ${DEV:?"Error you must define a DEV"} 2> /dev/null | /usr/bin/grep vhid | /usr/bin/awk '{print $2}'` STATE=${STATE:?"Error finding state for $DEV."} if [ $STATE = 'MASTER' ]; then echo "${HOST:=`/bin/hostname`} is $STATE on $DEV." echo "This script is going to cycle interface in attempt to relinquish MASTER status." echo "If this is not desired on $HOST, remove $0 from the crontab." echo echo "IFCONFIG before cylce:" /sbin/ifconfig $DEV /sbin/ifconfig $DEV down; sleep 3; echo echo "IFCONFIG during cylce:" /sbin/ifconfig $DEV /sbin/ifconfig $DEV up; sleep 3; echo echo "IFCONFIG after cylce:" /sbin/ifconfig $DEV elif [ $STATE != 'BACKUP' ]; then echo "Something is ill configured with $0" echo "${HOST:=`/bin/hostname`} is $STATE on $DEV." echo echo "I don't know what the state '$STATE' is all about." elif [ -n "$DEBUG" ]; then echo "${HOST:=`/bin/hostname`} is $STATE on $DEV." fi From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 23:30:38 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EFA616A468 for ; Tue, 12 Jun 2007 23:30:38 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.238]) by mx1.freebsd.org (Postfix) with ESMTP id 14EB513C44B for ; Tue, 12 Jun 2007 23:30:37 +0000 (UTC) (envelope-from dave@dogwood.com) Received: by nz-out-0506.google.com with SMTP id 14so17148nzn for ; Tue, 12 Jun 2007 16:30:37 -0700 (PDT) Received: by 10.115.91.2 with SMTP id t2mr7127882wal.1181689299592; Tue, 12 Jun 2007 16:01:39 -0700 (PDT) Received: from Gecko.dogwood.com ( [66.175.65.65]) by mx.google.com with ESMTP id l36sm99003waf.2007.06.12.16.01.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jun 2007 16:01:38 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Jun 2007 13:01:23 -1000 To: John-Mark Gurney , Bill Moran From: David Cornejo In-Reply-To: <20070612204514.GS4602@funkthat.com> References: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> <466EBE3E.3050105@freebsd.org> <20070612131320.c120cd00.wmoran@collaborativefusion.com> <20070612204514.GS4602@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <466f25d2.24bc720a.6d85.2e17@mx.google.com> Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: Weird "ignoring syn" problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2007 23:30:38 -0000 This may not be related, but I have a Soekris 4801 running CURRENT that with a GENERIC kernel exhibits the behavior where TCP connects don't happen. If I switch to an old kernel config file, it works.. This failure happens between this box and a RELENG_6 (updated last week), another CURRENT box, and a Windows XP machine. If I ssh back into the 4801 from the console it works ok, as someone earlier mentioned. I also have tcpdumps from the 4801 to the RELENG_6 box if anyone wants to see them... dave c === old config file === cpu I586_CPU cpu I686_CPU ident S4801 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options CONSPEED=19200 options CPU_GEODE # To make an SMP kernel, the next two lines are needed #options SMP # Symmetric MultiProcessor Kernel #device apic # I/O APIC # Bus support. device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc device miibus # MII bus support device sis # Silicon Integrated Systems SiS 900/SiS 7016 # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device wlan device wlan_wep device wlan_tkip device wlan_ccmp device wlan_xauth device wlan_acl device ath device ath_hal device ath_rate_sample From owner-freebsd-net@FreeBSD.ORG Wed Jun 13 05:40:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1E6616A46D; Wed, 13 Jun 2007 05:40:43 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9471A13C45D; Wed, 13 Jun 2007 05:40:43 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=DFEMfgJP8xZGf4kcgA8V0wSgin/OpgXD6f5jH1QiiEcT+rGpva8Zv2Ya/NSdu3y2BVplsOgeMJgujLDTloyKHHl14iV7Fw0vfB1+YKiSyH/HXuDvJ5NDT29sqUuKN77CzDJ1+1gCO3duVC/gaW1vZmxn5JcSNci2l88Ljz7KPNw=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HyLay-000CZO-Ab; Wed, 13 Jun 2007 09:40:40 +0400 Date: Wed, 13 Jun 2007 09:40:35 +0400 From: Eygene Ryabinkin To: Andre Oppermann Message-ID: <20070613054035.GL86872@void.codelabs.ru> References: <20070611140644.GH86872@void.codelabs.ru> <466D9DDE.6090302@freebsd.org> <20070612032656.GJ86872@void.codelabs.ru> <20070612033432.GK86872@void.codelabs.ru> <466ED4B4.30909@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <466ED4B4.30909@freebsd.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.5 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Connections in the CLOSED state [was: nfe(4) strangeness on the 7-CURRENT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 05:40:44 -0000 Andre, good day. Tue, Jun 12, 2007 at 07:15:32PM +0200, Andre Oppermann wrote: > >Just checked my netstat output and spotted weird lines: > >----- > >tcp4 0 0 127.0.0.1.* 127.0.0.1.40001 CLOSED > >tcp4 0 0 127.0.0.1.* 127.0.0.1.40001 CLOSED > >----- > >Can they be related to the bug you mentioned? > > Yes, this looks related. Do these line stick around or do they go > away after some time? They are staying with the listener virtually forever. But they are disappearing with the listener exit. -- Eygene From owner-freebsd-net@FreeBSD.ORG Wed Jun 13 06:10:38 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46BDF16A400 for ; Wed, 13 Jun 2007 06:10:38 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id AEA7413C46A for ; Wed, 13 Jun 2007 06:10:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 9047 invoked from network); 13 Jun 2007 05:24:03 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Jun 2007 05:24:03 -0000 Message-ID: <466F8A5E.40703@freebsd.org> Date: Wed, 13 Jun 2007 08:10:38 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: David Cornejo References: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> <466EBE3E.3050105@freebsd.org> <20070612131320.c120cd00.wmoran@collaborativefusion.com> <20070612204514.GS4602@funkthat.com> <466f25d2.24bc720a.6d85.2e17@mx.google.com> In-Reply-To: <466f25d2.24bc720a.6d85.2e17@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, John-Mark Gurney , Bill Moran Subject: Re: Weird "ignoring syn" problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 06:10:38 -0000 David Cornejo wrote: > This may not be related, but I have a Soekris 4801 running CURRENT that > with a GENERIC kernel exhibits the behavior where TCP connects don't > happen. If I switch to an old kernel config file, it works.. > > This failure happens between this box and a RELENG_6 (updated last > week), another CURRENT box, and a Windows XP machine. > > If I ssh back into the 4801 from the console it works ok, as someone > earlier mentioned. > > I also have tcpdumps from the 4801 to the RELENG_6 box if anyone wants > to see them.. Yes please. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jun 13 08:08:26 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C3FA16A41F for ; Wed, 13 Jun 2007 08:08:26 +0000 (UTC) (envelope-from marko.lerota@claresco.hr) Received: from zid.claresco.hr (zid.claresco.hr [85.114.42.226]) by mx1.freebsd.org (Postfix) with ESMTP id 585F113C468 for ; Wed, 13 Jun 2007 08:08:25 +0000 (UTC) (envelope-from marko.lerota@claresco.hr) Received: (qmail 1208 invoked by uid 1001); 13 Jun 2007 09:41:04 +0200 To: Rudy Rucker Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWgnbRLVpRNVY9jMRPh s21jSlEyNVX45Mv4zI+sbUclFAtMVpT8V0lFAAACZ0lEQVR4nG3Tv2vbQBQHcFMogWyeNeVK BLXGl5j6xnABOaNTuXFGmWpwtw519yj4soW6AatT4GKD3+aDZrl/rt/Tr9qlGiz7Pn7v3bsf HVc/NrIiSfElqH53GgijcCqzk/+AmBF5cN0DsFlIRGMh/oHuqxkTM6VlzB4EoZEs2aSZOASb EQJYZpweQshE697GTDndBXtgp9LIT9+OpDGHEfb9knk+nx+jfN1JCVZMCl6XwFm0a2EXztZD 3s4fj47ZbKI2VeBmJImeEfGLJ+M9sDPilX7IB5rN6sdfcGhuoHU+LC4nxfnI7YOJtdb95Gb+ fbgJ2uJ2ZgaA++f5ZzBqNCCYfMTd5q0BfBVNqm7I8gUjQ+YtXotRW6PH9AEj+dKs/KuNQAl5 o/NY+QkonW8aQAl0oXMYPvRiXIM4pRJifbXytnhTA8alBx/jefG2ar3DBlt34/PXz9M+nMVN iNaPUdCApJc2ItejOmLGoK1qQLV9pJmXBnL10DYoBA5aHNfj8ZNwZa5O4CzgTJeilKJmrQJs IHIt1/7/Sg2p3iq/Hz0/5W05rq4M9aN2B5FLohUP4ylVyfxhEIjAs8J4PhIJ9U+CEroogib5 BXAf7bB4vkfAzgPFt1tM9sJZAOH+lCexhwswuNtim4QTZdokqo4o89LkH7V6iFxICeqfp+Wh fmUuGPunLj2Meti6Cn4DjJ/UReROqR+aqawAi/JkfgKE64rrfkhjU8MtT8ivR4S5n6Yo08A7 HvgAlHDWRSGlNSDxwK9HtXy4FS2I60EdUIJM+Ut9OZNJG4CpbEQW1VBQoQoPuBw2EVa4P0u0 TgzQF+VoAAAAAElFTkSuQmCC In-Reply-To: <466F21DA.20001@monkeybrains.net> (Rudy Rucker's message of "Tue, 12 Jun 2007 15:44:42 -0700") References: <466F21DA.20001@monkeybrains.net> Organization: *BSD Users - Fanatics Dept. From: Marko Lerota Date: Wed, 13 Jun 2007 09:41:03 +0200 Message-ID: <86r6ogfgj4.fsf@sparrow.local> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org Subject: Re: CARP on backup doesn't relinquish MASTER 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, 13 Jun 2007 08:08:26 -0000 Rudy Rucker writes: > I noticed that if I reboot a server that is the MASTER, the carp0 on > the BACKUP box goes into MASTER mode and stays that way -- even when > the real master machine has finished rebooting. Is this a desired > trait to prevent CARP from switching IPs out of control? Yes, it depends of what you have put in 'net.inet.carp.preempt' if it's net.inet.carp.preempt=0 than the backap will become master and stays that way and if it's net.inet.carp.preempt=1 then the "real" master will take over the IP address from backup server when he gets in the OK state -- One cannot sell the earth upon which the people walk Tacunka Witco From owner-freebsd-net@FreeBSD.ORG Wed Jun 13 12:24:44 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92BDA16A469 for ; Wed, 13 Jun 2007 12:24:44 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD4713C468 for ; Wed, 13 Jun 2007 12:24:44 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Wed, 13 Jun 2007 08:24:43 -0400 id 0005641D.466FE20B.00014F9C Date: Wed, 13 Jun 2007 08:24:43 -0400 From: Bill Moran To: Adam McDougall Message-Id: <20070613082443.80d54fd1.wmoran@collaborativefusion.com> In-Reply-To: <20070612180349.GN23144@egr.msu.edu> References: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> <20070612180349.GN23144@egr.msu.edu> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Weird "ignoring syn" problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2007 12:24:44 -0000 In response to Adam McDougall : > On Tue, Jun 12, 2007 at 10:19:49AM -0400, Bill Moran wrote: > > > This one has got me pretty befuddled. > > We're seeing some really odd behaviour with FreeBSD ignoring SYN packets. > I've been trying to diagnose this for a couple of weeks now, and my current > guess is that there's something wrong with the em driver. Here's a narrowed > down list of what I've ruled out: > *) I've done my best to eliminate other network components as the problem. > My theory at this point is that it can't possibly be any other network > hardware, based on the tcpdump show below. > *) The problem occurred on both FreeBSD 6.1 and FreeBSD 6.2-p3. > *) The problem does not appear to be tied to CPU usage -- the CPU is nearly > idle when the problem occurs. > *) I can now reproduce it pretty easily, so I'll know when it's fixed. > *) The system exhibiting the problem is running 15 jails, but they are > idle 95% of the time. The problem initially occurred inside one of > the jails, but I just recreated it outside the jail (on the host) and > it's _easier_ to reproduce outside the jail. > *) The problem occurred with both GENERIC, and the SMP kernel (this is a > dual-CPU, hyperthreaded system) > *) I've tested and the behavior occurs both with a dynamically generated > file (from PHP) or from a static file. > > The nature of the beast is that we've got a SOAP application running under > Apache and PHP. This application is subject to many requests in rapid > succession, such that load can be simulated by the following loop: > > while true; do fetch http://192.168.121.250/test.php; done > > The problem is that occasionally, the Apache server machine just ignores > SYN packets. Take the following tcpdump output for example: > > 13:34:17.312296 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > 13:34:20.312398 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > 13:34:23.512626 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > > This is the _only_ traffic on port 80 during the test. It looks like the > kernel has ignored the initial syn packet and two duplicates. I've seen it > take as long as 45 seconds to establish a connection, and this causes > ugly performance problems, as well as frequent timeouts on the client end. > The only clue I've found so far is this output from netstat -s. > > > Does the Apache server have a firewall of any sort? (Could be making unexpected > decisions there, even not part of a fw rule) > > Try net.inet.ip.portrange.randomized=0 on the client? (If this is the problem, > we would probably see a reused port if you had a tcpdump of a few minutes > if started after waiting for several minutes of "silence") > > Are both systems on the same subnet? If not, can/have you tried that? No, they aren't. My ability to test on the same subnet is limited and the results inconclusive. > Can you show tcpdump output using -e on the requests that aren't answered > as well as an example that IS answered? (I have seen routers mess up the MAC > addresses for the source and destination and if I kept staring at layer 3 > data all day I might never have seen the problem) > > Better yet, can you post files containing tcpdump output using -w of an entire > session that ideally contains failed attempts that eventually work? That way > people could look at a broader picture and perhaps pick up on something subtle. > Its worth comparing a SYN that works, directly with a SYN that doesn't work. We've decided to swap the card out on Friday and see if that resolves the problem. We have similar units that don't exhibit the problem, so I'm getting pretty suspicious that this might be a flaky NIC. If the new card doesn't solve the problem, I'll post more details on Monday. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 00:03:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E28916A474 for ; Thu, 14 Jun 2007 00:03:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx02.syd.optusnet.com.au (fallbackmx02.syd.optusnet.com.au [211.29.133.72]) by mx1.freebsd.org (Postfix) with ESMTP id E1AE913C455 for ; Thu, 14 Jun 2007 00:02:24 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx02.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l5D51pR6000844 for ; Wed, 13 Jun 2007 15:01:51 +1000 Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l5D51iKv016709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jun 2007 15:01:49 +1000 Date: Wed, 13 Jun 2007 15:01:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Stephan Koenig In-Reply-To: Message-ID: <20070613134445.H19019@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Tuning if_bge for high packet rates (receive descriptors/transmit descriptors?) 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, 14 Jun 2007 00:03:34 -0000 On Tue, 12 Jun 2007, Stephan Koenig wrote: > We have some servers that have a very high packet rate in a normal > production mode, and require polling to keep the CPU load reasonable. > > We have Kern.HZ=4000, and even still, have some dropped packets. > > On our servers that use the intel "em" driver, we have tuned the > drivers as following, by default, if_em.h has: > > #define EM_MIN_TXD 80 > #define EM_MAX_TXD_82543 256 > #define EM_MAX_TXD 4096 > #define EM_DEFAULT_TXD EM_MAX_TXD_82543 > > #define EM_MIN_RXD 80 > #define EM_MAX_RXD_82543 256 > #define EM_MAX_RXD 4096 > #define EM_DEFAULT_RXD EM_MAX_RXD_82543 > > > We have changed EM_DEFAULT_TXD and EM_DEFAULT_RXD to 4096 -- This > solved the problem on these servers. > > The question is now what to do on our servers with Broadcom "bge" > series cards. Does anyone know how to tune this driver in a similar > matter? 1) Change BGE_SSLOTS from 256 to 512. This corresponds to changing EM_DEFAULT_RXD from 256 to 4096, except the max is much smaller. 2) Don't use polling. Polling "works" to reduce CPU by dropping packets on input and be reducing throughput on output. It works particularly badly for bge. 3) When not using polling, change the interrupt coalescing parameters. These can be set to give similar behaviour to polling, without most of pollings losses or features. E.g., setting interrupt moderation timeouts to 250 uS gives behaviour similar to polling at 4000 Hz. For input, the main difference is that the interrupts are high priority so dropping packets is less likely. For output, the throttling behaviour of polling is more useful and without it bge interfaces may use more CPU so as to actually send packets as fast as possible. I use the following simple coalescing tuning in RELENG_6. This essentially restores the old tuning. The tuning is now essentially Linux''s and is not good for FreeBSD. % Index: if_bge.c % =================================================================== % RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v % retrieving revision 1.91.2.23 % diff -u -2 -r1.91.2.23 if_bge.c % --- if_bge.c 8 May 2007 16:18:21 -0000 1.91.2.23 % +++ if_bge.c 9 May 2007 10:09:55 -0000 % @@ -2391,7 +2391,7 @@ % sc->bge_stat_ticks = BGE_TICKS_PER_SEC; % sc->bge_rx_coal_ticks = 150; % - sc->bge_tx_coal_ticks = 150; % - sc->bge_rx_max_coal_bds = 10; % - sc->bge_tx_max_coal_bds = 10; % + sc->bge_tx_coal_ticks = 1000000; % + sc->bge_rx_max_coal_bds = 64; % + sc->bge_tx_max_coal_bds = 384; % % /* Set up ifnet structure */ The parameters here are: sc->bge_rx_coal_ticks: Set this to 100000/N to give essentially the same behaviour as polling at N Hz. The default of 150 gives polling at 6667 Hz. This is a good default. sc->bge_tx_coal_ticks: Like the rx coal_ticks, but not really needed since tx can be controlled better by coal_bds. I set it to 1000000 (1 second) since it is only used to free inactive tx descriptors if the device becomes idle. sc->bge_rx_max_coal_bds: Set this to 1 to give minimum latency and maximum CPU use. Set it to 0 (infinity) or large to give bad latency but less CPU use. The default of 64 gave a good traeoff. The current and RELENG_6 value is too small. For 1500-byte packets, the regression in this parameter little effect when the rx ticks timeout is 150 uS, since the timeout fires first for either value, but for tiny packets a value of 10 for this parameter asks for 150k interrupts per second which is too many. sc->bge_tx_max_coal_bds: Set this to almost the maximum possible to give minimum CPU use at almost no cost to latency. The maximum possible is 511 (496?), but that is too agressive. I use 384. The old value of 128 works OK too (costs ~10% more CPU than 512). The current and RELENG_6 value of 10 is not good. It costs about 100% more CPU than a value of 384 and has no observable good effects. (Above 384, there are some observable bad effects due to bus contention with rx. I only tested on PCI 33MHz buses. The tradeoffs might be a little different on faster buses.) I use dynamic tuning of bge rx coalescing (by rate-limiting interrupts) in -current. em does this in hardware. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 01:29:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5405516A400 for ; Thu, 14 Jun 2007 01:29:32 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id CDFBD13C447 for ; Thu, 14 Jun 2007 01:29:26 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hycge-0001kK-S5 for freebsd-net@freebsd.org; Thu, 14 Jun 2007 01:55:40 +0200 Received: from 78-1-84-209.adsl.net.t-com.hr ([78.1.84.209]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Jun 2007 01:55:40 +0200 Received: from ivoras by 78-1-84-209.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Jun 2007 01:55:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Thu, 14 Jun 2007 01:55:20 +0200 Lines: 65 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF4678ADB2738186B0727E09C" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-84-209.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) X-Enigmail-Version: 0.94.3.0 Sender: news Subject: VLANs and routing 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, 14 Jun 2007 01:29:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4678ADB2738186B0727E09C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! I have a question that's accidentally connected with VLANs, but I think it's generally routing related. The situation is : machine1 VLAN 400 on fxp1 <-- network --> machine2, VLAN 400 on em0 The interfaces on both machines are called vlan400. If I assign "normal" IP addresses on both ends, e.g. 10.10.0.10/24 on vlan400 on machine1 and 10.10.0.11/24 on vlan400 on machine2, everything's fine, I can ping each other through VLAN 400. But the (somewhat weird) requirements are that the vlan interface on machine1 shouldn't have assigned IP address, but the second one should. So, I've removed the IP from vlan400 on machine1, and added a static host route to 10.0.0.11 via vlan400. Now, when I ping 10.10.0.11 I get th= is: PING 10.10.0.11 (10.10.0.11): 56 data bytes ping: sendto: Invalid argument ping: sendto: Invalid argument The (excerpt from) route table with assigned IP address on machine1 (first case) looks like: 10.10/24 link#70 UC 0 0 1500 vlan= 400 10.10.0.11 00:30:48:8d:15:76 UHLW 1 3 1500 vlan400 1188 With the static route it looks like: 10.10.0.11 00:07:e9:d4:2b:39 UHLS 0 2 1500 vlan= 400 (the command is route add -host 10.10.0.11 -iface vlan400 -llinfo) The MAC address in the first case is correct - ...:76 is the MAC from machine2. In the second case, it's not, it's the local MAC. Is this kind of setup even supported? --------------enigF4678ADB2738186B0727E09C 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcIPvldnAQVacBcgRAmb8AJ0SiJCjnnm7JQ2TMDyVNhxNkYsAfgCeISd+ XjidbRif3a9FhI1K4myCq3U= =4DaP -----END PGP SIGNATURE----- --------------enigF4678ADB2738186B0727E09C-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 17:40:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2F7B16A46E for ; Thu, 14 Jun 2007 17:40:47 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from cmail.yandex.ru (cmail.yandex.ru [213.180.193.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5106213C44C for ; Thu, 14 Jun 2007 17:40:46 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [213.180.202.1] (wawa.yandex.ru [213.180.202.1]) by cmail.yandex.ru (8.14.1/8.14.1) with ESMTP id l5EHegsF093529; Thu, 14 Jun 2007 21:40:45 +0400 (MSD) (envelope-from wawa@yandex-team.ru) Message-ID: <46717D97.6010901@yandex-team.ru> Date: Thu, 14 Jun 2007 21:40:39 +0400 From: Vladimir Ivanov Organization: Yandex LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.11) Gecko/20070217 Iceape/1.0.8 (Debian-1.0.8-4) MIME-Version: 1.0 To: freebsd-net@freebsd.org, jfvogel@gmail.com Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030900080101060005020904" Cc: Subject: IXGB driver refactoring. 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, 14 Jun 2007 17:40:48 -0000 This is a cryptographically signed message in MIME format. --------------ms030900080101060005020904 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Hello, all Pls, revise http://people.yandex-team.ru/~wawa/ixgb-6.1.0.Y5.tar.gz If you've interest to IXGB driver. It is significantly altered Intel's IXGB driver. We've fixed several big and small bugs, made some unification w/more developed EM - driver and also I've tried to make it more SMPable. The driver is being developed and tested w/RELENG_6 using CX4 interface. Feedbacks welcome WBR, -- Vladimir Ivanov Network Operations Center OOO "Yandex" t: +7 495 739-7000 f: +7 495 739-7070 @: noc@yandex.net (corporate) wawa@yandex-team.ru (personal) www: www.yandex.ru -- --------------ms030900080101060005020904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCC AuAwggJJoAMCAQICEFuWN3fzFL7yRhcuYyvn3cgwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDYyODE1MjAxMVoX DTA3MDYyODE1MjAxMVowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTd2F3YUB5YW5kZXgtdGVhbS5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAM1EpYvBCs5XMLDPDg5tRbD+cPCbBxVjVosITiajgg7eRtgIewxyNoIPC8TY KkUfbJTO33s09XmfbYjQhtWQA4mFRIgSJqy5WtXdSl1+Gjq2MMy7TZjN0CH6boshmGnxjW/D 0FV8qm4PebXD1PDWokmOx+etcudCr2WSPZ0oPdqS2EkWgClLK6v7qjdm8oTF5rA+ro1t1KXh RvnYxYv0nz0moWG0G8RPtQ2kNpODbmbEBqKl2pTrOw+o6nY7Z47FJXEZiqpPBLXUV+2ykYey 2PT3lZtYwHOh76kh3HdsVVd8UQVfalCZNNJJkZXD0QRfxByBEGHLdYC34SRzvyHK/HkCAwEA AaMwMC4wHgYDVR0RBBcwFYETd2F3YUB5YW5kZXgtdGVhbS5ydTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAIj8aIRL9pal/v0odxMweiFvOdTJBI3Ov/mmA0FNrxeSDD9ALUy5 ROAqyuvIxjkyisxlx1iAtMGmPuu+9vVGT8W4ZcO8PdCFjXnvUV1ec+lNKKlGO4Hbh9Q9MKi7 Gg1wKN5G1OdDGlHkHnGNIS9R3WPSSFdm7+GAnCOTNsL6gzGsMIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAlEwggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBbljd38xS+8kYXLmMr593IMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE0MTc0MDM5WjAjBgkqhkiG 9w0BCQQxFgQUtZCkUUqLt/FtuWPwhmsPYv7rVhgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEggEAN1u5lAfShwf/ZgHnjCuvHRl1YNH3etOGpWPTmrei y13lPQVpd3GKu8AH7eMRsdjk4xDYroAFdQffnUjTwl0eKqOXRfrM7G2914zCJKD4swThFgky qYYYsN1kVBvESFlhz6D/rBZoTKmhYRNmBMfmsWes68WxoABQikt5RSbWAdDDvJ5gUum8ReA6 3wSYOGp2nrCigkkO8GeZ6G0KAaIamprZ3Kg6oUG10WBwzqGNA4AUMFr24CY1yi2IcBM4yux8 w61WlVlSHtmhPQ12mbHHdwuuOGPSbx2A1HAu+4PFvpHEELk31RHaQdkXUwMxDKp5VG/a0BaV XA1rJiLAsXEaAQAAAAAAAA== --------------ms030900080101060005020904-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 18:16:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13B2516A49A for ; Thu, 14 Jun 2007 18:16:21 +0000 (UTC) (envelope-from george.uhl@gsfc.nasa.gov) Received: from rattler.eos.nasa.gov (rattler.eos.nasa.gov [198.119.22.20]) by mx1.freebsd.org (Postfix) with ESMTP id E581613C4C1 for ; Thu, 14 Jun 2007 18:16:20 +0000 (UTC) (envelope-from george.uhl@gsfc.nasa.gov) Received: from rattler.eos.nasa.gov (localhost.localdomain [127.0.0.1]) by rattler.eos.nasa.gov (Postfix) with SMTP id 3F431644E4 for ; Thu, 14 Jun 2007 13:26:27 -0400 (EDT) Mime-Version: 1.0 Message-Id: Date: Thu, 14 Jun 2007 13:54:51 -0400 To: freebsd-net@freebsd.org From: George Uhl Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: ng_netflow unable to capture data 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, 14 Jun 2007 18:16:21 -0000 I'm using a freebsd 6.2-RELEASE host as a passive monitor between two routers. I have a netoptics fiber tap that I use to split out the transmit signal from each router and I run them into two fiber interfaces on my host. With ng_eiface I've created a virtual ethernet interface that I use to combine the two transmit streams using ng_one2many. I can see the combined transmit streams on the virtual interface using tcpdump. However, I'm unable to capture netflow data. Any help would be appreciated. Script to set up netflow using netgraph: #!/bin/sh kldload ng_ether kldload ng_tee kldload ng_one2many kldload ng_netflow kldload ng_ksocket # ifaces accepting transmit streams from the routers ifconfig em2 promisc -arp up ifconfig em3 promisc -arp up # create a netgraph virtual interface and attach a tee node to it ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: tee lower right ngctl name ngeth0:lower tee0 # bring up ngeth0 ifconfig ngeth0 promisc -arp up # create a one2many node, attach tapped interfaces to it and hook it to tee node ngctl mkpeer tee0: one2many left one ngctl name tee0:left o2m0 ngctl connect em2: o2m0: lower many0 ngctl connect em3: o2m0: lower many1 # hook up netflow to tap ngctl mkpeer tee0: netflow right2left iface0 ngctl name tee0:right2left flow0 # hook up netflow export to ksocket ngctl mkpeer flow0: ksocket export inet/dgram/udp ngctl msg flow0:export connect inet/127.0.0.1:4444 -- ----------------------------------------------- George Uhl ESDIS Network Prototyping Lab email: george.uhl@gsfc.nasa.gov phone: 301-614-5155 From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 07:40:10 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70E7F16A400 for ; Fri, 15 Jun 2007 07:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC4C13C483 for ; Fri, 15 Jun 2007 07:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5F7e9nw077041 for ; Fri, 15 Jun 2007 07:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5F7e9N1077036; Fri, 15 Jun 2007 07:40:09 GMT (envelope-from gnats) Date: Fri, 15 Jun 2007 07:40:09 GMT Message-Id: <200706150740.l5F7e9N1077036@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alexey Illarionov Cc: Subject: Re: kern/113548: [dummynet] [patch] system hangs with dummynet queues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexey Illarionov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 07:40:10 -0000 The following reply was made to PR kern/113548; it has been noted by GNATS. From: Alexey Illarionov To: Cristian KLEIN Cc: bug-followup@FreeBSD.org Subject: Re: kern/113548: [dummynet] [patch] system hangs with dummynet queues Date: Fri, 15 Jun 2007 11:11:39 +0400 This is a multi-part message in MIME format. --------------040704070900010000020204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cristian KLEIN wrote: > I think the problem occurs because you use ipfw tags. As far as I know, > ipfw tags are stored as mbuf_tags(9). Dummynet uses mbuf tags too to > mark it's own packets. However, I suspect that in dn_tag_get(), dummynet > incorrectly assumes it is the only one using mbuf_tags(9). > Could you please apply the following patch? Also, could you test whether > removing "tag 1" from ipfw rules has any impact? Thanks for a fast reply and for the patch. It seems that panics have really been caused by ipfw tags. When I apply this patch, there were no panics for several days, but I have got the following dump today: kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xec221d87 fault code = supervisor read, page not present instruction pointer = 0x20:0xc05dafc6 stack pointer = 0x28:0xde7b0c24 frame pointer = 0x28:0xde7b0c28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 30 (dummynet) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(100,c52ad480,28,de7b0be4,c,...) at kdb_backtrace+0x29 panic(c078df19,c07d4928,0,fffff,c09b,...) at panic+0xa4 trap_fatal(de7b0be4,ec221d87,c52ad480,c104b000,ec221000,...) at trap_fatal+0x2b7 trap_pfault(de7b0be4,0,ec221d87) at trap_pfault+0x16b trap(8,28,28,1,0,...) at trap+0x331 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc05dafc6, esp = 0xde7b0c24, ebp = 0xde7b0c28 --- m_tag_locate(c55df900,0,f,0) at m_tag_locate+0x36 dn_tag_get(c55df900,2ffbd300,1,c05c3e7e,c088e858,...) at dn_tag_get+0x1d ready_event_wfq(c57b0800,de7b0cac,de7b0cb0) at ready_event_wfq+0x50b dummynet_task(0,1) at dummynet_task+0x24c taskqueue_run(c5562a00) at taskqueue_run+0xd1 taskqueue_thread_loop(c08ce950,de7b0d38,c08ce950,c05c01e0,0,...) at taskqueue_thread_loop+0x4a fork_exit(c05c01e0,c08ce950,de7b0d38) at fork_exit+0xa8 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xde7b0d6c, ebp = 0 --- Uptime: 50m0s Dumping 511 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc059f2a6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc059f57b in panic (fmt=0xc078df19 "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc076c1f7 in trap_fatal (frame=0xde7b0be4, eva=3961658759) at /usr/src/sys/i386/i386/trap.c:837 #4 0xc076bf0b in trap_pfault (frame=0xde7b0be4, usermode=0, eva=3961658759) at /usr/src/sys/i386/i386/trap.c:745 #5 0xc076bb71 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 1, tf_esi = 0, tf_ebp = -562361304, tf_isp = -562361328, tf_ebx = 15, tf_edx = -333308545, tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1067601978, tf_cs = 32, tf_eflags = 66178, tf_esp = 22, tf_ss = -562361280}) at /usr/src/sys/i386/i386/trap.c:435 #6 0xc0758bca in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05dafc6 in m_tag_locate (m=0xec221d7f, cookie=0, type=15, t=0x0) at /usr/src/sys/kern/uipc_mbuf2.c:392 #8 0xc06279ad in dn_tag_get (m=0xec221d7f) at mbuf.h:881 #9 0xc06281fb in ready_event_wfq (p=0xc57b0800, head=0xde7b0cac, tail=0xde7b0cb0) at /usr/src/sys/netinet/ip_dummynet.c:705 #10 0xc06284cc in dummynet_task (context=0x0, pending=0) at /usr/src/sys/netinet/ip_dummynet.c:805 #11 0xc05bfe71 in taskqueue_run (queue=0xc5562a00) at /usr/src/sys/kern/subr_taskqueue.c:257 #12 0xc05c022a in taskqueue_thread_loop (arg=0x0) at /usr/src/sys/kern/subr_taskqueue.c:376 #13 0xc05897b8 in fork_exit (callout=0xc05c01e0 , arg=0xc08ce950, frame=0xde7b0d38) at /usr/src/sys/kern/kern_fork.c:821 #14 0xc0758c2c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) up 9 #9 0xc06281fb in ready_event_wfq (p=0xc57b0800, head=0xde7b0cac, tail=0xde7b0cb0) at /usr/src/sys/netinet/ip_dummynet.c:705 705 dn_tag_get(p->tail)->output_time += t ; (kgdb) p *p $1 = {next = {sle_next = 0xc6713600}, pipe_nr = 1700, bandwidth = 50000000, delay = 0, head = 0x0, tail = 0xc55df900, scheduler_heap = {size = 16, elements = 1, offset = 0, p = 0xc57b2800}, not_eligible_heap = {size = 16, elements = 0, offset = 0, p = 0xc57ac700}, idle_heap = {size = 16, elements = 0, offset = 124, p = 0xc56a2800}, V = 9830400, sum = 10, numbytes = -1090027776, sched_time = 2997985, if_name = '\0' , ifp = 0x0, ready = 0, fs = { next = {sle_next = 0x0}, fs_nr = 0, flags_fs = 0, pipe = 0xc57b0800, parent_nr = 0, weight = 0, qsize = 50, plr = 0, flow_mask = {dst_ip = 0, src_ip = 0, dst_port = 0, src_port = 0, proto = 0 '\0', flags = 0 '\0', addr_type = 0 '\0', dst_ip6 = {__u6_addr = {__u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = { 0, 0, 0, 0}}}, src_ip6 = {__u6_addr = {__u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, flow_id6 = 0, frag_id6 = 0}, rq_size = 1, rq_elements = 0, rq = 0xc55791b0, last_expired = 0, backlogged = 0, w_q = 0, max_th = 0, min_th = 0, max_p = 0, c_1 = 0, c_2 = 0, c_3 = 0, c_4 = 0, w_q_lookup = 0x0, lookup_depth = 0, lookup_step = 0, lookup_weight = 0, avg_pkt_size = 0, max_pkt_size = 0}} When I remove "tag 1" the kernel stopped panick, but deadlocks didn't pass away. When I managed to enter DDB using serial console I found dummynet_task() looped on the following code: h = heaps[i]; while (h->elements > 0 && DN_KEY_LEQ(h->p[0].key, curr_time)) { ... ready_event_wfq(p, &head, &tail); ... } It seems to me that problem is in ready_event_wfq() in the following code: if (p->bandwidth > 0) t = (p->bandwidth -1 - p->numbytes) / p->bandwidth ; Since p->bandwidth and p->numbytes are signed integers, the result can be negative (i have p->bandwidth=50000000 and p->numbytes=-2147483647) Now i test attached patch. I hope it will help. :) --------------040704070900010000020204 Content-Type: text/x-patch; name="ip_dummynet.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ip_dummynet.c.patch" --- ip_dummynet.c_orig Sun Jun 10 20:19:33 2007 +++ ip_dummynet.c Fri Jun 15 07:37:46 2007 @@ -433,7 +433,7 @@ static struct dn_pkt_tag * dn_tag_get(struct mbuf *m) { - struct m_tag *mtag = m_tag_first(m); + struct m_tag *mtag = m_tag_find(m, PACKET_TAG_DUMMYNET, NULL); KASSERT(mtag != NULL && mtag->m_tag_cookie == MTAG_ABI_COMPAT && mtag->m_tag_id == PACKET_TAG_DUMMYNET, @@ -698,8 +698,10 @@ if (p->if_name[0]==0 && p->numbytes < 0) { /* this implies bandwidth >0 */ dn_key t=0 ; /* number of ticks i have to wait */ - if (p->bandwidth > 0) - t = ( p->bandwidth -1 - p->numbytes) / p->bandwidth ; + if (p->bandwidth > 0) + t = ( (u_int64_t)p->bandwidth -1 - p->numbytes) / p->bandwidth ; + + KASSERT( (curr_time + t) >= curr_time, ("wfq overflow")); dn_tag_get(p->tail)->output_time += t ; p->sched_time = curr_time ; heap_insert(&wfq_ready_heap, curr_time + t, (void *)p); --------------040704070900010000020204-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 07:40:15 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 446E316A400 for ; Fri, 15 Jun 2007 07:40:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id E03A813C483 for ; Fri, 15 Jun 2007 07:40:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5F7eEZO077090 for ; Fri, 15 Jun 2007 07:40:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5F7eEl1077089; Fri, 15 Jun 2007 07:40:14 GMT (envelope-from gnats) Date: Fri, 15 Jun 2007 07:40:14 GMT Message-Id: <200706150740.l5F7eEl1077089@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Cristian KLEIN Cc: Subject: Re: kern/113548: [dummynet] [patch] system hangs with dummynet queues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cristian KLEIN List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 07:40:15 -0000 The following reply was made to PR kern/113548; it has been noted by GNATS. From: Cristian KLEIN To: Alexey Illarionov Cc: bug-followup@FreeBSD.org Subject: Re: kern/113548: [dummynet] [patch] system hangs with dummynet queues Date: Fri, 15 Jun 2007 10:30:43 +0300 Alexey Illarionov wrote: > Cristian KLEIN wrote: > >> I think the problem occurs because you use ipfw tags. As far as I know, >> ipfw tags are stored as mbuf_tags(9). Dummynet uses mbuf tags too to >> mark it's own packets. However, I suspect that in dn_tag_get(), dummynet >> incorrectly assumes it is the only one using mbuf_tags(9). > >> Could you please apply the following patch? Also, could you test whether >> removing "tag 1" from ipfw rules has any impact? > > Thanks for a fast reply and for the patch. It seems that panics have > really been caused by ipfw tags. When I apply this patch, there were no > panics for several days, but I have got the following dump today: > > kgdb: kvm_nlist(_stopped_cpus): > kgdb: kvm_nlist(_stoppcbs): > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xec221d87 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc05dafc6 > stack pointer = 0x28:0xde7b0c24 > frame pointer = 0x28:0xde7b0c28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 30 (dummynet) > trap number = 12 > panic: page fault > KDB: stack backtrace: > kdb_backtrace(100,c52ad480,28,de7b0be4,c,...) at kdb_backtrace+0x29 > panic(c078df19,c07d4928,0,fffff,c09b,...) at panic+0xa4 > trap_fatal(de7b0be4,ec221d87,c52ad480,c104b000,ec221000,...) at > trap_fatal+0x2b7 > trap_pfault(de7b0be4,0,ec221d87) at trap_pfault+0x16b > trap(8,28,28,1,0,...) at trap+0x331 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc05dafc6, esp = 0xde7b0c24, ebp = 0xde7b0c28 --- > m_tag_locate(c55df900,0,f,0) at m_tag_locate+0x36 > dn_tag_get(c55df900,2ffbd300,1,c05c3e7e,c088e858,...) at dn_tag_get+0x1d > ready_event_wfq(c57b0800,de7b0cac,de7b0cb0) at ready_event_wfq+0x50b > dummynet_task(0,1) at dummynet_task+0x24c > taskqueue_run(c5562a00) at taskqueue_run+0xd1 > taskqueue_thread_loop(c08ce950,de7b0d38,c08ce950,c05c01e0,0,...) at > taskqueue_thread_loop+0x4a > fork_exit(c05c01e0,c08ce950,de7b0d38) at fork_exit+0xa8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xde7b0d6c, ebp = 0 --- > Uptime: 50m0s > Dumping 511 MB (2 chunks) > chunk 0: 1MB (156 pages) ... ok > chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 > 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 > 31 15 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc059f2a6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc059f57b in panic (fmt=0xc078df19 "%s") at > /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc076c1f7 in trap_fatal (frame=0xde7b0be4, eva=3961658759) at > /usr/src/sys/i386/i386/trap.c:837 > #4 0xc076bf0b in trap_pfault (frame=0xde7b0be4, usermode=0, > eva=3961658759) at /usr/src/sys/i386/i386/trap.c:745 > #5 0xc076bb71 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 1, tf_esi = 0, tf_ebp > = -562361304, tf_isp = -562361328, tf_ebx = 15, tf_edx = -333308545, > tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = > -1067601978, tf_cs = 32, tf_eflags = 66178, tf_esp = 22, tf_ss = > -562361280}) at /usr/src/sys/i386/i386/trap.c:435 > #6 0xc0758bca in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc05dafc6 in m_tag_locate (m=0xec221d7f, cookie=0, type=15, t=0x0) > at /usr/src/sys/kern/uipc_mbuf2.c:392 > #8 0xc06279ad in dn_tag_get (m=0xec221d7f) at mbuf.h:881 > #9 0xc06281fb in ready_event_wfq (p=0xc57b0800, head=0xde7b0cac, > tail=0xde7b0cb0) at /usr/src/sys/netinet/ip_dummynet.c:705 > #10 0xc06284cc in dummynet_task (context=0x0, pending=0) at > /usr/src/sys/netinet/ip_dummynet.c:805 > #11 0xc05bfe71 in taskqueue_run (queue=0xc5562a00) at > /usr/src/sys/kern/subr_taskqueue.c:257 > #12 0xc05c022a in taskqueue_thread_loop (arg=0x0) at > /usr/src/sys/kern/subr_taskqueue.c:376 > #13 0xc05897b8 in fork_exit (callout=0xc05c01e0 , > arg=0xc08ce950, frame=0xde7b0d38) > at /usr/src/sys/kern/kern_fork.c:821 > #14 0xc0758c2c in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:208 > (kgdb) up 9 > #9 0xc06281fb in ready_event_wfq (p=0xc57b0800, head=0xde7b0cac, > tail=0xde7b0cb0) at /usr/src/sys/netinet/ip_dummynet.c:705 > 705 dn_tag_get(p->tail)->output_time += t ; > (kgdb) p *p > $1 = {next = {sle_next = 0xc6713600}, pipe_nr = 1700, bandwidth = > 50000000, delay = 0, head = 0x0, tail = 0xc55df900, > scheduler_heap = {size = 16, elements = 1, offset = 0, p = > 0xc57b2800}, not_eligible_heap = {size = 16, elements = 0, > offset = 0, p = 0xc57ac700}, idle_heap = {size = 16, elements = 0, > offset = 124, p = 0xc56a2800}, V = 9830400, > sum = 10, numbytes = -1090027776, sched_time = 2997985, if_name = '\0' > , ifp = 0x0, ready = 0, fs = { > next = {sle_next = 0x0}, fs_nr = 0, flags_fs = 0, pipe = 0xc57b0800, > parent_nr = 0, weight = 0, qsize = 50, plr = 0, > flow_mask = {dst_ip = 0, src_ip = 0, dst_port = 0, src_port = 0, > proto = 0 '\0', flags = 0 '\0', addr_type = 0 '\0', > dst_ip6 = {__u6_addr = {__u6_addr8 = '\0' , > __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = { > 0, 0, 0, 0}}}, src_ip6 = {__u6_addr = {__u6_addr8 = '\0' > , __u6_addr16 = {0, 0, 0, 0, 0, 0, > 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, flow_id6 = 0, frag_id6 > = 0}, rq_size = 1, rq_elements = 0, > rq = 0xc55791b0, last_expired = 0, backlogged = 0, w_q = 0, max_th = > 0, min_th = 0, max_p = 0, c_1 = 0, c_2 = 0, > c_3 = 0, c_4 = 0, w_q_lookup = 0x0, lookup_depth = 0, lookup_step = > 0, lookup_weight = 0, avg_pkt_size = 0, > max_pkt_size = 0}} > > > When I remove "tag 1" the kernel stopped panick, but deadlocks didn't > pass away. When I managed to enter DDB using serial console I found > dummynet_task() looped on the following code: > > h = heaps[i]; > while (h->elements > 0 && DN_KEY_LEQ(h->p[0].key, curr_time)) { > ... > ready_event_wfq(p, &head, &tail); > ... > } > It seems to me that problem is in ready_event_wfq() in the following code: > if (p->bandwidth > 0) > t = (p->bandwidth -1 - p->numbytes) / p->bandwidth ; > > Since p->bandwidth and p->numbytes are signed integers, the result can > be negative (i have p->bandwidth=50000000 and p->numbytes=-2147483647) > > Now i test attached patch. I hope it will help. :) Could you please be so kind and test whether SMP has any effect on the bug. I.e. does an unpatched ip_dummynet without SMP cause panics? I ask this because I was unable to reproduce this bug on a non-SMP machine. Also, I see you have "dummynet_task" in your dumps. Are using RELENG_6 or 1.93.2.6 of ip_dummynet.c? From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 08:01:45 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8B6516A400 for ; Fri, 15 Jun 2007 08:01:45 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 6D49813C44C for ; Fri, 15 Jun 2007 08:01:45 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix2-g20.free.fr (Postfix) with ESMTP id 8D2C9131F6D7 for ; Fri, 15 Jun 2007 08:28:27 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 5384244CA9 for ; Fri, 15 Jun 2007 09:27:51 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 339319B497 for ; Fri, 15 Jun 2007 07:27:35 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 11ACA405B; Fri, 15 Jun 2007 09:27:35 +0200 (CEST) Date: Fri, 15 Jun 2007 09:27:35 +0200 From: Jeremie Le Hen To: freebsd-net@FreeBSD.org Message-ID: <20070615072734.GC8093@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Subject: Firewalling NFS 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, 15 Jun 2007 08:01:45 -0000 Hi, It appears nearly impossible to firewall a NFS server on FreeBSD. The reason is that NFS related daemons use RPC, which means they don't bind to a deterministic port. Only mountd(8) can be requested to bind to a specific port or fail with the -p command-line switch. Is there any reason other than "no one has needed this yet" why this option is not available for nfsd(8), rpc.lockd(8) and rpc.statd(8)? Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 08:40:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F8DD16A41F for ; Fri, 15 Jun 2007 08:40:15 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 9B75113C46E for ; Fri, 15 Jun 2007 08:40:14 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l5F8PGB9096538; Fri, 15 Jun 2007 16:25:16 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l5F8PGbv096537; Fri, 15 Jun 2007 16:25:16 +0800 (KRAST) (envelope-from eugen) Date: Fri, 15 Jun 2007 16:25:16 +0800 From: Eugene Grosbein To: Jeremie Le Hen Message-ID: <20070615082516.GA96373@svzserv.kemerovo.su> References: <20070615072734.GC8093@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070615072734.GC8093@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Firewalling NFS 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, 15 Jun 2007 08:40:15 -0000 On Fri, Jun 15, 2007 at 09:27:35AM +0200, Jeremie Le Hen wrote: > Hi, > > It appears nearly impossible to firewall a NFS server on FreeBSD. > The reason is that NFS related daemons use RPC, which means they > don't bind to a deterministic port. Only mountd(8) can be requested to > bind to a specific port or fail with the -p command-line switch. > Is there any reason other than "no one has needed this yet" why this > option is not available for nfsd(8), rpc.lockd(8) and rpc.statd(8)? Why do you need such option for nfsd(8) in first place? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 09:05:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7418016A469 for ; Fri, 15 Jun 2007 09:05:34 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from mail.monkeybrains.net (mail1.monkeybrains.net [208.69.40.8]) by mx1.freebsd.org (Postfix) with ESMTP id 5DDAA13C46A for ; Fri, 15 Jun 2007 09:05:34 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from monchichi.monkeybrains.net (adsl-75-36-247-158.dsl.pltn13.sbcglobal.net [75.36.247.158]) (authenticated bits=0) by mail.monkeybrains.net (8.13.7/8.13.7) with ESMTP id l5F95XD4019028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jun 2007 02:05:34 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <46725657.8010807@monkeybrains.net> Date: Fri, 15 Jun 2007 02:05:27 -0700 From: Rudy Rucker User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: Marko Lerota References: <466F21DA.20001@monkeybrains.net> <86r6ogfgj4.fsf@sparrow.local> In-Reply-To: <86r6ogfgj4.fsf@sparrow.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on mail.monkeybrains.net X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: CARP on backup doesn't relinquish MASTER 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, 15 Jun 2007 09:05:34 -0000 Ah... put it will also failover all the OTHER carp interfaces on the box when a physical interface goes down.... I had read the man page as that being the ONLY feature of that sysctl variable. 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 interfaces. THanks! Marko Lerota wrote: > Rudy Rucker writes: > >> I noticed that if I reboot a server that is the MASTER, the carp0 on >> the BACKUP box goes into MASTER mode and stays that way -- even when >> the real master machine has finished rebooting. Is this a desired >> trait to prevent CARP from switching IPs out of control? > > Yes, it depends of what you have put in 'net.inet.carp.preempt' > > if it's net.inet.carp.preempt=0 > than the backap will become master and stays that way > > and if it's net.inet.carp.preempt=1 > then the "real" master will take over the IP address from backup > server when he gets in the OK state > From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 10:43:37 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13ACC16A469 for ; Fri, 15 Jun 2007 10:43:37 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 98D1D13C484 for ; Fri, 15 Jun 2007 10:43:36 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l5FAhUm1001803; Fri, 15 Jun 2007 20:43:30 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l5FAhT9V001802; Fri, 15 Jun 2007 20:43:29 +1000 (EST) (envelope-from peter) Date: Fri, 15 Jun 2007 20:43:29 +1000 From: Peter Jeremy To: Ivan Voras Message-ID: <20070615104329.GF1173@turion.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-net@freebsd.org Subject: Re: VLANs and routing 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, 15 Jun 2007 10:43:37 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jun-14 01:55:20 +0200, Ivan Voras wrote: >But the (somewhat weird) requirements are that the vlan interface on >machine1 shouldn't have assigned IP address, but the second one should. =2E.. >Is this kind of setup even supported? I don't see how it could be if machine1 is an IP endpoint: In order to transmit a packet, it needs to put a source IP address into the packet - which virtually always comes from the interface. --=20 Peter Jeremy --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGcm1R/opHv/APuIcRAozTAJ43EK6euK6f+iZg1XjUXoEQylQLigCeOIco yi9qJ6BCDc88b6yzruQscRg= =HbKv -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 10:56:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E80716A400 for ; Fri, 15 Jun 2007 10:56:22 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 361CD13C4B0 for ; Fri, 15 Jun 2007 10:56:21 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hz9TN-0005ZS-Jg for freebsd-net@freebsd.org; Fri, 15 Jun 2007 12:56:09 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jun 2007 12:56:09 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jun 2007 12:56:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 15 Jun 2007 12:55:40 +0200 Lines: 40 Message-ID: References: <20070615104329.GF1173@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6AA979154D3FFBF7E712CC2E" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: <20070615104329.GF1173@turion.vk2pj.dyndns.org> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: VLANs and routing 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, 15 Jun 2007 10:56:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6AA979154D3FFBF7E712CC2E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Peter Jeremy wrote: > On 2007-Jun-14 01:55:20 +0200, Ivan Voras wrote: >> But the (somewhat weird) requirements are that the vlan interface on >> machine1 shouldn't have assigned IP address, but the second one should= =2E > ... >> Is this kind of setup even supported? >=20 > I don't see how it could be if machine1 is an IP endpoint: In order > to transmit a packet, it needs to put a source IP address into the > packet - which virtually always comes from the interface. Yes, I'm wondering about the "almost always" case. Since machine1 has=20 multiple physical and vlan interfaces, shouldn't a (for example) server=20 bound to one of the existing physical interfaces be able to communicate=20 with machine2, provided that both machines know how to route packets to=20 each other over the vlan interface without IP address? --------------enig6AA979154D3FFBF7E712CC2E 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.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGcnAsldnAQVacBcgRAh9CAJ9XOBdL3PgakvwQHIUt8yW5UdkaOwCg+jg9 dOI5mLS5KWYcHumovjfwNoM= =tRUm -----END PGP SIGNATURE----- --------------enig6AA979154D3FFBF7E712CC2E-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 10:59:56 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8CF316A469 for ; Fri, 15 Jun 2007 10:59:56 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2ED13C447 for ; Fri, 15 Jun 2007 10:59:56 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=SwRzQTA5GM4xrSLnUw80fqITKLpNMwB8VIdNR0R0jgjeCQ4llen6shG4jlBAeJpKi/HBgSpDNy8g807nVgrgo47abPNqsaA/TxU3sGG8LsZhjYWWPt2IrReRbNUUJ4xe22BYNNSz0s/lrCFwi+WY92ObHYOwQL8VISFv/HauaxI=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Hz9X0-0004gL-KB; Fri, 15 Jun 2007 14:59:54 +0400 Date: Fri, 15 Jun 2007 14:59:50 +0400 From: Eygene Ryabinkin To: Jeremie Le Hen Message-ID: <20070615105950.GH3779@void.codelabs.ru> References: <20070615072734.GC8093@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070615072734.GC8093@obiwan.tataz.chchile.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_05 Cc: freebsd-net@FreeBSD.org Subject: Re: Firewalling NFS 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, 15 Jun 2007 10:59:56 -0000 Jeremie, good day. Fri, Jun 15, 2007 at 09:27:35AM +0200, Jeremie Le Hen wrote: > It appears nearly impossible to firewall a NFS server on FreeBSD. > The reason is that NFS related daemons use RPC, which means they > don't bind to a deterministic port. Only mountd(8) can be requested to > bind to a specific port or fail with the -p command-line switch. > Is there any reason other than "no one has needed this yet" why this > option is not available for nfsd(8), rpc.lockd(8) and rpc.statd(8)? NFSD binds to the port nfsd (2049) and for my -CURRENT both lockd and statd have '-p' options: ----- $ man rpc.lockd rpc.statd | grep -- -p rpc.lockd [-d debug_level] [-g grace period] [-p port] -p The -p option allow to force the daemon to bind to the specified rpc.statd [-d] [-p port] -p The -p option allow to force the daemon to bind to the specified ----- Are we talking about same entities? -- Eygene From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 16:04:16 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3315A16A46F for ; Fri, 15 Jun 2007 16:04:16 +0000 (UTC) (envelope-from tutatnhamon@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id C98A813C489 for ; Fri, 15 Jun 2007 16:04:15 +0000 (UTC) (envelope-from tutatnhamon@gmail.com) Received: by py-out-1112.google.com with SMTP id a29so1695240pyi for ; Fri, 15 Jun 2007 09:04:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=eRy4TwbAcKTuq081ZoGENn9yeIxtsPzi4pyEv6upYlgnC/2sNCUbpapmN3NvhIYtGiGozbDf2zRGAQRmFhJ7fp0k+O5whYaCBDKqLovQntI6K5MTb1X9ix884SNiaUbPXUE8lMJ8AVRJ0Rxmmy5TyikeQ42h2fVbSZMSDauVQFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=IeCzpAHbrKEkkoRQcYkSV6zJx6S57JXDYsgcsuk0dWntOx3FhmHpunZhCiNxvcyXpRy7YhynnX1XNqYSjUc4eaFAPdXadP7L7Wgp/OsAmtpMRozXXhyaOu070MwMWWZsKQ9JjagKhvAPOJC/2zU1q2SoWSLq9m0NNj7OGlTvIPM= Received: by 10.64.151.17 with SMTP id y17mr5390351qbd.1181921698250; Fri, 15 Jun 2007 08:34:58 -0700 (PDT) Received: by 10.65.180.5 with HTTP; Fri, 15 Jun 2007 08:34:58 -0700 (PDT) Message-ID: <65dfa4fc0706150834k3766f42ao8a77b66cb44b48c7@mail.gmail.com> Date: Fri, 15 Jun 2007 18:34:58 +0300 From: "Artem Naluzhny" Sender: tutatnhamon@gmail.com To: current@freebsd.org, net@freebsd.org In-Reply-To: <65dfa4fc0706150750s266e8f37l868a2bc685bd6750@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <65dfa4fc0706141427q24f74f0kd82d20a9bb20e09b@mail.gmail.com> <65dfa4fc0706150730g29619f06h3b5ca07e382485a3@mail.gmail.com> <65dfa4fc0706150750s266e8f37l868a2bc685bd6750@mail.gmail.com> X-Google-Sender-Auth: d4db3488398d3d01 Cc: Subject: Re: "kernel: rtfree: 0xc3c4bd98 has 2 refs" on recent current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 16:04:16 -0000 > Here is a backtrace: > > rtfree: 0xc3c5cca8 has 2 refs > KDB: stack backtrace: > db_trace_self_wrapper(c06b84de,e111dad4,c05d18f1,c06be1ff,c069bdd1,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(c06be1ff,c069bdd1,c3c5cca8,2,c3c5cca8,...) at kdb_backtrace+0x29 > rtfree(c3c5cca8,c3b3a010,10,c05d190b,c3c5cd98,...) at rtfree+0x51 > rtredirect(e111dba0,e111db90,0,6,e111db80,...) at rtredirect+0x1cf > icmp_input(c3d14400,14,e111dbd8,0,c3c63e00,...) at icmp_input+0x50f > ip_input(c3d14400,c05bd255,800,c39e5800,800,...) at ip_input+0x6ae > netisr_dispatch(2,c3d14400,10,3,0,...) at > netisr_dispatch+0x55 > ether_demux(c39e5800,c3d14400,3,0,3,...) at ether_demux+0x1aa > ether_input(c39e5800,c3d14400,2,1,c396cc84,...) at ether_input+0x323 > bfe_intr(c39d1000,0,c06b4383,46b,0,...) at bfe_intr+0x41a > ithread_loop(c39eb730,e111dd38,0,0,0,...) at ithread_loop+0x1ab > fork_exit(c0511d70,c39eb730,e111dd38) at fork_exit+0x99 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe111dd70, ebp = 0 --- > > > Here is an incoming ICMP packet (the last one) causing the "rtfree has > 2 refs" message (00:19:b9:5a:a3:10 is my host): > > 17:47:46.915491 00:0c:29:b2:14:38 > 00:19:b9:5a:a3:10, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 48899, offset 0, flags [none], proto: ICMP (1), length: 56) 192.168.0.25 > 192.168.0.55: ICMP redirect 192.168.0.1 to host 192.168.0.1, length 36 > (tos 0x0, ttl 16, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.0.55.68 > 192.168.0.1.67: [|bootp] > 0x0000: 4500 0038 bf03 0000 4001 3a21 c0a8 0019 E..8....@.:!.... > 0x0010: c0a8 0037 0501 48f7 c0a8 0001 4500 0148 ...7..H.....E..H > 0x0020: 0000 0000 1011 281d c0a8 0037 c0a8 0001 ......(....7.... > 0x0030: 0044 0043 0134 efa2 .D.C.4.. > 17:47:46.942512 00:19:b9:5a:a3:10 > 00:50:bf:b1:34:a3, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 207, offset 0, flags [none], proto: ICMP (1), length: 56) 192.168.0.55 > 192.168.0.1: ICMP 192.168.0.55 udp port 68 unreachable, length 36 > (tos 0x0, ttl 64, id 14203, offset 0, flags [none], proto: UDP (17), length: 334) 192.168.0.1.67 > 192.168.0.55.68: [|bootp] > 0x0000: 4500 0038 00cf 0000 4001 f86d c0a8 0037 E..8....@..m...7 > 0x0010: c0a8 0001 0303 0dbe 0000 0000 4500 014e ............E..N > 0x0020: 377b 0000 4011 c09b c0a8 0001 c0a8 0037 7{..@..........7 > 0x0030: 0043 0044 013a ed7d .C.D.:.} > 17:47:46.942528 00:19:b9:5a:a3:10 > 00:50:bf:b1:34:a3, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 208, offset 0, flags [none], proto: ICMP (1), length: 56) 192.168.0.55 > 192.168.0.1: ICMP 192.168.0.55 udp port 68 unreachable, length 36 > (tos 0x0, ttl 64, id 14204, offset 0, flags [none], proto: UDP (17), length: 334) 192.168.0.1.67 > 192.168.0.55.68: [|bootp] > 0x0000: 4500 0038 00d0 0000 4001 f86c c0a8 0037 E..8....@..l...7 > 0x0010: c0a8 0001 0303 0dbe 0000 0000 4500 014e ............E..N > 0x0020: 377c 0000 4011 c09a c0a8 0001 c0a8 0037 7|..@..........7 > 0x0030: 0043 0044 013a ed7d .C.D.:.} The behavior was introduced by following commit: glebius 2007-05-22 16:17:32 UTC FreeBSD src repository Modified files: sys/net route.c Log: Some minor cleanups: - In rt_check() remove the senderr() macro and the "bad" label. They used to simplify code, but now aren't. - Remove extra RT_LOCK_ASSERT() in rt_setgate(). The RT_REMREF macro does this. - In rtfree() convert panics to KASSERTs. - Strict the routing API: rtfree() should be called only in a case when we are completely sure we've got the last reference on the rtentry. In all other cases RTFREE_LOCKED() macro should be used. If the reference isn't the last one spit out a warning printf. Correct the only(?) case for this in rt_check(). - Fix typos in comments. Revision Changes Path 1.119 +15 -22 src/sys/net/route.c -- /tut From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 16:45:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 530D716A46C for ; Fri, 15 Jun 2007 16:45:17 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by mx1.freebsd.org (Postfix) with ESMTP id 089E513C468 for ; Fri, 15 Jun 2007 16:45:17 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 1HzEeJ-0003f3-Ls for freebsd-net@freebsd.org; Fri, 15 Jun 2007 16:27:47 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp3.email.verio.net with esmtp id 1HzEeJ-0003qd-H5 for freebsd-net@freebsd.org; Fri, 15 Jun 2007 16:27:47 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id B7C1C8E296; Fri, 15 Jun 2007 11:27:38 -0500 (CDT) Date: Fri, 15 Jun 2007 11:27:38 -0500 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20070615162738.GA21747@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20070615104329.GF1173@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20070615104329.GF1173@turion.vk2pj.dyndns.org> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: VLANs and routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 16:45:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Jeremy wrote: > > > But the (somewhat weird) requirements are that the vlan interface on > > machine1 shouldn't have assigned IP address, but the second one > > should. > [...] > > Is this kind of setup even supported? > > I don't see how it could be if machine1 is an IP endpoint: In order > to transmit a packet, it needs to put a source IP address into the > packet - which virtually always comes from the interface. When originating a packet, that is the case. But a forwarded packet already has a source address, which can be left unchanged. As long as routing is working (ARP is not needed, destination is clear, etc), the intermediate interface need not have an IP. - -- David DeSimone == Network Admin == fox@verio.net "It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGcr36FSrKRjX5eCoRAnnwAJ4l/TIJPiMsNULHhAoJi6q12Y/vygCggBEe k47dQu/ZHnKNEPTaE9aW4lQ= =pg4w -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 17:22:10 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C1E816A46B; Fri, 15 Jun 2007 17:22:10 +0000 (UTC) (envelope-from oleg@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id EA87013C45A; Fri, 15 Jun 2007 17:22:09 +0000 (UTC) (envelope-from oleg@FreeBSD.org) Received: from freefall.freebsd.org (oleg@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5FHM9vR049060; Fri, 15 Jun 2007 17:22:09 GMT (envelope-from oleg@freefall.freebsd.org) Received: (from oleg@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5FHM989049056; Fri, 15 Jun 2007 17:22:09 GMT (envelope-from oleg) Date: Fri, 15 Jun 2007 17:22:09 GMT From: Oleg Bulyzhin Message-Id: <200706151722.l5FHM989049056@freefall.freebsd.org> To: oleg@FreeBSD.org, freebsd-net@FreeBSD.org, oleg@FreeBSD.org Cc: Subject: Re: kern/113548: [dummynet] [patch] system hangs with dummynet queues 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, 15 Jun 2007 17:22:10 -0000 Synopsis: [dummynet] [patch] system hangs with dummynet queues Responsible-Changed-From-To: freebsd-net->oleg Responsible-Changed-By: oleg Responsible-Changed-When: Fri Jun 15 17:21:30 UTC 2007 Responsible-Changed-Why: take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=113548 From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 17:47:12 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3E0C16A400 for ; Fri, 15 Jun 2007 17:47:12 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 9EF8613C457 for ; Fri, 15 Jun 2007 17:47:12 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 3F230E0C; Fri, 15 Jun 2007 13:47:12 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 15 Jun 2007 13:47:12 -0400 X-Sasl-enc: YcM8odFVdT7onGzbMgKf75NTRwbhm6OH46MVWOIeOWP9 1181929631 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 88C0778A; Fri, 15 Jun 2007 13:47:11 -0400 (EDT) Message-ID: <4672D09B.9030100@incunabulum.net> Date: Fri, 15 Jun 2007 18:47:07 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eygene Ryabinkin References: <20070615072734.GC8093@obiwan.tataz.chchile.org> <20070615105950.GH3779@void.codelabs.ru> In-Reply-To: <20070615105950.GH3779@void.codelabs.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Jeremie Le Hen Subject: Re: Firewalling NFS 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, 15 Jun 2007 17:47:12 -0000 Eygene Ryabinkin wrote: > NFSD binds to the port nfsd (2049) and for my -CURRENT both lockd > and statd have '-p' options: > ----- > $ man rpc.lockd rpc.statd | grep -- -p > rpc.lockd [-d debug_level] [-g grace period] [-p port] > -p The -p option allow to force the daemon to bind to the specified > rpc.statd [-d] [-p port] > -p The -p option allow to force the daemon to bind to the specified > ----- > Are we talking about same entities? > I added the -p switch to mountd(8) a few years ago, as I needed to run a read-only NFS server exposed to the outside world; to firewall it I needed a deterministic RPC port number, which is what -p gives you. Otherwise you have to rely on the TCP wrapper support built into rpcbind(8). The rpc.lockd and rpc.statd daemons were recently changed to incorporate this switch too, although I don't think it has been backported to the 6-STABLE branch yet. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 17:55:39 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC42716A400 for ; Fri, 15 Jun 2007 17:55:39 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id A73AA13C43E for ; Fri, 15 Jun 2007 17:55:38 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=aLouZM5k1pzOa5VgnPMDiNvFV2c/NN3gLRPifFC7E3A8kNGr5sdKf4OjSDcJLEzha7z8biU6tjdnvdTlLn2sTOz7OVytHTM4IqsD9TNRBeniU+TgdBoqw1HW/P5Gd6cDjRTHNHu0EKpLiWr4XAQ2qjV8FVkqG3UkM/tDH0V6Lpc=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HzG1F-00055F-N6; Fri, 15 Jun 2007 21:55:33 +0400 Date: Fri, 15 Jun 2007 21:55:28 +0400 From: Eygene Ryabinkin To: "Bruce M. Simpson" Message-ID: <20070615175528.GL3779@void.codelabs.ru> References: <20070615072734.GC8093@obiwan.tataz.chchile.org> <20070615105950.GH3779@void.codelabs.ru> <4672D09B.9030100@incunabulum.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4672D09B.9030100@incunabulum.net> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-net@FreeBSD.org, Jeremie Le Hen Subject: Re: Firewalling NFS 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, 15 Jun 2007 17:55:39 -0000 Bruce, good day. Fri, Jun 15, 2007 at 06:47:07PM +0100, Bruce M. Simpson wrote: > I added the -p switch to mountd(8) a few years ago, as I needed to run a > read-only NFS server exposed to the outside world; to firewall it I needed a > deterministic RPC port number, which is what -p gives you. Otherwise you have > to rely on the TCP wrapper support built into rpcbind(8). The rpc.lockd and > rpc.statd daemons were recently changed to incorporate this switch too, > although I don't think it has been backported to the 6-STABLE branch yet. OK, thanks for the explanations. So, Jeremie, you will need to wait for merge of the change or backport it manually. -- Eygene From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 18:11:55 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F8AB16A477 for ; Fri, 15 Jun 2007 18:11:55 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7CF13C480 for ; Fri, 15 Jun 2007 18:11:55 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out4.apple.com (Postfix) with ESMTP id ECA0D91E580; Fri, 15 Jun 2007 11:11:54 -0700 (PDT) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id DEB7A29C003; Fri, 15 Jun 2007 11:11:54 -0700 (PDT) X-AuditID: 11807123-9c2d3bb000007975-40-4672d66a2c66 Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay5.apple.com (Apple SCV relay) with ESMTP id CE3AC30400C; Fri, 15 Jun 2007 11:11:54 -0700 (PDT) In-Reply-To: <20070615072734.GC8093@obiwan.tataz.chchile.org> References: <20070615072734.GC8093@obiwan.tataz.chchile.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E2012CE-0FEA-4A79-B386-13E4C58AA41A@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 15 Jun 2007 11:11:54 -0700 To: Jeremie Le Hen X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-net@FreeBSD.org Subject: Re: Firewalling NFS 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, 15 Jun 2007 18:11:55 -0000 On Jun 15, 2007, at 12:27 AM, Jeremie Le Hen wrote: > It appears nearly impossible to firewall a NFS server on FreeBSD. Yes and no. It's quite easy to firewall NFS along with everything else using a "default deny" ruleset. It's highly difficult to place a restrictive firewall ruleset between an NFS server and legitimate NFS clients, and, more relevantly, it's an open question as to whether it is useful (ie, results in a noticeable benefit to security) to try. The primary purpose of a firewall is to restrict traffic between machines or subnets which are in different trust domains, but you'd darn well better be willing to trust the NFS clients which you intend to connect to your NFS server to access the data on that NFS server, or else you shouldn't be letting them connect via NFS at all. This is because NFS is, by-and-large, unsecurable to a knowledgeable attacker who has NFS client access anyway, or even just the ability to see and inject packets into the same subnet that either the client or server is on. This is less true if NFSv4 via SecureRPC is involved, but otherwise a simple MitM attack via ARP-cache poisoning or similar will get the attacker quite far... -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 19:06:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D05B416A469 for ; Fri, 15 Jun 2007 19:06:24 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from ms-smtp-03.ohiordc.rr.com (ms-smtp-03.ohiordc.rr.com [65.24.5.137]) by mx1.freebsd.org (Postfix) with ESMTP id 803D613C46A for ; Fri, 15 Jun 2007 19:06:24 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from satellite (cpe-71-64-129-15.woh.res.rr.com [71.64.129.15]) by ms-smtp-03.ohiordc.rr.com (8.13.6/8.13.6) with SMTP id l5FI9xWQ017442 for ; Fri, 15 Jun 2007 14:10:00 -0400 (EDT) Message-ID: <000a01c7af78$636db920$0200a8c0@satellite> From: "Dave" To: References: <20070615072734.GC8093@obiwan.tataz.chchile.org> <20070615105950.GH3779@void.codelabs.ru> <4672D09B.9030100@incunabulum.net> Date: Fri, 15 Jun 2007 14:09:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Re: Firewalling NFS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2007 19:06:24 -0000 Hello, I also want to firewall an nfs server. The box that it's running on uses pf, it's a 6.2 box. I've got tcp port 2049 open, and am not sure what else to open or what other daemons to start. I'm also uncertain as to whether FreeBSD uses nfs v3 or v4? I want to export home directories to five or six different linux machines, some ubuntu and most centos5 and i remember vaguely reading about nfs v4. If anyone has this working i'd appreciate pointers. Thanks. Dave. ----- Original Message ----- From: "Bruce M. Simpson" To: "Eygene Ryabinkin" Cc: ; "Jeremie Le Hen" Sent: Friday, June 15, 2007 1:47 PM Subject: Re: Firewalling NFS > Eygene Ryabinkin wrote: >> NFSD binds to the port nfsd (2049) and for my -CURRENT both lockd >> and statd have '-p' options: >> ----- >> $ man rpc.lockd rpc.statd | grep -- -p >> rpc.lockd [-d debug_level] [-g grace period] [-p port] >> -p The -p option allow to force the daemon to bind to the >> specified >> rpc.statd [-d] [-p port] >> -p The -p option allow to force the daemon to bind to the >> specified >> ----- >> Are we talking about same entities? >> > > I added the -p switch to mountd(8) a few years ago, as I needed to run a > read-only NFS server exposed to the outside world; to firewall it I needed > a deterministic RPC port number, which is what -p gives you. Otherwise you > have to rely on the TCP wrapper support built into rpcbind(8). The > rpc.lockd and rpc.statd daemons were recently changed to incorporate this > switch too, although I don't think it has been backported to the 6-STABLE > branch yet. > > Regards, > BMS > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 20:01:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EFD516A469 for ; Fri, 15 Jun 2007 20:01:52 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (bavaria.utcluj.ro [193.226.5.35]) by mx1.freebsd.org (Postfix) with ESMTP id BA57513C4C5 for ; Fri, 15 Jun 2007 20:01:51 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 91CDE5083D for ; Fri, 15 Jun 2007 22:34:05 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on bavaria.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCSS+AW+XJeR for ; Fri, 15 Jun 2007 22:34:01 +0300 (EEST) Received: from intranet.utcluj.ro (localhost [IPv6:::1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 9433F50821 for ; Fri, 15 Jun 2007 22:34:01 +0300 (EEST) Received: from c7.campus.utcluj.ro ([193.226.6.226]) (SquirrelMail authenticated user cristiklein) by intranet.utcluj.ro with HTTP; Fri, 15 Jun 2007 22:34:01 +0300 (EEST) Message-ID: <57520.193.226.6.226.1181936041.squirrel@intranet.utcluj.ro> In-Reply-To: <20070615162738.GA21747@verio.net> References: <20070615104329.GF1173@turion.vk2pj.dyndns.org> <20070615162738.GA21747@verio.net> Date: Fri, 15 Jun 2007 22:34:01 +0300 (EEST) From: "Cristian KLEIN" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit Subject: Re: VLANs and routing 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, 15 Jun 2007 20:01:52 -0000 On Vin, Iunie 15, 2007 7:27 pm, David DeSimone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Peter Jeremy wrote: > >> >>> But the (somewhat weird) requirements are that the vlan interface on >>> machine1 shouldn't have assigned IP address, but the second one should. >>> >> [...] >> >>> Is this kind of setup even supported? >>> >> >> I don't see how it could be if machine1 is an IP endpoint: In order >> to transmit a packet, it needs to put a source IP address into the packet >> - which virtually always comes from the interface. >> > > When originating a packet, that is the case. But a forwarded packet > already has a source address, which can be left unchanged. As long as > routing is working (ARP is not needed, destination is clear, etc), the > intermediate interface need not have an IP. I completely agree with you. Theoretically speaking, you could inject something like (lladdr is not for real): side1# route add 192.168.2.0/24 -interface em0 -lladdr 00:10:ab:cd:ef:gh side2# route add 192.168.1.0/24 -interface em0 -lladdr 00:20:ab:cd:ef:gh And then you wouldn't require IPs on any interface. However, I haven't seen the ability to do something like this on any network stack, most probably, because in a layered approach (as networking is supposed to be) you shouldn't know, nor care what layer 2 does. Still, you could obtain something similar, by doing like this: side1# route add 192.168.2.0/24 -interface em0 side1# sysctl net.link.ether.inet.proxyall=1 side2# route add 192.168.1.0/24 -interface em0 side2# sysctl net.link.ether.inet.proxyall=1 This would tell both sides, that link-layer information for the destination network should be collected by using ARP. The other side will answer to this ARP request through the proxy-arp mechanism. If you don't want to enable proxy-arp, for reasons that you might discover in time, you may do the following: side1# route add 192.168.2.0/24 -interface em0 side1# arp -s 192.168.2.0 00:10:ab:cd:ef:gh side1# arp -s 192.168.2.1 00:10:ab:cd:ef:gh ... side1# arp -s 192.168.2.255 00:10:ab:cd:ef:gh Or, if you can afford using fake IPs: side1# route add 192.168.0.1/32 -interface em0 side1# arp -s 192.168.0.1 00:10:ab:cd:ef:gh side1# route add 192.168.2.0/24 192.168.0.1 In this setup, ping-ing 192.168.1.1 from 192.168.2.1 (assuming these are some IPs configured on some interface of the two routers) should work. Note that, in the configuration I suggested, network debugging (such as traceroute) might break. Make sure that you set net.inet.icmp.reply_src on both sides. From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 22:01:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3909816A46D for ; Fri, 15 Jun 2007 22:01:43 +0000 (UTC) (envelope-from ccowart@hal.rescomp.berkeley.edu) Received: from rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 263B513C4B9 for ; Fri, 15 Jun 2007 22:01:43 +0000 (UTC) (envelope-from ccowart@hal.rescomp.berkeley.edu) Received: by rescomp.berkeley.edu (Postfix, from userid 1225) id 0C3515B777; Fri, 15 Jun 2007 14:34:54 -0700 (PDT) Date: Fri, 15 Jun 2007 14:34:54 -0700 From: Christopher Cowart To: freebsd-net@freebsd.org Message-ID: <20070615213454.GE2335@rescomp.berkeley.edu> Mail-Followup-To: freebsd-net@freebsd.org, sysadmin@rescomp.berkeley.edu Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6e7ZaeXHKrTJCxdu" Content-Disposition: inline Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.9i Cc: sysadmin@rescomp.berkeley.edu Subject: Routing outbound IP packets on multihomed box 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, 15 Jun 2007 22:01:43 -0000 --6e7ZaeXHKrTJCxdu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I have a server with two NICs: em0: 169.229.79.139/25 vlan526: 169.229.126.9/24 The default gateway is 169.229.79.129. The router for the 126 subnet is 169.229.126.1.=20 netstat -rn: | Destination Gateway Flags Refs Use Netif Expire | default 169.229.79.129 UGS 0 102537 em0 | 127.0.0.1 127.0.0.1 UH 0 217 lo0 | 169.229.79.128/25 link#1 UC 0 0 em0 | 169.229.79.129 00:15:c7:b9:f4:80 UHLW 2 4 em0 1193 | 169.229.79.139 00:11:25:ab:42:70 UHLW 1 589 lo0 | 169.229.126/24 link#9 UC 0 0 vlan52 | 169.229.126.1 00:15:c7:b9:f4:80 UHLW 1 34 vlan52 1200 | 169.229.126.9 00:18:f8:09:d3:a5 UHLW 1 8 lo0 The IP address on em0 works exactly as one would expect. I have full IP connectivity to it from other subnets.=20 The problem is I can't get 2-way connectivity with the IP address on vlan526. Using my workstation on a third subnet (169.229.127.38/24), I cannot ping 169.229.126.9. I leave the ping running and do some tcpdumps on=20 the server. $ sudo tcpdump -ni vlan526 host 169.229.127.38 | 14:14:37.002920 IP 169.229.127.38 > 169.229.126.9: ICMP echo=20 | request, id 15733, seq 35, length 64 | 14:14:38.003037 IP 169.229.127.38 > 169.229.126.9: ICMP echo=20 | request, id 15733, seq 36, length 64 Notice there are no echo replies. That's because they're being sent=20 here: $ sudo tcpdump -ni em0 host 169.229.127.38 | 14:15:42.006997 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply,=20 | id 15733, seq 100, length 64 | 14:15:43.007118 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply,=20 | id 15733, seq 101, length 64 I repeated this last snoop with a -w and loaded it into ethereal. The echo replies being sent out on em0 indeed have a source address of 169.229.126.9. The router (169.229.79.139) drops these packets on the floor, because their source address isn't routable on that interface. Because routing is based on destination, not source address, I'm not sure how to get packets sourced from the 126 subnet to the router on the 126 subnet. I tried the following ipfw rule right after allow loopback traffic (my second rule): fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 Still no luck. Has anyone set up a multihomed box on *different* subnets before without routing them through the FreeBSD box? Does anyone have any pointers or things I should be looking at? Thanks, --=20 Chris Cowart Lead Systems Administrator Network Infrastructure, RSSP-IT UC Berkeley --6e7ZaeXHKrTJCxdu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFGcwX+V3SOqjnqPh0RAnJiAJsHhr1/gFx6suYATeMXTLcUtAMSOwCgnuyz 5BOD5j2DJULHsfeo3A/C5t0= =fE8r -----END PGP SIGNATURE----- --6e7ZaeXHKrTJCxdu-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 22:30:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75C4B16A468 for ; Fri, 15 Jun 2007 22:30:32 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2F00913C44C for ; Fri, 15 Jun 2007 22:30:31 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 50854 invoked from network); 15 Jun 2007 22:29:41 -0000 Received: from unknown (HELO ?128.238.242.16?) (spawk@128.238.242.16) by acm.poly.edu with AES256-SHA encrypted SMTP; 15 Jun 2007 22:29:41 -0000 Message-ID: <467312FF.5020506@acm.poly.edu> Date: Fri, 15 Jun 2007 18:30:23 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.0 (X11/20070609) MIME-Version: 1.0 To: freebsd-net@freebsd.org, sysadmin@rescomp.berkeley.edu References: <20070615213454.GE2335@rescomp.berkeley.edu> In-Reply-To: <20070615213454.GE2335@rescomp.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Routing outbound IP packets on multihomed box 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, 15 Jun 2007 22:30:32 -0000 Hi. I've come across this problem but solved it with a PF rule of this form, if that's an option for you: pass out route-to (vlan256 169.229.126.1) from 169.229.126.9 to any This tells PF to send all packets sent from 169.229.126.9 through the vlan256 interface with a next-hop address of 169.229.126.1. -Boris Christopher Cowart wrote: > Hello, > > I have a server with two NICs: > > em0: 169.229.79.139/25 > vlan526: 169.229.126.9/24 > > The default gateway is 169.229.79.129. The router for the 126 subnet is > 169.229.126.1. > > netstat -rn: > | Destination Gateway Flags Refs Use Netif Expire > | default 169.229.79.129 UGS 0 102537 em0 > | 127.0.0.1 127.0.0.1 UH 0 217 lo0 > | 169.229.79.128/25 link#1 UC 0 0 em0 > | 169.229.79.129 00:15:c7:b9:f4:80 UHLW 2 4 em0 1193 > | 169.229.79.139 00:11:25:ab:42:70 UHLW 1 589 lo0 > | 169.229.126/24 link#9 UC 0 0 vlan52 > | 169.229.126.1 00:15:c7:b9:f4:80 UHLW 1 34 vlan52 1200 > | 169.229.126.9 00:18:f8:09:d3:a5 UHLW 1 8 lo0 > > The IP address on em0 works exactly as one would expect. I have full IP > connectivity to it from other subnets. > > The problem is I can't get 2-way connectivity with the IP address on > vlan526. > > Using my workstation on a third subnet (169.229.127.38/24), I cannot > ping 169.229.126.9. I leave the ping running and do some tcpdumps on > the server. > > $ sudo tcpdump -ni vlan526 host 169.229.127.38 > | 14:14:37.002920 IP 169.229.127.38 > 169.229.126.9: ICMP echo > | request, id 15733, seq 35, length 64 > | 14:14:38.003037 IP 169.229.127.38 > 169.229.126.9: ICMP echo > | request, id 15733, seq 36, length 64 > > Notice there are no echo replies. That's because they're being sent > here: > > $ sudo tcpdump -ni em0 host 169.229.127.38 > | 14:15:42.006997 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply, > | id 15733, seq 100, length 64 > | 14:15:43.007118 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply, > | id 15733, seq 101, length 64 > > I repeated this last snoop with a -w and loaded it into ethereal. The > echo replies being sent out on em0 indeed have a source address of > 169.229.126.9. The router (169.229.79.139) drops these packets on the > floor, because their source address isn't routable on that interface. > > Because routing is based on destination, not source address, I'm not > sure how to get packets sourced from the 126 subnet to the router on the > 126 subnet. I tried the following ipfw rule right after allow loopback > traffic (my second rule): > > fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 > > Still no luck. Has anyone set up a multihomed box on *different* subnets > before without routing them through the FreeBSD box? Does anyone have > any pointers or things I should be looking at? > > Thanks, > > From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 23:12:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6503416A41F for ; Fri, 15 Jun 2007 23:12:56 +0000 (UTC) (envelope-from ccowart@hal.rescomp.berkeley.edu) Received: from rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF5C13C44C for ; Fri, 15 Jun 2007 23:12:56 +0000 (UTC) (envelope-from ccowart@hal.rescomp.berkeley.edu) Received: by rescomp.berkeley.edu (Postfix, from userid 1225) id 0483B5B772; Fri, 15 Jun 2007 16:12:55 -0700 (PDT) Date: Fri, 15 Jun 2007 16:12:55 -0700 From: Christopher Cowart To: Boris Kochergin Message-ID: <20070615231255.GG2335@rescomp.berkeley.edu> Mail-Followup-To: Boris Kochergin , freebsd-net@freebsd.org, sysadmin@rescomp.berkeley.edu References: <20070615213454.GE2335@rescomp.berkeley.edu> <467312FF.5020506@acm.poly.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9/eUdp+dLtKXvemk" Content-Disposition: inline In-Reply-To: <467312FF.5020506@acm.poly.edu> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, sysadmin@rescomp.berkeley.edu Subject: Re: Routing outbound IP packets on multihomed box 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, 15 Jun 2007 23:12:56 -0000 --9/eUdp+dLtKXvemk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 15, 2007 at 06:30:23PM -0400, Boris Kochergin wrote: > Christopher Cowart wrote: > >I have a server with two NICs: > > > >em0: 169.229.79.139/25 > >vlan526: 169.229.126.9/24 > > > >The default gateway is 169.229.79.129. The router for the 126 subnet is > >169.229.126.1.=20 > > > >netstat -rn: > >| Destination Gateway Flags Refs Use Netif=20 > >Expire > >| default 169.229.79.129 UGS 0 102537 em0 > >| 127.0.0.1 127.0.0.1 UH 0 217 lo0 > >| 169.229.79.128/25 link#1 UC 0 0 em0 > >| 169.229.79.129 00:15:c7:b9:f4:80 UHLW 2 4 em0 = =20 > >1193 > >| 169.229.79.139 00:11:25:ab:42:70 UHLW 1 589 lo0 > >| 169.229.126/24 link#9 UC 0 0 vlan52 > >| 169.229.126.1 00:15:c7:b9:f4:80 UHLW 1 34 vlan52 = =20 > >1200 > >| 169.229.126.9 00:18:f8:09:d3:a5 UHLW 1 8 lo0 > > > >The IP address on em0 works exactly as one would expect. I have full IP > >connectivity to it from other subnets.=20 > > > >The problem is I can't get 2-way connectivity with the IP address on > >vlan526. > > > >Using my workstation on a third subnet (169.229.127.38/24), I cannot > >ping 169.229.126.9. I leave the ping running and do some tcpdumps on=20 > >the server. > > > >$ sudo tcpdump -ni vlan526 host 169.229.127.38 > >| 14:14:37.002920 IP 169.229.127.38 > 169.229.126.9: ICMP echo=20 > >| request, id 15733, seq 35, length 64 > >| 14:14:38.003037 IP 169.229.127.38 > 169.229.126.9: ICMP echo=20 > >| request, id 15733, seq 36, length 64 > > > >Notice there are no echo replies. That's because they're being sent=20 > >here: > > > >$ sudo tcpdump -ni em0 host 169.229.127.38 > >| 14:15:42.006997 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply,=20 > >| id 15733, seq 100, length 64 > >| 14:15:43.007118 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply,=20 > >| id 15733, seq 101, length 64 > > > >I repeated this last snoop with a -w and loaded it into ethereal. The > >echo replies being sent out on em0 indeed have a source address of > >169.229.126.9. The router (169.229.79.139) drops these packets on the > >floor, because their source address isn't routable on that interface. > > > >Because routing is based on destination, not source address, I'm not > >sure how to get packets sourced from the 126 subnet to the router on the > >126 subnet. I tried the following ipfw rule right after allow loopback > >traffic (my second rule): > > > >fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 > > > >Still no luck. Has anyone set up a multihomed box on *different* subnets > >before without routing them through the FreeBSD box? Does anyone have > >any pointers or things I should be looking at? > > Hi. I've come across this problem but solved it with a PF rule of this=20 > form, if that's an option for you: >=20 > pass out route-to (vlan256 169.229.126.1) from 169.229.126.9 to any >=20 > This tells PF to send all packets sent from 169.229.126.9 through the=20 > vlan256 interface with a next-hop address of 169.229.126.1. Unfortunately, I don't think we can use pf. The rest of our infrastructure is ipfw and we don't particularly want this to be a one-off. I was under the impression that my ipfw rule did exactly this, by sending the packets to the 126 router as their next hop. Anyone have any ideas on whether an ipfw fwd rule can be used in a similar way to this pf rule? Thanks again, --=20 Chris Cowart Lead Systems Administrator Network Infrastructure, RSSP-IT UC Berkeley --9/eUdp+dLtKXvemk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFGcxz3V3SOqjnqPh0RAhjXAKCBz0FpDWPzX/ewWh30RwM+hzrEeQCcCWNy 93/IT3pv3Mz/PNHOGTOw18M= =SeGg -----END PGP SIGNATURE----- --9/eUdp+dLtKXvemk-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 00:27:30 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62AB916A41F for ; Sat, 16 Jun 2007 00:27:30 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from ms-smtp-07.ohiordc.rr.com (ms-smtp-07.ohiordc.rr.com [65.24.5.141]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF0413C4B0 for ; Sat, 16 Jun 2007 00:27:29 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from satellite (cpe-71-64-129-15.woh.res.rr.com [71.64.129.15]) by ms-smtp-07.ohiordc.rr.com (8.13.6/8.13.6) with SMTP id l5G0ROVS026532 for ; Fri, 15 Jun 2007 20:27:28 -0400 (EDT) Message-ID: <00a401c7afad$1f106680$0200a8c0@satellite> From: "Dave" To: References: <20070615072734.GC8093@obiwan.tataz.chchile.org> <20070615105950.GH3779@void.codelabs.ru> <4672D09B.9030100@incunabulum.net> Date: Fri, 15 Jun 2007 20:27:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Re: Firewalling NFS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 00:27:30 -0000 Hello, If anyone is interested i've got nfs going with a pf firewall on 6.2. I use a block by default policy and the client is a linux client, running it's iptables firewall, but it does work. I'm not sure about ipfw it's rule syntax but pf and i think ipf this should do it. The trick is udp and tcp 111, tcp 2049, and tcp 986 udp 669 those last two are so that mountd can be contacted. On the nfs server i have this in rc.conf: rpcbind_enable="YES" rpcbind_flags="-h 192.168.1.44" # i use jails on this box nfs_server_enable="YES" nfs_server_flags="-u -t -n 4 -h 192.168.1.44" # jails on this system mountd_flags="-r" and in my pf.conf file i have: pass in quick on $ext_if inet proto { tcp, udp } from to $ext_if port 111 flags S/SA keep state pass in quick on $ext_if inet proto tcp from to $ext_if port 2049 flags S/SA keep state pass in quick on $ext_if inet proto tcp from to $ext_if port 986 flags S/SA keep state pass in quick on $ext_if inet proto udp from to $ext_if port 669 keep state The only thing i'm not sure of is whether any of the ports will change if the box is rebooted, i've restarted the services several times and they hold the same ports. Hth Dave. ----- Original Message ----- From: "Bruce M. Simpson" To: "Eygene Ryabinkin" Cc: ; "Jeremie Le Hen" Sent: Friday, June 15, 2007 1:47 PM Subject: Re: Firewalling NFS > Eygene Ryabinkin wrote: >> NFSD binds to the port nfsd (2049) and for my -CURRENT both lockd >> and statd have '-p' options: >> ----- >> $ man rpc.lockd rpc.statd | grep -- -p >> rpc.lockd [-d debug_level] [-g grace period] [-p port] >> -p The -p option allow to force the daemon to bind to the >> specified >> rpc.statd [-d] [-p port] >> -p The -p option allow to force the daemon to bind to the >> specified >> ----- >> Are we talking about same entities? >> > > I added the -p switch to mountd(8) a few years ago, as I needed to run a > read-only NFS server exposed to the outside world; to firewall it I needed > a deterministic RPC port number, which is what -p gives you. Otherwise you > have to rely on the TCP wrapper support built into rpcbind(8). The > rpc.lockd and rpc.statd daemons were recently changed to incorporate this > switch too, although I don't think it has been backported to the 6-STABLE > branch yet. > > Regards, > BMS > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 00:35:36 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82D8C16A468 for ; Sat, 16 Jun 2007 00:35:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0B413C483 for ; Sat, 16 Jun 2007 00:35:36 +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.32) with ESMTP; Fri, 15 Jun 2007 17:35:36 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 91455125A2A; Fri, 15 Jun 2007 17:35:35 -0700 (PDT) Message-ID: <46733055.4080502@elischer.org> Date: Fri, 15 Jun 2007 17:35:33 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Boris Kochergin , freebsd-net@freebsd.org, sysadmin@rescomp.berkeley.edu References: <20070615213454.GE2335@rescomp.berkeley.edu> <467312FF.5020506@acm.poly.edu> <20070615231255.GG2335@rescomp.berkeley.edu> In-Reply-To: <20070615231255.GG2335@rescomp.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Routing outbound IP packets on multihomed box 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, 16 Jun 2007 00:35:36 -0000 Christopher Cowart wrote: > On Fri, Jun 15, 2007 at 06:30:23PM -0400, Boris Kochergin wrote: >> Christopher Cowart wrote: >>> I have a server with two NICs: >>> >>> em0: 169.229.79.139/25 >>> vlan526: 169.229.126.9/24 >>> >>> The default gateway is 169.229.79.129. The router for the 126 subnet is >>> 169.229.126.1. >>> >>> netstat -rn: >>> | Destination Gateway Flags Refs Use Netif >>> Expire >>> | default 169.229.79.129 UGS 0 102537 em0 >>> | 127.0.0.1 127.0.0.1 UH 0 217 lo0 >>> | 169.229.79.128/25 link#1 UC 0 0 em0 >>> | 169.229.79.129 00:15:c7:b9:f4:80 UHLW 2 4 em0 >>> 1193 >>> | 169.229.79.139 00:11:25:ab:42:70 UHLW 1 589 lo0 >>> | 169.229.126/24 link#9 UC 0 0 vlan52 >>> | 169.229.126.1 00:15:c7:b9:f4:80 UHLW 1 34 vlan52 >>> 1200 >>> | 169.229.126.9 00:18:f8:09:d3:a5 UHLW 1 8 lo0 >>> >>> The IP address on em0 works exactly as one would expect. I have full IP >>> connectivity to it from other subnets. >>> >>> The problem is I can't get 2-way connectivity with the IP address on >>> vlan526. >>> >>> Using my workstation on a third subnet (169.229.127.38/24), I cannot >>> ping 169.229.126.9. I leave the ping running and do some tcpdumps on >>> the server. >>> >>> $ sudo tcpdump -ni vlan526 host 169.229.127.38 >>> | 14:14:37.002920 IP 169.229.127.38 > 169.229.126.9: ICMP echo >>> | request, id 15733, seq 35, length 64 >>> | 14:14:38.003037 IP 169.229.127.38 > 169.229.126.9: ICMP echo >>> | request, id 15733, seq 36, length 64 >>> >>> Notice there are no echo replies. That's because they're being sent >>> here: >>> >>> $ sudo tcpdump -ni em0 host 169.229.127.38 >>> | 14:15:42.006997 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply, >>> | id 15733, seq 100, length 64 >>> | 14:15:43.007118 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply, >>> | id 15733, seq 101, length 64 >>> >>> I repeated this last snoop with a -w and loaded it into ethereal. The >>> echo replies being sent out on em0 indeed have a source address of >>> 169.229.126.9. The router (169.229.79.139) drops these packets on the >>> floor, because their source address isn't routable on that interface. >>> >>> Because routing is based on destination, not source address, I'm not >>> sure how to get packets sourced from the 126 subnet to the router on the >>> 126 subnet. I tried the following ipfw rule right after allow loopback >>> traffic (my second rule): >>> >>> fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 >>> >>> Still no luck. Has anyone set up a multihomed box on *different* subnets >>> before without routing them through the FreeBSD box? Does anyone have >>> any pointers or things I should be looking at? >> Hi. I've come across this problem but solved it with a PF rule of this >> form, if that's an option for you: >> >> pass out route-to (vlan256 169.229.126.1) from 169.229.126.9 to any >> >> This tells PF to send all packets sent from 169.229.126.9 through the >> vlan256 interface with a next-hop address of 169.229.126.1. > > Unfortunately, I don't think we can use pf. The rest of our > infrastructure is ipfw and we don't particularly want this to be a > one-off. I was under the impression that my ipfw rule did exactly this, > by sending the packets to the 126 router as their next hop. > > Anyone have any ideas on whether an ipfw fwd rule can be used in a > similar way to this pf rule? > > Thanks again, > he ipfw rule should work, assuming you have the IPFIREWALL_FORWARDING option (and it's not the couple of versions of the OS where you also needed the IPFIREWALL_FORWARD_EXTENDED option as well.. also, you need to make it an 'out' rule..i.e. fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 out From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 00:47:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D629216A469 for ; Sat, 16 Jun 2007 00:47:59 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from scarlett.lon.rewt.org.uk (scarlett.lon.rewt.org.uk [62.84.188.34]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5B313C465 for ; Sat, 16 Jun 2007 00:47:59 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from [192.168.10.230] (unknown [78.86.5.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by scarlett.lon.rewt.org.uk (Postfix) with ESMTP id 02E1539848; Sat, 16 Jun 2007 01:28:45 +0100 (BST) Message-ID: <46732E7E.908@joeholden.co.uk> Date: Sat, 16 Jun 2007 01:27:42 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Boris Kochergin , freebsd-net@freebsd.org, sysadmin@rescomp.berkeley.edu References: <20070615213454.GE2335@rescomp.berkeley.edu> <467312FF.5020506@acm.poly.edu> <20070615231255.GG2335@rescomp.berkeley.edu> In-Reply-To: <20070615231255.GG2335@rescomp.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Routing outbound IP packets on multihomed box 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, 16 Jun 2007 00:47:59 -0000 Christopher Cowart wrote: > On Fri, Jun 15, 2007 at 06:30:23PM -0400, Boris Kochergin wrote: >> Christopher Cowart wrote: >>> I have a server with two NICs: >>> >>> em0: 169.229.79.139/25 >>> vlan526: 169.229.126.9/24 >>> >>> The default gateway is 169.229.79.129. The router for the 126 subnet is >>> 169.229.126.1. >>> >>> netstat -rn: >>> | Destination Gateway Flags Refs Use Netif >>> Expire >>> | default 169.229.79.129 UGS 0 102537 em0 >>> | 127.0.0.1 127.0.0.1 UH 0 217 lo0 >>> | 169.229.79.128/25 link#1 UC 0 0 em0 >>> | 169.229.79.129 00:15:c7:b9:f4:80 UHLW 2 4 em0 >>> 1193 >>> | 169.229.79.139 00:11:25:ab:42:70 UHLW 1 589 lo0 >>> | 169.229.126/24 link#9 UC 0 0 vlan52 >>> | 169.229.126.1 00:15:c7:b9:f4:80 UHLW 1 34 vlan52 >>> 1200 >>> | 169.229.126.9 00:18:f8:09:d3:a5 UHLW 1 8 lo0 >>> >> pass out route-to (vlan256 169.229.126.1) from 169.229.126.9 to any >> >> This tells PF to send all packets sent from 169.229.126.9 through the >> vlan256 interface with a next-hop address of 169.229.126.1. > > Unfortunately, I don't think we can use pf. The rest of our > infrastructure is ipfw and we don't particularly want this to be a > one-off. I was under the impression that my ipfw rule did exactly this, > by sending the packets to the 126 router as their next hop. > > Anyone have any ideas on whether an ipfw fwd rule can be used in a > similar way to this pf rule? > Yes, ipfw fwd will work fine, you'll need to route based on the source ip addresses. For exmaple: ipfw add 1 fwd all from to any ipfw add 2 fwd all from to any That *should* work, been a long time since i've touched ipfw. -- Joe Holden T: (UK) 02071009593 (AU) 282442321 E: joe@joeholden.co.uk From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 01:25:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3341416A46F for ; Sat, 16 Jun 2007 01:25:56 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id B01B813C455 for ; Sat, 16 Jun 2007 01:25:55 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HzN2u-0002eM-H5 for freebsd-net@freebsd.org; Sat, 16 Jun 2007 03:25:44 +0200 Received: from 89-172-49-214.adsl.net.t-com.hr ([89.172.49.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jun 2007 03:25:44 +0200 Received: from ivoras by 89-172-49-214.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jun 2007 03:25:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sat, 16 Jun 2007 03:25:20 +0200 Lines: 66 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6C28D908E86D25133190FA18" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-49-214.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Quickly creating VLANs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 01:25:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6C28D908E86D25133190FA18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I have a problem I can demonstrate and reproduce with the following scrip= t: ---- #!/bin/sh ifconfig vlan600 destroy ifconfig vlan600 create ifconfig vlan600 vlan 600 vlandev fxp1 ifconfig vlan600 inet 10.20.0.1 netmask 255.255.255.0 ifconfig vlan601 destroy ifconfig vlan601 create ifconfig vlan601 vlan 601 vlandev fxp1 ifconfig vlan601 inet 10.21.0.5/29 ---- The addresses don't matter. The problem is that the IP address is "lost" - it's not assigned to the vlan devices: # ifconfig vlan600 vlan600: flags=3D8842 mtu 1500 ether 00:07:e9:d4:2b:39 media: Ethernet autoselect (100baseTX ) status: active vlan: 600 parent interface: fxp1 # ifconfig vlan601 vlan601: flags=3D8842 mtu 1500 ether 00:07:e9:d4:2b:39 media: Ethernet autoselect (100baseTX ) status: active vlan: 601 parent interface: fxp1 If I insert "sleep 1" before IP gets assigned, it works, so it seems like there's a timing issue. The machine already has about 100 vlan devices, so it may happen only when there are lots of then. Leaving "sleep 1" is not an option since the entire thing would take 100 s to complete. I can reproduce this 100% on two different machines running 6.2-RELEASE, also with different NICs. Does someone else feel this effect? --------------enig6C28D908E86D25133190FA18 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGczwGldnAQVacBcgRAmxdAKClGDU4alNiCX6MyM0EY82AcZkCgwCg8U8C 9X6swwaD52Bp5hDgBAy562w= =sTL0 -----END PGP SIGNATURE----- --------------enig6C28D908E86D25133190FA18-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 01:36:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0191016A41F for ; Sat, 16 Jun 2007 01:36:51 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id AC2D213C448 for ; Sat, 16 Jun 2007 01:36:50 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HzNDa-0004Nd-EZ for freebsd-net@freebsd.org; Sat, 16 Jun 2007 03:36:46 +0200 Received: from 89-172-49-214.adsl.net.t-com.hr ([89.172.49.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jun 2007 03:36:46 +0200 Received: from ivoras by 89-172-49-214.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jun 2007 03:36:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sat, 16 Jun 2007 03:36:23 +0200 Lines: 31 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDCA8A678D1CE6EB49E21838D" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-49-214.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: Quickly creating VLANs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 01:36:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDCA8A678D1CE6EB49E21838D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > If I insert "sleep 1" before IP gets assigned, it works, so it seems > like there's a timing issue. More data: changing the sleep command to "sleep 0.1" instead makes some of the interfaces correctly configured and some are "lost" again. With 0.2 seconds, it seems that so far all are configured. But I don't trust i= t. --------------enigDCA8A678D1CE6EB49E21838D 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcz6XldnAQVacBcgRAveEAJ9SptQXMgCY4Gn4wJZxTh4KoPGCTQCg8R/Y cXrm17lt98bgncG2jBp28tA= =TaWR -----END PGP SIGNATURE----- --------------enigDCA8A678D1CE6EB49E21838D-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 01:58:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 521A416A400 for ; Sat, 16 Jun 2007 01:58:31 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id DECD213C4C4 for ; Sat, 16 Jun 2007 01:58:30 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.21.157] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1HzNMQ2pJr-0008AL; Sat, 16 Jun 2007 03:45:55 +0200 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Sat, 16 Jun 2007 03:47:24 +0200 User-Agent: KMail/1.9.6 X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. X-Provags-ID: V01U2FsdGVkX1+5/kohqPo8zXyDhvD3j1C3PK0NDjzvQkn2zGM tdWmD89gZppLMhs9e67Rpk919fJAJ7KVfDxVp6tn5NgBIR111M WAEerUYI8DWmcAyegodyQ== Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: pf 4.1 Update available for testing 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, 16 Jun 2007 01:58:31 -0000 --nextPart2912810.rfjCpjmcA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, $subject at: http://people.freebsd.org/~mlaier/PF41/ As of today (20070616) I consider this to be BETA quality (at least). =20 Please test and provide me (and freebsd-pf@) with feedback (good or=20 else). If things work out well, I plan to commit this soon. To make testing easier I'm working on RELENG_6 patches as well, but it=20 will be a bit to get through the fix/build/repeat-cycles. Note that almost every API/ABI changed (as usual in OpenBSD-land) and thus= =20 you need to compile world, remove your old pflogd files. Also note that=20 the pfsync protocol has changed and thus you won't be able to sync an old=20 and a new box. It should be possible to sync with a OpenBSD 4.1 box,=20 however. Enjoy and report back! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2912810.rfjCpjmcA6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (FreeBSD) iD8DBQBGc0E1XyyEoT62BG0RAi4eAJ47w8LHWoAKrD1J1tyIISscaos7cgCeKyzx rYXNq4b4i2oMLyZ2+0XXppI= =Tva/ -----END PGP SIGNATURE----- --nextPart2912810.rfjCpjmcA6-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 02:06:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD98C16A469 for ; Sat, 16 Jun 2007 02:06:50 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from ms-smtp-04.ohiordc.rr.com (ms-smtp-04.ohiordc.rr.com [65.24.5.138]) by mx1.freebsd.org (Postfix) with ESMTP id 5DAC413C447 for ; Sat, 16 Jun 2007 02:06:50 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from satellite (cpe-71-64-129-15.woh.res.rr.com [71.64.129.15]) by ms-smtp-04.ohiordc.rr.com (8.13.6/8.13.6) with SMTP id l5G26mpw019032 for ; Fri, 15 Jun 2007 22:06:49 -0400 (EDT) Message-ID: <000301c7afba$ffa48b60$0200a8c0@satellite> From: "Dave" To: Date: Fri, 15 Jun 2007 22:06:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: freebsd nfs version4 server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 02:06:50 -0000 Hello, Firewalling nfs i was reading some client docs and i found out that FreeBSD has client support for the nfs v4. I was wondering if FreeBSD 6.2 could act as an nfs v4 server? Thanks. Dave. From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 04:34:27 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEB4C16A400 for ; Sat, 16 Jun 2007 04:34:27 +0000 (UTC) (envelope-from ccowart@hal.rescomp.berkeley.edu) Received: from rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id B4C1C13C484 for ; Sat, 16 Jun 2007 04:34:27 +0000 (UTC) (envelope-from ccowart@hal.rescomp.berkeley.edu) Received: by rescomp.berkeley.edu (Postfix, from userid 1225) id BCBEB5B774; Fri, 15 Jun 2007 21:34:25 -0700 (PDT) Date: Fri, 15 Jun 2007 21:34:25 -0700 From: Christopher Cowart To: Julian Elischer Message-ID: <20070616043425.GH2335@rescomp.berkeley.edu> Mail-Followup-To: Julian Elischer , sysadmin@rescomp.berkeley.edu, freebsd-net@freebsd.org References: <20070615213454.GE2335@rescomp.berkeley.edu> <467312FF.5020506@acm.poly.edu> <20070615231255.GG2335@rescomp.berkeley.edu> <46733055.4080502@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9ZOS6odDaRI+0hI" Content-Disposition: inline In-Reply-To: <46733055.4080502@elischer.org> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, sysadmin@rescomp.berkeley.edu Subject: Re: Routing outbound IP packets on multihomed box 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, 16 Jun 2007 04:34:27 -0000 --/9ZOS6odDaRI+0hI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 15, 2007 at 05:35:33PM -0700, Julian Elischer wrote: > Christopher Cowart wrote: > >On Fri, Jun 15, 2007 at 06:30:23PM -0400, Boris Kochergin wrote: > >>Christopher Cowart wrote: > >>>I have a server with two NICs: > >>> > >>>em0: 169.229.79.139/25 > >>>vlan526: 169.229.126.9/24 > >>> > >>>The default gateway is 169.229.79.129. The router for the 126 subnet is > >>>169.229.126.1.=20 > >>> > >>>netstat -rn: > >>>| Destination Gateway Flags Refs Use Netif= =20 > >>>Expire > >>>| default 169.229.79.129 UGS 0 102537 em0 > >>>| 127.0.0.1 127.0.0.1 UH 0 217 lo0 > >>>| 169.229.79.128/25 link#1 UC 0 0 em0 > >>>| 169.229.79.129 00:15:c7:b9:f4:80 UHLW 2 4 em0 = =20 > >>>1193 > >>>| 169.229.79.139 00:11:25:ab:42:70 UHLW 1 589 lo0 > >>>| 169.229.126/24 link#9 UC 0 0 vlan52 > >>>| 169.229.126.1 00:15:c7:b9:f4:80 UHLW 1 34 vlan52 = =20 > >>>1200 > >>>| 169.229.126.9 00:18:f8:09:d3:a5 UHLW 1 8 lo0 > >>> > >>>The IP address on em0 works exactly as one would expect. I have full IP > >>>connectivity to it from other subnets.=20 > >>> > >>>The problem is I can't get 2-way connectivity with the IP address on > >>>vlan526. > >>> > >>>Using my workstation on a third subnet (169.229.127.38/24), I cannot > >>>ping 169.229.126.9. I leave the ping running and do some tcpdumps on= =20 > >>>the server. > >>> > >>>$ sudo tcpdump -ni vlan526 host 169.229.127.38 > >>>| 14:14:37.002920 IP 169.229.127.38 > 169.229.126.9: ICMP echo=20 > >>>| request, id 15733, seq 35, length 64 > >>>| 14:14:38.003037 IP 169.229.127.38 > 169.229.126.9: ICMP echo=20 > >>>| request, id 15733, seq 36, length 64 > >>> > >>>Notice there are no echo replies. That's because they're being sent=20 > >>>here: > >>> > >>>$ sudo tcpdump -ni em0 host 169.229.127.38 > >>>| 14:15:42.006997 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply,= =20 > >>>| id 15733, seq 100, length 64 > >>>| 14:15:43.007118 IP 169.229.126.9 > 169.229.127.38: ICMP echo reply,= =20 > >>>| id 15733, seq 101, length 64 > >>> > >>>I repeated this last snoop with a -w and loaded it into ethereal. The > >>>echo replies being sent out on em0 indeed have a source address of > >>>169.229.126.9. The router (169.229.79.139) drops these packets on the > >>>floor, because their source address isn't routable on that interface. > >>> > >>>Because routing is based on destination, not source address, I'm not > >>>sure how to get packets sourced from the 126 subnet to the router on t= he > >>>126 subnet. I tried the following ipfw rule right after allow loopback > >>>traffic (my second rule): > >>> > >>>fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 > >>> > >>>Still no luck. Has anyone set up a multihomed box on *different* subne= ts > >>>before without routing them through the FreeBSD box? Does anyone have > >>>any pointers or things I should be looking at? > >>Hi. I've come across this problem but solved it with a PF rule of this= =20 > >>form, if that's an option for you: > >> > >>pass out route-to (vlan256 169.229.126.1) from 169.229.126.9 to any > >> > >>This tells PF to send all packets sent from 169.229.126.9 through the= =20 > >>vlan256 interface with a next-hop address of 169.229.126.1. > > > >Unfortunately, I don't think we can use pf. The rest of our > >infrastructure is ipfw and we don't particularly want this to be a > >one-off. I was under the impression that my ipfw rule did exactly this, > >by sending the packets to the 126 router as their next hop. > > > >Anyone have any ideas on whether an ipfw fwd rule can be used in a > >similar way to this pf rule? > > > >Thanks again, > > > he ipfw rule should work, assuming you have the IPFIREWALL_FORWARDING opt= ion > (and it's not the couple of versions of the OS where you also needed the > IPFIREWALL_FORWARD_EXTENDED option as well.. I had forwarding enabled, but not the EXTENDED flag. Apparently bypassing the routing table in the firewall is an "unsafe" practice. Now I can source traffic from the vlan526 interface correctly. Thanks! > also, you need to make it an 'out' rule..i.e.=20 > fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 out This doesn't appear to be necessary... The next step, and here I'm having more problems, is I want to NAT traffic using the vlan526 interface. Using the same configuration as above, I've added: vlan80: 10.80.1.1/16 When a NAT'd client pings off the 126 subnet (say, 169.229.127.38),=20 the packets go out em0 again. My ipfw ruleset looks like this: allow all from any to any via lo0 divert natd ip from not me to any via 169.229.126.9 fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 allow icmp from any to any My understanding of divert is that after natd munges the packets, they'll return to the ipfw rules immediately following rule 13. In this case, traffic appearing from the NAT ip address should be forwarded to the 126 router on the next-hop. When I do `tcpdump -ni em0 host 169.229.127.38`, I notice the outbound ICMP echo requests have src-addr of 10.80.x.x (IP address of the nat'd client). Does this mean that as ipfw continues processing the packet, even after natd has munged it, that as far as ipfw is concerned, the src-addr of the packet hasn't changed? In other words, would I need to write a complicated set of rules that do something like: divert natd ip from not me to any via 169.229.126.9 fwd 169.229.126.1 ip from 169.229.126.9 to not 169.229.126.0/24 fwd 169.229.126.1 ip from 10.80.0.0/16 to not 169.229.126.0/24 Any recommendations on how to solve the NATing extension of this routing problem? Thanks again, --=20 Chris Cowart Lead Systems Administrator Network Infrastructure, RSSP-IT UC Berkeley --/9ZOS6odDaRI+0hI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFGc2hRV3SOqjnqPh0RAgufAJ97WylzqEY5HMvZ3la1p7s9+WTXLwCeJ1A1 Qp8mVkdI211eFHaPPFmy1YQ= =sDVU -----END PGP SIGNATURE----- --/9ZOS6odDaRI+0hI-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 05:40:40 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EB7B16A400 for ; Sat, 16 Jun 2007 05:40:40 +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 F1A9713C45A for ; Sat, 16 Jun 2007 05:40:39 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 134131A4D8B; Fri, 15 Jun 2007 22:40:05 -0700 (PDT) Date: Fri, 15 Jun 2007 22:40:05 -0700 From: Alfred Perlstein To: Jeremie Le Hen Message-ID: <20070616054005.GU96936@elvis.mu.org> References: <20070615072734.GC8093@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070615072734.GC8093@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.2i Cc: freebsd-net@FreeBSD.org Subject: Re: Firewalling NFS 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, 16 Jun 2007 05:40:40 -0000 * Jeremie Le Hen [070615 01:07] wrote: > Hi, > > It appears nearly impossible to firewall a NFS server on FreeBSD. I would be nearly impossible if one didn't know much about NFS. Care to rephrase your assertion? > The reason is that NFS related daemons use RPC, which means they > don't bind to a deterministic port. Only mountd(8) can be requested to > bind to a specific port or fail with the -p command-line switch. > Is there any reason other than "no one has needed this yet" why this > option is not available for nfsd(8), rpc.lockd(8) and rpc.statd(8)? this is wrong, wrong and more wrong. -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 05:42:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E462216A468 for ; Sat, 16 Jun 2007 05:42: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 D3FCA13C45D for ; Sat, 16 Jun 2007 05:42:05 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 055F61A4D8D; Fri, 15 Jun 2007 22:41:31 -0700 (PDT) Date: Fri, 15 Jun 2007 22:41:30 -0700 From: Alfred Perlstein To: Dave Message-ID: <20070616054130.GV96936@elvis.mu.org> References: <000301c7afba$ffa48b60$0200a8c0@satellite> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000301c7afba$ffa48b60$0200a8c0@satellite> User-Agent: Mutt/1.4.2.2i Cc: freebsd-net@freebsd.org Subject: Re: freebsd nfs version4 server 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, 16 Jun 2007 05:42:06 -0000 * Dave [070615 19:06] wrote: > Hello, > Firewalling nfs i was reading some client docs and i found out that > FreeBSD has client support for the nfs v4. I was wondering if FreeBSD 6.2 > could act as an nfs v4 server? There's a patchset from Rick Maclem(sp?) that might do it. -Alfred From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 06:37:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 396AD16A41F for ; Sat, 16 Jun 2007 06:37:32 +0000 (UTC) (envelope-from bsdprakash@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.235]) by mx1.freebsd.org (Postfix) with ESMTP id EA87213C45A for ; Sat, 16 Jun 2007 06:37:31 +0000 (UTC) (envelope-from bsdprakash@gmail.com) Received: by qb-out-0506.google.com with SMTP id b14so1357783qbc for ; Fri, 15 Jun 2007 23:37:31 -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=W+8u/tLhojNC5ld4q3BBDiRzTwxKzVhInfNpzXUhu2W+U1kTSojNLwVG9HSwmiU1QMOBPBd94azch4t8lipN4Ehz2c4x5f6hz9KIT2PhLMqgOOF1iffpNws9zPO9DJgjMj4FM+IefPU4PjuXYbaKOpA261jOkQExkwUEriYUPEo= 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=XSAK31wYJ5FA2IQKEI5JADbbrHdQtP3wpxsV3+YRhC3wrkinDF+s1uRGKtOu0kstqZu6SFhZetovo+4gfviChrNQlThRUG7GgLQWMRbGKdVwHBhaJNOD653HZa9oJbnWY324vdhsPHWpP0BrPl6/JUf9MliuIo5lE9WCUhNsZks= Received: by 10.143.1.2 with SMTP id d2mr198166wfi.1181974874313; Fri, 15 Jun 2007 23:21:14 -0700 (PDT) Received: by 10.143.12.9 with HTTP; Fri, 15 Jun 2007 23:21:14 -0700 (PDT) Message-ID: <1428d0e80706152321u70b5c842jd3b09341dcc717b2@mail.gmail.com> Date: Sat, 16 Jun 2007 12:06:14 +0545 From: "Prakash Poudyal" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: How to make freebsd updater like cvsup 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, 16 Jun 2007 06:37:32 -0000 Hello everybody, I have 5 freebsd server in my system. I want to update freebsd from cvsup in only one server and remaining 4 server from the server where it was updated from cvsup. So please can you tell me how to do this process or I am waiting for your suggesstion or what you recommend to do it. you know I donot want to do update each and every server from cvsup. Thank you Waiting from your response From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 10:09:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 301BB16A41F for ; Sat, 16 Jun 2007 10:09:42 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (aberdeen.thelostparadise.com [193.202.115.174]) by mx1.freebsd.org (Postfix) with ESMTP id EE56F13C44C for ; Sat, 16 Jun 2007 10:09:41 +0000 (UTC) (envelope-from pieter@thedarkside.nl) Received: from [192.168.1.10] (s55915f73.adsl.wanadoo.nl [85.145.95.115]) by mail.thelostparadise.com (Postfix) with ESMTP id 15E5761C22; Sat, 16 Jun 2007 11:46:20 +0200 (CEST) Message-ID: <4673B170.9020005@thedarkside.nl> Date: Sat, 16 Jun 2007 11:46:24 +0200 From: Pieter de Boer User-Agent: Thunderbird 1.5.0.9 (X11/20061228) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Quickly creating VLANs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 10:09:42 -0000 Ivan Voras wrote: > ifconfig vlan600 destroy > ifconfig vlan600 create > ifconfig vlan600 vlan 600 vlandev fxp1 > ifconfig vlan600 inet 10.20.0.1 netmask 255.255.255.0 Try ifconfig vlan600 create vlan 600 vlandev fxp1 10.20.0.1/24 -- Pieter From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 10:25:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 333A916A400 for ; Sat, 16 Jun 2007 10:25:08 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id DD26113C44B for ; Sat, 16 Jun 2007 10:25:07 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HzVSo-00085e-Fb for freebsd-net@freebsd.org; Sat, 16 Jun 2007 12:25:02 +0200 Received: from 78-1-114-116.adsl.net.t-com.hr ([78.1.114.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jun 2007 12:25:02 +0200 Received: from ivoras by 78-1-114-116.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jun 2007 12:25:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sat, 16 Jun 2007 12:23:10 +0200 Lines: 32 Message-ID: References: <1428d0e80706152321u70b5c842jd3b09341dcc717b2@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBFEFA32A61491B779A7F19DA" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-114-116.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) In-Reply-To: <1428d0e80706152321u70b5c842jd3b09341dcc717b2@mail.gmail.com> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: How to make freebsd updater like cvsup 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, 16 Jun 2007 10:25:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBFEFA32A61491B779A7F19DA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Prakash Poudyal wrote: > Hello everybody, >=20 > I have 5 freebsd server in my system. I want to update freebsd from > cvsup in > only one server and remaining 4 server from the server where it was > updated > from cvsup.=20 The easiest way is just to export the updated src tree via NFS. --------------enigBFEFA32A61491B779A7F19DA 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGc7oOldnAQVacBcgRAvCnAKD1oiFP3RlpAnX9C7ZZAXYHV/FUNwCg/eeK vygtNaIa9kl+Yj1KE5q7KwQ= =Cq0U -----END PGP SIGNATURE----- --------------enigBFEFA32A61491B779A7F19DA-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 10:29:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2495F16A468 for ; Sat, 16 Jun 2007 10:29:47 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 83FC113C458 for ; Sat, 16 Jun 2007 10:29:45 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l5GATfY3096731; Sat, 16 Jun 2007 18:29:41 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l5GATf9h096730; Sat, 16 Jun 2007 18:29:41 +0800 (KRAST) (envelope-from eugen) Date: Sat, 16 Jun 2007 18:29:41 +0800 From: Eugene Grosbein To: Prakash Poudyal Message-ID: <20070616102941.GA96610@svzserv.kemerovo.su> References: <1428d0e80706152321u70b5c842jd3b09341dcc717b2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1428d0e80706152321u70b5c842jd3b09341dcc717b2@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: How to make freebsd updater like cvsup 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, 16 Jun 2007 10:29:47 -0000 On Sat, Jun 16, 2007 at 12:06:14PM +0545, Prakash Poudyal wrote: > I have 5 freebsd server in my system. I want to update freebsd from cvsup in > only one server and remaining 4 server from the server where it was updated > from cvsup. So please can you tell me how to do this process or I am waiting > for your suggesstion or what you recommend to do it. you know I donot want > to do update each and every server from cvsup. Thank you > Waiting from your response Just deliver updated /usr/src to remaining servers using tar or NFS mount. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 11:06:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD4A916A41F for ; Sat, 16 Jun 2007 11:06:48 +0000 (UTC) (envelope-from bsdprakash@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9E313C455 for ; Sat, 16 Jun 2007 11:06:48 +0000 (UTC) (envelope-from bsdprakash@gmail.com) Received: by nz-out-0506.google.com with SMTP id 14so976509nzn for ; Sat, 16 Jun 2007 04:06:47 -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; b=QvS44dSAnx1NfshFOMdh+SjhKiIzc1QmdR5BYfOsJV6Ewx/mW7zMmandiSEOhwMSSY7X8v9kwRqYE8LjqUTaI3DCSMu+9vOPqe0/n4jFDBKAistkEo9CeeXFzLYz0ScghyMpzL+caqTklnG9snAnSC6UDBPZa0mvK3g6YRPOIiE= 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; b=WJk1+aG576E7ftsFKPhvz43fwvfONAmmqPnIHOwhqrHoYuSTJJ8WOt8e39MNr8DqGMhg2mP/TXzq02A0QWIL99yjT4ZR5VTjYTyv4mtncAtbal7bIy4FNw9fu43mh6K/SkVR5bMZPpqlZi8WC3TntV3dgegIj3h4VjAxqjnv05U= Received: by 10.142.110.3 with SMTP id i3mr202942wfc.1181992006941; Sat, 16 Jun 2007 04:06:46 -0700 (PDT) Received: by 10.143.12.9 with HTTP; Sat, 16 Jun 2007 04:06:46 -0700 (PDT) Message-ID: <1428d0e80706160406v1a42c78ay9f1c0223890d2351@mail.gmail.com> Date: Sat, 16 Jun 2007 16:51:46 +0545 From: "Prakash Poudyal" To: "Eugene Grosbein" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: the file /usr/src would be sufficent for updateing the freebsd content 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, 16 Jun 2007 11:06:48 -0000 On 6/16/07, Prakash Poudyal wrote: > > Dear Eugene > > Thank you for your response would that be sufficent you know I do have > various hardware infrastructure in the freebsd server like two servers are > of IBM server and remaing other are of different hardware compatiblites. so > would that be sufficent by copying the /usr/src to other remaining server. > > waiting for the response > > Thanks > > Prakash > > On 6/16/07, Eugene Grosbein wrote: > > > > On Sat, Jun 16, 2007 at 12:06:14PM +0545, Prakash Poudyal wrote: > > > > > I have 5 freebsd server in my system. I want to update freebsd from > > cvsup in > > > only one server and remaining 4 server from the server where it was > > updated > > > from cvsup. So please can you tell me how to do this process or I am > > waiting > > > for your suggesstion or what you recommend to do it. you know I donot > > want > > > to do update each and every server from cvsup. Thank you > > > Waiting from your response > > > > Just deliver updated /usr/src to remaining servers using tar or NFS > > mount. > > > > Eugene Grosbein > > > > From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 14:55:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A57DB16A468; Sat, 16 Jun 2007 14:55:56 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from ms-smtp-05.ohiordc.rr.com (ms-smtp-05.ohiordc.rr.com [65.24.5.139]) by mx1.freebsd.org (Postfix) with ESMTP id 6BA1013C46C; Sat, 16 Jun 2007 14:55:56 +0000 (UTC) (envelope-from dmehler26@woh.rr.com) Received: from satellite (cpe-71-64-129-15.woh.res.rr.com [71.64.129.15]) by ms-smtp-05.ohiordc.rr.com (8.13.6/8.13.6) with SMTP id l5GEtstm006253; Sat, 16 Jun 2007 10:55:55 -0400 (EDT) Message-ID: <000301c7b026$70d87bf0$0200a8c0@satellite> From: "Dave" To: "Alfred Perlstein" References: <000301c7afba$ffa48b60$0200a8c0@satellite> <20070616054130.GV96936@elvis.mu.org> Date: Sat, 16 Jun 2007 10:55:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-net@freebsd.org Subject: Re: freebsd nfs version4 server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 14:55:56 -0000 Hi, Thanks for your reply. Do you know how far along this patch is or any configs needed to pull this off? Thanks. Dave. ----- Original Message ----- From: "Alfred Perlstein" To: "Dave" Cc: Sent: Saturday, June 16, 2007 1:41 AM Subject: Re: freebsd nfs version4 server >* Dave [070615 19:06] wrote: >> Hello, >> Firewalling nfs i was reading some client docs and i found out that >> FreeBSD has client support for the nfs v4. I was wondering if FreeBSD 6.2 >> could act as an nfs v4 server? > > There's a patchset from Rick Maclem(sp?) that might do it. > > -Alfred From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 20:10:15 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9007D16A469; Sat, 16 Jun 2007 20:10:15 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 2189713C46C; Sat, 16 Jun 2007 20:10:15 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 5B80E44D06; Sat, 16 Jun 2007 22:10:14 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 091049B497; Sat, 16 Jun 2007 20:09:57 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id EC571405B; Sat, 16 Jun 2007 22:09:56 +0200 (CEST) Date: Sat, 16 Jun 2007 22:09:56 +0200 From: Jeremie Le Hen To: Alfred Perlstein Message-ID: <20070616200956.GA63387@obiwan.tataz.chchile.org> References: <20070615072734.GC8093@obiwan.tataz.chchile.org> <20070616054005.GU96936@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070616054005.GU96936@elvis.mu.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-net@FreeBSD.org Subject: Re: Firewalling NFS 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, 16 Jun 2007 20:10:15 -0000 Hi Alfred, On Fri, Jun 15, 2007 at 10:40:05PM -0700, Alfred Perlstein wrote: > * Jeremie Le Hen [070615 01:07] wrote: > > Hi, > > > > It appears nearly impossible to firewall a NFS server on FreeBSD. > > I would be nearly impossible if one didn't know much about NFS. It is surely my case. > Care to rephrase your assertion? The new assertion is then: I don't know how to firewall my NFS server which is running FreeBSD 6.2. > > The reason is that NFS related daemons use RPC, which means they > > don't bind to a deterministic port. Only mountd(8) can be requested to > > bind to a specific port or fail with the -p command-line switch. > > Is there any reason other than "no one has needed this yet" why this > > option is not available for nfsd(8), rpc.lockd(8) and rpc.statd(8)? > > this is wrong, wrong and more wrong. Sorry, I checked RELENG_6. I've been told that rpc.lockd(8) and rpc.statd(8) now have the "-p" option in -CURRENT. It seems that nfsd(8)'s port number is assigned in recorded in services(5). Therefore my question will be totally pointless once rpc.lockd(8) and rpc.statd(8) "-p" option will be MFC'd to RELENG_6. Sorry for the noise guys. Thank you for your replies though. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 23:50:20 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91DAA16A469 for ; Sat, 16 Jun 2007 23:50:20 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from mail.monkeybrains.net (mail1.monkeybrains.net [208.69.40.8]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB3213C45B for ; Sat, 16 Jun 2007 23:50:20 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from monchichi.monkeybrains.net (adsl-75-36-247-158.dsl.pltn13.sbcglobal.net [75.36.247.158]) (authenticated bits=0) by mail.monkeybrains.net (8.13.7/8.13.7) with ESMTP id l5GNoJav003750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 16 Jun 2007 16:50:20 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <46747735.5010603@monkeybrains.net> Date: Sat, 16 Jun 2007 16:50:13 -0700 From: Rudy Rucker User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4673B170.9020005@thedarkside.nl> In-Reply-To: <4673B170.9020005@thedarkside.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on mail.monkeybrains.net X-Virus-Status: Clean Subject: Re: Quickly creating VLANs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2007 23:50:20 -0000 Works for me, but if you put in the 'inet' if breaks. # ifconfig vlan600 create vlan 600 vlandev fxp1 inet 10.20.0.1/24 ifconfig: inet: bad value man ifconfig: Since an interface can receive transmissions in differing protocols with different naming schemes, specifying the address family is recommended. either needs to be revised to: except when creating a vlan, 'cause that causes sh*t to break or, the ifconfig command needs to accept 'inet' when creating a vlan. Is inet inherited from the 'vlandev' and therefore redundant? Rudy Pieter de Boer wrote: > Ivan Voras wrote: > >> ifconfig vlan600 destroy >> ifconfig vlan600 create >> ifconfig vlan600 vlan 600 vlandev fxp1 >> ifconfig vlan600 inet 10.20.0.1 netmask 255.255.255.0 > Try ifconfig vlan600 create vlan 600 vlandev fxp1 10.20.0.1/24 >