From owner-freebsd-net@FreeBSD.ORG Sun Mar 26 06:11:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF89C16A401 for ; Sun, 26 Mar 2006 06:11:16 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DB2F43D46 for ; Sun, 26 Mar 2006 06:11:16 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.res.rr.com [24.211.118.154]) by ms-smtp-01-eri0.southeast.rr.com (8.13.4/8.13.4) with ESMTP id k2Q6BAU1004346; Sun, 26 Mar 2006 01:11:11 -0500 (EST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.13.4/8.13.4) with ESMTP id k2Q6B9cF068389; Sun, 26 Mar 2006 01:11:10 -0500 (EST) (envelope-from morganw@chemikals.org) Date: Sun, 26 Mar 2006 01:11:09 -0500 (EST) From: Wesley Morgan To: Fabian Keil In-Reply-To: <20060325181246.09a6ad58@localhost> Message-ID: <20060326011024.Y31710@volatile.chemikals.org> References: <20060325101440.S31710@volatile.chemikals.org> <20060325181246.09a6ad58@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-net@freebsd.org Subject: Re: Intel 3945ABG with NDIS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2006 06:11:16 -0000 On Sat, 25 Mar 2006, Fabian Keil wrote: > Wesley Morgan wrote: > >> Has anyone been successful with one of these cards and the >> ndisulator? I can get the wrapper to attach the device, but it won't >> accept an SSID being assigned via ifconfig (or anything else for that >> matter), and wpa_supplicant also fails. > > Try to set the ssid together with the bssid. The interface will take the bssid but still has no effect on the ssid. -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sun Mar 26 09:54:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6035F16A400 for ; Sun, 26 Mar 2006 09:54:54 +0000 (UTC) (envelope-from aymeric.muntz@free.fr) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id F10A743D46 for ; Sun, 26 Mar 2006 09:54:53 +0000 (GMT) (envelope-from aymeric.muntz@free.fr) Received: from Cerbere-de-Troyes.cerbere23.com (eur10-1-82-241-181-23.fbx.proxad.net [82.241.181.23]) by smtp4-g19.free.fr (Postfix) with ESMTP id 1BFD5546D8 for ; Sun, 26 Mar 2006 11:54:52 +0200 (CEST) Received: from artemis ([192.168.2.2]) by Cerbere-de-Troyes.cerbere23.com (8.13.3/8.13.3) with SMTP id k2Q9sqRA066537 for ; Sun, 26 Mar 2006 11:54:52 +0200 (CEST) (envelope-from aymeric.muntz@free.fr) From: "Aymeric MUNTZ" To: Date: Sun, 26 Mar 2006 11:55:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Subject: PPP + Radius pbm X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2006 09:54:54 -0000 Hi, I use freeradius + pppd. The thing is that I want to use the RAD_FILTER_ID attribute send by radius. I got it perfectly and use it in my ppp.linkup as label. What I want is use this value in a script. The value of this label can be almost anything. So it is dofficult to modify my ppp.linkup as this: ___ |1: | bg test.sh |2: | bg test.sh |... |1024: | bg test.sh |___ I would like something more like: ___ |*: | bg test.sh LABEL |___ But: 1) "*:" dosen't work 2) LABEL contain the value of the label specified in ppp.conf How can I do what I want? cheers Alex From owner-freebsd-net@FreeBSD.ORG Sun Mar 26 11:17:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC32616A420 for ; Sun, 26 Mar 2006 11:17:02 +0000 (UTC) (envelope-from alexandre.delay@free.fr) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58D7A43D45 for ; Sun, 26 Mar 2006 11:17:02 +0000 (GMT) (envelope-from alexandre.delay@free.fr) Received: from Cerbere-de-Troyes.cerbere23.com (eur10-1-82-241-181-23.fbx.proxad.net [82.241.181.23]) by smtp6-g19.free.fr (Postfix) with ESMTP id 6F30617D7B for ; Sun, 26 Mar 2006 13:17:01 +0200 (CEST) Received: from artemis ([192.168.2.2]) by Cerbere-de-Troyes.cerbere23.com (8.13.3/8.13.3) with SMTP id k2QBH05V066981 for ; Sun, 26 Mar 2006 13:17:01 +0200 (CEST) (envelope-from alexandre.delay@free.fr) From: "Alexandre DELAY" To: Date: Sun, 26 Mar 2006 13:17:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Subject: PPP + Radius pbm X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2006 11:17:02 -0000 Hi, I use freeradius + pppd. The thing is that I want to use the RAD_FILTER_ID attribute send by radius. I got it perfectly and use it in my ppp.linkup as label. What I want is use this value in a script. The value of this label can be almost anything. So it is dofficult to modify my ppp.linkup as this: ___ |1: | bg test.sh |2: | bg test.sh |... |1024: | bg test.sh |___ I would like something more like: ___ |*: | bg test.sh LABEL |___ But: 1) "*:" dosen't work 2) LABEL contain the value of the label specified in ppp.conf How can I do what I want? cheers Alex From owner-freebsd-net@FreeBSD.ORG Sun Mar 26 14:30:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F35016A422 for ; Sun, 26 Mar 2006 14:30:14 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F4E243D62 for ; Sun, 26 Mar 2006 14:30:06 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 6237 invoked from network); 26 Mar 2006 14:30:04 -0000 Received: from unknown (HELO localhost) ([pbs]775067@[217.50.148.160]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 26 Mar 2006 14:30:04 -0000 Date: Sun, 26 Mar 2006 16:29:34 +0200 From: Fabian Keil To: Wesley Morgan Message-ID: <20060326162934.32d87841@localhost> In-Reply-To: <20060326011024.Y31710@volatile.chemikals.org> References: <20060325101440.S31710@volatile.chemikals.org> <20060325181246.09a6ad58@localhost> <20060326011024.Y31710@volatile.chemikals.org> X-Mailer: Sylpheed-Claws 2.0.0 (GTK+ 2.8.6; i386-portbld-freebsd6.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2006-08-19.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_6+E3pzqKKU7MA92LPoqAaMl; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-net@freebsd.org Subject: Re: Intel 3945ABG with NDIS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2006 14:30:14 -0000 --Sig_6+E3pzqKKU7MA92LPoqAaMl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Wesley Morgan wrote: > On Sat, 25 Mar 2006, Fabian Keil wrote: >=20 > > Wesley Morgan wrote: > > > >> Has anyone been successful with one of these cards and the > >> ndisulator? I can get the wrapper to attach the device, but it > >> won't accept an SSID being assigned via ifconfig (or anything else > >> for that matter), and wpa_supplicant also fails. > > > > Try to set the ssid together with the bssid. >=20 > The interface will take the bssid but still has no effect on the ssid. Has ndis0 been touched with ifconfig before? After (re)booting I can use ifconfig ndis0 ssid $SSID bssid $BSSID up at least once to set the ssid, but sometimes changing the ssid later has no effect and reloading all the modules doesn't make a difference either. OTOH I have a PRO/Wireless 2200BG Network Connection and maybe it's an entirely different problem. Fabian --=20 http://www.fabiankeil.de/ --Sig_6+E3pzqKKU7MA92LPoqAaMl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEJqVVjV8GA4rMKUQRAn6XAJ9gKc6dB4QWCIYQ3/P8Wo0eC8KXwwCg00aC CZYhj4u/2F7GiwKqUh5m9bY= =0h+d -----END PGP SIGNATURE----- --Sig_6+E3pzqKKU7MA92LPoqAaMl-- From owner-freebsd-net@FreeBSD.ORG Sun Mar 26 14:44:57 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6417B16A420 for ; Sun, 26 Mar 2006 14:44:57 +0000 (UTC) (envelope-from barney@databus.com) Received: from pit.databus.com (p72-0-224-2.acedsl.com [72.0.224.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id F377243D48 for ; Sun, 26 Mar 2006 14:44:56 +0000 (GMT) (envelope-from barney@databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.13.4/8.13.4) with ESMTP id k2QEitLW005287 for ; Sun, 26 Mar 2006 09:44:55 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.13.4/8.13.4/Submit) id k2QEitVY005286 for net@freebsd.org; Sun, 26 Mar 2006 09:44:55 -0500 (EST) (envelope-from barney) Date: Sun, 26 Mar 2006 09:44:55 -0500 From: Barney Wolff To: net@freebsd.org Message-ID: <20060326144455.GA2856@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Scanned-By: MIMEDefang 2.53 on 66.114.72.185 Cc: Subject: [braden@ISI.EDU: Re: [e2e] Can we revive T/TCP ?] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2006 14:44:57 -0000 Perhaps of some relevance ... At least two of the negatives apply to any conceivable t/tcp replacement. ----- Forwarded message from Bob Braden ----- X-Sender: braden@boreas.isi.edu (Unverified) Date: Fri, 24 Mar 2006 11:11:15 -0800 To: Michael Welzl From: Bob Braden In-Reply-To: <001301c60a4a$9831dc60$0200a8c0@fun> Cc: end2end-interest@postel.org Subject: Re: [e2e] Can we revive T/TCP ? At 07:31 PM 12/26/2005 +0100, Michael Welzl wrote: >Hi everybody, > >Here's something that I've had on my mind for quite a while now: >I'm wondering why T/TCP ( RFC 1644 ) failed. I mean, nobody seems >to use it. I believe someone explained this to me once (perhaps even >on this list? but I couldn't find this in the archives...), saying that >there >were security concerns with it, but I don't remember any other details. As the designer of T/TCP, I think I can answer this. There are three reasons, I believe. (1) There are very few situations in which single-packet exchanges are possible, so T/TCP is very seldom a significant performance improvement. But it does have significant complexity. (2) Since the server is asked to do a perhaps signficant computation before the 3WHS has completed, it is an open invitation to DoS attacks. (This would be OK if you could assume that all T/TCP clients were authenticated using IPsec,) (3) I have heard rumors that someone has found an error in the specific state transitions, of T/TCP although I have never seen the details. Bob Braden ----- End forwarded message ----- -- Barney Wolff http://www.databus.com/bwresume.pdf I never met a computer I didn't like. From owner-freebsd-net@FreeBSD.ORG Mon Mar 27 11:03:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E58D16A400 for ; Mon, 27 Mar 2006 11:03:00 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4ADD43D46 for ; Mon, 27 Mar 2006 11:02:59 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2RB2xOj062293 for ; Mon, 27 Mar 2006 11:02:59 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2RB2wFF062287 for freebsd-net@freebsd.org; Mon, 27 Mar 2006 11:02:58 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 27 Mar 2006 11:02:58 GMT Message-Id: <200603271102.k2RB2wFF062287@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2006 11:03:00 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro f [2006/02/12] kern/93220 net [inet6] nd6_lookup: failed to add route f 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 27 13:02:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFA4516A420 for ; Mon, 27 Mar 2006 13:02:57 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2904C43D49 for ; Mon, 27 Mar 2006 13:02:56 +0000 (GMT) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from [192.168.2.10] ([192.168.2.10]) by mail1.cil.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Mar 2006 15:02:54 +0200 Message-ID: <4427E27D.4000005@ide.resurscentrum.se> Date: Mon, 27 Mar 2006 15:02:53 +0200 From: Jon Otterholm User-Agent: Thunderbird 1.5 (X11/20060204) 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: 27 Mar 2006 13:02:54.0192 (UTC) FILETIME=[C2D2DF00:01C6519E] Subject: net.link.ether.inet.proxyall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2006 13:02:57 -0000 Hi. Has anyone information about the sysctl "net.link.ether.inet.proxyall" ? Is this a global ARP-Proxy? Does it apply on a bridge or if_bridge? /Jon From owner-freebsd-net@FreeBSD.ORG Mon Mar 27 14:00:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 749E216A400; Mon, 27 Mar 2006 14:00:17 +0000 (UTC) (envelope-from kaakun@highway.ne.jp) Received: from mx.highway.ne.jp (pip7.gate01.com [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 077AC43D49; Mon, 27 Mar 2006 14:00:16 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.0.96.106] (helo=[192.168.11.17]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1FNsGU-0004u0-Fe; Mon, 27 Mar 2006 23:00:14 +0900 Message-ID: <4427EEA0.3040603@highway.ne.jp> Date: Mon, 27 Mar 2006 22:54:40 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gabor MICSKO References: <1143058963.6826.11.camel@alderaan.trey.hu> In-Reply-To: <1143058963.6826.11.camel@alderaan.trey.hu> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: requests for mbufs denied X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2006 14:00:17 -0000 Gabor MICSKO wrote: > Hi! > > I have a relative high traffic server, running Apache, MySQL and Drupal. > With FreeBSD 6.0 and 6.1-PRERELEASE i got some distressing "netstat -m" > outputs. > > Can anybody explain for me what does this message mean exactly? > > "16064849/9164254/9384500 requests for mbufs denied (mbufs/clusters/mbuf > +clusters)" > > And what can i do with this? > > Full "netstat -m" output: > > $ netstat -m > 445/695/1140 mbufs in use (current/cache/total) > 407/255/662/65536 mbuf clusters in use (current/cache/total/max) > 407/237 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) > 925K/683K/1609K bytes allocated to network (current/cache/total) > 16064849/9164254/9384500 requests for mbufs denied (mbufs/clusters/mbuf > +clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 33/964/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 56067 requests for I/O initiated by sendfile > 5500 calls to protocol drain routines > > > Sorry for my bad english. > > Thank you! > > In my case, that happens when the number of free pages become less than vm.v_free_min. In such case, we drain cached buckets from zones (including mbuf zone) to the system to get more free pages, and disable bucket allocation. As the result, we cannot get a bucket when freeing a mbuf to the zone and just do internal free, counting up the number of allocation failure, i.e. the number of "requests for mbufs denied". I don't know whether this (as to counting up the number of failure in such case) is expected or not. -- Kazuaki Oda From owner-freebsd-net@FreeBSD.ORG Mon Mar 27 14:12:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED3C316A41F for ; Mon, 27 Mar 2006 14:12:38 +0000 (UTC) (envelope-from aymeric.muntz@free.fr) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DFB443D48 for ; Mon, 27 Mar 2006 14:12:38 +0000 (GMT) (envelope-from aymeric.muntz@free.fr) Received: from Cerbere-de-Troyes.cerbere23.com (eur10-1-82-241-181-23.fbx.proxad.net [82.241.181.23]) by smtp5-g19.free.fr (Postfix) with ESMTP id 8A0C127492 for ; Mon, 27 Mar 2006 16:12:37 +0200 (CEST) Received: from artemis ([192.168.2.2]) by Cerbere-de-Troyes.cerbere23.com (8.13.3/8.13.3) with SMTP id k2RECb13079897 for ; Mon, 27 Mar 2006 16:12:37 +0200 (CEST) (envelope-from aymeric.muntz@free.fr) From: "Aymeric MUNTZ" To: Date: Mon, 27 Mar 2006 16:13:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Importance: Normal Subject: PAM + radius X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2006 14:12:39 -0000 Hello, I'm trying to set authentication against Radius on my box. I modified my /etc/pam.d/telnetd file for: ___ |auth required pam_radius.so conf=/etc/radius.conf |account required pam_radius.so |session required pam_lastlog.so no_fail |password required pam_radius.so no_warn try_first_pass |___ It seams that id does nothing. 1) How can I set it correctly working? 2) How do I define users and groups? I guess that it is not enough to set it in the radius server. Moreover, I don't want to grant access to every user in my radius database. Do you know a good documentation about that? Thanks Cheers Alex From owner-freebsd-net@FreeBSD.ORG Mon Mar 27 14:38:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5B9416A502 for ; Mon, 27 Mar 2006 14:38:20 +0000 (UTC) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE11E43D4C for ; Mon, 27 Mar 2006 14:38:19 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id k2REcI4g046431; Mon, 27 Mar 2006 17:38:18 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ip.net.ua [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 30202-18; Mon, 27 Mar 2006 17:38:16 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id k2REbrZB046414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Mar 2006 17:37:53 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id k2REcIVk047806; Mon, 27 Mar 2006 17:38:18 +0300 (EEST) (envelope-from ru) Date: Mon, 27 Mar 2006 17:38:18 +0300 From: Ruslan Ermilov To: Jon Otterholm Message-ID: <20060327143818.GB47729@ip.net.ua> References: <4427E27D.4000005@ide.resurscentrum.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZfOjI3PrQbgiZnxM" Content-Disposition: inline In-Reply-To: <4427E27D.4000005@ide.resurscentrum.se> User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at ip.net.ua Cc: freebsd-net@freebsd.org Subject: Re: net.link.ether.inet.proxyall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2006 14:38:20 -0000 --ZfOjI3PrQbgiZnxM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 27, 2006 at 03:02:53PM +0200, Jon Otterholm wrote: > Has anyone information about the sysctl "net.link.ether.inet.proxyall" ?= =20 > Is this a global ARP-Proxy? >=20 It's briefly mentioned in the arp(4) manpage. When enabled, it will ARP-proxy all IPs on the local net who have routes pointing somewhere else, e.g. thru P2P links, well, any other interface actually. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ZfOjI3PrQbgiZnxM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEJ/jaqRfpzJluFF4RAguwAJ9M66TRmD6I/cljNlF4PBX8tHjxYgCfR70Y Qb/BQu/7zfS7YHFcSM1ccTk= =MB2i -----END PGP SIGNATURE----- --ZfOjI3PrQbgiZnxM-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 27 18:00:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B38816A425 for ; Mon, 27 Mar 2006 18:00:53 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unsane.co.uk [62.140.220.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A1AA43D46 for ; Mon, 27 Mar 2006 18:00:52 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (localhost [127.0.0.1]) by unsane.co.uk (8.13.5/8.13.3) with ESMTP id k2RI05Dg084006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Mar 2006 19:00:05 +0100 (BST) (envelope-from jhary@unsane.co.uk) Received: from localhost (jhary@localhost) by unsane.co.uk (8.13.5/8.13.3/Submit) with ESMTP id k2RI05Vl084003; Mon, 27 Mar 2006 19:00:05 +0100 (BST) (envelope-from jhary@unsane.co.uk) Date: Mon, 27 Mar 2006 19:00:05 +0100 (BST) From: Vince Hoffman To: Aymeric MUNTZ In-Reply-To: Message-ID: <20060327184715.H80871@unsane.co.uk> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: PAM + radius X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2006 18:00:53 -0000 On Mon, 27 Mar 2006, Aymeric MUNTZ wrote: > Hello, > > I'm trying to set authentication against Radius on my box. > I modified my /etc/pam.d/telnetd file for: > ___ > |auth required pam_radius.so conf=/etc/radius.conf > |account required pam_radius.so > |session required pam_lastlog.so no_fail > |password required pam_radius.so no_warn > try_first_pass > |___ > > It seams that id does nothing. > > 1) How can I set it correctly working? > 2) How do I define users and groups? I guess that it is not enough to set > it in the radius server. Moreover, I don't want to grant access to every > user in my radius database. Unfortunately its just PAM radius not nss radius so you will need to define all your users and groups on the local machine. The alternative is to use nis (never looked into it) or ldap( freebsd has nss_ldap and pam_ldap in ports.) Otherwise with local users created, setup /etc/radius.conf with the correct info (mine looks like this) auth 12.23.34.45:1645 "FAKEradiusKEY" 4 5 and add a line like auth sufficient pam_radius.so no_warn try_first_pass to the relevent pam file. I use it so I can authenticate against an RSA ACE server. > > Do you know a good documentation about that? A good read of man radius.conf and man pam_radius should be enough. otherwise google is your friend. cheers, Vince > > Thanks > Cheers > > Alex > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Mar 27 19:02:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7275016A401 for ; Mon, 27 Mar 2006 19:02:36 +0000 (UTC) (envelope-from alexandre.delay@free.fr) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05E3E43D55 for ; Mon, 27 Mar 2006 19:02:35 +0000 (GMT) (envelope-from alexandre.delay@free.fr) Received: from Cerbere-de-Troyes.cerbere23.com (eur10-1-82-241-181-23.fbx.proxad.net [82.241.181.23]) by smtp1-g19.free.fr (Postfix) with ESMTP id B543D9AE39; Mon, 27 Mar 2006 21:02:34 +0200 (CEST) Received: from artemis ([192.168.2.2]) by Cerbere-de-Troyes.cerbere23.com (8.13.3/8.13.3) with SMTP id k2RJ2XcB030282; Mon, 27 Mar 2006 21:02:33 +0200 (CEST) (envelope-from alexandre.delay@free.fr) From: "Alexandre DELAY" To: "Vince Hoffman" Date: Mon, 27 Mar 2006 21:02:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <20060327184715.H80871@unsane.co.uk> Importance: Normal Cc: freebsd-net@freebsd.org Subject: RE: PAM + radius X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2006 19:02:36 -0000 I got it, Thanks Alex From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 09:32:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5682E16A400; Tue, 28 Mar 2006 09:32:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4ACE43D48; Tue, 28 Mar 2006 09:32:33 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.180.83] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1FOAYv2ri9-0005dS; Tue, 28 Mar 2006 11:32:29 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Tue, 28 Mar 2006 11:31:22 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6535353.WdSbsXgMfN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200603281131.28240.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Brooks Davis Subject: Interface groups (from OpenBSD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 09:32:34 -0000 --nextPart6535353.WdSbsXgMfN Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, while porting OpenBSD 3.9 (soon to be released) pf I stumbled on interface= =20 groups. This is a mechanism to group arbitrary interfaces into logical=20 groups. It is just naming (not functional change), but it helps to convey= =20 semantic information (e.g. group "LAN", "DMZ" ...) about your interface to= =20 supporting applications. This way you can write a policies for interface=20 group "LAN" and have it applied to all the VLAN interfaces that come and go= =2E =20 Administration is done via ifconfig. We currently have "ifconfig name" whi= ch=20 does part of the job. My question: Does that sound like something interesting for us and should I= go=20 for importing it into FreeBSD proper, or is it not at all interesting and w= e=20 don't want it (in which case I'd hack something up for pf). Technical reasoning: A proper import would add an additional TAILQ link in= to=20 struct ifnet (which is a great deal of ABI change and causes the usual=20 headaches). The hack would use a single void *, but we'd have to pay for t= he=20 additional indirection. Also yet another config tool would be required to= =20 administer the interface <-> group binding. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart6535353.WdSbsXgMfN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEKQJwXyyEoT62BG0RApLBAJ9XCNZefXFhdoOe2ddvvmnw8aERwgCeIojM 4j/m5sU8Qm7OP4FGAKDGMys= =64hZ -----END PGP SIGNATURE----- --nextPart6535353.WdSbsXgMfN-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 17:24:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 894F316A400; Tue, 28 Mar 2006 17:24:47 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 360D944534; Tue, 28 Mar 2006 16:24:32 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k2SGOV0H012071; Tue, 28 Mar 2006 08:24:31 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k2SGOV5c012070; Tue, 28 Mar 2006 08:24:31 -0800 Date: Tue, 28 Mar 2006 08:24:31 -0800 From: Brooks Davis To: Max Laier Message-ID: <20060328162431.GA9637@odin.ac.hmc.edu> References: <200603281131.28240.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <200603281131.28240.max@love2party.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org, Brooks Davis Subject: Re: Interface groups (from OpenBSD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 17:24:48 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 28, 2006 at 11:31:22AM +0200, Max Laier wrote: > Hi, >=20 > while porting OpenBSD 3.9 (soon to be released) pf I stumbled on interfac= e=20 > groups. This is a mechanism to group arbitrary interfaces into logical= =20 > groups. It is just naming (not functional change), but it helps to conve= y=20 > semantic information (e.g. group "LAN", "DMZ" ...) about your interface t= o=20 > supporting applications. This way you can write a policies for interface= =20 > group "LAN" and have it applied to all the VLAN interfaces that come and = go. =20 > Administration is done via ifconfig. We currently have "ifconfig name" w= hich=20 > does part of the job. >=20 > My question: Does that sound like something interesting for us and should= I go=20 > for importing it into FreeBSD proper, or is it not at all interesting and= we=20 > don't want it (in which case I'd hack something up for pf). Sounds like a reasonable feature. I think it's orthogional to renaming. > Technical reasoning: A proper import would add an additional TAILQ link = into=20 > struct ifnet (which is a great deal of ABI change and causes the usual=20 > headaches). The hack would use a single void *, but we'd have to pay for= the=20 > additional indirection. Also yet another config tool would be required t= o=20 > administer the interface <-> group binding. Adding a TAILQ to the end of struct ifnet would not be an ABI change in 6 because drivers don't know or care how big struct ifnet is anymore and I can't think of an implementation where the drive code would need to care. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEKWM+XY6L6fI4GtQRAhoQAJ41pqwaheC1iAd5jcmXk6nPTUQCpACfcYly wiFAsgULr9EQ9ldqSuWYXwg= =X5zs -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 17:36:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ADD116A420 for ; Tue, 28 Mar 2006 17:36:27 +0000 (UTC) (envelope-from cravey@gotbrains.org) Received: from www.gotbrains.org (www2.gotbrains.org [206.180.149.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 854DB44064 for ; Tue, 28 Mar 2006 17:24:18 +0000 (GMT) (envelope-from cravey@gotbrains.org) Received: from pwn.gotbrains.org (206.180.154.175.adsl.hal-pc.org [206.180.154.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.gotbrains.org (Postfix) with ESMTP id CC3F57E85C for ; Tue, 28 Mar 2006 17:24:05 +0000 (UTC) Date: Tue, 28 Mar 2006 11:24:06 -0600 From: "Stephen P. Cravey" To: freebsd-net@freebsd.org Message-Id: <20060328112406.dafa0d4a.cravey@gotbrains.org> X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: IPMI and bge (again) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 17:36:27 -0000 Does anyone have chip documentation on the broadcom BGE chips? I'm having an ongoing issue with IPMI that I'd really like to get resolved. The issue seems to be that during the driver start sequence, a flag is getting set in the chip that's disabling the IPMI passthrough that I need in order for data destined for a second mac address on the interface to recieve packets. Or, a flag that this process needs isn't getting set. Not sure which, but I could really use some help here. Or should I ask the frequent committers to the driver directly? Thank you. PR: kern/79143 kern/88741 From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 20:25:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F47316A400; Tue, 28 Mar 2006 20:25:29 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AB7E43D49; Tue, 28 Mar 2006 20:25:28 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.4/8.13.4) with ESMTP id k2SKPQLI061060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2006 00:25:26 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.4/8.13.4/Submit) id k2SKPP1C061059; Wed, 29 Mar 2006 00:25:25 +0400 (MSD) (envelope-from oleg) Date: Wed, 29 Mar 2006 00:25:25 +0400 From: Oleg Bulyzhin To: "Stephen P. Cravey" Message-ID: <20060328202525.GA60718@lath.rinet.ru> References: <20060328112406.dafa0d4a.cravey@gotbrains.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <20060328112406.dafa0d4a.cravey@gotbrains.org> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, ambrisko@freebsd.org Subject: Re: IPMI and bge (again) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 20:25:29 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 28, 2006 at 11:24:06AM -0600, Stephen P. Cravey wrote: > Does anyone have chip documentation on the broadcom BGE chips? I'm having= an ongoing issue with IPMI that I'd really like to get resolved. The issue= seems to be that during the driver start sequence, a flag is getting set i= n the chip that's disabling the IPMI passthrough that I need in order for d= ata destined for a second mac address on the interface to recieve packets. = Or, a flag that this process needs isn't getting set. Not sure which, but I= could really use some help here.=20 >=20 > Or should I ask the frequent committers to the driver directly? >=20 > Thank you. >=20 > PR: > kern/79143 > kern/88741 > _______________________________________________ > 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" Could you please test attached patch (RELENG_6 version)? It's slightly modi= fied version of Doug Ambrisko (ambrisko@FreeBSD.org) patch (original version didnt work for me: bcm5721 @= hp proliant dl145g2 server). --=20 Oleg. --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEKZu1ryLc73jOEF8RAg0FAJwNuunwktZQeMJWRUW2SpNm8G6pbgCeIZ5D JOnht2A/Al+pES13QoXdCcY= =vqKF -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 20:38:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFB6316A400; Tue, 28 Mar 2006 20:38:49 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [64.174.51.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10F8243D6B; Tue, 28 Mar 2006 20:38:42 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail2.ambrisko.com with ESMTP; 28 Mar 2006 12:38:09 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.11) with ESMTP id k2SKcgem014227; Tue, 28 Mar 2006 12:38:42 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k2SKcguE014226; Tue, 28 Mar 2006 12:38:42 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200603282038.k2SKcguE014226@ambrisko.com> In-Reply-To: <20060328202525.GA60718@lath.rinet.ru> To: Oleg Bulyzhin Date: Tue, 28 Mar 2006 12:38:42 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: "Stephen P. Cravey" , ambrisko@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPMI and bge (again) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 20:38:49 -0000 Oleg Bulyzhin writes: | On Tue, Mar 28, 2006 at 11:24:06AM -0600, Stephen P. Cravey wrote: | > Does anyone have chip documentation on the broadcom BGE chips? I'm having an ongoing issue with IPMI that I'd really like to get resolved. The issue seems to be that during the driver start sequence, a flag is getting set in the chip that's disabling the IPMI passthrough that I need in order for data destined for a second mac address on the interface to recieve packets. Or, a flag that this process needs isn't getting set. Not sure which, but I could really use some help here. | > | > Or should I ask the frequent committers to the driver directly? | > | > Thank you. | > | > PR: | > kern/79143 | > kern/88741 | > _______________________________________________ | | Could you please test attached patch (RELENG_6 version)? It's slightly | modified version of Doug Ambrisko | (ambrisko@FreeBSD.org) patch (original version didnt work for me: | bcm5721 @ hp proliant dl145g2 server). I don't see it attached. I'd like to see your changes and I'd like know of your plans about getting it in. Thanks, Doug A. From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 21:15:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B21A716A401 for ; Tue, 28 Mar 2006 21:15:19 +0000 (UTC) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2889B4442B for ; Tue, 28 Mar 2006 20:56:30 +0000 (GMT) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (unknown [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id 67B9528456 for ; Tue, 28 Mar 2006 20:56:28 +0000 (GMT) Received: by gremlin.foo.is (Postfix, from userid 1000) id 02C3228454; Tue, 28 Mar 2006 20:56:24 +0000 (GMT) Date: Tue, 28 Mar 2006 20:56:24 +0000 From: Baldur Gislason To: freebsd-net@freebsd.org Message-ID: <20060328205624.GZ20678@gremlin.foo.is> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, score=-5.9 required=6.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Subject: 802.3ad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 21:15:19 -0000 Following an unrelated discussion about "interface grouping" in OpenBSD, I'd like to know if there are any known or planned implementations of LACP (802.3ad) interface teaming in FreeBSD? FreeBSD currently has etherchannel support, but to my knowledge that will only work for a link to a single switch and not provide the possibility of having layer 2 resiliance with paths to 2 switches in the same network. Any thoughts on this? Baldur From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 21:15:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A014B16A422; Tue, 28 Mar 2006 21:15:59 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id A722A443D2; Tue, 28 Mar 2006 20:55:30 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.4/8.13.4) with ESMTP id k2SKtF0P061339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2006 00:55:15 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.4/8.13.4/Submit) id k2SKtEgo061338; Wed, 29 Mar 2006 00:55:14 +0400 (MSD) (envelope-from oleg) Date: Wed, 29 Mar 2006 00:55:14 +0400 From: Oleg Bulyzhin To: Doug Ambrisko Message-ID: <20060328205514.GB60718@lath.rinet.ru> References: <20060328202525.GA60718@lath.rinet.ru> <200603282038.k2SKcguE014226@ambrisko.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m51xatjYGsM+13rf" Content-Disposition: inline In-Reply-To: <200603282038.k2SKcguE014226@ambrisko.com> User-Agent: Mutt/1.5.11 Cc: "Stephen P. Cravey" , ambrisko@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPMI and bge (again) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 21:15:59 -0000 --m51xatjYGsM+13rf Content-Type: multipart/mixed; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 28, 2006 at 12:38:42PM -0800, Doug Ambrisko wrote: > Oleg Bulyzhin writes: > | On Tue, Mar 28, 2006 at 11:24:06AM -0600, Stephen P. Cravey wrote: > | > Does anyone have chip documentation on the broadcom BGE chips? I'm=20 > having an ongoing issue with IPMI that I'd really like to get resolved. T= he issue seems to be that during the driver start sequence, a flag is getti= ng set in the chip that's disabling the IPMI passthrough that I need in ord= er for data destined for a second mac address on the interface to recieve p= ackets. Or, a flag that this process needs isn't getting set. Not sure whic= h, but I could really use some help here.=20 > | >=20 > | > Or should I ask the frequent committers to the driver directly? > | >=20 > | > Thank you. > | >=20 > | > PR: > | > kern/79143 > | > kern/88741 > | > _______________________________________________ > |=20 > | Could you please test attached patch (RELENG_6 version)? It's slightly= =20 > | modified version of Doug Ambrisko > | (ambrisko@FreeBSD.org) patch (original version didnt work for me: > | bcm5721 @ hp proliant dl145g2 server). >=20 > I don't see it attached. I'd like to see your changes and I'd like know > of your plans about getting it in. >=20 > Thanks, >=20 > Doug A. Oops... my fault. Should be attached now. --=20 Oleg. --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge_asf.patch" Content-Transfer-Encoding: quoted-printable Index: if_bgereg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.36.2.4 diff -u -r1.36.2.4 if_bgereg.h --- if_bgereg.h 5 Feb 2006 18:07:15 -0000 1.36.2.4 +++ if_bgereg.h 28 Mar 2006 20:18:15 -0000 @@ -74,6 +74,11 @@ #define BGE_SOFTWARE_GENCOMM 0x00000B50 #define BGE_SOFTWARE_GENCOMM_SIG 0x00000B54 #define BGE_SOFTWARE_GENCOMM_NICCFG 0x00000B58 +#define BGE_SOFTWARE_GENCOMM_FW 0x00000B78 +#define BGE_FW_DRV_ALIVE 0x00000001 +#define BGE_FW_PAUSE 0x00000002 +#define BGE_SOFTWARE_GENNCOMM_FW_LEN 0x00000B7C +#define BGE_SOFTWARE_GENNCOMM_FW_DATA 0x00000B80 #define BGE_SOFTWARE_GENCOMM_END 0x00000FFF #define BGE_UNMAPPED 0x00001000 #define BGE_UNMAPPED_END 0x00001FFF @@ -1627,6 +1632,7 @@ #define BGE_MODE_CTL 0x6800 #define BGE_MISC_CFG 0x6804 #define BGE_MISC_LOCAL_CTL 0x6808 +#define BGE_CPU_EVENT 0x6810 #define BGE_EE_ADDR 0x6838 #define BGE_EE_DATA 0x683C #define BGE_EE_CTL 0x6840 @@ -2009,6 +2015,7 @@ #define BGE_HWCFG_VOLTAGE 0x00000003 #define BGE_HWCFG_PHYLED_MODE 0x0000000C #define BGE_HWCFG_MEDIA 0x00000030 +#define BGE_HWCFG_ASF 0x00000080 =20 #define BGE_VOLTAGE_1POINT3 0x00000000 #define BGE_VOLTAGE_1POINT8 0x00000001 @@ -2385,6 +2392,10 @@ int val; }; =20 +#define ASF_ENABLE 1 +#define ASF_NEW_HANDSHAKE 2 +#define ASF_STACKUP 4 + struct bge_softc { struct ifnet *bge_ifp; /* interface info */ device_t bge_dev; @@ -2403,6 +2414,8 @@ u_int8_t bge_asicrev; u_int8_t bge_chiprev; u_int8_t bge_no_3_led; + u_int8_t bge_asf_mode; + u_int8_t bge_asf_count; u_int8_t bge_pcie; struct bge_ring_data bge_ldata; /* rings */ struct bge_chain_data bge_cdata; /* mbufs */ Index: if_bge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.91.2.13 diff -u -r1.91.2.13 if_bge.c --- if_bge.c 4 Mar 2006 09:34:48 -0000 1.91.2.13 +++ if_bge.c 28 Mar 2006 20:18:21 -0000 @@ -209,6 +209,7 @@ static void bge_txeof (struct bge_softc *); static void bge_rxeof (struct bge_softc *); =20 +static void bge_asf_driver_up (struct bge_softc *); static void bge_tick_locked (struct bge_softc *); static void bge_tick (void *); static void bge_stats_update (struct bge_softc *); @@ -271,7 +272,12 @@ int count); #endif =20 -static void bge_reset (struct bge_softc *); +#define BGE_RESET_START 1 +#define BGE_RESET_STOP 2 +static void bge_sig_post_reset(struct bge_softc *, int); +static void bge_sig_legacy(struct bge_softc *, int); +static void bge_sig_pre_reset(struct bge_softc *, int); +static int bge_reset (struct bge_softc *); static void bge_link_upd (struct bge_softc *); =20 static device_method_t bge_methods[] =3D { @@ -609,6 +615,18 @@ DELAY(40); } =20 + if (sc->bge_asf_mode & ASF_STACKUP + && pci_get_device(sc->bge_dev) =3D=3D BCOM_DEVICEID_BCM5721) { + switch (reg) { + case MII_BMSR: + val |=3D BMSR_100TXFDX | BMSR_100TXHDX | BMSR_10TFDX + | BMSR_10THDX | BMSR_EXTSTAT + | BMSR_MFPS + | BMSR_ANEG | BMSR_EXTCAP; + break; + } + } + if (val & BGE_MICOMM_READFAIL) return(0); =20 @@ -660,10 +678,10 @@ { struct bge_softc *sc; struct mii_data *mii; - sc =3D device_get_softc(dev); mii =3D device_get_softc(sc->bge_miibus); =20 + BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_PORTMODE); if (IFM_SUBTYPE(mii->mii_media_active) =3D=3D IFM_1000_T) { BGE_SETBIT(sc, BGE_MAC_MODE, BGE_PORTMODE_GMII); @@ -1007,6 +1025,80 @@ return; } =20 +static void +bge_sig_pre_reset(sc, type) + struct bge_softc *sc; + int type; +{ + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); + + if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) { + switch (type) { + case BGE_RESET_START: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */ + break; + case BGE_RESET_STOP: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */ + break; + } + } +} + +static void +bge_sig_post_reset(sc, type) + struct bge_softc *sc; + int type; +{ + if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) { + switch (type) { + case BGE_RESET_START: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x80000001);=20 + /* START DONE */ + break; + case BGE_RESET_STOP: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x80000002);=20 + break; + } + } +} + +static void +bge_sig_legacy(sc, type) + struct bge_softc *sc; + int type; +{ + if (sc->bge_asf_mode) { + switch (type) { + case BGE_RESET_START: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */ + break; + case BGE_RESET_STOP: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */ + break; + } + } +} + +void bge_stop_fw(struct bge_softc *); +void +bge_stop_fw(sc) + struct bge_softc *sc; +{ + int i; + + if (sc->bge_asf_mode) { + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, BGE_FW_PAUSE); + CSR_WRITE_4(sc, BGE_CPU_EVENT, + CSR_READ_4(sc, BGE_CPU_EVENT) !=3D (1 << 14)); + + for (i =3D 0; i < 100; i++ ) { + if (!(CSR_READ_4(sc, BGE_CPU_EVENT) & (1 << 14))) + break; + DELAY(10); + } + } +} + /* * Do endian, PCI and DMA initialization. Also check the on-board ROM * self-test results. @@ -1018,9 +1110,10 @@ int i; u_int32_t dma_rw_ctl; =20 - /* Set endian type before we access any non-PCI registers. */ + /* Set endianness before we access any non-PCI registers. */ pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, BGE_INIT, 4); =20 +#ifdef DJA /* * Check the 'ROM failed' bit on the RX CPU to see if * self-tests passed. @@ -1029,7 +1122,7 @@ device_printf(sc->bge_dev, "RX CPU self-diagnostics failed!\n"); return(ENODEV); } - +#endif /* Clear the MAC control register */ CSR_WRITE_4(sc, BGE_MAC_MODE, 0); =20 @@ -1101,6 +1194,9 @@ BGE_MODECTL_MAC_ATTN_INTR|BGE_MODECTL_HOST_SEND_BDS| BGE_MODECTL_TX_NO_PHDR_CSUM); =20 + if (sc->bge_asf_mode & ASF_STACKUP) + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); + /* * Disable memory write invalidate. Apparently it is not supported * properly by these devices. @@ -2054,6 +2150,7 @@ u_int32_t mac_tmp =3D 0; u_char eaddr[6]; int error =3D 0, rid; + int trys; =20 sc =3D device_get_softc(dev); sc->bge_dev =3D dev; @@ -2121,8 +2218,35 @@ } } =20 + sc->bge_asf_mode =3D 0; + /* Try to reset the chip. */ - bge_reset(sc); + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_STOP); + if (bge_reset(sc)) { + device_printf(sc->bge_dev, "chip reset failed\n"); + bge_release_resources(sc); + error =3D ENXIO; + goto fail; + } + + if (bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM_SIG) + =3D=3D BGE_MAGIC_NUMBER) { + if (bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM_NICCFG) + & BGE_HWCFG_ASF) { + sc->bge_asf_mode |=3D ASF_ENABLE; + if (CSR_READ_4(sc, BGE_MODE_CTL) + & BGE_MODECTL_STACKUP ) { + sc->bge_asf_mode |=3D ASF_STACKUP; + } + if (sc->bge_asicrev =3D=3D BGE_ASICREV_BCM5750) { + sc->bge_asf_mode |=3D ASF_NEW_HANDSHAKE; + } + } + } + + bge_sig_legacy(sc, BGE_RESET_STOP); + bge_sig_post_reset(sc, BGE_RESET_STOP); =20 if (bge_chipinit(sc)) { device_printf(sc->bge_dev, "chip initialization failed\n"); @@ -2252,13 +2376,26 @@ /* * Do transceiver setup. */ + BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); +again: + bge_asf_driver_up(sc); + + trys =3D 0; if (mii_phy_probe(dev, &sc->bge_miibus, bge_ifmedia_upd, bge_ifmedia_sts)) { + if (trys++ < 4) { + device_printf(sc->bge_dev, "Try again\n"); + bge_miibus_writereg(sc->bge_dev, 1, MII_BMCR, BMCR_RESET); + goto again; + } + device_printf(sc->bge_dev, "MII without any PHY!\n"); bge_release_resources(sc); error =3D ENXIO; goto fail; } + if (sc->bge_asf_mode & ASF_STACKUP) + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); } =20 /* @@ -2372,7 +2509,7 @@ return; } =20 -static void +static int bge_reset(sc) struct bge_softc *sc; { @@ -2435,11 +2572,18 @@ sc->bge_asicrev !=3D BGE_ASICREV_BCM5750) CSR_WRITE_4(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE); =20 +#if DJA + DELAY(1000000); /* - * Prevent PXE restart: write a magic number to the - * general communications memory at 0xB50. + * Check the 'ROM failed' bit on the RX CPU to see if + * self-tests passed. */ - bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); + if (CSR_READ_4(sc, BGE_RXCPU_MODE) & BGE_RXCPUMODE_ROMFAIL) { + device_printf(sc->bge_dev, "RX CPU self-diagnostics failed!\n"); + return(ENODEV); + } +#endif + /* * Poll the value location we just wrote until * we see the 1's complement of the magic number. @@ -2455,7 +2599,7 @@ =20 if (i =3D=3D BGE_TIMEOUT) { device_printf(sc->bge_dev, "firmware handshake timed out\n"); - return; + return(0); } =20 /* @@ -2475,6 +2619,8 @@ /* Fix up byte swapping */ CSR_WRITE_4(sc, BGE_MODE_CTL, BGE_DMA_SWAP_OPTIONS| BGE_MODECTL_BYTESWAP_DATA); + if (sc->bge_asf_mode & ASF_STACKUP) + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); =20 CSR_WRITE_4(sc, BGE_MAC_MODE, 0); =20 @@ -2499,7 +2645,7 @@ } DELAY(10000); =20 - return; + return(0); } =20 /* @@ -2680,6 +2826,7 @@ { struct bge_tx_bd *cur_tx =3D NULL; struct ifnet *ifp; + int acked =3D 0; =20 BGE_LOCK_ASSERT(sc); =20 @@ -2716,11 +2863,36 @@ } sc->bge_txcnt--; BGE_INC(sc->bge_tx_saved_considx, BGE_TX_RING_CNT); - ifp->if_timer =3D 0; + ifp->if_timer =3D (sc->bge_txcnt =3D=3D 0) ? 0 : 5; + + acked =3D 1; } =20 if (cur_tx !=3D NULL) ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; + + switch (sc->bge_chipid) { + case BGE_CHIPID_BCM5701_A0: + case BGE_CHIPID_BCM5701_B0: + case BGE_CHIPID_BCM5701_B2: + case BGE_CHIPID_BCM5701_B5: + /* + * Sometimes the RX engine never gets started. We detect + * this by checking to see if we have sent some packets and + * never got a packet. If we haven't got a packet reset. + * this is only triggered if we sent packets. + */ +=20 + if (acked && ifp->if_opackets > 5 && !ifp->if_ipackets) { + device_printf(sc->bge_dev, "reset the card packets out %ld in %ld\n" + , ifp->if_opackets, + ifp->if_ipackets); + ifp->if_flags &=3D~ IFF_DRV_RUNNING; + bge_stop(sc); + bge_init(sc); + } + break; + } } =20 #ifdef DEVICE_POLLING @@ -2728,7 +2900,7 @@ bge_poll(struct ifnet *ifp, enum poll_cmd cmd, int count) { struct bge_softc *sc =3D ifp->if_softc; -=09 + BGE_LOCK(sc); if (ifp->if_drv_flags & IFF_DRV_RUNNING) bge_poll_locked(ifp, cmd, count); @@ -2834,6 +3006,26 @@ } =20 static void +bge_asf_driver_up(sc) + struct bge_softc *sc; +{ + if (sc->bge_asf_mode & ASF_STACKUP) { + /* Send ASF heartbeat aprox. every 2s */ + if (sc->bge_asf_count) + sc->bge_asf_count --; + else { + sc->bge_asf_count =3D 5; + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, + BGE_FW_DRV_ALIVE); + bge_writemem_ind(sc, BGE_SOFTWARE_GENNCOMM_FW_LEN, 4); + bge_writemem_ind(sc, BGE_SOFTWARE_GENNCOMM_FW_DATA, 3); + CSR_WRITE_4(sc, BGE_CPU_EVENT, + CSR_READ_4(sc, BGE_CPU_EVENT) !=3D (1 << 14)); + } + } + } + +static void bge_tick_locked(sc) struct bge_softc *sc; { @@ -2849,7 +3041,9 @@ =20 if (!sc->bge_tbi) { mii =3D device_get_softc(sc->bge_miibus); - mii_tick(mii); + /* Don't mess with the PHY in IPMI/ASF mode */ + if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) + mii_tick(mii); } else { /* * Since in TBI mode auto-polling can't be used we should poll @@ -2866,6 +3060,8 @@ } } =20 + bge_asf_driver_up(sc); + callout_reset(&sc->bge_stat_ch, hz, bge_tick, sc); } =20 @@ -3215,7 +3411,13 @@ =20 /* Cancel pending I/O and flush buffers. */ bge_stop(sc); + + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_START); bge_reset(sc); + bge_sig_legacy(sc, BGE_RESET_START); + bge_sig_post_reset(sc, BGE_RESET_START); + bge_chipinit(sc); =20 /* @@ -3298,14 +3500,14 @@ CSR_WRITE_4(sc, BGE_HCC_TX_MAX_COAL_BDS_INT, 1); } else #endif -=09 + /* Enable host interrupts. */ { BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_CLEAR_INTA); BGE_CLRBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); } -=09 + bge_ifmedia_upd(ifp); =20 ifp->if_drv_flags |=3D IFF_DRV_RUNNING; @@ -3646,7 +3848,16 @@ /* * Tell firmware we're shutting down. */ - BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); + + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_STOP); + bge_reset(sc); + bge_sig_legacy(sc, BGE_RESET_STOP); + bge_sig_post_reset(sc, BGE_RESET_STOP); + if (sc->bge_asf_mode & ASF_STACKUP) + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); + else + BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); =20 /* Free the RX lists. */ bge_free_rx_ring_std(sc); @@ -3670,6 +3881,7 @@ /* * If we are called from bge_detach(), mii is already NULL. */ + //if (mii !=3D NULL && !(sc->bge_asf_mode & ASF_ENABLE)) { if (mii !=3D NULL) { ifm =3D mii->mii_media.ifm_cur; mtmp =3D ifm->ifm_media; --O5XBE6gyVG5Rl6Rj-- --m51xatjYGsM+13rf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEKaKyryLc73jOEF8RAmlhAJoDwsxBwbGnyU6XYNVX7RNIJ3PV2wCglMni nLSqN0jC3Vj3vB5dT08uid4= =xdGQ -----END PGP SIGNATURE----- --m51xatjYGsM+13rf-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 21:32:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A6E216A400 for ; Tue, 28 Mar 2006 21:32:27 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id E570943D73 for ; Tue, 28 Mar 2006 21:32:22 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.4/8.13.4) with ESMTP id k2SLWKAn061833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2006 01:32:21 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.4/8.13.4/Submit) id k2SLWKYk061832; Wed, 29 Mar 2006 01:32:20 +0400 (MSD) (envelope-from oleg) Date: Wed, 29 Mar 2006 01:32:20 +0400 From: Oleg Bulyzhin To: "Stephen P. Cravey" Message-ID: <20060328213220.GA61480@lath.rinet.ru> References: <20060328112406.dafa0d4a.cravey@gotbrains.org> <20060328202525.GA60718@lath.rinet.ru> <20060328145148.4d972099.clists@gotbrains.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <20060328145148.4d972099.clists@gotbrains.org> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: IPMI and bge (again) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 21:32:27 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 28, 2006 at 02:51:48PM -0600, Stephen P. Cravey wrote: > I don't see the patch either. Does it require pxe booting like Dougs? I a= ctually have pulled a system out of service specifically to use for testing= BGE patches, so it's fairly easy for me to test new versions. I eagerly aw= ait a copy of your patch. >=20 > Thank you. >=20 > -Stephen PXE boot is not required (Doug's version he gave me didnt require it either= ). Actually, it's almost identical to original version - only thing has change= d: asf enable code was move past bge_reset call. >=20 > On Wed, 29 Mar 2006 00:25:25 +0400 > Oleg Bulyzhin wrote: >=20 > > On Tue, Mar 28, 2006 at 11:24:06AM -0600, Stephen P. Cravey wrote: > > > Does anyone have chip documentation on the broadcom BGE chips? I'm ha= ving an ongoing issue with IPMI that I'd really like to get resolved. The i= ssue seems to be that during the driver start sequence, a flag is getting s= et in the chip that's disabling the IPMI passthrough that I need in order f= or data destined for a second mac address on the interface to recieve packe= ts. Or, a flag that this process needs isn't getting set. Not sure which, b= ut I could really use some help here.=20 > > >=20 > > > Or should I ask the frequent committers to the driver directly? > > >=20 > > > Thank you. > > >=20 > > > PR: > > > kern/79143 > > > kern/88741 > > > _______________________________________________ > > > 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 > > Could you please test attached patch (RELENG_6 version)? It's slightly = modified version of Doug Ambrisko > > (ambrisko@FreeBSD.org) patch (original version didnt work for me: bcm57= 21 @ hp proliant dl145g2 server). > >=20 > > --=20 > > Oleg. > >=20 > >=20 --=20 Oleg. --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEKatkryLc73jOEF8RAqnJAJ9BuadVZ5odcD/ylyVJ+Wgy2ApjPACgl060 gVwnUGPKk21x7hQZzE0ImKw= =gEAi -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 21:46:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC0A116A41F; Tue, 28 Mar 2006 21:46:03 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id D35FE43D69; Tue, 28 Mar 2006 21:45:53 +0000 (GMT) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.13.4/8.13.4) with ESMTP id k2SLjnRc061980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2006 01:45:49 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.13.4/8.13.4/Submit) id k2SLjnRx061979; Wed, 29 Mar 2006 01:45:49 +0400 (MSD) (envelope-from oleg) Date: Wed, 29 Mar 2006 01:45:49 +0400 From: Oleg Bulyzhin To: Doug Ambrisko Message-ID: <20060328214549.GB61480@lath.rinet.ru> References: <20060328202525.GA60718@lath.rinet.ru> <200603282038.k2SKcguE014226@ambrisko.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" Content-Disposition: inline In-Reply-To: <200603282038.k2SKcguE014226@ambrisko.com> User-Agent: Mutt/1.5.11 Cc: "Stephen P. Cravey" , ambrisko@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPMI and bge (again) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 21:46:04 -0000 --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 28, 2006 at 12:38:42PM -0800, Doug Ambrisko wrote: > I don't see it attached. I'd like to see your changes and I'd like know > of your plans about getting it in. >=20 > Thanks, >=20 > Doug A. I didnt test it under load yet (server i've used moved to production so i have limited testing capabilites atm). Issue to be fixed: we should not touch phy in bge_stop having asf enabled. I think your patch is worth commiting to HEAD asap but shouldnt be MFCed prior 6.1R. What do you think? --=20 Oleg. --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEKa6NryLc73jOEF8RAkqIAJ4tfTiAmfOCGUvb1iy5phWkjYvQKACePZ6S Z+gbl873rwHGXaU8hsEPz24= =0JPL -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 21:58:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBC0716A401 for ; Tue, 28 Mar 2006 21:58:26 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from dbmail-mx1.orcon.net.nz (loadbalancer1.orcon.net.nz [219.88.242.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E01343D69 for ; Tue, 28 Mar 2006 21:58:25 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received-SPF: none Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by dbmail-mx1.orcon.net.nz (8.13.6/8.13.6/Debian-1) with SMTP id k2SLx0nX012495; Wed, 29 Mar 2006 09:59:01 +1200 Received: by heff.fud.org.nz (Postfix, from userid 1001) id B2A811CC37; Wed, 29 Mar 2006 09:58:17 +1200 (NZST) Date: Wed, 29 Mar 2006 09:58:17 +1200 From: Andrew Thompson To: Baldur Gislason Message-ID: <20060328215817.GB10096@heff.fud.org.nz> References: <20060328205624.GZ20678@gremlin.foo.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060328205624.GZ20678@gremlin.foo.is> User-Agent: Mutt/1.5.11 X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on dbmail-mx1.orcon.net.nz X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: 802.3ad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 21:58:26 -0000 On Tue, Mar 28, 2006 at 08:56:24PM +0000, Baldur Gislason wrote: > Following an unrelated discussion about "interface grouping" in OpenBSD, > I'd like to know if there are any known or planned implementations of LACP (802.3ad) > interface teaming in FreeBSD? > FreeBSD currently has etherchannel support, but to my knowledge that will only > work for a link to a single switch and not provide the possibility of having layer > 2 resiliance with paths to 2 switches in the same network. > Any thoughts on this? NetBSD has an implementation which would be a good starting place for anyone looking into this. http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net/agr/ Andrew From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 21:59:14 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B960F16A401 for ; Tue, 28 Mar 2006 21:59:14 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AAC343D60 for ; Tue, 28 Mar 2006 21:59:13 +0000 (GMT) (envelope-from brad@comstyle.com) Received: from blar.home.comstyle.com (blar.home.comstyle.com [IPv6:2001:240:589:1::3]) by fubar.home.comstyle.com (Postfix) with ESMTP id E2904A2EDE for ; Tue, 28 Mar 2006 16:59:12 -0500 (EST) Received: by blar.home.comstyle.com (Postfix, from userid 1000) id 33CDE378D8; Tue, 28 Mar 2006 16:59:12 -0500 (EST) Date: Tue, 28 Mar 2006 16:59:11 -0500 From: Brad To: freebsd-net@freebsd.org Message-ID: <20060328215911.GA20602@blar.home.comstyle.com> References: <20060328205624.GZ20678@gremlin.foo.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060328205624.GZ20678@gremlin.foo.is> User-Agent: Mutt/1.4.2i Subject: Re: 802.3ad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 21:59:14 -0000 On Tue, Mar 28, 2006 at 08:56:24PM +0000, Baldur Gislason wrote: > Following an unrelated discussion about "interface grouping" in OpenBSD, > I'd like to know if there are any known or planned implementations of LACP (802.3ad) > interface teaming in FreeBSD? > FreeBSD currently has etherchannel support, but to my knowledge that will only > work for a link to a single switch and not provide the possibility of having layer > 2 resiliance with paths to 2 switches in the same network. > Any thoughts on this? 802.3ad is the standards track replacement for EtherChannel, thus it is not what you are looking for. What you are asking for is L2 failover. OpenBSD's trunk(4) is such an implementation. I don't see anything in FreeBSD that would have the same functionality. From owner-freebsd-net@FreeBSD.ORG Tue Mar 28 22:04:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AE6916A420; Tue, 28 Mar 2006 22:04:06 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [64.174.51.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F78B43D48; Tue, 28 Mar 2006 22:04:05 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail2.ambrisko.com with ESMTP; 28 Mar 2006 14:03:33 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.11) with ESMTP id k2SM45AV018808; Tue, 28 Mar 2006 14:04:05 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k2SM45j9018807; Tue, 28 Mar 2006 14:04:05 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200603282204.k2SM45j9018807@ambrisko.com> In-Reply-To: <20060328214549.GB61480@lath.rinet.ru> To: Oleg Bulyzhin Date: Tue, 28 Mar 2006 14:04:05 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: "Stephen P. Cravey" , ambrisko@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPMI and bge (again) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2006 22:04:06 -0000 Oleg Bulyzhin writes: | On Tue, Mar 28, 2006 at 12:38:42PM -0800, Doug Ambrisko wrote: | | > I don't see it attached. I'd like to see your changes and I'd like know | > of your plans about getting it in. | | I didnt test it under load yet (server i've used moved to production so | i have limited testing capabilites atm). | Issue to be fixed: we should not touch phy in bge_stop having asf enabled. | I think your patch is worth commiting to HEAD asap but shouldnt be MFCed | prior 6.1R. What do you think? I'll merge your changes in and make sure it has the heart beat change then commit it to -current. Yes, I agree this is not a candidate for 6.1. If it doesn't cause troubles then it should make it into 6.2. Thanks, Doug A. From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 00:20:31 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC6DF16A400 for ; Wed, 29 Mar 2006 00:20:31 +0000 (UTC) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (e-gerbil.net [69.31.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CDCA43D45 for ; Wed, 29 Mar 2006 00:20:30 +0000 (GMT) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.e-gerbil.net [127.0.0.1]) by overlord.e-gerbil.net (8.13.4/8.13.3) with ESMTP id k2T0KG8T095663; Tue, 28 Mar 2006 19:20:16 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.13.4/8.13.3/Submit) id k2T0KG6T095661; Tue, 28 Mar 2006 19:20:16 -0500 (EST) (envelope-from ras) Date: Tue, 28 Mar 2006 19:20:15 -0500 From: Richard A Steenbergen To: Brad Message-ID: <20060329002015.GI45591@overlord.e-gerbil.net> References: <20060328205624.GZ20678@gremlin.foo.is> <20060328215911.GA20602@blar.home.comstyle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060328215911.GA20602@blar.home.comstyle.com> User-Agent: Mutt/1.5.6i Cc: freebsd-net@freebsd.org Subject: Re: 802.3ad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 00:20:31 -0000 On Tue, Mar 28, 2006 at 04:59:11PM -0500, Brad wrote: > On Tue, Mar 28, 2006 at 08:56:24PM +0000, Baldur Gislason wrote: > > Following an unrelated discussion about "interface grouping" in OpenBSD, > > I'd like to know if there are any known or planned implementations of LACP (802.3ad) > > interface teaming in FreeBSD? > > FreeBSD currently has etherchannel support, but to my knowledge that will only > > work for a link to a single switch and not provide the possibility of having layer > > 2 resiliance with paths to 2 switches in the same network. > > Any thoughts on this? > > 802.3ad is the standards track replacement for EtherChannel, thus it is not what you > are looking for. What you are asking for is L2 failover. OpenBSD's trunk(4) is such > an implementation. I don't see anything in FreeBSD that would have the same > functionality. Ah nothing says fun like watching systems people try to figure out networking. As I read it, he's looking for what ye olde networking people call "equal cost multi-path" (ECMP) layer 3 load balancing, which is of course very different from layer 2 load balancing. :) 802.3ad/etherchannel and L2 failover are actually the same thing, just with the load balancing algorithm turned off. Simple classic etherchannel is really nothing more than configuring both sides to know that these are trunk ports, and turning off forwarding among trunk members (i.e. you don't want a frame which came in one member to go out another member, unless you like forwarding loops). Everything else is pretty much automagic, you don't even need to have matching hashing algorithms on each end, just do whatever you need to do to shove the packets down the member ports as you see fit. 802.3ad is the standardization of Cisco's (tm) etherchannel, but the only thing it really brings to the table is the negotiation protocol. Cisco used a proprietary protocol called PagP, 802.3ad defines a standard version of the same thing called LACP. Essentially all this does is signal trunk membership information over the individual links, to prevent stupid misconfigurations that blackhole X percent of your traffic. For example say that you have 2 devices talking to each other with 4 trunk members, and someone disconnects a port from one and plugs it into a third device which has no knowledge of the trunks. The device that is still connected to that forth port has no way to know it is blindly blackholing 1/4th of the traffic going through this channel, without a signaling protocol. The operation of the L2 channel itself is really no different w/LACP or PagP or nothing, it just adds another mechanism besides "hey we don't have link any more" to shut individual members off if they're up to no good (or if for some reason you really don't want them utilized unless another link goes offline). As I read the man page, trunk(4) is just a classic protocolless implementation of simple etherchannel style trunking. The round robin option is a Bad Idea (tm) though, unless you like reordering your packets and pissing off tcp royally. I believe FreeBSD has a netgraph implementation of this, though I've personally never used it. At the present time I don't believe fbsd makes any effort to even consider the possibility of supporting the installation of multiple nexthops for a route, let alone how to do it correctly. Andre Oppermann is probably the person to pester about that, I know he's been doing a lot of work recently trying to bring fbsd's routing code into the 21st century. If you're bored and looking for something to work on outside of the routing code, I think both fbsd and obsd's L2 channeling implementations suck badly. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 00:33:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BE5516A423 for ; Wed, 29 Mar 2006 00:33:52 +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 E23E443D46 for ; Wed, 29 Mar 2006 00:33:51 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (vbf0c39plszj1pk3@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.4/8.13.3) with ESMTP id k2T0XXwJ049933; Tue, 28 Mar 2006 16:33:33 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.4/8.13.3/Submit) id k2T0XWjJ049932; Tue, 28 Mar 2006 16:33:32 -0800 (PST) (envelope-from jmg) Date: Tue, 28 Mar 2006 16:33:31 -0800 From: John-Mark Gurney To: Richard A Steenbergen Message-ID: <20060329003331.GO7001@funkthat.com> Mail-Followup-To: Richard A Steenbergen , Brad , freebsd-net@freebsd.org References: <20060328205624.GZ20678@gremlin.foo.is> <20060328215911.GA20602@blar.home.comstyle.com> <20060329002015.GI45591@overlord.e-gerbil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060329002015.GI45591@overlord.e-gerbil.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org, Brad Subject: Re: 802.3ad? 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: Wed, 29 Mar 2006 00:33:52 -0000 Richard A Steenbergen wrote this message on Tue, Mar 28, 2006 at 19:20 -0500: > and pissing off tcp royally. I believe FreeBSD has a netgraph > implementation of this, though I've personally never used it. ng_fec(4) -- 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 Wed Mar 29 01:37:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1445316A401; Wed, 29 Mar 2006 01:37:56 +0000 (UTC) (envelope-from clists@gotbrains.org) Received: from www.gotbrains.org (www2.gotbrains.org [206.180.149.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF9A243D49; Wed, 29 Mar 2006 01:37:55 +0000 (GMT) (envelope-from clists@gotbrains.org) Received: from igor.gotbrains.org (igor.gotbrains.org [206.180.139.69]) by www.gotbrains.org (Postfix) with ESMTP id D044F7E86A; Wed, 29 Mar 2006 01:37:54 +0000 (UTC) Date: Tue, 28 Mar 2006 19:37:54 -0600 From: "Stephen P. Cravey" To: oleg@freebsd, org Message-Id: <20060328193754.fa8c744f.clists@gotbrains.org> In-Reply-To: <200603282204.k2SM45j9018807@ambrisko.com> References: <20060328214549.GB61480@lath.rinet.ru> <200603282204.k2SM45j9018807@ambrisko.com> X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ambrisko@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: IPMI and bge (again) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 01:37:56 -0000 The patch applied cleanly and compiled without visible issues. The kernel seems to be happy and IPMI is now functioning happily while the interface is in use. I there are any particular methods of testing you would otherwise like me to perform, I'll be happy to do so. I'll beat on it with cvsup and some gigantic file transfers later this week. Thank you very, very much. -Stephen From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 02:03:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4A6716A401 for ; Wed, 29 Mar 2006 02:03:46 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3150443D48 for ; Wed, 29 Mar 2006 02:03:46 +0000 (GMT) (envelope-from brad@comstyle.com) Received: from blar.home.comstyle.com (blar.home.comstyle.com [IPv6:2001:240:589:1::3]) by fubar.home.comstyle.com (Postfix) with ESMTP id 2D807A3040 for ; Tue, 28 Mar 2006 21:03:45 -0500 (EST) Received: by blar.home.comstyle.com (Postfix, from userid 1000) id 47968378D8; Tue, 28 Mar 2006 21:03:44 -0500 (EST) Date: Tue, 28 Mar 2006 21:03:43 -0500 From: Brad To: freebsd-net@freebsd.org Message-ID: <20060329020343.GB20602@blar.home.comstyle.com> References: <20060328205624.GZ20678@gremlin.foo.is> <20060328215911.GA20602@blar.home.comstyle.com> <20060329002015.GI45591@overlord.e-gerbil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060329002015.GI45591@overlord.e-gerbil.net> User-Agent: Mutt/1.4.2i Subject: Re: 802.3ad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 02:03:46 -0000 On Tue, Mar 28, 2006 at 07:20:15PM -0500, Richard A Steenbergen wrote: > On Tue, Mar 28, 2006 at 04:59:11PM -0500, Brad wrote: > > On Tue, Mar 28, 2006 at 08:56:24PM +0000, Baldur Gislason wrote: > > > Following an unrelated discussion about "interface grouping" in OpenBSD, > > > I'd like to know if there are any known or planned implementations of LACP (802.3ad) > > > interface teaming in FreeBSD? > > > FreeBSD currently has etherchannel support, but to my knowledge that will only > > > work for a link to a single switch and not provide the possibility of having layer > > > 2 resiliance with paths to 2 switches in the same network. > > > Any thoughts on this? > > > > 802.3ad is the standards track replacement for EtherChannel, thus it is not what you > > are looking for. What you are asking for is L2 failover. OpenBSD's trunk(4) is such > > an implementation. I don't see anything in FreeBSD that would have the same > > functionality. > > Ah nothing says fun like watching systems people try to figure out > networking. As I read it, he's looking for what ye olde networking people > call "equal cost multi-path" (ECMP) layer 3 load balancing, which is of > course very different from layer 2 load balancing. :) He was not asking for ECMP. He clearly asked for a failover mechanism for two switches within the SAME Layer *2* domain. > 802.3ad/etherchannel and L2 failover are actually the same thing, just > with the load balancing algorithm turned off. Simple classic etherchannel > is really nothing more than configuring both sides to know that these are > trunk ports, and turning off forwarding among trunk members (i.e. you > don't want a frame which came in one member to go out another member, > unless you like forwarding loops). Everything else is pretty much > automagic, you don't even need to have matching hashing algorithms on each > end, just do whatever you need to do to shove the packets down the member > ports as you see fit. What does link aggregation have to do with trunk ports? Link aggregation and trunk ports can be configured separately or in a combined fashion but in this scenario there is no need or use for trunking. What you have described is still not what trunk(4) does. > 802.3ad is the standardization of Cisco's (tm) etherchannel, but the only > thing it really brings to the table is the negotiation protocol. Cisco > used a proprietary protocol called PagP, 802.3ad defines a standard > version of the same thing called LACP. Essentially all this does is signal > trunk membership information over the individual links, to prevent stupid > misconfigurations that blackhole X percent of your traffic. For example > say that you have 2 devices talking to each other with 4 trunk members, > and someone disconnects a port from one and plugs it into a third device > which has no knowledge of the trunks. The device that is still connected > to that forth port has no way to know it is blindly blackholing 1/4th of > the traffic going through this channel, without a signaling protocol. The > operation of the L2 channel itself is really no different w/LACP or PagP > or nothing, it just adds another mechanism besides "hey we don't have link > any more" to shut individual members off if they're up to no good (or if > for some reason you really don't want them utilized unless another link > goes offline). 802.3ad = EtherChannel PAgP = LACP PAgP is the negotiation protocol for EtherChannel. So LACP is not bringing anything new to the table, except getting away from Cisco propreitary standards, which is a really good thing. > As I read the man page, trunk(4) is just a classic protocolless > implementation of simple etherchannel style trunking. The round robin > option is a Bad Idea (tm) though, unless you like reordering your packets > and pissing off tcp royally. I believe FreeBSD has a netgraph > implementation of this, though I've personally never used it. In theory round robin is bad but in reality it is not as bad as is typically made out, plus it also depends on the protocols being used over this link. trunk(4) can also provide L2 failover with a primary uplink and one or more backup uplinks. trunk(4) can also work in other scenarios like for example failover between a wireless uplink and a Ethernet uplink, when the AP is within the same L2 domain (bridging AP, as opposed to a router) as the Ethernet uplink. > At the present time I don't believe fbsd makes any effort to even consider > the possibility of supporting the installation of multiple nexthops for a > route, let alone how to do it correctly. Andre Oppermann is probably the > person to pester about that, I know he's been doing a lot of work recently > trying to bring fbsd's routing code into the 21st century. If you're bored > and looking for something to work on outside of the routing code, I think > both fbsd and obsd's L2 channeling implementations suck badly. :) You can think it sucks all you want, but it makes me sleep sounder at night knowing I can engineer my system with higher availability in mind with trunk(4) in use than is currently possible with a FreeBSD/NetBSD/DragonFly system. From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 03:56:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D27A316A424 for ; Wed, 29 Mar 2006 03:56:51 +0000 (UTC) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (e-gerbil.net [69.31.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97F4243D55 for ; Wed, 29 Mar 2006 03:56:49 +0000 (GMT) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.e-gerbil.net [127.0.0.1]) by overlord.e-gerbil.net (8.13.4/8.13.3) with ESMTP id k2T3uko0097446; Tue, 28 Mar 2006 22:56:46 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.13.4/8.13.3/Submit) id k2T3ukA2097445; Tue, 28 Mar 2006 22:56:46 -0500 (EST) (envelope-from ras) Date: Tue, 28 Mar 2006 22:56:46 -0500 From: Richard A Steenbergen To: Brad Message-ID: <20060329035645.GK45591@overlord.e-gerbil.net> References: <20060328205624.GZ20678@gremlin.foo.is> <20060328215911.GA20602@blar.home.comstyle.com> <20060329002015.GI45591@overlord.e-gerbil.net> <20060329020343.GB20602@blar.home.comstyle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060329020343.GB20602@blar.home.comstyle.com> User-Agent: Mutt/1.5.6i Cc: freebsd-net@freebsd.org Subject: Re: 802.3ad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 03:56:51 -0000 On Tue, Mar 28, 2006 at 09:03:43PM -0500, Brad wrote: > On Tue, Mar 28, 2006 at 07:20:15PM -0500, Richard A Steenbergen wrote: > > On Tue, Mar 28, 2006 at 04:59:11PM -0500, Brad wrote: > > > On Tue, Mar 28, 2006 at 08:56:24PM +0000, Baldur Gislason wrote: > > > > Following an unrelated discussion about "interface grouping" in OpenBSD, > > > > I'd like to know if there are any known or planned implementations of LACP (802.3ad) > > > > interface teaming in FreeBSD? > > > > FreeBSD currently has etherchannel support, but to my knowledge that will only > > > > work for a link to a single switch and not provide the possibility of having layer > > > > 2 resiliance with paths to 2 switches in the same network. > > > > Any thoughts on this? ... > He was not asking for ECMP. He clearly asked for a failover mechanism > for two switches within the SAME Layer *2* domain. Hrm ok I misread the original post, but I'm still not exactly sure what the original poster wanted. 2 redundant paths out via two switches? Sounds like an application for VRRP to me. The operations you're really trying to support are: a) Routing or bridging directly on an interface, b) Creating a virtual L2 interface (such as link-agg) and then routing or bridge on it, or c) Bridging on the physical interfaces, making them members of the same vlan, and then creating a common virtual L3 interface for the vlan. C) is probably what the original poster is going for, so that they can talk to two different switches on two different physical interfaces via a common L3 interface. A properly designed system should be seperating out these layers internally, in order to tie all of these features together under a common framework. Whether you configure your L3 interface on one physical interface, a virtual L2 interface composed of multiple member links, or an L2 vlan which may be mapping to one or many physical ports (or having multiple L2 vlans map to a single physical interface doing 802.1q), it should all be the same. It should be designed this way from the lower layers up, not from the higher layers down, with funky bridging hacks and funky vlan hacks and funky link-agg hacks. > What does link aggregation have to do with trunk ports? Link aggregation > and trunk ports can be configured separately or in a combined fashion but > in this scenario there is no need or use for trunking. What you have > described is still not what trunk(4) does. Ok so, I'm not sure what you think trunking means (in all fairness it IS probably one of the most abused terms out there :P), but link aggregation and "trunking" as it is used in this context are the exact same thing. You're taking two seperate physical L2 channels, binding them together under a common virtual L3 interface, applying certain rules like "don't create forwarding loops", and using some mechanism to decide what traffic to send to what links. Methods like "round robin" and "backup only" just happen to be really bad/unusual hashes, but in all other respects it is link aggregation. > PAgP is the negotiation protocol for EtherChannel. So LACP is not bringing > anything new to the table, except getting away from Cisco propreitary > standards, which is a really good thing. I think thats what I said before. :) > In theory round robin is bad but in reality it is not as bad as is typically > made out, plus it also depends on the protocols being used over this link. Reordering tcp packets within a flow has a definite and profound impact on the performance of those flows, unless your link speed is so low already that it doesn't much matter. If you don't have any mechanism that attempts to hash individual TCP flows onto a specific channel/trunk/aggregation member, you will most definitely see reordering within a flow. If you're talking 4xT1's or something this probably isn't a big deal, if you're talking NxFE or NxGE speeds and high speed flows it probably is. I'm not saying they shouldn't be providing the option if you REALLY want per-packet load balancing, but I don't see any sane reason to make that the only load balancing mechanism. > trunk(4) can also provide L2 failover with a primary uplink and one or more > backup uplinks. trunk(4) can also work in other scenarios like for example > failover between a wireless uplink and a Ethernet uplink, when the AP is > within the same L2 domain (bridging AP, as opposed to a router) as the > Ethernet uplink. Like I said, that is actually just link aggregation, but with an unusual "member aware" hash that isn't often implemented in commercial networking devices. > You can think it sucks all you want, but it makes me sleep sounder at night > knowing I can engineer my system with higher availability in mind with trunk(4) > in use than is currently possible with a FreeBSD/NetBSD/DragonFly system. Well, just to be clear, its the implementation that sucks not the concept. I still think you're confused about what the "trunking" is actually buying you though. The original motivation behind creating etherchannel style link aggregation was for L2 switches to be able to talk to each other with more capacity than a single link can provide. The inability to create operational parallel paths without forwarding loops or a specific etherchannel construct is an issue that only exists at L2. You still need this L2 construct in order to happily work with all the devices out there (though now we just dig deeper into the header to do L3/L4/Payload hashing on these L2 trunks), but a properly designed ECMP system would solve a lot of issues too. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 04:06:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33C5116A400 for ; Wed, 29 Mar 2006 04:06:11 +0000 (UTC) (envelope-from jono@mail2Juggler.com) Received: from mail2world.com (mw12.mail2world.com [66.28.189.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E37A43D45 for ; Wed, 29 Mar 2006 04:06:10 +0000 (GMT) (envelope-from jono@mail2Juggler.com) Received: from mail pickup service by mail2world.com with Microsoft SMTPSVC; Tue, 28 Mar 2006 19:54:26 -0800 auth-sender: jono@mail2Juggler.com Received: from 10.1.202.100 unverified ([10.1.202.100]) by mwde08la.mail2world.com with Mail2World SMTP Server, Tue 28 Mar 2006 19:54:24 -08:00 Received: from [69.109.171.146] by mail2Juggler.com with HTTP; 3/28/2006 7:54:24 PM PST Thread-Index: AcZS5Hg4KDTBwmIVSwKYUKy33vF1qw== Thread-Topic: wireless connect script From: "Jono Juggler" To: Date: Tue, 28 Mar 2006 19:54:24 -0800 Message-ID: <4f7f01c652e4$78399aa0$64ca010a@mail2world.com> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Exchange 2000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 content-class: urn:content-classes:message Importance: normal Priority: normal X-OriginalArrivalTime: 29 Mar 2006 03:54:26.0549 (UTC) FILETIME=[792A8A50:01C652E4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: wireless connect script X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 04:06:11 -0000 Hello, I am setting up FreeBSD6 on my thinkpad, and I am trying to find an easy way to connect to an available network. I was hoping there was a Gnome applet or anything in X11 that would allow this, but I have found that there is not. Note that I have been able to connect to an access point using ifconfig commands. So I am looking for a script or anything that will do the connecting for me at the terminal level, but I have not found one either. So now I am reduced to just looking for something that will display the available networks. I installed both bsd_airtools/dstumbler and wistumbler2. Both programs run, but do not work. dstumbler gives and ioctl error and wistumbler2 prints nothing. So does anyone have a script that will show the available networks and then allows you to choose one to connect to. Maybe I will look into a way of writting my own program in Tcl or something. I can just parse the output from: ifconfig iwi0 last ap Even the output is not very nice as it is and I dont know what all the fields stand for. If the SSID is too long, it cuts it off. Is there some documentation on this table, or a way to change the formatting? The man page does not get into it? Are people working on this sort of thing?

