From owner-freebsd-net@FreeBSD.ORG Sun Jun 24 08:31:46 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 65D9416A46C for ; Sun, 24 Jun 2007 08:31:46 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 8612A13C4B7 for ; Sun, 24 Jun 2007 08:31:44 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [192.168.32.4] (aviko.aws-net.org.ua [192.168.32.4]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l5O8VcCt014206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Jun 2007 11:31:42 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <467E2BEC.80305@aws-net.org.ua> Date: Sun, 24 Jun 2007 11:31:40 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Jim Stapleton References: <80f4f2b20706230440n5abeceb6n6d94eef41f776265@mail.gmail.com> <467D1700.8050006@aws-net.org.ua> <80f4f2b20706231120u6b6f2659xa427b7a54f20b243@mail.gmail.com> In-Reply-To: <80f4f2b20706231120u6b6f2659xa427b7a54f20b243@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Sun, 24 Jun 2007 11:31:42 +0300 (EEST) X-Virus-Scanned: ClamAV 0.90.3/3513/Sun Jun 24 09:11:39 2007 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: ppp/peers/* files 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, 24 Jun 2007 08:31:46 -0000 Jim Stapleton wrote: > I can't find a way to specify mppe-128 for either pptp or pppd in the > man files, and every doc I see (including the man pages examples, > which don't work when I specify it in the file) seem to suggest that I > use either "mppe-128" or "require-mppe-128" for pppd, neither of which > work. Any suggestions? As far as I know, pppd in FreeBSD does not support natively mppc and needs patches. (Maybe this functionality provided by pptp.) But MPD does! And it support it using in-kernel netgraph subsystem. So, I suggest to install mpd and set it up to connect to your Windows VPN server. Your configs may look like this. mpd.conf file: default: load pptp0 pptp0: new -i ng0 pptp0 pptp0 set bundle enable compression set bundle disable multilink set bundle authname "your-username" set bundle password "your-password" set iface disable on-demand set iface idle 0 set iface mtu 1460 set iface route default set link yes acfcomp protocomp set link disable pap set link accept chap-md5 chap-msv1 chap-msv2 chap set link enable no-orig-auth set link mtu 1460 set link mru 1460 set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0 0.0.0.0/0 set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e56 set ccp yes mpp-e128 set ccp yes mpp-stateless set pptp peer set pptp disable incoming set pptp enable originate out-call set pptp disable windowing set pptp disable delayed-ack open iface mpd.links file: pptp0: set link type pptp Also make shure you have loaded (or compiled in kernel): ng_bpf.ko netgraph.ko ng_ether.ko ng_iface.ko ng_ksocket.ko ng_mppc.ko rc4.ko ng_netflow.ko ng_ppp.ko ng_pptpgre.ko ng_socket.ko ng_tee.ko ng_vjc.ko ng_tty.ko ng_async.ko Hope this helps. -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Sun Jun 24 13:12: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 CFAC816A41F for ; Sun, 24 Jun 2007 13:12:45 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id A5C9313C455 for ; Sun, 24 Jun 2007 13:12:45 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 1F7C31843; Sun, 24 Jun 2007 09:12:45 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 24 Jun 2007 09:12:45 -0400 X-Sasl-enc: 0x2XajVnAqirwc/3JGbCWKcrsTpMRuujb0DhjIbTjk0U 1182690764 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 7612427B9; Sun, 24 Jun 2007 09:12:44 -0400 (EDT) Message-ID: <467E6DC9.5080402@FreeBSD.org> Date: Sun, 24 Jun 2007 14:12:41 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: George Michaelson References: <20070620094806.3a95ec40@garlique.algebras.org> <20070622011451.GA3170@rogue.navcom.lan> <467C5DC2.1060109@FreeBSD.org> <20070623141309.76f4e3be@garlique.algebras.org> In-Reply-To: <20070623141309.76f4e3be@garlique.algebras.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, ghozzy Subject: Re: how do you bring IPv6 live without reboot? 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, 24 Jun 2007 13:12:45 -0000 George Michaelson wrote: > its interesting that when I sent-pr'd this, I got tut-tutted back to > freebsd questions. In my books, not being able to do this kind of V6 > maintenance work on the interface without taking it down probably > deserves to be kept as an open bug! > I agree. Please mail me the PR number and I'll reopen it. However, I can't make any commitment about when I personally would get time to do this as I need to go off and work for a living. It does however strike me as a sound design choice to make. The network stack design in Windows mandates that this is how it has to be -- TDI bindings must be explicitly made between the stack and the NDIS driver(s). Loopback is handled at TDI layer and does not appear until the PF_INET6 domain is attached to the system. Linux has gone part of the way down this road. I beleive BSD should do so as well, for a plethora of reasons including this one, as well as disentangling protocol domain stuff from struct ifnet. As a result ifconfig would get shaken up a bit. At the moment, the way the BSD stack works, neither IPv4 nor IPv6 are attached to struct ifnet until an address is explicitly configured, either by the user or by the kernel configuring a link-local address, so if you do need to purge protocol domain wide state, your current options are to remove the interface (which has been shown to cause problems, some of which I have been trying to fix) or reboot. regards, BMS From owner-freebsd-net@FreeBSD.ORG Sun Jun 24 18:57: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 C4B9C16A400 for ; Sun, 24 Jun 2007 18:57:28 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 44C6E13C468 for ; Sun, 24 Jun 2007 18:57:28 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by ug-out-1314.google.com with SMTP id u2so1278408uge for ; Sun, 24 Jun 2007 11:57:27 -0700 (PDT) Received: by 10.82.156.12 with SMTP id d12mr11027405bue.1182709893599; Sun, 24 Jun 2007 11:31:33 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Sun, 24 Jun 2007 11:31:33 -0700 (PDT) Message-ID: Date: Sun, 24 Jun 2007 21:31:33 +0300 From: "Vlad GALU" To: freebsd-net@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Building a kernel with SCTP support 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, 24 Jun 2007 18:57:28 -0000 Hi list, I have SCTP, SCTP_DEBUG and SCTP_HIGH_SPEED defined in my kernel configuration file. However, it looks that the SCTP source files aren't even built, so the linking fails with -- cut here -- linking kernel.debug uipc_syscalls.o(.text+0x31a): In function `sctp_generic_recvmsg': ../../../kern/uipc_syscalls.c:2642: undefined reference to `sctp_sorecvmsg' uipc_syscalls.o(.text+0x251e): In function `sctp_generic_sendmsg_iov': ../../../kern/uipc_syscalls.c:2521: undefined reference to `sctp_lower_sosend' uipc_syscalls.o(.text+0x276c): In function `sctp_generic_sendmsg': ../../../kern/uipc_syscalls.c:2415: undefined reference to `sctp_lower_sosend' uipc_syscalls.o(.text+0x2abd): In function `sctp_peeloff': ../../../kern/uipc_syscalls.c:2279: undefined reference to `sctp_can_peel_off' uipc_syscalls.o(.text+0x2bfa):../../../kern/uipc_syscalls.c:2316: undefined reference to `sctp_do_peeloff' rtsock.o(.text+0xb62): In function `rt_newaddrmsg': ../../../net/rtsock.c:896: undefined reference to `sctp_addr_change' in_proto.o(.data+0x150): undefined reference to `sctp_input' in_proto.o(.data+0x160): undefined reference to `sctp_ctlinput' in_proto.o(.data+0x168): undefined reference to `sctp_ctloutput' in_proto.o(.data+0x178): undefined reference to `sctp_init' in_proto.o(.data+0x190): undefined reference to `sctp_drain' in_proto.o(.data+0x198): undefined reference to `sctp_usrreqs' in_proto.o(.data+0x1b8): undefined reference to `sctp_input' in_proto.o(.data+0x1c8): undefined reference to `sctp_ctlinput' in_proto.o(.data+0x1d0): undefined reference to `sctp_ctloutput' in_proto.o(.data+0x1f8): undefined reference to `sctp_drain' in_proto.o(.data+0x200): undefined reference to `sctp_usrreqs' in_proto.o(.data+0x220): undefined reference to `sctp_input' in_proto.o(.data+0x230): undefined reference to `sctp_ctlinput' in_proto.o(.data+0x238): undefined reference to `sctp_ctloutput' in_proto.o(.data+0x260): undefined reference to `sctp_drain' in_proto.o(.data+0x268): undefined reference to `sctp_usrreqs' *** Error code 1 -- and here -- Do I need to define additional flags in my config file? -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Sun Jun 24 19:04:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E019416A46C for ; Sun, 24 Jun 2007 19:04:32 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7A70113C455 for ; Sun, 24 Jun 2007 19:04:32 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id u2so1279432uge for ; Sun, 24 Jun 2007 12:04:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qfDMv5PS7BdS0ydQIS26KBlWR1DCH7Y4XCC9rjPF18uqdAJ693MHyr7as4vUM41yJ6eci4mHYc2Xv3IxXdggKL544xyfrke8a9P8NR1WBLlaroaXr6hu+/uKBefYuNZxpYnvILzx7dWi3Wj6Owudt7qP/1uctSc3wSi3a4IGTAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pqWTT1n682RvUCHQbZmzs798LoV+H+CaMU6GxUa8umfurBzbTVTatDtd4G5zFD0fECOL9P3ODrAWkR6jNqFV0RD70QHcpcAoIrUgd2xnBhQRClnqNv1oaCjyIbqRcHyLKSy/97EeJlgWcmxbMk5/vjXtcTg4xNRmVNIF+7NSfKE= Received: by 10.78.185.15 with SMTP id i15mr2268766huf.1182711871195; Sun, 24 Jun 2007 12:04:31 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Sun, 24 Jun 2007 12:04:31 -0700 (PDT) Message-ID: Date: Sun, 24 Jun 2007 12:04:31 -0700 From: "Kip Macy" To: "Vlad GALU" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Building a kernel with SCTP support 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, 24 Jun 2007 19:04:33 -0000 > > Do I need to define additional flags in my config file? No, unless sctp_pcb.c was somehow removed from your sys/conf/files you probably need to 'make cleandepend; make depend'. It builds fine for me with those options. -Kip From owner-freebsd-net@FreeBSD.ORG Sun Jun 24 20:01: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 5AB3A16A41F for ; Sun, 24 Jun 2007 20:01:00 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id E9A9C13C447 for ; Sun, 24 Jun 2007 20:00:59 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by mu-out-0910.google.com with SMTP id w9so1472072mue for ; Sun, 24 Jun 2007 13:00:58 -0700 (PDT) Received: by 10.82.152.16 with SMTP id z16mr11201617bud.1182715258191; Sun, 24 Jun 2007 13:00:58 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Sun, 24 Jun 2007 13:00:58 -0700 (PDT) Message-ID: Date: Sun, 24 Jun 2007 23:00:58 +0300 From: "Vlad GALU" To: "Kip Macy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Building a kernel with SCTP support 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, 24 Jun 2007 20:01:00 -0000 On 6/24/07, Kip Macy wrote: > > > > Do I need to define additional flags in my config file? > > No, unless sctp_pcb.c was somehow removed from your sys/conf/files you > probably need to 'make cleandepend; make depend'. It builds fine for > me with those options. > I did that, and the result is here: http://night.rdslink.ro/dudu/freebsd/SCTP_out.bz2. I suspect a PEBKAC here :( Should this be the case, I appologise in advance. > -Kip > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Sun Jun 24 21:18:11 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 A507F16A400 for ; Sun, 24 Jun 2007 21:18:11 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 477E213C44B for ; Sun, 24 Jun 2007 21:18:11 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by nf-out-0910.google.com with SMTP id b2so48472nfb for ; Sun, 24 Jun 2007 14:18:10 -0700 (PDT) Received: by 10.82.108.9 with SMTP id g9mr11264887buc.1182719889895; Sun, 24 Jun 2007 14:18:09 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Sun, 24 Jun 2007 14:18:09 -0700 (PDT) Message-ID: Date: Mon, 25 Jun 2007 00:18:09 +0300 From: "Vlad GALU" To: "Yann Berthier" In-Reply-To: <20070624211128.GZ1371@bashibuzuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070624211128.GZ1371@bashibuzuk.net> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Building a kernel with SCTP support 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, 24 Jun 2007 21:18:11 -0000 On 6/25/07, Yann Berthier wrote: > On Sun, 24 Jun 2007, at 21:31, Vlad GALU wrote: > > > Hi list, I have SCTP, SCTP_DEBUG and SCTP_HIGH_SPEED defined in my > > kernel configuration file. However, it looks that the SCTP source > > files aren't even built, so the linking fails with > > try including INET6 and see if it helps - when i tried sctp a while > back, i was not able to compile my kernel without it - dunno if this > dependency is to be expected or not > Thanks for the tip! It worked! > > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Sun Jun 24 21:31:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 333AD16A41F for ; Sun, 24 Jun 2007 21:31:47 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 98E4D13C484 for ; Sun, 24 Jun 2007 21:31:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id u2so1300609uge for ; Sun, 24 Jun 2007 14:31:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ftXNj16uWUXIBitkymQWtm/0OG6pmhPQcSpwFtcIRrSbr0ao9MElFNAbztRyd3C53QWZFTBZYlCO6wKIJDnL8vmlG2P0NWXeCSwVqkHfHNTS2aVAWVixRNg4wgv8neXGJbqyRQ2p3DSDtyBtegBstjjapkoUFrSHO8s+zIvzOeM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p5Ewg3Tw83+mWNENJx7Y9B0HbsoFGzeKWhtIIGm58sD+ZFFfPpUDuMwF0cFYhObdzYH1xtRqaFHritphl2LgRlW+e/d8kXShgt/edgOn8e0O1sLy5AAoeEyGpMmyuQ+EpKXRH3DqOTz09H3OqZwMRUiPbFtkBD4HR5il3BNDFxM= Received: by 10.78.206.9 with SMTP id d9mr2302132hug.1182720705344; Sun, 24 Jun 2007 14:31:45 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Sun, 24 Jun 2007 14:31:45 -0700 (PDT) Message-ID: Date: Sun, 24 Jun 2007 14:31:45 -0700 From: "Kip Macy" To: "Randall Stewart" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070624211128.GZ1371@bashibuzuk.net> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Building a kernel with SCTP support 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, 24 Jun 2007 21:31:47 -0000 Interesting - Randall - does SCTP depend on ipv6? Or did you mean to have a pipe between inet and inet6? netinet/sctp_asconf.c optional inet inet6 sctp netinet/sctp_auth.c optional inet inet6 sctp netinet/sctp_bsd_addr.c optional inet inet6 sctp netinet/sctp_crc32.c optional inet inet6 sctp netinet/sctp_indata.c optional inet inet6 sctp netinet/sctp_input.c optional inet inet6 sctp netinet/sctp_output.c optional inet inet6 sctp netinet/sctp_pcb.c optional inet inet6 sctp netinet/sctp_peeloff.c optional inet inet6 sctp netinet/sctp_sysctl.c optional inet inet6 sctp netinet/sctp_timer.c optional inet inet6 sctp netinet/sctp_usrreq.c optional inet inet6 sctp netinet/sctputil.c optional inet inet6 sctp On 6/24/07, Vlad GALU wrote: > On 6/25/07, Yann Berthier wrote: > > On Sun, 24 Jun 2007, at 21:31, Vlad GALU wrote: > > > > > Hi list, I have SCTP, SCTP_DEBUG and SCTP_HIGH_SPEED defined in my > > > kernel configuration file. However, it looks that the SCTP source > > > files aren't even built, so the linking fails with > > > > try including INET6 and see if it helps - when i tried sctp a while > > back, i was not able to compile my kernel without it - dunno if this > > dependency is to be expected or not > > > > Thanks for the tip! It worked! > > > > > > > > -- > If it's there, and you can see it, it's real. > If it's not there, and you can see it, it's virtual. > If it's there, and you can't see it, it's transparent. > If it's not there, and you can't see it, you erased it. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Jun 24 21:37:19 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 A700516A41F; Sun, 24 Jun 2007 21:37:19 +0000 (UTC) (envelope-from yb@bashibuzuk.net) Received: from a.6f2.net (a.6f2.net [213.189.5.89]) by mx1.freebsd.org (Postfix) with ESMTP id 6EF7E13C458; Sun, 24 Jun 2007 21:37:19 +0000 (UTC) (envelope-from yb@bashibuzuk.net) Received: by a.6f2.net (Postfix, from userid 66) id 0ADEEBF905B; Sun, 24 Jun 2007 23:12:03 +0200 (CEST) Received: by cc.bashibuzuk.net (Postfix, from userid 1001) id 2ECCB20C8; Sun, 24 Jun 2007 17:11:29 -0400 (EDT) Date: Sun, 24 Jun 2007 17:11:28 -0400 From: Yann Berthier To: Vlad GALU Message-ID: <20070624211128.GZ1371@bashibuzuk.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Building a kernel with SCTP support 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, 24 Jun 2007 21:37:19 -0000 On Sun, 24 Jun 2007, at 21:31, Vlad GALU wrote: > Hi list, I have SCTP, SCTP_DEBUG and SCTP_HIGH_SPEED defined in my > kernel configuration file. However, it looks that the SCTP source > files aren't even built, so the linking fails with try including INET6 and see if it helps - when i tried sctp a while back, i was not able to compile my kernel without it - dunno if this dependency is to be expected or not From owner-freebsd-net@FreeBSD.ORG Sun Jun 24 22:25: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 F2D6116A41F; Sun, 24 Jun 2007 22:25:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id D580E13C45E; Sun, 24 Jun 2007 22:25:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.13.8) with ESMTP id l5OMNjMQ039126; Sun, 24 Jun 2007 15:23:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.13.8/Submit) id l5OMNikj039125; Sun, 24 Jun 2007 15:23:44 -0700 (PDT) (envelope-from sgk) Date: Sun, 24 Jun 2007 15:23:44 -0700 From: Steve Kargl To: Kip Macy Message-ID: <20070624222344.GA39096@troutmask.apl.washington.edu> References: <20070624211128.GZ1371@bashibuzuk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org Subject: Re: Building a kernel with SCTP support 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, 24 Jun 2007 22:25:40 -0000 On Sun, Jun 24, 2007 at 02:31:45PM -0700, Kip Macy wrote: > Interesting - > > Randall - does SCTP depend on ipv6? Or did you mean to have a pipe > between inet and inet6? > > >From /sys/conf/NOTES: # # Note YOU MUST have both INET and INET6 defined. # you don't have to enable V6, but SCTP is # dual stacked and so far we have not teased apart # the V6 and V4.. since an association can span # both a V6 and V4 address at the SAME time :-) -- Steve From owner-freebsd-net@FreeBSD.ORG Sun Jun 24 22:37:54 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 A73A816A482; Sun, 24 Jun 2007 22:37:54 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 7FB2513C44B; Sun, 24 Jun 2007 22:37:54 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from freefall.freebsd.org (bms@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5OMbsXE029308; Sun, 24 Jun 2007 22:37:54 GMT (envelope-from bms@freefall.freebsd.org) Received: (from bms@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5OMbsiK029304; Sun, 24 Jun 2007 22:37:54 GMT (envelope-from bms) Date: Sun, 24 Jun 2007 22:37:54 GMT From: Bruce M Simpson Message-Id: <200706242237.l5OMbsiK029304@freefall.freebsd.org> To: bms@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/113842: enabling IPv6 post-boot didn't work: required reboot 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, 24 Jun 2007 22:37:54 -0000 Synopsis: enabling IPv6 post-boot didn't work: required reboot Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: bms Responsible-Changed-When: Sun Jun 24 22:37:28 UTC 2007 Responsible-Changed-Why: Real issue. I may get around to this but am currently allocated on non FreeBSD stuff. http://www.freebsd.org/cgi/query-pr.cgi?pr=113842 From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 06:10: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 C8D9116A400 for ; Mon, 25 Jun 2007 06:10:29 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from bub.octopus.com.au (170.135.233.220.exetel.com.au [220.233.135.170]) by mx1.freebsd.org (Postfix) with ESMTP id 866CD13C458 for ; Mon, 25 Jun 2007 06:10:26 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from anzac.hos (170.135.233.220.exetel.com.au [220.233.135.170]) by bub.octopus.com.au (Postfix) with ESMTP id 37270B2511; Mon, 25 Jun 2007 16:10:26 +1000 (EST) Message-ID: <467F5C3F.8090908@modulus.org> Date: Mon, 25 Jun 2007 16:10:07 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.0 (X11/20070426) MIME-Version: 1.0 To: Jack Vogel References: <467C8C5F.8050206@modulus.org> <2a41acea0706230041p54212458mdd2ab339fe9bffd9@mail.gmail.com> In-Reply-To: <2a41acea0706230041p54212458mdd2ab339fe9bffd9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: watchdog timeout problem with freebsd 6.2-stable and v6.4.1 if_em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 06:10:29 -0000 Jack Vogel wrote: >> After medium-heavy traffic, the NIC locks up completely and no traffic >> passes for a long time, perhaps longer than half an hour. >> >> Then, it recovers and prints this to syslog: >> em0: watchdog timeout -- resetting >> em0: link state changed to DOWN >> em0: link state changed to UP >> > If you search thru the email archives you will find that > I have posted a DOS patcher that fixes the problem. > Search on 82573, if you have a problem let me know. Thanks Jack, the patch fixed the problem for me. I found it quite hard to find the patch to download, so I took the liberty of posting an article about it for posterity, including instructions and download link, I hope thats OK. http://www.higherorder.com.au/2007/6/25/intel_82573_patch - Andrew From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 06:50:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45A5E16A41F for ; Mon, 25 Jun 2007 06:50:08 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id E3A1713C468 for ; Mon, 25 Jun 2007 06:50:07 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 14:50:06 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 14:50:06 +0800 Received: from [172.23.17.70] ([172.23.17.70]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 14:50:05 +0800 Message-ID: <467F65A0.9010900@zyxel.com.tw> Date: Mon, 25 Jun 2007 14:50:08 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 06:50:05.0697 (UTC) FILETIME=[101DA710:01C7B6F5] Subject: Questions about PF_KEY interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 06:50:08 -0000 Dear all: I found there are two directories about PF_KEY interface: netkey and netipsec under $FreeBSD src$\sys\. Looking into the makefile, the one that is currently used and built in is netkey. However, I am wondering what's the purpose for netipsec? Besides, the handling for the global variable "regtree", which is used for key registery, in netipsec seems more proper to me. For example, when a key is needed to register, the static function, key_register(), which is defined in [netkey/netipsec]/key.c, will be called. However, in netkey/key.c, key_register() will not call mtx_lock before the operation of the global variable, regtree. On the other hand, in netipsec/key.c, key_register() will mtx_lock. In my opinion, I think the latter should be correct since there may be various processes to call the function. Without the protection, race condition will occur! Many thanks. blue From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 07:05:20 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 339A416A46C for ; Mon, 25 Jun 2007 07:05:20 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id EA66F13C4B0 for ; Mon, 25 Jun 2007 07:05:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 0409C1FFC5D; Mon, 25 Jun 2007 09:05:18 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 0146D1FFC5A; Mon, 25 Jun 2007 09:05:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 806A04448D5; Mon, 25 Jun 2007 07:03:38 +0000 (UTC) Date: Mon, 25 Jun 2007 07:03:38 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: blue In-Reply-To: <467F65A0.9010900@zyxel.com.tw> Message-ID: <20070625070055.P98813@maildrop.int.zabbadoz.net> References: <467F65A0.9010900@zyxel.com.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-net@freebsd.org Subject: Re: Questions about PF_KEY interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 07:05:20 -0000 On Mon, 25 Jun 2007, blue wrote: > Dear all: > > I found there are two directories about PF_KEY interface: netkey and netipsec > under $FreeBSD src$\sys\. > > Looking into the makefile, the one that is currently used and built in is > netkey. > > However, I am wondering what's the purpose for netipsec? netipsec is an anlternate, locked IPsec implementation and soonish will be the only one left in the tree. By that point userspace will be changed to use netipsec/*.h and no longer netkey/*.h which will be gone. In case you are interested testing patches, let me know. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 07:05:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAC3D16A41F for ; Mon, 25 Jun 2007 07:05:48 +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 AE82513C468 for ; Mon, 25 Jun 2007 07:05:48 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 4E5973F1F; Mon, 25 Jun 2007 09:05:47 +0200 (CEST) Date: Mon, 25 Jun 2007 09:05:47 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070625070547.GA24243@zen.inc> References: <467F65A0.9010900@zyxel.com.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467F65A0.9010900@zyxel.com.tw> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Questions about PF_KEY interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 07:05:49 -0000 On Mon, Jun 25, 2007 at 02:50:08PM +0800, blue wrote: > Dear all: Hi. > I found there are two directories about PF_KEY interface: netkey and > netipsec under $FreeBSD src$\sys\. > > Looking into the makefile, the one that is currently used and built in > is netkey. > > However, I am wondering what's the purpose for netipsec? netkey is used if you compile with IPSEC (KAME's stack). netipsec is used if you compile with FAST_IPSEC. > Besides, the handling for the global variable "regtree", which is used > for key registery, in netipsec seems more proper to me. > > For example, when a key is needed to register, the static function, > key_register(), which is defined in [netkey/netipsec]/key.c, will be called. > > However, in netkey/key.c, key_register() will not call mtx_lock before > the operation of the global variable, regtree. On the other hand, in > netipsec/key.c, key_register() will mtx_lock. In my opinion, I think the > latter should be correct since there may be various processes to call > the function. Without the protection, race condition will occur! KAME's IPSec stack is still giant locked, so doesn't needs more fined locking. FAST_IPSEC used fined grain locking. KAME's stack will probably be removed in the future (for 7.0 ?) thanks George V. Neville-Neil's work to provide all KAME's stack features on FAST_IPSEC. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 08:42: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 4E98416A468 for ; Mon, 25 Jun 2007 08:42:42 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id E7AA313C45B for ; Mon, 25 Jun 2007 08:42:41 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 16:42:40 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 16:42:40 +0800 Received: from [172.23.17.70] ([172.23.17.70]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 16:42:39 +0800 Message-ID: <467F8002.9010803@zyxel.com.tw> Date: Mon, 25 Jun 2007 16:42:42 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <467F65A0.9010900@zyxel.com.tw> <20070625070547.GA24243@zen.inc> In-Reply-To: <20070625070547.GA24243@zen.inc> X-OriginalArrivalTime: 25 Jun 2007 08:42:39.0415 (UTC) FILETIME=[C9A53C70:01C7B704] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Questions about PF_KEY interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 08:42:42 -0000 Hi, Thanks for your kindly and quick response :> I still have some questions, though... VANHULLEBUS Yvan wrote: >On Mon, Jun 25, 2007 at 02:50:08PM +0800, blue wrote: > > >>Dear all: >> >> > >Hi. > > > > >>I found there are two directories about PF_KEY interface: netkey and >>netipsec under $FreeBSD src$\sys\. >> >>Looking into the makefile, the one that is currently used and built in >>is netkey. >> >>However, I am wondering what's the purpose for netipsec? >> >> > >netkey is used if you compile with IPSEC (KAME's stack). >netipsec is used if you compile with FAST_IPSEC. > > > I have read the manual page for fast_ipsec and ipsec. However, the man page for fast_ipsec on FreeBSD-6.1Release said currently fast_ipsec does not support IPv6. However, I thought it could properly deal with IPv6 packets after tracing code. Could fast_ipsec support IPv6? Another problem is: if the only difference between fast_ipsec and ipsec is about crypto acceleration, why fast_ipsec needs to modify a bunch of files (including ip6_input, ip6_output, ip6_forward, ..., etc.), not only the encap/decap part? > > >>Besides, the handling for the global variable "regtree", which is used >>for key registery, in netipsec seems more proper to me. >> >>For example, when a key is needed to register, the static function, >>key_register(), which is defined in [netkey/netipsec]/key.c, will be called. >> >>However, in netkey/key.c, key_register() will not call mtx_lock before >>the operation of the global variable, regtree. On the other hand, in >>netipsec/key.c, key_register() will mtx_lock. In my opinion, I think the >>latter should be correct since there may be various processes to call >>the function. Without the protection, race condition will occur! >> >> > >KAME's IPSec stack is still giant locked, so doesn't needs more fined >locking. > >FAST_IPSEC used fined grain locking. > > > The function, key_output(), which is defined in netkey\keysock.c, does not lock Giant before key_parse(). According to the comments (see below), maybe the author wants to lock Giant before the operation? However, does it mean currently it may have race condition problem? / /*XXX giant lock*/ s = splnet(); error = key_parse(m, so); m = NULL; splx(s);/ >KAME's stack will probably be removed in the future (for 7.0 ?) thanks >George V. Neville-Neil's work to provide all KAME's stack features on >FAST_IPSEC. > > > > Do you mean FAST_IPSEC feature will be embedded in FreeBSD-7.0 or later version instead of IPSEC? >Yvan. > > > Thanks for your help :> Best regards, blue From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 09:30: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 1172916A46C for ; Mon, 25 Jun 2007 09:30:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id C7EC213C4BF for ; Mon, 25 Jun 2007 09:30:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 46A6F1FFD6C; Mon, 25 Jun 2007 11:30:13 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id D2B4F1FFAFA; Mon, 25 Jun 2007 11:30:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 98DDD4448D5; Mon, 25 Jun 2007 09:28:04 +0000 (UTC) Date: Mon, 25 Jun 2007 09:28:04 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: blue In-Reply-To: <467F8002.9010803@zyxel.com.tw> Message-ID: <20070625090445.B98813@maildrop.int.zabbadoz.net> References: <467F65A0.9010900@zyxel.com.tw> <20070625070547.GA24243@zen.inc> <467F8002.9010803@zyxel.com.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-net@freebsd.org Subject: Re: Questions about PF_KEY interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 09:30:16 -0000 On Mon, 25 Jun 2007, blue wrote: > I have read the manual page for fast_ipsec and ipsec. However, the man page > for fast_ipsec on FreeBSD-6.1Release said currently fast_ipsec does not > support IPv6. However, I thought it could properly deal with IPv6 packets > after tracing code. Could fast_ipsec support IPv6? Another problem is: if the yes, after you apply the patches that were posted the last weeks on this list and will be committed to HEAD shortly. > only difference between fast_ipsec and ipsec is about crypto acceleration, > why fast_ipsec needs to modify a bunch of files (including ip6_input, > ip6_output, ip6_forward, ..., etc.), not only the encap/decap part? If an ipv6 packet arrives that uses IPSec transport or tunnel mode, how should it be dispatched to ipsec processing if there were no hooks? Quite a bit of the code is there make it possible to interchange the ipsec implementations. Parts of that will go away too. > The function, key_output(), which is defined in netkey\keysock.c, does not > lock Giant before key_parse(). According to the comments (see below), maybe Ignore it. It's almost dead code. Apart from that quite a bit of the network stack runs with GIANT compat shims still. > Do you mean FAST_IPSEC feature will be embedded in FreeBSD-7.0 or later > version instead of IPSEC? As IPSEC. Kame IPSEC will go away. Read the archives of this list;-) -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 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 B79BE16A4D5 for ; Mon, 25 Jun 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 8FA1F13C44C for ; Mon, 25 Jun 2007 11:08:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5PB8eZq098773 for ; Mon, 25 Jun 2007 11:08:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5PB8dsh098768 for freebsd-net@FreeBSD.org; Mon, 25 Jun 2007 11:08:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 25 Jun 2007 11:08:39 GMT Message-Id: <200706251108.l5PB8dsh098768@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 11:08:41 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113359 net [ipv6] panic sbdrop after ICMP6, packet too big o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi 16 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/103253 net inconsistent behaviour in arp reply of a bridge o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112612 net [lo] Traffic via additional lo(4) interface shows up o o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/112710 net [re] if_re driver detects incorrect b243a405a405 MAC a o kern/112886 net [broadcom]: Wifi card not detected 15 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 11:20: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 6393416A468 for ; Mon, 25 Jun 2007 11:20:28 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 39ACC13C4AD for ; Mon, 25 Jun 2007 11:20:26 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 25 Jun 2007 04:10:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHY/f0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,458,1175497200"; d="scan'208"; a="497350668:sNHT26086558" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5PBAvN3025839; Mon, 25 Jun 2007 04:10:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5PBAvmo025348; Mon, 25 Jun 2007 11:10:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 04:10:56 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 04:10:56 -0700 Message-ID: <467FA329.1090401@cisco.com> Date: Mon, 25 Jun 2007 07:12:41 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Kargl References: <20070624211128.GZ1371@bashibuzuk.net> <20070624222344.GA39096@troutmask.apl.washington.edu> In-Reply-To: <20070624222344.GA39096@troutmask.apl.washington.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 11:10:56.0529 (UTC) FILETIME=[80BD1810:01C7B719] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=646; t=1182769857; x=1183633857; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Building=20a=20kernel=20with=20SCTP=20support |Sender:=20; bh=XPavSFIzqhmiRlxPU7zygU8c3bTnOopaUg7Hi1SDPBA=; b=1TL9ykb8Xrt2tjx927EfjWl4FMJEOrmB2VEfMSwcwmkkqtBNVGOLlKqQAGZtNnVQ841+o4XA ls5gLjSbC0Za+4RfDUF6g3PUAqvXJsBxAX7ItRR6dfAjY+soZjGlUKg8; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Cc: Kip Macy , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Building a kernel with SCTP support 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, 25 Jun 2007 11:20:28 -0000 Cool.. I even wrote it down :-D R Steve Kargl wrote: > On Sun, Jun 24, 2007 at 02:31:45PM -0700, Kip Macy wrote: > >>Interesting - >> >>Randall - does SCTP depend on ipv6? Or did you mean to have a pipe >>between inet and inet6? >> >> > > >>From /sys/conf/NOTES: > > # > # Note YOU MUST have both INET and INET6 defined. > # you don't have to enable V6, but SCTP is > # dual stacked and so far we have not teased apart > # the V6 and V4.. since an association can span > # both a V6 and V4 address at the SAME time :-) > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 11:37:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBDAB16A400 for ; Mon, 25 Jun 2007 11:37:47 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.freebsd.org (Postfix) with ESMTP id B5B5413C465 for ; Mon, 25 Jun 2007 11:37:47 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2007 04:10:18 -0700 X-IronPort-AV: i="4.16,458,1175497200"; d="scan'208"; a="171473492:sNHT46422891" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5PBAIAl022635; Mon, 25 Jun 2007 04:10:18 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5PBAGmq025014; Mon, 25 Jun 2007 11:10:18 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 04:10:16 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 04:10:16 -0700 Message-ID: <467FA301.8070600@cisco.com> Date: Mon, 25 Jun 2007 07:12:01 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kip Macy References: <20070624211128.GZ1371@bashibuzuk.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 11:10:16.0369 (UTC) FILETIME=[68CD2A10:01C7B719] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2632; t=1182769818; x=1183633818; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Building=20a=20kernel=20with=20SCTP=20support |Sender:=20; bh=mAlaojVv+4UTz2T65E/7RbvPrCWT54if5ofh1tooEcM=; b=ZmsDZOvDmx054zPVXdexe1QXH0pnYUhLQv5CUkqHWmk/EfADubRzALJssQnbaYiqdThVaTpQ 7FabaQzL4n8VhNNzGUYjdvgYmWp9xAyuwmh6/meAh7QmJQkZ8/VKw+Dg; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Building a kernel with SCTP support 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, 25 Jun 2007 11:37:47 -0000 Kip: Yes, we have a dependancy that both IPv4 and IPv6 are present. A while ago the guy that works on the NetBSd side of the code (who I can't remember his name since he has pretty much stopped working on it.. sigh) was trying to seperate things out.. but we have never put an effort into making it compileable without v6.. or without v4 for that matter.. You have to have both ... not that v6 needs to be enabled.. its just the data structures :-) R Kip Macy wrote: > Interesting - > > Randall - does SCTP depend on ipv6? Or did you mean to have a pipe > between inet and inet6? > > > netinet/sctp_asconf.c optional inet inet6 sctp > netinet/sctp_auth.c optional inet inet6 sctp > netinet/sctp_bsd_addr.c optional inet inet6 sctp > netinet/sctp_crc32.c optional inet inet6 sctp > netinet/sctp_indata.c optional inet inet6 sctp > netinet/sctp_input.c optional inet inet6 sctp > netinet/sctp_output.c optional inet inet6 sctp > netinet/sctp_pcb.c optional inet inet6 sctp > netinet/sctp_peeloff.c optional inet inet6 sctp > netinet/sctp_sysctl.c optional inet inet6 sctp > netinet/sctp_timer.c optional inet inet6 sctp > netinet/sctp_usrreq.c optional inet inet6 sctp > netinet/sctputil.c optional inet inet6 sctp > > > > > On 6/24/07, Vlad GALU wrote: > >> On 6/25/07, Yann Berthier wrote: >> > On Sun, 24 Jun 2007, at 21:31, Vlad GALU wrote: >> > >> > > Hi list, I have SCTP, SCTP_DEBUG and SCTP_HIGH_SPEED defined in my >> > > kernel configuration file. However, it looks that the SCTP source >> > > files aren't even built, so the linking fails with >> > >> > try including INET6 and see if it helps - when i tried sctp a while >> > back, i was not able to compile my kernel without it - dunno if this >> > dependency is to be expected or not >> > >> >> Thanks for the tip! It worked! >> >> > >> > >> >> >> -- >> If it's there, and you can see it, it's real. >> If it's not there, and you can see it, it's virtual. >> If it's there, and you can't see it, it's transparent. >> If it's not there, and you can't see it, you erased it. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 16:52: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 7977016A400 for ; Mon, 25 Jun 2007 16:52:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 0172013C469 for ; Mon, 25 Jun 2007 16:52:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l5PGqjcL014450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 02:52:50 +1000 Date: Tue, 26 Jun 2007 02:52:45 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Julian Elischer In-Reply-To: <467C727D.4060703@elischer.org> Message-ID: <20070626023944.M82078@besplex.bde.org> References: <467C727D.4060703@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net Subject: Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows. 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, 25 Jun 2007 16:52:56 -0000 On Fri, 22 Jun 2007, Julian Elischer wrote: > If one has an event-driven process that accepts tcp connections, one needs to > set eh non-blocking socket option and use kqueue or similar to schedule work. > > This is ok for data transfers, however when it comes to the close() call > there is a problem. The problem in in the following code in so_close() > > > if (so->so_options & SO_LINGER) { > if ((so->so_state & SS_ISDISCONNECTING) && > (so->so_state & SS_NBIO)) > goto drop; > ... > drop: > [ continues on to destroy socket ] > > > because SS_NBIO is set, the socket acts as if SO_LINGER was set, with a > timeout of 0. > the result of this, is the following behaviour: [ patckets in flight get lost ] This seems to be the correct behaviour. The application doesn't care about its data and/or wants to close the descriptor without blocking, so it doesn't turn off the blocking flag and/or wait for i/o to complete (so that it can see if the i/o actually worked) before calling close(). I implemented this behaviour for tty drivers in FreeBSD. Old BSD tty drivers didn't check the nonblocking flag and didn't have a timeout, so close() on tty devices tended to hang forever (normally at long weekends) even for closes that should have been nonblocking. Bruce From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 16:55:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6AB3716A41F for ; Mon, 25 Jun 2007 16:55:24 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 43EFC13C448 for ; Mon, 25 Jun 2007 16:55:24 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1963603waf for ; Mon, 25 Jun 2007 09:55:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MOQGlabIrKHkxPcjyoy/1CQC5/DquOgyWAM3GL2q3Jqm9byFzQ/wYWpLaoue2eK2R6+CaH5pMeyT6Atf5a2QwZYhemKcObyGtj2StjCMN5JhRMHCgAV16SL6ibriAh8OsxVa9TvgkrXCRxeTFmX3yFNVjf/93GC9momuAo53P2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G5QLW17cyjPYn+7JIIGYyKcg+zcVmu0fFHgj9pnbWZH0F+3NcEN3OzXHzPr/+eGsRvqAargv+dh7k9WKHOn9aEXzq98llq1FAbtzSFWQ46NSaXdNSIbvtqKhnhplR4CvhMEUZ/t1QGHVDZlEgnkfVXU1asFzqRIfAb1LNb+1APw= Received: by 10.115.14.1 with SMTP id r1mr5590012wai.1182790521633; Mon, 25 Jun 2007 09:55:21 -0700 (PDT) Received: by 10.114.103.14 with HTTP; Mon, 25 Jun 2007 09:55:21 -0700 (PDT) Message-ID: <2a41acea0706250955g67703f07ldca91f8c18df35b6@mail.gmail.com> Date: Mon, 25 Jun 2007 09:55:21 -0700 From: "Jack Vogel" To: "Andrew Snow" In-Reply-To: <467F5C3F.8090908@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <467C8C5F.8050206@modulus.org> <2a41acea0706230041p54212458mdd2ab339fe9bffd9@mail.gmail.com> <467F5C3F.8090908@modulus.org> Cc: freebsd-net@freebsd.org Subject: Re: watchdog timeout problem with freebsd 6.2-stable and v6.4.1 if_em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 16:55:24 -0000 On 6/24/07, Andrew Snow wrote: > Jack Vogel wrote: > >> After medium-heavy traffic, the NIC locks up completely and no traffic > >> passes for a long time, perhaps longer than half an hour. > >> > >> Then, it recovers and prints this to syslog: > >> em0: watchdog timeout -- resetting > >> em0: link state changed to DOWN > >> em0: link state changed to UP > >> > > If you search thru the email archives you will find that > > I have posted a DOS patcher that fixes the problem. > > Search on 82573, if you have a problem let me know. > > > Thanks Jack, the patch fixed the problem for me. > > I found it quite hard to find the patch to download, so I took the > liberty of posting an article about it for posterity, including > instructions and download link, I hope thats OK. > > http://www.higherorder.com.au/2007/6/25/intel_82573_patch Glad to hear it worked. Thanks for the article, anything that helps get the word out is great. Jack From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 17:17:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4972816A477 for ; Mon, 25 Jun 2007 17:17:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outF.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id 3621913C4D9 for ; Mon, 25 Jun 2007 17:17:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 25 Jun 2007 10:17:43 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 76C86125B45; Mon, 25 Jun 2007 10:17:42 -0700 (PDT) Message-ID: <467FF8BB.1040507@elischer.org> Date: Mon, 25 Jun 2007 10:17:47 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Bruce Evans References: <467C727D.4060703@elischer.org> <20070626023944.M82078@besplex.bde.org> In-Reply-To: <20070626023944.M82078@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows. 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, 25 Jun 2007 17:17:43 -0000 Bruce Evans wrote: > On Fri, 22 Jun 2007, Julian Elischer wrote: > >> If one has an event-driven process that accepts tcp connections, one >> needs to set eh non-blocking socket option and use kqueue or similar >> to schedule work. >> >> This is ok for data transfers, however when it comes to the close() >> call there is a problem. The problem in in the following code in >> so_close() >> >> >> if (so->so_options & SO_LINGER) { >> if ((so->so_state & SS_ISDISCONNECTING) && >> (so->so_state & SS_NBIO)) >> goto drop; >> ... >> drop: >> [ continues on to destroy socket ] >> >> >> because SS_NBIO is set, the socket acts as if SO_LINGER was set, with >> a timeout of 0. >> the result of this, is the following behaviour: > > [ patckets in flight get lost ] > > This seems to be the correct behaviour. The application doesn't care > about its data and/or wants to close the descriptor without blocking, > so it doesn't turn off the blocking flag and/or wait for i/o to complete > (so that it can see if the i/o actually worked) before calling close(). It's not the correct behaviour if the only packet coming back is an Ack of the FIN (and a FIN) because in the real world, making IE7 throw an error screen is not an acceptable option. This is the sort of thing that gets FreeBSD thrown out on favour of "anything else". Believe me, our customers are "NOT HAPPY" about this. Instead of getting an "authorization required" page along with the opportunity to log in, they get an error, and no opportunity to log in, which makes the system unusable. Yes, Blame Microsoft, but we are breaking the TCP spec, not them. We need to fix this some how. > > I implemented this behaviour for tty drivers in FreeBSD. Old BSD tty > drivers didn't check the nonblocking flag and didn't have a timeout, > so close() on tty devices tended to hang forever (normally at long > weekends) even for closes that should have been nonblocking. > > Bruce From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 17: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 88D0516A46E for ; Mon, 25 Jun 2007 17:31:37 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 4747813C46C for ; Mon, 25 Jun 2007 17:31:37 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Mon, 25 Jun 2007 13:31:36 -0400 id 00056416.467FFBF8.00011F61 Date: Mon, 25 Jun 2007 13:31:36 -0400 From: Bill Moran To: Julian Elischer Message-Id: <20070625133136.b3ed98b1.wmoran@collaborativefusion.com> In-Reply-To: <467FF8BB.1040507@elischer.org> References: <467C727D.4060703@elischer.org> <20070626023944.M82078@besplex.bde.org> <467FF8BB.1040507@elischer.org> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows. 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, 25 Jun 2007 17:31:37 -0000 In response to Julian Elischer : > Bruce Evans wrote: > > On Fri, 22 Jun 2007, Julian Elischer wrote: > > > >> If one has an event-driven process that accepts tcp connections, one > >> needs to set eh non-blocking socket option and use kqueue or similar > >> to schedule work. > >> > >> This is ok for data transfers, however when it comes to the close() > >> call there is a problem. The problem in in the following code in > >> so_close() > >> > >> > >> if (so->so_options & SO_LINGER) { > >> if ((so->so_state & SS_ISDISCONNECTING) && > >> (so->so_state & SS_NBIO)) > >> goto drop; > >> ... > >> drop: > >> [ continues on to destroy socket ] > >> > >> > >> because SS_NBIO is set, the socket acts as if SO_LINGER was set, with > >> a timeout of 0. > >> the result of this, is the following behaviour: > > > > [ patckets in flight get lost ] > > > > This seems to be the correct behaviour. The application doesn't care > > about its data and/or wants to close the descriptor without blocking, > > so it doesn't turn off the blocking flag and/or wait for i/o to complete > > (so that it can see if the i/o actually worked) before calling close(). > > It's not the correct behaviour if the only packet coming back is an Ack of > the FIN (and a FIN) because in the real world, making IE7 throw an error > screen is not an acceptable option. This is the sort of thing > that gets FreeBSD thrown out on favour of "anything else". > Believe me, our customers are "NOT HAPPY" about this. > Instead of getting an "authorization required" page along with > the opportunity to log in, they get an error, and no opportunity > to log in, which makes the system unusable. > Yes, Blame Microsoft, but we are breaking the TCP spec, not them. > We need to fix this some how. Correct me if I'm wrong, but I took Bruce's explanation to mean that the problem is not in FreeBSD, it's the fault of the application not using non-blocking IO in the manner it was intended. If you want properly closed connections, you turn of non-blocking before you close the connection. If you want fast close that's not contingent on anything, you close non-blocking and accept that some data may be lost and some errors may result. If you tell the OS to drop packets and it drops them, the OS isn't in error for following orders. Or did I misunderstand? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 17:46: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 60E7B16A468 for ; Mon, 25 Jun 2007 17:46:42 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 30F1E13C447 for ; Mon, 25 Jun 2007 17:46:42 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gurtj6ev04js16fg@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l5PHkepB083241; Mon, 25 Jun 2007 10:46:40 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l5PHkdPp083240; Mon, 25 Jun 2007 10:46:39 -0700 (PDT) (envelope-from jmg) Date: Mon, 25 Jun 2007 10:46:39 -0700 From: John-Mark Gurney To: Julian Elischer Message-ID: <20070625174639.GC1221@funkthat.com> Mail-Followup-To: Julian Elischer , Bruce Evans , FreeBSD Net References: <467C727D.4060703@elischer.org> <20070626023944.M82078@besplex.bde.org> <467FF8BB.1040507@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467FF8BB.1040507@elischer.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: FreeBSD Net Subject: Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 17:46:45 -0000 Julian Elischer wrote this message on Mon, Jun 25, 2007 at 10:17 -0700: > Bruce Evans wrote: > >On Fri, 22 Jun 2007, Julian Elischer wrote: > > > >>If one has an event-driven process that accepts tcp connections, one > >>needs to set eh non-blocking socket option and use kqueue or similar > >>to schedule work. > >> > >>This is ok for data transfers, however when it comes to the close() > >>call there is a problem. The problem in in the following code in > >>so_close() > >> > >> > >> if (so->so_options & SO_LINGER) { > >> if ((so->so_state & SS_ISDISCONNECTING) && > >> (so->so_state & SS_NBIO)) > >> goto drop; > >>... > >>drop: > >> [ continues on to destroy socket ] > >> > >> > >>because SS_NBIO is set, the socket acts as if SO_LINGER was set, with > >>a timeout of 0. > >>the result of this, is the following behaviour: > > > >[ patckets in flight get lost ] > > > >This seems to be the correct behaviour. The application doesn't care > >about its data and/or wants to close the descriptor without blocking, > >so it doesn't turn off the blocking flag and/or wait for i/o to complete > >(so that it can see if the i/o actually worked) before calling close(). > > It's not the correct behaviour if the only packet coming back is an Ack of > the FIN (and a FIN) because in the real world, making IE7 throw an error > screen is not an acceptable option. This is the sort of thing > that gets FreeBSD thrown out on favour of "anything else". > Believe me, our customers are "NOT HAPPY" about this. > Instead of getting an "authorization required" page along with > the opportunity to log in, they get an error, and no opportunity > to log in, which makes the system unusable. > Yes, Blame Microsoft, but we are breaking the TCP spec, not them. > We need to fix this some how. As bde mention, the bug is in the application... Even SUSv2 says: When all file descriptors associated with a pipe or FIFO special file are closed, any data remaining in the pipe or FIFO will be discarded. Our own close(2) says: on the last close of a socket(2) associated naming information and queued data are discarded So, failure of the application to ensure that all data is sent is the application's fault... bde alluded to a simple work around of clearing the non-blocking flag which will return close to the "expected" (but apprently broken) behavior of keeping the tcp socket around till all remaining data has been sent... I must note that the code you quoted has been in FreeBSD since 2.0. > >I implemented this behaviour for tty drivers in FreeBSD. Old BSD tty > >drivers didn't check the nonblocking flag and didn't have a timeout, > >so close() on tty devices tended to hang forever (normally at long > >weekends) even for closes that should have been nonblocking. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 18:02:07 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 40A8216A400 for ; Mon, 25 Jun 2007 18:02:07 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 2695313C44B for ; Mon, 25 Jun 2007 18:02:07 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay6.apple.com (relay6.apple.com [17.128.113.36]) by mail-out3.apple.com (Postfix) with ESMTP id 0D60AA33BCF; Mon, 25 Jun 2007 11:02:07 -0700 (PDT) Received: from relay6.apple.com (unknown [127.0.0.1]) by relay6.apple.com (Symantec Mail Security) with ESMTP id EB3EE10082; Mon, 25 Jun 2007 11:02:06 -0700 (PDT) X-AuditID: 11807124-a2ce2bb0000007e2-51-4680031e6cd0 Received: from [17.214.13.96] (int-si-a.apple.com [17.128.113.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay6.apple.com (Apple SCV relay) with ESMTP id D0EE310081; Mon, 25 Jun 2007 11:02:06 -0700 (PDT) In-Reply-To: <20070625174639.GC1221@funkthat.com> References: <467C727D.4060703@elischer.org> <20070626023944.M82078@besplex.bde.org> <467FF8BB.1040507@elischer.org> <20070625174639.GC1221@funkthat.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2DD749A4-FD3C-4B47-BD97-5C7A6421C811@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Mon, 25 Jun 2007 11:02:05 -0700 To: John-Mark Gurney X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: FreeBSD Net , Julian Elischer Subject: Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows. 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, 25 Jun 2007 18:02:07 -0000 On Jun 25, 2007, at 10:46 AM, John-Mark Gurney wrote: >> It's not the correct behaviour if the only packet coming back is >> an Ack of >> the FIN (and a FIN) because in the real world, making IE7 throw an >> error >> screen is not an acceptable option. This is the sort of thing >> that gets FreeBSD thrown out on favour of "anything else". >> Believe me, our customers are "NOT HAPPY" about this. >> Instead of getting an "authorization required" page along with >> the opportunity to log in, they get an error, and no opportunity >> to log in, which makes the system unusable. >> Yes, Blame Microsoft, but we are breaking the TCP spec, not them. >> We need to fix this some how. > > As bde mention, the bug is in the application... Even SUSv2 says: > When all file descriptors associated with a pipe or FIFO special > file are closed, any data remaining in the pipe or FIFO will be > discarded. A TCP socket isn't the same thing as a named pape or FIFO. SUSv2 isn't the most relevant standard; RFC-793 is... > Our own close(2) says: > on the last > close of a socket(2) associated naming information and queued > data are > discarded > > So, failure of the application to ensure that all data is sent is the > application's fault... bde alluded to a simple work around of > clearing > the non-blocking flag which will return close to the "expected" (but > apprently broken) behavior of keeping the tcp socket around till all > remaining data has been sent... > > I must note that the code you quoted has been in FreeBSD since 2.0. ...and the relevant part is section 3.5 (circa pg 37) and the TCP state diagram on pg 23. Using non-blocking I/O does not mean one can suddenly shortcut the FINWAIT-1 and FINWAIT-2 states before going into TIME_WAIT, nor the 2 * MSL timeout before the TCP control block is allowed to go away. Otherwise, you might end up sending a RST to a dup'ed packet like a stray ACK, which seems to be almost exactly the problem at hand. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 18:04:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1797416A469 for ; Mon, 25 Jun 2007 18:04:21 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id DAD7A13C4BD for ; Mon, 25 Jun 2007 18:04:20 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [10.0.0.14] (unknown [74.95.66.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id A97891702D for ; Mon, 25 Jun 2007 12:46:51 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-net@freebsd.org From: Eric F Crist Date: Mon, 25 Jun 2007 12:46:49 -0500 X-Mailer: Apple Mail (2.752.3) Subject: IPv6 Woes... 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, 25 Jun 2007 18:04:21 -0000 Hello folks! I've got a few FreeBSD 6.2-STABLE boxes configured for IPv6, with a netblock that I obtained from my ISP. I have a router that doesn't support IPv6 yet, so my ISP and I setup a gif tunnel, which is working great. I have a setup similar to this: ISP <---> ROUTER <---> FBSD FW <----> NETWORK LAN \____IPv6 Tunnel_____/ As things are configured, my LAN server can ping one another via IPv6 just fine. My FBSD firewall can ping my ISP just fine. My LAN cannot ping my IPv6 address on the firewall, or, of course, my ISP. My firewall cannot ping my LAN. My IPs are setup like so: My LAN is addressed 2001:4980:1:111:x/64 where x is the last octet of my current v4 addressing. All of these systems have a default ipv6 route of 2001:4980:1:111::1. My firewall has two NICs, fxp0 and fxp1, setup with ethernet bridging, fxp0 holding all my live IPs. ifconfig of my firewall is as follows: fxp0: flags=8943 mtu 1500 options=8 inet6 fe80::206:5bff:fe05:3019%fxp0 prefixlen 64 scopeid 0x1 inet xxx.xxx.xxx.xxx netmask 0xfffffff0 broadcast xxx.xxx.xxx.xxx inet xxx.xxx.xxx.xxx netmask 0xffffffff broadcast xxx.xxx.xxx.xxx inet6 2001:4980:1:111::145 prefixlen 64 inet6 2001:4980:1:111::1 prefixlen 128 ether 00:06:5b:05:30:19 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8943 mtu 1500 options=8 inet6 fe80::206:5bff:fe05:301a%fxp1 prefixlen 64 scopeid 0x2 ether 00:06:5b:05:30:1a media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 gif0: flags=8051 mtu 1280 tunnel inet xxx.xxx.xxx.xxx --> yyy.yyy.yyy.yyy inet6 fe80::206:5bff:fe05:3019%gif0 prefixlen 64 scopeid 0x6 inet6 2001:4980:1::6 prefixlen 126 Output from a netstat -r -f inet6 shows (truncated for length): Internet6: Destination Gateway Flags Netif Expire :: localhost.secure-c UGRS lo0 => default 2001:4980:1::5 UGS gif0 localhost.secure-c localhost.secure-c UHL lo0 ::ffff:0.0.0.0 localhost.secure-c UGRS lo0 2001:4980:1::4 link#6 UC gif0 2001:4980:1::5 link#6 UHLW gif0 2001:4980:1::6 link#6 UHL lo0 2001:4980:1:111:: link#1 UC fxp0 2001:4980:1:111::1 00:06:5b:05:30:19 UHL lo0 2001:4980:1:111::1 00:06:5b:05:30:19 UHL lo0 I'm think there may possibly be a problem with the bridging code? Any ideas would help. For the record, I have read the FreeBSD Handbook, amongst many, many, many other documentation sources. TIA for the help! ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 18:27:41 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 990C616A41F for ; Mon, 25 Jun 2007 18:27:41 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 6BA9A13C455 for ; Mon, 25 Jun 2007 18:27:41 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Mon, 25 Jun 2007 14:27:40 -0400 id 0005642E.4680091C.00012A6E Date: Mon, 25 Jun 2007 14:27:40 -0400 From: Bill Moran To: freebsd-net@freebsd.org Message-Id: <20070625142740.3b6964c0.wmoran@collaborativefusion.com> In-Reply-To: <20070613082443.80d54fd1.wmoran@collaborativefusion.com> References: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> <20070612180349.GN23144@egr.msu.edu> <20070613082443.80d54fd1.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.11; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Weird "ignoring syn" problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 18:27:41 -0000 In response to Bill Moran : > In response to Adam McDougall : > > > On Tue, Jun 12, 2007 at 10:19:49AM -0400, Bill Moran wrote: > > > > > > This one has got me pretty befuddled. > > > > We're seeing some really odd behaviour with FreeBSD ignoring SYN packets. > > I've been trying to diagnose this for a couple of weeks now, and my current > > guess is that there's something wrong with the em driver. Here's a narrowed > > down list of what I've ruled out: > > *) I've done my best to eliminate other network components as the problem. > > My theory at this point is that it can't possibly be any other network > > hardware, based on the tcpdump show below. > > *) The problem occurred on both FreeBSD 6.1 and FreeBSD 6.2-p3. > > *) The problem does not appear to be tied to CPU usage -- the CPU is nearly > > idle when the problem occurs. > > *) I can now reproduce it pretty easily, so I'll know when it's fixed. > > *) The system exhibiting the problem is running 15 jails, but they are > > idle 95% of the time. The problem initially occurred inside one of > > the jails, but I just recreated it outside the jail (on the host) and > > it's _easier_ to reproduce outside the jail. > > *) The problem occurred with both GENERIC, and the SMP kernel (this is a > > dual-CPU, hyperthreaded system) > > *) I've tested and the behavior occurs both with a dynamically generated > > file (from PHP) or from a static file. > > > > The nature of the beast is that we've got a SOAP application running under > > Apache and PHP. This application is subject to many requests in rapid > > succession, such that load can be simulated by the following loop: > > > > while true; do fetch http://192.168.121.250/test.php; done > > > > The problem is that occasionally, the Apache server machine just ignores > > SYN packets. Take the following tcpdump output for example: > > > > 13:34:17.312296 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > > 13:34:20.312398 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > > 13:34:23.512626 IP web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S 2645061726:2645061726(0) win 65535 > > > > This is the _only_ traffic on port 80 during the test. It looks like the > > kernel has ignored the initial syn packet and two duplicates. I've seen it > > take as long as 45 seconds to establish a connection, and this causes > > ugly performance problems, as well as frequent timeouts on the client end. > > The only clue I've found so far is this output from netstat -s. > > > > > > Does the Apache server have a firewall of any sort? (Could be making unexpected > > decisions there, even not part of a fw rule) > > > > Try net.inet.ip.portrange.randomized=0 on the client? (If this is the problem, > > we would probably see a reused port if you had a tcpdump of a few minutes > > if started after waiting for several minutes of "silence") > > > > Are both systems on the same subnet? If not, can/have you tried that? > > No, they aren't. My ability to test on the same subnet is limited and > the results inconclusive. > > > Can you show tcpdump output using -e on the requests that aren't answered > > as well as an example that IS answered? (I have seen routers mess up the MAC > > addresses for the source and destination and if I kept staring at layer 3 > > data all day I might never have seen the problem) > > > > Better yet, can you post files containing tcpdump output using -w of an entire > > session that ideally contains failed attempts that eventually work? That way > > people could look at a broader picture and perhaps pick up on something subtle. > > Its worth comparing a SYN that works, directly with a SYN that doesn't work. > > We've decided to swap the card out on Friday and see if that resolves the > problem. We have similar units that don't exhibit the problem, so I'm > getting pretty suspicious that this might be a flaky NIC. If the new > card doesn't solve the problem, I'll post more details on Monday. Just in case someone was curious as to the result, or finds this on a web search. The behaviour was apparently hardware related. We swapped the NIC out and can no longer reproduce the problem. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 18:59: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 7830716A46C for ; Mon, 25 Jun 2007 18:59:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outH.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 59B6A13C45B for ; Mon, 25 Jun 2007 18:59:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 25 Jun 2007 11:59:37 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 901E9125B24; Mon, 25 Jun 2007 11:59:36 -0700 (PDT) Message-ID: <4680109D.1030308@elischer.org> Date: Mon, 25 Jun 2007 11:59:41 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Chuck Swiger References: <467C727D.4060703@elischer.org> <20070626023944.M82078@besplex.bde.org> <467FF8BB.1040507@elischer.org> <20070625174639.GC1221@funkthat.com> <2DD749A4-FD3C-4B47-BD97-5C7A6421C811@mac.com> In-Reply-To: <2DD749A4-FD3C-4B47-BD97-5C7A6421C811@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , John-Mark Gurney Subject: Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows. 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, 25 Jun 2007 18:59:37 -0000 Chuck Swiger wrote: > On Jun 25, 2007, at 10:46 AM, John-Mark Gurney wrote: >>> It's not the correct behaviour if the only packet coming back is an >>> Ack of >>> the FIN (and a FIN) because in the real world, making IE7 throw an error >>> screen is not an acceptable option. This is the sort of thing >>> that gets FreeBSD thrown out on favour of "anything else". >>> Believe me, our customers are "NOT HAPPY" about this. >>> Instead of getting an "authorization required" page along with >>> the opportunity to log in, they get an error, and no opportunity >>> to log in, which makes the system unusable. >>> Yes, Blame Microsoft, but we are breaking the TCP spec, not them. >>> We need to fix this some how. >> >> As bde mention, the bug is in the application... Even SUSv2 says: >> When all file descriptors associated with a pipe or FIFO special file >> are closed, any data remaining in the pipe or FIFO will be discarded. > > A TCP socket isn't the same thing as a named pape or FIFO. SUSv2 isn't > the most relevant standard; RFC-793 is... > >> Our own close(2) says: >> on the last >> close of a socket(2) associated naming information and queued >> data are >> discarded >> >> So, failure of the application to ensure that all data is sent is the >> application's fault... bde alluded to a simple work around of clearing >> the non-blocking flag which will return close to the "expected" (but >> apprently broken) behavior of keeping the tcp socket around till all >> remaining data has been sent... >> >> I must note that the code you quoted has been in FreeBSD since 2.0. > > ...and the relevant part is section 3.5 (circa pg 37) and the TCP state > diagram on pg 23. Using non-blocking I/O does not mean one can suddenly > shortcut the FINWAIT-1 and FINWAIT-2 states before going into TIME_WAIT, > nor the 2 * MSL timeout before the TCP control block is allowed to go away. > > Otherwise, you might end up sending a RST to a dup'ed packet like a > stray ACK, which seems to be almost exactly the problem at hand. > Yes. I fact it is not even a STRAY ACK. It is the REQUIRED ACK that the client MUST send on reception of the FIN. everyone has made good points so I think I'll re-iterate and comment. 1/ Some feel the app should not use NON-blocking on the close. For an event-loop driven program using AIO and non-blocking sockets, this is not an option. If the socket is blocking, and the far end has died, then the blocking action would leave the whole event-loop blocked for the CLOSE_WAIT_1 period (i.e. 2 minutes by default). This is the behaviour that Bruce was trying to avoid when he made teh socket obey teh non-blocking flag in the first place. Even a 2 SECOND block whenever a client dies is not an acceptable delay on a server serving 2000 requests per second. 2/ As has been pointed out, there is a difference between the action seen from the system call interface point of view, and the "on the wire" point of view. These are not the same thing. On the wire we need to abide by the TCP RFC. We are not, leading to IE7 problems. (and possibly others we are not aware of). The answer is to decouple the behaviour of the protocol from the behaviour of the socket. My suggestion is to put the protocol control block for the session into a time event queue, just as is done for TIME_WAIT annd other states, and have it abide by the time set in the SO_LINGER socket option. Even if the socket itself is long gone. This is my task for the next day or so.. I will present patches for 6.x. Andre may decide to handle it differently in 7. From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 19:05:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C59416A47C for ; Mon, 25 Jun 2007 19:05:34 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 441C313C465 for ; Mon, 25 Jun 2007 19:05:34 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id C303B19EC; Mon, 25 Jun 2007 15:05:33 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 25 Jun 2007 15:05:33 -0400 X-Sasl-enc: Xr/qqFTZWJ+krzHcTbWLDUZ4JqkIeYaT0emxDB8Au8Rx 1182798333 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 41A7F14201; Mon, 25 Jun 2007 15:05:33 -0400 (EDT) Message-ID: <468011FC.4050308@FreeBSD.org> Date: Mon, 25 Jun 2007 20:05:32 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: Eric F Crist References: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> In-Reply-To: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPv6 Woes... 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, 25 Jun 2007 19:05:34 -0000 Is your routing table correct? My default route entry for IPv6 just looks like this: default fe80::%gif0 UGS gif0 and gif0 just looks like this: gif0: flags=8051 mtu 1280 tunnel inet a.b.c.d -> x.x.x.x inet6 fe80::XXX:XXX:XXXX%gif0 prefixlen 64 scopeid 0x8 inet6 2001:ZZZ:ZZZ::ZZZZ:ZZZZ prefixlen 128 In the output you posted, the next-hop of 2001:4980:1::5 will need to be resolved via NDP (hence the LW flags). You already have a 1:1 endpoint mapping due to the use of the gif IPIP header, so the upstream shouldn't need any other tag to demux your traffic. You shouldn't need to do anything special with Ethernet in your configuration. Hope this helps. BMS From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 19:07:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAB0816A474 for ; Mon, 25 Jun 2007 19:07:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5245713C484 for ; Mon, 25 Jun 2007 19:07:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 24360 invoked from network); 25 Jun 2007 18:18:56 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Jun 2007 18:18:56 -0000 Message-ID: <46801288.8070503@freebsd.org> Date: Mon, 25 Jun 2007 21:07:52 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Julian Elischer References: <467C727D.4060703@elischer.org> <20070626023944.M82078@besplex.bde.org> <467FF8BB.1040507@elischer.org> <20070625174639.GC1221@funkthat.com> <2DD749A4-FD3C-4B47-BD97-5C7A6421C811@mac.com> <4680109D.1030308@elischer.org> In-Reply-To: <4680109D.1030308@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , John-Mark Gurney Subject: Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows. 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, 25 Jun 2007 19:07:52 -0000 Julian Elischer wrote: > Chuck Swiger wrote: >> On Jun 25, 2007, at 10:46 AM, John-Mark Gurney wrote: >>>> It's not the correct behaviour if the only packet coming back is an >>>> Ack of >>>> the FIN (and a FIN) because in the real world, making IE7 throw an >>>> error >>>> screen is not an acceptable option. This is the sort of thing >>>> that gets FreeBSD thrown out on favour of "anything else". >>>> Believe me, our customers are "NOT HAPPY" about this. >>>> Instead of getting an "authorization required" page along with >>>> the opportunity to log in, they get an error, and no opportunity >>>> to log in, which makes the system unusable. >>>> Yes, Blame Microsoft, but we are breaking the TCP spec, not them. >>>> We need to fix this some how. >>> >>> As bde mention, the bug is in the application... Even SUSv2 says: >>> When all file descriptors associated with a pipe or FIFO special file >>> are closed, any data remaining in the pipe or FIFO will be discarded. >> >> A TCP socket isn't the same thing as a named pape or FIFO. SUSv2 >> isn't the most relevant standard; RFC-793 is... >> >>> Our own close(2) says: >>> on the last >>> close of a socket(2) associated naming information and queued >>> data are >>> discarded >>> >>> So, failure of the application to ensure that all data is sent is the >>> application's fault... bde alluded to a simple work around of clearing >>> the non-blocking flag which will return close to the "expected" (but >>> apprently broken) behavior of keeping the tcp socket around till all >>> remaining data has been sent... >>> >>> I must note that the code you quoted has been in FreeBSD since 2.0. >> >> ...and the relevant part is section 3.5 (circa pg 37) and the TCP >> state diagram on pg 23. Using non-blocking I/O does not mean one can >> suddenly shortcut the FINWAIT-1 and FINWAIT-2 states before going into >> TIME_WAIT, nor the 2 * MSL timeout before the TCP control block is >> allowed to go away. >> >> Otherwise, you might end up sending a RST to a dup'ed packet like a >> stray ACK, which seems to be almost exactly the problem at hand. >> > Yes. > > I fact it is not even a STRAY ACK. It is the REQUIRED ACK that the client > MUST send on reception of the FIN. > > everyone has made good points so I think I'll re-iterate and comment. > > 1/ Some feel the app should not use NON-blocking on the close. > For an event-loop driven program using AIO and non-blocking sockets, > this is not an option. If the socket is blocking, and the far end has > died, then the blocking action would leave the whole event-loop blocked > for the CLOSE_WAIT_1 period (i.e. 2 minutes > by default). This is the behaviour that Bruce was trying to avoid when > he made teh socket obey teh non-blocking flag in the first place. Even > a 2 SECOND block whenever a client dies is not an acceptable delay on a > server serving 2000 requests per second. > > 2/ As has been pointed out, there is a difference between the action > seen from the system call interface point of view, and the > "on the wire" point of view. These are not the same thing. On the wire > we need to abide by the TCP RFC. We are not, leading to IE7 problems. > (and possibly others we are not aware of). > > The answer is to decouple the behaviour of the protocol from the > behaviour of the socket. My suggestion is to put the protocol > control block for the session into a time event queue, just as is done > for TIME_WAIT annd other states, and have it abide by the time set in > the SO_LINGER > socket option. Even if the socket itself is long gone. > > This is my task for the next day or so.. I will present patches for 6.x. > Andre may decide to handle it differently in 7. I agree with you here. This behavior is the source of the many log messages of syncache. It should be changed. The tcpcb and socket can already run decoupled, you only have to change the test in the close case in tcp_usrreq.c -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 19:23: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 D3DA616A41F for ; Mon, 25 Jun 2007 19:23:39 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id AFED413C483 for ; Mon, 25 Jun 2007 19:23:39 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so2021266waf for ; Mon, 25 Jun 2007 12:23:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=tF94UPF33wD6M8AAaEdChcLQK9S4wMZ0g6ad4h+ajYQ384WdmoSyLciKrDBkCJ/McDadZ5so4PCYwLO6OBD4kJZ07KcVP1FmKX5T/z5rO0nkB4FG7kyW+gJ6dCKtQZ8ZKZsOQRQ3wHWq7vPWfqfp74ntqfAq53rmgq5MBpjiSD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=O389+eta4i+b/8Y2SZBB/7AZCRIv2kY7WsRlLKu4ZecrFNxPtPkPfjLTAqNmWUqKO3ncqJ/WEVPKPu2ZqsPmpM/SLH3883uOgUzgSlQO0bOzli7AO6G5Ojp2e5qxSiXX7KzCk3vmBVXsnwVXoJ/5tJDomlV6HBsWwHMpx8x3FJk= Received: by 10.114.130.1 with SMTP id c1mr5682200wad.1182797766357; Mon, 25 Jun 2007 11:56:06 -0700 (PDT) Received: by 10.114.146.14 with HTTP; Mon, 25 Jun 2007 11:56:05 -0700 (PDT) Message-ID: <82bdb5ec0706251156w789f8998g72b67f453c509634@mail.gmail.com> Date: Mon, 25 Jun 2007 13:56:05 -0500 From: "sazzadur rahman" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: A query about a missing file opt_sctp.h 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, 25 Jun 2007 19:23:39 -0000 Hello, In FreeBSD CVS, http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/?copt=1&hidecvsroot=0&hidenonreadable=1&sortby=&hideattic=1&logsort=date&f=u under src/sys/netinet tree, the header file sctp_os_bsd.h includes another header file named "opt_sctp.h" from version 1.6. Unfortunately I didn't find this file anywhere in the CVS. Is it possible to direct me how I can get the file "opt_sctp.h"? Thanks in advance Sazzad From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 19:39:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AFF316A41F for ; Mon, 25 Jun 2007 19:39:22 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.freebsd.org (Postfix) with ESMTP id 59F6913C447 for ; Mon, 25 Jun 2007 19:39:22 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 25 Jun 2007 12:39:13 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGa3f0arR7MVh2dsb2JhbACPHwEBCQ4s X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="381684438:sNHT140656092" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5PJdDlK025016; Mon, 25 Jun 2007 12:39:13 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5PJcoH2018238; Mon, 25 Jun 2007 19:39:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 12:39:07 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 12:39:06 -0700 Message-ID: <46801A44.2010007@cisco.com> Date: Mon, 25 Jun 2007 15:40:52 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sazzadur rahman References: <82bdb5ec0706251156w789f8998g72b67f453c509634@mail.gmail.com> In-Reply-To: <82bdb5ec0706251156w789f8998g72b67f453c509634@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2007 19:39:07.0065 (UTC) FILETIME=[7E83AA90:01C7B760] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1166; t=1182800353; x=1183664353; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20query=20about=20a=20missing=20file=20opt_sctp.h |Sender:=20; bh=Xh2O19iZdqf4it4fsBvbnlKSw2u/TT26lyuPgHIUOXM=; b=Nwh6vyPR7r75nJYWpNS0uAuhrVEtLfeJmiGf/g0rqIfCyBJEf4nqro4VLnlZ8F2PxnbPhFb9 ayYsQQg/QzTsb1JiYbQ6A6TzGMuipYvSGyZrqf8Rw1mldUIoVxgoekTeCOJkC41JBD6XPxW/sX i5otkvqhZb3lp2P3/8Eu0edq8=; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); Cc: freebsd-net@freebsd.org Subject: Re: A query about a missing file opt_sctp.h 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, 25 Jun 2007 19:39:22 -0000 opt_sctp.h Is one created by the config program when you run config with options SCTP in your list of things you want.. So for example I do cd /usr/src/sys/i386/conf config mymachine cd ../compile/mymachine and if I do ls -l opt_sctp.h I will see it there... That is of course assuming that I have SCTP in my config ;-D R sazzadur rahman wrote: > Hello, In FreeBSD CVS, > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/?copt=1&hidecvsroot=0&hidenonreadable=1&sortby=&hideattic=1&logsort=date&f=u > > > under src/sys/netinet tree, the header file sctp_os_bsd.h includes > another header file named "opt_sctp.h" from version 1.6. > Unfortunately I didn't find this file anywhere in the CVS. Is it > possible to direct me how I can get the file "opt_sctp.h"? > > Thanks in advance Sazzad > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, > send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 21:13:55 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E42BC16A46F for ; Mon, 25 Jun 2007 21:13:54 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.238]) by mx1.freebsd.org (Postfix) with ESMTP id 96EFA13C487 for ; Mon, 25 Jun 2007 21:13:54 +0000 (UTC) (envelope-from dave@dogwood.com) Received: by nz-out-0506.google.com with SMTP id 34so618513nzf for ; Mon, 25 Jun 2007 14:13:54 -0700 (PDT) Received: by 10.114.201.1 with SMTP id y1mr5789134waf.1182806033661; Mon, 25 Jun 2007 14:13:53 -0700 (PDT) Received: from Gecko.dogwood.com ( [66.175.65.65]) by mx.google.com with ESMTP id m30sm5656686wag.2007.06.25.14.13.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2007 14:13:52 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Jun 2007 11:13:43 -1000 To: Bill Moran ,freebsd-net@freebsd.org From: David Cornejo In-Reply-To: <20070625142740.3b6964c0.wmoran@collaborativefusion.com> References: <20070612101949.646dcaa5.wmoran@collaborativefusion.com> <20070612180349.GN23144@egr.msu.edu> <20070613082443.80d54fd1.wmoran@collaborativefusion.com> <20070625142740.3b6964c0.wmoran@collaborativefusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <46803010.1ed6720a.6149.3082@mx.google.com> Cc: Subject: Re: Weird "ignoring syn" problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 21:13:55 -0000 At 08:27 AM 6/25/2007, Bill Moran wrote: >In response to Bill Moran : > > > In response to Adam McDougall : > > > > > On Tue, Jun 12, 2007 at 10:19:49AM -0400, Bill Moran wrote: > > > > > > > > > This one has got me pretty befuddled. > > > > > > We're seeing some really odd behaviour with FreeBSD ignoring > SYN packets. > > > I've been trying to diagnose this for a couple of weeks now, > and my current > > > guess is that there's something wrong with the em > driver. Here's a narrowed > > > down list of what I've ruled out: > > > *) I've done my best to eliminate other network components as > the problem. > > > My theory at this point is that it can't possibly be any > other network > > > hardware, based on the tcpdump show below. > > > *) The problem occurred on both FreeBSD 6.1 and FreeBSD 6.2-p3. > > > *) The problem does not appear to be tied to CPU usage -- the > CPU is nearly > > > idle when the problem occurs. > > > *) I can now reproduce it pretty easily, so I'll know when it's fixed. > > > *) The system exhibiting the problem is running 15 jails, but they are > > > idle 95% of the time. The problem initially occurred inside one of > > > the jails, but I just recreated it outside the jail (on > the host) and > > > it's _easier_ to reproduce outside the jail. > > > *) The problem occurred with both GENERIC, and the SMP kernel > (this is a > > > dual-CPU, hyperthreaded system) > > > *) I've tested and the behavior occurs both with a > dynamically generated > > > file (from PHP) or from a static file. > > > > > > The nature of the beast is that we've got a SOAP application > running under > > > Apache and PHP. This application is subject to many requests in rapid > > > succession, such that load can be simulated by the following loop: > > > > > > while true; do fetch http://192.168.121.250/test.php; done > > > > > > The problem is that occasionally, the Apache server machine > just ignores > > > SYN packets. Take the following tcpdump output for example: > > > > > > 13:34:17.312296 IP > web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S > 2645061726:2645061726(0) win 65535 1,nop,nop,timestamp 2690201156 0,sackOK,eol> > > > 13:34:20.312398 IP > web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S > 2645061726:2645061726(0) win 65535 1,nop,nop,timestamp 2690204156 0,sackOK,eol> > > > 13:34:23.512626 IP > web04-v100.cust00.pitbpa1.priv.collaborativefusion.com.54808 > > anchor-is00.is.pitbpa1.priv.collaborativefusion.com.http: S > 2645061726:2645061726(0) win 65535 1,nop,nop,timestamp 2690207356 0,sackOK,eol> > > > > > > This is the _only_ traffic on port 80 during the test. It > looks like the > > > kernel has ignored the initial syn packet and two > duplicates. I've seen it > > > take as long as 45 seconds to establish a connection, and this causes > > > ugly performance problems, as well as frequent timeouts on > the client end. > > > The only clue I've found so far is this output from netstat -s. > > > > > > > > > Does the Apache server have a firewall of any sort? (Could be > making unexpected > > > decisions there, even not part of a fw rule) > > > > > > Try net.inet.ip.portrange.randomized=0 on the client? (If this > is the problem, > > > we would probably see a reused port if you had a tcpdump of a few minutes > > > if started after waiting for several minutes of "silence") > > > > > > Are both systems on the same subnet? If not, can/have you tried that? > > > > No, they aren't. My ability to test on the same subnet is limited and > > the results inconclusive. > > > > > Can you show tcpdump output using -e on the requests that aren't answered > > > as well as an example that IS answered? (I have seen routers > mess up the MAC > > > addresses for the source and destination and if I kept staring at layer 3 > > > data all day I might never have seen the problem) > > > > > > Better yet, can you post files containing tcpdump output using > -w of an entire > > > session that ideally contains failed attempts that eventually > work? That way > > > people could look at a broader picture and perhaps pick up on > something subtle. > > > Its worth comparing a SYN that works, directly with a SYN that > doesn't work. > > > > We've decided to swap the card out on Friday and see if that resolves the > > problem. We have similar units that don't exhibit the problem, so I'm > > getting pretty suspicious that this might be a flaky NIC. If the new > > card doesn't solve the problem, I'll post more details on Monday. > >Just in case someone was curious as to the result, or finds this on a web >search. > >The behaviour was apparently hardware related. We swapped the NIC out and >can no longer reproduce the problem. To follow up on my situation - Over the weekend I took the Soekris box that demonstrated the bad TCP checksums and wiped then reinstalled the same vintage CURRENT and the problem disappeared. I used the same kernel config in both cases. Thanks to those who replied... dave c From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 22:49:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1966316A41F for ; Mon, 25 Jun 2007 22:49:08 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id DD9D713C465; Mon, 25 Jun 2007 22:49:07 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 25 Jun 2007 15:15:56 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id l5PMKVdZ088398; Mon, 25 Jun 2007 15:20:31 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id l5PMKVEX088397; Mon, 25 Jun 2007 15:20:31 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200706252220.l5PMKVEX088397@ambrisko.com> In-Reply-To: <467C5EEC.1000208@icir.org> To: "Bruce M. Simpson" Date: Mon, 25 Jun 2007 15:20:31 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Net , Marko Zec , releng@freebsd.org, Julian Elischer , ambrisko@freebsd.org Subject: Re: Vimage virtual networking and 7.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: Mon, 25 Jun 2007 22:49:08 -0000 Bruce M. Simpson writes: [snip] | My concern is that vimage may be a very intrusive change indeed where | these matters are concerned, unless the vimage patches are being kept | up-to-date and regression tested as issues are resolved and new features | added. Just like it was mostly working in 4.X then never worked with 5.X & 6.X and now it sounds like it is working in 7.X but will it be working in 8.X etc? That's a lot of effort he is putting in to keep going dead. Note this comment is based on out-side observation. I know a few people that used it in 4.X. I played with it bit. Yes, it would help IronPort. I'd rather not have to keep merging it. I'm not involved in with the FreeBSD network folks to know the scope and the missing bits. IronPort might be able to help somewhat to accelerate it. Doug A. From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 23:20:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3CB0916A41F for ; Mon, 25 Jun 2007 23:20:21 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id 0539713C44B for ; Mon, 25 Jun 2007 23:20:20 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [192.168.1.2] (unknown [209.240.66.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id 7A11A1702D; Mon, 25 Jun 2007 18:20:20 -0500 (CDT) In-Reply-To: <468011FC.4050308@FreeBSD.org> References: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> <468011FC.4050308@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7731B558-35C7-4E22-A40D-8BCE208AFD6A@secure-computing.net> Content-Transfer-Encoding: 7bit From: Eric F Crist Date: Mon, 25 Jun 2007 18:20:18 -0500 To: "Bruce M. Simpson" X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org Subject: Re: IPv6 Woes... 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, 25 Jun 2007 23:20:21 -0000 On Jun 25, 2007, at 2:05 PMJun 25, 2007, Bruce M. Simpson wrote: > Is your routing table correct? My default route entry for IPv6 just > looks like this: > > default fe80::%gif0 > UGS gif0 > > and gif0 just looks like this: > > gif0: flags=8051 mtu 1280 > tunnel inet a.b.c.d -> x.x.x.x > inet6 fe80::XXX:XXX:XXXX%gif0 prefixlen 64 scopeid 0x8 > inet6 2001:ZZZ:ZZZ::ZZZZ:ZZZZ prefixlen 128 > > In the output you posted, the next-hop of 2001:4980:1::5 will need > to be resolved via NDP (hence the LW flags). > > You already have a 1:1 endpoint mapping due to the use of the gif > IPIP header, so the upstream shouldn't need any other tag to demux > your traffic. You shouldn't need to do anything special with > Ethernet in your configuration. > > Hope this helps. > > BMS > Bruce, My problem isn't getting out to 2001:4980:1::5, it's getting to my LAN, the 2001:4980:1:111::/64 network. My gateway, the machine from which I posted the routing and ifconfig information, is able to ping across the tunnel, and to the internet just fine. Nothing is able to get from the gateway to my LAN, however. Is it a problem with the fxp driver, or perhaps my setup with the ethernet bridging? Thanks again. ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 00:55:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F13C16A400 for ; Tue, 26 Jun 2007 00:55:21 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1485513C43E for ; Tue, 26 Jun 2007 00:55:21 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 2868D2121; Mon, 25 Jun 2007 20:55:19 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 25 Jun 2007 20:55:20 -0400 X-Sasl-enc: K4G03jsSiorSNZkKXshuI6hQyQGD66rnl/VX1NagavDr 1182819319 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 875BA47F9; Mon, 25 Jun 2007 20:55:19 -0400 (EDT) Message-ID: <468063F6.2050303@FreeBSD.org> Date: Tue, 26 Jun 2007 01:55:18 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: Eric F Crist References: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> <468011FC.4050308@FreeBSD.org> <7731B558-35C7-4E22-A40D-8BCE208AFD6A@secure-computing.net> In-Reply-To: <7731B558-35C7-4E22-A40D-8BCE208AFD6A@secure-computing.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPv6 Woes... 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, 26 Jun 2007 00:55:21 -0000 Eric F Crist wrote: > > My problem isn't getting out to 2001:4980:1::5, it's getting to my > LAN, the 2001:4980:1:111::/64 network. My gateway, the machine from > which I posted the routing and ifconfig information, is able to ping > across the tunnel, and to the internet just fine. Nothing is able to > get from the gateway to my LAN, however. Is it a problem with the fxp > driver, or perhaps my setup with the ethernet bridging? You appear to have a /64 network address on the inside of your v6 router. Are you using stateless address auto-configuration? You appear to have statically assigned ....::145 as a host address on that net. My setup works fine if I ping the network address of my v6 router from the v6 enabled hosts in my lab. When you ping local machines on the inside LAN from that router, do you see NDP entries being created? You shouldn't need to use bridging to achieve what you want in this scenario, in fact it makes no sense because you want to route v6 traffic over the gif, therefore ethernet bridging is not relevant here. regards BMS From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 01:11: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 41EBB16A400; Tue, 26 Jun 2007 01:11:37 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id 08FD313C4C9; Tue, 26 Jun 2007 01:11:37 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [192.168.1.2] (unknown [209.240.66.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id 941431702D; Mon, 25 Jun 2007 20:11:36 -0500 (CDT) In-Reply-To: <468063F6.2050303@FreeBSD.org> References: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> <468011FC.4050308@FreeBSD.org> <7731B558-35C7-4E22-A40D-8BCE208AFD6A@secure-computing.net> <468063F6.2050303@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AA398FC-A753-4BB8-A93F-224FDDCE41BA@secure-computing.net> Content-Transfer-Encoding: 7bit From: Eric F Crist Date: Mon, 25 Jun 2007 20:11:34 -0500 To: Bruce M. Simpson X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org Subject: Re: IPv6 Woes... 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, 26 Jun 2007 01:11:37 -0000 On Jun 25, 2007, at 7:55 PMJun 25, 2007, Bruce M. Simpson wrote: > Eric F Crist wrote: >> >> My problem isn't getting out to 2001:4980:1::5, it's getting to my >> LAN, the 2001:4980:1:111::/64 network. My gateway, the machine >> from which I posted the routing and ifconfig information, is able >> to ping across the tunnel, and to the internet just fine. Nothing >> is able to get from the gateway to my LAN, however. Is it a >> problem with the fxp driver, or perhaps my setup with the ethernet >> bridging? > > You appear to have a /64 network address on the inside of your v6 > router. Are you using stateless address auto-configuration? You > appear to have statically assigned ....::145 as a host address on > that net. > > My setup works fine if I ping the network address of my v6 router > from the v6 enabled hosts in my lab. > > When you ping local machines on the inside LAN from that router, do > you see NDP entries being created? > > You shouldn't need to use bridging to achieve what you want in this > scenario, in fact it makes no sense because you want to route v6 > traffic over the gif, therefore ethernet bridging is not relevant > here. > Bruce, First, thanks for taking time to help me through this. Here's some more information regarding the topography of my network. My FBSD firewall is running with 'options BRIDGE' in the kernel, and the following two lines in /etc/sysctl.conf: net.link.ether.bridge.enable=1 net.link.ether.bridge.config=fxp0,fxp1 This is so that I don't have to do routing on my firewall. I have a IPv4 /28 network, so a limited number of IP addresses, this saves one of those. This system is filtering traffic with PF. That's really the only reason for the bridging. Also, it does allow me to do traffic shaping and bandwidth monitoring. This bridging stuff really, as you said, has nothing to do with my IPv6 configuration issues. In addition, this gateway/firewall gets the gateway part from the duties I'm assigning regarding the IPv6 stuff. This box has the gif tunnel, and will route all my IPv6 traffic. I would have my primary router perform this, but it's not currently supported, as I have an over-priced POS. Regarding my addressing, you're right, I am statically assigning IP addresses. My current scheme is to simply use the last octet of my IPv4 address. As I said in my previous email, all of my other servers are communicating just fine across IPv6. The only machine I'm having problems with is my firewall machine, the one I want to be my gateway. TIA, please ask if there are further questions. ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 03:20:01 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 0C80116A400 for ; Tue, 26 Jun 2007 03:20:01 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id C5D0413C483 for ; Tue, 26 Jun 2007 03:20:00 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1I31Qe-000Fua-MM; Mon, 25 Jun 2007 23:09:20 -0400 Date: Mon, 25 Jun 2007 23:09:20 -0400 From: Gary Palmer To: Randall Stewart Message-ID: <20070626030920.GA1002@in-addr.com> Mail-Followup-To: Randall Stewart , sazzadur rahman , freebsd-net@freebsd.org References: <82bdb5ec0706251156w789f8998g72b67f453c509634@mail.gmail.com> <46801A44.2010007@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46801A44.2010007@cisco.com> Cc: freebsd-net@freebsd.org, sazzadur rahman Subject: Re: A query about a missing file opt_sctp.h 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, 26 Jun 2007 03:20:01 -0000 On Mon, Jun 25, 2007 at 03:40:52PM -0400, Randall Stewart wrote: > opt_sctp.h > > Is one created by the config program when you run > config with > > options SCTP > > in your list of things you want.. > > So for example I do > > cd /usr/src/sys/i386/conf > config mymachine > cd ../compile/mymachine > > and if I do > > ls -l opt_sctp.h > > I will see it there... > > That is of course assuming that I have > SCTP in my config ;-D Surely it would still be there, as an empty file, even without SCTP? Adding options SCTP would add something like #define SCTP 1 to the file AFAIK (at least on 6.x, I doubt config is that much changed in -current) > sazzadur rahman wrote: > >Hello, In FreeBSD CVS, > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/?copt=1&hidecvsroot=0&hidenonreadable=1&sortby=&hideattic=1&logsort=date&f=u > > > > > >under src/sys/netinet tree, the header file sctp_os_bsd.h includes > >another header file named "opt_sctp.h" from version 1.6. > >Unfortunately I didn't find this file anywhere in the CVS. Is it > >possible to direct me how I can get the file "opt_sctp.h"? > > > >Thanks in advance Sazzad > >_______________________________________________ > >freebsd-net@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, > >send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > > -- > Randall Stewart > NSSTG - Cisco Systems Inc. > 803-345-0369 803-317-4952 (cell) > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 03:45:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07C9116A400 for ; Tue, 26 Jun 2007 03:45:59 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from swin.edu.au (gpo5.cc.swin.edu.au [136.186.1.225]) by mx1.freebsd.org (Postfix) with ESMTP id 7DB7813C480 for ; Tue, 26 Jun 2007 03:45:58 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from [136.186.229.95] (lstewart.caia.swin.edu.au [136.186.229.95]) by swin.edu.au (8.13.6.20060614/8.13.1) with ESMTP id l5Q3IpVb025358; Tue, 26 Jun 2007 13:18:52 +1000 Message-ID: <468085D6.6050706@room52.net> Date: Tue, 26 Jun 2007 13:19:50 +1000 From: Lawrence Stewart User-Agent: Thunderbird 1.5.0.9 (X11/20070123) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on gpo5.cc.swin.edu.au Cc: James Healy Subject: New tool for TCP research [FYI] 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, 26 Jun 2007 03:45:59 -0000 Hi all, Finally managed to wrap up the code and documentation for a little module I thought might be of interest to people on this list. We've released the SIFTR (Statistical Information For TCP Research) code under a BSD licence, and hope some of you may find it useful. It's a tool mostly aimed at the TCP research community, but perhaps someone out there might find another use for all or part of the code. We've also made a technical report available that documents what we learnt whilst transitioning from noob kernel hackers to guys that have a (partial) clue. The report is certainly a useful reference for us and people working at our research centre. We hope it will also be a useful reference for the community to point people at who are new to kernel hacking. The report's title is "An Introduction to FreeBSD 6 Kernel Hacking" and has been released as Centre for Advanced Internet Architectures Technical Report 070622A. The code distributions and technical report can be grabbed from http://caia.swin.edu.au/urp/newtcp/ under the "Tools" and "Papers" sections respectively. If you find a use for the code or any bugs in the code/documentation, we'd be very happy to hear from you. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 10:54:36 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C62116A400 for ; Tue, 26 Jun 2007 10:54:36 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 151D513C48C for ; Tue, 26 Jun 2007 10:54:36 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 26 Jun 2007 03:54:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFWNgEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,463,1175497200"; d="scan'208"; a="497706001:sNHT28382914" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5QAsYv3020536; Tue, 26 Jun 2007 03:54:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5QAsYka010323; Tue, 26 Jun 2007 10:54:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 03:54:34 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 03:54:33 -0700 Message-ID: <4680F0D2.3070201@cisco.com> Date: Tue, 26 Jun 2007 06:56:18 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Palmer References: <82bdb5ec0706251156w789f8998g72b67f453c509634@mail.gmail.com> <46801A44.2010007@cisco.com> <20070626030920.GA1002@in-addr.com> In-Reply-To: <20070626030920.GA1002@in-addr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2007 10:54:34.0039 (UTC) FILETIME=[618AC470:01C7B7E0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2055; t=1182855274; x=1183719274; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20query=20about=20a=20missing=20file=20opt_sctp.h |Sender:=20; bh=WXjkfpMCjxLCPLjUlNnjA5AH+TRXpQNGces5krnkVew=; b=1DtkWzf3wm3nZ6bcVGkooVj4HAExHWaoJbFDkX0UGZizLvXNJg3OAivqhiBxqnKTeBmofRUx PZRuyEhqIPoZhfyNMSwxMCd7aN3sevGZDZUlrjAxk9HwbbkDqPrjXRn0; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Cc: freebsd-net@freebsd.org, sazzadur rahman Subject: Re: A query about a missing file opt_sctp.h 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, 26 Jun 2007 10:54:36 -0000 Gary Palmer wrote: > On Mon, Jun 25, 2007 at 03:40:52PM -0400, Randall Stewart wrote: > >>opt_sctp.h >> >>Is one created by the config program when you run >>config with >> >>options SCTP >> >>in your list of things you want.. >> >>So for example I do >> >>cd /usr/src/sys/i386/conf >>config mymachine >>cd ../compile/mymachine >> >>and if I do >> >>ls -l opt_sctp.h >> >>I will see it there... >> >>That is of course assuming that I have >>SCTP in my config ;-D > > > > Surely it would still be there, as an empty file, even without SCTP? Adding > > options SCTP > > would add something like > > #define SCTP 1 > > to the file AFAIK (at least on 6.x, I doubt config is that much changed > in -current) > Hmm I never looked.. thinking about it.. it should be.. Let me try on a machine configured without sctp :-D R > > >>sazzadur rahman wrote: >> >>>Hello, In FreeBSD CVS, >>>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/?copt=1&hidecvsroot=0&hidenonreadable=1&sortby=&hideattic=1&logsort=date&f=u >>> >>> >>>under src/sys/netinet tree, the header file sctp_os_bsd.h includes >>>another header file named "opt_sctp.h" from version 1.6. >>>Unfortunately I didn't find this file anywhere in the CVS. Is it >>>possible to direct me how I can get the file "opt_sctp.h"? >>> >>>Thanks in advance Sazzad >>>_______________________________________________ >>>freebsd-net@freebsd.org mailing list >>>http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, >>>send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> >>-- >>Randall Stewart >>NSSTG - Cisco Systems Inc. >>803-345-0369 803-317-4952 (cell) >>_______________________________________________ >>freebsd-net@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-net >>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 11:06: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 C0F3E16A400 for ; Tue, 26 Jun 2007 11:06:13 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.freebsd.org (Postfix) with ESMTP id 9B83913C48A for ; Tue, 26 Jun 2007 11:06:13 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2007 04:06:13 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABCPgEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,463,1175497200"; d="scan'208"; a="5578251:sNHT13733466" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5QB6DWp002374; Tue, 26 Jun 2007 04:06:13 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5QB68mo000687; Tue, 26 Jun 2007 11:06:12 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 04:06:08 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 04:06:07 -0700 Message-ID: <4680F388.3090308@cisco.com> Date: Tue, 26 Jun 2007 07:07:52 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lawrence Stewart References: <468085D6.6050706@room52.net> In-Reply-To: <468085D6.6050706@room52.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2007 11:06:08.0119 (UTC) FILETIME=[FF3EF870:01C7B7E1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1906; t=1182855973; x=1183719973; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20New=20tool=20for=20TCP=20research=20[FYI] |Sender:=20; bh=SgsR/OGzthbNBZRCBAvNP/MTIFIVhCMpHNk4v2iLHtM=; b=bw18p+VmZ12jD7yR/rvFz5n5/zImCQ6prN/aYs7rjmZrnawDQcrUZvQzjf45kJplgWH4/VFX U4qm256Xapse9wMVTsW5LkocjJfe1cb3jXxm7TdD5rnO5WgRKaQlrUXr; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); Cc: James Healy , freebsd-net@freebsd.org Subject: Re: New tool for TCP research [FYI] 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, 26 Jun 2007 11:06:13 -0000 Lawrence: Cools stuff... I have my intern working on getting pluggable CC into SCTP and HTCP with Fred's extra's as well... Hmm.. maybe I can align your code to work with SCTP as well.. Neat.. Thanks for the good work :-D R Lawrence Stewart wrote: > Hi all, > > Finally managed to wrap up the code and documentation for a little > module I thought might be of interest to people on this list. We've > released the SIFTR (Statistical Information For TCP Research) code under > a BSD licence, and hope some of you may find it useful. It's a tool > mostly aimed at the TCP research community, but perhaps someone out > there might find another use for all or part of the code. > > We've also made a technical report available that documents what we > learnt whilst transitioning from noob kernel hackers to guys that have a > (partial) clue. The report is certainly a useful reference for us and > people working at our research centre. We hope it will also be a useful > reference for the community to point people at who are new to kernel > hacking. The report's title is "An Introduction to FreeBSD 6 Kernel > Hacking" and has been released as Centre for Advanced Internet > Architectures Technical Report 070622A. > > The code distributions and technical report can be grabbed from > http://caia.swin.edu.au/urp/newtcp/ under the "Tools" and "Papers" > sections respectively. > > If you find a use for the code or any bugs in the code/documentation, > we'd be very happy to hear from you. > > Cheers, > Lawrence > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 12:04:09 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 3C8D716A46C for ; Tue, 26 Jun 2007 12:04:09 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id AB54013C4BA for ; Tue, 26 Jun 2007 12:04:08 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1995577mue for ; Tue, 26 Jun 2007 05:04:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dQ4twUD3JXIQ7khziAl7x1h8roFqzeBrgyqeWvSA6UNvQbRmhqxFFQ/7FGBQZ6wGZza9t46cKBxBcv2f24U8yUZ0vkjP56w3639GXuinlIWAViTcWPYrp4172W0JS8hNPcHcRd7KZpKP0d2K4KPQ8WNLY8qQ68Fh47w8u3MXajA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sohh4C64AIvB+UYWyBWw+PkXmRpMPlk1rl+QLmTLYX8SjZePmjkIe0/Z08hvGQQqOE6SuuN5EziZi/WaWER7N+dKyb3sXcpH7Z/47koZLBS/EUei9DJJLaMS/z0zbXL9TkMkTDByg+BMMeE7zE5MqENOpKxapY7ra4l45DGLGC4= Received: by 10.82.106.14 with SMTP id e14mr14781304buc.1182859447412; Tue, 26 Jun 2007 05:04:07 -0700 (PDT) Received: by 10.82.191.14 with HTTP; Tue, 26 Jun 2007 05:04:07 -0700 (PDT) Message-ID: <80f4f2b20706260504m782e25a2odadaa91be4856e37@mail.gmail.com> Date: Tue, 26 Jun 2007 08:04:07 -0400 From: "Jim Stapleton" To: "Artyom Viklenko" In-Reply-To: <467E2BEC.80305@aws-net.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <80f4f2b20706230440n5abeceb6n6d94eef41f776265@mail.gmail.com> <467D1700.8050006@aws-net.org.ua> <80f4f2b20706231120u6b6f2659xa427b7a54f20b243@mail.gmail.com> <467E2BEC.80305@aws-net.org.ua> Cc: freebsd-net@freebsd.org Subject: Re: ppp/peers/* files 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, 26 Jun 2007 12:04:09 -0000 That partially worked. I could only ping 192.168.1.1 on my local setup (router). I used $ mpd pptp0 However, I couldn't access the work DNS either. The latter output of MPD looked like: ========== pptp0] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) IPADDR [pptp0] IPCP: state change Ack-Sent --> Opened [pptp0] IPCP: LayerUp -> [pptp0] IFACE: Up event [pptp0] setting interface ng0 MTU to 1396 bytes [pptp0] exec: /sbin/ifconfig ng0 netmask 0xffffffff -link0 [pptp0] exec: /sbin/route add -iface lo0 [pptp0] exec: /sbin/route add 0.0.0.0 [pptp0] exec: command returned 256 ========== I could ping and after running mpd, but I could not ping them before running it, or after shutting it down. Both are valid IP addresses on my works internal network. Aside from my nve0 and l0 devices, which look normal, ifconfig displays the following: ========== ng0: flags=88d1 mtu 1396 inet --> netmask 0xffffffff ========== I could not ping the DNS servers. Any suggestions? Thanks, -Jim Stapleton On 6/24/07, Artyom Viklenko wrote: > Jim Stapleton wrote: > > I can't find a way to specify mppe-128 for either pptp or pppd in the > > man files, and every doc I see (including the man pages examples, > > which don't work when I specify it in the file) seem to suggest that I > > use either "mppe-128" or "require-mppe-128" for pppd, neither of which > > work. Any suggestions? > > As far as I know, pppd in FreeBSD does not support natively mppc and > needs patches. (Maybe this functionality provided by pptp.) > > But MPD does! And it support it using in-kernel netgraph subsystem. > So, I suggest to install mpd and set it up to connect to your Windows > VPN server. > > Your configs may look like this. > > mpd.conf file: > > default: > load pptp0 > > pptp0: > new -i ng0 pptp0 pptp0 > set bundle enable compression > set bundle disable multilink > set bundle authname "your-username" > set bundle password "your-password" > set iface disable on-demand > set iface idle 0 > set iface mtu 1460 > set iface route default > set link yes acfcomp protocomp > set link disable pap > set link accept chap-md5 chap-msv1 chap-msv2 chap > set link enable no-orig-auth > set link mtu 1460 > set link mru 1460 > set link keep-alive 10 60 > set ipcp yes vjcomp > set ipcp ranges 0.0.0.0/0 0.0.0.0/0 > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e56 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > set pptp peer > set pptp disable incoming > set pptp enable originate out-call > set pptp disable windowing > set pptp disable delayed-ack > open iface > > mpd.links file: > > pptp0: > set link type pptp > > > Also make shure you have loaded (or compiled in kernel): > > ng_bpf.ko > netgraph.ko > ng_ether.ko > ng_iface.ko > ng_ksocket.ko > ng_mppc.ko > rc4.ko > ng_netflow.ko > ng_ppp.ko > ng_pptpgre.ko > ng_socket.ko > ng_tee.ko > ng_vjc.ko > ng_tty.ko > ng_async.ko > > Hope this helps. > > -- > Sincerely yours, > Artyom Viklenko. > ------------------------------------------------------- > artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem > FreeBSD: The Power to Serve - http://www.freebsd.org > From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 12:57: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 3572216A400 for ; Tue, 26 Jun 2007 12:57:37 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 9784B13C447 for ; Tue, 26 Jun 2007 12:57:35 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [10.100.0.23] (vl-office.vl.net.ua [194.44.81.189]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l5QCvT92041956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jun 2007 15:57:32 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <46810D3A.6030308@aws-net.org.ua> Date: Tue, 26 Jun 2007 15:57:30 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 1.5.0.10 (X11/20070416) MIME-Version: 1.0 To: Jim Stapleton References: <80f4f2b20706230440n5abeceb6n6d94eef41f776265@mail.gmail.com> <467D1700.8050006@aws-net.org.ua> <80f4f2b20706231120u6b6f2659xa427b7a54f20b243@mail.gmail.com> <467E2BEC.80305@aws-net.org.ua> <80f4f2b20706260504m782e25a2odadaa91be4856e37@mail.gmail.com> In-Reply-To: <80f4f2b20706260504m782e25a2odadaa91be4856e37@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Tue, 26 Jun 2007 15:57:32 +0300 (EEST) X-Virus-Scanned: ClamAV 0.90.3/3526/Tue Jun 26 12:14:26 2007 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: ppp/peers/* files 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, 26 Jun 2007 12:57:37 -0000 Jim Stapleton wrote: > That partially worked. I could only ping 192.168.1.1 on my local setup > (router). > > I used > $ mpd pptp0 > > However, I couldn't access the work DNS either. The latter output of > MPD looked like: > ========== > pptp0] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) > IPADDR > [pptp0] IPCP: state change Ack-Sent --> Opened > [pptp0] IPCP: LayerUp > -> > [pptp0] IFACE: Up event > [pptp0] setting interface ng0 MTU to 1396 bytes > [pptp0] exec: /sbin/ifconfig ng0 netmask > 0xffffffff -link0 > [pptp0] exec: /sbin/route add -iface lo0 > [pptp0] exec: /sbin/route add 0.0.0.0 > [pptp0] exec: command returned 256 > ========== > > > I could ping and after running mpd, but I > could not ping them before running it, or after shutting it down. Both > are valid IP addresses on my works internal network. > > Aside from my nve0 and l0 devices, which look normal, ifconfig > displays the following: > > ========== > ng0: flags=88d1 mtu 1396 > inet --> netmask 0xffffffff > ========== > > I could not ping the DNS servers. > > Any suggestions? I think you need static route to your VPN server. After setting up tullel your default route changes. This can lead to incorrect routing. -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 13:23: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 1A50316A421 for ; Tue, 26 Jun 2007 13:23:12 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0514C13C447 for ; Tue, 26 Jun 2007 13:23:10 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: by ug-out-1314.google.com with SMTP id u2so100277uge for ; Tue, 26 Jun 2007 06:23:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WmYN4y/bkHasHXcE2NPD7iCZXDj7VUP6Qg5OCpcggZ4OAmDcmmXwzMxyCUsUSOPaYjpMgO7qQ/AOxESioSJbViAbe/CKP6YvfT0NCgyRyCXBCDkJxlk/8/kMJ5a5TXipXvFaIRdv9bR8g3u7dg1puSyjvC7AapVd+v8Vmvy5YEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UT41skN0bFrqO6N7illwvSjOcfCWwbodgpK5ayJLeBrVvp4diAMHYXLrBZ/PyqTRs0hr9gMsNBGuL56Ixq0ntbVCpUfkrgKzAFKY0tIs8MR5Bx/VzuQrOyHZcTzc5de19fgiNvrQGjQ15Syp2jPAWssQCi+OYPunpkl1EP0xdjE= Received: by 10.82.162.14 with SMTP id k14mr14959147bue.1182864188828; Tue, 26 Jun 2007 06:23:08 -0700 (PDT) Received: by 10.82.191.14 with HTTP; Tue, 26 Jun 2007 06:23:08 -0700 (PDT) Message-ID: <80f4f2b20706260623y6b7514e3q64879b3877fc2ac2@mail.gmail.com> Date: Tue, 26 Jun 2007 09:23:08 -0400 From: "Jim Stapleton" To: "Artyom Viklenko" , freebsd-net@freebsd.org In-Reply-To: <46810D3A.6030308@aws-net.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <80f4f2b20706230440n5abeceb6n6d94eef41f776265@mail.gmail.com> <467D1700.8050006@aws-net.org.ua> <80f4f2b20706231120u6b6f2659xa427b7a54f20b243@mail.gmail.com> <467E2BEC.80305@aws-net.org.ua> <80f4f2b20706260504m782e25a2odadaa91be4856e37@mail.gmail.com> <46810D3A.6030308@aws-net.org.ua> Cc: Subject: Re: ppp/peers/* files 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, 26 Jun 2007 13:23:12 -0000 What man/handbook pages/sections should I look at to get a clue. I'm so far from having one, I don't even know the direction... Thanks, -Jim Stapleton On 6/26/07, Artyom Viklenko wrote: > Jim Stapleton wrote: > > That partially worked. I could only ping 192.168.1.1 on my local setup > > (router). > > > > I used > > $ mpd pptp0 > > > > However, I couldn't access the work DNS either. The latter output of > > MPD looked like: > > ========== > > pptp0] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) > > IPADDR > > [pptp0] IPCP: state change Ack-Sent --> Opened > > [pptp0] IPCP: LayerUp > > -> > > [pptp0] IFACE: Up event > > [pptp0] setting interface ng0 MTU to 1396 bytes > > [pptp0] exec: /sbin/ifconfig ng0 netmask > > 0xffffffff -link0 > > [pptp0] exec: /sbin/route add -iface lo0 > > [pptp0] exec: /sbin/route add 0.0.0.0 > > [pptp0] exec: command returned 256 > > ========== > > > > > > I could ping and after running mpd, but I > > could not ping them before running it, or after shutting it down. Both > > are valid IP addresses on my works internal network. > > > > Aside from my nve0 and l0 devices, which look normal, ifconfig > > displays the following: > > > > ========== > > ng0: flags=88d1 mtu 1396 > > inet --> netmask 0xffffffff > > ========== > > > > I could not ping the DNS servers. > > > > Any suggestions? > > I think you need static route to your VPN server. > After setting up tullel your default route changes. > This can lead to incorrect routing. > > > -- > Sincerely yours, > Artyom Viklenko. > ------------------------------------------------------- > artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem > FreeBSD: The Power to Serve - http://www.freebsd.org > From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 13:30:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8D6616A400 for ; Tue, 26 Jun 2007 13:30:24 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id 40FD613C483 for ; Tue, 26 Jun 2007 13:30:22 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [192.168.32.253]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l5QDUK4M042303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 16:30:20 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Date: Tue, 26 Jun 2007 16:30:15 +0300 (EEST) From: Artyom Viklenko To: Jim Stapleton In-Reply-To: <80f4f2b20706260623y6b7514e3q64879b3877fc2ac2@mail.gmail.com> Message-ID: <20070626162827.X42212@alf.aws-net.org.ua> References: <80f4f2b20706230440n5abeceb6n6d94eef41f776265@mail.gmail.com> <467D1700.8050006@aws-net.org.ua> <80f4f2b20706231120u6b6f2659xa427b7a54f20b243@mail.gmail.com> <467E2BEC.80305@aws-net.org.ua> <80f4f2b20706260504m782e25a2odadaa91be4856e37@mail.gmail.com> <46810D3A.6030308@aws-net.org.ua> <80f4f2b20706260623y6b7514e3q64879b3877fc2ac2@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Tue, 26 Jun 2007 16:30:20 +0300 (EEST) X-Virus-Scanned: ClamAV 0.90.3/3528/Tue Jun 26 15:30:45 2007 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: ppp/peers/* files 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, 26 Jun 2007 13:30:24 -0000 On Tue, 26 Jun 2007, Jim Stapleton wrote: > What man/handbook pages/sections should I look at to get a clue. I'm > so far from having one, I don't even know the direction... see handbook section about networking. simply speaking enter route add ip-of-vpn-server ip-of-your-lan-gateway then start MPD and check is all ok. if yes, you can add this route to /etc/rc.conf using static_routes variable. > > Thanks, > -Jim Stapleton > > On 6/26/07, Artyom Viklenko wrote: >> Jim Stapleton wrote: >> > That partially worked. I could only ping 192.168.1.1 on my local setup >> > (router). >> > >> > I used >> > $ mpd pptp0 >> > >> > However, I couldn't access the work DNS either. The latter output of >> > MPD looked like: >> > ========== >> > pptp0] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) >> > IPADDR >> > [pptp0] IPCP: state change Ack-Sent --> Opened >> > [pptp0] IPCP: LayerUp >> > -> >> > [pptp0] IFACE: Up event >> > [pptp0] setting interface ng0 MTU to 1396 bytes >> > [pptp0] exec: /sbin/ifconfig ng0 netmask >> > 0xffffffff -link0 >> > [pptp0] exec: /sbin/route add -iface lo0 >> > [pptp0] exec: /sbin/route add 0.0.0.0 >> > [pptp0] exec: command returned 256 >> > ========== >> > >> > >> > I could ping and after running mpd, but I >> > could not ping them before running it, or after shutting it down. Both >> > are valid IP addresses on my works internal network. >> > >> > Aside from my nve0 and l0 devices, which look normal, ifconfig >> > displays the following: >> > >> > ========== >> > ng0: flags=88d1 mtu 1396 >> > inet --> netmask 0xffffffff >> > ========== >> > >> > I could not ping the DNS servers. >> > >> > Any suggestions? >> >> I think you need static route to your VPN server. >> After setting up tullel your default route changes. >> This can lead to incorrect routing. >> >> >> -- >> Sincerely yours, >> Artyom Viklenko. >> ------------------------------------------------------- >> artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem >> FreeBSD: The Power to Serve - http://www.freebsd.org >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 14:22: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 11EF516A421 for ; Tue, 26 Jun 2007 14:22:23 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7A98F13C469 for ; Tue, 26 Jun 2007 14:22:22 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 31791 invoked from network); 26 Jun 2007 13:33:19 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Jun 2007 13:33:19 -0000 Message-ID: <4681211F.2030607@freebsd.org> Date: Tue, 26 Jun 2007 16:22:23 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Doug Ambrisko References: <200706252220.l5PMKVEX088397@ambrisko.com> In-Reply-To: <200706252220.l5PMKVEX088397@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ambrisko@freebsd.org, FreeBSD Net , Marko Zec , releng@freebsd.org, Julian Elischer , "Bruce M. Simpson" Subject: Re: Vimage virtual networking and 7.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: Tue, 26 Jun 2007 14:22:23 -0000 Doug Ambrisko wrote: > Bruce M. Simpson writes: > [snip] > | My concern is that vimage may be a very intrusive change indeed where > | these matters are concerned, unless the vimage patches are being kept > | up-to-date and regression tested as issues are resolved and new features > | added. > > Just like it was mostly working in 4.X then never worked with 5.X & 6.X > and now it sounds like it is working in 7.X but will it be working in > 8.X etc? That's a lot of effort he is putting in to keep going dead. > Note this comment is based on out-side observation. I know a few people > that used it in 4.X. I played with it bit. Yes, it would help IronPort. > I'd rather not have to keep merging it. I'm not involved in with the > FreeBSD network folks to know the scope and the missing bits. IronPort > might be able to help somewhat to accelerate it. IMHO it's too late to fit it into 7.x in a sane and non-bitrotting way. It should have gone in right after BSDCan at latest. The window has closed. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 14:55: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 CA17216A421 for ; Tue, 26 Jun 2007 14:55:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 7D84613C45E for ; Tue, 26 Jun 2007 14:55:28 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id AAA17449; Wed, 27 Jun 2007 00:30:11 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 27 Jun 2007 00:30:10 +1000 (EST) From: Ian Smith To: Artyom Viklenko In-Reply-To: <20070626162827.X42212@alf.aws-net.org.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Jim Stapleton Subject: Re: ppp/peers/* files 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, 26 Jun 2007 14:55:29 -0000 On Tue, 26 Jun 2007, Artyom Viklenko wrote: > On Tue, 26 Jun 2007, Jim Stapleton wrote: > > > What man/handbook pages/sections should I look at to get a clue. I'm > > so far from having one, I don't even know the direction... > > see handbook section about networking. > > simply speaking enter > > route add ip-of-vpn-server ip-of-your-lan-gateway > > > > then start MPD and check is all ok. > if yes, you can add this route to /etc/rc.conf using > static_routes variable. Maybe browsing from file:///usr/local/share/doc/mpd4/mpd.html especially '5.5: PPTP device type commands' might help also? Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 17:01: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 5B37F16A468 for ; Tue, 26 Jun 2007 17:01:40 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id CFDF513C44B for ; Tue, 26 Jun 2007 17:01:39 +0000 (UTC) (envelope-from mav@freebsd.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 24448310; Tue, 26 Jun 2007 18:50:23 +0300 Message-ID: <468135BF.8010407@freebsd.org> Date: Tue, 26 Jun 2007 18:50:23 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.0 (X11/20070424) MIME-Version: 1.0 To: FreeBSD Net , mpd-users@lists.sourceforge.net X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Mpd-4.2 released. 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, 26 Jun 2007 17:01:40 -0000 Hi. I'm glad to present version 4.2 of MPD. It includes many new features, performance improvements and fixes. The most significant and unique new feature of mpd-4.2 is a link repeater functionality. It allows mpd to accept incoming connection of any supported type and forward it out as same or different type outgoing connection. As example, this functionality allows mpd to implement real LAC with accepting incoming PPPoE connection from client and forwarding it using L2TP tunnel to LNS. All other software L2TP implementations I know is only a LAC emulators without real incoming calls forwarding abilities. Also mpd-4.2 presents: - PPTP listening on multiple different IPs, - L2TP tunnel authentication with shared secret, - fast traffic filtering, shaping and rate-limiting using ng_bpf and ng_car, - new 'ext-auth' auth backend as full-featured local alternative to 'radius-auth', - NetFlow generation for both incoming and outgoing packets same time, - restored control console on stdin. Replacing external ifconfig and route calls with their internal implementations and other optimizations in 4.2 gave significant performance boost in session management. Newly implemented overload protection mechanism partially drops incoming connection requests for periods of critical load by monitoring daemon's internal message queue. As result, simple 2GHz P4 system is now able to accept, authenticate and completely process spike of 1000 concurrent PPPoE connections in just a 30 seconds. Complete change log as always can be found at: http://mpd.sourceforge.net/doc/mpd5.html -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 17:21:33 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 B7F2716A400 for ; Tue, 26 Jun 2007 17:21:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outG.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id A2E3113C45D for ; Tue, 26 Jun 2007 17:21:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 26 Jun 2007 10:21:33 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id D1FAF125A24; Tue, 26 Jun 2007 10:21:32 -0700 (PDT) Message-ID: <46814B21.5060800@elischer.org> Date: Tue, 26 Jun 2007 10:21:37 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Alexander Motin References: <468135BF.8010407@freebsd.org> In-Reply-To: <468135BF.8010407@freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 26 Jun 2007 17:21:33 -0000 Alexander Motin wrote: > Hi. > > I'm glad to present version 4.2 of MPD. It includes many new features, > performance improvements and fixes. [...] > Complete change log as always can be found at: > http://mpd.sourceforge.net/doc/mpd5.html > There has been some talk about whether mpd should be put in the base system to replace our 3 other ppp implementations. I guess one step would be to see what the usage cases would be for replacing if_ppp and sppp and a first step would be to see how many users of these there are. Brian talked a bit about this at the last DevSummit.. It just needs someone with the time and knowledge. Possibly Brian could work with Alex to make sure that all the functionality of ppp is in mpd. He did say that teh command language would need looking at to ensure that people would have a chance to convert their scripts.. From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 20:17:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB86716A400 for ; Tue, 26 Jun 2007 20:17:43 +0000 (UTC) (envelope-from lexx@cpms.ru) Received: from mail.cpms.ru (mail.cpms.ru [87.236.28.11]) by mx1.freebsd.org (Postfix) with ESMTP id 62FA113C448 for ; Tue, 26 Jun 2007 20:17:43 +0000 (UTC) (envelope-from lexx@cpms.ru) Received: from mailnull by mail.cpms.ru with spam-scanned (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3GuA-0003UN-I4 for freebsd-net@freebsd.org; Tue, 26 Jun 2007 23:40:54 +0400 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.cpms.ru X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=ALL_TRUSTED, REPTO_OVERQUOTE_THEBAT autolearn=disabled version=3.1.0 Received: from lxw.cpms.ru ([87.236.24.142]) by mail.cpms.ru with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3GuA-0003UJ-D5; Tue, 26 Jun 2007 23:40:50 +0400 Date: Tue, 26 Jun 2007 23:40:35 +0400 From: "Vadim A. Shklyaev" X-Mailer: The Bat! (v3.71.04) Professional Organization: CPMS X-Priority: 3 (Normal) Message-ID: <487823463.20070626234035@cpms.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: libalias / ng_nat memory leak X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Vadim A. Shklyaev" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2007 20:17:43 -0000 Hello, freebsd-net. We have large NAT server with 256 NAT instances there. Earlier, we used a lot of natd daemons, but recently (some months ago) i've moved it to ng_nat. And it seems to me, that there is a memory leak there, cause allocated memory grows constantly every day - after system startup there were only about 40Mbytes allocated, now - after 27 days uptime - it has about 373Mb. That machine has 1Gb of RAM, and it's proved, that it cannot work more than 2 months cause of this. Can you advise something, what can I try to do to debug or fix this issue? # sysctl kern.malloc | grep libalias libalias2914025373438K -1590585033 128 # uname -a FreeBSD nt1 6.2-STABLE FreeBSD 6.2-STABLE #0: Wed May 30 04:37:13 MSD 2007 root@nt1:/mnt/obj/mnt/src/sys/SRV64-MP amd64 # cat /var/run/dmesg.boot | head -24 Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #0: Wed May 30 04:37:13 MSD 2007 root@nt1:/mnt/obj/mnt/src/sys/SRV64-MP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 3.40GHz (3398.30-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 Features=0xbfebfbff Features2=0xe49d> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 real memory = 1072013312 (1022 MB) avail memory = 1027846144 (980 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 5 ioapic1: WARNING: intbase 30 != expected base 24 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 30-53 on motherboard #top last pid: 51703; load averages: 0.82, 0.89, 0.90 up 27+18:15:18 23:39:17 24 processes: 1 running, 23 sleeping CPU states: 0.0% user, 0.0% nice, 6.4% system, 43.3% interrupt, 50.3% idle Mem: 12M Active, 4268K Inact, 34M Wired, 63M Buf, 521M Free Swap: -- Best regards, Vadim A. Shklyaev, CPMS Network http://network.cpms.ru/ LX-RIPE, LEXX-RIPN, ICQ 23924367 From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 21:33:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA54916A475; Tue, 26 Jun 2007 21:33:05 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 9020B13C45D; Tue, 26 Jun 2007 21:33:05 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from bmah.local (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l5QLX45g021208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 14:33:04 -0700 Message-ID: <46818609.3080202@freebsd.org> Date: Tue, 26 Jun 2007 14:32:57 -0700 From: "Bruce A. Mah" User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eric F Crist References: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> <468011FC.4050308@FreeBSD.org> <7731B558-35C7-4E22-A40D-8BCE208AFD6A@secure-computing.net> <468063F6.2050303@FreeBSD.org> <8AA398FC-A753-4BB8-A93F-224FDDCE41BA@secure-computing.net> In-Reply-To: <8AA398FC-A753-4BB8-A93F-224FDDCE41BA@secure-computing.net> X-Enigmail-Version: 0.95.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDB76B82339FFF460601F957C" Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: IPv6 Woes... 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, 26 Jun 2007 21:33:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB76B82339FFF460601F957C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Eric F Crist wrote: > On Jun 25, 2007, at 7:55 PMJun 25, 2007, Bruce M. Simpson wrote: >=20 >> Eric F Crist wrote: >>> My problem isn't getting out to 2001:4980:1::5, it's getting to my =20 >>> LAN, the 2001:4980:1:111::/64 network. My gateway, the machine =20 >>> from which I posted the routing and ifconfig information, is able =20 >>> to ping across the tunnel, and to the internet just fine. Nothing =20 >>> is able to get from the gateway to my LAN, however. Is it a =20 >>> problem with the fxp driver, or perhaps my setup with the ethernet =20 >>> bridging? >> You appear to have a /64 network address on the inside of your v6 =20 >> router. Are you using stateless address auto-configuration? You =20 >> appear to have statically assigned ....::145 as a host address on =20 >> that net. >> >> My setup works fine if I ping the network address of my v6 router =20 >> from the v6 enabled hosts in my lab. >> >> When you ping local machines on the inside LAN from that router, do =20 >> you see NDP entries being created? Hi Eric-- First note that I'm a different Bruce than the chap who's been helping thus far. :-) BTW, use "ndp -a" to see this. >> You shouldn't need to use bridging to achieve what you want in this =20 >> scenario, in fact it makes no sense because you want to route v6 =20 >> traffic over the gif, therefore ethernet bridging is not relevant =20 >> here. I'm not quite so sure about this...see below. > First, thanks for taking time to help me through this. Here's some =20 > more information regarding the topography of my network. My FBSD =20 > firewall is running with 'options BRIDGE' in the kernel, and the =20 > following two lines in /etc/sysctl.conf: >=20 > net.link.ether.bridge.enable=3D1 > net.link.ether.bridge.config=3Dfxp0,fxp1 Your setup is not *too* different from what I have at home in terms of network topology and what you hope to accomplish. (I have a Soekris net4801 run 6.2-STABLE and acting as a filtering bridge between an IPv4 /29 and the rest of the Internet, and also terminating a gif(4) tunnel for IPv6.) > This is so that I don't have to do routing on my firewall. I have a =20 > IPv4 /28 network, so a limited number of IP addresses, this saves one = > of those. This system is filtering traffic with PF. That's really =20 > the only reason for the bridging. Also, it does allow me to do =20 > traffic shaping and bandwidth monitoring. This bridging stuff =20 > really, as you said, has nothing to do with my IPv6 configuration =20 > issues. I think the biggest difference between your network and mine is that rather than using options BRIDGE I'm using the if_bridge(4) driver between my "inside" and "outside" network interfaces. The physical interfaces in the bridge are unnumbered and the if_bridge pseudo_interface has IPv4 and IPv6 addresses. The main reason for doing this is that I've seen that bridge(4) can have difficulty determining the correct physical interface to use for packets that originate on the bridging host. I recall having this problem with pfnat. (I don't remember the exact details, but I did some postings to the m0n0wall mailing lists on this topic some time ago...your favorite search engine can probably help find these messages.) I wonder if the problem I've seen with bridge(4) might be related to your IPv6 problems (since you're terminating the tunnel on your firewall). If so, maybe switching to if_bridge(4) as I've described above might help things. In any case, good luck! Bruce. --------------enigDB76B82339FFF460601F957C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGgYYN2MoxcVugUsMRAtecAKCRbSU5N7rvqejW+V+wNnkEhYEfXgCg+W3P XLYrjIPGYz3KBvoEYX3fW10= =XItX -----END PGP SIGNATURE----- --------------enigDB76B82339FFF460601F957C-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 22:15:02 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 C8C2E16A421; Tue, 26 Jun 2007 22:15:02 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id 6BC9F13C465; Tue, 26 Jun 2007 22:15:02 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [192.168.1.2] (unknown [209.240.66.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id CD2DB1702D; Tue, 26 Jun 2007 17:15:01 -0500 (CDT) In-Reply-To: <46818609.3080202@freebsd.org> References: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> <468011FC.4050308@FreeBSD.org> <7731B558-35C7-4E22-A40D-8BCE208AFD6A@secure-computing.net> <468063F6.2050303@FreeBSD.org> <8AA398FC-A753-4BB8-A93F-224FDDCE41BA@secure-computing.net> <46818609.3080202@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Eric F Crist Date: Tue, 26 Jun 2007 17:14:59 -0500 To: Bruce A. Mah X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: IPv6 Woes... 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, 26 Jun 2007 22:15:02 -0000 On Jun 26, 2007, at 4:32 PMJun 26, 2007, Bruce A. Mah wrote: > If memory serves me right, Eric F Crist wrote: >> Hi Eric-- > > First note that I'm a different Bruce than the chap who's been helping > thus far. :-) > > BTW, use "ndp -a" to see this. > Your setup is not *too* different from what I have at home in terms of > network topology and what you hope to accomplish. (I have a Soekris > net4801 run 6.2-STABLE and acting as a filtering bridge between an > IPv4 > /29 and the rest of the Internet, and also terminating a gif(4) tunnel > for IPv6.) > >> This is so that I don't have to do routing on my firewall. I have a >> IPv4 /28 network, so a limited number of IP addresses, this saves one >> of those. This system is filtering traffic with PF. That's really >> the only reason for the bridging. Also, it does allow me to do >> traffic shaping and bandwidth monitoring. This bridging stuff >> really, as you said, has nothing to do with my IPv6 configuration >> issues. > > I think the biggest difference between your network and mine is that > rather than using options BRIDGE I'm using the if_bridge(4) driver > between my "inside" and "outside" network interfaces. The physical > interfaces in the bridge are unnumbered and the if_bridge > pseudo_interface has IPv4 and IPv6 addresses. > > The main reason for doing this is that I've seen that bridge(4) can > have > difficulty determining the correct physical interface to use for > packets > that originate on the bridging host. I recall having this problem > with > pfnat. (I don't remember the exact details, but I did some > postings to > the m0n0wall mailing lists on this topic some time ago...your favorite > search engine can probably help find these messages.) > > I wonder if the problem I've seen with bridge(4) might be related to > your IPv6 problems (since you're terminating the tunnel on your > firewall). If so, maybe switching to if_bridge(4) as I've described > above might help things. > > In any case, good luck! Bruce! Thanks for all the help! That did the trick! Only one more thing that's holding me up. On my gateway, I've got 2001:4980:1:111::145/64 as the primary IP address. In addition, I've got 2001:4980:1:111::1/128 as an alias. I can ping/connect to the xxx:145 address, but not the xxx:1 address. What did I configure wrong? Here's the output of netstat - r -f inet6: Routing tables Internet6: Destination Gateway Flags Refs Use Mtu Netif Expire :: localhost.secure-computing.net UGRS 0 0 16384 lo0 => default 2001:4980:1::5 UGS 0 0 1280 gif0 localhost.secure-computing.net localhost.secure-computing.net UHL 5 0 16384 lo0 ::ffff:0.0.0.0 localhost.secure-computing.net UGRS 0 0 16384 lo0 2001:4980:1::4 link#7 UC 0 0 1280 gif0 2001:4980:1::5 link#7 UHLW 2 4 1280 gif0 2001:4980:1::6 link#7 UHL 1 4 1280 lo0 2001:4980:1:111:: link#1 UC 0 1 1500 fxp0 2001:4980:1:111::1 00:06:5b:05:30:19 UHL 1 4 1500 lo0 2001:4980:1:111::145 00:06:5b:05:30:19 UHL 2 4 1500 lo0 2001:4980:1:111::147 00:06:5b:38:2e:82 UHLW 1 14 1500 fxp0 fe80:: localhost.secure-computing.net UGRS 0 0 16384 lo0 fe80::%fxp0 link#1 UC 0 0 1500 fxp0 fe80::206:5bff:fe05:3019%fxp0 00:06:5b:05:30:19 UHL 1 0 1500 lo0 fe80::%fxp1 link#2 UC 0 0 1500 fxp1 fe80::206:5bff:fe05:301a%fxp1 00:06:5b:05:30:1a UHL 1 0 1500 lo0 fe80::%lo0 fe80::1%lo0 U 0 0 16384 lo0 fe80::1%lo0 link#3 UHL 1 0 16384 lo0 fe80::%gif0 link#7 UC 0 0 1280 gif0 fe80::206:5bff:fe05:3019%gif0 link#7 UHL 1 0 1280 lo0 fe80::%tun0 link#8 UC 0 0 1500 tun0 fe80::206:5bff:fe05:3019%tun0 link#8 UHL 1 0 1500 lo0 ff01:1:: link#1 UC 0 0 1500 fxp0 ff01:2:: link#2 UC 0 0 1500 fxp1 ff01:3:: localhost.secure-computing.net UC 0 0 16384 lo0 ff01:7:: link#7 UC 0 0 1280 gif0 ff01:8:: link#8 UC 0 0 1500 tun0 ff02:: localhost.secure-computing.net UGRS 0 0 16384 lo0 ff02::%fxp0 link#1 UC 0 0 1500 fxp0 ff02::%fxp1 link#2 UC 0 0 1500 fxp1 ff02::%lo0 localhost.secure-computing.net UC 0 0 16384 lo0 ff02::%gif0 link#7 UC 0 0 1280 gif0 ff02::%tun0 link#8 UC 0 0 1500 tun0 Thanks for one last piece of advice! ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 22:16:14 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 90DB316A41F for ; Tue, 26 Jun 2007 22:16:14 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.freebsd.org (Postfix) with SMTP id 55A7E13C458 for ; Tue, 26 Jun 2007 22:16:14 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from zone3000.kharkov.ua (HELO localhost) (217.144.69.37) by 0 with SMTP; 26 Jun 2007 21:49:33 -0000 Date: Wed, 27 Jun 2007 00:49:36 +0300 From: Nikolay Pavlov To: Alexander Motin Message-ID: <20070626214936.GC79335@zone3000.net> Mail-Followup-To: Nikolay Pavlov , Alexander Motin , FreeBSD Net , mpd-users@lists.sourceforge.net References: <468135BF.8010407@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <468135BF.8010407@freebsd.org> X-Operating-System: FreeBSD 6.2-RELEASE-p4 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: FreeBSD Net , mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 26 Jun 2007 22:16:14 -0000 On Tuesday, 26 June 2007 at 18:50:23 +0300, Alexander Motin wrote: > Hi. > > I'm glad to present version 4.2 of MPD. It includes many new features, > performance improvements and fixes. > > The most significant and unique new feature of mpd-4.2 is a link > repeater functionality. It allows mpd to accept incoming connection of > any supported type and forward it out as same or different type outgoing > connection. > As example, this functionality allows mpd to implement real LAC with > accepting incoming PPPoE connection from client and forwarding it using > L2TP tunnel to LNS. All other software L2TP implementations I know is > only a LAC emulators without real incoming calls forwarding abilities. > > Also mpd-4.2 presents: > - PPTP listening on multiple different IPs, > - L2TP tunnel authentication with shared secret, > - fast traffic filtering, shaping and rate-limiting using ng_bpf and > ng_car, > - new 'ext-auth' auth backend as full-featured local alternative to > 'radius-auth', > - NetFlow generation for both incoming and outgoing packets same time, > - restored control console on stdin. > > Replacing external ifconfig and route calls with their internal > implementations and other optimizations in 4.2 gave significant > performance boost in session management. > Newly implemented overload protection mechanism partially drops incoming > connection requests for periods of critical load by monitoring daemon's > internal message queue. > As result, simple 2GHz P4 system is now able to accept, authenticate and > completely process spike of 1000 concurrent PPPoE connections in just a > 30 seconds. > > Complete change log as always can be found at: > http://mpd.sourceforge.net/doc/mpd5.html > > -- > Alexander Motin > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" This is good news. Thanks Alex. This is probably a new feature request, but is this possible to create some kind of VirtualTemplate interface like it is in Cisco access routers. Currently i have to configure bunch of different ng interfaces for every kind user. However on my Cisco 7206VXR i can bundle physical link together with VirtaulTemplate interface in one vpdn-group config like this: vpdn-template dslisp description "dslisp LNS" local name DSLISP l2tp tunnel password 7 xxxxxxxxxxxxx vpdn-group l2tp-301 accept-dialin protocol l2tp virtual-template 1 terminate-from hostname nexxia1006 lcp renegotiation always source vpdn-template dslisp interface Virtual-Template1 ip unnumbered GigabitEthernet0/1 ip mtu 1460 ip tcp header-compression ip tcp adjust-mss 1460 load-interval 60 no peer default ip address keepalive 30 ppp mru match ppp encrypt mppe auto passive stateful ppp authentication pap chap dslisprealm ppp authorization dslisprealm ppp accounting dslisprealm And all the ppp interfaces for all users will use this configuration as a template. -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ====================================================================== From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 22:50:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4A8C16A421 for ; Tue, 26 Jun 2007 22:50:54 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from mail.alkar.net (mail.alkar.net [195.248.191.95]) by mx1.freebsd.org (Postfix) with ESMTP id 47FE113C44B for ; Tue, 26 Jun 2007 22:50:54 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from [195.248.178.122] (HELO [192.168.3.2]) by mail.alkar.net (CommuniGate Pro SMTP 5.1.7) with ESMTPS id 785133594; Wed, 27 Jun 2007 01:50:52 +0300 Message-ID: <46819834.4030608@freebsd.org> Date: Wed, 27 Jun 2007 01:50:28 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <468135BF.8010407@freebsd.org> <46814B21.5060800@elischer.org> In-Reply-To: <46814B21.5060800@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 26 Jun 2007 22:50:54 -0000 Julian Elischer wrote: > There has been some talk about whether mpd should be put in the base > system to replace our 3 other ppp implementations. I guess one step > would be to see what the usage cases would be for replacing if_ppp and > sppp and a first step > would be to see how many users of these there are. As I see situation now: ppp - good user-level implementation. Not very fast, but stable, flexible and able to be used with other programs like pppoed. pppd - outdated many years. In theory can be fast with modem links, but who need them now? If used with other programs like poptop will loose it's performance to ppp level due to context switches. sppp - outdated too, but I have never used it. Is there anything except ISDN using it? In my country ISDN is mostly out of use now. mpd - very fast and functional solution. But it is a daemon with limited abilities to be used by other software like getty or some wrappers like pppoed for ppp or GUIs like kppp. > Brian talked a bit about this at the last DevSummit.. It just needs someone > with the time and knowledge. Possibly Brian could work with Alex to make > sure that > all the functionality of ppp is in mpd. He did say that teh command > language would need > looking at to ensure that people would have a chance to convert their > scripts.. Mpd uses command language different from all others, but I think it is not a big problem. If we would compare supported PPP extensions then I think mpd will now win in most nominations. The main problem I think is a general usage differences. Mpd was planned and implemented as daemon. It have very limited foreground operation and integration abilities. pppd as example is able to be called from getty and terminate after link disconnect, while mpd does not. sppp is somehow used by i4b project, but I know nothing about it. If somebody could help me to make list of reasonable requirements and/or wanted usage examples then I surely will try to implement missing parts. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Tue Jun 26 23:25:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E37816A41F for ; Tue, 26 Jun 2007 23:25:48 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from mail.alkar.net (mail.alkar.net [195.248.191.95]) by mx1.freebsd.org (Postfix) with ESMTP id F226313C465 for ; Tue, 26 Jun 2007 23:25:47 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from [195.248.178.122] (HELO [192.168.3.2]) by mail.alkar.net (CommuniGate Pro SMTP 5.1.7) with ESMTPS id 785156040; Wed, 27 Jun 2007 02:25:46 +0300 Message-ID: <4681A062.9040009@freebsd.org> Date: Wed, 27 Jun 2007 02:25:22 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nikolay Pavlov References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> In-Reply-To: <20070626214936.GC79335@zone3000.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 26 Jun 2007 23:25:48 -0000 Nikolay Pavlov wrote: > This is probably a new feature request, but is this possible to create > some kind of VirtualTemplate interface like it is in Cisco access > routers. Currently i have to configure bunch of different ng interfaces > for every kind user. However on my Cisco 7206VXR i can bundle physical > link together with VirtaulTemplate interface in one vpdn-group config > like this: > > And all the ppp interfaces for all users will use this configuration > as a template. Yes, I am thinking about that. That is not trivial change. It will require changing all internal model from static to the dynamic one. But that change also should give many other bonuses so I would like to try. One of problems is more or less new config file syntax required. I have very limited cisco experience, so it is difficult for me to adopt their model to mpd, but I would not like to reinvent a wheel. I will be grateful for any ideas/examples of how do you see that. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 00:00:57 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 96C1E16A46B for ; Wed, 27 Jun 2007 00:00:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 847DF13C45E for ; Wed, 27 Jun 2007 00:00:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 26 Jun 2007 17:00:56 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 8BFAB125A28; Tue, 26 Jun 2007 17:00:56 -0700 (PDT) Message-ID: <4681A8BE.7020905@elischer.org> Date: Tue, 26 Jun 2007 17:01:02 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Alexander Motin References: <468135BF.8010407@freebsd.org> <46814B21.5060800@elischer.org> <46819834.4030608@freebsd.org> In-Reply-To: <46819834.4030608@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 00:00:57 -0000 Alexander Motin wrote: > As I see situation now: > ppp - good user-level implementation. Not very fast, but stable, > flexible and able to be used with other programs like pppoed. possibly there could be a program that can run and then pass the connection to mpd. ppp Uses this technique to run in this way. ppp processes can pass their open file descriptors to a central ppp that is running in order to allow it to implement multilink. >> Brian talked a bit about this at the last DevSummit.. It just needs >> someone >> with the time and knowledge. Possibly Brian could work with Alex to >> make sure that >> all the functionality of ppp is in mpd. He did say that teh command >> language would need >> looking at to ensure that people would have a chance to convert their >> scripts.. > > Mpd uses command language different from all others, but I think it is > not a big problem. If we would compare supported PPP extensions then I > think mpd will now win in most nominations. > > The main problem I think is a general usage differences. Mpd was planned > and implemented as daemon. It have very limited foreground operation and > integration abilities. pppd as example is able to be called from getty > and terminate after link disconnect, while mpd does not. sppp is somehow > used by i4b project, but I know nothing about it. > > If somebody could help me to make list of reasonable requirements and/or > wanted usage examples then I surely will try to implement missing parts. > From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 00:08:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 348FB16A400; Wed, 27 Jun 2007 00:08:49 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 17F3113C45A; Wed, 27 Jun 2007 00:08:49 +0000 (UTC) (envelope-from bmah@freebsd.org) Received: from bmah.local (hornet.kitchenlab.org [64.142.31.105]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l5R08mOn003414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2007 17:08:48 -0700 Message-ID: <4681AA8D.8050009@freebsd.org> Date: Tue, 26 Jun 2007 17:08:45 -0700 From: "Bruce A. Mah" User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Eric F Crist References: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> <468011FC.4050308@FreeBSD.org> <7731B558-35C7-4E22-A40D-8BCE208AFD6A@secure-computing.net> <468063F6.2050303@FreeBSD.org> <8AA398FC-A753-4BB8-A93F-224FDDCE41BA@secure-computing.net> <46818609.3080202@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E2673EFBA427C1D67C0D801" Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: IPv6 Woes... 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, 27 Jun 2007 00:08:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E2673EFBA427C1D67C0D801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If memory serves me right, Eric F Crist wrote: > On Jun 26, 2007, at 4:32 PMJun 26, 2007, Bruce A. Mah wrote: [big snip] >> I wonder if the problem I've seen with bridge(4) might be related to >> your IPv6 problems (since you're terminating the tunnel on your >> firewall). If so, maybe switching to if_bridge(4) as I've described >> above might help things. >> >> In any case, good luck! >=20 > Bruce! Thanks for all the help! That did the trick! Only one more =20 > thing that's holding me up. Cool...I was half-guessing on this one. > On my gateway, I've got 2001:4980:1:111::145/64 as the primary IP =20 > address. In addition, I've got 2001:4980:1:111::1/128 as an alias. =20 > I can ping/connect to the xxx:145 address, but not the xxx:1 =20 > address. What did I configure wrong? Here's the output of netstat -=20 > r -f inet6: >=20 > Routing tables >=20 > Internet6: > Destination Gateway =20 > Flags Refs Use Mtu Netif Expire > :: localhost.secure-computing.net =20 > UGRS 0 0 16384 lo0 =3D> > default 2001:4980:1::5 =20 > UGS 0 0 1280 gif0 > localhost.secure-computing.net localhost.secure-computing.net =20 > UHL 5 0 16384 lo0 > ::ffff:0.0.0.0 localhost.secure-computing.net =20 > UGRS 0 0 16384 lo0 > 2001:4980:1::4 link#7 =20 > UC 0 0 1280 gif0 > 2001:4980:1::5 link#7 =20 > UHLW 2 4 1280 gif0 > 2001:4980:1::6 link#7 =20 > UHL 1 4 1280 lo0 > 2001:4980:1:111:: link#1 =20 > UC 0 1 1500 fxp0 > 2001:4980:1:111::1 00:06:5b:05:30:19 =20 > UHL 1 4 1500 lo0 > 2001:4980:1:111::145 00:06:5b:05:30:19 =20 > UHL 2 4 1500 lo0 > 2001:4980:1:111::147 00:06:5b:38:2e:82 =20 > UHLW 1 14 1500 fxp0 > fe80:: localhost.secure-computing.net =20 > UGRS 0 0 16384 lo0 > fe80::%fxp0 link#1 =20 > UC 0 0 1500 fxp0 > fe80::206:5bff:fe05:3019%fxp0 00:06:5b:05:30:19 =20 > UHL 1 0 1500 lo0 > fe80::%fxp1 link#2 =20 > UC 0 0 1500 fxp1 > fe80::206:5bff:fe05:301a%fxp1 00:06:5b:05:30:1a =20 > UHL 1 0 1500 lo0 > fe80::%lo0 fe80::1%lo0 =20 > U 0 0 16384 lo0 > fe80::1%lo0 link#3 =20 > UHL 1 0 16384 lo0 > fe80::%gif0 link#7 =20 > UC 0 0 1280 gif0 > fe80::206:5bff:fe05:3019%gif0 link#7 =20 > UHL 1 0 1280 lo0 > fe80::%tun0 link#8 =20 > UC 0 0 1500 tun0 > fe80::206:5bff:fe05:3019%tun0 link#8 =20 > UHL 1 0 1500 lo0 > ff01:1:: link#1 =20 > UC 0 0 1500 fxp0 > ff01:2:: link#2 =20 > UC 0 0 1500 fxp1 > ff01:3:: localhost.secure-computing.net =20 > UC 0 0 16384 lo0 > ff01:7:: link#7 =20 > UC 0 0 1280 gif0 > ff01:8:: link#8 =20 > UC 0 0 1500 tun0 > ff02:: localhost.secure-computing.net =20 > UGRS 0 0 16384 lo0 > ff02::%fxp0 link#1 =20 > UC 0 0 1500 fxp0 > ff02::%fxp1 link#2 =20 > UC 0 0 1500 fxp1 > ff02::%lo0 localhost.secure-computing.net =20 > UC 0 0 16384 lo0 > ff02::%gif0 link#7 =20 > UC 0 0 1280 gif0 > ff02::%tun0 link#8 =20 > UC 0 0 1500 tun0 This is a little odd. If you switched to using if_bridge for bridging, I would have expected to see bridge0 as one of your links. Is it not configured for IPv6? In my setup, the physical interfaces in the bridge are also unnumbered with respect to IPv6 as well (and the gateway machine's IPv6 address gets assigned to the bridge0 interface). I'm not sure what bearing this has on the question you really asked, which was about assigning another IPv6 address to an interface. It's not real obvious to me what the problem is there...at least from the routing table everything looks OK. What about the neighbor table ("ndp -a")? On the gateway, ndp -a should show entries for the two IPv6 addresses you assigned. On one of your LAN hosts (which I'm assuming are some *nix flavor), if you ping the two addresses of your gateway machine, you should then get entries in the NDP table for both those addresses as well. Bruce. --------------enig6E2673EFBA427C1D67C0D801 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGgaqN2MoxcVugUsMRAg7+AJ4urIpTADBqvhhlTM3R4dcJ3JzY7ACgtsE+ eTLMm48bhUiQ7SWvwmXPDi8= =x6Qz -----END PGP SIGNATURE----- --------------enig6E2673EFBA427C1D67C0D801-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 00:28:20 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AFFA616A421; Wed, 27 Jun 2007 00:28:19 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id 57E9213C458; Wed, 27 Jun 2007 00:28:19 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [192.168.1.2] (unknown [209.240.66.157]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id C660F1702D; Tue, 26 Jun 2007 19:28:18 -0500 (CDT) In-Reply-To: <4681AA8D.8050009@freebsd.org> References: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> <468011FC.4050308@FreeBSD.org> <7731B558-35C7-4E22-A40D-8BCE208AFD6A@secure-computing.net> <468063F6.2050303@FreeBSD.org> <8AA398FC-A753-4BB8-A93F-224FDDCE41BA@secure-computing.net> <46818609.3080202@freebsd.org> <4681AA8D.8050009@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Eric F Crist Date: Tue, 26 Jun 2007 19:28:16 -0500 To: Bruce A. Mah X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: IPv6 Woes... 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, 27 Jun 2007 00:28:20 -0000 On Jun 26, 2007, at 7:08 PMJun 26, 2007, Bruce A. Mah wrote: > If memory serves me right, Eric F Crist wrote: >> On Jun 26, 2007, at 4:32 PMJun 26, 2007, Bruce A. Mah wrote: > > [big snip] > >>> I wonder if the problem I've seen with bridge(4) might be related to >>> your IPv6 problems (since you're terminating the tunnel on your >>> firewall). If so, maybe switching to if_bridge(4) as I've described >>> above might help things. >>> >>> In any case, good luck! >> >> Bruce! Thanks for all the help! That did the trick! Only one more >> thing that's holding me up. > > Cool...I was half-guessing on this one. [snip] > This is a little odd. If you switched to using if_bridge for > bridging, > I would have expected to see bridge0 as one of your links. Is it not > configured for IPv6? In my setup, the physical interfaces in the > bridge > are also unnumbered with respect to IPv6 as well (and the gateway > machine's IPv6 address gets assigned to the bridge0 interface). The bridge0 interface is there (not in routing table), but it doesn't have anything assigned. Seems to be working great for IPv4 and IPv6 right now, aside from not being able to connect to that aliased v6 address... > I'm not sure what bearing this has on the question you really asked, > which was about assigning another IPv6 address to an interface. It's > not real obvious to me what the problem is there...at least from the > routing table everything looks OK. > > What about the neighbor table ("ndp -a")? On the gateway, ndp -a > should > show entries for the two IPv6 addresses you assigned. On one of your > LAN hosts (which I'm assuming are some *nix flavor), if you ping > the two > addresses of your gateway machine, you should then get entries in the > NDP table for both those addresses as well. > Here's the output of the command you asked for. I pinged the hosts on my network so there was more data to review: > ndp -a Neighbor Linklayer Address Netif Expire S Flags 2001:4980:1::5 (incomplete) gif0 23h51m15s S R 2001:4980:1::6 (incomplete) gif0 permanent R 2001:4980:1:111::1 0:6:5b:5:30:19 fxp0 permanent R 2001:4980:1:111::145 0:6:5b:5:30:19 fxp0 permanent R 2001:4980:1:111::147 0:6:5b:38:2e:82 fxp0 1d0h0m0s S 2001:4980:1:111::148 0:12:17:51:f6:e9 fxp0 23h59m58s S 2001:4980:1:111::149 0:12:17:4d:da:87 fxp0 9s R 2001:4980:1:111::150 0:6:5b:8b:8:d3 fxp0 2s R fe80::206:5bff:fe05:3019%fxp0 0:6:5b:5:30:19 fxp0 permanent R fe80::206:5bff:fe05:301a%fxp1 0:6:5b:5:30:1a fxp1 permanent R fe80::1%lo0 (incomplete) lo0 permanent R fe80::206:5bff:fe05:3019%gif0 (incomplete) gif0 permanent R fe80::206:5bff:fe05:3019%tun0 (incomplete) tun0 permanent R Thanks again! ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 00:57: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 8019016A46D for ; Wed, 27 Jun 2007 00:57:42 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.freebsd.org (Postfix) with SMTP id 36F4A13C46E for ; Wed, 27 Jun 2007 00:57:42 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from zone3000.kharkov.ua (HELO localhost) (217.144.69.37) by 0 with SMTP; 27 Jun 2007 00:57:36 -0000 Date: Wed, 27 Jun 2007 03:57:39 +0300 From: Nikolay Pavlov To: Alexander Motin Message-ID: <20070627005739.GA80825@zone3000.net> Mail-Followup-To: Nikolay Pavlov , Alexander Motin , FreeBSD Net , mpd-users@lists.sourceforge.net References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> <4681A062.9040009@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4681A062.9040009@freebsd.org> X-Operating-System: FreeBSD 6.2-RELEASE-p4 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: FreeBSD Net , mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 00:57:42 -0000 On Wednesday, 27 June 2007 at 2:25:22 +0300, Alexander Motin wrote: > Nikolay Pavlov wrote: > >This is probably a new feature request, but is this possible to create > >some kind of VirtualTemplate interface like it is in Cisco access > >routers. Currently i have to configure bunch of different ng interfaces > >for every kind user. However on my Cisco 7206VXR i can bundle physical > >link together with VirtaulTemplate interface in one vpdn-group config > >like this: > >And all the ppp interfaces for all users will use this configuration > >as a template. > > Yes, I am thinking about that. That is not trivial change. It will require changing all internal model from static to the dynamic one. But that change also should give many other > bonuses so I would like to try. > > One of problems is more or less new config file syntax required. I have very limited cisco experience, so it is difficult for me to adopt their model to mpd, but I would not like > to reinvent a wheel. I will be grateful for any ideas/examples of how do you see that. > > -- > Alexander Motin I think you can get a basic idea from this manual: http://www.cisco.com/warp/public/793/access_dial/vpdn-without-aaa.html It's a LAC-LNS scenario. Another examples could be found here: http://www.cisco.com/en/US/tech/tk801/tk703/tech_configuration_examples_list.html Also i forgot to mension it would be cool to see STAC compression support in future versions. Here in Ukraine we have at least one big telco that support it - people.net.ua -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ====================================================================== From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 01:31:27 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18C4E16A400 for ; Wed, 27 Jun 2007 01:31:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outI.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id 049DE13C45A for ; Wed, 27 Jun 2007 01:31:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 26 Jun 2007 18:31:25 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 73824125A23; Tue, 26 Jun 2007 18:31:25 -0700 (PDT) Message-ID: <4681BDF2.5020400@elischer.org> Date: Tue, 26 Jun 2007 18:31:30 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Nikolay Pavlov , Alexander Motin , FreeBSD Net , mpd-users@lists.sourceforge.net References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> <4681A062.9040009@freebsd.org> <20070627005739.GA80825@zone3000.net> In-Reply-To: <20070627005739.GA80825@zone3000.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 01:31:27 -0000 Nikolay Pavlov wrote: > On Wednesday, 27 June 2007 at 2:25:22 +0300, Alexander Motin wrote: >> Nikolay Pavlov wrote: >>> This is probably a new feature request, but is this possible to create >>> some kind of VirtualTemplate interface like it is in Cisco access >>> routers. Currently i have to configure bunch of different ng interfaces >>> for every kind user. However on my Cisco 7206VXR i can bundle physical >>> link together with VirtaulTemplate interface in one vpdn-group config >>> like this: >>> And all the ppp interfaces for all users will use this configuration >>> as a template. >> Yes, I am thinking about that. That is not trivial change. It will require changing all internal model from static to the dynamic one. But that change also should give many other >> bonuses so I would like to try. >> >> One of problems is more or less new config file syntax required. I have very limited cisco experience, so it is difficult for me to adopt their model to mpd, but I would not like >> to reinvent a wheel. I will be grateful for any ideas/examples of how do you see that. >> >> I am not sure that people know how to use the 'include' syntax in mpd. i have not used it for a long time but I do remember that my setups were very simple, because I used a kind of template entry to hold all teh common stuff. ah here it is.. in this example I use 'load' to save lots of typing.. tun_standard: set link yes acfcomp protocomp set link no pap set link no chap set link keep-alive 2 15 set link mru 900 set link mtu 900 # set link bandwidth 1440000 ############### per-link settings ################# vpn-site1: new -i ng0 vpn-site1 site1-ISP1 site1-ISP2 set iface addrs 10.12.1.24 10.12.1.10 set iface route 192.168.10.0/24 set ipcp ranges 10.12.1.24/32 10.12.1.10/32 load vpn_standard link site1-ISP1 load tun_standard link site1-ISP2 load tun_standard open vpn-site2: new -i ng1 vpn-site2 site2-ISP1 site2-ISP2 set iface addrs 10.12.1.24 10.12.1.20 set iface route 192.168.20.0/24 set ipcp ranges 10.12.1.24/32 10.12.1.20/32 load vpn_standard link site2-ISP1 load tun_standard link site2-ISP2 load tun_standard open From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 04:39:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 894B216A400 for ; Wed, 27 Jun 2007 04:39:47 +0000 (UTC) (envelope-from ozkan@mersin.edu.tr) Received: from mail.mersin.edu.tr (mail.mersin.edu.tr [193.255.128.3]) by mx1.freebsd.org (Postfix) with ESMTP id F355F13C489 for ; Wed, 27 Jun 2007 04:39:46 +0000 (UTC) (envelope-from ozkan@mersin.edu.tr) Received: from localhost (localhost.mersin.edu.tr [127.0.0.1]) by mail.mersin.edu.tr (Postfix) with ESMTP id 47B3932344E for ; Wed, 27 Jun 2007 07:15:45 +0300 (EEST) X-Virus-Scanned: amavisd-new at mersin.edu.tr Received: from mail.mersin.edu.tr ([127.0.0.1]) by localhost (yenimail.mersin.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3NaoqYlBo29 for ; Wed, 27 Jun 2007 07:15:44 +0300 (EEST) Received: from [10.0.50.20] (unknown [88.247.50.50]) by mail.mersin.edu.tr (Postfix) with ESMTP id 7C11A323443 for ; Wed, 27 Jun 2007 07:15:44 +0300 (EEST) Message-ID: <4681E4B2.1010407@mersin.edu.tr> Date: Wed, 27 Jun 2007 07:16:50 +0300 From: =?ISO-8859-9?Q?=D6zkan_KIRIK?= User-Agent: Mozilla Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> <4681A062.9040009@freebsd.org> <20070627005739.GA80825@zone3000.net> <4681BDF2.5020400@elischer.org> In-Reply-To: <4681BDF2.5020400@elischer.org> Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 04:39:47 -0000 hi; I wonder if new mpd still needs hundreds of config lines for 300 incoming pptp connections.? and does it still create a new ng interface even no pptp connections established? does new mpd support unlimited incoming connections? what about performance issuess ? (ex: cpu usage, memory usage?) thx. with best regards Julian Elischer yazmýþ: > Nikolay Pavlov wrote: >> On Wednesday, 27 June 2007 at 2:25:22 +0300, Alexander Motin wrote: >>> Nikolay Pavlov wrote: >>>> This is probably a new feature request, but is this possible to create >>>> some kind of VirtualTemplate interface like it is in Cisco access >>>> routers. Currently i have to configure bunch of different ng interfaces >>>> for every kind user. However on my Cisco 7206VXR i can bundle physical >>>> link together with VirtaulTemplate interface in one vpdn-group config >>>> like this: >>>> And all the ppp interfaces for all users will use this configuration >>>> as a template. >>> Yes, I am thinking about that. That is not trivial change. It will >>> require changing all internal model from static to the dynamic one. >>> But that change also should give many other bonuses so I would like >>> to try. >>> >>> One of problems is more or less new config file syntax required. I >>> have very limited cisco experience, so it is difficult for me to >>> adopt their model to mpd, but I would not like to reinvent a wheel. I >>> will be grateful for any ideas/examples of how do you see that. >>> >>> > > I am not sure that people know how to use the 'include' syntax in mpd. > > i have not used it for a long time but I do remember that my setups were > very simple, > because I used a kind of template entry to hold all teh common stuff. > > ah here it is.. in this example I use 'load' to save lots of typing.. > > > > tun_standard: > set link yes acfcomp protocomp > set link no pap > set link no chap > set link keep-alive 2 15 > set link mru 900 > set link mtu 900 > # set link bandwidth 1440000 > > ############### per-link settings ################# > vpn-site1: > new -i ng0 vpn-site1 site1-ISP1 site1-ISP2 > set iface addrs 10.12.1.24 10.12.1.10 > set iface route 192.168.10.0/24 > set ipcp ranges 10.12.1.24/32 10.12.1.10/32 > load vpn_standard > link site1-ISP1 load tun_standard > link site1-ISP2 > load tun_standard > open > > vpn-site2: > new -i ng1 vpn-site2 site2-ISP1 site2-ISP2 > set iface addrs 10.12.1.24 10.12.1.20 > set iface route 192.168.20.0/24 > set ipcp ranges 10.12.1.24/32 10.12.1.20/32 > load vpn_standard > link site2-ISP1 load tun_standard > link site2-ISP2 > load tun_standard > open > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 07:38: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 62FDB16A46B for ; Wed, 27 Jun 2007 07:38:46 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by mx1.freebsd.org (Postfix) with ESMTP id 16DF913C457 for ; Wed, 27 Jun 2007 07:38:45 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l5R7cWNQ072271; Wed, 27 Jun 2007 00:38:33 -0700 (PDT) Date: Wed, 27 Jun 2007 16:38:21 +0900 Message-ID: From: gnn@freebsd.org To: net@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.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current@freebsd.org Subject: FAST_IPSEC import to HEAD is imminent.. 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, 27 Jun 2007 07:38:46 -0000 Hi, I have been hacking on, testing and fixing the FAST_IPSEC code with support for IPv6 for a while now. There are still some issues to be worked out in the v6 integration but the v4 code is solid, in that it passes the full TAHI test suite. I intend to integrate this code into HEAD (I already have re's permission) in the next few days so that I have the weekend to work on other issues that come up with the code. There have been various patches out for a while (to be found in www.freebsd.org/~gnn) but it is clearly time to remove the KAME IPsec which is unlocked and unmaintained and move to FAST_IPSEC. Comments, questions and help always welcome. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 08:34:36 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 5394E16A469 for ; Wed, 27 Jun 2007 08:34:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 15A1613C4B8 for ; Wed, 27 Jun 2007 08:34:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7E1A717382; Wed, 27 Jun 2007 08:06:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l5R86TxW024958; Wed, 27 Jun 2007 08:06:29 GMT (envelope-from phk@critter.freebsd.dk) To: gnn@freebsd.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 27 Jun 2007 16:38:21 +0900." Date: Wed, 27 Jun 2007 08:06:29 +0000 Message-ID: <24957.1182931589@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@freebsd.org, net@freebsd.org Subject: Re: FAST_IPSEC import to HEAD is imminent.. 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, 27 Jun 2007 08:34:36 -0000 Can I ask a really fundamental question: Names like "newbus", "SMPng", "FAST_IPSEC" and similar grow really silly over time, because the attribute they carry in their name gets outdated. Once FAST_IPSEC replaces IPSEC, what is it faster than ? Can we please drop the FAST_ prefix along with the old IPSEC when we get to that point ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 10:23: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 F129B16A46D for ; Wed, 27 Jun 2007 10:23:28 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog10.obsmtp.com (s200aog10.obsmtp.com [207.126.144.124]) by mx1.freebsd.org (Postfix) with SMTP id 2F6E813C48A for ; Wed, 27 Jun 2007 10:23:27 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob010.postini.com ([207.126.147.11]) with SMTP; Wed, 27 Jun 2007 10:23:21 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 55B52181425; Wed, 27 Jun 2007 11:23:21 +0100 (BST) Message-ID: <46823A78.7020501@tomjudge.com> Date: Wed, 27 Jun 2007 11:22:48 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: David Christensen References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net Subject: Re: Problems with BCE network adapter (Dell PE2950) 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, 27 Jun 2007 10:23:29 -0000 David Christensen wrote: > Tom, > > There's already some debug code to watch for unusual size packets. > If you can recompile the driver from HEAD with the attached diffs > we can printout the first 128 bytes of any unusual sized packets. > > This does enabled other debugging code so performance will drop > but that should be OK since this doesn't present as a performance > problem. > > Dave > I am currently running the driver from RELENG_6 (With the MSI code backed out and your patch applied by hand) on a 6.2-p5 amd64 system (Dell PE2950) and have managed to get the following crash. The crash was caused by "cat * >/dev/null" in an NFS mounted directory. I'm not sure if this is the same crash but some other boxes (identical) to this one have crashed first time they are rebooted with the new driver. Unfortunately I have not managed to get a dump from one of these crashes yet. Also I am seeing a lot of these messages on boxes running this driver: bce0: bce_rx_intr(): Invalid TCP/UDP checksum = 0xD0F5! It seems to be caused by NFS traffic. I still have the core file if you need any more information. Tom kgdb /usr/obj/usr/src/sys/PE2950/kernel.debug vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: bce0: bce_rx_intr(): Invalid TCP/UDP checksum = 0xD0F5! bce0: bce_rx_intr(): Invalid TCP/UDP checksum = 0x2F0A! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFB > 0x01FE)! bce0: bce_rx_intr(): Invalid TCP/UDP checksum = 0xF043! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFF9 > 0x01FE)! bce0: bce_rx_intr(): Invalid TCP/UDP checksum = 0x8C5F! bce0: /usr/src/sys/dev/bce/if_bce.c(3973): Unexpected mbuf found in rx_bd[0x005A]! bce0: ---------------------------- Driver State ---------------------------- bce0: 0xFFFFFFFF:8B92A000 - (sc) driver softc structure virtual address bce0: 0xFFFFFF00:F4000000 - (sc->bce_vhandle) PCI BAR virtual address bce0: 0xFFFFFF00:009E3680 - (sc->status_block) status block virtual address bce0: 0xFFFFFF00:009D6400 - (sc->stats_block) statistics block virtual address bce0: 0xFFFFFFFF:8B92A1B0 - (sc->tx_bd_chain) tx_bd chain virtual adddress bce0: 0xFFFFFFFF:8B92A1E8 - (sc->rx_bd_chain) rx_bd chain virtual address bce0: 0xFFFFFFFF:8B92B260 - (sc->tx_mbuf_ptr) tx mbuf chain virtual address bce0: 0xFFFFFFFF:8B92D260 - (sc->rx_mbuf_ptr) rx mbuf chain virtual address bce0: 0x0000357F - (sc->interrupts_generated) h/w intrs bce0: 0x00002981 - (sc->rx_interrupts) rx interrupts handled bce0: 0x0000212A - (sc->tx_interrupts) tx interrupts handled bce0: 0x0000706B - (sc->last_status_idx) status block index bce0: 0x0000675E - (sc->tx_prod) tx producer index bce0: 0x00006707 - (sc->tx_cons) tx consumer index bce0: 0x001B39EA - (sc->tx_prod_bseq) tx producer bseq index bce0: 0x0000F25C - (sc->rx_prod) rx producer index bce0: 0x0000F059 - (sc->rx_cons) rx consumer index bce0: 0x0B850C00 - (sc->rx_prod_bseq) rx producer bseq index bce0: 0x000000AB - (sc->rx_mbuf_alloc) rx mbufs allocated bce0: 0x0000FFF8 - (sc->free_rx_bd) free rx_bd's bce0: 0x00000000/000001FE - (sc->rx_low_watermark) rx low watermark bce0: 0x0000001D - (sc->txmbuf_alloc) tx mbufs allocated bce0: 0x000000AB - (sc->rx_mbuf_alloc) rx mbufs allocated bce0: 0x00000057 - (sc->used_tx_bd) used tx_bd's bce0: 0x000001FE/000001FE - (sc->tx_hi_watermark) tx hi watermark bce0: 0x00000000 - (sc->mbuf_alloc_failed) failed mbuf alloc bce0: ------------------------------------------------------------------------ bce0: ---------------------------- Status Block ---------------------------- bce0: attn_bits = 0x00000001, attn_bits_ack = 0x00000001, index = 0x70BF bce0: rx_cons0 = 0x0000F061, tx_cons0 = 0x0000675E bce0: status_idx = 0x70BF bce0: ------------------------------------------------------------------------ Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 4; apic id = 04 instruction pointer = 0x8:0xffffffff801ee956 stack pointer = 0x10:0xffffffffb6d60b40 frame pointer = 0x10:0x5a code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 27 (irq16: bce0 bce1) trap number = 3 panic: breakpoint instruction fault cpuid = 4 Uptime: 3m10s Dumping 8191 MB (3 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 3327MB (851624 pages) 3311 3295 3279 3263 3247 3231 3215 3199 3183 31 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:172 #1 0x0000000000000004 in ?? () #2 0xffffffff8029e0e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff8029e781 in panic (fmt=0xffffff021ef0a4c0 "?\206?\036\002?????\036\002???") at /usr/src/sys/kern/kern_shutdown.c:565 #4 0xffffffff803f9e3f in trap_fatal (frame=0xffffff021ef0a4c0, eva=18446742983307069104) at /usr/src/sys/amd64/amd64/trap.c:660 #5 0xffffffff803fa2e2 in trap (frame= {tf_rdi = 0, tf_rsi = -2139025408, tf_rdx = 1, tf_rcx = 1915683, tf_r8 = 1048064, tf_r9 = 10, tf_rax = 79, tf_rbx = -1953325056, tf_rbp = 90, tf_r10 = -1227486624, tf_r11 = 4294967208, tf_r12 = -1953325056, tf_r13 = 90, tf_r14 = 61537, tf_r15 = 61530, tf_trapno = 3, tf_addr = 0, tf_flags = -1099501259136, tf_err = 0, tf_rip = -2145457834, tf_cs = 8, tf_rflags = 642, tf_rsp = -1227486384, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:469 #6 0xffffffff803e55fb in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #7 0xffffffff801ee956 in bce_breakpoint (sc=0xffffffff8b92a000) at cpufunc.h:63 #8 0xffffffff801ef0f6 in bce_intr (xsc=0x0) at /usr/src/sys/dev/bce/if_bce.c:3970 #9 0xffffffff80284919 in ithread_loop (arg=0xffffff00009e4000) at /usr/src/sys/kern/kern_intr.c:682 #10 0xffffffff802830b7 in fork_exit (callout=0xffffffff802847d0 , arg=0xffffff00009e4000, frame=0xffffffffb6d60c50) at /usr/src/sys/kern/kern_fork.c:821 #11 0xffffffff803e595e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:394 #12 0x0000000000000000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000001 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #44 0x00000000007f3000 in ?? () #45 0xffffff021ef286b0 in ?? () #46 0x0000000000000104 in ?? () #47 0x0000000000000000 in ?? () #48 0xffffff021ef286b0 in ?? () #49 0xffffff021ef68000 in ?? () #50 0xffffffffb6d60848 in ?? () #51 0xffffff021ef0a4c0 in ?? () #52 0xffffffff802b4856 in sched_switch (td=0xffffff00009e4000, newtd=0x0, flags=0) at /usr/src/sys/kern/sched_4bsd.c:973 #124 0x0000000000000000 in ?? () Cannot access memory at address 0xffffffffb6d61000 (kgdb) frame 8 #8 0xffffffff801ef0f6 in bce_intr (xsc=0x0) at /usr/src/sys/dev/bce/if_bce.c:3970 3970 DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)), (kgdb) list 3965 3966 /* The mbuf is stored with the last rx_bd entry of a packet. */ 3967 if (sc->rx_mbuf_ptr[sw_chain_cons] != NULL) { 3968 3969 /* Validate that this is the last rx_bd. */ 3970 DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)), 3971 BCE_PRINTF("%s(%d): Unexpected mbuf found in rx_bd[0x%04X]!\n", 3972 __FILE__, __LINE__, sw_chain_cons); 3973 bce_breakpoint(sc)); 3974 From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 10:42: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 75B7916A46C for ; Wed, 27 Jun 2007 10:42:13 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.freebsd.org (Postfix) with SMTP id 3D34B13C4B0 for ; Wed, 27 Jun 2007 10:42:12 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from zone3000.kharkov.ua (HELO localhost) (217.144.69.37) by 0 with SMTP; 27 Jun 2007 10:42:06 -0000 Date: Wed, 27 Jun 2007 13:42:10 +0300 From: Nikolay Pavlov To: Julian Elischer Message-ID: <20070627104210.GA83002@zone3000.net> Mail-Followup-To: Nikolay Pavlov , Julian Elischer , Alexander Motin , FreeBSD Net , mpd-users@lists.sourceforge.net References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> <4681A062.9040009@freebsd.org> <20070627005739.GA80825@zone3000.net> <4681BDF2.5020400@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4681BDF2.5020400@elischer.org> X-Operating-System: FreeBSD 6.2-RELEASE-p4 User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: FreeBSD Net , Alexander Motin , mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 10:42:13 -0000 On Tuesday, 26 June 2007 at 18:31:30 -0700, Julian Elischer wrote: > Nikolay Pavlov wrote: > >On Wednesday, 27 June 2007 at 2:25:22 +0300, Alexander Motin wrote: > >>Nikolay Pavlov wrote: > >>>This is probably a new feature request, but is this possible to create > >>>some kind of VirtualTemplate interface like it is in Cisco access > >>>routers. Currently i have to configure bunch of different ng interfaces > >>>for every kind user. However on my Cisco 7206VXR i can bundle physical > >>>link together with VirtaulTemplate interface in one vpdn-group config > >>>like this: > >>>And all the ppp interfaces for all users will use this configuration > >>>as a template. > >>Yes, I am thinking about that. That is not trivial change. It will require changing all internal model from static to the dynamic one. But that change also should give many > >>other bonuses so I would like to try. > >> > >>One of problems is more or less new config file syntax required. I have very limited cisco experience, so it is difficult for me to adopt their model to mpd, but I would not > >>like to reinvent a wheel. I will be grateful for any ideas/examples of how do you see that. > >> > >> > > I am not sure that people know how to use the 'include' syntax in mpd. > > i have not used it for a long time but I do remember that my setups were very simple, > because I used a kind of template entry to hold all teh common stuff. > > ah here it is.. in this example I use 'load' to save lots of typing.. > > > > tun_standard: > set link yes acfcomp protocomp > set link no pap > set link no chap > set link keep-alive 2 15 > set link mru 900 > set link mtu 900 > # set link bandwidth 1440000 > ############### per-link settings ################# > vpn-site1: > new -i ng0 vpn-site1 site1-ISP1 site1-ISP2 > set iface addrs 10.12.1.24 10.12.1.10 > set iface route 192.168.10.0/24 > set ipcp ranges 10.12.1.24/32 10.12.1.10/32 > load vpn_standard > link site1-ISP1 load tun_standard > link site1-ISP2 > load tun_standard > open > vpn-site2: > new -i ng1 vpn-site2 site2-ISP1 site2-ISP2 > set iface addrs 10.12.1.24 10.12.1.20 > set iface route 192.168.20.0/24 > set ipcp ranges 10.12.1.24/32 10.12.1.20/32 > load vpn_standard > link site2-ISP1 load tun_standard > link site2-ISP2 > load tun_standard > open But what if you want to support one thousand of concurrent connections? -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ====================================================================== From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 11:06:58 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 C56F516A41F; Wed, 27 Jun 2007 11:06:58 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 831CF13C469; Wed, 27 Jun 2007 11:06:56 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 93E911FFB57; Wed, 27 Jun 2007 12:50:11 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id CDBCF1FFE17; Wed, 27 Jun 2007 12:50:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 631CC4448A9; Wed, 27 Jun 2007 10:48:57 +0000 (UTC) Date: Wed, 27 Jun 2007 10:48:56 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Poul-Henning Kamp In-Reply-To: <24957.1182931589@critter.freebsd.dk> Message-ID: <20070627104126.G98813@maildrop.int.zabbadoz.net> References: <24957.1182931589@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: "George V. Neville-Neil" , FreeBSD current mailing list , FreeBSD net mailing list Subject: Re: FAST_IPSEC import to HEAD is imminent.. 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, 27 Jun 2007 11:06:58 -0000 On Wed, 27 Jun 2007, Poul-Henning Kamp wrote: Hi, > Can we please drop the FAST_ prefix along with the old IPSEC when we > get to that point ? yes, I think that is gnn's plan. I was a bit worried because it'll be confusing that IPSEC->gone and FAST_IPSEC->IPSEC but hey IPSEC is gone;-) Don't know if it will happen instantly with the first commit but it will happen. I am currently also going through user space again and should find someone to help with the man page;-) /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 11:27:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23AE716A421; Wed, 27 Jun 2007 11:27:59 +0000 (UTC) (envelope-from ovi@unixservers.us) Received: from www.unixservers.us (unixware.iasi.rdsnet.ro [86.124.41.195]) by mx1.freebsd.org (Postfix) with ESMTP id 93BDF13C45D; Wed, 27 Jun 2007 11:27:58 +0000 (UTC) (envelope-from ovi@unixservers.us) Received: from [10.0.0.14] (unknown [10.0.0.14]) (Authenticated sender: ovi@unixservers.us) by www.unixservers.us (Postfix) with ESMTP id D79168FC19; Wed, 27 Jun 2007 14:31:13 +0300 (EEST) Message-ID: <46824A3F.3020208@unixservers.us> Date: Wed, 27 Jun 2007 14:30:07 +0300 From: Ovi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mav@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 11:27:59 -0000 Alexander Motin wrote: > Nikolay Pavlov wrote: > >> This is probably a new feature request, but is this possible to create >> some kind of VirtualTemplate interface like it is in Cisco access >> routers. Currently i have to configure bunch of different ng interfaces >> for every kind user. However on my Cisco 7206VXR i can bundle physical >> link together with VirtaulTemplate interface in one vpdn-group config >> like this: >> >> And all the ppp interfaces for all users will use this configuration >> as a template. > > > > Yes, I am thinking about that. That is not trivial change. It will > require changing all internal model from static to the dynamic one. > But that change also should give many other bonuses so I would like to > try. > > One of problems is more or less new config file syntax required. I > have very limited cisco experience, so it is difficult for me to adopt > their model to mpd, but I would not like to reinvent a wheel. I will > be grateful for any ideas/examples of how do you see that. > Hello guys Mpd is a great piece of software, I use it for almost 3 years. There are some things I want to share with you I've used in the past pppoed, but I had to switch to mpd because I had problems with pppoed crashing because of a bad switch (burned port) on my network. I have a small network (Ethernet + Fiber) in a small town, and sometimes it happend for a switch to freeze or even stop working, flooding pppoe server with arp requests, that crashes the pppoe server. Using pppoed few years ago it started to crash when I had few users, like up to 100. Replacing it with mpd solved the problem then. Well, my network grew to 2000 users (1000 connected at the same time, on peek hours), and now, if a switch port crashes, mpd crashes too. I am talking about mpd4. I've used 3.18, and I can say 4 is a lot faster...... on 3.18 i had on a P IV at 3 GHZ with 2GB RAM, 70% cpu usage for 600-700 users connected at the same time. With mpd4, I have not more than 20% cpu usage with same number of users. This is great thinking that I have an 100mbps network, and some people are using pppoe connection when transfer files from other users in same network, which put some load on pppoe server. I did install a dhcp server, with private addresses, and usualy comunication between LAN users is done directly and not via pppoe server (which shoud be use for Internet connection). For my 2000 users I have a config file witch holds 2000 sections for every pppoe tunnel. It took me some time to generate it, I've wrote a php script do do that. It would be useful a feature like one Nikolay wrote. Also as you know PPPoE is vulnerable to arp poisoning and to DoSs. Having a small network with 10-20 computers using mpd is easy, but having 2000 users or more, things changes, problems appears. Solving arp poisoning or DoS attack (sometimes caused by a burned switch port which mixes RX with TX) I thing can be done using a Layer2 managed switch, with ACLs, I will try and I'll inform you. When having many users, it is useful to have high availability, so it would be nice and useful to setup multiple pppoe servers . I've tried that, using a router, connected to 2 pppoe servers, and at every pppoe connection, a route was added to the router and when user disconnected, the route was deleted from router. This is still a buggy implementation, we had problems messing up routing table. So to conclude: - an option like Nikolay said, would be very useful, not to generate thousands of rules manualy - it would be nice to have a documentation, or to give me some clues how could be done high availability with mpd pppoe servers, and I'll wrote a documentation for that - would be nice to have a documentation for tuning mpd for lots of users, I can do that but I would need your feedback Best Regards, Ovidiu From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 11:30: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 E976A16A421; Wed, 27 Jun 2007 11:30:45 +0000 (UTC) (envelope-from ovi@unixservers.us) Received: from www.unixservers.us (unixware.iasi.rdsnet.ro [86.124.41.195]) by mx1.freebsd.org (Postfix) with ESMTP id 63EE813C465; Wed, 27 Jun 2007 11:30:45 +0000 (UTC) (envelope-from ovi@unixservers.us) Received: from [10.0.0.14] (unknown [10.0.0.14]) (Authenticated sender: ovidiue@smartbsd.com) by www.unixservers.us (Postfix) with ESMTP id 880588FC08; Wed, 27 Jun 2007 14:14:34 +0300 (EEST) Message-ID: <468245F8.1090709@unixservers.us> Date: Wed, 27 Jun 2007 14:11:52 +0300 From: Ovi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Motin References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> <4681A062.9040009@freebsd.org> In-Reply-To: <4681A062.9040009@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 11:30:46 -0000 Alexander Motin wrote: > Nikolay Pavlov wrote: > >> This is probably a new feature request, but is this possible to create >> some kind of VirtualTemplate interface like it is in Cisco access >> routers. Currently i have to configure bunch of different ng interfaces >> for every kind user. However on my Cisco 7206VXR i can bundle physical >> link together with VirtaulTemplate interface in one vpdn-group config >> like this: >> >> And all the ppp interfaces for all users will use this configuration >> as a template. > > > Yes, I am thinking about that. That is not trivial change. It will > require changing all internal model from static to the dynamic one. > But that change also should give many other bonuses so I would like to > try. > > One of problems is more or less new config file syntax required. I > have very limited cisco experience, so it is difficult for me to adopt > their model to mpd, but I would not like to reinvent a wheel. I will > be grateful for any ideas/examples of how do you see that. > Hello guys Mpd is a great piece of software, I use it for almost 3 years. There are some things I want to share with you I've used in the past pppoed, but I had to switch to mpd because I had problems with pppoed crashing because of a bad switch (burned port) on my network. I have a small network (Ethernet + Fiber) in a small town, and sometimes it happend for a switch to freeze or even stop working, flooding pppoe server with arp requests, that crashes the pppoe server. Using pppoed few years ago it started to crash when I had few users, like up to 100. Replacing it with mpd solved the problem then. Well, my network grew to 2000 users (1000 connected at the same time, on peek hours), and now, if a switch port crashes, mpd crashes too. I am talking about mpd4. I've used 3.18, and I can say 4 is a lot faster...... on 3.18 i had on a P IV at 3 GHZ with 2GB RAM, 70% cpu usage for 600-700 users connected at the same time. With mpd4, I have not more than 20% cpu usage with same number of users. This is great thinking that I have an 100mbps network, and some people are using pppoe connection when transfer files from other users in same network, which put some load on pppoe server. I did install a dhcp server, with private addresses, and usualy comunication between LAN users is done directly and not via pppoe server (which shoud be use for Internet connection). For my 2000 users I have a config file witch holds 2000 sections for every pppoe tunnel. It took me some time to generate it, I've wrote a php script do do that. It would be useful a feature like one Nikolay wrote. Also as you know PPPoE is vulnerable to arp poisoning and to DoSs. Having a small network with 10-20 computers using mpd is easy, but having 2000 users or more, things changes, problems appears. Solving arp poisoning or DoS attack (sometimes caused by a burned switch port which mixes RX with TX) I thing can be done using a Layer2 managed switch, with ACLs, I will try and I'll inform you. When having many users, it is useful to have high availability, so it would be nice and useful to setup multiple pppoe servers . I've tried that, using a router, connected to 2 pppoe servers, and at every pppoe connection, a route was added to the router and when user disconnected, the route was deleted from router. This is still a buggy implementation, we had problems messing up routing table. So to conclude: - an option like Nikolay said, would be very useful, not to generate thousands of rules manualy - it would be nice to have a documentation, or to give me some clues how could be done high availability with mpd pppoe servers, and I'll wrote a documentation for that - would be nice to have a documentation for tuning mpd for lots of users, I can do that but I would need your feedback Best Regards, Ovidiu From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 12:03:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F67F16A46C for ; Wed, 27 Jun 2007 12:03:49 +0000 (UTC) (envelope-from miroslav@svishtov.net) Received: from mail.svishtov.net (mail.svishtov.net [85.217.192.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9278813C487 for ; Wed, 27 Jun 2007 12:03:48 +0000 (UTC) (envelope-from miroslav@svishtov.net) X-Spam-Status: No, hits=5.2 required=7.5 tests=AWL: -0.839,BAYES_99: 4.07,FORGED_RCVD_HELO: 0.135, HTML_30_40: 0.374,HTML_MESSAGE: 0.001,RCVD_NUMERIC_HELO: 1.5, TOTAL_SCORE: 5.241 X-Spam-Level: ***** Received: from 85.217.222.0 ([85.217.222.0]) by mail.svishtov.net for quetzal@zone3000.net; Wed, 27 Jun 2007 13:16:25 +0300 To: "Nikolay Pavlov" From: "Miroslav Slavkov" In-Reply-To: 20070627005739.GA80825@zone3000.net Message-ID: <20070627101625.827aec08@mail.svishtov.net> Date: Wed, 27 Jun 2007 13:16:25 +0300 X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; bg; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net , Alexander Motin , mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 12:03:49 -0000 Maxim Zenin did some effort to create such templates. His work was done = on 3.18 version of mpd mainly for PPPoE server usage. You can see his work at http://www.foggy.ru/soft/mpd/ It may be useful for the future development. =5F=5F=5F=5F=5F =20 From: Nikolay Pavlov [mailto:quetzal@zone3000.net] To: Alexander Motin [mailto:mav@freebsd.org] Cc: FreeBSD Net [mailto:freebsd-net@freebsd.org], mpd-users@lists.source= forge.net Sent: Wed, 27 Jun 2007 03:57:39 +0300 Subject: Re: Mpd-4.2 released. On Wednesday, 27 June 2007 at 2:25:22 +0300, Alexander Motin wrote: > Nikolay Pavlov wrote: > >This is probably a new feature request, but is this possible to cre= ate > >some kind of VirtualTemplate interface like it is in Cisco access > >routers. Currently i have to configure bunch of different ng interf= aces > >for every kind user. However on my Cisco 7206VXR i can bundle physi= cal > >link together with VirtaulTemplate interface in one vpdn-group conf= ig > >like this: > >And all the ppp interfaces for all users will use this configuratio= n > >as a template. >=20 > Yes, I am thinking about that. That is not trivial change. It will r= equire changing all internal model from static to the dynamic one. But t= hat change also should give many other=20 > bonuses so I would like to try. >=20 > One of problems is more or less new config file syntax required. I h= ave very limited cisco experience, so it is difficult for me to adopt th= eir model to mpd, but I would not like=20 > to reinvent a wheel. I will be grateful for any ideas/examples of ho= w do you see that. >=20 > --=20 > Alexander Motin =20 I think you can get a basic idea from this manual: http://www.cisco.com/warp/public/793/access=5Fdial/vpdn-without-aaa.ht= ml It's a LAC-LNS scenario. =20 Another examples could be found here: http://www.cisco.com/en/US/tech/tk801/tk703/tech=5Fconfiguration=5Fexa= mples=5Flist.html =20 Also i forgot to mension it would be cool to see STAC compression supp= ort in future versions. Here in Ukraine we have at least one big telco that support it - people.net.ua =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =20 - Best regards, Nikolay Pavlov. <<<-----------------------------------= =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =20 =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =20 From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 12:08: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 A580E16A400 for ; Wed, 27 Jun 2007 12:08:42 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2A59413C44C for ; Wed, 27 Jun 2007 12:08:41 +0000 (UTC) (envelope-from mav@freebsd.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 24472300; Wed, 27 Jun 2007 15:08:41 +0300 Message-ID: <46825347.1030206@freebsd.org> Date: Wed, 27 Jun 2007 15:08:39 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.0 (X11/20070424) MIME-Version: 1.0 To: Ovi References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> <4681A062.9040009@freebsd.org> <468245F8.1090709@unixservers.us> In-Reply-To: <468245F8.1090709@unixservers.us> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 12:08:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ovi wrote: > Also as you know > PPPoE is vulnerable to arp poisoning and to DoSs. Having a small network > with 10-20 computers using mpd is easy, but having 2000 users or more, > things changes, problems appears. Solving arp poisoning or DoS attack > (sometimes caused by a burned switch port which mixes RX with TX) I > thing can be done using a Layer2 managed switch, with ACLs, I will try > and I'll inform you. Even if pppoe have some DoS weaknesses it also have some protection mechanisms against it. It's a pity but ng_pppoe originally implements protocol in a way which does not allow this protection to be effectively used. As I have told 4.2 release contains overload protection which should also help against DoS attacks. I am not sure it will be able to handle 100Mbit/s flood of PADI requests from broken switch, but should avoid mpd freeze in such case. > When having many users, it is useful to have high availability, so it > would be nice and useful to setup multiple pppoe servers . I've tried > that, using a router, connected > to 2 pppoe servers, and at every pppoe connection, a route was added to > the router and when user disconnected, the route was deleted from > router. This is still a buggy implementation, we had problems messing > up routing table. Having several PPPoE servers in one segment is a normal solution protocol. It is not so efficient now as it could be due to ng_pppoe implementation problem I have told, but it still should increase performance and stability. What is about routing problems, you just should find good dynamic routing solution. I have successfully working network with hundred PPPoE servers and many thousands of users with routing successfully managed by quagga bgp. - -- Alexander Motin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGglNH0kCgngV3usoRAoANAJ9k2lRBnR8VtWu4pm1BhiQKwrimuQCgkTEE oY83aUVdgXzPITM/ea4cTK8= =Sk3P -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 12:28: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 D71F916A400; Wed, 27 Jun 2007 12:28:38 +0000 (UTC) (envelope-from ovi@unixservers.us) Received: from www.unixservers.us (unixware.iasi.rdsnet.ro [86.124.41.195]) by mx1.freebsd.org (Postfix) with ESMTP id F1A8113C46C; Wed, 27 Jun 2007 12:28:37 +0000 (UTC) (envelope-from ovi@unixservers.us) Received: from [10.0.0.14] (unknown [10.0.0.14]) (Authenticated sender: ovi@unixservers.us) by www.unixservers.us (Postfix) with ESMTP id 57D048FC08; Wed, 27 Jun 2007 15:31:53 +0300 (EEST) Message-ID: <46825855.6090908@unixservers.us> Date: Wed, 27 Jun 2007 15:30:13 +0300 From: Ovi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Motin References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> <4681A062.9040009@freebsd.org> <468245F8.1090709@unixservers.us> <46825347.1030206@freebsd.org> In-Reply-To: <46825347.1030206@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 12:28:38 -0000 Dear Alexander Thank yoo for your email, it is very interesting. I am not very familiar with BGP (but I will learn), my question is: did you use multiple pppoe servers with different subnet for every pppoe server, or you have high availability with every serverer giving IPs from the same pool of addresses. I am using Radius, and I would like to have configured the pppoe servers the same way, so if I would need more power, I would add another server, that would offer pppoe connections from the same pool, using the same radius server as everyone. I think if bgp sessions are estabilished between router and pppoe servers, every pppoe server would have his own subnet of addresses to give to users, which is not good, it will be interesting every pppoe server to accept all users. So not have pppoeserve1 for 100 customers, pppoeserv2 for another 100 customers and so on. The second issue I've encountered , on my setup I've connected router to two pppoe servers, and on pppoe servers decond network card of both pppoe servers was connected to our LAN. Because all users from lan already have setup pppoe on their workstations, I wanted to transparently for them make this system work. So, I setup both pppoe servers with the same name (same hostname), and also the service name is *. Still the load is not balanced, most of the users connect to one server, and only few of them to the other. It is a posibility that the fastest pppoe server who answer to establish the connection with user? I've searched a lot for those issues, I did not found much information on the Internet, maybe you know some resources for me to study. Thank you Best regards, Ovidiu Alexander Motin wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Ovi wrote: > > >>Also as you know >>PPPoE is vulnerable to arp poisoning and to DoSs. Having a small network >>with 10-20 computers using mpd is easy, but having 2000 users or more, >>things changes, problems appears. Solving arp poisoning or DoS attack >>(sometimes caused by a burned switch port which mixes RX with TX) I >>thing can be done using a Layer2 managed switch, with ACLs, I will try >>and I'll inform you. >> >> > >Even if pppoe have some DoS weaknesses it also have some protection >mechanisms against it. It's a pity but ng_pppoe originally implements >protocol in a way which does not allow this protection to be effectively >used. > >As I have told 4.2 release contains overload protection which should >also help against DoS attacks. I am not sure it will be able to handle >100Mbit/s flood of PADI requests from broken switch, but should avoid >mpd freeze in such case. > > > >>When having many users, it is useful to have high availability, so it >>would be nice and useful to setup multiple pppoe servers . I've tried >>that, using a router, connected >>to 2 pppoe servers, and at every pppoe connection, a route was added to >>the router and when user disconnected, the route was deleted from >>router. This is still a buggy implementation, we had problems messing >>up routing table. >> >> > >Having several PPPoE servers in one segment is a normal solution >protocol. It is not so efficient now as it could be due to ng_pppoe >implementation problem I have told, but it still should increase >performance and stability. > >What is about routing problems, you just should find good dynamic >routing solution. I have successfully working network with hundred PPPoE >servers and many thousands of users with routing successfully managed by >quagga bgp. > >- -- >Alexander Motin >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.7 (FreeBSD) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFGglNH0kCgngV3usoRAoANAJ9k2lRBnR8VtWu4pm1BhiQKwrimuQCgkTEE >oY83aUVdgXzPITM/ea4cTK8= >=Sk3P >-----END PGP SIGNATURE----- >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 12:47: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 E05DC16A468 for ; Wed, 27 Jun 2007 12:47:38 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2F813C48C for ; Wed, 27 Jun 2007 12:47:38 +0000 (UTC) (envelope-from mav@freebsd.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 24473750; Wed, 27 Jun 2007 15:47:37 +0300 Message-ID: <46825C68.6020302@freebsd.org> Date: Wed, 27 Jun 2007 15:47:36 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.0 (X11/20070424) MIME-Version: 1.0 To: Ovi References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> <4681A062.9040009@freebsd.org> <468245F8.1090709@unixservers.us> <46825347.1030206@freebsd.org> <46825855.6090908@unixservers.us> In-Reply-To: <46825855.6090908@unixservers.us> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 12:47:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ovi wrote: > I am not very familiar with BGP (but I will learn), my question is: did > you use multiple pppoe servers with different subnet for every pppoe > server, > or you have high availability with every serverer giving IPs from the > same pool of addresses. I am using Radius, and I would like to have > configured the > pppoe servers the same way, so if I would need more power, I would add > another server, that would offer pppoe connections from the same pool, > using the same > radius server as everyone. I think if bgp sessions are estabilished > between router and pppoe servers, every pppoe server would have his own > subnet of addresses > to give to users, which is not good, it will be interesting every pppoe > server to accept all users. So not have pppoeserve1 for 100 customers, > pppoeserv2 for another 100 customers and so on. Due to firmware problems of some ADSL modems we use I am currently limited with having only one PPPoE server per vlan. But all of my servers is completely identical except their external IP and hostname. All ip pool management implemented by RADIUS server so when one of servers is going down it's clients easily routed to the backup one by simple switch reconfiguration. > The second issue I've encountered , on my setup I've connected router to > two pppoe servers, and on pppoe servers decond network card of both > pppoe servers > was connected to our LAN. Because all users from lan already have setup > pppoe on their workstations, I wanted to transparently for them make > this system work. > So, I setup both pppoe servers with the same name (same hostname), and > also the service name is *. Still the load is not balanced, most of the > users connect to one server, and only few of them to the other. It is a > posibility that the fastest pppoe server who answer to establish the > connection with user? When there several PPPoE servers in segment then client will receive several PADO responses. After that it is free to choose among them. Algorithm of that choosing is not defined. Usually the first reply is used, but if not much relations with router load. Only when there is no free link mpd will stop sending replies. - -- Alexander Motin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGglxn0kCgngV3usoRAvZSAKDmLu47tEaGFcra+i17nALqO37XnQCfdjXh V9Av8XlS9u/A9Vpgm4I8yx4= =A7Ih -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 14:03:37 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6A8416A421; Wed, 27 Jun 2007 14:03:37 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 9BFAC13C44B; Wed, 27 Jun 2007 14:03:37 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l5RDr7s4071123; Wed, 27 Jun 2007 06:53:07 -0700 (PDT) Date: Wed, 27 Jun 2007 22:52:56 +0900 Message-ID: From: "George V. Neville-Neil" To: "Bjoern A. Zeeb" In-Reply-To: <20070627104126.G98813@maildrop.int.zabbadoz.net> References: <24957.1182931589@critter.freebsd.dk> <20070627104126.G98813@maildrop.int.zabbadoz.net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Poul-Henning Kamp , FreeBSD current mailing list , FreeBSD net mailing list Subject: Re: FAST_IPSEC import to HEAD is imminent.. 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, 27 Jun 2007 14:03:38 -0000 At Wed, 27 Jun 2007 10:48:56 +0000 (UTC), Bjoern A. Zeeb wrote: > > On Wed, 27 Jun 2007, Poul-Henning Kamp wrote: > > Hi, > > > Can we please drop the FAST_ prefix along with the old IPSEC when we > > get to that point ? > > yes, I think that is gnn's plan. I was a bit worried because it'll be > confusing that IPSEC->gone and FAST_IPSEC->IPSEC but hey IPSEC is gone;-) > As Bjoern said, that is the plan. After all is said and done we'll just have an IPSEC option with completely different code backing it. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 15:48:36 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86AAC16A421 for ; Wed, 27 Jun 2007 15:48:36 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [213.251.163.210]) by mx1.freebsd.org (Postfix) with ESMTP id 2181813C468 for ; Wed, 27 Jun 2007 15:48:35 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (ip-83-134-208-129.dsl.scarlet.be [83.134.208.129]) by tignes.restart.be (8.13.8/8.13.8) with ESMTP id l5RFmYnW026124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jun 2007 17:48:34 +0200 (CEST) (envelope-from hlh@restart.be) Received: from morzine.restart.bel (morzine.restart.bel [192.168.24.2]) (authenticated bits=0) by restart.be (8.14.1/8.14.1) with ESMTP id l5RFmQAx065023; Wed, 27 Jun 2007 17:48:30 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1182959313; bh=wfQ6K6A+tG2LJYTCvLoqW92QHHl3NU917OmF/jt pjbk=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-Scanned-By; b=gnqWVK351AS Eh9MvGZTFk6AmOWFlE8SXMEL1rsC4G+BRUHpD+yBiym2Pg1HBv9NqRboBe2GjSPEfNs jdPmFc2A== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=nPvnpv0AONXk0NTzdG5sVoJst8Q6l6UJV4GbWq2HAHShLkPnM9lbbqRLw5hWBq0bf i6UtsPZ4a+GJflH2S4Glg== Message-ID: <468286CA.3090607@restart.be> Date: Wed, 27 Jun 2007 17:48:26 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.4 (X11/20070616) MIME-Version: 1.0 To: Alexander Motin References: <468135BF.8010407@freebsd.org> In-Reply-To: <468135BF.8010407@freebsd.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 192.168.24.1 Cc: FreeBSD Net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 15:48:36 -0000 Alexander Motin wrote: > Hi. > > I'm glad to present version 4.2 of MPD. It includes many new features, > performance improvements and fixes. > I try it for my pppoe adsl connection and I find that On FreeBSD-RELEASE, set iface route default add a route to 0/32 which is not valid as default route. I try 0.0.0.0/0 with the same result. What am I missing? Thank you Henri From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 16:46: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 5684116A46B for ; Wed, 27 Jun 2007 16:46:56 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 434CE13C483 for ; Wed, 27 Jun 2007 16:46:56 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 27 Jun 2007 09:46:54 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 7C408125B59; Wed, 27 Jun 2007 09:45:30 -0700 (PDT) Message-ID: <46829431.8020500@elischer.org> Date: Wed, 27 Jun 2007 09:45:37 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Alexander Motin References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> <4681A062.9040009@freebsd.org> <468245F8.1090709@unixservers.us> <46825347.1030206@freebsd.org> In-Reply-To: <46825347.1030206@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ovi , mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 16:46:56 -0000 Alexander Motin wrote: > > Even if pppoe have some DoS weaknesses it also have some protection > mechanisms against it. It's a pity but ng_pppoe originally implements > protocol in a way which does not allow this protection to be effectively > used. ng_pppoe can always be rewritten :-) > > As I have told 4.2 release contains overload protection which should > also help against DoS attacks. I am not sure it will be able to handle > 100Mbit/s flood of PADI requests from broken switch, but should avoid > mpd freeze in such case. > >> When having many users, it is useful to have high availability, so it >> would be nice and useful to setup multiple pppoe servers . I've tried >> that, using a router, connected >> to 2 pppoe servers, and at every pppoe connection, a route was added to >> the router and when user disconnected, the route was deleted from >> router. This is still a buggy implementation, we had problems messing >> up routing table. > > Having several PPPoE servers in one segment is a normal solution > protocol. It is not so efficient now as it could be due to ng_pppoe > implementation problem I have told, but it still should increase > performance and stability. > > What is about routing problems, you just should find good dynamic > routing solution. I have successfully working network with hundred PPPoE > servers and many thousands of users with routing successfully managed by > quagga bgp. > > From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 16:53:07 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 425FA16A46D for ; Wed, 27 Jun 2007 16:53:07 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from mail.alkar.net (mail.alkar.net [195.248.191.95]) by mx1.freebsd.org (Postfix) with ESMTP id B99B813C44C for ; Wed, 27 Jun 2007 16:53:06 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from [195.248.178.122] (HELO [192.168.3.2]) by mail.alkar.net (CommuniGate Pro SMTP 5.1.7) with ESMTPS id 786007458; Wed, 27 Jun 2007 19:53:05 +0300 Message-ID: <468295D8.9090107@freebsd.org> Date: Wed, 27 Jun 2007 19:52:40 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henri Hennebert References: <468135BF.8010407@freebsd.org> <468286CA.3090607@restart.be> In-Reply-To: <468286CA.3090607@restart.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 16:53:07 -0000 Henri Hennebert wrote: >> I'm glad to present version 4.2 of MPD. It includes many new features, >> performance improvements and fixes. > > I try it for my pppoe adsl connection and I find that On > FreeBSD-RELEASE, set iface route default add a route to 0/32 which is > not valid as default route. I try 0.0.0.0/0 with the same result. > > What am I missing? That is a bug I have missed. Fixed mpd-4.2.1 is already in ports. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Wed Jun 27 17:17: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 8130516A468 for ; Wed, 27 Jun 2007 17:17:38 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from mail.alkar.net (mail.alkar.net [195.248.191.95]) by mx1.freebsd.org (Postfix) with ESMTP id 00BA213C45B for ; Wed, 27 Jun 2007 17:17:37 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from [195.248.178.122] (HELO [192.168.3.2]) by mail.alkar.net (CommuniGate Pro SMTP 5.1.7) with ESMTPS id 786024093; Wed, 27 Jun 2007 20:17:36 +0300 Message-ID: <46829B98.2050202@freebsd.org> Date: Wed, 27 Jun 2007 20:17:12 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <468135BF.8010407@freebsd.org> <20070626214936.GC79335@zone3000.net> <4681A062.9040009@freebsd.org> <468245F8.1090709@unixservers.us> <46825347.1030206@freebsd.org> <46829431.8020500@elischer.org> In-Reply-To: <46829431.8020500@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ovi , mpd-users@lists.sourceforge.net Subject: Re: Mpd-4.2 released. 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, 27 Jun 2007 17:17:38 -0000 Julian Elischer wrote: >> Even if pppoe have some DoS weaknesses it also have some protection >> mechanisms against it. It's a pity but ng_pppoe originally implements >> protocol in a way which does not allow this protection to be effectively >> used. > > ng_pppoe can always be rewritten :-) Surely, there are always many things can be rewritten. Even that which was just created. :) It just was not our biggest problem I think. Absence of good L2TP implementation in FreeBSD before mpd-4.1/4.2, as example, was much worse. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 01:12: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 A7A4616A400; Thu, 28 Jun 2007 01:12:34 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 783A613C468; Thu, 28 Jun 2007 01:12:34 +0000 (UTC) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.14.1/8.13.8) with SMTP id l5S0YuWM044024; Wed, 27 Jun 2007 20:34:56 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Alexander Motin Date: Wed, 27 Jun 2007 20:35:11 -0400 Message-ID: References: <468135BF.8010407@freebsd.org> In-Reply-To: <468135BF.8010407@freebsd.org> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Mpd-4.2 released. 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, 28 Jun 2007 01:12:34 -0000 On Tue, 26 Jun 2007 18:50:23 +0300, in sentex.lists.freebsd.net you wrote: >As example, this functionality allows mpd to implement real LAC with >accepting incoming PPPoE connection from client and forwarding it using >L2TP tunnel to LNS. All other software L2TP implementations I know is >only a LAC emulators without real incoming calls forwarding abilities. > >Also mpd-4.2 presents: > - PPTP listening on multiple different IPs, > - L2TP tunnel authentication with shared secret, > - fast traffic filtering, shaping and rate-limiting using ng_bpf and Hi, How does MPD perform terminating L2TP connections, ie as an LNS ? Can it also terminate a few hundred L2TP connections as efficiently as PPPoE connections ? ---Mike -------------------------------------------------------- Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 mike@sentex.net, (http://www.tancsa.com) From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 02:27: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 2FD9D16A400 for ; Thu, 28 Jun 2007 02:27:50 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from mail.alkar.net (mail.alkar.net [195.248.191.95]) by mx1.freebsd.org (Postfix) with ESMTP id A6A2A13C44C for ; Thu, 28 Jun 2007 02:27:49 +0000 (UTC) (envelope-from mav@freebsd.org) Received: from [195.248.178.122] (HELO [192.168.3.2]) by mail.alkar.net (CommuniGate Pro SMTP 5.1.7) with ESMTPS id 786325001; Thu, 28 Jun 2007 05:27:47 +0300 Message-ID: <46831C89.6060009@freebsd.org> Date: Thu, 28 Jun 2007 05:27:21 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Tancsa References: <468135BF.8010407@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Mpd-4.2 released. 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, 28 Jun 2007 02:27:50 -0000 Mike Tancsa wrote: > How does MPD perform terminating L2TP connections, ie as an > LNS ? What do you mean by how? IMO possible ansers: well, fast, using ng_ksockat and ng_l2tp nodes, alike PPTP, ... Choose any. :) > Can it also terminate a few hundred L2TP connections as > efficiently as PPPoE connections ? I have not used it in production, but think it's efficiency should be close to PPTP's one, as they are relatives. PPPoE is some more efficient by it's nature as it works on lower protocol layer - Ethernet instead of UDP. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 05:54:17 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 2F5DE16A400; Thu, 28 Jun 2007 05:54:17 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 087BF13C480; Thu, 28 Jun 2007 05:54:17 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5S5sGJu041078; Thu, 28 Jun 2007 05:54:16 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5S5sGHw041074; Thu, 28 Jun 2007 05:54:16 GMT (envelope-from remko) Date: Thu, 28 Jun 2007 05:54:16 GMT From: Remko Lodder Message-Id: <200706280554.l5S5sGHw041074@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: bin/114081: [patch] ppp(8) should be able to set ethernet address for PPPoE 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, 28 Jun 2007 05:54:17 -0000 Synopsis: [patch] ppp(8) should be able to set ethernet address for PPPoE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Thu Jun 28 05:54:16 UTC 2007 Responsible-Changed-Why: I think this is more something for the networking team, reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=114081 From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 08:34:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B76FF16A421; Thu, 28 Jun 2007 08:34:58 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.freebsd.org (Postfix) with ESMTP id 62DBA13C455; Thu, 28 Jun 2007 08:34:58 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I3o0B-0006Vh-GE; Thu, 28 Jun 2007 11:01:15 +0400 From: Vladimir Grebenschikov To: Alexander Motin In-Reply-To: <46819834.4030608@freebsd.org> References: <468135BF.8010407@freebsd.org> <46814B21.5060800@elischer.org> <46819834.4030608@freebsd.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Thu, 28 Jun 2007 11:01:14 +0400 Message-Id: <1183014074.1329.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: FreeBSD Net , mpd-users@lists.sourceforge.net, Julian Elischer Subject: Re: Mpd-4.2 released. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2007 08:34:58 -0000 =F7 =D3=D2, 27/06/2007 =D7 01:50 +0300, Alexander Motin =D0=C9=DB=C5=D4: > Julian Elischer wrote: > > There has been some talk about whether mpd should be put in the base=20 > > system to replace our 3 other ppp implementations. I guess one step=20 > > would be to see what the usage cases would be for replacing if_ppp and=20 > > sppp and a first step > > would be to see how many users of these there are. >=20 > As I see situation now: > ppp - good user-level implementation. Not very fast, but stable,=20 > flexible and able to be used with other programs like pppoed. > pppd - outdated many years. In theory can be fast with modem links,=20 > but who need them now? If used with other programs like poptop will=20 > loose it's performance to ppp level due to context switches. > sppp - outdated too, but I have never used it. Is there anything=20 > except ISDN using it? In my country ISDN is mostly out of use now. > mpd - very fast and functional solution. But it is a daemon with=20 > limited abilities to be used by other software like getty or some=20 > wrappers like pppoed for ppp or GUIs like kppp. There are also some ppp(d)-based programs in tree, like rfcomm_pppd (bluetooth modem connection), which behave like ppp/pppd. just one more notice --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 09:30:08 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 2558316A473 for ; Thu, 28 Jun 2007 09:30:08 +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 12B3A13C46A for ; Thu, 28 Jun 2007 09:30:08 +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 l5S9U7Kd059678 for ; Thu, 28 Jun 2007 09:30:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5S9U7Dw059677; Thu, 28 Jun 2007 09:30:07 GMT (envelope-from gnats) Date: Thu, 28 Jun 2007 09:30:07 GMT Message-Id: <200706280930.l5S9U7Dw059677@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Bjoern A. Zeeb" Cc: Subject: Re: bin/114081: [patch] ppp(8) should be able to set ethernet address for PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Bjoern A. Zeeb" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2007 09:30:08 -0000 The following reply was made to PR bin/114081; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org Cc: frank@pinky.sax.de Subject: Re: bin/114081: [patch] ppp(8) should be able to set ethernet address for PPPoE Date: Thu, 28 Jun 2007 08:54:28 +0000 (UTC) On Thu, 28 Jun 2007, Remko Lodder wrote: > Synopsis: [patch] ppp(8) should be able to set ethernet address for PPPoE > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: remko > Responsible-Changed-When: Thu Jun 28 05:54:16 UTC 2007 > Responsible-Changed-Why: > I think this is more something for the networking team, reassign. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=114081 I have more complete patches since 2004 in my private tree for exactly the same DTAG reason;-) The very early versions are still around here: http://sources.zabbadoz.net/freebsd/patchset/ 10005-10008* I think. But they are highly outdated. I can upload newer versions somewhen the next days. BTW: are you putting your NIC into promisc mode using ifconfig? I cannot see how you would receive the packets for a different MAC else? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 12:00:16 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 A951B16A4D4 for ; Thu, 28 Jun 2007 12:00:16 +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 9921513C45D for ; Thu, 28 Jun 2007 12:00:16 +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 l5SC0G2N071932 for ; Thu, 28 Jun 2007 12:00:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5SC0GVG071931; Thu, 28 Jun 2007 12:00:16 GMT (envelope-from gnats) Date: Thu, 28 Jun 2007 12:00:16 GMT Message-Id: <200706281200.l5SC0GVG071931@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Frank Behrens" Cc: Subject: Re: bin/114081: [patch] ppp(8) should be able to set ethernet address for PPPoE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Frank Behrens List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2007 12:00:16 -0000 The following reply was made to PR bin/114081; it has been noted by GNATS. From: "Frank Behrens" To: "Bjoern A. Zeeb" Cc: bug-followup@FreeBSD.org Subject: Re: bin/114081: [patch] ppp(8) should be able to set ethernet address for PPPoE Date: Thu, 28 Jun 2007 13:39:10 +0200 Bjoern A. Zeeb wrote on 28 Jun 2007 8:54: > On Thu, 28 Jun 2007, Remko Lodder wrote: > > > Synopsis: [patch] ppp(8) should be able to set ethernet address for PPPoE > >... > > http://www.freebsd.org/cgi/query-pr.cgi?pr=114081 > > I have more complete patches since 2004 in my private tree for exactly > the same DTAG reason;-) :-) Unfortunately I did not find them before. I believe we need in offical FreeBSD documention a link list to users patch directories. ;-) > The very early versions are still around here: > http://sources.zabbadoz.net/freebsd/patchset/ > 10005-10008* I think. But they are highly outdated. > > I can upload newer versions somewhen the next days. Fine. Do you believe, that this functionality can go into FreeBSD sources? > BTW: are you putting your NIC into promisc mode using ifconfig? I > cannot see how you would receive the packets for a different MAC else? Hm, interesting question. *I* did not bring the NIC into promisc mode, but it seems to be. For PPPoE I use a vlan interface, and parent and sibling are marked PROMISC. I don't know, where it comes from: dhcpd, rtadvd, ...? Conclusions? 1. My patch may not work, because it may require PROMISC mode. I will test this. 2. Should we create a patch for mpd? (See discussion on freebsd-net). Thanks for your answer. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 14:29: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 A352F16A46B for ; Thu, 28 Jun 2007 14:29:34 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog13.obsmtp.com (s200aog13.obsmtp.com [207.126.144.127]) by mx1.freebsd.org (Postfix) with SMTP id DFAE613C44B for ; Thu, 28 Jun 2007 14:29:22 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Thu, 28 Jun 2007 14:29:16 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 10CF718141E; Thu, 28 Jun 2007 15:29:16 +0100 (BST) Message-ID: <4683C578.6070009@tomjudge.com> Date: Thu, 28 Jun 2007 15:28:08 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tom Judge References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> <46823A78.7020501@tomjudge.com> In-Reply-To: <46823A78.7020501@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , David Christensen Subject: Re: Problems with BCE network adapter (Dell PE2950) 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, 28 Jun 2007 14:29:34 -0000 Dave, Sorry for the top post, but I have just managed to repeat is exact crash twice on a new PE 1950 system. I have core files available. It seems that after a couple of reboots the problem goes away. The system actually crashed 4 times but 2 of the cores where corrupt. It also seems that the system will be stable if the following message is not produced shortly after /etc/rc.d/netif start: bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFF9 > 0x01FE)! I have attached the chip information bellow. Any help with this would be appreciated as we now have 21 systems PE[12]950 systems which randomly crash due to the original error bce0: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967292) Tom PE 2950 Chips: bce0@pci9:0:0: class=0x020000 card=0x01b21028 chip=0x164c14e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet -- bce1@pci5:0:0: class=0x020000 card=0x01b21028 chip=0x164c14e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet PE1950 Chips: bce0@pci9:0:0: class=0x020000 card=0x01b31028 chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet -- bce1@pci5:0:0: class=0x020000 card=0x01b31028 chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet Tom Judge wrote: > David Christensen wrote: >> Tom, >> >> There's already some debug code to watch for unusual size packets. >> If you can recompile the driver from HEAD with the attached diffs >> we can printout the first 128 bytes of any unusual sized packets. >> >> This does enabled other debugging code so performance will drop >> but that should be OK since this doesn't present as a performance >> problem. >> >> Dave >> > > I am currently running the driver from RELENG_6 (With the MSI code > backed out and your patch applied by hand) on a 6.2-p5 amd64 system > (Dell PE2950) and have managed to get the following crash. > > The crash was caused by "cat * >/dev/null" in an NFS mounted directory. > > I'm not sure if this is the same crash but some other boxes (identical) > to this one have crashed first time they are rebooted with the new > driver. Unfortunately I have not managed to get a dump from one of these > crashes yet. > > Also I am seeing a lot of these messages on boxes running this driver: > > bce0: bce_rx_intr(): Invalid TCP/UDP checksum = 0xD0F5! > > It seems to be caused by NFS traffic. > > I still have the core file if you need any more information. > > Tom > > kgdb /usr/obj/usr/src/sys/PE2950/kernel.debug vmcore.0 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > bce0: bce_rx_intr(): Invalid TCP/UDP checksum = 0xD0F5! > bce0: bce_rx_intr(): Invalid TCP/UDP checksum = 0x2F0A! > > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFB > > 0x01FE)! > bce0: bce_rx_intr(): Invalid TCP/UDP checksum = 0xF043! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFF9 > > 0x01FE)! > bce0: bce_rx_intr(): Invalid TCP/UDP checksum = 0x8C5F! > bce0: /usr/src/sys/dev/bce/if_bce.c(3973): Unexpected mbuf found in > rx_bd[0x005A]! > bce0: ---------------------------- Driver State > ---------------------------- > bce0: 0xFFFFFFFF:8B92A000 - (sc) driver softc structure virtual address > bce0: 0xFFFFFF00:F4000000 - (sc->bce_vhandle) PCI BAR virtual address > bce0: 0xFFFFFF00:009E3680 - (sc->status_block) status block virtual address > bce0: 0xFFFFFF00:009D6400 - (sc->stats_block) statistics block virtual > address > bce0: 0xFFFFFFFF:8B92A1B0 - (sc->tx_bd_chain) tx_bd chain virtual adddress > bce0: 0xFFFFFFFF:8B92A1E8 - (sc->rx_bd_chain) rx_bd chain virtual address > bce0: 0xFFFFFFFF:8B92B260 - (sc->tx_mbuf_ptr) tx mbuf chain virtual address > bce0: 0xFFFFFFFF:8B92D260 - (sc->rx_mbuf_ptr) rx mbuf chain virtual address > bce0: 0x0000357F - (sc->interrupts_generated) h/w intrs > bce0: 0x00002981 - (sc->rx_interrupts) rx interrupts handled > bce0: 0x0000212A - (sc->tx_interrupts) tx interrupts handled > bce0: 0x0000706B - (sc->last_status_idx) status block index > bce0: 0x0000675E - (sc->tx_prod) tx producer index > bce0: 0x00006707 - (sc->tx_cons) tx consumer index > bce0: 0x001B39EA - (sc->tx_prod_bseq) tx producer bseq index > bce0: 0x0000F25C - (sc->rx_prod) rx producer index > bce0: 0x0000F059 - (sc->rx_cons) rx consumer index > bce0: 0x0B850C00 - (sc->rx_prod_bseq) rx producer bseq index > bce0: 0x000000AB - (sc->rx_mbuf_alloc) rx mbufs allocated > bce0: 0x0000FFF8 - (sc->free_rx_bd) free rx_bd's > bce0: 0x00000000/000001FE - (sc->rx_low_watermark) rx low watermark > bce0: 0x0000001D - (sc->txmbuf_alloc) tx mbufs allocated > bce0: 0x000000AB - (sc->rx_mbuf_alloc) rx mbufs allocated > bce0: 0x00000057 - (sc->used_tx_bd) used tx_bd's > bce0: 0x000001FE/000001FE - (sc->tx_hi_watermark) tx hi watermark > bce0: 0x00000000 - (sc->mbuf_alloc_failed) failed mbuf alloc > bce0: > ------------------------------------------------------------------------ > bce0: ---------------------------- Status Block > ---------------------------- > bce0: attn_bits = 0x00000001, attn_bits_ack = 0x00000001, index = 0x70BF > bce0: rx_cons0 = 0x0000F061, tx_cons0 = 0x0000675E > bce0: status_idx = 0x70BF > bce0: > ------------------------------------------------------------------------ > > > Fatal trap 3: breakpoint instruction fault while in kernel mode > cpuid = 4; apic id = 04 > instruction pointer = 0x8:0xffffffff801ee956 > stack pointer = 0x10:0xffffffffb6d60b40 > frame pointer = 0x10:0x5a > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 27 (irq16: bce0 bce1) > trap number = 3 > panic: breakpoint instruction fault > cpuid = 4 > Uptime: 3m10s > Dumping 8191 MB (3 chunks) > chunk 0: 1MB (156 pages) ... ok > chunk 1: 3327MB (851624 pages) 3311 3295 3279 3263 3247 3231 3215 3199 > 3183 31 > > #0 doadump () at pcpu.h:172 > 172 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:172 > #1 0x0000000000000004 in ?? () > #2 0xffffffff8029e0e7 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #3 0xffffffff8029e781 in panic (fmt=0xffffff021ef0a4c0 > "?\206?\036\002?????\036\002???") at /usr/src/sys/kern/kern_shutdown.c:565 > #4 0xffffffff803f9e3f in trap_fatal (frame=0xffffff021ef0a4c0, > eva=18446742983307069104) at /usr/src/sys/amd64/amd64/trap.c:660 > #5 0xffffffff803fa2e2 in trap (frame= > {tf_rdi = 0, tf_rsi = -2139025408, tf_rdx = 1, tf_rcx = 1915683, > tf_r8 = 1048064, tf_r9 = 10, tf_rax = 79, tf_rbx = -1953325056, tf_rbp = > 90, tf_r10 = -1227486624, tf_r11 = 4294967208, tf_r12 = -1953325056, > tf_r13 = 90, tf_r14 = 61537, tf_r15 = 61530, tf_trapno = 3, tf_addr = 0, > tf_flags = -1099501259136, tf_err = 0, tf_rip = -2145457834, tf_cs = 8, > tf_rflags = 642, tf_rsp = -1227486384, tf_ss = 16}) at > /usr/src/sys/amd64/amd64/trap.c:469 > #6 0xffffffff803e55fb in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:168 > #7 0xffffffff801ee956 in bce_breakpoint (sc=0xffffffff8b92a000) at > cpufunc.h:63 > #8 0xffffffff801ef0f6 in bce_intr (xsc=0x0) at > /usr/src/sys/dev/bce/if_bce.c:3970 > #9 0xffffffff80284919 in ithread_loop (arg=0xffffff00009e4000) at > /usr/src/sys/kern/kern_intr.c:682 > #10 0xffffffff802830b7 in fork_exit (callout=0xffffffff802847d0 > , arg=0xffffff00009e4000, frame=0xffffffffb6d60c50) at > /usr/src/sys/kern/kern_fork.c:821 > #11 0xffffffff803e595e in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:394 > #12 0x0000000000000000 in ?? () > #13 0x0000000000000000 in ?? () > #14 0x0000000000000001 in ?? () > #15 0x0000000000000000 in ?? () > #16 0x0000000000000000 in ?? () > #17 0x0000000000000000 in ?? () > #18 0x0000000000000000 in ?? () > #19 0x0000000000000000 in ?? () > > #44 0x00000000007f3000 in ?? () > #45 0xffffff021ef286b0 in ?? () > #46 0x0000000000000104 in ?? () > #47 0x0000000000000000 in ?? () > #48 0xffffff021ef286b0 in ?? () > #49 0xffffff021ef68000 in ?? () > #50 0xffffffffb6d60848 in ?? () > #51 0xffffff021ef0a4c0 in ?? () > #52 0xffffffff802b4856 in sched_switch (td=0xffffff00009e4000, > newtd=0x0, flags=0) at /usr/src/sys/kern/sched_4bsd.c:973 > > #124 0x0000000000000000 in ?? () > Cannot access memory at address 0xffffffffb6d61000 > (kgdb) frame 8 > #8 0xffffffff801ef0f6 in bce_intr (xsc=0x0) at > /usr/src/sys/dev/bce/if_bce.c:3970 > 3970 DBRUNIF((!(rxbd->rx_bd_flags & > RX_BD_FLAGS_END)), > (kgdb) list > 3965 > 3966 /* The mbuf is stored with the last rx_bd entry > of a packet. */ > 3967 if (sc->rx_mbuf_ptr[sw_chain_cons] != NULL) { > 3968 > 3969 /* Validate that this is the last rx_bd. */ > 3970 DBRUNIF((!(rxbd->rx_bd_flags & > RX_BD_FLAGS_END)), > 3971 BCE_PRINTF("%s(%d): Unexpected > mbuf found in rx_bd[0x%04X]!\n", > 3972 __FILE__, __LINE__, sw_chain_cons); > 3973 bce_breakpoint(sc)); > 3974 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 17:30:54 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 4A4D716A468; Thu, 28 Jun 2007 17:30:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 233E313C46E; Thu, 28 Jun 2007 17:30:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5SHUrJV000509; Thu, 28 Jun 2007 17:30:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5SHUr1K000505; Thu, 28 Jun 2007 17:30:53 GMT (envelope-from linimon) Date: Thu, 28 Jun 2007 17:30:53 GMT From: Mark Linimon Message-Id: <200706281730.l5SHUr1K000505@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/114095: [carp] carp+pf delay with high state limit 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, 28 Jun 2007 17:30:54 -0000 Old Synopsis: Carp+pf delay with high state limit New Synopsis: [carp] carp+pf delay with high state limit Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jun 28 17:30:15 UTC 2007 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=114095 From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 18:11:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97FB216A46F for ; Thu, 28 Jun 2007 18:11:15 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from a5.virtuaal.com (a5.virtuaal.com [195.222.15.75]) by mx1.freebsd.org (Postfix) with ESMTP id 583E413C4B9 for ; Thu, 28 Jun 2007 18:11:15 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from pc88.host50.starman.ee ([62.65.242.88] helo=[192.168.2.101]) by a5.virtuaal.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1I3xnp-0007Uw-P4 for freebsd-net@freebsd.org; Thu, 28 Jun 2007 20:29:09 +0300 From: Andrei Kolu To: freebsd-net@freebsd.org Date: Thu, 28 Jun 2007 20:29:06 +0300 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200706282029.06957.antik@bsd.ee> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - a5.virtuaal.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - bsd.ee Subject: mounted ntfs partition shared with samba not accessible 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, 28 Jun 2007 18:11:15 -0000 I can access "test" mount from other FreeBSD without any problem but have no access to "moovid" share. With Konqueror fish://antik@192.168.2.102/usr/home/antik/moovid I can see all files. Is it possible at all share ntfs volumes with samba on FreeBSD box? samba-3.0.25a,1 =46reeBSD 6.2-RELEASE-p5 # mount /dev/ad0s5 on /usr/home/antik/moovid (ntfs, local) /usr/local/etc/smb.conf =2D------------------------------------------------- [moovid] =A0 =A0path =3D /home/antik/moovid =A0 =A0valid users =3D antik =A0 =A0public =3D yes =A0 =A0writable =3D no =A0 =A0printable =3D no =A0 =A0create mask =3D 0765 [test] =A0 =A0path =3D /home/antik/down =A0 =A0valid users =3D antik =A0 =A0public =3D yes =A0 =A0writable =3D yes =A0 =A0printable =3D no =A0 =A0create mask =3D 0765 =2D------------------------------------------------- /var/log/samba/log.machinename =2D------------------------------------------------- [2007/06/28 20:06:38, 0] lib/util.c:smb_panic(1632) =A0 PANIC (pid 14414): internal error [2007/06/28 20:06:38, 0] lib/util.c:log_stack_trace(1786) =A0 unable to produce a stack trace on this platform [2007/06/28 20:06:38, 0] lib/fault.c:dump_core(181) =A0 dumping core in /var/log/samba/cores/smbd =2D------------------------------------------------- No core dumps found in this dicectory. /var/log/messages =2D------------------------------------------------- Jun 28 20:06:38 supermicro kernel: pid 14414 (smbd), uid 0: exited on signa= l 6 =2D------------------------------------------------- From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 21:00:17 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 C3B8E16A469 for ; Thu, 28 Jun 2007 21:00:17 +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 7AFB313C46E for ; Thu, 28 Jun 2007 21:00:17 +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 l5SL0HZZ023046 for ; Thu, 28 Jun 2007 21:00:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5SL0Hep023044; Thu, 28 Jun 2007 21:00:17 GMT (envelope-from gnats) Date: Thu, 28 Jun 2007 21:00:17 GMT Message-Id: <200706282100.l5SL0Hep023044@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: W Forms Cc: Subject: Re: kern/112710: [re] if_re driver detects incorrect b243a405a405 MAC address on SMC9452TX-1 pci gigabit cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: W Forms List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2007 21:00:17 -0000 The following reply was made to PR kern/112710; it has been noted by GNATS. From: W Forms To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/112710: [re] if_re driver detects incorrect b243a405a405 MAC address on SMC9452TX-1 pci gigabit cards Date: Thu, 28 Jun 2007 22:26:29 +0200 I tested this issue today using an OpenBSD 4.1 boot CD. The test hardware is exactly the same system my original report and tests were based on, with only two minor exceptions: 1., the ORDER of the "5 bad" network adapters may not be the same as with the original tests 2., for this OpenBSD test I also had a 16MB USB pendrive (sd1) connected to dump dmesg to, which was not present for the FreeBSD and Linux tests Please notice how the 5 adapters all show the same "incorrect" MAC address under OpenBSD! Exactly as with FreeBSD. I guess this is because FreeBSD and OpenBSD uses the same driver. Could somebody confirm that?! How about NetBSD ? OpenBSD 4.1 (RAMDISK_CD) #248: Sat Mar 10 19:32:46 MST 2007 deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache) 499 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, MMX,FXSR,SSE real mem = 536420352 (523848K) avail mem = 483319808 (471992K) using 4278 buffers containing 26943488 bytes (26312K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+ BIOS, date 02/09/01, BIOS32 rev. 0 @ 0xfd5e1 pcibios0 at bios0: rev 2.1 @ 0xf0000/0xffff pcibios0: PCI BIOS has 11 Interrupt Routing table entries pcibios0: PCI Interrupt Router at 000:15:0 ("ServerWorks OSB4" rev 0x00) pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc0000/0x8000 0xc8000/0x5000 acpi at mainbus0 not configured cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 "ServerWorks CNB20-LE Host" rev 0x04 pchb1 at pci0 dev 0 function 1 "ServerWorks CNB20-LE Host" rev 0x02 pci1 at pchb1 bus 1 re0 at pci1 dev 2 function 0 "Realtek 8169" rev 0x10: RTL8169/8110SB (0x1000), irq 15, address b2:43:a4:05:a4:05 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 3 re1 at pci1 dev 3 function 0 "Realtek 8169" rev 0x10: RTL8169/8110SB (0x1000), irq 9, address b2:43:a4:05:a4:05 rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 3 re2 at pci1 dev 4 function 0 "Realtek 8169" rev 0x10: RTL8169/8110SB (0x1000), irq 10, address b2:43:a4:05:a4:05 rgephy2 at re2 phy 7: RTL8169S/8110S PHY, rev. 3 re3 at pci1 dev 5 function 0 "Realtek 8169" rev 0x10: RTL8169/8110SB (0x1000), irq 11, address b2:43:a4:05:a4:05 rgephy3 at re3 phy 7: RTL8169S/8110S PHY, rev. 3 re4 at pci0 dev 1 function 0 "Realtek 8169" rev 0x10: RTL8169/8110SB (0x1000), irq 11, address b2:43:a4:05:a4:05 rgephy4 at re4 phy 7: RTL8169S/8110S PHY, rev. 3 ahc0 at pci0 dev 6 function 0 "Adaptec AIC-7895" rev 0x04: irq 15 scsibus0 at ahc0: 16 targets ahc1 at pci0 dev 6 function 1 "Adaptec AIC-7895" rev 0x04: irq 10 scsibus1 at ahc1: 16 targets sd0 at scsibus1 targ 0 lun 0: SCSI2 0/ direct fixed sd0: 8683MB, 8057 cyl, 10 head, 220 sec, 512 bytes/sec, 17783249 sec total st0 at scsibus1 targ 6 lun 0: SCSI2 1/ sequential removable scsibus1 targ 14 lun 0: SCSI2 3/processor fixed not configured pcn0 at pci0 dev 9 function 0 "AMD 79c970 PCnet-PCI" rev 0x36, Am79c972, rev 6: irq 11, address 00:06:29:50:d9:9e nsphyter0 at pcn0 phy 1: DP83843 10/100 PHY, rev. 0 ukphy0 at pcn0 phy 31: Generic IEEE 802.3u media interface, rev. 1: OUI 0x00001a, model 0x0001 ifmedia_set: no match for 0x20/0xffffffff vga1 at pci0 dev 10 function 0 "S3 Trio64V2/DX" rev 0x16 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) pcib0 at pci0 dev 15 function 0 "ServerWorks OSB4" rev 0x4d pciide0 at pci0 dev 15 function 1 "ServerWorks IDE" rev 0x4a: DMA (unsupported), channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus2 at atapiscsi0: 2 targets cd0 at scsibus2 targ 0 lun 0: SCSI0 5/ cdrom removable pciide0: no compatibility interrupt for use by channel 1 ohci0 at pci0 dev 15 function 2 "ServerWorks OSB4/CSB5 USB" rev 0x04: irq 10, version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec biomask f5e5 netmask ffe5 ttymask ffe7 rd0: fixed, 3800 blocks umass0 at uhub0 port 2 configuration 1 interface 0 umass0: vendor 0x0c76 product 0x0005, rev 1.10/1.00, addr 2 umass0: using SCSI over Bulk-Only scsibus3 at umass0: 2 targets sd1 at scsibus3 targ 1 lun 0: SCSI2 0/direct removable sd1: 15MB, 15 cyl, 64 head, 32 sec, 512 bytes/sec, 31263 sec total ahc1: target 0 using 16bit transfers ahc1: target 0 synchronous at 5.7MHz, offset = 0x8 dkcsum: sd0 matches BIOS drive 0x80 root on rd0a rootdev=0x1100 rrootdev=0x2f00 rawdev=0x2f02 sd1(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a SENSE KEY: Write Protected ASC/ASCQ: ASC 0x27 ASCQ 0x00 umass0: at uhub0 port 2 (addr 2) disconnected sd1 detached scsibus3 detached umass0 detached umass0 at uhub0 port 2 configuration 1 interface 0 umass0: vendor 0x0c76 product 0x0005, rev 1.10/1.00, addr 2 umass0: using SCSI over Bulk-Only scsibus3 at umass0: 2 targets sd1 at scsibus3 targ 1 lun 0: SCSI2 0/direct removable sd1: 15MB, 15 cyl, 64 head, 32 sec, 512 bytes/sec, 31263 sec total umass0: at uhub0 port 2 (addr 2) disconnected sd1 detached scsibus3 detached umass0 detached umass0 at uhub0 port 2 configuration 1 interface 0 umass0: vendor 0x0c76 product 0x0005, rev 1.10/1.00, addr 2 umass0: using SCSI over Bulk-Only scsibus3 at umass0: 2 targets sd1 at scsibus3 targ 1 lun 0: SCSI2 0/direct removable sd1: 15MB, 15 cyl, 64 head, 32 sec, 512 bytes/sec, 31263 sec total Regards, Keve From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 21:02:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 711E816A421 for ; Thu, 28 Jun 2007 21:02:31 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id 45FB013C483 for ; Thu, 28 Jun 2007 21:02:31 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 28 Jun 2007 14:02:20 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 32D662AF; Thu, 28 Jun 2007 14:02:20 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 1E0A42AE; Thu, 28 Jun 2007 14:02:20 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FKR70315; Thu, 28 Jun 2007 14:02:11 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 3D3F269CA3; Thu, 28 Jun 2007 14:02:11 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Jun 2007 14:02:10 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD9030457137B@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <4683C578.6070009@tomjudge.com> Thread-Topic: Problems with BCE network adapter (Dell PE2950) Thread-Index: Ace5kMf8tXReAU+tSNO0tue8ft3OFgANaqRg References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> <46823A78.7020501@tomjudge.com> <4683C578.6070009@tomjudge.com> From: "David Christensen" To: "Tom Judge" X-WSS-ID: 6A9AFE563DG518277-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: RE: Problems with BCE network adapter (Dell PE2950) 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, 28 Jun 2007 21:02:31 -0000 > Sorry for the top post, but I have just managed to repeat is=20 > exact crash=20 > twice on a new PE 1950 system. I have core files available. >=20 > It seems that after a couple of reboots the problem goes away. The=20 > system actually crashed 4 times but 2 of the cores where corrupt. >=20 > It also seems that the system will be stable if the following=20 > message is=20 > not produced shortly after /etc/rc.d/netif start: >=20 > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free=20 > rx_bd (0xFFF9 >=20 > 0x01FE)! >=20 The error indicates that too many receive buffer descriptors were freed from the receive chain. The driver must be losing count somewhere. The process for duplicating the error sounds simple enough, how much data is in your NFS mounted directory? Are you using TCP or UDP for the NFS mount? Any idea what type of network activity is happening just after /etc/rc.d/netif start (DHCP, NTP, anything else)? Dave From owner-freebsd-net@FreeBSD.ORG Thu Jun 28 23:36:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9231616A400 for ; Thu, 28 Jun 2007 23:36:54 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 694B913C457 for ; Thu, 28 Jun 2007 23:36:54 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 28 Jun 2007 16:36:45 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A1F412AF; Thu, 28 Jun 2007 16:36:45 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 8D70C2AE; Thu, 28 Jun 2007 16:36:45 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FKS04421; Thu, 28 Jun 2007 16:36:45 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 3483669CA5; Thu, 28 Jun 2007 16:36:45 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Jun 2007 16:36:44 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> Thread-Topic: Problems with BCE network adapter (Dell PE2950) Thread-Index: Ace5kMf8tXReAU+tSNO0tue8ft3OFgANaqRgAAWpYmA= References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> <46823A78.7020501@tomjudge.com> <4683C578.6070009@tomjudge.com> From: "David Christensen" To: "Tom Judge" X-WSS-ID: 6A9A99873AC16489191-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: RE: Problems with BCE network adapter (Dell PE2950) 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, 28 Jun 2007 23:36:54 -0000 > > Sorry for the top post, but I have just managed to repeat is=20 > > exact crash=20 > > twice on a new PE 1950 system. I have core files available. > >=20 > > It seems that after a couple of reboots the problem goes away. The=20 > > system actually crashed 4 times but 2 of the cores where corrupt. > >=20 > > It also seems that the system will be stable if the following=20 > > message is=20 > > not produced shortly after /etc/rc.d/netif start: > >=20 > > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free=20 > > rx_bd (0xFFF9 >=20 > > 0x01FE)! > >=20 >=20 > The error indicates that too many receive buffer descriptors > were freed from the receive chain. The driver must be losing > count somewhere. The process for duplicating the error sounds > simple enough, how much data is in your NFS mounted directory? > Are you using TCP or UDP for the NFS mount? >=20 > Any idea what type of network activity is happening just after > /etc/rc.d/netif start (DHCP, NTP, anything else)? >=20 > Dave One other thing, are you using jumbo frames? What's your MTU setting? Dave From owner-freebsd-net@FreeBSD.ORG Fri Jun 29 01:00: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 58AA816A421 for ; Fri, 29 Jun 2007 01:00:29 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 02A3C13C457 for ; Fri, 29 Jun 2007 01:00:28 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 09:00:26 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 09:00:26 +0800 Received: from [172.23.17.155] ([172.23.17.155]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 09:00:26 +0800 Message-ID: <468459B2.3060601@zyxel.com.tw> Date: Fri, 29 Jun 2007 09:00:34 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2007 01:00:26.0318 (UTC) FILETIME=[E11576E0:01C7B9E8] Subject: Some implementation problems about IPsec 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, 29 Jun 2007 01:00:29 -0000 Dear all: I am tracing the codes for the implementation for IPsec recently. I have two problems here about the implementation: 1. In ip6_input.c, before handing the packet to the next protocol handler after processing of IPv6 headers, #ifdef IPSEC /* * enforce IPsec policy checking if we are seeing last header. * note that we do not visit this with protocols with pcb layer * code - like udp/tcp/raw ip. */ if ((inet6sw[ip6_protox[nxt]].pr_flags & PR_LASTHDR) != 0 && ipsec6_in_reject(m, NULL)) { ipsec6stat.in_polvio++; goto bad; } #endif Why needs to do ipsec6_in_reject() here for some specific "LASTHDER" protocols, such as icmp? Why not all the packets need the check? 2. What is the real meaning for the flags M_AUTHIPHDR, M_AUTHIPDGM, and M_DECRYPTED? At the beginning, I thought the mbuf carrying either one of the flags would represent it had processed by IPsec stack. However, in KAME implementation, ah_input and ah6_input will unset the flag after an AH tunneled packet has been passed the authentication. While ESP is the case, once M_DECRYPTED flag is set, it would never be unset. On the other hand, in FAST_IPSEC, which is another different IPsec implementation on FreeBSD, the flags are never unset, and also another flag named M_IPSEC is defined as M_AUTHIPHDR | M_AUTHIPDGM | M_DECRYPTED. I am confused by the inconsistent usage..... Many Thanks. Susan From owner-freebsd-net@FreeBSD.ORG Fri Jun 29 02:49:06 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 976DB16A400 for ; Fri, 29 Jun 2007 02:49:06 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE1613C4B0 for ; Fri, 29 Jun 2007 02:49:06 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 28 Jun 2007 19:48:54 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 8231D2AF; Thu, 28 Jun 2007 19:48:54 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6DB7A2AE; Thu, 28 Jun 2007 19:48:54 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FKS39262; Thu, 28 Jun 2007 19:48:51 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 6CFDF69CA3; Thu, 28 Jun 2007 19:48:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Jun 2007 19:48:50 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD903045714EF@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> Thread-Topic: Problems with BCE network adapter (Dell PE2950) Thread-Index: Ace5kMf8tXReAU+tSNO0tue8ft3OFgANaqRgAAWpYmAABluJwA== References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> <46823A78.7020501@tomjudge.com> <4683C578.6070009@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> From: "David Christensen" To: "Tom Judge" X-WSS-ID: 6A9AAC9C3DG643444-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: RE: Problems with BCE network adapter (Dell PE2950) 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, 29 Jun 2007 02:49:06 -0000 > > > Sorry for the top post, but I have just managed to repeat is=20 > > > exact crash=20 > > > twice on a new PE 1950 system. I have core files available. > > >=20 > > > It seems that after a couple of reboots the problem goes=20 > away. The=20 > > > system actually crashed 4 times but 2 of the cores where corrupt. > > >=20 > > > It also seems that the system will be stable if the following=20 > > > message is=20 > > > not produced shortly after /etc/rc.d/netif start: > > >=20 > > > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free=20 > > > rx_bd (0xFFF9 >=20 > > > 0x01FE)! > > >=20 > >=20 > > The error indicates that too many receive buffer descriptors > > were freed from the receive chain. The driver must be losing > > count somewhere. The process for duplicating the error sounds > > simple enough, how much data is in your NFS mounted directory? > > Are you using TCP or UDP for the NFS mount? > >=20 > > Any idea what type of network activity is happening just after > > /etc/rc.d/netif start (DHCP, NTP, anything else)? > >=20 > > Dave >=20 > One other thing, are you using jumbo frames? What's your MTU setting? >=20 And one more thing. I've been passing line rate traffic for a few=20 hours (with both netperf running the tcp_stream_script and a constant stream of UDP traffic to the discard server on the FreeBSD system) and I haven't seen a hiccup yet on the tip of RELENG_6 with jumbo frames enabled on my Dell PE2950 (one dual-core CPU, 4GB RAM). Of course I don't have any real services running on it (load average is 0.19). Any unusual settings I should be aware of? Does anyone know a simple way to drive up CPU utilization and consume large amounts of memory to try and simulate a heavily loaded system? Dave From owner-freebsd-net@FreeBSD.ORG Fri Jun 29 09:51: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 2748716A46F for ; Fri, 29 Jun 2007 09:51:44 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog14.obsmtp.com (s200aog14.obsmtp.com [207.126.144.128]) by mx1.freebsd.org (Postfix) with SMTP id CAD4A13C458 for ; Fri, 29 Jun 2007 09:51:39 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Fri, 29 Jun 2007 09:51:25 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id ADF46181424; Fri, 29 Jun 2007 10:51:24 +0100 (BST) Message-ID: <4684D5C0.3040709@tomjudge.com> Date: Fri, 29 Jun 2007 10:49:52 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: David Christensen References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> <46823A78.7020501@tomjudge.com> <4683C578.6070009@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> <09BFF2FA5EAB4A45B6655E151BBDD903045714EF@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD903045714EF@NT-IRVA-0750.brcm.ad.broadcom.com> Content-Type: multipart/mixed; boundary="------------030907020009000402030006" Cc: freebsd-net Subject: Re: Problems with BCE network adapter (Dell PE2950) 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, 29 Jun 2007 09:51:44 -0000 This is a multi-part message in MIME format. --------------030907020009000402030006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit David Christensen wrote: >>>> Sorry for the top post, but I have just managed to repeat is >>>> exact crash >>>> twice on a new PE 1950 system. I have core files available. >>>> >>>> It seems that after a couple of reboots the problem goes >> away. The >>>> system actually crashed 4 times but 2 of the cores where corrupt. >>>> >>>> It also seems that the system will be stable if the following >>>> message is >>>> not produced shortly after /etc/rc.d/netif start: >>>> >>>> bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free >>>> rx_bd (0xFFF9 > >>>> 0x01FE)! >>>> >>> The error indicates that too many receive buffer descriptors >>> were freed from the receive chain. The driver must be losing >>> count somewhere. The process for duplicating the error sounds >>> simple enough, how much data is in your NFS mounted directory? >>> Are you using TCP or UDP for the NFS mount? >>> >>> Any idea what type of network activity is happening just after >>> /etc/rc.d/netif start (DHCP, NTP, anything else)? >>> >>> Dave >> One other thing, are you using jumbo frames? What's your MTU setting? >> > > And one more thing. I've been passing line rate traffic for a few > hours (with both netperf running the tcp_stream_script and a constant > stream of UDP traffic to the discard server on the FreeBSD system) > and I haven't seen a hiccup yet on the tip of RELENG_6 with jumbo > frames enabled on my Dell PE2950 (one dual-core CPU, 4GB RAM). Of > course I don't have any real services running on it (load average is > 0.19). Any unusual settings I should be aware of? > > Does anyone know a simple way to drive up CPU utilization and consume > large amounts of memory to try and simulate a heavily loaded system? > > Dave > Hi, As the NIC's are coming UP (as indicated by messages on the console) the system is trying to mount NFS file systems. At this stage if the system does not produce the "Too many free rx_bd" error the system will be stable. We are using Jumbo Frames with an MTU of 8192. The switches are Dell PowerConnect 5324's. The NFS server is a Dell PE1850 with EM cards. The bug can be triggered by NFS data (there was arround 600Mb of data in the directory that I ran "cat * > /dev/null" in). Also the bug can be triggered by heavy rsync traffic. (Rsync over ssh where the box crashing is the SSH client, also SSH has the HPN patches applied to it.) The box that crashed 4 times did so in the following sequence: 1) First boot with debug driver crash very shortly after nfs mounts start/complete (Corrupt dump). "Too many free rx_bd" message is present on the console before the crash. 2) Second boot with the debug driver system does not crash after cat * over NFS. Crashes a few minutes after starting a rsync from an identical PE1950 the system crashed (Again producing a corrupt core dump). "Too many free rx_bd" message is present on the console before the crash. 3) Third boot NFS crash was not tested. Restarted rsync process and the system crashed again. (Core ok this time but log buffer not present in the dump, or was empty.) Back trace indicates the driver crashed the system at the same place as the next crash on this system and the only core I have from a PE2950. "Too many free rx_bd" message is present on the console before the crash. 4) Fourth boot again did not test the NFS crash. Restarted the rsync process causing the system to crash. ( Core and log buffer present in core, buffer and back trace at the end of this email.) "Too many free rx_bd" message is present on the console before the crash. 5) Fifth boot of the system. No "Too many free rx_bd" messages appear on the console. The system rsync's ~290Gb of data and is still up. At each reboot the system was just left to reboot itself the system was not powered off at any point. I have a PE2950 that went through a similar cycle of crashes only to boot into a stable configuration 3-4 reboots later. (I have the last core available from this system.) The system crashing above is a PE1950 with 1 5110 1.6Ghz Dual Core Xeon, 2Gb RAM, PREC5/i (2 * 80 Gb SATA RAID 1), PERC5/e (MD1000 3 * 500Gb SATA RAID 5). The source of the data being rsynced was an identical system. I have attached the patch for the driver we are running (patch is against RELENG_6_2). Tom root@sultan '10:48:28' '/var/crash' > $ ifconfig bce0 bce0: flags=8843 mtu 8192 options=3b inet 172.31.0.28 netmask 0xffffff00 broadcast 172.31.0.255 ether 00:19:b9:e4:4d:cc media: Ethernet autoselect (1000baseTX ) status: active root@sultan '10:48:34' '/var/crash' > $ pciconf -lv | fgrep -A 3 bce0 bce0@pci9:0:0: class=0x020000 card=0x01b31028 chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet root@sultan '10:47:08' '/var/crash' > $ kgdb /usr/obj/usr/src/sys/PE2950/kernel.debug vmcore.3 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFF > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFF > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFF > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFE > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFD > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFD > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFD > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFD > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFD > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFC > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFC > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFC > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFB > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFF9 > 0x01FE)! bce0: /usr/src/sys/dev/bce/if_bce.c(3973): Unexpected mbuf found in rx_bd[0x0098]! bce0: ---------------------------- Driver State ---------------------------- bce0: 0xFFFFFFFF:866A6000 - (sc) driver softc structure virtual address bce0: 0xFFFFFF00:F4000000 - (sc->bce_vhandle) PCI BAR virtual address bce0: 0xFFFFFF00:009C3DC0 - (sc->status_block) status block virtual address bce0: 0xFFFFFF00:009D7400 - (sc->stats_block) statistics block virtual address bce0: 0xFFFFFFFF:866A61B0 - (sc->tx_bd_chain) tx_bd chain virtual adddress bce0: 0xFFFFFFFF:866A61E8 - (sc->rx_bd_chain) rx_bd chain virtual address bce0: 0xFFFFFFFF:866A7260 - (sc->tx_mbuf_ptr) tx mbuf chain virtual address bce0: 0xFFFFFFFF:866A9260 - (sc->rx_mbuf_ptr) rx mbuf chain virtual address bce0: 0x0006D4FE - (sc->interrupts_generated) h/w intrs bce0: 0x00039B5F - (sc->rx_interrupts) rx interrupts handled bce0: 0x000339FB - (sc->tx_interrupts) tx interrupts handled bce0: 0x0000A413 - (sc->last_status_idx) status block index bce0: 0x00009500 - (sc->tx_prod) tx producer index bce0: 0x000094FD - (sc->tx_cons) tx consumer index bce0: 0x01FC8BFD - (sc->tx_prod_bseq) tx producer bseq index bce0: 0x0000B69A - (sc->rx_prod) rx producer index bce0: 0x0000B497 - (sc->rx_cons) rx consumer index bce0: 0xBF89D400 - (sc->rx_prod_bseq) rx producer bseq index bce0: 0x000000AB - (sc->rx_mbuf_alloc) rx mbufs allocated bce0: 0x0000FFF8 - (sc->free_rx_bd) free rx_bd's bce0: 0x00000000/000001FE - (sc->rx_low_watermark) rx low watermark bce0: 0x00000002 - (sc->txmbuf_alloc) tx mbufs allocated bce0: 0x000000AB - (sc->rx_mbuf_alloc) rx mbufs allocated bce0: 0x00000002 - (sc->used_tx_bd) used tx_bd's bce0: 0x000001FE/000001FE - (sc->tx_hi_watermark) tx hi watermark bce0: 0x00000000 - (sc->mbuf_alloc_failed) failed mbuf alloc bce0: ------------------------------------------------------------------------ bce0: ---------------------------- Status Block ---------------------------- bce0: attn_bits = 0x00000001, attn_bits_ack = 0x00000001, index = 0xA422 bce0: rx_cons0 = 0x0000B4BF, tx_cons0 = 0x000094FF bce0: status_idx = 0xA422 bce0: ------------------------------------------------------------------------ Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xffffffff801ee956 stack pointer = 0x10:0xffffffffb1922b40 frame pointer = 0x10:0x98 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 21 (irq16: bce0 bce1) trap number = 3 panic: breakpoint instruction fault cpuid = 0 Uptime: 1h5m39s Dumping 2047 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 2047MB (523944 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:172 #1 0x0000000000000004 in ?? () #2 0xffffffff8029e0e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff8029e781 in panic (fmt=0xffffff007b9ed720 "\b?\236{") at /usr/src/sys/kern/kern_shutdown.c:565 #4 0xffffffff803f9e3f in trap_fatal (frame=0xffffff007b9ed720, eva=18446742976271936008) at /usr/src/sys/amd64/amd64/trap.c:660 #5 0xffffffff803fa2e2 in trap (frame= {tf_rdi = 0, tf_rsi = -2139025408, tf_rdx = 1, tf_rcx = 1298717, tf_r8 = 1048064, tf_r9 = 10, tf_rax = 79, tf_rbx = -2039848960, tf_rbp = 152, tf_r10 = -1315820960, tf_r11 = 4294967274, tf_r12 = -2039848960, tf_r13 = 152, tf_r14 = 46242, tf_r15 = 46232, tf_trapno = 3, tf_addr = 0, tf_flags = -1099501388352, tf_err = 0, tf_rip = -2145457834, tf_cs = 8, tf_rflags = 642, tf_rsp = -1315820720, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:469 #6 0xffffffff803e55fb in calltrap () at /usr/src/sys/amd64/amd64/exception.S:168 #7 0xffffffff801ee956 in bce_breakpoint (sc=0xffffffff866a6000) at cpufunc.h:63 #8 0xffffffff801ef0f6 in bce_intr (xsc=0x0) at /usr/src/sys/dev/bce/if_bce.c:3970 #9 0xffffffff80284919 in ithread_loop (arg=0xffffff00009d35a0) at /usr/src/sys/kern/kern_intr.c:682 #10 0xffffffff802830b7 in fork_exit (callout=0xffffffff802847d0 , arg=0xffffff00009d35a0, frame=0xffffffffb1922c50) at /usr/src/sys/kern/kern_fork.c:821 #11 0xffffffff803e595e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:394 #12 0x0000000000000000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000001 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000000 in ?? () #44 0x00000000007f3000 in ?? () #45 0xffffff007b9ed720 in ?? () #46 0xffffff00009d35a0 in ?? () #47 0x0000000000000001 in ?? () #48 0xffffff007b9eea08 in ?? () #49 0xffffff007b9a5980 in ?? () #50 0xffffffffb1922b58 in ?? () #51 0xffffff007b9ed720 in ?? () #52 0xffffffff802b4856 in sched_switch (td=0xffffff00009d35a0, newtd=0x0, flags=0) at /usr/src/sys/kern/sched_4bsd.c:973 #53 0x0000000000000000 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x0000000000000000 in ?? () #57 0x0000000000000000 in ?? () #58 0x0000000000000000 in ?? () #59 0x0000000000000000 in ?? () ---Type to continue, or q to quit--- #60 0x0000000000000000 in ?? () #61 0x0000000000000000 in ?? () #62 0x0000000000000000 in ?? () #63 0x0000000000000000 in ?? () #64 0x0000000000000000 in ?? () #65 0x0000000000000000 in ?? () #66 0x0000000000000000 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000000 in ?? () #69 0x0000000000000000 in ?? () #70 0x0000000000000000 in ?? () #71 0x0000000000000000 in ?? () #72 0x0000000000000000 in ?? () #73 0x0000000000000000 in ?? () #74 0x0000000000000000 in ?? () #75 0x0000000000000000 in ?? () #76 0x0000000000000000 in ?? () #77 0x0000000000000000 in ?? () #78 0x0000000000000000 in ?? () #79 0x0000000000000000 in ?? () #80 0x0000000000000000 in ?? () #81 0x0000000000000000 in ?? () #82 0x0000000000000000 in ?? () #83 0x0000000000000000 in ?? () #84 0x0000000000000000 in ?? () #85 0x0000000000000000 in ?? () #86 0x0000000000000000 in ?? () #87 0x0000000000000000 in ?? () #88 0x0000000000000000 in ?? () #89 0x0000000000000000 in ?? () #90 0x0000000000000000 in ?? () #91 0x0000000000000000 in ?? () #92 0x0000000000000000 in ?? () #93 0x0000000000000000 in ?? () #94 0x0000000000000000 in ?? () #95 0x0000000000000000 in ?? () #96 0x0000000000000000 in ?? () #97 0x0000000000000000 in ?? () #98 0x0000000000000000 in ?? () #99 0x0000000000000000 in ?? () #100 0x0000000000000000 in ?? () #101 0x0000000000000000 in ?? () #102 0x0000000000000000 in ?? () #103 0x0000000000000000 in ?? () #104 0x0000000000000000 in ?? () #105 0x0000000000000000 in ?? () #106 0x0000000000000000 in ?? () #107 0x0000000000000000 in ?? () #108 0x0000000000000000 in ?? () #109 0x0000000000000000 in ?? () #110 0x0000000000000000 in ?? () #111 0x0000000000000000 in ?? () #112 0x0000000000000000 in ?? () #113 0x0000000000000000 in ?? () #114 0x0000000000000000 in ?? () #115 0x0000000000000000 in ?? () #116 0x0000000000000000 in ?? () #117 0x0000000000000000 in ?? () #118 0x0000000000000000 in ?? () #119 0x0000000000000000 in ?? () #120 0x0000000000000000 in ?? () #121 0x0000000000000000 in ?? () #122 0x0000000000000000 in ?? () ---Type to continue, or q to quit--- #123 0x0000000000000000 in ?? () #124 0x0000000000000000 in ?? () Cannot access memory at address 0xffffffffb1923000 (kgdb) frame 8 #8 0xffffffff801ef0f6 in bce_intr (xsc=0x0) at /usr/src/sys/dev/bce/if_bce.c:3970 3970 DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)), (kgdb) list 3965 3966 /* The mbuf is stored with the last rx_bd entry of a packet. */ 3967 if (sc->rx_mbuf_ptr[sw_chain_cons] != NULL) { 3968 3969 /* Validate that this is the last rx_bd. */ 3970 DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)), 3971 BCE_PRINTF("%s(%d): Unexpected mbuf found in rx_bd[0x%04X]!\n", 3972 __FILE__, __LINE__, sw_chain_cons); 3973 bce_breakpoint(sc)); 3974 (kgdb) root@sultan '10:50:15' '/var/crash' > $ sysctl dev.bce.0 dev.bce.0.%desc: Broadcom NetXtreme II BCM5708 1000Base-T (B2) dev.bce.0.%driver: bce dev.bce.0.%location: slot=0 function=0 dev.bce.0.%pnpinfo: vendor=0x14e4 device=0x164c subvendor=0x1028 subdevice=0x01b3 class=0x020000 dev.bce.0.%parent: pci9 dev.bce.0.rx_low_watermark: 0 dev.bce.0.tx_hi_watermark: 510 dev.bce.0.l2fhdr_status_errors: 0 dev.bce.0.unexpected_attentions: 0 dev.bce.0.lost_status_block_updates: 0 dev.bce.0.mbuf_alloc_failed: 0 dev.bce.0.stat_IfHcInOctets: 306538083283 dev.bce.0.stat_IfHCInBadOctets: 54437647 dev.bce.0.stat_IfHCOutOctets: 3416768690 dev.bce.0.stat_IfHCOutBadOctets: 0 dev.bce.0.stat_IfHCInUcastPkts: 76567319 dev.bce.0.stat_IfHCInMulticastPkts: 0 dev.bce.0.stat_IfHCInBroadcastPkts: 44564 dev.bce.0.stat_IfHCOutUcastPkts: 44874071 dev.bce.0.stat_IfHCOutMulticastPkts: 0 dev.bce.0.stat_IfHCOutBroadcastPkts: 200 dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 dev.bce.0.stat_Dot3StatsFCSErrors: 0 dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 dev.bce.0.stat_Dot3StatsSingleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 dev.bce.0.stat_Dot3StatsLateCollisions: 0 dev.bce.0.stat_EtherStatsCollisions: 0 dev.bce.0.stat_EtherStatsFragments: 0 dev.bce.0.stat_EtherStatsJabbers: 0 dev.bce.0.stat_EtherStatsUndersizePkts: 0 dev.bce.0.stat_EtherStatsOverrsizePkts: 0 dev.bce.0.stat_EtherStatsPktsRx64Octets: 7255 dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 3084173 dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 548353 dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 70953 dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 7546 dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 3221 dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 72890382 dev.bce.0.stat_EtherStatsPktsTx64Octets: 277 dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 42379729 dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 2485130 dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 727 dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 709 dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 853 dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 6846 dev.bce.0.stat_XonPauseFramesReceived: 0 dev.bce.0.stat_XoffPauseFramesReceived: 0 dev.bce.0.stat_OutXonSent: 0 dev.bce.0.stat_OutXoffSent: 0 dev.bce.0.stat_FlowControlDone: 0 dev.bce.0.stat_MacControlFramesReceived: 0 dev.bce.0.stat_XoffStateEntered: 0 dev.bce.0.stat_IfInFramesL2FilterDiscards: 351690 dev.bce.0.stat_IfInRuleCheckerDiscards: 0 dev.bce.0.stat_IfInFTQDiscards: 0 dev.bce.0.stat_IfInMBUFDiscards: 0 dev.bce.0.stat_IfInRuleCheckerP4Hit: 44564 dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 dev.bce.0.stat_CatchupInFTQDiscards: 0 dev.bce.0.stat_CatchupInMBUFDiscards: 0 dev.bce.0.stat_CatchupInRuleCheckerP4Hit: 0 dev.bce.0.com_no_bufers: 0 dev.bce.0.driver_state: -1 dev.bce.0.hw_state: -1 dev.bce.0.dump_rx_chain: -1 dev.bce.0.dump_tx_chain: -1 dev.bce.0.breakpoint: -1 dev.bce.0.reg_read: -1 --------------030907020009000402030006 Content-Type: text/x-patch; name="bce_patch.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bce_patch.diff" Index: if_bce.c =================================================================== --- if_bce.c (.../trunk/6_2/sys/dev/bce) (revision 55) +++ if_bce.c (.../branches/mintel_6_2/sys/dev/bce) (revision 55) @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2006 Broadcom Corporation + * Copyright (c) 2006-2007 Broadcom Corporation * David Christensen . All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -29,12 +29,12 @@ */ #include -__FBSDID("$FreeBSD: src/sys/dev/bce/if_bce.c,v 1.2.2.6.2.1 2006/11/28 17:14:07 scottl Exp $"); +__FBSDID("$FreeBSD: src/sys/dev/bce/if_bce.c,v 1.2.2.15 2007/06/05 01:56:08 davidch Exp $"); /* * The following controllers are supported by this driver: * BCM5706C A2, A3 - * BCM5708C B1 + * BCM5708C B1, B2 * * The following controllers are not supported by this driver: * (These are not "Production" versions of the controller.) @@ -42,7 +42,7 @@ * BCM5706C A0, A1 * BCM5706S A0, A1, A2, A3 * BCM5708C A0, B0 - * BCM5708S A0, B0, B1 + * BCM5708S A0, B0, B1, B2 */ #include "opt_bce.h" @@ -51,12 +51,6 @@ #include /****************************************************************************/ -/* BCE Driver Version */ -/****************************************************************************/ -char bce_driver_version[] = "v0.9.6"; - - -/****************************************************************************/ /* BCE Debug Options */ /****************************************************************************/ #ifdef BCE_DEBUG @@ -116,8 +110,8 @@ "Broadcom NetXtreme II BCM5708 1000Base-T" }, /* BCM5708S controllers and OEM boards. */ - { BRCM_VENDORID, BRCM_DEVICEID_BCM5708, PCI_ANY_ID, PCI_ANY_ID, - "Broadcom NetXtreme II BCM5708 1000Base-T" }, + { BRCM_VENDORID, BRCM_DEVICEID_BCM5708S, PCI_ANY_ID, PCI_ANY_ID, + "Broadcom NetXtreme II BCM5708S 1000Base-T" }, { 0, 0, 0, 0, NULL } }; @@ -303,8 +297,9 @@ static void bce_start_locked (struct ifnet *); static void bce_start (struct ifnet *); static int bce_ioctl (struct ifnet *, u_long, caddr_t); -static void bce_watchdog (struct ifnet *); +static void bce_watchdog (struct bce_softc *); static int bce_ifmedia_upd (struct ifnet *); +static void bce_ifmedia_upd_locked (struct ifnet *); static void bce_ifmedia_sts (struct ifnet *, struct ifmediareq *); static void bce_init_locked (struct bce_softc *); static void bce_init (void *); @@ -326,7 +321,6 @@ static void bce_intr (void *); static void bce_set_rx_mode (struct bce_softc *); static void bce_stats_update (struct bce_softc *); -static void bce_tick_locked (struct bce_softc *); static void bce_tick (void *); static void bce_add_sysctls (struct bce_softc *); @@ -416,11 +410,10 @@ return(ENOMEM); /* Print out the device identity. */ - snprintf(descbuf, BCE_DEVDESC_MAX, "%s (%c%d), %s", + snprintf(descbuf, BCE_DEVDESC_MAX, "%s (%c%d)", t->bce_name, (((pci_read_config(dev, PCIR_REVID, 4) & 0xf0) >> 4) + 'A'), - (pci_read_config(dev, PCIR_REVID, 4) & 0xf), - bce_driver_version); + (pci_read_config(dev, PCIR_REVID, 4) & 0xf)); device_set_desc_copy(dev, descbuf); free(descbuf, M_TEMP); @@ -473,7 +466,7 @@ RF_ACTIVE | PCI_RF_DENSE); /* flags */ if (sc->bce_res == NULL) { - BCE_PRINTF(sc, "%s(%d): PCI memory allocation failed\n", + BCE_PRINTF("%s(%d): PCI memory allocation failed\n", __FILE__, __LINE__); rc = ENXIO; goto bce_attach_fail; @@ -484,13 +477,12 @@ sc->bce_bhandle = rman_get_bushandle(sc->bce_res); sc->bce_vhandle = (vm_offset_t) rman_get_virtual(sc->bce_res); - /* Allocate PCI IRQ resources. */ rid = 0; sc->bce_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, RF_SHAREABLE | RF_ACTIVE); if (sc->bce_irq == NULL) { - BCE_PRINTF(sc, "%s(%d): PCI map interrupt failed\n", + BCE_PRINTF("%s(%d): PCI map interrupt failed\n", __FILE__, __LINE__); rc = ENXIO; goto bce_attach_fail; @@ -518,7 +510,7 @@ case BCE_CHIP_ID_5706_A1: case BCE_CHIP_ID_5708_A0: case BCE_CHIP_ID_5708_B0: - BCE_PRINTF(sc, "%s(%d): Unsupported controller revision (%c%d)!\n", + BCE_PRINTF("%s(%d): Unsupported controller revision (%c%d)!\n", __FILE__, __LINE__, (((pci_read_config(dev, PCIR_REVID, 4) & 0xf0) >> 4) + 'A'), (pci_read_config(dev, PCIR_REVID, 4) & 0xf)); @@ -526,13 +518,6 @@ goto bce_attach_fail; } - if (BCE_CHIP_BOND_ID(sc) & BCE_CHIP_BOND_ID_SERDES_BIT) { - BCE_PRINTF(sc, "%s(%d): SerDes controllers are not supported!\n", - __FILE__, __LINE__); - rc = ENODEV; - goto bce_attach_fail; - } - /* * The embedded PCIe to PCI-X bridge (EPB) * in the 5708 cannot address memory above @@ -605,7 +590,7 @@ if (val & BCE_PCICFG_MISC_STATUS_32BIT_DET) sc->bce_flags |= BCE_PCI_32BIT_FLAG; - BCE_PRINTF(sc, "ASIC ID 0x%08X; Revision (%c%d); PCI%s %s %dMHz\n", + BCE_PRINTF("ASIC ID 0x%08X; Revision (%c%d); PCI%s %s %dMHz\n", sc->bce_chipid, ((BCE_CHIP_ID(sc) & 0xf000) >> 12) + 'A', ((BCE_CHIP_ID(sc) & 0x0ff0) >> 4), @@ -621,7 +606,7 @@ /* Initialize the controller. */ if (bce_chipinit(sc)) { - BCE_PRINTF(sc, "%s(%d): Controller initialization failed!\n", + BCE_PRINTF("%s(%d): Controller initialization failed!\n", __FILE__, __LINE__); rc = ENXIO; goto bce_attach_fail; @@ -629,7 +614,7 @@ /* Perform NVRAM test. */ if (bce_nvram_test(sc)) { - BCE_PRINTF(sc, "%s(%d): NVRAM test failed!\n", + BCE_PRINTF("%s(%d): NVRAM test failed!\n", __FILE__, __LINE__); rc = ENXIO; goto bce_attach_fail; @@ -695,7 +680,7 @@ /* Allocate DMA memory resources. */ if (bce_dma_alloc(dev)) { - BCE_PRINTF(sc, "%s(%d): DMA resource allocation failed!\n", + BCE_PRINTF("%s(%d): DMA resource allocation failed!\n", __FILE__, __LINE__); rc = ENXIO; goto bce_attach_fail; @@ -704,7 +689,7 @@ /* Allocate an ifnet structure. */ ifp = sc->bce_ifp = if_alloc(IFT_ETHER); if (ifp == NULL) { - BCE_PRINTF(sc, "%s(%d): Interface allocation failed!\n", + BCE_PRINTF("%s(%d): Interface allocation failed!\n", __FILE__, __LINE__); rc = ENXIO; goto bce_attach_fail; @@ -716,8 +701,6 @@ ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_ioctl = bce_ioctl; ifp->if_start = bce_start; - ifp->if_timer = 0; - ifp->if_watchdog = bce_watchdog; ifp->if_init = bce_init; ifp->if_mtu = ETHERMTU; ifp->if_hwassist = BCE_IF_HWASSIST; @@ -739,20 +722,13 @@ IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); IFQ_SET_READY(&ifp->if_snd); - if (sc->bce_phy_flags & BCE_PHY_SERDES_FLAG) { - BCE_PRINTF(sc, "%s(%d): SerDes is not supported by this driver!\n", + /* Look for our PHY. */ + if (mii_phy_probe(dev, &sc->bce_miibus, bce_ifmedia_upd, + bce_ifmedia_sts)) { + BCE_PRINTF("%s(%d): PHY probe failed!\n", __FILE__, __LINE__); - rc = ENODEV; + rc = ENXIO; goto bce_attach_fail; - } else { - /* Look for our PHY. */ - if (mii_phy_probe(dev, &sc->bce_miibus, bce_ifmedia_upd, - bce_ifmedia_sts)) { - BCE_PRINTF(sc, "%s(%d): PHY probe failed!\n", - __FILE__, __LINE__); - rc = ENXIO; - goto bce_attach_fail; - } } /* Attach to the Ethernet interface list. */ @@ -761,7 +737,7 @@ #if __FreeBSD_version < 500000 callout_init(&sc->bce_stat_ch); #else - callout_init(&sc->bce_stat_ch, CALLOUT_MPSAFE); + callout_init_mtx(&sc->bce_stat_ch, &sc->bce_mtx, 0); #endif /* Hookup IRQ last. */ @@ -769,7 +745,7 @@ bce_intr, sc, &sc->bce_intrhand); if (rc) { - BCE_PRINTF(sc, "%s(%d): Failed to setup IRQ!\n", + BCE_PRINTF("%s(%d): Failed to setup IRQ!\n", __FILE__, __LINE__); bce_detach(dev); goto bce_attach_exit; @@ -833,12 +809,8 @@ ether_ifdetach(ifp); /* If we have a child device on the MII bus remove it too. */ - if (sc->bce_phy_flags & BCE_PHY_SERDES_FLAG) { - ifmedia_removeall(&sc->bce_ifmedia); - } else { - bus_generic_detach(dev); - device_delete_child(dev, sc->bce_miibus); - } + bus_generic_detach(dev); + device_delete_child(dev, sc->bce_miibus); /* Release all remaining resources. */ bce_release_resources(sc); @@ -999,7 +971,7 @@ } if (val & BCE_EMAC_MDIO_COMM_START_BUSY) { - BCE_PRINTF(sc, "%s(%d): Error: PHY read timeout! phy = %d, reg = 0x%04X\n", + BCE_PRINTF("%s(%d): Error: PHY read timeout! phy = %d, reg = 0x%04X\n", __FILE__, __LINE__, phy, reg); val = 0x0; } else { @@ -1076,7 +1048,7 @@ } if (val1 & BCE_EMAC_MDIO_COMM_START_BUSY) - BCE_PRINTF(sc, "%s(%d): PHY write timeout!\n", + BCE_PRINTF("%s(%d): PHY write timeout!\n", __FILE__, __LINE__); if (sc->bce_phy_flags & BCE_PHY_INT_MODE_AUTO_POLLING_FLAG) { @@ -1115,7 +1087,8 @@ BCE_CLRBIT(sc, BCE_EMAC_MODE, BCE_EMAC_MODE_PORT); /* Set MII or GMII inerface based on the speed negotiated by the PHY. */ - if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T) { + if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T || + IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_SX) { DBPRINT(sc, BCE_INFO, "Setting GMII interface.\n"); BCE_SETBIT(sc, BCE_EMAC_MODE, BCE_EMAC_MODE_PORT_GMII); } else { @@ -1429,7 +1402,7 @@ /* Check for errors. */ if (i >= NVRAM_TIMEOUT_COUNT) { - BCE_PRINTF(sc, "%s(%d): Timeout error reading NVRAM at offset 0x%08X!\n", + BCE_PRINTF("%s(%d): Timeout error reading NVRAM at offset 0x%08X!\n", __FILE__, __LINE__, offset); rc = EBUSY; } @@ -1485,7 +1458,7 @@ break; } if (j >= NVRAM_TIMEOUT_COUNT) { - BCE_PRINTF(sc, "%s(%d): Timeout error writing NVRAM at offset 0x%08X\n", + BCE_PRINTF("%s(%d): Timeout error writing NVRAM at offset 0x%08X\n", __FILE__, __LINE__, offset); return EBUSY; } @@ -1582,7 +1555,7 @@ /* Check if a matching device was found. */ if (j == entry_count) { sc->bce_flash_info = NULL; - BCE_PRINTF(sc, "%s(%d): Unknown Flash NVRAM found!\n", + BCE_PRINTF("%s(%d): Unknown Flash NVRAM found!\n", __FILE__, __LINE__); rc = ENODEV; } @@ -1940,7 +1913,7 @@ magic = bce_be32toh(buf[0]); if (magic != BCE_NVRAM_MAGIC) { rc = ENODEV; - BCE_PRINTF(sc, "%s(%d): Invalid NVRAM magic value! Expected: 0x%08X, " + BCE_PRINTF("%s(%d): Invalid NVRAM magic value! Expected: 0x%08X, " "Found: 0x%08X\n", __FILE__, __LINE__, BCE_NVRAM_MAGIC, magic); goto bce_nvram_test_done; @@ -1956,7 +1929,7 @@ csum = ether_crc32_le(data, 0x100); if (csum != BCE_CRC32_RESIDUAL) { rc = ENODEV; - BCE_PRINTF(sc, "%s(%d): Invalid Manufacturing Information NVRAM CRC! " + BCE_PRINTF("%s(%d): Invalid Manufacturing Information NVRAM CRC! " "Expected: 0x%08X, Found: 0x%08X\n", __FILE__, __LINE__, BCE_CRC32_RESIDUAL, csum); goto bce_nvram_test_done; @@ -1964,7 +1937,7 @@ csum = ether_crc32_le(data + 0x100, 0x100); if (csum != BCE_CRC32_RESIDUAL) { - BCE_PRINTF(sc, "%s(%d): Invalid Feature Configuration Information " + BCE_PRINTF("%s(%d): Invalid Feature Configuration Information " "NVRAM CRC! Expected: 0x%08X, Found: 08%08X\n", __FILE__, __LINE__, BCE_CRC32_RESIDUAL, csum); rc = ENODEV; @@ -2188,7 +2161,7 @@ NULL, /* locfunc */ NULL, /* lockarg */ &sc->parent_tag)) { - BCE_PRINTF(sc, "%s(%d): Could not allocate parent DMA tag!\n", + BCE_PRINTF("%s(%d): Could not allocate parent DMA tag!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2214,7 +2187,7 @@ NULL, /* lockfunc */ NULL, /* lockarg */ &sc->status_tag)) { - BCE_PRINTF(sc, "%s(%d): Could not allocate status block DMA tag!\n", + BCE_PRINTF("%s(%d): Could not allocate status block DMA tag!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2225,7 +2198,7 @@ (void **)&sc->status_block, /* vaddr */ BUS_DMA_NOWAIT, /* flags */ &sc->status_map)) { - BCE_PRINTF(sc, "%s(%d): Could not allocate status block DMA memory!\n", + BCE_PRINTF("%s(%d): Could not allocate status block DMA memory!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2243,7 +2216,7 @@ BUS_DMA_NOWAIT); /* flags */ if (error) { - BCE_PRINTF(sc, "%s(%d): Could not map status block DMA memory!\n", + BCE_PRINTF("%s(%d): Could not map status block DMA memory!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2274,7 +2247,7 @@ NULL, /* lockfunc */ NULL, /* lockarg */ &sc->stats_tag)) { - BCE_PRINTF(sc, "%s(%d): Could not allocate statistics block DMA tag!\n", + BCE_PRINTF("%s(%d): Could not allocate statistics block DMA tag!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2285,7 +2258,7 @@ (void **)&sc->stats_block, /* vaddr */ BUS_DMA_NOWAIT, /* flags */ &sc->stats_map)) { - BCE_PRINTF(sc, "%s(%d): Could not allocate statistics block DMA memory!\n", + BCE_PRINTF("%s(%d): Could not allocate statistics block DMA memory!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2303,7 +2276,7 @@ BUS_DMA_NOWAIT); /* flags */ if(error) { - BCE_PRINTF(sc, "%s(%d): Could not map statistics block DMA memory!\n", + BCE_PRINTF("%s(%d): Could not map statistics block DMA memory!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2334,7 +2307,7 @@ NULL, /* lockfunc */ NULL, /* lockarg */ &sc->tx_bd_chain_tag)) { - BCE_PRINTF(sc, "%s(%d): Could not allocate TX descriptor chain DMA tag!\n", + BCE_PRINTF("%s(%d): Could not allocate TX descriptor chain DMA tag!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2347,7 +2320,7 @@ (void **)&sc->tx_bd_chain[i], /* vaddr */ BUS_DMA_NOWAIT, /* flags */ &sc->tx_bd_chain_map[i])) { - BCE_PRINTF(sc, "%s(%d): Could not allocate TX descriptor " + BCE_PRINTF("%s(%d): Could not allocate TX descriptor " "chain DMA memory!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2363,7 +2336,7 @@ BUS_DMA_NOWAIT); /* flags */ if (error) { - BCE_PRINTF(sc, "%s(%d): Could not map TX descriptor chain DMA memory!\n", + BCE_PRINTF("%s(%d): Could not map TX descriptor chain DMA memory!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2391,7 +2364,7 @@ NULL, /* lockfunc */ NULL, /* lockarg */ &sc->tx_mbuf_tag)) { - BCE_PRINTF(sc, "%s(%d): Could not allocate TX mbuf DMA tag!\n", + BCE_PRINTF("%s(%d): Could not allocate TX mbuf DMA tag!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2401,7 +2374,7 @@ for (i = 0; i < TOTAL_TX_BD; i++) { if (bus_dmamap_create(sc->tx_mbuf_tag, BUS_DMA_NOWAIT, &sc->tx_mbuf_map[i])) { - BCE_PRINTF(sc, "%s(%d): Unable to create TX mbuf DMA map!\n", + BCE_PRINTF("%s(%d): Unable to create TX mbuf DMA map!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2428,7 +2401,7 @@ NULL, /* lockfunc */ NULL, /* lockarg */ &sc->rx_bd_chain_tag)) { - BCE_PRINTF(sc, "%s(%d): Could not allocate RX descriptor chain DMA tag!\n", + BCE_PRINTF("%s(%d): Could not allocate RX descriptor chain DMA tag!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2441,7 +2414,7 @@ (void **)&sc->rx_bd_chain[i], /* vaddr */ BUS_DMA_NOWAIT, /* flags */ &sc->rx_bd_chain_map[i])) { - BCE_PRINTF(sc, "%s(%d): Could not allocate RX descriptor chain " + BCE_PRINTF("%s(%d): Could not allocate RX descriptor chain " "DMA memory!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2459,7 +2432,7 @@ BUS_DMA_NOWAIT); /* flags */ if (error) { - BCE_PRINTF(sc, "%s(%d): Could not map RX descriptor chain DMA memory!\n", + BCE_PRINTF("%s(%d): Could not map RX descriptor chain DMA memory!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2489,7 +2462,7 @@ NULL, /* lockfunc */ NULL, /* lockarg */ &sc->rx_mbuf_tag)) { - BCE_PRINTF(sc, "%s(%d): Could not allocate RX mbuf DMA tag!\n", + BCE_PRINTF("%s(%d): Could not allocate RX mbuf DMA tag!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2499,7 +2472,7 @@ for (i = 0; i < TOTAL_RX_BD; i++) { if (bus_dmamap_create(sc->rx_mbuf_tag, BUS_DMA_NOWAIT, &sc->rx_mbuf_map[i])) { - BCE_PRINTF(sc, "%s(%d): Unable to create RX mbuf DMA map!\n", + BCE_PRINTF("%s(%d): Unable to create RX mbuf DMA map!\n", __FILE__, __LINE__); rc = ENOMEM; goto bce_dma_alloc_exit; @@ -2603,7 +2576,7 @@ if (((val & BCE_FW_MSG_ACK) != (msg_data & BCE_DRV_MSG_SEQ)) && ((msg_data & BCE_DRV_MSG_DATA) != BCE_DRV_MSG_DATA_WAIT0)) { - BCE_PRINTF(sc, "%s(%d): Firmware synchronization timeout! " + BCE_PRINTF("%s(%d): Firmware synchronization timeout! " "msg_data = 0x%08X\n", __FILE__, __LINE__, msg_data); @@ -3015,7 +2988,7 @@ BCE_PORT_HW_CFG_MAC_LOWER); if ((mac_lo == 0) && (mac_hi == 0)) { - BCE_PRINTF(sc, "%s(%d): Invalid Ethernet address!\n", + BCE_PRINTF("%s(%d): Invalid Ethernet address!\n", __FILE__, __LINE__); } else { sc->eaddr[0] = (u_char)(mac_hi >> 8); @@ -3115,7 +3088,7 @@ } ifp->if_flags = itmp; - ifp->if_timer = 0; + sc->watchdog_timer = 0; sc->bce_link = 0; @@ -3178,7 +3151,7 @@ /* Check that reset completed successfully. */ if (val & (BCE_PCICFG_MISC_CONFIG_CORE_RST_REQ | BCE_PCICFG_MISC_CONFIG_CORE_RST_BSY)) { - BCE_PRINTF(sc, "%s(%d): Reset failed!\n", + BCE_PRINTF("%s(%d): Reset failed!\n", __FILE__, __LINE__); rc = EBUSY; goto bce_reset_exit; @@ -3187,7 +3160,7 @@ /* Make sure byte swapping is properly configured. */ val = REG_RD(sc, BCE_PCI_SWAP_DIAG0); if (val != 0x01020304) { - BCE_PRINTF(sc, "%s(%d): Byte swap is incorrect!\n", + BCE_PRINTF("%s(%d): Byte swap is incorrect!\n", __FILE__, __LINE__); rc = ENODEV; goto bce_reset_exit; @@ -3199,7 +3172,7 @@ /* Wait for the firmware to finish its initialization. */ rc = bce_fw_sync(sc, BCE_DRV_MSG_DATA_WAIT1 | reset_code); if (rc) - BCE_PRINTF(sc, "%s(%d): Firmware did not complete initialization!\n", + BCE_PRINTF("%s(%d): Firmware did not complete initialization!\n", __FILE__, __LINE__); bce_reset_exit: @@ -3284,6 +3257,7 @@ REG_WR(sc, BCE_MQ_KNL_BYP_WIND_START, val); REG_WR(sc, BCE_MQ_KNL_WIND_END, val); + /* Set the page size and clear the RV2P processor stall bits. */ val = (BCM_PAGE_BITS - 8) << 24; REG_WR(sc, BCE_RV2P_CONFIG, val); @@ -3371,13 +3345,13 @@ reg = REG_RD_IND(sc, sc->bce_shmem_base + BCE_DEV_INFO_SIGNATURE); DBRUNIF(DB_RANDOMTRUE(bce_debug_bootcode_running_failure), - BCE_PRINTF(sc, "%s(%d): Simulating bootcode failure.\n", + BCE_PRINTF("%s(%d): Simulating bootcode failure.\n", __FILE__, __LINE__); reg = 0); if ((reg & BCE_DEV_INFO_SIGNATURE_MAGIC_MASK) != BCE_DEV_INFO_SIGNATURE_MAGIC) { - BCE_PRINTF(sc, "%s(%d): Bootcode not running! Found: 0x%08X, " + BCE_PRINTF("%s(%d): Bootcode not running! Found: 0x%08X, " "Expected: 08%08X\n", __FILE__, __LINE__, (reg & BCE_DEV_INFO_SIGNATURE_MAGIC_MASK), BCE_DEV_INFO_SIGNATURE_MAGIC); @@ -3441,7 +3415,7 @@ /* Make sure the inputs are valid. */ DBRUNIF((*chain_prod > MAX_RX_BD), - BCE_PRINTF(sc, "%s(%d): RX producer out of range: 0x%04X > 0x%04X\n", + BCE_PRINTF("%s(%d): RX producer out of range: 0x%04X > 0x%04X\n", __FILE__, __LINE__, *chain_prod, (u16) MAX_RX_BD)); DBPRINT(sc, BCE_VERBOSE_RECV, "%s(enter): prod = 0x%04X, chain_prod = 0x%04X, " @@ -3450,7 +3424,7 @@ if (m == NULL) { DBRUNIF(DB_RANDOMTRUE(bce_debug_mbuf_allocation_failure), - BCE_PRINTF(sc, "%s(%d): Simulating mbuf allocation failure.\n", + BCE_PRINTF("%s(%d): Simulating mbuf allocation failure.\n", __FILE__, __LINE__); sc->mbuf_alloc_failed++; rc = ENOBUFS; @@ -3498,7 +3472,7 @@ segs, &nsegs, BUS_DMA_NOWAIT); if (error) { - BCE_PRINTF(sc, "%s(%d): Error mapping mbuf into RX chain!\n", + BCE_PRINTF("%s(%d): Error mapping mbuf into RX chain!\n", __FILE__, __LINE__); m_freem(m_new); @@ -3511,7 +3485,7 @@ /* Watch for overflow. */ DBRUNIF((sc->free_rx_bd > USABLE_RX_BD), - BCE_PRINTF(sc, "%s(%d): Too many free rx_bd (0x%04X > 0x%04X)!\n", + BCE_PRINTF("%s(%d): Too many free rx_bd (0x%04X > 0x%04X)!\n", __FILE__, __LINE__, sc->free_rx_bd, (u16) USABLE_RX_BD)); DBRUNIF((sc->free_rx_bd < sc->rx_low_watermark), @@ -3663,7 +3637,7 @@ /* Check if we lost any mbufs in the process. */ DBRUNIF((sc->tx_mbuf_alloc), - BCE_PRINTF(sc, "%s(%d): Memory leak! Lost %d mbufs " + BCE_PRINTF("%s(%d): Memory leak! Lost %d mbufs " "from tx chain!\n", __FILE__, __LINE__, sc->tx_mbuf_alloc)); @@ -3728,7 +3702,7 @@ while (prod < BCE_RX_SLACK_SPACE) { chain_prod = RX_CHAIN_IDX(prod); if (bce_get_buf(sc, NULL, &prod, &chain_prod, &prod_bseq)) { - BCE_PRINTF(sc, "%s(%d): Error filling RX chain: rx_bd[0x%04X]!\n", + BCE_PRINTF("%s(%d): Error filling RX chain: rx_bd[0x%04X]!\n", __FILE__, __LINE__, chain_prod); rc = ENOBUFS; break; @@ -3790,7 +3764,7 @@ /* Check if we lost any mbufs in the process. */ DBRUNIF((sc->rx_mbuf_alloc), - BCE_PRINTF(sc, "%s(%d): Memory leak! Lost %d mbufs from rx chain!\n", + BCE_PRINTF("%s(%d): Memory leak! Lost %d mbufs from rx chain!\n", __FILE__, __LINE__, sc->rx_mbuf_alloc)); DBPRINT(sc, BCE_VERBOSE_RESET, "Exiting %s()\n", __FUNCTION__); @@ -3807,26 +3781,38 @@ bce_ifmedia_upd(struct ifnet *ifp) { struct bce_softc *sc; + + sc = ifp->if_softc; + BCE_LOCK(sc); + bce_ifmedia_upd_locked(ifp); + BCE_UNLOCK(sc); + return (0); +} + +static void +bce_ifmedia_upd_locked(struct ifnet *ifp) +{ + struct bce_softc *sc; struct mii_data *mii; struct ifmedia *ifm; - int rc = 0; sc = ifp->if_softc; ifm = &sc->bce_ifmedia; + BCE_LOCK_ASSERT(sc); - /* DRC - ToDo: Add SerDes support. */ + mii = device_get_softc(sc->bce_miibus); - mii = device_get_softc(sc->bce_miibus); - sc->bce_link = 0; - if (mii->mii_instance) { - struct mii_softc *miisc; - for (miisc = LIST_FIRST(&mii->mii_phys); miisc != NULL; - miisc = LIST_NEXT(miisc, mii_list)) - mii_phy_reset(miisc); + /* Make sure the MII bus has been enumerated. */ + if (mii) { + sc->bce_link = 0; + if (mii->mii_instance) { + struct mii_softc *miisc; + + LIST_FOREACH(miisc, &mii->mii_phys, mii_list) + mii_phy_reset(miisc); + } + mii_mediachg(mii); } - mii_mediachg(mii); - - return(rc); } @@ -3848,8 +3834,6 @@ mii = device_get_softc(sc->bce_miibus); - /* DRC - ToDo: Add SerDes support. */ - mii_pollstat(mii); ifmr->ifm_active = mii->mii_media_active; ifmr->ifm_status = mii->mii_media_status; @@ -3881,7 +3865,7 @@ sc->bce_link = 0; callout_stop(&sc->bce_stat_ch); - bce_tick_locked(sc); + bce_tick(sc); /* Update the status_attn_bits_ack field in the status block. */ if (new_link_state) { @@ -3956,6 +3940,9 @@ unsigned int len; u32 status; + /* Clear the MBUF pointer. */ + m = NULL; + /* Convert the producer/consumer indices to an actual rx_bd index. */ sw_chain_cons = RX_CHAIN_IDX(sw_cons); sw_chain_prod = RX_CHAIN_IDX(sw_prod); @@ -3965,7 +3952,7 @@ sc->free_rx_bd++; DBRUN(BCE_VERBOSE_RECV, - BCE_PRINTF(sc, "%s(): ", __FUNCTION__); + BCE_PRINTF("%s(): ", __FUNCTION__); bce_dump_rxbd(sc, sw_chain_cons, rxbd)); #ifdef DEVICE_POLLING @@ -3981,7 +3968,7 @@ /* Validate that this is the last rx_bd. */ DBRUNIF((!(rxbd->rx_bd_flags & RX_BD_FLAGS_END)), - BCE_PRINTF(sc, "%s(%d): Unexpected mbuf found in rx_bd[0x%04X]!\n", + BCE_PRINTF("%s(%d): Unexpected mbuf found in rx_bd[0x%04X]!\n", __FILE__, __LINE__, sw_chain_cons); bce_breakpoint(sc)); @@ -4016,17 +4003,17 @@ status = l2fhdr->l2_fhdr_status; DBRUNIF(DB_RANDOMTRUE(bce_debug_l2fhdr_status_check), - BCE_PRINTF(sc, "Simulating l2_fhdr status error.\n"); + BCE_PRINTF("Simulating l2_fhdr status error.\n"); status = status | L2_FHDR_ERRORS_PHY_DECODE); /* Watch for unusual sized frames. */ DBRUNIF(((len < BCE_MIN_MTU) || (len > BCE_MAX_JUMBO_ETHER_MTU_VLAN)), - BCE_PRINTF(sc, "%s(%d): Unusual frame size found. " + BCE_PRINTF("%s(%d): Unusual frame size found. " "Min(%d), Actual(%d), Max(%d)\n", __FILE__, __LINE__, (int) BCE_MIN_MTU, len, (int) BCE_MAX_JUMBO_ETHER_MTU_VLAN); - bce_dump_mbuf(sc, m); - bce_breakpoint(sc)); + bce_dump_mbuf(sc, m)); +// bce_breakpoint(sc)); len -= ETHER_CRC_LEN; @@ -4057,7 +4044,7 @@ if (bce_get_buf(sc, NULL, &sw_prod, &sw_chain_prod, &sw_prod_bseq)) { DBRUN(BCE_WARN, - BCE_PRINTF(sc, "%s(%d): Failed to allocate " + BCE_PRINTF("%s(%d): Failed to allocate " "new mbuf, incoming frame dropped!\n", __FILE__, __LINE__)); @@ -4085,7 +4072,7 @@ DBRUN(BCE_VERBOSE_RECV, struct ether_header *eh; eh = mtod(m, struct ether_header *); - BCE_PRINTF(sc, "%s(): to: %6D, from: %6D, type: 0x%04X\n", + BCE_PRINTF("%s(): to: %6D, from: %6D, type: 0x%04X\n", __FUNCTION__, eh->ether_dhost, ":", eh->ether_shost, ":", htons(eh->ether_type))); @@ -4142,19 +4129,35 @@ /* Pass the mbuf off to the upper layers. */ ifp->if_ipackets++; + +bce_rx_int_next_rx: + sw_prod = NEXT_RX_BD(sw_prod); + } + + sw_cons = NEXT_RX_BD(sw_cons); + + /* If we have a packet, pass it up the stack. */ + if (m) { + sc->rx_cons = sw_cons; + sc->rx_prod = sw_prod; + sc->rx_prod_bseq = sw_prod_bseq; + DBPRINT(sc, BCE_VERBOSE_RECV, "%s(): Passing received frame up.\n", __FUNCTION__); BCE_UNLOCK(sc); (*ifp->if_input)(ifp, m); DBRUNIF(1, sc->rx_mbuf_alloc--); BCE_LOCK(sc); - -bce_rx_int_next_rx: - sw_prod = NEXT_RX_BD(sw_prod); + + /* Recover our place. */ + sw_cons = sc->rx_cons; + sw_prod = sc->rx_prod; + sw_prod_bseq = sc->rx_prod_bseq; + hw_cons = sc->hw_rx_cons = sblk->status_rx_quick_consumer_index0; + if ((hw_cons & USABLE_RX_BD_PER_PAGE) == USABLE_RX_BD_PER_PAGE) + hw_cons++; } - sw_cons = NEXT_RX_BD(sw_cons); - /* Refresh hw_cons to see if there's new work */ if (sw_cons == hw_cons) { hw_cons = sc->hw_rx_cons = sblk->status_rx_quick_consumer_index0; @@ -4227,7 +4230,7 @@ __FUNCTION__, hw_tx_cons, sw_tx_cons, sw_tx_chain_cons); DBRUNIF((sw_tx_chain_cons > MAX_TX_BD), - BCE_PRINTF(sc, "%s(%d): TX chain consumer out of range! " + BCE_PRINTF("%s(%d): TX chain consumer out of range! " " 0x%04X > 0x%04X\n", __FILE__, __LINE__, sw_tx_chain_cons, (int) MAX_TX_BD); @@ -4238,12 +4241,12 @@ [TX_IDX(sw_tx_chain_cons)]); DBRUNIF((txbd == NULL), - BCE_PRINTF(sc, "%s(%d): Unexpected NULL tx_bd[0x%04X]!\n", + BCE_PRINTF("%s(%d): Unexpected NULL tx_bd[0x%04X]!\n", __FILE__, __LINE__, sw_tx_chain_cons); bce_breakpoint(sc)); DBRUN(BCE_INFO_SEND, - BCE_PRINTF(sc, "%s(): ", __FUNCTION__); + BCE_PRINTF("%s(): ", __FUNCTION__); bce_dump_txbd(sc, sw_tx_chain_cons, txbd)); /* @@ -4255,12 +4258,12 @@ /* Validate that this is the last tx_bd. */ DBRUNIF((!(txbd->tx_bd_flags & TX_BD_FLAGS_END)), - BCE_PRINTF(sc, "%s(%d): tx_bd END flag not set but " + BCE_PRINTF("%s(%d): tx_bd END flag not set but " "txmbuf == NULL!\n", __FILE__, __LINE__); bce_breakpoint(sc)); DBRUN(BCE_INFO_SEND, - BCE_PRINTF(sc, "%s(): Unloading map/freeing mbuf " + BCE_PRINTF("%s(): Unloading map/freeing mbuf " "from tx_bd[0x%04X]\n", __FUNCTION__, sw_tx_chain_cons)); /* Unmap the mbuf. */ @@ -4289,13 +4292,13 @@ } /* Clear the TX timeout timer. */ - ifp->if_timer = 0; + sc->watchdog_timer = 0; /* Clear the tx hardware queue full flag. */ if ((sc->used_tx_bd + BCE_TX_SLACK_SPACE) < USABLE_TX_BD) { - DBRUNIF((ifp->if_drv_flags & IFF_DRV_OACTIVE), - BCE_PRINTF(sc, "%s(): TX chain is open for business! Used tx_bd = %d\n", - __FUNCTION__, sc->used_tx_bd)); +/* DBRUNIF((ifp->if_drv_flags & IFF_DRV_OACTIVE), + BCE_PRINTF("%s(): TX chain is open for business! Used tx_bd = %d\n", + __FUNCTION__, sc->used_tx_bd)); */ ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; } @@ -4344,8 +4347,6 @@ /****************************************************************************/ /* Handles controller initialization. */ /* */ -/* Must be called from a locked routine. */ -/* */ /* Returns: */ /* Nothing. */ /****************************************************************************/ @@ -4368,19 +4369,19 @@ bce_stop(sc); if (bce_reset(sc, BCE_DRV_MSG_CODE_RESET)) { - BCE_PRINTF(sc, "%s(%d): Controller reset failed!\n", + BCE_PRINTF("%s(%d): Controller reset failed!\n", __FILE__, __LINE__); goto bce_init_locked_exit; } if (bce_chipinit(sc)) { - BCE_PRINTF(sc, "%s(%d): Controller initialization failed!\n", + BCE_PRINTF("%s(%d): Controller initialization failed!\n", __FILE__, __LINE__); goto bce_init_locked_exit; } if (bce_blockinit(sc)) { - BCE_PRINTF(sc, "%s(%d): Block initialization failed!\n", + BCE_PRINTF("%s(%d): Block initialization failed!\n", __FILE__, __LINE__); goto bce_init_locked_exit; } @@ -4440,7 +4441,7 @@ /* Enable host interrupts. */ bce_enable_intr(sc); - bce_ifmedia_upd(ifp); + bce_ifmedia_upd_locked(ifp); ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; @@ -4453,6 +4454,14 @@ return; } + +/****************************************************************************/ +/* Initialize the controller just enough so that any management firmware */ +/* running on the device will continue to operate correctly. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_mgmt_init_locked(struct bce_softc *sc) { @@ -4472,6 +4481,7 @@ /* Initialize the on-boards CPUs */ bce_init_cpus(sc); + /* Set the page size and clear the RV2P processor stall bits. */ val = (BCM_PAGE_BITS - 8) << 24; REG_WR(sc, BCE_RV2P_CONFIG, val); @@ -4483,7 +4493,7 @@ REG_RD(sc, BCE_MISC_ENABLE_SET_BITS); DELAY(20); - bce_ifmedia_upd(ifp); + bce_ifmedia_upd_locked(ifp); bce_mgmt_init_locked_exit: DBPRINT(sc, BCE_VERBOSE_RESET, "Exiting %s()\n", __FUNCTION__); @@ -4561,7 +4571,7 @@ /* Try to defrag the mbuf if there are too many segments. */ DBPRINT(sc, BCE_WARN, "%s(): fragmented mbuf (%d pieces)\n", - __FUNCTION__, map_arg.maxsegs); + __FUNCTION__, nsegs); m0 = m_defrag(*m_head, M_DONTWAIT); if (m0 == NULL) { @@ -4578,7 +4588,7 @@ if (error == ENOMEM) { return (error); } else if (error != 0) { - BCE_PRINTF(sc, + BCE_PRINTF( "%s(%d): Error mapping mbuf into TX chain!\n", __FILE__, __LINE__); m_freem(m0); @@ -4614,7 +4624,7 @@ DBPRINT(sc, BCE_INFO_SEND, "%s(): Start: prod = 0x%04X, chain_prod = %04X, " "prod_bseq = 0x%08X\n", - __FUNCTION__, *prod, chain_prod, prod_bseq); + __FUNCTION__, prod, chain_prod, prod_bseq); /* * Cycle through each mbuf segment that makes up @@ -4641,7 +4651,7 @@ /* Set the END flag on the last TX buffer descriptor. */ txbd->tx_bd_flags |= htole16(TX_BD_FLAGS_END); - DBRUN(BCE_INFO_SEND, bce_dump_tx_chain(sc, debug_prod, nseg)); + DBRUN(BCE_INFO_SEND, bce_dump_tx_chain(sc, debug_prod, nsegs)); DBPRINT(sc, BCE_INFO_SEND, "%s(): End: prod = 0x%04X, chain_prod = %04X, " @@ -4757,7 +4767,7 @@ REG_WR(sc, MB_TX_CID_ADDR + BCE_L2CTX_TX_HOST_BSEQ, sc->tx_prod_bseq); /* Set the tx timeout. */ - ifp->if_timer = BCE_TX_TIMEOUT; + sc->watchdog_timer = BCE_TX_TIMEOUT; bce_start_locked_exit: return; @@ -4866,17 +4876,10 @@ DBPRINT(sc, BCE_VERBOSE, "bce_phy_flags = 0x%08X\n", sc->bce_phy_flags); - if (sc->bce_phy_flags & BCE_PHY_SERDES_FLAG) { - DBPRINT(sc, BCE_VERBOSE, "SerDes media set/get\n"); - - error = ifmedia_ioctl(ifp, ifr, - &sc->bce_ifmedia, command); - } else { - DBPRINT(sc, BCE_VERBOSE, "Copper media set/get\n"); - mii = device_get_softc(sc->bce_miibus); - error = ifmedia_ioctl(ifp, ifr, - &mii->mii_media, command); - } + DBPRINT(sc, BCE_VERBOSE, "Copper media set/get\n"); + mii = device_get_softc(sc->bce_miibus); + error = ifmedia_ioctl(ifp, ifr, + &mii->mii_media, command); break; /* Set interface capability */ @@ -4891,7 +4894,7 @@ /* Setup the poll routine to call. */ error = ether_poll_register(bce_poll, ifp); if (error) { - BCE_PRINTF(sc, "%s(%d): Error registering poll function!\n", + BCE_PRINTF("%s(%d): Error registering poll function!\n", __FILE__, __LINE__); goto bce_ioctl_exit; } @@ -4948,18 +4951,18 @@ /* Toggle VLAN_MTU capabilities enable flag. */ if (mask & IFCAP_VLAN_MTU) { - BCE_PRINTF(sc, "%s(%d): Changing VLAN_MTU not supported.\n", + BCE_PRINTF("%s(%d): Changing VLAN_MTU not supported.\n", __FILE__, __LINE__); } /* Toggle VLANHWTAG capabilities enabled flag. */ if (mask & IFCAP_VLAN_HWTAGGING) { if (sc->bce_flags & BCE_MFW_ENABLE_FLAG) - BCE_PRINTF(sc, "%s(%d): Cannot change VLAN_HWTAGGING while " + BCE_PRINTF("%s(%d): Cannot change VLAN_HWTAGGING while " "management firmware (ASF/IPMI/UMP) is running!\n", __FILE__, __LINE__); else - BCE_PRINTF(sc, "%s(%d): Changing VLAN_HWTAGGING not supported!\n", + BCE_PRINTF("%s(%d): Changing VLAN_HWTAGGING not supported!\n", __FILE__, __LINE__); } @@ -4990,25 +4993,34 @@ /* Nothing. */ /****************************************************************************/ static void -bce_watchdog(struct ifnet *ifp) +bce_watchdog(struct bce_softc *sc) { - struct bce_softc *sc = ifp->if_softc; - DBRUN(BCE_WARN_SEND, + DBRUN(BCE_VERBOSE_SEND, bce_dump_driver_state(sc); bce_dump_status_block(sc)); - BCE_PRINTF(sc, "%s(%d): Watchdog timeout occurred, resetting!\n", + BCE_LOCK_ASSERT(sc); + + if (sc->watchdog_timer == 0 || --sc->watchdog_timer) + return; + + /* + * If we are in this routine because of pause frames, then + * don't reset the hardware. + */ + if (REG_RD(sc, BCE_EMAC_TX_STATUS) & BCE_EMAC_TX_STATUS_XOFFED) + return; + + BCE_PRINTF("%s(%d): Watchdog timeout occurred, resetting!\n", __FILE__, __LINE__); /* DBRUN(BCE_FATAL, bce_breakpoint(sc)); */ - BCE_LOCK(sc); - ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + sc->bce_ifp->if_drv_flags &= ~IFF_DRV_RUNNING; bce_init_locked(sc); - ifp->if_oerrors++; - BCE_UNLOCK(sc); + sc->bce_ifp->if_oerrors++; } @@ -5096,6 +5108,7 @@ sc = xsc; ifp = sc->bce_ifp; + DBPRINT(sc, BCE_EXCESSIVE, "Entering %s()\n", __FUNCTION__); BCE_LOCK(sc); DBRUNIF(1, sc->interrupts_generated++); @@ -5131,7 +5144,7 @@ status_attn_bits = sc->status_block->status_attn_bits; DBRUNIF(DB_RANDOMTRUE(bce_debug_unexpected_attention), - BCE_PRINTF(sc, "Simulating unexpected status attention bit set."); + BCE_PRINTF("Simulating unexpected status attention bit set."); status_attn_bits = status_attn_bits | STATUS_ATTN_BITS_PARITY_ERROR); /* Was it a link change interrupt? */ @@ -5146,7 +5159,7 @@ DBRUN(1, sc->unexpected_attentions++); - BCE_PRINTF(sc, "%s(%d): Fatal attention detected: 0x%08X\n", + BCE_PRINTF("%s(%d): Fatal attention detected: 0x%08X\n", __FILE__, __LINE__, sc->status_block->status_attn_bits); DBRUN(BCE_FATAL, @@ -5209,7 +5222,7 @@ { struct ifnet *ifp; struct ifmultiaddr *ifma; - u32 hashes[4] = { 0, 0, 0, 0 }; + u32 hashes[NUM_MC_HASH_REGISTERS] = { 0, 0, 0, 0, 0, 0, 0, 0 }; u32 rx_mode, sort_mode; int h, i; @@ -5257,12 +5270,12 @@ if (ifma->ifma_addr->sa_family != AF_LINK) continue; h = ether_crc32_le(LLADDR((struct sockaddr_dl *) - ifma->ifma_addr), ETHER_ADDR_LEN) & 0x7F; - hashes[(h & 0x60) >> 5] |= 1 << (h & 0x1F); + ifma->ifma_addr), ETHER_ADDR_LEN) & 0xFF; + hashes[(h & 0xE0) >> 5] |= 1 << (h & 0x1F); } IF_ADDR_UNLOCK(ifp); - for (i = 0; i < 4; i++) + for (i = 0; i < NUM_MC_HASH_REGISTERS; i++) REG_WR(sc, BCE_EMAC_MULTICAST_HASH0 + (i * 4), hashes[i]); sort_mode |= BCE_RPM_SORT_USER0_MC_HSH_EN; @@ -5504,14 +5517,23 @@ sc->stat_CatchupInRuleCheckerP4Hit = stats->stat_CatchupInRuleCheckerP4Hit; + sc->com_no_buffers = REG_RD_IND(sc, 0x120084); + DBPRINT(sc, BCE_EXCESSIVE, "Exiting %s()\n", __FUNCTION__); } +/****************************************************************************/ +/* Periodic function to perform maintenance tasks. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void -bce_tick_locked(struct bce_softc *sc) +bce_tick(void *xsc) { - struct mii_data *mii = NULL; + struct bce_softc *sc = xsc; + struct mii_data *mii; struct ifnet *ifp; u32 msg; @@ -5530,9 +5552,12 @@ /* Update the statistics from the hardware statistics block. */ bce_stats_update(sc); + /* Check that chip hasn't hung. */ + bce_watchdog(sc); + /* Schedule the next tick. */ callout_reset( - &sc->bce_stat_ch, /* callout */ + &sc->bce_stat_ch, /* callout */ hz, /* ticks */ bce_tick, /* function */ sc); /* function argument */ @@ -5541,8 +5566,6 @@ if (sc->bce_link) goto bce_tick_locked_exit; - /* DRC - ToDo: Add SerDes support and check SerDes link here. */ - mii = device_get_softc(sc->bce_miibus); mii_tick(mii); @@ -5553,7 +5576,7 @@ if ((IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T || IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_SX) && bootverbose) - BCE_PRINTF(sc, "Gigabit link up\n"); + BCE_PRINTF("Gigabit link up\n"); /* Now that link is up, handle any outstanding TX traffic. */ if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) bce_start_locked(ifp); @@ -5564,19 +5587,6 @@ } -static void -bce_tick(void *xsc) -{ - struct bce_softc *sc; - - sc = xsc; - - BCE_LOCK(sc); - bce_tick_locked(sc); - BCE_UNLOCK(sc); -} - - #ifdef BCE_DEBUG /****************************************************************************/ /* Allows the driver state to be dumped through the sysctl interface. */ @@ -5635,8 +5645,8 @@ /****************************************************************************/ +/* Provides a sysctl interface to allow dumping the RX chain. */ /* */ -/* */ /* Returns: */ /* 0 for success, positive value for failure. */ /****************************************************************************/ @@ -5663,12 +5673,75 @@ /****************************************************************************/ +/* Provides a sysctl interface to allow dumping the TX chain. */ /* */ +/* Returns: */ +/* 0 for success, positive value for failure. */ +/****************************************************************************/ +static int +bce_sysctl_dump_tx_chain(SYSCTL_HANDLER_ARGS) +{ + int error; + int result; + struct bce_softc *sc; + + result = -1; + error = sysctl_handle_int(oidp, &result, 0, req); + + if (error || !req->newptr) + return (error); + + if (result == 1) { + sc = (struct bce_softc *)arg1; + bce_dump_tx_chain(sc, 0, USABLE_TX_BD); + } + + return error; +} + + +/****************************************************************************/ +/* Provides a sysctl interface to allow reading arbitrary registers in the */ +/* device. DO NOT ENABLE ON PRODUCTION SYSTEMS! */ /* */ /* Returns: */ /* 0 for success, positive value for failure. */ /****************************************************************************/ static int +bce_sysctl_reg_read(SYSCTL_HANDLER_ARGS) +{ + struct bce_softc *sc; + int error; + u32 val, result; + + result = -1; + error = sysctl_handle_int(oidp, &result, 0, req); + if (error || (req->newptr == NULL)) + return (error); + + /* Make sure the register is accessible. */ + if (result < 0x8000) { + sc = (struct bce_softc *)arg1; + val = REG_RD(sc, result); + BCE_PRINTF("reg 0x%08X = 0x%08X\n", result, val); + } else if (result < 0x0280000) { + sc = (struct bce_softc *)arg1; + val = REG_RD_IND(sc, result); + BCE_PRINTF("reg 0x%08X = 0x%08X\n", result, val); + } + + return (error); +} + + +/****************************************************************************/ +/* Provides a sysctl interface to force the driver to dump state and enter */ +/* the debugger. DO NOT ENABLE ON PRODUCTION SYSTEMS! */ +/* */ +/* Returns: */ +/* 0 for success, positive value for failure. */ +/****************************************************************************/ +static int bce_sysctl_breakpoint(SYSCTL_HANDLER_ARGS) { int error; @@ -5706,11 +5779,6 @@ ctx = device_get_sysctl_ctx(sc->bce_dev); children = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->bce_dev)); - SYSCTL_ADD_STRING(ctx, children, OID_AUTO, - "driver_version", - CTLFLAG_RD, &bce_driver_version, - 0, "bce driver version"); - #ifdef BCE_DEBUG SYSCTL_ADD_INT(ctx, children, OID_AUTO, "rx_low_watermark", @@ -6013,6 +6081,11 @@ CTLFLAG_RD, &sc->stat_CatchupInRuleCheckerP4Hit, 0, "Received packets rule checker hits in Catchup path"); + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, + "com_no_bufers", + CTLFLAG_RD, &sc->com_no_buffers, + 0, "Valid packets received but no RX buffers available"); + #ifdef BCE_DEBUG SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "driver_state", CTLTYPE_INT | CTLFLAG_RW, @@ -6030,9 +6103,20 @@ bce_sysctl_dump_rx_chain, "I", "Dump rx_bd chain"); SYSCTL_ADD_PROC(ctx, children, OID_AUTO, + "dump_tx_chain", CTLTYPE_INT | CTLFLAG_RW, + (void *)sc, 0, + bce_sysctl_dump_tx_chain, "I", "Dump tx_bd chain"); + + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "breakpoint", CTLTYPE_INT | CTLFLAG_RW, (void *)sc, 0, bce_sysctl_breakpoint, "I", "Driver breakpoint"); + + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, + "reg_read", CTLTYPE_INT | CTLFLAG_RW, + (void *)sc, 0, + bce_sysctl_reg_read, "I", "Register read"); + #endif } @@ -6052,8 +6136,12 @@ static void bce_dump_mbuf(struct bce_softc *sc, struct mbuf *m) { - u32 val_hi, val_lo; - struct mbuf *mp = m; +// u32 val_hi, val_lo; +// struct mbuf *mp = m; + u32 val_hi, val_lo; + int i; + struct mbuf *mp = m; + u_char *d; if (m == NULL) { /* Index out of range. */ @@ -6064,8 +6152,24 @@ while (mp) { val_hi = BCE_ADDR_HI(mp); val_lo = BCE_ADDR_LO(mp); - BCE_PRINTF(sc, "mbuf: vaddr = 0x%08X:%08X, m_len = %d, m_flags = ", + BCE_PRINTF("mbuf: vaddr = 0x%08X:%08X, m_len = %d, m_flags = ", val_hi, val_lo, mp->m_len); + /* Print up to 128 bytes of data (should be the Ethernet header) */ + d = mtod(m, u_char *); + for (i = 0; (i < m->m_len && i < 128); ) { + if ((i % 16) == 0) + printf("0x%02X: ", i); + if (i <= m->m_len) { + printf("%02X ", *d); + d++; + i++; + } else + break; + if ((i % 16) == 0) + printf("\n"); + } + if (i != 128) + printf("\n"); if (mp->m_flags & M_EXT) printf("M_EXT "); @@ -6076,7 +6180,7 @@ if (mp->m_flags & M_EXT) { val_hi = BCE_ADDR_HI(mp->m_ext.ext_buf); val_lo = BCE_ADDR_LO(mp->m_ext.ext_buf); - BCE_PRINTF(sc, "- m_ext: vaddr = 0x%08X:%08X, ext_size = 0x%04X\n", + BCE_PRINTF("- m_ext: vaddr = 0x%08X:%08X, ext_size = 0x%04X\n", val_hi, val_lo, mp->m_ext.ext_size); } @@ -6098,96 +6202,156 @@ { struct mbuf *m; - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" " tx mbuf data " "----------------------------\n"); for (int i = 0; i < count; i++) { m = sc->tx_mbuf_ptr[chain_prod]; - BCE_PRINTF(sc, "txmbuf[%d]\n", chain_prod); + BCE_PRINTF("txmbuf[%d]\n", chain_prod); bce_dump_mbuf(sc, m); chain_prod = TX_CHAIN_IDX(NEXT_TX_BD(chain_prod)); } - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" "----------------" "----------------------------\n"); } -/* - * This routine prints the RX mbuf chain. - */ +/****************************************************************************/ +/* Prints out the mbufs in the RX mbuf chain. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_dump_rx_mbuf_chain(struct bce_softc *sc, int chain_prod, int count) { struct mbuf *m; - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" " rx mbuf data " "----------------------------\n"); for (int i = 0; i < count; i++) { m = sc->rx_mbuf_ptr[chain_prod]; - BCE_PRINTF(sc, "rxmbuf[0x%04X]\n", chain_prod); + BCE_PRINTF("rxmbuf[0x%04X]\n", chain_prod); bce_dump_mbuf(sc, m); chain_prod = RX_CHAIN_IDX(NEXT_RX_BD(chain_prod)); } - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" "----------------" "----------------------------\n"); } +/****************************************************************************/ +/* Prints out a tx_bd structure. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_dump_txbd(struct bce_softc *sc, int idx, struct tx_bd *txbd) { if (idx > MAX_TX_BD) /* Index out of range. */ - BCE_PRINTF(sc, "tx_bd[0x%04X]: Invalid tx_bd index!\n", idx); + BCE_PRINTF("tx_bd[0x%04X]: Invalid tx_bd index!\n", idx); else if ((idx & USABLE_TX_BD_PER_PAGE) == USABLE_TX_BD_PER_PAGE) /* TX Chain page pointer. */ - BCE_PRINTF(sc, "tx_bd[0x%04X]: haddr = 0x%08X:%08X, chain page pointer\n", + BCE_PRINTF("tx_bd[0x%04X]: haddr = 0x%08X:%08X, chain page pointer\n", idx, txbd->tx_bd_haddr_hi, txbd->tx_bd_haddr_lo); - else + else { /* Normal tx_bd entry. */ - BCE_PRINTF(sc, "tx_bd[0x%04X]: haddr = 0x%08X:%08X, nbytes = 0x%08X, " - "vlan tag= 0x%4X, "flags = 0x%04X\n", idx, + BCE_PRINTF("tx_bd[0x%04X]: haddr = 0x%08X:%08X, nbytes = 0x%08X, " + "vlan tag= 0x%4X, flags = 0x%04X (", idx, txbd->tx_bd_haddr_hi, txbd->tx_bd_haddr_lo, txbd->tx_bd_mss_nbytes, txbd->tx_bd_vlan_tag, txbd->tx_bd_flags); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_CONN_FAULT) + printf(" CONN_FAULT"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_TCP_UDP_CKSUM) + printf(" TCP_UDP_CKSUM"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_IP_CKSUM) + printf(" IP_CKSUM"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_VLAN_TAG) + printf(" VLAN"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_COAL_NOW) + printf(" COAL_NOW"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_DONT_GEN_CRC) + printf(" DONT_GEN_CRC"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_START) + printf(" START"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_END) + printf(" END"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_SW_OPTION_WORD) + printf(" OPTION_WORD"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_SW_FLAGS) + printf(" FLAGS"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_SW_SNAP) + printf(" SNAP"); + + if (txbd->tx_bd_flags & TX_BD_FLAGS_SW_LSO) + printf(" LSO"); + + printf(" )\n"); + } } +/****************************************************************************/ +/* Prints out a rx_bd structure. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_dump_rxbd(struct bce_softc *sc, int idx, struct rx_bd *rxbd) { if (idx > MAX_RX_BD) /* Index out of range. */ - BCE_PRINTF(sc, "rx_bd[0x%04X]: Invalid rx_bd index!\n", idx); + BCE_PRINTF("rx_bd[0x%04X]: Invalid rx_bd index!\n", idx); else if ((idx & USABLE_RX_BD_PER_PAGE) == USABLE_RX_BD_PER_PAGE) /* TX Chain page pointer. */ - BCE_PRINTF(sc, "rx_bd[0x%04X]: haddr = 0x%08X:%08X, chain page pointer\n", + BCE_PRINTF("rx_bd[0x%04X]: haddr = 0x%08X:%08X, chain page pointer\n", idx, rxbd->rx_bd_haddr_hi, rxbd->rx_bd_haddr_lo); else /* Normal tx_bd entry. */ - BCE_PRINTF(sc, "rx_bd[0x%04X]: haddr = 0x%08X:%08X, nbytes = 0x%08X, " + BCE_PRINTF("rx_bd[0x%04X]: haddr = 0x%08X:%08X, nbytes = 0x%08X, " "flags = 0x%08X\n", idx, rxbd->rx_bd_haddr_hi, rxbd->rx_bd_haddr_lo, rxbd->rx_bd_len, rxbd->rx_bd_flags); } +/****************************************************************************/ +/* Prints out a l2_fhdr structure. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_dump_l2fhdr(struct bce_softc *sc, int idx, struct l2_fhdr *l2fhdr) { - BCE_PRINTF(sc, "l2_fhdr[0x%04X]: status = 0x%08X, " + BCE_PRINTF("l2_fhdr[0x%04X]: status = 0x%08X, " "pkt_len = 0x%04X, vlan = 0x%04x, ip_xsum = 0x%04X, " "tcp_udp_xsum = 0x%04X\n", idx, l2fhdr->l2_fhdr_status, l2fhdr->l2_fhdr_pkt_len, @@ -6196,29 +6360,32 @@ } -/* - * This routine prints the TX chain. - */ +/****************************************************************************/ +/* Prints out the TX chain. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_dump_tx_chain(struct bce_softc *sc, int tx_prod, int count) { struct tx_bd *txbd; /* First some info about the tx_bd chain structure. */ - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" " tx_bd chain " "----------------------------\n"); - BCE_PRINTF(sc, "page size = 0x%08X, tx chain pages = 0x%08X\n", + BCE_PRINTF("page size = 0x%08X, tx chain pages = 0x%08X\n", (u32) BCM_PAGE_SIZE, (u32) TX_PAGES); - BCE_PRINTF(sc, "tx_bd per page = 0x%08X, usable tx_bd per page = 0x%08X\n", + BCE_PRINTF("tx_bd per page = 0x%08X, usable tx_bd per page = 0x%08X\n", (u32) TOTAL_TX_BD_PER_PAGE, (u32) USABLE_TX_BD_PER_PAGE); - BCE_PRINTF(sc, "total tx_bd = 0x%08X\n", (u32) TOTAL_TX_BD); + BCE_PRINTF("total tx_bd = 0x%08X\n", (u32) TOTAL_TX_BD); - BCE_PRINTF(sc, "" + BCE_PRINTF( "-----------------------------" " tx_bd data " "-----------------------------\n"); @@ -6230,38 +6397,39 @@ tx_prod = TX_CHAIN_IDX(NEXT_TX_BD(tx_prod)); } - BCE_PRINTF(sc, - "-----------------------------" - "--------------" - "-----------------------------\n"); + BCE_PRINTF( + "----------------------------" + "----------------" + "----------------------------\n"); } -/* - * This routine prints the RX chain. - */ +/****************************************************************************/ +/* Prints out the RX chain. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_dump_rx_chain(struct bce_softc *sc, int rx_prod, int count) { struct rx_bd *rxbd; /* First some info about the tx_bd chain structure. */ - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" " rx_bd chain " "----------------------------\n"); - BCE_PRINTF(sc, "----- RX_BD Chain -----\n"); - - BCE_PRINTF(sc, "page size = 0x%08X, rx chain pages = 0x%08X\n", + BCE_PRINTF("page size = 0x%08X, rx chain pages = 0x%08X\n", (u32) BCM_PAGE_SIZE, (u32) RX_PAGES); - BCE_PRINTF(sc, "rx_bd per page = 0x%08X, usable rx_bd per page = 0x%08X\n", + BCE_PRINTF("rx_bd per page = 0x%08X, usable rx_bd per page = 0x%08X\n", (u32) TOTAL_RX_BD_PER_PAGE, (u32) USABLE_RX_BD_PER_PAGE); - BCE_PRINTF(sc, "total rx_bd = 0x%08X\n", (u32) TOTAL_RX_BD); + BCE_PRINTF("total rx_bd = 0x%08X\n", (u32) TOTAL_RX_BD); - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" " rx_bd data " "----------------------------\n"); @@ -6273,16 +6441,19 @@ rx_prod = RX_CHAIN_IDX(NEXT_RX_BD(rx_prod)); } - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" - "--------------" + "----------------" "----------------------------\n"); } -/* - * This routine prints the status block. - */ +/****************************************************************************/ +/* Prints out the status block from host memory. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_dump_status_block(struct bce_softc *sc) { @@ -6290,88 +6461,95 @@ sblk = sc->status_block; - BCE_PRINTF(sc, "----------------------------- Status Block " - "-----------------------------\n"); + BCE_PRINTF( + "----------------------------" + " Status Block " + "----------------------------\n"); - BCE_PRINTF(sc, "attn_bits = 0x%08X, attn_bits_ack = 0x%08X, index = 0x%04X\n", + BCE_PRINTF("attn_bits = 0x%08X, attn_bits_ack = 0x%08X, index = 0x%04X\n", sblk->status_attn_bits, sblk->status_attn_bits_ack, sblk->status_idx); - BCE_PRINTF(sc, "rx_cons0 = 0x%08X, tx_cons0 = 0x%08X\n", + BCE_PRINTF("rx_cons0 = 0x%08X, tx_cons0 = 0x%08X\n", sblk->status_rx_quick_consumer_index0, sblk->status_tx_quick_consumer_index0); - BCE_PRINTF(sc, "status_idx = 0x%04X\n", sblk->status_idx); + BCE_PRINTF("status_idx = 0x%04X\n", sblk->status_idx); /* Theses indices are not used for normal L2 drivers. */ if (sblk->status_rx_quick_consumer_index1 || sblk->status_tx_quick_consumer_index1) - BCE_PRINTF(sc, "rx_cons1 = 0x%08X, tx_cons1 = 0x%08X\n", + BCE_PRINTF("rx_cons1 = 0x%08X, tx_cons1 = 0x%08X\n", sblk->status_rx_quick_consumer_index1, sblk->status_tx_quick_consumer_index1); if (sblk->status_rx_quick_consumer_index2 || sblk->status_tx_quick_consumer_index2) - BCE_PRINTF(sc, "rx_cons2 = 0x%08X, tx_cons2 = 0x%08X\n", + BCE_PRINTF("rx_cons2 = 0x%08X, tx_cons2 = 0x%08X\n", sblk->status_rx_quick_consumer_index2, sblk->status_tx_quick_consumer_index2); if (sblk->status_rx_quick_consumer_index3 || sblk->status_tx_quick_consumer_index3) - BCE_PRINTF(sc, "rx_cons3 = 0x%08X, tx_cons3 = 0x%08X\n", + BCE_PRINTF("rx_cons3 = 0x%08X, tx_cons3 = 0x%08X\n", sblk->status_rx_quick_consumer_index3, sblk->status_tx_quick_consumer_index3); if (sblk->status_rx_quick_consumer_index4 || sblk->status_rx_quick_consumer_index5) - BCE_PRINTF(sc, "rx_cons4 = 0x%08X, rx_cons5 = 0x%08X\n", + BCE_PRINTF("rx_cons4 = 0x%08X, rx_cons5 = 0x%08X\n", sblk->status_rx_quick_consumer_index4, sblk->status_rx_quick_consumer_index5); if (sblk->status_rx_quick_consumer_index6 || sblk->status_rx_quick_consumer_index7) - BCE_PRINTF(sc, "rx_cons6 = 0x%08X, rx_cons7 = 0x%08X\n", + BCE_PRINTF("rx_cons6 = 0x%08X, rx_cons7 = 0x%08X\n", sblk->status_rx_quick_consumer_index6, sblk->status_rx_quick_consumer_index7); if (sblk->status_rx_quick_consumer_index8 || sblk->status_rx_quick_consumer_index9) - BCE_PRINTF(sc, "rx_cons8 = 0x%08X, rx_cons9 = 0x%08X\n", + BCE_PRINTF("rx_cons8 = 0x%08X, rx_cons9 = 0x%08X\n", sblk->status_rx_quick_consumer_index8, sblk->status_rx_quick_consumer_index9); if (sblk->status_rx_quick_consumer_index10 || sblk->status_rx_quick_consumer_index11) - BCE_PRINTF(sc, "rx_cons10 = 0x%08X, rx_cons11 = 0x%08X\n", + BCE_PRINTF("rx_cons10 = 0x%08X, rx_cons11 = 0x%08X\n", sblk->status_rx_quick_consumer_index10, sblk->status_rx_quick_consumer_index11); if (sblk->status_rx_quick_consumer_index12 || sblk->status_rx_quick_consumer_index13) - BCE_PRINTF(sc, "rx_cons12 = 0x%08X, rx_cons13 = 0x%08X\n", + BCE_PRINTF("rx_cons12 = 0x%08X, rx_cons13 = 0x%08X\n", sblk->status_rx_quick_consumer_index12, sblk->status_rx_quick_consumer_index13); if (sblk->status_rx_quick_consumer_index14 || sblk->status_rx_quick_consumer_index15) - BCE_PRINTF(sc, "rx_cons14 = 0x%08X, rx_cons15 = 0x%08X\n", + BCE_PRINTF("rx_cons14 = 0x%08X, rx_cons15 = 0x%08X\n", sblk->status_rx_quick_consumer_index14, sblk->status_rx_quick_consumer_index15); if (sblk->status_completion_producer_index || sblk->status_cmd_consumer_index) - BCE_PRINTF(sc, "com_prod = 0x%08X, cmd_cons = 0x%08X\n", + BCE_PRINTF("com_prod = 0x%08X, cmd_cons = 0x%08X\n", sblk->status_completion_producer_index, sblk->status_cmd_consumer_index); - BCE_PRINTF(sc, "-------------------------------------------" - "-----------------------------\n"); + BCE_PRINTF( + "----------------------------" + "----------------" + "----------------------------\n"); } -/* - * This routine prints the statistics block. - */ +/****************************************************************************/ +/* Prints out the statistics block from host memory. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_dump_stats_block(struct bce_softc *sc) { @@ -6379,393 +6557,414 @@ sblk = sc->stats_block; - BCE_PRINTF(sc, "" - "-----------------------------" - " Stats Block " - "-----------------------------\n"); + BCE_PRINTF( + "----------------------------" + " Stats Block " + "----------------------------\n"); - BCE_PRINTF(sc, "IfHcInOctets = 0x%08X:%08X, " + BCE_PRINTF("IfHcInOctets = 0x%08X:%08X, " "IfHcInBadOctets = 0x%08X:%08X\n", sblk->stat_IfHCInOctets_hi, sblk->stat_IfHCInOctets_lo, sblk->stat_IfHCInBadOctets_hi, sblk->stat_IfHCInBadOctets_lo); - BCE_PRINTF(sc, "IfHcOutOctets = 0x%08X:%08X, " + BCE_PRINTF("IfHcOutOctets = 0x%08X:%08X, " "IfHcOutBadOctets = 0x%08X:%08X\n", sblk->stat_IfHCOutOctets_hi, sblk->stat_IfHCOutOctets_lo, sblk->stat_IfHCOutBadOctets_hi, sblk->stat_IfHCOutBadOctets_lo); - BCE_PRINTF(sc, "IfHcInUcastPkts = 0x%08X:%08X, " + BCE_PRINTF("IfHcInUcastPkts = 0x%08X:%08X, " "IfHcInMulticastPkts = 0x%08X:%08X\n", sblk->stat_IfHCInUcastPkts_hi, sblk->stat_IfHCInUcastPkts_lo, sblk->stat_IfHCInMulticastPkts_hi, sblk->stat_IfHCInMulticastPkts_lo); - BCE_PRINTF(sc, "IfHcInBroadcastPkts = 0x%08X:%08X, " + BCE_PRINTF("IfHcInBroadcastPkts = 0x%08X:%08X, " "IfHcOutUcastPkts = 0x%08X:%08X\n", sblk->stat_IfHCInBroadcastPkts_hi, sblk->stat_IfHCInBroadcastPkts_lo, sblk->stat_IfHCOutUcastPkts_hi, sblk->stat_IfHCOutUcastPkts_lo); - BCE_PRINTF(sc, "IfHcOutMulticastPkts = 0x%08X:%08X, IfHcOutBroadcastPkts = 0x%08X:%08X\n", + BCE_PRINTF("IfHcOutMulticastPkts = 0x%08X:%08X, IfHcOutBroadcastPkts = 0x%08X:%08X\n", sblk->stat_IfHCOutMulticastPkts_hi, sblk->stat_IfHCOutMulticastPkts_lo, sblk->stat_IfHCOutBroadcastPkts_hi, sblk->stat_IfHCOutBroadcastPkts_lo); if (sblk->stat_emac_tx_stat_dot3statsinternalmactransmiterrors) - BCE_PRINTF(sc, "0x%08X : " + BCE_PRINTF("0x%08X : " "emac_tx_stat_dot3statsinternalmactransmiterrors\n", sblk->stat_emac_tx_stat_dot3statsinternalmactransmiterrors); if (sblk->stat_Dot3StatsCarrierSenseErrors) - BCE_PRINTF(sc, "0x%08X : Dot3StatsCarrierSenseErrors\n", + BCE_PRINTF("0x%08X : Dot3StatsCarrierSenseErrors\n", sblk->stat_Dot3StatsCarrierSenseErrors); if (sblk->stat_Dot3StatsFCSErrors) - BCE_PRINTF(sc, "0x%08X : Dot3StatsFCSErrors\n", + BCE_PRINTF("0x%08X : Dot3StatsFCSErrors\n", sblk->stat_Dot3StatsFCSErrors); if (sblk->stat_Dot3StatsAlignmentErrors) - BCE_PRINTF(sc, "0x%08X : Dot3StatsAlignmentErrors\n", + BCE_PRINTF("0x%08X : Dot3StatsAlignmentErrors\n", sblk->stat_Dot3StatsAlignmentErrors); if (sblk->stat_Dot3StatsSingleCollisionFrames) - BCE_PRINTF(sc, "0x%08X : Dot3StatsSingleCollisionFrames\n", + BCE_PRINTF("0x%08X : Dot3StatsSingleCollisionFrames\n", sblk->stat_Dot3StatsSingleCollisionFrames); if (sblk->stat_Dot3StatsMultipleCollisionFrames) - BCE_PRINTF(sc, "0x%08X : Dot3StatsMultipleCollisionFrames\n", + BCE_PRINTF("0x%08X : Dot3StatsMultipleCollisionFrames\n", sblk->stat_Dot3StatsMultipleCollisionFrames); if (sblk->stat_Dot3StatsDeferredTransmissions) - BCE_PRINTF(sc, "0x%08X : Dot3StatsDeferredTransmissions\n", + BCE_PRINTF("0x%08X : Dot3StatsDeferredTransmissions\n", sblk->stat_Dot3StatsDeferredTransmissions); if (sblk->stat_Dot3StatsExcessiveCollisions) - BCE_PRINTF(sc, "0x%08X : Dot3StatsExcessiveCollisions\n", + BCE_PRINTF("0x%08X : Dot3StatsExcessiveCollisions\n", sblk->stat_Dot3StatsExcessiveCollisions); if (sblk->stat_Dot3StatsLateCollisions) - BCE_PRINTF(sc, "0x%08X : Dot3StatsLateCollisions\n", + BCE_PRINTF("0x%08X : Dot3StatsLateCollisions\n", sblk->stat_Dot3StatsLateCollisions); if (sblk->stat_EtherStatsCollisions) - BCE_PRINTF(sc, "0x%08X : EtherStatsCollisions\n", + BCE_PRINTF("0x%08X : EtherStatsCollisions\n", sblk->stat_EtherStatsCollisions); if (sblk->stat_EtherStatsFragments) - BCE_PRINTF(sc, "0x%08X : EtherStatsFragments\n", + BCE_PRINTF("0x%08X : EtherStatsFragments\n", sblk->stat_EtherStatsFragments); if (sblk->stat_EtherStatsJabbers) - BCE_PRINTF(sc, "0x%08X : EtherStatsJabbers\n", + BCE_PRINTF("0x%08X : EtherStatsJabbers\n", sblk->stat_EtherStatsJabbers); if (sblk->stat_EtherStatsUndersizePkts) - BCE_PRINTF(sc, "0x%08X : EtherStatsUndersizePkts\n", + BCE_PRINTF("0x%08X : EtherStatsUndersizePkts\n", sblk->stat_EtherStatsUndersizePkts); if (sblk->stat_EtherStatsOverrsizePkts) - BCE_PRINTF(sc, "0x%08X : EtherStatsOverrsizePkts\n", + BCE_PRINTF("0x%08X : EtherStatsOverrsizePkts\n", sblk->stat_EtherStatsOverrsizePkts); if (sblk->stat_EtherStatsPktsRx64Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsRx64Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsRx64Octets\n", sblk->stat_EtherStatsPktsRx64Octets); if (sblk->stat_EtherStatsPktsRx65Octetsto127Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsRx65Octetsto127Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsRx65Octetsto127Octets\n", sblk->stat_EtherStatsPktsRx65Octetsto127Octets); if (sblk->stat_EtherStatsPktsRx128Octetsto255Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsRx128Octetsto255Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsRx128Octetsto255Octets\n", sblk->stat_EtherStatsPktsRx128Octetsto255Octets); if (sblk->stat_EtherStatsPktsRx256Octetsto511Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsRx256Octetsto511Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsRx256Octetsto511Octets\n", sblk->stat_EtherStatsPktsRx256Octetsto511Octets); if (sblk->stat_EtherStatsPktsRx512Octetsto1023Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsRx512Octetsto1023Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsRx512Octetsto1023Octets\n", sblk->stat_EtherStatsPktsRx512Octetsto1023Octets); if (sblk->stat_EtherStatsPktsRx1024Octetsto1522Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsRx1024Octetsto1522Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsRx1024Octetsto1522Octets\n", sblk->stat_EtherStatsPktsRx1024Octetsto1522Octets); if (sblk->stat_EtherStatsPktsRx1523Octetsto9022Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsRx1523Octetsto9022Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsRx1523Octetsto9022Octets\n", sblk->stat_EtherStatsPktsRx1523Octetsto9022Octets); if (sblk->stat_EtherStatsPktsTx64Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsTx64Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsTx64Octets\n", sblk->stat_EtherStatsPktsTx64Octets); if (sblk->stat_EtherStatsPktsTx65Octetsto127Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsTx65Octetsto127Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsTx65Octetsto127Octets\n", sblk->stat_EtherStatsPktsTx65Octetsto127Octets); if (sblk->stat_EtherStatsPktsTx128Octetsto255Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsTx128Octetsto255Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsTx128Octetsto255Octets\n", sblk->stat_EtherStatsPktsTx128Octetsto255Octets); if (sblk->stat_EtherStatsPktsTx256Octetsto511Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsTx256Octetsto511Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsTx256Octetsto511Octets\n", sblk->stat_EtherStatsPktsTx256Octetsto511Octets); if (sblk->stat_EtherStatsPktsTx512Octetsto1023Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsTx512Octetsto1023Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsTx512Octetsto1023Octets\n", sblk->stat_EtherStatsPktsTx512Octetsto1023Octets); if (sblk->stat_EtherStatsPktsTx1024Octetsto1522Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsTx1024Octetsto1522Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsTx1024Octetsto1522Octets\n", sblk->stat_EtherStatsPktsTx1024Octetsto1522Octets); if (sblk->stat_EtherStatsPktsTx1523Octetsto9022Octets) - BCE_PRINTF(sc, "0x%08X : EtherStatsPktsTx1523Octetsto9022Octets\n", + BCE_PRINTF("0x%08X : EtherStatsPktsTx1523Octetsto9022Octets\n", sblk->stat_EtherStatsPktsTx1523Octetsto9022Octets); if (sblk->stat_XonPauseFramesReceived) - BCE_PRINTF(sc, "0x%08X : XonPauseFramesReceived\n", + BCE_PRINTF("0x%08X : XonPauseFramesReceived\n", sblk->stat_XonPauseFramesReceived); if (sblk->stat_XoffPauseFramesReceived) - BCE_PRINTF(sc, "0x%08X : XoffPauseFramesReceived\n", + BCE_PRINTF("0x%08X : XoffPauseFramesReceived\n", sblk->stat_XoffPauseFramesReceived); if (sblk->stat_OutXonSent) - BCE_PRINTF(sc, "0x%08X : OutXonSent\n", + BCE_PRINTF("0x%08X : OutXonSent\n", sblk->stat_OutXonSent); if (sblk->stat_OutXoffSent) - BCE_PRINTF(sc, "0x%08X : OutXoffSent\n", + BCE_PRINTF("0x%08X : OutXoffSent\n", sblk->stat_OutXoffSent); if (sblk->stat_FlowControlDone) - BCE_PRINTF(sc, "0x%08X : FlowControlDone\n", + BCE_PRINTF("0x%08X : FlowControlDone\n", sblk->stat_FlowControlDone); if (sblk->stat_MacControlFramesReceived) - BCE_PRINTF(sc, "0x%08X : MacControlFramesReceived\n", + BCE_PRINTF("0x%08X : MacControlFramesReceived\n", sblk->stat_MacControlFramesReceived); if (sblk->stat_XoffStateEntered) - BCE_PRINTF(sc, "0x%08X : XoffStateEntered\n", + BCE_PRINTF("0x%08X : XoffStateEntered\n", sblk->stat_XoffStateEntered); if (sblk->stat_IfInFramesL2FilterDiscards) - BCE_PRINTF(sc, "0x%08X : IfInFramesL2FilterDiscards\n", + BCE_PRINTF("0x%08X : IfInFramesL2FilterDiscards\n", sblk->stat_IfInFramesL2FilterDiscards); if (sblk->stat_IfInRuleCheckerDiscards) - BCE_PRINTF(sc, "0x%08X : IfInRuleCheckerDiscards\n", + BCE_PRINTF("0x%08X : IfInRuleCheckerDiscards\n", sblk->stat_IfInRuleCheckerDiscards); if (sblk->stat_IfInFTQDiscards) - BCE_PRINTF(sc, "0x%08X : IfInFTQDiscards\n", + BCE_PRINTF("0x%08X : IfInFTQDiscards\n", sblk->stat_IfInFTQDiscards); if (sblk->stat_IfInMBUFDiscards) - BCE_PRINTF(sc, "0x%08X : IfInMBUFDiscards\n", + BCE_PRINTF("0x%08X : IfInMBUFDiscards\n", sblk->stat_IfInMBUFDiscards); if (sblk->stat_IfInRuleCheckerP4Hit) - BCE_PRINTF(sc, "0x%08X : IfInRuleCheckerP4Hit\n", + BCE_PRINTF("0x%08X : IfInRuleCheckerP4Hit\n", sblk->stat_IfInRuleCheckerP4Hit); if (sblk->stat_CatchupInRuleCheckerDiscards) - BCE_PRINTF(sc, "0x%08X : CatchupInRuleCheckerDiscards\n", + BCE_PRINTF("0x%08X : CatchupInRuleCheckerDiscards\n", sblk->stat_CatchupInRuleCheckerDiscards); if (sblk->stat_CatchupInFTQDiscards) - BCE_PRINTF(sc, "0x%08X : CatchupInFTQDiscards\n", + BCE_PRINTF("0x%08X : CatchupInFTQDiscards\n", sblk->stat_CatchupInFTQDiscards); if (sblk->stat_CatchupInMBUFDiscards) - BCE_PRINTF(sc, "0x%08X : CatchupInMBUFDiscards\n", + BCE_PRINTF("0x%08X : CatchupInMBUFDiscards\n", sblk->stat_CatchupInMBUFDiscards); if (sblk->stat_CatchupInRuleCheckerP4Hit) - BCE_PRINTF(sc, "0x%08X : CatchupInRuleCheckerP4Hit\n", + BCE_PRINTF("0x%08X : CatchupInRuleCheckerP4Hit\n", sblk->stat_CatchupInRuleCheckerP4Hit); - BCE_PRINTF(sc, - "-----------------------------" - "--------------" - "-----------------------------\n"); + BCE_PRINTF( + "----------------------------" + "----------------" + "----------------------------\n"); } +/****************************************************************************/ +/* Prints out a summary of the driver state. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_dump_driver_state(struct bce_softc *sc) { u32 val_hi, val_lo; - BCE_PRINTF(sc, - "-----------------------------" - " Driver State " - "-----------------------------\n"); + BCE_PRINTF( + "----------------------------" + " Driver State " + "----------------------------\n"); val_hi = BCE_ADDR_HI(sc); val_lo = BCE_ADDR_LO(sc); - BCE_PRINTF(sc, "0x%08X:%08X - (sc) driver softc structure virtual address\n", + BCE_PRINTF("0x%08X:%08X - (sc) driver softc structure virtual address\n", val_hi, val_lo); val_hi = BCE_ADDR_HI(sc->bce_vhandle); val_lo = BCE_ADDR_LO(sc->bce_vhandle); - BCE_PRINTF(sc, "0x%08X:%08X - (sc->bce_vhandle) PCI BAR virtual address\n", + BCE_PRINTF("0x%08X:%08X - (sc->bce_vhandle) PCI BAR virtual address\n", val_hi, val_lo); val_hi = BCE_ADDR_HI(sc->status_block); val_lo = BCE_ADDR_LO(sc->status_block); - BCE_PRINTF(sc, "0x%08X:%08X - (sc->status_block) status block virtual address\n", + BCE_PRINTF( + "0x%08X:%08X - (sc->status_block) status block virtual address\n", val_hi, val_lo); val_hi = BCE_ADDR_HI(sc->stats_block); val_lo = BCE_ADDR_LO(sc->stats_block); - BCE_PRINTF(sc, "0x%08X:%08X - (sc->stats_block) statistics block virtual address\n", + BCE_PRINTF( + "0x%08X:%08X - (sc->stats_block) statistics block virtual address\n", val_hi, val_lo); val_hi = BCE_ADDR_HI(sc->tx_bd_chain); val_lo = BCE_ADDR_LO(sc->tx_bd_chain); - BCE_PRINTF(sc, + BCE_PRINTF( "0x%08X:%08X - (sc->tx_bd_chain) tx_bd chain virtual adddress\n", val_hi, val_lo); val_hi = BCE_ADDR_HI(sc->rx_bd_chain); val_lo = BCE_ADDR_LO(sc->rx_bd_chain); - BCE_PRINTF(sc, + BCE_PRINTF( "0x%08X:%08X - (sc->rx_bd_chain) rx_bd chain virtual address\n", val_hi, val_lo); val_hi = BCE_ADDR_HI(sc->tx_mbuf_ptr); val_lo = BCE_ADDR_LO(sc->tx_mbuf_ptr); - BCE_PRINTF(sc, + BCE_PRINTF( "0x%08X:%08X - (sc->tx_mbuf_ptr) tx mbuf chain virtual address\n", val_hi, val_lo); val_hi = BCE_ADDR_HI(sc->rx_mbuf_ptr); val_lo = BCE_ADDR_LO(sc->rx_mbuf_ptr); - BCE_PRINTF(sc, + BCE_PRINTF( "0x%08X:%08X - (sc->rx_mbuf_ptr) rx mbuf chain virtual address\n", val_hi, val_lo); - BCE_PRINTF(sc, " 0x%08X - (sc->interrupts_generated) h/w intrs\n", + BCE_PRINTF(" 0x%08X - (sc->interrupts_generated) h/w intrs\n", sc->interrupts_generated); - BCE_PRINTF(sc, " 0x%08X - (sc->rx_interrupts) rx interrupts handled\n", + BCE_PRINTF(" 0x%08X - (sc->rx_interrupts) rx interrupts handled\n", sc->rx_interrupts); - BCE_PRINTF(sc, " 0x%08X - (sc->tx_interrupts) tx interrupts handled\n", + BCE_PRINTF(" 0x%08X - (sc->tx_interrupts) tx interrupts handled\n", sc->tx_interrupts); - BCE_PRINTF(sc, " 0x%08X - (sc->last_status_idx) status block index\n", + BCE_PRINTF(" 0x%08X - (sc->last_status_idx) status block index\n", sc->last_status_idx); - BCE_PRINTF(sc, " 0x%08X - (sc->tx_prod) tx producer index\n", + BCE_PRINTF(" 0x%08X - (sc->tx_prod) tx producer index\n", sc->tx_prod); - BCE_PRINTF(sc, " 0x%08X - (sc->tx_cons) tx consumer index\n", + BCE_PRINTF(" 0x%08X - (sc->tx_cons) tx consumer index\n", sc->tx_cons); - BCE_PRINTF(sc, " 0x%08X - (sc->tx_prod_bseq) tx producer bseq index\n", + BCE_PRINTF(" 0x%08X - (sc->tx_prod_bseq) tx producer bseq index\n", sc->tx_prod_bseq); - BCE_PRINTF(sc, " 0x%08X - (sc->rx_prod) rx producer index\n", + BCE_PRINTF(" 0x%08X - (sc->rx_prod) rx producer index\n", sc->rx_prod); - BCE_PRINTF(sc, " 0x%08X - (sc->rx_cons) rx consumer index\n", + BCE_PRINTF(" 0x%08X - (sc->rx_cons) rx consumer index\n", sc->rx_cons); - BCE_PRINTF(sc, " 0x%08X - (sc->rx_prod_bseq) rx producer bseq index\n", + BCE_PRINTF(" 0x%08X - (sc->rx_prod_bseq) rx producer bseq index\n", sc->rx_prod_bseq); - BCE_PRINTF(sc, " 0x%08X - (sc->rx_mbuf_alloc) rx mbufs allocated\n", + BCE_PRINTF(" 0x%08X - (sc->rx_mbuf_alloc) rx mbufs allocated\n", sc->rx_mbuf_alloc); - BCE_PRINTF(sc, " 0x%08X - (sc->free_rx_bd) free rx_bd's\n", + BCE_PRINTF(" 0x%08X - (sc->free_rx_bd) free rx_bd's\n", sc->free_rx_bd); - BCE_PRINTF(sc, "0x%08X/%08X - (sc->rx_low_watermark) rx low watermark\n", + BCE_PRINTF("0x%08X/%08X - (sc->rx_low_watermark) rx low watermark\n", sc->rx_low_watermark, (u32) USABLE_RX_BD); - BCE_PRINTF(sc, " 0x%08X - (sc->txmbuf_alloc) tx mbufs allocated\n", + BCE_PRINTF(" 0x%08X - (sc->txmbuf_alloc) tx mbufs allocated\n", sc->tx_mbuf_alloc); - BCE_PRINTF(sc, " 0x%08X - (sc->rx_mbuf_alloc) rx mbufs allocated\n", + BCE_PRINTF(" 0x%08X - (sc->rx_mbuf_alloc) rx mbufs allocated\n", sc->rx_mbuf_alloc); - BCE_PRINTF(sc, " 0x%08X - (sc->used_tx_bd) used tx_bd's\n", + BCE_PRINTF(" 0x%08X - (sc->used_tx_bd) used tx_bd's\n", sc->used_tx_bd); - BCE_PRINTF(sc, "0x%08X/%08X - (sc->tx_hi_watermark) tx hi watermark\n", + BCE_PRINTF("0x%08X/%08X - (sc->tx_hi_watermark) tx hi watermark\n", sc->tx_hi_watermark, (u32) USABLE_TX_BD); - BCE_PRINTF(sc, " 0x%08X - (sc->mbuf_alloc_failed) failed mbuf alloc\n", + BCE_PRINTF(" 0x%08X - (sc->mbuf_alloc_failed) failed mbuf alloc\n", sc->mbuf_alloc_failed); - BCE_PRINTF(sc, - "-----------------------------" - "--------------" - "-----------------------------\n"); + BCE_PRINTF( + "----------------------------" + "----------------" + "----------------------------\n"); } +/****************************************************************************/ +/* Prints out the hardware state through a summary of important register, */ +/* followed by a complete register dump. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_dump_hw_state(struct bce_softc *sc) { u32 val1; - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" " Hardware State " "----------------------------\n"); - BCE_PRINTF(sc, "0x%08X : bootcode version\n", sc->bce_fw_ver); + BCE_PRINTF("0x%08X : bootcode version\n", sc->bce_fw_ver); val1 = REG_RD(sc, BCE_MISC_ENABLE_STATUS_BITS); - BCE_PRINTF(sc, "0x%08X : (0x%04X) misc_enable_status_bits\n", + BCE_PRINTF("0x%08X : (0x%04X) misc_enable_status_bits\n", val1, BCE_MISC_ENABLE_STATUS_BITS); val1 = REG_RD(sc, BCE_DMA_STATUS); - BCE_PRINTF(sc, "0x%08X : (0x%04X) dma_status\n", val1, BCE_DMA_STATUS); + BCE_PRINTF("0x%08X : (0x%04X) dma_status\n", val1, BCE_DMA_STATUS); val1 = REG_RD(sc, BCE_CTX_STATUS); - BCE_PRINTF(sc, "0x%08X : (0x%04X) ctx_status\n", val1, BCE_CTX_STATUS); + BCE_PRINTF("0x%08X : (0x%04X) ctx_status\n", val1, BCE_CTX_STATUS); val1 = REG_RD(sc, BCE_EMAC_STATUS); - BCE_PRINTF(sc, "0x%08X : (0x%04X) emac_status\n", val1, BCE_EMAC_STATUS); + BCE_PRINTF("0x%08X : (0x%04X) emac_status\n", val1, BCE_EMAC_STATUS); val1 = REG_RD(sc, BCE_RPM_STATUS); - BCE_PRINTF(sc, "0x%08X : (0x%04X) rpm_status\n", val1, BCE_RPM_STATUS); + BCE_PRINTF("0x%08X : (0x%04X) rpm_status\n", val1, BCE_RPM_STATUS); val1 = REG_RD(sc, BCE_TBDR_STATUS); - BCE_PRINTF(sc, "0x%08X : (0x%04X) tbdr_status\n", val1, BCE_TBDR_STATUS); + BCE_PRINTF("0x%08X : (0x%04X) tbdr_status\n", val1, BCE_TBDR_STATUS); val1 = REG_RD(sc, BCE_TDMA_STATUS); - BCE_PRINTF(sc, "0x%08X : (0x%04X) tdma_status\n", val1, BCE_TDMA_STATUS); + BCE_PRINTF("0x%08X : (0x%04X) tdma_status\n", val1, BCE_TDMA_STATUS); val1 = REG_RD(sc, BCE_HC_STATUS); - BCE_PRINTF(sc, "0x%08X : (0x%04X) hc_status\n", val1, BCE_HC_STATUS); + BCE_PRINTF("0x%08X : (0x%04X) hc_status\n", val1, BCE_HC_STATUS); - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" "----------------" "----------------------------\n"); - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" " Register Dump " "----------------------------\n"); for (int i = 0x400; i < 0x8000; i += 0x10) - BCE_PRINTF(sc, "0x%04X: 0x%08X 0x%08X 0x%08X 0x%08X\n", + BCE_PRINTF("0x%04X: 0x%08X 0x%08X 0x%08X 0x%08X\n", i, REG_RD(sc, i), REG_RD(sc, i + 0x4), REG_RD(sc, i + 0x8), REG_RD(sc, i + 0xC)); - BCE_PRINTF(sc, + BCE_PRINTF( "----------------------------" "----------------" "----------------------------\n"); } +/****************************************************************************/ +/* Prints out the driver state and then enters the debugger. */ +/* */ +/* Returns: */ +/* Nothing. */ +/****************************************************************************/ static void bce_breakpoint(struct bce_softc *sc) { @@ -6786,7 +6985,6 @@ } bce_dump_driver_state(sc); - /* Print the important status block fields. */ bce_dump_status_block(sc); /* Call the debugger. */ Index: if_bcereg.h =================================================================== --- if_bcereg.h (.../trunk/6_2/sys/dev/bce) (revision 55) +++ if_bcereg.h (.../branches/mintel_6_2/sys/dev/bce) (revision 55) @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2006 Broadcom Corporation + * Copyright (c) 2006-2007 Broadcom Corporation * David Christensen . All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -26,7 +26,7 @@ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF * THE POSSIBILITY OF SUCH DAMAGE. * - * $FreeBSD: src/sys/dev/bce/if_bcereg.h,v 1.1.2.3.2.1 2006/11/28 17:14:07 scottl Exp $ + * $FreeBSD: src/sys/dev/bce/if_bcereg.h,v 1.1.2.6 2007/06/05 01:56:08 davidch Exp $ */ #ifndef _BCE_H_DEFINED @@ -97,6 +97,7 @@ /****************************************************************************/ /* Debugging macros and definitions. */ /****************************************************************************/ +#define BCE_DEBUG 1 #define BCE_CP_LOAD 0x00000001 #define BCE_CP_SEND 0x00000002 #define BCE_CP_RECV 0x00000004 @@ -248,9 +249,11 @@ #define BCE_CHIP_ID_5706_A0 0x57060000 #define BCE_CHIP_ID_5706_A1 0x57060010 #define BCE_CHIP_ID_5706_A2 0x57060020 +#define BCE_CHIP_ID_5706_A3 0x57060030 #define BCE_CHIP_ID_5708_A0 0x57080000 #define BCE_CHIP_ID_5708_B0 0x57081000 #define BCE_CHIP_ID_5708_B1 0x57081010 +#define BCE_CHIP_ID_5708_B2 0x57081020 #define BCE_CHIP_BOND_ID(sc) (((sc)->bce_chipid) & 0xf) @@ -689,7 +692,7 @@ /****************************************************************************/ /* Convenience definitions. */ /****************************************************************************/ -#define BCE_PRINTF(sc, fmt, args...) device_printf(sc->bce_dev, fmt, ##args) +#define BCE_PRINTF(fmt, args...) device_printf(sc->bce_dev, fmt, ##args) #define BCE_LOCK_INIT(_sc, _name) mtx_init(&(_sc)->bce_mtx, _name, MTX_NETWORK_LOCK, MTX_DEF) #define BCE_LOCK(_sc) mtx_lock(&(_sc)->bce_mtx) @@ -4755,6 +4758,8 @@ int bce_link; struct callout bce_stat_ch; + int watchdog_timer; /* ticks until chip reset */ + /* Frame size and mbuf allocation size for RX frames. */ u32 max_frame_size; int mbuf_alloc_size; @@ -4871,6 +4876,8 @@ u32 stat_CatchupInMBUFDiscards; u32 stat_CatchupInRuleCheckerP4Hit; + /* Provides access to certain firmware statistics. */ + u32 com_no_buffers; #ifdef BCE_DEBUG /* Track the number of enqueued mbufs. */ int tx_mbuf_alloc; --------------030907020009000402030006-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 29 11:36: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 BC02316A421 for ; Fri, 29 Jun 2007 11:36:29 +0000 (UTC) (envelope-from gexlie@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.freebsd.org (Postfix) with ESMTP id 7FD3513C45D for ; Fri, 29 Jun 2007 11:36:29 +0000 (UTC) (envelope-from gexlie@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so123133wxd for ; Fri, 29 Jun 2007 04:36:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=reRGQ6s8RaE9umJ6WNo+WtXdOlbqwmgtTdgk9EDUaL/bQ2WxWyYQ2H3a88z42I1llp9kOEOtXgvEC0Gvb8gVMvqS6CFth8ZKz2BqVOB3QJp3pfS7sQeC52CD2gQbuIDajmRZOS+0xQ7nklFK34TZETOomqpLW3xDqgFdbi+BajU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hvI9HUfmsY9s5LhXMaicAwOhZ6MeyfRqXDeZgs9z2kiPxT1lBgrhR5pXwBpc5LNSRUguGQgYgM4f7toqNxfqq0s4tK0/A6pv3JIML1Kkb9wZy9qLwOIQDmZUlFWS+1uukHRlZbgazzW02iivyxP1DFNAfu8TTRVwgxMJBpQjp1A= Received: by 10.90.89.5 with SMTP id m5mr2916015agb.1183115371390; Fri, 29 Jun 2007 04:09:31 -0700 (PDT) Received: by 10.90.116.3 with HTTP; Fri, 29 Jun 2007 04:09:31 -0700 (PDT) Message-ID: <53cc795f0706290409j164d5dc3j9218dbf561df789f@mail.gmail.com> Date: Fri, 29 Jun 2007 15:09:31 +0400 From: sa8o1age To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: skype dummynet high priority 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, 29 Jun 2007 11:36:29 -0000 does anyone know how to set up high priority of skype traffic with the dummynet? i have this rules for now: ## shaping ipfw pipe 108 config bw 120Kbit/s queue 10kbytes mask all ipfw queue 109 config pipe 108 weight 50 mask dst-ip 0xffffffff ipfw add queue 109 ip from not 192.168.0.0/24 to 192.168.0.0/24,192.168.2.108 i need to prioritize all skype traffic to/from 192.168.2.108 when its coming From owner-freebsd-net@FreeBSD.ORG Fri Jun 29 12:12:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 005A116A41F; Fri, 29 Jun 2007 12:12:55 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id BF17E13C46C; Fri, 29 Jun 2007 12:12:55 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [10.0.0.14] (unknown [74.95.66.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id B914A1702D; Fri, 29 Jun 2007 07:12:54 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <39D6F9D8-3A2C-4AD7-9FA4-0024E304194A@secure-computing.net> <468011FC.4050308@FreeBSD.org> <7731B558-35C7-4E22-A40D-8BCE208AFD6A@secure-computing.net> <468063F6.2050303@FreeBSD.org> <8AA398FC-A753-4BB8-A93F-224FDDCE41BA@secure-computing.net> <46818609.3080202@freebsd.org> <4681AA8D.8050009@freebsd.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88EDD0D7-B5C9-4DA7-B27C-CAE662CDFA36@secure-computing.net> Content-Transfer-Encoding: 7bit From: Eric F Crist Date: Fri, 29 Jun 2007 07:12:53 -0500 X-Mailer: Apple Mail (2.752.3) Cc: "Bruce A. Mah" , "Bruce M. Simpson" , freebsd-net@freebsd.org Subject: Re: IPv6 Woes... 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, 29 Jun 2007 12:12:56 -0000 [cut it out] I just wanted everyone to know that my IPv6 Woes have been resolved. As it turns out, there a couple of things that were killing my setup. First, I had fat-fingered the IP6 alias on my gateway - works great there. Secondly, my ISP fat-fingered the network address for my subnet in their routing tables. Third, and last, there is (still) a routing problem on the high-level at Verizon/Alter/UUnet that has yet to be resolved. Thanks a lot for all your help! ----- Eric F Crist Secure Computing Networks From owner-freebsd-net@FreeBSD.ORG Fri Jun 29 20:20:08 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 A4CF616A41F for ; Fri, 29 Jun 2007 20:20:08 +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 940F613C458 for ; Fri, 29 Jun 2007 20:20:08 +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 l5TKK8Uj041454 for ; Fri, 29 Jun 2007 20:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5TKK8aL041447; Fri, 29 Jun 2007 20:20:08 GMT (envelope-from gnats) Date: Fri, 29 Jun 2007 20:20:08 GMT Message-Id: <200706292020.l5TKK8aL041447@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: W Forms Cc: Subject: Re: kern/112710: [re] if_re driver detects incorrect b243a405a405 MAC address on SMC9452TX-1 pci gigabit cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: W Forms List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2007 20:20:08 -0000 The following reply was made to PR kern/112710; it has been noted by GNATS. From: W Forms To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/112710: [re] if_re driver detects incorrect b243a405a405 MAC address on SMC9452TX-1 pci gigabit cards Date: Fri, 29 Jun 2007 22:16:23 +0200 Today I run a test using the "NetBSD Live! 2007" live-CD, which is apparently based on NetBSD 4.0 BETA. NetBSD also uses the re driver for these cards. Upon boot all the "5 bad cards" are detected as RealTek 8169SB gigabit adapters and believe or not, each and every single adapter uses its own correct MAC address. SO whatever the problem is in the FreeBSD and OpenBSD re driver, the NetBSD guys have already solved it. Or, they didn't scew it up in the first place! :-) Either way, it might be worthwile talking to them about this defect or having a thorough look at their re driver code (or the code of any related networking module). I also run a test with a Gentoo Linux Live CD which also uses the correct MAC addresses. Unfortunately this is where my abilities stop. Somebody, Please! You don't have to reinvent the solution, NetBSD already/still has the answer. Regards, Keve From owner-freebsd-net@FreeBSD.ORG Fri Jun 29 20:50:14 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEC0E16A41F for ; Fri, 29 Jun 2007 20:50:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 52CC613C483 for ; Fri, 29 Jun 2007 20:50:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l5TKoE29045952 for ; Fri, 29 Jun 2007 20:50:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5TKoDP0045950; Fri, 29 Jun 2007 20:50:14 GMT (envelope-from gnats) Date: Fri, 29 Jun 2007 20:50:14 GMT Message-Id: <200706292050.l5TKoDP0045950@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Nagy Keve Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nagy Keve List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2007 20:50:14 -0000 The following reply was made to PR kern/112654; it has been noted by GNATS. From: Nagy Keve To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 Date: Fri, 29 Jun 2007 22:21:39 +0200 I ran a few tests today. Tried a Gentoo Linux LiveCD, NetBSD Live! 2007 live-CD (based on NetBSD 4.0 BETA) and OpenBSD 4.1. Each of these loaded the pcn card driver with the cable being plugged in, no errors reported, no kernel panics. Regards, Keve From owner-freebsd-net@FreeBSD.ORG Sat Jun 30 09:01: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 5B3EC16A400 for ; Sat, 30 Jun 2007 09:01:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 2A2F513C447 for ; Sat, 30 Jun 2007 09:01:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id j37so1519929waf for ; Sat, 30 Jun 2007 02:01:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=qUeQN6V/2OilRUZ4zoDN1HAKO7ptxUkyJFf3vzfFuxyaO5fxoJE6y0y64zCiZiioqvfWvJGmvTGZGFv+WZnBhojXCF4WhatWoX8s1N0n7Qg/ljOcUyF+EwTkHV0URqBNHcPLdocsuqL40zkh3vuNirepjYzsLz4tK2sHNEJi5Uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=N7h6dEQbI69nWwhWhCDDZsMYK22jZzXH9JDDZFWJRshYcboUBRPfD6HMMu+IvdbSPv7gOP0YbRCj8FW+10+j5zNns4q2liwARgPBI7KEz7LTwyd4Zo+xWHawd3I6S9Jj9gPRc9bjMdxjKXuhRUVY9U9ToqRI9addE9u9NwCUAXw= Received: by 10.115.111.1 with SMTP id o1mr3334320wam.1183194082610; Sat, 30 Jun 2007 02:01:22 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id m40sm10828448waf.2007.06.30.02.01.20 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jun 2007 02:01:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l5U91Gkd058668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jun 2007 18:01:16 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l5U91F2B058667; Sat, 30 Jun 2007 18:01:15 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 30 Jun 2007 18:01:15 +0900 From: Pyun YongHyeon To: W Forms Message-ID: <20070630090115.GA56970@cdnetworks.co.kr> References: <200706292020.l5TKK8aL041447@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <200706292020.l5TKK8aL041447@freefall.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/112710: [re] if_re driver detects incorrect b243a405a405 MAC address on SMC9452TX-1 pci gigabit cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2007 09:01:23 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 29, 2007 at 08:20:08PM +0000, W Forms wrote: > The following reply was made to PR kern/112710; it has been noted by GNATS. > > From: W Forms > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/112710: [re] if_re driver detects incorrect b243a405a405 MAC address on SMC9452TX-1 pci gigabit cards > Date: Fri, 29 Jun 2007 22:16:23 +0200 > > Today I run a test using the "NetBSD Live! 2007" live-CD, which is > apparently based on NetBSD 4.0 BETA. > NetBSD also uses the re driver for these cards. Upon boot all the "5 > bad cards" are detected as RealTek 8169SB gigabit adapters and > believe or not, each and every single adapter uses its own correct > MAC address. > SO whatever the problem is in the FreeBSD and OpenBSD re driver, the > NetBSD guys have already solved it. Or, they didn't scew it up in the > first place! :-) > Either way, it might be worthwile talking to them about this defect > or having a thorough look at their re driver code (or the code of any > related networking module). > I also run a test with a Gentoo Linux Live CD which also uses the > correct MAC addresses. > Unfortunately this is where my abilities stop. > > Somebody, Please! > You don't have to reinvent the solution, NetBSD already/still has the > answer. > How about attached patch? -- Regards, Pyun YongHyeon --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.eeprom.patch" Index: if_re.c =================================================================== RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v retrieving revision 1.90 diff -u -r1.90 if_re.c --- if_re.c 16 Jun 2007 02:54:19 -0000 1.90 +++ if_re.c 30 Jun 2007 08:58:13 -0000 @@ -1211,10 +1211,10 @@ hw_rev++; } - sc->rl_eewidth = 6; + sc->rl_eewidth = RL_9356_ADDR_LEN; re_read_eeprom(sc, (caddr_t)&re_did, 0, 1); if (re_did != 0x8129) - sc->rl_eewidth = 8; + sc->rl_eewidth = RL_9346_ADDR_LEN; /* * Get station address from the EEPROM. Index: ../../pci/if_rlreg.h =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rlreg.h,v retrieving revision 1.65 diff -u -r1.65 if_rlreg.h --- ../../pci/if_rlreg.h 18 Apr 2007 00:40:43 -0000 1.65 +++ ../../pci/if_rlreg.h 30 Jun 2007 08:58:13 -0000 @@ -312,6 +312,8 @@ #define RL_EEMODE_WRITECFG (0x80|0x40) /* 9346 EEPROM commands */ +#define RL_9346_ADDR_LEN 6 /* 93C46 1K: 128x16 */ +#define RL_9356_ADDR_LEN 8 /* 93C56 2K: 256x16 */ #define RL_9346_WRITE 0x5 #define RL_9346_READ 0x6 --45Z9DzgjV8m4Oswq-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 30 09:30:09 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 7AFF016A400 for ; Sat, 30 Jun 2007 09:30:09 +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 5EE6613C45A for ; Sat, 30 Jun 2007 09:30:09 +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 l5U9U8EH018500 for ; Sat, 30 Jun 2007 09:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l5U9U8gT018499; Sat, 30 Jun 2007 09:30:08 GMT (envelope-from gnats) Date: Sat, 30 Jun 2007 09:30:08 GMT Message-Id: <200706300930.l5U9U8gT018499@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pyun YongHyeon Cc: Subject: Re: kern/112710: [re] if_re driver detects incorrect b243a405a405 MAC address on SMC9452TX-1 pci gigabit cards X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pyun YongHyeon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2007 09:30:09 -0000 The following reply was made to PR kern/112710; it has been noted by GNATS. From: Pyun YongHyeon To: W Forms Cc: freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: kern/112710: [re] if_re driver detects incorrect b243a405a405 MAC address on SMC9452TX-1 pci gigabit cards Date: Sat, 30 Jun 2007 18:01:15 +0900 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 29, 2007 at 08:20:08PM +0000, W Forms wrote: > The following reply was made to PR kern/112710; it has been noted by GNATS. > > From: W Forms > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/112710: [re] if_re driver detects incorrect b243a405a405 MAC address on SMC9452TX-1 pci gigabit cards > Date: Fri, 29 Jun 2007 22:16:23 +0200 > > Today I run a test using the "NetBSD Live! 2007" live-CD, which is > apparently based on NetBSD 4.0 BETA. > NetBSD also uses the re driver for these cards. Upon boot all the "5 > bad cards" are detected as RealTek 8169SB gigabit adapters and > believe or not, each and every single adapter uses its own correct > MAC address. > SO whatever the problem is in the FreeBSD and OpenBSD re driver, the > NetBSD guys have already solved it. Or, they didn't scew it up in the > first place! :-) > Either way, it might be worthwile talking to them about this defect > or having a thorough look at their re driver code (or the code of any > related networking module). > I also run a test with a Gentoo Linux Live CD which also uses the > correct MAC addresses. > Unfortunately this is where my abilities stop. > > Somebody, Please! > You don't have to reinvent the solution, NetBSD already/still has the > answer. > How about attached patch? -- Regards, Pyun YongHyeon --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.eeprom.patch" Index: if_re.c =================================================================== RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v retrieving revision 1.90 diff -u -r1.90 if_re.c --- if_re.c 16 Jun 2007 02:54:19 -0000 1.90 +++ if_re.c 30 Jun 2007 08:58:13 -0000 @@ -1211,10 +1211,10 @@ hw_rev++; } - sc->rl_eewidth = 6; + sc->rl_eewidth = RL_9356_ADDR_LEN; re_read_eeprom(sc, (caddr_t)&re_did, 0, 1); if (re_did != 0x8129) - sc->rl_eewidth = 8; + sc->rl_eewidth = RL_9346_ADDR_LEN; /* * Get station address from the EEPROM. Index: ../../pci/if_rlreg.h =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rlreg.h,v retrieving revision 1.65 diff -u -r1.65 if_rlreg.h --- ../../pci/if_rlreg.h 18 Apr 2007 00:40:43 -0000 1.65 +++ ../../pci/if_rlreg.h 30 Jun 2007 08:58:13 -0000 @@ -312,6 +312,8 @@ #define RL_EEMODE_WRITECFG (0x80|0x40) /* 9346 EEPROM commands */ +#define RL_9346_ADDR_LEN 6 /* 93C46 1K: 128x16 */ +#define RL_9356_ADDR_LEN 8 /* 93C56 2K: 256x16 */ #define RL_9346_WRITE 0x5 #define RL_9346_READ 0x6 --45Z9DzgjV8m4Oswq-- From owner-freebsd-net@FreeBSD.ORG Sat Jun 30 09:44:35 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 3AB4A16A468 for ; Sat, 30 Jun 2007 09:44:35 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 42BA913C458 for ; Sat, 30 Jun 2007 09:44:34 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so266184anc for ; Sat, 30 Jun 2007 02:44:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Dqhe5lA9/KYwW3J/Bo1nTNPuQgKUhflDCID9evQXQalfeDUAFDwL6vMlDl3ixXq+gYinZxaohbqAu6vqBl6Oc3t/9UZpe22xf/Mg8HkHiSmtG7zsgHq30+zNS+ww95ZkKMVsu+RFtgWdbxbKXzhY8T224DSs+piHQhyb2ijSW/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BtV4Lwv3gBAuG/2a04xgIqZBGEbmWsAbvUjFwL8Zr+tGso/ikfTF8ENHbOWM5vP+VvxmeQnXeoOnsl0rIxyIiR7GE9IFHywNeExM41HfuhYXLvseAGSWKwni4jIwiAn38iGxvrqgcKEA+vvGsQpbcVFgtr9PEd9NsIcUjW+5NNY= Received: by 10.100.128.8 with SMTP id a8mr2632032and.1183196672832; Sat, 30 Jun 2007 02:44:32 -0700 (PDT) Received: by 10.100.47.5 with HTTP; Sat, 30 Jun 2007 02:44:32 -0700 (PDT) Message-ID: Date: Sat, 30 Jun 2007 17:44:32 +0800 From: "Sepherosa Ziehau" To: "Tom Judge" In-Reply-To: <4684D5C0.3040709@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46680DB1.9050905@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030414B1EC@NT-IRVA-0750.brcm.ad.broadcom.com> <466873FA.9030800@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD9030423EE13@NT-IRVA-0750.brcm.ad.broadcom.com> <46823A78.7020501@tomjudge.com> <4683C578.6070009@tomjudge.com> <09BFF2FA5EAB4A45B6655E151BBDD90304571430@NT-IRVA-0750.brcm.ad.broadcom.com> <09BFF2FA5EAB4A45B6655E151BBDD903045714EF@NT-IRVA-0750.brcm.ad.broadcom.com> <4684D5C0.3040709@tomjudge.com> Cc: freebsd-net , David Christensen Subject: Re: Problems with BCE network adapter (Dell PE2950) 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, 30 Jun 2007 09:44:35 -0000 Sorry for the top post, please try following patch: http://people.freebsd.org/~sephe/if_bce.c.diff This is probably the cause; I noticed it when bce(4) was ported to DragonFly. Best Regards, sephe On 6/29/07, Tom Judge wrote: > David Christensen wrote: > >>>> Sorry for the top post, but I have just managed to repeat is > >>>> exact crash > >>>> twice on a new PE 1950 system. I have core files available. > >>>> > >>>> It seems that after a couple of reboots the problem goes > >> away. The > >>>> system actually crashed 4 times but 2 of the cores where corrupt. > >>>> > >>>> It also seems that the system will be stable if the following > >>>> message is > >>>> not produced shortly after /etc/rc.d/netif start: > >>>> > >>>> bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free > >>>> rx_bd (0xFFF9 > > >>>> 0x01FE)! > >>>> > >>> The error indicates that too many receive buffer descriptors > >>> were freed from the receive chain. The driver must be losing > >>> count somewhere. The process for duplicating the error sounds > >>> simple enough, how much data is in your NFS mounted directory? > >>> Are you using TCP or UDP for the NFS mount? > >>> > >>> Any idea what type of network activity is happening just after > >>> /etc/rc.d/netif start (DHCP, NTP, anything else)? > >>> > >>> Dave > >> One other thing, are you using jumbo frames? What's your MTU setting? > >> > > > > And one more thing. I've been passing line rate traffic for a few > > hours (with both netperf running the tcp_stream_script and a constant > > stream of UDP traffic to the discard server on the FreeBSD system) > > and I haven't seen a hiccup yet on the tip of RELENG_6 with jumbo > > frames enabled on my Dell PE2950 (one dual-core CPU, 4GB RAM). Of > > course I don't have any real services running on it (load average is > > 0.19). Any unusual settings I should be aware of? > > > > Does anyone know a simple way to drive up CPU utilization and consume > > large amounts of memory to try and simulate a heavily loaded system? > > > > Dave > > > > Hi, > > As the NIC's are coming UP (as indicated by messages on the console) the > system is trying to mount NFS file systems. At this stage if the system > does not produce the "Too many free rx_bd" error the system will be stable. > > We are using Jumbo Frames with an MTU of 8192. The switches are Dell > PowerConnect 5324's. The NFS server is a Dell PE1850 with EM cards. > > The bug can be triggered by NFS data (there was arround 600Mb of data in > the directory that I ran "cat * > /dev/null" in). Also the bug can be > triggered by heavy rsync traffic. (Rsync over ssh where the box crashing > is the SSH client, also SSH has the HPN patches applied to it.) > > The box that crashed 4 times did so in the following sequence: > > 1) First boot with debug driver crash very shortly after nfs mounts > start/complete (Corrupt dump). "Too many free rx_bd" message is present > on the console before the crash. > > 2) Second boot with the debug driver system does not crash after cat * > over NFS. Crashes a few minutes after starting a rsync from an > identical PE1950 the system crashed (Again producing a corrupt core > dump). "Too many free rx_bd" message is present on the console before > the crash. > > 3) Third boot NFS crash was not tested. Restarted rsync process and the > system crashed again. (Core ok this time but log buffer not present in > the dump, or was empty.) Back trace indicates the driver crashed the > system at the same place as the next crash on this system and the only > core I have from a PE2950. "Too many free rx_bd" message is present on > the console before the crash. > > 4) Fourth boot again did not test the NFS crash. Restarted the rsync > process causing the system to crash. ( Core and log buffer present in > core, buffer and back trace at the end of this email.) "Too many free > rx_bd" message is present on the console before the crash. > > 5) Fifth boot of the system. No "Too many free rx_bd" messages appear > on the console. The system rsync's ~290Gb of data and is still up. > > At each reboot the system was just left to reboot itself the system was > not powered off at any point. I have a PE2950 that went through a > similar cycle of crashes only to boot into a stable configuration 3-4 > reboots later. (I have the last core available from this system.) > > > The system crashing above is a PE1950 with 1 5110 1.6Ghz Dual Core Xeon, > 2Gb RAM, PREC5/i (2 * 80 Gb SATA RAID 1), PERC5/e (MD1000 3 * 500Gb SATA > RAID 5). The source of the data being rsynced was an identical system. > > > I have attached the patch for the driver we are running (patch is > against RELENG_6_2). > > > Tom > root@sultan '10:48:28' '/var/crash' > > $ ifconfig bce0 > bce0: flags=8843 mtu 8192 > options=3b > inet 172.31.0.28 netmask 0xffffff00 broadcast 172.31.0.255 > ether 00:19:b9:e4:4d:cc > media: Ethernet autoselect (1000baseTX ) > status: active > > > root@sultan '10:48:34' '/var/crash' > > $ pciconf -lv | fgrep -A 3 bce0 > bce0@pci9:0:0: class=0x020000 card=0x01b31028 chip=0x164c14e4 rev=0x12 > hdr=0x00 > vendor = 'Broadcom Corporation' > class = network > subclass = ethernet > > > root@sultan '10:47:08' '/var/crash' > > $ kgdb /usr/obj/usr/src/sys/PE2950/kernel.debug vmcore.3 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd". > > Unread portion of the kernel message buffer: > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFF > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFF > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFF > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFE > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFD > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFD > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFD > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFD > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFD > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFC > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFC > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFC > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFFB > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3489): Too many free rx_bd (0xFFF9 > > 0x01FE)! > bce0: /usr/src/sys/dev/bce/if_bce.c(3973): Unexpected mbuf found in > rx_bd[0x0098]! > bce0: ---------------------------- Driver State > ---------------------------- > bce0: 0xFFFFFFFF:866A6000 - (sc) driver softc structure virtual address > bce0: 0xFFFFFF00:F4000000 - (sc->bce_vhandle) PCI BAR virtual address > bce0: 0xFFFFFF00:009C3DC0 - (sc->status_block) status block virtual address > bce0: 0xFFFFFF00:009D7400 - (sc->stats_block) statistics block virtual > address > bce0: 0xFFFFFFFF:866A61B0 - (sc->tx_bd_chain) tx_bd chain virtual adddress > bce0: 0xFFFFFFFF:866A61E8 - (sc->rx_bd_chain) rx_bd chain virtual address > bce0: 0xFFFFFFFF:866A7260 - (sc->tx_mbuf_ptr) tx mbuf chain virtual address > bce0: 0xFFFFFFFF:866A9260 - (sc->rx_mbuf_ptr) rx mbuf chain virtual address > bce0: 0x0006D4FE - (sc->interrupts_generated) h/w intrs > bce0: 0x00039B5F - (sc->rx_interrupts) rx interrupts handled > bce0: 0x000339FB - (sc->tx_interrupts) tx interrupts handled > bce0: 0x0000A413 - (sc->last_status_idx) status block index > bce0: 0x00009500 - (sc->tx_prod) tx producer index > bce0: 0x000094FD - (sc->tx_cons) tx consumer index > bce0: 0x01FC8BFD - (sc->tx_prod_bseq) tx producer bseq index > bce0: 0x0000B69A - (sc->rx_prod) rx producer index > bce0: 0x0000B497 - (sc->rx_cons) rx consumer index > bce0: 0xBF89D400 - (sc->rx_prod_bseq) rx producer bseq index > bce0: 0x000000AB - (sc->rx_mbuf_alloc) rx mbufs allocated > bce0: 0x0000FFF8 - (sc->free_rx_bd) free rx_bd's > bce0: 0x00000000/000001FE - (sc->rx_low_watermark) rx low watermark > bce0: 0x00000002 - (sc->txmbuf_alloc) tx mbufs allocated > bce0: 0x000000AB - (sc->rx_mbuf_alloc) rx mbufs allocated > bce0: 0x00000002 - (sc->used_tx_bd) used tx_bd's > bce0: 0x000001FE/000001FE - (sc->tx_hi_watermark) tx hi watermark > bce0: 0x00000000 - (sc->mbuf_alloc_failed) failed mbuf alloc > bce0: > ------------------------------------------------------------------------ > bce0: ---------------------------- Status Block > ---------------------------- > bce0: attn_bits = 0x00000001, attn_bits_ack = 0x00000001, index = 0xA422 > bce0: rx_cons0 = 0x0000B4BF, tx_cons0 = 0x000094FF > bce0: status_idx = 0xA422 > bce0: > ------------------------------------------------------------------------ > > > Fatal trap 3: breakpoint instruction fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x8:0xffffffff801ee956 > stack pointer = 0x10:0xffffffffb1922b40 > frame pointer = 0x10:0x98 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 21 (irq16: bce0 bce1) > trap number = 3 > panic: breakpoint instruction fault > cpuid = 0 > Uptime: 1h5m39s > Dumping 2047 MB (2 chunks) > chunk 0: 1MB (156 pages) ... ok > chunk 1: 2047MB (523944 pages) 2031 2015 1999 1983 1967 1951 1935 > 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 > 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 > 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 > 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 > 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 > 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 > 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 > 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:172 > 172 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:172 > #1 0x0000000000000004 in ?? () > #2 0xffffffff8029e0e7 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #3 0xffffffff8029e781 in panic (fmt=0xffffff007b9ed720 "\b?\236{") at > /usr/src/sys/kern/kern_shutdown.c:565 > #4 0xffffffff803f9e3f in trap_fatal (frame=0xffffff007b9ed720, > eva=18446742976271936008) at /usr/src/sys/amd64/amd64/trap.c:660 > #5 0xffffffff803fa2e2 in trap (frame= > {tf_rdi = 0, tf_rsi = -2139025408, tf_rdx = 1, tf_rcx = 1298717, > tf_r8 = 1048064, tf_r9 = 10, tf_rax = 79, tf_rbx = -2039848960, tf_rbp = > 152, tf_r10 = -1315820960, tf_r11 = 4294967274, tf_r12 = -2039848960, > tf_r13 = 152, tf_r14 = 46242, tf_r15 = 46232, tf_trapno = 3, tf_addr = > 0, tf_flags = -1099501388352, tf_err = 0, tf_rip = -2145457834, tf_cs = > 8, tf_rflags = 642, tf_rsp = -1315820720, tf_ss = 16}) at > /usr/src/sys/amd64/amd64/trap.c:469 > #6 0xffffffff803e55fb in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:168 > #7 0xffffffff801ee956 in bce_breakpoint (sc=0xffffffff866a6000) at > cpufunc.h:63 > #8 0xffffffff801ef0f6 in bce_intr (xsc=0x0) at > /usr/src/sys/dev/bce/if_bce.c:3970 > #9 0xffffffff80284919 in ithread_loop (arg=0xffffff00009d35a0) at > /usr/src/sys/kern/kern_intr.c:682 > #10 0xffffffff802830b7 in fork_exit (callout=0xffffffff802847d0 > , arg=0xffffff00009d35a0, frame=0xffffffffb1922c50) at > /usr/src/sys/kern/kern_fork.c:821 > #11 0xffffffff803e595e in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:394 > #12 0x0000000000000000 in ?? () > #13 0x0000000000000000 in ?? () > #14 0x0000000000000001 in ?? () > #15 0x0000000000000000 in ?? () > #16 0x0000000000000000 in ?? () > #17 0x0000000000000000 in ?? () > #18 0x0000000000000000 in ?? () > #19 0x0000000000000000 in ?? () > #20 0x0000000000000000 in ?? () > #21 0x0000000000000000 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x0000000000000000 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000000 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0x0000000000000000 in ?? () > #40 0x0000000000000000 in ?? () > #41 0x0000000000000000 in ?? () > #42 0x0000000000000000 in ?? () > #43 0x0000000000000000 in ?? () > #44 0x00000000007f3000 in ?? () > #45 0xffffff007b9ed720 in ?? () > #46 0xffffff00009d35a0 in ?? () > #47 0x0000000000000001 in ?? () > #48 0xffffff007b9eea08 in ?? () > #49 0xffffff007b9a5980 in ?? () > #50 0xffffffffb1922b58 in ?? () > #51 0xffffff007b9ed720 in ?? () > #52 0xffffffff802b4856 in sched_switch (td=0xffffff00009d35a0, > newtd=0x0, flags=0) at /usr/src/sys/kern/sched_4bsd.c:973 > #53 0x0000000000000000 in ?? () > #54 0x0000000000000000 in ?? () > #55 0x0000000000000000 in ?? () > #56 0x0000000000000000 in ?? () > #57 0x0000000000000000 in ?? () > #58 0x0000000000000000 in ?? () > #59 0x0000000000000000 in ?? () > ---Type to continue, or q to quit--- > #60 0x0000000000000000 in ?? () > #61 0x0000000000000000 in ?? () > #62 0x0000000000000000 in ?? () > #63 0x0000000000000000 in ?? () > #64 0x0000000000000000 in ?? () > #65 0x0000000000000000 in ?? () > #66 0x0000000000000000 in ?? () > #67 0x0000000000000000 in ?? () > #68 0x0000000000000000 in ?? () > #69 0x0000000000000000 in ?? () > #70 0x0000000000000000 in ?? () > #71 0x0000000000000000 in ?? () > #72 0x0000000000000000 in ?? () > #73 0x0000000000000000 in ?? () > #74 0x0000000000000000 in ?? () > #75 0x0000000000000000 in ?? () > #76 0x0000000000000000 in ?? () > #77 0x0000000000000000 in ?? () > #78 0x0000000000000000 in ?? () > #79 0x0000000000000000 in ?? () > #80 0x0000000000000000 in ?? () > #81 0x0000000000000000 in ?? () > #82 0x0000000000000000 in ?? () > #83 0x0000000000000000 in ?? () > #84 0x0000000000000000 in ?? () > #85 0x0000000000000000 in ?? () > #86 0x0000000000000000 in ?? () > #87 0x0000000000000000 in ?? () > #88 0x0000000000000000 in ?? () > #89 0x0000000000000000 in ?? () > #90 0x0000000000000000 in ?? () > #91 0x0000000000000000 in ?? () > #92 0x0000000000000000 in ?? () > #93 0x0000000000000000 in ?? () > #94 0x0000000000000000 in ?? () > #95 0x0000000000000000 in ?? () > #96 0x0000000000000000 in ?? () > #97 0x0000000000000000 in ?? () > #98 0x0000000000000000 in ?? () > #99 0x0000000000000000 in ?? () > #100 0x0000000000000000 in ?? () > #101 0x0000000000000000 in ?? () > #102 0x0000000000000000 in ?? () > #103 0x0000000000000000 in ?? () > #104 0x0000000000000000 in ?? () > #105 0x0000000000000000 in ?? () > #106 0x0000000000000000 in ?? () > #107 0x0000000000000000 in ?? () > #108 0x0000000000000000 in ?? () > #109 0x0000000000000000 in ?? () > #110 0x0000000000000000 in ?? () > #111 0x0000000000000000 in ?? () > #112 0x0000000000000000 in ?? () > #113 0x0000000000000000 in ?? () > #114 0x0000000000000000 in ?? () > #115 0x0000000000000000 in ?? () > #116 0x0000000000000000 in ?? () > #117 0x0000000000000000 in ?? () > #118 0x0000000000000000 in ?? () > #119 0x0000000000000000 in ?? () > #120 0x0000000000000000 in ?? () > #121 0x0000000000000000 in ?? () > #122 0x0000000000000000 in ?? () > ---Type to continue, or q to quit--- > #123 0x0000000000000000 in ?? () > #124 0x0000000000000000 in ?? () > Cannot access memory at address 0xffffffffb1923000 > (kgdb) frame 8 > #8 0xffffffff801ef0f6 in bce_intr (xsc=0x0) at > /usr/src/sys/dev/bce/if_bce.c:3970 > 3970 DBRUNIF((!(rxbd->rx_bd_flags & > RX_BD_FLAGS_END)), > (kgdb) list > 3965 > 3966 /* The mbuf is stored with the last rx_bd entry > of a packet. */ > 3967 if (sc->rx_mbuf_ptr[sw_chain_cons] != NULL) { > 3968 > 3969 /* Validate that this is the last rx_bd. */ > 3970 DBRUNIF((!(rxbd->rx_bd_flags & > RX_BD_FLAGS_END)), > 3971 BCE_PRINTF("%s(%d): Unexpected > mbuf found in rx_bd[0x%04X]!\n", > 3972 __FILE__, __LINE__, sw_chain_cons); > 3973 bce_breakpoint(sc)); > 3974 > (kgdb) > > > > root@sultan '10:50:15' '/var/crash' > > $ sysctl dev.bce.0 > dev.bce.0.%desc: Broadcom NetXtreme II BCM5708 1000Base-T (B2) > dev.bce.0.%driver: bce > dev.bce.0.%location: slot=0 function=0 > dev.bce.0.%pnpinfo: vendor=0x14e4 device=0x164c subvendor=0x1028 > subdevice=0x01b3 class=0x020000 > dev.bce.0.%parent: pci9 > dev.bce.0.rx_low_watermark: 0 > dev.bce.0.tx_hi_watermark: 510 > dev.bce.0.l2fhdr_status_errors: 0 > dev.bce.0.unexpected_attentions: 0 > dev.bce.0.lost_status_block_updates: 0 > dev.bce.0.mbuf_alloc_failed: 0 > dev.bce.0.stat_IfHcInOctets: 306538083283 > dev.bce.0.stat_IfHCInBadOctets: 54437647 > dev.bce.0.stat_IfHCOutOctets: 3416768690 > dev.bce.0.stat_IfHCOutBadOctets: 0 > dev.bce.0.stat_IfHCInUcastPkts: 76567319 > dev.bce.0.stat_IfHCInMulticastPkts: 0 > dev.bce.0.stat_IfHCInBroadcastPkts: 44564 > dev.bce.0.stat_IfHCOutUcastPkts: 44874071 > dev.bce.0.stat_IfHCOutMulticastPkts: 0 > dev.bce.0.stat_IfHCOutBroadcastPkts: 200 > dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 > dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 > dev.bce.0.stat_Dot3StatsFCSErrors: 0 > dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 > dev.bce.0.stat_Dot3StatsSingleCollisionFrames: 0 > dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 > dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 > dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 > dev.bce.0.stat_Dot3StatsLateCollisions: 0 > dev.bce.0.stat_EtherStatsCollisions: 0 > dev.bce.0.stat_EtherStatsFragments: 0 > dev.bce.0.stat_EtherStatsJabbers: 0 > dev.bce.0.stat_EtherStatsUndersizePkts: 0 > dev.bce.0.stat_EtherStatsOverrsizePkts: 0 > dev.bce.0.stat_EtherStatsPktsRx64Octets: 7255 > dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 3084173 > dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 548353 > dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 70953 > dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 7546 > dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 3221 > dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 72890382 > dev.bce.0.stat_EtherStatsPktsTx64Octets: 277 > dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 42379729 > dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 2485130 > dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 727 > dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 709 > dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 853 > dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 6846 > dev.bce.0.stat_XonPauseFramesReceived: 0 > dev.bce.0.stat_XoffPauseFramesReceived: 0 > dev.bce.0.stat_OutXonSent: 0 > dev.bce.0.stat_OutXoffSent: 0 > dev.bce.0.stat_FlowControlDone: 0 > dev.bce.0.stat_MacControlFramesReceived: 0 > dev.bce.0.stat_XoffStateEntered: 0 > dev.bce.0.stat_IfInFramesL2FilterDiscards: 351690 > dev.bce.0.stat_IfInRuleCheckerDiscards: 0 > dev.bce.0.stat_IfInFTQDiscards: 0 > dev.bce.0.stat_IfInMBUFDiscards: 0 > dev.bce.0.stat_IfInRuleCheckerP4Hit: 44564 > dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 > dev.bce.0.stat_CatchupInFTQDiscards: 0 > dev.bce.0.stat_CatchupInMBUFDiscards: 0 > dev.bce.0.stat_CatchupInRuleCheckerP4Hit: 0 > dev.bce.0.com_no_bufers: 0 > dev.bce.0.driver_state: -1 > dev.bce.0.hw_state: -1 > dev.bce.0.dump_rx_chain: -1 > dev.bce.0.dump_tx_chain: -1 > dev.bce.0.breakpoint: -1 > dev.bce.0.reg_read: -1 > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -- Live Free or Die