From owner-freebsd-net@FreeBSD.ORG Sun Sep 2 02:22:36 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F1DC16A418 for ; Sun, 2 Sep 2007 02:22:36 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by mx1.freebsd.org (Postfix) with ESMTP id 575C813C461 for ; Sun, 2 Sep 2007 02:22:36 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from em60-254-201-51.pool.emnet.ne.jp.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l822LlwV092823; Sat, 1 Sep 2007 19:21:48 -0700 (PDT) Date: Sun, 02 Sep 2007 11:21:37 +0900 Message-ID: From: gnn@freebsd.org To: "Bruce M. Simpson" In-Reply-To: <46D51F4A.1050004@FreeBSD.org> References: <20070828165333.GA14159@sub.vaned.net> <46D48A3D.6080901@FreeBSD.org> <46D51F4A.1050004@FreeBSD.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, "Christian S.J. Peron" Subject: Re: [csjp@FreeBSD.org: Re: rtfree: 0xffffff00036fb1e0 has 1 refs] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Sep 2007 02:22:36 -0000 At Wed, 29 Aug 2007 08:24:58 +0100, Bruce M. Simpson wrote: >=20 > BTW: Casual inspection with kscope suggests there is a similar=20 > free-while-locked issue in nd6_ns_input() (netient6/nd6_nbr.c) and=20 > in_arpinput() (netinet/if_ether.c). >=20 > nd6_ns_input() references rt-=BBrt_gateway after rtfree(), a potential=20 > race not to mention a use-after-free. >=20 > I haven't checked Coverity for this, but it just doesn't look right. At least in the ND6 case I think that the correct logic is: =3D=3D=3D=3D //depot/user/gnn/ipsec_seven/src/sys/netinet6/nd6_nbr.c#1 - /s= ources/p4/user/gnn/ipsec_seven/src/sys/netinet6/nd6_nbr.c =3D=3D=3D=3D @@ -215,8 +215,6 @@ rt =3D rtalloc1((struct sockaddr *)&tsin6, 0, 0); need_proxy =3D (rt && (rt->rt_flags & RTF_ANNOUNCE) !=3D 0 && rt->rt_gateway->sa_family =3D=3D AF_LINK); - if (rt) - rtfree(rt); if (need_proxy) { /* * proxy NDP for single entry @@ -228,6 +226,9 @@ proxydl =3D SDL(rt->rt_gateway); } } + if (!need_proxy || ifa =3D=3D NULL) + if (rt) + rtfree(rt); } if (ifa =3D=3D NULL) { /* Thoughts? Best, George From owner-freebsd-net@FreeBSD.ORG Sun Sep 2 12:01:33 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49CA516A418 for ; Sun, 2 Sep 2007 12:01:33 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 0776A13C4A3 for ; Sun, 2 Sep 2007 12:01:32 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 722 invoked from network); 2 Sep 2007 07:01:14 -0500 Received: from 124-170-76-14.dyn.iinet.net.au (HELO localhost) (124.170.76.14) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Sep 2007 07:01:13 -0500 Date: Sun, 2 Sep 2007 22:01:10 +1000 From: Norberto Meijome To: FreeBSD Net ML Message-ID: <20070902220110.5c494bea@localhost> In-Reply-To: <20070831202729.7e4c0f7a@localhost> References: <20070831202729.7e4c0f7a@localhost> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: SOLUTION + Patch to: pf rdr + netsed : reinject loop... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Sep 2007 12:01:33 -0000 On Fri, 31 Aug 2007 20:27:29 +1000 Norberto Meijome wrote: > Hello everyone, I need your help / insight here :) Mel (fbsd.questions at rachie.is-a-geek.net ) has very kindly and cleverly provided a neat solution for this problem. It was posted to Question@, and it can be found here : http://lists.freebsd.org/pipermail/freebsd-questions/2007-August/156901.html thanks everyone for your help! B > > My setup, 2 VMs, XP (WinXP) and BSD (FreeBSD 6.2) > > [XP ,172.16.82.81 ] --- [172.16.82.81,em1 BSD A.B.C.D,em0] --- The Interweb ---- [Other_servers_galore] > > A.B.C.D is a public IP. > > [Other_servers_galore] represents all and any servers XP wants to talk to . I really don't know either port or IP of these servers. > > BSD is performing as gateway for XP , with NAT on em0 using pf. > > I want to replace certain bytes (FOO) in TCP packets between XP and [Other_servers_galore] for other bytes (BAR). Vlad Galu pointed out that net/netsed can help with this (with overhead, i know, this is only a test ). (Thanks again! ) > > so what I have setup : > > 1) pf.conf has : > ---- > ext_if="em0" > int_if="em1" > nat on $ext_if from $internal_net to any -> ($ext_if) > rdr on $int_if proto tcp from 172.16.82.81 to any -> 127.0.0.1 port 10101 > ----- > 2) I run netsed in transparent proxy mode as : > > netsed tcp 10101 0 0 s/FOO/BAR > > --- > The traffic from XP gets redirected just fine to netsed, which replaces the bytes just fine. BUT the changed packets (the output of netsed) get reinjected somewhere so that the rdr hits them again, sending them back to netsed ad infinitum. ( yes, i managed to hit a load of 700+ without anything ever leaving BSD ...quite cool) > > Now, netsed works just fine in that setup if I define the IP, eg : > pf.conf : > ext_if="em0" > int_if="em1" > nat on $ext_if from $internal_net to any -> ($ext_if) > rdr on $int_if proto tcp from 172.16.82.81 to O.P.Q.R -> 127.0.0.1 port 10101 > > netsed : > netsed tcp 10101 O.P.Q.R 0 s/FOO/BAR > > traffic goes to the external server O.P.Q.R ... but this was just a proof of concept, as I really can't tell the remote IPs in advance > > How do I modify this setup so that netsed packets aren't caught again by pf's rdr and sent back into netsed ? I'm happy to try other tools / setups... > > thanks for your time and any help you can provide :) > B _________________________ {Beto|Norberto|Numard} Meijome Commitment is active, not passive. Commitment is doing whatever you can to bring about the desired result. Anything less is half-hearted. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Sun Sep 2 21:22:32 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83D4B16A41B; Sun, 2 Sep 2007 21:22:32 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4F413C46A; Sun, 2 Sep 2007 21:22:32 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id A38F41A4D87; Sun, 2 Sep 2007 14:19:45 -0700 (PDT) Date: Sun, 2 Sep 2007 14:19:45 -0700 From: Alfred Perlstein To: "Bruce M. Simpson" Message-ID: <20070902211945.GQ87451@elvis.mu.org> References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46CC45F0.3000105@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Max Laier , net@freebsd.org Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Sep 2007 21:22:32 -0000 * Bruce M. Simpson [070822 07:33] wrote: > I second Max. If you are going to introduce a bunch of AF_* constants > into the tree you have to be very careful as AF_MAX is used to size > arrays and figure out how many radix trie heads to allocate. Ok, I'm not really sure what to do here. At Juniper we have approx 20 additional entries for AF_ constants. We also have theoretical but not practical "problems" with spareness and utility of this list, meaning we have plenty of arrays in our version of ifnets and route entries that are also "bloated" as well. We happen not to find it a problem. Perhaps if $BIG_ROUTER_COMPANY is not concerned about this then that might be convincing enough to let it go? Perhaps if I tossed in that it would be my intention to share code to dynamically allocate the data if we ever did it ourselves. Otherwise one other policy would be to specify an allocation policy such that new AF_ constants are allocated only for even numbers where odd numbers are left to vendors. This would slow the "bloat" and still provide vendors with something useful. How does that sound? -Alfred > > It could be argued this wastes a bunch of CPU time and memory, though I > speculate 'not much' at the moment; I am just a bit concerned that we > have ifnet->if_afdata which is also sized based on AF_MAX, 37, even > though most of the protocols in it are never attached to ifnets. > > The only domain I've seen which really uses if_afdata is PF_INET6. > PF_INET does not use it at all. In my opinion, there are structures > per-family per-ifnet which really belong hung-off ifnet on a 1:1 basis > and would simplify some of the lazy allocations we have further down in > the stack. > > If AF_MAX increases significantly so will wasted memory. If you are > going to make any significant changes here, please considering moving > this stuff to a more dynamic method of allocation. > > On the other hand, if you don't need to reference these constants in the > kernel at all, and they will all exist beyond AF_MAX, then you can > disregard what I've said and append them to the rest of the list. > > That is pretty much what happens for the libpcap/bpf DLT constants > (which are not an exact analogue of the AF constants - we don't allocate > other, larger kernel structures based on their value). > > regards, > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 11:08:23 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8982216A4DD for ; Mon, 3 Sep 2007 11:08:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 68F8B13C461 for ; Mon, 3 Sep 2007 11:08:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l83B8NNJ079132 for ; Mon, 3 Sep 2007 11:08:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l83B8K6f079128 for freebsd-net@FreeBSD.org; Mon, 3 Sep 2007 11:08:20 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Sep 2007 11:08:20 GMT Message-Id: <200709031108.l83B8K6f079128@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 11:08:23 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/115360 net [ipv6] IPv6 address and if_bridge don't play well toge 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/21998 net [socket] [patch] ident only for outgoing connections a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat 19 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/103253 net inconsistent behaviour in arp reply of a bridge o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114095 net [carp] carp+pf delay with high state limit o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f 14 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 12:00:00 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D686216A418 for ; Mon, 3 Sep 2007 12:00:00 +0000 (UTC) (envelope-from mermite@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 97E3E13C46C for ; Mon, 3 Sep 2007 12:00:00 +0000 (UTC) (envelope-from mermite@googlemail.com) Received: by rv-out-0910.google.com with SMTP id l15so864763rvb for ; Mon, 03 Sep 2007 04:59:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=sEliWtpigpKW+3PLZpHA/chVS241l4hub/qLw+Hlhzk60IH0vWgESgNxd38OScUt8VgT+7scOCNXADIL1wRplrBR0gTek3OUJgly9vPb4s7pO1830ReFpCY5cf2TNPghhjMF9gB3GB7pAlxu7JurkSWf+Zg+oWU+kjOLoAOXR3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=XjpsVIWUUjTx+bqOhcTg4ZhnDnm/kinyKZBsCwdZO4dXHuTqO+HHUvEk2XpC8FyWHJjC23KPj6L1DKy2QmzIYg8EWFMAXQ3CH04oTDYgiYJKtWmWmDbrBbDWqeRmxInjGl8g5YSLVNr44oo04XpGC8zIXAzQG4SXwjxnGNLQ9XQ= Received: by 10.140.249.20 with SMTP id w20mr656650rvh.1188820787140; Mon, 03 Sep 2007 04:59:47 -0700 (PDT) Received: by 10.141.44.3 with HTTP; Mon, 3 Sep 2007 04:59:47 -0700 (PDT) Message-ID: Date: Mon, 3 Sep 2007 13:59:47 +0200 From: "mer mite" To: mermite@gmail.com MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 03 Sep 2007 12:08:29 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Ethernet Bonding X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Sep 2007 12:00:00 -0000 Hi All, I'm looking for a way to provide ethernet interface bonding in FreeBSD similar to ipmp in Solaris or just ethernet bonding in Linux. Don't want to do anything fancy. Just want a second interface to take over for one which has failed. Preferable would be a solution that doesn't require a specific configuration on our switches or routers. I have perused the www and have found multiple articles describing the procedure in HP-UX, Solaris, Linux, etc., but nothing for FreeBSD. Thanks in advance for your responses. Cheers, -Joe P.S. I hope the administrator is happier with this post than with my last. From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 12:47:07 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2DEF16A418 for ; Mon, 3 Sep 2007 12:47:07 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by mx1.freebsd.org (Postfix) with ESMTP id 63EF213C442 for ; Mon, 3 Sep 2007 12:47:07 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.3.58]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JNS001VEKREWF30@mta-1.ms.rz.RWTH-Aachen.de> for net@freebsd.org; Mon, 03 Sep 2007 14:16:26 +0200 (CEST) Received: from talos.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.3.22]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 03 Sep 2007 14:16:26 +0200 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8/8.13.1/1) with ESMTP id l83CGPK9032266; Mon, 03 Sep 2007 14:16:25 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ISAqw-0002oK-9R; Mon, 03 Sep 2007 14:16:26 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 165B43F41B; Mon, 03 Sep 2007 14:16:21 +0200 (CEST) Date: Mon, 03 Sep 2007 14:16:20 +0200 From: Christian Brueffer In-reply-to: To: mer mite Message-id: <20070903121620.GB1767@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=K8nIJk4ghYZn606h Content-disposition: inline X-IronPort-AV: E=Sophos;i="4.20,201,1186351200"; d="scan'208";a="20089410" X-Operating-System: FreeBSD 6.2-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: User-Agent: Mutt/1.5.11 Cc: net@freebsd.org Subject: Re: Ethernet Bonding X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Sep 2007 12:47:07 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 03, 2007 at 01:59:47PM +0200, mer mite wrote: > Hi All, >=20 > I'm looking for a way to provide ethernet interface bonding in FreeBSD > similar to ipmp in Solaris or just ethernet bonding in Linux. Don't want= to > do anything fancy. Just want a second interface to take over for one whi= ch > has failed. Preferable would be a solution that doesn't require a specif= ic > configuration on our switches or routers. >=20 > I have perused the www and have found multiple articles describing the > procedure in HP-UX, Solaris, Linux, etc., but nothing for FreeBSD. >=20 > Thanks in advance for your responses. Take a look at lagg(4), it's available in 6-STABLE (not included in any release yet, 6.3 will be the first one shipping with it). - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFG2/sUbHYXjKDtmC0RAk7wAKCYWL4AmAtK5InnZaNJAClwqgK7bQCcC3oz B0IPKToBlJPsO4ErEhtScUE= =O/Vv -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 13:44:36 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA82F16A41B; Mon, 3 Sep 2007 13:44:36 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog10.obsmtp.com (s200aog10.obsmtp.com [207.126.144.124]) by mx1.freebsd.org (Postfix) with SMTP id CD1E413C48D; Mon, 3 Sep 2007 13:44:35 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob010.postini.com ([207.126.147.11]) with SMTP; Mon, 03 Sep 2007 13:44:17 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id DE417181430; Mon, 3 Sep 2007 14:11:59 +0100 (BST) Message-ID: <46DC081F.6010203@tomjudge.com> Date: Mon, 03 Sep 2007 14:11:59 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: net@freebsd.org, thompsa@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: If_bridge and MST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Sep 2007 13:44:36 -0000 Hi, I was wondering if if_bridge had been taught how to speak multiple instance spanning tree? Thanks Tom From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 14:11:50 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B65F16A468 for ; Mon, 3 Sep 2007 14:11:50 +0000 (UTC) (envelope-from dailydose@siliconindia.org) Received: from siliconindia.org (mail.siliconindia.org [72.52.77.20]) by mx1.freebsd.org (Postfix) with ESMTP id E226013C4A3 for ; Mon, 3 Sep 2007 14:11:49 +0000 (UTC) (envelope-from dailydose@siliconindia.org) Received: from siliconindia.org (localhost.localdomain [127.0.0.1]) by siliconindia.org (Postfix) with ESMTP id 095D1751FA for ; Mon, 3 Sep 2007 06:24:05 -0700 (PDT) Received: (from dailydose@localhost) by siliconindia.org (8.13.1/8.13.1/Submit) id l83DO4sG008121; Mon, 3 Sep 2007 06:24:04 -0700 To: freebsd-net@freebsd.org Date: Mon, 3 Sep 2007 06:24:04 -0700 From: si dailydose Message-ID: <0d6fbeb99fa2bff359b7a6cc5d8d74fd@mail.siliconindia.org> X-Priority: 3 X-Mailer: PHPMailer [version 1.73] Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Helped by Asian markets, Indian shares rise sharply/Confident ISRO targets global launch market/500 Indian students receive EU scholarship X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dailydose@siliconindia.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2007 14:11:50 -0000 SiliconIndia Daily Dose | September 03 2007 >> TOP NEWS [1]Helped by Asian markets, Indian shares rise sharply After lying low for some weeks, the bulls were back in full strength on Indian bourses during the week ended Friday, helping a key index end with gains on all the five sessions despite lingering political uncertainty. [2]Confident ISRO targets global launch market Its confidence further boosted after a successful satellite launch Sunday, ISRO said that it was targeting 5-10 percent of the global satellite launch market. [3]500 Indian students receive EU scholarship More than 500 Indian students and scholars have secured admission to a number of European universities under the Erasmus Mundus scholarship. >> TECHNOLOGY [4]India's first digital car project launched In a bid to promote innovation in the automobile sector, Satyam Computers Friday launched India's first digital car project here. [5]Kolkata firm has new ERP solution for SMEs Coral Soff'wares Ltd, a software firm that has corporate majors like Tata and Lafarge as its clients, is launching an ERP application catering to small and medium enterprises. >> BUSINESS [6]RR Donnelley expands Kerala BPO facility Printing giant RR Donnelley Monday expanded its BPO facility at the Technopark campus here by acquiring another 41,000 square foot centre. [7]Tata Motors wants to expand range in Russia Tata Motors, representing India at the Third International Motor Show InterAuto-2007, is planning to expand its produce range in the Russian market. >> OTHER NEWS [8]Indian sand artist to create Taj replica in New York Sand artist Sudarsan Patnaik will be creating a replica of the Taj Mahal at an Indian festival in New York later this month. [9]Radio listeners in U.S. to get BIG FM content Indians in the United States can now listen to their favourite Bollywood content on Asian FM with the US radio station entering into an arrangement with BIG 92.7 FM. >> BLOGS [10]Corporate's Role in Social Metamorphosis - [11]Atul Joshi Ask any engineer or scientist applying for DRDO, ISRO or BARC the same question, answer again would be.... MAGAZINE [12]Cover Story [13][cvr_si.jpg] GCI's client-centric approach and best-shore strategy. Also siliconindia 10th Anniversary Special. SiliconIndia Books [14]The Man Who Divided India [15][mandivede.jpg] Even after the lapse of over fifty years, the question of how and why India was divided remains unresolved. [16]Buy Now [17]Ayurveda [18][Ayurveda_LHealth.jpg] Ayurveda treats not just the ailment but the whole person and emphasizes prevention of disease to avoid the need for cure... [19]Buy Now [20]Click Here If you are siliconindia network member and do not want to receive daily dose, please select "unsubscribe" from your setting page when you log in. If you are not a member,[21] visit here to stop receiving daily dose. References Visible links 1. http://www.siliconindia.com/shownews/36865 2. http://www.siliconindia.com/shownews/36862 3. http://www.siliconindia.com/shownews/36859 4. http://www.siliconindia.com/shownews/36856 5. http://www.siliconindia.com/shownews/36863 6. http://www.siliconindia.com/shownews/36854 7. http://www.siliconindia.com/shownews/36855 8. http://www.siliconindia.com/shownews/36861 9. http://www.siliconindia.com/shownews/36860 10. http://blogs.siliconindia.com/atul_joshi 11. http://blogs.siliconindia.com/atul_joshi 12. http://www.siliconindia.com/magazine/ 13. http://www.siliconindia.com/magazine/ 14. http://www.siliconindia.com/books/newbooks/booksdetails/1349 15. http://www.siliconindia.com/books/newbooks/booksdetails/1349 16. http://www.siliconindia.com/books/newbooks/booksdetails/1349 17. http://www.siliconindia.com/books/newbooks/booksdetails/561 18. http://www.siliconindia.com/books/newbooks/booksdetails/561 19. http://www.siliconindia.com/books/newbooks/booksdetails/561 20. http://a.tribalfusion.com/i.click?site=siliconindiacom&adSpace=ROS&size=728x90&requestID=1658934770 21. http://www.siliconindia.com/newsletter/remove.php Hidden links: 22. http://www.chugh.com/ 23. http://www.india.amazon.com/ From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 14:12:12 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32AE316A41A for ; Mon, 3 Sep 2007 14:12:12 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from zzz.ee (kalah.zzz.ee [194.204.30.253]) by mx1.freebsd.org (Postfix) with ESMTP id D199B13C467 for ; Mon, 3 Sep 2007 14:12:11 +0000 (UTC) (envelope-from antik@bsd.ee) Received: by zzz.ee (Postfix, from userid 3019) id 615BB198415; Mon, 3 Sep 2007 16:15:55 +0300 (EEST) Received: from [192.168.1.26] (adsl215.uninet.ee [194.204.62.215]) by zzz.ee (Postfix) with ESMTP id ADB3C198413 for ; Mon, 3 Sep 2007 16:15:53 +0300 (EEST) From: Andrei Kolu To: freebsd-net@freebsd.org Date: Mon, 3 Sep 2007 16:15:52 +0300 User-Agent: KMail/1.9.7 References: <20070903121620.GB1767@haakonia.hitnet.RWTH-Aachen.DE> In-Reply-To: <20070903121620.GB1767@haakonia.hitnet.RWTH-Aachen.DE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709031615.53042.antik@bsd.ee> X-Spam-Checker-Version: SpamAssassin on spamassassin.zzz.ee X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_55 Subject: Re: Ethernet Bonding X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Sep 2007 14:12:12 -0000 On Monday 03 September 2007 15:16:20 Christian Brueffer wrote: > On Mon, Sep 03, 2007 at 01:59:47PM +0200, mer mite wrote: > > Hi All, > > > > I'm looking for a way to provide ethernet interface bonding in FreeBSD > > similar to ipmp in Solaris or just ethernet bonding in Linux. Don't want > > to do anything fancy. Just want a second interface to take over for one > > which has failed. Preferable would be a solution that doesn't require a > > specific configuration on our switches or routers. > > > > I have perused the www and have found multiple articles describing the > > procedure in HP-UX, Solaris, Linux, etc., but nothing for FreeBSD. > > > > Thanks in advance for your responses. > > Take a look at lagg(4), it's available in 6-STABLE (not included in any > release yet, 6.3 will be the first one shipping with it). > > - Christian You can use bond interfaces with netgraph: http://www.vorant.com/nsmwiki/index.php?title=FreeBSD_Netgraph_Port_Bonding From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 14:46:56 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2886A16A418; Mon, 3 Sep 2007 14:46:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id C775313C459; Mon, 3 Sep 2007 14:46:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 21BE91D3D7; Mon, 3 Sep 2007 10:46:43 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 03 Sep 2007 10:46:43 -0400 X-Sasl-enc: cQ6O1MIP3xpaH8SaZOWRX8B6KyNRBSJVLKglU8Id8WoG 1188830802 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 8E203187DA; Mon, 3 Sep 2007 10:46:42 -0400 (EDT) Message-ID: <46DC1E51.3040707@FreeBSD.org> Date: Mon, 03 Sep 2007 15:46:41 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Alfred Perlstein References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> In-Reply-To: <20070902211945.GQ87451@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , net@freebsd.org Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Sep 2007 14:46:56 -0000 Alfred Perlstein wrote: > Ok, I'm not really sure what to do here. At Juniper we have approx > 20 additional entries for AF_ constants. We also have theoretical > but not practical "problems" with spareness and utility of this > list, meaning we have plenty of arrays in our version of ifnets and > route entries that are also "bloated" as well. > Can you merge them into the list in such a way that AF_MAX does not need to slide forward? Or do they need to be referenced from within the kernel tree itself? Prevention of code bloat is better than the cure. Not having the code in front of me I couldn't say for sure if we're talking about a dozen bytes or several pages potentially being wasted, so it is impossible to judge. One of my concerns is that we have ifnet.if_afdata, we're not really using it, it makes sense to use it for some things. Help from big companies as well as little folks is always appreciated, providing we can reach consensus. > Otherwise one other policy would be to specify an allocation > policy such that new AF_ constants are allocated only for even > numbers where odd numbers are left to vendors. > > This would slow the "bloat" and still provide vendors with something > useful. > > How does that sound? > EPARSE? I don't follow this at all. BMS From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 17:34:36 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E220716A417 for ; Mon, 3 Sep 2007 17:34:36 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 9780213C458 for ; Mon, 3 Sep 2007 17:34:36 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 11CB11CC2C; Tue, 4 Sep 2007 05:34:35 +1200 (NZST) Date: Tue, 4 Sep 2007 05:34:35 +1200 From: Andrew Thompson To: Tom Judge Message-ID: <20070903173435.GA9902@heff.fud.org.nz> References: <46DC081F.6010203@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DC081F.6010203@tomjudge.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: net@freebsd.org Subject: Re: If_bridge and MST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Sep 2007 17:34:37 -0000 On Mon, Sep 03, 2007 at 02:11:59PM +0100, Tom Judge wrote: > Hi, > > I was wondering if if_bridge had been taught how to speak multiple > instance spanning tree? Not yet. I havnt started it yet and I do not know of anyone else working on it. Andrew From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 17:37:58 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5A6F16A417 for ; Mon, 3 Sep 2007 17:37:58 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 6E13313C45D for ; Mon, 3 Sep 2007 17:37:58 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id A06711CC2C; Tue, 4 Sep 2007 05:37:57 +1200 (NZST) Date: Tue, 4 Sep 2007 05:37:57 +1200 From: Andrew Thompson To: mer mite , net@freebsd.org Message-ID: <20070903173757.GB9902@heff.fud.org.nz> References: <20070903121620.GB1767@haakonia.hitnet.RWTH-Aachen.DE> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070903121620.GB1767@haakonia.hitnet.RWTH-Aachen.DE> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: Ethernet Bonding X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Sep 2007 17:37:58 -0000 On Mon, Sep 03, 2007 at 02:16:20PM +0200, Christian Brueffer wrote: > On Mon, Sep 03, 2007 at 01:59:47PM +0200, mer mite wrote: > > Hi All, > > > > I'm looking for a way to provide ethernet interface bonding in FreeBSD > > similar to ipmp in Solaris or just ethernet bonding in Linux. Don't want to > > do anything fancy. Just want a second interface to take over for one which > > has failed. Preferable would be a solution that doesn't require a specific > > configuration on our switches or routers. > > > > I have perused the www and have found multiple articles describing the > > procedure in HP-UX, Solaris, Linux, etc., but nothing for FreeBSD. > > > > Thanks in advance for your responses. > > Take a look at lagg(4), it's available in 6-STABLE (not included in any > release yet, 6.3 will be the first one shipping with it). There is a bit more information here too, http://nzfug.nz.freebsd.org/nzfug/HandbookUpdates/NetworkAggregation Andrew From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 20:14:25 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14FFD16A41A; Mon, 3 Sep 2007 20:14:25 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id EEA7113C428; Mon, 3 Sep 2007 20:14:24 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E0EBC1A4D9A; Mon, 3 Sep 2007 13:11:33 -0700 (PDT) Date: Mon, 3 Sep 2007 13:11:33 -0700 From: Alfred Perlstein To: "Bruce M. Simpson" Message-ID: <20070903201133.GU87451@elvis.mu.org> References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> <46DC1E51.3040707@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DC1E51.3040707@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Max Laier , net@freebsd.org Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Sep 2007 20:14:25 -0000 * Bruce M. Simpson [070903 07:44] wrote: > Alfred Perlstein wrote: > >Ok, I'm not really sure what to do here. At Juniper we have approx > >20 additional entries for AF_ constants. We also have theoretical > >but not practical "problems" with spareness and utility of this > >list, meaning we have plenty of arrays in our version of ifnets and > >route entries that are also "bloated" as well. > > > > Can you merge them into the list in such a way that AF_MAX does not need > to slide forward? > Or do they need to be referenced from within the kernel tree itself? They are refenced inside the kernel. > Prevention of code bloat is better than the cure. Not having the code > in front of me I couldn't say for sure if we're talking about a dozen > bytes or several pages potentially being wasted, so it is impossible to > judge. Well, for the most part it's going to be something like 32*sizeof(void*) so 128 or 256 bytes depending on arch. > One of my concerns is that we have ifnet.if_afdata, we're not really > using it, it makes sense to use it for some things. I'll have ot look into this. > Help from big companies as well as little folks is always appreciated, > providing we can reach consensus. YES! :) > >Otherwise one other policy would be to specify an allocation > >policy such that new AF_ constants are allocated only for even > >numbers where odd numbers are left to vendors. > > > >This would slow the "bloat" and still provide vendors with something > >useful. > > > >How does that sound? > > > > EPARSE? I don't follow this at all. Ok, let's say we garantee that going forward, all odd AF_ constants are verdor reserved.... So whenever FreeBSD allocates an AF constant, it should be even, vendors can use odd. That means that, from socket.h: #define AF_ARP 35 #define AF_BLUETOOTH 36 /* Bluetooth sockets */ #define AF_IEEE80211 37 /* IEEE 802.11 protocol */ #define AF_MAX 38 Now let's say FreeBSD wants to add a AF constant, the next one to allocate would be 38, so we have: #define AF_ARP 35 #define AF_BLUETOOTH 36 /* Bluetooth sockets */ #define AF_IEEE80211 37 /* IEEE 802.11 protocol */ #define AF_NEWPROTO1 38 /* some awesome new protocol! */ #define AF_MAX 39 Ok, well that doesn't explain it much, however, shortly thereafter we allocate another AF constant in FreeBSD, the list now looks like: #define AF_ARP 35 #define AF_BLUETOOTH 36 /* Bluetooth sockets */ #define AF_IEEE80211 37 /* IEEE 802.11 protocol */ #define AF_NEWPROTO1 38 /* some awesome new protocol! */ #define AF_VENDOR0 39 /* reserved for vendors. */ #define AF_NEWPROTO2 40 /* some awesome new protocol! */ #define AF_MAX 41 Soon another protocol is added: #define AF_ARP 35 #define AF_BLUETOOTH 36 /* Bluetooth sockets */ #define AF_IEEE80211 37 /* IEEE 802.11 protocol */ #define AF_NEWPROTO1 38 /* some awesome new protocol! */ #define AF_VENDOR0 39 /* reserved for vendors. */ #define AF_NEWPROTO2 40 /* some awesome new protocol! */ #define AF_VENDOR1 41 /* reserved for vendors. */ #define AF_NEWPROTO3 42 /* some awesome new protocol! */ #define AF_MAX 43 As you can see we are defering the "bloat". Does that make sense? -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 20:46:44 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98E9F16A418 for ; Mon, 3 Sep 2007 20:46:44 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp814.mail.ird.yahoo.com (smtp814.mail.ird.yahoo.com [217.146.188.74]) by mx1.freebsd.org (Postfix) with SMTP id F422813C45B for ; Mon, 3 Sep 2007 20:46:43 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 37074 invoked from network); 3 Sep 2007 20:20:02 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.140.28.215 with plain) by smtp814.mail.ird.yahoo.com with SMTP; 3 Sep 2007 20:20:01 -0000 X-YMail-OSG: IAVtg4gVM1lVfbwUlOqW8W9SgRwnJeVqEG9s_2rnFxFuYn2I Message-ID: <46DC7AD0.4080800@tomjudge.com> Date: Mon, 03 Sep 2007 22:21:20 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Andrew Thompson References: <46DC081F.6010203@tomjudge.com> <20070903173435.GA9902@heff.fud.org.nz> In-Reply-To: <20070903173435.GA9902@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: If_bridge and MST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Sep 2007 20:46:44 -0000 Andrew Thompson wrote: > On Mon, Sep 03, 2007 at 02:11:59PM +0100, Tom Judge wrote: >> Hi, >> >> I was wondering if if_bridge had been taught how to speak multiple >> instance spanning tree? > > Not yet. I havnt started it yet and I do not know of anyone else working > on it. > > > Andrew While playing with if_bridge today and a pair of Dell PowerConnect 5324's (with the recent upgrade to MSTP) I noticed that it did not seem to be possible to enable STP on if_vlan bridge members. This would seem to be correct as transmitting STP frames tagged with VLAN_ID would seem to break the spec and fall into the realm of cisco PVST. However should if_bridge be taught that the vlandev should be used for collection and transmission spanning tree in this scenario or should if_vlan be taught to copy untagged [R]STP frames onto the vlan interface? Tom From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 21:00:07 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63E9816A4A0 for ; Mon, 3 Sep 2007 21:00:07 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 08F1613C46A for ; Mon, 3 Sep 2007 21:00:06 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 510AF1CC2C; Tue, 4 Sep 2007 09:00:05 +1200 (NZST) Date: Tue, 4 Sep 2007 09:00:05 +1200 From: Andrew Thompson To: Tom Judge Message-ID: <20070903210005.GA14592@heff.fud.org.nz> References: <46DC081F.6010203@tomjudge.com> <20070903173435.GA9902@heff.fud.org.nz> <46DC7AD0.4080800@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DC7AD0.4080800@tomjudge.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: net@freebsd.org Subject: Re: If_bridge and MST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Sep 2007 21:00:07 -0000 On Mon, Sep 03, 2007 at 10:21:20PM +0100, Tom Judge wrote: > Andrew Thompson wrote: > >On Mon, Sep 03, 2007 at 02:11:59PM +0100, Tom Judge wrote: > >>Hi, > >> > >>I was wondering if if_bridge had been taught how to speak multiple > >>instance spanning tree? > > > >Not yet. I havnt started it yet and I do not know of anyone else working > >on it. > > > While playing with if_bridge today and a pair of Dell PowerConnect > 5324's (with the recent upgrade to MSTP) I noticed that it did not seem > to be possible to enable STP on if_vlan bridge members. This would seem > to be correct as transmitting STP frames tagged with VLAN_ID would seem > to break the spec and fall into the realm of cisco PVST. However should > if_bridge be taught that the vlandev should be used for collection and > transmission spanning tree in this scenario or should if_vlan be taught > to copy untagged [R]STP frames onto the vlan interface? Would this make it work the same as Cisco PVST? I havnt looked into how PVST works but whatever the solution is it would need to interoperate with other vendors. Obviously MST support is ideal. Most of the code is already there in the form of RSTP, and MST tacks a bit more info on the end. To be honest I have found 802.1Q-2003 a bit unclear in this area. cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 01:16:00 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22BA316A417 for ; Tue, 4 Sep 2007 01:16:00 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from srvbsdsmt002.uct.ac.za (srvbsdsmt002.uct.ac.za [137.158.153.104]) by mx1.freebsd.org (Postfix) with ESMTP id BD0D813C46A for ; Tue, 4 Sep 2007 01:15:59 +0000 (UTC) (envelope-from bsd@lordcow.org) Received: from mail.uct.ac.za ([137.158.153.100]) by srvbsdsmt002.uct.ac.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1ISMcJ-00086t-RD for freebsd-net@freebsd.org; Tue, 04 Sep 2007 02:50:07 +0200 Received: from lhc.phy.uct.ac.za ([137.158.92.134]) by mail.uct.ac.za with esmtp (Exim 4.44 (FreeBSD)) id 1ISMcI-000CVS-3o for freebsd-net@freebsd.org; Tue, 04 Sep 2007 02:50:06 +0200 Received: from lordcow by lhc.phy.uct.ac.za with local (Exim 4.67) (envelope-from ) id 1ISMcM-000670-DG for freebsd-net@freebsd.org; Tue, 04 Sep 2007 02:50:10 +0200 Date: Tue, 4 Sep 2007 02:50:10 +0200 From: gareth To: freebsd-net@freebsd.org Message-ID: <20070904005010.GA23347@lordcow.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-11) Subject: Re: re0 - D-Link DGE-528T not recognised X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 01:16:00 -0000 hey guys, sorry about the break in thread, i've just joined the mailing list and am copy/pasting from pipermail on the web. i have the same problem as MaXX in his mail dated 'Sun May 6 11:53:56 UTC 2007' (http://lists.freebsd.org/pipermail/freebsd-net/2007-May/014117.html). Denis replied with a patch on 'Sat May 19 10:08:02 UTC 2007' (http://lists.freebsd.org/pipermail/freebsd-net/2007-May/014195.html) which read as: --- /usr/src/sys/dev/re/if_re.c Wed Jan 24 03:57:50 2007 +++ /usr/src/sys/dev/re/if_re.c.new Sat May 19 04:08:32 2007 @@ -168,6 +168,8 @@ static struct rl_type re_devs[] = { { DLINK_VENDORID, DLINK_DEVICEID_528T, RL_HWREV_8169S, "D-Link DGE-528(T) Gigabit Ethernet Adapter" }, + { DLINK_VENDORID, DLINK_DEVICEID_528T, RL_HWREV_8169_8110SB, + "D-Link DGE-528(T) Rev.B1 Gigabit Ethernet Adapter" }, { RT_VENDORID, RT_DEVICEID_8139, RL_HWREV_8139CPLUS, "RealTek 8139C+ 10/100BaseTX" }, { RT_VENDORID, RT_DEVICEID_8101E, RL_HWREV_8101E, i did this but on compiling the kernel it stopped with error in if_re.c, line 168: 'RL_HWREV_8169_8110SB' undeclared here (not in a function). i found the corresponding declaration in /usr/src/sys/pci/if_rlreg.h and did: #define RL_HWREV_8169SB 0x10000000 + #define RL_HWREV_8169_8110SB 0x10000000 and looking around in the /usr/src/sys/pci/if_rl.c file i did this just in case: - hwrev == RL_HWREV_8110S) { + hwrev == RL_HWREV_8110S || + hwrev == RL_HWREV_8169_8110SB) { the kernel then recompiles without error and the network card comes up and i can join a network. i have no idea what i was doing though, and would like to know if i've done the right thing, eg. setting the #define to 0x10000000 and not 0x04000000 etc.? ps. i notice nothing else has been said on http://www.freebsd.org/cgi/query-pr.cgi?pr=112774 From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 01:46:13 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52B3316A417 for ; Tue, 4 Sep 2007 01:46:13 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 180EA13C45E for ; Tue, 4 Sep 2007 01:46:13 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (9kyquabcmqfiuahp@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l841kC61053984; Mon, 3 Sep 2007 18:46:12 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l841k9cD053983; Mon, 3 Sep 2007 18:46:09 -0700 (PDT) (envelope-from jmg) Date: Mon, 3 Sep 2007 18:46:09 -0700 From: John-Mark Gurney To: Prahar Shah Message-ID: <20070904014609.GG977@funkthat.com> Mail-Followup-To: Prahar Shah , freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org Subject: Re: Accessing device memory from user-land application process X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 01:46:13 -0000 Prahar Shah wrote this message on Fri, Aug 31, 2007 at 10:30 +0530: > I am writing a device driver in user-land process. I do a contigmalloc() to > allocate the descriptor memory, do a vtophys() on it and mmap that memory in > the user-land application process. I allocate buffers again using You should be using bus_dma(9) instead of vtophys... With bus_dma, you won't have to restrict your driver to i386 and other platforms that provide vtophys... > contigmalloc(), and mmap it within the same process. I pass on a buffer each > to the device descriptor. And my packet reception works fine. > While processing packets, once i reset the device (all device registers and > related memory), and repopulate buffers into the descriptors, I > occasionally find that while receiving a packet after reset, the buffer > address that I read from the first descriptor is not the one that I gave to > the descriptor after the reset. Instead, it turns out to be an older buffer > address which as allocated to a descriptor which was supposed to be read > next, prior to the reset. > My doubt is, could this be a cache-coherency issue? Or could there be a > chance that the device might be caching the buffer address available with > the descriptors, and re-writing back to the descriptor after receiving the > packet, and somehow these cached address are not flushed during a device > reset? Probably a cache issue... If you use bus_dma, you can call bus_dmamap_sync to deal w/ the cache issue... > If i've missed any details, kindly let me know. > Any help would be greatly appriciated Good luck! Hope this helps... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 02:06:30 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70E7816A419 for ; Tue, 4 Sep 2007 02:06:30 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id E272213C494 for ; Tue, 4 Sep 2007 02:06:29 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 30D73690FA0 for ; Tue, 4 Sep 2007 02:47:55 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id B0B376910A1; Tue, 4 Sep 2007 02:47:54 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local (87-196-23-68.net.novis.pt [87.196.23.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id 5F7E0690FA0 for ; Tue, 4 Sep 2007 02:47:51 +0100 (WEST) Message-ID: <46DCB831.3030207@fnop.net> Date: Tue, 04 Sep 2007 02:43:13 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Killing IPTOS_CE and IPTOS_ECT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 02:06:30 -0000 Hi, I'm working on TCP ECN support and I would like to kill these defines from netinet/ip.h #if 1 /* ECN RFC3168 obsoletes RFC2481, and these will be deprecated soon. */ #define IPTOS_CE 0x01 #define IPTOS_ECT 0x02 #endif The are outdated and should no longer be used because that RFC has been obsoleted. RFC 3168 uses a bit different bits: #define IPTOS_ECN_NOTECT 0x00 /* not-ECT */ #define IPTOS_ECN_ECT1 0x01 /* ECN-capable transport (1) */ #define IPTOS_ECN_ECT0 0x02 /* ECN-capable transport (0) */ #define IPTOS_ECN_CE 0x03 /* congestion experienced */ #define IPTOS_ECN_MASK 0x03 /* ECN field mask */ The only consumer of the RFC 2481 defines is sbin/ipfw/ipfw2.c and luigi@ accepted the attached patch. Does anyone have any objection against the removal ? Regards. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 02:10:46 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86D2016A417 for ; Tue, 4 Sep 2007 02:10:46 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 0015813C45D for ; Tue, 4 Sep 2007 02:10:45 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 9B48E6910A0 for ; Tue, 4 Sep 2007 03:15:17 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 471FD6910A3; Tue, 4 Sep 2007 03:15:17 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local (87-196-23-68.net.novis.pt [87.196.23.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id 442686910A0 for ; Tue, 4 Sep 2007 03:15:12 +0100 (WEST) Message-ID: <46DCBE9A.60109@fnop.net> Date: Tue, 04 Sep 2007 03:10:34 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <46DCB831.3030207@fnop.net> In-Reply-To: <46DCB831.3030207@fnop.net> Content-Type: multipart/mixed; boundary="------------060102000708020701020409" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Killing IPTOS_CE and IPTOS_ECT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 02:10:46 -0000 This is a multi-part message in MIME format. --------------060102000708020701020409 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Rui Paulo wrote: > The only consumer of the RFC 2481 defines is sbin/ipfw/ipfw2.c and > luigi@ accepted the attached patch. Here's the attached patch. -- Rui Paulo --------------060102000708020701020409 Content-Type: text/plain; x-mac-type="54455854"; x-mac-creator="74747874"; name="ipfw2-ecn.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw2-ecn.diff" Index: ipfw2.c =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.107 diff -u -p -r1.107 ipfw2.c --- ipfw2.c 26 Aug 2007 18:38:31 -0000 1.107 +++ ipfw2.c 3 Sep 2007 00:27:39 -0000 @@ -179,8 +179,8 @@ static struct _s_x f_iptos[] = { { "throughput", IPTOS_THROUGHPUT}, { "reliability", IPTOS_RELIABILITY}, { "mincost", IPTOS_MINCOST}, - { "congestion", IPTOS_CE}, - { "ecntransport", IPTOS_ECT}, + { "congestion", IPTOS_ECN_CE}, + { "ecntransport", IPTOS_ECN_ECT0}, { "ip tos option", 0}, { NULL, 0 } }; --------------060102000708020701020409-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 08:33:13 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E071016A419 for ; Tue, 4 Sep 2007 08:33:13 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id B406513C467 for ; Tue, 4 Sep 2007 08:33:13 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1032644rvb for ; Tue, 04 Sep 2007 01:33:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=npUSGwyr2Ceg6ghDQMqjklF0XXz61vEz2+6KhfKwq6idZzB5SpnnOg1A0d7lCox1tGbKeI6GApuHF7uHAibZ3dolGlAxuw2E5n1Q15HGnPpbRTkBU+9R0bpXdKJ2+LOFY7Tx2DsEFfKNfiL80ase1cCTjK5WDeXkQ2h/Aew1Q70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=f9GxBiMc2C5sLB+gBb3MXe+zfO9c38gOMKUWg3x0SlyH5pN4AbCL/YTZ+vw9/cc8h3dfuUCtOB2JkbFNEOoYNRRQfHwnC0jb18sEUXc6U7HMIIWLCi8pSVaOQ0WZW7+MEjW5a0zsJt4ezVcHWk1Ukp1HtqyOR93UcRF3rsZ1F8c= Received: by 10.141.18.14 with SMTP id v14mr2253247rvi.1188893242898; Tue, 04 Sep 2007 01:07:22 -0700 (PDT) Received: by 10.141.32.21 with HTTP; Tue, 4 Sep 2007 01:07:22 -0700 (PDT) Message-ID: <61b573980709040107t490632far990da52e5bfea3a1@mail.gmail.com> Date: Tue, 4 Sep 2007 11:07:22 +0300 From: "Shteryana Shopova" Sender: shteryana@gmail.com To: "Andrew Thompson" , "Tom Judge" In-Reply-To: <20070903210005.GA14592@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46DC081F.6010203@tomjudge.com> <20070903173435.GA9902@heff.fud.org.nz> <46DC7AD0.4080800@tomjudge.com> <20070903210005.GA14592@heff.fud.org.nz> X-Google-Sender-Auth: 66575df13c8ae472 Cc: net@freebsd.org Subject: Re: If_bridge and MST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syrinx@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 08:33:14 -0000 On 9/4/07, Andrew Thompson wrote: > On Mon, Sep 03, 2007 at 10:21:20PM +0100, Tom Judge wrote: > > Andrew Thompson wrote: > > >On Mon, Sep 03, 2007 at 02:11:59PM +0100, Tom Judge wrote: > > >>Hi, > > >> > > >>I was wondering if if_bridge had been taught how to speak multiple > > >>instance spanning tree? > > > > > >Not yet. I havnt started it yet and I do not know of anyone else working > > >on it. > > > > > While playing with if_bridge today and a pair of Dell PowerConnect > > 5324's (with the recent upgrade to MSTP) I noticed that it did not seem > > to be possible to enable STP on if_vlan bridge members. This would seem > > to be correct as transmitting STP frames tagged with VLAN_ID would seem > > to break the spec and fall into the realm of cisco PVST. However should > > if_bridge be taught that the vlandev should be used for collection and > > transmission spanning tree in this scenario or should if_vlan be taught > > to copy untagged [R]STP frames onto the vlan interface? > > Would this make it work the same as Cisco PVST? I havnt looked into how > PVST works but whatever the solution is it would need to interoperate > with other vendors. Obviously MST support is ideal. Most of the code is > already there in the form of RSTP, and MST tacks a bit more info on the > end. To be honest I have found 802.1Q-2003 a bit unclear in this area. > > AFAIK, Cisco PVST is the predecessor of 802.1Q MSTP. If I remember correctly one of the notable differences between the two is that with Cisco PVST BPDUs are send for every spanning tree instance (also tagged?) while with 802.1Q MSTP all information is contained in the per instance M-records (MSTI Configuration Messages) in a single BPDU, and BPDUs are only sent in instance 0. cheers, Shteryana From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 08:38:52 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9641616A417; Tue, 4 Sep 2007 08:38:52 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog12.obsmtp.com (s200aog12.obsmtp.com [207.126.144.126]) by mx1.freebsd.org (Postfix) with SMTP id 6253F13C46C; Tue, 4 Sep 2007 08:38:51 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob012.postini.com ([207.126.147.11]) with SMTP; Tue, 04 Sep 2007 08:38:42 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id DBA2018142E; Tue, 4 Sep 2007 09:38:41 +0100 (BST) Message-ID: <46DD1991.1080104@tomjudge.com> Date: Tue, 04 Sep 2007 09:38:41 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: syrinx@FreeBSD.org References: <46DC081F.6010203@tomjudge.com> <20070903173435.GA9902@heff.fud.org.nz> <46DC7AD0.4080800@tomjudge.com> <20070903210005.GA14592@heff.fud.org.nz> <61b573980709040107t490632far990da52e5bfea3a1@mail.gmail.com> In-Reply-To: <61b573980709040107t490632far990da52e5bfea3a1@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Thompson , net@freebsd.org Subject: Re: If_bridge and MST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 08:38:52 -0000 Shteryana Shopova wrote: > On 9/4/07, Andrew Thompson wrote: >> On Mon, Sep 03, 2007 at 10:21:20PM +0100, Tom Judge wrote: >>> Andrew Thompson wrote: >>>> On Mon, Sep 03, 2007 at 02:11:59PM +0100, Tom Judge wrote: >>>>> Hi, >>>>> >>>>> I was wondering if if_bridge had been taught how to speak multiple >>>>> instance spanning tree? >>>> Not yet. I havnt started it yet and I do not know of anyone else working >>>> on it. >>>> >>> While playing with if_bridge today and a pair of Dell PowerConnect >>> 5324's (with the recent upgrade to MSTP) I noticed that it did not seem >>> to be possible to enable STP on if_vlan bridge members. This would seem >>> to be correct as transmitting STP frames tagged with VLAN_ID would seem >>> to break the spec and fall into the realm of cisco PVST. However should >>> if_bridge be taught that the vlandev should be used for collection and >>> transmission spanning tree in this scenario or should if_vlan be taught >>> to copy untagged [R]STP frames onto the vlan interface? >> Would this make it work the same as Cisco PVST? I havnt looked into how >> PVST works but whatever the solution is it would need to interoperate >> with other vendors. Obviously MST support is ideal. Most of the code is >> already there in the form of RSTP, and MST tacks a bit more info on the >> end. To be honest I have found 802.1Q-2003 a bit unclear in this area. >> >> > > AFAIK, Cisco PVST is the predecessor of 802.1Q MSTP. If I remember > correctly one of the notable differences between the two is that with > Cisco PVST BPDUs are send for every spanning tree instance (also > tagged?) while with 802.1Q MSTP all information is contained in the > per instance M-records (MSTI Configuration Messages) in a single BPDU, > and BPDUs are only sent in instance 0. > > cheers, > Shteryana Yes this seems correct from what I have read, there is an instance for every VLAN, and BPDU's are transmitted tagged on each VLAN. In MST instance 0 is the default instance and RSTP BPDU's are transmitted untagged on the interface, other instance data is attached to the instance 0 BPDU's as described. Tom From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 09:34:52 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2262016A418 for ; Tue, 4 Sep 2007 09:34:52 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by mx1.freebsd.org (Postfix) with ESMTP id D7DF713C459 for ; Tue, 4 Sep 2007 09:34:51 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so677894wra for ; Tue, 04 Sep 2007 02:34:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=WcNt+SfPMW31Ti+pXpGau9D6gJgDi05gudawt30+7mV3l6prhk0/Y7mtCK3Lq8ca4yidzHAvrK5kJsztdIByX45+0KYMiFeELmwqE+aEeKLFvw1mEQnsn5oq3HKtX6fcB5EMklTsgBKdhhgmwS1PZ5dHD66PSaN8ok5gkCp5l0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=D8Pc5gAdcfUCVuC6przP6/uY7utOM7DlV+ZIK5mtpKE6gJ9ssRrAEheefuUB+uItnMECkt0v6KWuiXW9lI1oBhYU1Z7/7bLhkBupfws5YXfC4giSrv0fnL4/rnvAhlkWZBjiLbCqTP181QxOFUDgZ9GkKBb6JROaQnE0Ap254VU= Received: by 10.90.66.9 with SMTP id o9mr4932801aga.1188898489458; Tue, 04 Sep 2007 02:34:49 -0700 (PDT) Received: by 10.90.114.13 with HTTP; Tue, 4 Sep 2007 02:34:48 -0700 (PDT) Message-ID: Date: Tue, 4 Sep 2007 12:34:49 +0300 From: "Ivo Vachkov" To: freebsd-net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Network stack locking 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, 04 Sep 2007 09:34:52 -0000 Hello all, I'm currently working on some ipv6 related code. At some point I have to do a routing lookup and I meet following problem: panic: mtx_lock() of spin mutex 'some_strange_chars' ../../../net/route.c:114 cpuid = 0 KDB: enter: panic [thread pid 17 tid 100021 ] Stopped at kdb_enter+0x31: leave According to the debugger the events happen in the following order: ether_demux() at ether_demux+ my_func() at my_func+ rtalloc_ign() at rtalloc_ign+ _mtx_lock_flags() at _mtx_lock_flags+ panic() at panic+ I do not include GIANT_REQUIRED in my code. Can you propose a solution or a pointer to information where I can make myself familiar with the networking code locking ... besides 'man 9 locking' and related. Thank you very much in advance. Ivo From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 09:49:20 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7C7416A418 for ; Tue, 4 Sep 2007 09:49:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7B7D913C491 for ; Tue, 4 Sep 2007 09:49:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 21CD327053; Tue, 4 Sep 2007 05:49:20 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 04 Sep 2007 05:49:20 -0400 X-Sasl-enc: CCJL+BdFrp1XXx3WT5aEivQ28jBk1AFJW57wKfvvbgHY 1188899359 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id A03863472; Tue, 4 Sep 2007 05:49:19 -0400 (EDT) Message-ID: <46DD2A1E.3060109@FreeBSD.org> Date: Tue, 04 Sep 2007 10:49:18 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Ivo Vachkov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Network stack locking 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, 04 Sep 2007 09:49:20 -0000 Ivo Vachkov wrote: > panic: mtx_lock() of spin mutex 'some_strange_chars' ../../../net/route.c:114 > > ether_demux() at ether_demux+ > my_func() at my_func+ > rtalloc_ign() at rtalloc_ign+ > _mtx_lock_flags() at _mtx_lock_flags+ > panic() at panic+ > > I do not include GIANT_REQUIRED in my code. Can you propose a solution > or a pointer to information where I can make myself familiar with the > networking code locking ... besides 'man 9 locking' and related. > It really isn't as simple as 'read this doc' because the code is subject to change - the code *is* the reference - it is constantly evolving. If you want to contribute docs, please feel free, Robert may have something lying around. How is ether_demux() calling your function, and does ether_input() appear in this call trace? This is counterintuitive and I don't really have enough data to go on. Looking at the code, it seems your backtrace hits the RTFREE() call when trying to allocate an rtentry through rtalloc_ign(), are you attempting to cache the results of a previous call which may still be locked? On a more general note. I suggest is that you *do not* hold any locks when calling ether_demux() for whatever reason. I wouldn't recommend calling that function directly - the only things outside of the ethernet paths which do this are dummynet and netgraph. tap(4) doesn't - it dispatches through ether_input(). When re-entering the bottom of the stack in this way, you *should not* hold any locks. rtalloc_ign() currently acquires a lock on its rtentry by default, please release it before reentering the bottom half of the network stack. regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 10:11:09 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15DA916A419; Tue, 4 Sep 2007 10:11:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id B5A6B13C442; Tue, 4 Sep 2007 10:11:08 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 4F52527901; Tue, 4 Sep 2007 06:11:08 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 04 Sep 2007 06:11:08 -0400 X-Sasl-enc: E16zLfizDHRJDkAf1z5g2HPRSj86TXYTL1FjAfCQGZJ/ 1188900667 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 9B8833470; Tue, 4 Sep 2007 06:11:07 -0400 (EDT) Message-ID: <46DD2F3A.20904@FreeBSD.org> Date: Tue, 04 Sep 2007 11:11:06 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Alfred Perlstein References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> <46DC1E51.3040707@FreeBSD.org> <20070903201133.GU87451@elvis.mu.org> In-Reply-To: <20070903201133.GU87451@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , net@freebsd.org Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 10:11:09 -0000 Alfred Perlstein wrote: >> Can you merge them into the list in such a way that AF_MAX does not need >> to slide forward? >> Or do they need to be referenced from within the kernel tree itself? >> > > They are refenced inside the kernel. > Let me rephrase that: are protocol domains attached in the kernel using these constants? Pull an AF_MAX 'referenced from' list from kscope or fxr.watson.org and you'll see what I mean - we use this constant in a LOT of places, particularly in the socket path, it is used to bound loops and allocate static array space. 1 extra slot won't make much difference, 20 will -- and this is why it's an invasive change. >> Prevention of code bloat is better than the cure. Not having the code >> in front of me I couldn't say for sure if we're talking about a dozen >> bytes or several pages potentially being wasted, so it is impossible to >> judge. >> > > Well, for the most part it's going to be something like 32*sizeof(void*) > so 128 or 256 bytes depending on arch. > Adding bloat to ifnet is far from ideal. It isn't a show stopper for most use cases, but there are folk out there who use FreeBSD as a VPN access concentrator, and creating 10,000 ifnets for their purposes is not out of the question for them. There is also the case of smaller embedded systems. It might not seem like a lot now, but it could be a show stopper for some. >> One of my concerns is that we have ifnet.if_afdata, we're not really >> using it, it makes sense to use it for some things. >> > > I'll have ot look into this. > To give examples: Consider for example the case of the 'router_info' structure in IGMP. Its relationship cardinality w.r.t struct ifnet is 1:1 - for each ifnet, there is a router_info - but only if AF_INET is attached to that ifnet. This is where if_afdata is typically used. I would like to take the per-link IPv4 stack structures and hang them off ifnet directly. Reasons: 1. Lazy allocation of router_info leads to potential races in igmp. These are worked around by constantly checking if a struct is allocated or deallocated upon any reference to them. Easy to do in C++. Tedious and error prone in C. The struct also needs to be garbage collected when an ifnet goes away. 2. We can potentially move protocol domain addresses for upper layers into their own struct. We don't lock a global address list every time we perform an address operation. 3. Right now, we can't detach and re-attach protocol stacks to ifnets. A number of folks are affected, particularly for IPv6, where there are perfectly legitimate reasons to bounce the stack in this way, say, link-local addresses get screwed up, or even just need to be enabled. > As you can see we are defering the "bloat". > Does that make sense? > I follow but it still doesn't really make sense. Granted, you are deferring the growth of arrays sized off AF_MAX but only ever by 1 slot. What if Vendor Z wants to add 25 entries at once? We would also be tying ourselves down to the notion of a vendor in any AF_ allocation. Is this an avenue that people are happy to pursue? regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 11:03:49 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 153DB16A417; Tue, 4 Sep 2007 11:03:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B57C513C459; Tue, 4 Sep 2007 11:03:48 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=anWJP+6YKt7MnlnkK4O6UjlkR2hMnkQUONFghgvfkBDWxd4do5zlohY6Nv3ZTgjeav4roIsWzLUuQKJ03D8Ksns9tduSluD2mlVp57WgILaK6Lguj9GvAfbC/+6L99aePgJVDhVUfeva1kEeahGhP3yPK/MQ3BbZybtsY73+eZ0=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1ISVug-0005gH-Fy; Tue, 04 Sep 2007 14:45:42 +0400 Date: Tue, 4 Sep 2007 14:45:37 +0400 From: Eygene Ryabinkin To: Shteryana Shopova Message-ID: <20070904104537.GQ31819@void.codelabs.ru> References: <46DC081F.6010203@tomjudge.com> <20070903173435.GA9902@heff.fud.org.nz> <46DC7AD0.4080800@tomjudge.com> <20070903210005.GA14592@heff.fud.org.nz> <61b573980709040107t490632far990da52e5bfea3a1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <61b573980709040107t490632far990da52e5bfea3a1@mail.gmail.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: Tom Judge , Andrew Thompson , net@freebsd.org Subject: Re: If_bridge and MST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 11:03:49 -0000 Good day. Tue, Sep 04, 2007 at 11:07:22AM +0300, Shteryana Shopova wrote: > AFAIK, Cisco PVST is the predecessor of 802.1Q MSTP. If I remember > correctly one of the notable differences between the two is that with > Cisco PVST BPDUs are send for every spanning tree instance (also > tagged?) while with 802.1Q MSTP all information is contained in the > per instance M-records (MSTI Configuration Messages) in a single BPDU, > and BPDUs are only sent in instance 0. Yeah, according to http://www.cisco.com/warp/public/473/147.html this looks correct. Though I am not sure that BPDUs are sent only in the IST, but I can be wrong. -- Eygene From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 11:17:56 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CA7D16A420; Tue, 4 Sep 2007 11:17:56 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1458F13C4CA; Tue, 4 Sep 2007 11:17:56 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l84BHtMT070674; Tue, 4 Sep 2007 11:17:55 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l84BHt6G070670; Tue, 4 Sep 2007 11:17:55 GMT (envelope-from remko) Date: Tue, 4 Sep 2007 11:17:55 GMT Message-Id: <200709041117.l84BHt6G070670@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 11:17:56 -0000 Synopsis: 6.2-STABLE panic during use of multi-cast networking client Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Tue Sep 4 11:17:55 UTC 2007 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=116077 From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 12:45:18 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F71F16A419; Tue, 4 Sep 2007 12:45:18 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4BD4B13C45B; Tue, 4 Sep 2007 12:45:18 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 514011A4D9B; Tue, 4 Sep 2007 05:42:24 -0700 (PDT) Date: Tue, 4 Sep 2007 05:42:24 -0700 From: Alfred Perlstein To: "Bruce M. Simpson" Message-ID: <20070904124224.GF87451@elvis.mu.org> References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> <46DC1E51.3040707@FreeBSD.org> <20070903201133.GU87451@elvis.mu.org> <46DD2F3A.20904@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DD2F3A.20904@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Max Laier , net@freebsd.org Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 12:45:18 -0000 * Bruce M. Simpson [070904 03:08] wrote: > >As you can see we are defering the "bloat". > >Does that make sense? > > > > I follow but it still doesn't really make sense. > > Granted, you are deferring the growth of arrays sized off AF_MAX but > only ever by 1 slot. > What if Vendor Z wants to add 25 entries at once? Then as long as they allocate odd numbered entries they should be fine. FreeBSD's AF_MAX does not need to change to accomidate a vendor, it only has to restrict itself to even numbered slots. > We would also be tying ourselves down to the notion of a vendor in any > AF_ allocation. Is this an avenue that people are happy to pursue? Yes, until the "horrific" problem of the statically sized arrays is "fixed". Then the allocation policy can change. -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 13:13:28 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76E3C16A417 for ; Tue, 4 Sep 2007 13:13:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id AF12D13C45A for ; Tue, 4 Sep 2007 13:13:26 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 90085 invoked from network); 4 Sep 2007 13:01:10 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Sep 2007 13:01:10 -0000 Message-ID: <46DD59F9.1080107@freebsd.org> Date: Tue, 04 Sep 2007 15:13:29 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Rui Paulo References: <46DCB831.3030207@fnop.net> In-Reply-To: <46DCB831.3030207@fnop.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Killing IPTOS_CE and IPTOS_ECT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 13:13:28 -0000 Rui Paulo wrote: > Hi, > I'm working on TCP ECN support and I would like to kill these defines > from netinet/ip.h > > #if 1 > /* ECN RFC3168 obsoletes RFC2481, and these will be deprecated soon. */ > #define IPTOS_CE 0x01 > #define IPTOS_ECT 0x02 > #endif > > The are outdated and should no longer be used because that RFC has been > obsoleted. RFC 3168 uses a bit different bits: > #define IPTOS_ECN_NOTECT 0x00 /* not-ECT */ > #define IPTOS_ECN_ECT1 0x01 /* ECN-capable transport (1) */ > #define IPTOS_ECN_ECT0 0x02 /* ECN-capable transport (0) */ > #define IPTOS_ECN_CE 0x03 /* congestion experienced */ > #define IPTOS_ECN_MASK 0x03 /* ECN field mask */ > > The only consumer of the RFC 2481 defines is sbin/ipfw/ipfw2.c and > luigi@ accepted the attached patch. > > Does anyone have any objection against the removal ? No. Please produce a complete unified diff patch including both the changes to ip.h and ipfw2.c, a sufficiently verbose commit message, the result a complete make universe build run with the patch applied to otherwise clean sources and send it to re@ and me in CC. If approved I commit it for you. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 13:20:06 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DE0916A419 for ; Tue, 4 Sep 2007 13:20:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 87CAD13C468 for ; Tue, 4 Sep 2007 13:20:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l84DK6eM077446 for ; Tue, 4 Sep 2007 13:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l84DK6nr077445; Tue, 4 Sep 2007 13:20:06 GMT (envelope-from gnats) Date: Tue, 4 Sep 2007 13:20:06 GMT Message-Id: <200709041320.l84DK6nr077445@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bruce M Simpson Cc: Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce M Simpson List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 13:20:06 -0000 The following reply was made to PR kern/116077; it has been noted by GNATS. From: Bruce M Simpson To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client Date: Tue, 04 Sep 2007 14:17:53 +0100 I wrote this, but I may not have time to fix it, because I need to do work other than FreeBSD to support myself. I have no idea what an elvin or avis is. It isn't clear to me how you are triggering this panic, it looks like you are removing or tearing down interfaces from the system? Are you using a network driver which has IFF_NEEDSGIANT set? Unfortunately because the ifp lock has to be taken before other locks if IFF_NEEDSGIANT is set, it dereferences the ifp provided which may have already gone away. The link layer multicast code will try to invalidate the ifp pointer in the underlying ifma. However in this case the cached ifp used is the one in struct in_multi. Try the following. Change 1063 ifp = inm->inm_ifp; 1064 IFF_LOCKGIANT(ifp); 1065 IN_MULTI_LOCK(); ... to ifp = inm->inm_ifma->ifp; if (ifp != NULL) IFF_LOCKGIANT(ifp); ... and put if (ifp != NULL) IFF_UNLOCKGIANT(ifp); at the end of the function. It is safe to deref inm->inm_ifma as ifma is refcounted. The real fix is to either eliminate Giant completely or to implement reference counting for struct ifnet. I should point out that this code gets rewritten for IGMPv3. Please let me know if this works around the issue. If it doesn't, I'll leave it to someone else for now - there should be enough in here to go on. From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 14:15:25 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86B3516A419 for ; Tue, 4 Sep 2007 14:15:25 +0000 (UTC) (envelope-from dailydose@siliconindia.org) Received: from siliconindia.org (mail.siliconindia.org [72.52.77.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6F30613C428 for ; Tue, 4 Sep 2007 14:15:25 +0000 (UTC) (envelope-from dailydose@siliconindia.org) Received: from siliconindia.org (localhost.localdomain [127.0.0.1]) by siliconindia.org (Postfix) with ESMTP id 5EBD82C4E4 for ; Tue, 4 Sep 2007 06:27:29 -0700 (PDT) Received: (from dailydose@localhost) by siliconindia.org (8.13.1/8.13.1/Submit) id l84DRSGv025332; Tue, 4 Sep 2007 06:27:28 -0700 To: freebsd-net@freebsd.org Date: Tue, 4 Sep 2007 06:27:28 -0700 From: si dailydose Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.73] Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Advance IST by 30 minutes, save Rs.10 bn: scientists/Kalyani to acquire German wind firm/GAIL seeks nod for pipeline gas in 230 cities X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dailydose@siliconindia.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2007 14:15:25 -0000 SiliconIndia Daily Dose | September 04 2007 >> TOP NEWS [1]Advance IST by 30 minutes, save Rs.10 bn: scientists A group of scientists have suggested that the Indian Standard Time (IST) be shifted forward by 30 minutes to reduce peak time energy demand and save at least Rs.10 billion per year. [2]Kalyani to acquire German wind firm The Kalyani Group has stepped up its presence in the wind power sector with the acquisition of Germany's wind turbine maker RSBconsult GmbH. [3]GAIL seeks nod for pipeline gas in 230 cities State-run gas distribution and exploration major Gas Authority of India Ltd (GAIL) has sought the government's nod for supplying pipeline gas in 230 cities across the country. >> TECHNOLOGY [4]GE keen to invest in Bengal infrastructure projects GE Equipment Services, the US-based diversified services, technology and manufacturing company, has evinced interest to invest in West Bengal's infrastructure sector. [5]Intoto sets new 16 Gbps Firewall performance record Intoto announced that its iGateway Firewall has set a new industry performance standard as the first firewall to deliver up to 16 Gigabits per second (Gbps). >> BUSINESS [6]OPI named the FAO vendor for middle-market Companies OPI, a professional services firm , announced that it has been selected as FAO vendor for middle-market companies for the second consecutive year. [7]Air India to operate more international flights from Kolkata Air India will soon operate more international flights from Kolkata and replace its Boeing aircraft with Airbus to connect most of the important capital cities in the northeast. >> OTHER NEWS [8]Every second Punjabi now has a phone! Punjab, after green revolution is now undergoing another one, this time in telecommunications with every second resident having a telephone - be it mobile or landline. [9]Chennai company to import garbage bins The city-based private garbage clearance company Neel Metal Fanalca Environment has decided to import garbage bins from Bangkok to install in the three Chennai corporation zones. >> BLOGS [10]Glamour world or Drugs world - [11]Gitika Roy Today most of the teenagers have only one ambitious in their mind to become rich and popular as the earliest. The best way for it is the glamor world. Increasing number of model hunt has just added fire.... MAGAZINE [12]Cover Story [13][cvr_si.jpg] GCI's client-centric approach and best-shore strategy. Also siliconindia 10th Anniversary Special. SiliconIndia Books [14]The Man Who Divided India [15][mandivede.jpg] Even after the lapse of over fifty years, the question of how and why India was divided remains unresolved. [16]Buy Now [17]Ayurveda [18][Ayurveda_LHealth.jpg] Ayurveda treats not just the ailment but the whole person and emphasizes prevention of disease to avoid the need for cure... [19]Buy Now [20]Click Here If you are siliconindia network member and do not want to receive daily dose, please select "unsubscribe" from your setting page when you log in. If you are not a member,[21] visit here to stop receiving daily dose. References Visible links 1. http://www.siliconindia.com/shownews/36868 2. http://www.siliconindia.com/shownews/36876 3. http://www.siliconindia.com/shownews/36874 4. http://www.siliconindia.com/shownews/36866 5. http://www.siliconindia.com/shownews/36872 6. http://www.siliconindia.com/shownews/36871 7. http://www.siliconindia.com/shownews/36867 8. http://www.siliconindia.com/shownews/36869 9. http://www.siliconindia.com/shownews/36873 10. http://blogs.siliconindia.com/gitika 11. http://blogs.siliconindia.com/gitika 12. http://www.siliconindia.com/magazine/ 13. http://www.siliconindia.com/magazine/ 14. http://www.siliconindia.com/books/newbooks/booksdetails/1349 15. http://www.siliconindia.com/books/newbooks/booksdetails/1349 16. http://www.siliconindia.com/books/newbooks/booksdetails/1349 17. http://www.siliconindia.com/books/newbooks/booksdetails/561 18. http://www.siliconindia.com/books/newbooks/booksdetails/561 19. http://www.siliconindia.com/books/newbooks/booksdetails/561 20. http://a.tribalfusion.com/i.click?site=siliconindiacom&adSpace=ROS&size=728x90&requestID=1658934770 21. http://www.siliconindia.com/newsletter/remove.php Hidden links: 22. http://www.chugh.com/ 23. http://www.india.amazon.com/ From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 18:22:44 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 220D716A41A; Tue, 4 Sep 2007 18:22:44 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 8765113C4D0; Tue, 4 Sep 2007 18:22:43 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 66C30690FA0; Tue, 4 Sep 2007 19:27:11 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id F0C7C691095; Tue, 4 Sep 2007 19:27:10 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from epsilon.local (62.169.122.58.rev.optimus.pt [62.169.122.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id 7E126690FA0; Tue, 4 Sep 2007 19:27:06 +0100 (WEST) Message-ID: <46DDA265.2090500@fnop.net> Date: Tue, 04 Sep 2007 19:22:29 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Andre Oppermann References: <46DCB831.3030207@fnop.net> <46DD59F9.1080107@freebsd.org> In-Reply-To: <46DD59F9.1080107@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org Subject: Re: Killing IPTOS_CE and IPTOS_ECT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 18:22:44 -0000 Andre Oppermann wrote: > Rui Paulo wrote: >> Hi, >> I'm working on TCP ECN support and I would like to kill these defines >> from netinet/ip.h >> >> #if 1 >> /* ECN RFC3168 obsoletes RFC2481, and these will be deprecated soon. */ >> #define IPTOS_CE 0x01 >> #define IPTOS_ECT 0x02 >> #endif >> >> The are outdated and should no longer be used because that RFC has >> been obsoleted. RFC 3168 uses a bit different bits: >> #define IPTOS_ECN_NOTECT 0x00 /* not-ECT */ >> #define IPTOS_ECN_ECT1 0x01 /* ECN-capable transport (1) */ >> #define IPTOS_ECN_ECT0 0x02 /* ECN-capable transport (0) */ >> #define IPTOS_ECN_CE 0x03 /* congestion experienced */ >> #define IPTOS_ECN_MASK 0x03 /* ECN field mask */ >> >> The only consumer of the RFC 2481 defines is sbin/ipfw/ipfw2.c and >> luigi@ accepted the attached patch. >> >> Does anyone have any objection against the removal ? > > No. Please produce a complete unified diff patch including both > the changes to ip.h and ipfw2.c, a sufficiently verbose commit > message, the result a complete make universe build run with the > patch applied to otherwise clean sources and send it to re@ and > me in CC. If approved I commit it for you. Well, I was asking for comments regarding on the usage of these flags. I was hoping to commit ip.h along with TCP ECN. This doesn't really need to be before the branch, I think. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 19:26:13 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 093B016A41A for ; Tue, 4 Sep 2007 19:26:13 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id D33A413C442 for ; Tue, 4 Sep 2007 19:26:12 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 7128E270E3; Tue, 4 Sep 2007 15:26:12 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 04 Sep 2007 15:26:12 -0400 X-Sasl-enc: BVEE+jQ2u8VEpk7axdheUMR3slRhzSqxSDby+UGWvycZ 1188933972 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id D8F5B17806; Tue, 4 Sep 2007 15:26:11 -0400 (EDT) Message-ID: <46DDB153.6040909@FreeBSD.org> Date: Tue, 04 Sep 2007 20:26:11 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Rui Paulo References: <46DCB831.3030207@fnop.net> <46DD59F9.1080107@freebsd.org> <46DDA265.2090500@fnop.net> In-Reply-To: <46DDA265.2090500@fnop.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: Killing IPTOS_CE and IPTOS_ECT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 19:26:13 -0000 Rui Paulo wrote: > Well, I was asking for comments regarding on the usage of these flags. > I was hoping to commit ip.h along with TCP ECN. > > This doesn't really need to be before the branch, I think. Looks fine to me. ECN would be a useful feature to have. AFAIK nothing else uses these flags. Although I do remember it being possible to fingerprint Solaris boxes based on their response to the ECN Echo, this was around 6 years ago. I second Andre's request for a full unified diff if you want it to go in ASAP. regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 19:42:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE7CC16A469; Tue, 4 Sep 2007 19:42:01 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC8413C47E; Tue, 4 Sep 2007 19:42:00 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id 7F251690FA0; Tue, 4 Sep 2007 20:46:28 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 3BD4369105F; Tue, 4 Sep 2007 20:46:28 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from epsilon.local (62.169.122.58.rev.optimus.pt [62.169.122.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by core.fnop.net (Postfix) with ESMTP id EF11C690FA0; Tue, 4 Sep 2007 20:46:24 +0100 (WEST) Message-ID: <46DDB4FC.5050505@fnop.net> Date: Tue, 04 Sep 2007 20:41:48 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <46DCB831.3030207@fnop.net> <46DD59F9.1080107@freebsd.org> <46DDA265.2090500@fnop.net> <46DDB153.6040909@FreeBSD.org> In-Reply-To: <46DDB153.6040909@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: Killing IPTOS_CE and IPTOS_ECT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 19:42:01 -0000 Bruce M. Simpson wrote: > Rui Paulo wrote: >> Well, I was asking for comments regarding on the usage of these flags. >> I was hoping to commit ip.h along with TCP ECN. >> >> This doesn't really need to be before the branch, I think. > > Looks fine to me. ECN would be a useful feature to have. AFAIK nothing > else uses these flags. I have TCP ECN support diff's against CURRENT. I just need to test that everything works as expected. I'll mail -net after that. > Although I do remember it being possible to fingerprint Solaris boxes > based on their response to the ECN Echo, this was around 6 years ago. > > I second Andre's request for a full unified diff if you want it to go in > ASAP. Ok. Thanks. Regards. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 20:35:56 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1203216A41B for ; Tue, 4 Sep 2007 20:35:56 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: from web43144.mail.sp1.yahoo.com (web43144.mail.sp1.yahoo.com [216.252.121.74]) by mx1.freebsd.org (Postfix) with SMTP id F0ECA13C4B7 for ; Tue, 4 Sep 2007 20:35:55 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: (qmail 74293 invoked by uid 60001); 4 Sep 2007 20:35:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=sCPVIudNn9TreBZfkp8GJeVjn+CToCi5JtOZ3GbDPXcP3bBfyHjnjlWDFv6Ao5D07cMszQcss7E1ZVNOfVFEgY/fvYFBEN0rF8IrUzbZeb/mlw+XuWh3MDDfRGmKJeVsSng3SPEbs4HbH2ntYMLQqgkCdCewjARqDlYLF6nePz4=; Received: from [69.147.84.253] by web43144.mail.sp1.yahoo.com via HTTP; Tue, 04 Sep 2007 13:35:49 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Tue, 4 Sep 2007 13:35:49 -0700 (PDT) From: Weiguang Shi To: Gleb Smirnoff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <396207.74117.qm@web43144.mail.sp1.yahoo.com> Cc: maxim@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: questions wrt ng_netflow X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 20:35:56 -0000 Thanks! That all make sense.=0A=0AWei=0A=0A----- Original Message ----=0AFr= om: Gleb Smirnoff =0ATo: Weiguang Shi =0ACc: maxim@FreeBSD.org; freebsd-net@FreeBSD.org=0ASent: Saturday, Sept= ember 1, 2007 1:51:38 AM=0ASubject: Re: questions wrt ng_netflow=0A=0A Wei= guang,=0A=0A sorry for late answer, I'm too loaded with daytime job.=0A=0A= On Thu, Aug 23, 2007 at 09:40:30AM -0700, Weiguang Shi wrote:=0AW> I've bee= n reading netlfow.c in FreeBSD-6.2 and this piece of code confuses me.=0AW= > 484 /*=0AW> 485 * Go through hash and fi= nd our entry. If we encounter an=0AW> 486 * entry, that sh= ould be expired, purge it. We do a reverse=0AW> 487 * sear= ch since most active entries are first, and most=0AW> 488 = * searches are done on most active entries.=0AW> 489 */=0A= W> 490 TAILQ_FOREACH_REVERSE_SAFE(fle, &hsh->head, fhead, f= le_hash, fle1) {=0AW> 491 if (bcmp(&r, &fle->f.r, s= izeof(struct flow_rec)) =3D=3D 0)=0AW> 492 = break;=0AW> 493 if ((INACTIVE(fle) && SMALL(fle)) |= | AGED(fle)) {=0AW> 494 TAILQ_REMOVE(&hsh->= head, fle, fle_hash);=0AW> 495 expire_flow(= priv, &item, fle, NG_QUEUE);=0AW> 496 atomi= c_add_32(&priv->info.nfinfo_act_exp, 1);=0AW> 497 }= =0AW> 498 }=0AW> =0AW> +-------------+ +--------+ = +--------+ +--------+ +--------+=0AW> | Bucket Head |---= -->| RecA |----->| RecB |----->| RecC |----->| RecD |=0AW> +---= ----------+ +--------+ +--------+ +--------+ +--------+= =0AW> =0AW> In the figure above, let's say our packet matches RecC. So befo= re the=0AW> match, RecD is examined to see if it's AGED, i.e., it's lasted = for too=0AW> long, or if it's too small and inactive. As the match is found= , the=0AW> code stops searching.=0AW> =0AW> First, isn't INACTIVE alone eno= ugh to expire a flow? Why must INACTIVE=0AW> _and_ SMALL?=0A=0ANo. Netflow = engine tries to minimise number of export records sent, and=0Aavoid splitti= ng one long flow into several records. Thus, if we have enough=0Aspace in t= he cache, we keep inactive flows, because they can become active=0Aagain.= =0A=0AFor example, a TCP ssh session, where you have stopped typing and are= =0Areading the text becomes inactive after some time passes. However, it wi= ll=0Acontinue, when you start typeing again.=0A=0AWe make an exclusion for = SMALL flows, to avoid blowing the cache due to=0Acontinuous internet scanni= ng by worms:=0A=0A/*=0A * 4 is a magical number: statistically number of 4-= packet flows is=0A * bigger than 5,6,7...-packet flows by an order of magni= tude. Most UDP/ICMP=0A * scans are 1 packet (~ 90% of flow cache). TCP scan= s are 2-packet in case=0A * of reachable host and 4-packet otherwise.=0A */= =0A#define SMALL(fle) (fle->f.packets <=3D 4)=0A=0AW> RecA and RecB wo= uld not be examined for expiration but since they are=0AW> to the beginning= of the queue and therefore actually less recently=0AW> accessed, they are = more likely to be INACTIVE and could be more AGED.=0AW> I must be missing s= omething, but what justifies examining RecD but not =0AW> RecA and RecB?=0A= =0ABecause we are in the interrupt thread. Our aim is to finish processing= =0Aof one IP packet as fast as possible and return. Our aim is not to expir= e=0Aas much as possible. However we examine the flows that we have just bcm= p()'ed.=0AThese entires are in the CPU's cache, so we can quickly check the= m.=0A=0AThe periodic expiry routine goes through the TAILQ in opposite orde= r,=0Astarting from head, so it accesses the oldest flows earlier.=0A=0A-- = =0ATotus tuus, Glebius.=0AGLEBIUS-RIPN GLEB-RIPE=0A=0A=0A=0A=0A=0A = =0A________________________________________________________________________= ____________=0ATake the Internet to Go: Yahoo!Go puts the Internet in your = pocket: mail, news, photos & more. =0Ahttp://mobile.yahoo.com/go?refer=3D1G= NXIC From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 20:57:49 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C171416A468; Tue, 4 Sep 2007 20:57:49 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id AEF1413C45E; Tue, 4 Sep 2007 20:57:49 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 0E3D91A4D9B; Tue, 4 Sep 2007 13:54:54 -0700 (PDT) Date: Tue, 4 Sep 2007 13:54:54 -0700 From: Alfred Perlstein To: Randall Stewart Message-ID: <20070904205454.GY87451@elvis.mu.org> References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> <46DC1E51.3040707@FreeBSD.org> <20070903201133.GU87451@elvis.mu.org> <46DD2F3A.20904@FreeBSD.org> <20070904124224.GF87451@elvis.mu.org> <46DDB9E9.4010408@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DDB9E9.4010408@cisco.com> User-Agent: Mutt/1.4.2.3i Cc: Max Laier , "Bruce M. Simpson" , net@freebsd.org Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 20:57:49 -0000 * Randall Stewart [070904 13:22] wrote: > Alfred Perlstein wrote: > >* Bruce M. Simpson [070904 03:08] wrote: > > > >>>As you can see we are defering the "bloat". > >>>Does that make sense? > >>> > >> > >>I follow but it still doesn't really make sense. > >> > >>Granted, you are deferring the growth of arrays sized off AF_MAX but > >>only ever by 1 slot. > >>What if Vendor Z wants to add 25 entries at once? > > > > > >Then as long as they allocate odd numbered entries they should > >be fine. FreeBSD's AF_MAX does not need to change to accomidate > >a vendor, it only has to restrict itself to even numbered slots. > > > > > >>We would also be tying ourselves down to the notion of a vendor in any > >>AF_ allocation. Is this an avenue that people are happy to pursue? > > > > > >Yes, until the "horrific" problem of the statically sized arrays > >is "fixed". Then the allocation policy can change. > > > > > So basically in this scheme we only have to "stumble" across an > additional slot when we add a new one to FreeBSD.. i.e. some > random vendor may assign 50 slots (in odd numbers) but FreeBSD > would not see the growth until really 2 new AF_XXX's are added. > Then you would have to bump it from by 3, to cover the two > new ones (reserving the vendor specific slots and thus causing > allocations of unused things). YES! Exactly. > > This seems like a reasonable compromise to me... I can't imagine > where we would need to add a lont of new AF_XXX's.. of course > maybe I just lack imagination :-D Well, Freebsd or 5 added bluetooth, and freebsd 7 has some IEEE thing added... sooo... the array is growing, but slowly. -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 21:05:40 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 551ED16A41B; Tue, 4 Sep 2007 21:05:40 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 2900213C474; Tue, 4 Sep 2007 21:05:40 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 04 Sep 2007 13:02:57 -0700 X-IronPort-AV: i="4.20,208,1186383600"; d="scan'208"; a="520363108:sNHT6816829284" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l84K2ui2031800; Tue, 4 Sep 2007 13:02:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l84K2u61022446; Tue, 4 Sep 2007 20:02:56 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 13:02:55 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 13:02:55 -0700 Message-ID: <46DDB9E9.4010408@cisco.com> Date: Tue, 04 Sep 2007 16:02:49 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alfred Perlstein References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> <46DC1E51.3040707@FreeBSD.org> <20070903201133.GU87451@elvis.mu.org> <46DD2F3A.20904@FreeBSD.org> <20070904124224.GF87451@elvis.mu.org> In-Reply-To: <20070904124224.GF87451@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Sep 2007 20:02:55.0735 (UTC) FILETIME=[9565A870:01C7EF2E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1557; t=1188936176; x=1189800176; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Allocating=20AF=20constants=20for=20vendors. |Sender:=20; bh=jvC+CjhDDtAKaoLeWvmv6qxGRv0RttSpfapR0AkrpzQ=; b=UBzXCwTKuft0nEfr+/ikhzts8tAITfh+2OpeCDMfJYH0ENISSox3M7LLWXRdBcIkCtME5MPa 6z+SmtXNqGC/nGV9YncQTWTt5AIie7A7QL3qJiRTjKaKB0g9ku18xnZE; Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Cc: Max Laier , "Bruce M. Simpson" , net@freebsd.org Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Sep 2007 21:05:40 -0000 Alfred Perlstein wrote: > * Bruce M. Simpson [070904 03:08] wrote: > >>>As you can see we are defering the "bloat". >>>Does that make sense? >>> >> >>I follow but it still doesn't really make sense. >> >>Granted, you are deferring the growth of arrays sized off AF_MAX but >>only ever by 1 slot. >>What if Vendor Z wants to add 25 entries at once? > > > Then as long as they allocate odd numbered entries they should > be fine. FreeBSD's AF_MAX does not need to change to accomidate > a vendor, it only has to restrict itself to even numbered slots. > > >>We would also be tying ourselves down to the notion of a vendor in any >>AF_ allocation. Is this an avenue that people are happy to pursue? > > > Yes, until the "horrific" problem of the statically sized arrays > is "fixed". Then the allocation policy can change. > > So basically in this scheme we only have to "stumble" across an additional slot when we add a new one to FreeBSD.. i.e. some random vendor may assign 50 slots (in odd numbers) but FreeBSD would not see the growth until really 2 new AF_XXX's are added. Then you would have to bump it from by 3, to cover the two new ones (reserving the vendor specific slots and thus causing allocations of unused things). This seems like a reasonable compromise to me... I can't imagine where we would need to add a lont of new AF_XXX's.. of course maybe I just lack imagination :-D R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 09:16:47 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAD3816A419 for ; Wed, 5 Sep 2007 09:16:47 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id 6924A13C48A for ; Wed, 5 Sep 2007 09:16:47 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1857203wxd for ; Wed, 05 Sep 2007 02:16:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=piOL0PxJLwYXXBNipNMxM/tu8Cvfx/j42gIvaFENx99q7xMdyI5nASNxdqa4G6Y2WlMtqFeyf73efKW/mgkwrc/STKLgoqte9OY7gPB9i0Uvdgpiay9nxutX4AS2JQ+qK5bSET4I0VzmEYvK77gI/E8iBF8rqmrqdQPvrB+Z9e4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pQ0OSz+87uViMOF8qILQJKu1dBrJ5rpSHYC1UXYIHCB/jP6nKDIC2oJTaQ5eaoy0RKlLK2zH7QbXfUT/bEcBvV6ti0H5valOJNXx7/21sH0u67dGu4fTJtJf1bpC/yGoA6Mmx9lacl/8Oa4RBH4/a4OFWhq7mEDEV3ptZlEH+vI= Received: by 10.90.66.9 with SMTP id o9mr6640713aga.1188983800519; Wed, 05 Sep 2007 02:16:40 -0700 (PDT) Received: by 10.90.114.13 with HTTP; Wed, 5 Sep 2007 02:16:40 -0700 (PDT) Message-ID: Date: Wed, 5 Sep 2007 12:16:40 +0300 From: "Ivo Vachkov" To: freebsd-net In-Reply-To: <46DD2A1E.3060109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46DD2A1E.3060109@FreeBSD.org> Subject: Re: Network stack locking 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: Wed, 05 Sep 2007 09:16:47 -0000 On 9/4/07, Bruce M. Simpson wrote: > > It really isn't as simple as 'read this doc' because the code is subject > to change - the code *is* the reference - it is constantly evolving. If > you want to contribute docs, please feel free, Robert may have something > lying around. > > How is ether_demux() calling your function, and does ether_input() > appear in this call trace? This is counterintuitive and I don't really > have enough data to go on. ether_demux() calls my_func() directly. my_func() can consume the packet or return it to the ether_demux(). ether_input() does not appear in the call trace. > Looking at the code, it seems your backtrace hits the RTFREE() call when > trying to allocate an rtentry through rtalloc_ign(), are you attempting > to cache the results of a previous call which may still be locked? My lookup code looks like the following: struct sockaddr_in6 *dst = NULL; struct route_in6 out_rt; /* ... */ dst = (struct sockaddr_in6 *)&out_rt.ro_dst; bzero(dst, sizeof(*dst)); dst->sin6_len = sizeof(struct sockaddr_in6); dst->sin6_family = AF_INET6; dst->sin6_addr = ip6->ip6_dst; rtalloc((struct route *)&out_rt); > On a more general note. > > I suggest is that you *do not* hold any locks when calling ether_demux() > for whatever reason. I wouldn't recommend calling that function directly > - the only things outside of the ethernet paths which do this are > dummynet and netgraph. tap(4) doesn't - it dispatches through ether_input(). > > When re-entering the bottom of the stack in this way, you *should not* > hold any locks. rtalloc_ign() currently acquires a lock on its rtentry > by default, please release it before reentering the bottom half of the > network stack. i do not call ether_demux() myself > regards, > BMS > thank you for the time and the help. From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 13:12:55 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1601116A469 for ; Wed, 5 Sep 2007 13:12:55 +0000 (UTC) (envelope-from riga.bsd@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC9D13C469 for ; Wed, 5 Sep 2007 13:12:54 +0000 (UTC) (envelope-from riga.bsd@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so1694909nfd for ; Wed, 05 Sep 2007 06:12:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=PQS0vZo2KVMGwi596EB/DzFYWbd6fW0feVockUvhdiegrJy2JusQ5M2EwsvWCEZ6AWxyhr2uyv9/MpDs2y8lrS8SKDoLD9cgrTtuY67Nn0Rt2yw9IZspqpGf2vvIUKGOeF6aoTQxqJAZzFLkbfJPryxjahoy/3ZDp/Cw6baHc0c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mBieGk4Z5wgPU4ThDVSNSngWM3i6QQkA2Q2S+7LQx4qhA7qsyQu8PBqfI5rfzFEIX40QgCadA4pywQbtCLa4/WF8YBxkMK3cXucM/2MGoIx7wYZ7j/jfcwqcuR32Rbxg53/+WV79OQiZJ4xU5514kOq0It1N8ZUFHl0HFs5FNeA= Received: by 10.86.98.18 with SMTP id v18mr5140795fgb.1188997967367; Wed, 05 Sep 2007 06:12:47 -0700 (PDT) Received: by 10.86.74.11 with HTTP; Wed, 5 Sep 2007 06:12:47 -0700 (PDT) Message-ID: Date: Wed, 5 Sep 2007 16:12:47 +0300 From: "lost janis" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: IPsec gif problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Sep 2007 13:12:55 -0000 Hello! I'm apologise about my English I'm using FreeBSD 6.2 with kernel compiled options options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options IPSEC_DEBUG #debug for IP security Ipesec-tools installed portversion 0.7 I'm using PF firewall. I'm feeling already self dumb and fr..out one week spending on this problem and cannot find solution. There is my problem, First GRE tunnel end-point IP address (must be public IPv4) My host A.A.A.A and host B.B.B.B Second Gre tunnel end-point C.C.C.C D.D.D.D (must be public IPv4) IPsec device IP (must be public IPv4) E.E.E.E-F.F.F.F SA - authentication - preshared secret SA cypher 3des-cbc SA encription/authentication ESP SA hash f - md5 1) I tray out making gif device like writ en in to the http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html and nothing - it's does not workout. 2) I put the IP A.A.A.A B.B.B.B e.c.t on real interfaces #my /usr/local/etc/racoon/psk.txt B.B.B.B preshared secret #my /etc/ipsec.conf spdadd A.A.A.A/32 B.B.B.B/32 any -P out ipsec esp/tunnel/A.A.A.A-B.B.B.B/require; spdadd B.B.B.B/32 A.A.A.A/32 any -P in ipsec esp/tunnel/B.B.B.B-A.A.A.A/require; #My /usr/local/etc/racoon/racoon.conf path include "/usr/local/etc/racoon" ; path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; log debug2; # # "padding" defines some parameter of padding. You should not touch these. padding { maximum_length 20; # maximum padding length. randomize off; # enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } listen { isakmp A.A.A.A [500]; } timer { counter 2; # maximum trying count to send. interval 20 sec; # maximum interval to resend. persend 1; # the number of packets per send. phase1 30 sec; phase2 20 sec; } remote anonymous { exchange_mode main,base; my_identifier address A.A.A.A; lifetime time 1 hour ; # sec,min,hour proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key ; dh_group 2 ; } proposal_check strict; } sainfo anonymous { pfs_group 2; lifetime time 12 hour ; encryption_algorithm 3des; authentication_algorithm hmac_md5 ; compression_algorithm deflate ; } And I can not get clear how to tunnel CCCC and EEEE to AAAA-BBBB tunnel to DDDD-FFFF I try to ping #ping -S C.C.C.C D.D.D.D and got reply tcpdump esp C.C.C.C > D.D.D.D ESP(spi=0x199fecdf,seq=0x7), length 116 C.C.C.C > D.D.D.D ESP(spi=0x199fecdf,seq=0x7), length 116 C.C.C.C > D.D.D.D ESP(spi=0x199fecdf,seq=0x7), length 116 C.C.C.C > D.D.D.D ESP(spi=0x199fecdf,seq=0x7), length 116 And when I try just simple ping host D.D.D.D there is no ESP. From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 14:57:55 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 756C016A496 for ; Wed, 5 Sep 2007 14:57:55 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from mail.duras.ro (mail.duras.ro [86.105.56.133]) by mx1.freebsd.org (Postfix) with ESMTP id D7DA713C4CE for ; Wed, 5 Sep 2007 14:57:54 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from localhost (localhost [127.0.0.1]) by mail.duras.ro (Postfix) with ESMTP id A228C16A2BF for ; Wed, 5 Sep 2007 17:34:36 +0300 (EEST) Received: from mail.duras.ro ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10370-03 for ; Wed, 5 Sep 2007 17:34:34 +0300 (EEST) Received: from [86.105.56.194] (ma.plimb.cu.barca.prin.padure.ro [86.105.56.194]) by mail.duras.ro (Postfix) with ESMTP id E93E69B93 for ; Wed, 5 Sep 2007 17:34:34 +0300 (EEST) Message-ID: <46DEBEA7.1020201@duras.ro> Date: Wed, 05 Sep 2007 17:35:19 +0300 From: Mihai Tanasescu User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (RedHat) at duras.ro Subject: Freebsd MPD PPTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Sep 2007 14:57:55 -0000 Hello, I'm using MPD4 to establish a PPTP VPN from my FreeBSD 6.2 server to some clients and I've started encountering some strange problems. The connection goes well, everything functions accordingly but after a while (very random, can be 5 minutes, 1 hour, 8 hours) I loose connectivity (the clients' Windows icon show packet are being sent, but nothing is received). A tcpdump on the external interface shows no packets going out and the same for tcpdump on ng0 (although I'm not sure if it should display something here). For what I've seen the ip address on the ng0 interface disappears. My config looks like the following: FreeBSD cs.duras.ro 6.2-RELEASE FreeBSD 6.2-RELEASE #0 - standard kernel - rc.conf: mpd_enable="YES" mpd.conf pptp1: new -i ng0 pptp1 pptp1 set iface disable proxy-arp set ipcp ranges 192.168.1.129/32 192.168.1.130/32 set iface route 192.168.1.130/32 load pptp_standard pptp_standard: set iface idle 0 set iface disable on-demand set iface enable tcpmssfix set bundle disable multilink set bundle enable compression set bundle enable noretry set bundle max-logins 0 set link no pap chap set link enable chap set link keep-alive 0 0 // tried before with 10 and 60 and now I've disabled the keepalives set link max-redial -1 set link yes acfcomp protocomp set link enable chap-md5 chap-msv1 chap-msv2 chap set link mtu 1460 set link mtu 1460 //here I also tried without these set link mru 1460 // here I also tried without these set link latency 0 set ipcp dns dns-ip-address set ipcp yes vjcomp set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set pptp disable delayed-ack mpd.links pptp1: set link type pptp set pptp self my-server-ip-address set pptp enable incoming set pptp disable originate set pptp disable windowing I'm also using pf for NAT: scrub in all fragment reassemble no-df max-mss 1452 #nonat = local table with lan ip addresses nat on $ext_if from 192.168.1.128/25 to ! -> ($ext_if) I get no packet errors during the communication. Can anyone help in debugging this ? Thanks, Mihai From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 15:16:58 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2AC516A419 for ; Wed, 5 Sep 2007 15:16:58 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id A5C7113C45D for ; Wed, 5 Sep 2007 15:16:58 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 0679227AE3; Wed, 5 Sep 2007 11:16:23 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 05 Sep 2007 11:16:24 -0400 X-Sasl-enc: 8wcTIXyjf3mra5ozYPBdz8ZVdirisu0cZ6kBq/YKKFWP 1189004905 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 9DAAB4478; Wed, 5 Sep 2007 11:08:25 -0400 (EDT) Message-ID: <46DEC668.50509@FreeBSD.org> Date: Wed, 05 Sep 2007 16:08:24 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Ivo Vachkov References: <46DD2A1E.3060109@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: Re: Network stack locking 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: Wed, 05 Sep 2007 15:16:58 -0000 Ivo Vachkov wrote: > My lookup code looks like the following: > > struct sockaddr_in6 *dst =3D NULL; > struct route_in6 out_rt; > > /* ... */ > > dst =3D (struct sockaddr_in6 *)&out_rt.ro_dst; > bzero(dst, sizeof(*dst)); > dst->sin6_len =3D sizeof(struct sockaddr_in6); > dst->sin6_family =3D AF_INET6; > dst->sin6_addr =3D ip6->ip6_dst; > > rtalloc((struct route *)&out_rt); > =20 You need to remember to drop the lock which rtalloc() acquires on your=20 behalf using RTFREE() before leaving the function or possibly calling a=20 function which needs exclusive/write access to the rtentry. If your code needs this rtentry to remain in the system, a call to=20 RT_ADDREF() with the lock held may be necessary, although you should=20 remember to RT_REMREF() with the lock held when done with the rtentry. See =ABnet/route.h=BB for more info. regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 16:10:44 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 847B616A41B for ; Wed, 5 Sep 2007 16:10:44 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from mail.duras.ro (mail.duras.ro [86.105.56.133]) by mx1.freebsd.org (Postfix) with ESMTP id 0831D13C481 for ; Wed, 5 Sep 2007 16:10:43 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from localhost (localhost [127.0.0.1]) by mail.duras.ro (Postfix) with ESMTP id 6CEF116756A; Wed, 5 Sep 2007 19:10:29 +0300 (EEST) Received: from mail.duras.ro ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12578-01; Wed, 5 Sep 2007 19:10:27 +0300 (EEST) Received: from [86.105.56.194] (ma.plimb.cu.barca.prin.padure.ro [86.105.56.194]) by mail.duras.ro (Postfix) with ESMTP id A5BB2CDD; Wed, 5 Sep 2007 19:10:27 +0300 (EEST) Message-ID: <46DED51F.9080809@duras.ro> Date: Wed, 05 Sep 2007 19:11:11 +0300 From: Mihai Tanasescu User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Mihai Tanasescu References: <46DEBEA7.1020201@duras.ro> In-Reply-To: <46DEBEA7.1020201@duras.ro> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (RedHat) at duras.ro Cc: freebsd-net@freebsd.org Subject: Re: Freebsd MPD PPTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Sep 2007 16:10:44 -0000 Mihai Tanasescu wrote: > Hello, > > > I'm using MPD4 to establish a PPTP VPN from my FreeBSD 6.2 server to > some clients and I've started encountering some strange problems. > > The connection goes well, everything functions accordingly but after a > while (very random, can be 5 minutes, 1 hour, 8 hours) I loose > connectivity (the clients' Windows icon show packet are being sent, > but nothing is received). A tcpdump on the external interface shows no > packets going out and the same for tcpdump on ng0 (although I'm not > sure if it should display something here). > > For what I've seen the ip address on the ng0 interface disappears. > > My config looks like the following: > > FreeBSD cs.duras.ro 6.2-RELEASE FreeBSD 6.2-RELEASE #0 > > - standard kernel > - rc.conf: mpd_enable="YES" > > > mpd.conf > pptp1: > new -i ng0 pptp1 pptp1 > set iface disable proxy-arp > set ipcp ranges 192.168.1.129/32 192.168.1.130/32 > set iface route 192.168.1.130/32 > load pptp_standard > > pptp_standard: > set iface idle 0 > set iface disable on-demand > set iface enable tcpmssfix > set bundle disable multilink > set bundle enable compression > set bundle enable noretry > set bundle max-logins 0 > set link no pap chap > set link enable chap > set link keep-alive 0 0 // tried before with 10 and 60 and now > I've disabled the keepalives > set link max-redial -1 > set link yes acfcomp protocomp > set link enable chap-md5 chap-msv1 chap-msv2 chap > set link mtu 1460 > set link mtu 1460 //here I also tried without these > set link mru 1460 // here I also tried without these > set link latency 0 > set ipcp dns dns-ip-address > set ipcp yes vjcomp > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > set pptp disable delayed-ack > > mpd.links > > pptp1: > set link type pptp > set pptp self my-server-ip-address > set pptp enable incoming > set pptp disable originate > set pptp disable windowing > > I'm also using pf for NAT: > scrub in all fragment reassemble no-df max-mss 1452 > #nonat = local table with lan ip addresses > nat on $ext_if from 192.168.1.128/25 to ! -> ($ext_if) > > I get no packet errors during the communication. > > Can anyone help in debugging this ? > > > Thanks, > Mihai > > > > > Forgot to mention this: As far as I'm seeing it now, this only happens when 2 users try to be simultaneously connected. I have defined: pptp1: new -i ng0 pptp1 pptp1 set iface disable proxy-arp set ipcp ranges 192.168.1.129/32 192.168.1.130/32 load pptp_standard pptp2: new -i ng0 pptp2 pptp2 set iface disable proxy-arp set ipcp ranges 192.168.1.131/32 192.168.1.132/32 load pptp_standard pptp1: set link type pptp set pptp self 86.105.56.134 set pptp enable incoming set pptp disable originate set pptp disable windowing pptp2: set link type pptp set pptp self 86.105.56.134 set pptp enable incoming set pptp disable originate set pptp disable windowing From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 17:31:15 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6EEF16A419 for ; Wed, 5 Sep 2007 17:31:15 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by mx1.freebsd.org (Postfix) with ESMTP id 813EA13C465 for ; Wed, 5 Sep 2007 17:31:15 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1960266wxd for ; Wed, 05 Sep 2007 10:30:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UcRB0iuCMAZS545VPjr5VwtRFJpYZfqiwJ7sMFXGy5nhYJPFFcxIvEwLsUi7tyuYjnbTJrWEH5dKA/0grkJvmuAmeZEiwQbwrQjnXDSsDr7VZ2ViJVR4GGviupmCQnIZDqjTDg1cPr0LtFg1Q8cdgLdiF/dhEbzZrIHLCuQrzz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q9vljca5J29TtTk0qRetsZ10GoyBaE3RUp0ESKquxmCEuGdE3sdiiVvCSj+NMSVB/Q/6TlTx8DTHhQQwlyZ2PKPmoZHK1pL3Jytbm7KRuFnAAIar59S+Wf3cBNnTB+VItWy2U0Jrso+GYWo60i4JMhscz5+7Pla3sBsuhsBRWB0= Received: by 10.90.75.10 with SMTP id x10mr337247aga.1189013459213; Wed, 05 Sep 2007 10:30:59 -0700 (PDT) Received: by 10.90.114.13 with HTTP; Wed, 5 Sep 2007 10:30:59 -0700 (PDT) Message-ID: Date: Wed, 5 Sep 2007 20:30:59 +0300 From: "Ivo Vachkov" To: freebsd-net In-Reply-To: <46DEC668.50509@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <46DD2A1E.3060109@FreeBSD.org> <46DEC668.50509@FreeBSD.org> Subject: Re: Network stack locking 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: Wed, 05 Sep 2007 17:31:15 -0000 On 9/5/07, Bruce M. Simpson wrote: > You need to remember to drop the lock which rtalloc() acquires on your > behalf using RTFREE() before leaving the function or possibly calling a > function which needs exclusive/write access to the rtentry. > > If your code needs this rtentry to remain in the system, a call to > RT_ADDREF() with the lock held may be necessary, although you should > remember to RT_REMREF() with the lock held when done with the rtentry. > > See =ABnet/route.h=BB for more info. actually, a simple bzero(&out_rt, sizeof(struct route_in6)); (i'll test it tonight with just a 'out_rt.ro_rt =3D NULL;') fixed the problem. > regards, > BMS > thanks again for the help. From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 18:58:41 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB63E16A420 for ; Wed, 5 Sep 2007 18:58:41 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1D513C45D for ; Wed, 5 Sep 2007 18:58:40 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 30158928; Wed, 05 Sep 2007 21:58:26 +0300 Message-ID: <46DEFC4F.7060802@FreeBSD.org> Date: Wed, 05 Sep 2007 21:58:23 +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: Mihai Tanasescu References: <1189016608.00796469.1189004406@10.7.7.3> In-Reply-To: <1189016608.00796469.1189004406@10.7.7.3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Freebsd MPD PPTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Sep 2007 18:58:41 -0000 Hi. Mihai Tanasescu wrote: > I'm using MPD4 to establish a PPTP VPN from my FreeBSD 6.2 server to > some clients and I've started encountering some strange problems. > > The connection goes well, everything functions accordingly but after a > while (very random, can be 5 minutes, 1 hour, 8 hours) I loose > connectivity (the clients' Windows icon show packet are being sent, but > nothing is received). A tcpdump on the external interface shows no > packets going out and the same for tcpdump on ng0 (although I'm not sure > if it should display something here). Tcpdump on ng0 interface should display traffic inside tunnel. It also may be interesting to look on internal interface as tcpdump is able to decode PPTP packets. > For what I've seen the ip address on the ng0 interface disappears. This may be significant. Configure syslog for logging mpd messages, it should give you information about why IP disappeared. Probably it happened in result of some error. Also look to the messages logs, there may be something interesting. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 20:52:15 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 875B216A41A for ; Wed, 5 Sep 2007 20:52:15 +0000 (UTC) (envelope-from jfvogel@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 1E6B013C4B0 for ; Wed, 5 Sep 2007 20:52:14 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so1798119nfd for ; Wed, 05 Sep 2007 13:52:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=XScp8QuYDcTVdOkGy7xdNGlPwNfGzZH5dMDkZQzXwNJP1jj/klbnNu0f6TbIz8iblQKavINJnJNlxYreTP+MtkQ2QtyJDwZ4wKx8E8omd2HVdc6YaINrq7BGFBW+Beuk27MihhtY8zs9x27SNPTetn77ZQZXoch/oDC3tdnakpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=csPvW9JRTxjCXtvyocTYYaGZv6XjZQYYE5yJmVoee4knZwKe++HujxqnYbk9H0xZSf3fPWJa0zfbGCpxMRz9myqlVR7YK3kzIR2kDrCxLWOOIO/lI1K9f+9vAJuUCmHw0U/M1TqI9rImZQqzBiavh3d00VOUZNy1l0Bm1D7A+iU= Received: by 10.86.26.11 with SMTP id 11mr895fgz.1189025525310; Wed, 05 Sep 2007 13:52:05 -0700 (PDT) Received: by 10.86.81.6 with HTTP; Wed, 5 Sep 2007 13:52:05 -0700 (PDT) Message-ID: <2a41acea0709051352n583b4724o359faaf29a1479d8@mail.gmail.com> Date: Wed, 5 Sep 2007 13:52:05 -0700 From: "Jack Vogel" To: "freebsd-net@freebsd.org" , "Andre Oppermann" , "Scott Long" , "John Baldwin" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Thoughts on vlan filter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Sep 2007 20:52:15 -0000 I had an idea, I was debugging a problem on my new 10G driver a week back, and found I had the hardware vlan filter enabled by accident, this led me to wonder about supporting this hardware feature in the driver... I have done some experimentation, and find that when the vlan device is configured, ultimately the SETMULTI ioctl will happen in my driver, this means I could add code that checks the trunk, finds there is a vlan and then sets the tag into the filter. Any interest, or thoughts ya or nay about my doing this? Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 21:51:52 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF9016A418; Wed, 5 Sep 2007 21:51:52 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id AB15013C459; Wed, 5 Sep 2007 21:51:52 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 4FAAC278BA; Wed, 5 Sep 2007 17:51:52 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 05 Sep 2007 17:51:52 -0400 X-Sasl-enc: F92YSI2zkUfaAif87CDBXp/iCaneWqryUKSFzuP0NGa0 1189029112 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 62CCBBFBB; Wed, 5 Sep 2007 17:51:51 -0400 (EDT) Message-ID: <46DF24F6.1060602@FreeBSD.org> Date: Wed, 05 Sep 2007 22:51:50 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0709051352n583b4724o359faaf29a1479d8@mail.gmail.com> In-Reply-To: <2a41acea0709051352n583b4724o359faaf29a1479d8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Scott Long , Andre Oppermann , Kip Macy , John Baldwin Subject: Re: Thoughts on vlan filter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Sep 2007 21:51:52 -0000 Jack Vogel wrote: > I had an idea, I was debugging a problem on my new 10G driver a week back, > and found I had the hardware vlan filter enabled by accident, this led me to > wonder about supporting this hardware feature in the driver... > > I have done some experimentation, and find that when the vlan device is > configured, ultimately the SETMULTI ioctl will happen in my driver, this > means I could add code that checks the trunk, finds there is a vlan and > then sets the tag into the filter. > > Any interest, or thoughts ya or nay about my doing this? > I can't say for sure what the right answer here is. It seems reasonable to have a means of checking if the setmulti is happening from a stacked vlan(4) instance. I think it is reasonable to only support this for 2 layers of nesting levels i.e. Q-in-Q, in the mainline stack, and encourage folks to use Netgraph if they need arbitrary nesting levels. Kip raised some performance related concerns about the driver lock being taken whenever multicast address list changes happen, thus deferring or delaying packet flows on other transmit queues, perhaps he can chime in? regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 22:14:28 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9086016A417; Wed, 5 Sep 2007 22:14:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 02A3413C46A; Wed, 5 Sep 2007 22:14:27 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l85LZbf3097883; Wed, 5 Sep 2007 15:35:37 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46DF2119.6030909@samsco.org> Date: Wed, 05 Sep 2007 15:35:21 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Jack Vogel References: <2a41acea0709051352n583b4724o359faaf29a1479d8@mail.gmail.com> In-Reply-To: <2a41acea0709051352n583b4724o359faaf29a1479d8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Wed, 05 Sep 2007 15:35:38 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: "freebsd-net@freebsd.org" , Andre Oppermann , John Baldwin Subject: Re: Thoughts on vlan filter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Sep 2007 22:14:28 -0000 Jack Vogel wrote: > I had an idea, I was debugging a problem on my new 10G driver a week back, > and found I had the hardware vlan filter enabled by accident, this led me to > wonder about supporting this hardware feature in the driver... > > I have done some experimentation, and find that when the vlan device is > configured, ultimately the SETMULTI ioctl will happen in my driver, this > means I could add code that checks the trunk, finds there is a vlan and > then sets the tag into the filter. > > Any interest, or thoughts ya or nay about my doing this? > > Cheers, > > Jack Overloading the SETMULTI ioctl is probably a bad idea for anything more than a proof-of-concept. From a cleanliness point of view, making the software vlan module aware of this as a hardware offload capability and able to control it via new ioctls sounds more reasonable. Scott From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 22:14:50 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F0A316A419 for ; Wed, 5 Sep 2007 22:14:50 +0000 (UTC) (envelope-from jfvogel@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 2CC5213C459 for ; Wed, 5 Sep 2007 22:14:49 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so1814440nfd for ; Wed, 05 Sep 2007 15:14:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tO29ecvkE8cvbr9CagT/dEq3iymKZQH6SfhesZHjkI1gUtzbI00Bw+5pGcjO5KxYmMdKEjmxRRvNUDGWrqbpYMYsD0zqgP976cbMJn7EUwK80XT4qNCe0Hdw4f+5M4T6aTmI5UVC5eVuq1NDWC2LSGVNCl6xGuUsvfiZ7G9FtpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C4Un4B8gZ/90ZlA6agm3jdjoLx6EXOyC7DFbj50293/iMkRXLnlg7vlViLn43KRsnfELiuWDmCwqgg9OGUuKc/sRKo23kPNBD2zjwrdT2qmdj7K3wjYt0VO+NvSBqSPjrdIr8qUV/zJ68Rfo4tPuNVM6q39+v/roRX215TVoZKQ= Received: by 10.86.57.9 with SMTP id f9mr48838fga.1189030488586; Wed, 05 Sep 2007 15:14:48 -0700 (PDT) Received: by 10.86.81.6 with HTTP; Wed, 5 Sep 2007 15:14:48 -0700 (PDT) Message-ID: <2a41acea0709051514k3b72c932ya7b2e9bcb46a9c70@mail.gmail.com> Date: Wed, 5 Sep 2007 15:14:48 -0700 From: "Jack Vogel" To: "Scott Long" In-Reply-To: <46DF2119.6030909@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0709051352n583b4724o359faaf29a1479d8@mail.gmail.com> <46DF2119.6030909@samsco.org> Cc: "freebsd-net@freebsd.org" , Andre Oppermann , John Baldwin Subject: Re: Thoughts on vlan filter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Sep 2007 22:14:50 -0000 On 9/5/07, Scott Long wrote: > Jack Vogel wrote: > > I had an idea, I was debugging a problem on my new 10G driver a week back, > > and found I had the hardware vlan filter enabled by accident, this led me to > > wonder about supporting this hardware feature in the driver... > > > > I have done some experimentation, and find that when the vlan device is > > configured, ultimately the SETMULTI ioctl will happen in my driver, this > > means I could add code that checks the trunk, finds there is a vlan and > > then sets the tag into the filter. > > > > Any interest, or thoughts ya or nay about my doing this? > > > > Cheers, > > > > Jack > > Overloading the SETMULTI ioctl is probably a bad idea for anything more > than a proof-of-concept. From a cleanliness point of view, making the > software vlan module aware of this as a hardware offload capability and > able to control it via new ioctls sounds more reasonable. > > Scott > > You're right, that would be ideal, so is there any other adapters with this capability, and is the vlan driver owner interested in implementing it? Jack From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 22:14:51 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D60A16A421; Wed, 5 Sep 2007 22:14:51 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0C04D13C468; Wed, 5 Sep 2007 22:14:50 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id C47F71A4D84; Wed, 5 Sep 2007 15:11:50 -0700 (PDT) Date: Wed, 5 Sep 2007 15:11:50 -0700 From: Alfred Perlstein To: "Bruce M. Simpson" Message-ID: <20070905221150.GY87451@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: (forw) Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Sep 2007 22:14:51 -0000 Bruce, I haven't heard back from you on this. can you please comment? I'd like to add the policy to the header. ----- Forwarded message from Alfred Perlstein ----- From: Alfred Perlstein To: "Bruce M. Simpson" Cc: Max Laier , net@freebsd.org Subject: Re: Allocating AF constants for vendors. Date: Tue, 4 Sep 2007 05:42:24 -0700 Message-ID: <20070904124224.GF87451@elvis.mu.org> User-Agent: Mutt/1.4.2.3i Sender: owner-freebsd-net@freebsd.org * Bruce M. Simpson [070904 03:08] wrote: > >As you can see we are defering the "bloat". > >Does that make sense? > > > > I follow but it still doesn't really make sense. > > Granted, you are deferring the growth of arrays sized off AF_MAX but > only ever by 1 slot. > What if Vendor Z wants to add 25 entries at once? Then as long as they allocate odd numbered entries they should be fine. FreeBSD's AF_MAX does not need to change to accomidate a vendor, it only has to restrict itself to even numbered slots. > We would also be tying ourselves down to the notion of a vendor in any > AF_ allocation. Is this an avenue that people are happy to pursue? Yes, until the "horrific" problem of the statically sized arrays is "fixed". Then the allocation policy can change. -- - Alfred Perlstein _______________________________________________ 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" ----- End forwarded message ----- -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 01:51:48 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 697DC16A421 for ; Thu, 6 Sep 2007 01:51:48 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 441D213C457 for ; Thu, 6 Sep 2007 01:51:48 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so13933waf for ; Wed, 05 Sep 2007 18:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=VuqNNRQc41zmOy2xRWR/Oiv3IcztHkVKaZYFvxthGHs=; b=CWp4zpvAKsrFzhL9WMiwSElzQYNz4wNb6RhqQbYXtgBhfcc8MSj0P2IX1S1dTLAQEd5hSEwcE3kxFJQWpUaJ491wVNskQG3V6CxJr28z5HiCrDsJwB9o3tcNeWYZNSql3Gl3DFFG0+1QwMikIVtD6T+fMADahHXphzdjs1vQJmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=MPDuzDk39l67fJ5sAwWeRWeFxaBAPHfgfvp9lHQgQ2IpUrjsF46FCYtOrrJzxH9AwDq+iCG9RykruNG+nAHl9MlGZX8lWMY1XFoa30awbEHWCqzRlEFrcpPNqbg1RmeE0CTzXd6RwgETfp1rQRdn4R6WQ1QQx5/fgTLce9AEgCs= Received: by 10.115.90.1 with SMTP id s1mr6668wal.1189041454477; Wed, 05 Sep 2007 18:17:34 -0700 (PDT) Received: by 10.115.79.2 with HTTP; Wed, 5 Sep 2007 18:17:34 -0700 (PDT) Message-ID: <82bdb5ec0709051817j16bfea69u74b9f4978c1f00fc@mail.gmail.com> Date: Wed, 5 Sep 2007 20:17:34 -0500 From: "sazzadur rahman" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: A query regarding sctp_bindx api in SCTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 01:51:48 -0000 Hello, I am using sctp patch for freebsd6.1. For dynamic address configuration, I am calling sctp_bindx() API after successfull bind() and connect() API's. Although sctp_bindx() API successfully returns 0, the debug message shows: addr_mgmt_assoc: added to pending list... asconf_queue_add: appended asconf ADD_IP_ADDRESS... And I didn't see any ASCONF chunk sent to the peer in the tcpdump. Hence, I am confused why it should be in the pendling list instead of immediate send to peer? In draft-ietf-tsvwg-addip-sctp-22.txt: page 20, A3, I have found that "If an ASCONF chunk is outstanding, then the ASCONF chunk should be queued for later transmission and no further action should be taken until the previous ASCONF is acknowledged or a timeout occurs." But as I am calling sctp_bindx() for the first time, there should not be any previous ASCONF existing. Does anyone have any idea what I am missing here? I would appriciate any help in this regard. Best Regards, Md. Sazzadur Rahman, Graduate Student, School of Computer Science, University of Oklahoma, Norman, USA ---------------------------code segment I have used--------------------- //socket s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); //bind memset(&myAddr, 0, sizeof myAddr); myAddr.sin_family = AF_INET; myAddr.sin_port = htons(5060); myAddr.sin_addr.s_addr = inet_addr("129.15.78.125"); if (bind(s, (struct sockaddr *)&myAddr, sizeof myAddr) < 0) { goto close; } //connect memset(&farAddr, 0, sizeof farAddr); farAddr.sin_family = AF_INET; farAddr.sin_port = htons(6060); farAddr.sin_addr.s_addr = inet_addr( "129.15.78.114" ); int iRet = connect(s, (struct sockaddr *)&farAddr, sizeof farAddr); //sctp_bindx struct sockaddr_in my2ndAddr; memset(&my2ndAddr, 0, sizeof my2ndAddr); my2ndAddr.sin_len = sizeof my2ndAddr; my2ndAddr.sin_family = AF_INET; my2ndAddr.sin_port = htons(5060); my2ndAddr.sin_addr.s_addr = inet_addr("129.15.78.126"); iRet = sctp_bindx(s,(struct sockaddr*)&my2ndAddr,1,SCTP_BINDX_ADD_ADDR); ------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 03:10:49 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C35A16A417 for ; Thu, 6 Sep 2007 03:10:49 +0000 (UTC) (envelope-from gloomygroup@hotmail.com) Received: from bay0-omc1-s22.bay0.hotmail.com (bay0-omc1-s22.bay0.hotmail.com [65.54.246.94]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7CB13C45D for ; Thu, 6 Sep 2007 03:10:49 +0000 (UTC) (envelope-from gloomygroup@hotmail.com) Received: from BAY131-W17 ([65.55.136.52]) by bay0-omc1-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Sep 2007 19:57:43 -0700 Message-ID: X-Originating-IP: [202.79.53.71] From: Gloomy Group To: Date: Thu, 6 Sep 2007 02:57:42 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Sep 2007 02:57:43.0276 (UTC) FILETIME=[B1F0CAC0:01C7F031] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Interface Status changes to UP and Down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 03:10:49 -0000 Hi all, I am running Freebsd 6.2 as Transparent proxy Server. My hardware is Int= el(R) Pentium(R) 4 CPU 3.00GHz, 1GB DDR2 Memory and 2 SATA hardisk. While c= hecking dmesg it shows link state change to up and Down and sometimes the s= erver crashes. ipfw: pullup failed ipfw: pullup failed ipfw: pullup failed ipfw: pullup failed ipfw: pullup failed ipfw: pullup failed fxp0: link state changed to DOWN fxp0: link state changed to UP fxp0: link state changed to DOWN fxp0: link state changed to UP fxp0: link state changed to DOWN fxp0: link state changed to UP fxp0: link state changed to DOWN fxp0: link state changed to UP fxp0: link state changed to DOWN fxp0: link state changed to UP fxp0: link state changed to DOWN Is this due to misconfigured firewall rules or some special tuning= need in kernel variables; Below is my IPFW rules: 00100 allow ip from any to any via lo0 00101 check-state 00102 deny icmp from any to any in icmptypes 5,9,13,14,15,16,17 00200 allow icmp from 202.xx.xx.0/24 to me in 00201 allow icmp from 202.xx.xx.0/24 to me in 00300 allow tcp from me to any out keep-state 00301 allow udp from me to any dst-port 53 keep-state 00302 allow ip from me to any out keep-state 00303 allow tcp from any 80,443 to me in keep-state 00304 allow tcp from any 80,443 to any out keep-state 00400 allow tcp from 202.79.xx.0/24 to me dst-port 2001 keep-state 00500 allow udp from 202.79.xx.xx 3130 to me dst-port 3130 keep-state 00501 allow tcp from 202.79.xx.xx 3128 to me in 00600 allow udp from 202.79.xx.xx to me dst-port 161 keep-state 00601 allow udp from 202.79.xx.xx to me dst-port 3401 keep-state 03000 allow tcp from 202.79.xx.0/24 to me dst-port 3128 03001 allow tcp from 202.79.xx.0/24 to me dst-port 3128 03002 fwd 127.0.0.1,3128 tcp from 202.79.xx.0/24 to any dst-port 80 keep-st= ate 03003 fwd 127.0.0.1,3128 tcp from 202.79.xx.0/24 to any dst-port 80 keep-st= ate 65534 deny log logamount 200 ip from any to any =20 _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Space= s. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=3Dcreate&wx_url=3D/friends.= aspx&mkt=3Den-us= From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 07:03:24 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FFAC16A418; Thu, 6 Sep 2007 07:03:24 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0523913C442; Thu, 6 Sep 2007 07:03:24 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 55B832709A; Thu, 6 Sep 2007 03:03:10 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 06 Sep 2007 03:03:10 -0400 X-Sasl-enc: Mn2xEmUFBIqfvmd9hCuOt3ia+DolkxKGFOeX3OUq4c4F 1189062189 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id A8457115B7; Thu, 6 Sep 2007 03:03:09 -0400 (EDT) Message-ID: <46DFA62C.3070700@FreeBSD.org> Date: Thu, 06 Sep 2007 08:03:08 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Alfred Perlstein References: <20070905221150.GY87451@elvis.mu.org> In-Reply-To: <20070905221150.GY87451@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: (forw) Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 07:03:24 -0000 Alfred Perlstein wrote: > Bruce, I haven't heard back from you on this. can you please comment? > > I'd like to add the policy to the header. > I'm not 100% happy with this suggestion, however, it is a loosely working compromise. I would be happier if the static index dependency on AF_MAX is ironed out at some later date. regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 08:42:15 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C8416A420 for ; Thu, 6 Sep 2007 08:42:15 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp809.mail.ird.yahoo.com (smtp809.mail.ird.yahoo.com [217.146.188.69]) by mx1.freebsd.org (Postfix) with SMTP id 4738F13C457 for ; Thu, 6 Sep 2007 08:42:14 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 32383 invoked from network); 6 Sep 2007 08:15:33 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@217.44.142.35 with plain) by smtp809.mail.ird.yahoo.com with SMTP; 6 Sep 2007 08:15:32 -0000 X-YMail-OSG: yamd3I8VM1njmsT1sM2QJDTczMap36zCCc.57OIiU59XqYigzQopCfbVE8j3zleTnf8- Message-ID: <46DFC595.7050803@tomjudge.com> Date: Thu, 06 Sep 2007 10:17:09 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Gloomy Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Interface Status changes to UP and Down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 08:42:15 -0000 Gloomy Group wrote: > Hi all, > > I am running Freebsd 6.2 as Transparent proxy Server. My hardware is Intel(R) Pentium(R) 4 CPU 3.00GHz, 1GB DDR2 Memory and 2 SATA hardisk. While checking dmesg it shows link state change to up and Down and sometimes the server crashes. > > ipfw: pullup failed > ipfw: pullup failed > ipfw: pullup failed > ipfw: pullup failed > ipfw: pullup failed > ipfw: pullup failed > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > fxp0: link state changed to UP > fxp0: link state changed to DOWN > > > Is this due to misconfigured firewall rules or some special tuning need in kernel variables; Below is my IPFW rules: This is most likely to be being caused by a cable or hardware problem (NIC or switch). The firewall can't affect the link state of the NIC. Tom > > 00100 allow ip from any to any via lo0 > 00101 check-state > 00102 deny icmp from any to any in icmptypes 5,9,13,14,15,16,17 > 00200 allow icmp from 202.xx.xx.0/24 to me in > 00201 allow icmp from 202.xx.xx.0/24 to me in > 00300 allow tcp from me to any out keep-state > 00301 allow udp from me to any dst-port 53 keep-state > 00302 allow ip from me to any out keep-state > 00303 allow tcp from any 80,443 to me in keep-state > 00304 allow tcp from any 80,443 to any out keep-state > 00400 allow tcp from 202.79.xx.0/24 to me dst-port 2001 keep-state > 00500 allow udp from 202.79.xx.xx 3130 to me dst-port 3130 keep-state > 00501 allow tcp from 202.79.xx.xx 3128 to me in > 00600 allow udp from 202.79.xx.xx to me dst-port 161 keep-state > 00601 allow udp from 202.79.xx.xx to me dst-port 3401 keep-state > 03000 allow tcp from 202.79.xx.0/24 to me dst-port 3128 > 03001 allow tcp from 202.79.xx.0/24 to me dst-port 3128 > 03002 fwd 127.0.0.1,3128 tcp from 202.79.xx.0/24 to any dst-port 80 keep-state > 03003 fwd 127.0.0.1,3128 tcp from 202.79.xx.0/24 to any dst-port 80 keep-state > 65534 deny log logamount 200 ip from any to any > From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 12:55:30 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1896116A468 for ; Thu, 6 Sep 2007 12:55:30 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id C4C8413C468 for ; Thu, 6 Sep 2007 12:55:29 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: by smtp.teledomenet.gr (Postfix, from userid 58) id DD6D61420E4; Thu, 6 Sep 2007 15:40:24 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on smtp.teledomenet.gr X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from iris (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id 3ED2C14210F; Thu, 6 Sep 2007 15:40:22 +0300 (EEST) From: Nikos Vassiliadis To: freebsd-net@freebsd.org Date: Thu, 6 Sep 2007 15:38:41 +0300 User-Agent: KMail/1.9.1 References: <46DEBEA7.1020201@duras.ro> <46DED51F.9080809@duras.ro> In-Reply-To: <46DED51F.9080809@duras.ro> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709061538.41827.nvass@teledomenet.gr> Cc: Mihai Tanasescu Subject: Re: Freebsd MPD PPTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 12:55:30 -0000 On Wednesday 05 September 2007 19:11, Mihai Tanasescu wrote: > As far as I'm seeing it now, this only happens when 2 users try to be > simultaneously connected. Just an assumption... Do by any chance these two clients are behind the same NAT device? Something like this? Client_a Client_b | | ------------ | NAT | | internet | | pptp_server You cannot have more than one GRE tunnel between two IP adresses. Nikos From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 13:26:34 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EE7016A418 for ; Thu, 6 Sep 2007 13:26:34 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8B113C478 for ; Thu, 6 Sep 2007 13:26:34 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Sep 2007 06:26:35 -0700 X-IronPort-AV: i="4.20,215,1186383600"; d="scan'208"; a="397168758:sNHT73077368" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l86DQX1p010465; Thu, 6 Sep 2007 06:26:33 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l86DQOxL018362; Thu, 6 Sep 2007 13:26:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 06:26:31 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 06:26:30 -0700 Message-ID: <46DFFFFD.6000309@cisco.com> Date: Thu, 06 Sep 2007 09:26:21 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sazzadur rahman References: <82bdb5ec0709051817j16bfea69u74b9f4978c1f00fc@mail.gmail.com> In-Reply-To: <82bdb5ec0709051817j16bfea69u74b9f4978c1f00fc@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Sep 2007 13:26:30.0866 (UTC) FILETIME=[89562B20:01C7F089] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2902; t=1189085194; x=1189949194; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20query=20regarding=20sctp_bindx=20api=20in=20SCTP |Sender:=20; bh=iSzGqMPMmJMbll/HfcXDMPoY78cPC1RJLjQ5keyLgWs=; b=PQAyoO2xlmObZLDbLC+Vcs/+0vvad3XiBolESyl+WWb5ypt5srHdNjF/BGLjHsXPei4pgoOR cipqe9il8gjM8pfhcGIFDoxMbajUR1lh3V/EvSLl6a8dQ/8ijCmMiKjo; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); Cc: freebsd-net@freebsd.org Subject: Re: A query regarding sctp_bindx api in SCTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 13:26:34 -0000 Definetly a bug... let me dig in a bit further.. it appears that ASCONF is not happening on sub-set bound sockets at all ;-( I will see if I can figure out why :-D R sazzadur rahman wrote: > Hello, > I am using sctp patch for freebsd6.1. For dynamic address configuration, I > am calling sctp_bindx() API after successfull bind() and connect() API's. > Although sctp_bindx() API successfully returns 0, the debug message shows: > > addr_mgmt_assoc: added to pending list... > asconf_queue_add: appended asconf ADD_IP_ADDRESS... > > And I didn't see any ASCONF chunk sent to the peer in the tcpdump. Hence, I > am confused why it should be in the pendling list instead of immediate send > to peer? > > In draft-ietf-tsvwg-addip-sctp-22.txt: page 20, A3, I have found that "If an > ASCONF chunk is outstanding, then the ASCONF chunk should be queued for > later transmission and no further action should be taken until the previous > ASCONF is acknowledged or a timeout occurs." But as I am calling > sctp_bindx() for the first time, there should not be any previous ASCONF > existing. > > Does anyone have any idea what I am missing here? > I would appriciate any help in this regard. > > Best Regards, > Md. Sazzadur Rahman, > Graduate Student, > School of Computer Science, > University of Oklahoma, > Norman, USA > > ---------------------------code segment I have used--------------------- > //socket > s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); > > //bind > memset(&myAddr, 0, sizeof myAddr); > myAddr.sin_family = AF_INET; > myAddr.sin_port = htons(5060); > myAddr.sin_addr.s_addr = inet_addr("129.15.78.125"); > if (bind(s, (struct sockaddr *)&myAddr, sizeof myAddr) < 0) { > goto close; > } > //connect > memset(&farAddr, 0, sizeof farAddr); > farAddr.sin_family = AF_INET; > farAddr.sin_port = htons(6060); > farAddr.sin_addr.s_addr = inet_addr( "129.15.78.114" ); > int iRet = connect(s, (struct sockaddr *)&farAddr, sizeof farAddr); > > //sctp_bindx > struct sockaddr_in my2ndAddr; > memset(&my2ndAddr, 0, sizeof my2ndAddr); > my2ndAddr.sin_len = sizeof my2ndAddr; > my2ndAddr.sin_family = AF_INET; > my2ndAddr.sin_port = htons(5060); > my2ndAddr.sin_addr.s_addr = inet_addr("129.15.78.126"); > > iRet = sctp_bindx(s,(struct > sockaddr*)&my2ndAddr,1,SCTP_BINDX_ADD_ADDR); > > ------------------------------------------ > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 13:40:51 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FAD616A417 for ; Thu, 6 Sep 2007 13:40:51 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mx1.freebsd.org (Postfix) with ESMTP id 797A013C4A5 for ; Thu, 6 Sep 2007 13:40:51 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 06 Sep 2007 06:11:52 -0700 X-IronPort-AV: i="4.20,215,1186383600"; d="scan'208"; a="16727040:sNHT27303246" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l86DBqXl023564; Thu, 6 Sep 2007 06:11:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l86DBqxJ004308; Thu, 6 Sep 2007 13:11:52 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 06:11:51 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 06:11:51 -0700 Message-ID: <46DFFC8E.2030502@cisco.com> Date: Thu, 06 Sep 2007 09:11:42 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sazzadur rahman References: <82bdb5ec0709051817j16bfea69u74b9f4978c1f00fc@mail.gmail.com> In-Reply-To: <82bdb5ec0709051817j16bfea69u74b9f4978c1f00fc@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Sep 2007 13:11:51.0626 (UTC) FILETIME=[7D44CAA0:01C7F087] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4228; t=1189084312; x=1189948312; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20query=20regarding=20sctp_bindx=20api=20in=20SCTP |Sender:=20; bh=QgcPC895GrXz6yBG/iG2h1x6XbD+a3inKDE+p+gYouI=; b=jku9L9ht32bJsKI9aiR5GWH95OSlgGVaimtNLzm5Z9XeDobxclB2CeVaXuL8ksx7WBqq3XpY /oOD9frlYlJZxOyG1SMtiR7RGOTYc7BQndL9exDUWobP5XFAwyIGmFl7; Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Cc: freebsd-net@freebsd.org, Peter Lei Subject: Re: A query regarding sctp_bindx api in SCTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 13:40:51 -0000 sazzadur rahman wrote: > Hello, > I am using sctp patch for freebsd6.1. For dynamic address configuration, I > am calling sctp_bindx() API after successfull bind() and connect() API's. > Although sctp_bindx() API successfully returns 0, the debug message shows: > > addr_mgmt_assoc: added to pending list... > asconf_queue_add: appended asconf ADD_IP_ADDRESS... > > And I didn't see any ASCONF chunk sent to the peer in the tcpdump. Hence, I > am confused why it should be in the pendling list instead of immediate send > to peer? Hmm.. I would like to see a packet trace of this as well.. A couple of thoughts. a) The 6.x code is a bit out of date.. I need to update and get a new patch out for you.. I know Peter did some work on the ASCONF code recently.. so there may be some fixes that have not been propagated to 6.x.. which could be a problem (added Peter for that reason even though I know he subscribes.. not sure how often he reads net). b) Whenever an address gets added like this, then the address will go into a pending point in the assoc. Since it can't be used yet i.e. the ASCONF-ACK must be returned BEFORE the address is part of the assoc. I am also not sure of the state of your association at this point. I will try testing this... since it is most likely in a front state, this may also be a problem. The ASCONF cannot be sent until after we reach ESTABLISHED... not sure we have tested this scenario. c) Normally I would think you should do all the bindx BEFORE the connect. When you do subset binding (which you are doing here since you are NOT bound-all) then what you are saying is that YOU the application wish to manage the addresses.. no automatic ASCONF will be done for you. When you do the bindx() it is supposed to kick off the ASCONF.. but again.. this may be an issue since you are in a front state... I will test this scenario with the latest 7.0 code and see if I can recreate it. R > > In draft-ietf-tsvwg-addip-sctp-22.txt: page 20, A3, I have found that "If an > ASCONF chunk is outstanding, then the ASCONF chunk should be queued for > later transmission and no further action should be taken until the previous > ASCONF is acknowledged or a timeout occurs." But as I am calling > sctp_bindx() for the first time, there should not be any previous ASCONF > existing. > > Does anyone have any idea what I am missing here? > I would appriciate any help in this regard. > > Best Regards, > Md. Sazzadur Rahman, > Graduate Student, > School of Computer Science, > University of Oklahoma, > Norman, USA > > ---------------------------code segment I have used--------------------- > //socket > s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); > > //bind > memset(&myAddr, 0, sizeof myAddr); > myAddr.sin_family = AF_INET; > myAddr.sin_port = htons(5060); > myAddr.sin_addr.s_addr = inet_addr("129.15.78.125"); > if (bind(s, (struct sockaddr *)&myAddr, sizeof myAddr) < 0) { > goto close; > } > //connect > memset(&farAddr, 0, sizeof farAddr); > farAddr.sin_family = AF_INET; > farAddr.sin_port = htons(6060); > farAddr.sin_addr.s_addr = inet_addr( "129.15.78.114" ); > int iRet = connect(s, (struct sockaddr *)&farAddr, sizeof farAddr); > > //sctp_bindx > struct sockaddr_in my2ndAddr; > memset(&my2ndAddr, 0, sizeof my2ndAddr); > my2ndAddr.sin_len = sizeof my2ndAddr; > my2ndAddr.sin_family = AF_INET; > my2ndAddr.sin_port = htons(5060); > my2ndAddr.sin_addr.s_addr = inet_addr("129.15.78.126"); > > iRet = sctp_bindx(s,(struct > sockaddr*)&my2ndAddr,1,SCTP_BINDX_ADD_ADDR); > > ------------------------------------------ > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 13:45:03 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CF8516A421 for ; Thu, 6 Sep 2007 13:45:03 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id D884A13C4A5 for ; Thu, 6 Sep 2007 13:45:02 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from [10.20.1.5] (unknown [10.0.0.126]) by netasq.netasq.com (Postfix) with ESMTP id 18DDC2D6B9 for ; Thu, 6 Sep 2007 15:12:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-net@freebsd.org From: Fabien THOMAS Date: Thu, 6 Sep 2007 15:12:06 +0200 X-Mailer: Apple Mail (2.752.3) Subject: new version of polling for FreeBSD 6.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 13:45:03 -0000 Hi, After many years of good services we will stop using FreeBSD 4.x :) During my performance regression tests under FreeBSD 6.2 i've found that polling has lower performance than interrupt. To solve that issue i've rewritten the core of polling to be more SMP ready. You can find a summary of all my tests and the source code at the following address: http://www.netasq.com/opensource/pollng-rev1-freebsd.tgz Feel free to ask more detailed information if necessary and report any bugs / comments. Fabien From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 14:10:25 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03FCF16A417 for ; Thu, 6 Sep 2007 14:10:25 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mx1.freebsd.org (Postfix) with ESMTP id CE8D313C45B for ; Thu, 6 Sep 2007 14:10:24 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 06 Sep 2007 07:10:15 -0700 X-IronPort-AV: i="4.20,215,1186383600"; d="scan'208"; a="397183035:sNHT56874926" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l86EAEQR014253; Thu, 6 Sep 2007 07:10:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l86EAAD1019700; Thu, 6 Sep 2007 14:10:10 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 07:10:09 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 07:10:09 -0700 Message-ID: <46E00A39.6020208@cisco.com> Date: Thu, 06 Sep 2007 10:10:01 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sazzadur rahman References: <82bdb5ec0709051817j16bfea69u74b9f4978c1f00fc@mail.gmail.com> <46DFFFFD.6000309@cisco.com> In-Reply-To: <46DFFFFD.6000309@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Sep 2007 14:10:09.0697 (UTC) FILETIME=[A2481110:01C7F08F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4201; t=1189087814; x=1189951814; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20query=20regarding=20sctp_bindx=20api=20in=20SCTP |Sender:=20; bh=hQkA4wEozdGVx/ZVAdfvHtojw7uOIqEFqHynJmsFjgs=; b=GL7l0N1LpLaAJ9izzppaKj5JtVq5N/0/XAnfSTrPVIQOtQA0OLEOcg25SDLslIfgJy2CyvtE uZhS0VSQDT57vQ38bDe5+TNtarO0LYyfDC7sg++6MzooIgFOK6mSVbjZ; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Cc: freebsd-net@freebsd.org Subject: Re: A query regarding sctp_bindx api in SCTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 14:10:25 -0000 Well I spoke to soon.. after a bit more testing .. I figured out that I had fat-fingered my address set on my second interface.. opps :-D So after testing I see this all working now on the latest code.. now as I said the Jul_13 issue is way behind.. so I have now updated the sctp.org web site with a Sep 6 version. This as even a LOT of patches that the current software does not.. ** I am waiting for approval of a patch (18) which does some deep restructure so we can have MAC-OSX use the same locking model as BSD.. behind that I have a patch (19) with many more bug fixes.. we now are to the point that we are running VERY VERY well on an 8 Core MAC box in Michael Tuexens lab.. running both the MPI test suite AND the special mywaitall killer MPI test (as well as the reserpool workout). The good new for you is that the update on my website (Sep6_2007) has all of these bug fixes... so please update to the latest code and tell me if the problem has gone away.. it should.. or I am doing something wrong with the test code (based on the code in this email).. Let me know if you have any more problems.. Thanks R Randall Stewart wrote: > Definetly a bug... let me dig in a bit further.. it > appears that ASCONF is not happening on sub-set bound > sockets at all ;-( > > I will see if I can figure out why :-D > > R > > sazzadur rahman wrote: > >> Hello, >> I am using sctp patch for freebsd6.1. For dynamic address >> configuration, I >> am calling sctp_bindx() API after successfull bind() and connect() API's. >> Although sctp_bindx() API successfully returns 0, the debug message >> shows: >> >> addr_mgmt_assoc: added to pending list... >> asconf_queue_add: appended asconf ADD_IP_ADDRESS... >> >> And I didn't see any ASCONF chunk sent to the peer in the tcpdump. >> Hence, I >> am confused why it should be in the pendling list instead of immediate >> send >> to peer? >> >> In draft-ietf-tsvwg-addip-sctp-22.txt: page 20, A3, I have found that >> "If an >> ASCONF chunk is outstanding, then the ASCONF chunk should be queued for >> later transmission and no further action should be taken until the >> previous >> ASCONF is acknowledged or a timeout occurs." But as I am calling >> sctp_bindx() for the first time, there should not be any previous ASCONF >> existing. >> >> Does anyone have any idea what I am missing here? >> I would appriciate any help in this regard. >> >> Best Regards, >> Md. Sazzadur Rahman, >> Graduate Student, >> School of Computer Science, >> University of Oklahoma, >> Norman, USA >> >> ---------------------------code segment I have used--------------------- >> //socket >> s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); >> >> //bind >> memset(&myAddr, 0, sizeof myAddr); >> myAddr.sin_family = AF_INET; >> myAddr.sin_port = htons(5060); >> myAddr.sin_addr.s_addr = inet_addr("129.15.78.125"); >> if (bind(s, (struct sockaddr *)&myAddr, sizeof myAddr) < 0) { >> goto close; >> } >> //connect >> memset(&farAddr, 0, sizeof farAddr); >> farAddr.sin_family = AF_INET; >> farAddr.sin_port = htons(6060); >> farAddr.sin_addr.s_addr = inet_addr( "129.15.78.114" ); >> int iRet = connect(s, (struct sockaddr *)&farAddr, sizeof >> farAddr); >> >> //sctp_bindx >> struct sockaddr_in my2ndAddr; >> memset(&my2ndAddr, 0, sizeof my2ndAddr); >> my2ndAddr.sin_len = sizeof my2ndAddr; >> my2ndAddr.sin_family = AF_INET; >> my2ndAddr.sin_port = htons(5060); >> my2ndAddr.sin_addr.s_addr = inet_addr("129.15.78.126"); >> >> iRet = sctp_bindx(s,(struct >> sockaddr*)&my2ndAddr,1,SCTP_BINDX_ADD_ADDR); >> >> ------------------------------------------ >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 14:32:44 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2357E16A418 for ; Thu, 6 Sep 2007 14:32:44 +0000 (UTC) (envelope-from peterlei@cisco.com) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mx1.freebsd.org (Postfix) with ESMTP id 87B3E13C4B3 for ; Thu, 6 Sep 2007 14:32:43 +0000 (UTC) (envelope-from peterlei@cisco.com) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Sep 2007 10:18:41 -0400 X-IronPort-AV: i="4.20,215,1186372800"; d="p7s'?scan'208"; a="131140919:sNHT66380712" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l86EIeU2004344; Thu, 6 Sep 2007 10:18:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l86EIWBk018992; Thu, 6 Sep 2007 14:18:40 GMT Received: from xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 10:18:37 -0400 Received: from macbookpro.lei.chicago.il.us ([171.68.225.134]) by xmb-rtp-20c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 10:18:36 -0400 Message-ID: <46E00C3D.1010009@cisco.com> Date: Thu, 06 Sep 2007 09:18:37 -0500 From: "Peter Lei (peterlei)" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Randall Stewart , sazzadur rahman References: <82bdb5ec0709051817j16bfea69u74b9f4978c1f00fc@mail.gmail.com> <46DFFC8E.2030502@cisco.com> In-Reply-To: <46DFFC8E.2030502@cisco.com> X-Enigmail-Version: 0.95.3 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010301060508070900070306" X-OriginalArrivalTime: 06 Sep 2007 14:18:36.0626 (UTC) FILETIME=[D06F4B20:01C7F090] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9938; t=1189088320; x=1189952320; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=peterlei@cisco.com; z=From:=20=22Peter=20Lei=20(peterlei)=22=20 |Subject:=20Re=3A=20A=20query=20regarding=20sctp_bindx=20api=20in=20SCTP |Sender:=20 |To:=20Randall=20Stewart=20, =0A=20=20=20=20=20=20=20=20saz zadur=20rahman=20; bh=OOHTOIszRPupzY1b04s3j4QZNFoaGeohqDdta0hcpsI=; b=0e5tA5tLIHOEwqoa8K5nPn0Py95CevrZQLLT7FWlwFuFbA83rBJA6LTYRYGm0vkvSEYkBN2U lXEIxodSd3g2R2XYSrUEedP446dcLpdDawtYu3B5QUUmsbRnKvnCI0YM; Authentication-Results: rtp-dkim-2; header.From=peterlei@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: freebsd-net@freebsd.org Subject: Re: A query regarding sctp_bindx api in SCTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 14:32:44 -0000 This is a cryptographically signed message in MIME format. --------------ms010301060508070900070306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Randall Stewart wrote: > sazzadur rahman wrote: >> Hello, >> I am using sctp patch for freebsd6.1. For dynamic address >> configuration, I >> am calling sctp_bindx() API after successfull bind() and connect() API's. >> Although sctp_bindx() API successfully returns 0, the debug message >> shows: >> >> addr_mgmt_assoc: added to pending list... >> asconf_queue_add: appended asconf ADD_IP_ADDRESS... >> >> And I didn't see any ASCONF chunk sent to the peer in the tcpdump. >> Hence, I >> am confused why it should be in the pendling list instead of immediate >> send >> to peer? > > Hmm.. I would like to see a packet trace of this as well.. > > A couple of thoughts. > > a) The 6.x code is a bit out of date.. I need to update > and get a new patch out for you.. I know Peter did some > work on the ASCONF code recently.. so there may be some > fixes that have not been propagated to 6.x.. which could > be a problem (added Peter for that reason even though I > know he subscribes.. not sure how often he reads net). I don't recall if there was something in the timeframe of 6.1 where bindx() broke or not... there were a number of bugs fixed surrounding bindx() though for 7.0/-current for the new address list handling and change to use the iterator work thread. > b) Whenever an address gets added like this, then the address will > go into a pending point in the assoc. Since it can't be used > yet i.e. the ASCONF-ACK must be returned BEFORE the address > is part of the assoc. I am also not sure of the state of your > association at this point. I will try testing this... since it > is most likely in a front state, this may also be a problem. > The ASCONF cannot be sent until after we reach ESTABLISHED... not > sure we have tested this scenario. Any queued asconf's would go out after hitting the established state... There was a bug in the 7.0 code where the asconf would not get queued at all in the early front state (COOKIE-WAIT) because the 'peer supports addip' flag had not been set yet. > c) Normally I would think you should do all the bindx BEFORE the > connect. When you do subset binding (which you are doing here > since you are NOT bound-all) then what you are saying is that > YOU the application wish to manage the addresses.. no automatic > ASCONF will be done for you. When you do the bindx() it is supposed > to kick off the ASCONF.. but again.. this may be an issue > since you are in a front state... I will test this scenario > with the latest 7.0 code and see if I can recreate it. This works fine on 7.0. If Randy can update the patch for 6.1, we might be able to better assist. --peter > R > >> >> In draft-ietf-tsvwg-addip-sctp-22.txt: page 20, A3, I have found that >> "If an >> ASCONF chunk is outstanding, then the ASCONF chunk should be queued for >> later transmission and no further action should be taken until the >> previous >> ASCONF is acknowledged or a timeout occurs." But as I am calling >> sctp_bindx() for the first time, there should not be any previous ASCONF >> existing. >> >> Does anyone have any idea what I am missing here? >> I would appriciate any help in this regard. >> >> Best Regards, >> Md. Sazzadur Rahman, >> Graduate Student, >> School of Computer Science, >> University of Oklahoma, >> Norman, USA >> >> ---------------------------code segment I have used--------------------- >> //socket >> s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); >> >> //bind >> memset(&myAddr, 0, sizeof myAddr); >> myAddr.sin_family = AF_INET; >> myAddr.sin_port = htons(5060); >> myAddr.sin_addr.s_addr = inet_addr("129.15.78.125"); >> if (bind(s, (struct sockaddr *)&myAddr, sizeof myAddr) < 0) { >> goto close; >> } >> //connect >> memset(&farAddr, 0, sizeof farAddr); >> farAddr.sin_family = AF_INET; >> farAddr.sin_port = htons(6060); >> farAddr.sin_addr.s_addr = inet_addr( "129.15.78.114" ); >> int iRet = connect(s, (struct sockaddr *)&farAddr, sizeof >> farAddr); >> >> //sctp_bindx >> struct sockaddr_in my2ndAddr; >> memset(&my2ndAddr, 0, sizeof my2ndAddr); >> my2ndAddr.sin_len = sizeof my2ndAddr; >> my2ndAddr.sin_family = AF_INET; >> my2ndAddr.sin_port = htons(5060); >> my2ndAddr.sin_addr.s_addr = inet_addr("129.15.78.126"); >> >> iRet = sctp_bindx(s,(struct >> sockaddr*)&my2ndAddr,1,SCTP_BINDX_ADD_ADDR); >> >> ------------------------------------------ >> _______________________________________________ >> 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" >> > > -- Peter Lei IP Engineering Tech Center Cisco Systems, Inc. office: (773) 695-8201 mobile: (847) 830-8869 peterlei@cisco.com --------------ms010301060508070900070306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEC6nrtnINUwxJqQhHgziOxswDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUwNTE5MTY0MFoX DTA4MDUwNDE5MTY0MFowRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScGV0ZXJsZWlAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAwYnrr9EnG79FXqKjtxyVKd+iDkLIUzSnQ/N7g1RIx898b31Z1i/Cr9MOPWEY mSkkKvSQzZCKP/H7LxZUoDiL8jtL0HroDOiESD3RAL7do5u6JYdEZ7QOiLcdrN2VX4G3GRdP I64W8N/AzpeUCXp6GdqAjPSzGgc4IP9Z/6/wUIFVK9BVhD0DD3WngnOvRQ9LMbfaYHbnpK6/ 3hanVp4xVIPSwjIZIY3/W8ArwJ958MjkFMe4LuiOJ+pGcrHKXFgTv25RrDlpVjntnh0VgUmI khoaJ9c1lqYsMAJOFRR2MRu5scXeKOw50XSD7s4XIYDK8CsIArben8ZKRMy/7ce3hwIDAQAB oy8wLTAdBgNVHREEFjAUgRJwZXRlcmxlaUBjaXNjby5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOBgQA9PBoqRjvRt2InmWFEFkFmOO5dgSU0pau5duM5rx8gk87dARmsiWxe wcmepIiichIQL+qPiwNAOG+lwdtMwHldnfsTOvvZOnpU0wkTjrM664zTf8BjgyEBbKkSgFmg EUYoP3UiJUAWJJkTHH0mq8yT1BdRj4OZUGBbarbe6M6xbzCCAt4wggJHoAMCAQICEC6nrtnI NUwxJqQhHgziOxswDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDUwNTE5MTY0MFoXDTA4MDUwNDE5MTY0MFowRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScGV0ZXJs ZWlAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwYnrr9EnG79F XqKjtxyVKd+iDkLIUzSnQ/N7g1RIx898b31Z1i/Cr9MOPWEYmSkkKvSQzZCKP/H7LxZUoDiL 8jtL0HroDOiESD3RAL7do5u6JYdEZ7QOiLcdrN2VX4G3GRdPI64W8N/AzpeUCXp6GdqAjPSz Ggc4IP9Z/6/wUIFVK9BVhD0DD3WngnOvRQ9LMbfaYHbnpK6/3hanVp4xVIPSwjIZIY3/W8Ar wJ958MjkFMe4LuiOJ+pGcrHKXFgTv25RrDlpVjntnh0VgUmIkhoaJ9c1lqYsMAJOFRR2MRu5 scXeKOw50XSD7s4XIYDK8CsIArben8ZKRMy/7ce3hwIDAQABoy8wLTAdBgNVHREEFjAUgRJw ZXRlcmxlaUBjaXNjby5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA9PBoq RjvRt2InmWFEFkFmOO5dgSU0pau5duM5rx8gk87dARmsiWxewcmepIiichIQL+qPiwNAOG+l wdtMwHldnfsTOvvZOnpU0wkTjrM664zTf8BjgyEBbKkSgFmgEUYoP3UiJUAWJJkTHH0mq8yT 1BdRj4OZUGBbarbe6M6xbzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQLqeu2cg1 TDEmpCEeDOI7GzAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNzA5MDYxNDE4MzdaMCMGCSqGSIb3DQEJBDEWBBRe++VI7mFv7Snn YK5oeaD4plVY5TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEC6n rtnINUwxJqQhHgziOxswgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEC6nrtnINUwxJqQhHgziOxswDQYJKoZIhvcN AQEBBQAEggEAYI0C1a8MJiGZkFzFLpH+RXR27L6ci/SUJy472FVqcWFdKzhSWGf+59VTYz5Q 7tUNwxPHoK1DW1Hbc6hq0pAIoFfZoP72jA4kjdzY0DSuDAlnDUwCVG287x0v7zNuX/sAHRgx /k7/3JHwXHarxCpD5JcP9NsXU68SfmVu2lHYigXgcociX55k/O/dvOlCA9t+TucL1RdpdmZq SROG/YtUBrGx1CzZG7Mx+khDehICkjiLwQLexZ3bcADWtYjXs3ueQTjhforNkBbdXcT4OyHD MQJ27a/61nisZEG6RhMTNZWHFwfw7C2Y0dvBgcVzOEvJWMzeIFfA0l/4bCIuXiQcAAAAAAAA AA== --------------ms010301060508070900070306-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 18:13:27 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01FD316A41A for ; Thu, 6 Sep 2007 18:13:27 +0000 (UTC) (envelope-from kirc.gover@yahoo.com.au) Received: from n7a.bullet.mail.re3.yahoo.com (n7a.bullet.mail.re3.yahoo.com [68.142.236.45]) by mx1.freebsd.org (Postfix) with SMTP id 878A713C46C for ; Thu, 6 Sep 2007 18:13:26 +0000 (UTC) (envelope-from kirc.gover@yahoo.com.au) Received: from [68.142.230.28] by n7.bullet.re3.yahoo.com with NNFMP; 06 Sep 2007 18:00:26 -0000 Received: from [66.196.101.131] by t1.bullet.re2.yahoo.com with NNFMP; 06 Sep 2007 18:00:26 -0000 Received: from [127.0.0.1] by rrr2.mail.re1.yahoo.com with NNFMP; 06 Sep 2007 18:00:26 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 309181.84380.bm@rrr2.mail.re1.yahoo.com Received: (qmail 81634 invoked by uid 60001); 6 Sep 2007 17:06:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=qUOd3AHIb3tJyXnjZuIXcWzrZo8DFf54wfOKLq/tVM7J2c93+1EVQSPoUPmE4SctilW9yjCEtb2IMs7jHbLBkTQX/NS2srzK50AOVWManaggUS1MTKmQVrXeu3uv1hpD0X6tQ9k+Mr8Fmty13IZ9Qc1t5knco9isA36DgxkSSQU=; X-YMail-OSG: DeulvcAVM1nthk7e_BWMkUVJe2bF2I6PtScigYQlfM69wakoZxiAS8wyB6YQyyl5qLaZ5wSTGJ4mj11GGl2rsxGYZg-- Received: from [125.60.235.213] by web44811.mail.sp1.yahoo.com via HTTP; Fri, 07 Sep 2007 03:06:54 EST Date: Fri, 7 Sep 2007 03:06:54 +1000 (EST) From: Kirc Gover To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <695994.81567.qm@web44811.mail.sp1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 18:13:27 -0000 We are in the stage of planning and research for a commercial development of an edge router that will be based mostly on OpenSource software. I would like to solicit for information and recommendation if FreeBSD is a suitable OS. The router is expected to withstand forwarding of sustained traffic from 10Mbps to 1Gbps and maybe more than that. Are there any known limitations of FreeBSD in terms of architecture and performance? Can I just take out a FreeBSD as is and put it with the hardware without any specific or major refinements in its code? I'm very much concerned with its capability in forwarding heavy sustained traffic. Packet loss should be at minimum and critical userland processes should working normally even under heavy load. Are there any known specific limitations of FreeBSD? I have browsed through the archives and found a lot of hangups, deadlocks and freeze issues. What is the usual or minimum hardware requirement? Is soekris box enough, or dual core or ASIC based platforms? I'm aware that there are so many FreeBSD based routers and network based devices in the market. Is this a way to go over realtime and embedded OS such as VxWorks and others (mostly commercial) without putting the licensing cost in picture? I really appreciate any help, suggestions and recommendations. More power to FreeBSD! Thanks Kirc --------------------------------- Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. Get it now. From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 19:07:57 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36E8216A41A for ; Thu, 6 Sep 2007 19:07:57 +0000 (UTC) (envelope-from scrappy@freebsd.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.freebsd.org (Postfix) with ESMTP id E004813C478 for ; Thu, 6 Sep 2007 19:07:56 +0000 (UTC) (envelope-from scrappy@freebsd.org) Received: from localhost (unknown [200.46.204.183]) by hub.org (Postfix) with ESMTP id 3F665B47B50 for ; Thu, 6 Sep 2007 15:49:25 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 86375-02 for ; Thu, 6 Sep 2007 15:49:25 -0300 (ADT) Received: from fserv.hub.org (blk-89-241-126.eastlink.ca [24.89.241.126]) by hub.org (Postfix) with ESMTP id 8F59BB47B4F for ; Thu, 6 Sep 2007 15:49:19 -0300 (ADT) Received: from [192.168.1.2] (unknown [192.168.1.2]) by fserv.hub.org (Postfix) with ESMTP id B2673E809E for ; Thu, 6 Sep 2007 15:49:27 -0300 (ADT) Date: Thu, 06 Sep 2007 15:48:37 -0300 From: "Marc G. Fournier" To: freebsd-net@freebsd.org Message-ID: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: DDoS attacks ... identifying destination ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 19:07:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today, I got hit by an attack, but haven't been able to easily determine whom was being attacked ... I run ipaudit to monitor bandwidth usage, so I have 'source / destination' information, but I'm not finding any particularly easy way to narrow down whom was being attacked ... I run mrtg on the switch so that I know which *server* is being attacked, so I need some method of being able to see whom is being attacked so that I can put appropriate blocks in place ... Is there either a command line command, or ports tool, that I can use similar to top, or systat -iostat, that will help identify the IP that is being attacked? Thank you ... - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG4EuF4QvfyHIvDvMRArtBAJ476WaXhFxzb5S+QRsJuFPQfs6SNgCePONi MCdrm9L85MBseHho0cGM6q8= =EfvZ -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 19:42:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6448416A419 for ; Thu, 6 Sep 2007 19:42:39 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from snipe.secure-computing.net (snipe.secure-computing.net [209.240.66.149]) by mx1.freebsd.org (Postfix) with ESMTP id 22AA113C459 for ; Thu, 6 Sep 2007 19:42:39 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from [10.0.0.14] (unknown [74.95.66.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by snipe.secure-computing.net (Postfix) with ESMTP id C23B817021; Thu, 6 Sep 2007 14:42:37 -0500 (CDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-347158145" Message-Id: <8CAB10E6-C13C-4DCB-B5C0-FE5D7DF00410@secure-computing.net> Content-Transfer-Encoding: 7bit From: Eric F Crist Date: Thu, 6 Sep 2007 14:42:35 -0500 To: Marc G. Fournier X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org Subject: Re: DDoS attacks ... identifying destination ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 19:42:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-347158145 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 6, 2007, at 1:48 PMSep 6, 2007, Marc G. Fournier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Today, I got hit by an attack, but haven't been able to easily > determine whom > was being attacked ... > > I run ipaudit to monitor bandwidth usage, so I have 'source / > destination' > information, but I'm not finding any particularly easy way to > narrow down whom > was being attacked ... > > I run mrtg on the switch so that I know which *server* is being > attacked, so I > need some method of being able to see whom is being attacked so > that I can put > appropriate blocks in place ... > > Is there either a command line command, or ports tool, that I can > use similar > to top, or systat -iostat, that will help identify the IP that is > being > attacked? > > Thank you ... > tcpdump might be of use. ----- Eric F Crist Secure Computing Networks --Apple-Mail-1-347158145 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFG4FgryuaZYRUu2ukRAvRHAKCLX2rJ6EFcvIY2YH8pywkYjUrE5QCfV1An bJdX351wGpQ9ELnBUL8QAuA= =F0t6 -----END PGP SIGNATURE----- --Apple-Mail-1-347158145-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 20:25:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 353DD16A419 for ; Thu, 6 Sep 2007 20:25:39 +0000 (UTC) (envelope-from oli@unixcraft.org) Received: from 42.mail-out.ovh.net (42.mail-out.ovh.net [213.251.189.42]) by mx1.freebsd.org (Postfix) with SMTP id 9248A13C483 for ; Thu, 6 Sep 2007 20:25:38 +0000 (UTC) (envelope-from oli@unixcraft.org) Received: (qmail 10474 invoked by uid 503); 6 Sep 2007 19:59:09 -0000 Received: from b6.ovh.net (HELO mail140.ha.ovh.net) (213.186.33.56) by 42.mail-out.ovh.net with SMTP; 6 Sep 2007 19:59:09 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 6 Sep 2007 19:58:57 -0000 Received: from 150.21.202.62.fix.bluewin.ch (HELO localhost) (62.202.21.150) by ns0.ovh.net with SMTP; 6 Sep 2007 19:58:55 -0000 Date: Thu, 6 Sep 2007 21:59:36 +0200 From: Olivier Brisson To: freebsd-net@freebsd.org Message-ID: <20070906195936.GB81651@haribo.unixcraft.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Ovh-Remote: 62.202.21.150 (150.21.202.62.fix.bluewin.ch) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.5/N Subject: Re: DDoS attacks ... identifying destination ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 20:25:39 -0000 * Marc G. Fournier [070906 21:28]: > > Is there either a command line command, or ports tool, that I can use similar > to top, or systat -iostat, that will help identify the IP that is being > attacked? In some way, you could also use wireshark: http://www.wireshark.org/ Olivier From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 20:29:40 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73E7316A41A for ; Thu, 6 Sep 2007 20:29:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 5F40313C4A6 for ; Thu, 6 Sep 2007 20:29:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 06 Sep 2007 13:29:35 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4F8CA1262DB for ; Thu, 6 Sep 2007 13:29:34 -0700 (PDT) Message-ID: <46E0632D.8070200@elischer.org> Date: Thu, 06 Sep 2007 13:29:33 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 20:29:40 -0000 Ok which clever person did this again? It just broke our product. If it hasn't been removed from 7.0 and 6.x yet it's just about to be... From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 20:43:48 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1658816A417 for ; Thu, 6 Sep 2007 20:43:48 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from mail.duras.ro (mail.duras.ro [86.105.56.133]) by mx1.freebsd.org (Postfix) with ESMTP id BF80613C49D for ; Thu, 6 Sep 2007 20:43:47 +0000 (UTC) (envelope-from mihai@duras.ro) Received: from localhost (localhost [127.0.0.1]) by mail.duras.ro (Postfix) with ESMTP id AFB59167845 for ; Thu, 6 Sep 2007 23:43:50 +0300 (EEST) Received: from mail.duras.ro ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12640-04 for ; Thu, 6 Sep 2007 23:43:49 +0300 (EEST) Received: from [86.105.56.194] (ma.plimb.cu.barca.prin.padure.ro [86.105.56.194]) by mail.duras.ro (Postfix) with ESMTP id 0028CCDD for ; Thu, 6 Sep 2007 23:43:48 +0300 (EEST) Message-ID: <46E066B1.1040601@duras.ro> Date: Thu, 06 Sep 2007 23:44:33 +0300 From: Mihai Tanasescu User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1189016608.00796469.1189004406@10.7.7.3> <46DEFC4F.7060802@FreeBSD.org> In-Reply-To: <46DEFC4F.7060802@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (RedHat) at duras.ro Subject: Re: Freebsd MPD PPTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 20:43:48 -0000 Alexander Motin wrote: > Hi. > > Mihai Tanasescu wrote: >> I'm using MPD4 to establish a PPTP VPN from my FreeBSD 6.2 server to >> some clients and I've started encountering some strange problems. >> >> The connection goes well, everything functions accordingly but after >> a while (very random, can be 5 minutes, 1 hour, 8 hours) I loose >> connectivity (the clients' Windows icon show packet are being sent, >> but nothing is received). A tcpdump on the external interface shows >> no packets going out and the same for tcpdump on ng0 (although I'm >> not sure if it should display something here). > > Tcpdump on ng0 interface should display traffic inside tunnel. It also > may be interesting to look on internal interface as tcpdump is able to > decode PPTP packets. > >> For what I've seen the ip address on the ng0 interface disappears. > > This may be significant. Configure syslog for logging mpd messages, it > should give you information about why IP disappeared. Probably it > happened in result of some error. Also look to the messages logs, > there may be something interesting. > Hello, Sorry..my mistake...I typed ng0 (for the first and second connections) and didn't notice it. Now I have different netgraph interfaces. From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 20:50:22 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D8F916A418; Thu, 6 Sep 2007 20:50:22 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from rogue.navcom.lan (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 54D6013C45E; Thu, 6 Sep 2007 20:50:15 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: by rogue.navcom.lan (Postfix, from userid 1001) id 877F826A9; Thu, 6 Sep 2007 23:50:12 +0300 (EAT) Date: Thu, 6 Sep 2007 23:50:12 +0300 From: Mike Makonnen To: "Marc G. Fournier" Message-ID: <20070906205012.GA60071@rogue.navcom.lan> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD/7.0-CURRENT (i386) Cc: freebsd-net@freebsd.org Subject: Re: DDoS attacks ... identifying destination ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 20:50:22 -0000 On Thu, Sep 06, 2007 at 03:48:37PM -0300, Marc G. Fournier wrote: > > Is there either a command line command, or ports tool, that I can use similar > to top, or systat -iostat, that will help identify the IP that is being > attacked? > I've found net-mgmt/iftop to be very usefull in the past. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mmakonnen @ gmail.com | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm @ FreeBSD.Org | FreeBSD - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 20:52:42 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8959A16A417 for ; Thu, 6 Sep 2007 20:52:42 +0000 (UTC) (envelope-from amason@rackspace.com) Received: from mx2.dfw1.rackspace.com (mx2.dfw1.rackspace.com [72.3.128.181]) by mx1.freebsd.org (Postfix) with ESMTP id 5580013C469 for ; Thu, 6 Sep 2007 20:52:42 +0000 (UTC) (envelope-from amason@rackspace.com) Received: from mail.rackspace.com (mail.rackspace.com [72.3.128.170]) by mx2.dfw1.rackspace.com (8.13.8/8.13.8) with ESMTP id l86KbkwA006582 for ; Thu, 6 Sep 2007 15:37:46 -0500 (envelope-from amason@rackspace.com) Received: from mizar.rackspace.com (nat-vlan0202.sat4.rackspace.com [64.39.0.40]) by mail.rackspace.com (8.13.1/8.13.1) with ESMTP id l86KbjO5018436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Sep 2007 15:37:46 -0500 From: Art Mason Organization: Rackspace Managed Hosting To: freebsd-net@freebsd.org Date: Thu, 6 Sep 2007 15:38:49 -0500 User-Agent: KMail/1.9.7 References: <20070906195936.GB81651@haribo.unixcraft.org> In-Reply-To: <20070906195936.GB81651@haribo.unixcraft.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709061538.49483.amason@rackspace.com> Subject: Re: DDoS attacks ... identifying destination ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 20:52:42 -0000 On Thursday 06 September 2007 14:59:36 Olivier Brisson wrote: > * Marc G. Fournier [070906 21:28]: > > Is there either a command line command, or ports tool, that I can use > > similar to top, or systat -iostat, that will help identify the IP that is > > being attacked? > > In some way, you could also use wireshark: > http://www.wireshark.org/ > > Olivier > _______________________________________________ > 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" In the past, I've used DoSDetector to some success: /usr/ports/net/dosdetector "DoSDetector analyzes and detects suspicious IP traffic and alerts about it. It can detect worm traffic, SYN flood, icmp flood, udp flood attacks and more. It's configurable via a rule set; when an IP exceeds the score limit, DoSDetector prints a warning. WWW: http://dark-zone.eu/resources/unix/dosdetector/" Combined w/ NetFlow exports on your edge routers provides even more accuracy in at least identifying the router and interface the traffic is coming in from and then acting accordingly to mitigate its effects. Many of the CAIDA tools (http://www.caida.org/tools/) can also help with identifying the source and destination of the anoomalous traffic. Hope this information proves to be of some value. Cheers, -- Art Mason amason@rackspace.com Intensive Network Security Rackspace Managed Hosting (800) 961-4454 ext. 4290 Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace Managed Hosting. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse@rackspace.com, and delete the original message. Your cooperation is appreciated. From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 21:26:55 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E52416A418; Thu, 6 Sep 2007 21:26:55 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (unknown [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id 13D6B13C467; Thu, 6 Sep 2007 21:26:55 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1ITOh1-000Gso-9W; Thu, 06 Sep 2007 17:15:15 -0400 Date: Thu, 6 Sep 2007 17:15:15 -0400 From: Gary Palmer To: "Marc G. Fournier" Message-ID: <20070906211515.GA8194@in-addr.com> Mail-Followup-To: "Marc G. Fournier" , freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-net@freebsd.org Subject: Re: DDoS attacks ... identifying destination ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 21:26:55 -0000 On Thu, Sep 06, 2007 at 03:48:37PM -0300, Marc G. Fournier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Today, I got hit by an attack, but haven't been able to easily determine whom > was being attacked ... > > I run ipaudit to monitor bandwidth usage, so I have 'source / destination' > information, but I'm not finding any particularly easy way to narrow down whom > was being attacked ... > > I run mrtg on the switch so that I know which *server* is being attacked, so I > need some method of being able to see whom is being attacked so that I can put > appropriate blocks in place ... > > Is there either a command line command, or ports tool, that I can use similar > to top, or systat -iostat, that will help identify the IP that is being > attacked? > > Thank you ... net/trafshow will show throughput on various protocols on a host in a more user friendly format than raw tcpdump alone. From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 21:37:55 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B56B516A419 for ; Thu, 6 Sep 2007 21:37:55 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A792313C45E for ; Thu, 6 Sep 2007 21:37:55 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 56A5B1A4D80; Thu, 6 Sep 2007 14:34:51 -0700 (PDT) Date: Thu, 6 Sep 2007 14:34:51 -0700 From: Alfred Perlstein To: Kirc Gover Message-ID: <20070906213451.GE87451@elvis.mu.org> References: <695994.81567.qm@web44811.mail.sp1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <695994.81567.qm@web44811.mail.sp1.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 21:37:55 -0000 * Kirc Gover [070906 11:10] wrote: > We are in the stage of planning and research for a commercial development of an edge router that will be based mostly on OpenSource software. I would like to solicit for information and recommendation if FreeBSD is a suitable OS. The router is expected to withstand forwarding of sustained traffic from 10Mbps to 1Gbps and maybe more than that. Are there any known limitations of FreeBSD in terms of architecture and performance? Can I just take out a FreeBSD as is and put it with the hardware without any specific or major refinements in its code? I'm very much concerned with its capability in forwarding heavy sustained traffic. Packet loss should be at minimum and critical userland processes should working normally even under heavy load. Are there any known specific limitations of FreeBSD? I have browsed through the archives and found a lot of hangups, deadlocks and freeze issues. What is the usual or minimum hardware requirement? Is soekris box enough, or dual core or ASIC > based platforms? I'm aware that there are so many FreeBSD based routers and network based devices in the market. Is this a way to go over realtime and embedded OS such as VxWorks and others (mostly commercial) without putting the licensing cost in picture? I really appreciate any help, suggestions and recommendations. More power to FreeBSD! > > Thanks > Kirc Kirc, do some research into Juniper routers. :) 1gps shouldn't be a problem for FreeBSD, however you may have to do some custom tweaks that I can't get into for obvious reasons. I don't think a soekris would be sufficient for 1Gbps, however a mid-range to high-end PC with good NICS and smart software should suffice. I think going with FreeBSD would be a great choice. -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 22:02:42 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C808A16A469 for ; Thu, 6 Sep 2007 22:02:42 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id BBC3313C4D9 for ; Thu, 6 Sep 2007 22:02:42 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 681571A4D7C; Thu, 6 Sep 2007 14:59:38 -0700 (PDT) Date: Thu, 6 Sep 2007 14:59:38 -0700 From: Alfred Perlstein To: net@freebsd.org Message-ID: <20070906215938.GL87451@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: take II: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 22:02:42 -0000 * Alfred Perlstein [070821 14:13] wrote: > Hello all, > > I would like to reserve about 64 entries for VENDOR specific address > families in sys/socket.h. > > I think this will allow vendors to comfortably use the array of > address families without worrying about overlap with FreeBSD > protocols. > > If no one objects I plan to commit this in the next few days. > > The format will be along the lines of: > > AF_VENDOR0 -> AF_VENDOR63 > > Suggestions? Sam asked that I provide some numbers for this proposal, I have them, however in the meanwhile another proposal I've floated was implementing a reservation system where FreeBSD would allocate every even number in the AF_ set of constants and leave the odd numbers for vendors. Q: "What if a vendor wants to then contribute code to FreeBSD?" A: They should have asked FreeBSD to reserve a number, now they can allocate a FreeBSD one. The numbers are specifically meant for internal address families. Here's the numbers for simply bumping AF_MAX: Here's what I have for sizing it up 59 entries. =========================================================================== GDB commands to get sizes of structures related to AF_MAX: printf "AF_MAX: %d\n", sizeof(((struct ifnet *)0)->if_afdata) / sizeof(void*) printf "struct netexport: %d\n", sizeof(struct netexport) printf "struct ifnet: %d\n", sizeof(struct ifnet) printf "route.c:rt_tables: %d\n", sizeof(rt_tables) =========================================================================== Data from AF_MAX = 37 (FreeBSD-stable) AF_MAX: 37 Kernel size: /usr/src/sys/i386/compile/JUNIPER_6_2_SMP % size kernel.debugSMALLMAX text data bss dec hex filename 5964450 791752 367916 7124118 6cb496 kernel.debugSMALLMAX /usr/src/sys/i386/compile/JUNIPER_6_2_SMP % gdb kernel.debugSMALLMAX GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) printf "AF_MAX: %d\n", sizeof(((struct ifnet *)0)->if_afdata) / sizeof(void*) AF_MAX: 37 (gdb) printf "struct netexport: %d\n", sizeof(struct netexport) struct netexport: 316 (gdb) printf "struct ifnet: %d\n", sizeof(struct ifnet) struct ifnet: 644 (gdb) printf "route.c:rt_tables: %d\n", sizeof(rt_tables) route.c:rt_tables: 152 (gdb) =========================================================================== Data from AF_MAX = 96 (FreeBSD-stable + 59 entries) AF_MAX: 96 /usr/src/sys/i386/compile/JUNIPER_6_2_SMP % size kernel.debug text data bss dec hex filename 5964450 791752 368140 7124342 6cb576 kernel.debug .(14:22:56)(alfred@pants.juniper.net) !!! SANDBOX UNSET!!! /usr/src/sys/i386/compile/JUNIPER_6_2_SMP % gdb kernel.debug GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) printf "AF_MAX: %d\n", sizeof(((struct ifnet *)0)->if_afdata) / sizeof(void*) AF_MAX: 96 (gdb) printf "struct netexport: %d\n", sizeof(struct netexport) struct netexport: 552 (gdb) printf "struct ifnet: %d\n", sizeof(struct ifnet) struct ifnet: 880 (gdb) printf "route.c:rt_tables: %d\n", sizeof(rt_tables) route.c:rt_tables: 388 (gdb) % =========================================================================== Summary of differences: size: text data bss dec hex filename 5964450 791752 367916 7124118 6cb496 kernel.debugSMALLMAX 5964450 791752 368140 7124342 6cb576 kernel.debug AF_MAX: 37 struct netexport: 316 struct ifnet: 644 route.c:rt_tables: 152 AF_MAX: 96 struct netexport: 552 struct ifnet: 880 route.c:rt_tables: 388 bss diff: bytes: 224 percent: 1% dec diff: bytes: 224 percent: 1% AF_MAX: difference: 59 percent: 62% struct netexport: bytes: 236 percent: 43% struct ifnet: bytes: 236 percent: 27% route.c:rt_tables: bytes: 236 percent: 61% =========================================================================== Unknown: (I don't know how to get a static variable from gdb) unknown: netatm/atm_if.c: -> atm_ifouttbl =========================================================================== Source inpection reveals the following iterations over AF_MAX: vfs_free_addrlist: iterates whenever a filesystem exports are changed. net/if.c: when deleting an interface, the rt_tables are walked to delete all routes. =========================================================================== Misc information: Both PF_MAX and NET_MAXID are influenced by AF_MAX, but they do not appear to influence the size of anything in the kernel. =========================================================================== Summary: bss diff: bytes: 224 percent: 1% dec diff: bytes: 224 percent: 1% AF_MAX: difference: 59 percent: 62% struct netexport: bytes: 236 percent: 43% struct ifnet: bytes: 236 percent: 27% route.c:rt_tables: bytes: 236 percent: 61% -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 22:03:46 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F29FD16A418 for ; Thu, 6 Sep 2007 22:03:46 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (unknown [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id BB45113C45E for ; Thu, 6 Sep 2007 22:03:46 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1ITPRx-000GzF-Ha; Thu, 06 Sep 2007 18:03:45 -0400 Date: Thu, 6 Sep 2007 18:03:45 -0400 From: Gary Palmer To: Kirc Gover Message-ID: <20070906220345.GB8194@in-addr.com> Mail-Followup-To: Kirc Gover , freebsd-net@freebsd.org References: <695994.81567.qm@web44811.mail.sp1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <695994.81567.qm@web44811.mail.sp1.yahoo.com> Cc: freebsd-net@freebsd.org Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 22:03:47 -0000 On Fri, Sep 07, 2007 at 03:06:54AM +1000, Kirc Gover wrote: > We are in the stage of planning and research for a commercial development of an edge router that will be based mostly on OpenSource software. I would like to solicit for information and recommendation if FreeBSD is a suitable OS. The router is expected to withstand forwarding of sustained traffic from 10Mbps to 1Gbps and maybe more than that. Are there any known limitations of FreeBSD in terms of architecture and performance? Can I just take out a FreeBSD as is and put it with the hardware without any specific or major refinements in its code? I'm very much concerned with its capability in forwarding heavy sustained traffic. Packet loss should be at minimum and critical userland processes should working normally even under heavy load. Are there any known specific limitations of FreeBSD? I have browsed through the archives and found a lot of hangups, deadlocks and freeze issues. What is the usual or minimum hardware requirement? Is soekris box enough, or dual core or ASIC > based platforms? I'm aware that there are so many FreeBSD based routers and network based devices in the market. Is this a way to go over realtime and embedded OS such as VxWorks and others (mostly commercial) without putting the licensing cost in picture? I really appreciate any help, suggestions and recommendations. More power to FreeBSD! Kirc, There are two factors to consider: - bus architecture (PCI, PCI-X, PCI-Express, etc) will dictate the maximum throughput in bits/sec. Allow some overhead for bus arbitration activities, and remember that the packet crosses the bus twice, once on the inbound leg and once on the outbound leg. - Host CPU (and perhaps to a limited extent the interface cards used) will dictate the packets per second (PPS) Most commercial routers run out of packets per second (in real-world situations, not lab mockups) long before the theoretical maximum throughput is achieved. Thinks like ICMP ping packets and TCP RST packets are small (less than 100 bytes usually) but normally take as much CPU to process & route as a 1500 byte (or larger) packet. The more you put in the processing path (e.g. packet filters, complex routing tables) the more you reduce the PPS. Gary From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 22:11:50 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0512116A420 for ; Thu, 6 Sep 2007 22:11:50 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 923CC13C468 for ; Thu, 6 Sep 2007 22:11:49 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so251141nfd for ; Thu, 06 Sep 2007 15:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=dJpM0BzQUc9ae+OjFEY7S2WQyYQR+OljkprJfKH0tiM=; b=Isu7ujUBY4HPrK5mxPBV+V5TYcKdslr3E78xH22FgrxX3/hpd74sHIaU1xnX6wZc2/MluJH07oqP/Unw6IL4xmTSiHt4cWjUl3e5P8LNr3x18GKKJqVfDlsqyTkwna5RjQxaQbLVAp4N/2mrNEAZtjWai0S8hd/doHBF88tgjms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H5tBT+V5g41IQic4fmGNZtZRb/Tr9hzAgRXF/+diRHjzHvuX4sKmP6QBLxj/JZYVR01zkaRvWBmcV9SdjG+wnVNgAYjdIflElWyeNHKUsAfp+4fSVFyeaAtrO2kOxR4yZTWK3OCmGIn+9tkdIFiKH2pi6w2qCtkJBRPYuREzOEQ= Received: by 10.78.180.16 with SMTP id c16mr503577huf.1189115249201; Thu, 06 Sep 2007 14:47:29 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Thu, 6 Sep 2007 14:47:28 -0700 (PDT) Message-ID: Date: Thu, 6 Sep 2007 14:47:28 -0700 From: "Kip Macy" To: "Julian Elischer" In-Reply-To: <46E0632D.8070200@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46E0632D.8070200@elischer.org> Cc: FreeBSD Net Subject: Re: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 22:11:50 -0000 On 9/6/07, Julian Elischer wrote: > Ok which clever person did this again? > > It just broke our product. > If it hasn't been removed from 7.0 and 6.x yet it's just about to be... Talk to Sam. I think we added a flag for LRO, may want something more general. -Kip From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 22:26:08 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67E6416A417 for ; Thu, 6 Sep 2007 22:26:08 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outL.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id 4B25113C45A for ; Thu, 6 Sep 2007 22:26:08 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 06 Sep 2007 15:25:57 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 126EA1262DE for ; Thu, 6 Sep 2007 15:25:57 -0700 (PDT) Message-ID: <46E07E74.5020204@elischer.org> Date: Thu, 06 Sep 2007 15:25:56 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: FreeBSD Net References: <46E0632D.8070200@elischer.org> In-Reply-To: <46E0632D.8070200@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 22:26:08 -0000 Julian Elischer wrote: > Ok which clever person did this again? > > It just broke our product. > If it hasn't been removed from 7.0 and 6.x yet it's just about to be... > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" on the topic above, I've found that the bce driver seems to be throwingaway packets larger than the mtu regardless of the rest of the system.. the following code seems to be responsible.. in the spirit of "be generous on receive" as mentionned before, should it be relaxed? /* Calculate and program the Ethernet MTU size. */ ether_mtu = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN + ifp->if_mtu + ETHER_CRC_LEN; DBPRINT(sc, BCE_INFO, "%s(): setting mtu = %d\n",__FUNCTION__, ether_mtu); /* * Program the mtu, enabling jumbo frame * support if necessary. Also set the mbuf * allocation count for RX frames. */ if (ether_mtu > ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) { REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu | BCE_EMAC_RX_MTU_SIZE_JUMBO_ENA); sc->mbuf_alloc_size = MJUM9BYTES; } else { REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu); sc->mbuf_alloc_size = MCLBYTES; } could probably be relaxed in the non jumbo case to accept packets up to MCLBYTES in size instead of ether_mtu. manually I have set the mtu to larger values which increases ether_mtu and that seems to work.. now, Why do we need this? WCCP is a protocol from Cisco. it encapsulates packets in GRE, including an extra intermediate header. when packets are encapsulated in GRE by cisco 6k switches (quite a few around) they do NOT frag the result, but instead, send an oversized packet. if you have a bce interface, it discards these packets which is a drag. From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 22:27:22 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEA2816A417 for ; Thu, 6 Sep 2007 22:27:22 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by mx1.freebsd.org (Postfix) with ESMTP id 7E92713C461 for ; Thu, 6 Sep 2007 22:27:22 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fk-out-0910.google.com with SMTP id b27so301149fka for ; Thu, 06 Sep 2007 15:27:13 -0700 (PDT) Received: by 10.82.158.12 with SMTP id g12mr1783532bue.1189117632832; Thu, 06 Sep 2007 15:27:12 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Thu, 6 Sep 2007 15:27:12 -0700 (PDT) Message-ID: Date: Fri, 7 Sep 2007 01:27:12 +0300 From: "Vlad GALU" To: "Marc G. Fournier" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-net@freebsd.org Subject: Re: DDoS attacks ... identifying destination ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 22:27:23 -0000 On 9/6/07, Marc G. Fournier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Today, I got hit by an attack, but haven't been able to easily determine whom > was being attacked ... > > I run ipaudit to monitor bandwidth usage, so I have 'source / destination' > information, but I'm not finding any particularly easy way to narrow down whom > was being attacked ... > > I run mrtg on the switch so that I know which *server* is being attacked, so I > need some method of being able to see whom is being attacked so that I can put > appropriate blocks in place ... > > Is there either a command line command, or ports tool, that I can use similar > to top, or systat -iostat, that will help identify the IP that is being > attacked? > ports/net/glflow > Thank you ... > > - ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.4 (FreeBSD) > > iD8DBQFG4EuF4QvfyHIvDvMRArtBAJ476WaXhFxzb5S+QRsJuFPQfs6SNgCePONi > MCdrm9L85MBseHho0cGM6q8= > =EfvZ > -----END PGP SIGNATURE----- > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 23:39:07 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B01B16A41A for ; Thu, 6 Sep 2007 23:39:07 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id EA7B613C46B for ; Thu, 6 Sep 2007 23:39:06 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Thu, 06 Sep 2007 16:38:51 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 4AA532AF; Thu, 6 Sep 2007 16:38:51 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 367922AE; Thu, 6 Sep 2007 16:38:51 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FQP88589; Thu, 6 Sep 2007 16:38:35 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 20D0769CB1; Thu, 6 Sep 2007 16:38:35 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Sep 2007 16:38:35 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <46E07E74.5020204@elischer.org> Thread-Topic: FreeBSD discarding received packets > MTU Thread-Index: Acfw1QLS5vDnuUSSTii9qkh3Gq0u0QAAluow References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> From: "David Christensen" To: "Julian Elischer" , "FreeBSD Net" X-WSS-ID: 6AFE50012M81035300-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 23:39:07 -0000 > Julian Elischer wrote: > > Ok which clever person did this again? > >=20 > > It just broke our product. > > If it hasn't been removed from 7.0 and 6.x yet it's just=20 > about to be... >=20 >=20 > on the topic above, I've found that the bce driver seems to=20 > be throwingaway packets > larger than the mtu regardless of the rest of the system.. This has been part of the driver since it's initial release, it's not an addition or change. >=20 > the following code seems to be responsible.. >=20 > in the spirit of "be generous on receive" as mentionned before, > should it be relaxed? >=20 When this RX MTU size issue was being discussed previously I was wondering why nobody actually discussed what the drivers=20 are doing. Both the NetXtreme (bge) and NetXtreme II (bce) controllers have a setting in the RX MAC to specify the MTU size of the medium. Anything larger than the MTU is discarded and a statistic is recorded. Support for jumbo frames is available (though not on all bge supported controllers) but the general understanding from the hardware design perspective is that the MTU is the maximum message size on the medium and that all controllers on the medium should be configured for the same message size. I've never seen an Ethernet driver that supports different MTUs for RX and TX (is there one implemented under=20 FreeBSD?) and I would really hate to troubleshoot any higher=20 level application problems that might occur if the RX and TX MTU=20 were different for every system on a network. >=20 >=20 > /* Calculate and program the Ethernet MTU size. */ > ether_mtu =3D ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN +=20 > ifp->if_mtu + > ETHER_CRC_LEN; >=20 > DBPRINT(sc, BCE_INFO, "%s(): setting mtu =3D=20 > %d\n",__FUNCTION__, ether_mtu); >=20 >=20 > /* > * Program the mtu, enabling jumbo frame > * support if necessary. Also set the mbuf > * allocation count for RX frames. > */ > if (ether_mtu > ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) { > REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu | > BCE_EMAC_RX_MTU_SIZE_JUMBO_ENA); > sc->mbuf_alloc_size =3D MJUM9BYTES; > } else { > REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu); > sc->mbuf_alloc_size =3D MCLBYTES; > } >=20 >=20 > could probably be relaxed in the non jumbo case to accept=20 > packets up to=20 > MCLBYTES in size instead of ether_mtu. Maybe MCLBYTES is good enough for you but what if someone has a different requirement? How big is big enough for everyone? I suppose supporting different MTUs for RX and TX is possible, though the memory requirements are 5x larger for jumbo frames over standard frames and many users might consider this a waste of resources if they don't support jumbo frames on their=20 network (that would be almost 4MB). Support would obviously be easier if "ifconfig" support both an RX and TX MTU size. >=20 > manually I have set the mtu to larger values which increases > ether_mtu and that seems to work.. > now, Why do we need this? >=20 > WCCP is a protocol from Cisco. > it encapsulates packets in GRE, including an extra=20 > intermediate header. > when packets are encapsulated in GRE by cisco 6k switches=20 > (quite a few around) > they do NOT frag the result, but instead, send an oversized packet. >=20 > if you have a bce interface, it discards these packets which=20 > is a drag. It could certainly be argued by some that Cisco is not standards compliant in this case for sending an oversized Ethernet frame and expecting everyone to accept it. Hardware has limitations and assuming that all Ethernet controllers can support frames greater than 1522 bytes is not reasonable. Fortunately there is a suitable workaround which is setting a larger MTU for the=20 interface. What size do you use? How did you arrive at that value? Dave From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 23:45:32 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E76E16A417 for ; Thu, 6 Sep 2007 23:45:32 +0000 (UTC) (envelope-from canada2007@megaquebec.net) Received: from megaquebec.net (mtl-pppoe-adsl697.securenet.net [66.38.238.188]) by mx1.freebsd.org (Postfix) with SMTP id 62F4013C478 for ; Thu, 6 Sep 2007 23:45:29 +0000 (UTC) (envelope-from canada2007@megaquebec.net) From: "Csd 2007" To: Sender: "Csd 2007" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 6 Sep 2007 19:45:13 -0400 Content-Transfer-Encoding: 8bit Message-Id: <20070906234530.62F4013C478@mx1.freebsd.org> Subject: Available; canadian subsidies grants and loans X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Sep 2007 23:45:32 -0000 PRESS RELEASE Subsidy directory 2007 (Legal Deposit-National-Library) The 2007 edition is now available. A guide containing more than 3200 programs from: Federal & provincial governments, associations & foundations. Including; Organisation names Program names Program descriptions Addresses Telephones Organization Url's (web sites) and program Url's (web sites) CD-Rom (.pdf) or printed (430 pages) Cd-Rom......................$69.95 Printed....................$149.95 To obtain a copy please call toll free: 1-866-322-3376 Remove freebsd-net@freebsd.org at delete2007@mailcan.com From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 00:07:29 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 774C416A418 for ; Fri, 7 Sep 2007 00:07:27 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id F242B13C459 for ; Fri, 7 Sep 2007 00:04:07 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l86NiikF058330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 16:44:44 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46E09202.5070700@errno.com> Date: Thu, 06 Sep 2007 16:49:22 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Kip Macy References: <46E0632D.8070200@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Julian Elischer Subject: Re: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 00:07:29 -0000 Kip Macy wrote: > On 9/6/07, Julian Elischer wrote: > >> Ok which clever person did this again? >> >> It just broke our product. >> If it hasn't been removed from 7.0 and 6.x yet it's just about to be... >> > > Talk to Sam. I think we added a flag for LRO, may want something more general. > No. I've already said (multiple times): nuke the code. Sam From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 00:44:21 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BE2816A417 for ; Fri, 7 Sep 2007 00:44:21 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 020A413C45E for ; Fri, 7 Sep 2007 00:44:20 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so273841nfd for ; Thu, 06 Sep 2007 17:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pXuy1sd0a6yx1l+mB2msMIuo0JjBeNdQmDUk5PeUmQg=; b=VDGZ9XGQ4bo/uy2P8lvoutfXmhV0taNqpbA52wo+NxW7M+cIBvkxMK8eFrSChlUB0aXlq2F++e2OpjhvzGdMNMmxrR61Vs4Xu3tXajYMYQFySj3U+ZXTUQbwcSwLN81GJQ4Bt/6+/ovZWOI7528zGK+C0BI3QZ5ED8HJLaICzy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RxTn1eigVbEdV9XBya90UuF9g8IMZKJw4ZReTsUl+7C/hLPbMn55Te64TqOQyyimpEsqey7uB9rUxZLC9ceOx9GI+zpuVJU3mVAdzhfLQQRts2ViHMrMIKcFFfD6xgkcvVmTnP0clEoSsZDq0q4UYrwSElucos1IBhPj2k2rJrs= Received: by 10.78.123.5 with SMTP id v5mr532991huc.1189125859422; Thu, 06 Sep 2007 17:44:19 -0700 (PDT) Received: by 10.78.162.18 with HTTP; Thu, 6 Sep 2007 17:44:19 -0700 (PDT) Message-ID: Date: Thu, 6 Sep 2007 17:44:19 -0700 From: "Kip Macy" To: "Sam Leffler" In-Reply-To: <46E09202.5070700@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46E0632D.8070200@elischer.org> <46E09202.5070700@errno.com> Cc: FreeBSD Net , Julian Elischer Subject: Re: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 00:44:21 -0000 On 9/6/07, Sam Leffler wrote: > No. I've already said (multiple times): nuke the code. Oops - faulty memory - brain too small. -Kip From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 01:14:05 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4C1116A420 for ; Fri, 7 Sep 2007 01:14:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outJ.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 9359013C442 for ; Fri, 7 Sep 2007 01:14:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 06 Sep 2007 18:14:04 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 45ED21262F4; Thu, 6 Sep 2007 18:14:04 -0700 (PDT) Message-ID: <46E0A5DB.3080404@elischer.org> Date: Thu, 06 Sep 2007 18:14:03 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Christensen References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 01:14:05 -0000 David Christensen wrote: >> Julian Elischer wrote: >>> Ok which clever person did this again? >>> >>> It just broke our product. >>> If it hasn't been removed from 7.0 and 6.x yet it's just >> about to be... >> >> >> on the topic above, I've found that the bce driver seems to >> be throwingaway packets >> larger than the mtu regardless of the rest of the system.. > > This has been part of the driver since it's initial release, > it's not an addition or change. > >> the following code seems to be responsible.. >> >> in the spirit of "be generous on receive" as mentionned before, >> should it be relaxed? >> > > When this RX MTU size issue was being discussed previously I > was wondering why nobody actually discussed what the drivers > are doing. Both the NetXtreme (bge) and NetXtreme II (bce) > controllers have a setting in the RX MAC to specify the MTU > size of the medium. Anything larger than the MTU is discarded > and a statistic is recorded. Support for jumbo frames is > available (though not on all bge supported controllers) but the > general understanding from the hardware design perspective is > that the MTU is the maximum message size on the medium and that > all controllers on the medium should be configured for the same > message size. I've never seen an Ethernet driver that supports > different MTUs for RX and TX (is there one implemented under > FreeBSD?) and I would really hate to troubleshoot any higher > level application problems that might occur if the RX and TX MTU > were different for every system on a network. > >> >> /* Calculate and program the Ethernet MTU size. */ >> ether_mtu = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN + >> ifp->if_mtu + >> ETHER_CRC_LEN; >> >> DBPRINT(sc, BCE_INFO, "%s(): setting mtu = >> %d\n",__FUNCTION__, ether_mtu); >> >> >> /* >> * Program the mtu, enabling jumbo frame >> * support if necessary. Also set the mbuf >> * allocation count for RX frames. >> */ >> if (ether_mtu > ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) { >> REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu | >> BCE_EMAC_RX_MTU_SIZE_JUMBO_ENA); >> sc->mbuf_alloc_size = MJUM9BYTES; >> } else { >> REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu); >> sc->mbuf_alloc_size = MCLBYTES; >> } >> >> >> could probably be relaxed in the non jumbo case to accept >> packets up to >> MCLBYTES in size instead of ether_mtu. > > Maybe MCLBYTES is good enough for you but what if someone has > a different requirement? How big is big enough for everyone? > > I suppose supporting different MTUs for RX and TX is possible, > though the memory requirements are 5x larger for jumbo frames > over standard frames and many users might consider this a waste > of resources if they don't support jumbo frames on their > network (that would be almost 4MB). Support would obviously > be easier if "ifconfig" support both an RX and TX MTU size. > >> manually I have set the mtu to larger values which increases >> ether_mtu and that seems to work.. >> now, Why do we need this? >> >> WCCP is a protocol from Cisco. >> it encapsulates packets in GRE, including an extra >> intermediate header. >> when packets are encapsulated in GRE by cisco 6k switches >> (quite a few around) >> they do NOT frag the result, but instead, send an oversized packet. >> >> if you have a bce interface, it discards these packets which >> is a drag. > > It could certainly be argued by some that Cisco is not standards > compliant in this case for sending an oversized Ethernet frame > and expecting everyone to accept it. Hardware has limitations > and assuming that all Ethernet controllers can support frames > greater than 1522 bytes is not reasonable. Fortunately there is > a suitable workaround which is setting a larger MTU for the > interface. What size do you use? How did you arrive at that > value? I use 1550 to make it work in the test harness. The trouble is that if I set the mtu to 1550, and the machine talks to another such machine with it's mtu also set to 1550 then they negotiate a maximum sized packet based on 1550, and the problem hits me again. This is a web proxy and that problem occurs when there are two layers of proxy and one proxy talks to another. I really just need it to to silently accept a packet some 32 bytes or so larger than the stated MTU. I see no reason for the driver to not do what the em driver does and allow itself to receive any packet up to the MCLBYTES size. We only hit this problem recently because the data interfaces on our devices are usually em NICs and we only just recently started allowing the users to use the built in (on DELL 2950) bce interfaces for this purpose. > > Dave From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 02:01:04 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6F8416A417 for ; Fri, 7 Sep 2007 02:01:04 +0000 (UTC) (envelope-from gloomygroup@hotmail.com) Received: from bay0-omc3-s29.bay0.hotmail.com (bay0-omc3-s29.bay0.hotmail.com [65.54.246.229]) by mx1.freebsd.org (Postfix) with ESMTP id AE77E13C48D for ; Fri, 7 Sep 2007 02:01:04 +0000 (UTC) (envelope-from gloomygroup@hotmail.com) Received: from BAY131-W40 ([65.55.136.75]) by bay0-omc3-s29.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Sep 2007 19:01:04 -0700 Message-ID: X-Originating-IP: [202.79.53.77] From: Gloomy Group To: Tom Judge Date: Fri, 7 Sep 2007 02:01:04 +0000 Importance: Normal In-Reply-To: <46DFC595.7050803@tomjudge.com> References: <46DFC595.7050803@tomjudge.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2007 02:01:04.0573 (UTC) FILETIME=[F2919ED0:01C7F0F2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: RE: Interface Status changes to UP and Down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 02:01:04 -0000 I have tested by changing Cable and Switch too but doesnot seem to solve pr= oblem. May be it;s due to NIC card, it's inbuilt Intel fxp0 card.=20 > Date: Thu, 6 Sep 2007 10:17:09 +0100 > From: tom@tomjudge.com > To: gloomygroup@hotmail.com > CC: freebsd-net@freebsd.org > Subject: Re: Interface Status changes to UP and Down >=20 > Gloomy Group wrote: > > Hi all, > >=20 > > I am running Freebsd 6.2 as Transparent proxy Server. My hardware is= Intel(R) Pentium(R) 4 CPU 3.00GHz, 1GB DDR2 Memory and 2 SATA hardisk. Whi= le checking dmesg it shows link state change to up and Down and sometimes t= he server crashes. > >=20 > > ipfw: pullup failed > > ipfw: pullup failed > > ipfw: pullup failed > > ipfw: pullup failed > > ipfw: pullup failed > > ipfw: pullup failed > > fxp0: link state changed to DOWN > > fxp0: link state changed to UP > > fxp0: link state changed to DOWN > > fxp0: link state changed to UP > > fxp0: link state changed to DOWN > > fxp0: link state changed to UP > > fxp0: link state changed to DOWN > > fxp0: link state changed to UP > > fxp0: link state changed to DOWN > > fxp0: link state changed to UP > > fxp0: link state changed to DOWN > >=20 > >=20 > > Is this due to misconfigured firewall rules or some special tu= ning need in kernel variables; Below is my IPFW rules: >=20 > This is most likely to be being caused by a cable or hardware problem=20 > (NIC or switch). The firewall can't affect the link state of the NIC. >=20 >=20 > Tom >=20 > >=20 > > 00100 allow ip from any to any via lo0 > > 00101 check-state > > 00102 deny icmp from any to any in icmptypes 5,9,13,14,15,16,17 > > 00200 allow icmp from 202.xx.xx.0/24 to me in > > 00201 allow icmp from 202.xx.xx.0/24 to me in > > 00300 allow tcp from me to any out keep-state > > 00301 allow udp from me to any dst-port 53 keep-state > > 00302 allow ip from me to any out keep-state > > 00303 allow tcp from any 80,443 to me in keep-state > > 00304 allow tcp from any 80,443 to any out keep-state > > 00400 allow tcp from 202.79.xx.0/24 to me dst-port 2001 keep-state > > 00500 allow udp from 202.79.xx.xx 3130 to me dst-port 3130 keep-state > > 00501 allow tcp from 202.79.xx.xx 3128 to me in > > 00600 allow udp from 202.79.xx.xx to me dst-port 161 keep-state > > 00601 allow udp from 202.79.xx.xx to me dst-port 3401 keep-state > > 03000 allow tcp from 202.79.xx.0/24 to me dst-port 3128 > > 03001 allow tcp from 202.79.xx.0/24 to me dst-port 3128 > > 03002 fwd 127.0.0.1,3128 tcp from 202.79.xx.0/24 to any dst-port 80 kee= p-state > > 03003 fwd 127.0.0.1,3128 tcp from 202.79.xx.0/24 to any dst-port 80 kee= p-state > > 65534 deny log logamount 200 ip from any to any > >=20 >=20 > _______________________________________________ > 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" _________________________________________________________________ Connect to the next generation of MSN Messenger=A0 http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&sourc= e=3Dwlmailtagline= From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 03:05:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 855CE16A417 for ; Fri, 7 Sep 2007 03:05:39 +0000 (UTC) (envelope-from wgriffin@fraktured.net) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 8D82313C4A7 for ; Fri, 7 Sep 2007 03:05:38 +0000 (UTC) (envelope-from wgriffin@fraktured.net) Received: by nf-out-0910.google.com with SMTP id k4so293669nfd for ; Thu, 06 Sep 2007 20:05:37 -0700 (PDT) Received: by 10.78.181.13 with SMTP id d13mr559123huf.1189132698034; Thu, 06 Sep 2007 19:38:18 -0700 (PDT) Received: by 10.78.11.13 with HTTP; Thu, 6 Sep 2007 19:38:17 -0700 (PDT) Message-ID: Date: Thu, 6 Sep 2007 22:38:17 -0400 From: "Wesley Griffin" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_52841_3683181.1189132697976" Subject: Country Code woes with D-Link DWL-AG530 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 03:05:39 -0000 ------=_Part_52841_3683181.1189132697976 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have purchased a D-Link DWL-AG530 PCI NIC for my gateway and am attempting to get it working with RELENG_6_2 but am having problems and could use some help please. First, I'm using 6.2-RELEASE-p7. Relevant (I've attached the full /var/run/dmesg.boot) dmesg output: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xfeab0000-0xfeabffff irq 9 at device 12.0 on pci2 ath0: unable to collect channel list from hal; regdomain likely 19 country code 0 ath0: Ethernet address: 00:1b:11:bb:da:09 ath0: mac 10.5 phy 6.1 radio 6.3 Following some leads via google and marc, I used this page: and this page: to patch if_ath.c to 'return 0' at line 4736: ----- if (!ath_hal_init_channels(ah, chans, IEEE80211_CHAN_MAX, &nchan, NULL, 0, NULL, cc, HAL_MODE_ALL, outdoor, xchanmode)) { u_int32_t rd; ath_hal_getregdomain(ah, &rd); if_printf(ifp, "unable to collect channel list from hal; " "regdomain likely %u country code %u\n", rd, cc); free(chans, M_TEMP); /* wgriffin return EINVAL; */ return 0; ----- I then ran ar5k (which I believe I found in the madwifi sources) like thus: sudo ./ar5k 0xfeab0000 0x10 but I get the following output: ----- Current value 0x0013 will change to 0x0010 Retrying eeprom write! Retrying eeprom write! [snip lots of this message] EEPROM write failed Write & read don't match 0x0010 != 0x0013 ----- and am now unsure as to what to try next. I've been pouring over the madwifi pages and google results, but cannot find anything else related. Any help would be greatly appreciated. Thanks, Wes ------=_Part_52841_3683181.1189132697976 Content-Type: application/octet-stream; name=dmesg.boot Content-Transfer-Encoding: base64 X-Attachment-Id: f_1pjs7mz Content-Disposition: attachment; filename="dmesg.boot" YXRoMDogPEF0aGVyb3MgNTIxMj4gbWVtIDB4ZmVhYjAwMDAtMHhmZWFiZmZmZiBpcnEgOSBhdCBk ZXZpY2UgMTIuMCBvbiBwY2kyCmF0aDA6IHVuYWJsZSB0byBjb2xsZWN0IGNoYW5uZWwgbGlzdCBm cm9tIGhhbDsgcmVnZG9tYWluIGxpa2VseSAxOSBjb3VudHJ5IGNvZGUgMApkZXZpY2VfYXR0YWNo OiBhdGgwIGF0dGFjaCByZXR1cm5lZCAyMgpwY2kyOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2Ug MTMuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZp Y2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwg SUNIMiBVRE1BMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgx NzcsMHgzNzYsMHhmZmEwLTB4ZmZhZiBhdCBkZXZpY2UgMzEuMSBvbiBwY2kwCmF0YTA6IDxBVEEg Y2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCnVo Y2kwOiA8SW50ZWwgODI4MDFCQS9CQU0gKElDSDIpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0 IDB4ZWY4MC0weGVmOWYgaXJxIDEwIGF0IGRldmljZSAzMS4yIG9uIHBjaTAKdWhjaTA6IFtHSUFO VC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4MjgwMUJBL0JBTSAoSUNIMikgVVNCIGNvbnRyb2xsZXIg VVNCLUE+IG9uIHVoY2kwCnVzYjA6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjA6IEludGVsIFVIQ0kg cm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIwOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+ IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIgYXR0YWNoZWQpCnBtdGltZXIwIG9uIGlzYTAKYXRr YmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24g aXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2Jk MAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmZkYzA6IDxFbmhhbmNlZCBmbG9wcHkgY29udHJvbGxl cj4gYXQgcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBpc2EwCmZkYzA6IFtG QVNUXQpmZDA6IDwxNDQwLUtCIDMuNSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMApwcGMwOiBwYXJh bGxlbCBwb3J0IG5vdCBmb3VuZC4Kc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAw IG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzaW8w IGF0IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBpc2EwCnNpbzA6IHR5cGUg MTY1NTBBCnNpbzE6IGNvbmZpZ3VyZWQgaXJxIDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJx cyAwCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+ IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKVGltZWNv dW50ZXIgIlRTQyIgZnJlcXVlbmN5IDg2Mzg2NzAyMSBIeiBxdWFsaXR5IDgwMApUaW1lY291bnRl cnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmFkMDogMzgxNjZNQiA8V0RDIFdENDAwQkItNzVBVUEx IDE4LjIwRDE4PiBhdCBhdGEwLW1hc3RlciBVRE1BMTAwCmFkMTogMTk2MjNNQiA8SUJNIERUTEEt MzA1MDIwIFRXMk9BNjBBPiBhdCBhdGEwLXNsYXZlIFVETUExMDAKYWNkMDogRFZEUk9NIDxORUMg RFYtNTcwMEEvMy4wNz4gYXQgYXRhMS1tYXN0ZXIgVURNQTMzCmFjZDE6IENEUlcgPExHIENELVJX IENFRC04MDgwQi8xLjA0PiBhdCBhdGExLXNsYXZlIFBJTzQKVHJ5aW5nIHRvIG1vdW50IHJvb3Qg ZnJvbSB1ZnM6L2Rldi9hZDBzMWEKeGwxOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKV2FpdGlu ZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0b3AuLi5k b25lCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRhZW1v bicgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJv Y2VzcyBgc3luY2VyJyB0byBzdG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1haW5pbmcu Li4xIDEgMCAwIGRvbmUKQWxsIGJ1ZmZlcnMgc3luY2VkLgpVcHRpbWU6IDdtMzhzClJlYm9vdGlu Zy4uLgpDb3B5cmlnaHQgKGMpIDE5OTItMjAwNyBUaGUgRnJlZUJTRCBQcm9qZWN0LgpDb3B5cmln aHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5 OTMsIDE5OTQKCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFs bCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBU aGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpGcmVlQlNEIDYuMi1SRUxFQVNFLXA0ICMwOiBUaHUgQXBy IDI2IDE3OjQwOjUzIFVUQyAyMDA3CiAgICByb290QGkzODYtYnVpbGRlci5kYWVtb25vbG9neS5u ZXQ6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQwpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1 ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6IEludGVsIFBlbnRpdW0gSUlJICg4NjMuODct TUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHg2ODYg IFN0ZXBwaW5nID0gNgogIEZlYXR1cmVzPTB4MzgzZjlmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNS LFBBRSxNQ0UsQ1g4LFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsTU1YLEZYU1IsU1NF PgpyZWFsIG1lbW9yeSAgPSAxMzM5NTU1ODQgKDEyNyBNQikKYXZhaWwgbWVtb3J5ID0gMTIxNDkx NDU2ICgxMTUgTUIpCnBucGJpb3M6IEJhZCBQblAgQklPUyBkYXRhIGNoZWNrc3VtCmtiZDEgYXQg a2JkbXV4MAphdGhfaGFsOiAwLjkuMTcuMiAoQVI1MjEwLCBBUjUyMTEsIEFSNTIxMiwgUkY1MTEx LCBSRjUxMTIsIFJGMjQxMywgUkY1NDEzKQphY3BpMDogPERFTEwgWlVVTD4gb24gbW90aGVyYm9h cmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZy ZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1l ciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMApjcHUwOiA8QUNQSSBD UFU+IG9uIGFjcGkwCmFjcGlfYnV0dG9uMDogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6 IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liMAphZ3AwOiA8SW50ZWwgODI4MTUgKGk4MTUgR01DSCkgaG9z dCB0byBQQ0kgYnJpZGdlPiBtZW0gMHhmODAwMDAwMC0weGZiZmZmZmZmIGF0IGRldmljZSAwLjAg b24gcGNpMApwY2liMTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNp MTogPFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAwLjAg KG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMzAuMCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnhsMDogPDNDb20g M2M5MDVCLVRYIEZhc3QgRXRoZXJsaW5rIFhMPiBwb3J0IDB4ZGMwMC0weGRjN2YgbWVtIDB4ZmVh ZmZjMDAtMHhmZWFmZmM3ZiBpcnEgMyBhdCBkZXZpY2UgMTAuMCBvbiBwY2kyCm1paWJ1czA6IDxN SUkgYnVzPiBvbiB4bDAKeGxwaHkwOiA8M0NvbSBpbnRlcm5hbCBtZWRpYSBpbnRlcmZhY2U+IG9u IG1paWJ1czAKeGxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFz ZVRYLUZEWCwgYXV0bwp4bDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjEwOjVhOmM3OmZiOmM2Cnhs MTogPDNDb20gM2M5MDUtVFggRmFzdCBFdGhlcmxpbmsgWEw+IHBvcnQgMHhkZjAwLTB4ZGYzZiBp cnEgNyBhdCBkZXZpY2UgMTEuMCBvbiBwY2kyCm1paWJ1czE6IDxNSUkgYnVzPiBvbiB4bDEKbnNw aHkwOiA8RFA4Mzg0MCAxMC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWlidXMxCm5zcGh5MDog IDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8KeGwx OiBFdGhlcm5ldCBhZGRyZXNzOiAwMDo2MDowODowZDo4NTpmZAphdGgwOiA8QXRoZXJvcyA1MjEy PiBtZW0gMHhmZWFiMDAwMC0weGZlYWJmZmZmIGlycSA5IGF0IGRldmljZSAxMi4wIG9uIHBjaTIK YXRoMDogdW5hYmxlIHRvIGNvbGxlY3QgY2hhbm5lbCBsaXN0IGZyb20gaGFsOyByZWdkb21haW4g bGlrZWx5IDE5IGNvdW50cnkgY29kZSAwCmRldmljZV9hdHRhY2g6IGF0aDAgYXR0YWNoIHJldHVy bmVkIDIyCnBjaTI6IDxzaW1wbGUgY29tbXM+IGF0IGRldmljZSAxMy4wIChubyBkcml2ZXIgYXR0 YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNh MDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBJQ0gyIFVETUExMDAgY29udHJv bGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGZmYTAtMHhm ZmFmIGF0IGRldmljZSAzMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBj aTAKYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKdWhjaTA6IDxJbnRlbCA4MjgwMUJB L0JBTSAoSUNIMikgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IHBvcnQgMHhlZjgwLTB4ZWY5ZiBpcnEg MTAgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAp1aGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMDogPElu dGVsIDgyODAxQkEvQkFNIChJQ0gyKSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAKdXNi MDogVVNCIHJldmlzaW9uIDEuMAp1aHViMDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8w LCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwg c2VsZiBwb3dlcmVkCnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5v IGRyaXZlciBhdHRhY2hlZCkKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4g cG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAx IG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpmZGMwOiA8 ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQgMHgzZjAtMHgzZjEsMHgzZjItMHgzZjMsMHgz ZjQtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTAKZmRjMDogW0ZBU1RdCmZkMDogPDE0 NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCnNpbzA6IDwxNjU1MEEtY29tcGF0aWJs ZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwCnNp bzA6IHR5cGUgMTY1NTBBCnBtdGltZXIwIG9uIGlzYTAKcHBjMDogcGFyYWxsZWwgcG9ydCBub3Qg Zm91bmQuCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDog VkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2lvMTogY29uZmlndXJlZCBp cnEgMyBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBtYXkgbm90IGJl IGVuYWJsZWQKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21l bSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgODYz ODY3Njg0IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMK YWQwOiAzODE2Nk1CIDxXREMgV0Q0MDBCQi03NUFVQTEgMTguMjBEMTg+IGF0IGF0YTAtbWFzdGVy IFVETUExMDAKYWQxOiAxOTYyM01CIDxJQk0gRFRMQS0zMDUwMjAgVFcyT0E2MEE+IGF0IGF0YTAt c2xhdmUgVURNQTEwMAphY2QwOiBEVkRST00gPE5FQyBEVi01NzAwQS8zLjA3PiBhdCBhdGExLW1h c3RlciBVRE1BMzMKYWNkMTogQ0RSVyA8TEcgQ0QtUlcgQ0VELTgwODBCLzEuMDQ+IGF0IGF0YTEt c2xhdmUgUElPNApUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMxYQp4bDE6 IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUApXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5 c3RlbSBwcm9jZXNzIGB2bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29u ZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aW5n IChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi4K U3luY2luZyBkaXNrcywgdm5vZGVzIHJlbWFpbmluZy4uLjMgMSAxIDAgMCBkb25lCkFsbCBidWZm ZXJzIHN5bmNlZC4KVXB0aW1lOiAzN20zNXMKUmVib290aW5nLi4uCkNvcHlyaWdodCAoYykgMTk5 Mi0yMDA3IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4 MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJlZ2VudHMg b2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KRnJl ZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVlQlNEIEZvdW5kYXRpb24u CkZyZWVCU0QgNi4yLVJFTEVBU0UtcDQgIzA6IFRodSBBcHIgMjYgMTc6NDA6NTMgVVRDIDIwMDcK ICAgIHJvb3RAaTM4Ni1idWlsZGVyLmRhZW1vbm9sb2d5Lm5ldDovdXNyL29iai91c3Ivc3JjL3N5 cy9HRU5FUklDClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0 eSAwCkNQVTogSW50ZWwgUGVudGl1bSBJSUkgKDg2My44Ny1NSHogNjg2LWNsYXNzIENQVSkKICBP cmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDY4NiAgU3RlcHBpbmcgPSA2CiAgRmVhdHVy ZXM9MHgzODNmOWZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsU0VQLE1UUlIs UEdFLE1DQSxDTU9WLFBBVCxQU0UzNixNTVgsRlhTUixTU0U+CnJlYWwgbWVtb3J5ICA9IDEzMzk1 NTU4NCAoMTI3IE1CKQphdmFpbCBtZW1vcnkgPSAxMjE1MDc4NDAgKDExNSBNQikKcG5wYmlvczog QmFkIFBuUCBCSU9TIGRhdGEgY2hlY2tzdW0Ka2JkMSBhdCBrYmRtdXgwCmF0aF9oYWw6IDAuOS4x Ny4yIChBUjUyMTAsIEFSNTIxMSwgQVI1MjEyLCBSRjUxMTEsIFJGNTExMiwgUkYyNDEzLCBSRjU0 MTMpCmNwdTAgb24gbW90aGVyYm9hcmQKcGNpYjA6IDxJbnRlbCA4MjgxNSAoaTgxNSBHTUNIKSBI b3N0IFRvIEh1YiBicmlkZ2U+IHBjaWJ1cyAwIG9uIG1vdGhlcmJvYXJkCnBpcjA6IDxQQ0kgSW50 ZXJydXB0IFJvdXRpbmcgVGFibGU6IDEyIEVudHJpZXM+IG9uIG1vdGhlcmJvYXJkCnBjaTA6IDxQ Q0kgYnVzPiBvbiBwY2liMAphZ3AwOiA8SW50ZWwgODI4MTUgKGk4MTUgR01DSCkgaG9zdCB0byBQ Q0kgYnJpZGdlPiBtZW0gMHhmODAwMDAwMC0weGZiZmZmZmZmIGF0IGRldmljZSAwLjAgb24gcGNp MApwY2liMTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpMTogPFBD SSBidXM+IG9uIHBjaWIxCnBjaTE6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAwLjAgKG5vIGRy aXZlciBhdHRhY2hlZCkKcGNpYjI6IDxQQ0lCSU9TIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug MzAuMCBvbiBwY2kwCnBjaTI6IDxQQ0kgYnVzPiBvbiBwY2liMgp4bDA6IDwzQ29tIDNjOTA1Qi1U WCBGYXN0IEV0aGVybGluayBYTD4gcG9ydCAweGRjMDAtMHhkYzdmIG1lbSAweGZlYWZmYzAwLTB4 ZmVhZmZjN2YgaXJxIDMgYXQgZGV2aWNlIDEwLjAgb24gcGNpMgptaWlidXMwOiA8TUlJIGJ1cz4g b24geGwwCnhscGh5MDogPDNDb20gaW50ZXJuYWwgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWlidXMw CnhscGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgs IGF1dG8KeGwwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxMDo1YTpjNzpmYjpjNgp4bDE6IDwzQ29t IDNjOTA1LVRYIEZhc3QgRXRoZXJsaW5rIFhMPiBwb3J0IDB4ZGYwMC0weGRmM2YgaXJxIDcgYXQg ZGV2aWNlIDExLjAgb24gcGNpMgptaWlidXMxOiA8TUlJIGJ1cz4gb24geGwxCm5zcGh5MDogPERQ ODM4NDAgMTAvMTAwIG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVzMQpuc3BoeTA6ICAxMGJhc2VU LCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvCnhsMTogRXRoZXJu ZXQgYWRkcmVzczogMDA6NjA6MDg6MGQ6ODU6ZmQKYXRoMDogPEF0aGVyb3MgNTIxMj4gbWVtIDB4 ZmVhYjAwMDAtMHhmZWFiZmZmZiBpcnEgOSBhdCBkZXZpY2UgMTIuMCBvbiBwY2kyCmF0aDA6IHVu YWJsZSB0byBjb2xsZWN0IGNoYW5uZWwgbGlzdCBmcm9tIGhhbDsgcmVnZG9tYWluIGxpa2VseSAx OSBjb3VudHJ5IGNvZGUgMApkZXZpY2VfYXR0YWNoOiBhdGgwIGF0dGFjaCByZXR1cm5lZCAyMgpw Y2kyOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgMTMuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpp c2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0Eg YnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgSUNIMiBVRE1BMTAwIGNvbnRyb2xsZXI+IHBv cnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmZmEwLTB4ZmZhZiBhdCBk ZXZpY2UgMzEuMSBvbiBwY2kwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTE6 IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCnVoY2kwOiA8SW50ZWwgODI4MDFCQS9CQU0gKElD SDIpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4ZWY4MC0weGVmOWYgaXJxIDEwIGF0IGRl dmljZSAzMS4yIG9uIHBjaTAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4Mjgw MUJBL0JBTSAoSUNIMikgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVoY2kwCnVzYjA6IFVTQiBy ZXZpc2lvbiAxLjAKdWh1YjA6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEu MDAvMS4wMCwgYWRkciAxCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIg YXR0YWNoZWQpCnBtdGltZXIwIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIg KGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4g aXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmZk YzA6IDxFbmhhbmNlZCBmbG9wcHkgY29udHJvbGxlcj4gYXQgcG9ydCAweDNmMC0weDNmNSwweDNm NyBpcnEgNiBkcnEgMiBvbiBpc2EwCmZkYzA6IFtGQVNUXQpmZDA6IDwxNDQwLUtCIDMuNSIgZHJp dmU+IG9uIGZkYzAgZHJpdmUgMApwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3VuZC4Kc2MwOiA8 U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1 YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzaW8wIGF0IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQg ZmxhZ3MgMHgxMCBvbiBpc2EwCnNpbzA6IHR5cGUgMTY1NTBBCnNpbzE6IGNvbmZpZ3VyZWQgaXJx IDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBl bmFibGVkCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0g MHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDg2Mzg2 ODA1NSBIeiBxdWFsaXR5IDgwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmFk MDogMzgxNjZNQiA8V0RDIFdENDAwQkItNzVBVUExIDE4LjIwRDE4PiBhdCBhdGEwLW1hc3RlciBV RE1BMTAwCmFkMTogMTk2MjNNQiA8SUJNIERUTEEtMzA1MDIwIFRXMk9BNjBBPiBhdCBhdGEwLXNs YXZlIFVETUExMDAKYWNkMDogRFZEUk9NIDxORUMgRFYtNTcwMEEvMy4wNz4gYXQgYXRhMS1tYXN0 ZXIgVURNQTMzCmFjZDE6IENEUlcgPExHIENELVJXIENFRC04MDgwQi8xLjA0PiBhdCBhdGExLXNs YXZlIFBJTzQKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzMWEKeGwxOiBs aW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0 ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0b3AuLi5kb25lCldhaXRpbmcgKG1heCA2MCBzZWNvbmRz KSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRhZW1vbicgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAo bWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgc3luY2VyJyB0byBzdG9wLi4uClN5 bmNpbmcgZGlza3MsIHZub2RlcyByZW1haW5pbmcuLi4yIDEgMCAwIDAgZG9uZQpBbGwgYnVmZmVy cyBzeW5jZWQuClVwdGltZTogNTBtNDlzClJlYm9vdGluZy4uLgpDb3B5cmlnaHQgKGMpIDE5OTIt MjAwNyBUaGUgRnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMs IDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVzZXJ2ZWQuCkZyZWVC U0QgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLgpG cmVlQlNEIDYuMi1SRUxFQVNFICMwOiBGcmkgQXVnIDMxIDIxOjMwOjEzIEVEVCAyMDA3CiAgICB3 Z3JpZmZpbkBkZWd1Y2hpLmludGVybmFsLmZyYWt0dXJlZC5uZXQ6L3Vzci9vYmovdXNyL3NyYy9z eXMvR0VORVJJQwpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxp dHkgMApDUFU6IEludGVsIFBlbnRpdW0gSUlJICg4NjMuODctTUh6IDY4Ni1jbGFzcyBDUFUpCiAg T3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHg2ODYgIFN0ZXBwaW5nID0gNgogIEZlYXR1 cmVzPTB4MzgzZjlmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LFNFUCxNVFJS LFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsTU1YLEZYU1IsU1NFPgpyZWFsIG1lbW9yeSAgPSAxMzM5 NTU1ODQgKDEyNyBNQikKYXZhaWwgbWVtb3J5ID0gMTIxNTA3ODQwICgxMTUgTUIpCnBucGJpb3M6 IEJhZCBQblAgQklPUyBkYXRhIGNoZWNrc3VtCmtiZDEgYXQga2JkbXV4MAphdGhfaGFsOiAwLjku MTcuMiAoQVI1MjEwLCBBUjUyMTEsIEFSNTIxMiwgUkY1MTExLCBSRjUxMTIsIFJGMjQxMywgUkY1 NDEzKQpjcHUwIG9uIG1vdGhlcmJvYXJkCnBjaWIwOiA8SW50ZWwgODI4MTUgKGk4MTUgR01DSCkg SG9zdCBUbyBIdWIgYnJpZGdlPiBwY2lidXMgMCBvbiBtb3RoZXJib2FyZApwaXIwOiA8UENJIElu dGVycnVwdCBSb3V0aW5nIFRhYmxlOiAxMiBFbnRyaWVzPiBvbiBtb3RoZXJib2FyZApwY2kwOiA8 UENJIGJ1cz4gb24gcGNpYjAKYWdwMDogPEludGVsIDgyODE1IChpODE1IEdNQ0gpIGhvc3QgdG8g UENJIGJyaWRnZT4gbWVtIDB4ZjgwMDAwMDAtMHhmYmZmZmZmZiBhdCBkZXZpY2UgMC4wIG9uIHBj aTAKcGNpYjE6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaTE6IDxQ Q0kgYnVzPiBvbiBwY2liMQpwY2kxOiA8ZGlzcGxheSwgVkdBPiBhdCBkZXZpY2UgMC4wIChubyBk cml2ZXIgYXR0YWNoZWQpCnBjaWIyOiA8UENJQklPUyBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNl IDMwLjAgb24gcGNpMApwY2kyOiA8UENJIGJ1cz4gb24gcGNpYjIKeGwwOiA8M0NvbSAzYzkwNUIt VFggRmFzdCBFdGhlcmxpbmsgWEw+IHBvcnQgMHhkYzAwLTB4ZGM3ZiBtZW0gMHhmZWFmZmMwMC0w eGZlYWZmYzdmIGlycSAzIGF0IGRldmljZSAxMC4wIG9uIHBjaTIKbWlpYnVzMDogPE1JSSBidXM+ IG9uIHhsMAp4bHBoeTA6IDwzQ29tIGludGVybmFsIG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVz MAp4bHBoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRY LCBhdXRvCnhsMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MTA6NWE6Yzc6ZmI6YzYKeGwxOiA8M0Nv bSAzYzkwNS1UWCBGYXN0IEV0aGVybGluayBYTD4gcG9ydCAweGRmMDAtMHhkZjNmIGlycSA3IGF0 IGRldmljZSAxMS4wIG9uIHBjaTIKbWlpYnVzMTogPE1JSSBidXM+IG9uIHhsMQpuc3BoeTA6IDxE UDgzODQwIDEwLzEwMCBtZWRpYSBpbnRlcmZhY2U+IG9uIG1paWJ1czEKbnNwaHkwOiAgMTBiYXNl VCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwp4bDE6IEV0aGVy bmV0IGFkZHJlc3M6IDAwOjYwOjA4OjBkOjg1OmZkCmF0aDA6IDxBdGhlcm9zIDUyMTI+IG1lbSAw eGZlYWIwMDAwLTB4ZmVhYmZmZmYgaXJxIDkgYXQgZGV2aWNlIDEyLjAgb24gcGNpMgphdGgwOiB1 bmFibGUgdG8gY29sbGVjdCBjaGFubmVsIGxpc3QgZnJvbSBoYWw7IHJlZ2RvbWFpbiBsaWtlbHkg MTkgY291bnRyeSBjb2RlIDAKYXRoMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MWI6MTE6YmI6ZGE6 MDkKYXRoMDogbWFjIDEwLjUgcGh5IDYuMSByYWRpbyA2LjMKcGNpMjogPHNpbXBsZSBjb21tcz4g YXQgZGV2aWNlIDEzLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRn ZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNp MDogPEludGVsIElDSDIgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2 LDB4MTcwLTB4MTc3LDB4Mzc2LDB4ZmZhMC0weGZmYWYgYXQgZGV2aWNlIDMxLjEgb24gcGNpMAph dGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24g YXRhcGNpMAp1aGNpMDogPEludGVsIDgyODAxQkEvQkFNIChJQ0gyKSBVU0IgY29udHJvbGxlciBV U0ItQT4gcG9ydCAweGVmODAtMHhlZjlmIGlycSAxMCBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCnVo Y2kwOiBbR0lBTlQtTE9DS0VEXQp1c2IwOiA8SW50ZWwgODI4MDFCQS9CQU0gKElDSDIpIFVTQiBj b250cm9sbGVyIFVTQi1BPiBvbiB1aGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIwOiBJ bnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1aHVi MDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKcGNpMDogPHNlcmlhbCBi dXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQpwbXRpbWVyMCBv biBpc2EwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2 MCwweDY0IG9uIGlzYTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2Jk MCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpmZGMwOiA8RW5oYW5jZWQgZmxvcHB5 IGNvbnRyb2xsZXI+IGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gaXNh MApmZGMwOiBbRkFTVF0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZlIDAK cHBjMDogcGFyYWxsZWwgcG9ydCBub3QgZm91bmQuCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBm bGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0w eDMwMD4Kc2lvMCBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gaXNhMApz aW8wOiB0eXBlIDE2NTUwQQpzaW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAgb2Yg cHJvYmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZAp2Z2EwOiA8R2VuZXJp YyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBp c2EwClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSA4NjM4NjYxOTQgSHogcXVhbGl0eSA4MDAK VGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwphZDA6IDM4MTY2TUIgPFdEQyBXRDQw MEJCLTc1QVVBMSAxOC4yMEQxOD4gYXQgYXRhMC1tYXN0ZXIgVURNQTEwMAphZDE6IDE5NjIzTUIg PElCTSBEVExBLTMwNTAyMCBUVzJPQTYwQT4gYXQgYXRhMC1zbGF2ZSBVRE1BMTAwCmFjZDA6IERW RFJPTSA8TkVDIERWLTU3MDBBLzMuMDc+IGF0IGF0YTEtbWFzdGVyIFVETUEzMwphY2QxOiBDRFJX IDxMRyBDRC1SVyBDRUQtODA4MEIvMS4wND4gYXQgYXRhMS1zbGF2ZSBQSU80ClRyeWluZyB0byBt b3VudCByb290IGZyb20gdWZzOi9kZXYvYWQwczFhCmF0aDA6IGludmFsaWQgY2hhbm5lbCAoTlVM TCkKYXRoMDogaW52YWxpZCBjaGFubmVsIChOVUxMKQp4bDE6IGxpbmsgc3RhdGUgY2hhbmdlZCB0 byBVUAphdGgwOiBpbnZhbGlkIGNoYW5uZWwgKE5VTEwpCldhaXRpbmcgKG1heCA2MCBzZWNvbmRz KSBmb3Igc3lzdGVtIHByb2Nlc3MgYHZubHJ1JyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXgg NjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBidWZkYWVtb24nIHRvIHN0b3AuLi5kb25l CldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYHN5bmNlcicgdG8g c3RvcC4uLgpTeW5jaW5nIGRpc2tzLCB2bm9kZXMgcmVtYWluaW5nLi4uMCAxIDAgMCBkb25lCkFs bCBidWZmZXJzIHN5bmNlZC4KVXB0aW1lOiAyZDIyaDI0bTUzcwpSZWJvb3RpbmcuLi4KQ29weXJp Z2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5 LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglU aGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJl c2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0Qg Rm91bmRhdGlvbi4KRnJlZUJTRCA2LjItUkVMRUFTRS1wNCAjMDogVGh1IEFwciAyNiAxNzo0MDo1 MyBVVEMgMjAwNwogICAgcm9vdEBpMzg2LWJ1aWxkZXIuZGFlbW9ub2xvZ3kubmV0Oi91c3Ivb2Jq L3Vzci9zcmMvc3lzL0dFTkVSSUMKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4 MiBIeiBxdWFsaXR5IDAKQ1BVOiBJbnRlbCBQZW50aXVtIElJSSAoODYzLjg3LU1IeiA2ODYtY2xh c3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4Njg2ICBTdGVwcGluZyA9 IDYKICBGZWF0dXJlcz0weDM4M2Y5ZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENY OCxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LE1NWCxGWFNSLFNTRT4KcmVhbCBtZW1v cnkgID0gMTMzOTU1NTg0ICgxMjcgTUIpCmF2YWlsIG1lbW9yeSA9IDEyMTUwNzg0MCAoMTE1IE1C KQpwbnBiaW9zOiBCYWQgUG5QIEJJT1MgZGF0YSBjaGVja3N1bQprYmQxIGF0IGtiZG11eDAKYXRo X2hhbDogMC45LjE3LjIgKEFSNTIxMCwgQVI1MjExLCBBUjUyMTIsIFJGNTExMSwgUkY1MTEyLCBS RjI0MTMsIFJGNTQxMykKY3B1MCBvbiBtb3RoZXJib2FyZApwY2liMDogPEludGVsIDgyODE1IChp ODE1IEdNQ0gpIEhvc3QgVG8gSHViIGJyaWRnZT4gcGNpYnVzIDAgb24gbW90aGVyYm9hcmQKcGly MDogPFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZTogMTIgRW50cmllcz4gb24gbW90aGVyYm9h cmQKcGNpMDogPFBDSSBidXM+IG9uIHBjaWIwCmFncDA6IDxJbnRlbCA4MjgxNSAoaTgxNSBHTUNI KSBob3N0IHRvIFBDSSBicmlkZ2U+IG1lbSAweGY4MDAwMDAwLTB4ZmJmZmZmZmYgYXQgZGV2aWNl IDAuMCBvbiBwY2kwCnBjaWIxOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNp MApwY2kxOiA8UENJIGJ1cz4gb24gcGNpYjEKcGNpMTogPGRpc3BsYXksIFZHQT4gYXQgZGV2aWNl IDAuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liMjogPFBDSUJJT1MgUENJLVBDSSBicmlkZ2U+ IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKcGNpMjogPFBDSSBidXM+IG9uIHBjaWIyCnhsMDogPDND b20gM2M5MDVCLVRYIEZhc3QgRXRoZXJsaW5rIFhMPiBwb3J0IDB4ZGMwMC0weGRjN2YgbWVtIDB4 ZmVhZmZjMDAtMHhmZWFmZmM3ZiBpcnEgMyBhdCBkZXZpY2UgMTAuMCBvbiBwY2kyCm1paWJ1czA6 IDxNSUkgYnVzPiBvbiB4bDAKeGxwaHkwOiA8M0NvbSBpbnRlcm5hbCBtZWRpYSBpbnRlcmZhY2U+ IG9uIG1paWJ1czAKeGxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAw YmFzZVRYLUZEWCwgYXV0bwp4bDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjEwOjVhOmM3OmZiOmM2 CnhsMTogPDNDb20gM2M5MDUtVFggRmFzdCBFdGhlcmxpbmsgWEw+IHBvcnQgMHhkZjAwLTB4ZGYz ZiBpcnEgNyBhdCBkZXZpY2UgMTEuMCBvbiBwY2kyCm1paWJ1czE6IDxNSUkgYnVzPiBvbiB4bDEK bnNwaHkwOiA8RFA4Mzg0MCAxMC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWlidXMxCm5zcGh5 MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8K eGwxOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDo2MDowODowZDo4NTpmZAphdGgwOiA8QXRoZXJvcyA1 MjEyPiBtZW0gMHhmZWFiMDAwMC0weGZlYWJmZmZmIGlycSA5IGF0IGRldmljZSAxMi4wIG9uIHBj aTIKYXRoMDogdW5hYmxlIHRvIGNvbGxlY3QgY2hhbm5lbCBsaXN0IGZyb20gaGFsOyByZWdkb21h aW4gbGlrZWx5IDE5IGNvdW50cnkgY29kZSAwCmRldmljZV9hdHRhY2g6IGF0aDAgYXR0YWNoIHJl dHVybmVkIDIyCnBjaTI6IDxzaW1wbGUgY29tbXM+IGF0IGRldmljZSAxMy4wIChubyBkcml2ZXIg YXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAK aXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBJQ0gyIFVETUExMDAgY29u dHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGZmYTAt MHhmZmFmIGF0IGRldmljZSAzMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0 YXBjaTAKYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKdWhjaTA6IDxJbnRlbCA4Mjgw MUJBL0JBTSAoSUNIMikgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IHBvcnQgMHhlZjgwLTB4ZWY5ZiBp cnEgMTAgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAp1aGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMDog PEludGVsIDgyODAxQkEvQkFNIChJQ0gyKSBVU0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTAK dXNiMDogVVNCIHJldmlzaW9uIDEuMAp1aHViMDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3Mg OS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMg KG5vIGRyaXZlciBhdHRhY2hlZCkKcG10aW1lcjAgb24gaXNhMAphdGtiZGMwOiA8S2V5Ym9hcmQg Y29udHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBvbiBpc2EwCmF0a2JkMDogPEFU IEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5U LUxPQ0tFRF0KZmRjMDogPEVuaGFuY2VkIGZsb3BweSBjb250cm9sbGVyPiBhdCBwb3J0IDB4M2Yw LTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGlzYTAKZmRjMDogW0ZBU1RdCmZkMDogPDE0NDAt S0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCnBwYzA6IHBhcmFsbGVsIHBvcnQgbm90IGZv dW5kLgpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZH QSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNpbzAgYXQgcG9ydCAweDNmOC0w eDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGlzYTAKc2lvMDogdHlwZSAxNjU1MEEKc2lvMTogY29u ZmlndXJlZCBpcnEgMyBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBt YXkgbm90IGJlIGVuYWJsZWQKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0w eDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApUaW1lY291bnRlciAiVFNDIiBmcmVx dWVuY3kgODYzODY2MTUxIEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEu MDAwIG1zZWMKYWQwOiAzODE2Nk1CIDxXREMgV0Q0MDBCQi03NUFVQTEgMTguMjBEMTg+IGF0IGF0 YTAtbWFzdGVyIFVETUExMDAKYWQxOiAxOTYyM01CIDxJQk0gRFRMQS0zMDUwMjAgVFcyT0E2MEE+ IGF0IGF0YTAtc2xhdmUgVURNQTEwMAphY2QwOiBEVkRST00gPE5FQyBEVi01NzAwQS8zLjA3PiBh dCBhdGExLW1hc3RlciBVRE1BMzMKYWNkMTogQ0RSVyA8TEcgQ0QtUlcgQ0VELTgwODBCLzEuMDQ+ IGF0IGF0YTEtc2xhdmUgUElPNApUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2Fk MHMxYQp4bDE6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUApXYWl0aW5nIChtYXggNjAgc2Vjb25k cykgZm9yIHN5c3RlbSBwcm9jZXNzIGB2bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4 IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9u ZQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRv IHN0b3AuLi4KU3luY2luZyBkaXNrcywgdm5vZGVzIHJlbWFpbmluZy4uLjIgMCAxIDAgMCBkb25l CkFsbCBidWZmZXJzIHN5bmNlZC4KVXB0aW1lOiAxZDE5aDI1bTQ0cwpSZWJvb3RpbmcuLi4KQ29w eXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAx OTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0 CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRz IHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVC U0QgRm91bmRhdGlvbi4KRnJlZUJTRCA2LjItUkVMRUFTRS1wNyAjMjogV2VkIFNlcCAgNSAxNTox OTo0MiBFRFQgMjAwNwogICAgd2dyaWZmaW5AZGVndWNoaS5pbnRlcm5hbC5mcmFrdHVyZWQubmV0 Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVu Y3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKQ1BVOiBJbnRlbCBQZW50aXVtIElJSSAoODYzLjg3LU1I eiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4Njg2ICBT dGVwcGluZyA9IDYKICBGZWF0dXJlcz0weDM4M2Y5ZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQ QUUsTUNFLENYOCxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LE1NWCxGWFNSLFNTRT4K cmVhbCBtZW1vcnkgID0gMTMzOTU1NTg0ICgxMjcgTUIpCmF2YWlsIG1lbW9yeSA9IDEyMTUwNzg0 MCAoMTE1IE1CKQpwbnBiaW9zOiBCYWQgUG5QIEJJT1MgZGF0YSBjaGVja3N1bQprYmQxIGF0IGti ZG11eDAKYXRoX2hhbDogMC45LjE3LjIgKEFSNTIxMCwgQVI1MjExLCBBUjUyMTIsIFJGNTExMSwg UkY1MTEyLCBSRjI0MTMsIFJGNTQxMykKY3B1MCBvbiBtb3RoZXJib2FyZApwY2liMDogPEludGVs IDgyODE1IChpODE1IEdNQ0gpIEhvc3QgVG8gSHViIGJyaWRnZT4gcGNpYnVzIDAgb24gbW90aGVy Ym9hcmQKcGlyMDogPFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZTogMTIgRW50cmllcz4gb24g bW90aGVyYm9hcmQKcGNpMDogPFBDSSBidXM+IG9uIHBjaWIwCmFncDA6IDxJbnRlbCA4MjgxNSAo aTgxNSBHTUNIKSBob3N0IHRvIFBDSSBicmlkZ2U+IG1lbSAweGY4MDAwMDAwLTB4ZmJmZmZmZmYg YXQgZGV2aWNlIDAuMCBvbiBwY2kwCnBjaWIxOiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAx LjAgb24gcGNpMApwY2kxOiA8UENJIGJ1cz4gb24gcGNpYjEKcGNpMTogPGRpc3BsYXksIFZHQT4g YXQgZGV2aWNlIDAuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liMjogPFBDSUJJT1MgUENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKcGNpMjogPFBDSSBidXM+IG9uIHBjaWIy CnhsMDogPDNDb20gM2M5MDVCLVRYIEZhc3QgRXRoZXJsaW5rIFhMPiBwb3J0IDB4ZGMwMC0weGRj N2YgbWVtIDB4ZmVhZmZjMDAtMHhmZWFmZmM3ZiBpcnEgMyBhdCBkZXZpY2UgMTAuMCBvbiBwY2ky Cm1paWJ1czA6IDxNSUkgYnVzPiBvbiB4bDAKeGxwaHkwOiA8M0NvbSBpbnRlcm5hbCBtZWRpYSBp bnRlcmZhY2U+IG9uIG1paWJ1czAKeGxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJh c2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwp4bDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjEwOjVh OmM3OmZiOmM2CnhsMTogPDNDb20gM2M5MDUtVFggRmFzdCBFdGhlcmxpbmsgWEw+IHBvcnQgMHhk ZjAwLTB4ZGYzZiBpcnEgNyBhdCBkZXZpY2UgMTEuMCBvbiBwY2kyCm1paWJ1czE6IDxNSUkgYnVz PiBvbiB4bDEKbnNwaHkwOiA8RFA4Mzg0MCAxMC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWli dXMxCm5zcGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1G RFgsIGF1dG8KeGwxOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDo2MDowODowZDo4NTpmZAphdGgwOiA8 QXRoZXJvcyA1MjEyPiBtZW0gMHhmZWFiMDAwMC0weGZlYWJmZmZmIGlycSA5IGF0IGRldmljZSAx Mi4wIG9uIHBjaTIKYXRoMDogdW5hYmxlIHRvIGNvbGxlY3QgY2hhbm5lbCBsaXN0IGZyb20gaGFs OyByZWdkb21haW4gbGlrZWx5IDE5IGNvdW50cnkgY29kZSAwCmRldmljZV9hdHRhY2g6IGF0aDAg YXR0YWNoIHJldHVybmVkIDIyCnBjaTI6IDxzaW1wbGUgY29tbXM+IGF0IGRldmljZSAxMy4wIChu byBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4w IG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBJQ0gyIFVE TUExMDAgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3 NiwweGZmYTAtMHhmZmFmIGF0IGRldmljZSAzMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVs IDA+IG9uIGF0YXBjaTAKYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKdWhjaTA6IDxJ bnRlbCA4MjgwMUJBL0JBTSAoSUNIMikgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IHBvcnQgMHhlZjgw LTB4ZWY5ZiBpcnEgMTAgYXQgZGV2aWNlIDMxLjIgb24gcGNpMAp1aGNpMDogW0dJQU5ULUxPQ0tF RF0KdXNiMDogPEludGVsIDgyODAxQkEvQkFNIChJQ0gyKSBVU0IgY29udHJvbGxlciBVU0ItQT4g b24gdWhjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1aHViMDogSW50ZWwgVUhDSSByb290IGh1 YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDIgcG9ydHMgd2l0aCAy IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnBjaTA6IDxzZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2 aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKcG10aW1lcjAgb24gaXNhMAphdGtiZGMwOiA8 S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBvbiBpc2EwCmF0 a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2Jk MDogW0dJQU5ULUxPQ0tFRF0KZmRjMDogPEVuaGFuY2VkIGZsb3BweSBjb250cm9sbGVyPiBhdCBw b3J0IDB4M2YwLTB4M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGlzYTAKZmRjMDogW0ZBU1RdCmZk MDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCnBwYzA6IHBhcmFsbGVsIHBv cnQgbm90IGZvdW5kLgpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNh MApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgzMDA+CnNpbzAgYXQgcG9y dCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGlzYTAKc2lvMDogdHlwZSAxNjU1MEEK c2lvMTogY29uZmlndXJlZCBpcnEgMyBub3QgaW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lv MTogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9y dCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApUaW1lY291bnRlciAi VFNDIiBmcmVxdWVuY3kgODYzODY2MzEyIEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNr IGV2ZXJ5IDEuMDAwIG1zZWMKYWQwOiAzODE2Nk1CIDxXREMgV0Q0MDBCQi03NUFVQTEgMTguMjBE MTg+IGF0IGF0YTAtbWFzdGVyIFVETUExMDAKYWQxOiAxOTYyM01CIDxJQk0gRFRMQS0zMDUwMjAg VFcyT0E2MEE+IGF0IGF0YTAtc2xhdmUgVURNQTEwMAphY2QwOiBEVkRST00gPE5FQyBEVi01NzAw QS8zLjA3PiBhdCBhdGExLW1hc3RlciBVRE1BMzMKYWNkMTogQ0RSVyA8TEcgQ0QtUlcgQ0VELTgw ODBCLzEuMDQ+IGF0IGF0YTEtc2xhdmUgUElPNApUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVm czovZGV2L2FkMHMxYQp4bDE6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAphcnBsb29rdXAgMC4w LjAuMCBmYWlsZWQ6IGhvc3QgaXMgbm90IG9uIGxvY2FsIG5ldHdvcmsKV2FpdGluZyAobWF4IDYw IHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0b3AuLi5kb25lCldhaXRp bmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRhZW1vbicgdG8gc3Rv cC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgc3lu Y2VyJyB0byBzdG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1haW5pbmcuLi4yIDEgMCAw IGRvbmUKQWxsIGJ1ZmZlcnMgc3luY2VkLgpVcHRpbWU6IDFoMW0xNnMKUmVib290aW5nLi4uCkNv cHlyaWdodCAoYykgMTk5Mi0yMDA3IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykg MTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5 NAoJVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0 cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVl QlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgNi4yLVJFTEVBU0UtcDcgIzM6IFdlZCBTZXAgIDUgMTY6 MjI6NTUgRURUIDIwMDcKICAgIHdncmlmZmluQGRlZ3VjaGkuaW50ZXJuYWwuZnJha3R1cmVkLm5l dDovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVl bmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNQVTogSW50ZWwgUGVudGl1bSBJSUkgKDg2My44Ny1N SHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDY4NiAg U3RlcHBpbmcgPSA2CiAgRmVhdHVyZXM9MHgzODNmOWZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1Is UEFFLE1DRSxDWDgsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixNTVgsRlhTUixTU0U+ CnJlYWwgbWVtb3J5ICA9IDEzMzk1NTU4NCAoMTI3IE1CKQphdmFpbCBtZW1vcnkgPSAxMjE1MDc4 NDAgKDExNSBNQikKcG5wYmlvczogQmFkIFBuUCBCSU9TIGRhdGEgY2hlY2tzdW0Ka2JkMSBhdCBr YmRtdXgwCmF0aF9oYWw6IDAuOS4xNy4yIChBUjUyMTAsIEFSNTIxMSwgQVI1MjEyLCBSRjUxMTEs IFJGNTExMiwgUkYyNDEzLCBSRjU0MTMpCmNwdTAgb24gbW90aGVyYm9hcmQKcGNpYjA6IDxJbnRl bCA4MjgxNSAoaTgxNSBHTUNIKSBIb3N0IFRvIEh1YiBicmlkZ2U+IHBjaWJ1cyAwIG9uIG1vdGhl cmJvYXJkCnBpcjA6IDxQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGU6IDEyIEVudHJpZXM+IG9u IG1vdGhlcmJvYXJkCnBjaTA6IDxQQ0kgYnVzPiBvbiBwY2liMAphZ3AwOiA8SW50ZWwgODI4MTUg KGk4MTUgR01DSCkgaG9zdCB0byBQQ0kgYnJpZGdlPiBtZW0gMHhmODAwMDAwMC0weGZiZmZmZmZm IGF0IGRldmljZSAwLjAgb24gcGNpMApwY2liMTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug MS4wIG9uIHBjaTAKcGNpMTogPFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IDxkaXNwbGF5LCBWR0E+ IGF0IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjI6IDxQQ0lCSU9TIFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBjaTI6IDxQQ0kgYnVzPiBvbiBwY2li Mgp4bDA6IDwzQ29tIDNjOTA1Qi1UWCBGYXN0IEV0aGVybGluayBYTD4gcG9ydCAweGRjMDAtMHhk YzdmIG1lbSAweGZlYWZmYzAwLTB4ZmVhZmZjN2YgaXJxIDMgYXQgZGV2aWNlIDEwLjAgb24gcGNp MgptaWlidXMwOiA8TUlJIGJ1cz4gb24geGwwCnhscGh5MDogPDNDb20gaW50ZXJuYWwgbWVkaWEg aW50ZXJmYWNlPiBvbiBtaWlidXMwCnhscGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBi YXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8KeGwwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxMDo1 YTpjNzpmYjpjNgp4bDE6IDwzQ29tIDNjOTA1LVRYIEZhc3QgRXRoZXJsaW5rIFhMPiBwb3J0IDB4 ZGYwMC0weGRmM2YgaXJxIDcgYXQgZGV2aWNlIDExLjAgb24gcGNpMgptaWlidXMxOiA8TUlJIGJ1 cz4gb24geGwxCm5zcGh5MDogPERQODM4NDAgMTAvMTAwIG1lZGlhIGludGVyZmFjZT4gb24gbWlp YnVzMQpuc3BoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgt RkRYLCBhdXRvCnhsMTogRXRoZXJuZXQgYWRkcmVzczogMDA6NjA6MDg6MGQ6ODU6ZmQKYXRoMDog PEF0aGVyb3MgNTIxMj4gbWVtIDB4ZmVhYjAwMDAtMHhmZWFiZmZmZiBpcnEgOSBhdCBkZXZpY2Ug MTIuMCBvbiBwY2kyCmF0aDA6IHVuYWJsZSB0byBjb2xsZWN0IGNoYW5uZWwgbGlzdCBmcm9tIGhh bDsgcmVnZG9tYWluIGxpa2VseSAxOSBjb3VudHJ5IGNvZGUgMAphdGgwOiBFdGhlcm5ldCBhZGRy ZXNzOiAwMDoxYjoxMTpiYjpkYTowOQphdGgwOiBtYWMgMTAuNSBwaHkgNi4xIHJhZGlvIDYuMwpw Y2kyOiA8c2ltcGxlIGNvbW1zPiBhdCBkZXZpY2UgMTMuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpp c2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0Eg YnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgSUNIMiBVRE1BMTAwIGNvbnRyb2xsZXI+IHBv cnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmZmEwLTB4ZmZhZiBhdCBk ZXZpY2UgMzEuMSBvbiBwY2kwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTE6 IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCnVoY2kwOiA8SW50ZWwgODI4MDFCQS9CQU0gKElD SDIpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4ZWY4MC0weGVmOWYgaXJxIDEwIGF0IGRl dmljZSAzMS4yIG9uIHBjaTAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4Mjgw MUJBL0JBTSAoSUNIMikgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVoY2kwCnVzYjA6IFVTQiBy ZXZpc2lvbiAxLjAKdWh1YjA6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEu MDAvMS4wMCwgYWRkciAxCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIg YXR0YWNoZWQpCnBtdGltZXIwIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIg KGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBLZXlib2FyZD4g aXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmZk YzA6IDxFbmhhbmNlZCBmbG9wcHkgY29udHJvbGxlcj4gYXQgcG9ydCAweDNmMC0weDNmNSwweDNm NyBpcnEgNiBkcnEgMiBvbiBpc2EwCmZkYzA6IFtGQVNUXQpmZDA6IDwxNDQwLUtCIDMuNSIgZHJp dmU+IG9uIGZkYzAgZHJpdmUgMApwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3VuZC4Kc2MwOiA8 U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1 YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzaW8wIGF0IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQg ZmxhZ3MgMHgxMCBvbiBpc2EwCnNpbzA6IHR5cGUgMTY1NTBBCnNpbzE6IGNvbmZpZ3VyZWQgaXJx IDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBl bmFibGVkCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0g MHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDg2Mzg2 NzU5NCBIeiBxdWFsaXR5IDgwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmFk MDogMzgxNjZNQiA8V0RDIFdENDAwQkItNzVBVUExIDE4LjIwRDE4PiBhdCBhdGEwLW1hc3RlciBV RE1BMTAwCmFkMTogMTk2MjNNQiA8SUJNIERUTEEtMzA1MDIwIFRXMk9BNjBBPiBhdCBhdGEwLXNs YXZlIFVETUExMDAKYWNkMDogRFZEUk9NIDxORUMgRFYtNTcwMEEvMy4wNz4gYXQgYXRhMS1tYXN0 ZXIgVURNQTMzCmFjZDE6IENEUlcgPExHIENELVJXIENFRC04MDgwQi8xLjA0PiBhdCBhdGExLXNs YXZlIFBJTzQKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzMWEKYXRoMDog aW52YWxpZCBjaGFubmVsIChOVUxMKQphdGgwOiBpbnZhbGlkIGNoYW5uZWwgKE5VTEwpCg== ------=_Part_52841_3683181.1189132697976-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 03:59:30 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA96516A41A for ; Fri, 7 Sep 2007 03:59:30 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate4.pacific.net.sg (smtpgate4.pacific.net.sg [203.81.36.24]) by mx1.freebsd.org (Postfix) with SMTP id 2A7E113C442 for ; Fri, 7 Sep 2007 03:59:29 +0000 (UTC) (envelope-from oceanare@pacific.net.sg) Received: (qmail 30206 invoked from network); 7 Sep 2007 03:32:48 -0000 Received: from bb121-7-106-120.singnet.com.sg (HELO P2120.somewherefaraway.com) (oceanare@121.7.106.120) by smtpgate4.pacific.net.sg with ESMTPA; 7 Sep 2007 03:32:48 -0000 Message-ID: <46E0C65C.80200@pacific.net.sg> Date: Fri, 07 Sep 2007 11:32:44 +0800 From: Erich Dollansky User-Agent: Thunderbird 2.0.0.6 (X11/20070826) MIME-Version: 1.0 To: Wesley Griffin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Country Code woes with D-Link DWL-AG530 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 03:59:31 -0000 Hi, Wesley Griffin wrote: > > but I get the following output: > ----- > Current value 0x0013 will change to 0x0010 > Retrying eeprom write! > Retrying eeprom write! > [snip lots of this message] > EEPROM write failed this sounds like a simple hardware error. Or does your device have a write protection? In any case, whatever you tried to write to the device did not work. Erich From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 08:45:36 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 123B616A41A; Fri, 7 Sep 2007 08:45:36 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C3F9513C459; Fri, 7 Sep 2007 08:45:35 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l878jZUu037361; Fri, 7 Sep 2007 08:45:35 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l878jZaU037357; Fri, 7 Sep 2007 08:45:35 GMT (envelope-from remko) Date: Fri, 7 Sep 2007 08:45:35 GMT Message-Id: <200709070845.l878jZaU037357@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/116172: Network / ipv6 recursive mutex panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 08:45:36 -0000 Synopsis: Network / ipv6 recursive mutex panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Sep 7 08:45:35 UTC 2007 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=116172 From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 10:23:07 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F0516A41A for ; Fri, 7 Sep 2007 10:23:07 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 304C513C4CC for ; Fri, 7 Sep 2007 10:23:06 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 18:22:56 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 18:22:56 +0800 Received: from [172.23.17.9] ([172.23.17.9]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 18:22:55 +0800 Message-ID: <46E1268E.5030500@zyxel.com.tw> Date: Fri, 07 Sep 2007 18:23:10 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Sep 2007 10:22:55.0600 (UTC) FILETIME=[0E23B700:01C7F139] Subject: ICMP error notification with IPsec in ip6_forward() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 10:23:07 -0000 Dear all: Recently I am tracing the codes of ip6_forward(), which is defined in ip6_forward.c. My referenced version is FreeBSD Release 6.1. I have the following questions about IPsec operations: (1) lines 489-512 are about the transmission of ICMP Packet Too Big message. Is it necessary here since tunneled packets are already sent out at this point? (2) The location of the packet size examination is not proper. If the packet matches SP, then it will be tunneled without sending out ICMP packet too big error message to the source. (3) Is there any RFC about ICMP notification and IPsec? I am not sure what kind of ICMP error messages should be sent out from the security gateway. For example, is ICMP destination unreachable necessary if the inner destination is unreachable? Or ICMP Redirect packet necessary if the inner destination needs to be redirected? Thanks. Best regards, Yi-Wen From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 10:47:29 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7028516A418 for ; Fri, 7 Sep 2007 10:47:29 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aob12.obsmtp.com (s200aob12.obsmtp.com [207.126.144.116]) by mx1.freebsd.org (Postfix) with SMTP id D952713C4DB for ; Fri, 7 Sep 2007 10:47:28 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([213.206.147.173]) by eu1sys200aob012.postini.com ([207.126.147.11]) with SMTP; Fri, 07 Sep 2007 10:44:08 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 8522C181452 for ; Fri, 7 Sep 2007 10:08:38 +0100 (BST) Message-ID: <46E11515.8090007@tomjudge.com> Date: Fri, 07 Sep 2007 10:08:37 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Strange behaviour of route command X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 10:47:29 -0000 Hi, While making some changes to the routing table on one of our routers today I noticed that "route add" was showing some strange behaviour. When adding a route for 128/8 to the table rather than adding 128.0.0.0/8 it would add 0.0.0.0/8, however adding 10/9 works correctly. Is this a bug in route or the routing table? Tom [root@fw1 /tftpboot]# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 4838 bge0 10.0.0.0/8 link#1 UC 0 0 bge0 10.0.0.46 00:11:43:37:2e:2e UHLW 1 0 bge0 1196 10.0.0.89 00:16:17:e1:ea:bc UHLW 1 18 bge0 631 10.0.6.0/23 link#3 UC 0 0 bge2 127.0.0.1 127.0.0.1 UH 0 231 lo0 [root@fw1 /tftpboot]# route add 128/8 10.0.0.1 add net 128: gateway 10.0.0.1 [root@fw1 /tftpboot]# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 0.0.0.0/8 10.0.0.1 UGS 0 0 bge0 => default 10.0.0.1 UGS 0 4838 bge0 10.0.0.0/8 link#1 UC 0 0 bge0 10.0.0.1 link#1 UHLW 2 0 bge0 10.0.0.46 00:11:43:37:2e:2e UHLW 1 0 bge0 1193 10.0.0.89 00:16:17:e1:ea:bc UHLW 1 84 bge0 612 10.0.6.0/23 link#3 UC 0 0 bge2 127.0.0.1 127.0.0.1 UH 0 231 lo0 [root@fw1 /tftpboot]# route add 128.0/8 10.0.0.1 add net 128.0: gateway 10.0.0.1 [root@fw1 /tftpboot]# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 0.0.0.0/8 10.0.0.1 UGS 0 0 bge0 => default 10.0.0.1 UGS 0 4838 bge0 10.0.0.0/8 link#1 UC 0 0 bge0 10.0.0.1 link#1 UHLW 3 0 bge0 10.0.0.46 00:11:43:37:2e:2e UHLW 1 0 bge0 1180 10.0.0.89 00:16:17:e1:ea:bc UHLW 1 131 bge0 1200 10.0.6.0/23 link#3 UC 0 0 bge2 127.0.0.1 127.0.0.1 UH 0 231 lo0 128.0.0.0/8 10.0.0.1 UGS 0 0 bge0 root@fw1 /tftpboot]# route add 10/9 10.0.0.50 add net 128.0: gateway 10.0.0.1 [root@fw1 /tftpboot]# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 0.0.0.0/8 10.0.0.1 UGS 0 0 bge0 => default 10.0.0.1 UGS 0 4838 bge0 10.0.0.0/9 10.0.0.50 UGS 0 0 bge0 10.0.0.0/8 link#1 UC 0 0 bge0 10.0.0.1 link#1 UHLW 3 0 bge0 10.0.0.46 00:11:43:37:2e:2e UHLW 1 0 bge0 1180 10.0.0.89 00:16:17:e1:ea:bc UHLW 1 131 bge0 1200 10.0.6.0/23 link#3 UC 0 0 bge2 127.0.0.1 127.0.0.1 UH 0 231 lo0 128.0.0.0/8 10.0.0.1 UGS 0 0 bge0 From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 12:31:19 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B77F416A417 for ; Fri, 7 Sep 2007 12:31:19 +0000 (UTC) (envelope-from wgriffin@fraktured.net) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 5F57313C46B for ; Fri, 7 Sep 2007 12:31:17 +0000 (UTC) (envelope-from wgriffin@fraktured.net) Received: by nf-out-0910.google.com with SMTP id k4so371786nfd for ; Fri, 07 Sep 2007 05:31:16 -0700 (PDT) Received: by 10.78.201.15 with SMTP id y15mr751122huf.1189168275467; Fri, 07 Sep 2007 05:31:15 -0700 (PDT) Received: by 10.78.11.13 with HTTP; Fri, 7 Sep 2007 05:31:15 -0700 (PDT) Message-ID: Date: Fri, 7 Sep 2007 08:31:15 -0400 From: "Wesley Griffin" To: "Erich Dollansky" In-Reply-To: <46E0C65C.80200@pacific.net.sg> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46E0C65C.80200@pacific.net.sg> Cc: freebsd-net@freebsd.org Subject: Re: Country Code woes with D-Link DWL-AG530 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 12:31:19 -0000 On 9/6/07, Erich Dollansky wrote: > Hi, > > Wesley Griffin wrote: > > > > but I get the following output: > > ----- > > Current value 0x0013 will change to 0x0010 > > Retrying eeprom write! > > Retrying eeprom write! > > [snip lots of this message] > > EEPROM write failed > > this sounds like a simple hardware error. Hrm. So is it possible the card is bad? I guess I can take it to work and try it out in some Windows computers. > Or does your device have a write protection? Is there any way to determine this? Perhaps a jumper on the card? Thanks, Wes From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 15:45:09 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA90716A421 for ; Fri, 7 Sep 2007 15:45:09 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id 9547613C468 for ; Fri, 7 Sep 2007 15:45:09 +0000 (UTC) (envelope-from louie@transsys.com) Received: from LMamakos-MacBook-Pro.local (71-80-54-023.dhcp.mant.nc.charter.com [71.80.54.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 2594F5C04; Fri, 7 Sep 2007 11:18:27 -0400 (EDT) Message-ID: <46E16BB9.80908@transsys.com> Date: Fri, 07 Sep 2007 11:18:17 -0400 From: Louis Mamakos User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kirc Gover References: <695994.81567.qm@web44811.mail.sp1.yahoo.com> In-Reply-To: <695994.81567.qm@web44811.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 15:45:09 -0000 Kirc Gover wrote: > We are in the stage of planning and research for a commercial development of an edge router that will be based mostly on OpenSource software. I would like to solicit for information and recommendation if FreeBSD is a suitable OS. The router is expected to withstand forwarding of sustained traffic from 10Mbps to 1Gbps and maybe more than that. Are there any known limitations of FreeBSD in terms of architecture and performance? Can I just take out a FreeBSD as is and put it with the hardware without any specific or major refinements in its code? I'm very much concerned with its capability in forwarding heavy sustained traffic. Packet loss should be at minimum and critical userland processes should working normally even under heavy load. Are there any known specific limitations of FreeBSD? I have browsed through the archives and found a lot of hangups, deadlocks and freeze issues. What is the usual or minimum hardware requirement? Is soekris box enough, or dual core or ASIC > based platforms? I'm aware that there are so many FreeBSD based routers and network based devices in the market. Is this a way to go over realtime and embedded OS such as VxWorks and others (mostly commercial) without putting the licensing cost in picture? I really appreciate any help, suggestions and recommendations. More power to FreeBSD! > > Thanks > Kirc > > --------------------------------- > Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. Get it now. > _______________________________________________ > 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" > What's an "edge" router? Is this a customer device, or a servicer provider's "edge" router that's used to termination a bunch of individual customer connections? I'm sure you can probably use FreeBSD for some moderate performance customer equipment, assuming you scrape together or write your own bits to flesh out the feature set. For a service provider edge router, you ought to align your thinking a bit differently and consider the control plane distinctly from the data/forwarding plane in the box. Running all of the forwarding operations through the CPU won't get you very far (though this is a relative measure, I supposed). In a previous life, I worked for a high-end router start-up that used NetBSD as the basis of the control plane of the router (though with a interesting, non-traditional twist on the software architecture). It ran the routing protocols, management, and system control functions over a set of NetBSD instances. The router had a distributed, scalable switch fabric with multi-Gb/s ports that line interfaces plugged into. To run line-rate forwarding with small packet sizes for multiple gigabit ethernet, or OC48/OC192 ports usually requires specialized forwarding engines and the host OS is essentially uninvolved (on a per packet basis) other than setting up the hardware and managing it. The choice of NetBSD was just because of an existing port to a CPU architecture. Please don't take this the wrong way, but you probably need some professional help in making these sorts of design decisions that extends beyond what you're likely to get from public mailing lists. The router business is very competitive both for CPE service provider products, and having a good understanding the external requirements is a significant effort, never mind the specific implementation. What IGPs do you need to support, how many routes in the RIB and the FIB? What BGP features do you need? Will you need to support multiple classes of traffic, do you have hard limits on delay and delay jitter through the router? Do you intend to support MPLS, that opens a whole other can of worms, choices and complexity. Louis Mamakos From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 15:57:17 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2173D16A417 for ; Fri, 7 Sep 2007 15:57:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0641B13C467 for ; Fri, 7 Sep 2007 15:57:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 5AB3A2C37B; Fri, 7 Sep 2007 11:57:16 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 07 Sep 2007 11:57:16 -0400 X-Sasl-enc: hNL98o1Yt0xuFuxFV1su/9ZTYrkzn0H09diJBub6YMgh 1189180636 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id D75453D51; Fri, 7 Sep 2007 11:57:15 -0400 (EDT) Message-ID: <46E174DB.8070004@FreeBSD.org> Date: Fri, 07 Sep 2007 16:57:15 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Tom Judge References: <46E11515.8090007@tomjudge.com> In-Reply-To: <46E11515.8090007@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: Strange behaviour of route command X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 15:57:17 -0000 Tom Judge wrote: > Hi, > > While making some changes to the routing table on one of our routers > today I noticed that "route add" was showing some strange behaviour. > When adding a route for 128/8 to the table rather than adding > 128.0.0.0/8 it would add 0.0.0.0/8, however adding 10/9 works correctly. > > Is this a bug in route or the routing table? Run 'route -nv monitor' in another shell while you do this and post the output to this list so someone can get more of a handle on it. BMS From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 17:15:54 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E72A16A417 for ; Fri, 7 Sep 2007 17:15:54 +0000 (UTC) (envelope-from chengjin@FASTSOFT.COM) Received: from HQ-ES.FASTSOFT.COM (static-71-160-206-130.lsanca.dsl-w.verizon.net [71.160.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id 2762213C468 for ; Fri, 7 Sep 2007 17:15:54 +0000 (UTC) (envelope-from chengjin@FASTSOFT.COM) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Sep 2007 10:03:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel 82572GI PCIe question Thread-Index: AcfxcP1H49wthY8/SxOTzTMyB0eweQ== From: "Cheng Jin" To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Intel 82572GI PCIe 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: Fri, 07 Sep 2007 17:15:54 -0000 Hi, =20 Has anyone had experience playing with the 82572GI PCIe cards under = FreeBSD? =20 We had bunch of cards from two vendors, a few server adapter cards, but = most of them client adapter cards = (http://www.intel.com/network/connectivity/products/prodbrf/pro1000_pt_de= sktop_adapter.pdf) =20 They all had problems (hard to pin down the exact problem, but i suspect = auto-negotiation) under FreeBSD 5.4. We are using the em-5.1.5 driver = from Intel's website that is meant for FreeBSD 5.x, and the cards are all recognized = on boot, and if I assign an IP, it appears to work (at least i could = ping the machine's own IP). However, when they are connected to the rest of the network via 100Mbps switches, = they are not able to ping any host on the network. =20 =20 Sometimes, i could get the cards to work by plugging them into a = different 100Mbps port and then back to the original port, and I also = found that if i have a gigabit port handy, i could connect the adapter = to the GigE, and then connecting to the 100Mbps would work. =20 The strange and not so funny thing is that a few cards have no problems, = but most of have this problem. I cannot quite tell whether i have a = bunch of defective cards (I guess I should test it under Windows), or = maybe the 5.x driver doesnt support these PCIe cards very well. =20 One thing I did that might shed some light is that I backed ported some = stuff from 6.2 em driver, and that really eliminated the trouble that I = was having. If anyone is interested, I'd be happy to post the code I = backported. =20 Thanks, =20 Cheng =20 =20 =20 From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 17:22:20 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62C4716A46B for ; Fri, 7 Sep 2007 17:22:20 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 33ACB13C4CA for ; Fri, 7 Sep 2007 17:22:19 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (ekuv6qvll16jfqu5@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l87HMHUQ042646; Fri, 7 Sep 2007 10:22:17 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l87HMH1f042645; Fri, 7 Sep 2007 10:22:17 -0700 (PDT) (envelope-from jmg) Date: Fri, 7 Sep 2007 10:22:16 -0700 From: John-Mark Gurney To: Julian Elischer Message-ID: <20070907172216.GL977@funkthat.com> Mail-Followup-To: Julian Elischer , David Christensen , FreeBSD Net References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> <46E0A5DB.3080404@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E0A5DB.3080404@elischer.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: FreeBSD Net , David Christensen Subject: Re: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 17:22:20 -0000 Julian Elischer wrote this message on Thu, Sep 06, 2007 at 18:14 -0700: > David Christensen wrote: > >>Julian Elischer wrote: > >>>Ok which clever person did this again? > >>> > >>>It just broke our product. > >>>If it hasn't been removed from 7.0 and 6.x yet it's just > >>about to be... > >> > >> > >>on the topic above, I've found that the bce driver seems to > >>be throwingaway packets > >>larger than the mtu regardless of the rest of the system.. > > > >This has been part of the driver since it's initial release, > >it's not an addition or change. > > > >>the following code seems to be responsible.. > >> > >>in the spirit of "be generous on receive" as mentionned before, > >> should it be relaxed? > >> > > > >When this RX MTU size issue was being discussed previously I > >was wondering why nobody actually discussed what the drivers > >are doing. Both the NetXtreme (bge) and NetXtreme II (bce) > >controllers have a setting in the RX MAC to specify the MTU > >size of the medium. Anything larger than the MTU is discarded > >and a statistic is recorded. Support for jumbo frames is > >available (though not on all bge supported controllers) but the > >general understanding from the hardware design perspective is > >that the MTU is the maximum message size on the medium and that > >all controllers on the medium should be configured for the same > >message size. I've never seen an Ethernet driver that supports > >different MTUs for RX and TX (is there one implemented under > >FreeBSD?) and I would really hate to troubleshoot any higher > >level application problems that might occur if the RX and TX MTU > >were different for every system on a network. > > > >> > >> /* Calculate and program the Ethernet MTU size. */ > >> ether_mtu = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN + > >>ifp->if_mtu + > >> ETHER_CRC_LEN; > >> > >> DBPRINT(sc, BCE_INFO, "%s(): setting mtu = > >>%d\n",__FUNCTION__, ether_mtu); > >> > >> > >> /* > >> * Program the mtu, enabling jumbo frame > >> * support if necessary. Also set the mbuf > >> * allocation count for RX frames. > >> */ > >> if (ether_mtu > ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) { > >> REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu | > >> BCE_EMAC_RX_MTU_SIZE_JUMBO_ENA); > >> sc->mbuf_alloc_size = MJUM9BYTES; > >> } else { > >> REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu); > >> sc->mbuf_alloc_size = MCLBYTES; > >> } > >> > >> > >>could probably be relaxed in the non jumbo case to accept > >>packets up to > >>MCLBYTES in size instead of ether_mtu. > > > >Maybe MCLBYTES is good enough for you but what if someone has > >a different requirement? How big is big enough for everyone? > > > >I suppose supporting different MTUs for RX and TX is possible, > >though the memory requirements are 5x larger for jumbo frames > >over standard frames and many users might consider this a waste > >of resources if they don't support jumbo frames on their > >network (that would be almost 4MB). Support would obviously > >be easier if "ifconfig" support both an RX and TX MTU size. > > > >>manually I have set the mtu to larger values which increases > >>ether_mtu and that seems to work.. > >>now, Why do we need this? > >> > >>WCCP is a protocol from Cisco. > >>it encapsulates packets in GRE, including an extra > >>intermediate header. > >>when packets are encapsulated in GRE by cisco 6k switches > >>(quite a few around) > >>they do NOT frag the result, but instead, send an oversized packet. > >> > >>if you have a bce interface, it discards these packets which > >>is a drag. > > > >It could certainly be argued by some that Cisco is not standards > >compliant in this case for sending an oversized Ethernet frame > >and expecting everyone to accept it. Hardware has limitations > >and assuming that all Ethernet controllers can support frames > >greater than 1522 bytes is not reasonable. Fortunately there is > >a suitable workaround which is setting a larger MTU for the > >interface. What size do you use? How did you arrive at that > >value? > > I use 1550 to make it work in the test harness. > > The trouble is that if I set the mtu to 1550, and the machine talks to > another > such machine with it's mtu also set to 1550 then they negotiate a maximum > sized > packet based on 1550, and the problem hits me again. This is a web proxy > and that problem occurs when there are two layers of proxy and one proxy > talks to another. I really just need it to to silently accept a packet some > 32 bytes or so larger than the stated MTU. Why not set the mtu on the net and host routes to 1500 to make it all work? I forget if my route mtu code is in 6.2, but it'll be in 7.0... Maybe someone will write the mtud and we can be the first OS to turn on jumbo frames by default.. :) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 17:51:43 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A51A16A417 for ; Fri, 7 Sep 2007 17:51:43 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id 67A4313C48D for ; Fri, 7 Sep 2007 17:51:43 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 07 Sep 2007 10:51:33 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 4BDDE2AF; Fri, 7 Sep 2007 10:51:33 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 3798C2AE; Fri, 7 Sep 2007 10:51:33 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FQR79249; Fri, 7 Sep 2007 10:51:28 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 06CA569CA3; Fri, 7 Sep 2007 10:51:28 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Sep 2007 10:51:27 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD903051CBEB6@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <46E0A5DB.3080404@elischer.org> Thread-Topic: FreeBSD discarding received packets > MTU Thread-Index: Acfw7GuVhd0rU0HcQxu+nYf4UFN0iwAin/yw References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> <46E0A5DB.3080404@elischer.org> From: "David Christensen" To: "Julian Elischer" X-WSS-ID: 6AFF502F2M81501789-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net Subject: RE: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 17:51:43 -0000 > > It could certainly be argued by some that Cisco is not standards > > compliant in this case for sending an oversized Ethernet frame > > and expecting everyone to accept it. Hardware has limitations > > and assuming that all Ethernet controllers can support frames > > greater than 1522 bytes is not reasonable. Fortunately there is > > a suitable workaround which is setting a larger MTU for the=20 > > interface. What size do you use? How did you arrive at that > > value? >=20 > I use 1550 to make it work in the test harness. >=20 > The trouble is that if I set the mtu to 1550, and the machine=20 > talks to another > such machine with it's mtu also set to 1550 then they=20 > negotiate a maximum sized > packet based on 1550, and the problem hits me again. This is=20 > a web proxy=20 > and that problem occurs when there are two layers of proxy=20 > and one proxy talks to=20 > another. I really just need it to to silently accept a packet some=20 > 32 bytes or so larger than the stated MTU. >=20 > I see no reason for the driver to not do what the em driver=20 > does and allow=20 > itself to receive any packet up to the MCLBYTES size. >=20 > We only hit this problem recently because the data interfaces on our > devices are usually em NICs and we only just recently started=20 > allowing the=20 > users to use the built in (on DELL 2950) bce interfaces for=20 > this purpose. >=20 I'm not completely opposed to making such a change, but I don't want to make a default change in the driver's behavior that other people=20 may be depending upon (whether they are aware of it or not). A tunable driver value could be the answer but I'm not entirely sure how it would fare in the hardware at the high end of MTU values such=20 as 9000. Dave From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 18:08:50 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5B1416A41B for ; Fri, 7 Sep 2007 18:08:50 +0000 (UTC) (envelope-from kirc.gover@yahoo.com.au) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by mx1.freebsd.org (Postfix) with SMTP id 5D27213C45D for ; Fri, 7 Sep 2007 18:08:50 +0000 (UTC) (envelope-from kirc.gover@yahoo.com.au) Received: from [68.142.237.87] by n7.bullet.re3.yahoo.com with NNFMP; 07 Sep 2007 17:55:40 -0000 Received: from [66.196.101.130] by t3.bullet.re3.yahoo.com with NNFMP; 07 Sep 2007 17:55:39 -0000 Received: from [127.0.0.1] by rrr1.mail.re1.yahoo.com with NNFMP; 07 Sep 2007 17:55:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 881669.40727.bm@rrr1.mail.re1.yahoo.com Received: (qmail 38422 invoked by uid 60001); 7 Sep 2007 17:33:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Y9X7leefVBuSMGGZdHl4IHHVUBWLpaVyxAFzfjz/53vx9Cv4e6dk8bYvvy1d42m3D+mHIU13n7fJtEYpApJwrZcWOWVOVGTnJa/Gj0zTGoYyBp+jyEkJ9c7Hl8ije9YWC43ZKahWlqKIobzMkIAYydJt28mClrhUKxnGdlTe7c0=; X-YMail-OSG: o2a8eWYVM1l3C0XQXeGgp.NhzuX5Oj6rPINdVkNd Received: from [125.60.235.213] by web44804.mail.sp1.yahoo.com via HTTP; Sat, 08 Sep 2007 03:33:19 EST Date: Sat, 8 Sep 2007 03:33:19 +1000 (EST) From: Kirc Gover To: Louis Mamakos In-Reply-To: <46E16BB9.80908@transsys.com> MIME-Version: 1.0 Message-ID: <379420.38247.qm@web44804.mail.sp1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 18:08:50 -0000 Hi Louis, Thanks for your response. I appreciate it a lot. The router would be deployed at the service provider network that will terminate roughly 4000 (maximum) individual customers and corporate networks/VPNs. We have decided to integrate control plane, data plane and management plane functionality into the router in consideration of the hardware cost. Basically, the router will have a single CPU that will handle all the processing, including the operating system, system processes, routing protocol processes and the forwarding engine (built-in FreeBSD IP stack). The idea is to take a regular FreeBSD box (PC with 2 NICs) configured as a router into a different level that can handle the expected traffic. I have substantial experience in configuring a FreeBSD router but in a very limited environment, like a company, department or small-office router configuration. I also run and encountered several issues of FreeBSD (could be inherent to its architecture and implementation) like deadlocks, hangups, panics, high cpu utilization when subjected to a very high traffic. The motivation of developing our own router is that we will be integrating propriety and value added services into the router to support some business goals. Considering these, am I on the right path? The initial list of the routing protocols that will be supported include RIP, OSPF, BGP and IGMP (PIM-DM, etc). The routing table size should be enough to support the expected number of costumers, at the top of my head roughly a thousand. MPLS will not be needed. I expect in the feature IPv6 will be included (also for label switching in place of MPLS). There is a need to support classes of traffic. That would be through packet marking and QoS which is already supported by FreeBSD. Would these be too much for a single high performance (multi-core core) CPU? Thanks a lot. Kirc Louis Mamakos wrote: Kirc Gover wrote: > We are in the stage of planning and research for a commercial development of an edge router that will be based mostly on OpenSource software. I would like to solicit for information and recommendation if FreeBSD is a suitable OS. What's an "edge" router? Is this a customer device, or a servicer provider's "edge" router that's used to termination a bunch of individual customer connections? I'm sure you can probably use FreeBSD for some moderate performance customer equipment, assuming you scrape together or write your own bits to flesh out the feature set. For a service provider edge router, you ought to align your thinking a bit differently and consider the control plane distinctly from the data/forwarding plane in the box. Running all of the forwarding operations through the CPU won't get you very far (though this is a relative measure, I supposed). In a previous life, I worked for a high-end router start-up that used NetBSD as the basis of the control plane of the router (though with a interesting, non-traditional twist on the software architecture). It ran the routing protocols, management, and system control functions over a set of NetBSD instances. The router had a distributed, scalable switch fabric with multi-Gb/s ports that line interfaces plugged into. To run line-rate forwarding with small packet sizes for multiple gigabit ethernet, or OC48/OC192 ports usually requires specialized forwarding engines and the host OS is essentially uninvolved (on a per packet basis) other than setting up the hardware and managing it. The choice of NetBSD was just because of an existing port to a CPU architecture. Please don't take this the wrong way, but you probably need some professional help in making these sorts of design decisions that extends beyond what you're likely to get from public mailing lists. The router business is very competitive both for CPE service provider products, and having a good understanding the external requirements is a significant effort, never mind the specific implementation. What IGPs do you need to support, how many routes in the RIB and the FIB? What BGP features do you need? Will you need to support multiple classes of traffic, do you have hard limits on delay and delay jitter through the router? Do you intend to support MPLS, that opens a whole other can of worms, choices and complexity. Louis Mamakos --------------------------------- Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. Get it now. From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 18:34:00 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26BA716A41A for ; Fri, 7 Sep 2007 18:34:00 +0000 (UTC) (envelope-from kirc.gover@yahoo.com.au) Received: from n6a.bullet.mail.re3.yahoo.com (n6a.bullet.mail.re3.yahoo.com [68.142.236.44]) by mx1.freebsd.org (Postfix) with SMTP id C16E213C480 for ; Fri, 7 Sep 2007 18:33:59 +0000 (UTC) (envelope-from kirc.gover@yahoo.com.au) Received: from [68.142.230.29] by n6.bullet.re3.yahoo.com with NNFMP; 07 Sep 2007 18:33:59 -0000 Received: from [66.196.101.132] by t2.bullet.re2.yahoo.com with NNFMP; 07 Sep 2007 18:33:59 -0000 Received: from [127.0.0.1] by rrr3.mail.re1.yahoo.com with NNFMP; 07 Sep 2007 18:33:59 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 203595.18333.bm@rrr3.mail.re1.yahoo.com Received: (qmail 21959 invoked by uid 60001); 7 Sep 2007 17:57:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Q98yxxRM+sZdzudcTCzh4evJNUO7St63u31bPlGpQNnKlgivmyV9SyNST8UXOO8VVeRk8bkdLyBXYV8qPpZiueRxcSevXEQDROoA5t/AQXXsFGnCTueqW+zwPmyW+HCT6Xw+CKknzlPVVYBHE0STLdpG5LO/WmYk3Awg+j5za9A=; X-YMail-OSG: Kui_4joVM1nYj3nOT11JIIofozcfO_dHXgrgZ8Af Received: from [125.60.235.213] by web44802.mail.sp1.yahoo.com via HTTP; Sat, 08 Sep 2007 03:57:11 EST Date: Sat, 8 Sep 2007 03:57:11 +1000 (EST) From: Kirc Gover To: Gary Palmer In-Reply-To: <20070906220345.GB8194@in-addr.com> MIME-Version: 1.0 Message-ID: <517436.12027.qm@web44802.mail.sp1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 18:34:00 -0000 Hi Gary, Thanks for your response. Yes, the bus architecture would be either PCI-X or PCI-Express. Host CPU would be a high performance multi-core such as Xeon and NICs would be Intel. One of my concern is on the native forwarding capability of FreeBSD OS and the execution of critical userland processes. I have experience before that a FreeBSD box configured as router appears to slow down the userland processes when the traffic load is high. I have verified this lately on 6.1, running on Athlon64 with 1G NIC cards with PF and ALTQ (queuing) enabled. I'm not so sure if this is caused by PF or ALTQ. Looking at the processes using top, it could see that "swi(x) net" process is almost as near 100% cpu utilization. At this state, the box can still forward traffic (not sure yet if the was a change in throughput) but I could notice the userland processes to be very slow, like invoking any command from the shell (e.g. ls) will take so long to be executed and completed. Is this a know limitation or bug? Thanks a lot. Kirc Gary Palmer wrote: On Fri, Sep 07, 2007 at 03:06:54AM +1000, Kirc Gover wrote: > We are in the stage of planning and research for a commercial development of an edge router that will be based mostly on OpenSource software. I would like to solicit for information and recommendation if FreeBSD is a suitable OS. The router is expected to withstand forwarding of sustained traffic from 10Mbps to 1Gbps and maybe more than that. Are there any known limitations of FreeBSD in terms of architecture and performance? Can I just take out a FreeBSD as is and put it with the hardware without any specific or major refinements in its code? I'm very much concerned with its capability in forwarding heavy sustained traffic. Packet loss should be at minimum and critical userland processes should working normally even under heavy load. Are there any known specific limitations of FreeBSD? I have browsed through the archives and found a lot of hangups, deadlocks and freeze issues. What is the usual or minimum hardware requirement? Is soekris box enough, or dual core or ASIC > based platforms? I'm aware that there are so many FreeBSD based routers and network based devices in the market. Is this a way to go over realtime and embedded OS such as VxWorks and others (mostly commercial) without putting the licensing cost in picture? I really appreciate any help, suggestions and recommendations. More power to FreeBSD! Kirc, There are two factors to consider: - bus architecture (PCI, PCI-X, PCI-Express, etc) will dictate the maximum throughput in bits/sec. Allow some overhead for bus arbitration activities, and remember that the packet crosses the bus twice, once on the inbound leg and once on the outbound leg. - Host CPU (and perhaps to a limited extent the interface cards used) will dictate the packets per second (PPS) Most commercial routers run out of packets per second (in real-world situations, not lab mockups) long before the theoretical maximum throughput is achieved. Thinks like ICMP ping packets and TCP RST packets are small (less than 100 bytes usually) but normally take as much CPU to process & route as a 1500 byte (or larger) packet. The more you put in the processing path (e.g. packet filters, complex routing tables) the more you reduce the PPS. Gary --------------------------------- Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. Get it now. From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 18:58:52 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E100916A421 for ; Fri, 7 Sep 2007 18:58:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (outE.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id DDA7113C4A8 for ; Fri, 7 Sep 2007 18:58:51 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 07 Sep 2007 11:58:50 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id C9C5C1262EA; Fri, 7 Sep 2007 11:58:49 -0700 (PDT) Message-ID: <46E19F68.1090802@elischer.org> Date: Fri, 07 Sep 2007 11:58:48 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Julian Elischer , David Christensen , FreeBSD Net References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> <46E0A5DB.3080404@elischer.org> <20070907172216.GL977@funkthat.com> In-Reply-To: <20070907172216.GL977@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 18:58:53 -0000 John-Mark Gurney wrote: > Julian Elischer wrote this message on Thu, Sep 06, 2007 at 18:14 -0700: >> David Christensen wrote: >>>> Julian Elischer wrote: >>>>> Ok which clever person did this again? >>>>> >>>>> It just broke our product. >>>>> If it hasn't been removed from 7.0 and 6.x yet it's just >>>> about to be... >>>> >>>> >>>> on the topic above, I've found that the bce driver seems to >>>> be throwingaway packets >>>> larger than the mtu regardless of the rest of the system.. >>> This has been part of the driver since it's initial release, >>> it's not an addition or change. >>> >>>> the following code seems to be responsible.. >>>> >>>> in the spirit of "be generous on receive" as mentionned before, >>>> should it be relaxed? >>>> >>> When this RX MTU size issue was being discussed previously I >>> was wondering why nobody actually discussed what the drivers >>> are doing. Both the NetXtreme (bge) and NetXtreme II (bce) >>> controllers have a setting in the RX MAC to specify the MTU >>> size of the medium. Anything larger than the MTU is discarded >>> and a statistic is recorded. Support for jumbo frames is >>> available (though not on all bge supported controllers) but the >>> general understanding from the hardware design perspective is >>> that the MTU is the maximum message size on the medium and that >>> all controllers on the medium should be configured for the same >>> message size. I've never seen an Ethernet driver that supports >>> different MTUs for RX and TX (is there one implemented under >>> FreeBSD?) and I would really hate to troubleshoot any higher >>> level application problems that might occur if the RX and TX MTU >>> were different for every system on a network. >>> >>>> /* Calculate and program the Ethernet MTU size. */ >>>> ether_mtu = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN + >>>> ifp->if_mtu + >>>> ETHER_CRC_LEN; >>>> >>>> DBPRINT(sc, BCE_INFO, "%s(): setting mtu = >>>> %d\n",__FUNCTION__, ether_mtu); >>>> >>>> >>>> /* >>>> * Program the mtu, enabling jumbo frame >>>> * support if necessary. Also set the mbuf >>>> * allocation count for RX frames. >>>> */ >>>> if (ether_mtu > ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) { >>>> REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu | >>>> BCE_EMAC_RX_MTU_SIZE_JUMBO_ENA); >>>> sc->mbuf_alloc_size = MJUM9BYTES; >>>> } else { >>>> REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu); David, Assuming I want to just allow it to capture packets that will fit in whatever was allocated, what would I add here? as a guess I imagine the following? REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, MCLBYTES-(sizeof(struct l2_fhdr) + 2 + 8)); >>>> sc->mbuf_alloc_size = MCLBYTES; >>>> } >>>> >>>> >>>> could probably be relaxed in the non jumbo case to accept >>>> packets up to >>>> MCLBYTES in size instead of ether_mtu. >>> Maybe MCLBYTES is good enough for you but what if someone has >>> a different requirement? How big is big enough for everyone? I just want the case for encapsulated packets. usually this is a small overhead. The BSD 'way' has always been to accept whatever we practically can, but to only send strictly according to the spec. (I say BSD way as in "since 1982 or so") it's even documented somewhere. (see Mike Karel's previous email on the topic) >>> >>> I suppose supporting different MTUs for RX and TX is possible, >>> though the memory requirements are 5x larger for jumbo frames >>> over standard frames and many users might consider this a waste >>> of resources if they don't support jumbo frames on their >>> network (that would be almost 4MB). Support would obviously >>> be easier if "ifconfig" support both an RX and TX MTU size. >>> >>>> manually I have set the mtu to larger values which increases >>>> ether_mtu and that seems to work.. >>>> now, Why do we need this? >>>> >>>> WCCP is a protocol from Cisco. >>>> it encapsulates packets in GRE, including an extra >>>> intermediate header. >>>> when packets are encapsulated in GRE by cisco 6k switches >>>> (quite a few around) >>>> they do NOT frag the result, but instead, send an oversized packet. >>>> >>>> if you have a bce interface, it discards these packets which >>>> is a drag. >>> It could certainly be argued by some that Cisco is not standards >>> compliant in this case for sending an oversized Ethernet frame >>> and expecting everyone to accept it. Hardware has limitations >>> and assuming that all Ethernet controllers can support frames >>> greater than 1522 bytes is not reasonable. Fortunately there is >>> a suitable workaround which is setting a larger MTU for the >>> interface. What size do you use? How did you arrive at that >>> value? >> I use 1550 to make it work in the test harness. >> >> The trouble is that if I set the mtu to 1550, and the machine talks to >> another >> such machine with it's mtu also set to 1550 then they negotiate a maximum >> sized >> packet based on 1550, and the problem hits me again. This is a web proxy >> and that problem occurs when there are two layers of proxy and one proxy >> talks to another. I really just need it to to silently accept a packet some >> 32 bytes or so larger than the stated MTU. > > Why not set the mtu on the net and host routes to 1500 to make it all > work? I forget if my route mtu code is in 6.2, but it'll be in 7.0... > > Maybe someone will write the mtud and we can be the first OS to turn > on jumbo frames by default.. :) > From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 19:10:48 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E4E216A418 for ; Fri, 7 Sep 2007 19:10:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 4581213C428 for ; Fri, 7 Sep 2007 19:10:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 07 Sep 2007 12:10:34 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 96BB9126302; Fri, 7 Sep 2007 12:10:33 -0700 (PDT) Message-ID: <46E1A229.10308@elischer.org> Date: Fri, 07 Sep 2007 12:10:33 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Julian Elischer , David Christensen , FreeBSD Net References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> <46E0A5DB.3080404@elischer.org> <20070907172216.GL977@funkthat.com> In-Reply-To: <20070907172216.GL977@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 19:10:48 -0000 John-Mark Gurney wrote: > > Why not set the mtu on the net and host routes to 1500 to make it all > work? I forget if my route mtu code is in 6.2, but it'll be in 7.0... I think it is.. took us ages to figure out why some client machines hit this and others didn't. turned out that there were MTUs on some routes that were different to others for various reasons. I was considering using route change (route) -mtu 1440 as a workaround, but it's a bit dependent on knowing what and where all your routes are. From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 19:15:56 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A242516A417; Fri, 7 Sep 2007 19:15:56 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1B59413C442; Fri, 7 Sep 2007 19:15:55 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (vader.bytemobile.ondsl.gr [83.235.244.135]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-8) with ESMTP id l87IwERO014672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Sep 2007 21:58:21 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l87IvwnM025790; Fri, 7 Sep 2007 21:58:14 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l87IvvwH025789; Fri, 7 Sep 2007 21:57:57 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 7 Sep 2007 21:57:57 +0300 From: Giorgos Keramidas To: "Bruce M. Simpson" Message-ID: <20070907185757.GA25624@kobe.laptop> References: <46E11515.8090007@tomjudge.com> <46E174DB.8070004@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E174DB.8070004@FreeBSD.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.959, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.44, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Tom Judge , freebsd-net@freebsd.org Subject: Re: Strange behaviour of route command X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 19:15:56 -0000 On 2007-09-07 16:57, "Bruce M. Simpson" wrote: > Tom Judge wrote: >> Hi, >> While making some changes to the routing table on one of our routers >> today I noticed that "route add" was showing some strange >> behaviour. When adding a route for 128/8 to the table rather than >> adding 128.0.0.0/8 it would add 0.0.0.0/8, however adding 10/9 works >> correctly. >> >> Is this a bug in route or the routing table? > > Run 'route -nv monitor' in another shell while you do this and post the > output to this list so someone can get more of a handle on it. I can reproduce what Tom describes, and route -nv monitor shows: got message of size 132 on Fri Sep 7 21:55:29 2007 RTM_ADD: Add Route: len 132, pid: 25766, seq 1, errno 0, flags: locks: inits: sockaddrs: 0.128.0.0 10.8.1.100 (0) 0 ff This is with a userland and kernel from around 15:00:00 UTC, built at: FreeBSD kobe 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu Sep 6 21:06:38 EEST 2007 From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 19:38:35 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385CE16A418; Fri, 7 Sep 2007 19:38:35 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (unknown [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id DC8AD13C4A7; Fri, 7 Sep 2007 19:38:34 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from uucp by noop.in-addr.com with local-rmail (Exim 4.54 (FreeBSD)) id 1ITjew-000JRW-En; Fri, 07 Sep 2007 15:38:30 -0400 Received: from localhost.home.in-addr.com ([127.0.0.1]:62955 helo=rimmer.home.in-addr.com) by rimmer.home.in-addr.com with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1ITjel-0002Jm-Nx; Fri, 07 Sep 2007 20:38:19 +0100 Message-ID: <46E1A8AB.7070708@freebsd.org> Date: Fri, 07 Sep 2007 20:38:19 +0100 From: Gary Palmer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.6) Gecko/20070808 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Kirc Gover References: <517436.12027.qm@web44802.mail.sp1.yahoo.com> In-Reply-To: <517436.12027.qm@web44802.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 19:38:35 -0000 Kirc Gover wrote: > Hi Gary, Thanks for your response. > > Yes, the bus architecture would be either PCI-X or PCI-Express. Host CP= U would be a high performance multi-core such as Xeon and NICs would be I= ntel. > > One of my concern is on the native forwarding capability of FreeBSD OS = and the execution of critical userland processes. I have experience befor= e that a FreeBSD box configured as router appears to slow down the userla= nd processes when the traffic load is high. I have verified this lately o= n 6.1, running on Athlon64 with 1G NIC cards with PF and ALTQ (queuing) e= nabled. I'm not so sure if this is caused by PF or ALTQ. Looking at the = processes using top, it could see that "swi(x) net" process is almost as = near 100% cpu utilization. At this state, the box can still forward traff= ic (not sure yet if the was a change in throughput) but I could notice th= e userland processes to be very slow, like invoking any command from the= shell (e.g. ls) will take so long to be executed and completed. Is this = a know limitation or bug? > =20 I'm probably not the best person to address that, but its my=20 understanding that interrupts will preempt other activity such as=20 userland processing. Since there is often a requirement to service=20 interrupts as a matter of priority (e.g. before the receive buffer in=20 the NIC overflows) I'm not sure theres a way around it. The performance = improvements in 7.x, especially relating to multi-core/CPU environments=20 might help. The complexity of the PF / ALTQ rules can also have an=20 impact, although I'm a little surprised that they counted towards=20 interrupt activity, which your message seems to imply. Gary P.S. Please don't top post. > Thanks a lot. > Kirc > > Gary Palmer wrote: On Fri, Sep 07, 2007 at 03:06:= 54AM +1000, Kirc Gover wrote: > =20 >> We are in the stage of planning and research for a commercial developm= ent of an edge router that will be based mostly on OpenSource software. I= would like to solicit for information and recommendation if FreeBSD is a= suitable OS. The router is expected to withstand forwarding of sustained= traffic from 10Mbps to 1Gbps and maybe more than that. Are there any kno= wn limitations of FreeBSD in terms of architecture and performance? Can I= just take out a FreeBSD as is and put it with the hardware without any s= pecific or major refinements in its code? I'm very much concerned with i= ts capability in forwarding heavy sustained traffic. Packet loss should b= e at minimum and critical userland processes should working normally eve= n under heavy load. Are there any known specific limitations of FreeBSD? = I have browsed through the archives and found a lot of hangups, deadlocks= and freeze issues. What is the usual or minimum hardware requirement? Is= soekris box enough, or dual core or ASIC >> based platforms? I'm aware that there are so many FreeBSD based route= rs and network based devices in the market. Is this a way to go over real= time and embedded OS such as VxWorks and others (mostly commercial) witho= ut putting the licensing cost in picture? I really appreciate any help, s= uggestions and recommendations. More power to FreeBSD! >> =20 > > Kirc, > > There are two factors to consider: > > - bus architecture (PCI, PCI-X, PCI-Express, etc) will dictate the > maximum throughput in bits/sec. Allow some overhead for bus arbitrat= ion > activities, and remember that the packet crosses the bus twice, once > on the inbound leg and once on the outbound leg. > > - Host CPU (and perhaps to a limited extent the interface cards used) > will dictate the packets per second (PPS) > > Most commercial routers run out of packets per second (in real-world > situations, not lab mockups) long before the theoretical maximum > throughput is achieved. Thinks like ICMP ping packets and TCP RST > packets are small (less than 100 bytes usually) but normally take as mu= ch > CPU to process & route as a 1500 byte (or larger) packet. > > The more you put in the processing path (e.g. packet filters, complex > routing tables) the more you reduce the PPS. > > Gary > > > =20 > --------------------------------- > Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. G= et it now. > =20 From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 19:50:57 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89BD016A41A for ; Fri, 7 Sep 2007 19:50:57 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 75A8C13C465 for ; Fri, 7 Sep 2007 19:50:57 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 294E61A4D7C; Fri, 7 Sep 2007 12:47:49 -0700 (PDT) Date: Fri, 7 Sep 2007 12:47:49 -0700 From: Alfred Perlstein To: David Christensen Message-ID: <20070907194749.GD87451@elvis.mu.org> References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> <46E0A5DB.3080404@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD903051CBEB6@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD903051CBEB6@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , Julian Elischer Subject: Re: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 19:50:57 -0000 * David Christensen [070907 10:48] wrote: > > > It could certainly be argued by some that Cisco is not standards > > > compliant in this case for sending an oversized Ethernet frame > > > and expecting everyone to accept it. Hardware has limitations > > > and assuming that all Ethernet controllers can support frames > > > greater than 1522 bytes is not reasonable. Fortunately there is > > > a suitable workaround which is setting a larger MTU for the > > > interface. What size do you use? How did you arrive at that > > > value? > > > > I use 1550 to make it work in the test harness. > > > > The trouble is that if I set the mtu to 1550, and the machine > > talks to another > > such machine with it's mtu also set to 1550 then they > > negotiate a maximum sized > > packet based on 1550, and the problem hits me again. This is > > a web proxy > > and that problem occurs when there are two layers of proxy > > and one proxy talks to > > another. I really just need it to to silently accept a packet some > > 32 bytes or so larger than the stated MTU. > > > > I see no reason for the driver to not do what the em driver > > does and allow > > itself to receive any packet up to the MCLBYTES size. > > > > We only hit this problem recently because the data interfaces on our > > devices are usually em NICs and we only just recently started > > allowing the > > users to use the built in (on DELL 2950) bce interfaces for > > this purpose. > > > > I'm not completely opposed to making such a change, but I don't want > to make a default change in the driver's behavior that other people > may be depending upon (whether they are aware of it or not). A > tunable driver value could be the answer but I'm not entirely sure > how it would fare in the hardware at the high end of MTU values such > as 9000. Dave: Internet ettiquette demands being gracious in what you accept. The default policy of FreeBSD is to accept such packets. This is a really weird bug to track down. Other drivers support it. This isn't worth making a stand over, unless you're trying to hold users of YOUR driver hostage. -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 20:41:12 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B56616A417 for ; Fri, 7 Sep 2007 20:41:12 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 465B513C45B for ; Fri, 7 Sep 2007 20:41:11 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id CB6B05B58; Fri, 7 Sep 2007 13:08:09 -0700 (PDT) To: Kirc Gover In-reply-to: Your message of "Sat, 08 Sep 2007 03:57:11 +1000." <517436.12027.qm@web44802.mail.sp1.yahoo.com> Date: Fri, 07 Sep 2007 13:08:09 -0700 From: Bakul Shah Message-Id: <20070907200809.CB6B05B58@mail.bitblocks.com> Cc: freebsd-net@freebsd.org Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 20:41:12 -0000 > One of my concern is on the native forwarding capability of FreeBSD OS and the > execution of critical userland processes. I have experience before that a > FreeBSD box configured as router appears to slow down the userland processes > when the traffic load is high. I have verified this lately on 6.1, running on > Athlon64 with 1G NIC cards with PF and ALTQ (queuing) enabled. I'm not so sure > if this is caused by PF or ALTQ. Looking at the processes using top, it could > see that "swi(x) net" process is almost as near 100% cpu utilization. At this > state, the box can still forward traffic (not sure yet if the was a change in > throughput) but I could notice the userland processes to be very slow, like > invoking any command from the shell (e.g. ls) will take so long to be executed > and completed. Is this a know limitation or bug? On my Athlon64 X2 3800+ box I get about 42,500 pings a second (with ping -q -f localhost, after removing icmp limits). For forwarding, you won't get a packets per second (pps) number significantly higher than that. Less if you do PF, ALTQ or VPNs. The worst case for 1GBps is about 1.488 Million pps. Even if you assume there is one ack packet for one data pacet of max size, you have over 150K pps when the full 1GBps is used up. I just don't think stock *BSD will do this for you on a typical el cheapo PC box. Neither will Linux or vmware. Listen to what Louis Mamakos said! Use FreeBSD primarily for the control plane. May be there are NICs where you can offload some packet forwarding.... But that is a substantial change to FreeBSD. Or live with what FreeBSD can do on a given box. For a project like yours, any Open Source code you get is a *starting point* and no more. Your customers don't care if it is FreeBSD or CP/M; they just expect your router to work and when it doesn't they expect you to fix it pronto. This means you have to do QA, find and fix bugs, add missing functionality and so on. You can't wait for FreeBSD volunteers to fix any problems; you will have to fix any OS panics, deadlocks and inefficiencies! May be you can start with requirements. How many VPNs, how much bandwidth, required pps, other performance/latency requirements, protocols (and specific features in them) you *must* have, protocols you may like to have, required CPU bandwidth for running your proprietary services, some idea of how these numbers will grow over the next three years, what applications you may wish to run, what cost of goods you can afford, etc. That ought to help you decide what h/w platform is suitable or which requirement must go :-) From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 20:44:05 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A2E116A418; Fri, 7 Sep 2007 20:44:05 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id BD57E13C46C; Fri, 7 Sep 2007 20:44:04 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 07 Sep 2007 13:43:49 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 93FAB2AF; Fri, 7 Sep 2007 13:43:49 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 7F8472AE; Fri, 7 Sep 2007 13:43:49 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FQS13967; Fri, 7 Sep 2007 13:43:46 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id BFF7E69CA3; Fri, 7 Sep 2007 13:43:46 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Sep 2007 13:43:43 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD903051CBF54@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20070907194749.GD87451@elvis.mu.org> Thread-Topic: FreeBSD discarding received packets > MTU Thread-Index: AcfxiHLJkDK0BJCZSnqWy2939BvrPQAA92CA References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> <46E0A5DB.3080404@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD903051CBEB6@NT-IRVA-0750.brcm.ad.broadcom.com> <20070907194749.GD87451@elvis.mu.org> From: "David Christensen" To: "Alfred Perlstein" X-WSS-ID: 6AFF678F49W40562-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , Julian Elischer Subject: RE: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 20:44:05 -0000 > > I'm not completely opposed to making such a change, but I don't want > > to make a default change in the driver's behavior that other people=20 > > may be depending upon (whether they are aware of it or not). A > > tunable driver value could be the answer but I'm not entirely sure > > how it would fare in the hardware at the high end of MTU=20 > values such=20 > > as 9000. >=20 > Dave: >=20 > Internet ettiquette demands being gracious in what you accept. > The default policy of FreeBSD is to accept such packets. > This is a really weird bug to track down. > Other drivers support it. >=20 > This isn't worth making a stand over, unless you're trying > to hold users of YOUR driver hostage. >=20 I'm just being cautious about making changes before I understand all of the implications. The driver's current behavior is supported by IEEE 802.3 specification (802.3-2005, 4.2.4.2.1) and is implemented in the same way for other operating systems that are very widely deployed (including Windows and Linux) without any reported problems. The existing bge driver which was developed for FreeBSD 10 years ago also operates this way, so all of my references for porting this driver happen to agree on the same implementation. Dave From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 21:45:48 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B5D616A418; Fri, 7 Sep 2007 21:45:48 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EFEBB13C481; Fri, 7 Sep 2007 21:45:47 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l87LjlA0082504; Fri, 7 Sep 2007 21:45:47 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l87LjlDK082500; Fri, 7 Sep 2007 21:45:47 GMT (envelope-from remko) Date: Fri, 7 Sep 2007 21:45:47 GMT Message-Id: <200709072145.l87LjlDK082500@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/116185: if_iwi driver leads system to reboot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 21:45:48 -0000 Synopsis: if_iwi driver leads system to reboot Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Sep 7 21:45:47 UTC 2007 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=116185 From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 21:45:58 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FCD016A421; Fri, 7 Sep 2007 21:45:58 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C9CE613C4A5; Fri, 7 Sep 2007 21:45:57 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l87Ljvd8082592; Fri, 7 Sep 2007 21:45:57 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l87LjvlN082588; Fri, 7 Sep 2007 21:45:57 GMT (envelope-from remko) Date: Fri, 7 Sep 2007 21:45:57 GMT Message-Id: <200709072145.l87LjvlN082588@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/116186: can not set wi channel on current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2007 21:45:58 -0000 Synopsis: can not set wi channel on current Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Sep 7 21:45:57 UTC 2007 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=116186 From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 22:45:51 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94B9B16A417 for ; Fri, 7 Sep 2007 22:45:51 +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 3A54013C4A6 for ; Fri, 7 Sep 2007 22:45:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.14.1/8.13.8) with SMTP id l87MVwQ4037522; Fri, 7 Sep 2007 18:31:58 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Fabien THOMAS Date: Fri, 07 Sep 2007 18:32:07 -0400 Message-ID: <09k3e3d46bb5br07r883sdokn0j7qlkp0c@4ax.com> 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: new version of polling for FreeBSD 6.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 22:45:51 -0000 On Thu, 6 Sep 2007 15:12:06 +0200, in sentex.lists.freebsd.net you wrote: >After many years of good services we will stop using FreeBSD 4.x :) >During my performance regression tests under FreeBSD 6.2 i've found =20 >that polling has lower performance than interrupt. >To solve that issue i've rewritten the core of polling to be more SMP =20 >ready. Hi, This is really interesting work! Reading the pdf file, it seems forwarding performance on 6 and 7 is still much lower than RELENG_4 ? is that correct ? ---Mike > >You can find a summary of all my tests and the source code at the =20 >following address: >http://www.netasq.com/opensource/pollng-rev1-freebsd.tgz > >Feel free to ask more detailed information if necessary and report =20 >any bugs / comments. > >Fabien > > >_______________________________________________ >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 Fri Sep 7 22:57:16 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D8B716A420 for ; Fri, 7 Sep 2007 22:57:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 09C3813C428 for ; Fri, 7 Sep 2007 22:57:11 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 41467 invoked from network); 7 Sep 2007 22:44:17 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Sep 2007 22:44:17 -0000 Message-ID: <46E1D74D.3070409@freebsd.org> Date: Sat, 08 Sep 2007 00:57:17 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Bakul Shah References: <20070907200809.CB6B05B58@mail.bitblocks.com> In-Reply-To: <20070907200809.CB6B05B58@mail.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Kirc Gover Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 22:57:16 -0000 Bakul Shah wrote: >> One of my concern is on the native forwarding capability of FreeBSD OS and the >> execution of critical userland processes. I have experience before that a >> FreeBSD box configured as router appears to slow down the userland processes >> when the traffic load is high. I have verified this lately on 6.1, running on >> Athlon64 with 1G NIC cards with PF and ALTQ (queuing) enabled. I'm not so sure >> if this is caused by PF or ALTQ. Looking at the processes using top, it could >> see that "swi(x) net" process is almost as near 100% cpu utilization. At this >> state, the box can still forward traffic (not sure yet if the was a change in >> throughput) but I could notice the userland processes to be very slow, like >> invoking any command from the shell (e.g. ls) will take so long to be executed >> and completed. Is this a know limitation or bug? All software switched platforms have this problem. You've got only so much CPU power and it is shared between forwarding packets and running userland processes. Even the popular Cisco 7200, 7300, 3800, 2800, 1800 and 800 Series routers suffer from it. All of them break down quite hard under load and advanced features like ACLs, QoS and all other stuff. The only way around it a split forwarding and control plane where the forwarding is done on dedicated ASICs or FPGAs. Examples are the Cisco 7600, 12000 and CRS-1 Series. At Juniper it's all the M Series routers. At Foundry Networks it's the Net- and BigIron Series. However this dedicated hardware has its cost and isn't available on commodity platforms. > On my Athlon64 X2 3800+ box I get about 42,500 pings a second > (with ping -q -f localhost, after removing icmp limits). For > forwarding, you won't get a packets per second (pps) number > significantly higher than that. Less if you do PF, ALTQ or > VPNs. This is not the case. Flood ping doesn't reach the limit in any way. Have a look at the ping man page and flood ping description. > The worst case for 1GBps is about 1.488 Million pps. Even if > you assume there is one ack packet for one data pacet of max > size, you have over 150K pps when the full 1GBps is used up. > I just don't think stock *BSD will do this for you on a > typical el cheapo PC box. Neither will Linux or vmware. Stock FreeBSD 6.2 or 7.0 can easily do 500kpps with good network cards and fastforwarding enabled. On a dual-Opteron 2.6GHz with PCI-X Intel and Broadcom network cards I've done 800kpps in-out. Just sinking 2.88Mpps into the box (into a blackhole route) takes about 60% CPU at zero unintended packet loss. Throughput in terms of bandwidth is an non-issue. Bus bandwidth on PCI-X and PCI-E is plenty and even at 500kpps you can push more than 5Gbit/s at 1500 byte packets. Of course there is a mix of small and large packets and at 500kpps the actual peak throughput is closer to 2Gbit/s. All measured with a calibrated Agilent N2X packet generator. The forwarding bandwidth is only limited by the pps rate (times packet size or size mix). Firewalling may have some non-trivial impact on forwarding performance depending on the number and structure of the rules. In general ipfw has quite a bit less impact than pf. A rule of thumb is that about 100 ipfw rules cost 50% of the peak pps performance. Doing ALTQ on a box with GigE ports is not useful and only wastes pps performance. As long as there is no queuing going on ALTQ doesn't provide any benefits and only burns CPU. ALTQ isn't really optimized on FreeBSD and the performance impact is probably significant, although I don't have any hard numbers on it. > Listen to what Louis Mamakos said! Use FreeBSD primarily for > the control plane. May be there are NICs where you can > offload some packet forwarding.... But that is a substantial > change to FreeBSD. Or live with what FreeBSD can do on a > given box. There are no NICs known that can do packet forwarding offload. And neither is there support in FreeBSD for that. You're probably confusing this with checksum offloading or TSO (TCP segmentation offloading) which isn't an issue with packet forwarding at all. > For a project like yours, any Open Source code you get is a > *starting point* and no more. Your customers don't care if > it is FreeBSD or CP/M; they just expect your router to work > and when it doesn't they expect you to fix it pronto. This > means you have to do QA, find and fix bugs, add missing > functionality and so on. You can't wait for FreeBSD > volunteers to fix any problems; you will have to fix any OS > panics, deadlocks and inefficiencies! I'm running all my routing on FreeBSD since about 1998. No problems and much more reliable than the countless Cisco IOS versions that have been deprecated since then. On any more recent platform or new line card you have to run IOS T versions which is most of the time is much worse than running FreeBSD-current on a production machine. It's probably cheaper to pay FreeBSD developers to fix any issues you find or run into than to pay Cisco for the pretty much mandatory service contract where any useful level starts at some 14% annually of the purchase price. And even then you have to pay for TAC cases and you are last in the queue relative to all others who pay more. Even when SQL slammer hit my network I didn't notice. The FreeBSD routers kept up while the Ciscos left and right (at other ISPs) fell over. OTOH I'm only doing plain vanilla BGP routing with a number of full feeds (about 230k routes at the moment, I'm part of the DFZ). My AS is a genuine AS8271. Router uptime of more than 600 days. Stuff just works, never have to worry about it. No sleep lost. > May be you can start with requirements. How many VPNs, how > much bandwidth, required pps, other performance/latency > requirements, protocols (and specific features in them) you > *must* have, protocols you may like to have, required CPU > bandwidth for running your proprietary services, some idea of > how these numbers will grow over the next three years, what > applications you may wish to run, what cost of goods you can > afford, etc. That ought to help you decide what h/w platform > is suitable or which requirement must go :-) Can't comment on VPN or IPSEC stuff. Never used that to any significant extent. However keep in mind that for the price of a single high powered Cisco or Juniper you can buy a very large number of also quite well powered FreeBSD powered routers. My recommendation for a optimal FreeBSD based router is as follows: CPU Core2 Duo or Athlon 64X2, more cores don't help in any way. One core can take the interrupts and one can continue to serve userland. A quality mainboard from Tyan, Supermicro or Intel with PCI-Express. A number of (dual-port) Intel Gigabit PCI-E network cards. Some two GB of RAM and a flash based ATA or SATA harddisk. Good case, redundant power supplies, good fans and otherwise no movable parts. Don't try RAID1 or stuff like that, causes more problems than it solves. Go for a single flash disk that is replaceable without having to disassemble the entire case. There are some 3.5" based flash disks on the market or buy a CF to ATA adapter for mounting into a 3.5" disk slot and use normal but fast CF cards. That'll do it. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 23:00:49 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1C9616A418 for ; Fri, 7 Sep 2007 23:00:49 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 92C2513C442 for ; Fri, 7 Sep 2007 23:00:49 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7DB801A4D7C; Fri, 7 Sep 2007 16:00:49 -0700 (PDT) Date: Fri, 7 Sep 2007 16:00:49 -0700 From: Alfred Perlstein To: David Christensen Message-ID: <20070907230049.GG87451@elvis.mu.org> References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> <46E0A5DB.3080404@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD903051CBEB6@NT-IRVA-0750.brcm.ad.broadcom.com> <20070907194749.GD87451@elvis.mu.org> <09BFF2FA5EAB4A45B6655E151BBDD903051CBF54@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD903051CBF54@NT-IRVA-0750.brcm.ad.broadcom.com> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , Julian Elischer Subject: Re: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 23:00:49 -0000 * David Christensen [070907 13:41] wrote: > > > I'm not completely opposed to making such a change, but I don't want > > > to make a default change in the driver's behavior that other people > > > may be depending upon (whether they are aware of it or not). A > > > tunable driver value could be the answer but I'm not entirely sure > > > how it would fare in the hardware at the high end of MTU > > values such > > > as 9000. > > > > Dave: > > > > Internet ettiquette demands being gracious in what you accept. > > The default policy of FreeBSD is to accept such packets. > > This is a really weird bug to track down. > > Other drivers support it. > > > > This isn't worth making a stand over, unless you're trying > > to hold users of YOUR driver hostage. > > > > I'm just being cautious about making changes before I understand > all of the implications. The driver's current behavior is > supported by IEEE 802.3 specification (802.3-2005, 4.2.4.2.1) > and is implemented in the same way for other operating systems > that are very widely deployed (including Windows and Linux) > without any reported problems. The existing bge driver which > was developed for FreeBSD 10 years ago also operates this way, > so all of my references for porting this driver happen to agree > on the same implementation. Which is all well and good, but the age of a bug does not a feature make. Please think of the four points I raised. I think it makes sense to possibly add a "enforce rx mtu" knob somewhere, but it should likely be turned off. -Alfred From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 23:03:27 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F403016A419; Fri, 7 Sep 2007 23:03:26 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 8AB3213C442; Fri, 7 Sep 2007 23:03:26 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 07 Sep 2007 16:03:10 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 27F772AF; Fri, 7 Sep 2007 16:03:10 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 136232AE; Fri, 7 Sep 2007 16:03:10 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FQS41248; Fri, 7 Sep 2007 16:03:09 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com ( nt-irva-0750.brcm.ad.broadcom.com [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id D6BD169CA4; Fri, 7 Sep 2007 16:03:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Sep 2007 16:03:07 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD903051CBFCB@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <20070907230049.GG87451@elvis.mu.org> Thread-Topic: FreeBSD discarding received packets > MTU Thread-Index: AcfxovRyX5hKnh4nR1SVG9kM5YnoMwAADpoQ References: <46E0632D.8070200@elischer.org> <46E07E74.5020204@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD9030501D5C0@NT-IRVA-0750.brcm.ad.broadcom.com> <46E0A5DB.3080404@elischer.org> <09BFF2FA5EAB4A45B6655E151BBDD903051CBEB6@NT-IRVA-0750.brcm.ad.broadcom.com> <20070907194749.GD87451@elvis.mu.org> <09BFF2FA5EAB4A45B6655E151BBDD903051CBF54@NT-IRVA-0750.brcm.ad.broadcom.com> <20070907230049.GG87451@elvis.mu.org> From: "David Christensen" To: "Alfred Perlstein" X-WSS-ID: 6AFF07246B094959-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , Julian Elischer Subject: RE: FreeBSD discarding received packets > MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 23:03:27 -0000 > > > Internet ettiquette demands being gracious in what you accept. > > > The default policy of FreeBSD is to accept such packets. > > > This is a really weird bug to track down. > > > Other drivers support it. > > >=20 > > > This isn't worth making a stand over, unless you're trying > > > to hold users of YOUR driver hostage. > > >=20 > >=20 > > I'm just being cautious about making changes before I understand > > all of the implications. The driver's current behavior is > > supported by IEEE 802.3 specification (802.3-2005, 4.2.4.2.1) > > and is implemented in the same way for other operating systems > > that are very widely deployed (including Windows and Linux) > > without any reported problems. The existing bge driver which > > was developed for FreeBSD 10 years ago also operates this way, > > so all of my references for porting this driver happen to agree > > on the same implementation. >=20 > Which is all well and good, but the age of a bug does not a feature > make. >=20 > Please think of the four points I raised. >=20 > I think it makes sense to possibly add a "enforce rx mtu" knob > somewhere, but it should likely be turned off. That's the plan. Dave From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 23:05:25 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89DE116A46C for ; Fri, 7 Sep 2007 23:05:25 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D204713C45B for ; Fri, 7 Sep 2007 23:05:21 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 41550 invoked from network); 7 Sep 2007 22:52:27 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Sep 2007 22:52:27 -0000 Message-ID: <46E1D937.8040600@freebsd.org> Date: Sat, 08 Sep 2007 01:05:27 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Mike Tancsa References: <09k3e3d46bb5br07r883sdokn0j7qlkp0c@4ax.com> In-Reply-To: <09k3e3d46bb5br07r883sdokn0j7qlkp0c@4ax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Fabien THOMAS Subject: Re: new version of polling for FreeBSD 6.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 23:05:25 -0000 Mike Tancsa wrote: > On Thu, 6 Sep 2007 15:12:06 +0200, in sentex.lists.freebsd.net you > wrote: >> After many years of good services we will stop using FreeBSD 4.x :) >> During my performance regression tests under FreeBSD 6.2 i've found >> that polling has lower performance than interrupt. >> To solve that issue i've rewritten the core of polling to be more SMP >> ready. > > Hi, > This is really interesting work! Reading the pdf file, it > seems forwarding performance on 6 and 7 is still much lower than > RELENG_4 ? is that correct ? Haven't tested RELENG_4 performance in a controlled environment and thus can't answer the question directly. However using fastforward on 6 and 7 is key to good performance. Without it you're stuck at some 150-200kpps, perhaps 300kpps. With it you get to 500-800kpps. -- Andre > ---Mike >> You can find a summary of all my tests and the source code at the >> following address: >> http://www.netasq.com/opensource/pollng-rev1-freebsd.tgz >> >> Feel free to ask more detailed information if necessary and report >> any bugs / comments. >> >> Fabien >> >> >> _______________________________________________ >> 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) > _______________________________________________ > 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 Sep 7 23:56:23 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C143016A419 for ; Fri, 7 Sep 2007 23:56:23 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5F57C13C478 for ; Fri, 7 Sep 2007 23:56:23 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id C410D5B58; Fri, 7 Sep 2007 16:56:22 -0700 (PDT) To: Andre Oppermann In-reply-to: Your message of "Sat, 08 Sep 2007 00:57:17 +0200." <46E1D74D.3070409@freebsd.org> Date: Fri, 07 Sep 2007 16:56:22 -0700 From: Bakul Shah Message-Id: <20070907235622.C410D5B58@mail.bitblocks.com> Cc: freebsd-net@freebsd.org, Kirc Gover Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 23:56:23 -0000 > This is not the case. Flood ping doesn't reach the limit in any > way. Have a look at the ping man page and flood ping description. Ah yes, I was forgetting about the strict synchrony. > Stock FreeBSD 6.2 or 7.0 can easily do 500kpps with good network > cards and fastforwarding enabled. On a dual-Opteron 2.6GHz with > PCI-X Intel and Broadcom network cards I've done 800kpps in-out. What is the throughput when fastforwarding is not used and packets go to different destinations? Note that typically fastforwarding does not help much on a router since only one route is cached. > > Listen to what Louis Mamakos said! Use FreeBSD primarily for > > the control plane. May be there are NICs where you can > > offload some packet forwarding.... But that is a substantial > > change to FreeBSD. Or live with what FreeBSD can do on a > > given box. > > There are no NICs known that can do packet forwarding offload. > And neither is there support in FreeBSD for that. You're probably > confusing this with checksum offloading or TSO (TCP segmentation > offloading) which isn't an issue with packet forwarding at all. Indeed. That is why I said "that is a substantial change to FreeBSD"! But even offloading checksum can help as the CPU has less to do. > I'm running all my routing on FreeBSD since about 1998. No > problems and much more reliable than the countless Cisco IOS > versions that have been deprecated since then. On any more > recent platform or new line card you have to run IOS T versions > which is most of the time is much worse than running FreeBSD-current > on a production machine. It's probably cheaper to pay FreeBSD > developers to fix any issues you find or run into than to pay > Cisco for the pretty much mandatory service contract where any > useful level starts at some 14% annually of the purchase price. > And even then you have to pay for TAC cases and you are last in > the queue relative to all others who pay more. This is fine if he was building one or a few for his own company's use but for selling routers to a third party you have to productize the software and provide tighter bounds on when you will fix critical bugs. Also, what works for Cisco won't work for a startup. Even if you provide free service they may not want to buy your product! > Can't comment on VPN or IPSEC stuff. Never used that to any > significant extent. However keep in mind that for the price > of a single high powered Cisco or Juniper you can buy a very > large number of also quite well powered FreeBSD powered routers. Agreed! > My recommendation for a optimal FreeBSD based router is as follows: > CPU Core2 Duo or Athlon 64X2, more cores don't help in any way. One > core can take the interrupts and one can continue to serve userland. > A quality mainboard from Tyan, Supermicro or Intel with PCI-Express. > A number of (dual-port) Intel Gigabit PCI-E network cards. Some two > GB of RAM and a flash based ATA or SATA harddisk. Good case, redundant > power supplies, good fans and otherwise no movable parts. Don't try > RAID1 or stuff like that, causes more problems than it solves. Go for > a single flash disk that is replaceable without having to disassemble > the entire case. There are some 3.5" based flash disks on the market > or buy a CF to ATA adapter for mounting into a 3.5" disk slot and use > normal but fast CF cards. That'll do it. May be! From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 23:59:11 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 733EB16A417 for ; Fri, 7 Sep 2007 23:59:11 +0000 (UTC) (envelope-from chris@arnold.se) Received: from mailstore.infotropic.com (mailstore.infotropic.com [213.136.34.3]) by mx1.freebsd.org (Postfix) with ESMTP id A64C413C459 for ; Fri, 7 Sep 2007 23:59:10 +0000 (UTC) (envelope-from chris@arnold.se) Received: (qmail 35820 invoked by uid 89); 7 Sep 2007 23:32:28 -0000 Received: by simscan 1.2.0 ppid: 35815, pid: 35817, t: 0.1252s scanners: attach: 1.2.0 clamav: 0.90/m:42 Received: from unknown (HELO ?192.168.123.123?) (chris@arnold.se@82.182.86.134) by mailstore.infotropic.com with ESMTPA; 7 Sep 2007 23:32:28 -0000 Date: Sat, 8 Sep 2007 01:32:25 +0200 (CEST) From: Christopher Arnold X-X-Sender: chris@chrishome.localnet To: Andre Oppermann In-Reply-To: <46E1D74D.3070409@freebsd.org> Message-ID: <20070908012111.C66700@chrishome.localnet> References: <20070907200809.CB6B05B58@mail.bitblocks.com> <46E1D74D.3070409@freebsd.org> X-message-flag: =?ISO-8859-1?Q?Outlook_isn=B4t_compliant_with_current_standards?= =?ISO-8859-1?Q?_please_install_another_mail_client!?= MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Bakul Shah , freebsd-net@freebsd.org, Kirc Gover Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Sep 2007 23:59:11 -0000 On Sat, 8 Sep 2007, Andre Oppermann wrote: > There are no NICs known that can do packet forwarding offload. > And neither is there support in FreeBSD for that. You're probably > confusing this with checksum offloading or TSO (TCP segmentation > offloading) which isn't an issue with packet forwarding at all. > This was my understanding to until the original poster inspired be to google yet another time for a card supporting packet forwarding offload. To my suprise i found one! http://netfpga.org/ 4 port wire speed GigE forwarding on a PCI card with drivers for linux CentOS 4. (And inter card links for joining more cards together.) Hardware developed at Stanford under a BSD license, and they seem to have cards ready to ship any day now. I shure would like to take that card for a ride under FreeBSD! > a single flash disk that is replaceable without having to disassemble > the entire case. There are some 3.5" based flash disks on the market > or buy a CF to ATA adapter for mounting into a 3.5" disk slot and use > normal but fast CF cards. That'll do it. > May i ask if you take any precautions to protect against wearing out the flash? /Chris -- http://www.arnold.se/ From owner-freebsd-net@FreeBSD.ORG Sat Sep 8 00:29:43 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE4E116A417 for ; Sat, 8 Sep 2007 00:29:43 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 98E6D13C45B for ; Sat, 8 Sep 2007 00:29:43 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so709383waf for ; Fri, 07 Sep 2007 17:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=VQZhr4naGAHaGqXKiI+Tv+mNeYKjAJNKmkfqFZo6cgo=; b=YtDBMXQIT1iOqW7UNPVOkM3/HVIBIFVxwg1tpjPKQTnoMOEU2bQpk+ihrbHohcKKeThSVH93uH6YrhV8dunAdNGIQRD4IBgZiMN8KVXMdV+Hdu/41QHNh/J0UhkLt8ZB0K5ydawzZONtvQnaxve4+x09Wo14yg2qRdljOYNkoYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=df8d/CwE1LgZM5mQBZuphD0WLF50nw1GO77mfWOoox2URRjGxCiXNecXiN8VFcbvJXvTAldGG2DtIVqeIrC44lK1MygKxHsd5X5P5Et3PUGBfuHHqR48zq1r7/3zOC18w76s82YWkQaP7+0Zq6rM0NUgTaYQ6LknY41vIAGODho= Received: by 10.115.111.1 with SMTP id o1mr1642132wam.1189211382726; Fri, 07 Sep 2007 17:29:42 -0700 (PDT) Received: by 10.115.79.2 with HTTP; Fri, 7 Sep 2007 17:29:42 -0700 (PDT) Message-ID: <82bdb5ec0709071729l1bd68f8v551dc64440a328b7@mail.gmail.com> Date: Fri, 7 Sep 2007 19:29:42 -0500 From: "sazzadur rahman" To: "Randall Stewart" In-Reply-To: <46E00A39.6020208@cisco.com> MIME-Version: 1.0 References: <82bdb5ec0709051817j16bfea69u74b9f4978c1f00fc@mail.gmail.com> <46DFFFFD.6000309@cisco.com> <46E00A39.6020208@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: A query regarding sctp_bindx api in SCTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Sep 2007 00:29:44 -0000 Thanks for your update (Sep6_2007) in your website. It simply works fine. Comparing with sctp_asconf.c of 6.1 patch, I found that sending ASCONF chunk was only timer based where in the updated version, it is sent immediately. Basically I am porting SCTP from freebsd to a RTOS to test some algorithms which use multi-homing feature of SCTP. I may have some problem in callout in the port that's why timer based ASCONF didn't work. Although Sending immediate ASCONF works fine. Best Regards, Sazzad On 9/6/07, Randall Stewart wrote: > > Well I spoke to soon.. after a bit more testing .. I figured > out that I had fat-fingered my address set on my > second interface.. opps :-D > > So after testing I see this all working now on the latest > code.. now as I said the Jul_13 issue is way behind.. so > I have now updated the sctp.org web site with a Sep 6 version. > > This as even a LOT of patches that the current software > does not.. ** I am waiting for approval of a patch (18) which > does some deep restructure so we can have MAC-OSX use the > same locking model as BSD.. behind that I have a patch (19) with > many more bug fixes.. we now are to the point that we are running > VERY VERY well on an 8 Core MAC box in Michael Tuexens lab.. running > both the MPI test suite AND the special mywaitall killer MPI test > (as well as the reserpool workout). The good new for you is > that the update on my website (Sep6_2007) has all of these > bug fixes... so please update to the latest code and tell me > if the problem has gone away.. it should.. or I am doing something > wrong with the test code (based on the code in this email).. > > Let me know if you have any more problems.. > > Thanks > > R > > > Randall Stewart wrote: > > Definetly a bug... let me dig in a bit further.. it > > appears that ASCONF is not happening on sub-set bound > > sockets at all ;-( > > > > I will see if I can figure out why :-D > > > > R > > > > sazzadur rahman wrote: > > > >> Hello, > >> I am using sctp patch for freebsd6.1. For dynamic address > >> configuration, I > >> am calling sctp_bindx() API after successfull bind() and connect() > API's. > >> Although sctp_bindx() API successfully returns 0, the debug message > >> shows: > >> > >> addr_mgmt_assoc: added to pending list... > >> asconf_queue_add: appended asconf ADD_IP_ADDRESS... > >> > >> And I didn't see any ASCONF chunk sent to the peer in the tcpdump. > >> Hence, I > >> am confused why it should be in the pendling list instead of immediate > >> send > >> to peer? > >> > >> In draft-ietf-tsvwg-addip-sctp-22.txt: page 20, A3, I have found that > >> "If an > >> ASCONF chunk is outstanding, then the ASCONF chunk should be queued for > >> later transmission and no further action should be taken until the > >> previous > >> ASCONF is acknowledged or a timeout occurs." But as I am calling > >> sctp_bindx() for the first time, there should not be any previous > ASCONF > >> existing. > >> > >> Does anyone have any idea what I am missing here? > >> I would appriciate any help in this regard. > >> > >> Best Regards, > >> Md. Sazzadur Rahman, > >> Graduate Student, > >> School of Computer Science, > >> University of Oklahoma, > >> Norman, USA > >> > >> ---------------------------code segment I have > used--------------------- > >> //socket > >> s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); > >> > >> //bind > >> memset(&myAddr, 0, sizeof myAddr); > >> myAddr.sin_family = AF_INET; > >> myAddr.sin_port = htons(5060); > >> myAddr.sin_addr.s_addr = inet_addr("129.15.78.125"); > >> if (bind(s, (struct sockaddr *)&myAddr, sizeof myAddr) < 0) { > >> goto close; > >> } > >> //connect > >> memset(&farAddr, 0, sizeof farAddr); > >> farAddr.sin_family = AF_INET; > >> farAddr.sin_port = htons(6060); > >> farAddr.sin_addr.s_addr = inet_addr( "129.15.78.114" ); > >> int iRet = connect(s, (struct sockaddr *)&farAddr, sizeof > >> farAddr); > >> > >> //sctp_bindx > >> struct sockaddr_in my2ndAddr; > >> memset(&my2ndAddr, 0, sizeof my2ndAddr); > >> my2ndAddr.sin_len = sizeof my2ndAddr; > >> my2ndAddr.sin_family = AF_INET; > >> my2ndAddr.sin_port = htons(5060); > >> my2ndAddr.sin_addr.s_addr = inet_addr("129.15.78.126"); > >> > >> iRet = sctp_bindx(s,(struct > >> sockaddr*)&my2ndAddr,1,SCTP_BINDX_ADD_ADDR); > >> > >> ------------------------------------------ > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >> > > > > > > > -- > Randall Stewart > NSSTG - Cisco Systems Inc. > 803-345-0369 803-317-4952 (cell) > From owner-freebsd-net@FreeBSD.ORG Sat Sep 8 07:47:08 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73F5F16A417 for ; Sat, 8 Sep 2007 07:47:08 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 080FD13C428 for ; Sat, 8 Sep 2007 07:47:07 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from [192.168.0.199] (unknown [10.0.0.126]) by netasq.netasq.com (Postfix) with ESMTP id 598FC1B623; Sat, 8 Sep 2007 09:47:06 +0200 (CEST) In-Reply-To: <09k3e3d46bb5br07r883sdokn0j7qlkp0c@4ax.com> References: <09k3e3d46bb5br07r883sdokn0j7qlkp0c@4ax.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02D34D73-5AD4-4B8E-88B6-313FBEBB5E98@netasq.com> Content-Transfer-Encoding: 7bit From: Fabien THOMAS Date: Sat, 8 Sep 2007 09:46:56 +0200 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.752.3) Cc: Mike Tancsa Subject: Re: new version of polling for FreeBSD 6.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Sep 2007 07:47:08 -0000 > Hi, > This is really interesting work! Reading the pdf file, it > seems forwarding performance on 6 and 7 is still much lower than > RELENG_4 ? is that correct ? > > ---Mike Thanks, Yes it is still slower but as you can see in the graph (programming cost) just adding a mutex drop the rate and we have some on the forwarding path. We have beaten FreeBSD 4.x with pollng on 2 core with the best throughput at 7089Mb/s but only when the test last 10s => maybe periodic task that get some CPU time. One really interesting things is that FreeBSD 7.x can have great performance: It performs slower than FreeBSD 6.x when using one CPU (4437 vs 5017) but better when using 2 CPU (5214 vs 5026). While reading the pdf i've discovered a mistake in the loss percentage: it is 0.001% and not 0.0001%. Fabien >> >> You can find a summary of all my tests and the source code at the >> following address: >> http://www.netasq.com/opensource/pollng-rev1-freebsd.tgz >> >> Feel free to ask more detailed information if necessary and report >> any bugs / comments. >> >> Fabien >> >> >> _______________________________________________ >> 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 Sat Sep 8 08:08:24 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E681416A41B for ; Sat, 8 Sep 2007 08:08:24 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id A56CD13C459 for ; Sat, 8 Sep 2007 08:08:24 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from [192.168.0.199] (unknown [10.0.0.126]) by netasq.netasq.com (Postfix) with ESMTP id DFCE81B6C0; Sat, 8 Sep 2007 10:08:22 +0200 (CEST) In-Reply-To: <46E1D937.8040600@freebsd.org> References: <09k3e3d46bb5br07r883sdokn0j7qlkp0c@4ax.com> <46E1D937.8040600@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <35F0020D-5D6F-4FE0-A787-6D8E5DE59B68@netasq.com> Content-Transfer-Encoding: quoted-printable From: Fabien THOMAS Date: Sat, 8 Sep 2007 10:08:13 +0200 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.752.3) Cc: Andre Oppermann , Mike Tancsa Subject: Re: new version of polling for FreeBSD 6.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Sep 2007 08:08:25 -0000 Le 8 sept. 07 =E0 01:05, Andre Oppermann a =E9crit : > Mike Tancsa wrote: >> On Thu, 6 Sep 2007 15:12:06 +0200, in sentex.lists.freebsd.net you >> wrote: >>> After many years of good services we will stop using FreeBSD 4.x :) >>> During my performance regression tests under FreeBSD 6.2 i've =20 >>> found that polling has lower performance than interrupt. >>> To solve that issue i've rewritten the core of polling to be more =20= >>> SMP ready. >> Hi, >> This is really interesting work! Reading the pdf file, it >> seems forwarding performance on 6 and 7 is still much lower than >> RELENG_4 ? is that correct ? > > Haven't tested RELENG_4 performance in a controlled environment and > thus can't answer the question directly. However using fastforward > on 6 and 7 is key to good performance. Without it you're stuck at > some 150-200kpps, perhaps 300kpps. With it you get to 500-800kpps. Using net.isr.direct is the key success and can get much better =20 forwarding rate (intermediate queue kill the performance). i aggree than using fastforwarding gets another big step because =20 there is a lot less code than on the IP stack: FreeBSD 6.2 using fastforward on 64bytes packets (L3 Mb/s): pollng 1CPU: 156 pollng 2CPU: 123 intr: 144 pollng 1CPU fastfwd: 221 pollng 2CPU fastfwd: 270 intr fastfwd: 211 Fabien > > --=20 > Andre > >> ---Mike >>> You can find a summary of all my tests and the source code at =20 >>> the following address: >>> http://www.netasq.com/opensource/pollng-rev1-freebsd.tgz >>> >>> Feel free to ask more detailed information if necessary and =20 >>> report any bugs / comments. >>> >>> Fabien >>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-=20 >>> unsubscribe@freebsd.org" >> -------------------------------------------------------- >> Mike Tancsa, Sentex communications http://www.sentex.net >> Providing Internet Access since 1994 >> mike@sentex.net, (http://www.tancsa.com) >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-=20 >> unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Sat Sep 8 08:54:07 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C11716A419; Sat, 8 Sep 2007 08:54:07 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.freebsd.org (Postfix) with ESMTP id 13BC813C459; Sat, 8 Sep 2007 08:54:06 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from [192.168.0.199] (unknown [10.0.0.126]) by netasq.netasq.com (Postfix) with ESMTP id 5E03E1B6C0; Sat, 8 Sep 2007 10:54:05 +0200 (CEST) In-Reply-To: <46E1D937.8040600@freebsd.org> References: <09k3e3d46bb5br07r883sdokn0j7qlkp0c@4ax.com> <46E1D937.8040600@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50A25602-5658-4AC3-98B5-CB1767CE6163@netasq.com> Content-Transfer-Encoding: 7bit From: Fabien THOMAS Date: Sat, 8 Sep 2007 10:53:55 +0200 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.752.3) Cc: Andre Oppermann , Mike Tancsa Subject: Re: new version of polling for FreeBSD 6.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Sep 2007 08:54:07 -0000 > Haven't tested RELENG_4 performance in a controlled environment and > thus can't answer the question directly. However using fastforward > on 6 and 7 is key to good performance. Without it you're stuck at > some 150-200kpps, perhaps 300kpps. With it you get to 500-800kpps. > > To show that pps is mainly related to CPU freq (with high end component): FreeBSD 6.2, packet size is 64bytes and value L3 Mb/s between the two only CPU change. Xeon Woodcrest 2.33 3.00 1,287 pollng 1CPU: 210 257 1,224 pollng 2CPU: 329 396 1,204 pollng 1CPU fastfwd: 291 364 1,251 pollng 2CPU fastfwd: 455 536 1,178 warn: this is not the same hardware than in the pdf. From owner-freebsd-net@FreeBSD.ORG Sat Sep 8 10:00:33 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA7F416A46B for ; Sat, 8 Sep 2007 10:00:33 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id 290E613C46E for ; Sat, 8 Sep 2007 10:00:32 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 17913 invoked by uid 1001); 8 Sep 2007 10:00:31 -0000 Date: Sat, 8 Sep 2007 12:00:31 +0200 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20070908100031.GA4563@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org References: <46E1D74D.3070409@freebsd.org> <20070907235622.C410D5B58@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070907235622.C410D5B58@mail.bitblocks.com> User-Agent: Mutt/1.5.12-2006-07-14 Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Sep 2007 10:00:33 -0000 On Fri, Sep 07, 2007 at 04:56:22PM -0700, Bakul Shah wrote: > > This is not the case. Flood ping doesn't reach the limit in any > > way. Have a look at the ping man page and flood ping description. > > Ah yes, I was forgetting about the strict synchrony. > > > Stock FreeBSD 6.2 or 7.0 can easily do 500kpps with good network > > cards and fastforwarding enabled. On a dual-Opteron 2.6GHz with > > PCI-X Intel and Broadcom network cards I've done 800kpps in-out. > > What is the throughput when fastforwarding is not used and > packets go to different destinations? Note that typically > fastforwarding does not help much on a router since only one > route is cached. Wrong. Fastforwarding does not cache routes, it is more a process-to- completion frowarding bypassing a lot of unneeded code. > > > > Listen to what Louis Mamakos said! Use FreeBSD primarily for > > > the control plane. May be there are NICs where you can > > > offload some packet forwarding.... But that is a substantial > > > change to FreeBSD. Or live with what FreeBSD can do on a > > > given box. > > > > There are no NICs known that can do packet forwarding offload. > > And neither is there support in FreeBSD for that. You're probably > > confusing this with checksum offloading or TSO (TCP segmentation > > offloading) which isn't an issue with packet forwarding at all. > > Indeed. That is why I said "that is a substantial change to > FreeBSD"! But even offloading checksum can help as the CPU > has less to do. > Wrong. A router only needs to check and update the IPv4 checksum and doing that can be done in a few simple instructions. There is no need to look at the TCP or UDP checksum. So in the end checksum offloading has little effect on forwarding performance. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Sat Sep 8 15:30:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5530016A417 for ; Sat, 8 Sep 2007 15:30:01 +0000 (UTC) (envelope-from daffy@xview.net) Received: from mail.oav.net (mail.oav.net [193.218.105.18]) by mx1.freebsd.org (Postfix) with ESMTP id 00EFF13C468 for ; Sat, 8 Sep 2007 15:30:00 +0000 (UTC) (envelope-from daffy@xview.net) Received: from localhost (localhost [127.0.0.1]) by mail02.oav.net (Postfix) with ESMTP id 08C563F441; Sat, 8 Sep 2007 17:19:44 +0200 (CEST) (envelope-from daffy@xview.net) X-Virus-Scanned: by amavisd-new at mail02.oav.net Received: from mail02.oav.net ([127.0.0.1]) by localhost (mail02.oav.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id HxLssib72-MY; Sat, 8 Sep 2007 17:19:43 +0200 (CEST) Received: from [192.168.0.10] (ble59-1-82-66-131-119.fbx.proxad.net [82.66.131.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail02.oav.net (Postfix) with ESMTP id 4320D3F443; Sat, 8 Sep 2007 17:19:43 +0200 (CEST) (envelope-from daffy@xview.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <89A69741-1961-431D-A102-4AC89411A40B@xview.net> Content-Transfer-Encoding: quoted-printable From: Olivier Warin Date: Sat, 8 Sep 2007 17:17:56 +0200 To: Fabien THOMAS X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org, Suphathorn RAMABUTR , Luigi Rizzo Subject: Re: new version of polling for FreeBSD 6.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Sep 2007 15:30:01 -0000 Le 6 sept. 07 =E0 15:12, Fabien THOMAS a =E9crit : > Hi, > > After many years of good services we will stop using FreeBSD 4.x :) > During my performance regression tests under FreeBSD 6.2 i've found =20= > that polling has lower performance than interrupt. > To solve that issue i've rewritten the core of polling to be more =20 > SMP ready. > > You can find a summary of all my tests and the source code at the =20 > following address: > http://www.netasq.com/opensource/pollng-rev1-freebsd.tgz > > Feel free to ask more detailed information if necessary and report =20 > any bugs / comments. Hello Fabien, 1- I have noticed you are not using GENERIC config file, can you =20 provide us more information on how your KERNCONF differs from =20 GENERIC ? I am pretty sure you have removed all the debug OPTIONs =20 from the kernel, isn't it ? 2- Did you get a chance to try Jumbo Frames and evaluate jumbo mbufs =20 (I never success to make them work for me, did someone had more =20 chance ?). In any cases, PPS values are important for such tests. Andre is right, with Fast Forward you get the best perfs for such test. 3- Did you monitor the DUT to see where CPU cycles were spend in each =20= test ? 4- Have you considered measuring the time it takes for an interrupt =20 to be handled and processed by the kernel Bottom/Top Half and ISR ? [1] 5- When I have performed some test using a Spirent SmartBits =20 (SmartFlow) last summer I got the following results [2]. (For =20 comparison purposes) 6- In the test with Spirent Avalanche, you are using Lighttpd as =20 webserver, did you enable kqueue ? how many workers ? You are using HTTP 1.0 wo Keep-Alive, what was your net.inet.tcp.msl =20 MIB's value ? 7- Polling is known to introduce higher latency, I would expect its =20 benefits to be less in 7-CURRENT compared to 6.x since (Scott ?) a =20 FAST INTR Handler has been introduced around a year ago. Nonetheless, =20= what you report sounds like a perf regression... Have you filled a =20 PR ? Luigi might have a good explaination here. :-D 8- Lock profiling information were obtanied through KTR ? 9- I was wondering if you have explored Intr CPU affinity [3] and IRQ =20= Swizzling [4] ? Thanks for your efforts and your valuable contribution, best regards, /Olivier [1] http://xview.net/papers/interrupt_latency_scheduler/ (WARNING: =20 Never find the time to finish that doc and publish it) && http://xview.net/research/RTBench/ [2] http://xview.net/papers/jumbo_mbufs_freebsd/ [3] http://www.intel.com/cd/ids/developer/asmo-na/eng/188935.htm?prn=3DY [4] http://download.intel.com/design/chipsets/applnots/31433702.pdf -- Olivier Warin From owner-freebsd-net@FreeBSD.ORG Sat Sep 8 19:37:00 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86E9916A41A; Sat, 8 Sep 2007 19:37:00 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (unknown [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id 4177D13C461; Sat, 8 Sep 2007 19:37:00 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1IU670-0003S6-0W; Sat, 08 Sep 2007 15:36:58 -0400 Date: Sat, 8 Sep 2007 15:36:57 -0400 From: Gary Palmer To: Christopher Arnold Message-ID: <20070908193657.GC8194@in-addr.com> Mail-Followup-To: Christopher Arnold , Andre Oppermann , Bakul Shah , freebsd-net@freebsd.org, Kirc Gover References: <20070907200809.CB6B05B58@mail.bitblocks.com> <46E1D74D.3070409@freebsd.org> <20070908012111.C66700@chrishome.localnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070908012111.C66700@chrishome.localnet> Cc: Bakul Shah , freebsd-net@freebsd.org, Kirc Gover , Andre Oppermann Subject: Re: OS choice for an edge router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Sep 2007 19:37:00 -0000 On Sat, Sep 08, 2007 at 01:32:25AM +0200, Christopher Arnold wrote: > > > On Sat, 8 Sep 2007, Andre Oppermann wrote: > > >There are no NICs known that can do packet forwarding offload. > >And neither is there support in FreeBSD for that. You're probably > >confusing this with checksum offloading or TSO (TCP segmentation > >offloading) which isn't an issue with packet forwarding at all. > > > This was my understanding to until the original poster inspired be to > google yet another time for a card supporting packet forwarding offload. > > To my suprise i found one! > > http://netfpga.org/ This might also prove a good routing platform: http://www.tilera.com/products/boards.php From owner-freebsd-net@FreeBSD.ORG Sat Sep 8 20:55:04 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00E8916A418 for ; Sat, 8 Sep 2007 20:55:04 +0000 (UTC) (envelope-from thomas.fabien@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA7213C465 for ; Sat, 8 Sep 2007 20:55:02 +0000 (UTC) (envelope-from thomas.fabien@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so591412nfd for ; Sat, 08 Sep 2007 13:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:content-type:message-id:cc:reply-to:from:subject:date:to:x-mailer; bh=irNEBwTUPFswlQ89PWKGD0Dgp7Nv0mYBoh7U/otlQt8=; b=R6fCTqy6qLpmNvQddyRZ4pIiEnEcZnei6ZbrFHhuGdmMqtv0KFmAYlKWcWy73x3JSQD0VUdLLYVHYW5+2f3Uib2r7Szb/XlxNAc3JwIcuj4inuGjgYVsu8vC5nTFRuPB6IpdNdE75zhrYSZiw7fD220/1NTPqUAiYXC4XUi5CiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:content-type:message-id:cc:reply-to:from:subject:date:to:x-mailer; b=fL7PlTiJtau/A13VAsFYtzEZJpSVcH0XTveO0L1FWRTjARFLpnkcYML0DXcQjcoHsubowgooVcXCLYgBDJgi51jU5rkQUKdTKkW9NBfsHlhZOVJ4pG7/srUv5QBbzpIalObLxd61ihUedi6LObKiTaKfRO2d0k0fDv4/PnBX6zM= Received: by 10.86.65.11 with SMTP id n11mr2440892fga.1189283236715; Sat, 08 Sep 2007 13:27:16 -0700 (PDT) Received: from ?192.168.0.1? ( [85.68.82.61]) by mx.google.com with ESMTPS id f8sm2492420nfh.2007.09.08.13.27.10 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 08 Sep 2007 13:27:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <6DED4888-AE5E-4BF6-85CF-6968ED7BEBF4@gmail.com> From: Fabien THOMAS Date: Sat, 8 Sep 2007 22:27:10 +0200 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: daffy@xview.net Subject: Re: new version of polling for FreeBSD 6.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fabien.thomas@netasq.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 20:55:04 -0000 > > Hello Fabien, Hello :) > > 1- I have noticed you are not using GENERIC config file, can you > provide us more information on how your KERNCONF differs from > GENERIC ? > I am pretty sure you have removed all the debug OPTIONs from the > kernel, isn't it ? It's a GENERIC kernel conf with polling and SMP activated. With FreeBSD 7.x i've removed witness and invariant. > > 2- Did you get a chance to try Jumbo Frames and evaluate jumbo > mbufs (I never success to make them work for me, did someone had > more chance ?). > In any cases, PPS values are important for such tests. Andre is > right, with Fast Forward you get the best perfs for such test. No i havent done any jumbo frame test, maybe on next try. Yes fastforward is better but my goal was to stress the IP stack so i've not integrated the fastforward result in the pdf. (but you can find some results in my reply to Andre). > > 3- Did you monitor the DUT to see where CPU cycles were spend in > each test ? Not during the real test. Profiling using hwpmc and LOCK_PROFILING have been done under the same condition but ignoring results. hwpmc use the callgraph patch published by Joseph Koshy. > > 4- Have you considered measuring the time it takes for an interrupt > to be handled and processed by the kernel Bottom/Top Half and ISR ? > [1] No > > 5- When I have performed some test using a Spirent SmartBits > (SmartFlow) last summer I got the following results [2]. (For > comparison purposes) It's really difficult to compare. For all my test i'm always using a reference hardware (not too powerful to be in the range of test tools). > > 6- In the test with Spirent Avalanche, you are using Lighttpd as > webserver, did you enable kqueue ? how many workers ? > You are using HTTP 1.0 wo Keep-Alive, what was your > net.inet.tcp.msl MIB's value ? The goal of the application test was simple: i've pollng that works better than interrupt in all forwarding case but is my socket application will works better ? For that i've just installed the port with the default config (log disabled, default is one worker). The result on this test show that polling is a great benefit to network application vs interrupt (near than two times more connections per seconds). > > 7- Polling is known to introduce higher latency, I would expect its > benefits to be less in 7-CURRENT compared to 6.x since (Scott ?) > a FAST INTR Handler has been introduced around a year ago. Yes it cost more in term of packet latency (where FreeBSD 4.11 was better than 6.x / 7.x in all mode) but under high pps with interrupt the DUT is unresponsive (ithread, filter, em fastintr). > Nonetheless, what you report sounds like a perf regression...Have > you filled a PR ? Luigi might have a good explaination here. :-D For us polling have always worked better than interrupt under FreeBSD 4.x, under FreeBSD 6.x it is not the case and under one of my application benchmark you can see that it really have a problem to sustain the load. Behind the new model there is more than a regression fix: I think it will scale better to SMP and provide a good acceleration for packet inspection. > > 8- Lock profiling information were obtanied through KTR ? no: LOCK_PROFILING > > 9- I was wondering if you have explored Intr CPU affinity [3] and > IRQ Swizzling [4] ? No, but one idea is the hybrid mode used under Solaris (intr when load is low and polling). > > Thanks for your efforts and your valuable contribution, best regards, > /Olivier Kind regards, Fabien > > [1] http://xview.net/papers/interrupt_latency_scheduler/ (WARNING: > Never find the time to finish that doc and publish it) && > http://xview.net/research/RTBench/ > > [2] http://xview.net/papers/jumbo_mbufs_freebsd/ > > [3] http://www.intel.com/cd/ids/developer/asmo-na/eng/188935.htm? > prn=3DY > > [4] http://download.intel.com/design/chipsets/applnots/31433702.pdf > -- > Olivier Warin > > > >