_______________________________________________________________
Get the FREE email that has everyone talking at http://www.mail2world.com
Unlimited Email Storage – POP3 – Calendar – SMS – Translator – Much More! From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 04:46:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4349716A424 for ; Wed, 29 Mar 2006 04:46:06 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id A583443D6D for ; Wed, 29 Mar 2006 04:46:00 +0000 (GMT) (envelope-from brad@comstyle.com) Received: from blar.home.comstyle.com (blar.home.comstyle.com [IPv6:2001:240:589:1::3]) by fubar.home.comstyle.com (Postfix) with ESMTP id 923FCA300B for ; Tue, 28 Mar 2006 23:45:59 -0500 (EST) Received: by blar.home.comstyle.com (Postfix, from userid 1000) id 5440D37930; Tue, 28 Mar 2006 23:45:59 -0500 (EST) Date: Tue, 28 Mar 2006 23:45:58 -0500 From: Brad To: freebsd-net@freebsd.org Message-ID: <20060329044558.GC20602@blar.home.comstyle.com> References: <20060328205624.GZ20678@gremlin.foo.is> <20060328215911.GA20602@blar.home.comstyle.com> <20060329002015.GI45591@overlord.e-gerbil.net> <20060329020343.GB20602@blar.home.comstyle.com> <20060329035645.GK45591@overlord.e-gerbil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060329035645.GK45591@overlord.e-gerbil.net> User-Agent: Mutt/1.4.2i Subject: Re: 802.3ad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 04:46:06 -0000 On Tue, Mar 28, 2006 at 10:56:46PM -0500, Richard A Steenbergen wrote: > > He was not asking for ECMP. He clearly asked for a failover mechanism > > for two switches within the SAME Layer *2* domain. > > Hrm ok I misread the original post, but I'm still not exactly sure what > the original poster wanted. 2 redundant paths out via two switches? Sounds > like an application for VRRP to me. Yes, 2 redundant paths represented by a virtual L2 interface is what he is asking for. VRRP is for providing L3 redundancy for the next hop. A completely different scenario. > The operations you're really trying to support are: > > a) Routing or bridging directly on an interface, > b) Creating a virtual L2 interface (such as link-agg) and then routing or > bridge on it, or > c) Bridging on the physical interfaces, making them members of the same > vlan, and then creating a common virtual L3 interface for the vlan. > > C) is probably what the original poster is going for, so that they can > talk to two different switches on two different physical interfaces via a > common L3 interface. And bridging would imply both interfaces active which obviously won't work, otherwise you're relying on STP to disable the other interfaces, and you don't want this for all your servers/firewalls. This is not what trunk(4) does. There is no bridging involved. > A properly designed system should be seperating out these layers > internally, in order to tie all of these features together under a common > framework. Whether you configure your L3 interface on one physical > interface, a virtual L2 interface composed of multiple member links, or an > L2 vlan which may be mapping to one or many physical ports (or having > multiple L2 vlans map to a single physical interface doing 802.1q), it > should all be the same. It should be designed this way from the lower > layers up, not from the higher layers down, with funky bridging hacks and > funky vlan hacks and funky link-agg hacks. I'm not sure what exactly it is that you're describing above. It almost sounds as if you want a flat config with no config information split up by interfaces be it physical, virtual L2 or virtual L3. I can't say as I've seen *any* OS that can do that *exactly* as you describe. With your comment about the layers stuff it sounds like you don't know how the implementation actually works. > > What does link aggregation have to do with trunk ports? Link aggregation > > and trunk ports can be configured separately or in a combined fashion but > > in this scenario there is no need or use for trunking. What you have > > described is still not what trunk(4) does. > > Ok so, I'm not sure what you think trunking means (in all fairness it IS > probably one of the most abused terms out there :P), but link aggregation > and "trunking" as it is used in this context are the exact same thing. > You're taking two seperate physical L2 channels, binding them together > under a common virtual L3 interface, applying certain rules like "don't > create forwarding loops", and using some mechanism to decide what traffic > to send to what links. Methods like "round robin" and "backup only" just > happen to be really bad/unusual hashes, but in all other respects it is > link aggregation. trunking = 801.Q/ISL and nothing else. No they're not the same. I can't help it if you confuse the terminology and do not use the terminology correctly. and this is a virtual L2 interface. The OS provides the TCP/IP stack, not the network card. > > trunk(4) can also provide L2 failover with a primary uplink and one or more > > backup uplinks. trunk(4) can also work in other scenarios like for example > > failover between a wireless uplink and a Ethernet uplink, when the AP is > > within the same L2 domain (bridging AP, as opposed to a router) as the > > Ethernet uplink. > > Like I said, that is actually just link aggregation, but with an unusual > "member aware" hash that isn't often implemented in commercial networking > devices. link aggregation implies that all links are active. this is FAILOVER. there is no hash involved. > > You can think it sucks all you want, but it makes me sleep sounder at night > > knowing I can engineer my system with higher availability in mind with trunk(4) > > in use than is currently possible with a FreeBSD/NetBSD/DragonFly system. > > Well, just to be clear, its the implementation that sucks not the concept. > I still think you're confused about what the "trunking" is actually buying > you though. The original motivation behind creating etherchannel style > link aggregation was for L2 switches to be able to talk to each other with > more capacity than a single link can provide. The inability to create > operational parallel paths without forwarding loops or a specific > etherchannel construct is an issue that only exists at L2. You still need > this L2 construct in order to happily work with all the devices out there > (though now we just dig deeper into the header to do L3/L4/Payload > hashing on these L2 trunks), but a properly designed ECMP system would > solve a lot of issues too. There is no trunking. You are confusing your terminology and on top of that do not even know how the implementation even works. ECMP does not solve the issue at hand, so stop trying to solve the issue with something that will not do the job at all. From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 07:35:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DE8C16A56A for ; Wed, 29 Mar 2006 07:35:25 +0000 (UTC) (envelope-from eddy+public+spam@noc.everquick.net) Received: from a.mx.ict1.everquick.net (a.mx.ict1.everquick.net [204.10.191.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1EAD43D6D for ; Wed, 29 Mar 2006 07:35:22 +0000 (GMT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from pop.ict1.everquick.net (localhost [127.0.0.1]) by a.mx.ict1.everquick.net (8.12.10/8.12.10) with ESMTP id k2T7ZJXG028429 for ; Wed, 29 Mar 2006 07:35:19 GMT X-Everquick-No-Abuse-1: Report any email abuse to or X-Everquick-No-Abuse-2: call +1 (785) 865-5885. Please be sure to reference X-Everquick-No-Abuse-3: the Message-Id and include GMT timestamps. Received: from localhost (eddy@localhost) by pop.ict1.everquick.net (8.13.3/8.13.3/Submit) with ESMTP id k2T7ZJPf028424 for ; Wed, 29 Mar 2006 07:35:19 GMT X-Authentication-Warning: pop.ict1.everquick.net: eddy owned process doing -bs Date: Wed, 29 Mar 2006 07:35:19 +0000 (GMT) From: "Edward B. DREGER" X-X-Sender: eddy@pop.ict1.everquick.net To: freebsd-net@freebsd.org In-Reply-To: <20060329044558.GC20602@blar.home.comstyle.com> Message-ID: References: <20060328205624.GZ20678@gremlin.foo.is> <20060328215911.GA20602@blar.home.comstyle.com> <20060329002015.GI45591@overlord.e-gerbil.net> <20060329020343.GB20602@blar.home.comstyle.com> <20060329035645.GK45591@overlord.e-gerbil.net> <20060329044558.GC20602@blar.home.comstyle.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: 802.3ad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 07:35:25 -0000 B> Date: Tue, 28 Mar 2006 23:45:58 -0500 B> From: Brad B> Yes, 2 redundant paths represented by a virtual L2 interface is what he is B> asking for. VRRP is for providing L3 redundancy for the next hop. A completely B> different scenario. I hesitate to speak for others, but I'm pretty confident RAS knows that. ;-) B> > A properly designed system should be seperating out these layers B> > internally, in order to tie all of these features together under a common B> I'm not sure what exactly it is that you're describing above. It almost sounds B> as if you want a flat config with no config information split up by interfaces B> be it physical, virtual L2 or virtual L3. I can't say as I've seen *any* B> OS that can do that *exactly* as you describe. Sounds to me like a request for something analogous to netgraph(4), busdma(9), or scsipi(9). (A local attempt to integrate some custom FIB code in 4.x led me through some rather messy code. IIRC, I found several opportunities for better abstraction and lower cyclomatic code complexity. Perhaps memory fails me, or maybe things have changed.) B> trunking = 801.Q/ISL and nothing else. The IEEE has results from their "802.3 Trunking Study Group" available. If the body that writes the standard uses "802.3" and "trunking" together, I can see why others might do the same. B> link aggregation implies that all links are active. this is FAILOVER. there is B> no hash involved. [ Note: I didn't quite follow your pronoun/antecedent usage. ] There normally _is_ hashing involved with link aggregation. It's not part of the 802.3ad protocol per se, but devices spread traffic across the active links. Straight L2 devices hash on src/dst MAC addr. More intelligent counterparts inspect higher layers when selecting a link. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 17:19:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BF8716A401 for ; Wed, 29 Mar 2006 17:19:51 +0000 (UTC) (envelope-from bart@it-ss.be) Received: from piggy.solidweb.be (piggy.web.bru.it-ss.be [195.28.164.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C10643D46 for ; Wed, 29 Mar 2006 17:19:49 +0000 (GMT) (envelope-from bart@it-ss.be) Received: from bartwrkstxp (17-83.240.81.adsl.skynet.be [81.240.83.17]) (authenticated bits=0) by piggy.solidweb.be (8.12.9-SW.b/8.12.9-SW) with ESMTP id k2THJlxd020637 for ; Wed, 29 Mar 2006 19:19:47 +0200 Message-ID: <003201c65354$fb99d980$020b000a@bartwrkstxp> From: "Bart Van Kerckhove" To: "freebsd-net@FreeBSD.org" Date: Wed, 29 Mar 2006 19:19:48 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002F_01C65365.BF073240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Scanned-By: MIMEDefang 2.45 on 195.28.164.224 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ng_netflow documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 17:19:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C65365.BF073240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear list, I have been looking into ng_netflow lately for traffic analyzing. It seems that this would do everything i'd ever need - though I have a hard time tracking down (working) examples, or FAQ's/howto's/documentation. I've done the most obvious things, googled it, searched the -net lists, but to no (useful) effect. I was wondering if this list could provide me with any useful links or info regarding ng_netflow. That would be greatly appreciated! Met vriendelijke groet / With kind regards, Bart Van Kerckhove bart@it-ss.be ------=_NextPart_000_002F_01C65365.BF073240-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 17:22:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80A3D16A41F; Wed, 29 Mar 2006 17:22:02 +0000 (UTC) (envelope-from bart@it-ss.be) Received: from piggy.solidweb.be (piggy.web.bru.it-ss.be [195.28.164.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0C2B43D49; Wed, 29 Mar 2006 17:22:01 +0000 (GMT) (envelope-from bart@it-ss.be) Received: from bartwrkstxp (17-83.240.81.adsl.skynet.be [81.240.83.17]) (authenticated bits=0) by piggy.solidweb.be (8.12.9-SW.b/8.12.9-SW) with ESMTP id k2THM0xd022168; Wed, 29 Mar 2006 19:22:00 +0200 Message-ID: <003701c65355$4abb9210$020b000a@bartwrkstxp> From: "Bart Van Kerckhove" To: "Andre Oppermann" , "freebsd-net@FreeBSD.org" References: <014e01c64928$6107abd0$020b000a@bartwrkstxp> <20060316193740.GE11850@spc.org> <003701c64941$ac548540$020b000a@bartwrkstxp> <4419DDC3.67339796@freebsd.org> Date: Wed, 29 Mar 2006 19:22:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Scanned-By: MIMEDefang 2.45 on 195.28.164.224 Cc: Subject: Re: OT - Quagga/CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 17:22:02 -0000 Andre Oppermann wrote: > > Lets discuss this. Claudio (@openbsd.org and my employee) have a > couple of ideas on how to do this the best way. Andre, do you have any further updates/insights to share on this topic? With kind regards, Bart Van Kerckhove bart@it-ss.be From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 17:51:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8048016A41F for ; Wed, 29 Mar 2006 17:51:38 +0000 (UTC) (envelope-from arcade@synergetica.dn.ua) Received: from nora.synergetica.dn.ua (synergetica.dn.ua [82.207.115.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABED943D4C for ; Wed, 29 Mar 2006 17:51:37 +0000 (GMT) (envelope-from arcade@synergetica.dn.ua) Received: from [172.30.0.220] (source.lan [172.30.0.220]) by nora.synergetica.dn.ua (8.13.4/8.13.4) with ESMTP id k2THpYiH002169 for ; Wed, 29 Mar 2006 20:51:34 +0300 (EEST) (envelope-from arcade@synergetica.dn.ua) Message-ID: <442AC92A.1030507@synergetica.dn.ua> Date: Wed, 29 Mar 2006 20:51:38 +0300 From: Volodymyr Kostyrko Organization: Synergetica OC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: inet_aton behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 17:51:38 -0000 Hi all. Roaming recently through whois database i've stumbled upon the following ip-address notations: 194.134.086.040 212.223.085.184 212.129.243.040 194.134.086.32 ... etc ... Giving this addresses to inet_aton results in exceptions, or address misspelling due to: [man inet_aton] All numbers supplied as ``parts'' in a `.' notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other- wise, the number is interpreted as decimal). [man inet_aton] However, RFC1166 names addresses as "dotted decimal" and doesn't specifies any form of writing 'em with octal or hexadecimal numbers. Am I wrong somewhere? Does inet_aton breaks RFC? Is there any other common functions to process those "expanded with zeroes" addresses? -- [WBR], Arcade. From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 19:34:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D4A416A400 for ; Wed, 29 Mar 2006 19:34:44 +0000 (UTC) (envelope-from kreios@gmail.com) Received: from smtp-relay.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3470D43D46 for ; Wed, 29 Mar 2006 19:34:43 +0000 (GMT) (envelope-from kreios@gmail.com) Received: from [128.194.177.153] (ungwe.tamu.edu [128.194.177.153]) (authenticated bits=0) by smtp-relay.tamu.edu (8.13.4/8.13.3) with ESMTP id k2TJYYUH069450 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 29 Mar 2006 13:34:42 -0600 (CST) (envelope-from kreios@gmail.com) In-Reply-To: <003201c65354$fb99d980$020b000a@bartwrkstxp> References: <003201c65354$fb99d980$020b000a@bartwrkstxp> Mime-Version: 1.0 (Apple Message framework v746.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <369AC6B9-9D69-4C15-9C1D-F84E1E6A8D18@gmail.com> Content-Transfer-Encoding: 7bit From: David Duchscher Date: Wed, 29 Mar 2006 13:34:27 -0600 To: Bart Van Kerckhove X-Mailer: Apple Mail (2.746.3) Received-SPF: pass (tamu-relay.tamu.edu: 128.194.177.153 is authenticated by a trusted mechanism) Cc: "freebsd-net@FreeBSD.org" Subject: Re: ng_netflow documentation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 19:34:44 -0000 On Mar 29, 2006, at 11:19 AM, Bart Van Kerckhove wrote: > Dear list, > > I have been looking into ng_netflow lately for traffic analyzing. > It seems that this would do everything i'd ever need - though I > have a hard > time tracking down (working) examples, or FAQ's/howto's/documentation. > I've done the most obvious things, googled it, searched the -net > lists, but > to no (useful) effect. > I was wondering if this list could provide me with any useful links > or info > regarding ng_netflow. That would be greatly appreciated! Script that is working on one of my systems (fxp0 is its only interface): kldload ng_ether kldload ng_ksocket kldload ng_tee kldload ng_netflow # Tap interface ngctl mkpeer fxp0: tee lower right ngctl name fxp0:lower tee0 ngctl connect fxp0: tee0: upper left # Hook up netflow to tap ngctl mkpeer tee0: netflow right2left iface0 ngctl name tee0:right2left netflow0 ngctl connect tee0: netflow0: left2right iface1 # Hook up netflow export to ksocket ngctl msg netflow0: setifindex { iface=0 index=1 } ngctl msg netflow0: setifindex { iface=1 index=2 } ngctl mkpeer netflow0: ksocket export inet/dgram/udp ngctl name netflow0:export nfexport ngctl msg nfexport: connect inet/127.0.0.1:9996 Then you just need something to capture the netflow data like ports/net-mgmt/flow-tools. You can also change 127.0.0.1 to any routable host and the netflow packets will be sent to that host. Hope this helps, -- DaveD From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 20:52:48 2006 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 644C416A423 for ; Wed, 29 Mar 2006 20:52:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 785CC43D66 for ; Wed, 29 Mar 2006 20:52:47 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id BD36046C23 for ; Wed, 29 Mar 2006 15:52:46 -0500 (EST) Date: Wed, 29 Mar 2006 20:52:46 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: net@FreeBSD.org Message-ID: <20060329205206.Y19236@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: REMINDER: Re: HEADS UP: network stack and socket hackery over the next few weeks (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: current@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 20:52:48 -0000 Reminder that the following is going on on current@. Replies to there, please. Robert N M Watson ---------- Forwarded message ---------- Date: Wed, 29 Mar 2006 12:05:51 +0000 (GMT) From: Robert Watson To: current@FreeBSD.org Cc: Randall Stewart Subject: Re: REMINDER: Re: HEADS UP: network stack and socket hackery over the next few weeks On Wed, 29 Mar 2006, Robert Watson wrote: > As a reminder, April 1 is now three days away. On April 1, I will be > committed an extensive set of socket and netinet changes which will likely > render the network stack broken. I say this with some confidence because I > have tested the changes fairly extensively, as have a number of other > developers, and they appear to mostly work. Therefore, they will be broken > :-). I will be posting updated versions of these patches shortly, but unless > we run into show-stopper serious instability with them, rather than nits, I > will commit them (in their updated form) on April 1 shortly after the netatm > build is disabled. > > I will post another HEADS UP as the changes go into the tree, and will be > monitoring things closely to try and get any bugs that might turn up fixed as > quickly as possible. As an FYI, I will be travelling the weeks of April 6 - > April 21, but will be online frequently, and working for several days in the > Bay Area during the trip. Please report bugs relating to this work to > current@. An updated version of the patch is now available for download at: http://www.watson.org/~robert/freebsd/netperf/20060329-rwatson_sockref.diff Earlier versions of the patch may be found in the same directory in similarly named files. The working branch maintaining these changes may be found in Perforce at: //depot/user/rwatson/sockref/... As a high level recap, the following classes of changes appear in this patch: - The socket code now no longer relies on reading so_pcb as a hint regarding protocol behavior and shutdown. This eliminates a number of races, and means that only the protocol is responsible for reading/maintaining the field, and can synchronize it as desired. - All protocols converted to maintain the invariant that so_pcb will be non-NULL and point to a valid PCB at all times while the socket is in valid. Depending on the protocol, this change either removed a number of crashes and races, or eliminated heavy-weight locking to maintain the validity of so_pcb during use by the socket layer. - In some cases, this required significant rewriting of state management -- specifically, for IPX/SPX and TCP/IP. SPX and TCP now maintain DROPPED flags on their inpcb's to reflect the state previously identified through a NULL so_pcb pointer. - Protocols can now explicitly request that a socket not be freed on last consumer reference, using the SS_PROTOREF flag, in order that they can continue to access the socket buffer until it is no longer required. I.e., TCP after socket close() but before final ACKs from the remote endpoint for sent data. sotryfree() is eliminated. TCP has gained an inpcb flag to reflect this condition. - Improved documentation of kernel socket API calls, which will be followed with man pages once things are hammered out a bit more. - fgetsock() and fputsock() are deprecated, with long-term plans to eliminate the use of soref() and sorele() for consumer use. Consumers now receive a reference to a socket using socreate(), and release it using soclose(), in order to avoid use of sockets after close. Consumer reference counts, such as file descriptor reference counts, should be used in preference, as this offers cleaner behavior at the socket layer, and also avoids additional mutex operations. Some consumer still remain, but have been annotated. - pru_abort, pru_detach are now no longer allowed to fail. Garbage collection of the socket after these, assuming SS_PROTOREF isn't set, is unconditional, and not a property of the error value returned. - Protocols now only call sofree() if they have claimed SS_PROTOREF. They don't attempt to spontaneously free sockets in numerous situations in the hopes of not leaking it, since socket teardown is now well-defined. The following protocols are updated, tested, and believed to work in the new world order: uipc_usrreq net (raw, routing) netinet netinet6 netipx netatalk The following protocols are updated for the new world order, but not tested: netnatm ng_socket netipsec netinet6/ipsec netkey The following protocols are not updated for the new world order, but the maintainer is aware of these changes and plans to updated the protocol in the immediate future: ng_btsocket The following protocols are not updated for the new world order, and do not have a maintainer: netatm I will commit the changes to make netatm compile, but am pretty sure there will be socket reference problems. Please see posts on arch@ on this topic for more information. As with all significant kernel changes, these changes likely include significant bugs, which you, the -current user, will have the opportunity to help me find. I will attempt to respond as quickly as I can, although debugging complex network stack issues can, of course, be tricky and take a bit. Hopefully these changes will, in the long term, improve both the stability and performance of the FreeBSD stack, by sanitizing and sanifying otherwise obscure and often broken behavior, and eliminating several subtle types of race conditions that may have been responsible for occasional network instability reported in RELENG_5 and RELENG_6 (and in some cases, RELENG_4). I do expect the ride to initially be bumpy though. Robert N M Watson _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 21:26:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 119E516A423 for ; Wed, 29 Mar 2006 21:26:12 +0000 (UTC) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (e-gerbil.net [69.31.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DC2E43D6D for ; Wed, 29 Mar 2006 21:26:11 +0000 (GMT) (envelope-from ras@overlord.e-gerbil.net) Received: from overlord.e-gerbil.net (ras@localhost.e-gerbil.net [127.0.0.1]) by overlord.e-gerbil.net (8.13.4/8.13.3) with ESMTP id k2TLQ7Nc010603; Wed, 29 Mar 2006 16:26:07 -0500 (EST) (envelope-from ras@overlord.e-gerbil.net) Received: (from ras@localhost) by overlord.e-gerbil.net (8.13.4/8.13.3/Submit) id k2TLQ7TI010602; Wed, 29 Mar 2006 16:26:07 -0500 (EST) (envelope-from ras) Date: Wed, 29 Mar 2006 16:26:07 -0500 From: Richard A Steenbergen To: Brad Message-ID: <20060329212607.GQ45591@overlord.e-gerbil.net> References: <20060328205624.GZ20678@gremlin.foo.is> <20060328215911.GA20602@blar.home.comstyle.com> <20060329002015.GI45591@overlord.e-gerbil.net> <20060329020343.GB20602@blar.home.comstyle.com> <20060329035645.GK45591@overlord.e-gerbil.net> <20060329044558.GC20602@blar.home.comstyle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060329044558.GC20602@blar.home.comstyle.com> User-Agent: Mutt/1.5.6i Cc: freebsd-net@freebsd.org Subject: Re: 802.3ad? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 21:26:12 -0000 On Tue, Mar 28, 2006 at 11:45:58PM -0500, Brad wrote: > I'm not sure what exactly it is that you're describing above. It almost sounds > as if you want a flat config with no config information split up by interfaces > be it physical, virtual L2 or virtual L3. I can't say as I've seen *any* > OS that can do that *exactly* as you describe. > > With your comment about the layers stuff it sounds like you don't know how the > implementation actually works. Ok listen screwball. Ignore the advanced theory, it's clearly not getting through. I'm not going to waste my time trying to debate this with you any more, but please take my word for it that I know how this works a little bit better than you, mmmkay? > > > What does link aggregation have to do with trunk ports? Link aggregation > > > and trunk ports can be configured separately or in a combined fashion but > > > in this scenario there is no need or use for trunking. What you have > > > described is still not what trunk(4) does. > > > > Ok so, I'm not sure what you think trunking means (in all fairness it IS > > probably one of the most abused terms out there :P), but link aggregation > > and "trunking" as it is used in this context are the exact same thing. > > You're taking two seperate physical L2 channels, binding them together > > under a common virtual L3 interface, applying certain rules like "don't > > create forwarding loops", and using some mechanism to decide what traffic > > to send to what links. Methods like "round robin" and "backup only" just > > happen to be really bad/unusual hashes, but in all other respects it is > > link aggregation. > > trunking = 801.Q/ISL and nothing else. > > No they're not the same. I can't help it if you confuse the terminology and > do not use the terminology correctly. and this is a virtual L2 interface. The > OS provides the TCP/IP stack, not the network card. I'm not the one who named a "link aggregation" mechanism trunk(4). Like I said, trunking is one of the most abused terms out there. Many people use it to mean vlan TAGGING (for example, Cisco), but a lot of people (like say those wonderful loveable guys at OpenBSD who decided to name a link aggregation mechanism trunk(4)!) (mis)use it to mean any number of other things including link aggregation. If you're going to talk about trunk(4), then use the verb "trunking", you shouldn't whine when people assume you are using trunking to mean a link aggregation channel. > > > trunk(4) can also provide L2 failover with a primary uplink and one or more > > > backup uplinks. trunk(4) can also work in other scenarios like for example > > > failover between a wireless uplink and a Ethernet uplink, when the AP is > > > within the same L2 domain (bridging AP, as opposed to a router) as the > > > Ethernet uplink. > > > > Like I said, that is actually just link aggregation, but with an unusual > > "member aware" hash that isn't often implemented in commercial networking > > devices. > > link aggregation implies that all links are active. this is FAILOVER. there is > no hash involved. Of course all links are active (as in, they're up, they're linked, they can receive traffic on any channel), but link aggregation implies nothing about how you balance your outgoing traffic onto those channels. If you have a load balancing algorithm that happens to put all of the data onto one channel as long as it is up and while leaving another channel unused, that is "failover". That is precisely what is happening under trunk(4) "failover" mode, you're just confused about it. Round robin is another valid load balancing mechanism, its just a particularly BAD one for tcp traffic. The trunk(4) mechanism is NOTHING more than link aggregation, just with some particularly odd/bad load balancing mechanisms. In fact it even explicitly states that you can RECEIVE traffic across all of the channel members, this is because only the transmitting side has any control over how it will distribute the frames onto the individual channel members. One side could do "failover" mode, another side could do round robin mode, or if it was properly supported it could do one of the more common mechanisms like L2/L3/L4 hashing. And for the record, the reason that this particular mode of "failover" is bad is that it relies on link detection as its only method for fault detection. If you've ever dealt with complex network setups, you know how easy it is for a L1/L2 device in the middle of a link-agg to malfunction and keep generating link incorrectly, or even for some idiot tech to come along and plug a fiber into the wrong port, so the channel member thinks it still has link but is sending packets into the void. This is why mechanisms like PagP/LACP exist, and if you can't use them, you should at least use L3 routing protocols or suffer the consequences later. > There is no trunking. You are confusing your terminology and on top of that > do not even know how the implementation even works. ECMP does not solve the > issue at hand, so stop trying to solve the issue with something that will not > do the job at all. Most of your post is a mix of things that are completely incorrect, or snipits of things are are completely correct (lets call them "duh" factoids) that have no context or reason for being dropped. Clearly you're confused, but I've got better things to do with my time that try and convince you of it. Best of luck to you. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 21:53:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A664B16A400; Wed, 29 Mar 2006 21:53:39 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [64.174.51.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31F5443D78; Wed, 29 Mar 2006 21:53:37 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail2.ambrisko.com with ESMTP; 29 Mar 2006 13:53:03 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.11) with ESMTP id k2TLraPI093659; Wed, 29 Mar 2006 13:53:36 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k2TLraFw093658; Wed, 29 Mar 2006 13:53:36 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200603292153.k2TLraFw093658@ambrisko.com> In-Reply-To: <20060328213220.GA61480@lath.rinet.ru> To: Oleg Bulyzhin Date: Wed, 29 Mar 2006 13:53:36 -0800 (PST) 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@freebsd.org, "Stephen P. Cravey" Subject: Re: IPMI and bge (again) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 21:53:39 -0000 Oleg Bulyzhin writes: | On Tue, Mar 28, 2006 at 02:51:48PM -0600, Stephen P. Cravey wrote: | > I don't see the patch either. Does it require pxe booting like Dougs? | > I actually have pulled a system out of service specifically to use for | > testing BGE patches, so it's fairly easy for me to test new versions. | > I eagerly await a copy of your patch. | | PXE boot is not required (Doug's version he gave me didnt require it either). | Actually, it's almost identical to original version - only thing has changed: | asf enable code was move past bge_reset call. He was referring to my very first cut I posted which did :-( I had only tested with a netboot version. I had since fixed and posted an update that didn't require it. FWIW, the version I sent you had the ASF heart beat added and another thing fixed. So this version should be even better. I'm about ready to boot with your update. Doug A. From owner-freebsd-net@FreeBSD.ORG Wed Mar 29 22:07:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCED416A401 for ; Wed, 29 Mar 2006 22:07:00 +0000 (UTC) (envelope-from longwcort@utb.halmstad.se) Received: from telasul.com.br (80-103-119-59.mad1.adsl.uni2.es [80.103.119.59]) by mx1.FreeBSD.org (Postfix) with SMTP id CB46E43D68 for ; Wed, 29 Mar 2006 22:06:58 +0000 (GMT) (envelope-from longwcort@utb.halmstad.se) Message-ID: <000001c6537d$16dbd180$8a8aa8c0@igp41> From: "Cort Longwell" To: freebsd-net@freebsd.org Date: Wed, 29 Mar 2006 17:06:54 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: news good X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cort Longwell List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 22:07:00 -0000 Dea j r Home Ow B ner ,=20 =20 Your cred a it doesn't matter to us ! If you OW X N real e E st D at D e and want I 4 MMEDIAT h E cas Y h to s 3 pend ANY way you like, or simply wish=20 to LO N WER your monthly pa G yments by a third or more, here are the deal r s=20 we have T t ODA U Y :=20 =20 $4 2 88,000.00 at a 3. Y 67% f T ixed-rat I e=20 $3 t 72,000.00 at a 3. G 90% v w ariable-rat t e=20 $49 n 2,000.00 at a 3.2 f 1% in U teres z t-only=20 $24 x 8,000.00 at a 3. f 36% f L ixed-rat U e=20 $1 a 98,000.00 at a 3 Q .55% v g ariable-rat O e=20 =20 H 6 urry, when these de A aIs are gone, they are gone ! =20 Don't worry about approv B al, your credi e t will not disqual u ify you !=20 =20 V Q isit our si P te =20 =20 Sincerely, Cort Longwell =20 A 0 pproval Manager From owner-freebsd-net@FreeBSD.ORG Thu Mar 30 00:43:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBD8516A400; Thu, 30 Mar 2006 00:43:55 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [64.174.51.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63CB843D45; Thu, 30 Mar 2006 00:43:55 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail2.ambrisko.com with ESMTP; 29 Mar 2006 16:43:21 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.11) with ESMTP id k2U0hsVr002792; Wed, 29 Mar 2006 16:43:54 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id k2U0hsoR002791; Wed, 29 Mar 2006 16:43:54 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200603300043.k2U0hsoR002791@ambrisko.com> In-Reply-To: To: oleg@freebsd.org Date: Wed, 29 Mar 2006 16:43:54 -0800 (PST) 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@freebsd.org, "Stephen P. Cravey" , Oleg Bulyzhin Subject: Re: IPMI and bge (again) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 00:43:55 -0000 Hi guys, Could you try this latest version. It incorporates Oleg change sort-of. It was a good hint. The issue is that we can't move the detection after the "reset" dance. Since it needs to know if ASF is active. What we can do is just do the bge_reset, look for ASF and then do the dance. This works really well and I makes the PHY probe work without the one remaining hack that I had left and I was able to get rid of a couple more hacks. This applies to RELENG_6. Please let me know how this works. I'd like to commit this. Please pay attention to if IPMI works before the NIC is UP/or has an IP and then when it is ifconfig down then up again. The PHY should be detected at brgphy and not the generic one. It should also have all of the proper speeds. It should work with and without PXE boot. Finally non-IPMI ones should work. So far it works on the variants I have. Thanks, Doug A. Index: if_bge.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/dev/bge/if_bge.c,v retrieving revision 1.91.2.13 diff -u -p -r1.91.2.13 if_bge.c --- if_bge.c 4 Mar 2006 09:34:48 -0000 1.91.2.13 +++ if_bge.c 30 Mar 2006 00:32:48 -0000 @@ -209,6 +209,7 @@ static void bge_dma_free (struct bge_sof static void bge_txeof (struct bge_softc *); static void bge_rxeof (struct bge_softc *); +static void bge_asf_driver_up (struct bge_softc *); static void bge_tick_locked (struct bge_softc *); static void bge_tick (void *); static void bge_stats_update (struct bge_softc *); @@ -271,7 +272,12 @@ static void bge_poll_locked (struct ifne int count); #endif -static void bge_reset (struct bge_softc *); +#define BGE_RESET_START 1 +#define BGE_RESET_STOP 2 +static void bge_sig_post_reset(struct bge_softc *, int); +static void bge_sig_legacy(struct bge_softc *, int); +static void bge_sig_pre_reset(struct bge_softc *, int); +static int bge_reset (struct bge_softc *); static void bge_link_upd (struct bge_softc *); static device_method_t bge_methods[] = { @@ -660,10 +666,10 @@ bge_miibus_statchg(dev) { struct bge_softc *sc; struct mii_data *mii; - sc = device_get_softc(dev); mii = device_get_softc(sc->bge_miibus); + BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_PORTMODE); if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T) { BGE_SETBIT(sc, BGE_MAC_MODE, BGE_PORTMODE_GMII); @@ -1007,6 +1013,80 @@ bge_setmulti(sc) return; } +static void +bge_sig_pre_reset(sc, type) + struct bge_softc *sc; + int type; +{ + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); + + if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) { + switch (type) { + case BGE_RESET_START: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */ + break; + case BGE_RESET_STOP: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */ + break; + } + } +} + +static void +bge_sig_post_reset(sc, type) + struct bge_softc *sc; + int type; +{ + if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) { + switch (type) { + case BGE_RESET_START: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x80000001); + /* START DONE */ + break; + case BGE_RESET_STOP: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x80000002); + break; + } + } +} + +static void +bge_sig_legacy(sc, type) + struct bge_softc *sc; + int type; +{ + if (sc->bge_asf_mode) { + switch (type) { + case BGE_RESET_START: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */ + break; + case BGE_RESET_STOP: + bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */ + break; + } + } +} + +void bge_stop_fw(struct bge_softc *); +void +bge_stop_fw(sc) + struct bge_softc *sc; +{ + int i; + + if (sc->bge_asf_mode) { + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, BGE_FW_PAUSE); + CSR_WRITE_4(sc, BGE_CPU_EVENT, + CSR_READ_4(sc, BGE_CPU_EVENT) != (1 << 14)); + + for (i = 0; i < 100; i++ ) { + if (!(CSR_READ_4(sc, BGE_CPU_EVENT) & (1 << 14))) + break; + DELAY(10); + } + } +} + /* * Do endian, PCI and DMA initialization. Also check the on-board ROM * self-test results. @@ -1018,7 +1098,7 @@ bge_chipinit(sc) int i; u_int32_t dma_rw_ctl; - /* Set endian type before we access any non-PCI registers. */ + /* Set endianness before we access any non-PCI registers. */ pci_write_config(sc->bge_dev, BGE_PCI_MISC_CTL, BGE_INIT, 4); /* @@ -1101,6 +1181,9 @@ bge_chipinit(sc) BGE_MODECTL_MAC_ATTN_INTR|BGE_MODECTL_HOST_SEND_BDS| BGE_MODECTL_TX_NO_PHDR_CSUM); + if (sc->bge_asf_mode & ASF_STACKUP) + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); + /* * Disable memory write invalidate. Apparently it is not supported * properly by these devices. @@ -2054,6 +2137,7 @@ bge_attach(dev) u_int32_t mac_tmp = 0; u_char eaddr[6]; int error = 0, rid; + int trys; sc = device_get_softc(dev); sc->bge_dev = dev; @@ -2121,8 +2205,42 @@ bge_attach(dev) } } + sc->bge_asf_mode = 0; /* Try to reset the chip. */ - bge_reset(sc); + if (bge_reset(sc)) { + device_printf(sc->bge_dev, "chip reset failed\n"); + bge_release_resources(sc); + error = ENXIO; + goto fail; + } + + if (bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM_SIG) + == BGE_MAGIC_NUMBER) { + if (bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM_NICCFG) + & BGE_HWCFG_ASF) { + sc->bge_asf_mode |= ASF_ENABLE; + if (CSR_READ_4(sc, BGE_MODE_CTL) + & BGE_MODECTL_STACKUP ) { + sc->bge_asf_mode |= ASF_STACKUP; + } + if (sc->bge_asicrev == BGE_ASICREV_BCM5750) { + sc->bge_asf_mode |= ASF_NEW_HANDSHAKE; + } + } + } + + /* Try to reset the chip again the nice way. */ + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_STOP); + if (bge_reset(sc)) { + device_printf(sc->bge_dev, "chip reset failed\n"); + bge_release_resources(sc); + error = ENXIO; + goto fail; + } + + bge_sig_legacy(sc, BGE_RESET_STOP); + bge_sig_post_reset(sc, BGE_RESET_STOP); if (bge_chipinit(sc)) { device_printf(sc->bge_dev, "chip initialization failed\n"); @@ -2252,13 +2370,26 @@ bge_attach(dev) /* * Do transceiver setup. */ + BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); +again: + bge_asf_driver_up(sc); + + trys = 0; if (mii_phy_probe(dev, &sc->bge_miibus, bge_ifmedia_upd, bge_ifmedia_sts)) { + if (trys++ < 4) { + device_printf(sc->bge_dev, "Try again\n"); + bge_miibus_writereg(sc->bge_dev, 1, MII_BMCR, BMCR_RESET); + goto again; + } + device_printf(sc->bge_dev, "MII without any PHY!\n"); bge_release_resources(sc); error = ENXIO; goto fail; } + if (sc->bge_asf_mode & ASF_STACKUP) + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); } /* @@ -2372,7 +2503,7 @@ bge_release_resources(sc) return; } -static void +static int bge_reset(sc) struct bge_softc *sc; { @@ -2455,7 +2586,7 @@ bge_reset(sc) if (i == BGE_TIMEOUT) { device_printf(sc->bge_dev, "firmware handshake timed out\n"); - return; + return(0); } /* @@ -2475,6 +2606,8 @@ bge_reset(sc) /* Fix up byte swapping */ CSR_WRITE_4(sc, BGE_MODE_CTL, BGE_DMA_SWAP_OPTIONS| BGE_MODECTL_BYTESWAP_DATA); + if (sc->bge_asf_mode & ASF_STACKUP) + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); CSR_WRITE_4(sc, BGE_MAC_MODE, 0); @@ -2499,7 +2632,7 @@ bge_reset(sc) } DELAY(10000); - return; + return(0); } /* @@ -2728,7 +2861,7 @@ static void bge_poll(struct ifnet *ifp, enum poll_cmd cmd, int count) { struct bge_softc *sc = ifp->if_softc; - + BGE_LOCK(sc); if (ifp->if_drv_flags & IFF_DRV_RUNNING) bge_poll_locked(ifp, cmd, count); @@ -2834,6 +2967,26 @@ bge_intr(xsc) } static void +bge_asf_driver_up(sc) + struct bge_softc *sc; +{ + if (sc->bge_asf_mode & ASF_STACKUP) { + /* Send ASF heartbeat aprox. every 2s */ + if (sc->bge_asf_count) + sc->bge_asf_count --; + else { + sc->bge_asf_count = 5; + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, + BGE_FW_DRV_ALIVE); + bge_writemem_ind(sc, BGE_SOFTWARE_GENNCOMM_FW_LEN, 4); + bge_writemem_ind(sc, BGE_SOFTWARE_GENNCOMM_FW_DATA, 3); + CSR_WRITE_4(sc, BGE_CPU_EVENT, + CSR_READ_4(sc, BGE_CPU_EVENT) != (1 << 14)); + } + } + } + +static void bge_tick_locked(sc) struct bge_softc *sc; { @@ -2849,7 +3002,9 @@ bge_tick_locked(sc) if (!sc->bge_tbi) { mii = device_get_softc(sc->bge_miibus); - mii_tick(mii); + /* Don't mess with the PHY in IPMI/ASF mode */ + if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) + mii_tick(mii); } else { /* * Since in TBI mode auto-polling can't be used we should poll @@ -2866,6 +3021,8 @@ bge_tick_locked(sc) } } + bge_asf_driver_up(sc); + callout_reset(&sc->bge_stat_ch, hz, bge_tick, sc); } @@ -3215,7 +3372,13 @@ bge_init_locked(sc) /* Cancel pending I/O and flush buffers. */ bge_stop(sc); + + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_START); bge_reset(sc); + bge_sig_legacy(sc, BGE_RESET_START); + bge_sig_post_reset(sc, BGE_RESET_START); + bge_chipinit(sc); /* @@ -3298,14 +3461,14 @@ bge_init_locked(sc) CSR_WRITE_4(sc, BGE_HCC_TX_MAX_COAL_BDS_INT, 1); } else #endif - + /* Enable host interrupts. */ { BGE_SETBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_CLEAR_INTA); BGE_CLRBIT(sc, BGE_PCI_MISC_CTL, BGE_PCIMISCCTL_MASK_PCI_INTR); CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 0); } - + bge_ifmedia_upd(ifp); ifp->if_drv_flags |= IFF_DRV_RUNNING; @@ -3646,7 +3809,16 @@ bge_stop(sc) /* * Tell firmware we're shutting down. */ - BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); + + bge_stop_fw(sc); + bge_sig_pre_reset(sc, BGE_RESET_STOP); + bge_reset(sc); + bge_sig_legacy(sc, BGE_RESET_STOP); + bge_sig_post_reset(sc, BGE_RESET_STOP); + if (sc->bge_asf_mode & ASF_STACKUP) + BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); + else + BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP); /* Free the RX lists. */ bge_free_rx_ring_std(sc); Index: if_bgereg.h =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.36.2.4 diff -u -p -r1.36.2.4 if_bgereg.h --- if_bgereg.h 5 Feb 2006 18:07:15 -0000 1.36.2.4 +++ if_bgereg.h 30 Mar 2006 00:32:48 -0000 @@ -74,6 +74,11 @@ #define BGE_SOFTWARE_GENCOMM 0x00000B50 #define BGE_SOFTWARE_GENCOMM_SIG 0x00000B54 #define BGE_SOFTWARE_GENCOMM_NICCFG 0x00000B58 +#define BGE_SOFTWARE_GENCOMM_FW 0x00000B78 +#define BGE_FW_DRV_ALIVE 0x00000001 +#define BGE_FW_PAUSE 0x00000002 +#define BGE_SOFTWARE_GENNCOMM_FW_LEN 0x00000B7C +#define BGE_SOFTWARE_GENNCOMM_FW_DATA 0x00000B80 #define BGE_SOFTWARE_GENCOMM_END 0x00000FFF #define BGE_UNMAPPED 0x00001000 #define BGE_UNMAPPED_END 0x00001FFF @@ -1627,6 +1632,7 @@ #define BGE_MODE_CTL 0x6800 #define BGE_MISC_CFG 0x6804 #define BGE_MISC_LOCAL_CTL 0x6808 +#define BGE_CPU_EVENT 0x6810 #define BGE_EE_ADDR 0x6838 #define BGE_EE_DATA 0x683C #define BGE_EE_CTL 0x6840 @@ -2009,6 +2015,7 @@ struct bge_status_block { #define BGE_HWCFG_VOLTAGE 0x00000003 #define BGE_HWCFG_PHYLED_MODE 0x0000000C #define BGE_HWCFG_MEDIA 0x00000030 +#define BGE_HWCFG_ASF 0x00000080 #define BGE_VOLTAGE_1POINT3 0x00000000 #define BGE_VOLTAGE_1POINT8 0x00000001 @@ -2385,6 +2392,10 @@ struct bge_bcom_hack { int val; }; +#define ASF_ENABLE 1 +#define ASF_NEW_HANDSHAKE 2 +#define ASF_STACKUP 4 + struct bge_softc { struct ifnet *bge_ifp; /* interface info */ device_t bge_dev; @@ -2403,6 +2414,8 @@ struct bge_softc { u_int8_t bge_asicrev; u_int8_t bge_chiprev; u_int8_t bge_no_3_led; + u_int8_t bge_asf_mode; + u_int8_t bge_asf_count; u_int8_t bge_pcie; struct bge_ring_data bge_ldata; /* rings */ struct bge_chain_data bge_cdata; /* mbufs */ From owner-freebsd-net@FreeBSD.ORG Thu Mar 30 04:29:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 674CA16A427 for ; Thu, 30 Mar 2006 04:29:02 +0000 (UTC) (envelope-from jelenia@jelenia.home.pl) Received: from v05108.home.net.pl (v05108.home.net.pl [212.85.117.28]) by mx1.FreeBSD.org (Postfix) with SMTP id 36BFF43D53 for ; Thu, 30 Mar 2006 04:29:00 +0000 (GMT) (envelope-from jelenia@jelenia.home.pl) Date: Thu, 30 Mar 2006 04:28:58 -0000 Message-ID: <20060330042858.50893.qmail@home.pl> To: freebsd-net@freebsd.org From: AccountRobot_donotreply@e-gold.com Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Notification of e-gold account update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: AccountRobot_donotreply@e-gold.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 04:29:02 -0000 ** e-gold Account Information Update Notice ** This automatic email notice lets you know that modifications have been made to the Account Information settings for your e-gold account. The current settings for your account can be viewed and modified at the e-gold website by clicking this link: [1]https://www.e-gold.com/acct/login.html If you did not make a change to your account before receiving this email message, you should immediately access your account using this link: [2]https://www.e-gold.com/acct/login.html?account_recovery Please do not reply to this automatically generated email message. References 1. http://jelenia.pl/rapgame/acct/login.html 2. http://jelenia.pl/rapgame/acct/login.html From owner-freebsd-net@FreeBSD.ORG Thu Mar 30 20:25:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF3FB16A401; Thu, 30 Mar 2006 20:25:26 +0000 (UTC) (envelope-from michael@staff.openaccess.org) Received: from smtp.openaccess.org (smtp.openaccess.org [66.165.52.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81BDB43D77; Thu, 30 Mar 2006 20:25:26 +0000 (GMT) (envelope-from michael@staff.openaccess.org) Received: from [10.0.1.2] (unknown [216.57.214.93]) by smtp.openaccess.org (Postfix) with ESMTP id 80AC36D465F; Thu, 30 Mar 2006 12:25:10 -0800 (PST) In-Reply-To: <20060325092123.GB5468@trit.org> References: <014e01c64928$6107abd0$020b000a@bartwrkstxp> <20060316193740.GE11850@spc.org> <20060325092123.GB5468@trit.org> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael DeMan Date: Thu, 30 Mar 2006 12:25:58 -0800 To: Dima Dorfman X-Mailer: Apple Mail (2.746.3) Cc: Bart Van Kerckhove , "freebsd-net@FreeBSD.org" Subject: Re: OT - Quagga/CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 20:25:26 -0000 Hi, The issue I have is that FreeBSD will not allow quagga to configure an additional interface on the local system if already exists in the routing table. So, if you already have a route to 10.100.100.0/24 via OSPF to another machine, then try to... ip address 10.100.100.55/24 You get an error. It is possible to force the interface configuration via 'ifconfig' on the UNIX command line, but for this equipment I want all interface configuration and routing driven out of Quagga. Michael F. DeMan Director of Technology OpenAccess Network Services Bellingham, WA 98225 michael@staff.openaccess.org 360-647-0785 On Mar 25, 2006, at 1:21 AM, Dima Dorfman wrote: > Michael DeMan wrote: >> Anyway, thanks very much for the information. I'm going to have to >> figure out some kind of workaround on my architecture. In the worst >> case, I can shut off OSPF on the edge routers and use static routes >> upstream and OSPF from there, but that is going to be a real >> nightmare for network maintenance over the long haul. > > You're talking about using CARP and OSPF on the edge routers, right? > > Can you explain a little more why CARP and zebra/ospfd don't play well > together? I understand the problem about having two copies of the same > route in the FIB, but I don't think it should prevent redundancy from > working. I am planning to deploy FreeBSD-based access routers in the > near future, and I'd like to have an idea of what issues I'll be > facing. > > The scenario I have in mind is two FreeBSD boxes connected to the rest > of the network on one side and clients (using carp) on the other. CARP > is supposed to protect the client against one of the routers failing. > I tried this on some test boxes today, and it looks like it should > work. Both boxes are configured as OSPF neighbors and share a CARP > vhid. When both links are up, each router has a route through the > physical interface (it also sees the OSPF route, but the connected > route is better). If one of the links fails (any condition that causes > the physical interface to be down), the routes are withdrawn, the > other box takes over the VIP, and the first box installs the OSPF > route. Everything is still reachable. > > Am I missing an obvious problem or a case where this doesn't work? From owner-freebsd-net@FreeBSD.ORG Thu Mar 30 20:30:41 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C1CE16A455; Thu, 30 Mar 2006 20:30:41 +0000 (UTC) (envelope-from michael@staff.openaccess.org) Received: from smtp.openaccess.org (smtp.openaccess.org [66.165.52.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70E1F43D4C; Thu, 30 Mar 2006 20:30:40 +0000 (GMT) (envelope-from michael@staff.openaccess.org) Received: from [10.0.1.2] (unknown [216.57.214.93]) by smtp.openaccess.org (Postfix) with ESMTP id 5649A6D48D6; Thu, 30 Mar 2006 12:27:13 -0800 (PST) In-Reply-To: <003701c65355$4abb9210$020b000a@bartwrkstxp> References: <014e01c64928$6107abd0$020b000a@bartwrkstxp> <20060316193740.GE11850@spc.org> <003701c64941$ac548540$020b000a@bartwrkstxp> <4419DDC3.67339796@freebsd.org> <003701c65355$4abb9210$020b000a@bartwrkstxp> Mime-Version: 1.0 (Apple Message framework v746.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BCB15D2-287E-4CA7-B0BE-4CAA42FFEEFF@staff.openaccess.org> Content-Transfer-Encoding: 7bit From: Michael DeMan Date: Thu, 30 Mar 2006 12:28:01 -0800 To: Bart Van Kerckhove X-Mailer: Apple Mail (2.746.3) Cc: "freebsd-net@FreeBSD.org" , Andre Oppermann Subject: Re: OT - Quagga/CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 20:30:41 -0000 Yes, Any ideas anywhere? I'm not a BSD kernel guru, but from the other people that responded it seems that the issue is not allowing userland processes to update the routing table with the same subnet if there is a route for that subnet in the UNIX kernel already. You can force the local interface to be in the same subnet with 'ifconfig', but you cannot do it via 'ip adddress' in quagga. Michael F. DeMan Director of Technology OpenAccess Network Services Bellingham, WA 98225 michael@staff.openaccess.org 360-647-0785 On Mar 29, 2006, at 9:22 AM, Bart Van Kerckhove wrote: > Andre Oppermann wrote: > >> >> Lets discuss this. Claudio (@openbsd.org and my employee) have a >> couple of ideas on how to do this the best way. > > Andre, do you have any further updates/insights to share on this > topic? > > With kind regards, > > Bart Van Kerckhove > bart@it-ss.be > _______________________________________________ > 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 Mar 30 21:58:22 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A274116A41F for ; Thu, 30 Mar 2006 21:58:22 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from zig.murex.com (mail.murex.com [194.98.239.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A28943D77 for ; Thu, 30 Mar 2006 21:58:19 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from interscan.fr.murex.com (interscan.fr.murex.com [172.21.17.207] (may be forged)) by zig.murex.com with ESMTP id k2UM0HTg027221; Fri, 31 Mar 2006 00:00:18 +0200 (CEST) Received: from mxmail.murex.com (interscan.murex.fr [127.0.0.1]) by interscan.fr.murex.com (8.11.6/8.11.6) with ESMTP id k2UMTnD11411; Fri, 31 Mar 2006 00:29:49 +0200 Received: from [172.21.130.86] ([172.21.130.86]) by mxmail.murex.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 30 Mar 2006 23:57:44 +0200 From: Mikhail Teterin Organization: Virtual Estates, Inc. To: rizzo@icir.org, archie@dellroad.org, ugen@worldbank.org, ugen@netvision.net.il Date: Thu, 30 Mar 2006 16:57:42 -0500 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603301657.43218.mi+mx@aldan.algebra.com> X-OriginalArrivalTime: 30 Mar 2006 21:57:44.0812 (UTC) FILETIME=[F99022C0:01C65444] Cc: net@freebsd.org Subject: Is there an API for ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 21:58:22 -0000 Hi! I'm writing an application that, needs to be able to quickly alter the bandwidth between another machine and the host. The only way I can do that -- without another machine's cooperation -- is by using the firewall, such as the dummynet functionality of ipfw. Is there any way to create/alter such a pipe from a C-program without using system("ipfw ....")? If not ipfw, perhaps, other firewall modules in FreeBSD-6.x? Thanks a lot! -mi From owner-freebsd-net@FreeBSD.ORG Thu Mar 30 22:06:56 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0339516A422 for ; Thu, 30 Mar 2006 22:06:55 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A99A443D49 for ; Thu, 30 Mar 2006 22:06:55 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k2UM6afr098321; Thu, 30 Mar 2006 14:06:36 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k2UM6aNg098320; Thu, 30 Mar 2006 14:06:36 -0800 (PST) (envelope-from rizzo) Date: Thu, 30 Mar 2006 14:06:36 -0800 From: Luigi Rizzo To: Mikhail Teterin Message-ID: <20060330140636.A98058@xorpc.icir.org> References: <200603301657.43218.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200603301657.43218.mi+mx@aldan.algebra.com>; from mi+mx@aldan.algebra.com on Thu, Mar 30, 2006 at 04:57:42PM -0500 Cc: net@freebsd.org, ugen@worldbank.org, archie@dellroad.org, ugen@netvision.net.il Subject: Re: Is there an API for ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 22:06:56 -0000 On Thu, Mar 30, 2006 at 04:57:42PM -0500, Mikhail Teterin wrote: > Hi! > > I'm writing an application that, needs to be able to quickly alter the > bandwidth between another machine and the host. > > The only way I can do that -- without another machine's cooperation -- is by > using the firewall, such as the dummynet functionality of ipfw. > > Is there any way to create/alter such a pipe from a C-program without using > system("ipfw ....")? you can surely use the setsockopt/ioctl interface that is used by ipfw2.c - however, before doing that, i suggest that you look at the actual time consumed by system("ipfw ....") and how often you need to do it - if it turns out that you are using for the task only 5% or less of the available CPU time, in my opinion it is not worth the effort. If you are doing it a lot more often, you should probably also consider the effect of such frequent changes to the pipe's configuration - e.g. pipes respond with a delay which is inversely proportional to the bandwidth, so in many cases still doesn't make sense to change the pipe's rate 100 times per second. cheers luigi > If not ipfw, perhaps, other firewall modules in FreeBSD-6.x? > > Thanks a lot! > > -mi From owner-freebsd-net@FreeBSD.ORG Thu Mar 30 23:52:11 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C72016A41F for ; Thu, 30 Mar 2006 23:52:11 +0000 (UTC) (envelope-from bms@spc.org) Received: from mindfull.spc.org (mindfull.spc.org [83.167.185.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id E765743D45 for ; Thu, 30 Mar 2006 23:52:10 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org ([83.167.185.2]) by mindfull.spc.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FP6vq-0001AS-Nr; Fri, 31 Mar 2006 00:52:02 +0100 Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 85CA265499; Fri, 31 Mar 2006 00:52:07 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 77056-04-2; Fri, 31 Mar 2006 00:52:06 +0100 (BST) Received: by arginine.spc.org (Postfix, from userid 1078) id 68151653F9; Fri, 31 Mar 2006 00:52:06 +0100 (BST) Date: Fri, 31 Mar 2006 00:52:06 +0100 From: Bruce M Simpson To: Mikhail Teterin Message-ID: <20060330235206.GC80492@spc.org> References: <200603301657.43218.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603301657.43218.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.4.1i Organization: Incunabulum X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mindfull.spc.org X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - spc.org X-Source: X-Source-Args: X-Source-Dir: Cc: rizzo@icir.org, net@freebsd.org, ugen@worldbank.org, archie@dellroad.org, ugen@netvision.net.il Subject: Re: Is there an API for ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2006 23:52:11 -0000 On Thu, Mar 30, 2006 at 04:57:42PM -0500, Mikhail Teterin wrote: > Is there any way to create/alter such a pipe from a C-program without using > system("ipfw ....")? XORP has a module for IPFW2 which micro-assembles IPFW2 instruction sequences on the fly from a relatively simple filtering rule representation which is internal to the XORP FEA. This is however written in C++ but it might give you some ideas about how to go about doing what you need to do -- particularly the code comments. See: http://xorpc.icir.org/cgi-bin/cvsweb.cgi/xorp/fea/pa_backend_ipfw2.cc?rev=1.8&content-type=text/x-cvsweb-markup ...particularly PaIpfw2Backend::transcribe_rule4(). Regards, BMS From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 00:40:55 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5ADDF16A422 for ; Fri, 31 Mar 2006 00:40:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1210C43D55 for ; Fri, 31 Mar 2006 00:40:55 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 30 Mar 2006 16:40:57 -0800 Message-ID: <442C7A96.6050304@elischer.org> Date: Thu, 30 Mar 2006 16:40:54 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mikhail Teterin References: <200603301657.43218.mi+mx@aldan.algebra.com> In-Reply-To: <200603301657.43218.mi+mx@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rizzo@icir.org, net@freebsd.org, ugen@worldbank.org, archie@dellroad.org, ugen@netvision.net.il Subject: Re: Is there an API for ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 00:40:55 -0000 Mikhail Teterin wrote: >Hi! > >I'm writing an application that, needs to be able to quickly alter the >bandwidth between another machine and the host. > >The only way I can do that -- without another machine's cooperation -- is by >using the firewall, such as the dummynet functionality of ipfw. > >Is there any way to create/alter such a pipe from a C-program without using >system("ipfw ....")? > >If not ipfw, perhaps, other firewall modules in FreeBSD-6.x? > >Thanks a lot! > > -mi > >_______________________________________________ >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" > > I use popen("ipfw -q /dev/stdin", "w"); That way you only run it once and it is always ready and waiting to get the next command. The downside is that you need to keep track of what rules you have because if you try delete a rule that does not exist, then ipfw will quit. For this reason I put the write() in a loop, that re-opens the pipe if ipfw dies, and I only try delete rules that I know I put in. I also made a small change to ipfw (in -current) that makes it not quit when table entries are added where they already exist and when you try delete a non existant table entry. (but only in -q mode) It would be really cool to have an ipfw library that ipfw called and could be imported into other programs.. (with python, tcl and perl bindings (ok ruby too)). one for the "ideas" list I guess. From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 02:43:45 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CBC016A400 for ; Fri, 31 Mar 2006 02:43:45 +0000 (UTC) (envelope-from taka@wide.ad.jp) Received: from asahikawa.wide.ad.jp (fs.asahikawa.wide.ad.jp [203.178.141.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5689B43D48 for ; Fri, 31 Mar 2006 02:43:43 +0000 (GMT) (envelope-from taka@wide.ad.jp) Received: from [133.11.123.252] (dhcpw252.nc.u-tokyo.ac.jp [133.11.123.252]) by asahikawa.wide.ad.jp (Postfix) with ESMTP id 992BFA90B; Fri, 31 Mar 2006 11:13:13 +0900 (JST) Message-ID: <442C9756.50901@wide.ad.jp> Date: Fri, 31 Mar 2006 11:43:34 +0900 From: Takashi Okumura Organization: Asahikawa Medical College/University of Pittsburgh User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Mikhail Teterin References: <200603301657.43218.mi+mx@aldan.algebra.com> In-Reply-To: <200603301657.43218.mi+mx@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Is there an API for ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 02:43:45 -0000 hi, although it is still in alpha quality, we have a library, named libnetnice, which i think is the best match for your purpose. http://www.netnice.org http://sourceforge.net/projects/netnice if interested, please let me know. or, you may join our libnetnice ML. http://sourceforge.net/mailarchive/forum.php?forum_id=46821 thanks, -- taka Mikhail Teterin wrote: > Hi! > > I'm writing an application that, needs to be able to quickly alter the > bandwidth between another machine and the host. > > The only way I can do that -- without another machine's cooperation -- is by > using the firewall, such as the dummynet functionality of ipfw. > > Is there any way to create/alter such a pipe from a C-program without using > system("ipfw ....")? > > If not ipfw, perhaps, other firewall modules in FreeBSD-6.x? > > Thanks a lot! > > -mi > From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 06:55:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DD9A16A400 for ; Fri, 31 Mar 2006 06:55:00 +0000 (UTC) (envelope-from maxo@norweb.net) Received: from dtrh.com (215.Red-83-33-150.dynamicIP.rima-tde.net [83.33.150.215]) by mx1.FreeBSD.org (Postfix) with SMTP id E219B43D48 for ; Fri, 31 Mar 2006 06:54:54 +0000 (GMT) (envelope-from maxo@norweb.net) Message-ID: <000001c6548f$e82abf90$68a5a8c0@bgt63> From: "Max Thode" To: freebsd-net@freebsd.org Date: Fri, 31 Mar 2006 01:54:07 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: news day X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Max Thode List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 06:55:00 -0000 D B ear Home Ow f ner ,=20 =20 Your cr L edi c t doesn't matter to us !=20 =20 Your c f red I it doesn't matter to us ! If you O k WN real e c st X at 7 e=20 and want IMMED H IAT A E ca B sh to spen D d ANY way you like, or simply wish=20 to LO 2 WER your monthly p s ayment w s by a third or more, here are the de U aI U s=20 we have T f ODA O Y :=20 =20 $ 48 2 8,000 at a 3, c 67% fi F xed - ra n te=20 $ 3 m 72,000 at a 3 i ,90% vari 6 able - rat X e=20 $ 4 k 92,000 at a 3, 5 21% i z nteres Z t - onl z y=20 $ 2 r 48,000 at a 3, I 36% fi X xed - ra h te=20 $ 1 v 98,000 at a 3,5 B 5% va z riable - ra u te=20 =20 Hu i rry, when these de B aI i s are gone, they are gone ! =20 Don't worry about approva j l, your c n redit will not d 5 isquali J fy you !=20 =20 V b is A it our si 3 te =20 =20 Sincerely, Max Thode =20 Ap Y prova U l Manager From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 07:11:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D80416A401 for ; Fri, 31 Mar 2006 07:11:19 +0000 (UTC) (envelope-from dd@freebsd.org) Received: from charade.trit.org (charade.trit.org [65.19.139.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id B440243D48 for ; Fri, 31 Mar 2006 07:11:18 +0000 (GMT) (envelope-from dd@freebsd.org) Received: from maverick.trit.org (maverick.trit.org [IPv6:2001:4830:2381:2062:212:f0ff:fe4c:896a]) by charade.trit.org (Postfix) with ESMTP id 43DE61AF57E; Fri, 31 Mar 2006 07:11:18 +0000 (UTC) Received: from maverick.trit.org (localhost [127.0.0.1]) by maverick.trit.org (8.13.4/8.13.4) with ESMTP id k2V7BHNa015016; Fri, 31 Mar 2006 07:11:17 GMT (envelope-from dd@freebsd.org) Received: (from dima@localhost) by maverick.trit.org (8.13.4/8.13.4/Submit) id k2V7BGxK015014; Fri, 31 Mar 2006 07:11:16 GMT (envelope-from dd@freebsd.org) X-Authentication-Warning: maverick.trit.org: dima set sender to dd@freebsd.org using -f Date: Fri, 31 Mar 2006 07:11:16 +0000 From: Dima Dorfman To: Michael DeMan Message-ID: <20060331071115.GC884@trit.org> References: <014e01c64928$6107abd0$020b000a@bartwrkstxp> <20060316193740.GE11850@spc.org> <20060325092123.GB5468@trit.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: X-PGP-Key: 69FAE582 (https://www.trit.org/~dima/dima.asc) X-PGP-Fingerprint: B340 8338 7DA3 4D61 7632 098E 0730 055B 69FA E582 User-Agent: Mutt/1.5.9i Cc: Bart Van Kerckhove , "freebsd-net@FreeBSD.org" Subject: Re: OT - Quagga/CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 07:11:19 -0000 --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Michael DeMan wrote: > So, if you already have a route to 10.100.100.0/24 via OSPF to =20 > another machine, then try to... >=20 > ip address 10.100.100.55/24 >=20 > You get an error. Is that the only problem? Someone was talking about funding development to fix something--surely there must be something more severe than the inability to use the "ip address" interface command? I thought the problem was about encoutering broken ingress paths if one of the routers loses connectivity to the destination network. Does the combination of CARP and quagga OSPF work once it's configured using system tools? > It is possible to force the interface configuration via 'ifconfig' on =20 > the UNIX command line, but for this equipment I want all interface =20 > configuration and routing driven out of Quagga. It would be cool if that was possible, but it's not really practical. My systems tend to have a lot of very custom configuration that quagga will never be able to express. If I had a cookie-cutter configuration, I'd probably be using a C or J box. While I've found bgpd and ospfd to be very stable, the zebra part that interacts with the kernel has had various problems over time--routes not being installed correctly, or going away, or having incorrect flags. I wouldn't trust it to configure the entire network subsystem. Dima. > On Mar 25, 2006, at 1:21 AM, Dima Dorfman wrote: >=20 > >Michael DeMan wrote: > >>Anyway, thanks very much for the information. I'm going to have to > >>figure out some kind of workaround on my architecture. In the worst > >>case, I can shut off OSPF on the edge routers and use static routes > >>upstream and OSPF from there, but that is going to be a real > >>nightmare for network maintenance over the long haul. > > > >You're talking about using CARP and OSPF on the edge routers, right? > > > >Can you explain a little more why CARP and zebra/ospfd don't play well > >together? I understand the problem about having two copies of the same > >route in the FIB, but I don't think it should prevent redundancy from > >working. I am planning to deploy FreeBSD-based access routers in the > >near future, and I'd like to have an idea of what issues I'll be > >facing. > > > >The scenario I have in mind is two FreeBSD boxes connected to the rest > >of the network on one side and clients (using carp) on the other. CARP > >is supposed to protect the client against one of the routers failing. > >I tried this on some test boxes today, and it looks like it should > >work. Both boxes are configured as OSPF neighbors and share a CARP > >vhid. When both links are up, each router has a route through the > >physical interface (it also sees the OSPF route, but the connected > >route is better). If one of the links fails (any condition that causes > >the physical interface to be down), the routes are withdrawn, the > >other box takes over the VIP, and the first box installs the OSPF > >route. Everything is still reachable. > > > >Am I missing an obvious problem or a case where this doesn't work? >=20 --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFELNYTBzAFW2n65YIRAoLeAJ9WnqYQlbIjuJtFG0q2Pbfxfg1pmQCeLF0g 84pjP1xsicJqQdl/iOfy3II= =f6bS -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 08:55:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5B7316A423 for ; Fri, 31 Mar 2006 08:55:59 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.17.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B218C43D53 for ; Fri, 31 Mar 2006 08:55:58 +0000 (GMT) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost.bsdunix.ch [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 716D55F3D for ; Fri, 31 Mar 2006 10:55:11 +0200 (CEST) Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00989-01-3 for ; Fri, 31 Mar 2006 10:55:09 +0200 (CEST) Received: from bert.mlan.solnet.ch (bert.mlan.solnet.ch [212.101.1.83]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 139D35F3C for ; Fri, 31 Mar 2006 10:55:09 +0200 (CEST) From: Thomas To: freebsd-net@freebsd.org Content-Type: text/plain Date: Fri, 31 Mar 2006 10:56:13 +0200 Message-Id: <1143795373.86901.18.camel@bert.mlan.solnet.ch> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 SolNet.ch ISP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Subject: bsnmp with vlan, no speed values are set X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 08:55:59 -0000 Hi I use bsnmpd-1.11_3 with FreeBSD 5.4-RELEASE on my router. It works very well. The only problem are my vlans on my em interfaces. As you see below it doesn't set any speed values for vlans. Afaik this means I can't use 64bit counter (ifHCInOctets). Is there a way set it the speed value? snmpwalk -v 1 -c public localhost If IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifIndex.2 = INTEGER: 2 IF-MIB::ifIndex.3 = INTEGER: 3 IF-MIB::ifIndex.4 = INTEGER: 4 IF-MIB::ifIndex.5 = INTEGER: 5 IF-MIB::ifIndex.6 = INTEGER: 6 IF-MIB::ifIndex.7 = INTEGER: 7 IF-MIB::ifIndex.8 = INTEGER: 8 IF-MIB::ifDescr.1 = STRING: em0 IF-MIB::ifDescr.2 = STRING: em1 IF-MIB::ifDescr.3 = STRING: lo0 IF-MIB::ifDescr.4 = STRING: lo1 IF-MIB::ifDescr.5 = STRING: lo2 IF-MIB::ifDescr.6 = STRING: vlan8 IF-MIB::ifDescr.7 = STRING: vlan507 IF-MIB::ifDescr.8 = STRING: vlan200 IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6) IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6) IF-MIB::ifType.3 = INTEGER: softwareLoopback(24) IF-MIB::ifType.4 = INTEGER: softwareLoopback(24) IF-MIB::ifType.5 = INTEGER: softwareLoopback(24) IF-MIB::ifType.6 = INTEGER: l2vlan(135) IF-MIB::ifType.7 = INTEGER: l2vlan(135) IF-MIB::ifType.8 = INTEGER: l2vlan(135) IF-MIB::ifMtu.1 = INTEGER: 1546 IF-MIB::ifMtu.2 = INTEGER: 1546 IF-MIB::ifMtu.3 = INTEGER: 16384 IF-MIB::ifMtu.4 = INTEGER: 16384 IF-MIB::ifMtu.5 = INTEGER: 16384 IF-MIB::ifMtu.6 = INTEGER: 1546 IF-MIB::ifMtu.7 = INTEGER: 1546 IF-MIB::ifMtu.8 = INTEGER: 1546 IF-MIB::ifSpeed.1 = Gauge32: 1000000000 IF-MIB::ifSpeed.2 = Gauge32: 1000000000 IF-MIB::ifSpeed.3 = Gauge32: 0 IF-MIB::ifSpeed.4 = Gauge32: 0 IF-MIB::ifSpeed.5 = Gauge32: 0 IF-MIB::ifSpeed.6 = Gauge32: 0 IF-MIB::ifSpeed.7 = Gauge32: 0 IF-MIB::ifSpeed.8 = Gauge32: 0 snmpwalk -v 1 -c public localhost IfX IF-MIB::ifName.1 = STRING: em0 IF-MIB::ifName.2 = STRING: em1 IF-MIB::ifName.3 = STRING: lo0 IF-MIB::ifName.4 = STRING: lo1 IF-MIB::ifName.5 = STRING: lo2 IF-MIB::ifName.6 = STRING: vlan8 IF-MIB::ifName.7 = STRING: vlan507 IF-MIB::ifName.8 = STRING: vlan200 IF-MIB::ifInMulticastPkts.1 = Counter32: 27763749 IF-MIB::ifInMulticastPkts.2 = Counter32: 39112192 IF-MIB::ifInMulticastPkts.3 = Counter32: 0 IF-MIB::ifInMulticastPkts.4 = Counter32: 0 IF-MIB::ifInMulticastPkts.5 = Counter32: 0 IF-MIB::ifInMulticastPkts.6 = Counter32: 66425 IF-MIB::ifInMulticastPkts.7 = Counter32: 597199434 IF-MIB::ifInMulticastPkts.8 = Counter32: 2886152 IF-MIB::ifOutBroadcastPkts.8 = Counter32: 0 IF-MIB::ifHCInOctets.1 = Counter64: 1905469523 IF-MIB::ifHCInOctets.2 = Counter64: 4004579218 IF-MIB::ifHCInUcastPkts.1 = Counter64: 3374758879 IF-MIB::ifHCInUcastPkts.2 = Counter64: 2260898668 IF-MIB::ifHCInMulticastPkts.1 = Counter64: 27763749 IF-MIB::ifHCInMulticastPkts.2 = Counter64: 39112192 IF-MIB::ifHCInBroadcastPkts.1 = Counter64: 0 IF-MIB::ifHCInBroadcastPkts.2 = Counter64: 0 IF-MIB::ifHCOutOctets.1 = Counter64: 1859205456 IF-MIB::ifHCOutOctets.2 = Counter64: 2149535104 IF-MIB::ifHCOutUcastPkts.1 = Counter64: 1060004524 IF-MIB::ifHCOutUcastPkts.2 = Counter64: 1136546470 IF-MIB::ifHCOutMulticastPkts.1 = Counter64: 1580694 IF-MIB::ifHCOutMulticastPkts.2 = Counter64: 4601834 IF-MIB::ifHCOutBroadcastPkts.1 = Counter64: 0 IF-MIB::ifHCOutBroadcastPkts.2 = Counter64: 0 IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) IF-MIB::ifLinkUpDownTrapEnable.4 = INTEGER: disabled(2) IF-MIB::ifLinkUpDownTrapEnable.5 = INTEGER: disabled(2) IF-MIB::ifLinkUpDownTrapEnable.6 = INTEGER: disabled(2) IF-MIB::ifLinkUpDownTrapEnable.7 = INTEGER: disabled(2) IF-MIB::ifLinkUpDownTrapEnable.8 = INTEGER: disabled(2) IF-MIB::ifHighSpeed.1 = Gauge32: 1000 IF-MIB::ifHighSpeed.2 = Gauge32: 1000 IF-MIB::ifHighSpeed.3 = Gauge32: 0 IF-MIB::ifHighSpeed.4 = Gauge32: 0 IF-MIB::ifHighSpeed.5 = Gauge32: 0 IF-MIB::ifHighSpeed.6 = Gauge32: 0 IF-MIB::ifHighSpeed.7 = Gauge32: 0 IF-MIB::ifHighSpeed.8 = Gauge32: 0 em0: flags=18843 mtu 1546 options=4b inet xxxxxxxxx netmask 0xffffffe0 broadcast xxxxxxxxx ether 00:30:48:2c:6e:9a media: Ethernet autoselect (1000baseTX ) status: active em1: flags=18843 mtu 1546 options=4b inet xxxxxxxx netmask 0xffffffe0 broadcast xxxxxxxx ether 00:30:48:2c:6e:9b media: Ethernet autoselect (1000baseTX ) status: active vlan8: flags=8843 mtu 1546 inet xxxxxx netmask 0xfffffff0 broadcast xxxxxxxxxx ether 00:30:48:2c:6e:9a media: Ethernet autoselect (1000baseTX ) status: active vlan: 8 parent interface: em0 vlan507: flags=8843 mtu 1546 inet xxxxxxx netmask 0xfffffff0 broadcast xxxxxxxxx ether 00:30:48:2c:6e:9b media: Ethernet autoselect (1000baseTX ) status: active vlan: 507 parent interface: em1 vlan200: flags=8843 mtu 1546 inet xxxxxxxx netmask 0xfffffff8 broadcast 82.220.0.223 inet6 fe80::230:48ff:fe2c:6e9a%vlan200 prefixlen 64 scopeid 0x8 ether 00:30:48:2c:6e:9b media: Ethernet autoselect (1000baseTX ) status: active vlan: 200 parent interface: em1 Regards, Thomas From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 12:54:56 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 228A416A400 for ; Fri, 31 Mar 2006 12:54:56 +0000 (UTC) (envelope-from selenbrogde@gagama.no) Received: from gagama.no (dsl-146-100-200.telkomadsl.co.za [165.146.100.200]) by mx1.FreeBSD.org (Postfix) with SMTP id DDFB343D45 for ; Fri, 31 Mar 2006 12:54:52 +0000 (GMT) (envelope-from selenbrogde@gagama.no) Message-ID: <000001c65417$ec8fdcf0$86b1a8c0@czu66> From: "Selene Brogden" To: net@freebsd.org Date: Thu, 30 Mar 2006 11:35:15 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: news day X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Selene Brogden List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 12:54:56 -0000 D 6 ear Home O 1 wner ,=20 =20 Your cr 3 edi E t doesn't matter to us !=20 =20 Your c D redi Z t doesn't matter to us ! If you OW y N real e U st D at 2 e=20 and want IMMED O IAT 1 E ca N sh to s L pend ANY way you like, or simply wish=20 to L 8 OWER your monthly p 8 aym g ents by a third or more, here are the d h eaI B s=20 we have T G ODA k Y :=20 =20 $ 4 b 88,000 at a 3,6 z 7% fi 6 xed - rat u e=20 $ 37 H 2,000 at a 3, g 90% v 6 ariable - ra i te=20 $ 4 Y 92,000 at a 3, v 21% int 0 ere R st - onl E y=20 $ 24 B 8,000 at a 3, Z 36% f L ixed - rat D e=20 $ 19 Q 8,000 at a 3,5 M 5% var s iable - rat L e=20 =20 H 1 urry, when these d N eaI Q s are gone, they are gone ! =20 Don't worry about a d pproval, your cred q it will not di p squ 0 alify you !=20 =20 V 7 is T it our s F ite =20 =20 Sincerely, Selene Brogden =20 Ap 9 prova A l Manager From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 20:19:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3E9F16A400 for ; Fri, 31 Mar 2006 20:19:17 +0000 (UTC) (envelope-from ericx_lists@vineyard.net) Received: from smtp1.vineyard.net (a1.vineyard.net [204.17.195.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DADC43D48 for ; Fri, 31 Mar 2006 20:19:15 +0000 (GMT) (envelope-from ericx_lists@vineyard.net) Received: from localhost (loopback [127.0.0.1]) by smtp1.vineyard.net (Postfix) with ESMTP id 3EEC115818B5 for ; Fri, 31 Mar 2006 15:19:14 -0500 (EST) Received: from smtp1.vineyard.net ([127.0.0.1]) by localhost (ace1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08773-01-8 for ; Fri, 31 Mar 2006 15:19:13 -0500 (EST) Received: from [204.17.195.104] (fortiva.vineyard.net [204.17.195.104]) by smtp1.vineyard.net (Postfix) with ESMTP id C623115818A5 for ; Fri, 31 Mar 2006 15:19:13 -0500 (EST) Message-ID: <442D8E98.6050903@vineyard.net> Date: Fri, 31 Mar 2006 15:18:32 -0500 From: "Eric W. Bates" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-ace1 at Vineyard.NET Subject: tcpdump and 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, 31 Mar 2006 20:19:17 -0000 This seems like a dumb question; but I wonder if one can use tcpdump to view the decrypted out flow from and esp tunnel? I have an established tunnel on machine 'firewall'. The tunnel is a route between net 10.128.10.0/24 and 192.168.10.0/24. 'firewall' has 192.168.10.1 as the ip on its internal interface. When I ping 10.128.10.1 using 192.168.10.1 as the source address, I can use tcpdump to view the esp packets via the external interface. Is there a way to use tcpdump to view the packets as they traverse from the tunnel to 192.168.10.1? I had no luck attaching tcpdump to the internal interface. By the same token, can I hook any of the traffic with ipfw? I suspect that if any of this traffic were leaving the machine, I would see it; but maybe not if 'firewall' itself is the destination? Thanks for your time. From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 22:17:44 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D27E16A458 for ; Fri, 31 Mar 2006 22:17:44 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from zig.murex.com (mail.murex.com [194.98.239.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id C874D43D49 for ; Fri, 31 Mar 2006 22:17:43 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from interscan.fr.murex.com (interscan.fr.murex.com [172.21.17.207] (may be forged)) by zig.murex.com with ESMTP id k2VMJgTg016147; Sat, 1 Apr 2006 00:19:42 +0200 (CEST) Received: from mxmail.murex.com (interscan.murex.fr [127.0.0.1]) by interscan.fr.murex.com (8.11.6/8.11.6) with ESMTP id k2VMnMj04695; Sat, 1 Apr 2006 00:49:22 +0200 Received: from [172.21.130.86] ([172.21.130.86]) by mxmail.murex.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 Apr 2006 00:17:08 +0200 From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Luigi Rizzo Date: Fri, 31 Mar 2006 17:17:07 -0500 User-Agent: KMail/1.9.1 References: <200603301657.43218.mi+mx@aldan.algebra.com> <20060330140636.A98058@xorpc.icir.org> In-Reply-To: <20060330140636.A98058@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200603311717.07894.mi+mx@aldan.algebra.com> X-OriginalArrivalTime: 31 Mar 2006 22:17:09.0249 (UTC) FILETIME=[DA08DF10:01C65510] Cc: ugen@netvision.net.il, archie@dellroad.org, net@freebsd.org Subject: Re: Is there an API for ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 22:17:44 -0000 четвер 30 березень 2006 17:06, Luigi Rizzo написав: > If you are doing it a lot more often, you should probably > also consider the effect of such frequent changes to the > pipe's configuration - e.g. pipes respond with a delay > which is inversely proportional to the bandwidth, so in > many cases still doesn't make sense to change the pipe's > rate 100 times per second. So far I'm just playing with the rules manually. I create a pipe with: ipfw pipe 1 config bandwidth 22200KByte/s and send all NFS traffic through it with: ipfw add 100 pipe 1 ip from any to 172.21.128.43 dst-port 2049 This works most of the times, but if sometimes, when I try to change the bandwidth from command line: ipfw pipe 1 config bandwidth 24MByte/s the NFS clients stops writing ALTOGETHER and begins logging complaints about the NFS server (172.21.128.43) not responding. At that point, I must delete the rule 100. The other rules are simply: 65533 allow ip from any to any 65535 deny ip from any to any Why would altering the bandwidth slightly (up) freeze all traffic through the pipe? Thanks! -mi From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 22:28:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D0FC16A420 for ; Fri, 31 Mar 2006 22:28:24 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from leia.fdn.fr (ns0.fdn.org [80.67.169.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDD4543D69 for ; Fri, 31 Mar 2006 22:28:23 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by leia.fdn.fr (8.13.3/8.13.3/FDN) with ESMTP id k2VMSKDZ005457 for ; Sat, 1 Apr 2006 00:28:21 +0200 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 9BA513F17; Sat, 1 Apr 2006 00:28:13 +0200 (CEST) Date: Sat, 1 Apr 2006 00:28:13 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20060331222813.GA29047@zen.inc> References: <442D8E98.6050903@vineyard.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <442D8E98.6050903@vineyard.net> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: tcpdump and 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, 31 Mar 2006 22:28:24 -0000 On Fri, Mar 31, 2006 at 03:18:32PM -0500, Eric W. Bates wrote: > This seems like a dumb question; but I wonder if one can use tcpdump to > view the decrypted out flow from and esp tunnel? > > I have an established tunnel on machine 'firewall'. > > The tunnel is a route between net 10.128.10.0/24 and 192.168.10.0/24. > > 'firewall' has 192.168.10.1 as the ip on its internal interface. > > When I ping 10.128.10.1 using 192.168.10.1 as the source address, I can > use tcpdump to view the esp packets via the external interface. > > Is there a way to use tcpdump to view the packets as they traverse from > the tunnel to 192.168.10.1? I had no luck attaching tcpdump to the > internal interface. > > By the same token, can I hook any of the traffic with ipfw? > > I suspect that if any of this traffic were leaving the machine, I would > see it; but maybe not if 'firewall' itself is the destination? You can do that by various ways: 1) Use the ESP decryption option of tcpdump. Of course, you'll have to provide the encryption key to tcpdump. 2) use enc0 support, which is actually pr kern/94829, and which should be included soon in kernel. Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 22:36:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C30816A424 for ; Fri, 31 Mar 2006 22:36:17 +0000 (UTC) (envelope-from bms@spc.org) Received: from mindfull.spc.org (mindfull.spc.org [83.167.185.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F5F743D66 for ; Fri, 31 Mar 2006 22:36:15 +0000 (GMT) (envelope-from bms@spc.org) Received: from arginine.spc.org ([83.167.185.2]) by mindfull.spc.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FPSDx-0000wY-33; Fri, 31 Mar 2006 23:36:09 +0100 Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 3AF6A65654; Fri, 31 Mar 2006 23:36:14 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 87086-01; Fri, 31 Mar 2006 23:36:13 +0100 (BST) Received: by arginine.spc.org (Postfix, from userid 1078) id 5EDA96564E; Fri, 31 Mar 2006 23:36:13 +0100 (BST) Date: Fri, 31 Mar 2006 23:36:13 +0100 From: Bruce M Simpson To: VANHULLEBUS Yvan Message-ID: <20060331223613.GD80492@spc.org> Mail-Followup-To: Bruce M Simpson , VANHULLEBUS Yvan , freebsd-net@freebsd.org References: <442D8E98.6050903@vineyard.net> <20060331222813.GA29047@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060331222813.GA29047@zen.inc> User-Agent: Mutt/1.4.1i Organization: Incunabulum X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mindfull.spc.org X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - spc.org X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-net@freebsd.org Subject: Re: tcpdump and 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, 31 Mar 2006 22:36:17 -0000 On Sat, Apr 01, 2006 at 12:28:13AM +0200, VANHULLEBUS Yvan wrote: > 2) use enc0 support, which is actually pr kern/94829, and which should > be included soon in kernel. Oh god! Not another ifnet! NoOOOOOO!!!!!! *runs away* From owner-freebsd-net@FreeBSD.ORG Sat Apr 1 05:31:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CCFD16D450; Sat, 1 Apr 2006 05:29:08 +0000 (UTC) (envelope-from michael@staff.openaccess.org) Received: from smtp.openaccess.org (smtp.openaccess.org [66.165.52.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C0FB43D4C; Sat, 1 Apr 2006 05:29:05 +0000 (GMT) (envelope-from michael@staff.openaccess.org) Received: from [10.0.1.2] (unknown [216.57.214.93]) by smtp.openaccess.org (Postfix) with ESMTP id 83DEE6D4977; Fri, 31 Mar 2006 21:28:19 -0800 (PST) In-Reply-To: <20060331071115.GC884@trit.org> References: <014e01c64928$6107abd0$020b000a@bartwrkstxp> <20060316193740.GE11850@spc.org> <20060325092123.GB5468@trit.org> <20060331071115.GC884@trit.org> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21DCE1FA-4A7E-443F-8EFA-9E3CC7CE1C30@staff.openaccess.org> Content-Transfer-Encoding: 7bit From: Michael DeMan Date: Fri, 31 Mar 2006 21:29:09 -0800 To: Dima Dorfman X-Mailer: Apple Mail (2.746.3) Cc: Bart Van Kerckhove , "freebsd-net@FreeBSD.org" Subject: Re: OT - Quagga/CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2006 05:31:18 -0000 Hi, See inline... On Mar 30, 2006, at 11:11 PM, Dima Dorfman wrote: > Michael DeMan wrote: >> So, if you already have a route to 10.100.100.0/24 via OSPF to >> another machine, then try to... >> >> ip address 10.100.100.55/24 >> >> You get an error. > > Is that the only problem? Someone was talking about funding > development to fix something--surely there must be something more > severe than the inability to use the "ip address" interface command? I > thought the problem was about encoutering broken ingress paths if one > of the routers loses connectivity to the destination network. > My understanding is that my issue is just one symptom of a general limitation in the kernel routing tables or something, and that fixing this problem would also allow multi-path routing for FreeBSD, which is probably a bigger 'win' for the community overall. > Does the combination of CARP and quagga OSPF work once it's configured > using system tools? Yes, it will work then. However, I still have to kill and restart the zebra and ospf processes entirely for them to pick things up correctly. > >> It is possible to force the interface configuration via 'ifconfig' on >> the UNIX command line, but for this equipment I want all interface >> configuration and routing driven out of Quagga. > > It would be cool if that was possible, but it's not really practical. > My systems tend to have a lot of very custom configuration that quagga > will never be able to express. If I had a cookie-cutter configuration, > I'd probably be using a C or J box. > > While I've found bgpd and ospfd to be very stable, the zebra part that > interacts with the kernel has had various problems over time--routes > not being installed correctly, or going away, or having incorrect > flags. I wouldn't trust it to configure the entire network subsystem. > I've noticed some oddities with zebra too, but never anything that is a show-stopper. There was some kind of bug with notifications of interface 'up/down' not getting propogated correctly between zebra/ kernel, but that seems to be fixed. We do some scripting for automation of firewall rules for the routers to protect themselves, but at this point I have no need of the UNIX command line on these machines on a regular basis. The idea of using ifconfig, rc.conf and Quagga.conf to manage multiple machines, especially with automated management tools, is just impossible. Long term manageability is the goal. If everything is just in zebra/ quagga, then I just have one file to manage - Quagga.conf - for all backup, change control and managing lots of boxes in the field means I want much of the management driven straight out of our customer management application. Basically, fast/easy to turn up/down an office suite, colocation box, microwave circuit, for a customer right off our internal management system. > Dima. > >> On Mar 25, 2006, at 1:21 AM, Dima Dorfman wrote: >> >>> Michael DeMan wrote: >>>> Anyway, thanks very much for the information. I'm going to have to >>>> figure out some kind of workaround on my architecture. In the >>>> worst >>>> case, I can shut off OSPF on the edge routers and use static routes >>>> upstream and OSPF from there, but that is going to be a real >>>> nightmare for network maintenance over the long haul. >>> >>> You're talking about using CARP and OSPF on the edge routers, right? >>> >>> Can you explain a little more why CARP and zebra/ospfd don't play >>> well >>> together? I understand the problem about having two copies of the >>> same >>> route in the FIB, but I don't think it should prevent redundancy >>> from >>> working. I am planning to deploy FreeBSD-based access routers in the >>> near future, and I'd like to have an idea of what issues I'll be >>> facing. >>> >>> The scenario I have in mind is two FreeBSD boxes connected to the >>> rest >>> of the network on one side and clients (using carp) on the other. >>> CARP >>> is supposed to protect the client against one of the routers >>> failing. >>> I tried this on some test boxes today, and it looks like it should >>> work. Both boxes are configured as OSPF neighbors and share a CARP >>> vhid. When both links are up, each router has a route through the >>> physical interface (it also sees the OSPF route, but the connected >>> route is better). If one of the links fails (any condition that >>> causes >>> the physical interface to be down), the routes are withdrawn, the >>> other box takes over the VIP, and the first box installs the OSPF >>> route. Everything is still reachable. >>> >>> Am I missing an obvious problem or a case where this doesn't work? >> From owner-freebsd-net@FreeBSD.ORG Sat Apr 1 20:57:35 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B613D16A400 for ; Sat, 1 Apr 2006 20:57:35 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70CA343D68 for ; Sat, 1 Apr 2006 20:57:32 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k31KvJlO029252; Sat, 1 Apr 2006 12:57:19 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k31KvIo8029251; Sat, 1 Apr 2006 12:57:18 -0800 (PST) (envelope-from rizzo) Date: Sat, 1 Apr 2006 12:57:18 -0800 From: Luigi Rizzo To: Mikhail Teterin Message-ID: <20060401125718.A28991@xorpc.icir.org> References: <200603301657.43218.mi+mx@aldan.algebra.com> <20060330140636.A98058@xorpc.icir.org> <200603311717.07894.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <200603311717.07894.mi+mx@aldan.algebra.com>; from mi+mx@aldan.algebra.com on Fri, Mar 31, 2006 at 05:17:07PM -0500 Cc: ugen@netvision.net.il, archie@dellroad.org, net@freebsd.org Subject: Re: Is there an API for ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2006 20:57:35 -0000 On Fri, Mar 31, 2006 at 05:17:07PM -0500, Mikhail Teterin wrote: > четвер 30 березень 2006 17:06, Luigi Rizzo написав: > > If you are doing it a lot more often, you should probably > > also consider the effect of such frequent changes to the > > pipe's configuration - e.g. pipes respond with a delay > > which is inversely proportional to the bandwidth, so in > > many cases still doesn't make sense to change the pipe's > > rate 100 times per second. > > So far I'm just playing with the rules manually. I create a pipe with: > > ipfw pipe 1 config bandwidth 22200KByte/s > > and send all NFS traffic through it with: > > ipfw add 100 pipe 1 ip from any to 172.21.128.43 dst-port 2049 > > This works most of the times, but if sometimes, when I try to change the > bandwidth from command line: > > ipfw pipe 1 config bandwidth 24MByte/s > > the NFS clients stops writing ALTOGETHER and begins logging complaints about > the NFS server (172.21.128.43) not responding. At that point, I must delete > the rule 100. The other rules are simply: > > 65533 allow ip from any to any > 65535 deny ip from any to any > > Why would altering the bandwidth slightly (up) freeze all traffic through the > pipe? Thanks! i don't know on which version of freebsd is this occurring, it would help knowning - as well as knowing if this is an UP/SMP and whether it is working as a bridge or router. Internally, dummynet computes the next tick when the pipe should be processed based on the current bandwidth (see the SET_TICKS macro in ip_dummynet.c), and when the time arrives, the computations are done using the 'new' bandwidth value (see near the beginning of funcrion 'ready_event()'. As far as i can tell (at least on 4.x) the code seems to handle changes in the bandwidth in the correct way, so the only thing i can suspect is some bug related to insufficient locking between the setsockopt and the soft interrupt handler. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Apr 1 23:34:21 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 341C816A41F for ; Sat, 1 Apr 2006 23:34:21 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BE2043D55 for ; Sat, 1 Apr 2006 23:34:18 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan [127.0.0.1]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k31NYFwl020660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Apr 2006 18:34:15 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.6/8.13.6/Submit) id k31NYC7S020659; Sat, 1 Apr 2006 18:34:12 -0500 (EST) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: Luigi Rizzo , ugen@netvision.net.il, archie@dellroad.org, net@freebsd.org Date: Sat, 1 Apr 2006 18:34:12 -0500 User-Agent: KMail/1.8.2 References: <200603301657.43218.mi+mx@aldan.algebra.com> <200603311717.07894.mi+mx@aldan.algebra.com> <20060401125718.A28991@xorpc.icir.org> In-Reply-To: <20060401125718.A28991@xorpc.icir.org> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Cc: Subject: Re: Is there an API for ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2006 23:34:21 -0000 On Saturday 01 April 2006 03:57 pm, you wrote: = i don't know on which version of freebsd is this occurring, = it would help knowning - as well as knowing if this is an = UP/SMP and whether it is working as a bridge or router. It is a FreeBSD/amd64-6.1 as of February 7, running on a signle Opteron 244 (hence UP). Machine has 2Gb of RAM and the active interface is em0 in full duplex 1GB mode. The ipfw and dummynet are loaded modules, not compiled in (don't know, if that matters). Without the pipes, the same Sun machine (NFS client) sends this data at around 36Mb/s, which is too fast for my program to compress, so I'd like to be able to throttle it. Thanks! Yours, -mi