From owner-freebsd-net@FreeBSD.ORG Sun Oct 8 05:30:26 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC70C16A403 for ; Sun, 8 Oct 2006 05:30:26 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97D2443D49 for ; Sun, 8 Oct 2006 05:30:26 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k985UQ8N074356 for ; Sun, 8 Oct 2006 05:30:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k985UQde074355; Sun, 8 Oct 2006 05:30:26 GMT (envelope-from gnats) Date: Sun, 8 Oct 2006 05:30:26 GMT Message-Id: <200610080530.k985UQde074355@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Astrodog Cc: Subject: Re: kern/95665: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Astrodog List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2006 05:30:26 -0000 The following reply was made to PR kern/95665; it has been noted by GNATS. From: Astrodog To: bug-followup@FreeBSD.org, johan@nocrew.org Cc: Subject: Re: kern/95665: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) Date: Sun, 8 Oct 2006 00:22:20 -0500 I can reproduce this problem with some ease. It occurs when the buffer for tun0 fills up, because the NIC is unable to send the packets as quickly as the program is generating them. This is fairly common on slow or dodgy NICs, when combined with tun/gif/etc. There is not a real fix, because the outgoing NIC used by tun can change, so any attempt to make it aware of the buffer, and throttle accordingly would be painfully hacked together. To confirm that this is actually the issue, increase the size of the buffer. You should see a larger number of packets make it through. From owner-freebsd-net@FreeBSD.ORG Sun Oct 8 19:43:39 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EDFA16A416; Sun, 8 Oct 2006 19:43:39 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9076B43D5E; Sun, 8 Oct 2006 19:43:38 +0000 (GMT) (envelope-from thompsa@FreeBSD.org) Received: from freefall.freebsd.org (thompsa@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k98Jhcau074225; Sun, 8 Oct 2006 19:43:38 GMT (envelope-from thompsa@freefall.freebsd.org) Received: (from thompsa@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k98JhcYl074220; Sun, 8 Oct 2006 19:43:38 GMT (envelope-from thompsa) Date: Sun, 8 Oct 2006 19:43:38 GMT From: Andrew Thompson Message-Id: <200610081943.k98JhcYl074220@freefall.freebsd.org> To: hsn@netmag.cz, thompsa@FreeBSD.org, freebsd-net@FreeBSD.org, thompsa@FreeBSD.org Cc: Subject: Re: kern/102607: [if_bridge] don't generate random L2 address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Oct 2006 19:43:39 -0000 Synopsis: [if_bridge] don't generate random L2 address State-Changed-From-To: open->patched State-Changed-By: thompsa State-Changed-When: Sun Oct 8 19:42:02 UTC 2006 State-Changed-Why: Committed. I decided not to include the link address in the example as it shouldnt need to be set in the default case. Responsible-Changed-From-To: freebsd-net->thompsa Responsible-Changed-By: thompsa Responsible-Changed-When: Sun Oct 8 19:42:02 UTC 2006 Responsible-Changed-Why: Committed. I decided not to include the link address in the example as it shouldnt need to be set in the default case. http://www.freebsd.org/cgi/query-pr.cgi?pr=102607 From owner-freebsd-net@FreeBSD.ORG Mon Oct 9 03:37: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 C41F716A416 for ; Mon, 9 Oct 2006 03:37:55 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01B6943D4C for ; Mon, 9 Oct 2006 03:37:54 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.61 (FreeBSD)) (envelope-from ) id 1GWlxY-000HNI-4B; Mon, 09 Oct 2006 11:37:44 +0800 Message-ID: <4529C408.5070807@micom.mng.net> Date: Mon, 09 Oct 2006 11:37:44 +0800 From: Ganbold User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: Alexander Motin References: <1159971789.00612536.1159960802@10.7.7.3> <4524055D.7060906@mavhome.dp.ua> In-Reply-To: <4524055D.7060906@mavhome.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Oct 2006 03:37:55 -0000 Alexander Motin wrote: > Hi. > > Ganbold wrote: >> Oh, I put up my question wrong. Anyway, can mpd listen on many vlan >> interfaces? >> Maybe something like: >> >> set pppoe iface vlan0,vlan1,etc > > One PPPoE link can listen on the only one interface/vlan. But you can > create many links to listen on many interfaces/vlans. Create one or > more link for each interface. > You mean something like this that I have in my mpd.conf: default: load server1 load server2 load server3 ... set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set pppoe iface bge1 # set pppoe iface vlan0 set pppoe service "*" set pppoe disable originate set pppoe enable incoming ... server1: new -i ng1 pppoe1 pppoe1 set ipcp ranges x.x.x.x/32 y.y.y.y/24 load pppoe_standard server2: new -i ng2 pppoe2 pppoe2 set ipcp ranges x.x.x.x/32 y.y.y.y/24 load pppoe_standard server3: new -i ng3 pppoe3 pppoe3 set ipcp ranges x.x.x.x/32 y.y.y.y/24 load pppoe_standard ... mpd.links file: pppoe1: set link type pppoe set pppoe enable incoming set pppoe disable originate pppoe2: set link type pppoe set pppoe enable incoming set pppoe disable originate pppoe3: set link type pppoe set pppoe enable incoming set pppoe disable originate ... Ganbold From owner-freebsd-net@FreeBSD.ORG Mon Oct 9 07:55:58 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 70AC116A4A0 for ; Mon, 9 Oct 2006 07:55:58 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B89A43D45 for ; Mon, 9 Oct 2006 07:55:57 +0000 (GMT) (envelope-from mav@mavhome.dp.ua) X-Spam-Level: 46 [XX] (100%) BAYESIAN TRAINING: 80-89 Received: from [212.86.226.11] (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 17127310; Mon, 09 Oct 2006 10:55:55 +0300 Message-ID: <452A008B.8040804@mavhome.dp.ua> Date: Mon, 09 Oct 2006 10:55:55 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20051108 MIME-Version: 1.0 To: Ganbold References: <1159971789.00612536.1159960802@10.7.7.3> <4524055D.7060906@mavhome.dp.ua> <4529C408.5070807@micom.mng.net> In-Reply-To: <4529C408.5070807@micom.mng.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Oct 2006 07:55:58 -0000 Hi Ganbold wrote: >>> Oh, I put up my question wrong. Anyway, can mpd listen on many vlan >>> interfaces? >>> Maybe something like: >>> >>> set pppoe iface vlan0,vlan1,etc >> >> One PPPoE link can listen on the only one interface/vlan. But you can >> create many links to listen on many interfaces/vlans. Create one or >> more link for each interface. >> > You mean something like this that I have in my mpd.conf: I mean something like this: default: load server1 load server2 load server3 ... pppoe_standard: set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set pppoe service "*" set pppoe disable originate set pppoe enable incoming ... server1: new -i ng1 pppoe1 pppoe1 set ipcp ranges x.x.x.x/32 y.y.y.y/24 load pppoe_standard server2: new -i ng2 pppoe2 pppoe2 set ipcp ranges x.x.x.x/32 y.y.y.y/24 load pppoe_standard server3: new -i ng3 pppoe3 pppoe3 set ipcp ranges x.x.x.x/32 y.y.y.y/24 load pppoe_standard ... mpd.links file: pppoe1: set link type pppoe set pppoe iface vlan0 pppoe2: set link type pppoe set pppoe iface vlan1 pppoe3: set link type pppoe set pppoe iface vlan2 ... -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Mon Oct 9 08:58: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 579A116A417 for ; Mon, 9 Oct 2006 08:58:29 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A4D443D46 for ; Mon, 9 Oct 2006 08:58:27 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.61 (FreeBSD)) (envelope-from ) id 1GWqxn-000Jv8-2w; Mon, 09 Oct 2006 16:58:19 +0800 Message-ID: <452A0F2A.3000901@micom.mng.net> Date: Mon, 09 Oct 2006 16:58:18 +0800 From: Ganbold User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: Alexander Motin References: <1159971789.00612536.1159960802@10.7.7.3> <4524055D.7060906@mavhome.dp.ua> <4529C408.5070807@micom.mng.net> <452A008B.8040804@mavhome.dp.ua> In-Reply-To: <452A008B.8040804@mavhome.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Oct 2006 08:58:29 -0000 Alexander, Alexander Motin wrote: > I mean something like this: > > default: > load server1 > load server2 > load server3 > .. > pppoe_standard: > set ccp yes mpp-e40 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > set pppoe service "*" > set pppoe disable originate > set pppoe enable incoming > .. > server1: > new -i ng1 pppoe1 pppoe1 > set ipcp ranges x.x.x.x/32 y.y.y.y/24 > load pppoe_standard > server2: > new -i ng2 pppoe2 pppoe2 > set ipcp ranges x.x.x.x/32 y.y.y.y/24 > load pppoe_standard > server3: > new -i ng3 pppoe3 pppoe3 > set ipcp ranges x.x.x.x/32 y.y.y.y/24 > load pppoe_standard > .. > > mpd.links file: > pppoe1: > set link type pppoe > set pppoe iface vlan0 > pppoe2: > set link type pppoe > set pppoe iface vlan1 > pppoe3: > set link type pppoe > set pppoe iface vlan2 > .. > OK, so I have to create vlans first on the system and then configure mpd.links file accordingly and take out the "set pppoe iface bge1" line from mpd.conf. I will try it sometime later and let you know how it goes. thanks a lot, Ganbold From owner-freebsd-net@FreeBSD.ORG Mon Oct 9 09:28: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 D62D916A407 for ; Mon, 9 Oct 2006 09:28:44 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00FC543D45 for ; Mon, 9 Oct 2006 09:28:43 +0000 (GMT) (envelope-from mav@mavhome.dp.ua) X-Spam-Level: 64 [XX] (100%) BAYESIAN TRAINING: 100 Received: from [212.86.226.11] (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 17129557; Mon, 09 Oct 2006 12:28:43 +0300 Message-ID: <452A164A.9080507@mavhome.dp.ua> Date: Mon, 09 Oct 2006 12:28:42 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20051108 MIME-Version: 1.0 To: Ganbold References: <1159971789.00612536.1159960802@10.7.7.3> <4524055D.7060906@mavhome.dp.ua> <4529C408.5070807@micom.mng.net> <452A008B.8040804@mavhome.dp.ua> <452A0F2A.3000901@micom.mng.net> In-Reply-To: <452A0F2A.3000901@micom.mng.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Oct 2006 09:28:44 -0000 Ganbold wrote: > OK, so I have to create vlans first on the system and then configure > mpd.links file accordingly and take out the "set pppoe iface bge1" line > from mpd.conf. I will try it sometime later and let you know how it goes. Somebody should strip vlan header. If not a system (if you dont like to create vlans) and not mpd (this is not its business) then who? It will work fine. vlan for mpd is like a usual ethernet interface without any specifics. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Mon Oct 9 11:09: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 BFD1A16A49E for ; Mon, 9 Oct 2006 11:09:19 +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 8A10543DBC for ; Mon, 9 Oct 2006 11:08:49 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k99B8aax071605 for ; Mon, 9 Oct 2006 11:08:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k99B8YWt071600 for freebsd-net@FreeBSD.org; Mon, 9 Oct 2006 11:08:34 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Oct 2006 11:08:34 GMT Message-Id: <200610091108.k99B8YWt071600@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2006 11:09:19 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/52585 net [netinet] [patch] Kernel panic with ipfw2 and syncooki o kern/92552 net A serious bug in most network drivers from 5.X to 6.X f kern/93220 net [inet6] nd6_lookup: failed to add route for a neighbor s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n 9 problems total. From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 01:18:23 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 928E616A407 for ; Tue, 10 Oct 2006 01:18:23 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1BD643D45 for ; Tue, 10 Oct 2006 01:18:22 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=[192.168.0.18]) by publicd.ub.mng.net with esmtpa (Exim 4.61 (FreeBSD)) (envelope-from ) id 1GX6G7-000PuL-U4; Tue, 10 Oct 2006 09:18:16 +0800 Message-ID: <452AF4D7.6030906@micom.mng.net> Date: Tue, 10 Oct 2006 09:18:15 +0800 From: Ganbold User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: Alexander Motin References: <1159971789.00612536.1159960802@10.7.7.3> <4524055D.7060906@mavhome.dp.ua> <4529C408.5070807@micom.mng.net> <452A008B.8040804@mavhome.dp.ua> <452A0F2A.3000901@micom.mng.net> <452A164A.9080507@mavhome.dp.ua> In-Reply-To: <452A164A.9080507@mavhome.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: mpd and vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 01:18:23 -0000 Alexander Motin wrote: > Ganbold wrote: >> OK, so I have to create vlans first on the system and then configure >> mpd.links file accordingly and take out the "set pppoe iface bge1" >> line from mpd.conf. I will try it sometime later and let you know how >> it goes. > > Somebody should strip vlan header. What you mean by strip vlan header? thanks, Ganbold > If not a system (if you dont like to create vlans) and not mpd (this > is not its business) then who? > > It will work fine. vlan for mpd is like a usual ethernet interface > without any specifics. > From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 02:12: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 C88ED16A403 for ; Tue, 10 Oct 2006 02:12:34 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from mail.stovebolt.com (mail.stovebolt.com [66.221.101.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id A340943D7C for ; Tue, 10 Oct 2006 02:12:22 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from [192.168.2.102] (adsl-68-93-62-100.dsl.rcsntx.swbell.net [68.93.62.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.stovebolt.com (Postfix) with ESMTP id BAB54114307 for ; Mon, 9 Oct 2006 21:14:13 -0500 (CDT) Date: Mon, 09 Oct 2006 21:12:07 -0500 From: Paul Schmehl To: freebsd-net@freebsd.org Message-ID: X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========C99907A05FF4933AB41E==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 02:12:34 -0000 --==========C99907A05FF4933AB41E========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I've been trying to get this to work on my laptop without success.=20 According to this page -=20 - the ipw driver=20 should work. I can load the driver, but it doesn't show up in dmesg. kldstat -n if_ipw Id Refs Address Size Name 10 1 0xc52d0000 9000 if_ipw.ko dmesg | grep ipw uname -a FreeBSD hostname.utdallas.edu 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May=20 7 04:32:43 UTC 2006=20 root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 The startup script, that's supposed to download the firmware, fails, of=20 course. /etc/rc.d/ipw start Starting ipw [ipw0:bss]ipwcontrol: Can't load /boot/firmware/ipw.fw to=20 driver: Device not configured Have I missed something? Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========C99907A05FF4933AB41E==========-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 02:33: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 0160316A407 for ; Tue, 10 Oct 2006 02:33:57 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51C6A43D58 for ; Tue, 10 Oct 2006 02:33:56 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.185.104] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GX7RL0jR9-0003TJ; Tue, 10 Oct 2006 04:33:55 +0200 From: Max Laier Organization: FreeBSD To: Paul Schmehl Date: Tue, 10 Oct 2006 04:33:35 +0200 User-Agent: KMail/1.9.4 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2226331.MQCKfHaGEq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200610100433.53511.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-net@freebsd.org Subject: Re: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 02:33:57 -0000 --nextPart2226331.MQCKfHaGEq Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 10 October 2006 04:12, Paul Schmehl wrote: > I've been trying to get this to work on my laptop without success. > According to this page - > - the ipw driver > should work. I can load the driver, but it doesn't show up in dmesg. You are mistaken, I'm afraid. This has been discussed a couple of time=20 already. The ipw(4) driver supports the now already quite dated 2100bg=20 cards. Support for the new 3945abg is not available - other than ndis(4)=20 and I don't know if that works or not. OpenBSD has a driver by the name=20 of wpi(4). This is probably the point to start from if you were to write=20 a FreeBSD one. > kldstat -n if_ipw > Id Refs Address Size Name > 10 1 0xc52d0000 9000 if_ipw.ko > > dmesg | grep ipw > > uname -a > FreeBSD hostname.utdallas.edu 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun > May 7 04:32:43 UTC 2006 > root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > The startup script, that's supposed to download the firmware, fails, of > course. > > /etc/rc.d/ipw start > Starting ipw [ipw0:bss]ipwcontrol: Can't load /boot/firmware/ipw.fw to > driver: Device not configured > > Have I missed something? > > Paul Schmehl (pauls@utdallas.edu) > Adjunct Information Security Officer > The University of Texas at Dallas > http://www.utdallas.edu/ir/security/ =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 --nextPart2226331.MQCKfHaGEq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFKwaRXyyEoT62BG0RAllTAJ4w5czhGacbJ8n4hR6X0raNf0jx9QCfVpHy m4iFoBLkcexXnb7Y77r6O5g= =VjpV -----END PGP SIGNATURE----- --nextPart2226331.MQCKfHaGEq-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 03:09:43 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 2EB3E16A403 for ; Tue, 10 Oct 2006 03:09:43 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from mail.stovebolt.com (webmail.stovebolt.com [66.221.101.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B6B43D55 for ; Tue, 10 Oct 2006 03:09:42 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from [192.168.2.102] (adsl-68-93-62-100.dsl.rcsntx.swbell.net [68.93.62.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.stovebolt.com (Postfix) with ESMTP id F33B8114307 for ; Mon, 9 Oct 2006 22:11:34 -0500 (CDT) Date: Mon, 09 Oct 2006 22:09:38 -0500 From: Paul Schmehl To: freebsd-net@freebsd.org Message-ID: <9476505F959C119216F6FF6D@paul-schmehls-powerbook59.local> In-Reply-To: <200610100433.53511.max@love2party.net> References: <200610100433.53511.max@love2party.net> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========7F75582F812E67B3F98B==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 03:09:43 -0000 --==========7F75582F812E67B3F98B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On October 10, 2006 4:33:35 AM +0200 Max Laier =20 wrote: > On Tuesday 10 October 2006 04:12, Paul Schmehl wrote: >> I've been trying to get this to work on my laptop without success. >> According to this page - >> - the ipw driver >> should work. I can load the driver, but it doesn't show up in dmesg. > > You are mistaken, I'm afraid. This has been discussed a couple of time > already. The ipw(4) driver supports the now already quite dated 2100bg > cards. Support for the new 3945abg is not available - other than > ndis(4) and I don't know if that works or not. OpenBSD has a driver by > the name of wpi(4). This is probably the point to start from if you > were to write a FreeBSD one. > I guess I'm screwed them. I tried to create a module using ndisgen, but=20 when I try to load the module, it crashes the system and forces a complete = restart. I'm afraid I don't have the skills to write a device driver. Thanks for the info. Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========7F75582F812E67B3F98B==========-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 04:25:05 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 A2AE916A407 for ; Tue, 10 Oct 2006 04:25:05 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EA1B43D53 for ; Tue, 10 Oct 2006 04:25:04 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2471540pye for ; Mon, 09 Oct 2006 21:25:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=O8uAxPIwGTiZlERVG1nxLyuB8iaTu7lr3vZvDHbcWKDLG88oNs+t5FOoDY53H/1PNKG+I99XazkvE0s55C53s6m1hIWFskG+RNlO5QVOOVLkXUWQDwHeenG2ZcJqBU8B+5GUVsVWCrgUKe9Ya4oCvTLVUFpbriDUUPPH7nJyot0= Received: by 10.35.99.17 with SMTP id b17mr14428155pym; Mon, 09 Oct 2006 21:25:04 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 15sm2037183nzo.2006.10.09.21.25.02; Mon, 09 Oct 2006 21:25:04 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k9A4OjA1008350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Oct 2006 13:24:45 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k9A4Ohb2008349; Tue, 10 Oct 2006 13:24:43 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 10 Oct 2006 13:24:43 +0900 From: Pyun YongHyeon To: Tim Allender Message-ID: <20061010042443.GB7419@cdnetworks.co.kr> References: <4520695C.9060302@goldenpath.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4520695C.9060302@goldenpath.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: D-Link DGE-530T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2006 04:25:05 -0000 On Sun, Oct 01, 2006 at 09:20:28PM -0400, Tim Allender wrote: > Come's with fbsd 5.3 drivers, but not 6.1. > Is there an easy way out? > I've always wanted to learn about writing drivers. > But, I don't know if I'm up for it, and I need these things to work now. The sk(4) driver in RELENG_6/6.2-PRERELEASE got various fixes and enhancements and supports your second generation DGE-530T. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 06:36: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 3298816A4C9 for ; Tue, 10 Oct 2006 06:36:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CD0243D5E for ; Tue, 10 Oct 2006 06:36:15 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2513207pye for ; Mon, 09 Oct 2006 23:36:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=QBIIfdKNUEI0o6lcPbx79INvsL30UebLzXS0xoGrJVQWrWdwmcS+7SaXg+r8iReW4Kt51gnS+H7dxlpf0W7hiC1Y9qkjLyi80EVWf4U1R/E9jSXXV7EmuJoqBn679hRzsBXn9+pmoIKWbsP+On/1tmThjp6YIUN7fdUTnNaAmfI= Received: by 10.35.91.1 with SMTP id t1mr14599772pyl; Mon, 09 Oct 2006 23:36:14 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 20sm2076129nzp.2006.10.09.23.36.12; Mon, 09 Oct 2006 23:36:13 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k9A6Zw6B008647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Oct 2006 15:35:58 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k9A6Zu41008646; Tue, 10 Oct 2006 15:35:56 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 10 Oct 2006 15:35:56 +0900 From: Pyun YongHyeon To: Artem Belevich Message-ID: <20061010063556.GC7419@cdnetworks.co.kr> References: <4525FD2A.6060509@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, "Andrey V. Elsukov" Subject: Re: 88E8053 Yukon2 PCI-E GbE - any plans to port msk() driver from OpenBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2006 06:36:16 -0000 On Fri, Oct 06, 2006 at 01:09:05AM -0700, Artem Belevich wrote: > Andrey, thanks for the pointer. > > Pyun, > > Thanks a lot for the driver. Considering that question about support > for Yukon2 based cards was popping up on this list for more than a > year, I'm pretty sure I'm not the only one who appreciates your work. > > BTW, your driver seems to be largely based on Marvel's driver, while Yes. > the one in OpenBSD seems to be patched up if_sk. Can you give an > overview of the current status of your driver - stability, > supported/unsupported features, etc.? Would that be possible to get I've adopted the OpenBSD interface name msk(4) to reduce naming differences between BSDs. Personally I think we should give Marvell credit for their BSD-licensed myk(4). Without myk(4) writing a driver for the hardware would be impossible. I don't think OpenBSD can solve various hardware issues without Yukon II datasheet which is not available to developers. FreeBSD msk(4) has workaround code obtained from myk(4). The driver supports the following hardware features. o Tx TCP/UDP checksum offload o Rx IP checksum offload o VLAN hardware tag stripping/insertion o Jumbo frame support(up to 9018 bytes) o Support for dual MAC configuration - Not tested. o Automatic crossover detection Not implemented hardware features. o Failover functionality - No plan to implement. o Rx TCP/UDP checksum offload - Don't know how to make it work. o TCP Segmentation offload(a.k.a TCP Large Send) - Needs datasheet. o 64bit DMA - No plan for a while as it needs complex list elements managements. The driver needs more tests and feedback from users but it seems to work well for normal usage patterns. However it seems that the driver has a Rx performance issue which I'd like to fix. I have an onboard Yukon EC NIC but Marvell produced so many revisions and each revision has bugs that needs special code to workaound it. > the driver back-ported to -stable? I'd be glad to give it a try. > First, I need more feedback before commiting to HEAD. > Thanks a lot, > --Artem > > > On 10/5/06, Andrey V. Elsukov wrote: > >Artem Belevich wrote: > > > >> OpenBSD apparently got a driver for Marvell Yukon2 Gigabit Ethernet > >> adapters that these days present on quite a few motherboards (or as a > >> relatively inexpensive PCI-Express card). NetBSD got it as well. > > > >See here: > >http://people.freebsd.org/~yongari/msk/ > > > >-- > >WBR, Andrey V. Elsukov > > > > > -- > --Artem -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 08:59:30 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 C0F9716A415 for ; Tue, 10 Oct 2006 08:59:30 +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 1FE2343D68 for ; Tue, 10 Oct 2006 08:59:29 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from [192.168.10.217] (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.13.7/8.13.3) with ESMTP id k9A8xQQ6053846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Oct 2006 09:59:30 +0100 (BST) (envelope-from jhary@unsane.co.uk) Message-ID: <452B60E3.1060206@unsane.co.uk> Date: Tue, 10 Oct 2006 09:59:15 +0100 From: Vince User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: Paul Schmehl References: <200610100433.53511.max@love2party.net> <9476505F959C119216F6FF6D@paul-schmehls-powerbook59.local> In-Reply-To: <9476505F959C119216F6FF6D@paul-schmehls-powerbook59.local> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 08:59:30 -0000 Paul Schmehl wrote: > --On October 10, 2006 4:33:35 AM +0200 Max Laier > wrote: > >> On Tuesday 10 October 2006 04:12, Paul Schmehl wrote: >>> I've been trying to get this to work on my laptop without success. >>> According to this page - >>> - the ipw driver >>> should work. I can load the driver, but it doesn't show up in dmesg. >> >> You are mistaken, I'm afraid. This has been discussed a couple of time >> already. The ipw(4) driver supports the now already quite dated 2100bg >> cards. Support for the new 3945abg is not available - other than >> ndis(4) and I don't know if that works or not. OpenBSD has a driver by >> the name of wpi(4). This is probably the point to start from if you >> were to write a FreeBSD one. >> > I guess I'm screwed them. I tried to create a module using ndisgen, but > when I try to load the module, it crashes the system and forces a > complete restart. > > I'm afraid I don't have the skills to write a device driver. > > Thanks for the info. > Just a a final note. The (discontinued) wpi driver that Damien started is still floating around and works for some people (although its a little flaky and only gives 6Mbps even for those where it does work.) I have a copy you can try if you like. Vince > Paul Schmehl (pauls@utdallas.edu) > Adjunct Information Security Officer > The University of Texas at Dallas > http://www.utdallas.edu/ir/security/ From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 12:05: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 BB27116A567 for ; Tue, 10 Oct 2006 12:05:52 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from intranet.ru (intranet.ru [212.164.71.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BC6443D58 for ; Tue, 10 Oct 2006 12:05:44 +0000 (GMT) (envelope-from ivsan@ngs.ru) Received: from [172.16.1.1] (HELO mx1.intranet.ru) by intranet.ru (CommuniGate Pro SMTP 4.3.2) with ESMTP id 308594488 for freebsd-net@freebsd.org; Tue, 10 Oct 2006 19:05:41 +0700 Received: from [80.242.64.3] (account ivsan@ngs.ru) by mx1.intranet.ru (CommuniGate Pro WebUser 4.3.2) with HTTP id 80244165 for freebsd-net@freebsd.org; Tue, 10 Oct 2006 19:05:41 +0700 From: "Ivan Alexandrovich" To: freebsd-net@freebsd.org X-Mailer: CommuniGate Pro WebUser Interface v.4.3.2 Date: Tue, 10 Oct 2006 19:05:41 +0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Subject: ng_netflow and router performance question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 12:05:52 -0000 Hi I'd like to ask a question about performance tuning for freebsd router running ng_netflow. There were a number of messages in mailing lists and forums where people inform that in their setups ng_netflow sustains high packet rates (>100K pkt/s) without any harm to accounting accuracy and lost packets. Nobody mentions any specific tuning so it can be assumed that in many cases it just runs 'out of the box' with default kernel parameters set (sysctls, boot-time and compile-time). So I tried ng_netflow and got very strange result: with 13K pkt/s and 25K different flows the router looses most of the packets. I know there's something wrong with my setup, and not with netgraph code itself but I just cant't figure out why it is so. When packet do not pass ng_netgraph router handles 60K pkt/s just fine. But with ng_netgraph performance degrades significantly - no matter what kernel and set of ip stack optimization options were used. During testing I used RELENG_6 (200610) and 6.1-RELEASE. Kernels: built for K8 architecture and GENERIC from the distribution. Custom kernel configurations were based on GENERIC for amd64 and i386. Just got rid of unused device drivers. Added DEVICE_POLLING, also tried with "maxusers 512". Linux box with pktgen was used to generate the packet flow: ip packet size: 250; protocol: udp, src/dst port=9; ip-addr varies from 10.60.0.0 to 10.60.100.255 Hardware configuration: Processor: Athlon 64 x2 3800+ Motherboard: Asus K8Ne Mem: 2x1Gb DDR-400 Hdd: Western Digital WD1600JS (SATA) Network inetface 1: integrated nforce4 Ethernet adapter Network interace 2: 3Com 905B pci33 1 as incoming, 2 as outgoing or vise versa tried to use xl0 in polling mode with "options HZ=1000" in kernel configuration. Linux router with fprobe-ulog (userespace accounting via ipt_ULOG) handled packet rate 43pkt/s with 256K unique flows on the same box and 20pkt/s with 2560K unique flows. ng_netflow running in kernel context surely can perform faster. #route for 10.60.0.0 for testing purposes ifconfig nve0 10.1.1.2 netmask 255.255.255.0 ifconfig xl0 10.50.1.1 netmask 255.255.255.0 arp -s 10.50.1.2 3:2:1:5:6:3 route add -net 10.60.0.0 -netmask 255.255.0.0 10.50.1.2 sysctl -w net.inet.ip.forwarding=1 route add default 10.1.1.1 #ng_netflow usage scenario 1 /sbin/kldload ng_ether /sbin/kldload ng_ipfw /usr/sbin/ngctl mkpeer ipfw: netflow 10 iface0 /usr/sbin/ngctl name ipfw:10 countall /usr/sbin/ngctl msg countall: setdlt { iface=0 dlt=12 } /sbin/ipfw add 64990 ngtee 10 ip from any to 10.60.0.0/16 in /sbin/ipfw add 64999 allow ip from any to 10.60.0.0/16 out /sbin/ipfw add 65000 allow ip from any to any /usr/sbin/ngctl msg countall: settimeouts { inactive=30 active=3 /usr/sbin/ngctl mkpeer countall: ksocket export inet/dgram/udp /usr/sbin/ngctl msg countall:export connect inet/127.0.0.1:4444 /usr/local/bin/flow-capture -z 0 \ -n 600 -w /var/log/flows 127.0.0.1/127.0.0.1/4444 #ng_netflow usage scenario 2 (old-style) /usr/sbin/ngctl mkpeer xl0: tee lower right /usr/sbin/ngctl connect xl0: xl0:lower upper left /usr/sbin/ngctl name xl0:lower xl0_tee /usr/sbin/ngctl mkpeer xl0:lower netflow right2left iface0 /usr/sbin/ngctl name xl0:lower.right2left netflow /usr/sbin/ngctl msg netflow: setifindex { iface=0 index=1 } /usr/sbin/ngctl connect xl0:lower netflow: left2right iface1 /usr/sbin/ngctl msg netflow: setifindex { iface=1 index=1 } /usr/sbin/ngctl mkpeer netflow: ksocket export inet/dgram/udp /usr/sbin/ngctl msg netflow:export connect inet/127.0.0.1:4444 /usr/local/bin/flow-capture -z 0 \ -n 600 -w /var/log/flows 127.0.0.1/127.0.0.1/4444 # kernel runtime parameters that I tried to change include: sysctl -w net.inet.ip.fastforwarding=1 kern.polling.enable=1 kern.ipc.nmbcluster=32768 kern.ipc.maxsockbufs=2097152 kern.ipc.somaxconn=8192 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.graph.maxalloc=2048 (via loader.conf) net.graph.maxdgram=45000 net.graph.recvspace=45000 sysctl kern.random.sys.harvest.ethernet=0 sysctl kern.random.sys.harvest.interrupt=0 According to counters of ipfw rules only small percent of packets get through < 100000 of 50000000. With small number of unique flows (~1000) acounting works almost without losses (99,6%). The whole situation is just ridiculous. Maybe someone can give a hint - what am I doing wrong? Thanks, Ivan From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 15:11: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 62C4316A40F for ; Tue, 10 Oct 2006 15:11:12 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp1.utdallas.edu (smtp1.utdallas.edu [129.110.10.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id C976F43D4C for ; Tue, 10 Oct 2006 15:11:11 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) by smtp1.utdallas.edu (Postfix) with ESMTP id 2AB9A388FA3; Tue, 10 Oct 2006 10:11:11 -0500 (CDT) Date: Tue, 10 Oct 2006 10:07:59 -0500 From: Paul Schmehl To: Vince Message-ID: <1D56A458AD95ABD932F2DF0D@utd59514.utdallas.edu> In-Reply-To: <452B60E3.1060206@unsane.co.uk> References: <200610100433.53511.max@love2party.net> <9476505F959C119216F6FF6D@paul-schmehls-powerbook59.local> <452B60E3.1060206@unsane.co.uk> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========E4203B3B531125ADA69A==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 15:11:12 -0000 --==========E4203B3B531125ADA69A========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Tuesday, October 10, 2006 09:59:15 +0100 Vince =20 wrote: > > Just a a final note. The (discontinued) wpi driver that Damien started > is still floating around and works for some people (although its a > little flaky and only gives 6Mbps even for those where it does work.) > I have a copy you can try if you like. > Can you post a url? Why isn't anyone working on updating it? Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========E4203B3B531125ADA69A==========-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 15:28: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 37B6416A4D0 for ; Tue, 10 Oct 2006 15:28:55 +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 1049D43DD1 for ; Tue, 10 Oct 2006 15:28:25 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from [192.168.10.217] (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.13.7/8.13.3) with ESMTP id k9AFSOFi058583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Oct 2006 16:28:25 +0100 (BST) (envelope-from jhary@unsane.co.uk) Message-ID: <452BBC0C.4090301@unsane.co.uk> Date: Tue, 10 Oct 2006 16:28:12 +0100 From: Vince User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: Paul Schmehl References: <200610100433.53511.max@love2party.net> <9476505F959C119216F6FF6D@paul-schmehls-powerbook59.local> <452B60E3.1060206@unsane.co.uk> <1D56A458AD95ABD932F2DF0D@utd59514.utdallas.edu> In-Reply-To: <1D56A458AD95ABD932F2DF0D@utd59514.utdallas.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 15:28:55 -0000 Paul Schmehl wrote: > --On Tuesday, October 10, 2006 09:59:15 +0100 Vince > wrote: >> >> Just a a final note. The (discontinued) wpi driver that Damien started >> is still floating around and works for some people (although its a >> little flaky and only gives 6Mbps even for those where it does work.) >> I have a copy you can try if you like. >> > Can you post a url? > http://unsane.co.uk/~jhary/freebsd/wpi-freebsd.tgz to compile I had to link the extracted wpi-freebsd/wpi directory to /usr/src/sys/dev/wpi then I have to load the modules in the following order kldload firmware.ko (well mines in kernel but if yours isnt) kldload wpi_ucode.ko kldload if_wpi.ko And occasionally I loose the interface and need to kldunload wpi_ucode kldunload if_wpi kldload wpi_ucode It works well enough for me but I know other people havent got it working. > Why isn't anyone working on updating it? I wish I knew, Damien stopped developing for FreeBSD cause of disagreements with other developers (he says something about it in a kerneltrap interview if i remember rightly. Luca Morettoni one of the Freesbie developers said he'd have a look at it last time i sent a link to it to one of the freebsd lists, but I havent heard more since then. Sadly I'm not a coder and wouldnt know where to start with it myself. Vince > > Paul Schmehl (pauls@utdallas.edu) > Adjunct Information Security Officer > The University of Texas at Dallas > http://www.utdallas.edu/ir/security/ From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 16:49: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 E030116A403 for ; Tue, 10 Oct 2006 16:49:36 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CC4C43D58 for ; Tue, 10 Oct 2006 16:49:34 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 61C6D33CAA; Tue, 10 Oct 2006 18:49:32 +0200 (SAST) Date: Tue, 10 Oct 2006 18:49:32 +0200 From: John Hay To: freebsd-net@freebsd.org Message-ID: <20061010164932.GB87412@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: ifconfig tunnel and /etc/network.subr mismatch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 16:49:37 -0000 Hi, While trying to configure a IPv4-over-IPv6 tunnel, I found that the old way of "ifconfig gif0 tunnel inet6 " does not work anymore. It gives an unhelpful error message: ###### ifconfig gif0 tunnel fd9c:6829:597c::1 fd9c:6829:597c:9:2c0:dfff:fef7:82eb ifconfig: SIOCSIFPHYADDR: Address family not supported by protocol family ###### You have to swap inet6 and tunnel, so it should look like this "ifconfig gif0 inet6 tunnel " The problem with that is that you cannot do that with the current /etc/network.subr and rc.conf scripts because /etc/network.subr do it this way: ###### ifconfig $i create >/dev/null 2>&1 ifconfig $i tunnel ${peers} ifconfig $i up ###### The printfs in ifconfig also still show that one can have the "tunnel inet6" syntax: ###### grep tunnel * | grep printf af_inet.c: printf("\ttunnel inet %s --> %s\n", src, dst); af_inet6.c: printf("\ttunnel inet6 %s --> %s\n", src, dst); ###### PR 97014 also mentioned the problem. So what should we do? Should ifconfig be fixed or should network.subr be fixed? John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 11:56: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 0768B16A412 for ; Tue, 10 Oct 2006 11:56:20 +0000 (UTC) (envelope-from scorp@scorp.sk) Received: from pavol.slovenska.sk (t0uch.slovenska.sk [212.5.219.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id D876E43D45 for ; Tue, 10 Oct 2006 11:56:17 +0000 (GMT) (envelope-from scorp@scorp.sk) Received: (qmail 30136 invoked by uid 98); 10 Oct 2006 11:56:14 -0000 Received: from 87.244.196.57 by pavol.slovenska.sk (envelope-from , uid 82) with qmail-scanner-1.25 (uvscan: v4.4.00/v4786. spamassassin: 3.0.2. Clear:RC:0(87.244.196.57):. Processed in 4.381092 secs); 10 Oct 2006 11:56:14 -0000 X-Qmail-Scanner-Mail-From: scorp@scorp.sk via pavol.slovenska.sk X-Qmail-Scanner: 1.25 (Clear:RC:0(87.244.196.57):. Processed in 4.381092 secs) Received: from unknown (HELO miriam-in.slovenska.sk) (scorp@87.244.196.57) by ns.slovenska.sk with SMTP; 10 Oct 2006 11:56:09 -0000 Date: Tue, 10 Oct 2006 13:56:06 +0200 From: =?Windows-1250?Q?Pavol_=C8ierny?= X-Mailer: The Bat! (v3.5.30) Professional Organization: WEBY.SLOVENSKA.SK X-Priority: 3 (Normal) Message-ID: <631998368.20061010135606@cierny.sk> To: FreeBSD-Net MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1250 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 10 Oct 2006 19:30:26 +0000 Subject: FreeBSD and Lights-Out Management X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 11:56:20 -0000 Hello, I'm solving issues with Lights-Out Management and FreeBSD. I've Fujitsu-Siemens Primergy RX220 and Sun Fire X2200 ... both dual opteron servers... They have integrated LOM on one network card. When this NIC is detected by FreeBSD, the LOM stops working... Also the console in the LOM via serial stops working after FreeBSD begins booting.... Did someone try to solve this issue? Thanks for any help... --- Best regards Pavol Èierny From owner-freebsd-net@FreeBSD.ORG Tue Oct 10 23: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 9090616A47C for ; Tue, 10 Oct 2006 23:03:00 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00E0D43D9E for ; Tue, 10 Oct 2006 23:02:45 +0000 (GMT) (envelope-from mav@mavhome.dp.ua) X-Spam-Level: 64 [XX] (100%) BAYESIAN TRAINING: 100 Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.5]) by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11) with ESMTPA id 17167624; Wed, 11 Oct 2006 02:02:44 +0300 Message-ID: <452C268E.4020700@mavhome.dp.ua> Date: Wed, 11 Oct 2006 02:02:38 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan Alexandrovich References: <1160493809.00616691.1160482801@10.7.7.3> In-Reply-To: <1160493809.00616691.1160482801@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ng_netflow and router performance question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Oct 2006 23:03:00 -0000 Hi. I think, that there is not very good hash function now used in ng_netflow in traffic aggregation. So if > ip-addr varies from 10.60.0.0 to 10.60.100.255 means than destination address will vary in this range and all other parameters is remain constant then it will be worst case possible. Try other traffic pattern (as example random ports or src addrs) or wait for some time. We have discussed it with author and hi will probably change this function. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 05:30:33 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 E580016A403 for ; Wed, 11 Oct 2006 05:30:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 583B243D53 for ; Wed, 11 Oct 2006 05:30:33 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 22188 invoked by uid 399); 11 Oct 2006 05:30:31 -0000 Received: from localhost (HELO dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 11 Oct 2006 05:30:31 -0000 Date: Tue, 10 Oct 2006 22:30:29 -0700 (PDT) From: Doug Barton To: Paul Schmehl In-Reply-To: <1D56A458AD95ABD932F2DF0D@utd59514.utdallas.edu> Message-ID: <20061010223001.F32706@qbhto.arg> References: <200610100433.53511.max@love2party.net> <9476505F959C119216F6FF6D@paul-schmehls-powerbook59.local> <452B60E3.1060206@unsane.co.uk> <1D56A458AD95ABD932F2DF0D@utd59514.utdallas.edu> Organization: http://www.FreeBSD.org/ X-OpenPGP-Key-ID: 0xD5B2F0FB X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Vince Subject: Re: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 05:30:34 -0000 On Tue, 10 Oct 2006, Paul Schmehl wrote: > Why isn't anyone working on updating it? This is a volunteer project. No one has volunteered. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 09:19: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 AD63116A415; Wed, 11 Oct 2006 09:19:26 +0000 (UTC) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 560DB43D5C; Wed, 11 Oct 2006 09:19:23 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from laptop.freebsd.czest.pl (v243.wat.edu.pl [148.81.117.243]) by freebsd.czest.pl (8.13.4/8.12.9) with ESMTP id k9B9f771014718; Wed, 11 Oct 2006 09:41:09 GMT (envelope-from dunstan@freebsd.czest.pl) Received: from laptop.freebsd.czest.pl (localhost [127.0.0.1]) by laptop.freebsd.czest.pl (8.13.7/8.13.7) with ESMTP id k9B92h4W002924; Wed, 11 Oct 2006 11:02:48 +0200 (CEST) (envelope-from dunstan@laptop.freebsd.czest.pl) Received: (from dunstan@localhost) by laptop.freebsd.czest.pl (8.13.7/8.13.4/Submit) id k9B92gDI002923; Wed, 11 Oct 2006 11:02:42 +0200 (CEST) (envelope-from dunstan) Date: Wed, 11 Oct 2006 11:02:41 +0200 From: "Wojciech A. Koszek" To: freebsd-net@freebsd.org Message-ID: <20061011090241.GA2831@FreeBSD.czest.pl> Mail-Followup-To: freebsd-net@freebsd.org, andre@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Greylist: Delayed for 00:16:24 by milter-greylist-2.0.2 (freebsd.czest.pl [80.48.250.4]); Wed, 11 Oct 2006 09:41:10 +0000 (UTC) Cc: andre@freebsd.org Subject: [PATCH] Make hash.h usable in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 09:19:26 -0000 Hello, I'm working on potential consumer of functions from sys/hash.h. Currently, I can't make them work without modyfication in my sample KLD. This is a patch which fixes the problem: http://people.freebsd.org/~wkoszek/patches/hash.h.0.patch It makes following program.. http://people.freebsd.org/~wkoszek/hash.c ..compile without warnings with WARNS=5. If noone objects, I'd like to commit it. Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.org http://FreeBSD.czest.pl/dunstan/ From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 09:41:04 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 0D5F616A538; Wed, 11 Oct 2006 09:41:04 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D12743D6A; Wed, 11 Oct 2006 09:40:54 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id AFA765EBA; Wed, 11 Oct 2006 13:40:46 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 744115FD4; Wed, 11 Oct 2006 13:40:46 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k9B9enJc025109; Wed, 11 Oct 2006 13:40:49 +0400 (MSD) (envelope-from ru) Date: Wed, 11 Oct 2006 13:40:49 +0400 From: Ruslan Ermilov To: freebsd-net@freebsd.org, andre@freebsd.org Message-ID: <20061011094049.GA24964@rambler-co.ru> References: <20061011090241.GA2831@FreeBSD.czest.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20061011090241.GA2831@FreeBSD.czest.pl> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Subject: Re: [PATCH] Make hash.h usable in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 09:41:04 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 11, 2006 at 11:02:41AM +0200, Wojciech A. Koszek wrote: > Hello, >=20 > I'm working on potential consumer of functions from sys/hash.h. Currently= , I > can't make them work without modyfication in my sample KLD. This is a pat= ch > which fixes the problem: >=20 > http://people.freebsd.org/~wkoszek/patches/hash.h.0.patch >=20 > It makes following program.. >=20 > http://people.freebsd.org/~wkoszek/hash.c >=20 > ..compile without warnings with WARNS=3D5. If noone objects, I'd like to > commit it. >=20 This is a wrong fix. A correct fix would be: %%% Index: sys/sys/hash.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/sys/hash.h,v retrieving revision 1.2 diff -u -p -r1.2 hash.h --- sys/sys/hash.h 12 Mar 2006 15:34:33 -0000 1.2 +++ sys/sys/hash.h 11 Oct 2006 09:38:50 -0000 @@ -86,7 +86,7 @@ hash32_strn(const void *buf, size_t len, * namei() hashing of path name parts. */ static __inline uint32_t -hash32_stre(const void *buf, int end, char **ep, uint32_t hash) +hash32_stre(const void *buf, int end, const char **ep, uint32_t hash) { const unsigned char *p =3D buf; =20 @@ -94,7 +94,7 @@ hash32_stre(const void *buf, int end, ch hash =3D HASHSTEP(hash, *p++); =20 if (ep) - *ep =3D (char *)p; + *ep =3D (const char *)p; =20 return hash; } @@ -105,7 +105,7 @@ hash32_stre(const void *buf, int end, ch * as a helper for the namei() hashing of path name parts. */ static __inline uint32_t -hash32_strne(const void *buf, size_t len, int end, char **ep, uint32_t has= h) +hash32_strne(const void *buf, size_t len, int end, const char **ep, uint32= _t hash) { const unsigned char *p =3D buf; =20 @@ -113,7 +113,7 @@ hash32_strne(const void *buf, size_t len hash =3D HASHSTEP(hash, *p++); =20 if (ep) - *ep =3D (char *)p; + *ep =3D (const char *)p; =20 return hash; } Index: share/man/man9/hash.9 =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/share/man/man9/hash.9,v retrieving revision 1.2 diff -u -p -r1.2 hash.9 --- share/man/man9/hash.9 30 Sep 2006 17:09:59 -0000 1.2 +++ share/man/man9/hash.9 11 Oct 2006 09:39:43 -0000 @@ -47,9 +47,11 @@ .Ft uint32_t .Fn hash32_strn "void *buf" "size_t len" "uint32_t hash" .Ft uint32_t -.Fn hash32_stre "void *buf" "int end" "char **ep" "uint32_t hash" +.Fn hash32_stre "void *buf" "int end" "const char **ep" "uint32_t hash" .Ft uint32_t -.Fn hash32_strne "void *buf" "size_t len" "int end" "char **ep" "uint32_t = hash" +.Fo hash32_strne +.Fa "void *buf" "size_t len" "int end" "const char **ep" "uint32_t hash" +.Fc .Sh DESCRIPTION The .Fn hash32 %%% Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFLLwhqRfpzJluFF4RArHFAKCavXGrFUiltnw+bTAEsuUsaMa12gCdHzSV t+PLVfQnzeZYweUvFAVi9jI= =mtKN -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 12:35: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 3F84516A4F1 for ; Wed, 11 Oct 2006 12:35:44 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96F2043D72 for ; Wed, 11 Oct 2006 12:34:31 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k9BCY4qV048384 for ; Wed, 11 Oct 2006 16:34:04 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k9BCY4L3048379 for freebsd-net@freebsd.org; Wed, 11 Oct 2006 16:34:04 +0400 (MSD) (envelope-from yar) Date: Wed, 11 Oct 2006 16:34:04 +0400 From: Yar Tikhiy To: freebsd-net@freebsd.org Message-ID: <20061011123403.GC47124@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: A way to disable reception of broadcast UDP? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 12:35:44 -0000 Hi all, Is there a well-known way for a UDP application to tell to the system that it doesn't want to receive broadcast datagrams? E.g., it would be very good for TFTP as required by RFC 1123. In general, accepting broadcast UDP is a security flaw unless the higher proto was specifically designed to work with broadcast. SO_BROADCAST affects sending only, and not reception. Dropping broadcast datagrams in the application is not an option because they can't be told without bogus system-dependent hacks. I found that our network stack would stop passing broadcast datagrams to the application as soon as it bound the socket to a particular address, but the status of this feature is unclear to me. By the way, it's the reason for a funny problem: Samba's nmbd won't work if started from inetd bound to a single IP. I can remember that, when T/TCP was there, the respective option must have been enabled on a socket for reception and transmission, for security reasons. (IIRC there was even a security incident related to that.) Perhaps SO_BROADCAST should be given similar semantics? It could improve security of many UDP applications. Any ideas? Thanks! -- Yar From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 13:08: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 3F7A916A4AB for ; Wed, 11 Oct 2006 13:08:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A68343D94 for ; Wed, 11 Oct 2006 13:08:11 +0000 (GMT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with SMTP id XAA11211; Wed, 11 Oct 2006 23:07:36 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 11 Oct 2006 23:07:36 +1000 (EST) From: Ian Smith To: Yar Tikhiy In-Reply-To: <20061011123403.GC47124@comp.chem.msu.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: A way to disable reception of broadcast UDP? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 13:08:27 -0000 On Wed, 11 Oct 2006, Yar Tikhiy wrote: > Is there a well-known way for a UDP application to tell to the > system that it doesn't want to receive broadcast datagrams? E.g., > it would be very good for TFTP as required by RFC 1123. In general, > accepting broadcast UDP is a security flaw unless the higher proto > was specifically designed to work with broadcast. I know this doesn't address your question regarding the stack, but you could immediately benefit by having a firewall rule dropping all IP traffic on the broadcast address (and the network address) via the outside interface. Working here since '98, counting plenty of them. If you also wanted to limit UDP on the inside, that's just as easy. Cheers, Ian > SO_BROADCAST affects sending only, and not reception. Dropping > broadcast datagrams in the application is not an option because > they can't be told without bogus system-dependent hacks. I found > that our network stack would stop passing broadcast datagrams to > the application as soon as it bound the socket to a particular > address, but the status of this feature is unclear to me. By the > way, it's the reason for a funny problem: Samba's nmbd won't work > if started from inetd bound to a single IP. > > I can remember that, when T/TCP was there, the respective option > must have been enabled on a socket for reception and transmission, > for security reasons. (IIRC there was even a security incident > related to that.) Perhaps SO_BROADCAST should be given similar > semantics? It could improve security of many UDP applications. > > Any ideas? Thanks! > > -- > Yar From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 13:39: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 D7FF516A4F4 for ; Wed, 11 Oct 2006 13:39:54 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BFDC43E10 for ; Wed, 11 Oct 2006 13:38:46 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k9BDcUpm049465; Wed, 11 Oct 2006 17:38:30 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k9BDcUVc049464; Wed, 11 Oct 2006 17:38:30 +0400 (MSD) (envelope-from yar) Date: Wed, 11 Oct 2006 17:38:29 +0400 From: Yar Tikhiy To: Ian Smith Message-ID: <20061011133829.GD47124@comp.chem.msu.su> References: <20061011123403.GC47124@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: A way to disable reception of broadcast UDP? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 13:39:55 -0000 On Wed, Oct 11, 2006 at 11:07:36PM +1000, Ian Smith wrote: > On Wed, 11 Oct 2006, Yar Tikhiy wrote: > > > Is there a well-known way for a UDP application to tell to the > > system that it doesn't want to receive broadcast datagrams? E.g., > > it would be very good for TFTP as required by RFC 1123. In general, > > accepting broadcast UDP is a security flaw unless the higher proto > > was specifically designed to work with broadcast. > > I know this doesn't address your question regarding the stack, but you > could immediately benefit by having a firewall rule dropping all IP > traffic on the broadcast address (and the network address) via the > outside interface. Working here since '98, counting plenty of them. > > If you also wanted to limit UDP on the inside, that's just as easy. Thanks for your comment! However, there are many kinds of broadcast or multicast traffic that can be coming to a UDP app from the outside or a connected network. Those include datagrams destined to broadcast address for any IP alias on this host, should the aliases belong to different IP networks, all multicast groups this host has joined, etc. All of them can be (and are!) distinguished internally by the local stack with M_MCAST and M_BCAST mbuf flags. This information can be hard to maintain on the border router for a large network, and it's lost when passing network data to the application. That was my point. In addition, I think that filtering broadcasts on the border router is a bit redundant today because modern network stacks just drop directed broadcasts. Local broadcast or multicast traffic is the main problem here. -- Yar From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 14:06: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 D757216A403; Wed, 11 Oct 2006 14:06:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 799B543D5F; Wed, 11 Oct 2006 14:06:18 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GXeiv-0007hw-4u; Wed, 11 Oct 2006 16:06:17 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Oct 2006 16:06:17 +0200 From: Danny Braniss Message-ID: Cc: freebsd-net@freebsd.org Subject: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 14:06:19 -0000 the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) dual cpu. running iperf -c (receiving): freebsd-4.10 0.0-10.0 sec 936 MBytes 785 Mbits/sec freebsd-5.4 0.0-10.0 sec 413 MBytes 346 Mbits/sec freebsd.6.1 0.0-10.0 sec 366 MBytes 307 Mbits/sec freebsd-6.2 0.0-10.0 sec 344 MBytes 289 Mbits/sec btw, iperf -s (xmitting) is slightly better freebsd-4.10 0.0-10.0 sec 664 MBytes 558 Mbits/sec freebsd-5.4 0.0-10.0 sec 390 MBytes 327 Mbits/sec freebsd-6.1 0.0-10.0 sec 495 MBytes 415 Mbits/sec freebsd-6.2 0.0-10.0 sec 487 MBytes 408 Mbits/sec so, it seems that as the release number increases, the em throughput gets worse - or iperf is. danny From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 14:30: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 58A1816A4C8; Wed, 11 Oct 2006 14:30:17 +0000 (UTC) (envelope-from lists@swaggi.com) Received: from swaggi.com (c-24-91-61-171.hsd1.ma.comcast.net [24.91.61.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 482E243D73; Wed, 11 Oct 2006 14:30:13 +0000 (GMT) (envelope-from lists@swaggi.com) Received: from localhost ([127.0.0.1] helo=swaggi.com) by swaggi.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GXg40-000Nj2-0H; Wed, 11 Oct 2006 10:32:08 -0500 Received: (from lists@localhost) by swaggi.com (8.13.6/8.13.6/Submit) id k9BFW7Bg091203; Wed, 11 Oct 2006 10:32:07 -0500 (EST) (envelope-from lists@swaggi.com) From: "Yuri Lukin" To: Doug Barton X-Originating-IP: 24.91.61.171 X-Mailer: swaggi.com Webmail Message-Id: <1160580727.91199@swaggi.com> Date: Wed, 11 Oct 2006 10:32:07 -0500 (EST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1160580727" Cc: Paul Schmehl , Vince , freebsd-net@FreeBSD.org Subject: Re: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 14:30:17 -0000 This is a multi-part message in MIME format. --bound1160580727 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Doug Barton wrote .. > On Tue, 10 Oct 2006, Paul Schmehl wrote: > > > Why isn't anyone working on updating it? > > This is a volunteer project. No one has volunteered. > > Doug > I think there are some that would like to contribute but don't know where to begin. I, for one, enjoy wireless networking and would like to contribute to the project but I dont know the OS internals and don't have any real programming experience. Perhaps some basic guidance could set people like myself on the right path? I'm not asking for hand-holding, just something to start with. -Yuri --bound1160580727-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 14:32:08 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 7D4BC16A40F for ; Wed, 11 Oct 2006 14:32:08 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4D7143D46 for ; Wed, 11 Oct 2006 14:32:06 +0000 (GMT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with SMTP id AAA13224; Thu, 12 Oct 2006 00:31:50 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 12 Oct 2006 00:31:49 +1000 (EST) From: Ian Smith To: Yar Tikhiy In-Reply-To: <20061011133829.GD47124@comp.chem.msu.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: A way to disable reception of broadcast UDP? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 14:32:08 -0000 On Wed, 11 Oct 2006, Yar Tikhiy wrote: > On Wed, Oct 11, 2006 at 11:07:36PM +1000, Ian Smith wrote: > > On Wed, 11 Oct 2006, Yar Tikhiy wrote: > > > > > Is there a well-known way for a UDP application to tell to the > > > system that it doesn't want to receive broadcast datagrams? E.g., > > > it would be very good for TFTP as required by RFC 1123. In general, > > > accepting broadcast UDP is a security flaw unless the higher proto > > > was specifically designed to work with broadcast. > > > > I know this doesn't address your question regarding the stack, but you > > could immediately benefit by having a firewall rule dropping all IP > > traffic on the broadcast address (and the network address) via the > > outside interface. Working here since '98, counting plenty of them. > > > > If you also wanted to limit UDP on the inside, that's just as easy. > > Thanks for your comment! However, there are many kinds of broadcast > or multicast traffic that can be coming to a UDP app from the outside > or a connected network. Those include datagrams destined to broadcast > address for any IP alias on this host, should the aliases belong > to different IP networks, all multicast groups this host has joined, > etc. All of them can be (and are!) distinguished internally by the > local stack with M_MCAST and M_BCAST mbuf flags. This information > can be hard to maintain on the border router for a large network, > and it's lost when passing network data to the application. That > was my point. And for once I'd thought I wasn't too far out of my depth :) > In addition, I think that filtering broadcasts on the border router > is a bit redundant today because modern network stacks just drop > directed broadcasts. Local broadcast or multicast traffic is the > main problem here. Thanks for the education. Back to lurking, awaiting a learned response. Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 14:56: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 9808116A4B3 for ; Wed, 11 Oct 2006 14:56:34 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp1.utdallas.edu (smtp1.utdallas.edu [129.110.10.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76DDC43DC3 for ; Wed, 11 Oct 2006 14:56:11 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) by smtp1.utdallas.edu (Postfix) with ESMTP id 210EF388DE4 for ; Wed, 11 Oct 2006 09:55:53 -0500 (CDT) Date: Wed, 11 Oct 2006 09:52:43 -0500 From: Paul Schmehl To: freebsd-net@freebsd.org Message-ID: In-Reply-To: <20061010223001.F32706@qbhto.arg> References: <200610100433.53511.max@love2party.net> <9476505F959C119216F6FF6D@paul-schmehls-powerbook59.local> <452B60E3.1060206@unsane.co.uk> <1D56A458AD95ABD932F2DF0D@utd59514.utdallas.edu> <20061010223001.F32706@qbhto.arg> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========24F4DB398238F037D4DB==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 14:56:34 -0000 --==========24F4DB398238F037D4DB========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On Tuesday, October 10, 2006 22:30:29 -0700 Doug Barton=20 wrote: > On Tue, 10 Oct 2006, Paul Schmehl wrote: > >> Why isn't anyone working on updating it? > > This is a volunteer project. No one has volunteered. > I'd volunteer if I had a clue. I'm not a programmer, and my only exposure=20 to C/C++ is two semesters a while ago. I doubt you want me writing device=20 drivers. :-) I understand that the guy who was writing the driver had some sort of=20 disagreement with someone and dropped the project. He's still maintaining=20 the driver for OpenBSD. I'm wondering how much work it would take to adapt = what's in OBSD CVS to FBSD and get the thing working? Is it a simple=20 matter of fixing paths so they point to the right source and header files?=20 Or is there more to it? Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ --==========24F4DB398238F037D4DB==========-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 16:39:01 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 0E08316A40F; Wed, 11 Oct 2006 16:39:01 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F2E543D7B; Wed, 11 Oct 2006 16:38:59 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.176.223] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GXh0q0pf0-0005cF; Wed, 11 Oct 2006 18:32:57 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Wed, 11 Oct 2006 18:32:40 +0200 User-Agent: KMail/1.9.4 References: <1160580727.91199@swaggi.com> In-Reply-To: <1160580727.91199@swaggi.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4012606.GqzedmBi8z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200610111832.54869.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Paul Schmehl , Doug Barton , Vince Subject: Re: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 16:39:01 -0000 --nextPart4012606.GqzedmBi8z Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 11 October 2006 17:32, Yuri Lukin wrote: > Doug Barton wrote .. > > > On Tue, 10 Oct 2006, Paul Schmehl wrote: > > > Why isn't anyone working on updating it? > > > > This is a volunteer project. No one has volunteered. > > > > Doug > > I think there are some that would like to contribute but don't > know where to begin. I, for one, enjoy wireless networking > and would like to contribute to the project but I dont > know the OS internals and don't have any real programming > experience. Perhaps some basic guidance could set people > like myself on the right path? I'm not asking for hand-holding, > just something to start with. There are three things that need to be done here: 1) Adapt the bus interface. This is not too much work and should boil=20 down to a couple of sed(1)s and a few manual edits. Check drivers that=20 are in OpenBSD and FreeBSD and compare, or just check existing drivers. =20 The DRIVER(9) manual page and jmg@'s paper[1,2] should provide additional=20 insight. 2) Use firmware(9) to load the ucode - as far as I understand the device=20 needs firmware as well. This shouldn't be much work and can be taken=20 verbatim from iwi(4). 3) Adapt the net80211 interface. This one's a bit tricky since OpenBSD=20 went a different way with their 80211 implementation. Again, looking at=20 existing drivers (esp. ath(4) as the reference implementation and iwi(4)=20 as a driver from OpenBSD that was also retrofitted into FreeBSD) should=20 give an idea what is done how. In the end, you won't know what problems you come across until you start=20 with it. I can help with questions regarding 2 & 3, but will be busy for=20 the next two months and don't have a 3945 to test with, either. [1] http://www.bsdcan.org/2006/papers/freebsd.driver.pdf [2] http://www.bsdcan.org/2006/papers/freebsd.device.driver.slides.pdf =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 --nextPart4012606.GqzedmBi8z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFLRy2XyyEoT62BG0RAlBdAJ9d+YGvbdPAqzntumLQg+0IDvCwVQCdFZhP 53yMvqMVCtOGbvZu4ayzaso= =UHwB -----END PGP SIGNATURE----- --nextPart4012606.GqzedmBi8z-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 17:35:33 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 8F3AF16A659 for ; Wed, 11 Oct 2006 17:35:33 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDBEC44157 for ; Wed, 11 Oct 2006 17:29:13 +0000 (GMT) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.13.8/8.13.8) with SMTP id k9BHStVG026951; Wed, 11 Oct 2006 13:28:55 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Danny Braniss Date: Wed, 11 Oct 2006 13:28:58 -0400 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 17:35:33 -0000 On Wed, 11 Oct 2006 16:06:17 +0200, in sentex.lists.freebsd.net you wrote: >the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) >dual cpu. > >running iperf -c (receiving): > >freebsd-4.10 0.0-10.0 sec 936 MBytes 785 Mbits/sec >freebsd-5.4 0.0-10.0 sec 413 MBytes 346 Mbits/sec >freebsd.6.1 0.0-10.0 sec 366 MBytes 307 Mbits/sec >freebsd-6.2 0.0-10.0 sec 344 MBytes 289 Mbits/sec > >btw, iperf -s (xmitting) is slightly better >freebsd-4.10 0.0-10.0 sec 664 MBytes 558 Mbits/sec >freebsd-5.4 0.0-10.0 sec 390 MBytes 327 Mbits/sec >freebsd-6.1 0.0-10.0 sec 495 MBytes 415 Mbits/sec >freebsd-6.2 0.0-10.0 sec 487 MBytes 408 Mbits/sec > >so, it seems that as the release number increases, the em >throughput gets worse - or iperf is. Hi, What is your setup for testing ? For me, with a couple of em NICs back to back I get iperf -c 1.1.1.2 ------------------------------------------------------------ Client connecting to 1.1.1.2, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 1.1.1.1 port 57584 connected with 1.1.1.2 port 5001 [ 3] 0.0-10.0 sec 1.06 GBytes 914 Mbits/sec 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Mon Oct 9 23:22:10 EDT 2006 One is a Pentium(R) 4 CPU 3.00GHz and the other an AMD 3800 X2 Going the other way is about the same (900Mb) ---Mike > >danny > > >_______________________________________________ >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" -------------------------------------------------------- Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 mike@sentex.net, (http://www.tancsa.com) From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 17:54: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 5D69E16A40F for ; Wed, 11 Oct 2006 17:54:38 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0186843D5D for ; Wed, 11 Oct 2006 17:52:29 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so278745pye for ; Wed, 11 Oct 2006 10:51:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r5xjSb0Dwls7lwlpJ5LjiXNaG/zMkyquutaSgIP5pzv6AUanz4pl8scymzj+l8BeBcrxxEMJUXgwaBLH1AsBbHJK4dXP1t7sjNGmZvTSjn+XQflzy0QOi35TyBHxqH1/lv9JYDJPkbTPXtZxKDcrA2OSTsloaTyhetKi91k6z30= Received: by 10.35.89.10 with SMTP id r10mr1254549pyl; Wed, 11 Oct 2006 10:51:34 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Wed, 11 Oct 2006 10:51:33 -0700 (PDT) Message-ID: <2a41acea0610111051r36ad7200gef868593e34c9331@mail.gmail.com> Date: Wed, 11 Oct 2006 10:51:33 -0700 From: "Jack Vogel" To: "Danny Braniss" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 17:54:38 -0000 On 10/11/06, Danny Braniss wrote: > the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) > dual cpu. > > running iperf -c (receiving): > > freebsd-4.10 0.0-10.0 sec 936 MBytes 785 Mbits/sec > freebsd-5.4 0.0-10.0 sec 413 MBytes 346 Mbits/sec > freebsd.6.1 0.0-10.0 sec 366 MBytes 307 Mbits/sec > freebsd-6.2 0.0-10.0 sec 344 MBytes 289 Mbits/sec > > btw, iperf -s (xmitting) is slightly better > freebsd-4.10 0.0-10.0 sec 664 MBytes 558 Mbits/sec > freebsd-5.4 0.0-10.0 sec 390 MBytes 327 Mbits/sec > freebsd-6.1 0.0-10.0 sec 495 MBytes 415 Mbits/sec > freebsd-6.2 0.0-10.0 sec 487 MBytes 408 Mbits/sec > > so, it seems that as the release number increases, the em > throughput gets worse - or iperf is. You arent measuring em, you're measuring RELEASES on your hardware, is this a surprise on a P3, no. I still do 930ish Mb/s on a P4 with a PCI-E or PCI-X adaptors running 6.1, in fact can do that with a 4 port adaptor I believe. Regards, Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 18:13: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 81C8B16A416 for ; Wed, 11 Oct 2006 18:13:57 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26F4A43D6B for ; Wed, 11 Oct 2006 18:13:55 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so285955pye for ; Wed, 11 Oct 2006 11:13:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r5xjSb0Dwls7lwlpJ5LjiXNaG/zMkyquutaSgIP5pzv6AUanz4pl8scymzj+l8BeBcrxxEMJUXgwaBLH1AsBbHJK4dXP1t7sjNGmZvTSjn+XQflzy0QOi35TyBHxqH1/lv9JYDJPkbTPXtZxKDcrA2OSTsloaTyhetKi91k6z30= Received: by 10.35.89.10 with SMTP id r10mr1254549pyl; Wed, 11 Oct 2006 10:51:34 -0700 (PDT) Received: by 10.35.119.1 with HTTP; Wed, 11 Oct 2006 10:51:33 -0700 (PDT) Message-ID: <2a41acea0610111051r36ad7200gef868593e34c9331@mail.gmail.com> Date: Wed, 11 Oct 2006 10:51:33 -0700 From: "Jack Vogel" To: "Danny Braniss" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 18:13:57 -0000 On 10/11/06, Danny Braniss wrote: > the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) > dual cpu. > > running iperf -c (receiving): > > freebsd-4.10 0.0-10.0 sec 936 MBytes 785 Mbits/sec > freebsd-5.4 0.0-10.0 sec 413 MBytes 346 Mbits/sec > freebsd.6.1 0.0-10.0 sec 366 MBytes 307 Mbits/sec > freebsd-6.2 0.0-10.0 sec 344 MBytes 289 Mbits/sec > > btw, iperf -s (xmitting) is slightly better > freebsd-4.10 0.0-10.0 sec 664 MBytes 558 Mbits/sec > freebsd-5.4 0.0-10.0 sec 390 MBytes 327 Mbits/sec > freebsd-6.1 0.0-10.0 sec 495 MBytes 415 Mbits/sec > freebsd-6.2 0.0-10.0 sec 487 MBytes 408 Mbits/sec > > so, it seems that as the release number increases, the em > throughput gets worse - or iperf is. You arent measuring em, you're measuring RELEASES on your hardware, is this a surprise on a P3, no. I still do 930ish Mb/s on a P4 with a PCI-E or PCI-X adaptors running 6.1, in fact can do that with a 4 port adaptor I believe. Regards, Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 11 19:21: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 98FA716A407; Wed, 11 Oct 2006 19:21:24 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id D425D43D5E; Wed, 11 Oct 2006 19:21:12 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id F3F775A0E70; Thu, 12 Oct 2006 05:21:10 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id D41F98C0C; Thu, 12 Oct 2006 05:21:09 +1000 (EST) Date: Thu, 12 Oct 2006 05:21:09 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Ruslan Ermilov In-Reply-To: <20061011094049.GA24964@rambler-co.ru> Message-ID: <20061012052101.A814@epsplex.bde.org> References: <20061011090241.GA2831@FreeBSD.czest.pl> <20061011094049.GA24964@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, andre@FreeBSD.org Subject: Re: [PATCH] Make hash.h usable in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Oct 2006 19:21:24 -0000 On Wed, 11 Oct 2006, Ruslan Ermilov wrote: > On Wed, Oct 11, 2006 at 11:02:41AM +0200, Wojciech A. Koszek wrote: >> I'm working on potential consumer of functions from sys/hash.h. Currently, I >> can't make them work without modyfication in my sample KLD. This is a patch >> which fixes the problem: >> ... > This is a wrong fix. A correct fix would be: > > %%% > Index: sys/sys/hash.h > =================================================================== > RCS file: /home/ncvs/src/sys/sys/hash.h,v > retrieving revision 1.2 > diff -u -p -r1.2 hash.h > --- sys/sys/hash.h 12 Mar 2006 15:34:33 -0000 1.2 > +++ sys/sys/hash.h 11 Oct 2006 09:38:50 -0000 > @@ -86,7 +86,7 @@ hash32_strn(const void *buf, size_t len, > * namei() hashing of path name parts. > */ > static __inline uint32_t > -hash32_stre(const void *buf, int end, char **ep, uint32_t hash) > +hash32_stre(const void *buf, int end, const char **ep, uint32_t hash) > { > const unsigned char *p = buf; > I think this would break passing ep in almost all callers, in the same way that "fixing" the corresponding arg in the strtol(3) family would break almost all callers. Callers want and need to pass char **, but char ** is not compatible with const char **. Callers want to do this because it's easier to write "char *end; ... &end", and they often need to do this so that they can modify the resulting *end. Changing the prototype forces all callers to use "const char **end; ... &end", and then if they want to modify *end, to convert `end' to plain char *. Modifying *end is only valid if the original string is modifyable, and this case ends up needing lots of ugly casting away of const, which leads to compiler warnings, which lead to even uglier things like the __DECONST() mistake to "fix" the warnings. Similarly for the strchr(3) family. > @@ -94,7 +94,7 @@ hash32_stre(const void *buf, int end, ch > hash = HASHSTEP(hash, *p++); > > if (ep) > - *ep = (char *)p; > + *ep = (const char *)p; > > return hash; > } Doesn't this cause a cast-qual warning in the kernel? > @@ -105,7 +105,7 @@ hash32_stre(const void *buf, int end, ch > * as a helper for the namei() hashing of path name parts. > */ > static __inline uint32_t > -hash32_strne(const void *buf, size_t len, int end, char **ep, uint32_t hash) > +hash32_strne(const void *buf, size_t len, int end, const char **ep, uint32_t hash) Line too long. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 03:05:33 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 E3AC416A417 for ; Thu, 12 Oct 2006 03:05:33 +0000 (UTC) (envelope-from mendonan@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 042D443D62 for ; Thu, 12 Oct 2006 03:05:28 +0000 (GMT) (envelope-from mendonan@gmail.com) Received: by nf-out-0910.google.com with SMTP id n15so960927nfc for ; Wed, 11 Oct 2006 20:05:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LgspwjeI9P97VkqAukbceYQTzNhW1PU0S3rDbR6Nige4/EK7KrdH03RDVD0oe/1CwbblFpLr5UlvANNEfrCR7y32v4n7ForsqUYcwjfg0UeWC3dLZPsH4d2lWXkaaDlyEzlWsL53E2S30wb08DMElayNyBcgb9yBwnec2To5gLs= Received: by 10.78.128.11 with SMTP id a11mr1645659hud; Wed, 11 Oct 2006 20:05:26 -0700 (PDT) Received: by 10.78.200.16 with HTTP; Wed, 11 Oct 2006 20:05:26 -0700 (PDT) Message-ID: <94c7120b0610112005g62c0a137j97a3adf0d97c2ba5@mail.gmail.com> Date: Thu, 12 Oct 2006 11:05:26 +0800 From: "Senandung Mendonan" To: freebsd-net@freebsd.org In-Reply-To: <94c7120b0608210209o482fef7ev1b4922d0597af666@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <94c7120b0608181236j2475301ds1379510f94b12d34@mail.gmail.com> <09BFF2FA5EAB4A45B6655E151BBDD90301D42713@NT-IRVA-0750.brcm.ad.broadcom.com> <94c7120b0608210209o482fef7ev1b4922d0597af666@mail.gmail.com> Subject: Re: Problem with IBM NetXtreme 1000-T GigaEthernet Adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 03:05:34 -0000 David / list, Some new developments/leads on this issue:- On 8/21/06, Senandung Mendonan wrote: > > > If you could attach a dump of dmesg that shows the messages from the > > driver that might help too. > > Here's the dmesg for the dual-port version:- > > pci5: on pcib4 > bge0: mem > 0xdcff0000-0xdcffffff irq 48 at device 1.0 on pci5 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:10:18:11:2a:0d > bge1: mem > 0xdcfe0000-0xdcfeffff irq 49 at device 1.1 on pci5 > miibus1: on bge1 > brgphy1: on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge1: Ethernet address: 00:10:18:11:2a:0a > > After deploying on a few servers, we realized some of the servers work OK, and some not, although the cards are apparently same model, with same dmesg shown above. Upon closer inspection, we found out that the two NICs' chipsets differ in minor revision:- 1. The working NIC:- Broadcom BCM5704CKRB TS0341 P13 706741 B (manufactured 23/12/2004, older revision of the same BCM5704C chipset supported by the FreeBSD bge driver. ( Picture: http://absolute-p.ath.cx/wp-content/uploads/2006/10/old-23-12-2004.jpg ) 2. The intermittent NIC:- Broadcom BCM5704CKRB CS0424 P20 723153B B (unknown manufacture date, but probably newer than the working NIC). ( Picture: http://absolute-p.ath.cx/wp-content/uploads/2006/10/new.jpg ) I have yet to try a 6.2 kernel, the site has no internet connections and a bit far, so takes a while for me to try that. In the meantime, perhaps with the chipset details you have some ideas? Thanks. --mendonan "Yang mimpikan secangkir kopi panas dengan selimut.." (Dreaming of a cup of hot coffee, and a blanket..") From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 04:16:15 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 2C34716A403; Thu, 12 Oct 2006 04:16:15 +0000 (UTC) (envelope-from beastie@mra.co.id) Received: from mx3.mra.co.id (fw.mra.co.id [202.57.14.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F28743D58; Thu, 12 Oct 2006 04:16:13 +0000 (GMT) (envelope-from beastie@mra.co.id) Received: from localhost (localhost.mra.co.id [127.0.0.1]) by mx3.mra.co.id (Postfix) with ESMTP id 5F23730F7E; Thu, 12 Oct 2006 11:07:57 +0700 (WIT) Received: from mx3.mra.co.id ([127.0.0.1]) by localhost (mx3.mra.co.id [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86723-24; Thu, 12 Oct 2006 11:07:57 +0700 (WIT) Received: from mailbox.mra.co.id (unknown [172.16.0.225]) by mx3.mra.co.id (Postfix) with ESMTP id 2D25C30F7B; Thu, 12 Oct 2006 11:07:57 +0700 (WIT) Received: from beastie.mra.co.id (unknown [172.16.0.228]) by mailbox.mra.co.id (Postfix) with ESMTP id 7CE18FDC5; Thu, 12 Oct 2006 10:37:39 +0700 (WIT) From: Muhammad Reza To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain Message-Id: <1009992059.6727.20.camel@beastie.mra.co.id> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-8) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mra.co.id Cc: Subject: pf.conf + altq problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 12 Oct 2006 04:16:15 -0000 X-Original-Date: Thu, 03 Jan 2002 00:20:59 +0700 X-List-Received-Date: Thu, 12 Oct 2006 04:16:15 -0000 Dear list. My pf.conf not working. I have pf in bridge machine with xl2 to internet firewall and xl1 to internal switch. Bridging is ok. This my simple pf.conf me="172.16.0.228" altq on xl1 bandwidth 100% cbq queue {me,dflt} queue me bandwidth 8Kb queue dflt bandwidth 16Kb cbq (default) block log on {xl1,xl2} all pass out log on xl1 from $me to any keep state pass log on xl2 from $me to any keep state queue (me) This rule is match when i try to connect to iperf server # tcpdump -nett -i pflog0 | grep 172.16.0.228 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG 1160655756.150048 rule 3/(match) pass in on xl2: 172.16.0.228.44405 > 128.6.231.102.5001: [|tcp] (DF) 1160655756.150059 rule 2/(match) pass out on xl1: 172.16.0.228.44405 > 128.6.231.102.5001: [|tcp] (DF) But iperf tell me that this connection is 24.4 Kbits/Sec. (more than 8Kbps) [root@beastie beastie]# iperf -c lss.rutgers.edu ------------------------------------------------------------ Client connecting to lss.rutgers.edu, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 172.16.0.228 port 44408 connected with 128.6.231.102 port 5001 [ 3] 0.0-16.1 sec 48.0 KBytes 24.4 Kbits/sec I'm expecting that iperf report it equal with the bandwidth that i assign to (me) queue pipe. Is there any thing wrong or i missed something here ??? Please help me regards Reza From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 07:20:35 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 9CCC316A416; Thu, 12 Oct 2006 07:20:35 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 256B943D60; Thu, 12 Oct 2006 07:20:34 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id B054B5FBB; Thu, 12 Oct 2006 11:20:32 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id A8DE35F50; Thu, 12 Oct 2006 11:20:32 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k9C7KaJj061341; Thu, 12 Oct 2006 11:20:36 +0400 (MSD) (envelope-from ru) Date: Thu, 12 Oct 2006 11:20:36 +0400 From: Ruslan Ermilov To: Bruce Evans Message-ID: <20061012072036.GA60767@rambler-co.ru> References: <20061011090241.GA2831@FreeBSD.czest.pl> <20061011094049.GA24964@rambler-co.ru> <20061012052101.A814@epsplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <20061012052101.A814@epsplex.bde.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-net@FreeBSD.org, andre@FreeBSD.org Subject: Re: [PATCH] Make hash.h usable in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 07:20:35 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 12, 2006 at 05:21:09AM +1000, Bruce Evans wrote: > On Wed, 11 Oct 2006, Ruslan Ermilov wrote: > >%%% > >Index: sys/sys/hash.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/sys/hash.h,v > >retrieving revision 1.2 > >diff -u -p -r1.2 hash.h > >--- sys/sys/hash.h 12 Mar 2006 15:34:33 -0000 1.2 > >+++ sys/sys/hash.h 11 Oct 2006 09:38:50 -0000 > >@@ -86,7 +86,7 @@ hash32_strn(const void *buf, size_t len, > > * namei() hashing of path name parts. > > */ > >static __inline uint32_t > >-hash32_stre(const void *buf, int end, char **ep, uint32_t hash) > >+hash32_stre(const void *buf, int end, const char **ep, uint32_t hash) > >{ > > const unsigned char *p =3D buf; > > >=20 > I think this would break passing ep in almost all callers, >=20 There are no callers of these functions yet, at least not in the current FreeBSD kernel. There are only 2 callers in OpenBSD, both in sys/kern/vfs_lookup.c > in the same > way that "fixing" the corresponding arg in the strtol(3) family would > break almost all callers. >=20 Yes, but strtol(3) has seen more life in sin. ;) > Callers want and need to pass char **, but > char ** is not compatible with const char **. >=20 Not compatible, but "char **" can safely be casted to "const char **". > Callers want to do this > because it's easier to write "char *end; ... &end", and they often > need to do this so that they can modify the resulting *end. >=20 But this is bad practice; if string is really const, writing to *end will SIGBUS, and the fact that interface has it spelled as "char **" doesn't mitigate it: : #include :=20 : static const char *s =3D "123a"; :=20 : int : main(void) : { : long v; : char *endptr; :=20 : endptr =3D NULL; : v =3D strtol(s, &endptr, 0); : if (endptr !=3D NULL) : *endptr =3D '\0'; : return (0); : } OTOH, if string is really modifiable, then simple casting when calling a function works: : #include :=20 : void foo(const char *, char *); : void bar(const char *, const char **); :=20 : void : foo(const char *s1, char *s2) : { : const char *end1 =3D NULL; : char *end2 =3D NULL; :=20 : bar(s1, &end1); : bar(s2, (const char **)&end2); : } Or differently: it's safe (and possible) to do "end1 =3D end2", but not the opposite. > Changing > the prototype forces all callers to use "const char **end; ... &end", ^ extra `*' > and then if they want to modify *end, to convert `end' to plain char *. >=20 Not necessarily, see above. And from the function's POV (whose prototype we're considering), "end" will be made to point to a substring of a const string, so obviously it will also point to a const string. > Modifying *end is only valid if the original string is modifyable, and > this case ends up needing lots of ugly casting away of const, which > leads to compiler warnings, which lead to even uglier things like the > __DECONST() mistake to "fix" the warnings. >=20 Not *lots* actually. Passing "char *" where "const char *" is required is safe and allowed, passing "char **" as "const char **" is allowed but requires a (safe) cast. > >@@ -94,7 +94,7 @@ hash32_stre(const void *buf, int end, ch > > hash =3D HASHSTEP(hash, *p++); > > > > if (ep) > >- *ep =3D (char *)p; > >+ *ep =3D (const char *)p; > > > > return hash; > >} >=20 > Doesn't this cause a cast-qual warning in the kernel? >=20 Why? None of qualifiers are lost as a result of cast; both "p" and "ep" are pointers to const-qualified base types. (No, it doesn't cause a warning.) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFLezEqRfpzJluFF4RArz+AJwPTP7EDDuEcZDi4aF49yIw8CBoLgCdEFLI +uGMOqytUx8bpaxFFqX/3xw= =r2jR -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 07:30:04 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 CA35316A4A7 for ; Thu, 12 Oct 2006 07:30:04 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from intranet.ru (intranet.ru [212.164.71.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id B660B43D72 for ; Thu, 12 Oct 2006 07:29:52 +0000 (GMT) (envelope-from ivsan@ngs.ru) Received: from [172.16.1.1] (HELO mx1.intranet.ru) by intranet.ru (CommuniGate Pro SMTP 4.3.2) with ESMTP id 308739804 for freebsd-net@freebsd.org; Thu, 12 Oct 2006 14:29:49 +0700 Received: from [80.242.64.3] (account ivsan@ngs.ru) by mx1.intranet.ru (CommuniGate Pro WebUser 4.3.2) with HTTP id 80365442 for freebsd-net@freebsd.org; Thu, 12 Oct 2006 14:29:49 +0700 From: "Ivan Alexandrovich" To: freebsd-net@freebsd.org X-Mailer: CommuniGate Pro WebUser Interface v.4.3.2 Date: Thu, 12 Oct 2006 14:29:49 +0700 Message-ID: In-Reply-To: <452C268E.4020700@mavhome.dp.ua> References: <1160493809.00616691.1160482801@10.7.7.3> <452C268E.4020700@mavhome.dp.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Subject: Re: ng_netflow and router performance question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 07:30:04 -0000 On Wed, 11 Oct 2006 02:02:38 +0300 Alexander Motin wrote: > I think, that there is not very good hash function now used in ng_netflow >in traffic aggregation. So if > > ip-addr varies from 10.60.0.0 to 10.60.100.255 > means than destination address will vary in this range and all other >parameters is remain constant then it will be worst case possible. Thanks for your help. With pretty random src ip (10.0.*.* - 100.*.*.*) it was able to handle 23K pkt/s of unique flows without packet losses and with 99,96 accuracy (both active and inactive timeouts were set to 3 seconds for testing purposes). I'd like to ask about the reasonable values of timeout parameters for a highly loaded router to avoid records cache overruns? There is a compile-time option CACHESIZE defined in ng_netflow.h. Is it ok to increase it or should I manipulate with timeout values alone? Thanks, Ivan From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 08:38: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 E4EF716A403 for ; Thu, 12 Oct 2006 08:38:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E3FA43D45 for ; Thu, 12 Oct 2006 08:38:55 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GXw5e-000O7H-ID; Thu, 12 Oct 2006 10:38:54 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Mike Tancsa In-reply-to: References: Comments: In-reply-to Mike Tancsa message dated "Wed, 11 Oct 2006 13:28:58 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Oct 2006 10:38:54 +0200 From: Danny Braniss Message-ID: Cc: freebsd-net@freebsd.org Subject: Re: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 08:38:56 -0000 > On Wed, 11 Oct 2006 16:06:17 +0200, in sentex.lists.freebsd.net you > wrote: >=20 >=20 >the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) >=20 >dual cpu. >=20 > > >running iperf -c (receiving): >freebsd-4.10 0.0-10.0 sec 936 MBytes 785 Mbits/sec >freebsd-5.4 0.0-10.0 sec 413 MBytes 346 Mbits/sec >freebsd.6.1 0.0-10.0 sec 366 MBytes 307 Mbits/sec >freebsd-6.2 0.0-10.0 sec 344 MBytes 289 Mbits/sec > >btw, iperf -s (xmitting) is slightly better >freebsd-4.10 0.0-10.0 sec 664 MBytes 558 Mbits/sec >freebsd-5.4 0.0-10.0 sec 390 MBytes 327 Mbits/sec >freebsd-6.1 0.0-10.0 sec 495 MBytes 415 Mbits/sec >freebsd-6.2 0.0-10.0 sec 487 MBytes 408 Mbits/sec >so, it seems that as the release number increases, the em >throughput gets worse - or iperf is. > > Hi, > What is your setup for testing ? For me, with a couple of em > NICs back to back I get > iperf -c 1.1.1.2 > ------------------------------------------------------------ > Client connecting to 1.1.1.2, TCP port 5001 > TCP window size: 32.5 KByte (default) > ------------------------------------------------------------ > =5B 3=5D local 1.1.1.1 port 57584 connected with 1.1.1.2 port 5001 > =5B 3=5D 0.0-10.0 sec 1.06 GBytes 914 Mbits/sec >=20 > 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE =230: Mon Oct 9 23:22:10 EDT 200= 6 >=20 > One is a Pentium(R) 4 CPU 3.00GHz and the other an AMD 3800 X2 >=20 > Going the other way is about the same (900Mb) >=20 > ---Mike no back to back, regular production infrastructure, Nortel Passport 8010 router as a backbone. one host, as mentioned, is a PIII, the other is an Intel(R) Xeon(TM) CPU 3.06GHz (3056.82-MHz 686-class CPU) running FreeBSD 6.2-PRERELEASE =239: Wed Oct 11 09:05:49 IST 2006 which gives nicer numbers, if for example the client is of the same hardw= are, and at the moment running 6.1-STABLE: 0.0-10.0 sec 1.08 GBytes 928 Mbits/sec short version: the point im trying to make, is that the same setup, where I only change the release, is going downhill - with this particular MB. the long version: Before I send this box to pasture, i decided to use it as a dns/dhcp/tfpt= server, and i also upgraded it to the latest/greatest version of freebsd,= before it becomes eol. as soon as it became production, i noticed that booting a class of some 60 ws was somewhat slower.=20 danny danny From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 08:59: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 B472E16A403; Thu, 12 Oct 2006 08:59:12 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41CCD43D62; Thu, 12 Oct 2006 08:59:12 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GXwPG-000Op9-VV; Thu, 12 Oct 2006 10:59:10 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Jack Vogel" In-reply-to: <2a41acea0610111051r36ad7200gef868593e34c9331@mail.gmail.com> References: <2a41acea0610111051r36ad7200gef868593e34c9331@mail.gmail.com> Comments: In-reply-to "Jack Vogel" message dated "Wed, 11 Oct 2006 10:51:33 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Oct 2006 10:59:10 +0200 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 08:59:12 -0000 > On 10/11/06, Danny Braniss wrote: > > the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) > > dual cpu. > > > > running iperf -c (receiving): > > > > freebsd-4.10 0.0-10.0 sec 936 MBytes 785 Mbits/sec > > freebsd-5.4 0.0-10.0 sec 413 MBytes 346 Mbits/sec > > freebsd.6.1 0.0-10.0 sec 366 MBytes 307 Mbits/sec > > freebsd-6.2 0.0-10.0 sec 344 MBytes 289 Mbits/sec > > > > btw, iperf -s (xmitting) is slightly better > > freebsd-4.10 0.0-10.0 sec 664 MBytes 558 Mbits/sec > > freebsd-5.4 0.0-10.0 sec 390 MBytes 327 Mbits/sec > > freebsd-6.1 0.0-10.0 sec 495 MBytes 415 Mbits/sec > > freebsd-6.2 0.0-10.0 sec 487 MBytes 408 Mbits/sec > > > > so, it seems that as the release number increases, the em > > throughput gets worse - or iperf is. > > You arent measuring em, you're measuring RELEASES on > your hardware, is this a surprise on a P3, no. > I agree 100% with your first statement, but, if_em is useless without the rest, and if it's not delivering, then something is wrong somewhere, no necesarely with the em driver, but in how the system interacts. > I still do 930ish Mb/s on a P4 with a PCI-E or PCI-X adaptors > running 6.1, in fact can do that with a 4 port adaptor I believe. i do get on certain combinations nice numbers: Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 4] 0.0-10.0 sec 1.08 GBytes 928 Mbits/sec (the mb is Intel SWV). which seems almost optimal, but on other platforms i get [ 3] 0.0-10.0 sec 654 MBytes 548 Mbits/sec (the mb is Intel SE7501) cheers, danny From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 10:30: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 8DDE816A40F; Thu, 12 Oct 2006 10:30:24 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3BC143D60; Thu, 12 Oct 2006 10:30:23 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50003082934.msg; Thu, 12 Oct 2006 11:30:03 +0100 Message-ID: <01ad01c6ede9$5e4ee730$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Jack Vogel" , "Danny Braniss" References: <2a41acea0610111051r36ad7200gef868593e34c9331@mail.gmail.com> Date: Thu, 12 Oct 2006 11:29:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Processed: multiplay.co.uk, Thu, 12 Oct 2006 11:30:03 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDAV-Processed: multiplay.co.uk, Thu, 12 Oct 2006 11:30:04 +0100 Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 10:30:24 -0000 Jack Vogel wrote: > On 10/11/06, Danny Braniss wrote: >> the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) >> dual cpu. >> running iperf -c (receiving): >> >> freebsd-4.10 0.0-10.0 sec 936 MBytes 785 Mbits/sec >> freebsd-5.4 0.0-10.0 sec 413 MBytes 346 Mbits/sec >> freebsd.6.1 0.0-10.0 sec 366 MBytes 307 Mbits/sec >> freebsd-6.2 0.0-10.0 sec 344 MBytes 289 Mbits/sec > You arent measuring em, you're measuring RELEASES on > your hardware, is this a surprise on a P3, no. > > I still do 930ish Mb/s on a P4 with a PCI-E or PCI-X adaptors > running 6.1, in fact can do that with a 4 port adaptor I believe. Old hardware or not I'd say they are interesting results as there should be no real reason why we need the most up to date hardware not to loose out on performance. Out of interest Danny how do the various OS compare when using a single CPU kernel? Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 10:49:04 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 2A7DE16A407; Thu, 12 Oct 2006 10:49:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 958DB43D4C; Thu, 12 Oct 2006 10:48:53 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GXy7Q-00021o-Gn; Thu, 12 Oct 2006 12:48:52 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Steven Hartland" In-reply-to: <01ad01c6ede9$5e4ee730$b3db87d4@multiplay.co.uk> References: <2a41acea0610111051r36ad7200gef868593e34c9331@mail.gmail.com> <01ad01c6ede9$5e4ee730$b3db87d4@multiplay.co.uk> Comments: In-reply-to "Steven Hartland" message dated "Thu, 12 Oct 2006 11:29:52 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Oct 2006 12:48:52 +0200 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Jack Vogel , freebsd-net@freebsd.org Subject: Re: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 10:49:04 -0000 > Jack Vogel wrote: > > On 10/11/06, Danny Braniss wrote: > >> the box is a bit old (Intel Pentium III (933.07-MHz 686-class CPU) > >> dual cpu. > >> running iperf -c (receiving): > >> > >> freebsd-4.10 0.0-10.0 sec 936 MBytes 785 Mbits/sec > >> freebsd-5.4 0.0-10.0 sec 413 MBytes 346 Mbits/sec > >> freebsd.6.1 0.0-10.0 sec 366 MBytes 307 Mbits/sec > >> freebsd-6.2 0.0-10.0 sec 344 MBytes 289 Mbits/sec > > You arent measuring em, you're measuring RELEASES on > > your hardware, is this a surprise on a P3, no. > > > > I still do 930ish Mb/s on a P4 with a PCI-E or PCI-X adaptors > > running 6.1, in fact can do that with a 4 port adaptor I believe. > > Old hardware or not I'd say they are interesting results as > there should be no real reason why we need the most up to > date hardware not to loose out on performance. > and eol threats :-) > Out of interest Danny how do the various OS compare when > using a single CPU kernel? i don't have any UP kernels, but i'll make one for 6.2 an let you know. danny From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 11:11: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 7400C16A407 for ; Thu, 12 Oct 2006 11:11:38 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from grunt15.ihug.co.nz (grunt15.ihug.co.nz [203.109.254.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D8EE43D76 for ; Thu, 12 Oct 2006 11:11:25 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from 203-109-251-39.static.bliink.ihug.co.nz (heff.fud.org.nz) [203.109.251.39] by grunt15.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1GXySw-0002eK-00; Fri, 13 Oct 2006 00:11:06 +1300 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 1F8CA1CC1F; Fri, 13 Oct 2006 00:11:06 +1300 (NZDT) Date: Fri, 13 Oct 2006 00:11:06 +1300 From: Andrew Thompson To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Message-ID: <20061012111106.GH2566@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , freebsd-current@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: Subject: RSTP code for test/review X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 11:11:38 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Attached is a patch that brings in rapid spanning tree (802.1w) support. I would appreciate any testing or code review. The states will be printed out at the moment as packets are transfered and the topo is calculated, these should stop when it becomes stable. The requirements are: (a) it reaches a stable topology, no constant flipflops (b) it calculates the correct topology (c) no loops are created It defaults to RSTP mode but will downgrade any port connected to a legacy STP network so can be tested even if you dont use RSTP in your network. The patch only applies to HEAD, no RELENG_6 patch available sorry. The code implements chapter 17 of 802.1D-2004 if you really want to get your hands dirty. Comments welcome. cheers, Andrew --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bridge_rstp.20061012.diff" Index: sbin/ifconfig/ifbridge.c =================================================================== RCS file: /home/ncvs/src/sbin/ifconfig/ifbridge.c,v retrieving revision 1.3 diff -u -p -r1.3 ifbridge.c --- sbin/ifconfig/ifbridge.c 14 Dec 2005 02:52:12 -0000 1.3 +++ sbin/ifconfig/ifbridge.c 12 Oct 2006 10:46:13 -0000 @@ -61,6 +61,27 @@ static const char rcsid[] = #include "ifconfig.h" +static const char *stpstates[] = { + "disabled", + "listening", + "learning", + "forwarding", + "blocking", + "discarding" +}; +static const char *stpproto[] = { + "stp", + "-", + "rstp" +}; +static const char *stproles[] = { + "disabled", + "root", + "designated", + "alternate", + "backup" +}; + static int get_val(const char *cp, u_long *valp) { @@ -113,13 +134,6 @@ do_bridgeflag(int sock, const char *ifs, static void bridge_interfaces(int s, const char *prefix) { - static const char *stpstates[] = { - "disabled", - "listening", - "learning", - "forwarding", - "blocking", - }; struct ifbifconf bifc; struct ifbreq *req; char *inbuf = NULL, *ninbuf; @@ -159,9 +173,23 @@ bridge_interfaces(int s, const char *pre printf("port %u priority %u", req->ifbr_portno, req->ifbr_priority); printf(" path cost %u", req->ifbr_path_cost); + if (req->ifbr_proto < + sizeof(stpproto) / sizeof(stpproto[0])) + printf(" proto %s", stpproto[req->ifbr_proto]); + else + printf(" ", + req->ifbr_proto); + + printf("\n%s", pad); + if (req->ifbr_role < + sizeof(stproles) / sizeof(stproles[0])) + printf("role %s", stproles[req->ifbr_role]); + else + printf("", + req->ifbr_role); if (req->ifbr_state < sizeof(stpstates) / sizeof(stpstates[0])) - printf(" %s", stpstates[req->ifbr_state]); + printf(" state %s", stpstates[req->ifbr_state]); else printf(" ", req->ifbr_state); @@ -210,28 +238,22 @@ bridge_addresses(int s, const char *pref static void bridge_status(int s) { - struct ifbrparam param; + struct ifbropreq param; u_int16_t pri; - u_int8_t ht, fd, ma; + u_int8_t ht, fd, ma, hc, pro; - if (do_cmd(s, BRDGGPRI, ¶m, sizeof(param), 0) < 0) + if (do_cmd(s, BRDGPARAM, ¶m, sizeof(param), 0) < 0) return; - pri = param.ifbrp_prio; - - if (do_cmd(s, BRDGGHT, ¶m, sizeof(param), 0) < 0) - return; - ht = param.ifbrp_hellotime; - - if (do_cmd(s, BRDGGFD, ¶m, sizeof(param), 0) < 0) - return; - fd = param.ifbrp_fwddelay; - - if (do_cmd(s, BRDGGMA, ¶m, sizeof(param), 0) < 0) - return; - ma = param.ifbrp_maxage; - - printf("\tpriority %u hellotime %u fwddelay %u maxage %u\n", - pri, ht, fd, ma); + pri = param.ifbop_priority; + pro = param.ifbop_protocol; + ht = param.ifbop_hellotime; + fd = param.ifbop_fwddelay; + hc = param.ifbop_holdcount; + ma = param.ifbop_maxage; + + printf("\tpriority %u hellotime %u fwddelay %u" + " maxage %u hc %u proto %s\n", + pri, ht, fd, ma, hc, stpproto[pro]); bridge_interfaces(s, "\tmember: "); @@ -469,6 +491,38 @@ setbridge_priority(const char *arg, int } static void +setbridge_protocol(const char *arg, int d, int s, const struct afswtch *afp) +{ + struct ifbrparam param; + + if (strcasecmp(arg, "stp") == 0) { + param.ifbrp_proto = 0; + } else if (strcasecmp(arg, "rstp") == 0) { + param.ifbrp_proto = 2; + } else { + errx(1, "unknown stp protocol"); + } + + if (do_cmd(s, BRDGSPROTO, ¶m, sizeof(param), 1) < 0) + err(1, "BRDGSPROTO %s", arg); +} + +static void +setbridge_holdcount(const char *arg, int d, int s, const struct afswtch *afp) +{ + struct ifbrparam param; + u_long val; + + if (get_val(arg, &val) < 0 || (val & ~0xff) != 0) + errx(1, "invalid value: %s", arg); + + param.ifbrp_txhc = val & 0xff; + + if (do_cmd(s, BRDGSTXHC, ¶m, sizeof(param), 1) < 0) + err(1, "BRDGSTXHC %s", arg); +} + +static void setbridge_ifpriority(const char *ifn, const char *pri, int s, const struct afswtch *afp) { @@ -496,11 +550,11 @@ setbridge_ifpathcost(const char *ifn, co memset(&req, 0, sizeof(req)); - if (get_val(cost, &val) < 0 || (val & ~0xff) != 0) + if (get_val(cost, &val) < 0) errx(1, "invalid value: %s", cost); strlcpy(req.ifbr_ifsname, ifn, sizeof(req.ifbr_ifsname)); - req.ifbr_path_cost = val & 0xffff; + req.ifbr_path_cost = val; if (do_cmd(s, BRDGSIFCOST, &req, sizeof(req), 1) < 0) err(1, "BRDGSIFCOST %s", cost); @@ -542,6 +596,8 @@ static struct cmd bridge_cmds[] = { DEF_CMD_ARG("fwddelay", setbridge_fwddelay), DEF_CMD_ARG("maxage", setbridge_maxage), DEF_CMD_ARG("priority", setbridge_priority), + DEF_CMD_ARG("proto", setbridge_protocol), + DEF_CMD_ARG("holdcount", setbridge_holdcount), DEF_CMD_ARG2("ifpriority", setbridge_ifpriority), DEF_CMD_ARG2("ifpathcost", setbridge_ifpathcost), DEF_CMD_ARG("timeout", setbridge_timeout), Index: sbin/ifconfig/ifconfig.8 =================================================================== RCS file: /home/ncvs/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.124 diff -u -p -r1.124 ifconfig.8 --- sbin/ifconfig/ifconfig.8 10 Oct 2006 09:44:08 -0000 1.124 +++ sbin/ifconfig/ifconfig.8 12 Oct 2006 10:46:33 -0000 @@ -1270,35 +1270,47 @@ This is the default for all interfaces a .It Cm maxage Ar seconds Set the time that a Spanning Tree protocol configuration is valid. The default is 20 seconds. -The minimum is 1 second and the maximum is 255 seconds. +The minimum is 6 seconds and the maximum is 40 seconds. .It Cm fwddelay Ar seconds Set the time that must pass before an interface begins forwarding packets when Spanning Tree is enabled. The default is 15 seconds. -The minimum is 1 second and the maximum is 255 seconds. +The minimum is 4 seconds and the maximum is 30 seconds. .It Cm hellotime Ar seconds Set the time between broadcasting of Spanning Tree protocol configuration messages. +The hello time may only be changed when operating in legacy stp mode. The default is 2 seconds. -The minimum is 1 second and the maximum is 255 seconds. +The minimum is 1 second and the maximum is 2 seconds. .It Cm priority Ar value Set the bridge priority for Spanning Tree. The default is 32768. -The minimum is 0 and the maximum is 65536. +The minimum is 0 and the maximum is 61440. +.It Cm protocol Ar value +Set the Spanning Tree protocol. +The default is rstp. +The available options are stp and rstp. +.It Cm holdcount Ar value +Set the transmit hold count for Spanning Tree. +This is the number of packets transmitted before being rate limited. +The default is 6. +The minimum is 1 and the maximum is 10. .It Cm ifpriority Ar interface Ar value Set the Spanning Tree priority of .Ar interface to .Ar value . The default is 128. -The minimum is 0 and the maximum is 255. +The minimum is 0 and the maximum is 240. .It Cm ifpathcost Ar interface Ar value Set the Spanning Tree path cost of .Ar interface to .Ar value . -The default is 55. -The minimum is 0 and the maximum is 65535. +The default is calculated from the link speed. +To change a previously selected path cost back to automatic, set the +cost to 0. +The minimum is 1 and the maximum is 200000000. .El .Pp The following parameters are specific to IP tunnel interfaces, Index: sys/net/bridgestp.c =================================================================== RCS file: /home/ncvs/src/sys/net/bridgestp.c,v retrieving revision 1.20 diff -u -p -r1.20 bridgestp.c --- sys/net/bridgestp.c 1 Oct 2006 03:48:32 -0000 1.20 +++ sys/net/bridgestp.c 12 Oct 2006 10:57:57 -0000 @@ -2,6 +2,7 @@ /* * Copyright (c) 2000 Jason L. Wright (jason@thought.net) + * Copyright (c) 2006 Andrew Thompson (thompsa@FreeBSD.org) * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -30,8 +31,7 @@ /* * Implementation of the spanning tree protocol as defined in - * ISO/IEC Final DIS 15802-3 (IEEE P802.1D/D17), May 25, 1998. - * (In English: IEEE 802.1D, Draft 17, 1998) + * ISO/IEC 802.1D-2004, June 9, 2004. */ #include @@ -62,276 +62,177 @@ __FBSDID("$FreeBSD: src/sys/net/bridgest #include #include +#define BRIDGESTP_DEBUG 1 + +#ifdef BRIDGESTP_DEBUG +#define DPRINTF(fmt, arg...) printf("bstp: " fmt, ##arg) +#else +#define DPRINTF(fmt, arg...) +#endif + +#define PV2ADDR(pv, eaddr) do { \ + eaddr[0] = pv >> 40; \ + eaddr[1] = pv >> 32; \ + eaddr[2] = pv >> 24; \ + eaddr[3] = pv >> 16; \ + eaddr[4] = pv >> 8; \ + eaddr[5] = pv >> 0; \ +} while (0) + +#define INFO_BETTER 1 +#define INFO_SAME 0 +#define INFO_WORSE -1 + const uint8_t bstp_etheraddr[] = { 0x01, 0x80, 0xc2, 0x00, 0x00, 0x00 }; LIST_HEAD(, bstp_state) bstp_list; static struct mtx bstp_list_mtx; -static void bstp_initialize_port(struct bstp_state *, - struct bstp_port *); -static void bstp_ifupdstatus(struct bstp_state *, struct bstp_port *); -static void bstp_enable_port(struct bstp_state *, struct bstp_port *); -static void bstp_disable_port(struct bstp_state *, - struct bstp_port *); -#ifdef notused -static void bstp_enable_change_detection(struct bstp_port *); -static void bstp_disable_change_detection(struct bstp_port *); -#endif /* notused */ -static int bstp_root_bridge(struct bstp_state *bs); -static int bstp_supersedes_port_info(struct bstp_state *, - struct bstp_port *, struct bstp_config_unit *); -static int bstp_designated_port(struct bstp_state *, +static void bstp_transmit(struct bstp_state *, struct bstp_port *); -static int bstp_designated_for_some_port(struct bstp_state *); -static void bstp_transmit_config(struct bstp_state *, +static void bstp_transmit_bpdu(struct bstp_state *, struct bstp_port *); -static void bstp_transmit_tcn(struct bstp_state *); -static void bstp_received_config_bpdu(struct bstp_state *, - struct bstp_port *, struct bstp_config_unit *); -static void bstp_received_tcn_bpdu(struct bstp_state *, - struct bstp_port *, struct bstp_tcn_unit *); -static void bstp_record_config_information(struct bstp_state *, - struct bstp_port *, struct bstp_config_unit *); -static void bstp_record_config_timeout_values(struct bstp_state *, +static void bstp_transmit_tcn(struct bstp_state *, + struct bstp_port *); +static void bstp_decode_bpdu(struct bstp_port *, struct bstp_cbpdu *, struct bstp_config_unit *); -static void bstp_config_bpdu_generation(struct bstp_state *); -static void bstp_send_config_bpdu(struct bstp_state *, - struct bstp_port *, struct bstp_config_unit *); -static void bstp_configuration_update(struct bstp_state *); -static void bstp_root_selection(struct bstp_state *); -static void bstp_designated_port_selection(struct bstp_state *); -static void bstp_become_designated_port(struct bstp_state *, - struct bstp_port *); -static void bstp_port_state_selection(struct bstp_state *); -static void bstp_make_forwarding(struct bstp_state *, - struct bstp_port *); -static void bstp_make_blocking(struct bstp_state *, - struct bstp_port *); -static void bstp_set_port_state(struct bstp_port *, uint8_t); -static void bstp_state_change(void *, int); -static void bstp_update_forward_transitions(struct bstp_port *); -#ifdef notused -static void bstp_set_bridge_priority(struct bstp_state *, uint64_t); -static void bstp_set_port_priority(struct bstp_state *, - struct bstp_port *, uint16_t); -static void bstp_set_path_cost(struct bstp_state *, - struct bstp_port *, uint32_t); -#endif /* notused */ -static void bstp_topology_change_detection(struct bstp_state *); -static void bstp_topology_change_acknowledged(struct bstp_state *); -static void bstp_acknowledge_topology_change(struct bstp_state *, - struct bstp_port *); - +static void bstp_send_bpdu(struct bstp_state *, + struct bstp_port *, struct bstp_cbpdu *); static void bstp_enqueue(struct ifnet *, struct mbuf *); +static int bstp_pdu_flags(struct bstp_port *); +static void bstp_received_stp(struct bstp_state *, struct bstp_port *, + struct mbuf *, struct bstp_tbpdu *); +static void bstp_received_rstp(struct bstp_state *, + struct bstp_port *, struct mbuf *, struct bstp_tbpdu *); +static void bstp_received_tcn(struct bstp_state *, + struct bstp_port *, struct bstp_tcn_unit *); +static void bstp_received_bpdu(struct bstp_state *, + struct bstp_port *, struct bstp_config_unit *); +static int bstp_pdu_rcvtype(struct bstp_port *, struct bstp_config_unit *); +static int bstp_pdu_bettersame(struct bstp_port *, int); +static int bstp_info_cmp(struct bstp_pri_vector *, + struct bstp_pri_vector *); +static int bstp_info_superior(struct bstp_pri_vector *, + struct bstp_pri_vector *); +static void bstp_assign_roles(struct bstp_state *); +static void bstp_update_roles(struct bstp_state *, struct bstp_port *); +static void bstp_update_state(struct bstp_state *, struct bstp_port *); +static void bstp_update_tc(struct bstp_port *); +static void bstp_update_info(struct bstp_port *); +static void bstp_set_other_tcprop(struct bstp_port *); +static void bstp_set_all_reroot(struct bstp_state *); +static void bstp_set_all_sync(struct bstp_state *); +static void bstp_set_port_state(struct bstp_port *, int); +static void bstp_set_port_role(struct bstp_port *, int); +static void bstp_set_port_proto(struct bstp_port *, int); +static void bstp_set_port_tc(struct bstp_port *, int); +static void bstp_set_timer_tc(struct bstp_port *); +static void bstp_set_timer_msgage(struct bstp_port *); +static int bstp_rerooted(struct bstp_state *, struct bstp_port *); +static uint32_t bstp_calc_path_cost(struct bstp_port *); +static void bstp_notify_state(void *, int); +static void bstp_notify_rtage(void *, int); +static void bstp_ifupdstatus(struct bstp_state *, struct bstp_port *); +static void bstp_enable_port(struct bstp_state *, struct bstp_port *); +static void bstp_disable_port(struct bstp_state *, struct bstp_port *); static void bstp_tick(void *); static void bstp_timer_start(struct bstp_timer *, uint16_t); static void bstp_timer_stop(struct bstp_timer *); -static int bstp_timer_expired(struct bstp_timer *, uint16_t); - -static void bstp_hold_timer_expiry(struct bstp_state *, +static void bstp_timer_latch(struct bstp_timer *); +static int bstp_timer_expired(struct bstp_timer *); +static void bstp_hello_timer_expiry(struct bstp_state *, + struct bstp_port *); +static void bstp_message_age_expiry(struct bstp_state *, struct bstp_port *); -static void bstp_message_age_timer_expiry(struct bstp_state *, +static void bstp_migrate_delay_expiry(struct bstp_state *, struct bstp_port *); -static void bstp_forward_delay_timer_expiry(struct bstp_state *, +static void bstp_edge_delay_expiry(struct bstp_state *, struct bstp_port *); -static void bstp_topology_change_timer_expiry(struct bstp_state *); -static void bstp_tcn_timer_expiry(struct bstp_state *); -static void bstp_hello_timer_expiry(struct bstp_state *); static int bstp_addr_cmp(const uint8_t *, const uint8_t *); +static int bstp_same_bridgeid(uint64_t, uint64_t); +static void bstp_reinit(struct bstp_state *); +static void bstp_stop_locked(struct bstp_state *); static void -bstp_transmit_config(struct bstp_state *bs, struct bstp_port *bp) +bstp_transmit(struct bstp_state *bs, struct bstp_port *bp) { - BSTP_LOCK_ASSERT(bs); - - if (bp->bp_hold_timer.active) { - bp->bp_config_pending = 1; + /* + * a PDU can only be sent if we have tx quota left and the + * hello timer is running. + */ + if (bp->bp_hello_timer.active == 0) { + /* Test if it needs to be reset */ + bstp_hello_timer_expiry(bs, bp); return; } + if (bp->bp_txcount > bs->bs_txholdcount) + /* Ran out of karma */ + return; - bp->bp_config_bpdu.cu_message_type = BSTP_MSGTYPE_CFG; - bp->bp_config_bpdu.cu_rootid = bs->bs_designated_root; - bp->bp_config_bpdu.cu_root_path_cost = bs->bs_root_path_cost; - bp->bp_config_bpdu.cu_bridge_id = bs->bs_bridge_id; - bp->bp_config_bpdu.cu_port_id = bp->bp_port_id; - - if (bstp_root_bridge(bs)) - bp->bp_config_bpdu.cu_message_age = 0; - else - bp->bp_config_bpdu.cu_message_age = - bs->bs_root_port->bp_message_age_timer.value + - BSTP_MESSAGE_AGE_INCR; - - bp->bp_config_bpdu.cu_max_age = bs->bs_max_age; - bp->bp_config_bpdu.cu_hello_time = bs->bs_hello_time; - bp->bp_config_bpdu.cu_forward_delay = bs->bs_forward_delay; - bp->bp_config_bpdu.cu_topology_change_acknowledgment - = bp->bp_topology_change_acknowledge; - bp->bp_config_bpdu.cu_topology_change = bs->bs_topology_change; - - if (bp->bp_config_bpdu.cu_message_age < bs->bs_max_age) { - bp->bp_topology_change_acknowledge = 0; - bp->bp_config_pending = 0; - bstp_send_config_bpdu(bs, bp, &bp->bp_config_bpdu); - bstp_timer_start(&bp->bp_hold_timer, 0); + if (bp->bp_protover == BSTP_PROTO_RSTP) { + bstp_transmit_bpdu(bs, bp); + bp->bp_tc_ack = 0; + } else { /* STP */ + switch (bp->bp_role) { + case BSTP_ROLE_DESIGNATED: + bstp_transmit_bpdu(bs, bp); + bp->bp_tc_ack = 0; + break; + + case BSTP_ROLE_ROOT: + bstp_transmit_tcn(bs, bp); + break; + } } + bstp_timer_start(&bp->bp_hello_timer, bp->bp_desg_htime); + bp->bp_flags &= ~BSTP_PORT_NEWINFO; } static void -bstp_send_config_bpdu(struct bstp_state *bs, struct bstp_port *bp, - struct bstp_config_unit *cu) +bstp_transmit_bpdu(struct bstp_state *bs, struct bstp_port *bp) { - struct ifnet *ifp; - struct mbuf *m; - struct ether_header *eh; struct bstp_cbpdu bpdu; BSTP_LOCK_ASSERT(bs); - ifp = bp->bp_ifp; - - if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) - return; - - MGETHDR(m, M_DONTWAIT, MT_DATA); - if (m == NULL) - return; - - eh = mtod(m, struct ether_header *); - - m->m_pkthdr.rcvif = ifp; - m->m_pkthdr.len = sizeof(*eh) + sizeof(bpdu); - m->m_len = m->m_pkthdr.len; - - bpdu.cbu_ssap = bpdu.cbu_dsap = LLC_8021D_LSAP; - bpdu.cbu_ctl = LLC_UI; - bpdu.cbu_protoid = htons(0); - bpdu.cbu_protover = 0; - bpdu.cbu_bpdutype = cu->cu_message_type; - bpdu.cbu_flags = (cu->cu_topology_change ? BSTP_FLAG_TC : 0) | - (cu->cu_topology_change_acknowledgment ? BSTP_FLAG_TCA : 0); - - bpdu.cbu_rootpri = htons(cu->cu_rootid >> 48); - bpdu.cbu_rootaddr[0] = cu->cu_rootid >> 40; - bpdu.cbu_rootaddr[1] = cu->cu_rootid >> 32; - bpdu.cbu_rootaddr[2] = cu->cu_rootid >> 24; - bpdu.cbu_rootaddr[3] = cu->cu_rootid >> 16; - bpdu.cbu_rootaddr[4] = cu->cu_rootid >> 8; - bpdu.cbu_rootaddr[5] = cu->cu_rootid >> 0; - - bpdu.cbu_rootpathcost = htonl(cu->cu_root_path_cost); - - bpdu.cbu_bridgepri = htons(cu->cu_bridge_id >> 48); - bpdu.cbu_bridgeaddr[0] = cu->cu_bridge_id >> 40; - bpdu.cbu_bridgeaddr[1] = cu->cu_bridge_id >> 32; - bpdu.cbu_bridgeaddr[2] = cu->cu_bridge_id >> 24; - bpdu.cbu_bridgeaddr[3] = cu->cu_bridge_id >> 16; - bpdu.cbu_bridgeaddr[4] = cu->cu_bridge_id >> 8; - bpdu.cbu_bridgeaddr[5] = cu->cu_bridge_id >> 0; - - bpdu.cbu_portid = htons(cu->cu_port_id); - bpdu.cbu_messageage = htons(cu->cu_message_age); - bpdu.cbu_maxage = htons(cu->cu_max_age); - bpdu.cbu_hellotime = htons(cu->cu_hello_time); - bpdu.cbu_forwarddelay = htons(cu->cu_forward_delay); - - memcpy(eh->ether_shost, IF_LLADDR(ifp), ETHER_ADDR_LEN); - memcpy(eh->ether_dhost, bstp_etheraddr, ETHER_ADDR_LEN); - eh->ether_type = htons(sizeof(bpdu)); - - memcpy(mtod(m, caddr_t) + sizeof(*eh), &bpdu, sizeof(bpdu)); - - bstp_enqueue(ifp, m); -} - -static int -bstp_root_bridge(struct bstp_state *bs) -{ - return (bs->bs_designated_root == bs->bs_bridge_id); -} - -static int -bstp_supersedes_port_info(struct bstp_state *bs, struct bstp_port *bp, - struct bstp_config_unit *cu) -{ - if (cu->cu_rootid < bp->bp_designated_root) - return (1); - if (cu->cu_rootid > bp->bp_designated_root) - return (0); - - if (cu->cu_root_path_cost < bp->bp_designated_cost) - return (1); - if (cu->cu_root_path_cost > bp->bp_designated_cost) - return (0); - - if (cu->cu_bridge_id < bp->bp_designated_bridge) - return (1); - if (cu->cu_bridge_id > bp->bp_designated_bridge) - return (0); - - if (bs->bs_bridge_id != cu->cu_bridge_id) - return (1); - if (cu->cu_port_id <= bp->bp_designated_port) - return (1); - return (0); -} - -static void -bstp_record_config_information(struct bstp_state *bs, - struct bstp_port *bp, struct bstp_config_unit *cu) -{ - BSTP_LOCK_ASSERT(bs); + bpdu.cbu_rootpri = htons(bp->bp_desg_pv.pv_root_id >> 48); + PV2ADDR(bp->bp_desg_pv.pv_root_id, bpdu.cbu_rootaddr); - bp->bp_designated_root = cu->cu_rootid; - bp->bp_designated_cost = cu->cu_root_path_cost; - bp->bp_designated_bridge = cu->cu_bridge_id; - bp->bp_designated_port = cu->cu_port_id; - bstp_timer_start(&bp->bp_message_age_timer, cu->cu_message_age); -} + bpdu.cbu_rootpathcost = htonl(bp->bp_desg_pv.pv_cost); -static void -bstp_record_config_timeout_values(struct bstp_state *bs, - struct bstp_config_unit *config) -{ - BSTP_LOCK_ASSERT(bs); + bpdu.cbu_bridgepri = htons(bp->bp_desg_pv.pv_dbridge_id >> 48); + PV2ADDR(bp->bp_desg_pv.pv_dbridge_id, bpdu.cbu_bridgeaddr); - bs->bs_max_age = config->cu_max_age; - bs->bs_hello_time = config->cu_hello_time; - bs->bs_forward_delay = config->cu_forward_delay; - bs->bs_topology_change = config->cu_topology_change; -} + bpdu.cbu_portid = htons(bp->bp_port_id); + bpdu.cbu_messageage = htons(bp->bp_desg_msg_age); + bpdu.cbu_maxage = htons(bp->bp_desg_max_age); + bpdu.cbu_hellotime = htons(bp->bp_desg_htime); + bpdu.cbu_forwarddelay = htons(bp->bp_desg_fdelay); -static void -bstp_config_bpdu_generation(struct bstp_state *bs) -{ - struct bstp_port *bp; + bpdu.cbu_flags = bstp_pdu_flags(bp); - BSTP_LOCK_ASSERT(bs); + switch (bp->bp_protover) { + case BSTP_PROTO_STP: + bpdu.cbu_bpdutype = BSTP_MSGTYPE_CFG; + break; - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - if (bstp_designated_port(bs, bp) && - (bp->bp_state != BSTP_IFSTATE_DISABLED)) - bstp_transmit_config(bs, bp); + case BSTP_PROTO_RSTP: + bpdu.cbu_bpdutype = BSTP_MSGTYPE_RSTP; + break; } -} -static int -bstp_designated_port(struct bstp_state *bs, struct bstp_port *bp) -{ - return ((bp->bp_designated_bridge == bs->bs_bridge_id) - && (bp->bp_designated_port == bp->bp_port_id)); + bstp_send_bpdu(bs, bp, &bpdu); } static void -bstp_transmit_tcn(struct bstp_state *bs) +bstp_transmit_tcn(struct bstp_state *bs, struct bstp_port *bp) { struct bstp_tbpdu bpdu; - struct bstp_port *bp = bs->bs_root_port; struct ifnet *ifp = bp->bp_ifp; struct ether_header *eh; struct mbuf *m; - BSTP_LOCK_ASSERT(bs); + KASSERT(bp == bs->bs_root_port, ("%s: bad root port\n", __func__)); if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) return; @@ -358,234 +259,205 @@ bstp_transmit_tcn(struct bstp_state *bs) memcpy(mtod(m, caddr_t) + sizeof(*eh), &bpdu, sizeof(bpdu)); + bp->bp_txcount++; bstp_enqueue(ifp, m); } static void -bstp_configuration_update(struct bstp_state *bs) -{ - BSTP_LOCK_ASSERT(bs); - - bstp_root_selection(bs); - bstp_designated_port_selection(bs); -} - -static void -bstp_root_selection(struct bstp_state *bs) +bstp_decode_bpdu(struct bstp_port *bp, struct bstp_cbpdu *cpdu, + struct bstp_config_unit *cu) { - struct bstp_port *root_port = NULL, *bp; - - BSTP_LOCK_ASSERT(bs); - - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - if (bstp_designated_port(bs, bp)) - continue; - if (bp->bp_state == BSTP_IFSTATE_DISABLED) - continue; - if (bp->bp_designated_root >= bs->bs_bridge_id) - continue; - if (root_port == NULL) - goto set_port; - - if (bp->bp_designated_root < root_port->bp_designated_root) - goto set_port; - if (bp->bp_designated_root > root_port->bp_designated_root) - continue; + int flags; - if ((bp->bp_designated_cost + bp->bp_path_cost) < - (root_port->bp_designated_cost + root_port->bp_path_cost)) - goto set_port; - if ((bp->bp_designated_cost + bp->bp_path_cost) > - (root_port->bp_designated_cost + root_port->bp_path_cost)) - continue; - - if (bp->bp_designated_bridge < - root_port->bp_designated_bridge) - goto set_port; - if (bp->bp_designated_bridge > - root_port->bp_designated_bridge) - continue; - - if (bp->bp_designated_port < root_port->bp_designated_port) - goto set_port; - if (bp->bp_designated_port > root_port->bp_designated_port) - continue; + cu->cu_pv.pv_root_id = + (((uint64_t)ntohs(cpdu->cbu_rootpri)) << 48) | + (((uint64_t)cpdu->cbu_rootaddr[0]) << 40) | + (((uint64_t)cpdu->cbu_rootaddr[1]) << 32) | + (((uint64_t)cpdu->cbu_rootaddr[2]) << 24) | + (((uint64_t)cpdu->cbu_rootaddr[3]) << 16) | + (((uint64_t)cpdu->cbu_rootaddr[4]) << 8) | + (((uint64_t)cpdu->cbu_rootaddr[5]) << 0); + + cu->cu_pv.pv_dbridge_id = + (((uint64_t)ntohs(cpdu->cbu_bridgepri)) << 48) | + (((uint64_t)cpdu->cbu_bridgeaddr[0]) << 40) | + (((uint64_t)cpdu->cbu_bridgeaddr[1]) << 32) | + (((uint64_t)cpdu->cbu_bridgeaddr[2]) << 24) | + (((uint64_t)cpdu->cbu_bridgeaddr[3]) << 16) | + (((uint64_t)cpdu->cbu_bridgeaddr[4]) << 8) | + (((uint64_t)cpdu->cbu_bridgeaddr[5]) << 0); + + cu->cu_pv.pv_cost = ntohl(cpdu->cbu_rootpathcost); + cu->cu_message_age = ntohs(cpdu->cbu_messageage); + cu->cu_max_age = ntohs(cpdu->cbu_maxage); + cu->cu_hello_time = ntohs(cpdu->cbu_hellotime); + cu->cu_forward_delay = ntohs(cpdu->cbu_forwarddelay); + cu->cu_pv.pv_dport_id = ntohs(cpdu->cbu_portid); + cu->cu_pv.pv_port_id = bp->bp_port_id; + cu->cu_message_type = cpdu->cbu_bpdutype; + + /* Strip off unused flags in STP mode */ + flags = cpdu->cbu_flags; + switch (bp->bp_protover) { + case BSTP_PROTO_STP: + flags &= BSTP_PDU_STPMASK; + /* A STP BPDU explicitly conveys a Designated Port */ + cu->cu_role = BSTP_ROLE_DESIGNATED; + break; - if (bp->bp_port_id >= root_port->bp_port_id) - continue; -set_port: - root_port = bp; + case BSTP_PROTO_RSTP: + flags &= BSTP_PDU_RSTPMASK; + break; } - bs->bs_root_port = root_port; - if (root_port == NULL) { - bs->bs_designated_root = bs->bs_bridge_id; - bs->bs_root_path_cost = 0; - } else { - bs->bs_designated_root = root_port->bp_designated_root; - bs->bs_root_path_cost = root_port->bp_designated_cost + - root_port->bp_path_cost; + cu->cu_topology_change_ack = + (flags & BSTP_PDU_F_TCA) ? 1 : 0; + cu->cu_proposal = + (flags & BSTP_PDU_F_P) ? 1 : 0; + cu->cu_agree = + (flags & BSTP_PDU_F_A) ? 1 : 0; + cu->cu_learning = + (flags & BSTP_PDU_F_L) ? 1 : 0; + cu->cu_forwarding = + (flags & BSTP_PDU_F_F) ? 1 : 0; + cu->cu_topology_change = + (flags & BSTP_PDU_F_TC) ? 1 : 0; + + switch ((flags & BSTP_PDU_PRMASK) >> BSTP_PDU_PRSHIFT) { + case BSTP_PDU_F_ROOT: + cu->cu_role = BSTP_ROLE_ROOT; + break; + case BSTP_PDU_F_ALT: + cu->cu_role = BSTP_ROLE_ALTERNATE; + break; + case BSTP_PDU_F_DESG: + cu->cu_role = BSTP_ROLE_DESIGNATED; + break; } } static void -bstp_designated_port_selection(struct bstp_state *bs) +bstp_send_bpdu(struct bstp_state *bs, struct bstp_port *bp, + struct bstp_cbpdu *bpdu) { - struct bstp_port *bp; + struct ifnet *ifp; + struct mbuf *m; + struct ether_header *eh; BSTP_LOCK_ASSERT(bs); - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - if (bstp_designated_port(bs, bp)) - goto designated; - if (bp->bp_designated_root != bs->bs_designated_root) - goto designated; - - if (bs->bs_root_path_cost < bp->bp_designated_cost) - goto designated; - if (bs->bs_root_path_cost > bp->bp_designated_cost) - continue; - - if (bs->bs_bridge_id < bp->bp_designated_bridge) - goto designated; - if (bs->bs_bridge_id > bp->bp_designated_bridge) - continue; + ifp = bp->bp_ifp; - if (bp->bp_port_id > bp->bp_designated_port) - continue; -designated: - bstp_become_designated_port(bs, bp); - } -} + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) + return; -static void -bstp_become_designated_port(struct bstp_state *bs, struct bstp_port *bp) -{ - BSTP_LOCK_ASSERT(bs); + MGETHDR(m, M_DONTWAIT, MT_DATA); + if (m == NULL) + return; - bp->bp_designated_root = bs->bs_designated_root; - bp->bp_designated_cost = bs->bs_root_path_cost; - bp->bp_designated_bridge = bs->bs_bridge_id; - bp->bp_designated_port = bp->bp_port_id; -} + eh = mtod(m, struct ether_header *); -static void -bstp_port_state_selection(struct bstp_state *bs) -{ - struct bstp_port *bp; + bpdu->cbu_ssap = bpdu->cbu_dsap = LLC_8021D_LSAP; + bpdu->cbu_ctl = LLC_UI; + bpdu->cbu_protoid = htons(BSTP_PROTO_ID); - BSTP_LOCK_ASSERT(bs); + memcpy(eh->ether_shost, IF_LLADDR(ifp), ETHER_ADDR_LEN); + memcpy(eh->ether_dhost, bstp_etheraddr, ETHER_ADDR_LEN); - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - if (bp == bs->bs_root_port) { - bp->bp_config_pending = 0; - bp->bp_topology_change_acknowledge = 0; - bstp_make_forwarding(bs, bp); - } else if (bstp_designated_port(bs, bp)) { - bstp_timer_stop(&bp->bp_message_age_timer); - bstp_make_forwarding(bs, bp); - } else { - bp->bp_config_pending = 0; - bp->bp_topology_change_acknowledge = 0; - bstp_make_blocking(bs, bp); - } - } -} + switch (bpdu->cbu_bpdutype) { + case BSTP_MSGTYPE_CFG: + bpdu->cbu_protover = BSTP_PROTO_STP; + m->m_pkthdr.len = sizeof(*eh) + BSTP_BPDU_STP_LEN; + eh->ether_type = htons(BSTP_BPDU_STP_LEN); + memcpy(mtod(m, caddr_t) + sizeof(*eh), bpdu, + BSTP_BPDU_STP_LEN); + break; -static void -bstp_make_forwarding(struct bstp_state *bs, struct bstp_port *bp) -{ - BSTP_LOCK_ASSERT(bs); + case BSTP_MSGTYPE_RSTP: + bpdu->cbu_protover = BSTP_PROTO_RSTP; + bpdu->cbu_versionlen = htons(0); + m->m_pkthdr.len = sizeof(*eh) + BSTP_BPDU_RSTP_LEN; + eh->ether_type = htons(BSTP_BPDU_RSTP_LEN); + memcpy(mtod(m, caddr_t) + sizeof(*eh), bpdu, + BSTP_BPDU_RSTP_LEN); + break; - if (bp->bp_state == BSTP_IFSTATE_BLOCKING) { - bstp_set_port_state(bp, BSTP_IFSTATE_LISTENING); - bstp_timer_start(&bp->bp_forward_delay_timer, 0); + default: + panic("not implemented"); } -} - -static void -bstp_make_blocking(struct bstp_state *bs, struct bstp_port *bp) -{ - BSTP_LOCK_ASSERT(bs); + m->m_pkthdr.rcvif = ifp; + m->m_len = m->m_pkthdr.len; - if ((bp->bp_state != BSTP_IFSTATE_DISABLED) && - (bp->bp_state != BSTP_IFSTATE_BLOCKING)) { - if ((bp->bp_state == BSTP_IFSTATE_FORWARDING) || - (bp->bp_state == BSTP_IFSTATE_LEARNING)) { - if (bp->bp_change_detection_enabled) { - bstp_topology_change_detection(bs); - } - } - bstp_set_port_state(bp, BSTP_IFSTATE_BLOCKING); - bstp_timer_stop(&bp->bp_forward_delay_timer); - } + bp->bp_txcount++; + bstp_enqueue(ifp, m); } static void -bstp_set_port_state(struct bstp_port *bp, uint8_t state) +bstp_enqueue(struct ifnet *dst_ifp, struct mbuf *m) { - struct bstp_state *bs = bp->bp_bs; + int err = 0; - bp->bp_state = state; + IFQ_ENQUEUE(&dst_ifp->if_snd, m, err); - /* notify the parent bridge */ - if (bs->bs_state_cb != NULL) - taskqueue_enqueue(taskqueue_swi, &bp->bp_statetask); + if ((dst_ifp->if_drv_flags & IFF_DRV_OACTIVE) == 0) + (*dst_ifp->if_start)(dst_ifp); } -/* - * Notify the bridge that a port state has changed, we need to do this from a - * taskqueue to avoid a LOR. - */ -static void -bstp_state_change(void *arg, int pending) +static int +bstp_pdu_flags(struct bstp_port *bp) { - struct bstp_port *bp = (struct bstp_port *)arg; - struct bstp_state *bs = bp->bp_bs; + int flags = 0; - if (bp->bp_active == 1) - (*bs->bs_state_cb)(bp->bp_ifp, bp->bp_state); -} + if (bp->bp_proposing && bp->bp_state != BSTP_IFSTATE_FORWARDING) + flags |= BSTP_PDU_F_P; -static void -bstp_update_forward_transitions(struct bstp_port *bp) -{ - bp->bp_forward_transitions++; -} + if (bp->bp_agree) + flags |= BSTP_PDU_F_A; -static void -bstp_topology_change_detection(struct bstp_state *bs) -{ - BSTP_LOCK_ASSERT(bs); + if (bp->bp_tc_timer.active) + flags |= BSTP_PDU_F_TC; + + if (bp->bp_tc_ack) + flags |= BSTP_PDU_F_TCA; + + switch (bp->bp_state) { + case BSTP_IFSTATE_LEARNING: + flags |= BSTP_PDU_F_L; + break; - if (bstp_root_bridge(bs)) { - bs->bs_topology_change = 1; - bstp_timer_start(&bs->bs_topology_change_timer, 0); - } else if (!bs->bs_topology_change_detected) { - bstp_transmit_tcn(bs); - bstp_timer_start(&bs->bs_tcn_timer, 0); + case BSTP_IFSTATE_FORWARDING: + flags |= (BSTP_PDU_F_L | BSTP_PDU_F_F); + break; } - bs->bs_topology_change_detected = 1; - getmicrotime(&bs->bs_last_tc_time); -} -static void -bstp_topology_change_acknowledged(struct bstp_state *bs) -{ - BSTP_LOCK_ASSERT(bs); + switch (bp->bp_role) { + case BSTP_ROLE_ROOT: + flags |= + (BSTP_PDU_F_ROOT << BSTP_PDU_PRSHIFT); + break; - bs->bs_topology_change_detected = 0; - bstp_timer_stop(&bs->bs_tcn_timer); -} + case BSTP_ROLE_ALTERNATE: + case BSTP_ROLE_BACKUP: /* fall through */ + flags |= + (BSTP_PDU_F_ALT << BSTP_PDU_PRSHIFT); + break; -static void -bstp_acknowledge_topology_change(struct bstp_state *bs, - struct bstp_port *bp) -{ - BSTP_LOCK_ASSERT(bs); + case BSTP_ROLE_DESIGNATED: + flags |= + (BSTP_PDU_F_DESG << BSTP_PDU_PRSHIFT); + break; + } - bp->bp_topology_change_acknowledge = 1; - bstp_transmit_config(bs, bp); + /* Strip off unused flags in either mode */ + switch (bp->bp_protover) { + case BSTP_PROTO_STP: + flags &= BSTP_PDU_STPMASK; + break; + case BSTP_PROTO_RSTP: + flags &= BSTP_PDU_RSTPMASK; + break; + } + return (flags); } struct mbuf * @@ -594,9 +466,6 @@ bstp_input(struct bstp_port *bp, struct struct bstp_state *bs = bp->bp_bs; struct ether_header *eh; struct bstp_tbpdu tpdu; - struct bstp_cbpdu cpdu; - struct bstp_config_unit cu; - struct bstp_tcn_unit tu; uint16_t len; if (bp->bp_active == 0) { @@ -622,59 +491,39 @@ bstp_input(struct bstp_port *bp, struct memcpy(&tpdu, mtod(m, caddr_t), sizeof(tpdu)); + /* basic packet checks */ if (tpdu.tbu_dsap != LLC_8021D_LSAP || tpdu.tbu_ssap != LLC_8021D_LSAP || tpdu.tbu_ctl != LLC_UI) goto out; - if (tpdu.tbu_protoid != 0 || tpdu.tbu_protover != 0) + if (tpdu.tbu_protoid != BSTP_PROTO_ID) goto out; - switch (tpdu.tbu_bpdutype) { - case BSTP_MSGTYPE_TCN: - tu.tu_message_type = tpdu.tbu_bpdutype; - bstp_received_tcn_bpdu(bs, bp, &tu); - break; - case BSTP_MSGTYPE_CFG: - if (m->m_len < sizeof(cpdu) && - (m = m_pullup(m, sizeof(cpdu))) == NULL) + if (tpdu.tbu_protover != bp->bp_protover) { + /* + * Wait for the migration delay timer to expire before changing + * protocol version to avoid flip-flops. + */ + if (bp->bp_flags & BSTP_PORT_CANMIGRATE) + bstp_set_port_proto(bp, tpdu.tbu_protover); + else goto out; - memcpy(&cpdu, mtod(m, caddr_t), sizeof(cpdu)); - - cu.cu_rootid = - (((uint64_t)ntohs(cpdu.cbu_rootpri)) << 48) | - (((uint64_t)cpdu.cbu_rootaddr[0]) << 40) | - (((uint64_t)cpdu.cbu_rootaddr[1]) << 32) | - (((uint64_t)cpdu.cbu_rootaddr[2]) << 24) | - (((uint64_t)cpdu.cbu_rootaddr[3]) << 16) | - (((uint64_t)cpdu.cbu_rootaddr[4]) << 8) | - (((uint64_t)cpdu.cbu_rootaddr[5]) << 0); - - cu.cu_bridge_id = - (((uint64_t)ntohs(cpdu.cbu_bridgepri)) << 48) | - (((uint64_t)cpdu.cbu_bridgeaddr[0]) << 40) | - (((uint64_t)cpdu.cbu_bridgeaddr[1]) << 32) | - (((uint64_t)cpdu.cbu_bridgeaddr[2]) << 24) | - (((uint64_t)cpdu.cbu_bridgeaddr[3]) << 16) | - (((uint64_t)cpdu.cbu_bridgeaddr[4]) << 8) | - (((uint64_t)cpdu.cbu_bridgeaddr[5]) << 0); - - cu.cu_root_path_cost = ntohl(cpdu.cbu_rootpathcost); - cu.cu_message_age = ntohs(cpdu.cbu_messageage); - cu.cu_max_age = ntohs(cpdu.cbu_maxage); - cu.cu_hello_time = ntohs(cpdu.cbu_hellotime); - cu.cu_forward_delay = ntohs(cpdu.cbu_forwarddelay); - cu.cu_port_id = ntohs(cpdu.cbu_portid); - cu.cu_message_type = cpdu.cbu_bpdutype; - cu.cu_topology_change_acknowledgment = - (cpdu.cbu_flags & BSTP_FLAG_TCA) ? 1 : 0; - cu.cu_topology_change = - (cpdu.cbu_flags & BSTP_FLAG_TC) ? 1 : 0; - bstp_received_config_bpdu(bs, bp, &cu); - break; - default: - goto out; } + /* Clear operedge upon receiving a PDU on the port */ + bp->bp_operedge = 0; + bstp_timer_start(&bp->bp_edge_delay_timer, + BSTP_DEFAULT_MIGRATE_DELAY); + + switch (tpdu.tbu_protover) { + case BSTP_PROTO_STP: + bstp_received_stp(bs, bp, m, &tpdu); + break; + + case BSTP_PROTO_RSTP: + bstp_received_rstp(bs, bp, m, &tpdu); + break; + } out: BSTP_UNLOCK(bs); if (m) @@ -683,141 +532,1359 @@ out: } static void -bstp_received_config_bpdu(struct bstp_state *bs, struct bstp_port *bp, - struct bstp_config_unit *cu) +bstp_received_stp(struct bstp_state *bs, struct bstp_port *bp, + struct mbuf *m, struct bstp_tbpdu *tpdu) +{ + struct bstp_cbpdu cpdu; + struct bstp_config_unit *cu = &bp->bp_msg_cu; + struct bstp_tcn_unit tu; + + switch (tpdu->tbu_bpdutype) { + case BSTP_MSGTYPE_TCN: + tu.tu_message_type = tpdu->tbu_bpdutype; + bstp_received_tcn(bs, bp, &tu); + break; + case BSTP_MSGTYPE_CFG: + if (m->m_len < BSTP_BPDU_STP_LEN && + (m = m_pullup(m, BSTP_BPDU_STP_LEN)) == NULL) + return; + memcpy(&cpdu, mtod(m, caddr_t), BSTP_BPDU_STP_LEN); + + bstp_decode_bpdu(bp, &cpdu, cu); + bstp_received_bpdu(bs, bp, cu); + break; + } +} + +static void +bstp_received_rstp(struct bstp_state *bs, struct bstp_port *bp, + struct mbuf *m, struct bstp_tbpdu *tpdu) +{ + struct bstp_cbpdu cpdu; + struct bstp_config_unit *cu = &bp->bp_msg_cu; + + if (tpdu->tbu_bpdutype != BSTP_MSGTYPE_RSTP) { + m_freem(m); + return; + } + + if (m->m_len < BSTP_BPDU_RSTP_LEN && + (m = m_pullup(m, BSTP_BPDU_RSTP_LEN)) == NULL) + return; + memcpy(&cpdu, mtod(m, caddr_t), BSTP_BPDU_RSTP_LEN); + + bstp_decode_bpdu(bp, &cpdu, cu); + bstp_received_bpdu(bs, bp, cu); +} + +static void +bstp_received_tcn(struct bstp_state *bs, struct bstp_port *bp, + struct bstp_tcn_unit *tcn) +{ + bp->bp_rcvdtcn = 1; + bstp_update_tc(bp); +} + +static void +bstp_received_bpdu(struct bstp_state *bs, struct bstp_port *bp, + struct bstp_config_unit *cu) +{ + int type; + + BSTP_LOCK_ASSERT(bs); + + /* We need to have transitioned to INFO_MINE before proceeding */ + switch (bp->bp_infois) { + case BSTP_INFO_DISABLED: + case BSTP_INFO_AGED: + return; + } + + type = bstp_pdu_rcvtype(bp, cu); + + switch (type) { + case BSTP_PDU_SUPERIOR: + bs->bs_allsynced = 0; + bp->bp_agreed = 0; + bp->bp_proposing = 0; + + if (cu->cu_proposal && cu->cu_forwarding == 0) + bp->bp_proposed = 1; + if (cu->cu_topology_change) + bp->bp_rcvdtc = 1; + if (cu->cu_topology_change_ack) + bp->bp_rcvdtca = 1; + + if (bp->bp_agree && + !bstp_pdu_bettersame(bp, BSTP_INFO_RECIEVED)) + bp->bp_agree = 0; + + /* copy the received priority and timers to the port */ + bp->bp_port_pv = cu->cu_pv; + bp->bp_port_msg_age = cu->cu_message_age; + bp->bp_port_max_age = cu->cu_max_age; + bp->bp_port_fdelay = cu->cu_forward_delay; + bp->bp_port_htime = + (cu->cu_hello_time > BSTP_MIN_HELLO_TIME ? + cu->cu_hello_time : BSTP_MIN_HELLO_TIME); + + /* set expiry for the new info */ + bstp_set_timer_msgage(bp); + + bp->bp_infois = BSTP_INFO_RECIEVED; + bstp_assign_roles(bs); + break; + + case BSTP_PDU_REPEATED: + if (cu->cu_proposal && cu->cu_forwarding == 0) + bp->bp_proposed = 1; + if (cu->cu_topology_change) + bp->bp_rcvdtc = 1; + if (cu->cu_topology_change_ack) + bp->bp_rcvdtca = 1; + + /* rearm the age timer */ + bstp_set_timer_msgage(bp); + break; + + case BSTP_PDU_INFERIOR: + if (cu->cu_learning) { + bp->bp_agreed = 1; + bp->bp_proposing = 0; + } + break; + + case BSTP_PDU_INFERIORALT: + /* + * only point to point links are allowed fast + * transitions to forwarding. + */ + if (cu->cu_agree && bp->bp_p2p_link) { + bp->bp_agreed = 1; + bp->bp_proposing = 0; + } else + bp->bp_agreed = 0; + + if (cu->cu_topology_change) + bp->bp_rcvdtc = 1; + if (cu->cu_topology_change_ack) + bp->bp_rcvdtca = 1; + break; + + case BSTP_PDU_OTHER: + return; /* do nothing */ + } + /* update the state machines with the new data */ + bstp_update_state(bs, bp); +} + +static int +bstp_pdu_rcvtype(struct bstp_port *bp, struct bstp_config_unit *cu) +{ + int type; + + /* default return type */ + type = BSTP_PDU_OTHER; + + switch (cu->cu_role) { + case BSTP_ROLE_DESIGNATED: + if (bstp_info_superior(&bp->bp_port_pv, &cu->cu_pv)) + /* bpdu priority is superior */ + type = BSTP_PDU_SUPERIOR; + else if (bstp_info_cmp(&bp->bp_port_pv, &cu->cu_pv) == + INFO_SAME) { + if (bp->bp_port_msg_age != cu->cu_message_age || + bp->bp_port_max_age != cu->cu_max_age || + bp->bp_port_fdelay != cu->cu_forward_delay || + bp->bp_port_htime != cu->cu_hello_time) + /* bpdu priority is equal and timers differ */ + type = BSTP_PDU_SUPERIOR; + else + /* bpdu is equal */ + type = BSTP_PDU_REPEATED; + } else + /* bpdu priority is worse */ + type = BSTP_PDU_INFERIOR; + + break; + + case BSTP_ROLE_ROOT: + case BSTP_ROLE_ALTERNATE: + case BSTP_ROLE_BACKUP: + if (bstp_info_cmp(&bp->bp_port_pv, &cu->cu_pv) <= INFO_SAME) + /* + * not a designated port and priority is the same or + * worse + */ + type = BSTP_PDU_INFERIORALT; + break; + } + + return (type); +} + +static int +bstp_pdu_bettersame(struct bstp_port *bp, int newinfo) +{ + if (newinfo == BSTP_INFO_RECIEVED && + bp->bp_infois == BSTP_INFO_RECIEVED && + bstp_info_cmp(&bp->bp_port_pv, &bp->bp_msg_cu.cu_pv) >= INFO_SAME) { + return (1); + } + + if (newinfo == BSTP_INFO_MINE && + bp->bp_infois == BSTP_INFO_MINE && + bstp_info_cmp(&bp->bp_port_pv, &bp->bp_desg_pv) >= INFO_SAME) { + return (1); + } + + return (0); +} + +static int +bstp_info_cmp(struct bstp_pri_vector *pv, + struct bstp_pri_vector *cpv) +{ + if (cpv->pv_root_id < pv->pv_root_id) + return (INFO_BETTER); + if (cpv->pv_root_id > pv->pv_root_id) + return (INFO_WORSE); + + if (cpv->pv_cost < pv->pv_cost) + return (INFO_BETTER); + if (cpv->pv_cost > pv->pv_cost) + return (INFO_WORSE); + + if (cpv->pv_dbridge_id < pv->pv_dbridge_id) + return (INFO_BETTER); + if (cpv->pv_dbridge_id > pv->pv_dbridge_id) + return (INFO_WORSE); + + if (cpv->pv_dport_id < pv->pv_dport_id) + return (INFO_BETTER); + if (cpv->pv_dport_id > pv->pv_dport_id) + return (INFO_WORSE); + + return (INFO_SAME); +} + +/* + * This message priority vector is superior to the port priority vector and + * will replace it if, and only if, the message priority vector is better than + * the port priority vector, or the message has been transmitted from the same + * designated bridge and designated port as the port priority vector. + */ +static int +bstp_info_superior(struct bstp_pri_vector *pv, + struct bstp_pri_vector *cpv) +{ + if (bstp_info_cmp(pv, cpv) == INFO_BETTER || + (bstp_same_bridgeid(pv->pv_dbridge_id, cpv->pv_dbridge_id) && + (cpv->pv_dport_id & 0xfff) == (pv->pv_dport_id & 0xfff))) + return (1); + return (0); +} + +static void +bstp_assign_roles(struct bstp_state *bs) +{ + struct bstp_port *bp, *rbp = NULL; + struct bstp_pri_vector pv; + + /* default to our priority vector */ + bs->bs_root_pv = bs->bs_bridge_pv; + bs->bs_root_msg_age = 0; + bs->bs_root_max_age = bs->bs_bridge_max_age; + bs->bs_root_fdelay = bs->bs_bridge_fdelay; + bs->bs_root_htime = bs->bs_bridge_htime; + bs->bs_root_port = NULL; + + /* check if any recieved info supersedes us */ + LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { + if (bp->bp_infois != BSTP_INFO_RECIEVED) + continue; + + pv = bp->bp_port_pv; + pv.pv_cost += bp->bp_path_cost; + + /* The root priority vector is the best of the set comprising + * the bridge priority vector plus all root path priority + * vectors whose bridge address is not equal to us. + */ + if (bstp_same_bridgeid(pv.pv_dbridge_id, + bs->bs_bridge_pv.pv_dbridge_id) == 0 && + bstp_info_cmp(&bs->bs_root_pv, &pv) == INFO_BETTER) { + /* the port vector replaces the root */ + bs->bs_root_pv = pv; + bs->bs_root_msg_age = bp->bp_port_msg_age + + BSTP_MESSAGE_AGE_INCR; + bs->bs_root_max_age = bp->bp_port_max_age; + bs->bs_root_fdelay = bp->bp_port_fdelay; + bs->bs_root_htime = bp->bp_port_htime; + rbp = bp; + } + } + + LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { + /* calculate the port designated vector */ + bp->bp_desg_pv.pv_root_id = bs->bs_root_pv.pv_root_id; + bp->bp_desg_pv.pv_cost = bs->bs_root_pv.pv_cost; + bp->bp_desg_pv.pv_dbridge_id = bs->bs_bridge_pv.pv_dbridge_id; + bp->bp_desg_pv.pv_dport_id = bp->bp_port_id; + bp->bp_desg_pv.pv_port_id = bp->bp_port_id; + + /* calculate designated times */ + bp->bp_desg_msg_age = bs->bs_root_msg_age; + bp->bp_desg_max_age = bs->bs_root_max_age; + bp->bp_desg_fdelay = bs->bs_root_fdelay; + bp->bp_desg_htime = bs->bs_bridge_htime; + + + switch (bp->bp_infois) { + case BSTP_INFO_DISABLED: + bstp_set_port_role(bp, BSTP_ROLE_DISABLED); + break; + + case BSTP_INFO_AGED: + bstp_set_port_role(bp, BSTP_ROLE_DESIGNATED); + bstp_update_info(bp); + break; + + case BSTP_INFO_MINE: + bstp_set_port_role(bp, BSTP_ROLE_DESIGNATED); + /* update the port info if stale */ + if (bstp_info_cmp(&bp->bp_port_pv, + &bp->bp_desg_pv) != INFO_SAME || + (rbp != NULL && + (bp->bp_port_msg_age != rbp->bp_port_msg_age || + bp->bp_port_max_age != rbp->bp_port_max_age || + bp->bp_port_fdelay != rbp->bp_port_fdelay || + bp->bp_port_htime != rbp->bp_port_htime))) + bstp_update_info(bp); + break; + + case BSTP_INFO_RECIEVED: + if (bp == rbp) { + /* + * root priority is derived from this + * port, make it the root port. + */ + bstp_set_port_role(bp, BSTP_ROLE_ROOT); + bs->bs_root_port = bp; + } else if (bstp_info_cmp(&bp->bp_port_pv, + &bp->bp_desg_pv) == INFO_BETTER) { + /* + * the port priority is lower than the root + * port. + */ + bstp_set_port_role(bp, BSTP_ROLE_DESIGNATED); + bstp_update_info(bp); + } else { + if (bstp_same_bridgeid( + bp->bp_port_pv.pv_dbridge_id, + bs->bs_bridge_pv.pv_dbridge_id)) { + /* + * the designated bridge refers to + * another port on this bridge. + */ + bstp_set_port_role(bp, + BSTP_ROLE_BACKUP); + } else { + /* + * the port is an inferior path to the + * root bridge. + */ + bstp_set_port_role(bp, + BSTP_ROLE_ALTERNATE); + } + } + break; + } + } +} + +static void +bstp_update_state(struct bstp_state *bs, struct bstp_port *bp) +{ + struct bstp_port *bp2; + int synced; + + BSTP_LOCK_ASSERT(bs); + + /* check if all the ports have syncronised again */ + if (!bs->bs_allsynced) { + synced = 1; + LIST_FOREACH(bp2, &bs->bs_bplist, bp_next) { + if (!(bp->bp_synced || + bp->bp_role == BSTP_ROLE_ROOT)) { + synced = 0; + break; + } + } + bs->bs_allsynced = synced; + } + + bstp_update_roles(bs, bp); + bstp_update_tc(bp); +} + +static void +bstp_update_roles(struct bstp_state *bs, struct bstp_port *bp) +{ + switch (bp->bp_role) { + case BSTP_ROLE_DISABLED: + /* Clear any flags if set */ + if (bp->bp_sync || !bp->bp_synced || bp->bp_reroot) { + bp->bp_sync = 0; + bp->bp_synced = 1; + bp->bp_reroot = 0; + } + break; + + case BSTP_ROLE_ALTERNATE: + case BSTP_ROLE_BACKUP: + if ((bs->bs_allsynced && !bp->bp_agree) || + (bp->bp_proposed && bp->bp_agree)) { + bp->bp_proposed = 0; + bp->bp_agree = 1; + bp->bp_flags |= BSTP_PORT_NEWINFO; + DPRINTF("%s -> ALTERNATE_AGREED\n", + bp->bp_ifp->if_xname); + } + + if (bp->bp_proposed && !bp->bp_agree) { + bstp_set_all_sync(bs); + bp->bp_proposed = 0; + DPRINTF("%s -> ALTERNATE_PROPOSED\n", + bp->bp_ifp->if_xname); + } + + /* Clear any flags if set */ + if (bp->bp_sync || !bp->bp_synced || bp->bp_reroot) { + bp->bp_sync = 0; + bp->bp_synced = 1; + bp->bp_reroot = 0; + DPRINTF("%s -> ALTERNATE_PORT\n", bp->bp_ifp->if_xname); + } + break; + + case BSTP_ROLE_ROOT: + if (bp->bp_state != BSTP_IFSTATE_FORWARDING && !bp->bp_reroot) { + bstp_set_all_reroot(bs); + DPRINTF("%s -> ROOT_REROOT\n", bp->bp_ifp->if_xname); + } + + if ((bs->bs_allsynced && !bp->bp_agree) || + (bp->bp_proposed && bp->bp_agree)) { + bp->bp_proposed = 0; + bp->bp_sync = 0; + bp->bp_agree = 1; + bp->bp_flags |= BSTP_PORT_NEWINFO; + DPRINTF("%s -> ROOT_AGREED\n", bp->bp_ifp->if_xname); + } + + if (bp->bp_proposed && !bp->bp_agree) { + bstp_set_all_sync(bs); + bp->bp_proposed = 0; + DPRINTF("%s -> ROOT_PROPOSED\n", bp->bp_ifp->if_xname); + } + + if (bp->bp_forward_delay_timer.active == 0 || + (bstp_rerooted(bs, bp) && + bp->bp_recent_backup_timer.active == 0 && + bp->bp_protover == BSTP_PROTO_RSTP)) { + switch (bp->bp_state) { + case BSTP_IFSTATE_DISCARDING: + bstp_set_port_state(bp, BSTP_IFSTATE_LEARNING); + break; + case BSTP_IFSTATE_LEARNING: + bstp_set_port_state(bp, + BSTP_IFSTATE_FORWARDING); + break; + } + } + + if (bp->bp_state == BSTP_IFSTATE_FORWARDING && bp->bp_reroot) { + bp->bp_reroot = 0; + DPRINTF("%s -> ROOT_REROOTED\n", bp->bp_ifp->if_xname); + } + break; + + case BSTP_ROLE_DESIGNATED: + if (bp->bp_recent_root_timer.active == 0 && bp->bp_reroot) { + bp->bp_reroot = 0; + DPRINTF("%s -> DESIGNATED_RETIRED\n", + bp->bp_ifp->if_xname); + } + + if ((bp->bp_state == BSTP_IFSTATE_DISCARDING && + !bp->bp_synced) || (bp->bp_agreed && !bp->bp_synced) || + (bp->bp_operedge && !bp->bp_synced) || + (bp->bp_sync && bp->bp_synced)) { + bstp_timer_stop(&bp->bp_recent_root_timer); + bp->bp_synced = 1; + bp->bp_sync = 0; + DPRINTF("%s -> DESIGNATED_SYNCED\n", + bp->bp_ifp->if_xname); + } + + if (bp->bp_state != BSTP_IFSTATE_FORWARDING && + !bp->bp_agreed && !bp->bp_proposing && + !bp->bp_operedge) { + bp->bp_proposing = 1; + bp->bp_flags |= BSTP_PORT_NEWINFO; + bstp_timer_start(&bp->bp_edge_delay_timer, + (bp->bp_p2p_link ? BSTP_DEFAULT_MIGRATE_DELAY : + bp->bp_desg_max_age)); + DPRINTF("%s -> DESIGNATED_PROPOSE\n", + bp->bp_ifp->if_xname); + } + + if ((bp->bp_forward_delay_timer.active == 0 || bp->bp_agreed || + bp->bp_operedge) && + (bp->bp_recent_root_timer.active == 0 || !bp->bp_reroot) && + !bp->bp_sync) { + switch (bp->bp_state) { + case BSTP_IFSTATE_DISCARDING: + bstp_set_port_state(bp, BSTP_IFSTATE_LEARNING); + break; + case BSTP_IFSTATE_LEARNING: + bstp_set_port_state(bp, BSTP_IFSTATE_FORWARDING); + bp->bp_agreed = bp->bp_protover; + break; + } + } + + if (((bp->bp_sync && !bp->bp_synced) || + (bp->bp_reroot && bp->bp_recent_root_timer.active) || + (bp->bp_flags & BSTP_PORT_DISPUTED)) && !bp->bp_operedge && + bp->bp_state != BSTP_IFSTATE_DISCARDING) { + bstp_set_port_state(bp, BSTP_IFSTATE_DISCARDING); + bp->bp_flags &= ~BSTP_PORT_DISPUTED; + bstp_timer_start(&bp->bp_forward_delay_timer, + bp->bp_protover == BSTP_PROTO_RSTP ? + bp->bp_desg_htime : bp->bp_desg_fdelay); + DPRINTF("%s -> DESIGNATED_DISCARD\n", + bp->bp_ifp->if_xname); + } + break; + } + + if (bp->bp_flags & BSTP_PORT_NEWINFO) + bstp_transmit(bs, bp); +} + +static void +bstp_update_tc(struct bstp_port *bp) +{ + switch (bp->bp_tcstate) { + case BSTP_TCSTATE_ACTIVE: + if ((bp->bp_role != BSTP_ROLE_DESIGNATED && + bp->bp_role != BSTP_ROLE_ROOT) || bp->bp_operedge) + bstp_set_port_tc(bp, BSTP_TCSTATE_LEARNING); + + if (bp->bp_rcvdtcn) + bstp_set_port_tc(bp, BSTP_TCSTATE_TCN); + if (bp->bp_rcvdtc) + bstp_set_port_tc(bp, BSTP_TCSTATE_TC); + + if (bp->bp_tc_prop && !bp->bp_operedge) + bstp_set_port_tc(bp, BSTP_TCSTATE_PROPAG); + + if (bp->bp_rcvdtca) + bstp_set_port_tc(bp, BSTP_TCSTATE_ACK); + break; + + case BSTP_TCSTATE_INACTIVE: + if ((bp->bp_state == BSTP_IFSTATE_LEARNING || + bp->bp_state == BSTP_IFSTATE_FORWARDING) && + bp->bp_fdbflush == 0) + bstp_set_port_tc(bp, BSTP_TCSTATE_LEARNING); + break; + + case BSTP_TCSTATE_LEARNING: + if (bp->bp_rcvdtc || bp->bp_rcvdtcn || bp->bp_rcvdtca || + bp->bp_tc_prop) + bstp_set_port_tc(bp, BSTP_TCSTATE_LEARNING); + else if (bp->bp_role != BSTP_ROLE_DESIGNATED && + bp->bp_role != BSTP_ROLE_ROOT && + bp->bp_state == BSTP_IFSTATE_DISCARDING) + bstp_set_port_tc(bp, BSTP_TCSTATE_INACTIVE); + + if ((bp->bp_role == BSTP_ROLE_DESIGNATED || + bp->bp_role == BSTP_ROLE_ROOT) && + bp->bp_state == BSTP_IFSTATE_FORWARDING && + !bp->bp_operedge) + bstp_set_port_tc(bp, BSTP_TCSTATE_DETECTED); + break; + + /* these are transient states and go straight back to ACTIVE */ + case BSTP_TCSTATE_DETECTED: + case BSTP_TCSTATE_TCN: + case BSTP_TCSTATE_TC: + case BSTP_TCSTATE_PROPAG: + case BSTP_TCSTATE_ACK: + DPRINTF("Invalid TC state for %s\n", + bp->bp_ifp->if_xname); + break; + } + +} + +static void +bstp_update_info(struct bstp_port *bp) +{ + struct bstp_state *bs = bp->bp_bs; + + bp->bp_proposing = 0; + bp->bp_proposed = 0; + + if (bp->bp_agreed && !bstp_pdu_bettersame(bp, BSTP_INFO_MINE)) + bp->bp_agreed = 0; + + if (bp->bp_synced && !bp->bp_agreed) { + bp->bp_synced = 0; + bs->bs_allsynced = 0; + } + + /* copy the designated pv to the port */ + bp->bp_port_pv = bp->bp_desg_pv; + bp->bp_port_msg_age = bp->bp_desg_msg_age; + bp->bp_port_max_age = bp->bp_desg_max_age; + bp->bp_port_fdelay = bp->bp_desg_fdelay; + bp->bp_port_htime = bp->bp_desg_htime; + bp->bp_infois = BSTP_INFO_MINE; + + bp->bp_flags |= BSTP_PORT_NEWINFO; + bstp_transmit(bs, bp); +} + +/* set tcprop on every port other than the caller */ +static void +bstp_set_other_tcprop(struct bstp_port *bp) +{ + struct bstp_state *bs = bp->bp_bs; + struct bstp_port *bp2; + + BSTP_LOCK_ASSERT(bs); + + LIST_FOREACH(bp2, &bs->bs_bplist, bp_next) { + if (bp2 == bp) + continue; + bp->bp_tc_prop = 1; + } +} + +static void +bstp_set_all_reroot(struct bstp_state *bs) +{ + struct bstp_port *bp; + + BSTP_LOCK_ASSERT(bs); + + LIST_FOREACH(bp, &bs->bs_bplist, bp_next) + bp->bp_reroot = 1; +} + +static void +bstp_set_all_sync(struct bstp_state *bs) +{ + struct bstp_port *bp; + + BSTP_LOCK_ASSERT(bs); + + LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { + bp->bp_sync = 1; + bp->bp_synced = 0; /* Not explicit in spec */ + } + + bs->bs_allsynced = 0; +} + +static void +bstp_set_port_state(struct bstp_port *bp, int state) +{ + if (bp->bp_state == state) + return; + + bp->bp_state = state; + + switch (bp->bp_state) { + case BSTP_IFSTATE_DISCARDING: + DPRINTF("state changed to DISCARDING on %s\n", + bp->bp_ifp->if_xname); + break; + + case BSTP_IFSTATE_LEARNING: + DPRINTF("state changed to LEARNING on %s\n", + bp->bp_ifp->if_xname); + + bstp_timer_start(&bp->bp_forward_delay_timer, + bp->bp_protover == BSTP_PROTO_RSTP ? + bp->bp_desg_htime : bp->bp_desg_fdelay); + break; + + case BSTP_IFSTATE_FORWARDING: + DPRINTF("state changed to FORWARDING on %s\n", + bp->bp_ifp->if_xname); + + bstp_timer_stop(&bp->bp_forward_delay_timer); + /* Record that we enabled forwarding */ + bp->bp_forward_transitions++; + break; + } + + /* notify the parent bridge */ + taskqueue_enqueue(taskqueue_swi, &bp->bp_statetask); +} + +static void +bstp_set_port_role(struct bstp_port *bp, int role) +{ + struct bstp_state *bs = bp->bp_bs; + + if (bp->bp_role == role) + return; + + /* perform pre-change tasks */ + switch (bp->bp_role) { + case BSTP_ROLE_DISABLED: + bstp_timer_start(&bp->bp_forward_delay_timer, + bp->bp_desg_max_age); + break; + + case BSTP_ROLE_BACKUP: + bstp_timer_start(&bp->bp_recent_backup_timer, + bp->bp_desg_htime * 2); + /* fall through */ + case BSTP_ROLE_ALTERNATE: + bstp_timer_start(&bp->bp_forward_delay_timer, + bp->bp_desg_fdelay); + bp->bp_sync = 0; + bp->bp_synced = 1; + bp->bp_reroot = 0; + break; + + case BSTP_ROLE_ROOT: + bstp_timer_start(&bp->bp_recent_root_timer, + BSTP_DEFAULT_FORWARD_DELAY); + break; + } + + bp->bp_role = role; + /* clear values not carried between roles */ + bp->bp_proposing = 0; + bs->bs_allsynced = 0; + + /* initialise the new role */ + switch (bp->bp_role) { + case BSTP_ROLE_DISABLED: + case BSTP_ROLE_ALTERNATE: + case BSTP_ROLE_BACKUP: + DPRINTF("%s role -> ALT/BACK/DISABLED\n", + bp->bp_ifp->if_xname); + bstp_set_port_state(bp, BSTP_IFSTATE_DISCARDING); + bstp_timer_stop(&bp->bp_recent_root_timer); + bstp_timer_latch(&bp->bp_forward_delay_timer); + bp->bp_sync = 0; + bp->bp_synced = 1; + bp->bp_reroot = 0; + break; + + case BSTP_ROLE_ROOT: + DPRINTF("%s role -> ROOT\n", + bp->bp_ifp->if_xname); + bstp_set_port_state(bp, BSTP_IFSTATE_DISCARDING); + bstp_timer_latch(&bp->bp_recent_root_timer); + bp->bp_proposing = 0; + break; + + case BSTP_ROLE_DESIGNATED: + DPRINTF("%s role -> DESIGNATED\n", + bp->bp_ifp->if_xname); + bstp_timer_start(&bp->bp_hello_timer, + bp->bp_desg_htime); + bp->bp_agree = 0; + break; + } + + /* let the TC state know that the role changed */ + bstp_update_tc(bp); +} + +static void +bstp_set_port_proto(struct bstp_port *bp, int proto) +{ + struct bstp_state *bs = bp->bp_bs; + + /* supported protocol versions */ + switch (proto) { + case BSTP_PROTO_STP: + /* we can downgrade protocols only */ + bstp_timer_stop(&bp->bp_migrate_delay_timer); + /* clear unsupported features */ + bp->bp_operedge = 0; + break; + + case BSTP_PROTO_RSTP: + bstp_timer_start(&bp->bp_migrate_delay_timer, + bs->bs_migration_delay); + break; + + default: + DPRINTF("Unsupported STP version %d\n", proto); + return; + } + + bp->bp_protover = proto; + bp->bp_flags &= ~BSTP_PORT_CANMIGRATE; +} + +static void +bstp_set_port_tc(struct bstp_port *bp, int state) +{ + struct bstp_state *bs = bp->bp_bs; + + bp->bp_tcstate = state; + + /* initialise the new state */ + switch (bp->bp_tcstate) { + case BSTP_TCSTATE_ACTIVE: + DPRINTF("%s -> TC_ACTIVE\n", bp->bp_ifp->if_xname); + /* nothing to do */ + break; + + case BSTP_TCSTATE_INACTIVE: + bstp_timer_stop(&bp->bp_tc_timer); + /* flush routes on the parent bridge */ + bp->bp_fdbflush = 1; + taskqueue_enqueue(taskqueue_swi, &bp->bp_rtagetask); + bp->bp_tc_ack = 0; + DPRINTF("%s -> TC_INACTIVE\n", bp->bp_ifp->if_xname); + break; + + case BSTP_TCSTATE_LEARNING: + bp->bp_rcvdtc = 0; + bp->bp_rcvdtcn = 0; + bp->bp_rcvdtca = 0; + bp->bp_tc_prop = 0; + DPRINTF("%s -> TC_LEARNING\n", bp->bp_ifp->if_xname); + break; + + case BSTP_TCSTATE_DETECTED: + bstp_set_timer_tc(bp); + bstp_set_other_tcprop(bp); + /* send out notification */ + bp->bp_flags |= BSTP_PORT_NEWINFO; + bstp_transmit(bs, bp); + getmicrotime(&bs->bs_last_tc_time); + DPRINTF("%s -> TC_DETECTED\n", bp->bp_ifp->if_xname); + bp->bp_tcstate = BSTP_TCSTATE_ACTIVE; /* UCT */ + break; + + case BSTP_TCSTATE_TCN: + bstp_set_timer_tc(bp); + DPRINTF("%s -> TC_TCN\n", bp->bp_ifp->if_xname); + /* fall through */ + case BSTP_TCSTATE_TC: + bp->bp_rcvdtc = 0; + bp->bp_rcvdtcn = 0; + if (bp->bp_role == BSTP_ROLE_DESIGNATED) + bp->bp_tc_ack = 1; + + bstp_set_other_tcprop(bp); + DPRINTF("%s -> TC_TC\n", bp->bp_ifp->if_xname); + bp->bp_tcstate = BSTP_TCSTATE_ACTIVE; /* UCT */ + break; + + case BSTP_TCSTATE_PROPAG: + /* flush routes on the parent bridge */ + bp->bp_fdbflush = 1; + taskqueue_enqueue(taskqueue_swi, &bp->bp_rtagetask); + bp->bp_tc_prop = 0; + bstp_set_timer_tc(bp); + DPRINTF("%s -> TC_PROPAG\n", bp->bp_ifp->if_xname); + bp->bp_tcstate = BSTP_TCSTATE_ACTIVE; /* UCT */ + break; + + case BSTP_TCSTATE_ACK: + bstp_timer_stop(&bp->bp_tc_timer); + bp->bp_rcvdtca = 0; + DPRINTF("%s -> TC_ACK\n", bp->bp_ifp->if_xname); + bp->bp_tcstate = BSTP_TCSTATE_ACTIVE; /* UCT */ + break; + } +} + +static void +bstp_set_timer_tc(struct bstp_port *bp) +{ + struct bstp_state *bs = bp->bp_bs; + + if (bp->bp_tc_timer.active) + return; + + switch (bp->bp_protover) { + case BSTP_PROTO_RSTP: + bstp_timer_start(&bp->bp_tc_timer, + bp->bp_desg_htime + BSTP_TICK_VAL); + bp->bp_flags |= BSTP_PORT_NEWINFO; + break; + + case BSTP_PROTO_STP: + bstp_timer_start(&bp->bp_tc_timer, + bs->bs_root_max_age + bs->bs_root_fdelay); + break; + } +} + +static void +bstp_set_timer_msgage(struct bstp_port *bp) +{ + if (bp->bp_port_msg_age + BSTP_MESSAGE_AGE_INCR <= + bp->bp_port_max_age) { + bstp_timer_start(&bp->bp_message_age_timer, + bp->bp_port_htime * 3); + } else + /* expires immediately */ + bstp_timer_start(&bp->bp_message_age_timer, 0); +} + +static int +bstp_rerooted(struct bstp_state *bs, struct bstp_port *bp) +{ + struct bstp_port *bp2; + int rr_set = 0; + + LIST_FOREACH(bp2, &bs->bs_bplist, bp_next) { + if (bp2 == bp) + continue; + if (bp2->bp_recent_root_timer.active) { + rr_set = 1; + break; + } + } + return (!rr_set); +} + +int +bstp_set_htime(struct bstp_state *bs, int t) +{ + /* convert seconds to ticks */ + t *= BSTP_TICK_VAL; + + /* value can only be changed in leagacy stp mode */ + if (bs->bs_protover != BSTP_PROTO_STP) + return (EINVAL); + + if (t < BSTP_MIN_HELLO_TIME || t > BSTP_MAX_HELLO_TIME) + return (EINVAL); + + BSTP_LOCK(bs); + bs->bs_bridge_htime = t; + bstp_reinit(bs); + BSTP_UNLOCK(bs); + return (0); +} + +int +bstp_set_fdelay(struct bstp_state *bs, int t) +{ + /* convert seconds to ticks */ + t *= BSTP_TICK_VAL; + + if (t < BSTP_MIN_FORWARD_DELAY || t > BSTP_MAX_FORWARD_DELAY) + return (EINVAL); + + BSTP_LOCK(bs); + bs->bs_bridge_fdelay = t; + bstp_reinit(bs); + BSTP_UNLOCK(bs); + return (0); +} + +int +bstp_set_maxage(struct bstp_state *bs, int t) +{ + /* convert seconds to ticks */ + t *= BSTP_TICK_VAL; + + if (t < BSTP_MIN_MAX_AGE || t > BSTP_MAX_MAX_AGE) + return (EINVAL); + + BSTP_LOCK(bs); + bs->bs_bridge_max_age = t; + bstp_reinit(bs); + BSTP_UNLOCK(bs); + return (0); +} + +int +bstp_set_holdcount(struct bstp_state *bs, int count) +{ + struct bstp_port *bp; + + if (count < BSTP_MIN_HOLD_COUNT || + count > BSTP_MAX_HOLD_COUNT) + return (EINVAL); + + BSTP_LOCK(bs); + bs->bs_txholdcount = count; + LIST_FOREACH(bp, &bs->bs_bplist, bp_next) + bp->bp_txcount = 0; + BSTP_UNLOCK(bs); + return (0); +} + +int +bstp_set_protocol(struct bstp_state *bs, int proto) +{ + struct bstp_port *bp; + + switch (proto) { + /* Supported protocol versions */ + case BSTP_PROTO_STP: + case BSTP_PROTO_RSTP: + break; + + default: + return (EINVAL); + } + + BSTP_LOCK(bs); + bs->bs_protover = proto; + bs->bs_bridge_htime = BSTP_DEFAULT_HELLO_TIME; + LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { + /* reinit state */ + bp->bp_infois = BSTP_INFO_DISABLED; + bp->bp_txcount = 0; + bstp_set_port_proto(bp, bs->bs_protover); + bstp_set_port_role(bp, BSTP_ROLE_DISABLED); + bstp_set_port_tc(bp, BSTP_TCSTATE_INACTIVE); + bstp_timer_stop(&bp->bp_recent_backup_timer); + } + bstp_reinit(bs); + BSTP_UNLOCK(bs); + return (0); +} + +int +bstp_set_priority(struct bstp_state *bs, int pri) +{ + if (pri < 0 || pri > BSTP_MAX_PRIORITY) + return (EINVAL); + + /* Limit to steps of 4096 */ + pri -= pri % 4096; + + BSTP_LOCK(bs); + bs->bs_bridge_priority = pri; + bstp_reinit(bs); + BSTP_UNLOCK(bs); + return (0); +} + +int +bstp_set_port_priority(struct bstp_port *bp, int pri) +{ + struct bstp_state *bs = bp->bp_bs; + + if (pri < 0 || pri > BSTP_MAX_PORT_PRIORITY) + return (EINVAL); + + /* Limit to steps of 16 */ + pri -= pri % 16; + + BSTP_LOCK(bs); + bp->bp_priority = pri; + bstp_reinit(bs); + BSTP_UNLOCK(bs); + return (0); +} + +int +bstp_set_path_cost(struct bstp_port *bp, uint32_t path_cost) +{ + struct bstp_state *bs = bp->bp_bs; + + if (path_cost > BSTP_MAX_PATH_COST) + return (EINVAL); + + BSTP_LOCK(bs); + + if (path_cost == 0) { /* use auto */ + bp->bp_flags &= ~BSTP_PORT_ADMCOST; + bp->bp_path_cost = bstp_calc_path_cost(bp); + } else { + bp->bp_path_cost = path_cost; + bp->bp_flags |= BSTP_PORT_ADMCOST; + } + bstp_reinit(bs); + BSTP_UNLOCK(bs); + return (0); +} + +/* + * Calculate the path cost according to the link speed. + */ +static uint32_t +bstp_calc_path_cost(struct bstp_port *bp) +{ + struct ifnet *ifp = bp->bp_ifp; + uint32_t path_cost; + + /* If the priority has been manually set then retain the value */ + if (bp->bp_flags & BSTP_PORT_ADMCOST) + return bp->bp_path_cost; + + if (ifp->if_baudrate < 1000) + return (BSTP_DEFAULT_PATH_COST); + + /* formula from section 17.14, IEEE Std 802.1D-2004 */ + path_cost = 20000000000 / (ifp->if_baudrate / 1000); + + if (path_cost > BSTP_MAX_PATH_COST) + path_cost = BSTP_MAX_PATH_COST; + + /* STP compat mode only uses 16 bits of the 32 */ + if (bp->bp_protover == BSTP_PROTO_STP && path_cost > 65535) + path_cost = 65535; + + return (path_cost); +} + +/* + * Notify the bridge that a port state has changed, we need to do this from a + * taskqueue to avoid a LOR. + */ +static void +bstp_notify_state(void *arg, int pending) +{ + struct bstp_port *bp = (struct bstp_port *)arg; + struct bstp_state *bs = bp->bp_bs; + + if (bp->bp_active == 1 && bs->bs_state_cb != NULL) + (*bs->bs_state_cb)(bp->bp_ifp, bp->bp_state); +} + +/* + * Flush the routes on the bridge port, we need to do this from a + * taskqueue to avoid a LOR. + */ +static void +bstp_notify_rtage(void *arg, int pending) +{ + struct bstp_port *bp = (struct bstp_port *)arg; + struct bstp_state *bs = bp->bp_bs; + int age = 0; + + BSTP_LOCK(bs); + switch (bp->bp_protover) { + case BSTP_PROTO_STP: + /* convert to seconds */ + age = bp->bp_desg_fdelay / BSTP_TICK_VAL; + break; + + case BSTP_PROTO_RSTP: + age = 0; + break; + } + BSTP_UNLOCK(bs); + + if (bp->bp_active == 1 && bs->bs_rtage_cb != NULL) + (*bs->bs_rtage_cb)(bp->bp_ifp, age); + + /* flush is complete */ + BSTP_LOCK(bs); + bp->bp_fdbflush = 0; + BSTP_UNLOCK(bs); +} + +void +bstp_linkstate(struct ifnet *ifp, int state) +{ + struct bstp_state *bs; + struct bstp_port *bp; + + /* search for the stp port */ + mtx_lock(&bstp_list_mtx); + LIST_FOREACH(bs, &bstp_list, bs_list) { + BSTP_LOCK(bs); + LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { + if (bp->bp_ifp == ifp) { + bstp_ifupdstatus(bs, bp); + /* it only exists once so return */ + BSTP_UNLOCK(bs); + mtx_unlock(&bstp_list_mtx); + return; + } + } + BSTP_UNLOCK(bs); + } + mtx_unlock(&bstp_list_mtx); +} + +static void +bstp_ifupdstatus(struct bstp_state *bs, struct bstp_port *bp) +{ + struct ifnet *ifp = bp->bp_ifp; + struct ifmediareq ifmr; + int error = 0; + + BSTP_LOCK_ASSERT(bs); + + bzero((char *)&ifmr, sizeof(ifmr)); + error = (*ifp->if_ioctl)(ifp, SIOCGIFMEDIA, (caddr_t)&ifmr); + + if ((error == 0) && (ifp->if_flags & IFF_UP)) { + if (ifmr.ifm_status & IFM_ACTIVE) { + /* A full-duplex link is assumed to be point to point */ + bp->bp_p2p_link = ifmr.ifm_active & IFM_FDX ? 1 : 0; + + if (bp->bp_role == BSTP_ROLE_DISABLED) + bstp_enable_port(bs, bp); + } else { + if (bp->bp_role != BSTP_ROLE_DISABLED) + bstp_disable_port(bs, bp); + } + return; + } + + if (bp->bp_infois != BSTP_INFO_DISABLED) + bstp_disable_port(bs, bp); +} + +static void +bstp_enable_port(struct bstp_state *bs, struct bstp_port *bp) +{ + bp->bp_infois = BSTP_INFO_AGED; + bstp_assign_roles(bs); +} + +static void +bstp_disable_port(struct bstp_state *bs, struct bstp_port *bp) +{ + bp->bp_infois = BSTP_INFO_DISABLED; + bstp_set_port_state(bp, BSTP_IFSTATE_DISCARDING); + bstp_assign_roles(bs); +} + +static void +bstp_tick(void *arg) { - int root; + struct bstp_state *bs = arg; + struct bstp_port *bp; BSTP_LOCK_ASSERT(bs); - root = bstp_root_bridge(bs); + /* slow timer to catch missed link events */ + if (bstp_timer_expired(&bs->bs_link_timer)) { + LIST_FOREACH(bp, &bs->bs_bplist, bp_next) + bstp_ifupdstatus(bs, bp); + bstp_timer_start(&bs->bs_link_timer, BSTP_LINK_TIMER); + } - if (bp->bp_state != BSTP_IFSTATE_DISABLED) { - if (bstp_supersedes_port_info(bs, bp, cu)) { - bstp_record_config_information(bs, bp, cu); - bstp_configuration_update(bs); - bstp_port_state_selection(bs); - - if ((bstp_root_bridge(bs) == 0) && root) { - bstp_timer_stop(&bs->bs_hello_timer); - - if (bs->bs_topology_change_detected) { - bstp_timer_stop( - &bs->bs_topology_change_timer); - bstp_transmit_tcn(bs); - bstp_timer_start(&bs->bs_tcn_timer, 0); - } - } + LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { + /* no events need to happen for these */ + bstp_timer_expired(&bp->bp_tc_timer); + bstp_timer_expired(&bp->bp_recent_root_timer); + bstp_timer_expired(&bp->bp_forward_delay_timer); + bstp_timer_expired(&bp->bp_recent_backup_timer); - if (bp == bs->bs_root_port) { - bstp_record_config_timeout_values(bs, cu); - bstp_config_bpdu_generation(bs); + if (bstp_timer_expired(&bp->bp_hello_timer)) + bstp_hello_timer_expiry(bs, bp); - if (cu->cu_topology_change_acknowledgment) - bstp_topology_change_acknowledged(bs); - } - } else if (bstp_designated_port(bs, bp)) - bstp_transmit_config(bs, bp); - } -} + if (bstp_timer_expired(&bp->bp_message_age_timer)) + bstp_message_age_expiry(bs, bp); -static void -bstp_received_tcn_bpdu(struct bstp_state *bs, struct bstp_port *bp, - struct bstp_tcn_unit *tcn) -{ - if (bp->bp_state != BSTP_IFSTATE_DISABLED && - bstp_designated_port(bs, bp)) { - bstp_topology_change_detection(bs); - bstp_acknowledge_topology_change(bs, bp); + if (bstp_timer_expired(&bp->bp_migrate_delay_timer)) + bstp_migrate_delay_expiry(bs, bp); + + if (bstp_timer_expired(&bp->bp_edge_delay_timer)) + bstp_edge_delay_expiry(bs, bp); + + /* update the various state machines for the port */ + bstp_update_state(bs, bp); + + if (bp->bp_txcount > 0) + bp->bp_txcount--; } + + callout_reset(&bs->bs_bstpcallout, hz, bstp_tick, bs); } static void -bstp_hello_timer_expiry(struct bstp_state *bs) +bstp_timer_start(struct bstp_timer *t, uint16_t v) { - bstp_config_bpdu_generation(bs); - bstp_timer_start(&bs->bs_hello_timer, 0); + t->value = v; + t->active = 1; + t->latched = 0; } static void -bstp_message_age_timer_expiry(struct bstp_state *bs, - struct bstp_port *bp) +bstp_timer_stop(struct bstp_timer *t) { - int root; - - BSTP_LOCK_ASSERT(bs); - - root = bstp_root_bridge(bs); - bstp_become_designated_port(bs, bp); - bstp_configuration_update(bs); - bstp_port_state_selection(bs); - - if ((bstp_root_bridge(bs)) && (root == 0)) { - bs->bs_max_age = bs->bs_bridge_max_age; - bs->bs_hello_time = bs->bs_bridge_hello_time; - bs->bs_forward_delay = bs->bs_bridge_forward_delay; - - bstp_topology_change_detection(bs); - bstp_timer_stop(&bs->bs_tcn_timer); - bstp_config_bpdu_generation(bs); - bstp_timer_start(&bs->bs_hello_timer, 0); - } + t->value = 0; + t->active = 0; + t->latched = 0; } static void -bstp_forward_delay_timer_expiry(struct bstp_state *bs, - struct bstp_port *bp) -{ - if (bp->bp_state == BSTP_IFSTATE_LISTENING) { - bstp_set_port_state(bp, BSTP_IFSTATE_LEARNING); - bstp_timer_start(&bp->bp_forward_delay_timer, 0); - } else if (bp->bp_state == BSTP_IFSTATE_LEARNING) { - bstp_set_port_state(bp, BSTP_IFSTATE_FORWARDING); - bstp_update_forward_transitions(bp); - if (bstp_designated_for_some_port(bs) && - bp->bp_change_detection_enabled) - bstp_topology_change_detection(bs); - } +bstp_timer_latch(struct bstp_timer *t) +{ + t->latched = 1; + t->active = 1; } static int -bstp_designated_for_some_port(struct bstp_state *bs) +bstp_timer_expired(struct bstp_timer *t) { - - struct bstp_port *bp; - - BSTP_LOCK_ASSERT(bs); - - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - if (bp->bp_designated_bridge == bs->bs_bridge_id) - return (1); + if (t->active == 0 || t->latched) + return (0); + t->value -= BSTP_TICK_VAL; + if (t->value <= 0) { + bstp_timer_stop(t); + return (1); } return (0); + } static void -bstp_tcn_timer_expiry(struct bstp_state *bs) +bstp_hello_timer_expiry(struct bstp_state *bs, struct bstp_port *bp) { - BSTP_LOCK_ASSERT(bs); - - bstp_transmit_tcn(bs); - bstp_timer_start(&bs->bs_tcn_timer, 0); + if ((bp->bp_flags & BSTP_PORT_NEWINFO) || + bp->bp_role == BSTP_ROLE_DESIGNATED || + (bp->bp_role == BSTP_ROLE_ROOT && + bp->bp_tc_timer.active == 1)) { + bstp_timer_start(&bp->bp_hello_timer, bp->bp_desg_htime); + bp->bp_flags |= BSTP_PORT_NEWINFO; + bstp_transmit(bs, bp); + } } static void -bstp_topology_change_timer_expiry(struct bstp_state *bs) +bstp_message_age_expiry(struct bstp_state *bs, struct bstp_port *bp) { - BSTP_LOCK_ASSERT(bs); + if (bp->bp_infois == BSTP_INFO_RECIEVED) { + bp->bp_infois = BSTP_INFO_AGED; + bstp_assign_roles(bs); + DPRINTF("aged info on %s\n", bp->bp_ifp->if_xname); + } +} - bs->bs_topology_change_detected = 0; - bs->bs_topology_change = 0; +static void +bstp_migrate_delay_expiry(struct bstp_state *bs, struct bstp_port *bp) +{ + bp->bp_flags |= BSTP_PORT_CANMIGRATE; } static void -bstp_hold_timer_expiry(struct bstp_state *bs, struct bstp_port *bp) +bstp_edge_delay_expiry(struct bstp_state *bs, struct bstp_port *bp) { - if (bp->bp_config_pending) - bstp_transmit_config(bs, bp); + if (bp->bp_protover == BSTP_PROTO_RSTP && bp->bp_proposing && + bp->bp_role == BSTP_ROLE_DESIGNATED) + bp->bp_operedge = 1; } static int @@ -832,18 +1899,36 @@ bstp_addr_cmp(const uint8_t *a, const ui return (d); } +/* + * compare the bridge address component of the bridgeid + */ +static int +bstp_same_bridgeid(uint64_t id1, uint64_t id2) +{ + u_char addr1[ETHER_ADDR_LEN]; + u_char addr2[ETHER_ADDR_LEN]; + + PV2ADDR(id1, addr1); + PV2ADDR(id2, addr2); + + if (bstp_addr_cmp(addr1, addr2) == 0) { + return (1); + } + return (0); +} + void bstp_reinit(struct bstp_state *bs) { struct bstp_port *bp, *mbp; u_char *e_addr; - BSTP_LOCK(bs); + BSTP_LOCK_ASSERT(bs); mbp = NULL; LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { bp->bp_port_id = (bp->bp_priority << 8) | - (bp->bp_ifp->if_index & 0xff); + (bp->bp_ifp->if_index & 0xfff); if (mbp == NULL) { mbp = bp; @@ -856,13 +1941,12 @@ bstp_reinit(struct bstp_state *bs) } } if (mbp == NULL) { - BSTP_UNLOCK(bs); - bstp_stop(bs); + bstp_stop_locked(bs); return; } e_addr = IF_LLADDR(mbp->bp_ifp); - bs->bs_bridge_id = + bs->bs_bridge_pv.pv_dbridge_id = (((uint64_t)bs->bs_bridge_priority) << 48) | (((uint64_t)e_addr[0]) << 40) | (((uint64_t)e_addr[1]) << 32) | @@ -871,17 +1955,10 @@ bstp_reinit(struct bstp_state *bs) (((uint64_t)e_addr[4]) << 8) | (((uint64_t)e_addr[5])); - bs->bs_designated_root = bs->bs_bridge_id; - bs->bs_root_path_cost = 0; - bs->bs_root_port = NULL; - - bs->bs_max_age = bs->bs_bridge_max_age; - bs->bs_hello_time = bs->bs_bridge_hello_time; - bs->bs_forward_delay = bs->bs_bridge_forward_delay; - bs->bs_topology_change_detected = 0; - bs->bs_topology_change = 0; - bstp_timer_stop(&bs->bs_tcn_timer); - bstp_timer_stop(&bs->bs_topology_change_timer); + bs->bs_bridge_pv.pv_root_id = bs->bs_bridge_pv.pv_dbridge_id; + bs->bs_bridge_pv.pv_cost = 0; + bs->bs_bridge_pv.pv_dport_id = 0; + bs->bs_bridge_pv.pv_port_id = 0; if (callout_pending(&bs->bs_bstpcallout) == 0) callout_reset(&bs->bs_bstpcallout, hz, @@ -891,11 +1968,8 @@ bstp_reinit(struct bstp_state *bs) bstp_ifupdstatus(bs, bp); getmicrotime(&bs->bs_last_tc_time); - bstp_port_state_selection(bs); - bstp_config_bpdu_generation(bs); - bstp_timer_start(&bs->bs_hello_timer, 0); - bstp_timer_start(&bs->bs_link_timer, 0); - BSTP_UNLOCK(bs); + bstp_assign_roles(bs); + bstp_timer_start(&bs->bs_link_timer, BSTP_LINK_TIMER); } static int @@ -927,18 +2001,25 @@ DECLARE_MODULE(bridgestp, bstp_mod, SI_S MODULE_VERSION(bridgestp, 1); void -bstp_attach(struct bstp_state *bs, bstp_state_cb_t state_callback) +bstp_attach(struct bstp_state *bs, bstp_state_cb_t state_callback, + bstp_rtage_cb_t rtage_callback) { BSTP_LOCK_INIT(bs); callout_init_mtx(&bs->bs_bstpcallout, &bs->bs_mtx, 0); LIST_INIT(&bs->bs_bplist); bs->bs_bridge_max_age = BSTP_DEFAULT_MAX_AGE; - bs->bs_bridge_hello_time = BSTP_DEFAULT_HELLO_TIME; - bs->bs_bridge_forward_delay = BSTP_DEFAULT_FORWARD_DELAY; + bs->bs_bridge_htime = BSTP_DEFAULT_HELLO_TIME; + bs->bs_bridge_fdelay = BSTP_DEFAULT_FORWARD_DELAY; bs->bs_bridge_priority = BSTP_DEFAULT_BRIDGE_PRIORITY; bs->bs_hold_time = BSTP_DEFAULT_HOLD_TIME; + bs->bs_migration_delay = BSTP_DEFAULT_MIGRATE_DELAY; + bs->bs_txholdcount = BSTP_DEFAULT_HOLD_COUNT; + bs->bs_protover = BSTP_PROTO_RSTP; bs->bs_state_cb = state_callback; + bs->bs_rtage_cb = rtage_callback; + + getmicrotime(&bs->bs_last_tc_time); mtx_lock(&bstp_list_mtx); LIST_INSERT_HEAD(&bstp_list, bs, bs_list); @@ -959,294 +2040,32 @@ bstp_detach(struct bstp_state *bs) void bstp_init(struct bstp_state *bs) { + BSTP_LOCK(bs); callout_reset(&bs->bs_bstpcallout, hz, bstp_tick, bs); bstp_reinit(bs); + BSTP_UNLOCK(bs); } void bstp_stop(struct bstp_state *bs) { - struct bstp_port *bp; - BSTP_LOCK(bs); - - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - bstp_set_port_state(bp, BSTP_IFSTATE_DISABLED); - bstp_timer_stop(&bp->bp_hold_timer); - bstp_timer_stop(&bp->bp_message_age_timer); - bstp_timer_stop(&bp->bp_forward_delay_timer); - } - - callout_drain(&bs->bs_bstpcallout); - callout_stop(&bs->bs_bstpcallout); - - bstp_timer_stop(&bs->bs_topology_change_timer); - bstp_timer_stop(&bs->bs_tcn_timer); - bstp_timer_stop(&bs->bs_hello_timer); - + bstp_stop_locked(bs); BSTP_UNLOCK(bs); } static void -bstp_initialize_port(struct bstp_state *bs, struct bstp_port *bp) -{ - BSTP_LOCK_ASSERT(bs); - - bstp_become_designated_port(bs, bp); - bstp_set_port_state(bp, BSTP_IFSTATE_BLOCKING); - bp->bp_topology_change_acknowledge = 0; - bp->bp_config_pending = 0; - bp->bp_change_detection_enabled = 1; - bstp_timer_stop(&bp->bp_message_age_timer); - bstp_timer_stop(&bp->bp_forward_delay_timer); - bstp_timer_stop(&bp->bp_hold_timer); -} - -static void -bstp_enable_port(struct bstp_state *bs, struct bstp_port *bp) -{ - bstp_initialize_port(bs, bp); - bstp_port_state_selection(bs); -} - -static void -bstp_disable_port(struct bstp_state *bs, struct bstp_port *bp) -{ - int root; - - BSTP_LOCK_ASSERT(bs); - - root = bstp_root_bridge(bs); - bstp_become_designated_port(bs, bp); - bstp_set_port_state(bp, BSTP_IFSTATE_DISABLED); - bp->bp_topology_change_acknowledge = 0; - bp->bp_config_pending = 0; - bstp_timer_stop(&bp->bp_message_age_timer); - bstp_timer_stop(&bp->bp_forward_delay_timer); - bstp_configuration_update(bs); - bstp_port_state_selection(bs); - - if (bstp_root_bridge(bs) && (root == 0)) { - bs->bs_max_age = bs->bs_bridge_max_age; - bs->bs_hello_time = bs->bs_bridge_hello_time; - bs->bs_forward_delay = bs->bs_bridge_forward_delay; - - bstp_topology_change_detection(bs); - bstp_timer_stop(&bs->bs_tcn_timer); - bstp_config_bpdu_generation(bs); - bstp_timer_start(&bs->bs_hello_timer, 0); - } -} - -#ifdef notused -static void -bstp_set_bridge_priority(struct bstp_state *bs, uint64_t new_bridge_id) -{ - struct bstp_port *bp; - int root; - - BSTP_LOCK_ASSERT(bs); - - root = bstp_root_bridge(bs); - - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - if (bstp_designated_port(bs, bp)) - bp->bp_designated_bridge = new_bridge_id; - } - - bs->bs_bridge_id = new_bridge_id; - - bstp_configuration_update(bs); - bstp_port_state_selection(bs); - - if (bstp_root_bridge(bs) && (root == 0)) { - bs->bs_max_age = bs->bs_bridge_max_age; - bs->bs_hello_time = bs->bs_bridge_hello_time; - bs->bs_forward_delay = bs->bs_bridge_forward_delay; - - bstp_topology_change_detection(bs); - bstp_timer_stop(&bs->bs_tcn_timer); - bstp_config_bpdu_generation(bs); - bstp_timer_start(&bs->bs_hello_timer, 0); - } -} - -static void -bstp_set_port_priority(struct bstp_state *bs, struct bstp_port *bp, - uint16_t new_port_id) -{ - if (bstp_designated_port(bs, bp)) - bp->bp_designated_port = new_port_id; - - bp->bp_port_id = new_port_id; - - if ((bs->bs_bridge_id == bp->bp_designated_bridge) && - (bp->bp_port_id < bp->bp_designated_port)) { - bstp_become_designated_port(bs, bp); - bstp_port_state_selection(bs); - } -} - -static void -bstp_set_path_cost(struct bstp_state *bs, struct bstp_port *bp, - uint32_t path_cost) -{ - bp->bp_path_cost = path_cost; - bstp_configuration_update(bs); - bstp_port_state_selection(bs); -} - -static void -bstp_enable_change_detection(struct bstp_port *bp) -{ - bp->bp_change_detection_enabled = 1; -} - -static void -bstp_disable_change_detection(struct bstp_port *bp) -{ - bp->bp_change_detection_enabled = 0; -} -#endif /* notused */ - -static void -bstp_enqueue(struct ifnet *dst_ifp, struct mbuf *m) -{ - int err = 0; - - IFQ_ENQUEUE(&dst_ifp->if_snd, m, err); - - if ((dst_ifp->if_drv_flags & IFF_DRV_OACTIVE) == 0) - (*dst_ifp->if_start)(dst_ifp); -} - -void -bstp_linkstate(struct ifnet *ifp, int state) -{ - struct bstp_state *bs; - struct bstp_port *bp; - - /* - * It would be nice if the ifnet had a pointer to the bstp_port so we - * didnt need to search for it, but that may be an overkill. In reality - * this is fast and doesnt get called often. - */ - mtx_lock(&bstp_list_mtx); - LIST_FOREACH(bs, &bstp_list, bs_list) { - BSTP_LOCK(bs); - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - if (bp->bp_ifp == ifp) { - bstp_ifupdstatus(bs, bp); - /* it only exists once so return */ - BSTP_UNLOCK(bs); - mtx_unlock(&bstp_list_mtx); - return; - } - } - BSTP_UNLOCK(bs); - } - mtx_unlock(&bstp_list_mtx); -} - -static void -bstp_ifupdstatus(struct bstp_state *bs, struct bstp_port *bp) -{ - struct ifnet *ifp = bp->bp_ifp; - struct ifmediareq ifmr; - int error = 0; - - BSTP_LOCK_ASSERT(bs); - - bzero((char *)&ifmr, sizeof(ifmr)); - error = (*ifp->if_ioctl)(ifp, SIOCGIFMEDIA, (caddr_t)&ifmr); - - if ((error == 0) && (ifp->if_flags & IFF_UP)) { - if (ifmr.ifm_status & IFM_ACTIVE) { - if (bp->bp_state == BSTP_IFSTATE_DISABLED) - bstp_enable_port(bs, bp); - - } else { - if (bp->bp_state != BSTP_IFSTATE_DISABLED) - bstp_disable_port(bs, bp); - } - return; - } - - if (bp->bp_state != BSTP_IFSTATE_DISABLED) - bstp_disable_port(bs, bp); -} - -static void -bstp_tick(void *arg) +bstp_stop_locked(struct bstp_state *bs) { - struct bstp_state *bs = arg; struct bstp_port *bp; BSTP_LOCK_ASSERT(bs); - /* slow timer to catch missed link events */ - if (bstp_timer_expired(&bs->bs_link_timer, BSTP_LINK_TIMER)) { - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - bstp_ifupdstatus(bs, bp); - } - bstp_timer_start(&bs->bs_link_timer, 0); - } - - if (bstp_timer_expired(&bs->bs_hello_timer, bs->bs_hello_time)) - bstp_hello_timer_expiry(bs); - - if (bstp_timer_expired(&bs->bs_tcn_timer, bs->bs_bridge_hello_time)) - bstp_tcn_timer_expiry(bs); - - if (bstp_timer_expired(&bs->bs_topology_change_timer, - bs->bs_topology_change_time)) - bstp_topology_change_timer_expiry(bs); - - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - if (bstp_timer_expired(&bp->bp_message_age_timer, - bs->bs_max_age)) - bstp_message_age_timer_expiry(bs, bp); - } - - LIST_FOREACH(bp, &bs->bs_bplist, bp_next) { - if (bstp_timer_expired(&bp->bp_forward_delay_timer, - bs->bs_forward_delay)) - bstp_forward_delay_timer_expiry(bs, bp); - - if (bstp_timer_expired(&bp->bp_hold_timer, - bs->bs_hold_time)) - bstp_hold_timer_expiry(bs, bp); - } - - callout_reset(&bs->bs_bstpcallout, hz, bstp_tick, bs); -} - -static void -bstp_timer_start(struct bstp_timer *t, uint16_t v) -{ - t->value = v; - t->active = 1; -} - -static void -bstp_timer_stop(struct bstp_timer *t) -{ - t->value = 0; - t->active = 0; -} - -static int -bstp_timer_expired(struct bstp_timer *t, uint16_t v) -{ - if (t->active == 0) - return (0); - t->value += BSTP_TICK_VAL; - if (t->value >= v) { - bstp_timer_stop(t); - return (1); - } - return (0); + LIST_FOREACH(bp, &bs->bs_bplist, bp_next) + bstp_set_port_state(bp, BSTP_IFSTATE_DISCARDING); + callout_drain(&bs->bs_bstpcallout); + callout_stop(&bs->bs_bstpcallout); } int @@ -1262,18 +2081,31 @@ bstp_add(struct bstp_state *bs, struct b return (EINVAL); } + bzero(bp, sizeof(struct bstp_port)); + BSTP_LOCK(bs); bp->bp_ifp = ifp; bp->bp_bs = bs; - bp->bp_active = 1; bp->bp_priority = BSTP_DEFAULT_PORT_PRIORITY; - bp->bp_path_cost = BSTP_DEFAULT_PATH_COST; + bp->bp_txcount = 0; + TASK_INIT(&bp->bp_statetask, 0, bstp_notify_state, bp); + TASK_INIT(&bp->bp_rtagetask, 0, bstp_notify_rtage, bp); + + /* Init state */ + bp->bp_infois = BSTP_INFO_DISABLED; + bstp_set_port_state(bp, BSTP_IFSTATE_DISCARDING); + bstp_set_port_proto(bp, bs->bs_protover); + bstp_set_port_role(bp, BSTP_ROLE_DISABLED); + bstp_set_port_tc(bp, BSTP_TCSTATE_INACTIVE); + bp->bp_path_cost = bstp_calc_path_cost(bp); LIST_INSERT_HEAD(&bs->bs_bplist, bp, bp_next); - TASK_INIT(&bp->bp_statetask, 0, bstp_state_change, bp); - BSTP_UNLOCK(bs); - bstp_reinit(bs); + bp->bp_active = 1; + bp->bp_flags |= BSTP_PORT_NEWINFO; + bstp_reinit(bs); + bstp_update_roles(bs, bp); + BSTP_UNLOCK(bs); return (0); } @@ -1285,14 +2117,11 @@ bstp_delete(struct bstp_port *bp) KASSERT(bp->bp_active == 1, ("not a bstp member")); BSTP_LOCK(bs); - if (bp->bp_state != BSTP_IFSTATE_DISABLED) - bstp_disable_port(bs, bp); LIST_REMOVE(bp, bp_next); - BSTP_UNLOCK(bs); bp->bp_bs = NULL; bp->bp_active = 0; - bstp_reinit(bs); + BSTP_UNLOCK(bs); } /* @@ -1303,4 +2132,5 @@ bstp_drain(struct bstp_port *bp) { KASSERT(bp->bp_active == 0, ("port is still attached")); taskqueue_drain(taskqueue_swi, &bp->bp_statetask); + taskqueue_drain(taskqueue_swi, &bp->bp_rtagetask); } Index: sys/net/bridgestp.h =================================================================== RCS file: /home/ncvs/src/sys/net/bridgestp.h,v retrieving revision 1.4 diff -u -p -r1.4 bridgestp.h --- sys/net/bridgestp.h 2 Aug 2006 02:47:27 -0000 1.4 +++ sys/net/bridgestp.h 12 Oct 2006 10:51:44 -0000 @@ -83,9 +83,55 @@ #define BSTP_IFSTATE_LEARNING 2 #define BSTP_IFSTATE_FORWARDING 3 #define BSTP_IFSTATE_BLOCKING 4 +#define BSTP_IFSTATE_DISCARDING 5 + +#define BSTP_TCSTATE_ACTIVE 1 +#define BSTP_TCSTATE_DETECTED 2 +#define BSTP_TCSTATE_INACTIVE 3 +#define BSTP_TCSTATE_LEARNING 4 +#define BSTP_TCSTATE_PROPAG 5 +#define BSTP_TCSTATE_ACK 6 +#define BSTP_TCSTATE_TC 7 +#define BSTP_TCSTATE_TCN 8 + +#define BSTP_ROLE_DISABLED 0 +#define BSTP_ROLE_ROOT 1 +#define BSTP_ROLE_DESIGNATED 2 +#define BSTP_ROLE_ALTERNATE 3 +#define BSTP_ROLE_BACKUP 4 #ifdef _KERNEL +/* STP port flags */ +#define BSTP_PORT_CANMIGRATE 0x0001 +#define BSTP_PORT_NEWINFO 0x0002 +#define BSTP_PORT_DISPUTED 0x0004 +#define BSTP_PORT_ADMCOST 0x0008 + +/* BPDU priority */ +#define BSTP_PDU_SUPERIOR 1 +#define BSTP_PDU_REPEATED 2 +#define BSTP_PDU_INFERIOR 3 +#define BSTP_PDU_INFERIORALT 4 +#define BSTP_PDU_OTHER 5 + +/* BPDU flags */ +#define BSTP_PDU_PRMASK 0x0c /* Port Role */ +#define BSTP_PDU_PRSHIFT 2 /* Port Role offset */ +#define BSTP_PDU_F_UNKN 0x00 /* Unknown port (00) */ +#define BSTP_PDU_F_ALT 0x01 /* Alt/Backup port (01) */ +#define BSTP_PDU_F_ROOT 0x02 /* Root port (10) */ +#define BSTP_PDU_F_DESG 0x03 /* Designated port (11) */ + +#define BSTP_PDU_STPMASK 0x81 /* strip unused STP flags */ +#define BSTP_PDU_RSTPMASK 0x7f /* strip unused RSTP flags */ +#define BSTP_PDU_F_TC 0x01 /* Topology change */ +#define BSTP_PDU_F_P 0x02 /* Proposal flag */ +#define BSTP_PDU_F_L 0x10 /* Learning flag */ +#define BSTP_PDU_F_F 0x20 /* Forwarding flag */ +#define BSTP_PDU_F_A 0x40 /* Agreement flag */ +#define BSTP_PDU_F_TCA 0x80 /* Topology change ack */ + /* * Spanning tree defaults. */ @@ -93,26 +139,48 @@ #define BSTP_DEFAULT_HELLO_TIME (2 * 256) #define BSTP_DEFAULT_FORWARD_DELAY (15 * 256) #define BSTP_DEFAULT_HOLD_TIME (1 * 256) +#define BSTP_DEFAULT_MIGRATE_DELAY (3 * 256) +#define BSTP_DEFAULT_HOLD_COUNT 6 #define BSTP_DEFAULT_BRIDGE_PRIORITY 0x8000 #define BSTP_DEFAULT_PORT_PRIORITY 0x80 #define BSTP_DEFAULT_PATH_COST 55 +#define BSTP_MIN_HELLO_TIME (1 * 256) +#define BSTP_MIN_MAX_AGE (6 * 256) +#define BSTP_MIN_FORWARD_DELAY (4 * 256) +#define BSTP_MIN_HOLD_COUNT 1 +#define BSTP_MAX_HELLO_TIME (2 * 256) +#define BSTP_MAX_MAX_AGE (40 * 256) +#define BSTP_MAX_FORWARD_DELAY (30 * 256) +#define BSTP_MAX_HOLD_COUNT 10 +#define BSTP_MAX_PRIORITY 61440 +#define BSTP_MAX_PORT_PRIORITY 240 +#define BSTP_MAX_PATH_COST 200000000 /* BPDU message types */ #define BSTP_MSGTYPE_CFG 0x00 /* Configuration */ +#define BSTP_MSGTYPE_RSTP 0x02 /* Rapid STP */ #define BSTP_MSGTYPE_TCN 0x80 /* Topology chg notification */ -/* BPDU flags */ -#define BSTP_FLAG_TC 0x01 /* Topology change */ -#define BSTP_FLAG_TCA 0x80 /* Topology change ack */ +/* Protocol versions */ +#define BSTP_PROTO_ID 0x00 +#define BSTP_PROTO_STP 0x00 +#define BSTP_PROTO_RSTP 0x02 + +#define BSTP_INFO_RECIEVED 1 +#define BSTP_INFO_MINE 2 +#define BSTP_INFO_AGED 3 +#define BSTP_INFO_DISABLED 4 + #define BSTP_MESSAGE_AGE_INCR (1 * 256) /* in 256ths of a second */ #define BSTP_TICK_VAL (1 * 256) /* in 256ths of a second */ -#define BSTP_LINK_TIMER (BSTP_TICK_VAL * 30) +#define BSTP_LINK_TIMER (BSTP_TICK_VAL * 15) /* * * Driver callbacks for STP state changes * */ typedef void (*bstp_state_cb_t)(struct ifnet *, int); +typedef void (*bstp_rtage_cb_t)(struct ifnet *, int); /* * Because BPDU's do not make nicely aligned structures, two different @@ -145,7 +213,10 @@ struct bstp_cbpdu { uint16_t cbu_maxage; /* maximum age */ uint16_t cbu_hellotime; /* hello time */ uint16_t cbu_forwarddelay; /* forwarding delay */ + uint8_t cbu_versionlen; /* version 1 length */ } __attribute__((__packed__)); +#define BSTP_BPDU_STP_LEN (3 + 35) /* LLC + STP pdu */ +#define BSTP_BPDU_RSTP_LEN (3 + 36) /* LLC + RSTP pdu */ /* topology change notification bridge protocol data unit */ struct bstp_tbpdu { @@ -161,53 +232,91 @@ struct bstp_tbpdu { * Timekeeping structure used in spanning tree code. */ struct bstp_timer { - uint16_t active; - uint16_t value; + int active; + int latched; + int value; +}; + +struct bstp_pri_vector { + uint64_t pv_root_id; + uint32_t pv_cost; + uint64_t pv_dbridge_id; + uint16_t pv_dport_id; + uint16_t pv_port_id; }; struct bstp_config_unit { - uint64_t cu_rootid; - uint64_t cu_bridge_id; - uint32_t cu_root_path_cost; + struct bstp_pri_vector cu_pv; uint16_t cu_message_age; uint16_t cu_max_age; - uint16_t cu_hello_time; uint16_t cu_forward_delay; - uint16_t cu_port_id; + uint16_t cu_hello_time; uint8_t cu_message_type; - uint8_t cu_topology_change_acknowledgment; + uint8_t cu_topology_change_ack; uint8_t cu_topology_change; + uint8_t cu_proposal; + uint8_t cu_agree; + uint8_t cu_learning; + uint8_t cu_forwarding; + uint8_t cu_role; }; struct bstp_tcn_unit { uint8_t tu_message_type; }; -/* - * Bridge interface list entry. - */ struct bstp_port { LIST_ENTRY(bstp_port) bp_next; struct ifnet *bp_ifp; /* parent if */ struct bstp_state *bp_bs; - int bp_active; - uint64_t bp_designated_root; - uint64_t bp_designated_bridge; + uint8_t bp_active; + uint8_t bp_protover; + uint32_t bp_flags; uint32_t bp_path_cost; - uint32_t bp_designated_cost; - struct bstp_timer bp_hold_timer; - struct bstp_timer bp_message_age_timer; + uint16_t bp_port_msg_age; + uint16_t bp_port_max_age; + uint16_t bp_port_fdelay; + uint16_t bp_port_htime; + uint16_t bp_desg_msg_age; + uint16_t bp_desg_max_age; + uint16_t bp_desg_fdelay; + uint16_t bp_desg_htime; + struct bstp_timer bp_edge_delay_timer; struct bstp_timer bp_forward_delay_timer; - struct bstp_config_unit bp_config_bpdu; + struct bstp_timer bp_hello_timer; + struct bstp_timer bp_message_age_timer; + struct bstp_timer bp_migrate_delay_timer; + struct bstp_timer bp_recent_backup_timer; + struct bstp_timer bp_recent_root_timer; + struct bstp_timer bp_tc_timer; + struct bstp_config_unit bp_msg_cu; + struct bstp_pri_vector bp_desg_pv; + struct bstp_pri_vector bp_port_pv; uint16_t bp_port_id; - uint16_t bp_designated_port; uint8_t bp_state; - uint8_t bp_topology_change_acknowledge; - uint8_t bp_config_pending; - uint8_t bp_change_detection_enabled; + uint8_t bp_tcstate; + uint8_t bp_role; + uint8_t bp_infois; + uint8_t bp_tc_ack; + uint8_t bp_tc_prop; + uint8_t bp_fdbflush; uint8_t bp_priority; + uint8_t bp_p2p_link; + uint8_t bp_agree; + uint8_t bp_agreed; + uint8_t bp_sync; + uint8_t bp_synced; + uint8_t bp_proposing; + uint8_t bp_proposed; + uint8_t bp_operedge; + uint8_t bp_reroot; + uint8_t bp_rcvdtc; + uint8_t bp_rcvdtca; + uint8_t bp_rcvdtcn; uint32_t bp_forward_transitions; + uint8_t bp_txcount; struct task bp_statetask; + struct task bp_rtagetask; }; /* @@ -216,51 +325,58 @@ struct bstp_port { struct bstp_state { LIST_ENTRY(bstp_state) bs_list; struct mtx bs_mtx; - uint64_t bs_designated_root; - uint64_t bs_bridge_id; + struct bstp_pri_vector bs_bridge_pv; + struct bstp_pri_vector bs_root_pv; struct bstp_port *bs_root_port; - uint32_t bs_root_path_cost; - uint16_t bs_max_age; - uint16_t bs_hello_time; - uint16_t bs_forward_delay; + uint8_t bs_protover; + uint16_t bs_migration_delay; + uint16_t bs_edge_delay; uint16_t bs_bridge_max_age; - uint16_t bs_bridge_hello_time; - uint16_t bs_bridge_forward_delay; - uint16_t bs_topology_change_time; + uint16_t bs_bridge_fdelay; + uint16_t bs_bridge_htime; + uint16_t bs_root_msg_age; + uint16_t bs_root_max_age; + uint16_t bs_root_fdelay; + uint16_t bs_root_htime; uint16_t bs_hold_time; uint16_t bs_bridge_priority; - uint8_t bs_topology_change_detected; - uint8_t bs_topology_change; - struct bstp_timer bs_hello_timer; - struct bstp_timer bs_topology_change_timer; - struct bstp_timer bs_tcn_timer; + uint8_t bs_txholdcount; + uint8_t bs_allsynced; struct callout bs_bstpcallout; /* STP callout */ struct bstp_timer bs_link_timer; struct timeval bs_last_tc_time; LIST_HEAD(, bstp_port) bs_bplist; bstp_state_cb_t bs_state_cb; + bstp_rtage_cb_t bs_rtage_cb; }; -#define BSTP_LOCK_INIT(_bs) mtx_init(&(_bs)->bs_mtx, "bstp", \ +#define BSTP_LOCK_INIT(_bs) mtx_init(&(_bs)->bs_mtx, "bstp", \ NULL, MTX_DEF) -#define BSTP_LOCK_DESTROY(_bs) mtx_destroy(&(_bs)->bs_mtx) -#define BSTP_LOCK(_bs) mtx_lock(&(_bs)->bs_mtx) -#define BSTP_UNLOCK(_bs) mtx_unlock(&(_bs)->bs_mtx) -#define BSTP_LOCK_ASSERT(_bs) mtx_assert(&(_bs)->bs_mtx, MA_OWNED) +#define BSTP_LOCK_DESTROY(_bs) mtx_destroy(&(_bs)->bs_mtx) +#define BSTP_LOCK(_bs) mtx_lock(&(_bs)->bs_mtx) +#define BSTP_UNLOCK(_bs) mtx_unlock(&(_bs)->bs_mtx) +#define BSTP_LOCK_ASSERT(_bs) mtx_assert(&(_bs)->bs_mtx, MA_OWNED) extern const uint8_t bstp_etheraddr[]; extern void (*bstp_linkstate_p)(struct ifnet *ifp, int state); -void bstp_attach(struct bstp_state *, bstp_state_cb_t); +void bstp_attach(struct bstp_state *, bstp_state_cb_t, bstp_rtage_cb_t); void bstp_detach(struct bstp_state *); void bstp_init(struct bstp_state *); -void bstp_reinit(struct bstp_state *); void bstp_stop(struct bstp_state *); int bstp_add(struct bstp_state *, struct bstp_port *, struct ifnet *); void bstp_delete(struct bstp_port *); void bstp_drain(struct bstp_port *); void bstp_linkstate(struct ifnet *, int); +int bstp_set_htime(struct bstp_state *, int); +int bstp_set_fdelay(struct bstp_state *, int); +int bstp_set_maxage(struct bstp_state *, int); +int bstp_set_holdcount(struct bstp_state *, int); +int bstp_set_protocol(struct bstp_state *, int); +int bstp_set_priority(struct bstp_state *, int); +int bstp_set_port_priority(struct bstp_port *, int); +int bstp_set_path_cost(struct bstp_port *, uint32_t); struct mbuf *bstp_input(struct bstp_port *, struct ifnet *, struct mbuf *); #endif /* _KERNEL */ Index: sys/net/if_bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_bridge.c,v retrieving revision 1.82 diff -u -p -r1.82 if_bridge.c --- sys/net/if_bridge.c 9 Oct 2006 00:49:57 -0000 1.82 +++ sys/net/if_bridge.c 12 Oct 2006 10:52:27 -0000 @@ -266,6 +266,7 @@ static int bridge_rtnode_insert(struct b struct bridge_rtnode *); static void bridge_rtnode_destroy(struct bridge_softc *, struct bridge_rtnode *); +static void bridge_rtable_expire(struct ifnet *, int); static void bridge_state_change(struct ifnet *, int); static struct bridge_iflist *bridge_lookup_member(struct bridge_softc *, @@ -305,6 +306,8 @@ static int bridge_ioctl_delspan(struct b static int bridge_ioctl_gbparam(struct bridge_softc *, void *); static int bridge_ioctl_grte(struct bridge_softc *, void *); static int bridge_ioctl_gifsstp(struct bridge_softc *, void *); +static int bridge_ioctl_sproto(struct bridge_softc *, void *); +static int bridge_ioctl_stxhc(struct bridge_softc *, void *); static int bridge_pfil(struct mbuf **, struct ifnet *, struct ifnet *, int); static int bridge_ip_checkbasic(struct mbuf **mp); @@ -418,6 +421,12 @@ const struct bridge_control bridge_contr { bridge_ioctl_gifsstp, sizeof(struct ifbpstpconf), BC_F_COPYOUT }, + + { bridge_ioctl_sproto, sizeof(struct ifbrparam), + BC_F_COPYIN|BC_F_SUSER }, + + { bridge_ioctl_stxhc, sizeof(struct ifbrparam), + BC_F_COPYIN|BC_F_SUSER }, }; const int bridge_control_table_size = sizeof(bridge_control_table) / sizeof(bridge_control_table[0]); @@ -531,7 +540,6 @@ bridge_clone_create(struct if_clone *ifc sc->sc_brtmax = BRIDGE_RTABLE_MAX; sc->sc_brttimeout = BRIDGE_RTABLE_TIMEOUT; - getmicrotime(&(sc->sc_stp.bs_last_tc_time)); /* Initialize our routing table. */ bridge_rtable_init(sc); @@ -574,7 +582,7 @@ bridge_clone_create(struct if_clone *ifc mtx_unlock(&bridge_list_mtx); } - bstp_attach(&sc->sc_stp, bridge_state_change); + bstp_attach(&sc->sc_stp, bridge_state_change, bridge_rtable_expire); ether_ifattach(ifp, eaddr); /* Now undo some of the damage... */ ifp->if_baudrate = 0; @@ -997,7 +1005,10 @@ bridge_ioctl_gifflags(struct bridge_soft req->ifbr_state = bif->bif_stp.bp_state; req->ifbr_priority = bif->bif_stp.bp_priority; req->ifbr_path_cost = bif->bif_stp.bp_path_cost; - req->ifbr_portno = bif->bif_ifp->if_index & 0xff; + req->ifbr_portno = bif->bif_ifp->if_index & 0xfff; + req->ifbr_proto = bif->bif_stp.bp_protover; + req->ifbr_role = bif->bif_stp.bp_role; + req->ifbr_stpflags = bif->bif_stp.bp_flags; return (0); } @@ -1087,7 +1098,10 @@ bridge_ioctl_gifs(struct bridge_softc *s breq.ifbr_state = bif->bif_stp.bp_state; breq.ifbr_priority = bif->bif_stp.bp_priority; breq.ifbr_path_cost = bif->bif_stp.bp_path_cost; - breq.ifbr_portno = bif->bif_ifp->if_index & 0xff; + breq.ifbr_portno = bif->bif_ifp->if_index & 0xfff; + breq.ifbr_proto = bif->bif_stp.bp_protover; + breq.ifbr_role = bif->bif_stp.bp_role; + breq.ifbr_stpflags = bif->bif_stp.bp_flags; error = copyout(&breq, bifc->ifbic_req + count, sizeof(breq)); if (error) break; @@ -1101,10 +1115,7 @@ bridge_ioctl_gifs(struct bridge_softc *s strlcpy(breq.ifbr_ifsname, bif->bif_ifp->if_xname, sizeof(breq.ifbr_ifsname)); breq.ifbr_ifsflags = bif->bif_flags; - breq.ifbr_state = bif->bif_stp.bp_state; - breq.ifbr_priority = bif->bif_stp.bp_priority; - breq.ifbr_path_cost = bif->bif_stp.bp_path_cost; - breq.ifbr_portno = bif->bif_ifp->if_index & 0xff; + breq.ifbr_portno = bif->bif_ifp->if_index & 0xfff; error = copyout(&breq, bifc->ifbic_req + count, sizeof(breq)); if (error) break; @@ -1219,12 +1230,10 @@ static int bridge_ioctl_spri(struct bridge_softc *sc, void *arg) { struct ifbrparam *param = arg; - struct bstp_state *bs = &sc->sc_stp; - - bs->bs_bridge_priority = param->ifbrp_prio; - bstp_reinit(bs); + int error; - return (0); + error = bstp_set_priority(&sc->sc_stp, param->ifbrp_prio); + return (error); } static int @@ -1233,7 +1242,7 @@ bridge_ioctl_ght(struct bridge_softc *sc struct ifbrparam *param = arg; struct bstp_state *bs = &sc->sc_stp; - param->ifbrp_hellotime = bs->bs_bridge_hello_time >> 8; + param->ifbrp_hellotime = bs->bs_bridge_htime >> 8; return (0); } @@ -1241,14 +1250,10 @@ static int bridge_ioctl_sht(struct bridge_softc *sc, void *arg) { struct ifbrparam *param = arg; - struct bstp_state *bs = &sc->sc_stp; - - if (param->ifbrp_hellotime == 0) - return (EINVAL); - bs->bs_bridge_hello_time = param->ifbrp_hellotime << 8; - bstp_reinit(bs); + int error; - return (0); + error = bstp_set_htime(&sc->sc_stp, param->ifbrp_hellotime); + return (error); } static int @@ -1257,7 +1262,7 @@ bridge_ioctl_gfd(struct bridge_softc *sc struct ifbrparam *param = arg; struct bstp_state *bs = &sc->sc_stp; - param->ifbrp_fwddelay = bs->bs_bridge_forward_delay >> 8; + param->ifbrp_fwddelay = bs->bs_bridge_fdelay >> 8; return (0); } @@ -1265,14 +1270,10 @@ static int bridge_ioctl_sfd(struct bridge_softc *sc, void *arg) { struct ifbrparam *param = arg; - struct bstp_state *bs = &sc->sc_stp; - - if (param->ifbrp_fwddelay == 0) - return (EINVAL); - bs->bs_bridge_forward_delay = param->ifbrp_fwddelay << 8; - bstp_reinit(bs); + int error; - return (0); + error = bstp_set_fdelay(&sc->sc_stp, param->ifbrp_fwddelay); + return (error); } static int @@ -1289,14 +1290,10 @@ static int bridge_ioctl_sma(struct bridge_softc *sc, void *arg) { struct ifbrparam *param = arg; - struct bstp_state *bs = &sc->sc_stp; - - if (param->ifbrp_maxage == 0) - return (EINVAL); - bs->bs_bridge_max_age = param->ifbrp_maxage << 8; - bstp_reinit(bs); + int error; - return (0); + error = bstp_set_maxage(&sc->sc_stp, param->ifbrp_maxage); + return (error); } static int @@ -1304,15 +1301,14 @@ bridge_ioctl_sifprio(struct bridge_softc { struct ifbreq *req = arg; struct bridge_iflist *bif; + int error; bif = bridge_lookup_member(sc, req->ifbr_ifsname); if (bif == NULL) return (ENOENT); - bif->bif_stp.bp_priority = req->ifbr_priority; - bstp_reinit(&sc->sc_stp); - - return (0); + error = bstp_set_port_priority(&bif->bif_stp, req->ifbr_priority); + return (error); } static int @@ -1320,15 +1316,14 @@ bridge_ioctl_sifcost(struct bridge_softc { struct ifbreq *req = arg; struct bridge_iflist *bif; + int error; bif = bridge_lookup_member(sc, req->ifbr_ifsname); if (bif == NULL) return (ENOENT); - bif->bif_stp.bp_path_cost = req->ifbr_path_cost; - bstp_reinit(&sc->sc_stp); - - return (0); + error = bstp_set_path_cost(&bif->bif_stp, req->ifbr_path_cost); + return (error); } static int @@ -1397,22 +1392,26 @@ static int bridge_ioctl_gbparam(struct bridge_softc *sc, void *arg) { struct ifbropreq *req = arg; + struct bstp_state *bs = &sc->sc_stp; struct bstp_port *root_port; - req->ifbop_maxage = sc->sc_stp.bs_max_age; - req->ifbop_hellotime = sc->sc_stp.bs_hello_time; - req->ifbop_fwddelay = sc->sc_stp.bs_forward_delay; + req->ifbop_maxage = bs->bs_bridge_max_age >> 8; + req->ifbop_hellotime = bs->bs_bridge_htime >> 8; + req->ifbop_fwddelay = bs->bs_bridge_fdelay >> 8; - root_port = sc->sc_stp.bs_root_port; + root_port = bs->bs_root_port; if (root_port == NULL) req->ifbop_root_port = 0; else req->ifbop_root_port = root_port->bp_ifp->if_index; - req->ifbop_root_path_cost = sc->sc_stp.bs_root_path_cost; - req->ifbop_designated_root = sc->sc_stp.bs_designated_root; - req->ifbop_last_tc_time.tv_sec = sc->sc_stp.bs_last_tc_time.tv_sec; - req->ifbop_last_tc_time.tv_usec = sc->sc_stp.bs_last_tc_time.tv_usec; + req->ifbop_holdcount = bs->bs_txholdcount; + req->ifbop_priority = bs->bs_bridge_priority; + req->ifbop_protocol = bs->bs_protover; + req->ifbop_root_path_cost = bs->bs_root_pv.pv_cost; + req->ifbop_designated_root = bs->bs_root_pv.pv_root_id; + req->ifbop_last_tc_time.tv_sec = bs->bs_last_tc_time.tv_sec; + req->ifbop_last_tc_time.tv_usec = bs->bs_last_tc_time.tv_usec; return (0); } @@ -1455,12 +1454,12 @@ bridge_ioctl_gifsstp(struct bridge_softc if ((bif->bif_flags & IFBIF_STP) == 0) continue; - bpreq.ifbp_portno = bif->bif_ifp->if_index & 0xff; + bpreq.ifbp_portno = bif->bif_ifp->if_index & 0xfff; bpreq.ifbp_fwd_trans = bif->bif_stp.bp_forward_transitions; - bpreq.ifbp_design_cost = bif->bif_stp.bp_designated_cost; - bpreq.ifbp_design_port = bif->bif_stp.bp_designated_port; - bpreq.ifbp_design_bridge = bif->bif_stp.bp_designated_bridge; - bpreq.ifbp_design_root = bif->bif_stp.bp_designated_root; + bpreq.ifbp_design_cost = bif->bif_stp.bp_desg_pv.pv_cost; + bpreq.ifbp_design_port = bif->bif_stp.bp_desg_pv.pv_port_id; + bpreq.ifbp_design_bridge = bif->bif_stp.bp_desg_pv.pv_dbridge_id; + bpreq.ifbp_design_root = bif->bif_stp.bp_desg_pv.pv_root_id; error = copyout(&bpreq, bifstp->ifbpstp_req + count, sizeof(bpreq)); @@ -1475,6 +1474,26 @@ bridge_ioctl_gifsstp(struct bridge_softc return (error); } +static int +bridge_ioctl_sproto(struct bridge_softc *sc, void *arg) +{ + struct ifbrparam *param = arg; + int error; + + error = bstp_set_protocol(&sc->sc_stp, param->ifbrp_proto); + return (error); +} + +static int +bridge_ioctl_stxhc(struct bridge_softc *sc, void *arg) +{ + struct ifbrparam *param = arg; + int error; + + error = bstp_set_holdcount(&sc->sc_stp, param->ifbrp_txhc); + return (error); +} + /* * bridge_ifdetach: * @@ -1716,15 +1735,9 @@ bridge_output(struct ifnet *ifp, struct * tree, make sure the port is in a state that * allows forwarding. */ - if (dst_if != ifp && - (bif->bif_flags & IFBIF_STP) != 0) { - switch (bif->bif_stp.bp_state) { - case BSTP_IFSTATE_BLOCKING: - case BSTP_IFSTATE_LISTENING: - case BSTP_IFSTATE_DISABLED: - continue; - } - } + if (dst_if != ifp && (bif->bif_flags & IFBIF_STP) && + bif->bif_stp.bp_state == BSTP_IFSTATE_DISCARDING) + continue; if (LIST_NEXT(bif, bif_next) == NULL) { used = 1; @@ -1834,15 +1847,11 @@ bridge_forward(struct bridge_softc *sc, return; } - if (bif->bif_flags & IFBIF_STP) { - switch (bif->bif_stp.bp_state) { - case BSTP_IFSTATE_BLOCKING: - case BSTP_IFSTATE_LISTENING: - case BSTP_IFSTATE_DISABLED: - BRIDGE_UNLOCK(sc); - m_freem(m); - return; - } + if ((bif->bif_flags & IFBIF_STP) && + bif->bif_stp.bp_state == BSTP_IFSTATE_DISCARDING) { + BRIDGE_UNLOCK(sc); + m_freem(m); + return; } eh = mtod(m, struct ether_header *); @@ -1941,14 +1950,11 @@ bridge_forward(struct bridge_softc *sc, return; } - if (bif->bif_flags & IFBIF_STP) { - switch (bif->bif_stp.bp_state) { - case BSTP_IFSTATE_DISABLED: - case BSTP_IFSTATE_BLOCKING: - BRIDGE_UNLOCK(sc); - m_freem(m); - return; - } + if ((bif->bif_flags & IFBIF_STP) && + bif->bif_stp.bp_state == BSTP_IFSTATE_DISCARDING) { + BRIDGE_UNLOCK(sc); + m_freem(m); + return; } BRIDGE_UNLOCK(sc); @@ -2040,14 +2046,10 @@ bridge_input(struct ifnet *ifp, struct m } } - if (bif->bif_flags & IFBIF_STP) { - switch (bif->bif_stp.bp_state) { - case BSTP_IFSTATE_BLOCKING: - case BSTP_IFSTATE_LISTENING: - case BSTP_IFSTATE_DISABLED: - BRIDGE_UNLOCK(sc); - return (m); - } + if ((bif->bif_flags & IFBIF_STP) && + bif->bif_stp.bp_state == BSTP_IFSTATE_DISCARDING) { + BRIDGE_UNLOCK(sc); + return (m); } if (bcmp(etherbroadcastaddr, eh->ether_dhost, @@ -2093,14 +2095,10 @@ bridge_input(struct ifnet *ifp, struct m return (m); } - if (bif->bif_flags & IFBIF_STP) { - switch (bif->bif_stp.bp_state) { - case BSTP_IFSTATE_BLOCKING: - case BSTP_IFSTATE_LISTENING: - case BSTP_IFSTATE_DISABLED: - BRIDGE_UNLOCK(sc); - return (m); - } + if ((bif->bif_flags & IFBIF_STP) && + bif->bif_stp.bp_state == BSTP_IFSTATE_DISCARDING) { + BRIDGE_UNLOCK(sc); + return (m); } /* @@ -2186,13 +2184,9 @@ bridge_broadcast(struct bridge_softc *sc if (dst_if == src_if) continue; - if (bif->bif_flags & IFBIF_STP) { - switch (bif->bif_stp.bp_state) { - case BSTP_IFSTATE_BLOCKING: - case BSTP_IFSTATE_DISABLED: - continue; - } - } + if ((bif->bif_flags & IFBIF_STP) && + bif->bif_stp.bp_state == BSTP_IFSTATE_DISCARDING) + continue; if ((bif->bif_flags & IFBIF_DISCOVER) == 0 && (m->m_flags & (M_BCAST|M_MCAST)) == 0) @@ -2653,6 +2647,37 @@ bridge_rtnode_destroy(struct bridge_soft } /* + * bridge_rtable_expire: + * + * Set the expiry time for all routes on an interface. + */ +static void +bridge_rtable_expire(struct ifnet *ifp, int age) +{ + struct bridge_softc *sc = ifp->if_bridge; + struct bridge_rtnode *brt; + + BRIDGE_LOCK(sc); + + /* + * If the age is zero then flush, otherwise set all the expiry times to + * age for the interface + */ + if (age == 0) + bridge_rtdelete(sc, ifp, IFBF_FLUSHDYN); + else { + LIST_FOREACH(brt, &sc->sc_rtlist, brt_list) { + /* Cap the expiry time to 'age' */ + if (brt->brt_ifp == ifp && + brt->brt_expire > time_uptime + age && + (brt->brt_flags & IFBAF_TYPEMASK) == IFBAF_DYNAMIC) + brt->brt_expire = time_uptime + age; + } + } + BRIDGE_UNLOCK(sc); +} + +/* * bridge_state_change: * * Callback from the bridgestp code when a port changes states. @@ -2667,20 +2692,12 @@ bridge_state_change(struct ifnet *ifp, i "learning", "forwarding", "blocking", + "discarding" }; if (log_stp) log(LOG_NOTICE, "%s: state changed to %s on %s\n", sc->sc_ifp->if_xname, stpstates[state], ifp->if_xname); - - /* if the port is blocking then remove any routes to it */ - switch (state) { - case BSTP_IFSTATE_DISABLED: - case BSTP_IFSTATE_BLOCKING: - BRIDGE_LOCK(sc); - bridge_rtdelete(sc, ifp, IFBF_FLUSHDYN); - BRIDGE_UNLOCK(sc); - } } /* Index: sys/net/if_bridgevar.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_bridgevar.h,v retrieving revision 1.15 diff -u -p -r1.15 if_bridgevar.h --- sys/net/if_bridgevar.h 31 Jul 2006 20:24:46 -0000 1.15 +++ sys/net/if_bridgevar.h 12 Oct 2006 10:51:44 -0000 @@ -112,6 +112,8 @@ #define BRDGGRTE 26 /* get cache drops (ifbrparam) */ #define BRDGGIFSSTP 27 /* get member STP params list * (ifbpstpconf) */ +#define BRDGSPROTO 28 /* set protocol (ifbrparam) */ +#define BRDGSTXHC 29 /* set tx hold count (ifbrparam) */ /* * Generic bridge control request. @@ -119,10 +121,13 @@ struct ifbreq { char ifbr_ifsname[IFNAMSIZ]; /* member if name */ uint32_t ifbr_ifsflags; /* member if flags */ - uint8_t ifbr_state; /* member if STP state */ - uint8_t ifbr_priority; /* member if STP priority */ - uint8_t ifbr_path_cost; /* member if STP cost */ + uint32_t ifbr_stpflags; /* member if STP flags */ + uint32_t ifbr_path_cost; /* member if STP cost */ uint8_t ifbr_portno; /* member if port number */ + uint8_t ifbr_priority; /* member if STP priority */ + uint8_t ifbr_proto; /* member if STP protocol */ + uint8_t ifbr_role; /* member if STP state */ + uint8_t ifbr_state; /* member if STP state */ }; /* BRDGGIFFLAGS, BRDGSIFFLAGS */ @@ -192,6 +197,8 @@ struct ifbrparam { #define ifbrp_csize ifbrp_ifbrpu.ifbrpu_int32 /* cache size */ #define ifbrp_ctime ifbrp_ifbrpu.ifbrpu_int32 /* cache time (sec) */ #define ifbrp_prio ifbrp_ifbrpu.ifbrpu_int16 /* bridge priority */ +#define ifbrp_proto ifbrp_ifbrpu.ifbrpu_int8 /* bridge protocol */ +#define ifbrp_txhc ifbrp_ifbrpu.ifbrpu_int8 /* bridge protocol */ #define ifbrp_hellotime ifbrp_ifbrpu.ifbrpu_int8 /* hello time (sec) */ #define ifbrp_fwddelay ifbrp_ifbrpu.ifbrpu_int8 /* fwd time (sec) */ #define ifbrp_maxage ifbrp_ifbrpu.ifbrpu_int8 /* max age (sec) */ @@ -201,9 +208,12 @@ struct ifbrparam { * Bridge current operational parameters structure. */ struct ifbropreq { + uint8_t ifbop_holdcount; uint8_t ifbop_maxage; uint8_t ifbop_hellotime; uint8_t ifbop_fwddelay; + uint8_t ifbop_protocol; + uint16_t ifbop_priority; uint16_t ifbop_root_port; uint32_t ifbop_root_path_cost; uint64_t ifbop_designated_root; --FCuugMFkClbJLl1L-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 12:15:21 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 A5FC316A407 for ; Thu, 12 Oct 2006 12:15:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC27D43D81 for ; Thu, 12 Oct 2006 12:15:13 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k9CCF6YN057003; Thu, 12 Oct 2006 08:15:06 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id k9CCF4PO039769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Oct 2006 08:15:04 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <7.0.1.0.0.20061012080659.1516c6a0@sentex.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 12 Oct 2006 08:13:05 -0400 To: Danny Braniss From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 12:15:21 -0000 At 04:38 AM 10/12/2006, Danny Braniss wrote: >short version: >the point im trying to make, is that the same setup, where I only change >the release, is going downhill - with this particular MB. But its not the same necessarily. Some of the settings are different. For example, disable net.inet.tcp.inflight.enable on 6.x if you want it to be the same setting as on 4. This kicks in when the hosts are not directly connected and can hamper performance. ---Mike From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 14:36: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 DFF7916A492 for ; Thu, 12 Oct 2006 14:36:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BD8E43E5F; Thu, 12 Oct 2006 14:35:02 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1GY1e4-000AFI-2T; Thu, 12 Oct 2006 16:34:48 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Mike Tancsa In-reply-to: Your message of Thu, 12 Oct 2006 08:13:05 -0400 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Oct 2006 16:34:47 +0200 From: Danny Braniss Message-ID: Cc: freebsd-net@freebsd.org, feebsd-hackers@freebsd.org Subject: Re: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 14:36:21 -0000 > >short version: > >the point im trying to make, is that the same setup, where I only change > >the release, is going downhill - with this particular MB. > > But its not the same necessarily. Some of the settings are different. > For example, disable net.inet.tcp.inflight.enable on 6.x if you want > it to be the same setting as on 4. This kicks in when the hosts are > not directly connected and can hamper performance. I assume that by directly connected you mean not connected via WAN, and so, yes these hosts are on the same vlan, and no, net.inet.tcp.inflight.enable=1/0 make no difference in any case, other boxes are doing ok (well, could be better, but not as bad as this one). danny From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 19:01: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 B7D3B16A403 for ; Thu, 12 Oct 2006 19:01:49 +0000 (UTC) (envelope-from bilse@networksignature.com) Received: from wraith.qbfox.com (wraith.qbfox.com [217.151.96.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55F9C43D5F for ; Thu, 12 Oct 2006 19:01:32 +0000 (GMT) (envelope-from bilse@networksignature.com) Received: (from bilse@localhost) by wraith.qbfox.com (8.11.6/8.11.6) id k9CJ1Ul22300; Thu, 12 Oct 2006 20:01:30 +0100 Message-Id: <200610121901.k9CJ1Ul22300@wraith.qbfox.com> From: Per Gregers Bilse Date: Thu, 12 Oct 2006 20:01:30 +0100 Organization: Network Signature Ltd X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: freebsd-net@freebsd.org Subject: bge(4) interface link state changes, bad flaps X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 19:01:49 -0000 [I guess I should introduce myself before posting, but I'm a bit pushed for time.] Some weeks ago I decided to upgrade to 6.x in an attempt to get rid of some unrelated problems, and ever since then I've seen fairly bad flaps on fibre Broadcom interfaces. I notice other people have had similar problems. The problem occurs with all if_bge.c versions less than maybe a year old (I haven't investigated in detail). Cutting a long story short, it seems that somewhere along the line some code accounting for encoding errors incorrectly showing up as link state changes has been lost. Try looking in older code (or using your favourite search engine) for "Sometimes PCS encoding errors are detected" (full text below). I tried re-importing the code into if_bge.c 1.150 but it didn't work as well as I had hoped (it did make a difference, though). I'm not sure if the problems are due to further bugs in my chips (BCM5703 rev 1002) or something else, but I did try new fibre connections without it making a difference, so I'm guessing it's the chips. Anyway, what has worked best for me is the fairly simple solution below, simply checking the status register for BGE_MACSTAT_TBI_SIGNAL_DETECT (checking for BGE_MACSTAT_TBI_PCS_SYNCHED still causes significant flaps) and resetting when the link goes down. static void bge_link_upd(struct bge_softc *sc) { struct mii_data *mii; uint32_t link, status; [...] if (sc->bge_flags & BGE_FLAG_TBI) { /* * Sometimes PCS encoding errors are detected in * TBI mode (on fiber NICs), and for some reason * the chip will signal them as link changes. * If we get a link change event, but the 'PCS * encoding error' bit in the MAC status register * is set, don't bother doing a link check. * This avoids spurious "link UP" messages * that sometimes appear on fiber NICs during * periods of heavy traffic. (There should be no * effect on copper NICs.) * * If we do have a copper NIC then * check that the AUTOPOLL bit is set before * processing the event as a real link change. * Turning AUTOPOLL on and off in the MII read/write * functions will often trigger a link status * interrupt for no reason. */ status = CSR_READ_4(sc, BGE_MAC_STS); if (!!(status & BGE_MACSTAT_TBI_SIGNAL_DETECT) != sc->bge_link) { if (status & BGE_MACSTAT_TBI_SIGNAL_DETECT) { sc->bge_link = 1; if (sc->bge_asicrev == BGE_ASICREV_BCM5704) BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_TBI_SEND_CFGS); if (bootverbose) if_printf(sc->bge_ifp, "link UP\n"); if_link_state_change(sc->bge_ifp, LINK_STATE_UP); } else { sc->bge_link = 0; if (bootverbose) if_printf(sc->bge_ifp, "link DOWN\n"); if_link_state_change(sc->bge_ifp, LINK_STATE_DOWN); bge_ifmedia_upd_locked(sc->bge_ifp); } } /* Discard link events for MII/GMII cards if MI auto-polling disabled */ } else if (CSR_READ_4(sc, BGE_MI_MODE) & BGE_MIMODE_AUTOPOLL) { [...] } /* Clear the attention. */ CSR_WRITE_4(sc, BGE_MAC_STS, BGE_MACSTAT_SYNC_CHANGED| BGE_MACSTAT_CFG_CHANGED|BGE_MACSTAT_MI_COMPLETE| BGE_MACSTAT_PORT_DECODE_ERROR| BGE_MACSTAT_LINK_CHANGED); } Maybe not the finest solution, but it works much better than the stock code; fixes/thoughts/improvements welcome. Best, -- Per From owner-freebsd-net@FreeBSD.ORG Thu Oct 12 20:16: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 78D9516A407 for ; Thu, 12 Oct 2006 20:16:19 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AC4B43D60; Thu, 12 Oct 2006 20:16:18 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k9CKG0rN060904; Thu, 12 Oct 2006 16:16:03 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id k9CKFxU6041929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Oct 2006 16:15:59 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <7.0.1.0.0.20061012160920.12a780d8@sentex.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 12 Oct 2006 16:14:00 -0400 To: Danny Braniss From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, feebsd-hackers@freebsd.org Subject: Re: em blues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Oct 2006 20:16:19 -0000 At 10:34 AM 10/12/2006, Danny Braniss wrote: > > >short version: > > >the point im trying to make, is that the same setup, where I only change > > >the release, is going downhill - with this particular MB. > > > > But its not the same necessarily. Some of the settings are different. > > For example, disable net.inet.tcp.inflight.enable on 6.x if you want > > it to be the same setting as on 4. This kicks in when the hosts are > > not directly connected and can hamper performance. > >I assume that by directly connected you mean not connected via WAN, >and so, yes these hosts are on the same vlan, and no, > net.inet.tcp.inflight.enable=1/0 >make no difference By directly connected, I mean on the same subnet. Whether the underlying transport is over a WAN doesnt matter, as long as the two devices are on the same subnet is what counts. Just to rule out issues like duplex setting bugs, I would try the two boxes back to back and make sure its the same subpar performance. ---Mike From owner-freebsd-net@FreeBSD.ORG Fri Oct 13 11:47:22 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 D687B16A40F; Fri, 13 Oct 2006 11:47:22 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id E32AE43E3B; Fri, 13 Oct 2006 11:46:40 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout1.pacific.net.au (Postfix) with ESMTP id BDD0A64D2FE; Fri, 13 Oct 2006 21:46:22 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 495D32742D; Fri, 13 Oct 2006 21:46:21 +1000 (EST) Date: Fri, 13 Oct 2006 21:46:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Ruslan Ermilov In-Reply-To: <20061012072036.GA60767@rambler-co.ru> Message-ID: <20061013204457.G50563@delplex.bde.org> References: <20061011090241.GA2831@FreeBSD.czest.pl> <20061011094049.GA24964@rambler-co.ru> <20061012052101.A814@epsplex.bde.org> <20061012072036.GA60767@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, andre@freebsd.org Subject: Re: [PATCH] Make hash.h usable in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Oct 2006 11:47:23 -0000 On Thu, 12 Oct 2006, Ruslan Ermilov wrote: > On Thu, Oct 12, 2006 at 05:21:09AM +1000, Bruce Evans wrote: >> On Wed, 11 Oct 2006, Ruslan Ermilov wrote: >>> %%% >>> Index: sys/sys/hash.h >>> =================================================================== >>> RCS file: /home/ncvs/src/sys/sys/hash.h,v >>> retrieving revision 1.2 >>> diff -u -p -r1.2 hash.h >>> --- sys/sys/hash.h 12 Mar 2006 15:34:33 -0000 1.2 >>> +++ sys/sys/hash.h 11 Oct 2006 09:38:50 -0000 >>> @@ -86,7 +86,7 @@ hash32_strn(const void *buf, size_t len, >>> * namei() hashing of path name parts. >>> */ >>> static __inline uint32_t >>> -hash32_stre(const void *buf, int end, char **ep, uint32_t hash) >>> +hash32_stre(const void *buf, int end, const char **ep, uint32_t hash) BTW, the man page is missing the first `const' for all the functions. >>> { >>> const unsigned char *p = buf; >>> >> >> I think this would break passing ep in almost all callers, >> > There are no callers of these functions yet, at least not in the > current FreeBSD kernel. There are only 2 callers in OpenBSD, > both in sys/kern/vfs_lookup.c Oops, I thought this API was being adapted from userland. >> in the same >> way that "fixing" the corresponding arg in the strtol(3) family would >> break almost all callers. >> > Yes, but strtol(3) has seen more life in sin. ;) > >> Callers want and need to pass char **, but >> char ** is not compatible with const char **. >> > Not compatible, but "char **" can safely be casted to "const char **". No, this is unsafe. See C99 6.5.16.1 [#6] (at least in the n869.txt draft). C99 requires a diagnostic for the corresponding assignment, but not of course for the unsafe cast. >> Callers want to do this >> because it's easier to write "char *end; ... &end", and they often >> need to do this so that they can modify the resulting *end. >> > But this is bad practice; if string is really const, writing to *end > will SIGBUS, and the fact that interface has it spelled as "char **" > doesn't mitigate it: Often (perhaps usually for strtol()), the data isn't const... > OTOH, if string is really modifiable, then simple casting when calling > a function works: > > : #include > : > : void foo(const char *, char *); > : void bar(const char *, const char **); > : > : void > : foo(const char *s1, char *s2) > : { > : const char *end1 = NULL; > : char *end2 = NULL; > : > : bar(s1, &end1); > : bar(s2, (const char **)&end2); > : } Hmm, gcc -Wcast-qual doesn't warn about this cast. I think it should, since allowing this is equivalent to allowing casting away of const. Maybe gcc is allowing a loophole or just making no more effort than the C standard to make const work right at all levels. > Or differently: it's safe (and possible) to do "end1 = end2", > but not the opposite. That's different -- there is no ** in sight and both gcc and the C standard get things right. >>> @@ -94,7 +94,7 @@ hash32_stre(const void *buf, int end, ch >>> hash = HASHSTEP(hash, *p++); >>> >>> if (ep) >>> - *ep = (char *)p; >>> + *ep = (const char *)p; >>> >>> return hash; >>> } >> >> Doesn't this cause a cast-qual warning in the kernel? >> > Why? None of qualifiers are lost as a result of cast; both "p" and "ep" > are pointers to const-qualified base types. (No, it doesn't cause a > warning.) Oops, I missed that it is the old cast that is unsafe. Now I think it was only the warning for that cast which made hash.h unusable (the original mail said why, but I forget the details). The new cast is of course safe but is still weird. The old cast was mainly to break the diagnostic (fatal in gcc?) about the type mismatch due to assigning away `const'. With recent or newer versions of gcc, it would also break the diagnostic (warning in gcc) about the type mismatch due to different signedness. But why are we returning "[const] char *"? We start with "const void *" and use it as "const unsigned char *". Then we switch signedness and indirectly return "[const] char *". Why not indirectly return "[const] unsigned char *", or better "[const] void *"? Other problems in hash.h: - missing `restrict' ? - namespace problems limit it to the kernel - minor style bugs. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Oct 13 12:56:28 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 D3CDF16A403 for ; Fri, 13 Oct 2006 12:56:28 +0000 (UTC) (envelope-from fwun@bigpond.net.au) Received: from imta02sl.mx.bigpond.com (imta02sl.mx.bigpond.com [144.140.93.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E05643D49 for ; Fri, 13 Oct 2006 12:56:27 +0000 (GMT) (envelope-from fwun@bigpond.net.au) Received: from web03sl ([144.140.91.180]) by imta02sl.mx.bigpond.com with ESMTP id <20061013125625.ZSEV15998.imta02sl.mx.bigpond.com@web03sl> for ; Fri, 13 Oct 2006 12:56:25 +0000 Received: Message-ID: <25685948.1160744185756.JavaMail.root@web03sl> Date: Fri, 13 Oct 2006 22:56:25 +1000 From: To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) Sensitivity: Normal Subject: patch for IPSEC_NAT_T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Oct 2006 12:56:28 -0000 Hi, I tried to compile freebsd 6.2 prerelease source with "options IPSEC_NAT_T", but it said "unknown option "IPSEC_NAT_T"" when I build it Had IPSEC_NAT_T patch already built into the 6.2 pre source? If not, where to obtain the patch? Thanks S From owner-freebsd-net@FreeBSD.ORG Fri Oct 13 13:03: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 34E6316A417 for ; Fri, 13 Oct 2006 13:03:06 +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 8A57B43DA3 for ; Fri, 13 Oct 2006 13:03:04 +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 k9DD33xp022402 for ; Fri, 13 Oct 2006 15:03:03 +0200 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 8856D3F17; Fri, 13 Oct 2006 15:02:56 +0200 (CEST) Date: Fri, 13 Oct 2006 15:02:56 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20061013130256.GA10192@zen.inc> References: <25685948.1160744185756.JavaMail.root@web03sl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25685948.1160744185756.JavaMail.root@web03sl> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: patch for IPSEC_NAT_T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Oct 2006 13:03:06 -0000 On Fri, Oct 13, 2006 at 10:56:25PM +1000, fwun@bigpond.net.au wrote: > Hi, Hi. > I tried to compile freebsd 6.2 prerelease source with "options > IPSEC_NAT_T", but it said "unknown option "IPSEC_NAT_T"" when I > build it > > Had IPSEC_NAT_T patch already built into the 6.2 pre source? > > If not, where to obtain the patch? Patch is available here: http://ipsec-tools.sf.net/freebsd6-natt.diff and is not (yet ?) in FreeBSD's sources. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Oct 13 14:27: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 B77C616A403 for ; Fri, 13 Oct 2006 14:27:26 +0000 (UTC) (envelope-from smw2010@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id B959B43D58 for ; Fri, 13 Oct 2006 14:27:23 +0000 (GMT) (envelope-from smw2010@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so397268nzn for ; Fri, 13 Oct 2006 07:27:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=c5CpDlhhFC5dS9uL9H7lt9VeQisS0PIGBlMHxdH1dzOA4+iMOIPw+5FFHQfEsba27yITEi7F4IHyCK3UZpJKNwsYNbnKC6iqqZ+qSekPSt63KMHZfeZuTREfxCq9yTSbeziO8HLG2HS+sL2YrPVsvDOS/VoYJbeQfsgzARh4UZM= Received: by 10.65.191.7 with SMTP id t7mr5050010qbp; Fri, 13 Oct 2006 07:27:22 -0700 (PDT) Received: by 10.64.148.18 with HTTP; Fri, 13 Oct 2006 07:27:22 -0700 (PDT) Message-ID: Date: Sat, 14 Oct 2006 00:27:22 +1000 From: "Sam Wun" To: "VANHULLEBUS Yvan" In-Reply-To: <20061013130256.GA10192@zen.inc> MIME-Version: 1.0 References: <25685948.1160744185756.JavaMail.root@web03sl> <20061013130256.GA10192@zen.inc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: patch for IPSEC_NAT_T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Oct 2006 14:27:26 -0000 in the kernel config file, what if I only define options IPSEC_NAT_T without defining FAST_IPSEC? I m not familiar with FAST_IPSEC, if I compile IPSEC_NAT_T with or without FAST_IPSEC, what s that going to affect my current IPSEC configuration and connection? Thanks S On 10/13/06, VANHULLEBUS Yvan wrote: > > On Fri, Oct 13, 2006 at 10:56:25PM +1000, fwun@bigpond.net.au wrote: > > Hi, > > Hi. > > > I tried to compile freebsd 6.2 prerelease source with "options > > IPSEC_NAT_T", but it said "unknown option "IPSEC_NAT_T"" when I > > build it > > > > Had IPSEC_NAT_T patch already built into the 6.2 pre source? > > > > If not, where to obtain the patch? > > Patch is available here: http://ipsec-tools.sf.net/freebsd6-natt.diff > and is not (yet ?) in FreeBSD's sources. > > > Yvan. > > -- > NETASQ > http://www.netasq.com > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Oct 13 14: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 A50D616A40F for ; Fri, 13 Oct 2006 14:32:34 +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 062E243D4C for ; Fri, 13 Oct 2006 14:32:33 +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 k9DEW7qr015263; Fri, 13 Oct 2006 16:32:31 +0200 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 0E2F73F17; Fri, 13 Oct 2006 16:32:02 +0200 (CEST) Date: Fri, 13 Oct 2006 16:32:01 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20061013143201.GA21926@zen.inc> References: <25685948.1160744185756.JavaMail.root@web03sl> <20061013130256.GA10192@zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: Sam Wun Subject: Re: patch for IPSEC_NAT_T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Oct 2006 14:32:34 -0000 On Sat, Oct 14, 2006 at 12:27:22AM +1000, Sam Wun wrote: > in the kernel config file, what if I only define options IPSEC_NAT_T without > defining FAST_IPSEC? > I m not familiar with FAST_IPSEC, if I compile IPSEC_NAT_T with or without > FAST_IPSEC, what s that going to affect my current IPSEC configuration and > connection? Patch works for both IPSEC and FAST_IPSEC. So if you have one of them activated, you'll have NAT-T support. I don't know what will happen if you define IPSEC_NAT_T, but not IPSEC / FAST_IPSEC, guess it will generate the same thing as if you didn' define IPSEC_NAT_T. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Oct 13 14:56:01 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 1BB9316A412 for ; Fri, 13 Oct 2006 14:56:01 +0000 (UTC) (envelope-from elessar@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8F8243D8D for ; Fri, 13 Oct 2006 14:55:57 +0000 (GMT) (envelope-from elessar@bsdforen.de) Received: from loki.starkstrom.lan (p549CD067.dip.t-dialin.net [84.156.208.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 070B7424109 for ; Fri, 13 Oct 2006 16:55:53 +0200 (CEST) Date: Fri, 13 Oct 2006 16:55:18 +0200 From: Joerg Pernfuss To: freebsd-net@freebsd.org Message-ID: <20061013165518.103236c8@loki.starkstrom.lan> In-Reply-To: <20061013143201.GA21926@zen.inc> References: <25685948.1160744185756.JavaMail.root@web03sl> <20061013130256.GA10192@zen.inc> <20061013143201.GA21926@zen.inc> X-Mailer: Sylpheed-Claws 2.2.3 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_7idAlmpxWClF.XHk3c.j1=N"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: patch for IPSEC_NAT_T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Oct 2006 14:56:01 -0000 --Sig_7idAlmpxWClF.XHk3c.j1=N Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 13 Oct 2006 16:32:01 +0200 VANHULLEBUS Yvan wrote: > I don't know what will happen if you define IPSEC_NAT_T, but not IPSEC > / FAST_IPSEC, guess it will generate the same thing as if you didn' > define IPSEC_NAT_T. Or it won't compile because some defines are missing, just like umass breaks without scbus. Joerg --=20 | /"\ ASCII ribbon | GnuPG Key ID | e86d b753 3deb e749 6c3a | | \ / campaign against | 0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 | | X HTML in email | .the next sentence is true. | | / \ and news | .the previous sentence was a lie. | --Sig_7idAlmpxWClF.XHk3c.j1=N Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFFL6jeH31s/bvKrSQRAofdAJsH4APZZTNWCfFPIm4BgofzvN5jpgCfW4GU GXscqIf6c0X1jwLmRe297BU= =iCPy -----END PGP SIGNATURE----- --Sig_7idAlmpxWClF.XHk3c.j1=N-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 13 15:05:35 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 2676A16A597; Fri, 13 Oct 2006 15:05:35 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41BB343D70; Fri, 13 Oct 2006 15:05:32 +0000 (GMT) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id C6B4499F04D; Fri, 13 Oct 2006 17:05:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id woAyeehfczgw; Fri, 13 Oct 2006 17:05:27 +0200 (CEST) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) by server.t-hosting.hu (Postfix) with ESMTP id 2B28399F04B; Fri, 13 Oct 2006 17:05:27 +0200 (CEST) Message-ID: <452FAB31.5080409@FreeBSD.org> Date: Fri, 13 Oct 2006 17:05:21 +0200 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Max Laier References: <1160580727.91199@swaggi.com> <200610111832.54869.max@love2party.net> In-Reply-To: <200610111832.54869.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Vince , Doug Barton , Paul Schmehl Subject: Re: Intel PRO 3945ABG Wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Oct 2006 15:05:35 -0000 Max Laier wrote: > On Wednesday 11 October 2006 17:32, Yuri Lukin wrote: > >> Doug Barton wrote .. >> >> >>> On Tue, 10 Oct 2006, Paul Schmehl wrote: >>> >>>> Why isn't anyone working on updating it? >>>> >>> This is a volunteer project. No one has volunteered. >>> >>> Doug >>> >> I think there are some that would like to contribute but don't >> know where to begin. I, for one, enjoy wireless networking >> and would like to contribute to the project but I dont >> know the OS internals and don't have any real programming >> experience. Perhaps some basic guidance could set people >> like myself on the right path? I'm not asking for hand-holding, >> just something to start with. >> > > There are three things that need to be done here: > 1) Adapt the bus interface. This is not too much work and should boil > down to a couple of sed(1)s and a few manual edits. Check drivers that > are in OpenBSD and FreeBSD and compare, or just check existing drivers. > The DRIVER(9) manual page and jmg@'s paper[1,2] should provide additional > insight. > 2) Use firmware(9) to load the ucode - as far as I understand the device > needs firmware as well. This shouldn't be much work and can be taken > verbatim from iwi(4). > 3) Adapt the net80211 interface. This one's a bit tricky since OpenBSD > went a different way with their 80211 implementation. Again, looking at > existing drivers (esp. ath(4) as the reference implementation and iwi(4) > as a driver from OpenBSD that was also retrofitted into FreeBSD) should > give an idea what is done how. > > In the end, you won't know what problems you come across until you start > with it. I can help with questions regarding 2 & 3, but will be busy for > the next two months and don't have a 3945 to test with, either. > > [1] http://www.bsdcan.org/2006/papers/freebsd.driver.pdf > [2] http://www.bsdcan.org/2006/papers/freebsd.device.driver.slides.pdf > > I started to port (actually try to port) this driver. I can read and write C, but I don't have any experience and knowledge with kernel drivers and architectural programming. I was able to understand some pieces of the code and made some progress so far, and will try to finish the whole driver, but it is quite difficult to me. Could you give me some feedback, please if I'm going towards the good direction or not? I uploaded my modified files to here: http://gabor.t-hosting.hu/if_wpi.tar What I did so far: - Included the necessary headers and dropped the unnecessary ones - Ported the driver interface (DRIVER_MODULE, MODULE_DEPENDS, wpi_ident, wpi_ident_table[], wpi_methods[], wpi_driver, - Added the necessary functions for wpi_methods[] - Added the following functions in the same manner as used in our if_iwi (with the corresponding macros): static void wpi_radio_on(void *, int); static void wpi_radio_off(void *, int); static void wpi_scanabort(void *, int); static void wpi_scandone(void *, int); static void wpi_scanstart(void *, int); static void wpi_scanchan(void *, int); - Started to port wpi_attach, but that is quite complicated to me yet What I have difficulties with: - wpi_cmd is called differently than iwi_cmd so I have no idea how to handle that - at line 513 (still wpi_cmd) I don't know what macro to use, since there's no equivalent for IWI_CMD_ABORT_SCAN -- Cheers, Gabor From owner-freebsd-net@FreeBSD.ORG Fri Oct 13 16:52: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 1799E16A403 for ; Fri, 13 Oct 2006 16:52:38 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from rackman.netvulture.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2009643DB4 for ; Fri, 13 Oct 2006 16:50:13 +0000 (GMT) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host72.netvulture.com [208.201.244.72]) (authenticated bits=0) by rackman.netvulture.com (8.13.5/8.13.5) with ESMTP id k9DGliOr036578 for ; Fri, 13 Oct 2006 09:47:46 -0700 (PDT) Message-ID: <452FC336.6060504@netvulture.com> Date: Fri, 13 Oct 2006 09:47:50 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-netvulture_com-MailScanner-Information: Please contact the ISP for more information X-netvulture_com-MailScanner: Found to be clean X-netvulture_com-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (timed out) X-netvulture_com-MailScanner-From: vulture@netvulture.com X-Spam-Status: No Subject: Problems with 6.2-PRE and udp applications - dhcpd and named X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Oct 2006 16:52:38 -0000 Hello, I have a P4 2.8 box running on an intel MB with a em0 acting as a firewall. The em0 has multiple tagged vlans on it, no ip assigned to main interface. Almost clockwork now, 6-7 days after bootup named or dhcpd completly locks up. I can't even kill -9 the apps. I have recompiled both apps since upgrading. I have only made two changes to this system around the same time. 1. Removed 2nd em nic that had only 1 network connected not vlan tagged. 2. Upgraded to 6.2-PRE Has anyone else had these problems? I am going to try running the system with the internet connection not tagged to see if that helps. Thanks, -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Sat Oct 14 00:45:50 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 CF57A16A403 for ; Sat, 14 Oct 2006 00:45:50 +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 7B3C343D6D for ; Sat, 14 Oct 2006 00:45:50 +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 3BD9246D5F; Fri, 13 Oct 2006 20:45:50 -0400 (EDT) Date: Sat, 14 Oct 2006 01:45:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jonathan Feally In-Reply-To: <452FC336.6060504@netvulture.com> Message-ID: <20061014014441.D96390@fledge.watson.org> References: <452FC336.6060504@netvulture.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Problems with 6.2-PRE and udp applications - dhcpd and named X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Oct 2006 00:45:50 -0000 On Fri, 13 Oct 2006, Jonathan Feally wrote: > I have a P4 2.8 box running on an intel MB with a em0 acting as a firewall. > The em0 has multiple tagged vlans on it, no ip assigned to main interface. > Almost clockwork now, 6-7 days after bootup named or dhcpd completly locks > up. I can't even kill -9 the apps. I have recompiled both apps since > upgrading. I have only made two changes to this system around the same time. > 1. Removed 2nd em nic that had only 1 network connected not vlan tagged. 2. > Upgraded to 6.2-PRE > > Has anyone else had these problems? I am going to try running the system > with the internet connection not tagged to see if that helps. I've not seen this on any boxes. The usual debugging path here is to: (1) Look at the process wait channel in ps axl. (2) Compile KDB/DDB into the kernel, and do a kernel stack trace of the process. Once you know what the kernel thread associated with the process is doing, we can attempt to figure out why it's doing it. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sat Oct 14 07:14:21 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 5F59B16A416 for ; Sat, 14 Oct 2006 07:14:21 +0000 (UTC) (envelope-from thedanyes@yahoo.com) Received: from web56508.mail.re3.yahoo.com (web56508.mail.re3.yahoo.com [66.196.97.37]) by mx1.FreeBSD.org (Postfix) with SMTP id BC44143D5C for ; Sat, 14 Oct 2006 07:14:20 +0000 (GMT) (envelope-from thedanyes@yahoo.com) Received: (qmail 64067 invoked by uid 60001); 14 Oct 2006 07:14:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Qy1qYTCxco0tsO1PfB43UF+OaS83jTvW1MkAyX4Pgxfo5Dm9oRvs/0PTKazdF1Uj6/6xQj3qfl2137opbBYZeNBJHxiokKacxIC0TY68J3fyf8zivdwAgyFdeyH+D6EY50VBhhFp3ee/MF4k6S/8dXjpIZP+/ImKAdDjlrxbzQs= ; Message-ID: <20061014071416.64065.qmail@web56508.mail.re3.yahoo.com> Received: from [71.231.62.46] by web56508.mail.re3.yahoo.com via HTTP; Sat, 14 Oct 2006 00:14:16 PDT Date: Sat, 14 Oct 2006 00:14:16 -0700 (PDT) From: Dan b To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: reset netstat statistics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Oct 2006 07:14:21 -0000 Hello, I searched the archives for this and was unable to find anything relevant. I have a machine that is being used as a NAT Router with IPFW and IPNAT running 5.3-RELEASE. I'm only using IPFW to keep track of traffic, no actual packet filtering is going on. The problem is that the statistics reported by netstat seem to reset themselves intermittently. Last night I ran netstat -ib and got an Ibytes stat of around 2.1GB on my sis0 adapter. Today I ran netstat -ib and got an Ibytes stat of around 600MB on my sis0 adapter. The system has around 29 days of uptime, and I have run ipfw zero a few times, but have not run netstat -z at all. Let me know if you have any ideas about this. Thanks, Daniel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Sat Oct 14 14:55:09 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 28FE016A417 for ; Sat, 14 Oct 2006 14:55:09 +0000 (UTC) (envelope-from piotr.reda@datanet.pl) Received: from maja.datanet.pl (datanet.pl [80.54.200.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0601043D53 for ; Sat, 14 Oct 2006 14:55:07 +0000 (GMT) (envelope-from piotr.reda@datanet.pl) Received: from localhost (localhost [127.0.0.1]) by maja.datanet.pl (Postfix) with ESMTP id 09F76119484 for ; Sat, 14 Oct 2006 16:55:13 +0200 (CEST) Received: from maja.datanet.pl ([127.0.0.1]) by localhost (oels.datanet.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79898-02 for ; Sat, 14 Oct 2006 16:55:09 +0200 (CEST) Received: from datanet1 (office.datanet.pl [84.40.142.35]) by maja.datanet.pl (Postfix) with ESMTP id 68863119474 for ; Sat, 14 Oct 2006 16:55:09 +0200 (CEST) Message-ID: <008501c6efa0$b7e19d20$fe01a8c0@datanet1> From: "Piotr Reda" To: Date: Sat, 14 Oct 2006 16:54:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Virus-Scanned: by amavisd-new at datanet.pl Subject: ProSum ATM card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Oct 2006 14:55:09 -0000 Hello, I have to make a router with an ATM 155Mb/s interface ProSum PROATMFM on 77252 chipset. I heard that this card has a serious problem with small packets on FreeBSD operating system. Which version shoul I used? Maybe FreeBSD-CURRENT (AKA 7.0-CURRENT)? Please advice, Best regards Peter From owner-freebsd-net@FreeBSD.ORG Sat Oct 14 15:38:32 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 9070016A40F for ; Sat, 14 Oct 2006 15:38:32 +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 6940843D7F for ; Sat, 14 Oct 2006 15:38:28 +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 k9EFcOEM029552 for ; Sat, 14 Oct 2006 17:38:25 +0200 Received: from jayce.zen.inc (jayce.zen.inc [192.168.1.7]) by smtp.zeninc.net (smtpd) with ESMTP id 1BA0F3F17 for ; Sat, 14 Oct 2006 17:38:18 +0200 (CEST) Received: by jayce.zen.inc (Postfix, from userid 1000) id 36DD32E232; Sat, 14 Oct 2006 17:38:19 +0200 (CEST) Date: Sat, 14 Oct 2006 17:38:18 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20061014153818.GA94704@jayce.zen.inc> References: <25685948.1160744185756.JavaMail.root@web03sl> <20061013130256.GA10192@zen.inc> <20061013143201.GA21926@zen.inc> <20061013165518.103236c8@loki.starkstrom.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061013165518.103236c8@loki.starkstrom.lan> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: patch for IPSEC_NAT_T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Oct 2006 15:38:32 -0000 On Fri, Oct 13, 2006 at 04:55:18PM +0200, Joerg Pernfuss wrote: > On Fri, 13 Oct 2006 16:32:01 +0200 > VANHULLEBUS Yvan wrote: > > > I don't know what will happen if you define IPSEC_NAT_T, but not IPSEC > > / FAST_IPSEC, guess it will generate the same thing as if you didn' > > define IPSEC_NAT_T. > > Or it won't compile because some defines are missing, just like umass > breaks without scbus. Maybe. But as quite all NAT-T code is inside IPSEC/FAST_IPSEC, it may also just compile cleanly. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Sat Oct 14 17:21:40 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 1F3F616A403 for ; Sat, 14 Oct 2006 17:21:40 +0000 (UTC) (envelope-from rosti.bsd@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FDB243D46 for ; Sat, 14 Oct 2006 17:21:38 +0000 (GMT) (envelope-from rosti.bsd@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so1108615wxd for ; Sat, 14 Oct 2006 10:21:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=Fb1J1DU6Gw3lp99EHIytl5goQaiUck7jnXLrGYhq7Q1JopKGkavjqZt3sjypDr8d9fPl7YCDbv8QAmKw+er0KGlsFgKRl83tCKMR/7j5ZUj8CmujpZONUpddzB/P067NwLGjHz7MssOY4azYpZ7VxPrXLQ5Hhnmv1JyXQ+2dl1k= Received: by 10.90.94.2 with SMTP id r2mr2992085agb; Sat, 14 Oct 2006 10:21:36 -0700 (PDT) Received: from saturn.lan ( [212.143.154.227]) by mx.google.com with ESMTP id 26sm5382186wra.2006.10.14.10.21.31; Sat, 14 Oct 2006 10:21:35 -0700 (PDT) Date: Sat, 14 Oct 2006 19:21:17 +0200 From: Rostislav Krasny To: "Crist J. Clark" Message-Id: <20061014192117.4b74b5dd.rosti.bsd@gmail.com> In-Reply-To: <20060821195938.GA16332@goku.cjclark.org> References: <20060818235756.25f72db4.rosti.bsd@gmail.com> <20060821092350.GL20788@insomnia.benzedrine.cx> <20060821195938.GA16332@goku.cjclark.org> X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.8.20; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sat__14_Oct_2006_19_21_17_+0200_gIzOgAJze2s0DnOR" Cc: freebsd-net@freebsd.org, Daniel Hartmeier Subject: Re: PF or "traceroute -e -P TCP" bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Oct 2006 17:21:40 -0000 This is a multi-part message in MIME format. --Multipart=_Sat__14_Oct_2006_19_21_17_+0200_gIzOgAJze2s0DnOR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, On Mon, 21 Aug 2006 12:59:38 -0700 "Crist J. Clark" wrote: > On Mon, Aug 21, 2006 at 11:23:50AM +0200, Daniel Hartmeier wrote: > > [ I'm CC'ing Crist, maybe he can explain why -e behaves like it does ] [hided] > So, to expand on the three points above, we need (1) fixed > destination port, (2) to increment IP TTL, (3) the sequence > number encoded in some head field, and (3) a source port > chosen so that multiple traceroute invocations do not > share any src-sport-dst-dport-tuples during their lifetime. > In the past, using the PID worked for the sport, but think about > what happens if you start with the PID then start incrementing > or decrementing, you get overlaps (unless your system does a > decent job with random PIDs; not the default for FreeBSD > unfortunately). > > The patch to freebsd-net addresses these problems. It > changes the sorce port so that we don't have overlapping > src-sport-dst-dport-tuples, and uses a base source port from > the LSBs of the clock for a "random" number. That would seem > to fix the problem. The only question would be is that a good > way to pick the base source port? It's probably good enough, > although some kind of hash of the PID might be better. What do you think about new version of the patch, attached to this email? It swaps high and low bytes of the "ident" - 16-bits integer variable. This technique should produce far standing numbers from any close standing numbers. --Multipart=_Sat__14_Oct_2006_19_21_17_+0200_gIzOgAJze2s0DnOR Content-Type: text/plain; name="traceroute.c.diff" Content-Disposition: attachment; filename="traceroute.c.diff" Content-Transfer-Encoding: 7bit --- traceroute.c.orig Fri Aug 18 18:52:57 2006 +++ traceroute.c Sat Oct 14 18:49:11 2006 @@ -721,7 +721,8 @@ main(int argc, char **argv) outip->ip_dst = to->sin_addr; outip->ip_hl = (outp - (u_char *)outip) >> 2; - ident = (getpid() & 0xffff) | 0x8000; + ident = getpid(); + ident = ((ident << CHAR_BIT) | (ident >> CHAR_BIT) & 0xffff) | 0x8000; if (pe == NULL) { Fprintf(stderr, "%s: unknown protocol %s\n", prog, cp); @@ -1355,7 +1356,7 @@ tcp_prep(struct outdata *outdata) { struct tcphdr *const tcp = (struct tcphdr *) outp; - tcp->th_sport = htons(ident); + tcp->th_sport = htons(ident + (fixedPort ? outdata->seq : 0)); tcp->th_dport = htons(port + (fixedPort ? 0 : outdata->seq)); tcp->th_seq = (tcp->th_sport << 16) | (tcp->th_dport + (fixedPort ? outdata->seq : 0)); @@ -1375,9 +1376,10 @@ tcp_check(const u_char *data, int seq) { struct tcphdr *const tcp = (struct tcphdr *) data; - return (ntohs(tcp->th_sport) == ident + return (ntohs(tcp->th_sport) == ident + (fixedPort ? seq : 0) && ntohs(tcp->th_dport) == port + (fixedPort ? 0 : seq)) - && tcp->th_seq == (ident << 16) | (port + seq); + && tcp->th_seq == (tcp->th_sport << 16) | + (port + (fixedPort ? seq : 0)); } void --Multipart=_Sat__14_Oct_2006_19_21_17_+0200_gIzOgAJze2s0DnOR--