From owner-freebsd-net@FreeBSD.ORG Sun Jan 7 11:52:10 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 0CC8016A403 for ; Sun, 7 Jan 2007 11:52:10 +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 BFBDD13C44B for ; Sun, 7 Jan 2007 11:52:09 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1H3WZG-000GcZ-Uc; Sun, 07 Jan 2007 14:52:03 +0300 Date: Sun, 7 Jan 2007 14:51:58 +0300 From: Eygene Ryabinkin To: "Bruce M. Simpson" Message-ID: <20070107115158.GA63854@codelabs.ru> References: <459D4D88.2030708@delphij.net> <459FEDBC.4070008@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <459FEDBC.4070008@FreeBSD.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.5 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-net@freebsd.org, LI Xin Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Jan 2007 11:52:10 -0000 Bruce, good day! > With FreeBSD's stack, sending packets to the undirected broadcast address > INADDR_BROADCAST will result in the first ifnet with IPv4 configured and > IFF_BROADCAST set being selected as the source ifnet. See ip_output.c for > details. May be I didn't understood you, but you seems to be wrong: the ICMP packets with 255.255.255.255 as the destination will go through the full routing and will hit the 'else' statement at the line 224 of ip_output.c (citing revision 1.269). For me the routing gives the default gateway as the next hop, so the 'dst' will be rewritten at the line 241. > In my local network, pinging 255.255.255.255 from my FreeBSD laptop (running > 6.2-RC1) results in a single unicast ICMP reply from the edge router, with its > source address on the same LAN. I think that this confirms my findings. Have you tried to look at your packet with tcpdump? Link-level MAC should be set to your routers one, not to yhe 0xffffffff. > The IP_SENDONES socket option may be used to select the source interface for > undirected broadcasts, by sending to a directed broadcast address. The stack > will munge the directed address to 255.255.255.255 before it goes on the wire. > This came from BSD/OS; See ip(4) for details. Made the patch for 'ping': see my previous post in this thread. Testing is much welcome. > You might want to take a look at NetBSD's stack, which has recently had IPv4 > source address selection logic added to it to support schemes such as > link-local addressing (Zeroconf/Rendezvous). > > It would be great if someone had time to look at this and perhaps port it. May be it will be me, but not sure now :( -- Eygene From owner-freebsd-net@FreeBSD.ORG Mon Jan 8 05:10: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 40F8016A407 for ; Mon, 8 Jan 2007 05:10:26 +0000 (UTC) (envelope-from mallman@icir.org) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by mx1.freebsd.org (Postfix) with ESMTP id 295FC13C442 for ; Mon, 8 Jan 2007 05:10:26 +0000 (UTC) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l084MEFA005661; Sun, 7 Jan 2007 20:22:14 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id E579D67B3AE; Sun, 7 Jan 2007 23:24:12 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id DDDEB15E235; Sun, 7 Jan 2007 23:21:14 -0500 (EST) To: "maillist ifiaas" From: Mark Allman In-Reply-To: <161d69110612112007j5d545b33qd18c6b6306f93bca@mail.gmail.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Entertainer MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 07 Jan 2007 23:21:14 -0500 Sender: mallman@icir.org Message-Id: <20070108042114.DDDEB15E235@lawyers.icir.org> Cc: freebsd-net@freebsd.org Subject: Re: TCP payload size and throughput X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2007 05:10:26 -0000 --=_bOundary Content-Type: text/plain Content-Disposition: inline > I know there is some relationship between the packet size and the TCP > throughput. But what if two TCP Sack flows have the same MTU size, > but different header size (hence different payload size) ? Is there > any work that model this issue before? Yeah ... the TCP model that Padhye, et.al. worked out in their 1998 SIGCOMM paper shows that performance is directly proportional to packet size. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFoca6WyrrWs4yIs4RAgzdAJ97Czx7jfgjtz1O0XYryhr2j+bfbQCff32J 67OocBkmQIpbkMP/iaiwN5Q= =uxUt -----END PGP SIGNATURE----- --=_bOundary-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 8 09:32: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 1F1D416A40F; Mon, 8 Jan 2007 09:32:44 +0000 (UTC) (envelope-from nagao@iij.ad.jp) Received: from otm-mgo00.iij.ad.jp (otm-mgo00.iij.ad.jp [210.138.20.174]) by mx1.freebsd.org (Postfix) with ESMTP id 44A9B13C458; Mon, 8 Jan 2007 09:32:42 +0000 (UTC) (envelope-from nagao@iij.ad.jp) Received: OTM-MO(otm-mgo00) id l088ruUK085932; Mon, 8 Jan 2007 17:53:56 +0900 (JST) DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=iij.ad.jp; s=omgo0; t=1168246436; bh=DAiHPXb0RMZODDbKThN52IsAOJg=; h=Received:Received: Date:Message-Id:To:Cc:Subject:From:In-Reply-To:References:X-Mailer: Mime-Version:Content-Type:Content-Transfer-Encoding; b=MYeZUjeU4WS9 AHzS1cMApMkdWcUm0ctWhOFtLpiapyuFezW3lXl7JP5kBGzlxqWcJIXXhNCVrgQs9Aq ALTv3qim1L9rI79fMxfV+W7y/31/tiVcvumWyfxOxX7Q31G7/ALZKp3lrnXywSXpqXd +4wNlIQd75vOgDabKp0yxwpMQ= Received: OTM-MIX(otm-mix00) id l088rtHh039057; Mon, 8 Jan 2007 17:53:55 +0900 (JST) Received: from localhost (kabosu.iij.ad.jp [192.168.186.148]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp01) id l088rsco010375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 17:53:55 +0900 (JST) Date: Mon, 08 Jan 2007 17:53:54 +0900 (JST) Message-Id: <20070108.175354.26933985.nagao@iij.ad.jp> To: freebsd-net@freebsd.org From: Tadaaki Nagao In-Reply-To: <20070105162022.GA1503@twilight.mbslab.kiae.ru> References: <459D4D88.2030708@delphij.net> <20070105113442.GH37482@codelabs.ru> <20070105162022.GA1503@twilight.mbslab.kiae.ru> X-Mailer: Mew version 5.2rc3 on Emacs 22.0.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: delphij@delphij.net, andre@FreeBSD.org Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jan 2007 09:32:44 -0000 Hi, > > When FBSD is pinging 0xffffffff it does not use the Ethernet broadcasts, > > when the link-level destination MAC is set to 0xffffffffffff, using some > > 'known MAC' instead. For the network broadcast address -- it does use > > link-level broadcasts. This seems to be the same problem as kern/99558: "FreeBSD 6.1 can't send packets to INADDR_BROADCAST". Maybe andre has some thoughts on how to fix this issue? (I'm CC'ing him.) > > For me the 'known MAC' is that of our border router that serves as > > the default destination. And my box doing the ARP request for the > > precisely the IP of the router before pinging 255.255.255.255. You can > > try to empty your ARP table and then ping 255.255.255.255 watching > > for the ARP requests and the link-level header of the ICMP packets. > > OK, I've found that in order to ping undirected broadcast address > one should add some functionality to the 'ping' utility. It seems to me from the PR above, that before patching `ping', ip_output.c should receive some sort of fix in handling INADDR_BROADCAST. -- Tadaaki Nagao Applied Research and Development Department, Internet Initiative Japan Inc. From owner-freebsd-net@FreeBSD.ORG Mon Jan 8 10:36: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 71C5516A412 for ; Mon, 8 Jan 2007 10:36:45 +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 289B913C46C for ; Mon, 8 Jan 2007 10:36:45 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1H3rrs-000I4d-WA; Mon, 08 Jan 2007 13:36:41 +0300 Date: Mon, 8 Jan 2007 13:36:36 +0300 From: Eygene Ryabinkin To: Tadaaki Nagao Message-ID: <20070108103635.GI37482@codelabs.ru> References: <459D4D88.2030708@delphij.net> <20070105113442.GH37482@codelabs.ru> <20070105162022.GA1503@twilight.mbslab.kiae.ru> <20070108.175354.26933985.nagao@iij.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070108.175354.26933985.nagao@iij.ad.jp> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_20 Cc: freebsd-net@freebsd.org, andre@FreeBSD.org, delphij@delphij.net Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jan 2007 10:36:45 -0000 Tadaaki, good day! > This seems to be the same problem as kern/99558: "FreeBSD 6.1 can't send > packets to INADDR_BROADCAST". > > Maybe andre has some thoughts on how to fix this issue? (I'm CC'ing him.) Exactly, thank you very much for the pointer! > It seems to me from the PR above, that before patching `ping', ip_output.c > should receive some sort of fix in handling INADDR_BROADCAST. If ip_output.c will receive patching, it probably will be unneccessary to patch `ping' ;)) The problem with ip_output.c patch is that it is rather hard to spot the right interface to output the broadcast to: no pointers are given when the packet just destined to 255.255.255.255. Probably the best way will be to - output it to all interfaces with broadcast capability, - limit the TTL to 1. The patch for `ping' introduces '-b' flag namely for the purpose of identifying the interface the broadcast will go to. -- Eygene From owner-freebsd-net@FreeBSD.ORG Mon Jan 8 11:08: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 9D8AB16A508 for ; Mon, 8 Jan 2007 11:08:40 +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 8B5BD13C4AC for ; Mon, 8 Jan 2007 11:08:40 +0000 (UTC) (envelope-from owner-bugmaster@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 l08B8eZY016550 for ; Mon, 8 Jan 2007 11:08:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l08B8c6A016546 for freebsd-net@FreeBSD.org; Mon, 8 Jan 2007 11:08:38 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Jan 2007 11:08:38 GMT Message-Id: <200701081108.l08B8c6A016546@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon 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, 08 Jan 2007 11:08:40 -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 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 o kern/106722 net [net] [patch] ifconfig may not connect an interface to o kern/107358 net [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (re 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio 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/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/106999 net [netgraph] [patch] ng_ksocket fails to clear multicast 10 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 8 14:22:42 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 60E9616A40F; Mon, 8 Jan 2007 14:22:42 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2F29413C45B; Mon, 8 Jan 2007 14:22:42 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.dcn.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id l08ECKjN074190; Mon, 8 Jan 2007 06:12:21 -0800 (PST) Date: Mon, 08 Jan 2007 23:12:19 +0900 Message-ID: From: gnn@freebsd.org To: "David Boyd" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.90 (i386-apple-darwin8.8.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-stable@freebsd.org, net@freebsd.org Subject: Re: Panic in 6.2-RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jan 2007 14:22:42 -0000 At Sat, 6 Jan 2007 13:54:22 -0500, David Boyd wrote: > > The following panic occurs every one to three hours with 6.2-RC2. > Can you give more info on what, exactly, is going on when this happens? Also I'm redirecting this to net@ Best Geoge > This is the same problem as kern/88472 which is still open. > > 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: > <7>key_spddelete: no SP found. > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x23 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc074fc0c > stack pointer = 0x28:0xd0a4e8f8 > frame pointer = 0x28:0xd0a4e908 > 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 = 695 (isakmpd) > trap number = 12 > panic: page fault > Uptime: 1h2m52s > Dumping 255 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 255MB (65216 pages) 239 223 207 191 175 159 143 127 111 95 79 63 > 47 31 15 > > #0 doadump () at pcpu.h:165 > 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) by t > #0 doadump () at pcpu.h:165 > #1 0xc068c76e in boot (howto=260) at > /var/cvsup/usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc068ca04 in panic (fmt=0xc08c386a "%s") > at /var/cvsup/usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc08690b4 in trap_fatal (frame=0xd0a4e8b8, eva=35) > at /var/cvsup/usr/src/sys/i386/i386/trap.c:837 > #4 0xc0868e1b in trap_pfault (frame=0xd0a4e8b8, usermode=0, eva=35) > at /var/cvsup/usr/src/sys/i386/i386/trap.c:745 > #5 0xc0868a59 in trap (frame= > {tf_fs = -1035665400, tf_es = -1035665368, tf_ds = 40, tf_edi = 3, > tf_esi = -1037761536, tf_ebp = -794498808, tf_isp = -794498844, tf_ebx > = -1030032896, tf_edx = 1, tf_ecx = 1466671235, tf_eax = 3, tf_trapno = 12, > tf_err = 0, tf_eip = -1066075124, tf_cs = 32, tf_eflags = 66054, tf_esp = 0, > tf_ss = -1030032896}) at /var/cvsup/usr/src/sys/i386/i386/trap.c:435 > #6 0xc085712a in calltrap () at > /var/cvsup/usr/src/sys/i386/i386/exception.s:139 > #7 0xc074fc0c in key_getsavbyspi (sah=0xc2250400, spi=1466671235) > at /var/cvsup/usr/src/sys/netkey/key.c:2977 > #8 0xc07527cd in key_delete (so=0xc2452164, m=0xc29af200, mhp=0xd0a4ea64) > at /var/cvsup/usr/src/sys/netkey/key.c:5427 > #9 0xc07548b9 in key_parse (m=0xc29af200, so=0xc2452164) > at /var/cvsup/usr/src/sys/netkey/key.c:7149 > #10 0xc0756081 in key_output (m=0xc29af200, so=0xc2452164) > at /var/cvsup/usr/src/sys/netkey/keysock.c:119 > #11 0xc07074b0 in raw_usend (so=0x576ba083, flags=0, m=0x1, nam=0x0, > control=0x3, > td=0xc22a6a80) at /var/cvsup/usr/src/sys/net/raw_usrreq.c:263 > #12 0xc07565e7 in key_send (so=0xc2452164, flags=0, m=0xc29af200, nam=0x0, > control=0x0, > p=0xc22a6a80) at /var/cvsup/usr/src/sys/netkey/keysock.c:430 > #13 0xc06c5863 in sosend (so=0xc2452164, addr=0x0, uio=0xc2602100, > top=0xc29af200, > control=0x0, flags=0, td=0xc22a6a80) at > /var/cvsup/usr/src/sys/kern/uipc_socket.c:836 > #14 0xc06b40ee in soo_write (fp=0x3, uio=0xc2602100, active_cred=0xc2447480, > flags=0, > td=0xc22a6a80) at /var/cvsup/usr/src/sys/kern/sys_socket.c:118 > #15 0xc06ae7f7 in dofilewrite (td=0xc22a6a80, fd=5, fp=0xc23a2288, > auio=0xc2602100, offset= > ) at file.h:252 > #16 0xc06ae69b in kern_writev (td=0xc22a6a80, fd=5, auio=0xc2602100) > at /var/cvsup/usr/src/sys/kern/sys_generic.c:402 > #17 0xc06ae644 in writev (td=0xc22a6a80, uap=0xd0a4ed04) > at /var/cvsup/usr/src/sys/kern/sys_generic.c:388 > #18 0xc08693cb in syscall (frame= > {tf_fs = 59, tf_es = -1078001605, tf_ds = -1078001605, tf_edi = > 136368064, tf_esi = -1077941328, tf_ebp = -1077941224, tf_isp = -794497692, > tf_ebx = 5, tf_edx = 23, tf_ecx = 0, tf_eax = 121, tf_trapno = 0, tf_err = > 2, tf_eip = 673519919, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941364, > tf_ss = 59}) at /var/cvsup/usr/src/sys/i386/i386/trap.c:983 > #19 0xc085717f in Xint0x80_syscall () at > /var/cvsup/usr/src/sys/i386/i386/exception.s:200 > #20 0x00000033 in ?? () > (kgdb) q > > The following messages are logged just before the panic. > > Jan 6 00:34:28 vpn-gateway2 isakmpd[452]: isakmpd: quick mode done: src: > xxx.xxx.xxx.xxx dst: yyy.yyy.yyy.yyy > Jan 6 00:34:28 vpn-gateway2 isakmpd[452]: pf_key_v2_set_spi: ADD: Invalid > argument > > The other end of the connection is reported to be "Cisco-based". > From owner-freebsd-net@FreeBSD.ORG Mon Jan 8 20:16:29 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 A9FE616A47E for ; Mon, 8 Jan 2007 20:16:29 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 98E6413C45E for ; Mon, 8 Jan 2007 20:16:28 +0000 (UTC) (envelope-from killing@multiplay.co.uk) X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on core6.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-24.7 required=6.0 tests=BAYES_00, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=ham version=3.1.5 Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.5.4) with ESMTP id md50003369924.msg; Mon, 08 Jan 2007 19:58:46 +0000 Message-ID: <066101c7335f$611c41e0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: , Date: Mon, 8 Jan 2007 19:58:26 -0000 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-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-Spam-Processed: multiplay.co.uk, Mon, 08 Jan 2007 19:58:47 +0000 X-MDAV-Processed: multiplay.co.uk, Mon, 08 Jan 2007 19:58:47 +0000 Cc: Subject: Slow FreeBSD -> Windows performance with inflight enabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jan 2007 20:16:29 -0000 I've just been looking at an issue reported by some of our users that downloads from our one of our sites run on FreeBSD 6.1 and Apache 1.3 where strangely slow. After doing some digging around I found that two remote machines on the same network had wildly different results. The difference being one was Windows (slow) and one was FreeBSD 6.1 (fast). The results where 380Kb/s download speeds on Windows vs 500Kb/s on FreeBSD. I played around and Googled to find that this appears to caused by inflight. Disabling it and restarting apache cures the problem. This has been mentioned a few times in the past e.g. http://lists.freebsd.org/pipermail/freebsd-stable/2006-February/022622.html http://lists.freebsd.org/pipermail/freebsd-net/2005-November/008989.html But I cant find any real conclusive results. For reference the connection between the test machines is initially GE on both ends but at one point goes via DSL but is still relatively low latency the trace being: Host Loss% Snt Last Avg Best Wrst StDev 1. x.x.x.x 0.0% 12 0.3 0.3 0.3 0.3 0.0 2. x.x.x.x 0.0% 12 0.4 0.4 0.4 0.4 0.0 3. x.x.x.x 8.3% 12 1.4 1.7 1.3 3.1 0.6 4. x.x.x.x 0.0% 11 5.5 10.1 5.5 21.6 5.9 5. x.x.x.x 0.0% 11 7.6 6.8 6.3 7.6 0.3 6. x.x.x.x 0.0% 11 7.7 7.2 6.7 8.1 0.4 Looking at the before and after traces using wireshark on the windows box there are no notable changes just an increased throughput in exchanges. Possibly of note is that the server in question is running a 200HZ kernel. With the common client being Windows I'd say it would be good to get the default improved either by disabling inflight or changing it so that it better detects this sort of common connection arrangement. Does anyone have any ideas why inflight is causing such poor performance? Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Tue Jan 9 00:44:01 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 2EE8616A415; Tue, 9 Jan 2007 00:44:01 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.freebsd.org (Postfix) with ESMTP id C7BF813C461; Tue, 9 Jan 2007 00:44:00 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id l090XTEK019316; Mon, 8 Jan 2007 16:33:30 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20061231061903.J47883@delplex.bde.org> Date: Mon, 08 Jan 2007 16:33:29 -0800 (PST) From: John Polstra To: Bruce Evans X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (blake.polstra.com [64.81.189.66]); Mon, 08 Jan 2007 16:33:30 -0800 (PST) Cc: Doug Barton , oleg@freebsd.org, net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jan 2007 00:44:01 -0000 On 30-Dec-2006 Bruce Evans wrote: > More debugging showed that almost any of the reads of the phy in mii > cause an input error, The errors appear to be caused by the code in bge_miibus_{read,write}reg that clears and then restores the BGE_MIMODE_AUTOPOLL bit of the BGE_MI_MODE register. If you remove those chunks of code, the errors go away even when mii_tick is called periodically, and the chip performs quite well under heavy traffic load in both directions. I know that some of the *_MODE registers in these chips cause problems if they are read, so I tried putting a shadow copy of the register into the softc and doing only writes to the hardware register. But that didn't help in this case. I seem to recall having heard that Broadcom discourages the use of PHY autopolling for unspecified reasons. The Linux driver from Broadcom had code to support it, but it was never actually used for any devices. The current Linux driver uses autopolling only for the Altima chip that's present on the inexpensive Netgear GA302T card. I agree with you that we shouldn't need to call mii_tick periodically, except perhaps for a few very old variants of the Broadcom chip. John From owner-freebsd-net@FreeBSD.ORG Tue Jan 9 14: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 38E4616A47C for ; Tue, 9 Jan 2007 14:08:50 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.freebsd.org (Postfix) with SMTP id A70B013C448 for ; Tue, 9 Jan 2007 14:08:49 +0000 (UTC) (envelope-from mikej@rogers.com) Received: (qmail 95232 invoked from network); 9 Jan 2007 13:42:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Received:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:Importance; b=xo0vYWRYVaynMwqomMLV9HAYnbOJrqm2isNbVyxhfPhhOuCqRj4oxG7hNok+DOEnvEgYjk2K9Ajgkr49zfFah7RwbWGSwDukzDGcQZOhvtImhwiJKEGav5FKRzpMQ5VQxa2ns9vUnnkX9agQfT9uKtGand2xKvgKXAvKOsfrpug= ; Received: from unknown (HELO wettoast.dyndns.org) (mikej@rogers.com@74.111.253.239 with login) by smtp101.rog.mail.re2.yahoo.com with SMTP; 9 Jan 2007 13:42:09 -0000 X-YMail-OSG: 4E1_ek4VM1mSBdcI.dtRz5_FsjMxIC_OiJObr3YXAq5SuwU3KQ.l395iP2enTTGv1g-- Received: from 209.47.38.69 (SquirrelMail authenticated user mikej) by wettoast.dyndns.org with HTTP; Tue, 9 Jan 2007 08:42:06 -0500 (EST) Message-ID: <44647.209.47.38.69.1168350126.squirrel@wettoast.dyndns.org> In-Reply-To: <066101c7335f$611c41e0$b3db87d4@multiplay.co.uk> References: <066101c7335f$611c41e0$b3db87d4@multiplay.co.uk> Date: Tue, 9 Jan 2007 08:42:06 -0500 (EST) From: "Mike Jakubik" To: "Steven Hartland" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: Slow FreeBSD -> Windows performance with inflight enabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jan 2007 14:08:50 -0000 On Mon, January 8, 2007 2:58 pm, Steven Hartland wrote: > I've just been looking at an issue reported by some > of our users that downloads from our one of our sites > run on FreeBSD 6.1 and Apache 1.3 where strangely > slow. > > After doing some digging around I found that two remote > machines on the same network had wildly different results. > The difference being one was Windows (slow) and one was > FreeBSD 6.1 (fast). > > The results where 380Kb/s download speeds on Windows vs > 500Kb/s on FreeBSD. I played around and Googled to find > that this appears to caused by inflight. Disabling it > and restarting apache cures the problem. AFAIK there was some work done on this to make it more adaptive for LAN networks, but im not sure which version got this. From owner-freebsd-net@FreeBSD.ORG Tue Jan 9 16:21: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 21B3E16A591; Tue, 9 Jan 2007 16:21:38 +0000 (UTC) (envelope-from robertw@ssginnovations.com) Received: from ssg1.ssginnovations.com (ssginnovations.com [205.145.135.135]) by mx1.freebsd.org (Postfix) with ESMTP id F1D0E13C44B; Tue, 9 Jan 2007 16:21:37 +0000 (UTC) (envelope-from robertw@ssginnovations.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id 82EB6406C; Tue, 9 Jan 2007 10:53:42 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jan 2007 10:52:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <85D4F2C294E8434CA0AF775741532686203047@server1.ssgi.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bge autoneg full-duplex modes missing on 6.2-RC2 Thread-Index: Acc0BiJgR8vgOErpQTu3Othen4yjIw== From: "Robert Wojciechowski" To: Cc: freebsd-stable@freebsd.org Subject: bge autoneg full-duplex modes missing on 6.2-RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jan 2007 16:21:38 -0000 I'm having problems on one of two identical servers which have dual Broadcom BCM5704s onboard. The problem is that one of the servers is not linking at 100baseTX-FDX on the bge0 interface no matter what I do (forced, limited advertising on the switch, etc).=20 Upon further investigation I noticed this in dmesg: bge0: mem 0xfe7f0000-0xfe7fffff irq 49 at device 3.0 on pci2 miibus1: on bge0 brgphy0: on miibus1 brgphy0: 10baseT, 100baseTX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:30:48:56:93:32 bge1: mem 0xfe7e0000-0xfe7effff irq 50 at device 3.1 on pci2 miibus2: on bge1 brgphy1: on miibus2 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:30:48:56:93:33 Notice 10baseTX-FDX and 100baseTX-FDX are missing from brgphy0! The other server doesn't have this problem at all and is running off the same kernel and identical hardware. This is on amd64 and 6.2-RC2 as of Jan 8th. Thanks! -- Robert From owner-freebsd-net@FreeBSD.ORG Tue Jan 9 17:04: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 B5CAD16A407 for ; Tue, 9 Jan 2007 17:04:12 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 39BAE13C45B for ; Tue, 9 Jan 2007 17:04:12 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so188334nfc for ; Tue, 09 Jan 2007 09:04:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=n9VX0JDHsjC8U2hY5WSwkR3GrUZsPMB8jHue8s90gpNk8ID7Pxj4leWMmMuoOme+HYA/UURcSL/pUxzsHkGP/KJptF4honFaMCO4x2sR5+dD3xCQLuD2SyOXjEDQ40AspADaVbvLmW/KCK3oJ8/fNinxfAz8FBEzASiYu8BTjtg= Received: by 10.49.55.13 with SMTP id h13mr430193nfk.1168360707251; Tue, 09 Jan 2007 08:38:27 -0800 (PST) Received: by 10.48.213.12 with HTTP; Tue, 9 Jan 2007 08:38:26 -0800 (PST) Message-ID: <61b573980701090838q415d6c6fx75b7de73eeace9fd@mail.gmail.com> Date: Tue, 9 Jan 2007 18:38:26 +0200 From: "Shteryana Shopova" Sender: shteryana@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_47269_24053843.1168360706882" X-Google-Sender-Auth: 92d40e4f4db7308e Cc: tsvetan@erenditsov.com Subject: RFC: a MIB for a SNMP vlan monitoring module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syrinx@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 17:04:12 -0000 ------=_Part_47269_24053843.1168360706882 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, Work is about to start on a vlan monitoring module for bsnmpd(1) - I'm attaching the private BEGEMOT MIB that the module will implement. Any comments or suggestions are very welcome. Cheers, Shteryana ------=_Part_47269_24053843.1168360706882 Content-Type: text/plain; name=BEGEMOT-VLAN-MIB.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_ewqjm8ur Content-Disposition: attachment; filename="BEGEMOT-VLAN-MIB.txt" LS0KLS0gQ29weXJpZ2h0IChDKSAyMDA3IFNodGVyeWFuYSBTaG9wb3ZhIDxzeXJpbnhARnJlZUJT RC5vcmc+Ci0tIEFsbCByaWdodHMgcmVzZXJ2ZWQuCi0tCi0tIFJlZGlzdHJpYnV0aW9uIGFuZCB1 c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAotLSBtb2RpZmlj YXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlv bnMKLS0gYXJlIG1ldDoKLS0gMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3Qg cmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKLS0gICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29u ZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgotLSAyLiBSZWRpc3RyaWJ1dGlv bnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAotLSAg ICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2Ns YWltZXIgaW4gdGhlCi0tICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBw cm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCi0tCi0tIFRISVMgU09GVFdBUkUgSVMgUFJP VklERUQgQlkgQVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAotLSBBTlkgRVhQ UkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRP LCBUSEUKLS0gSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKLS0gQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVO VCBTSEFMTCBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQotLSBGT1IgQU5ZIERJUkVD VCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVO VElBTAotLSBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1F TlQgT0YgU1VCU1RJVFVURSBHT09EUwotLSBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEs IE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKLS0gSE9XRVZFUiBDQVVTRUQg QU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJ Q1QKLS0gTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJ U0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQotLSBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJF LCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCi0tIFNVQ0ggREFNQUdFLgot LQotLSAkRnJlZUJTRCQKLS0KCkJFR0VNT1QtVkxBTi1NSUIgREVGSU5JVElPTlMgOjo9IEJFR0lO CgpJTVBPUlRTCiAgICBNT0RVTEUtSURFTlRJVFksIE9CSkVDVC1UWVBFLCBOT1RJRklDQVRJT04t VFlQRSwKICAgIENvdW50ZXIzMiwgSW50ZWdlcjMyLCBUaW1lVGlja3MsIG1pYi0yCglGUk9NIFNO TVB2Mi1TTUkKICAgIFRFWFRVQUwtQ09OVkVOVElPTiwgTWFjQWRkcmVzcywgVHJ1dGhWYWx1ZSwg Um93U3RhdHVzCglGUk9NIFNOTVB2Mi1UQwogICAgSW50ZXJmYWNlSW5kZXggRlJPTSBJRi1NSUIK ICAgIFRpbWVvdXQgRlJPTSBCUklER0UtTUlCCiAgICBWbGFuSWQgRlJPTSBRLUJSSURHRS1NSUIK ICAgIEVuYWJsZWRTdGF0dXMgRlJPTSBQLUJSSURHRS1NSUIKICAgIGJlZ2Vtb3QKCUZST00gQkVH RU1PVC1NSUI7CgpiZWdlbW90VmxhbiBNT0RVTEUtSURFTlRJVFkKICAgIExBU1QtVVBEQVRFRAki MjAwNzAxMDkwMDAwWiIKICAgIE9SR0FOSVpBVElPTgkiU29maWEgVW5pdmVyc2l0eSBTdC4gS2xp bWVudCBPaHJpZHNraSIKICAgIENPTlRBQ1QtSU5GTwoJIgoJCQlTaHRlcnlhbmEgU2hvcG92YQoK CVBvc3RhbDoJCUZhY3VsdHkgb2YgTWF0aGVtYXRpY3MgYW5kIEluZm9ybWF0aWNzCgkJCTUgSmFt ZXMgQm91cmNoaWVyIEJsdmQuCgkJCTExNjQgU29maWEKCQkJQnVsZ2FyaWEKCglGYXg6CQkrMzU5 IDIgNjg3IDE4MAoKCUUtTWFpbDoJCXN5cmlueEBGcmVlQlNELm9yZyIKICAgIERFU0NSSVBUSU9O CgkiVGhlIEJlZ2Vtb3QgTUlCIGZvciBtYW5hZ2luZyB2bGFuIGludGVyZmFjZXMuIgogICAgUkVW SVNJT04JCSIyMDA3MDEwOTAwMDBaIgogICAgREVTQ1JJUFRJT04KCSJJbml0aWFsIHJldmlzaW9u LiIKICAgIDo6PSB7IGJlZ2Vtb3QgMjA2IH0KCi0tIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0KQmVnZW1vdFZsYW5CaXRNYXAgOjo9 IFRFWFRVQUwtQ09OVkVOVElPTgogICAgU1RBVFVTCWN1cnJlbnQKICAgIERFU0NSSVBUSU9OCgki RWFjaCBvY3RldCB3aXRoaW4gdGhpcyB2YWx1ZSBzcGVjaWZpZXMgYSBzZXQgb2YgZWlnaHQKCVZs YW5JZHMsIHdpdGggdGhlIGZpcnN0IG9jdGV0IHNwZWNpZnlpbmcgVmxhbklkcyAxIHRocm91Z2gK CTgsIHRoZSBzZWNvbmQgb2N0ZXQgc3BlY2lmeWluZyBWbGFuSWRzIDkgdGhyb3VnaCAxNiwgZXRj LgoJV2l0aGluIGVhY2ggb2N0ZXQsIHRoZSBtb3N0IHNpZ25pZmljYW50IGJpdCByZXByZXNlbnRz Cgl0aGUgc21hbGxlc3QgVmxhbklkLCBhbmQgdGhlIGxlYXN0IHNpZ25pZmljYW50IGJpdAoJcmVw cmVzZW50cyB0aGUgYmlnZ2VzdCBWbGFuSWQuIFRodXMsIGVhY2ggVmxhbklkIHRoYXQgY2FuCgli ZSByZXByZXNlbnRlZCBieSBhIDEyLWJpdCBJbnRlZ2VyIGlzIHJlcHJlc2VudGVkIGJ5IGEKCXNp bmdsZSBiaXQgd2l0aGluIHRoZSB2YWx1ZSBvZiB0aGlzIG9iamVjdC4gSWYgdGhhdCBiaXQKCWhh cyBhIHZhbHVlIG9mICcxJyB0aGVuIHRoYXQgVmxhbklkIGlzIGluY2x1ZGVkIGluIHRoZSBzZXQK CW9mIFZsYW5JZHM7IHRoZSBWbGFuSWQgaXMgbm90IGluY2x1ZGVkIGlmIGl0cyBiaXQgaGFzIGEK CXZhbHVlIG9mICcwJy4iCiAgICBTWU5UQVgJT0NURVQgU1RSSU5HIChTSVpFKDUxMikpCgotLSAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t IC0tCi0tIHN1YnRyZWVzIGluIHRoZSBCZWdlbW90IFZsYW4gTUlCCi0tIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0KYmVnZW1vdFZs YW5Db25maWcJT0JKRUNUIElERU5USUZJRVIgOjo9IHsgYmVnZW1vdFZsYW4gMSB9CgpiZWdlbW90 VmxhblRydW5rcwlPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBiZWdlbW90VmxhbiAyIH0KCmJlZ2Vt b3RWbGFuSW50ZXJmYWNlcwlPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBiZWdlbW90VmxhbiAzIH0K CmJlZ2Vtb3RWbGFuU3RhdGlzdGljcwlPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBiZWdlbW90Vmxh biA0IH0KCi0tIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gLS0KLS0gdGhlIGJlZ2Vtb3RWbGFuQ29uZmlnIG9iamVjdHMKLS0gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLQoK YmVnZW1vdFZsYW5NYXhJZCBPQkpFQ1QtVFlQRQogICAgU1lOVEFYCVZsYW5JZAogICAgTUFYLUFD Q0VTUwlyZWFkLW9ubHkKICAgIFNUQVRVUwljdXJyZW50CiAgICBERVNDUklQVElPTgoJIlRoZSBt YXhpbXVtIElFRUUgODAyLjFRIFZMQU4gSUQgdGhhdCB0aGUgc3lzdGVtCglzdXBwb3J0cy4iCiAg ICA6Oj0geyBiZWdlbW90VmxhbkNvbmZpZyAxIH0KCmJlZ2Vtb3RWbGFuTnVtVmxhbnMgT0JKRUNU LVRZUEUKICAgIFNZTlRBWAlJTlRFR0VSCiAgICBNQVgtQUNDRVNTCXJlYWQtb25seQogICAgU1RB VFVTCWN1cnJlbnQKICAgIERFU0NSSVBUSU9OCgkiVGhlIGN1cnJlbnQgbnVtYmVyIG9mIHZsYW4g aW50ZXJmYWNlcyBvbiB0aGUgc3lzdGVtLiIKICAgIDo6PSB7IGJlZ2Vtb3RWbGFuQ29uZmlnIDIg fQoKYmVnZW1vdFZsYW5EYXRhUG9sbCBPQkpFQ1QtVFlQRQogICAgU1lOVEFYCVRpbWVvdXQgKDEu LjM2MDApCiAgICBVTklUUwkic2Vjb25kcyIKICAgIE1BWC1BQ0NFU1MJcmVhZC13cml0ZQogICAg U1RBVFVTCWN1cnJlbnQKICAgIERFU0NSSVBUSU9OCgkiVGhlIHBvbGxpbmcgcmF0ZSBvZiBkYXRh IHdoZW4gdGhlIG1vZHVsZSBpcyBpZGxlLiIKICAgIERFRlZBTAl7IDMwMCB9CiAgICA6Oj0geyBi ZWdlbW90VmxhbkNvbmZpZyAzIH0KCmJlZ2Vtb3RWbGFuU29mdFBhZCBPQkpFQ1QtVFlQRQogICAg U1lOVEFYCUVuYWJsZWRTdGF0dXMKICAgIE1BWC1BQ0NFU1MJcmVhZC13cml0ZQogICAgU1RBVFVT CWN1cnJlbnQKICAgIERFU0NSSVBUSU9OCgkiVGhlIHZhbHVlIG9mIHRoaXMgb2JqZWN0IGluZGlj YXRlcyB3aGV0aGVyIHBhZGRpbmcKCW9mIHNob3J0IGZyYW1lcyBiZWZvcmUgdGFnZ2luZyB0aGVt IGlzIGVuYWJsZWQuIgogICAgOjo9IHsgYmVnZW1vdFZsYW5Db25maWcgNCB9CgotLSAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIC0tCi0t IHRoZSBiZWdlbW90IFZsYW4gVHJ1bmsgdGFibGUKLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLQoKYmVnZW1vdFZsYW5UcnVua1Rh YmxlIE9CSkVDVC1UWVBFCiAgICBTWU5UQVgJU0VRVUVOQ0UgT0YgQmVnZW1vdFZsYW5UcnVua0Vu dHJ5CiAgICBNQVgtQUNDRVNTCW5vdC1hY2Nlc3NpYmxlCiAgICBTVEFUVVMJY3VycmVudAogICAg REVTQ1JJUFRJT04KCSJBIHRhYmxlIHRoYXQgY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgcGh5 c2ljYWwKCWludGVyZmFjZXMgdGhhdCBhcmUgY29uZmlndXJlZCB0byBkZW11bHRpcGxleCB0YWdn ZWQKCWZyYW1lcy4iCiAgICA6Oj0geyBiZWdlbW90VmxhblRydW5rcyAxIH0KCmJlZ2Vtb3RWbGFu VHJ1bmtFbnRyeSBPQkpFQ1QtVFlQRQogICAgU1lOVEFYCUJlZ2Vtb3RWbGFuVHJ1bmtFbnRyeQog ICAgTUFYLUFDQ0VTUwlub3QtYWNjZXNzaWJsZQogICAgU1RBVFVTCWN1cnJlbnQKICAgIERFU0NS SVBUSU9OCgkiQSBsaXN0IG9mIGluZm9ybWF0aW9uIGFib3V0IHBoeXNpY2FsIGludGVyZmFjZXMg dGhhdAoJYXJlIGNvbmZpZ3VyZWQgdG8gZGVtdWx0aXBsZXggdGFnZ2VkIGZyYW1lcy4iCiAgICBJ TkRFWCB7IGJlZ2Vtb3RWbGFuVHJ1bmtJbmRleCB9CiAgICA6Oj0geyBiZWdlbW90VmxhblRydW5r VGFibGUgMSB9CgpCZWdlbW90VmxhblRydW5rRW50cnkgOjo9IFNFUVVFTkNFIHsKICAgIGJlZ2Vt b3RWbGFuVHJ1bmtJbmRleAkJSW50ZXJmYWNlSW5kZXgsCiAgICBiZWdlbW90VmxhblBhcmVudElm TmFtZQkJT0NURVQgU1RSSU5HLAogICAgYmVnZW1vdFZsYW5QYXJlbnRJZkh3VGFnU3VwcG9ydGVk CVRydXRoVmFsdWUsCiAgICBiZWdlbW90VmxhblBhcmVudElmSHdUYWdFbmFibGVkCUVuYWJsZWRT dGF0dXMsCiAgICBiZWdlbW90VmxhblBhcmVudElmSHdNdHVTdXBwb3J0ZWQJVHJ1dGhWYWx1ZSwK ICAgIGJlZ2Vtb3RWbGFuUGFyZW50SWZId010dUVuYWJsZWQJRW5hYmxlZFN0YXR1cywKICAgIGJl Z2Vtb3RWbGFuVHJ1bmtNZW1iZXJzCQlJTlRFR0VSLAogICAgYmVnZW1vdFZsYW5UcnVua01lbWJl clZpZHMJCUJlZ2Vtb3RWbGFuQml0TWFwCn0KCmJlZ2Vtb3RWbGFuVHJ1bmtJbmRleCBPQkpFQ1Qt VFlQRQogICAgU1lOVEFYCUludGVyZmFjZUluZGV4CiAgICBNQVgtQUNDRVNTCXJlYWQtb25seQog ICAgU1RBVFVTCWN1cnJlbnQKICAgIERFU0NSSVBUSU9OCgkiVGhlIHZhbHVlIG9mIHRoZSBpbnN0 YW5jZSBvZiB0aGUgaWZJbmRleCBvYmplY3QsIGRlZmluZWQKCWluIElGLU1JQiwgZm9yIHRoZSBw YXJlbnQgaW50ZXJmYWNlIGNvcnJlc3BvbmRpbmcgdG8gdGhpcwoJdmxhbiB0cnVuay4iCiAgICA6 Oj0geyBiZWdlbW90VmxhblRydW5rRW50cnkgMSB9CgotLSBiZWdlbW90VmxhblBhcmVudElmTmFt ZSBvYmplY3QgaXMgcmVkdW5kYW50IHNpbmNlIGl0cyB2YWx1ZSBjYW4KLS0gYmUgb2J0YWluZWQg YnkgYSBTTk1QIGNsaWVudCBieSBpbnZva2luZyBhIEdFVCBvbiB0aGUgaWZOYW1lCi0tIG9iamVj dCB3aXRoIGFuIGluZGV4IG9mIHRoZSBjb3JyZXNwb25kaW5nIHZhbHVlIG9mCi0tIGJlZ2Vtb3RW bGFuVHJ1bmtJbmRleCwgYnV0IGlzIGluY2x1ZGVkIGZvciBjb252ZW5pZW5jZS4gCgpiZWdlbW90 VmxhblBhcmVudElmTmFtZSBPQkpFQ1QtVFlQRQogICAgU1lOVEFYCU9DVEVUIFNUUklORyAoU0la RSgxLi4xNikpCiAgICBNQVgtQUNDRVNTCXJlYWQtb25seQogICAgU1RBVFVTCWN1cnJlbnQKICAg IERFU0NSSVBUSU9OCgkiVGhlIHZhbHVlIG9mIHRoZSBpbnN0YW5jZSBvZiB0aGUgaWZOYW1lIG9i amVjdCwgZGVmaW5lZAoJaW4gSUYtTUlCLCBmb3IgdGhlIHBhcmVudCBpbnRlcmZhY2UgY29ycmVz cG9uZGluZyB0byB0aGlzCgl2bGFuIHRydW5rLiIKICAgIDo6PSB7IGJlZ2Vtb3RWbGFuVHJ1bmtF bnRyeSAyIH0KCmJlZ2Vtb3RWbGFuUGFyZW50SWZId1RhZ1N1cHBvcnRlZCBPQkpFQ1QtVFlQRQog ICAgU1lOVEFYCVRydXRoVmFsdWUKICAgIE1BWC1BQ0NFU1MJcmVhZC1vbmx5CiAgICBTVEFUVVMJ Y3VycmVudAogICAgREVTQ1JJUFRJT04KCSJUaGUgdmFsdWUgb2YgdGhpcyBvYmplY3QgaW5kaWNh dGVzIHdoZXRoZXIgdGhlIHBhcmVudAoJaW50ZXJmYWNlIG9mIHRoZSB2bGFuIHRydW5rIHN1cHBv cnRzIHZsYW4gdGFnZ2luZwoJbmF0aXZlbHkuIgogICAgOjo9IHsgYmVnZW1vdFZsYW5UcnVua0Vu dHJ5IDMgfQoKYmVnZW1vdFZsYW5QYXJlbnRJZkh3VGFnRW5hYmxlZCBPQkpFQ1QtVFlQRQogICAg U1lOVEFYCUVuYWJsZWRTdGF0dXMKICAgIE1BWC1BQ0NFU1MJcmVhZC13cml0ZQogICAgU1RBVFVT CWN1cnJlbnQKICAgIERFU0NSSVBUSU9OCgkiVGhlIHZhbHVlIG9mIHRoaXMgb2JqZWN0IGluZGlj YXRlcyB3aGV0aGVyIHRoZSBwYXJlbnQKCWludGVyZmFjZSBvZiB0aGUgdmxhbiB0cnVuayBpcyBj b25maWd1cmVkIHRvIGRvIHZsYW4KCXRhZ2dpbmcgbmF0aXZlbHkuIgogICAgOjo9IHsgYmVnZW1v dFZsYW5UcnVua0VudHJ5IDQgfQoKYmVnZW1vdFZsYW5QYXJlbnRJZkh3TXR1U3VwcG9ydGVkIE9C SkVDVC1UWVBFCiAgICBTWU5UQVgJVHJ1dGhWYWx1ZQogICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkK ICAgIFNUQVRVUwljdXJyZW50CiAgICBERVNDUklQVElPTgoJIlRoZSB2YWx1ZSBvZiB0aGlzIG9i amVjdCBpbmRpY2F0ZXMgd2hldGhlciB0aGUgcGFyZW50CglpbnRlcmZhY2Ugb2YgdGhlIHZsYW4g dHJ1bmsgc3VwcG9ydHMgb3ZlcnNpemVkIGZyYW1lcwoJbmF0aXZlbHkuIgogICAgOjo9IHsgYmVn ZW1vdFZsYW5UcnVua0VudHJ5IDUgfQoKYmVnZW1vdFZsYW5QYXJlbnRJZkh3TXR1RW5hYmxlZCBP QkpFQ1QtVFlQRQogICAgU1lOVEFYCUVuYWJsZWRTdGF0dXMKICAgIE1BWC1BQ0NFU1MJcmVhZC13 cml0ZQogICAgU1RBVFVTCWN1cnJlbnQKICAgIERFU0NSSVBUSU9OCgkiVGhlIHZhbHVlIG9mIHRo aXMgb2JqZWN0IGluZGljYXRlcyB3aGV0aGVyIHRoZSBwYXJlbnQKCWludGVyZmFjZSBvZiB0aGUg dmxhbiB0cnVuayBpcyBjb25maWd1cmVkIHRvIHJlY2VpdmUKCWV4dGVuZGVkIGZyYW1lcyBpbiBo YXJkd2FyZS4iCiAgICA6Oj0geyBiZWdlbW90VmxhblRydW5rRW50cnkgNiB9CgpiZWdlbW90Vmxh blRydW5rTWVtYmVycyBPQkpFQ1QtVFlQRQogICAgU1lOVEFYCUlOVEVHRVIgKDEuLjQwOTYpCiAg ICBNQVgtQUNDRVNTCXJlYWQtb25seQogICAgU1RBVFVTCWN1cnJlbnQKICAgIERFU0NSSVBUSU9O CgkiVGhlIG51bWJlciBvZiB2bGFuIGludGVyZmFjZXMgY3VycmVudGx5IGJlbG9uZ2luZyB0bwoJ dGhpcyB0cnVuay4iCiAgICA6Oj0geyBiZWdlbW90VmxhblRydW5rRW50cnkgNyB9CgpiZWdlbW90 VmxhblRydW5rTWVtYmVyVmlkcyBPQkpFQ1QtVFlQRQogICAgU1lOVEFYCUJlZ2Vtb3RWbGFuQml0 TWFwCiAgICBNQVgtQUNDRVNTCXJlYWQtb25seQogICAgU1RBVFVTCWN1cnJlbnQKICAgIERFU0NS SVBUSU9OCgkiVGhlIHNldCBvZiBWbGFuSWRzIGZvciB3aGljaCBhIGZyYW1lLCBjb250YWluaW5n IG9uZQoJb2YgdGhlc2UgaXMgYmVpbmcgcHJvY2Nlc3NlZCByYXRoZXIgdGhhbiBkaXNjYXJlZCBi eSB0aGUKCXBhcmVudCBpbnRlcmZhY2Ugb2YgdGhlIHZsYW4gdHJ1bmsuIgogICAgOjo9IHsgYmVn ZW1vdFZsYW5UcnVua0VudHJ5IDggfQoKLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAtLQotLSB0aGUgYmVnZW1vdCBWbGFuIGludGVy ZmFjZXMgdGFibGUKLS0gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSAtLQoKYmVnZW1vdFZsYW5JbnRlcmZhY2VUYWJsZSBPQkpFQ1QtVFlQ RQogICAgU1lOVEFYCVNFUVVFTkNFIE9GIEJlZ2Vtb3RWbGFuSW50ZXJmYWNlRW50cnkKICAgIE1B WC1BQ0NFU1MJbm90LWFjY2Vzc2libGUKICAgIFNUQVRVUwljdXJyZW50CiAgICBERVNDUklQVElP TgoJIkEgdGFibGUgY29udGFpbmluZyBvZiBpbmZvcm1hdGlvbiBmb3IgdGhlIHZsYW4KCWludGVy ZmFjZXMgb24gdGhlIG1hbmFnZWQgZGV2aWNlLiIKICAgIDo6PSB7IGJlZ2Vtb3RWbGFuSW50ZXJm YWNlcyAxIH0KCmJlZ2Vtb3RWbGFuSW50ZXJmYWNlRW50cnkgT0JKRUNULVRZUEUKICAgIFNZTlRB WAlCZWdlbW90VmxhbkludGVyZmFjZUVudHJ5CiAgICBNQVgtQUNDRVNTCW5vdC1hY2Nlc3NpYmxl CiAgICBTVEFUVVMJY3VycmVudAogICAgREVTQ1JJUFRJT04KCSJBIGxpc3Qgb2YgaW5mb3JtYXRp b24gZm9yIHRoZSB2bGFuIGludGVyZmFjZXMgb24KCXRoZSBtYW5hZ2VkIGRldmljZS4iCiAgICBJ TkRFWAl7IGJlZ2Vtb3RWbGFuVHJ1bmtJbmRleCwgYmVnZW1vdFZsYW5JZk5hbWUgfQogICAgOjo9 IHsgYmVnZW1vdFZsYW5JbnRlcmZhY2VUYWJsZSAxIH0KCkJlZ2Vtb3RWbGFuSW50ZXJmYWNlRW50 cnkgOjo9IFNFUVVFTkNFIHsKICAgIGJlZ2Vtb3RWbGFuSWZOYW1lCQlPQ1RFVCBTVFJJTkcsCiAg ICBiZWdlbW90VmxhbklmVmlkCQlJTlRFR0VSLAogICAgYmVnZW1vdFZsYW5JZlByb3RvCQlJTlRF R0VSLAogICAgYmVnZW1vdFZsYW5JZlN0YXR1cwkJUm93U3RhdHVzLAogICAgYmVnZW1vdFZsYW5J ZkVuY2FwbGVuCUlOVEVHRVIsCiAgICBiZWdlbW90VmxhbklmTXR1RnVkZ2UJSU5URUdFUiwKICAg IGJlZ2Vtb3RWbGFuSWZNaW5UVQkJSU5URUdFUiAgIAp9CgpiZWdlbW90VmxhbklmTmFtZSBPQkpF Q1QtVFlQRQogICAgU1lOVEFYCU9DVEVUIFNUUklORyAoU0laRSgxLi4xNikpCiAgICBNQVgtQUND RVNTCXJlYWQtd3JpdGUKICAgIFNUQVRVUwljdXJyZW50CiAgICBERVNDUklQVElPTgoJIlRoZSBu YW1lIG9mIHRoZSB2bGFuIGludGVyZmFjZS4iCiAgICA6Oj0geyBiZWdlbW90VmxhbkludGVyZmFj ZUVudHJ5IDEgfQoKYmVnZW1vdFZsYW5JZlZpZCBPQkpFQ1QtVFlQRQogICAgU1lOVEFYCUlOVEVH RVIgKDEuLjQwOTUpCiAgICBNQVgtQUNDRVNTCXJlYWQtd3JpdGUKICAgIFNUQVRVUwljdXJyZW50 CiAgICBERVNDUklQVElPTgoJIlRoZSB2bGFuIHRhZyB0aGF0IGlzIGFwcGxpZWQgb24gcGFja2V0 cyBsZWF2aW5nCgl0aGlzIGludGVyZmFjZS4iCiAgICA6Oj0geyBiZWdlbW90VmxhbkludGVyZmFj ZUVudHJ5IDIgfQoKYmVnZW1vdFZsYW5JZlByb3RvIE9CSkVDVC1UWVBFCiAgICBTWU5UQVgJSU5U RUdFUiAoMS4uNjU1MzUpCiAgICBNQVgtQUNDRVNTCXJlYWQtd3JpdGUKICAgIFNUQVRVUwljdXJy ZW50CiAgICBERVNDUklQVElPTgoJIlRoZSBlbmNhcHN1bGF0aW9uIGV0aGVydHlwZSB0aGF0IGlz IGFwcGxpZWQgb24KCXBhY2tldHMgbGVhdmluZyB0aGlzIGludGVyZmFjZS4iCiAgICA6Oj0geyBi ZWdlbW90VmxhbkludGVyZmFjZUVudHJ5IDMgfQoKYmVnZW1vdFZsYW5JZlN0YXR1cyBPQkpFQ1Qt VFlQRQogICAgU1lOVEFYCVJvd1N0YXR1cwogICAgTUFYLUFDQ0VTUwlyZWFkLWNyZWF0ZQogICAg U1RBVFVTCWN1cnJlbnQKICAgIERFU0NSSVBUSU9OCgkiVXNlZCB0byBjcmVhdGUvZGVzdHJveSB2 bGFuIGludGVyZmFjZXMgb24gdGhlCgltYW5hZ2VkIGRldmljZS4iCiAgICA6Oj0geyBiZWdlbW90 VmxhbkludGVyZmFjZUVudHJ5IDQgfQoKYmVnZW1vdFZsYW5JZkVuY2FwbGVuIE9CSkVDVC1UWVBF CiAgICBTWU5UQVgJSU5URUdFUgogICAgTUFYLUFDQ0VTUwlyZWFkLXdyaXRlCiAgICBTVEFUVVMJ Y3VycmVudAogICAgREVTQ1JJUFRJT04KCSJUaGUgbGVuZ3RoIG9mIGVuY2Fwc3VsYXRpb24gZGF0 YSB0aGF0IGlzIGFwcGxpZWQgb24KCXBhY2tldHMgbGVhdmluZyB0aGlzIGludGVyZmFjZS4iCiAg ICA6Oj0geyBiZWdlbW90VmxhbkludGVyZmFjZUVudHJ5IDUgfQoKYmVnZW1vdFZsYW5JZk10dUZ1 ZGdlIE9CSkVDVC1UWVBFCiAgICBTWU5UQVgJSU5URUdFUgogICAgTUFYLUFDQ0VTUwlyZWFkLXdy aXRlCiAgICBTVEFUVVMJY3VycmVudAogICAgREVTQ1JJUFRJT04KCSJUaGUgdmFsdWUgYnkgd2hp Y2ggdGhlIE1UVSBpcyByZWR1Y2VkIG9uIHRoZSBwYXJlbnQKCWludGVyZmFjZSBvZiB0aGlzIHZs YW4gaW50ZXJmYWNlLiIgCiAgICA6Oj0geyBiZWdlbW90VmxhbkludGVyZmFjZUVudHJ5IDYgfQoK YmVnZW1vdFZsYW5JZk1pblRVIE9CSkVDVC1UWVBFCiAgICBTWU5UQVgJSU5URUdFUgogICAgTUFY LUFDQ0VTUwlyZWFkLXdyaXRlCiAgICBTVEFUVVMJY3VycmVudAogICAgREVTQ1JJUFRJT04KCSJU aGUgbWludW11bSB0cmFuc21pc3Npb24gdW5pdCBvZiB0aGUgdmxhbiBpbnRlcmZhY2UuIgogICAg Ojo9IHsgYmVnZW1vdFZsYW5JbnRlcmZhY2VFbnRyeSA3IH0KCi0tIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gLS0KLS0gdGhlIGJlZ2Vt b3QgVmxhbiBpbnRlcmZhY2Ugc3RhdGlzdGljcyB0YWJsZQotLSAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIC0tCgpiZWdlbW90Vmxhbklm U3RhdHNUYWJsZSBPQkpFQ1QtVFlQRQogICAgU1lOVEFYCVNFUVVFTkNFIE9GIEJlZ2Vtb3RWbGFu SWZTdGF0c0VudHJ5CiAgICBNQVgtQUNDRVNTCW5vdC1hY2Nlc3NpYmxlCiAgICBTVEFUVVMJY3Vy cmVudAogICAgREVTQ1JJUFRJT04KCSJBIHRhYmxlIGNvbnRhaW5pbmcgc3RhdGlzdGljcyBmb3Ig dGhlIHZsYW4KCWludGVyZmFjZXMgb24gdGhlIG1hbmFnZWQgZGV2aWNlLiIKICAgIDo6PSB7IGJl Z2Vtb3RWbGFuU3RhdGlzdGljcyAxIH0KCmJlZ2Vtb3RWbGFuSWZTdGF0c0VudHJ5IE9CSkVDVC1U WVBFCiAgICBTWU5UQVgJQmVnZW1vdFZsYW5JZlN0YXRzRW50cnkKICAgIE1BWC1BQ0NFU1MJbm90 LWFjY2Vzc2libGUKICAgIFNUQVRVUwljdXJyZW50CiAgICBERVNDUklQVElPTgoJIkEgbGlzdCBv ZiBzdGF0aXN0aWNzIGZvciBhIHZsYW4gaW50ZXJmYWNlIG9uCgl0aGUgbWFuYWdlZCBkZXZpY2Uu IgogICAgQVVHTUVOVFMgeyBiZWdlbW90VmxhbkludGVyZmFjZUVudHJ5IH0KICAgIDo6PSB7IGJl Z2Vtb3RWbGFuSWZTdGF0c1RhYmxlIDEgfQoKQmVnZW1vdFZsYW5JZlN0YXRzRW50cnkgOjo9IFNF UVVFTkNFIHsKICAgIGJlZ2Vtb3RWbGFuSWZJbkZyYW1lcwkJQ291bnRlcjMyLAogICAgYmVnZW1v dFZsYW5JZk91dEZyYW1lcwkJQ291bnRlcjMyLAogICAgYmVnZW1vdFZsYW5JZkluRGlzY2FyZHMJ CUNvdW50ZXIzMiwKICAgIGJlZ2Vtb3RWbGFuSWZJbk92ZXJmbG93RnJhbWVzIAlDb3VudGVyMzIs CiAgICBiZWdlbW90VmxhbklmT3V0T3ZlcmZsb3dGcmFtZXMgCUNvdW50ZXIzMiwKICAgIGJlZ2Vt b3RWbGFuSWZJbk92ZXJmbG93RGlzY2FyZHMgCUNvdW50ZXIzMgp9CgpiZWdlbW90VmxhbklmSW5G cmFtZXMgT0JKRUNULVRZUEUKICAgIFNZTlRBWAlDb3VudGVyMzIKICAgIE1BWC1BQ0NFU1MJcmVh ZC1vbmx5CiAgICBTVEFUVVMJY3VycmVudAogICAgREVTQ1JJUFRJT04KCSJUaGUgbnVtYmVyIG9m IHZhbGlkIGZyYW1lcyByZWNlaXZlZCBvbiB0aGlzCgl2bGFuIGludGVyZmFjZSB3aGljaCB3ZXJl IGNsYXNzaWZpZWQgYXMgYmVsb25naW5nCgl0byB0aGlzIFZMQU4uIgogICAgOjo9IHsgYmVnZW1v dFZsYW5JZlN0YXRzRW50cnkgMSB9CgpiZWdlbW90VmxhbklmT3V0RnJhbWVzIE9CSkVDVC1UWVBF CiAgICBTWU5UQVgJQ291bnRlcjMyCiAgICBNQVgtQUNDRVNTCXJlYWQtb25seQogICAgU1RBVFVT CWN1cnJlbnQKICAgIERFU0NSSVBUSU9OCgkiVGhlIG51bWJlciBvZiB2YWxpZCBmcmFtZXMgdHJh bnNtaXR0ZWQgYnkgdGhpcwoJdmxhbiBpbnRlcmZhY2UuIgogICAgOjo9IHsgYmVnZW1vdFZsYW5J ZlN0YXRzRW50cnkgMiB9CgpiZWdlbW90VmxhbklmSW5EaXNjYXJkcyBPQkpFQ1QtVFlQRQogICAg U1lOVEFYCUNvdW50ZXIzMgogICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkKICAgIFNUQVRVUwljdXJy ZW50CiAgICBERVNDUklQVElPTgoJIlRoZSBudW1iZXIgb2YgdmFsaWQgZnJhbWVzIHJlY2VpdmVk IG9uIHRoaXMKCXZsYW4gaW50ZXJmYWNlIHdoaWNoIHdlcmUgY2xhc3NpZmllZCBhcyBiZWxvbmdp bmcKCXRvIHRoaXMgVkxBTiBidXQgd2VyZSBkaXNjYXJkZWQuIgogICAgOjo9IHsgYmVnZW1vdFZs YW5JZlN0YXRzRW50cnkgMyB9CgpiZWdlbW90VmxhbklmSW5PdmVyZmxvd0ZyYW1lcyBPQkpFQ1Qt VFlQRQogICAgU1lOVEFYCUNvdW50ZXIzMgogICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkKICAgIFNU QVRVUwljdXJyZW50CiAgICBERVNDUklQVElPTgoJIlRoZSBudW1iZXIgb2YgdGltZXMgdGhlIGFz c29jaWF0ZWQKCWJlZ2Vtb3RWbGFuSWZJbkZyYW1lcyBjb3VudGVyIGhhcyBvdmVyZmxvd2VkLiIK ICAgIDo6PSB7IGJlZ2Vtb3RWbGFuSWZTdGF0c0VudHJ5IDQgfQoKYmVnZW1vdFZsYW5JZk91dE92 ZXJmbG93RnJhbWVzIE9CSkVDVC1UWVBFCiAgICBTWU5UQVgJQ291bnRlcjMyCiAgICBNQVgtQUND RVNTCXJlYWQtb25seQogICAgU1RBVFVTCWN1cnJlbnQKICAgIERFU0NSSVBUSU9OCgkiVGhlIG51 bWJlciBvZiB0aW1lcyB0aGUgYXNzb2NpYXRlZAoJYmVnZW1vdFZsYW5JZk91dEZyYW1lcyBjb3Vu dGVyIGhhcyBvdmVyZmxvd2VkLiIKICAgIDo6PSB7IGJlZ2Vtb3RWbGFuSWZTdGF0c0VudHJ5IDUg fQoKYmVnZW1vdFZsYW5JZkluT3ZlcmZsb3dEaXNjYXJkcyBPQkpFQ1QtVFlQRQogICAgU1lOVEFY CUNvdW50ZXIzMgogICAgTUFYLUFDQ0VTUwlyZWFkLW9ubHkKICAgIFNUQVRVUwljdXJyZW50CiAg ICBERVNDUklQVElPTgoJIlRoZSBudW1iZXIgb2YgdGltZXMgdGhlIGFzc29jaWF0ZWQKCWJlZ2Vt b3RWbGFuSWZJbkRpc2NhcmRzIGNvdW50ZXIgaGFzIG92ZXJmbG93ZWQuIgogICAgOjo9IHsgYmVn ZW1vdFZsYW5JZlN0YXRzRW50cnkgNiB9CgpFTkQKCg== ------=_Part_47269_24053843.1168360706882-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 9 18:54: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 7D51216A40F for ; Tue, 9 Jan 2007 18:54:39 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7A813C459 for ; Tue, 9 Jan 2007 18:54:39 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l09IscCC000746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 9 Jan 2007 10:54:39 -0800 X-Auth-Received: from [192.168.0.101] (dsl254-013-145.sea1.dsl.speakeasy.net [216.254.13.145]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l09IscQf000659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 Jan 2007 10:54:38 -0800 Message-ID: <45A3E4EC.5030403@u.washington.edu> Date: Tue, 09 Jan 2007 10:54:36 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.9 (X11/20061226) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.9.104433 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Why is rpcbind using port 906? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jan 2007 18:54:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The last time I checked rpcbind was supposed to run on port 111 [root@hoover /home/gcooper]# uname -a FreeBSD hoover.localdomain 6.1-RELEASE-p11 FreeBSD 6.1-RELEASE-p11 #18: Thu Dec 21 09:00:56 PST 2006 gcooper@hoover.localdomain:/usr/obj/usr/src/sys/HOOVER i386 [root@hoover /home/gcooper]# lsof | grep rpcbind | grep IPv lsof: WARNING: compiled for FreeBSD release 6.1-RELEASE-p10; this is 6.1-RELEASE-p11. rpcbind 375 root 4u IPv6 0xc67515a0 0t0 UDP *:* rpcbind 375 root 6u IPv6 0xc6751438 0t0 UDP *:sunrpc rpcbind 375 root 7u IPv6 0xc67512d0 0t0 UDP *:1023 rpcbind 375 root 8u IPv6 0xc67bb000 0t0 TCP *:sunrpc (LISTEN) rpcbind 375 root 9u IPv4 0xc6751168 0t0 UDP *:sunrpc rpcbind 375 root 10u IPv4 0xc6751000 0t0 UDP *:906 rpcbind 375 root 11u IPv4 0xc67bacb0 0t0 TCP *:sunrpc (LISTEN) Is there some way to change the default port to something static? manpage doesn't say so, but there may be an option. Annoying, but it appears that some smbclients _need_ to have rpcbind's port unblocked by a firewall; blocking it broke some functionality with mounting SMB shares on non-Windows clients. TIA, - -Garrett -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo+TrEnKyINQw/HARArH0AKCm07971prNO+/MYXIEuISO+bRTowCgp8qL Qs1VFiQ61nuAu6Cx8l8f3FE= =RhKO -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Jan 9 20:50:13 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 4D99016A40F; Tue, 9 Jan 2007 20:50:13 +0000 (UTC) (envelope-from robertw@ssginnovations.com) Received: from ssg1.ssginnovations.com (ssginnovations.com [205.145.135.135]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8DB13C455; Tue, 9 Jan 2007 20:50:12 +0000 (UTC) (envelope-from robertw@ssginnovations.com) Received: from server1.ssgi.local (unknown [205.145.129.164]) by ssg1.ssginnovations.com (Mail Daemon) with ESMTP id 383D0406E; Tue, 9 Jan 2007 15:51:33 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jan 2007 15:50:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <85D4F2C294E8434CA0AF77574153268620304A@server1.ssgi.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bge autoneg full-duplex modes missing on 6.2-RC2 (cause: IPMI patch) Thread-Index: Acc0BiJgR8vgOErpQTu3Othen4yjIwAEnfnQ From: "Robert Wojciechowski" To: Cc: freebsd-stable@freebsd.org Subject: RE: bge autoneg full-duplex modes missing on 6.2-RC2 (cause: IPMI patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 20:50:13 -0000 > I'm having problems on one of two identical servers which have dual > Broadcom BCM5704s onboard. The problem is that one of the servers is not > linking at 100baseTX-FDX on the bge0 interface no matter what I do > (forced, limited advertising on the switch, etc). >=20 > Upon further investigation I noticed this in dmesg: >=20 > bge0: mem 0xfe7f0000-0xfe7fffff > irq 49 at device 3.0 on pci2 > miibus1: on bge0 > brgphy0: on miibus1 > brgphy0: 10baseT, 100baseTX, 1000baseTX, 1000baseTX-FDX, auto > bge0: Ethernet address: 00:30:48:56:93:32 > bge1: mem 0xfe7e0000-0xfe7effff > irq 50 at device 3.1 on pci2 > miibus2: on bge1 > brgphy1: on miibus2 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge1: Ethernet address: 00:30:48:56:93:33 >=20 > Notice 10baseTX-FDX and 100baseTX-FDX are missing from brgphy0! The > other server doesn't have this problem at all and is running off the > same kernel and identical hardware. >=20 > This is on amd64 and 6.2-RC2 as of Jan 8th. Thanks! >=20 I may have found out why this is happening. I backed out Dan Ambrisko's bge IPMI patches but I forgot to reset my switch's negotiation configuration. I reset everything back to autoneg with clean RELENG_6_2 sources and everything links up as expected. After looking into a bit, it seems the problem is indeed related to the MII PHY media detection being flaky on bge0 (but operating correctly for bge1) when using the IPMI patch.=20 If I reboot over and over 10baseTX disappears and appears intermittently, as well as all the modes I'm looking for such as 100baseTX-FDX, albeit less often. Perhaps this is due to a race of some sort with the IPMI patch touching the PHY and the PHY media detection? I'm still running on the patch from http://www.ambrisko.com/doug/bge_ipmi_3.patch, modified slightly to patch cleanly on RELENG_6_2. I tried RELENG_6 but the system froze on boot while initializing bge and I'm not sure why (something I'll trace down after this). I see that it is also committed to HEAD but I haven't tried that version. Right now I temporarily patched mii_physubr.c to force it to advertise 100baseTX-FDX and it correctly links up. Any ideas? Thanks!! -- Robert From owner-freebsd-net@FreeBSD.ORG Tue Jan 9 21:40:36 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 4A04716A407 for ; Tue, 9 Jan 2007 21:40:36 +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 3A76A13C459 for ; Tue, 9 Jan 2007 21:40:36 +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 l09LeZsT086581 for ; Tue, 9 Jan 2007 21:40:35 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l09LeZFi086580; Tue, 9 Jan 2007 21:40:35 GMT (envelope-from gnats) Date: Tue, 9 Jan 2007 21:40:35 GMT Message-Id: <200701092140.l09LeZFi086580@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Bruce A. Mah" Cc: Subject: Re: kern/107358: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Bruce A. Mah" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 21:40:36 -0000 The following reply was made to PR kern/107358; it has been noted by GNATS. From: "Bruce A. Mah" To: bug-followup@freebsd.org Cc: tony@lava.net Subject: Re: kern/107358: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) Date: Tue, 09 Jan 2007 13:33:18 -0800 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3807A02A1C245B21A0F49067 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Mark Linimon wrote: > Old Synopsis: IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 > New Synopsis: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regre= ssion) >=20 > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Mon Jan 1 13:28:53 UTC 2007 > Responsible-Changed-Why:=20 > Perhaps someone on -net has an idea. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D107358 This looks to me like it could be a duplicate of kern/103415, which was fixed on HEAD and RELENG_6 (prior to RELENG_6_2 creation, so 6.2 should be OK, as well as both of the 6.2-RC snapshots). If this is true, a possible fix might be to apply revision 1.51.2.10 of src/sys/netinet6/in6= =2Ec. I don't really have an environment conducive to testing 6to4, so this hypothesis is completely untested. Bruce. --------------enig3807A02A1C245B21A0F49067 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.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpAoj2MoxcVugUsMRAmvSAKD6Ob8UcClH1vV56IOw8GXRwXoWHACaA/s7 rmEydKBElBocJJ34i1emxK4= =Kppv -----END PGP SIGNATURE----- --------------enig3807A02A1C245B21A0F49067-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 10 00:14:18 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 0F23816A403; Wed, 10 Jan 2007 00:14:18 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.freebsd.org (Postfix) with ESMTP id 807F613C441; Wed, 10 Jan 2007 00:14:17 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.8/8.13.8) with ESMTP id l0A0EGKp039636; Tue, 9 Jan 2007 16:14:16 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20070109235649.GC5246@lath.rinet.ru> Date: Tue, 09 Jan 2007 16:14:16 -0800 (PST) From: John Polstra To: Oleg Bulyzhin X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (blake.polstra.com [64.81.189.66]); Tue, 09 Jan 2007 16:14:16 -0800 (PST) Cc: Doug Barton , net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jan 2007 00:14:18 -0000 On 09-Jan-2007 Oleg Bulyzhin wrote: > On Mon, Jan 08, 2007 at 04:33:29PM -0800, John Polstra wrote: >> On 30-Dec-2006 Bruce Evans wrote: >> > More debugging showed that almost any of the reads of the phy in mii >> > cause an input error, >> >> The errors appear to be caused by the code in bge_miibus_{read,write}reg >> that clears and then restores the BGE_MIMODE_AUTOPOLL bit of the >> BGE_MI_MODE register. If you remove those chunks of code, the errors >> go away even when mii_tick is called periodically, and the chip >> performs quite well under heavy traffic load in both directions. > > I've seen this kind of ierrors (LINK_LOST error flag in rx buffer descriptor) > only on bcm5701 chip. Other chips i tried (5700 and 5721) seems are not > affected. The packet loss I observed was on a 5704. I didn't check the LINK_LOST flags. >> I agree with you that we shouldn't need to call mii_tick periodically, >> except perhaps for a few very old variants of the Broadcom chip. >> >> John > mii_tick periodic calls are requried - MII layer use it for link > autonegotiation. Though i guess it's possible to avoid phy access if we > have link up. > I see two different ways to solve this: > 1) convert driver for using phy interrupts as default (like linux driver), > thus BGE_MI_MODE read/write can be avoided. > 2) do not touch PHY inside bge_tick() if we have link up. Actually, this > check was in driver but was removed as workaround of existed link state > issues (due to some bugs in if_bge.c and brgphy.c link loss events were > detected with few seconds delay or even not detected at all). > Those bugs are fixed now, so we can revive this check (bge_link_upd() can > be simplified a bit too). I've been using #2 today, and it's working well so far. I implemented it like this. (Ignore the version numbers; I'm working in a private repository.) --- if_bge.c 8 Jan 2007 22:46:51 -0000 1.26 +++ if_bge.c 9 Jan 2007 22:52:43 -0000 1.27 @@ -3122,8 +3122,8 @@ bge_tick(void *xsc) if ((sc->bge_flags & BGE_FLAG_TBI) == 0) { mii = device_get_softc(sc->bge_miibus); - /* Don't mess with the PHY in IPMI/ASF mode */ - if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) + /* Don't mess with the PHY unless link is down. */ + if (!sc->bge_link) mii_tick(mii); } else { /* John From owner-freebsd-net@FreeBSD.ORG Wed Jan 10 00:31:21 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 040B816A40F; Wed, 10 Jan 2007 00:31:21 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0AAE913C448; Wed, 10 Jan 2007 00:31:18 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.8/8.13.8) with ESMTP id l09NupHI009880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Jan 2007 02:56:51 +0300 (MSK) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.8/8.13.8/Submit) id l09NunBl009879; Wed, 10 Jan 2007 02:56:49 +0300 (MSK) (envelope-from oleg) Date: Wed, 10 Jan 2007 02:56:49 +0300 From: Oleg Bulyzhin To: John Polstra Message-ID: <20070109235649.GC5246@lath.rinet.ru> References: <20061231061903.J47883@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Doug Barton , net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jan 2007 00:31:21 -0000 On Mon, Jan 08, 2007 at 04:33:29PM -0800, John Polstra wrote: > On 30-Dec-2006 Bruce Evans wrote: > > More debugging showed that almost any of the reads of the phy in mii > > cause an input error, > > The errors appear to be caused by the code in bge_miibus_{read,write}reg > that clears and then restores the BGE_MIMODE_AUTOPOLL bit of the > BGE_MI_MODE register. If you remove those chunks of code, the errors > go away even when mii_tick is called periodically, and the chip > performs quite well under heavy traffic load in both directions. I've seen this kind of ierrors (LINK_LOST error flag in rx buffer descriptor) only on bcm5701 chip. Other chips i tried (5700 and 5721) seems are not affected. > > I know that some of the *_MODE registers in these chips cause problems > if they are read, so I tried putting a shadow copy of the register > into the softc and doing only writes to the hardware register. But > that didn't help in this case. > > I seem to recall having heard that Broadcom discourages the use of > PHY autopolling for unspecified reasons. The Linux driver from > Broadcom had code to support it, but it was never actually used for > any devices. The current Linux driver uses autopolling only for the > Altima chip that's present on the inexpensive Netgear GA302T card. If i remember right, Broadcom recommends using phy interrupts for tracing link events, though auto-polling noted as alternative method for that. > > I agree with you that we shouldn't need to call mii_tick periodically, > except perhaps for a few very old variants of the Broadcom chip. > > John mii_tick periodic calls are requried - MII layer use it for link autonegotiation. Though i guess it's possible to avoid phy access if we have link up. I see two different ways to solve this: 1) convert driver for using phy interrupts as default (like linux driver), thus BGE_MI_MODE read/write can be avoided. 2) do not touch PHY inside bge_tick() if we have link up. Actually, this check was in driver but was removed as workaround of existed link state issues (due to some bugs in if_bge.c and brgphy.c link loss events were detected with few seconds delay or even not detected at all). Those bugs are fixed now, so we can revive this check (bge_link_upd() can be simplified a bit too). -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-net@FreeBSD.ORG Wed Jan 10 00:42: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 10EBC16A412; Wed, 10 Jan 2007 00:42:03 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from sumo.dreamhost.com (sumo.dreamhost.com [66.33.216.29]) by mx1.freebsd.org (Postfix) with ESMTP id EF22813C44C; Wed, 10 Jan 2007 00:42:02 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a14.dreamhost.com (sd-green-bigip-177.dreamhost.com [208.97.132.177]) by sumo.dreamhost.com (Postfix) with ESMTP id 51DF8178AE7; Tue, 9 Jan 2007 16:10:24 -0800 (PST) Received: from sauron.lan.box (unknown [200.180.177.239]) by spunkymail-a14.dreamhost.com (Postfix) with ESMTP id 15307190E2C; Tue, 9 Jan 2007 16:10:20 -0800 (PST) Date: Tue, 9 Jan 2007 22:10:19 -0200 From: Ricardo Nabinger Sanchez To: syrinx@FreeBSD.org Message-Id: <20070109221019.7e0e3303.rnsanchez@wait4.org> In-Reply-To: <61b573980701090838q415d6c6fx75b7de73eeace9fd@mail.gmail.com> References: <61b573980701090838q415d6c6fx75b7de73eeace9fd@mail.gmail.com> Organization: SYS_WAIT4 X-Mailer: Sylpheed 2.3.0 (GTK+ 2.10.6; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: RFC: a MIB for a SNMP vlan monitoring module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jan 2007 00:42:03 -0000 On Tue, 9 Jan 2007 18:38:26 +0200 "Shteryana Shopova" wrote: > Work is about to start on a vlan monitoring module for bsnmpd(1) - I'm > attaching the private BEGEMOT MIB that the module will implement. Any > comments or suggestions are very welcome. I missed a column to track errors/corrupted packets in the begemotVlanIfStatsTable. :) Other than that, it looks nice to me. Some nits follow (mostly whitespace). I'd rather read "VLAN" instead of "vlan" throughout the descriptions, but I didn't change them. --- BEGEMOT-VLAN-MIB.txt.orig Tue Jan 9 21:48:51 2007 +++ BEGEMOT-VLAN-MIB.txt Tue Jan 9 22:03:47 2007 @@ -179,7 +179,7 @@ -- begemotVlanParentIfName object is redundant since its value can -- be obtained by a SNMP client by invoking a GET on the ifName -- object with an index of the corresponding value of --- begemotVlanTrunkIndex, but is included for convenience. +-- begemotVlanTrunkIndex, but is included for convenience. begemotVlanParentIfName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1..16)) @@ -280,7 +280,7 @@ begemotVlanIfStatus RowStatus, begemotVlanIfEncaplen INTEGER, begemotVlanIfMtuFudge INTEGER, - begemotVlanIfMinTU INTEGER + begemotVlanIfMinTU INTEGER } begemotVlanIfName OBJECT-TYPE @@ -333,7 +333,7 @@ STATUS current DESCRIPTION "The value by which the MTU is reduced on the parent - interface of this vlan interface." + interface of this vlan interface." ::= { begemotVlanInterfaceEntry 6 } begemotVlanIfMinTU OBJECT-TYPE @@ -341,7 +341,7 @@ MAX-ACCESS read-write STATUS current DESCRIPTION - "The minumum transmission unit of the vlan interface." + "The minimum transmission unit of the vlan interface." ::= { begemotVlanInterfaceEntry 7 } -- ---------------------------------------------------------- -- -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-net@FreeBSD.ORG Wed Jan 10 10:05: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 C0AFD16A407; Wed, 10 Jan 2007 10:05:26 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD1013C441; Wed, 10 Jan 2007 10:05:26 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 10:53:21 +0100 Date: Wed, 10 Jan 2007 10:53:21 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: Shteryana Shopova In-Reply-To: <61b573980701090838q415d6c6fx75b7de73eeace9fd@mail.gmail.com> Message-ID: <20070110104909.T49466@knop-beagle.kn.op.dlr.de> References: <61b573980701090838q415d6c6fx75b7de73eeace9fd@mail.gmail.com> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 10 Jan 2007 09:53:21.0904 (UTC) FILETIME=[29CB2F00:01C7349D] Cc: freebsd-net@freebsd.org, tsvetan@erenditsov.com Subject: Re: RFC: a MIB for a SNMP vlan monitoring module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 10:05:26 -0000 Hi, On Tue, 9 Jan 2007, Shteryana Shopova wrote: SS>Work is about to start on a vlan monitoring module for bsnmpd(1) - I'm SS>attaching the private BEGEMOT MIB that the module will implement. Any SS>comments or suggestions are very welcome. I'm not an expert on the VLAN stuff, so I cannot comment on this. The only thing I see is that you might add a ...DiscontinuityTime variable to the statistics table so that a managemnt station can correctly catch fast destroy/create cycles on the VLANs (if that makes sense). You might want to look at ifCounterDiscontinuityTime in ifMIB:ifXTable. harti From owner-freebsd-net@FreeBSD.ORG Wed Jan 10 10:20:25 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 8BD5D16A40F for ; Wed, 10 Jan 2007 10:20:25 +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 37CE413C457 for ; Wed, 10 Jan 2007 10:20:25 +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 l0AAKP2P047528 for ; Wed, 10 Jan 2007 10:20:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0AAKOMN047526; Wed, 10 Jan 2007 10:20:24 GMT (envelope-from gnats) Date: Wed, 10 Jan 2007 10:20:24 GMT Message-Id: <200701101020.l0AAKOMN047526@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Antonio Querubin Cc: Subject: Re: kern/107358: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Antonio Querubin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 10:20:25 -0000 The following reply was made to PR kern/107358; it has been noted by GNATS. From: Antonio Querubin To: "Bruce A. Mah" Cc: bug-followup@freebsd.org Subject: Re: kern/107358: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) Date: Wed, 10 Jan 2007 00:10:45 -1000 (HST) On Tue, 9 Jan 2007, Bruce A. Mah wrote: > If memory serves me right, Mark Linimon wrote: >> Old Synopsis: IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 >> New Synopsis: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) >> >> Responsible-Changed-From-To: freebsd-bugs->freebsd-net >> Responsible-Changed-By: linimon >> Responsible-Changed-When: Mon Jan 1 13:28:53 UTC 2007 >> Responsible-Changed-Why: >> Perhaps someone on -net has an idea. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=107358 > > This looks to me like it could be a duplicate of kern/103415, which was > fixed on HEAD and RELENG_6 (prior to RELENG_6_2 creation, so 6.2 should > be OK, as well as both of the 6.2-RC snapshots). If this is true, a > possible fix might be to apply revision 1.51.2.10 of src/sys/netinet6/in6.c. > > I don't really have an environment conducive to testing 6to4, so this > hypothesis is completely untested. I applied the patch for in6.c to 6.1-RELEASE-p11 and IPv6 connectivity is working again. Thanks! Tony From owner-freebsd-net@FreeBSD.ORG Wed Jan 10 15:56:59 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 05C5716A403; Wed, 10 Jan 2007 15:56:59 +0000 (UTC) (envelope-from bmah@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id D43A713C44C; Wed, 10 Jan 2007 15:56:58 +0000 (UTC) (envelope-from bmah@FreeBSD.org) Received: from freefall.freebsd.org (bmah@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l0AFuwEK079218; Wed, 10 Jan 2007 15:56:58 GMT (envelope-from bmah@freefall.freebsd.org) Received: (from bmah@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0AFuwdH079214; Wed, 10 Jan 2007 15:56:58 GMT (envelope-from bmah) Date: Wed, 10 Jan 2007 15:56:58 GMT From: "Bruce A. Mah" Message-Id: <200701101556.l0AFuwdH079214@freefall.freebsd.org> To: tony@lava.net, bmah@FreeBSD.org, freebsd-net@FreeBSD.org, bmah@FreeBSD.org Cc: Subject: Re: kern/107358: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jan 2007 15:56:59 -0000 Synopsis: [ipv6] IPv6 6to4 broken in FreeBSD 6.1-RELEASE-p11 (regression) State-Changed-From-To: open->closed State-Changed-By: bmah State-Changed-When: Wed Jan 10 15:54:57 UTC 2007 State-Changed-Why: Closing this PR, as the problem originally described has been fixed in 6.2 and later versions. Responsible-Changed-From-To: freebsd-net->bmah Responsible-Changed-By: bmah Responsible-Changed-When: Wed Jan 10 15:54:57 UTC 2007 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=107358 From owner-freebsd-net@FreeBSD.ORG Wed Jan 10 19:42: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 B4F1D16A416 for ; Wed, 10 Jan 2007 19:42:44 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2D413C44C for ; Wed, 10 Jan 2007 19:42:44 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id AF876757E5; Wed, 10 Jan 2007 14:36:22 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Wed, 10 Jan 2007 14:36:22 -0500 X-Sasl-enc: 41HSIYC0UjHTvDsKCy+nMLOzB4DRqnG8EFkwYH6J7/01 1168457782 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 C0D07169B5; Wed, 10 Jan 2007 14:36:20 -0500 (EST) Message-ID: <45A54119.20809@FreeBSD.org> Date: Wed, 10 Jan 2007 19:40:09 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Eygene Ryabinkin References: <459D4D88.2030708@delphij.net> <459FEDBC.4070008@FreeBSD.org> <20070107115158.GA63854@codelabs.ru> In-Reply-To: <20070107115158.GA63854@codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, LI Xin Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jan 2007 19:42:44 -0000 Eygene Ryabinkin wrote: > > For me the routing gives the default gateway as the next hop, so the 'dst' > will be rewritten at the line 241. > You're quite right, I stand corrected -- the undirected broadcast case is hitting the default route. > I think that this confirms my findings. Have you tried to look at your packet > with tcpdump? Link-level MAC should be set to your routers one, not to yhe > 0xffffffff. > I saw this as well. The behaviour is actually as expected. FreeBSD has done this for years. Some years ago I did some work on a fix for this, but it was not net-smp safe. Wes Peters suggested treating INADDR_BROADCAST traffic like multicast-routed traffic. Whilst the MROUTING code has queues for each entry in the Multicast Forwarding Cache (MFC) and knows how to dispatch the same mbuf chain more than once, it isn't compiled in by default. Regards BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 11 06:37:28 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 422FA16A40F; Thu, 11 Jan 2007 06:37:28 +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 EFADD13C43E; Thu, 11 Jan 2007 06:37:27 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1H4tYu-0005Kz-Hm; Thu, 11 Jan 2007 09:37:20 +0300 Date: Thu, 11 Jan 2007 09:37:15 +0300 From: Eygene Ryabinkin To: "Bruce M. Simpson" Message-ID: <20070111063715.GL14822@codelabs.ru> References: <459D4D88.2030708@delphij.net> <459FEDBC.4070008@FreeBSD.org> <20070107115158.GA63854@codelabs.ru> <45A54119.20809@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <45A54119.20809@FreeBSD.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.5 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-net@freebsd.org, Tadaaki Nagao , andre@freebsd.org, LI Xin Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jan 2007 06:37:28 -0000 Bruce, good day! > >I think that this confirms my findings. Have you tried to look at your packet > >with tcpdump? Link-level MAC should be set to your routers one, not to yhe > >0xffffffff. > > > I saw this as well. The behaviour is actually as expected. FreeBSD has done > this for years. Some years ago I did some work on a fix for this, but it was > not net-smp safe. > > Wes Peters suggested treating INADDR_BROADCAST traffic like multicast-routed > traffic. Whilst the MROUTING code has queues for each entry in the Multicast > Forwarding Cache (MFC) and knows how to dispatch the same mbuf chain more than > once, it isn't compiled in by default. Fine. I will have a look at that code, may be it can be adopted to our case. But RFC 919 is a bit unclear about the case of multiple-interface hosts and INADDR_BROADCAST (from section 7): "The address 255.255.255.255 denotes a broadcast on a local hardware network, which must not be forwarded.". The current implementation correctly sets TTL = 1 for IP_ONESBCAST (as inspired by PR/99558), but it uses just one interface that is specified via its broadcast address. If we're taking "local hardware network" to be the specific interface that is to be chosen via socket options, then FreeBSD stack is behaving correctly. Then, probably, the ip(4) should be modified to document this behaviour and why it's not agains RFCs. And a patch for 'ping' should be applied to handle INADDR_BROADCAST in the specific manner. In principle, one can assume that packets for INADDR_BROADCAST should go into all local interfaces. I was able to test only at Linux (2.4): it forwards packets from 'ping -b 255.255.255.255' to the first interface with broadcast, but the interface can be chosen with '-I' option. Do you (or anyone else reading this post) have access to the different IP stack realisations at hosts with multiple broadcast-able interfaces? If yes, wouldn't you all be so kind to try to ping the broadcast address and report the behaviour? Or may be there are some arguments from RFCs, best practices or common sense on how INADDR_BROADCAST should be handled in the multiple-interfaces case? Thanks! -- Eygene From owner-freebsd-net@FreeBSD.ORG Thu Jan 11 08:37: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 6CDCE16A47E for ; Thu, 11 Jan 2007 08:37:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD3D13C428 for ; Thu, 11 Jan 2007 08:37:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id C9BD679BFB; Thu, 11 Jan 2007 03:33:58 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Thu, 11 Jan 2007 03:33:58 -0500 X-Sasl-enc: uLzGfplQHedP5FIXEZtWklYhNaJARYr68sa6GJF6Xwfw 1168504438 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 E063B19D5E; Thu, 11 Jan 2007 03:33:56 -0500 (EST) Message-ID: <45A5F75F.8080404@FreeBSD.org> Date: Thu, 11 Jan 2007 08:37:51 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Eygene Ryabinkin References: <459D4D88.2030708@delphij.net> <459FEDBC.4070008@FreeBSD.org> <20070107115158.GA63854@codelabs.ru> <45A54119.20809@FreeBSD.org> <20070111063715.GL14822@codelabs.ru> In-Reply-To: <20070111063715.GL14822@codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Tadaaki Nagao , andre@freebsd.org, LI Xin Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jan 2007 08:37:56 -0000 Eygene Ryabinkin wrote: > Do you (or anyone else reading this post) have access to the different > IP stack realisations at hosts with multiple broadcast-able interfaces? > If yes, wouldn't you all be so kind to try to ping the broadcast address > and report the behaviour? > Windows deals with this by assigning each interface an 'interface metric', which is a default metric that a route is tagged with if it traverses a particular interface, and adding a unicast route to its FIB to INADDR_BROADCAST via each IFF_BROADCAST interface configured and running in the system. You can see this in the output of 'route print'. Selection of the next-hop is then done as in the same way for any other unicast destination with an assigned metric. The Windows FIB supports equal cost multipath; ours doesn't at the present time. The Windows approach seems much cleaner, as it simply reuses the existing unicast FIB lookup, although it involves adding additional routes to the FIB; systems with hundreds of VPN interfaces would therefore spam the FIB with such routes if we used this approach, potentially causing problems similar to those which were part of the reason behind the removal of PRCLONING in the FreeBSD 5.x era. Given that these routes would normally never be exchanged with any peers (and the FIB is not the most appropriate place for route redistribution anyway), it may be preferable and acceptable to put the next-hop selection logic for INADDR_BROADCAST into the stack itself. I'm personally not in favour of sending a single broadcast packet to multiple interfaces as it has potential for denial of service, and doesn't seem to be consistent with the behaviour of other systems, or the most common use-case for undirected broadcast, which is early boot and/or DHCP. Applications such as ISC DHCP work around the traditional BSD behaviour by using BPF to inject and receive IP broadcasts. The MROUTING code can potentially copy mbuf chains for each interface, though it tries to avoid making such copies. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 11 16:17: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 65C7216A403 for ; Thu, 11 Jan 2007 16:17:56 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2AD0113C46B for ; Thu, 11 Jan 2007 16:17:56 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 8810E3F17; Thu, 11 Jan 2007 17:17:54 +0100 (CET) Date: Thu, 11 Jan 2007 17:17:54 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070111161754.GA955@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: All mail clients suck. This one just sucks less. Subject: NFS locking broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 16:17:56 -0000 Hi all. Summary of the problem: since a few days, one of my FreeBSD workstations can't lock anymore files on a NFS filesystem. More details: I have a NFS server (on a old Linux box, but that's not the problem, it works) and some workstations. Everything worked fine until a few days ago. It may not be related, but problems started just after I made a big portupgrade of the problematic workstation (last portupgrade was made 1 or 2 months ago). Now, when I boot this workstation (which mounts one NFS partition on boot), I may have time (less than 5 minuts) to do a few NFS locks on the partition (/home), then NFS locking stops working, and all lock requests will be blocked (top says programs are on state "lockd", and rpc.lockd is seen twice, on in "select" state and the other in "nfslock" state). If I stop/start /etc/rc.d/nfslocking, it may restart for a few minuts (but not always), then will block again. Everything else is still ok, including network, DNS, other NFS operations (non locked read/writes), etc... If, at the same time, I try to do some NFS locks from other clients (Ubuntu, other FreeBSD6 but not up to date stations, etc...) to the same host/same partition, it will work (some of the hosts are on the same switch as the problematic workstation). After some time, I'll have messages on NFS server's console telling that rpc on timed out. I'll have no debug/warning/message on the FreeBSD workstation. I just tried to upgrade my base system to latest 6.2-PRERELEASE (was in 6.1 before), and I still have the problem. Did someone noticed similar problem ? Could this problem really be related to my portupgrade ? The only started service from /usr/local/etc/rc.d is cups, which doesn't use the NFS partition. My /etc/rc.conf DOES include: nfs_client_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" rpcbind_enable="YES" And, most important for me: how can I fix that, or, at least, how can I generate some debug/informations on the box ? Thanks, Yvan. From owner-freebsd-net@FreeBSD.ORG Thu Jan 11 16:31: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 5D4E516A417 for ; Thu, 11 Jan 2007 16:31:37 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 16C3E13C45E for ; Thu, 11 Jan 2007 16:31:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 8BEF0EB23E2; Fri, 12 Jan 2007 00:31:32 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id S8rskWSTSB+u; Fri, 12 Jan 2007 00:31:21 +0800 (CST) Received: from [192.168.1.32] (unknown [61.49.187.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 70ABAEB2182; Fri, 12 Jan 2007 00:31:20 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=uq/Wlv2ERlv5xUYhAoKgA+Aka+d9O3oPo68iLRn7WnmDxraPe7/h9E5u+P4ta16Sr rG/mbsnbUNKCZBdUjjARQ== Message-ID: <45A66609.4090307@delphij.net> Date: Fri, 12 Jan 2007 00:30:01 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <20070111161754.GA955@zen.inc> In-Reply-To: <20070111161754.GA955@zen.inc> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig014A43C190C6B68BE27C029D" Cc: freebsd-net@freebsd.org Subject: Re: NFS locking broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 16:31:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig014A43C190C6B68BE27C029D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable VANHULLEBUS Yvan wrote: > Hi all. >=20 > Summary of the problem: since a few days, one of my FreeBSD > workstations can't lock anymore files on a NFS filesystem. >=20 >=20 >=20 > More details: >=20 > I have a NFS server (on a old Linux box, but that's not the problem, > it works) and some workstations. >=20 > Everything worked fine until a few days ago. It may not be related, > but problems started just after I made a big portupgrade of the > problematic workstation (last portupgrade was made 1 or 2 months > ago). >=20 >=20 > Now, when I boot this workstation (which mounts one NFS partition on > boot), I may have time (less than 5 minuts) to do a few NFS locks on > the partition (/home), then NFS locking stops working, and all lock > requests will be blocked (top says programs are on state "lockd", and > rpc.lockd is seen twice, on in "select" state and the other in > "nfslock" state). Sounds like an known and fixed issue. Try this patch: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/rpc.lockd/lockd_lock.c= =2Ediff?r1=3D1.18&r2=3D1.19 Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig014A43C190C6B68BE27C029D 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 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpmYJOfuToMruuMARAxOLAKCJ1h4+8+FPpQxn4TY5tZ0JSdx3egCfTHsQ Sz4BBcg217/nxwG/Txr8Er4= =4+o9 -----END PGP SIGNATURE----- --------------enig014A43C190C6B68BE27C029D-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 11 20:07: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 8D38616A407 for ; Thu, 11 Jan 2007 20:07:42 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5386813C467 for ; Thu, 11 Jan 2007 20:07:41 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 1958B3F17; Thu, 11 Jan 2007 21:07:41 +0100 (CET) Date: Thu, 11 Jan 2007 21:07:41 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070111200740.GB6884@zen.inc> References: <20070111161754.GA955@zen.inc> <45A66609.4090307@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45A66609.4090307@delphij.net> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: NFS locking broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2007 20:07:42 -0000 On Fri, Jan 12, 2007 at 12:30:01AM +0800, LI Xin wrote: Thanks for the fast reply ! > Sounds like an known and fixed issue. Try this patch: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/rpc.lockd/lockd_lock.c.diff?r1=1.18&r2=1.19 Just tried it, and I still have the problem. The really strange thing is that one "thing" (an application from /usr/local ???) blocks ALL the NFS locking system, for all users and all process... And as I also have the problem if I just reboot the computer then make a test on console or ssh (no X server, no applications, etc...), the only programs from /usr/ports which have been run at that point are cups (which doesn't use the NFS /home AFAIK), bash and pam_ldap. And I just tried again: stopping/restarting nfslocking doesn't change anything (tried a lockf just after restarting nfslock). Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Jan 12 11:00: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 058CA16A417 for ; Fri, 12 Jan 2007 11:00:25 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 95C8B13C45E for ; Fri, 12 Jan 2007 11:00:25 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 4A33C3F17; Fri, 12 Jan 2007 12:00:24 +0100 (CET) Date: Fri, 12 Jan 2007 12:00:24 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070112110024.GA28337@zen.inc> References: <20070111161754.GA955@zen.inc> <45A66609.4090307@delphij.net> <20070111200740.GB6884@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070111200740.GB6884@zen.inc> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: NFS locking broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2007 11:00:26 -0000 Ok.... After some more tests, looks like my problem was on the server side, but I still don't really understand why it worked before then stopped working, and why I had the problem only for THIS client, when it continued to work for other clients.... I'll try to continue investigating this when I'll have time for that. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Jan 12 17:28:00 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 0FF4916A47B for ; Fri, 12 Jan 2007 17:28:00 +0000 (UTC) (envelope-from hugme2@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id C778013C45E for ; Fri, 12 Jan 2007 17:27:59 +0000 (UTC) (envelope-from hugme2@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so546750wra for ; Fri, 12 Jan 2007 09:27:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=ijVGS6XlaM7KiBrw/XS8Wasn8CPyvifMGugjf53HcCyodU9PWFsVxqMrMJ42tYj8mXHPOqwevWAMzGRkg74PCI/ly483NmMFtmZwCGOLoSUGSTVohrb95uYRAk5Mj+jABu6m8qsbHar3C9ACV28z6deobRQO1iulD8UYblMNKx8= Received: by 10.78.20.13 with SMTP id 13mr477904hut.1168621397838; Fri, 12 Jan 2007 09:03:17 -0800 (PST) Received: by 10.78.178.2 with HTTP; Fri, 12 Jan 2007 09:03:17 -0800 (PST) Message-ID: Date: Fri, 12 Jan 2007 12:03:17 -0500 From: "Hug Me" Sender: hugme2@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 X-Google-Sender-Auth: 1ab8cb0a715821e7 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: Problem with port 0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jan 2007 17:28:00 -0000 I am attempting to TFTP the boot code from a FreeBSD server to hardware device butreceiving a timeout. tftp works from from other servers and from this server if not attempting to upload bootcode (see below for differences) The FreeBSD version on the system we are currently testing is 5.4 however other versions have been tested with the same result. the hardware device is a Juniper ISG-2000 some of the tests we have performed: default tftp with inetd yale-tftp as stand alone yale-tftp with inetd net.inet.ip.portrange.reservedhigh: 1023 and net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 0 and net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 and net.inet.ip.portrange.reservedlow: 1 these are the messages from /var/log/xferlog with default tftp - Jan 12 09:37:55 dukeengi01 tftpd[80898]: connect: Can't assign requested address with yale tftp - Jan 12 10:26:33 dukeengi01 tftpd[84367]: recvfrom: Socket operation on non-socket This is the tcpdump: (the freebsd system is 10.0.0.1 and the juniper system is 10.0.0.2) 11:08:06.519779 arp reply 10.0.0.1 is-at 00:11:25:a8:0e:e4 11:08:06.528691 IP (tos 0x4, ttl 255, id 0, offset 0, flags [DF], length: 51) 10.0.0.2.0 > 10.0.0.1.69: [udp sum ok] 23 RRQ "load2000v115.d" octet 11:08:08.558911 IP (tos 0x4, ttl 255, id 0, offset 0, flags [DF], length: 51) 10.0.0.2.0 > 10.0.0.1.69: [udp sum ok] 23 RRQ "load2000v115.d" octet 11:08:11.558959 IP (tos 0x4, ttl 255, id 0, offset 0, flags [DF], length: 51) 10.0.0.2.0 > 10.0.0.1.69: [udp sum ok] 23 RRQ "load2000v115.d" octet 11:08:15.559042 IP (tos 0x4, ttl 255, id 0, offset 0, flags [DF], length: 51) 10.0.0.2.0 > 10.0.0.1.69: [udp sum ok] 23 RRQ "load2000v115.d" octet 11:08:20.559052 IP (tos 0x4, ttl 255, id 0, offset 0, flags [DF], length: 51) 10.0.0.2.0 > 10.0.0.1.69: [udp sum ok] 23 RRQ "load2000v115.d" octet 11:08:26.559116 IP (tos 0x4, ttl 255, id 0, offset 0, flags [DF], length: 51) 10.0.0.20.0 > 10.0.0.1.69: [udp sum ok] 23 RRQ "load2000v115.d" octet When installing the boot loader on this hardware it is necessary to stop the boot process and load it before the OS loads. because of this many things have not loaded yet. for example the routing protocals. therefore the tftp server has to be in the same L2 segment as the hardware device (which it is) The hardware device is not able to assign a port number to it's own address yet (as seen in the tcpdump) Therefore in accordence with RFC's 768 and 1350 it uses the source port of 0. We believe FreeBSD is not allowing a UDP source port of 0 and the kernel is dropping the packet before it ever reaches the tftp server but are unable to verify this hypothesis. I was hoping someone here could help shed some light on the problem. Thank you for your help. -- ******************************************************************* Don't ever forget to -*HUGME*- Yield to Temptation ... it may not pass your way again. -- Lazarus Long, "Time Enough for Love" From owner-freebsd-net@FreeBSD.ORG Fri Jan 12 18:31:23 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 E6AB716A415 for ; Fri, 12 Jan 2007 18:31:23 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from spunkymail-a7.dreamhost.com (sd-green-bigip-83.dreamhost.com [208.97.132.83]) by mx1.freebsd.org (Postfix) with ESMTP id D37AD13C468 for ; Fri, 12 Jan 2007 18:31:23 +0000 (UTC) (envelope-from rnsanchez@wait4.org) Received: from sauron.lan.box (unknown [200.180.187.118]) by spunkymail-a7.dreamhost.com (Postfix) with ESMTP id 8EC455C07E; Fri, 12 Jan 2007 10:31:18 -0800 (PST) Date: Fri, 12 Jan 2007 16:30:57 -0200 From: Ricardo Nabinger Sanchez To: freebsd-net@freebsd.org Message-Id: <20070112163057.2a3ec8f0.rnsanchez@wait4.org> In-Reply-To: References: Organization: SYS_WAIT4 X-Mailer: Sylpheed 2.3.0 (GTK+ 2.10.6; i386-unknown-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: hugme@hugme.org Subject: Re: Problem with port 0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jan 2007 18:31:24 -0000 On Fri, 12 Jan 2007 12:03:17 -0500 "Hug Me" wrote: > We believe FreeBSD is not allowing a UDP source port of 0 and the kernel is > dropping the packet before it ever reaches the tftp server but are unable to > verify this hypothesis. I was hoping someone here could help shed some light > on the problem. But port 0 has special meaning to the kernel (ie, "give me some random port"). Also, it is a reserved one. Please check IANA: http://www.iana.org/assignments/port-numbers I'm afraid you'll have to select another port number. -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-net@FreeBSD.ORG Fri Jan 12 22:13:16 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 31A0C16A40F for ; Fri, 12 Jan 2007 22:13:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 09F0713C455 for ; Fri, 12 Jan 2007 22:13:15 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id C92247B277; Fri, 12 Jan 2007 17:08:59 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Fri, 12 Jan 2007 17:08:59 -0500 X-Sasl-enc: 1bHH111HhkVkaRMOWLRzPPdqjwQ3Hsif8kqGPIX6tt9K 1168639739 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 06FE7146DE; Fri, 12 Jan 2007 17:08:57 -0500 (EST) Message-ID: <45A807F8.7080603@FreeBSD.org> Date: Fri, 12 Jan 2007 22:13:12 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Ricardo Nabinger Sanchez References: <20070112163057.2a3ec8f0.rnsanchez@wait4.org> In-Reply-To: <20070112163057.2a3ec8f0.rnsanchez@wait4.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, hugme@hugme.org Subject: Re: Problem with port 0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jan 2007 22:13:16 -0000 Ricardo Nabinger Sanchez wrote: > On Fri, 12 Jan 2007 12:03:17 -0500 > "Hug Me" wrote: > > >> We believe FreeBSD is not allowing a UDP source port of 0 and the kernel is >> dropping the packet before it ever reaches the tftp server but are unable to >> verify this hypothesis. I was hoping someone here could help shed some light >> on the problem. >> > > But port 0 has special meaning to the kernel (ie, "give me some random > port"). Also, it is a reserved one. Please check IANA: > > http://www.iana.org/assignments/port-numbers > > I'm afraid you'll have to select another port number. > Nope. A source port of 0 is perfectly legal for UDP. I did an experiment with rpcbind whereby I performed a UDP based rpcinfo query from one FreeBSD machine to another, captured the traffic, and used tcpreplay to inject it from source port 0. At first I thought the INPCB hash lookup was doing the wrong thing, then I ktrace'd rpcbind and it was apparent that it was in fact being delivered to rpcbind from udp_input(). rpcbind tries to reply to destination port 0. This was verified with kdump and rpcbind -d. This quite rightly fails, and, indeed, we reject this from the socket code. So, FreeBSD appears to handle a UDP source port of 0 ok based on these tests. The most likely explanation for the failure in this case, without looking further, is that inetd or the tftpd implementations can't handle source port 0. BMS From owner-freebsd-net@FreeBSD.ORG Fri Jan 12 23:35: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 A5AAF16A416; Fri, 12 Jan 2007 23:35:34 +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 8AAA313C428; Fri, 12 Jan 2007 23:35:34 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l0CMnNiW010471; Fri, 12 Jan 2007 14:49:23 -0800 (PST) Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id 1AA3529C003; Fri, 12 Jan 2007 14:49:23 -0800 (PST) X-AuditID: 11807123-a435cbb0000039f2-f0-45a81072b006 Received: from [17.214.13.96] (unknown [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 ED6C930400C; Fri, 12 Jan 2007 14:49:22 -0800 (PST) In-Reply-To: <45A807F8.7080603@FreeBSD.org> References: <20070112163057.2a3ec8f0.rnsanchez@wait4.org> <45A807F8.7080603@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A4F1DBC-B536-4845-811B-8546E4201D69@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Fri, 12 Jan 2007 14:49:22 -0800 To: "Bruce M. Simpson" X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-net , Ricardo Nabinger Sanchez , hugme@hugme.org Subject: Re: Problem with port 0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jan 2007 23:35:34 -0000 On Jan 12, 2007, at 2:13 PM, Bruce M. Simpson wrote: > Ricardo Nabinger Sanchez wrote: >> But port 0 has special meaning to the kernel (ie, "give me some >> random >> port"). Also, it is a reserved one. Please check IANA: >> >> http://www.iana.org/assignments/port-numbers >> >> I'm afraid you'll have to select another port number. >> > Nope. A source port of 0 is perfectly legal for UDP. There's nothing in RFC-768 which forbids one from using a source or destination port of 0, but it also is true that IANA reserves 0/tcp and 0/udp for exactly the reasons Ricardo mentioned. I know that at least some firewalls will explicitly drop traffic using port 0 because it is expected that a well-behaved network stack will reassign a random ephemeral port rather than sending traffic out to or from port 0...YMMV. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sat Jan 13 01:37:28 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 6216316A412 for ; Sat, 13 Jan 2007 01:37:28 +0000 (UTC) (envelope-from hugme2@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id ECB3813C457 for ; Sat, 13 Jan 2007 01:37:27 +0000 (UTC) (envelope-from hugme2@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so853889uge for ; Fri, 12 Jan 2007 17:37:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=jB5lPyiBzMld4HdFgs17IrA4EV7tv7bJ0S9oEWiFM+zitfNpUkiaNStP7rAEYP0Uw6B60QQ5uSr8D51zBxnMGc23c1fzvW+JiUw0vMBbQGq6JaTZlEvbYk36Pu+rEPHXns3dnlSeXiYmaNgwxlqTd8iIlmBVAu4lOReltfGrMjo= Received: by 10.78.185.15 with SMTP id i15mr936707huf.1168652246358; Fri, 12 Jan 2007 17:37:26 -0800 (PST) Received: by 10.78.178.2 with HTTP; Fri, 12 Jan 2007 17:37:26 -0800 (PST) Message-ID: Date: Fri, 12 Jan 2007 20:37:26 -0500 From: "Hug Me" Sender: hugme2@gmail.com To: "Bruce M. Simpson" In-Reply-To: <45A807F8.7080603@FreeBSD.org> MIME-Version: 1.0 References: <20070112163057.2a3ec8f0.rnsanchez@wait4.org> <45A807F8.7080603@FreeBSD.org> X-Google-Sender-Auth: 59f8b8096eaa5730 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, Ricardo Nabinger Sanchez Subject: Re: Problem with port 0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jan 2007 01:37:28 -0000 This is what I thought at first as well. However as I mentioned I used 2 different tftp servers. I tried the yale version with and without inetd. I will get a full packet capture and attach it to my next e-mail. it's possible that it has nothing to do with the traffic being source port 0, that was only the most obvious difference I could find between the normal and dropped traffic. On 1/12/07, Bruce M. Simpson wrote: > > Ricardo Nabinger Sanchez wrote: > > On Fri, 12 Jan 2007 12:03:17 -0500 > > "Hug Me" wrote: > > > > > >> We believe FreeBSD is not allowing a UDP source port of 0 and the > kernel is > >> dropping the packet before it ever reaches the tftp server but are > unable to > >> verify this hypothesis. I was hoping someone here could help shed some > light > >> on the problem. > >> > > > > But port 0 has special meaning to the kernel (ie, "give me some random > > port"). Also, it is a reserved one. Please check IANA: > > > > http://www.iana.org/assignments/port-numbers > > > > I'm afraid you'll have to select another port number. > > > Nope. A source port of 0 is perfectly legal for UDP. > > I did an experiment with rpcbind whereby I performed a UDP based rpcinfo > query from one FreeBSD machine to another, captured the traffic, and > used tcpreplay to inject it from source port 0. > > At first I thought the INPCB hash lookup was doing the wrong thing, then > I ktrace'd rpcbind and it was apparent that it was in fact being > delivered to rpcbind from udp_input(). > > rpcbind tries to reply to destination port 0. This was verified with > kdump and rpcbind -d. This quite rightly fails, and, indeed, we reject > this from the socket code. > > So, FreeBSD appears to handle a UDP source port of 0 ok based on these > tests. > > The most likely explanation for the failure in this case, without > looking further, is that inetd or the tftpd implementations can't handle > source port 0. > > BMS > > > > > -- ******************************************************************* Don't ever forget to -*HUGME*- Yield to Temptation ... it may not pass your way again. -- Lazarus Long, "Time Enough for Love" From owner-freebsd-net@FreeBSD.ORG Sat Jan 13 10:14:59 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 B793916A47C; Sat, 13 Jan 2007 10:14:59 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id F243913C4D9; Sat, 13 Jan 2007 10:14:58 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.8/8.13.8) with ESMTP id l0DAEvfa015384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jan 2007 13:14:57 +0300 (MSK) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.8/8.13.8/Submit) id l0DAEtNl015383; Sat, 13 Jan 2007 13:14:55 +0300 (MSK) (envelope-from oleg) Date: Sat, 13 Jan 2007 13:14:55 +0300 From: Oleg Bulyzhin To: John Polstra Message-ID: <20070113101455.GA15045@lath.rinet.ru> References: <20070109235649.GC5246@lath.rinet.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Doug Barton , net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jan 2007 10:14:59 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 09, 2007 at 04:14:16PM -0800, John Polstra wrote: > I've been using #2 today, and it's working well so far. I > implemented it like this. (Ignore the version numbers; I'm working > in a private repository.) > > --- if_bge.c 8 Jan 2007 22:46:51 -0000 1.26 > +++ if_bge.c 9 Jan 2007 22:52:43 -0000 1.27 > @@ -3122,8 +3122,8 @@ bge_tick(void *xsc) > > if ((sc->bge_flags & BGE_FLAG_TBI) == 0) { > mii = device_get_softc(sc->bge_miibus); > - /* Don't mess with the PHY in IPMI/ASF mode */ > - if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) > + /* Don't mess with the PHY unless link is down. */ > + if (!sc->bge_link) > mii_tick(mii); > } else { > /* > > > John Could you please test attached patch? It should fix ierrs issue and should not break link events (would be fine to test it: unplug/plug cable, try to change media with ifconfig, change media on other end of wire). -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge_link.diff" Index: if_bgereg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.66 diff -u -r1.66 if_bgereg.h --- if_bgereg.h 11 Jan 2007 01:43:24 -0000 1.66 +++ if_bgereg.h 13 Jan 2007 10:05:31 -0000 @@ -2479,8 +2479,13 @@ uint32_t bge_tx_buf_ratio; int bge_if_flags; int bge_txcnt; - int bge_link; /* link state */ - int bge_link_evt; /* pending link event */ + uint32_t bge_sts; +#define BGE_STS_LINK 0x00000001 /* MAC link status */ +#define BGE_STS_LINK_EVT 0x00000002 /* pending link event */ +#define BGE_STS_AUTOPOLL 0x00000004 /* PHY auto-polling */ +#define BGE_STS_BIT(sc, x) ((sc)->bge_sts & (x)) +#define BGE_STS_SETBIT(sc, x) ((sc)->bge_sts |= (x)) +#define BGE_STS_CLRBIT(sc, x) ((sc)->bge_sts &= ~(x)) int bge_timer; struct callout bge_stat_ch; uint32_t bge_rx_discards; Index: if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.172 diff -u -r1.172 if_bge.c --- if_bge.c 26 Dec 2006 18:33:55 -0000 1.172 +++ if_bge.c 13 Jan 2007 10:05:33 -0000 @@ -590,6 +590,7 @@ /* Reading with autopolling on may trigger PCI errors */ autopoll = CSR_READ_4(sc, BGE_MI_MODE); if (autopoll & BGE_MIMODE_AUTOPOLL) { + BGE_STS_CLRBIT(sc, BGE_STS_AUTOPOLL); BGE_CLRBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL); DELAY(40); } @@ -613,6 +614,7 @@ done: if (autopoll & BGE_MIMODE_AUTOPOLL) { + BGE_STS_SETBIT(sc, BGE_STS_AUTOPOLL); BGE_SETBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL); DELAY(40); } @@ -635,6 +637,7 @@ /* Reading with autopolling on may trigger PCI errors */ autopoll = CSR_READ_4(sc, BGE_MI_MODE); if (autopoll & BGE_MIMODE_AUTOPOLL) { + BGE_STS_CLRBIT(sc, BGE_STS_AUTOPOLL); BGE_CLRBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL); DELAY(40); } @@ -648,6 +651,7 @@ } if (autopoll & BGE_MIMODE_AUTOPOLL) { + BGE_STS_SETBIT(sc, BGE_STS_AUTOPOLL); BGE_SETBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL); DELAY(40); } @@ -1588,6 +1592,7 @@ if (sc->bge_flags & BGE_FLAG_TBI) { CSR_WRITE_4(sc, BGE_MI_STS, BGE_MISTS_LINK); } else { + BGE_STS_SETBIT(sc, BGE_STS_AUTOPOLL); BGE_SETBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL|10<<16); if (sc->bge_asicrev == BGE_ASICREV_BCM5700 && sc->bge_chipid != BGE_CHIPID_BCM5700_B2) @@ -2992,12 +2997,13 @@ /* Note link event. It will be processed by POLL_AND_CHECK_STATUS cmd */ if (statusword & BGE_STATFLAG_LINKSTATE_CHANGED) - sc->bge_link_evt++; + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); if (cmd == POLL_AND_CHECK_STATUS) if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || - sc->bge_link_evt || (sc->bge_flags & BGE_FLAG_TBI)) + BGE_STS_BIT(sc, BGE_STS_LINK_EVT) || + (sc->bge_flags & BGE_FLAG_TBI)) bge_link_upd(sc); sc->rxcycles = count; @@ -3065,7 +3071,7 @@ if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || - statusword || sc->bge_link_evt) + statusword || BGE_STS_BIT(sc, BGE_STS_LINK_EVT)) bge_link_upd(sc); if (ifp->if_drv_flags & IFF_DRV_RUNNING) { @@ -3121,10 +3127,15 @@ bge_stats_update(sc); if ((sc->bge_flags & BGE_FLAG_TBI) == 0) { - mii = device_get_softc(sc->bge_miibus); - /* Don't mess with the PHY in IPMI/ASF mode */ - if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) + /* + * Do not touch PHY if we have link up. This could break + * IPMI/ASF mode or produce extra input errors. + * (extra input errors was reported for bcm5701 & bcm5704). + */ + if (!BGE_STS_BIT(sc, BGE_STS_LINK)) { + mii = device_get_softc(sc->bge_miibus); mii_tick(mii); + } } else { /* * Since in TBI mode auto-polling can't be used we should poll @@ -3136,7 +3147,7 @@ if (!(sc->bge_ifp->if_capenable & IFCAP_POLLING)) #endif { - sc->bge_link_evt++; + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); BGE_SETBIT(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_SET); } } @@ -3352,7 +3363,7 @@ sc = ifp->if_softc; - if (!sc->bge_link || IFQ_DRV_IS_EMPTY(&ifp->if_snd)) + if (!BGE_STS_BIT(sc, BGE_STS_LINK) || IFQ_DRV_IS_EMPTY(&ifp->if_snd)) return; prodidx = sc->bge_tx_prodidx; @@ -3633,7 +3644,7 @@ return (0); } - sc->bge_link_evt++; + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); mii = device_get_softc(sc->bge_miibus); if (mii->mii_instance) { struct mii_softc *miisc; @@ -3935,9 +3946,9 @@ sc->bge_tx_saved_considx = BGE_TXCONS_UNSET; /* Clear MAC's link state (PHY may still have link UP). */ - if (bootverbose && sc->bge_link) + if (bootverbose && BGE_STS_BIT(sc, BGE_STS_LINK)) if_printf(sc->bge_ifp, "link DOWN\n"); - sc->bge_link = 0; + BGE_STS_CLRBIT(sc, BGE_STS_LINK); ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); } @@ -3995,12 +4006,12 @@ bge_link_upd(struct bge_softc *sc) { struct mii_data *mii; - uint32_t link, status; + uint32_t status; BGE_LOCK_ASSERT(sc); /* Clear 'pending link event' flag. */ - sc->bge_link_evt = 0; + BGE_STS_CLRBIT(sc, BGE_STS_LINK_EVT); /* * Process link state changes. @@ -4023,16 +4034,16 @@ if (status & BGE_MACSTAT_MI_INTERRUPT) { mii = device_get_softc(sc->bge_miibus); mii_pollstat(mii); - if (!sc->bge_link && + if (!BGE_STS_BIT(sc, BGE_STS_LINK) && mii->mii_media_status & IFM_ACTIVE && IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { - sc->bge_link++; + BGE_STS_SETBIT(sc, BGE_STS_LINK); if (bootverbose) if_printf(sc->bge_ifp, "link UP\n"); - } else if (sc->bge_link && + } else if (BGE_STS_BIT(sc, BGE_STS_LINK) && (!(mii->mii_media_status & IFM_ACTIVE) || IFM_SUBTYPE(mii->mii_media_active) == IFM_NONE)) { - sc->bge_link = 0; + BGE_STS_CLRBIT(sc, BGE_STS_LINK); if (bootverbose) if_printf(sc->bge_ifp, "link DOWN\n"); } @@ -4050,8 +4061,8 @@ if (sc->bge_flags & BGE_FLAG_TBI) { status = CSR_READ_4(sc, BGE_MAC_STS); if (status & BGE_MACSTAT_TBI_PCS_SYNCHED) { - if (!sc->bge_link) { - sc->bge_link++; + if (!BGE_STS_BIT(sc, BGE_STS_LINK)) { + BGE_STS_SETBIT(sc, BGE_STS_LINK); if (sc->bge_asicrev == BGE_ASICREV_BCM5704) BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_TBI_SEND_CFGS); @@ -4061,40 +4072,38 @@ if_link_state_change(sc->bge_ifp, LINK_STATE_UP); } - } else if (sc->bge_link) { - sc->bge_link = 0; + } else if (BGE_STS_BIT(sc, BGE_STS_LINK)) { + BGE_STS_CLRBIT(sc, BGE_STS_LINK); if (bootverbose) if_printf(sc->bge_ifp, "link DOWN\n"); if_link_state_change(sc->bge_ifp, LINK_STATE_DOWN); } - /* Discard link events for MII/GMII cards if MI auto-polling disabled */ - } else if (CSR_READ_4(sc, BGE_MI_MODE) & BGE_MIMODE_AUTOPOLL) { - /* - * Some broken BCM chips have BGE_STATFLAG_LINKSTATE_CHANGED bit - * in status word always set. Workaround this bug by reading - * PHY link status directly. - */ - link = (CSR_READ_4(sc, BGE_MI_STS) & BGE_MISTS_LINK) ? 1 : 0; + /* + * Discard link events for MII/GMII cards if MI auto-polling disabled. + * This should not happen since mii callouts are locked now, but + * we keep this check for debug. + */ + } else if (BGE_STS_BIT(sc, BGE_STS_AUTOPOLL)) { + mii = device_get_softc(sc->bge_miibus); + mii_pollstat(mii); - if (link != sc->bge_link || - sc->bge_asicrev == BGE_ASICREV_BCM5700) { - mii = device_get_softc(sc->bge_miibus); - mii_pollstat(mii); - if (!sc->bge_link && - mii->mii_media_status & IFM_ACTIVE && - IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { - sc->bge_link++; - if (bootverbose) - if_printf(sc->bge_ifp, "link UP\n"); - } else if (sc->bge_link && - (!(mii->mii_media_status & IFM_ACTIVE) || - IFM_SUBTYPE(mii->mii_media_active) == IFM_NONE)) { - sc->bge_link = 0; - if (bootverbose) - if_printf(sc->bge_ifp, "link DOWN\n"); - } + if (!BGE_STS_BIT(sc, BGE_STS_LINK) && + mii->mii_media_status & IFM_ACTIVE && + IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { + BGE_STS_SETBIT(sc, BGE_STS_LINK); + if (bootverbose) + if_printf(sc->bge_ifp, "link UP\n"); + } else if (BGE_STS_BIT(sc, BGE_STS_LINK) && + (!(mii->mii_media_status & IFM_ACTIVE) || + IFM_SUBTYPE(mii->mii_media_active) == IFM_NONE)) { + BGE_STS_CLRBIT(sc, BGE_STS_LINK); + if (bootverbose) + if_printf(sc->bge_ifp, "link DOWN\n"); } - } + } else + /* Should not happen, see above. */ + if_printf(sc->bge_ifp, + "link event discarded: PHY auto-polling is off.\n"); /* Clear the attention. */ CSR_WRITE_4(sc, BGE_MAC_STS, BGE_MACSTAT_SYNC_CHANGED| --SUOF0GtieIMvvwua-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 13 10:33:46 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 DC61216A412; Sat, 13 Jan 2007 10:33:46 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3BEEC13C458; Sat, 13 Jan 2007 10:33:45 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.8/8.13.8) with ESMTP id l0DAXiWG015713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jan 2007 13:33:44 +0300 (MSK) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.8/8.13.8/Submit) id l0DAXiZf015712; Sat, 13 Jan 2007 13:33:44 +0300 (MSK) (envelope-from oleg) Date: Sat, 13 Jan 2007 13:33:44 +0300 From: Oleg Bulyzhin To: John Polstra Message-ID: <20070113103344.GB15045@lath.rinet.ru> References: <20070109235649.GC5246@lath.rinet.ru> <20070113101455.GA15045@lath.rinet.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nVMJ2NtxeReIH9PS" Content-Disposition: inline In-Reply-To: <20070113101455.GA15045@lath.rinet.ru> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Doug Barton , net@freebsd.org Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jan 2007 10:33:47 -0000 --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jan 13, 2007 at 01:14:55PM +0300, Oleg Bulyzhin wrote: > On Tue, Jan 09, 2007 at 04:14:16PM -0800, John Polstra wrote: > > > I've been using #2 today, and it's working well so far. I > > implemented it like this. (Ignore the version numbers; I'm working > > in a private repository.) > > > > --- if_bge.c 8 Jan 2007 22:46:51 -0000 1.26 > > +++ if_bge.c 9 Jan 2007 22:52:43 -0000 1.27 > > @@ -3122,8 +3122,8 @@ bge_tick(void *xsc) > > > > if ((sc->bge_flags & BGE_FLAG_TBI) == 0) { > > mii = device_get_softc(sc->bge_miibus); > > - /* Don't mess with the PHY in IPMI/ASF mode */ > > - if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) > > + /* Don't mess with the PHY unless link is down. */ > > + if (!sc->bge_link) > > mii_tick(mii); > > } else { > > /* > > > > > > John > > Could you please test attached patch? It should fix ierrs issue and should not > break link events (would be fine to test it: unplug/plug cable, try to change > media with ifconfig, change media on other end of wire). > Oops, previous patch was incomplete (forgot to add brgphy.c diff). Try this one. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge_link.diff" Index: sys/dev/bge/if_bgereg.h =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.66 diff -u -r1.66 if_bgereg.h --- sys/dev/bge/if_bgereg.h 11 Jan 2007 01:43:24 -0000 1.66 +++ sys/dev/bge/if_bgereg.h 13 Jan 2007 10:31:47 -0000 @@ -2479,8 +2479,13 @@ uint32_t bge_tx_buf_ratio; int bge_if_flags; int bge_txcnt; - int bge_link; /* link state */ - int bge_link_evt; /* pending link event */ + uint32_t bge_sts; +#define BGE_STS_LINK 0x00000001 /* MAC link status */ +#define BGE_STS_LINK_EVT 0x00000002 /* pending link event */ +#define BGE_STS_AUTOPOLL 0x00000004 /* PHY auto-polling */ +#define BGE_STS_BIT(sc, x) ((sc)->bge_sts & (x)) +#define BGE_STS_SETBIT(sc, x) ((sc)->bge_sts |= (x)) +#define BGE_STS_CLRBIT(sc, x) ((sc)->bge_sts &= ~(x)) int bge_timer; struct callout bge_stat_ch; uint32_t bge_rx_discards; Index: sys/dev/bge/if_bge.c =================================================================== RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.172 diff -u -r1.172 if_bge.c --- sys/dev/bge/if_bge.c 26 Dec 2006 18:33:55 -0000 1.172 +++ sys/dev/bge/if_bge.c 13 Jan 2007 10:31:52 -0000 @@ -590,6 +590,7 @@ /* Reading with autopolling on may trigger PCI errors */ autopoll = CSR_READ_4(sc, BGE_MI_MODE); if (autopoll & BGE_MIMODE_AUTOPOLL) { + BGE_STS_CLRBIT(sc, BGE_STS_AUTOPOLL); BGE_CLRBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL); DELAY(40); } @@ -613,6 +614,7 @@ done: if (autopoll & BGE_MIMODE_AUTOPOLL) { + BGE_STS_SETBIT(sc, BGE_STS_AUTOPOLL); BGE_SETBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL); DELAY(40); } @@ -635,6 +637,7 @@ /* Reading with autopolling on may trigger PCI errors */ autopoll = CSR_READ_4(sc, BGE_MI_MODE); if (autopoll & BGE_MIMODE_AUTOPOLL) { + BGE_STS_CLRBIT(sc, BGE_STS_AUTOPOLL); BGE_CLRBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL); DELAY(40); } @@ -648,6 +651,7 @@ } if (autopoll & BGE_MIMODE_AUTOPOLL) { + BGE_STS_SETBIT(sc, BGE_STS_AUTOPOLL); BGE_SETBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL); DELAY(40); } @@ -1588,6 +1592,7 @@ if (sc->bge_flags & BGE_FLAG_TBI) { CSR_WRITE_4(sc, BGE_MI_STS, BGE_MISTS_LINK); } else { + BGE_STS_SETBIT(sc, BGE_STS_AUTOPOLL); BGE_SETBIT(sc, BGE_MI_MODE, BGE_MIMODE_AUTOPOLL|10<<16); if (sc->bge_asicrev == BGE_ASICREV_BCM5700 && sc->bge_chipid != BGE_CHIPID_BCM5700_B2) @@ -2992,12 +2997,13 @@ /* Note link event. It will be processed by POLL_AND_CHECK_STATUS cmd */ if (statusword & BGE_STATFLAG_LINKSTATE_CHANGED) - sc->bge_link_evt++; + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); if (cmd == POLL_AND_CHECK_STATUS) if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || - sc->bge_link_evt || (sc->bge_flags & BGE_FLAG_TBI)) + BGE_STS_BIT(sc, BGE_STS_LINK_EVT) || + (sc->bge_flags & BGE_FLAG_TBI)) bge_link_upd(sc); sc->rxcycles = count; @@ -3065,7 +3071,7 @@ if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || - statusword || sc->bge_link_evt) + statusword || BGE_STS_BIT(sc, BGE_STS_LINK_EVT)) bge_link_upd(sc); if (ifp->if_drv_flags & IFF_DRV_RUNNING) { @@ -3121,10 +3127,15 @@ bge_stats_update(sc); if ((sc->bge_flags & BGE_FLAG_TBI) == 0) { - mii = device_get_softc(sc->bge_miibus); - /* Don't mess with the PHY in IPMI/ASF mode */ - if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) + /* + * Do not touch PHY if we have link up. This could break + * IPMI/ASF mode or produce extra input errors. + * (extra input errors was reported for bcm5701 & bcm5704). + */ + if (!BGE_STS_BIT(sc, BGE_STS_LINK)) { + mii = device_get_softc(sc->bge_miibus); mii_tick(mii); + } } else { /* * Since in TBI mode auto-polling can't be used we should poll @@ -3136,7 +3147,7 @@ if (!(sc->bge_ifp->if_capenable & IFCAP_POLLING)) #endif { - sc->bge_link_evt++; + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); BGE_SETBIT(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_SET); } } @@ -3352,7 +3363,7 @@ sc = ifp->if_softc; - if (!sc->bge_link || IFQ_DRV_IS_EMPTY(&ifp->if_snd)) + if (!BGE_STS_BIT(sc, BGE_STS_LINK) || IFQ_DRV_IS_EMPTY(&ifp->if_snd)) return; prodidx = sc->bge_tx_prodidx; @@ -3633,7 +3644,7 @@ return (0); } - sc->bge_link_evt++; + BGE_STS_SETBIT(sc, BGE_STS_LINK_EVT); mii = device_get_softc(sc->bge_miibus); if (mii->mii_instance) { struct mii_softc *miisc; @@ -3935,9 +3946,9 @@ sc->bge_tx_saved_considx = BGE_TXCONS_UNSET; /* Clear MAC's link state (PHY may still have link UP). */ - if (bootverbose && sc->bge_link) + if (bootverbose && BGE_STS_BIT(sc, BGE_STS_LINK)) if_printf(sc->bge_ifp, "link DOWN\n"); - sc->bge_link = 0; + BGE_STS_CLRBIT(sc, BGE_STS_LINK); ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); } @@ -3995,12 +4006,12 @@ bge_link_upd(struct bge_softc *sc) { struct mii_data *mii; - uint32_t link, status; + uint32_t status; BGE_LOCK_ASSERT(sc); /* Clear 'pending link event' flag. */ - sc->bge_link_evt = 0; + BGE_STS_CLRBIT(sc, BGE_STS_LINK_EVT); /* * Process link state changes. @@ -4023,16 +4034,16 @@ if (status & BGE_MACSTAT_MI_INTERRUPT) { mii = device_get_softc(sc->bge_miibus); mii_pollstat(mii); - if (!sc->bge_link && + if (!BGE_STS_BIT(sc, BGE_STS_LINK) && mii->mii_media_status & IFM_ACTIVE && IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { - sc->bge_link++; + BGE_STS_SETBIT(sc, BGE_STS_LINK); if (bootverbose) if_printf(sc->bge_ifp, "link UP\n"); - } else if (sc->bge_link && + } else if (BGE_STS_BIT(sc, BGE_STS_LINK) && (!(mii->mii_media_status & IFM_ACTIVE) || IFM_SUBTYPE(mii->mii_media_active) == IFM_NONE)) { - sc->bge_link = 0; + BGE_STS_CLRBIT(sc, BGE_STS_LINK); if (bootverbose) if_printf(sc->bge_ifp, "link DOWN\n"); } @@ -4050,8 +4061,8 @@ if (sc->bge_flags & BGE_FLAG_TBI) { status = CSR_READ_4(sc, BGE_MAC_STS); if (status & BGE_MACSTAT_TBI_PCS_SYNCHED) { - if (!sc->bge_link) { - sc->bge_link++; + if (!BGE_STS_BIT(sc, BGE_STS_LINK)) { + BGE_STS_SETBIT(sc, BGE_STS_LINK); if (sc->bge_asicrev == BGE_ASICREV_BCM5704) BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_TBI_SEND_CFGS); @@ -4061,40 +4072,38 @@ if_link_state_change(sc->bge_ifp, LINK_STATE_UP); } - } else if (sc->bge_link) { - sc->bge_link = 0; + } else if (BGE_STS_BIT(sc, BGE_STS_LINK)) { + BGE_STS_CLRBIT(sc, BGE_STS_LINK); if (bootverbose) if_printf(sc->bge_ifp, "link DOWN\n"); if_link_state_change(sc->bge_ifp, LINK_STATE_DOWN); } - /* Discard link events for MII/GMII cards if MI auto-polling disabled */ - } else if (CSR_READ_4(sc, BGE_MI_MODE) & BGE_MIMODE_AUTOPOLL) { - /* - * Some broken BCM chips have BGE_STATFLAG_LINKSTATE_CHANGED bit - * in status word always set. Workaround this bug by reading - * PHY link status directly. - */ - link = (CSR_READ_4(sc, BGE_MI_STS) & BGE_MISTS_LINK) ? 1 : 0; + /* + * Discard link events for MII/GMII cards if MI auto-polling disabled. + * This should not happen since mii callouts are locked now, but + * we keep this check for debug. + */ + } else if (BGE_STS_BIT(sc, BGE_STS_AUTOPOLL)) { + mii = device_get_softc(sc->bge_miibus); + mii_pollstat(mii); - if (link != sc->bge_link || - sc->bge_asicrev == BGE_ASICREV_BCM5700) { - mii = device_get_softc(sc->bge_miibus); - mii_pollstat(mii); - if (!sc->bge_link && - mii->mii_media_status & IFM_ACTIVE && - IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { - sc->bge_link++; - if (bootverbose) - if_printf(sc->bge_ifp, "link UP\n"); - } else if (sc->bge_link && - (!(mii->mii_media_status & IFM_ACTIVE) || - IFM_SUBTYPE(mii->mii_media_active) == IFM_NONE)) { - sc->bge_link = 0; - if (bootverbose) - if_printf(sc->bge_ifp, "link DOWN\n"); - } + if (!BGE_STS_BIT(sc, BGE_STS_LINK) && + mii->mii_media_status & IFM_ACTIVE && + IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { + BGE_STS_SETBIT(sc, BGE_STS_LINK); + if (bootverbose) + if_printf(sc->bge_ifp, "link UP\n"); + } else if (BGE_STS_BIT(sc, BGE_STS_LINK) && + (!(mii->mii_media_status & IFM_ACTIVE) || + IFM_SUBTYPE(mii->mii_media_active) == IFM_NONE)) { + BGE_STS_CLRBIT(sc, BGE_STS_LINK); + if (bootverbose) + if_printf(sc->bge_ifp, "link DOWN\n"); } - } + } else + /* Should not happen, see above. */ + if_printf(sc->bge_ifp, + "link event discarded: PHY auto-polling is off.\n"); /* Clear the attention. */ CSR_WRITE_4(sc, BGE_MAC_STS, BGE_MACSTAT_SYNC_CHANGED| Index: sys/dev/mii/brgphy.c =================================================================== RCS file: /home/ncvs/src/sys/dev/mii/brgphy.c,v retrieving revision 1.52 diff -u -r1.52 brgphy.c --- sys/dev/mii/brgphy.c 20 Dec 2006 00:34:12 -0000 1.52 +++ sys/dev/mii/brgphy.c 13 Jan 2007 10:32:03 -0000 @@ -398,6 +398,7 @@ } if (bmsr & BRGPHY_BMSR_LINK) { + sc->mii_ticks = 0; /* Reset autoneg timer. */ switch (PHY_READ(sc, BRGPHY_MII_AUXSTS) & BRGPHY_AUXSTS_AN_RES) { case BRGPHY_RES_1000FD: --nVMJ2NtxeReIH9PS-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 13 14:56: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 F129D16A407; Sat, 13 Jan 2007 14:56:26 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.freebsd.org (Postfix) with ESMTP id DCE0713C45E; Sat, 13 Jan 2007 14:56:26 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l0DEjYtL005590; Sat, 13 Jan 2007 06:45:34 -0800 (PST) Date: Sat, 13 Jan 2007 12:11:39 +0900 Message-ID: From: gnn@freebsd.org To: "Bruce M. Simpson" In-Reply-To: <45A5F75F.8080404@FreeBSD.org> References: <459D4D88.2030708@delphij.net> <459FEDBC.4070008@FreeBSD.org> <20070107115158.GA63854@codelabs.ru> <45A54119.20809@FreeBSD.org> <20070111063715.GL14822@codelabs.ru> <45A5F75F.8080404@FreeBSD.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.92 (i386-apple-darwin8.8.1) 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, Tadaaki Nagao , andre@freebsd.org, LI Xin Subject: Re: Different behavior of ping'ing INADDR_BROADCAST? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jan 2007 14:56:27 -0000 At Thu, 11 Jan 2007 08:37:51 +0000, Bruce M. Simpson wrote: > I'm personally not in favour of sending a single broadcast packet to > multiple interfaces as it has potential for denial of service, and > doesn't seem to be consistent with the behaviour of other systems, > or the most common use-case for undirected broadcast, which is early > boot and/or DHCP. Applications such as ISC DHCP work around the > traditional BSD behaviour by using BPF to inject and receive IP > broadcasts. > Just on this quick point, I too think copying broadcasts to all interfaces is a bad idea and should be avoided. Best, George