From owner-freebsd-net@FreeBSD.ORG Sun Sep 30 20:32:38 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 1F1FF16A419; Sun, 30 Sep 2007 20:32:38 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 968C413C45B; Sun, 30 Sep 2007 20:32:37 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.182.125] (helo=[192.168.4.160]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1Ic5Su1jY2-0007ds; Sun, 30 Sep 2007 22:32:36 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sun, 30 Sep 2007 22:32:16 +0200 User-Agent: KMail/1.9.7 X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. X-Provags-ID: V01U2FsdGVkX19+Jgt/GVDJMqEZDkR7wTnv20nSGu8fIQ+Agqm wUQhudXVGl1liPGzjYxf4K/cVUGgAVCMmWeEo3Fu1LzXxy/MZj 26EsZ9daqelcOlj2Hvt0sdTIvGC5IWSu0ZETql1MLM= Cc: freebsd-current@freebsd.org Subject: libpcap/tcpdump update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Sep 2007 20:32:38 -0000 --nextPart1458859.OcpWg9xcps Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I'd like to get some eyes on http://people.freebsd.org/~mlaier/tcpdump/ in= =20 order to get $subj into the tree. Let me know if you find any problems. =20 Thanks. This should also take care of bin/116610, by the way. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1458859.OcpWg9xcps Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHAAfiXyyEoT62BG0RAvfLAJ9ss3DmmYb6Z8JgwGqW90j6Ii7ZJgCfSnQy Ebsd5PCjftBkDpQBpkkh33k= =mzvE -----END PGP SIGNATURE----- --nextPart1458859.OcpWg9xcps-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 30 20:36: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 B3DCF16A41A for ; Sun, 30 Sep 2007 20:36:48 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp808.mail.ird.yahoo.com (smtp808.mail.ird.yahoo.com [217.146.188.68]) by mx1.freebsd.org (Postfix) with SMTP id 1B07313C447 for ; Sun, 30 Sep 2007 20:36:47 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 16245 invoked from network); 30 Sep 2007 20:28:41 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@217.44.142.35 with plain) by smtp808.mail.ird.yahoo.com with SMTP; 30 Sep 2007 20:28:41 -0000 X-YMail-OSG: 4dpf_sgVM1nRo8u2UaJUvU8z9M8A7LCHL1yNQRTb0p3n4.FkStDoe2sw99AolaOGSNHYRnugpm7mwBLdLMc53RY- Message-ID: <47001604.6030504@tomjudge.com> Date: Sun, 30 Sep 2007 22:32:52 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Oleg Bulyzhin References: <20070926060241.GA3945@lath.rinet.ru> In-Reply-To: <20070926060241.GA3945@lath.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: new mbuf flag proposal X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Sep 2007 20:36:48 -0000 Oleg Bulyzhin wrote: > Hi all. > > Recently, i discovered following problem (though it was already discussed, see > http://freebsd.rambler.ru/bsdmail/freebsd-ipfw_2006/msg00491.html): > pfil handlers (like ipfw or pf) sometime need to create packets (like tcp rst > or icmp errors). In order to avoid loops M_SKIP_FIREWALL flag is used. > Unfortunately, this behaviour is not always correct. > There are configurations when you need to reinject such packets into pfil(4) > handlers (in order to translate them using NAT or apply routing policy > or divert them somewhere, etc). In my case i had to modify kernel > in order to translate tcp keepalive packets(generated by ipfw) using pfnat. > > I have a proposal how to solve this: > 1) Introduce new mbuf flag, something like M_PFIL_CREATED, which should be > used to mark packets created by pfil handler. If packet is not supposed > to reenter pfil handlers M_SKIP_FIREWALL can be used instead. > 2) When pfil handler generate packet it should be marked either with > M_SKIP_FIREWALL or M_PFIL_CREATED. In latter case, pfil handler should add > mbuf_tag for distinguishing source of M_PFIL_CREATED flag. > I only really have one comment, surely all packets created in pfil handlers should have M_PFIL_CREATED set, and those that should not pass through the firewall should have M_SKIP_FIREWALL set in addition? Just my 2p Tom > So, for packet creation code should be like this: > > m->m_flags |= M_PFIL_CREATED; > mtag = m_tag_alloc(MTAG_PFIL_CREATED, PFIL_IPFW, 0, M_NOWAIT); > if (mtag) { > m_tag_prepend(m, mtag); > } else { > goto drop_pkt; > } > > at the beginning of pfil handler we should have something like this: > > int dont_emit_pkt = 0; > > if (m->m_flags & M_PFIL_CREATED) { > dont_emit_pkt = 1; > mtag = m_tag_locate(m, MTAG_PFIL_CREATED, PFIL_IPFW, NULL); > if (mtag) { /* pkt was created by myself */ > /* my own packet, handle it with care. */ > goto specal_handler; > } else { /* pkt was created by other pfil(4) handler */ > > /* do normal processing but do not emit new packets. */ > goto normal_handler; > } > } > > This functionality can be archived with mbuf_tag only (without new mbuf flag), > but it would be ineffective: > calling m_tag_locate() (unsuccessful most of the time!) for every packet is > rather expensive. > > What do you think about this? > From owner-freebsd-net@FreeBSD.ORG Mon Oct 1 07:43:04 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 E746916A419; Mon, 1 Oct 2007 07:43:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 6B45813C45B; Mon, 1 Oct 2007 07:43:03 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9176Yv2019092; Mon, 1 Oct 2007 17:06:34 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9176YZh019091; Mon, 1 Oct 2007 17:06:34 +1000 (EST) (envelope-from peter) Date: Mon, 1 Oct 2007 17:06:34 +1000 From: Peter Jeremy To: Kris Kennaway Message-ID: <20071001070634.GO1752@turion.vk2pj.dyndns.org> References: <46FEB462.4040307@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0" Content-Disposition: inline In-Reply-To: <46FEB462.4040307@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: net@freebsd.org Subject: Re: localhost connections showing source address 0.0.0.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 07:43:05 -0000 --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Sep-29 22:24:02 +0200, Kris Kennaway wrote: >Going back at least as far as January 2007 some of the package build=20 >machines have occasionally experienced a problem where a fetch(1) via a=20 >localhost:3128 squid proxy are denied because squid sees the connection as= =20 >having a source address of 0.0.0.0 instead of 127.0.0.1. Can you capture source port as well (squid.conf says %>p will do this)? Is there any correlation with the source port or package being fetched? Is it consistent? --=20 Peter Jeremy --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHAJx5/opHv/APuIcRAs5pAKCE4RXSEIm7Qh4VEhtwOLxeoY3YVACggFsk ajtGI1u4JiIyNBw7r5ji3Zk= =VVZ6 -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 1 07:55:30 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 99F1316A469 for ; Mon, 1 Oct 2007 07:55:30 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id E96D213C44B; Mon, 1 Oct 2007 07:55:28 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4700A7F3.7060206@FreeBSD.org> Date: Mon, 01 Oct 2007 09:55:31 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Peter Jeremy References: <46FEB462.4040307@FreeBSD.org> <20071001070634.GO1752@turion.vk2pj.dyndns.org> In-Reply-To: <20071001070634.GO1752@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: localhost connections showing source address 0.0.0.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 07:55:30 -0000 Peter Jeremy wrote: > On 2007-Sep-29 22:24:02 +0200, Kris Kennaway wrote: >> Going back at least as far as January 2007 some of the package build >> machines have occasionally experienced a problem where a fetch(1) via a >> localhost:3128 squid proxy are denied because squid sees the connection as >> having a source address of 0.0.0.0 instead of 127.0.0.1. > > Can you capture source port as well (squid.conf says %>p will do this)? Thanks, I am tcpdumping for this already but will change squid.conf. > Is there any correlation with the source port or package being fetched? > Is it consistent? There is no consistency, repeating the same fetch will work. It's only happening on something like 0.002% of all squid connections. Kris From owner-freebsd-net@FreeBSD.ORG Mon Oct 1 11:08: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 8447716A4CE for ; Mon, 1 Oct 2007 11:08:35 +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 64AFF13C4A8 for ; Mon, 1 Oct 2007 11:08:35 +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 l91B8Zdu064547 for ; Mon, 1 Oct 2007 11:08:35 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l91B8YC8064543 for freebsd-net@FreeBSD.org; Mon, 1 Oct 2007 11:08:34 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Oct 2007 11:08:34 GMT Message-Id: <200710011108.l91B8YC8064543@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, 01 Oct 2007 11:08:35 -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 o kern/116077 net 6.2-STABLE panic during use of multi-cast networking c o kern/116172 net Network / ipv6 recursive mutex panic o kern/116185 net if_iwi driver leads system to reboot o kern/116186 net can not set wi channel on current o kern/116328 net [bge]: Solid hang with bge interface 24 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 o bin/116643 net [patch] fstat(1): add INET/INET6 socket details as in 15 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 1 23:02:10 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 E171C16A4C7 for ; Mon, 1 Oct 2007 23:02:10 +0000 (UTC) (envelope-from jamie.ostrowski@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6A013C5A5 for ; Mon, 1 Oct 2007 23:01:58 +0000 (UTC) (envelope-from jamie.ostrowski@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so4943555mue for ; Mon, 01 Oct 2007 16:01:56 -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=QviAvRuoMBheSM+AWiILDUAztpqHhpSysHE24JQRQFY=; b=WmVHJlmKE6tUKP8a30sCqbxV/XNZhErbWIiNP9iGBKGJf8wPz38FSljhm0SpSExaelzCYBdwUWHkbOB2DrIDb8wxF1l+fVI4iaJ0MRwYRkyUy7rBGGQuQMsbOSyNOTkkCi7CT7GRyrFPX9StIh53fm3TGCoqMMzG4kBW7x4MEo0= 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=YmqKeIOyjP7lOeBdaDOL8LpA+30VZZcS1q79G5fbOeI6r3Z0ynWC6yN09lLkqubs08Rb50/z8ouwUfHrRXJu+qBajkOCyT9NByXsmIuVJgLiQabmRo91/S/AGKpaoCRlqnTUXQu92HHWhYCp4Nm3lokHgimeRdKTL1R0PY2vHyo= Received: by 10.82.165.13 with SMTP id n13mr17022625bue.1191278080725; Mon, 01 Oct 2007 15:34:40 -0700 (PDT) Received: by 10.82.161.2 with HTTP; Mon, 1 Oct 2007 15:34:40 -0700 (PDT) Message-ID: <29ae62fc0710011534u7b14d4cdp290c537b33ce79da@mail.gmail.com> Date: Mon, 1 Oct 2007 17:34:40 -0500 From: "Jamie Ostrowski" 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: Too many TIME_WAIT connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Oct 2007 23:02:11 -0000 Hello - I've got a mailserver running FreeBSD 4.11 and Sendmail 8.13 that has been running as a mailserver for a couple of years without any load/connection problems. Here are my memory stats: Mem: 71M Active, 265M Inact, 96M Wired, 24M Cache, 60M Buf, 36M Free Swap: 2048M Total, 760K Used, 2047M Free Then all of a sudden we started experiencing dropped connections even though the load average is generally around 2.0 or less. I found the problem today: there are currently 1300 socket connections suspended at status TIME_WAIT on the incoming smtp port. I checked some of my kernel settings: kern.ipc.somaxconn = 128 net.inet.tcp.msl: 30000 I suspect this is a dos attack: they're just opening these connections, and then let them hang there and they don't close them, so they just build up and the machine rejects new connections. Based on my configuration, does anyone have some suggestions on how I might tweak the system to overcome this (apparent?) DOS attack? Many thanks, - Jamie From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 00:07: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 5B83816A498 for ; Tue, 2 Oct 2007 00:07: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 62D0513C44B for ; Tue, 2 Oct 2007 00:07:55 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 2A17B1A4D7E; Mon, 1 Oct 2007 17:07:55 -0700 (PDT) Date: Mon, 1 Oct 2007 17:07:55 -0700 From: Alfred Perlstein To: Jamie Ostrowski Message-ID: <20071002000755.GQ53439@elvis.mu.org> References: <29ae62fc0710011534u7b14d4cdp290c537b33ce79da@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29ae62fc0710011534u7b14d4cdp290c537b33ce79da@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Too many TIME_WAIT connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Oct 2007 00:07:55 -0000 * Jamie Ostrowski [071001 16:02] wrote: > Hello - > > I've got a mailserver running FreeBSD 4.11 and Sendmail 8.13 that has > been running as a mailserver for a couple of years without any > load/connection problems. Here are my memory stats: > Mem: 71M Active, 265M Inact, 96M Wired, 24M Cache, 60M Buf, 36M Free > Swap: 2048M Total, 760K Used, 2047M Free > > Then all of a sudden we started experiencing dropped connections even though > the load average is generally around 2.0 or less. > > I found the problem today: there are currently 1300 socket connections > suspended at status TIME_WAIT on the incoming smtp port. > > I checked some of my kernel settings: > > kern.ipc.somaxconn = 128 > net.inet.tcp.msl: 30000 > > I suspect this is a dos attack: they're just opening these connections, > and then let them hang there and they don't close them, so they just build > up and the machine rejects new connections. > > Based on my configuration, does anyone have some suggestions on how I > might tweak the system to overcome this (apparent?) DOS attack? You can tweak msl, but it probably makes more sense to use some form of firewall, ipfw, ipfilter, pf, etc on the box. you can use netstat to see the remote addresses, just block them. -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 01:04:37 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 0F5A216A41A for ; Tue, 2 Oct 2007 01:04:37 +0000 (UTC) (envelope-from jamie.ostrowski@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id A81F913C4A5 for ; Tue, 2 Oct 2007 01:04:36 +0000 (UTC) (envelope-from jamie.ostrowski@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so4973203mue for ; Mon, 01 Oct 2007 18:04:35 -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=1x06RQPfDE6GilzFRZvBdZAfNGwvOyxHZctIf/QpT4Y=; b=hCh5R0ItWOZB02Gkfd49/UIQDOsfZ7itSeQ9tVlGCHen0VO/hGq7Rrfo9Vr9Y/7z5ETyas6RCd0dX/DyHfaOsk7/2YNzTZtyzOoiBBXb9ZmAmAv0Nb7a5t1PZh2IQTkifaVPV8D1MF5Q39luBUsXa/PYdrpdxAbDvsC39IMICBo= 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=QjzK4/gfuaR71DQVP51y5ZTnBUpzBFx1/RKS/M+U+5DKUWgmexDB1Urf//AHEo61YGRYvJ5yAp0xxnCNSuTuBCuGhfn8lf9lQTZSmtznnPr5mK705N8a9ya6CXOUJkT2wZhJkjDS6odERpVsqM1AoGO0u0G9FxuXL9epqdfTmhw= Received: by 10.82.165.13 with SMTP id n13mr17302431bue.1191287074881; Mon, 01 Oct 2007 18:04:34 -0700 (PDT) Received: by 10.82.161.2 with HTTP; Mon, 1 Oct 2007 18:04:34 -0700 (PDT) Message-ID: <29ae62fc0710011804j395815ccy47951aee4e2092a6@mail.gmail.com> Date: Mon, 1 Oct 2007 20:04:34 -0500 From: "Jamie Ostrowski" To: "Alfred Perlstein" In-Reply-To: <20071002000755.GQ53439@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <29ae62fc0710011534u7b14d4cdp290c537b33ce79da@mail.gmail.com> <20071002000755.GQ53439@elvis.mu.org> Cc: freebsd-net@freebsd.org Subject: Re: Too many TIME_WAIT connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Oct 2007 01:04:37 -0000 Thats a good idea, but in this particular arrangement we've firewalled off all other smtp connections except for a certain small range which comes through Postini. All these connections on the machine run through the Postini machines, so we can't firewall them off. Any other suggestions? If not, we'll tweak msl. On 10/1/07, Alfred Perlstein wrote: > * Jamie Ostrowski [071001 16:02] wrote: > > Hello - > > > > I've got a mailserver running FreeBSD 4.11 and Sendmail 8.13 that has > > been running as a mailserver for a couple of years without any > > load/connection problems. Here are my memory stats: > > Mem: 71M Active, 265M Inact, 96M Wired, 24M Cache, 60M Buf, 36M Free > > Swap: 2048M Total, 760K Used, 2047M Free > > > > Then all of a sudden we started experiencing dropped connections even > though > > the load average is generally around 2.0 or less. > > > > I found the problem today: there are currently 1300 socket connections > > suspended at status TIME_WAIT on the incoming smtp port. > > > > I checked some of my kernel settings: > > > > kern.ipc.somaxconn = 128 > > net.inet.tcp.msl: 30000 > > > > I suspect this is a dos attack: they're just opening these connections, > > and then let them hang there and they don't close them, so they just build > > up and the machine rejects new connections. > > > > Based on my configuration, does anyone have some suggestions on how I > > might tweak the system to overcome this (apparent?) DOS attack? > > You can tweak msl, but it probably makes more sense to use some form > of firewall, ipfw, ipfilter, pf, etc on the box. > > you can use netstat to see the remote addresses, just block them. > > -- > - Alfred Perlstein > From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 01:06: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 ACE1D16A420 for ; Tue, 2 Oct 2007 01:06:33 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 9830113C49D for ; Tue, 2 Oct 2007 01:06:33 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so4922852waf for ; Mon, 01 Oct 2007 18:06:33 -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=e6ABkDyif86DR0YiGTdPklw7Xu7XuZxMDt3STQHqC3w=; b=ISJell0uAI3fCMr1s0VGHxpeMsFEecPaRzCrLAgCtNeRg/TuXeCvAJHyifJNE+4IYC+WDVXz83pw/7//wPiTeBjOqPIKLrieH9MSej9d4Sh+SiElUMs3GtMTd3gfED1uv84HuNedjTOrAOjxF976f7gicFJp7Bb/47FWvKp7v8k= 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=fuhqLzSPe8KjrsxjB5H8i7Xms8bwUYn5Sx5Oh4QBmcwgo6ASASB33ZXPux+0Y49XZnRlA+o1wBZmhKMfmREpqVGdo/RyjTBbIn6Wqd6uXGmSbTmLyWCiDyR3ju/G1zfP2wLs/lgVgOf1dQzd0DWw6OxbIXO6cFaiTbEh4v4mwH0= Received: by 10.114.195.19 with SMTP id s19mr1544961waf.1191287192714; Mon, 01 Oct 2007 18:06:32 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Mon, 1 Oct 2007 18:06:32 -0700 (PDT) Message-ID: Date: Mon, 1 Oct 2007 18:06:32 -0700 From: "Kip Macy" To: "Jamie Ostrowski" In-Reply-To: <29ae62fc0710011804j395815ccy47951aee4e2092a6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <29ae62fc0710011534u7b14d4cdp290c537b33ce79da@mail.gmail.com> <20071002000755.GQ53439@elvis.mu.org> <29ae62fc0710011804j395815ccy47951aee4e2092a6@mail.gmail.com> Cc: freebsd-net@freebsd.org, Alfred Perlstein Subject: Re: Too many TIME_WAIT connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Oct 2007 01:06:33 -0000 On 10/1/07, Jamie Ostrowski wrote: > Thats a good idea, but in this particular arrangement we've > firewalled off all other smtp connections except for a certain small > range which comes through Postini. All these connections on the > machine run through the Postini machines, so we can't firewall them > off. If all your connections are local you can safely reduce the MSL. -Kip > > Any other suggestions? If not, we'll tweak msl. > > On 10/1/07, Alfred Perlstein wrote: > > * Jamie Ostrowski [071001 16:02] wrote: > > > Hello - > > > > > > I've got a mailserver running FreeBSD 4.11 and Sendmail 8.13 that has > > > been running as a mailserver for a couple of years without any > > > load/connection problems. Here are my memory stats: > > > Mem: 71M Active, 265M Inact, 96M Wired, 24M Cache, 60M Buf, 36M Free > > > Swap: 2048M Total, 760K Used, 2047M Free > > > > > > Then all of a sudden we started experiencing dropped connections even > > though > > > the load average is generally around 2.0 or less. > > > > > > I found the problem today: there are currently 1300 socket connections > > > suspended at status TIME_WAIT on the incoming smtp port. > > > > > > I checked some of my kernel settings: > > > > > > kern.ipc.somaxconn = 128 > > > net.inet.tcp.msl: 30000 > > > > > > I suspect this is a dos attack: they're just opening these connections, > > > and then let them hang there and they don't close them, so they just build > > > up and the machine rejects new connections. > > > > > > Based on my configuration, does anyone have some suggestions on how I > > > might tweak the system to overcome this (apparent?) DOS attack? > > > > You can tweak msl, but it probably makes more sense to use some form > > of firewall, ipfw, ipfilter, pf, etc on the box. > > > > you can use netstat to see the remote addresses, just block them. > > > > -- > > - 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" > From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 01:56: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 A488516A417; Tue, 2 Oct 2007 01:56:21 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id 0D09213C474; Tue, 2 Oct 2007 01:56:21 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.16.14] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1IcWzj2ULf-0002Bv; Tue, 02 Oct 2007 03:56:19 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Tue, 2 Oct 2007 03:55:59 +0200 User-Agent: KMail/1.9.7 References: <200709302232.34505.max@love2party.net> In-Reply-To: <200709302232.34505.max@love2party.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2278546.TezuI8gNlU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710020356.10429.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/UPw9sH5rmw6TUtKvTvVjVmP4p1rdon3bhJ+f MMEa+SHhSnH5F12hPC7fiuDLL7PVZlt+stcD4ClMIIbRDTaSsd FcpNZAoVSUu0VqwQMCM/5v1WIlWi1+Tfrwx4YfMncI= Cc: freebsd-current@freebsd.org Subject: Re: libpcap/tcpdump update X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Oct 2007 01:56:21 -0000 --nextPart2278546.TezuI8gNlU Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 30 September 2007, Max Laier wrote: > Hi, > > I'd like to get some eyes on http://people.freebsd.org/~mlaier/tcpdump/ > in order to get $subj into the tree. Let me know if you find any > problems. Thanks. > > This should also take care of bin/116610, by the way. Please refresh - the first version didn't get through buildworld - sorry! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2278546.TezuI8gNlU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHAaU6XyyEoT62BG0RAqsDAJ4vWCuptaoHvKhYaifmaLSpocXSDACbB/UA FAV3scFG3lPXIqXEvklODlk= =OwGA -----END PGP SIGNATURE----- --nextPart2278546.TezuI8gNlU-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 17:33: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 231FA16A419 for ; Tue, 2 Oct 2007 17:33:03 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from cmail.yandex.ru (cmail.yandex.ru [213.180.193.1]) by mx1.freebsd.org (Postfix) with ESMTP id 90D7113C457 for ; Tue, 2 Oct 2007 17:33:02 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [87.250.250.1] (wawa.yandex.ru [87.250.250.1]) by cmail.yandex.ru (8.14.1/8.14.1) with ESMTP id l92HWw5v024329; Tue, 2 Oct 2007 21:33:00 +0400 (MSD) (envelope-from wawa@yandex-team.ru) Message-ID: <470280F6.9070009@yandex-team.ru> Date: Tue, 02 Oct 2007 21:33:42 +0400 From: Vladimir Ivanov Organization: Yandex LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13pre) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.10~pre070720-0etch3+lenny1) MIME-Version: 1.0 To: Jack Vogel References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> In-Reply-To: <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 17:33:03 -0000 Hi, Jack Vogel wrote: > On 8/1/07, Vladimir Ivanov wrote: > >> Hi, >> >> I've just published revision of EM (mainstream RELENG_6 version w/patch) >> driver which is being used in our company to increase network >> performance. The main benefit - significantly better SMP utilization. >> >> http://people.yandex-team.ru/~wawa/em-6.2.9-yandex.tar.gz. >> The driver should be used w/RELENG_6. >> >> Feedbacks welcome. >> > > I will take a look at what you've done as soon as I can, I have a > some issues keeping me busy so it may take me a few days. > Didn't receive feedback still. :-( > Regards, > > Jack > We've just published newest revision of Yandex' em driver at http://people.yandex-team.ru/~wawa/em-6.2.9-yandex-1.15.tar.gz. Main improvement of this version: driver does not use TX interrupts at all. So, interrupt rate reduced significantly. There are also several small bug fixes and tiny patch set explanation in the file README.Yandex. WBR, -- Vladimir Ivanov Network Operations Center OOO "Yandex" t: +7 495 739-7000 f: +7 495 739-7070 @: noc@yandex.net (corporate) wawa@yandex-team.ru (personal) www: www.yandex.ru -- From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 18:18:41 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 2CEA216A41A; Tue, 2 Oct 2007 18:18:41 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E8A4713C465; Tue, 2 Oct 2007 18:18:40 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from freefall.freebsd.org (thompsa@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l92IIeYP089464; Tue, 2 Oct 2007 18:18:40 GMT (envelope-from thompsa@freefall.freebsd.org) Received: (from thompsa@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l92IIe69089460; Tue, 2 Oct 2007 18:18:40 GMT (envelope-from thompsa) Date: Tue, 2 Oct 2007 18:18:40 GMT Message-Id: <200710021818.l92IIe69089460@freefall.freebsd.org> To: thompsa@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: thompsa@FreeBSD.org Cc: Subject: Re: kern/116837: ifconfig tunX destroy: 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: Tue, 02 Oct 2007 18:18:41 -0000 Synopsis: ifconfig tunX destroy: panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: thompsa Responsible-Changed-When: Tue Oct 2 18:15:43 UTC 2007 Responsible-Changed-Why: A core dump isnt needed for this PR, the problem is quite obvious (not not necessarily the solution). http://www.freebsd.org/cgi/query-pr.cgi?pr=116837 From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 20:45: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 0082216A46C for ; Tue, 2 Oct 2007 20:45:25 +0000 (UTC) (envelope-from jamie.ostrowski@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id 66E0A13C457 for ; Tue, 2 Oct 2007 20:45:24 +0000 (UTC) (envelope-from jamie.ostrowski@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so5318063mue for ; Tue, 02 Oct 2007 13:45:23 -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=DAMKCpjQnBNUuwXSWWcwp+bVrG954fzKAFyqLpx7/80=; b=lWSH0SpbWJIegaHDU6GEpi8QYK8v5asxKIsCjGA5wi0pJVcFb1hYqjuJ6tVxXKHbnankN4I0FNowJCS8x8XdkFfEg25/JfP5mVHlgtVrTk6eptvXO/BVBxSstXrqro3ZBmfExaRxvu5qUe+rL113kHzIevyHlGfZeRqlDkSWSVE= 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=IQM66D7GvKdPpEs7wwwn10vd4buiDMQ4Eo/y6jz/t1sUxpJX3btAuYXF90sx+nvDbHKygAX2HijqTX9RVG8fFpe0VBb5qoK4gfxHXUU0g6yRnAqlY1tAL3Lg0mZUDRHJFowibCVDFgHiGgHyEjXnN30i6qE9MAc2XuhWUbPP7NM= Received: by 10.82.126.5 with SMTP id y5mr19836761buc.1191357922737; Tue, 02 Oct 2007 13:45:22 -0700 (PDT) Received: by 10.82.161.2 with HTTP; Tue, 2 Oct 2007 13:45:22 -0700 (PDT) Message-ID: <29ae62fc0710021345o4bf4f7e5xd0594205f9fb9bbc@mail.gmail.com> Date: Tue, 2 Oct 2007 15:45:22 -0500 From: "Jamie Ostrowski" 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: Troubleshooting with netstat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Oct 2007 20:45:25 -0000 I am having a difficult time interpreting the output of netstat, and I wonder if anyone can help shed some light on the netstat man page and help me interpret the results I'm getting. If I run netstat -al -p tcp I got a long list (810 entries) of network connections. 606 of these are at TIME_WAIT status. Since I was getting network connections, I assumed that due to the above output from netstat that the TIME_WAIT connections were filling my network buffer queues. So, I tried to increase the size of the queues, and limit the expiration time on the connections: sysctl kern.ipc.somaxconn=1024 (was 128) sysctl net.inet.tcp.msl=15000 (was 30000) The whole idea was to open up the size of the connection queue and allow more tcp connections to come in while at the same time limiting the amount of time they hung around so the older ones would leave the queue faster. Strangely, I my machine is STILL dropping approx 20% of my connections. How can I view the queue with netstat? What I'd like to know is how many empty slots I have available for connections at any given point in time. What I want to know is, as I am increasing my somaxconn, is my queue getting bigger? If so, why are connections still being dropped? Strangely, when I run %netstat -L -f inet -p tcp Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/50 localhost.domain tcp4 0/0/50 janus.domain From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 20:58: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 2249716A418 for ; Tue, 2 Oct 2007 20:58:24 +0000 (UTC) (envelope-from jfvogel@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 95BE313C4B2 for ; Tue, 2 Oct 2007 20:58:23 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so3020146nfb for ; Tue, 02 Oct 2007 13:58:22 -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=hayyeQzDrGZouhRtHWH2ugKOZHlA6qPloA4JfSvYSow=; b=XAWo0L/4v1AhywEerrNDBVUWwEBSL9J3UN4Qdm4eyXad++epUbiV8CqjA3nPDisoJNd9wwP6IPjyYhtVaet3uE3LVuVcvOYR9fua5DPSjgJ5puZrie5ys2YaMco0N9pztT3FeiTfafGv2YKeOxjerDn/oSEOR23xWrJJGxdsRks= 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=TEYrgbCG4MMxYkxgisPnEF+Db3CAghmd22VLGqdDtEIOmxohLbPx21BM6mOw7o9VrIQulHiP0MX5Ng03npXEGpXMO9IhC6iUbtjaHbRa3H3p6HxUXRb4VIsNPqfOVwt2uHLvINvAgUgLVtsGQmrjjffaGNi5AXEEN9kPFTGqGp4= Received: by 10.86.4.2 with SMTP id 2mr331122fgd.1191358702265; Tue, 02 Oct 2007 13:58:22 -0700 (PDT) Received: by 10.86.100.19 with HTTP; Tue, 2 Oct 2007 13:58:22 -0700 (PDT) Message-ID: <2a41acea0710021358h1940addct3f2b0d3824d04ea3@mail.gmail.com> Date: Tue, 2 Oct 2007 13:58:22 -0700 From: "Jack Vogel" To: "Vladimir Ivanov" In-Reply-To: <470280F6.9070009@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> Cc: "freebsd-net@freebsd.org" Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 20:58:24 -0000 I'm sorry I have not been able to get to this yet, but putting food on the table comes first so the FreeBSD work that Intel pays me for has to come first. Also your driver work is based on a version that is too old to just accept, I am hoping to get the STABLE tree converted to the new shared code that CURRENT has shortly, so whatever good ideas you have, and I'm sure you have many, will need to be made into the new code base. Furthermore, that base is a moving target as I add new hardware support. In the near term I will be taking changes that I did for the 10G Oplin driver, specifically multiqueue/rss and the lock splitting that is in that driver, and putting them back into the Gig driver, but that should go into CURRENT first. My recomendation is to move your work to CURRENT. Regards, Jack On 10/2/07, Vladimir Ivanov wrote: > Hi, > Jack Vogel wrote: > > On 8/1/07, Vladimir Ivanov wrote: > > > >> Hi, > >> > >> I've just published revision of EM (mainstream RELENG_6 version w/patch) > >> driver which is being used in our company to increase network > >> performance. The main benefit - significantly better SMP utilization. > >> > >> http://people.yandex-team.ru/~wawa/em-6.2.9-yandex.tar.gz. > >> The driver should be used w/RELENG_6. > >> > >> Feedbacks welcome. > >> > > > > I will take a look at what you've done as soon as I can, I have a > > some issues keeping me busy so it may take me a few days. > > > Didn't receive feedback still. > :-( > > Regards, > > > > Jack > > > > We've just published newest revision of Yandex' em driver at > http://people.yandex-team.ru/~wawa/em-6.2.9-yandex-1.15.tar.gz. > > Main improvement of this version: driver does not use TX interrupts at > all. So, interrupt rate reduced significantly. > > There are also several small bug fixes and tiny patch set explanation in > the file README.Yandex. > > WBR, > > -- > Vladimir Ivanov > Network Operations Center > OOO "Yandex" > t: +7 495 739-7000 > f: +7 495 739-7070 > @: noc@yandex.net (corporate) > wawa@yandex-team.ru (personal) > www: www.yandex.ru > -- > > From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 22:03:18 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 67A4616A41B for ; Tue, 2 Oct 2007 22:03:18 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from relanium.yandex.ru (relanium.yandex.ru [213.180.193.88]) by mx1.freebsd.org (Postfix) with ESMTP id E217413C4A3 for ; Tue, 2 Oct 2007 22:03:17 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [87.250.227.218] (v3-227-218.yandex.net [87.250.227.218]) by relanium.yandex.ru (8.14.1/8.14.1) with ESMTP id l92M3ERh082679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 02:03:14 +0400 (MSD) (envelope-from wawa@yandex-team.ru) Message-ID: <4702C021.8050304@yandex-team.ru> Date: Wed, 03 Oct 2007 02:03:13 +0400 From: Vladimir Ivanov Organization: Yandex LLC User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Jack Vogel References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> <2a41acea0710021358h1940addct3f2b0d3824d04ea3@mail.gmail.com> In-Reply-To: <2a41acea0710021358h1940addct3f2b0d3824d04ea3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: Dr.Web (R) for Mail Servers on relanium.yandex.ru host X-Antivirus-Code: 100000 Cc: "freebsd-net@freebsd.org" Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 22:03:18 -0000 Jack Vogel wrote: > I'm sorry I have not been able to get to this yet, but putting > food on the table comes first so the FreeBSD work that > Intel pays me for has to come first. Also your driver work > is based on a version that is too old to just accept, I am > hoping to get the STABLE tree converted to the new > shared code that CURRENT has shortly, so whatever good > ideas you have, and I'm sure you have many, will need to > be made into the new code base. Furthermore, that base > is a moving target as I add new hardware support. > > In the near term I will be taking changes that I did for the > 10G Oplin driver, specifically multiqueue/rss and the lock > splitting that is in that driver, and putting them back into > the Gig driver, but that should go into CURRENT first. > > My recomendation is to move your work to CURRENT. We have a little bit different points of view. Your business is code development. Our business is to make several thousand FreeBSD boxes fast and stable. That's why we've limited with OS release selection. But another side of my coin is: we able to test software with a lot of running systems. We plan to deal with CURRENT though. WBR, Vladimir From owner-freebsd-net@FreeBSD.ORG Tue Oct 2 22:44: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 E05B816A418 for ; Tue, 2 Oct 2007 22:44:34 +0000 (UTC) (envelope-from jfvogel@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 7116813C45D for ; Tue, 2 Oct 2007 22:44:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so3044095nfb for ; Tue, 02 Oct 2007 15:44:33 -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=3WtKhqbiRvS0SjdkpF3/o3BtGotLcuG5Uls2TInnkzs=; b=GvLyRXxaUSZDlPESLjeM6jIBPBbBcyk8u0QHr53OwdnJ3Ww47uQ3ckugFhM6nQjmbpzsywxmk/OrdMwyaCfV9jWBIUUIQqYW+d4aqDQm1f6ekS+4dxi0DesYPciWZOs5mzeNY1PXbkQgYLUiN0P+7GPRc9NArqNCzeGYat+rOaE= 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=GbgqkO+d2pr1Sijk2OTn+5BUSie32ZocIWlBC6PZnhmFb0HsScUU5B1PbRA2qyj6wD2/cOBVxQsvW7ad09nBjyuhklZX2/WeXkEC25cZrnCah/dvgt9OB2/6YqU+yQWbQHLbEEzQsgSi9pBwBRypKtVtDq3dVAjer1X+IiFlHSQ= Received: by 10.86.74.15 with SMTP id w15mr393918fga.1191365073042; Tue, 02 Oct 2007 15:44:33 -0700 (PDT) Received: by 10.86.100.19 with HTTP; Tue, 2 Oct 2007 15:44:32 -0700 (PDT) Message-ID: <2a41acea0710021544i694031f9u6ab2ccd157094b3c@mail.gmail.com> Date: Tue, 2 Oct 2007 15:44:32 -0700 From: "Jack Vogel" To: "Vladimir Ivanov" In-Reply-To: <4702C021.8050304@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> <2a41acea0710021358h1940addct3f2b0d3824d04ea3@mail.gmail.com> <4702C021.8050304@yandex-team.ru> Cc: "freebsd-net@freebsd.org" Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 22:44:35 -0000 On 10/2/07, Vladimir Ivanov wrote: > Jack Vogel wrote: > > I'm sorry I have not been able to get to this yet, but putting > > food on the table comes first so the FreeBSD work that > > Intel pays me for has to come first. Also your driver work > > is based on a version that is too old to just accept, I am > > hoping to get the STABLE tree converted to the new > > shared code that CURRENT has shortly, so whatever good > > ideas you have, and I'm sure you have many, will need to > > be made into the new code base. Furthermore, that base > > is a moving target as I add new hardware support. > > > > In the near term I will be taking changes that I did for the > > 10G Oplin driver, specifically multiqueue/rss and the lock > > splitting that is in that driver, and putting them back into > > the Gig driver, but that should go into CURRENT first. > > > > My recomendation is to move your work to CURRENT. > > We have a little bit different points of view. Your business is code > development. Our business is to make several thousand FreeBSD boxes fast > and stable. That's why we've limited with OS release selection. But > another side of my coin is: we able to test software with a lot of > running systems. > > We plan to deal with CURRENT though. I can understand and appreciate that, and in fact, both our tasks are necessary for success. I will try harder to get to your code Vladimir. Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 01:48:38 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 0F70816A418 for ; Wed, 3 Oct 2007 01:48:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id D534213C469 for ; Wed, 3 Oct 2007 01:48:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l931mXSj028618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2007 11:48:35 +1000 Date: Wed, 3 Oct 2007 11:48:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Vladimir Ivanov In-Reply-To: <470280F6.9070009@yandex-team.ru> Message-ID: <20071003111737.U14276@delplex.bde.org> References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 01:48:38 -0000 On Tue, 2 Oct 2007, Vladimir Ivanov wrote: > Main improvement of this version: driver does not use TX interrupts at all. > So, interrupt rate reduced significantly. Polling for anything is a bug IMO. Buggy hardware may work better with it, but em is not buggy :-). For bge, I tune the interrupt moderation parameters to reduce the tx interrupt rate to almost as low as possible without doing polling. The rate is either 1 interrupt per second if the tx is almost inactive or 1 interrupt every 384 packets if the tx is active. -current mistunes these parameters to 150 (microseconds) and 10 (descriptos). Old tuning of 150 and 128 only loses a little compared with 1000000 and 384. (150 gives 6667 interrupts per second under load. This interrupt rate is quite manageable and is about the same rate as you have to use with polling to get the same throughput but lower efficiency as with interrupts. 128 for the descriptor limit causes in a max interrupt rate of only a few hundred per second except with tiny packets, but 10 is excessively small and requires a rate of up to 140000 per second to keep up with tiny packets. 140000 isn't manageable.) em has more/better interrupt parameters with non-broken defaults so I haven't needed to tune them. For bge, I implement dynamic rx interrupt moderation in software where em has it in hardware. 10000 interrupts/second for rx is a good limit. IIRC, em uses 8000 which is a bit low for a max, and is missing a sysctl for easy tuning. Bruce From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 09:03: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 A1CE016A41B for ; Wed, 3 Oct 2007 09:03:39 +0000 (UTC) (envelope-from jan.koukal@fs.cvut.cz) Received: from ns.fsid.cvut.cz (ns.fsid.cvut.cz [147.32.160.4]) by mx1.freebsd.org (Postfix) with ESMTP id 237ED13C4B8 for ; Wed, 3 Oct 2007 09:03:38 +0000 (UTC) (envelope-from jan.koukal@fs.cvut.cz) Received: from mine.fsid.cvut.cz (mine.fsid.cvut.cz [147.32.161.31]) by ns.fsid.cvut.cz (Postfix) with ESMTP id 87E05802D6E5 for ; Wed, 3 Oct 2007 10:44:50 +0200 (CEST) Received: from wts (unknown [10.8.0.30]) by mine.fsid.cvut.cz (Postfix) with ESMTP id 1EEA26D434 for ; Wed, 3 Oct 2007 10:45:15 +0200 (CEST) From: "Jan Koukal" To: Date: Wed, 3 Oct 2007 10:44:50 +0200 Message-ID: <000101c80599$a91722a0$1e00080a@ad.fsid.cvut.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Thread-Index: AcgFmXfl9XqwW+pMQsWz1xp0/tAUZwAACbFA X-CTU-FME-D1-MailScanner: Found to be clean X-CTU-FME-D1-MailScanner-SpamCheck: neni spam, SpamAssassin (not cached, skore=-2.599, vyzaduje 4.2, autolearn=not spam, BAYES_00 -2.60) X-CTU-FME-D1-MailScanner-From: jan.koukal@fs.cvut.cz Subject: Ipsec with SA established, but NO traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Oct 2007 09:03:39 -0000 Hello, I have some strange problem with IpSec. Because,I'm not IpSec guru if you need more information write me. I have IpCop Linux firewall distribution(pluto,iptables) in head office which is terminating 2 VPN. First from Pfsence,Freebsd firewall distribution(racoon,Pf) and second from debian(racoon). This configuration worked well,but on monday without known change and no reboot, traffic is not passing through tunnel. But SA is established and tunnel is UP. I try reboots on all endpoints without success passing traffic through. I didn't make firewall filter changes. I try tcpdump on both endpoints.On IpCop is see that my ICMP packets go through ipsec0 interface,but on Pfsence I see in tcpdump on external interface "Destination host unreachable 50" I think problem will be in PfSense side because second VPN work still well. There's is my configuration: Pfsence ____________________________________________________________________ #Ifconfig rl0: flags=8843 mtu 1500 options=8 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::250:fcff:fea0:20ec%rl0 prefixlen 64 scopeid 0x1 ether 00:50:fc:a0:20:ec media: Ethernet autoselect (100baseTX ) status: active fxp0: flags=8843 mtu 1500 options=b inet 147.20.148.94 netmask 0xfffffffc broadcast 147.20.148.95 inet6 fe80::202:b3ff:fe5b:dbb%fxp0 prefixlen 64 scopeid 0x2 ether 00:02:b3:5b:0d:bb media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 pfsync0: flags=41 mtu 2020 pfsync: syncdev: lo0 maxupd: 128 pflog0: flags=100 mtu 33208 racoon.conf ----------------------------------------------------------------- path pre_shared_key "/var/etc/psk.txt"; path certificate "/var/etc"; remote 88.200.30.145 { exchange_mode main; my_identifier address "147.20.148.94"; peers_identifier address 88.200.30.145; initial_contact on; support_proxy on; proposal_check obey; proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key; dh_group 2; lifetime time 28000 secs; } lifetime time 28000 secs; } sainfo address 192.168.1.0/24 any address 192.168.0.0/24 any { encryption_algorithm 3des; authentication_algorithm hmac_md5; compression_algorithm deflate; pfs_group 2; lifetime time 28000 secs; } spd.conf ----------------------------------------------- spdadd 192.168.1.0/24 192.168.1.1/32 any -P in none; spdadd 192.168.1.1/32 192.168.1.0/24 any -P out none; spdadd 192.168.1.0/24 192.168.0.0/24 any -P out ipsec esp/tunnel/147.20.148.94-88.200.30.145/unique; spdadd 192.168.0.0/24 192.168.1.0/24 any -P in ipsec esp/tunnel/88.200.30.145-147.20.148.94/unique; ------------------------------------------------ #Netstat -sn fastipsec: 0 inbound packets violated process security policy 0 outbound packets violated process security policy 2 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 0 mbufs coalesced during clone 0 clusters coalesced during clone 0 clusters copied during clone 439 mbufs inserted during makespace ah: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets dropped; bad authentication detected 0 packets dropped; bad authentication length 0 possible replay packets detected 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures AH output histogram: hmac-md5: 1615 esp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 packets dropped; bad ilen 0 replay counter wraps 0 packets dropped; bad encryption detected 0 packets dropped; bad authentication detected 0 possible replay packets detected 0 packets in 1615 packets out 0 packets dropped; invalid TDB 0 bytes in 93926 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures ESP output histogram: 3des-cbc: 1615 # setkey -D 147.20.148.94 88.200.30.145 esp mode=tunnel spi=244918196(0x0e9927b4) reqid=16389(0x00004005) E: 3des-cbc 74b233f5 be320ffb 5262340e 7232917b 0b05bace 2368b3e1 A: hmac-md5 6ea864f2 90d31618 39dd48de 89c95bf0 seq=0x00000088 replay=4 flags=0x00000000 state=mature created: Oct 3 09:56:29 2007 current: Oct 3 10:11:38 2007 diff: 909(s) hard: 28000(s) soft: 22400(s) last: Oct 3 10:11:37 2007 hard: 0(s) soft: 0(s) current: 14648(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 136 hard: 0 soft: 0 sadb_seq=1 pid=43956 refcnt=2 88.200.30.145 147.20.148.94 esp mode=tunnel spi=51441993(0x0310f149) reqid=16390(0x00004006) E: 3des-cbc 4c4746d4 c9ba287a 9630340b 500ba432 fc6599af 66778117 A: hmac-md5 a715036a d0dca9ad ccd2e914 fd695b4a seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Oct 3 09:56:29 2007 current: Oct 3 10:11:38 2007 diff: 909(s) hard: 28000(s) soft: 22400(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=43956 refcnt=1 # setkey -DP 192.168.1.0/24[any] 192.168.1.1[any] any in none spid=9 seq=3 pid=44004 refcnt=1 192.168.0.0/24[any] 192.168.1.0/24[any] any in ipsec esp/tunnel/88.200.30.145-147.20.148.94/unique#16390 spid=12 seq=2 pid=44004 refcnt=1 192.168.1.1[any] 192.168.1.0/24[any] any out none spid=10 seq=1 pid=44004 refcnt=1 192.168.1.0/24[any] 192.168.0.0/24[any] any out ipsec esp/tunnel/147.20.148.94-88.200.30.145/unique#16389 spid=11 seq=0 pid=44004 refcnt=1 Tcpdump on external interface on command, ping -S 192.168.1.1 192.168.0.1 10:13:21.140393 IP 147.20.148.94 > 88.200.30.145: ESP(spi=0x0e9927b4,seq=0x98), length 116 10:13:21.151791 IP 88.200.30.145 > 147.20.148.94: ICMP 88.200.30.145 protocol 50 unreachable, length 144 From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 10:42: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 1E2DC16A417 for ; Wed, 3 Oct 2007 10:42:33 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from cmail.yandex.ru (cmail.yandex.ru [213.180.193.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4A97913C4A3 for ; Wed, 3 Oct 2007 10:42:31 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [87.250.250.1] (wawa.yandex.ru [87.250.250.1]) by cmail.yandex.ru (8.14.1/8.14.1) with ESMTP id l93AgTLX013060; Wed, 3 Oct 2007 14:42:29 +0400 (MSD) (envelope-from wawa@yandex-team.ru) Message-ID: <47037246.2070400@yandex-team.ru> Date: Wed, 03 Oct 2007 14:43:18 +0400 From: Vladimir Ivanov Organization: Yandex LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13pre) Gecko/20070505 Iceape/1.0.9 (Debian-1.0.10~pre070720-0etch3+lenny1) MIME-Version: 1.0 To: Bruce Evans References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> <20071003111737.U14276@delplex.bde.org> In-Reply-To: <20071003111737.U14276@delplex.bde.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030100060907060803030002" Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 10:42:33 -0000 This is a cryptographically signed message in MIME format. --------------ms030100060907060803030002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce Evans wrote: > On Tue, 2 Oct 2007, Vladimir Ivanov wrote: > >> Main improvement of this version: driver does not use TX interrupts >> at all. So, interrupt rate reduced significantly. > > Polling for anything is a bug IMO. Buggy hardware may work better > with it, > but em is not buggy :-). The driver does not use polling. We've disabled TX interrupts because we seem interrupt hook is too strange and ineffective place to make watchdog calculations and queue cleaning. We can do it from application context much easier. RX queue procedure uses another technique. We send wakeup message to RX kernel threads and mask RX interrupts. Each RX thread parses RX queue while it isn't empty. After completion RX kernel thread unmask interrupt. This hint let us avoid both RX interrupt storm and additional latency (due to admin's throttling). RX interrupt is being masked if and only if there are no threads to handle interrupt. Also, the driver behave itself like polling mode under heavy load. But the major benefit of our patchset is SMP. > For bge, I tune the interrupt moderation parameters to reduce the tx > interrupt rate to almost as low as possible without doing polling. > The rate is either 1 interrupt per second if the tx is almost inactive > or 1 interrupt every 384 packets if the tx is active. -current mistunes > these parameters to 150 (microseconds) and 10 (descriptos). Old tuning > of 150 and 128 only loses a little compared with 1000000 and 384. (150 > gives 6667 interrupts per second under load. This interrupt rate is > quite manageable and is about the same rate as you have to use with > polling to get the same throughput but lower efficiency as with > interrupts. 128 for the descriptor limit causes in a max interrupt rate > of only a few hundred per second except with tiny packets, but 10 is > excessively small and requires a rate of up to 140000 per second to keep > up with tiny packets. 140000 isn't manageable.) > > em has more/better interrupt parameters with non-broken defaults so I > haven't > needed to tune them. For bge, I implement dynamic rx interrupt > moderation > in software where em has it in hardware. 10000 interrupts/second for rx > is a good limit. IIRC, em uses 8000 which is a bit low for a max, and > is missing a sysctl for easy tuning. I've spent a lot of time for em tuning. This way has a limit. :-) > > Bruce Regards, PS: we have published newest 1.16 revision. Just small tuning fix. -- Vladimir Ivanov Network Operations Center OOO "Yandex" t: +7 495 739-7000 f: +7 495 739-7070 @: noc@yandex.net (corporate) wawa@yandex-team.ru (personal) www: www.yandex.ru -- --------------ms030100060907060803030002 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCC AuAwggJJoAMCAQICEA2B08GbcpEEl6Da/kpOht8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDcwNDE1MTM0NVoX DTA4MDcwMzE1MTM0NVowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTd2F3YUB5YW5kZXgtdGVhbS5ydTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANuooNgTWqT0D35N7rdbZAAje8iyZcELUHy3Dgh6Pymm+s7RIeP8EoxTnn1o YQMFkZdthNT/j+MXl61O0zBshti+34/9m0rQzntCHDboJf9yTeA0bOqL43EdnEMlUWTEaf00 dcOySQ3fpTKiiQKqFASI1MUPDCfQQuu6ansTCpddG8fOu+zaE570aH6hoy/NRGhH8SCbcARY QxjjiddCUknclX2gz4ak+wVB4IapHNSdtRG3APj5GZY9VK7sAwjOqodcNwbQEG/Gj6j99fU3 7GYAL+x3bz9wve9YGEJ7TUPLpd582tZtiiakqurnluId4Ix1B/HSyAZnPAr5WYJZrwcCAwEA AaMwMC4wHgYDVR0RBBcwFYETd2F3YUB5YW5kZXgtdGVhbS5ydTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBABzUVmJvH3Cr++WFtTFVewG2cLZo3geMNRuT+wIPULXt59LPuSg7 ZnK04wXNC2Am5UKilWxvDS6gs6pW2ZIDHw8YttQzej7z7+Scujr9uyfxMcTxHfk826UAdadz eKYGHEvb41wokW/lZR6fMLqRzfjHLDTZM46GiXQFVSMtqCT0MIIDPzCCAqigAwIBAgIBDTAN BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAlEwggJNAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhANgdPBm3KRBJeg2v5KTobfMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcxMDAzMTA0MzE4WjAjBgkqhkiG 9w0BCQQxFgQUcj54UL6kKkVwOZPKIGh7XfJTXRowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEggEAYHfpVrYQkH4vZVr6s5c/aGhCzlR1Z4EjDvYO9lzU 8MC7mSSzWB2bVjdJYsRS9bqP9K2eguSc6WfmibA8xBKJ9EY5MqzzeL1HK7iH932eaybtLwJS 7Mkl2smTVlzma2va0vdTrEdm18wRFZSkpRC/NI0ai9Tuq0YjPm0KX2e70ewaJpylt8aReZdM zkPXIYqTAAZcQj20QSSYZSNQDsWbPX+RO8zrO8TJHFeXamLlvnnlxw0dr8Uwipb/v1XZP1Ij kozx+0TLnBK0rSgXEQQr5ZVR9xbC1KfQUD7aDl2A7ayqNy3cwpNh+v0XpR3+F/q8LT7IZGOw Sq1CuAXctXUM6QAAAAAAAA== --------------ms030100060907060803030002-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 11:39:38 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 993A416A41A for ; Wed, 3 Oct 2007 11:39:38 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5FDEB13C457 for ; Wed, 3 Oct 2007 11:39:38 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Id2Ry-0007wu-Hc for freebsd-net@freebsd.org; Wed, 03 Oct 2007 11:31:34 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Oct 2007 11:31:34 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Oct 2007 11:31:34 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Wed, 03 Oct 2007 13:20:17 +0200 Lines: 33 Message-ID: References: <46FBE818.3020800@FreeBSD.org> <9bbcef730709271054k5cbda605wcfd44adede05614f@mail.gmail.com> <46FBF101.6080402@FreeBSD.org> <9bbcef730709271208t74938933p704b554625f443ba@mail.gmail.com> <46FC019F.60900@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigDB2EA833C130DC8CCD9C105A" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) In-Reply-To: X-Enigmail-Version: 0.94.4.0 Sender: news Subject: Re: Panic in rt_check X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Oct 2007 11:39:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB2EA833C130DC8CCD9C105A Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Ivan Voras wrote: > Apparently, this was patched 4 days ago so I'll try two things: 1) buil= d > with the new (patched) version and=20 Interesting development - the machine is stable now for 5 days (before=20 this, it would panic within 48 hours). It looks like the problem might=20 be fixed by the commit to if_stf.c (or something else in the recent=20 -CURRENT). I'll keep monitoring it closely. --------------enigDB2EA833C130DC8CCD9C105A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHA3rxldnAQVacBcgRA/RPAKDZiq/7MgEG+QzHidOO4dCj3gS5+ACgwyjG X94VD5kb/UFPmuDXYV0mC00= =7SKn -----END PGP SIGNATURE----- --------------enigDB2EA833C130DC8CCD9C105A-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 12:09: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 0262E16A41A for ; Wed, 3 Oct 2007 12:09:27 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-04.prod.mesa1.secureserver.net [64.202.165.12]) by mx1.freebsd.org (Postfix) with SMTP id B995D13C46A for ; Wed, 3 Oct 2007 12:09:26 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 13666 invoked from network); 3 Oct 2007 12:09:25 -0000 Received: from unknown (24.144.77.243) by smtpout08-04.prod.mesa1.secureserver.net (64.202.165.12) with ESMTP; 03 Oct 2007 12:09:25 -0000 Message-ID: <47038673.9020403@seclark.us> Date: Wed, 03 Oct 2007 08:09:23 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18) Gecko/20010110 Netscape6/6.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: are DMZ's out of vogue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 12:09:27 -0000 Hi List, Our in house network configuration is using FreeBSD for our firewall. We currently have it setup with 3 interfaces a public, private and DMZ. We our moving to a new facility and our network engineer says nobody is using DMZs any more and wants to just do NAT redirects from our FreeBSD firewall to servers on the private network. These servers were on the DMZ in our current configuration. Does this make sense? Is it true that DMZ's have fallen out of vogue? Sorry for the off topic post. Thanks for any input, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 13:50: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 5158916A41A for ; Wed, 3 Oct 2007 13:50:24 +0000 (UTC) (envelope-from ericx@vineyard.net) Received: from vineyard.net (k1.vineyard.net [204.17.195.90]) by mx1.freebsd.org (Postfix) with ESMTP id 2D33E13C4BE for ; Wed, 3 Oct 2007 13:50:24 +0000 (UTC) (envelope-from ericx@vineyard.net) Received: from amavis-ace1 (a1.vineyard.net [204.17.195.95]) by vineyard.net (Postfix) with ESMTP id B7A3A9155C; Wed, 3 Oct 2007 09:31:44 -0400 (EDT) X-Virus-Scanned: by AMaViS-ace1 at Vineyard.NET Received: from smtp1.vineyard.net ([127.0.0.1]) by amavis-ace1 (ace1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wMYeHisBurzA; Wed, 3 Oct 2007 09:31:44 -0400 (EDT) Received: from [204.17.195.104] (fortiva.vineyard.net [204.17.195.104]) by smtp1.vineyard.net (Postfix) with ESMTP id 6DAFC158180A; Wed, 3 Oct 2007 09:31:44 -0400 (EDT) Message-ID: <4703997A.3070206@vineyard.net> Date: Wed, 03 Oct 2007 09:30:34 -0400 From: "Eric W. Bates" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <47038673.9020403@seclark.us> In-Reply-To: <47038673.9020403@seclark.us> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: are DMZ's out of vogue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Oct 2007 13:50:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Clark wrote: > Hi List, > > Our in house network configuration is using FreeBSD for our firewall. We > currently have it setup with > 3 interfaces a public, private and DMZ. We our moving to a new facility > and our network engineer > says nobody is using DMZs any more and wants to just do NAT redirects > from our FreeBSD firewall > to servers on the private network. These servers were on the DMZ in our > current configuration. > > Does this make sense? Is it true that DMZ's have fallen out of vogue? I don't think they are out of vogue. But we usually use 2 firewalls. One to separate the DMZ from the Internet (usually the cisco with dynamic rules), and a second behind the DMZ (usually a FreeBSD box) before you get to the juicy stuff. By definition, you don't completely trust the machines in the DMZ. Because you are inviting the public to poke at ports 25, 80, 143, et al. on those machines you have to assume they will be exploited at any moment; so you separate them from your safe world as much as possible. > Sorry for the off topic post. > > Thanks for any input, > Steve > - -- Eric W. Bates ericx@vineyard.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHA5l6D1roJTQ4LlERAubkAJ0YggFHNwhznUw7ce1f3rOacJ0QugCggBwC ms+SveSUqeUkOKggjxRNU7U= =C3Qv -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 16:23: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 2803A16A419 for ; Wed, 3 Oct 2007 16:23:11 +0000 (UTC) (envelope-from elitecoder@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 EEFD513C447 for ; Wed, 3 Oct 2007 16:23:10 +0000 (UTC) (envelope-from elitecoder@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so5638150waf for ; Wed, 03 Oct 2007 09:23:10 -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=GYW4xqwKbAuntw+fWS2aUqPCAhx5CZWDG72svl06X08=; b=AKka7C0LUUkmb7vDXMrgd3VgAGWuxBhdc2Jstl7mrhvmQPNu0K5KJZu10//GmMMHIga423V8GOaxkuAKX0ifb48fxidZ8R08q1YCUNFsb1yR8mwrSL2f/hY8uZM+x3lQJMosa9hhMQv8OUDSSltPlaUzvLbbKo4BAbRCwMbCiS4= 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=TmsXbq4NFcu2IyENGPSECH0zjgfDxgXFAeQIVLDaO7WtXiDKCcBCP2YIpVwCvNn3JHBgIsTacp6wnOJcDsQpii4hvuuCU3kbiFxAcEuhIS2U/wZuZe8TvzpFtlyAsPYZ5SY4e9Tg792CtD/qcounHaUjKj1cU740MB2PQxO9H3I= Received: by 10.115.108.1 with SMTP id k1mr3217894wam.1191426883204; Wed, 03 Oct 2007 08:54:43 -0700 (PDT) Received: by 10.114.13.5 with HTTP; Wed, 3 Oct 2007 08:54:43 -0700 (PDT) Message-ID: <3c6d44e30710030854h2e261cf3s31c2825887f50237@mail.gmail.com> Date: Wed, 3 Oct 2007 08:54:43 -0700 From: David 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: arping only sending one packet - not exiting properly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Oct 2007 16:23:11 -0000 Hello all, I am trying to figure out why arping on one of my servers is unable to send more than one packet. When I am not using the verbose flag it will appear to "hang" and not exit until a ^C is given. With the verbose flag it just scrolls those pcap_dispatch errors down the terminal. (this is even the case when I specify -c 1) I don't know what 'arping: select=1 pcap_dispatch=0!' means. Could someone shed some light on this problem? Both systems are built with libnet11-1.1.2.1_1,1 and arping-2.05_2. Both are FreeBSD 6.2-RELEASE SMP I disabled the firewall completely during these tests Not working: [root@host /usr/home/user]# arping -v -c 4 xxx.xxx.90.200 This box: Interface: em0 IP: xxx.xxx.90.201 MAC address: 00:30:48:5b:1d:88 ARPING xxx.xxx.90.200 60 bytes from 00:11:09:2b:b5:28 (xxx.xxx.80.200): index=0 time=19.895 msec arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! arping: select=1 pcap_dispatch=0! ^C --- xxx.xxx.90.200 statistics --- 1 packets transmitted, 1 packets received, 0% unanswered [root@host /usr/home/user]# Working: [root@workinghost /usr/home/user]# arping -v -c 4 xxx.xxx.184.69 This box: Interface: fxp0 IP: xxx.xxx.236.156 MAC address: 00:0f:ea:47:52:f1 ARPING xxx.xxx.184.69 60 bytes from 00:30:48:57:5a:de (xxx.xxx.184.69): index=0 time=6.914 usec arping: select=1 pcap_dispatch=0! 60 bytes from 00:30:48:57:5a:de (xxx.xxx.184.69): index=1 time=5.007 usec arping: select=1 pcap_dispatch=0! 60 bytes from 00:30:48:57:5a:de (xxx.xxx.184.69): index=2 time=5.007 usec arping: select=1 pcap_dispatch=0! --- xxx.xxx.184.69 statistics --- 4 packets transmitted, 3 packets received, 25% unanswered Thanks. From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 17:52:45 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 6953B16A468 for ; Wed, 3 Oct 2007 17:52:45 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id AC64E13C48E for ; Wed, 3 Oct 2007 17:52:44 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so3290130nfb for ; Wed, 03 Oct 2007 10:52: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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=/Fzw0bRXRx9xsP+RRnWG+Mc+ZLOe8RqDDYAGIO5AlvI=; b=IviGdnAJYm7wvw5iiAjQBp0hTSWOpxAm4scOiHneXI+SEDiJmsSm0IDBnlcNKR0GElCZQoR9mM79lZPJBsj19SvCntWIqty2xPA6O2at1wC733EP9N5XO1PJN1+OtP8f12w6G5/BQgQAjHcgLabD+D33ijhoEpzx2D6ONBaJi7M= 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=Jg+OissD/nW6+Bco3M8GfUlLsR60uJiZ41SM4JjuRbpZRlc5v53dlpo/uGrb2oGiiXUxzAh4WpREPsdazRIkLqd0bb07XwrDj8EHiqe4sBTkWr803ZArfLp1NFMaPrWRuMMOUuccmy1wmpGVKm8phdFqqju4V6bgZmac4MJCaOw= Received: by 10.86.58.3 with SMTP id g3mr826333fga.1191433963282; Wed, 03 Oct 2007 10:52:43 -0700 (PDT) Received: by 10.86.100.19 with HTTP; Wed, 3 Oct 2007 10:52:43 -0700 (PDT) Message-ID: <2a41acea0710031052w40c10cabjf923803ba23b2546@mail.gmail.com> Date: Wed, 3 Oct 2007 10:52:43 -0700 From: "Jack Vogel" To: "freebsd-net@freebsd.org" , "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: RFC: Capability addition for IEEE 1588 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Oct 2007 17:52:45 -0000 I am adding support into the em driver for PTP, what I would prefer doing is to add interface capability support: IFCAP_TSYNC or something like that. The driver will then enable/disable the feature. Are there other vendor's hardware providing this support such that a net/if.h capability would be justified? There was also some other defines that are needed, an ethertype for instance, I forget what it was offhand but I did notice it wasn't there yet. Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 18:25: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 56DF616A46B for ; Wed, 3 Oct 2007 18:25:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id DCFAA13C469 for ; Wed, 3 Oct 2007 18:25:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9173E17104; Wed, 3 Oct 2007 17:59:53 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l93HxuAj052870; Wed, 3 Oct 2007 17:59:56 GMT (envelope-from phk@critter.freebsd.dk) To: "Jack Vogel" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 03 Oct 2007 10:52:43 MST." <2a41acea0710031052w40c10cabjf923803ba23b2546@mail.gmail.com> Date: Wed, 03 Oct 2007 17:59:56 +0000 Message-ID: <52869.1191434396@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "freebsd-net@freebsd.org" , FreeBSD Current Subject: Re: RFC: Capability addition for IEEE 1588 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Oct 2007 18:25:25 -0000 In message <2a41acea0710031052w40c10cabjf923803ba23b2546@mail.gmail.com>, "Jack Vogel" writes : >I am adding support into the em driver for PTP, what I would prefer doing is >to add interface capability support: IFCAP_TSYNC or something like that. >The driver will then enable/disable the feature. > >Are there other vendor's hardware providing this support such that a >net/if.h capability would be justified? > >There was also some other defines that are needed, an ethertype >for instance, I forget what it was offhand but I did notice it wasn't >there yet. When I talked to HP's licensing department, there were a $1k licensefee for anything IEEE1588 related and their message was that even if the FreeBSD foundation got such a license, the users would still have to have one as well if they compiled the source code or some such nonsense. If this has all been taken care of: Go for it! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 18:47:31 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 DFF2D16A418 for ; Wed, 3 Oct 2007 18:47:31 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from smtp3.utdallas.edu (smtp3.utdallas.edu [129.110.10.49]) by mx1.freebsd.org (Postfix) with ESMTP id A841413C447 for ; Wed, 3 Oct 2007 18:47:31 +0000 (UTC) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTP id 4FC2565507 for ; Wed, 3 Oct 2007 13:22:06 -0500 (CDT) Date: Wed, 03 Oct 2007 13:22:05 -0500 From: Paul Schmehl To: freebsd-net@freebsd.org Message-ID: <80304F2FE5F437924A638955@utd59514.utdallas.edu> In-Reply-To: <47038673.9020403@seclark.us> References: <47038673.9020403@seclark.us> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: are DMZ's out of vogue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Oct 2007 18:47:32 -0000 --On Wednesday, October 03, 2007 08:09:23 -0400 Stephen Clark wrote: > Hi List, > > Our in house network configuration is using FreeBSD for our firewall. We > currently have it setup with > 3 interfaces a public, private and DMZ. We our moving to a new facility > and our network engineer > says nobody is using DMZs any more and wants to just do NAT redirects > from our FreeBSD firewall > to servers on the private network. These servers were on the DMZ in our > current configuration. > > Does this make sense? Is it true that DMZ's have fallen out of vogue? > Any time someone makes a statement like that, I ask them for attribution. Where did they get this information? Why do they consider it to be reliable? This is the first time I've heard such a statement, and I consider it to be untrustworthy without some sort of pointer to a trusted source that has made the statement and backed it up with statistics. >From strictly a security philosophy standpoint, it sounds crazy. Without going in to great detail, NAT doesn't do a thing for you with regard to protecting machines. Essentially he's advocating removing one layer of defense without providing any reason why it makes sense other than "everybody is doing it". -- Paul Schmehl (pauls@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 20:06: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 95BEE16A41A for ; Wed, 3 Oct 2007 20:06:28 +0000 (UTC) (envelope-from jfvogel@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 11A8813C467 for ; Wed, 3 Oct 2007 20:06:27 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so3327102nfb for ; Wed, 03 Oct 2007 13:06:26 -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=GZ6g3V1rjhIqK7oSFnlWUJMtoxppQEbwljLaaw486ZA=; b=F9TkRd9qGUu6gF9HvcFpfHsVLGQYIihC/Vt12dvbV4lKerER+1pZWgQdtVghS65t+3iBY/cKUWDGq3YFlGq8wJ19l5VopwUq5nT5iRhnQRdhk2gNa09pUddX5iuQxcZmEbzYcZ+hsyV6YXVM1Q1YiRgrBPF0kqt4Okds5tNWWRs= 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=cAPM+hZetPdsyu7wE2wVen2ET00pnLUiLqg5tPKD+7F+8gtzadGJ+T1RNrBEFxezU8Jmq4EIKOgOoH1Mxw1lTpZSvrwSviLLyldG3aP1SkxmxSWi3XH7oG2gNkR37MBNyq+rrdmj3lhWLUZRdtyvyxlVdFab7m9kDGsW7796XD8= Received: by 10.86.9.8 with SMTP id 8mr888467fgi.1191441986395; Wed, 03 Oct 2007 13:06:26 -0700 (PDT) Received: by 10.86.100.19 with HTTP; Wed, 3 Oct 2007 13:06:26 -0700 (PDT) Message-ID: <2a41acea0710031306p22d66379oc6575ad9ff5ea99d@mail.gmail.com> Date: Wed, 3 Oct 2007 13:06:26 -0700 From: "Jack Vogel" To: "Poul-Henning Kamp" In-Reply-To: <52869.1191434396@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0710031052w40c10cabjf923803ba23b2546@mail.gmail.com> <52869.1191434396@critter.freebsd.dk> Cc: "freebsd-net@freebsd.org" , FreeBSD Current Subject: Re: RFC: Capability addition for IEEE 1588 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Oct 2007 20:06:28 -0000 On 10/3/07, Poul-Henning Kamp wrote: > In message <2a41acea0710031052w40c10cabjf923803ba23b2546@mail.gmail.com>, "Jack Vogel" writes > : > > >I am adding support into the em driver for PTP, what I would prefer doing is > >to add interface capability support: IFCAP_TSYNC or something like that. > >The driver will then enable/disable the feature. > > > >Are there other vendor's hardware providing this support such that a > >net/if.h capability would be justified? > > > >There was also some other defines that are needed, an ethertype > >for instance, I forget what it was offhand but I did notice it wasn't > >there yet. > > When I talked to HP's licensing department, there were a $1k licensefee > for anything IEEE1588 related and their message was that even if > the FreeBSD foundation got such a license, the users would still > have to have one as well if they compiled the source code or some > such nonsense. What source code was being talked about? I'm not talking about anything userland, and my driver is just turning on a hardware feature, I can't imagine HP having anything to do with it, but I double check internally. Also, there is the ptpd project on sourceforge, that even uses a BSD rather than GPL license, should be easy to use, but I'm new to this so its possible I'm missing something? I'm basically tasked with adding driver support, what happens to actually use it is another matter :) Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 20:11: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 25FF116A41A; Wed, 3 Oct 2007 20:11:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B603413C43E; Wed, 3 Oct 2007 20:10:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7459517106; Wed, 3 Oct 2007 20:10:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l93KB1TJ053520; Wed, 3 Oct 2007 20:11:01 GMT (envelope-from phk@critter.freebsd.dk) To: "Jack Vogel" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 03 Oct 2007 13:06:26 MST." <2a41acea0710031306p22d66379oc6575ad9ff5ea99d@mail.gmail.com> Date: Wed, 03 Oct 2007 20:11:01 +0000 Message-ID: <53519.1191442261@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "freebsd-net@freebsd.org" , FreeBSD Current Subject: Re: RFC: Capability addition for IEEE 1588 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Oct 2007 20:11:00 -0000 In message <2a41acea0710031306p22d66379oc6575ad9ff5ea99d@mail.gmail.com>, "Jack Vogel" writes : >> When I talked to HP's licensing department, there were a $1k licensefee >> for anything IEEE1588 related and their message was that even if >> the FreeBSD foundation got such a license, the users would still >> have to have one as well if they compiled the source code or some >> such nonsense. > >What source code was being talked about? I'm not talking about >anything userland, and my driver is just turning on a hardware >feature, I can't imagine HP having anything to do with it, but I >double check internally. They seem to think they have a patent on doing things that way, no matter what hardware or software you use. If Intel chips have hw-support for timestamping, somebody at intel must have thought about the patent thing. But as I said, if that can be resolved, it should certainly go in. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 20:21: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 3176C16A420 for ; Wed, 3 Oct 2007 20:21:33 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (unknown [IPv6:2001:b30:5000:2:20e:cff:fe4b:ca01]) by mx1.freebsd.org (Postfix) with ESMTP id 83A9313C44B for ; Wed, 3 Oct 2007 20:21:32 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 5A3F65084F for ; Wed, 3 Oct 2007 23:21:31 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on local.mail.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwxJGNZSdbeL for ; Wed, 3 Oct 2007 23:21:25 +0300 (EEST) Received: from [172.27.2.200] (c7.campus.utcluj.ro [193.226.6.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 48A7550899 for ; Wed, 3 Oct 2007 23:21:25 +0300 (EEST) Message-ID: <4703F9C3.2060601@net.utcluj.ro> Date: Wed, 03 Oct 2007 23:21:23 +0300 From: Cristian KLEIN User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: FreeBSD as a gigabit 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: Wed, 03 Oct 2007 20:21:33 -0000 Hi list, A few days ago I tested whether a FreeBSD 7 box is able to handle Gigabit traffic. So I used a Cisco 7600 and added static routes from the router to the box and from the box to the router, so that some packets would loop between the two. Then I externally injected 30Mbps of "ping -f -t 255 -s ", which should have generated a "maximum" of 3,6Gbps. I then used nload on the box to graph the bandwidth. The box is a Intel Core 2 Duo, with a PCIe re NIC. I used FreeBSD i386 with polling and fastforwarding. No WITNESS, INVARIANTS or firewalls. I was amased to see that injecting 1000 bytes packets gave a maximum throughput of 650Mbps, while 1400 bytes gave 750Mbps. During both tests one core was 98% idle, while the other one was more than 80% idle. Can anybody point me what the bottleneck of this configuration is? CPU was mostly idle and PCIe 1x should carry way more. Or is the experiment perhaps fundamentally flawed? Thanks. From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 20:51:14 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 2888516A419 for ; Wed, 3 Oct 2007 20:51:14 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 995EE13C46A for ; Wed, 3 Oct 2007 20:51:12 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so3338418nfb for ; Wed, 03 Oct 2007 13:51:12 -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=gth66V1XdeoZWncLWMEWo589azCnofh5mO0MHG0oauI=; b=CvAe88RfqP+3OL7u58mwAhHLFHG8R6V+1sjDWmDIHT509PnoK9vr5yEFS201XKObl2pjEjAOqIvduDs+GH+JKh+UkY0KbZUVj2neJbQbgDWw77dupFfyiGMA36Ms2oqXa8utntKG9n/raP5lDsD2hbPlnbFScpr9EAuc+MlsjOY= 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=P8rEk00wDzWBaJf7O0V4vbWmdFfKBER2fN6N/dBKkhDuW70Sm+8uNA+R2GbFKFklEGlVPD3jXfL+Lcdw4Pest1eHOFE09Yo90Cahe5AiRWoN5wW0KZLYlpoJLZCQCjthSv7HC8vk7l9iujnD3w0COjCMtC6WPTYkqGq1PbAh1wE= Received: by 10.86.65.11 with SMTP id n11mr944565fga.1191444671913; Wed, 03 Oct 2007 13:51:11 -0700 (PDT) Received: by 10.86.100.19 with HTTP; Wed, 3 Oct 2007 13:51:11 -0700 (PDT) Message-ID: <2a41acea0710031351m2101d49fo91579c8858316f51@mail.gmail.com> Date: Wed, 3 Oct 2007 13:51:11 -0700 From: "Jack Vogel" To: "Poul-Henning Kamp" In-Reply-To: <53519.1191442261@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0710031306p22d66379oc6575ad9ff5ea99d@mail.gmail.com> <53519.1191442261@critter.freebsd.dk> Cc: "freebsd-net@freebsd.org" , FreeBSD Current Subject: Re: RFC: Capability addition for IEEE 1588 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Oct 2007 20:51:14 -0000 On 10/3/07, Poul-Henning Kamp wrote: > In message <2a41acea0710031306p22d66379oc6575ad9ff5ea99d@mail.gmail.com>, "Jack Vogel" writes > : > > >> When I talked to HP's licensing department, there were a $1k licensefee > >> for anything IEEE1588 related and their message was that even if > >> the FreeBSD foundation got such a license, the users would still > >> have to have one as well if they compiled the source code or some > >> such nonsense. > > > >What source code was being talked about? I'm not talking about > >anything userland, and my driver is just turning on a hardware > >feature, I can't imagine HP having anything to do with it, but I > >double check internally. > > They seem to think they have a patent on doing things that way, > no matter what hardware or software you use. > > If Intel chips have hw-support for timestamping, somebody at intel > must have thought about the patent thing. > > But as I said, if that can be resolved, it should certainly go in. This is a feature that will be coming, its not in any hardware you can buy today, presumeably Intel dealt with the patent thing, but I have already sent internal email checking on the whole matter. I'll followup when I'm things are clarified. Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 21:00: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 ECD5A16A421 for ; Wed, 3 Oct 2007 21:00:46 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 8082013C45B for ; Wed, 3 Oct 2007 21:00:46 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so962161anc for ; Wed, 03 Oct 2007 14:00:45 -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:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=r92tR1Lrf+CtP7EzSfnOwrXdnHUpF8CcLqV1E6SCYt8=; b=Zk3I7oLXGmztE+YVqavX4wivFkQzaYZR3gNSv+v8GpAWy73FP678UtNJWj2eV80BFjObsbi2HVTN8PzihTVDT3+YYsM19QNuPcWFz2Qskxe1zrfLNqwIWFkkPZaZWlhVgbXzvfzNqi5YBMZfaxz+23kNZaPoOgXQ3HpdmAlpRBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=iG4iT65KdTgW07R2yjMf6TQFluEpyVM8Xxxeh9+5Quv7e0CORSTJtmpDj9lAx1yI1v2UbLLxQbTN8qV0LExd1t/J7CjOSD0/NsyKQU5R4zSSfOIXWorThoi1dr5g2ebRNlgtf5NWFS+zOsaXCB6b7bOZkDCHyxAiUBzoCXp3R4o= Received: by 10.142.77.11 with SMTP id z11mr1149627wfa.1191443710453; Wed, 03 Oct 2007 13:35:10 -0700 (PDT) Received: by 10.140.192.2 with HTTP; Wed, 3 Oct 2007 13:35:10 -0700 (PDT) Message-ID: <2e77fc10710031335x2e48f723vae4d0e869b4426f0@mail.gmail.com> Date: Wed, 3 Oct 2007 23:35:10 +0300 From: "Niki Denev" Sender: ndenev@gmail.com To: "Cristian KLEIN" , freebsd-net@freebsd.org In-Reply-To: <4703F9C3.2060601@net.utcluj.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4703F9C3.2060601@net.utcluj.ro> X-Google-Sender-Auth: 2de8ecfc3876f99e Cc: Subject: Re: FreeBSD as a gigabit 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: Wed, 03 Oct 2007 21:00:47 -0000 2007/10/3, Cristian KLEIN : > Hi list, > > A few days ago I tested whether a FreeBSD 7 box is able to handle Gigabit > traffic. So I used a Cisco 7600 and added static routes from the router to the > box and from the box to the router, so that some packets would loop between the > two. Then I externally injected 30Mbps of "ping -f -t 255 -s ", which > should have generated a "maximum" of 3,6Gbps. I then used nload on the box to > graph the bandwidth. > > The box is a Intel Core 2 Duo, with a PCIe re NIC. I used FreeBSD i386 with > polling and fastforwarding. No WITNESS, INVARIANTS or firewalls. > > I was amased to see that injecting 1000 bytes packets gave a maximum throughput > of 650Mbps, while 1400 bytes gave 750Mbps. During both tests one core was 98% > idle, while the other one was more than 80% idle. > > Can anybody point me what the bottleneck of this configuration is? CPU was > mostly idle and PCIe 1x should carry way more. Or is the experiment perhaps > fundamentally flawed? > > Thanks. > > _______________________________________________ > 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" > > Using icmp and especially "ping -f" does not sound like a good idea for testing network thoroughput. Maybe you should consider something like iperf or netperf (/usr/ports/benchmarks/iperf and /usr/ports/benchmarks/netperf) -- Niki From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 21:45: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 568BB16A469 for ; Wed, 3 Oct 2007 21:45:52 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id A889F13C467 for ; Wed, 3 Oct 2007 21:45:50 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id A9E44EBB3A5; Thu, 4 Oct 2007 05:45:49 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id kj0GE3O9uwQE; Thu, 4 Oct 2007 05:45:44 +0800 (CST) Received: from LI-Xins-MacBook.local (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 97EA8EBB334; Thu, 4 Oct 2007 05:45:42 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=JP5eh8UXLLAXLEyPAO8Ito6/Kil8F1B3kjyWmEzIT1Q9kxAgL5andxDDR9qjfwqu0 FdYmtuzURM3hkKVVHbJVw== Message-ID: <47040D83.9010706@delphij.net> Date: Wed, 03 Oct 2007 14:45:39 -0700 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Vladimir Ivanov References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> <20071003111737.U14276@delplex.bde.org> <47037246.2070400@yandex-team.ru> In-Reply-To: <47037246.2070400@yandex-team.ru> X-Enigmail-Version: 0.95.3 OpenPGP: url=http://www.delphij.net/delphij.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig19778564B8230D4BDB26AB74" Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 21:45:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig19778564B8230D4BDB26AB74 Content-Type: multipart/mixed; boundary="------------060708020602090500090901" This is a multi-part message in MIME format. --------------060708020602090500090901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Valdimir and Jack, I have ported Valdimir's 1.16 revision of their driver to -CURRENT code as of today, but I don't have a box that is suitable for testing right now as I just moved, and the server I used to do FreeBSD coding stuff is located several thousand miles away :-) I hope that this would be useful for adoption to the official em(4) driver, and thanks Valdimir and Yandex for their work on this. Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------060708020602090500090901 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="em.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="em.diff" Index: e1000_defines.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/em/e1000_defines.h,v retrieving revision 1.3 diff -u -p -r1.3 e1000_defines.h --- e1000_defines.h 16 May 2007 00:14:23 -0000 1.3 +++ e1000_defines.h 3 Oct 2007 21:36:07 -0000 @@ -746,7 +746,6 @@ */ #define IMS_ENABLE_MASK ( \ E1000_IMS_RXT0 | \ - E1000_IMS_TXDW | \ E1000_IMS_RXDMT0 | \ E1000_IMS_RXSEQ | \ E1000_IMS_LSC) Index: if_em.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v retrieving revision 1.184 diff -u -p -r1.184 if_em.c --- if_em.c 10 Sep 2007 21:50:40 -0000 1.184 +++ if_em.c 3 Oct 2007 21:41:12 -0000 @@ -240,14 +240,16 @@ static void em_initialize_transmit_unit( static int em_setup_receive_structures(struct adapter *); static void em_initialize_receive_unit(struct adapter *); static void em_enable_intr(struct adapter *); +static void em_enable_intr_rx(struct adapter *); static void em_disable_intr(struct adapter *); +static void em_disable_intr_rx(struct adapter *); static void em_free_transmit_structures(struct adapter *); static void em_free_receive_structures(struct adapter *); static void em_update_stats_counters(struct adapter *); static void em_txeof(struct adapter *); static int em_allocate_receive_structures(struct adapter *); static int em_allocate_transmit_structures(struct adapter *); -static int em_rxeof(struct adapter *, int); +static int em_rxeof(struct adapter *, int, int); #ifndef __NO_STRICT_ALIGNMENT static int em_fixup_rx(struct adapter *); #endif @@ -292,14 +294,19 @@ static void em_get_hw_control(struct static void em_release_hw_control(struct adapter *); static void em_enable_wakeup(device_t); =20 + +/* + * Fast interrupt handler and legacy ithread/polling modes are + * mutually exclusive. + */ #ifdef DEVICE_POLLING static poll_handler_t em_poll; static void em_intr(void *); #else +static void em_add_int_rx_kthread_priority(struct adapter *, const char = *, + const char *, int *, int); static int em_intr_fast(void *); -static void em_add_rx_process_limit(struct adapter *, const char *, - const char *, int *, int); -static void em_handle_rxtx(void *context, int pending); +static void em_kthread_rx(void *arg); static void em_handle_link(void *context, int pending); #endif =20 @@ -351,9 +358,8 @@ TUNABLE_INT("hw.em.rxd", &em_rxd); TUNABLE_INT("hw.em.txd", &em_txd); TUNABLE_INT("hw.em.smart_pwr_down", &em_smart_pwr_down); #ifndef DEVICE_POLLING -/* How many packets rxeof tries to clean at a time */ -static int em_rx_process_limit =3D 100; -TUNABLE_INT("hw.em.rx_process_limit", &em_rx_process_limit); +static int em_rx_kthread_priority =3D PRI_MAX_KERN; +TUNABLE_INT("hw.em.rx_kthread_priority", &em_rx_kthread_priority); #endif /* Global used in WOL setup with multiport cards */ static int global_quad_port_a =3D 0; @@ -370,7 +376,7 @@ static int global_quad_port_a =3D 0; static int em_probe(device_t dev) { - char adapter_name[60]; + char adapter_name[1024]; /* XXX why? */ uint16_t pci_vendor_id =3D 0; uint16_t pci_device_id =3D 0; uint16_t pci_subvendor_id =3D 0; @@ -431,7 +437,8 @@ em_attach(device_t dev) =20 adapter =3D device_get_softc(dev); adapter->dev =3D adapter->osdep.dev =3D dev; - EM_LOCK_INIT(adapter, device_get_nameunit(dev)); + EM_RXLOCK_INIT(adapter, device_get_nameunit(dev)); + EM_TXLOCK_INIT(adapter, device_get_nameunit(dev)); =20 /* SYSCTL stuff */ SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), @@ -444,8 +451,8 @@ em_attach(device_t dev) OID_AUTO, "stats", CTLTYPE_INT|CTLFLAG_RW, adapter, 0, em_sysctl_stats, "I", "Statistics"); =20 - callout_init_mtx(&adapter->timer, &adapter->mtx, 0); - callout_init_mtx(&adapter->tx_fifo_timer, &adapter->mtx, 0); + callout_init_mtx(&adapter->timer, &adapter->txmtx, 0); + callout_init_mtx(&adapter->tx_fifo_timer, &adapter->txmtx, 0); =20 /* Determine hardware and mac info */ em_identify_hardware(adapter); @@ -506,10 +513,10 @@ em_attach(device_t dev) } =20 #ifndef DEVICE_POLLING - /* Sysctls for limiting the amount of work done in the taskqueue */ - em_add_rx_process_limit(adapter, "rx_processing_limit", - "max number of rx packets to process", &adapter->rx_process_limit, - em_rx_process_limit); + /* Sysctls for set the RX kthreads' priority */ + em_add_int_rx_kthread_priority(adapter, "rx_kthread_priority", + "priority of RX handler kthread", &adapter->rx_kthread_priority, + em_rx_kthread_priority); #endif =20 /* @@ -517,25 +524,14 @@ em_attach(device_t dev) * must not exceed hardware maximum, and must be multiple * of E1000_DBA_ALIGN. */ - if (((em_txd * sizeof(struct e1000_tx_desc)) % EM_DBA_ALIGN) !=3D 0 || - (adapter->hw.mac.type >=3D e1000_82544 && em_txd > EM_MAX_TXD) || - (adapter->hw.mac.type < e1000_82544 && em_txd > EM_MAX_TXD_82543) |= | - (em_txd < EM_MIN_TXD)) { - device_printf(dev, "Using %d TX descriptors instead of %d!\n", - EM_DEFAULT_TXD, em_txd); - adapter->num_tx_desc =3D EM_DEFAULT_TXD; - } else - adapter->num_tx_desc =3D em_txd; - if (((em_rxd * sizeof(struct e1000_rx_desc)) % EM_DBA_ALIGN) !=3D 0 || - (adapter->hw.mac.type >=3D e1000_82544 && em_rxd > EM_MAX_RXD) || - (adapter->hw.mac.type < e1000_82544 && em_rxd > EM_MAX_RXD_82543) |= | - (em_rxd < EM_MIN_RXD)) { - device_printf(dev, "Using %d RX descriptors instead of %d!\n", - EM_DEFAULT_RXD, em_rxd); - adapter->num_rx_desc =3D EM_DEFAULT_RXD; - } else - adapter->num_rx_desc =3D em_rxd; - + if (adapter->hw.mac.type >=3D e1000_82544) { + adapter->num_tx_desc =3D EM_MAX_TXD; + adapter->num_rx_desc =3D EM_MAX_RXD; + } else { + adapter->num_tx_desc =3D EM_MAX_TXD_82543; + adapter->num_rx_desc =3D EM_MAX_RXD_82543; + } +=09 adapter->hw.mac.autoneg =3D DO_AUTO_NEG; adapter->hw.phy.wait_for_link =3D FALSE; adapter->hw.phy.autoneg_advertised =3D AUTONEG_ADV_DEFAULT; @@ -736,7 +732,9 @@ err_tx_desc: err_pci: em_free_intr(adapter); em_free_pci_resources(adapter); - EM_LOCK_DESTROY(adapter); + /* XXX */ + EM_TXLOCK_DESTROY(adapter); + EM_RXLOCK_DESTROY(adapter); =20 return (error); } @@ -766,7 +764,8 @@ em_detach(device_t dev) =20 em_disable_intr(adapter); em_free_intr(adapter); - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); adapter->in_detach =3D 1; em_stop(adapter); e1000_phy_hw_reset(&adapter->hw); @@ -785,7 +784,8 @@ em_detach(device_t dev) em_enable_wakeup(dev); } =20 - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); ether_ifdetach(adapter->ifp); =20 callout_drain(&adapter->timer); @@ -811,7 +811,8 @@ em_detach(device_t dev) adapter->rx_desc_base =3D NULL; } =20 - EM_LOCK_DESTROY(adapter); + EM_TXLOCK_DESTROY(adapter); + EM_RXLOCK_DESTROY(adapter); =20 return (0); } @@ -836,7 +837,8 @@ em_suspend(device_t dev) { struct adapter *adapter =3D device_get_softc(dev); =20 - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); em_stop(adapter); =20 em_release_manageability(adapter); @@ -853,7 +855,8 @@ em_suspend(device_t dev) em_enable_wakeup(dev); } =20 - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); =20 return bus_generic_suspend(dev); } @@ -864,7 +867,8 @@ em_resume(device_t dev) struct adapter *adapter =3D device_get_softc(dev); struct ifnet *ifp =3D adapter->ifp; =20 - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); em_init_locked(adapter); em_init_manageability(adapter); =20 @@ -872,7 +876,8 @@ em_resume(device_t dev) (ifp->if_drv_flags & IFF_DRV_RUNNING)) em_start_locked(ifp); =20 - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); =20 return bus_generic_resume(dev); } @@ -894,7 +899,7 @@ em_start_locked(struct ifnet *ifp) struct adapter *adapter =3D ifp->if_softc; struct mbuf *m_head; =20 - EM_LOCK_ASSERT(adapter); + EM_TXLOCK_ASSERT(adapter); =20 if ((ifp->if_drv_flags & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=3D IFF_DRV_RUNNING) @@ -906,7 +911,7 @@ em_start_locked(struct ifnet *ifp) =20 IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); if (m_head =3D=3D NULL) - break; + continue; /* * Encapsulation can modify our pointer, and or make it * NULL on failure. In that event, we can't requeue. @@ -926,7 +931,12 @@ em_start_locked(struct ifnet *ifp) ETHER_BPF_MTAP(ifp, m_head); =20 /* Set timeout in case hardware has problems transmitting. */ - adapter->watchdog_timer =3D EM_TX_TIMEOUT; + adapter->tx_counter ++; + } + + if (adapter->num_tx_desc - adapter->num_tx_desc_avail > 32) { + /* it's time to clean a little bit */ + em_txeof (adapter); } } =20 @@ -935,10 +945,10 @@ em_start(struct ifnet *ifp) { struct adapter *adapter =3D ifp->if_softc; =20 - EM_LOCK(adapter); + EM_TXLOCK(adapter); if (ifp->if_drv_flags & IFF_DRV_RUNNING) em_start_locked(ifp); - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); } =20 /********************************************************************* @@ -973,9 +983,11 @@ em_ioctl(struct ifnet *ifp, u_long comma */ ifp->if_flags |=3D IFF_UP; if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) { - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); em_init_locked(adapter); - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); } arp_ifinit(ifp, ifa); } else @@ -988,7 +1000,8 @@ em_ioctl(struct ifnet *ifp, u_long comma =20 IOCTL_DEBUGOUT("ioctl rcv'd: SIOCSIFMTU (Set Interface MTU)"); =20 - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); switch (adapter->hw.mac.type) { case e1000_82573: /* @@ -1019,7 +1032,8 @@ em_ioctl(struct ifnet *ifp, u_long comma } if (ifr->ifr_mtu > max_frame_size - ETHER_HDR_LEN - ETHER_CRC_LEN) { - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); error =3D EINVAL; break; } @@ -1028,13 +1042,15 @@ em_ioctl(struct ifnet *ifp, u_long comma adapter->hw.mac.max_frame_size =3D ifp->if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN; em_init_locked(adapter); - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); break; } case SIOCSIFFLAGS: IOCTL_DEBUGOUT("ioctl rcv'd:\ SIOCSIFFLAGS (Set Interface Flags)"); - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); if (ifp->if_flags & IFF_UP) { if ((ifp->if_drv_flags & IFF_DRV_RUNNING)) { if ((ifp->if_flags ^ adapter->if_flags) & @@ -1048,13 +1064,15 @@ em_ioctl(struct ifnet *ifp, u_long comma if (ifp->if_drv_flags & IFF_DRV_RUNNING) em_stop(adapter); adapter->if_flags =3D ifp->if_flags; - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); break; case SIOCADDMULTI: case SIOCDELMULTI: IOCTL_DEBUGOUT("ioctl rcv'd: SIOC(ADD|DEL)MULTI"); if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); em_disable_intr(adapter); em_set_multi(adapter); if (adapter->hw.mac.type =3D=3D e1000_82542 &&=20 @@ -1065,19 +1083,23 @@ em_ioctl(struct ifnet *ifp, u_long comma if (!(ifp->if_capenable & IFCAP_POLLING)) #endif em_enable_intr(adapter); - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); } break; case SIOCSIFMEDIA: /* Check SOL/IDER usage */ - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); if (e1000_check_reset_block(&adapter->hw)) { - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); device_printf(adapter->dev, "Media change is" " blocked due to SOL/IDER session.\n"); break; } - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); case SIOCGIFMEDIA: IOCTL_DEBUGOUT("ioctl rcv'd: \ SIOCxIFMEDIA (Get/Set Interface Media)"); @@ -1096,17 +1118,21 @@ em_ioctl(struct ifnet *ifp, u_long comma error =3D ether_poll_register(em_poll, ifp); if (error) return (error); - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); em_disable_intr(adapter); ifp->if_capenable |=3D IFCAP_POLLING; - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); } else { error =3D ether_poll_deregister(ifp); /* Enable interrupt even in error case */ - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); em_enable_intr(adapter); ifp->if_capenable &=3D ~IFCAP_POLLING; - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); } } #endif @@ -1149,29 +1175,49 @@ static void em_watchdog(struct adapter *adapter) { =20 - EM_LOCK_ASSERT(adapter); + EM_TXLOCK_ASSERT(adapter); =20 - /* - ** The timer is set to 5 every time start queues a packet. - ** Then txeof keeps resetting to 5 as long as it cleans at - ** least one descriptor. - ** Finally, anytime all descriptors are clean the timer is - ** set to 0. - */ - if (adapter->watchdog_timer =3D=3D 0 || --adapter->watchdog_timer) - return; + if (E1000_READ_REG(&adapter->hw, E1000_TDH) =3D=3D + E1000_READ_REG(&adapter->hw, E1000_TDT)) { + /* TX queue is clean. Nothing to wait */ + adapter->tx_counter_watchdog_mark =3D 0; + } =20 /* If we are in this routine because of pause frames, then * don't reset the hardware. */ if (E1000_READ_REG(&adapter->hw, E1000_STATUS) & E1000_STATUS_TXOFF) { - adapter->watchdog_timer =3D EM_TX_TIMEOUT; + /* XOFF received */ + adapter->tx_counter_watchdog_mark =3D 0; + return; + } + + if (!adapter->tx_counter_watchdog_mark) { + /* watchdog isn't started yet, let's do it */ + adapter->tx_counter_watchdog_mark =3D adapter->tx_counter; + adapter->tx_tdh_watchdog_mark =3D E1000_READ_REG(&adapter->hw, E1000_T= DH); + return; + } + + if (adapter->tx_counter - adapter->tx_counter_watchdog_mark >=3D adapte= r->num_tx_desc) { + /* TX ring has been wrapped, clean watchdog condition */ + adapter->tx_counter_watchdog_mark =3D 0; return; } =20 - if (e1000_check_for_link(&adapter->hw) =3D=3D 0) + if (adapter->tx_tdh_watchdog_mark !=3D E1000_READ_REG(&adapter->hw, E10= 00_TDH)) { + /* Something were sent */ + adapter->tx_counter_watchdog_mark =3D 0; + return; + } + + if (e1000_check_for_link(&adapter->hw) =3D=3D 0) { device_printf(adapter->dev, "watchdog timeout -- resetting\n"); + em_print_hw_stats(adapter); + em_print_debug_info(adapter); + } + adapter->ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; adapter->watchdog_events++; =20 @@ -1198,7 +1244,8 @@ em_init_locked(struct adapter *adapter) =20 INIT_DEBUGOUT("em_init: begin"); =20 - EM_LOCK_ASSERT(adapter); + EM_RXLOCK_ASSERT(adapter); + EM_TXLOCK_ASSERT(adapter); =20 em_stop(adapter); =20 @@ -1337,9 +1384,11 @@ em_init(void *arg) { struct adapter *adapter =3D arg; =20 - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); em_init_locked(adapter); - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); } =20 =20 @@ -1355,9 +1404,11 @@ em_poll(struct ifnet *ifp, enum poll_cmd struct adapter *adapter =3D ifp->if_softc; uint32_t reg_icr; =20 - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); if ((ifp->if_drv_flags & IFF_DRV_RUNNING) =3D=3D 0) { - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); return; } =20 @@ -1372,12 +1423,13 @@ em_poll(struct ifnet *ifp, enum poll_cmd em_local_timer, adapter); } } - em_rxeof(adapter, count); + em_rxeof(adapter, count, 0); em_txeof(adapter); =20 if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) em_start_locked(ifp); - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); } =20 /********************************************************************* @@ -1393,11 +1445,11 @@ em_intr(void *arg) struct ifnet *ifp; uint32_t reg_icr; =20 - EM_LOCK(adapter); + /* XXX EM_LOCK(adapter); */ ifp =3D adapter->ifp; =20 if (ifp->if_capenable & IFCAP_POLLING) { - EM_UNLOCK(adapter); + /* EM_UNLOCK(adapter); */ return; } =20 @@ -1419,29 +1471,35 @@ em_intr(void *arg) if (reg_icr =3D=3D 0xffffffff) break; =20 - if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - em_rxeof(adapter, -1); - em_txeof(adapter); - } - /* Link status change */ if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); callout_stop(&adapter->timer); adapter->hw.mac.get_link_status =3D 1; e1000_check_for_link(&adapter->hw); em_update_link_status(adapter); callout_reset(&adapter->timer, hz, em_local_timer, adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); + } + if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + if (reg_icr & (E1000_ICR_RXDMT0|E1000_ICR_RXO|E1000_ICR_RXT0)) { + EM_RXLOCK(adapter); + em_rxeof(adapter, -1,0); + EM_RXUNLOCK(adapter); + } + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { + EM_TXLOCK(adapter); + em_start_locked(ifp); + EM_TXUNLOCK(adapter); + } } =20 if (reg_icr & E1000_ICR_RXO) adapter->rx_overruns++; } - - if (ifp->if_drv_flags & IFF_DRV_RUNNING && - !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - em_start_locked(ifp); - EM_UNLOCK(adapter); } =20 #else /* if not DEVICE_POLLING, then fast interrupt routines only */ @@ -1454,9 +1512,11 @@ em_handle_link(void *context, int pendin =20 ifp =3D adapter->ifp; =20 - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) { - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); return; } =20 @@ -1465,33 +1525,37 @@ em_handle_link(void *context, int pendin e1000_check_for_link(&adapter->hw); em_update_link_status(adapter); callout_reset(&adapter->timer, hz, em_local_timer, adapter); - EM_UNLOCK(adapter); + + wakeup (&adapter->rxmtx); + wakeup (&adapter->txmtx); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); } =20 static void -em_handle_rxtx(void *context, int pending) +em_kthread_rx(void *arg) { - struct adapter *adapter =3D context; - struct ifnet *ifp; + struct adapter *adapter =3D arg; + struct ifnet *ifp =3D adapter->ifp; + int myKthreadNo =3D 0; =20 - ifp =3D adapter->ifp; + EM_RXLOCK(adapter); + myKthreadNo =3D adapter -> rxKthreadNo ++; + adapter -> rxIpBeingProcessed[myKthreadNo] =3D 0; + adapter -> waitedBy[myKthreadNo] =3D 0; + EM_RXUNLOCK(adapter); =20 - /* - * TODO: - * It should be possible to run the tx clean loop without the lock. - */ - if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - if (em_rxeof(adapter, adapter->rx_process_limit) !=3D 0) - taskqueue_enqueue(adapter->tq, &adapter->rxtx_task); - EM_LOCK(adapter); - em_txeof(adapter); - - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - em_start_locked(ifp); - EM_UNLOCK(adapter); + while (!adapter->rx_shutdown_flag) { + tsleep(&adapter->rxmtx, adapter->rx_kthread_priority, "em_rx", hz); + if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + EM_RXLOCK(adapter); + em_rxeof(adapter,-1, myKthreadNo); + EM_RXUNLOCK(adapter); + } + em_enable_intr_rx(adapter); } =20 - em_enable_intr(adapter); + kthread_exit(0); } =20 /********************************************************************* @@ -1526,13 +1590,17 @@ em_intr_fast(void *arg) (reg_icr & E1000_ICR_INT_ASSERTED) =3D=3D 0) return (FILTER_STRAY); =20 - /* - * Mask interrupts until the taskqueue is finished running. This is - * cheap, just assume that it is needed. This also works around the - * MSI message reordering errata on certain systems. - */ - em_disable_intr(adapter); - taskqueue_enqueue(adapter->tq, &adapter->rxtx_task); + if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + if (reg_icr & (E1000_ICR_RXDMT0|E1000_ICR_RXO|E1000_ICR_RXT0)) { + /* + * Mask interrupts until the taskqueue is finished running. This is + * cheap, just assume that it is needed. This also works around the + * MSI message reordering errata on certain systems. + */ + em_disable_intr_rx (adapter); + wakeup (&adapter->rxmtx); + } + } =20 /* Link status change */ if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) @@ -1560,7 +1628,8 @@ em_media_status(struct ifnet *ifp, struc =20 INIT_DEBUGOUT("em_media_status: begin"); =20 - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); e1000_check_for_link(&adapter->hw); em_update_link_status(adapter); =20 @@ -1568,7 +1637,8 @@ em_media_status(struct ifnet *ifp, struc ifmr->ifm_active =3D IFM_ETHER; =20 if (!adapter->link_active) { - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); return; } =20 @@ -1596,7 +1666,8 @@ em_media_status(struct ifnet *ifp, struc else ifmr->ifm_active |=3D IFM_HDX; } - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); } =20 /********************************************************************* @@ -1618,7 +1689,8 @@ em_media_change(struct ifnet *ifp) if (IFM_TYPE(ifm->ifm_media) !=3D IFM_ETHER) return (EINVAL); =20 - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); switch (IFM_SUBTYPE(ifm->ifm_media)) { case IFM_AUTO: adapter->hw.mac.autoneg =3D DO_AUTO_NEG; @@ -1656,7 +1728,8 @@ em_media_change(struct ifnet *ifp) adapter->hw.phy.reset_disable =3D FALSE; =20 em_init_locked(adapter); - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); =20 return (0); } @@ -2130,7 +2203,8 @@ em_82547_move_tail(void *arg) uint16_t length =3D 0; boolean_t eop =3D 0; =20 - EM_LOCK_ASSERT(adapter); + EM_RXLOCK_ASSERT(adapter); + EM_TXLOCK_ASSERT(adapter); =20 hw_tdt =3D E1000_READ_REG(&adapter->hw, E1000_TDT); sw_tdt =3D adapter->next_avail_tx_desc; @@ -2337,7 +2411,8 @@ em_local_timer(void *arg) struct adapter *adapter =3D arg; struct ifnet *ifp =3D adapter->ifp; =20 - EM_LOCK_ASSERT(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); =20 e1000_check_for_link(&adapter->hw); em_update_link_status(adapter); @@ -2359,6 +2434,9 @@ em_local_timer(void *arg) em_watchdog(adapter); =20 callout_reset(&adapter->timer, hz, em_local_timer, adapter); + + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); } =20 static void @@ -2419,7 +2497,8 @@ em_stop(void *arg) struct adapter *adapter =3D arg; struct ifnet *ifp =3D adapter->ifp; =20 - EM_LOCK_ASSERT(adapter); + EM_RXLOCK_ASSERT(adapter); + EM_TXLOCK_ASSERT(adapter); =20 INIT_DEBUGOUT("em_stop: begin"); =20 @@ -2606,19 +2685,22 @@ em_allocate_intr(struct adapter *adapter * Try allocating a fast interrupt and the associated deferred * processing contexts. */ - TASK_INIT(&adapter->rxtx_task, 0, em_handle_rxtx, adapter); - TASK_INIT(&adapter->link_task, 0, em_handle_link, adapter); - adapter->tq =3D taskqueue_create_fast("em_taskq", M_NOWAIT, - taskqueue_thread_enqueue, &adapter->tq); - taskqueue_start_threads(&adapter->tq, 1, PI_NET, "%s taskq", - device_get_nameunit(adapter->dev)); + TASK_INIT(&adapter->link_task, INTR_TYPE_NET | INTR_MPSAFE, em_handle_l= ink, adapter); + + adapter->rx_shutdown_flag=3DFALSE; + adapter->rxKthreadNo=3D0; + adapter->reorder_cnt=3D0; + for (int i =3D 0; i < RX_KTHREADS_NUM; i++) { + adapter->rx_kthreads_handles[i] =3D NULL; + kthread_create (em_kthread_rx, adapter, adapter->rx_kthreads_handles += i,=20 + INTR_TYPE_NET | INTR_FAST | INTR_MPSAFE, 0, "%s_rx_kthread_%d",device= _get_nameunit(dev),i); + } + if ((error =3D bus_setup_intr(dev, adapter->res_interrupt, - INTR_TYPE_NET, em_intr_fast, NULL, adapter, + INTR_TYPE_NET | INTR_FAST | INTR_MPSAFE, em_intr_fast, NULL, adapte= r, &adapter->int_handler_tag)) !=3D 0) { device_printf(dev, "Failed to register fast interrupt " "handler: %d\n", error); - taskqueue_free(adapter->tq); - adapter->tq =3D NULL; return (error); } #endif=20 @@ -2637,11 +2719,12 @@ em_free_intr(struct adapter *adapter) adapter->int_handler_tag); adapter->int_handler_tag =3D NULL; } - if (adapter->tq !=3D NULL) { - taskqueue_drain(adapter->tq, &adapter->rxtx_task); - taskqueue_drain(taskqueue_fast, &adapter->link_task); - taskqueue_free(adapter->tq); - adapter->tq =3D NULL; + taskqueue_drain(taskqueue_fast, &adapter->link_task); + + adapter->rx_shutdown_flag=3DTRUE; + for (int i =3D 0; i < RX_KTHREADS_NUM; i++) { + if (adapter->rx_kthreads_handles[i]) + tsleep(adapter->rx_kthreads_handles[i], 0, "RXSTOP", 3*hz); } } =20 @@ -3138,7 +3221,7 @@ em_initialize_transmit_unit(struct adapt E1000_WRITE_REG(&adapter->hw, E1000_TIDV, adapter->tx_int_delay.value);= if(adapter->hw.mac.type >=3D e1000_82540) E1000_WRITE_REG(&adapter->hw, E1000_TADV, - adapter->tx_abs_int_delay.value); + EM_USECS_TO_TICKS(adapter->tx_abs_int_delay.value)); =20 if ((adapter->hw.mac.type =3D=3D e1000_82571) || (adapter->hw.mac.type =3D=3D e1000_82572)) { @@ -3364,6 +3447,10 @@ em_transmit_checksum_setup(struct adapte =20 adapter->num_tx_desc_avail--; adapter->next_avail_tx_desc =3D curr_txd; + + adapter->tx_counter=3D0; + adapter->tx_counter_watchdog_mark=3D0; + adapter->tx_tdh_watchdog_mark=3D0; } =20 /********************************************************************** @@ -3736,7 +3823,7 @@ em_txeof(struct adapter *adapter) struct e1000_tx_desc *tx_desc, *eop_desc; struct ifnet *ifp =3D adapter->ifp; =20 - EM_LOCK_ASSERT(adapter); + EM_TXLOCK_ASSERT(adapter); =20 if (adapter->num_tx_desc_avail =3D=3D adapter->num_tx_desc) return; @@ -3809,15 +3896,8 @@ em_txeof(struct adapter *adapter) * If there are no pending descriptors, clear the timeout. Other= wise, * if some descriptors have been freed, restart the timeout. */ - if (num_avail > EM_TX_CLEANUP_THRESHOLD) { =20 + if (num_avail > EM_TX_CLEANUP_THRESHOLD) ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; - /* All clean, turn off the timer */ - if (num_avail =3D=3D adapter->num_tx_desc) - adapter->watchdog_timer =3D 0; - /* Some cleaned, reset the timer */ - else if (num_avail !=3D adapter->num_tx_desc_avail) - adapter->watchdog_timer =3D EM_TX_TIMEOUT; - } adapter->num_tx_desc_avail =3D num_avail; return; } @@ -4144,7 +4224,7 @@ em_free_receive_structures(struct adapte * *********************************************************************/ static int -em_rxeof(struct adapter *adapter, int count) +em_rxeof(struct adapter *adapter, int count, int myKthreadNo) { struct ifnet *ifp; struct mbuf *mp; @@ -4298,15 +4378,57 @@ discard: if (++i =3D=3D adapter->num_rx_desc) i =3D 0; if (m !=3D NULL) { + struct ip *ip =3D mtod(m, struct ip *); + adapter->next_rx_desc_to_check =3D i; -#ifdef DEVICE_POLLING - EM_UNLOCK(adapter); - (*ifp->if_input)(ifp, m); - EM_LOCK(adapter); -#else - /* Already running unlocked */ + + /* + * Trick to avoid reorder: + * + * Don't allow change order of tcp packets + * in same session. In order to make this + * easier, we will not allow to process packets + * from one same source with more than one CPU. + */ + int hlen =3D ip->ip_hl << 2; + if (hlen >=3D sizeof(struct ip)) { /* minimum header length */ + adapter -> rxIpBeingProcessed[myKthreadNo]=3Dip->ip_src.s_addr; + + if (ip->ip_src.s_addr) + for (int k=3D0; k < RX_KTHREADS_NUM; k++) { + if ((adapter->rxIpBeingProcessed[k] =3D=3D ip->ip_src.s_addr)=20 + && !adapter->waitedBy[k]) { + /* + * Packet from the same IP is being processed + * by another thread, wait until that was done. + */ + adapter->reorder_cnt++;=20 + adapter->waitedBy[k] =3D myKthreadNo; + msleep(adapter->rxIpBeingProcessed+k, + &adapter->rxmtx, + adapter->rx_kthread_priority, + "RORDER", -1); + } + } + } else=20 + ip =3D NULL; + + EM_RXUNLOCK(adapter); + (*ifp->if_input)(ifp, m); -#endif + + EM_RXLOCK(adapter); + + adapter->rxIpBeingProcessed[myKthreadNo]=3D0; + + if (adapter->waitedBy[myKthreadNo]) { + /* + * Wakeup threads blocking on our packet process + * procedure due to the reorder prevention check + */ + wakeup(adapter->rxIpBeingProcessed+myKthreadNo); + adapter->waitedBy[myKthreadNo] =3D 0; + } i =3D adapter->next_rx_desc_to_check; } current_desc =3D &adapter->rx_desc_base[i]; @@ -4438,6 +4560,18 @@ em_disable_intr(struct adapter *adapter) E1000_WRITE_REG(&adapter->hw, E1000_IMC, 0xffffffff); } =20 +static void +em_enable_intr_rx(struct adapter *adapter) +{ + E1000_WRITE_REG(&adapter->hw, E1000_IMS, E1000_IMS_RXT0 | E1000_IMS_RXD= MT0 | E1000_IMS_RXO); +} + +static void +em_disable_intr_rx(struct adapter *adapter) +{ + E1000_WRITE_REG(&adapter->hw, E1000_IMC, E1000_IMS_RXT0 | E1000_IMS_RXD= MT0 | E1000_IMS_RXO); +} + /* * Bit of a misnomer, what this really means is * to enable OS management of the system... aka @@ -4878,6 +5012,8 @@ em_print_debug_info(struct adapter *adap adapter->dropped_pkts); device_printf(dev, "Driver tx dma failure in encap =3D %ld\n", adapter->no_tx_dma_setup); + device_printf(dev, "Packets pended due to reorder =3D %ld\n", + adapter->reorder_cnt); } =20 static void @@ -4996,7 +5132,8 @@ em_sysctl_int_delay(SYSCTL_HANDLER_ARGS) =20 adapter =3D info->adapter; =09 - EM_LOCK(adapter); + EM_RXLOCK(adapter); + EM_TXLOCK(adapter); regval =3D E1000_READ_OFFSET(&adapter->hw, info->offset); regval =3D (regval & ~0xffff) | (ticks & 0xffff); /* Handle a few special cases. */ @@ -5014,7 +5151,8 @@ em_sysctl_int_delay(SYSCTL_HANDLER_ARGS) break; } E1000_WRITE_OFFSET(&adapter->hw, info->offset, regval); - EM_UNLOCK(adapter); + EM_TXUNLOCK(adapter); + EM_RXUNLOCK(adapter); return (0); } =20 @@ -5034,7 +5172,7 @@ em_add_int_delay_sysctl(struct adapter * =20 #ifndef DEVICE_POLLING static void -em_add_rx_process_limit(struct adapter *adapter, const char *name, +em_add_int_rx_kthread_priority(struct adapter *adapter, const char *name= , const char *description, int *limit, int value) { *limit =3D value; Index: if_em.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/em/if_em.h,v retrieving revision 1.62 diff -u -p -r1.62 if_em.h --- if_em.h 10 Sep 2007 21:50:40 -0000 1.62 +++ if_em.h 3 Oct 2007 21:35:44 -0000 @@ -82,7 +82,7 @@ POSSIBILITY OF SUCH DAMAGE. * system is reporting dropped transmits, this value may be set too hi= gh * causing the driver to run out of available transmit descriptors. */ -#define EM_TIDV 64 +#define EM_TIDV 65535 =20 /* * EM_TADV - Transmit Absolute Interrupt Delay Value @@ -96,7 +96,7 @@ POSSIBILITY OF SUCH DAMAGE. * along with EM_TIDV, may improve traffic throughput in specific * network conditions. */ -#define EM_TADV 64 +#define EM_TADV 65535 =20 /* * EM_RDTR - Receive Interrupt Delay Timer (Packet Timer) @@ -130,12 +130,12 @@ POSSIBILITY OF SUCH DAMAGE. * along with EM_RDTR, may improve traffic throughput in specific netw= ork * conditions. */ -#define EM_RADV 64 +#define EM_RADV 977 =20 /* * This parameter controls the duration of transmit watchdog timer. */ -#define EM_TX_TIMEOUT 5 /* set to 5 seconds */ +#define EM_TX_TIMEOUT 2 /* set to 2 seconds */ =20 /* * This parameter controls when the driver calls the routine to reclaim @@ -270,15 +270,31 @@ struct adapter { struct ifmedia media; struct callout timer; struct callout tx_fifo_timer; - int watchdog_timer; + + unsigned tx_counter; + unsigned tx_counter_watchdog_mark; + unsigned tx_tdh_watchdog_mark; + int io_rid; int msi; int if_flags; - struct mtx mtx; int em_insert_vlan_header; +=09 + /* RX/TX locks */ + struct mtx rxmtx; + struct mtx txmtx; + struct task link_task; - struct task rxtx_task; - struct taskqueue *tq; /* private task queue */ + +#define RX_KTHREADS_NUM 2 + struct proc *rx_kthreads_handles[RX_KTHREADS_NUM]; + int rx_shutdown_flag; + + in_addr_t rxIpBeingProcessed[RX_KTHREADS_NUM]; + int waitedBy[RX_KTHREADS_NUM]; + int rxKthreadNo; + unsigned long reorder_cnt; + /* Management and WOL features */ int wol; int has_manage; @@ -333,7 +349,7 @@ struct adapter { uint32_t next_rx_desc_to_check; uint32_t rx_buffer_len; uint16_t num_rx_desc; - int rx_process_limit; + int rx_kthread_priority; struct em_buffer *rx_buffer_area; bus_dma_tag_t rxtag; bus_dmamap_t rx_sparemap; @@ -413,11 +429,20 @@ typedef struct _DESCRIPTOR_PAIR uint32_t elements; } DESC_ARRAY, *PDESC_ARRAY; =20 -#define EM_LOCK_INIT(_sc, _name) \ - mtx_init(&(_sc)->mtx, _name, MTX_NETWORK_LOCK, MTX_DEF) -#define EM_LOCK_DESTROY(_sc) mtx_destroy(&(_sc)->mtx) -#define EM_LOCK(_sc) mtx_lock(&(_sc)->mtx) -#define EM_UNLOCK(_sc) mtx_unlock(&(_sc)->mtx) -#define EM_LOCK_ASSERT(_sc) mtx_assert(&(_sc)->mtx, MA_OWNED) +#define EM_RXLOCK_INIT(_sc, _name) \ + mtx_init(&(_sc)->rxmtx, _name, MTX_NETWORK_LOCK, MTX_DEF) +#define EM_RXLOCK_DESTROY(_sc) mtx_destroy(&(_sc)->rxmtx) +#define EM_RXLOCK(_sc) mtx_lock(&(_sc)->rxmtx) +#define EM_RXTRYLOCK(_sc) mtx_trylock(&(_sc)->rxmtx) +#define EM_RXUNLOCK(_sc) mtx_unlock(&(_sc)->rxmtx) +#define EM_RXLOCK_ASSERT(_sc) mtx_assert(&(_sc)->rxmtx, MA_OWNED) + +#define EM_TXLOCK_INIT(_sc, _name) \ + mtx_init(&(_sc)->txmtx, _name, MTX_NETWORK_LOCK, MTX_DEF) +#define EM_TXLOCK_DESTROY(_sc) mtx_destroy(&(_sc)->txmtx) +#define EM_TXLOCK(_sc) mtx_lock(&(_sc)->txmtx) +#define EM_TXTRYLOCK(_sc) mtx_trylock(&(_sc)->txmtx) +#define EM_TXUNLOCK(_sc) mtx_unlock(&(_sc)->txmtx) +#define EM_TXLOCK_ASSERT(_sc) mtx_assert(&(_sc)->txmtx, MA_OWNED) =20 #endif /* _EM_H_DEFINED_ */ --------------060708020602090500090901-- --------------enig19778564B8230D4BDB26AB74 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBA2DOfuToMruuMARCkW+AJ9c5eeADIOjd342XJj+h7rv/kiANACcD/g9 Lm8kC0mqO1eP/nH33NN1NAc= =rPFn -----END PGP SIGNATURE----- --------------enig19778564B8230D4BDB26AB74-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 21:48: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 897A716A51C for ; Wed, 3 Oct 2007 21:48:02 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5703913C45A for ; Wed, 3 Oct 2007 21:48:02 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IdBzf-00073j-56 for freebsd-net@freebsd.org; Wed, 03 Oct 2007 21:42:59 +0000 Received: from 89-172-50-225.adsl.net.t-com.hr ([89.172.50.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Oct 2007 21:42:59 +0000 Received: from ivoras by 89-172-50-225.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Oct 2007 21:42:59 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Wed, 03 Oct 2007 23:29:25 +0200 Lines: 33 Message-ID: References: <4703F9C3.2060601@net.utcluj.ro> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD4F9BD07D323071433B098F7" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-50-225.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <4703F9C3.2060601@net.utcluj.ro> X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: FreeBSD as a gigabit 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: Wed, 03 Oct 2007 21:48:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD4F9BD07D323071433B098F7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cristian KLEIN wrote: > Can anybody point me what the bottleneck of this configuration is? CPU = was > mostly idle and PCIe 1x should carry way more. Or is the experiment per= haps > fundamentally flawed? A "generic" problem in your case might be ICMP limiting which is turned on in FreeBSD by default. See net.inet.icmp.icmplim sysctl. --------------enigD4F9BD07D323071433B098F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBAm1ldnAQVacBcgRAolyAJ0R9WmxU14F0Uz6TSkdnx/tQBs00ACgrJxd kS8jngpVGW0Ri6272FUby7M= =PR7k -----END PGP SIGNATURE----- --------------enigD4F9BD07D323071433B098F7-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 22:23: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 C29A316A480 for ; Wed, 3 Oct 2007 22:23:42 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by mx1.freebsd.org (Postfix) with ESMTP id 63E2913C458 for ; Wed, 3 Oct 2007 22:23:42 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so2490544wra for ; Wed, 03 Oct 2007 15:23:41 -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:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=SQV8h8opqzmDAuelC8V1ZnDyDrIvei9uVEV/M2h+H24=; b=lbeAkDa//7g3mQvsyTu+PYU9EuOV6mgn6MnlfPfuAJtT0NP3fA+2FbVx6DrZFhgxLW0bHyiRj1sIt+JRo7aSaiW3DXrYGxoaoYiUTul+muWCW2ruzO3PEnokKB7OG/I5Y6KJogS3wckCgDGbqhgDErhdOMtZdvyBeyxBGpgQPag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=urwDelmwlpsfbXGB/XJpqB41HtqpQIck+dse6YBeFAfqEHGy1Q/MJxBmh/MSsMh4kzD9ISD/xBXLhPYo95ZTYIE0O6DRoSWoN/1SJ0O5sfcvy6FvctVP83SjEy/48LCs4wvFh/YP4LtEXt0kbF0taGt0z7LH4gbbaB5TtUXLYxs= Received: by 10.142.222.21 with SMTP id u21mr92352wfg.1191450221025; Wed, 03 Oct 2007 15:23:41 -0700 (PDT) Received: by 10.140.192.2 with HTTP; Wed, 3 Oct 2007 15:23:41 -0700 (PDT) Message-ID: <2e77fc10710031523w35792c4dmf7494572490c10af@mail.gmail.com> Date: Thu, 4 Oct 2007 01:23:41 +0300 From: "Niki Denev" Sender: ndenev@gmail.com To: freebsd-net@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4703F9C3.2060601@net.utcluj.ro> X-Google-Sender-Auth: d75542c6c03e4a80 Subject: Re: FreeBSD as a gigabit 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: Wed, 03 Oct 2007 22:23:42 -0000 2007/10/4, Ivan Voras : > Cristian KLEIN wrote: > > > Can anybody point me what the bottleneck of this configuration is? CPU was > > mostly idle and PCIe 1x should carry way more. Or is the experiment perhaps > > fundamentally flawed? > > A "generic" problem in your case might be ICMP limiting which is turned > on in FreeBSD by default. See net.inet.icmp.icmplim sysctl. > > Also ping -f itself does not try to saturate the link to the max. The manual states : -f Flood ping. Outputs packets as fast as they come back or one hundred times per second, whichever is more. -- Niki From owner-freebsd-net@FreeBSD.ORG Wed Oct 3 23:18: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 A6B3216A418 for ; Wed, 3 Oct 2007 23:18:54 +0000 (UTC) (envelope-from lists@codeangels.com) Received: from mail.codeangels.com (mail.codeangels.com [80.238.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 145A113C45D for ; Wed, 3 Oct 2007 23:18:53 +0000 (UTC) (envelope-from lists@codeangels.com) Received: (qmail-ldap/ctrl 648 invoked from network); 3 Oct 2007 22:52:11 -0000 Received: from monkey.codeangels.com (HELO www.codeangels.com) (jraslk@[192.168.5.6]) (envelope-sender ) by monkey.codeangels.com (qmail-ldap-1.03) with SMTP for ; 3 Oct 2007 22:52:11 -0000 Message-ID: <4532.192.168.2.137.1191451931.squirrel@www.codeangels.com> In-Reply-To: <4703F9C3.2060601@net.utcluj.ro> References: <4703F9C3.2060601@net.utcluj.ro> Date: Thu, 4 Oct 2007 00:52:11 +0200 (CEST) From: "Kirill Ponazdyr" To: "Cristian KLEIN" User-Agent: SquirrelMail/Codeangels_GEN MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD as a gigabit router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@codeangels.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 23:18:54 -0000 > Hi list, > > A few days ago I tested whether a FreeBSD 7 box is able to handle Gigabit > Can anybody point me what the bottleneck of this configuration is? CPU was > mostly idle and PCIe 1x should carry way more. Or is the experiment > perhaps > fundamentally flawed? ICMP is not a good way to perform such tests as many have mentioned, better use iperf. We have a FreeBSD 6.2 / pf box handling 2Gbps of traffic, real traffic, it will probably handle more, we just had no capacities or need to test. Hardware is a Single 2.4 Ghz Xeon with 2 x Intel Quad Pro 1000MT PCI-X Controllers on separate PCI-X Busses. Here are most optimal options: Kernel: ------------------------------------ options DEVICE_POLLING options HZ=2000 Sysctl: ------------------------------------ kern.polling.idle_poll=1 kern.polling.user_frac=20 net.inet.ip.fastforwarding=1 net.inet.ip.intr_queue_maxlen=5000 kern.ipc.maxsockbuf=8388608 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.rfc1323=1 Regards Kirill From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 01:09: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 C3E1B16A47B for ; Thu, 4 Oct 2007 01:09:46 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by mx1.freebsd.org (Postfix) with ESMTP id 7D55313C4BA for ; Thu, 4 Oct 2007 01:09:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so4295nzf for ; Wed, 03 Oct 2007 18:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=pR59+52cPXAR9m6CjoBw9vCbfEgVUTfZgIGvZXy63ro=; b=f9xuoXvXGXOfNd4F+sEsGKit9xdWaZe8edreB+HNMHLesSCpz8Gk1prf+Cg0Ss2HrF0H4gSuD8Wtbj0cv/Bnf2tp7NamiJ/1GmPt2/m1kv4g3Neo3tXMKG40bjvg0YSNPIlN7MWHXsq6fXr0QJXrsGSQ1OdndxUfWy+qTQb5wyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=PR3tNW5BP2o0n/pZm5GKrCFFS8SdHxxCnkBPcN1YDYxaaOVhkSvkPxAsv8ihwCqGdr+lEv1lztVH5mrqtzxGIpimkFjgxsyjdhblWpfn3Eo9rhKozI3c3lff1Xlj4eFuvrkpKn+KRqwgFtwNp5aO6L2UoJtjeFlP23mh5WhG5p8= Received: by 10.114.178.1 with SMTP id a1mr4914081waf.1191460180107; Wed, 03 Oct 2007 18:09:40 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id m40sm2317690waf.2007.10.03.18.09.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Oct 2007 18:09:38 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l9415vfM031078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Oct 2007 10:05:57 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l9415rru031077; Thu, 4 Oct 2007 10:05:53 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 4 Oct 2007 10:05:53 +0900 From: Pyun YongHyeon To: Cristian KLEIN Message-ID: <20071004010553.GA30781@cdnetworks.co.kr> References: <4703F9C3.2060601@net.utcluj.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4703F9C3.2060601@net.utcluj.ro> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD as a gigabit router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2007 01:09:46 -0000 On Wed, Oct 03, 2007 at 11:21:23PM +0300, Cristian KLEIN wrote: > Hi list, > > A few days ago I tested whether a FreeBSD 7 box is able to handle Gigabit > traffic. So I used a Cisco 7600 and added static routes from the router to the > box and from the box to the router, so that some packets would loop between the > two. Then I externally injected 30Mbps of "ping -f -t 255 -s ", which > should have generated a "maximum" of 3,6Gbps. I then used nload on the box to > graph the bandwidth. > > The box is a Intel Core 2 Duo, with a PCIe re NIC. I used FreeBSD i386 with > polling and fastforwarding. No WITNESS, INVARIANTS or firewalls. > Though RealTek GigE is not best suitable hardware for gigabit traffic handling how about overhauled re(4)? I've tried hard to fine tune the driver and it may have performance improvements over stock re(4). http://people.freebsd.org/~yongari/re/re.HEAD.patch > I was amased to see that injecting 1000 bytes packets gave a maximum throughput > of 650Mbps, while 1400 bytes gave 750Mbps. During both tests one core was 98% > idle, while the other one was more than 80% idle. > > Can anybody point me what the bottleneck of this configuration is? CPU was > mostly idle and PCIe 1x should carry way more. Or is the experiment perhaps > fundamentally flawed? > > Thanks. > -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 06:59: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 C1FF116A420; Thu, 4 Oct 2007 06:59:22 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id F21B713C48A; Thu, 4 Oct 2007 06:59:21 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l946leqJ009087; Thu, 4 Oct 2007 16:17:40 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 4 Oct 2007 16:29:15 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 16:29:14 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l946xDJn045804; Thu, 4 Oct 2007 14:59:13 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l946xDH7045803; Thu, 4 Oct 2007 14:59:13 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 4 Oct 2007 14:59:13 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, "freebsd-net@freebsd.org" Message-ID: <20071004065913.GG44700@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, "freebsd-net@freebsd.org" References: <2a41acea0710031052w40c10cabjf923803ba23b2546@mail.gmail.com> <20071004064736.GE44700@obelix.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20071004064736.GE44700@obelix.dsto.defence.gov.au> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 04 Oct 2007 06:59:15.0370 (UTC) FILETIME=[1377D8A0:01C80654] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1023-15462.000 X-TM-AS-Result: No--8.520600-0.000000-31 Content-Transfer-Encoding: 7bit Cc: Subject: Re: RFC: Capability addition for IEEE 1588 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Oct 2007 06:59:22 -0000 0n Thu, Oct 04, 2007 at 02:47:37PM +0800, Wilkinson, Alex wrote: > 0n Wed, Oct 03, 2007 at 10:52:43AM -0700, Jack Vogel wrote: > > >I am adding support into the em driver for PTP > >PTP ? Found http://ptpd.sourceforge.net/. Sorry for the noise. -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 07:02:02 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 BCA3616A475 for ; Thu, 4 Oct 2007 07:02:02 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 06F8E13C52C for ; Thu, 4 Oct 2007 07:01:51 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l946a5t7005844; Thu, 4 Oct 2007 16:06:05 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 4 Oct 2007 16:17:41 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 16:17:40 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l946ldg2045731; Thu, 4 Oct 2007 14:47:39 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l946lbum045730; Thu, 4 Oct 2007 14:47:37 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 4 Oct 2007 14:47:37 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, "freebsd-net@freebsd.org" Message-ID: <20071004064736.GE44700@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, "freebsd-net@freebsd.org" References: <2a41acea0710031052w40c10cabjf923803ba23b2546@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <2a41acea0710031052w40c10cabjf923803ba23b2546@mail.gmail.com> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 04 Oct 2007 06:47:41.0153 (UTC) FILETIME=[75AEBD10:01C80652] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1023-15462.000 X-TM-AS-Result: No--5.005900-0.000000-31 Content-Transfer-Encoding: 7bit Cc: Subject: Re: RFC: Capability addition for IEEE 1588 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Oct 2007 07:02:02 -0000 0n Wed, Oct 03, 2007 at 10:52:43AM -0700, Jack Vogel wrote: >I am adding support into the em driver for PTP PTP ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 14:07: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 E1B7B16A419 for ; Thu, 4 Oct 2007 14:07:07 +0000 (UTC) (envelope-from seth.mos@xs4all.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6B58A13C458 for ; Thu, 4 Oct 2007 14:07:07 +0000 (UTC) (envelope-from seth.mos@xs4all.nl) Received: from [127.0.0.1] ([194.151.164.164]) (authenticated bits=0) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id l94E75Th044782 for ; Thu, 4 Oct 2007 16:07:06 +0200 (CEST) (envelope-from seth.mos@xs4all.nl) Message-ID: <4704F388.5080506@xs4all.nl> Date: Thu, 04 Oct 2007 16:07:04 +0200 From: Seth Mos User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <46FBB7BC.3010301@xs4all.nl> In-Reply-To: <46FBB7BC.3010301@xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: Racoon 0.7 on FreeBSD 6 with a lot of VPN tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Oct 2007 14:07:08 -0000 Hello Yvan, I have tested the suggested workaorund in pfkey.c by raising the ceiling to 768kbytes from 128. I also raised the limit in the socketvar.h in FreeBSD 6 Stable from the default 128kbytes to 768kbytes. Any higher values then 768kbytes result in a integer overflow and prevents a build world of FreeBSD 6. The critical hit is around 120~130 active tunnels out of a configuration of 390. After his critical ceiling the racoon keeps getting stuck in sbwait after about 1 or 2 minutes after starting. A good way to test this with less tunnels is sending reload signals to the racoon processes which forces a lot of pfkey traffic. Which will eventually trigger the truncated pfkey socket buffer problem. The real problem is that racoon 0.6.7 and racoon 0.7 do not correctly handle a truncated socket. Instead of retrying the operation they either idle in sbwait and waiting for something that will never arrive or run away on a buffer which does not exist anymore. Any further suggestions? Kind regards, Seth Mos pfSense Developer Seth Mos schreef: > Hello there, > > I have problems with racoon hanging in sbwait state with ipsec-tools 0.6.7 > or getting into a tailspin on ipsec-tools 0.7. > > The problem is that the pfkey interface breaks down with a lot of VPN > tunnels and spd entries. The FreeBSd PR is here. > http://www.freebsd.org/cgi/query-pr.cgi?pr=115651 > > I have 390 discrete IPSEC VPN tunnels and endpoints. I have loaded this > all up into one config. I am using pfSense as the platform of choice. > pfSense 1.2-RC2 specifically which is based on FreeBSD 6.2 Stable p7. Note > that I am also a pfSense developer. > > At this current time I have exactly 112 IPSEC tunnels active. I am using > 3des-sha1 with a 3600 lifetime for phase 1 and aes128-sha1 with a 28800 > lifetime for phase2. > > On ipsec-tools 0.6.7 I can go by for several days before the racoon > process wedges itself into a hanging sbwait state (0% cpu). On ipsec-tools > 0.7 the situation is significantly worse and it starts churning 100% cpu > somewhere every 1-4 hours. > > Basically where 0.6.7 was difficult 0.7 has become unworkable. > > The hardware in question is a Dell PE860 with 6 gigabit nics (about 2mbps > ipsec traffic at most) with a DualCore Xeon 3050 2.13Ghz. With 1GB ram. > > In the pfSense kernel we use this patch. > http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/tools/patches/RELENG_6_2/socketvar.h.diff > > Which helps significantly. Without this patch the situation is the same as > I have described above but will be reached at about 30-40 active tunnels > instead of the 112 I have now. > > I really need a reliable solution to this problem. > > Kind regards, > > Seth Mos > pfSense Developer > From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 16:19: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 E3CE216A4A0 for ; Thu, 4 Oct 2007 16:19:35 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7E86013C46E for ; Thu, 4 Oct 2007 16:19:35 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 132923F1F; Thu, 4 Oct 2007 18:19:34 +0200 (CEST) Date: Thu, 4 Oct 2007 18:19:34 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20071004161933.GA5406@zen.inc> References: <46FBB7BC.3010301@xs4all.nl> <4704F388.5080506@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4704F388.5080506@xs4all.nl> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Racoon 0.7 on FreeBSD 6 with a lot of VPN tunnels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 04 Oct 2007 16:19:36 -0000 On Thu, Oct 04, 2007 at 04:07:04PM +0200, Seth Mos wrote: > Hello Yvan, Hi. > I have tested the suggested workaorund in pfkey.c by raising the ceiling > to 768kbytes from 128. > > I also raised the limit in the socketvar.h in FreeBSD 6 Stable from the > default 128kbytes to 768kbytes. > > Any higher values then 768kbytes result in a integer overflow and > prevents a build world of FreeBSD 6. Possible. I used to set up higher values a long time ago (with a fixed sbspace() macro in the kernel) but I noticed that some long are now ints. > The critical hit is around 120~130 active tunnels out of a configuration > of 390. After his critical ceiling the racoon keeps getting stuck in > sbwait after about 1 or 2 minutes after starting. I know we could get up to ~200-300 tunnels by "just" increasing the socket's buffer on old versions. > A good way to test this with less tunnels is sending reload signals to > the racoon processes which forces a lot of pfkey traffic. Which will > eventually trigger the truncated pfkey socket buffer problem. Don't worry, I know how to reproduce the problem :-) > The real problem is that racoon 0.6.7 and racoon 0.7 do not correctly > handle a truncated socket. Instead of retrying the operation they either > idle in sbwait and waiting for something that will never arrive or run > away on a buffer which does not exist anymore. I know 2 solutions: - Change the PFKey interface to avoid high number of messages. We did that for our appliances, but if this is perfect for our specific usage, this patch was not designed for general usage (we have specific buffer sizes, some structs in pfkeyv2.h have been changed, etc...). - Change the way racoon handles the PFKey messages: perhaps we could improve things by just filling an userland buffer (or a chain list, or something else) when we get such PFKey messages, so they would be removed quickly from the socket's buffer, then only parse our userland buffer/list once we know we got all the entries. I'll have a quick look to see if the second would be easy to implement, without significant drawbacks, of course. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 18:50: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 53F9616A41B for ; Thu, 4 Oct 2007 18:50:09 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (unknown [IPv6:2001:b30:5000:2:20e:cff:fe4b:ca01]) by mx1.freebsd.org (Postfix) with ESMTP id 82DDF13C46E for ; Thu, 4 Oct 2007 18:50:08 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 7E2505084B; Thu, 4 Oct 2007 21:50:06 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on local.mail.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARNIHHMxce6K; Thu, 4 Oct 2007 21:49:59 +0300 (EEST) Received: from [172.27.2.200] (c7.campus.utcluj.ro [193.226.6.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 77C9B508B0; Thu, 4 Oct 2007 21:49:59 +0300 (EEST) Message-ID: <470535D6.7020601@net.utcluj.ro> Date: Thu, 04 Oct 2007 21:49:58 +0300 From: Cristian KLEIN User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: lists@codeangels.com References: <4703F9C3.2060601@net.utcluj.ro> <4532.192.168.2.137.1191451931.squirrel@www.codeangels.com> In-Reply-To: <4532.192.168.2.137.1191451931.squirrel@www.codeangels.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD as a gigabit 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, 04 Oct 2007 18:50:09 -0000 Thank you all for your replies. Kirill Ponazdyr wrote: >> Hi list, >> >> A few days ago I tested whether a FreeBSD 7 box is able to handle Gigabit >> Can anybody point me what the bottleneck of this configuration is? CPU was >> mostly idle and PCIe 1x should carry way more. Or is the experiment >> perhaps >> fundamentally flawed? > > ICMP is not a good way to perform such tests as many have mentioned, > better use iperf. I used this test, because it proved perfect when, almost a decade ago, gigabit appeared. There wasn't anything at that time that could fill 1 Gbps, so we used the routers themselves to do the job. Also, I used this setup to avoid TCPs congestion control mecachnism and sub-maximum bandwidth. Of course, when I said "ping -f", I didn't mean a single "ping -f", but rather enough ping -f so that the looping packets would saturate the link. > We have a FreeBSD 6.2 / pf box handling 2Gbps of traffic, real traffic, it > will probably handle more, we just had no capacities or need to test. > > Hardware is a Single 2.4 Ghz Xeon with 2 x Intel Quad Pro 1000MT PCI-X > Controllers on separate PCI-X Busses. Could you tell me, is there any difference between 1000PT and 1000MT, except the slot type? Also, is there any difference between Intel Desktop and Intel Server adaptors, or are these just marketing buzzwords? From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 19:21: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 9F0F116A417 for ; Thu, 4 Oct 2007 19:21:17 +0000 (UTC) (envelope-from michael@staff.openaccess.org) Received: from smtp-out2.openaccess.org (smtp-out2.openaccess.org [66.114.32.175]) by mx1.freebsd.org (Postfix) with ESMTP id 85E7D13C481 for ; Thu, 4 Oct 2007 19:21:17 +0000 (UTC) (envelope-from michael@staff.openaccess.org) Received: from smtp-nas.openaccess.org (smtp-nas.openaccess.org [66.114.32.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-out2.openaccess.org (Postfix) with ESMTP id E5F46797A99; Thu, 4 Oct 2007 12:02:57 -0700 (PDT) Received: from [192.168.2.151] (unknown [66.114.32.158]) by smtp-nas.openaccess.org (Postfix) with ESMTP id 5B11561641F; Thu, 4 Oct 2007 12:02:57 -0700 (PDT) In-Reply-To: <470535D6.7020601@net.utcluj.ro> References: <4703F9C3.2060601@net.utcluj.ro> <4532.192.168.2.137.1191451931.squirrel@www.codeangels.com> <470535D6.7020601@net.utcluj.ro> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <0D18E826-52EA-4BEC-9404-1C98BFCDD418@staff.openaccess.org> From: Michael DeMan Date: Thu, 4 Oct 2007 12:02:56 -0700 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.752.2) 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: lists@codeangels.com, Cristian KLEIN Subject: Re: FreeBSD as a gigabit 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, 04 Oct 2007 19:21:17 -0000 Hi All, I've done some ad-hoc testing off and on for a few years. None of the data around, but we do have a couple rules of thumb that we use internally... 1) Get the fastest PCI bus you can - PCI-X, etc. 2) Plan on 1GHz of CPU per 1 gigabit of throughput. The performance hit going from FBSD4.x to FBSD5.x/6.x was horrendous for this kind of stuff, hopefully 7.x will speed things up. Also, thus far, we have stuck only with single CPU machines to be conservative/safe. We are looking forward to a speedier TCP/IP stack in 7.x and hoping to go to SMP routers at that time also. Also, we've noticed at least on FBSD 6.x that there seem to be very few advantages in using polling on network interfaces. We still run it, so that we have responsive SSH/BGP/OSPF processes on the machines, but my testing has shown that for sheer throughput, there is basically no difference. I'd be curious if anybody knows the scoop on this. Thanks, - mike Michael F. DeMan Director of Technology OpenAccess Network Services Bellingham, WA 98225 michael@staff.openaccess.org 360-733-9279 On Oct 4, 2007, at 11:49 AM, Cristian KLEIN wrote: > Thank you all for your replies. > > Kirill Ponazdyr wrote: >>> Hi list, >>> >>> A few days ago I tested whether a FreeBSD 7 box is able to handle >>> Gigabit >>> Can anybody point me what the bottleneck of this configuration >>> is? CPU was >>> mostly idle and PCIe 1x should carry way more. Or is the experiment >>> perhaps >>> fundamentally flawed? >> >> ICMP is not a good way to perform such tests as many have mentioned, >> better use iperf. > > I used this test, because it proved perfect when, almost a decade > ago, gigabit > appeared. There wasn't anything at that time that could fill 1 > Gbps, so we used > the routers themselves to do the job. Also, I used this setup to > avoid TCPs > congestion control mecachnism and sub-maximum bandwidth. > > Of course, when I said "ping -f", I didn't mean a single "ping -f", > but rather > enough ping -f so that the looping packets would saturate the link. > >> We have a FreeBSD 6.2 / pf box handling 2Gbps of traffic, real >> traffic, it >> will probably handle more, we just had no capacities or need to test. >> >> Hardware is a Single 2.4 Ghz Xeon with 2 x Intel Quad Pro 1000MT >> PCI-X >> Controllers on separate PCI-X Busses. > > Could you tell me, is there any difference between 1000PT and > 1000MT, except the > slot type? Also, is there any difference between Intel Desktop and > Intel Server > adaptors, or are these just marketing buzzwords? > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 19:33: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 BACF416A420 for ; Thu, 4 Oct 2007 19:33:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id A822B13C4B8 for ; Thu, 4 Oct 2007 19:33:32 +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, 04 Oct 2007 12:33:31 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 2DC6F1265BE; Thu, 4 Oct 2007 12:33:31 -0700 (PDT) Message-ID: <4705400D.8040008@elischer.org> Date: Thu, 04 Oct 2007 12:33:33 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Michael DeMan References: <4703F9C3.2060601@net.utcluj.ro> <4532.192.168.2.137.1191451931.squirrel@www.codeangels.com> <470535D6.7020601@net.utcluj.ro> <0D18E826-52EA-4BEC-9404-1C98BFCDD418@staff.openaccess.org> In-Reply-To: <0D18E826-52EA-4BEC-9404-1C98BFCDD418@staff.openaccess.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Cristian KLEIN , lists@codeangels.com Subject: Re: FreeBSD as a gigabit 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, 04 Oct 2007 19:33:32 -0000 Michael DeMan wrote: > Hi All, > > I've done some ad-hoc testing off and on for a few years. None of the > data around, but we do have a couple rules of thumb that we use > internally... > > 1) Get the fastest PCI bus you can - PCI-X, etc. PCI-express outstrips PCI-X and has a number of nice characteristics.. From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 20:59: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 4867E16A420 for ; Thu, 4 Oct 2007 20:59:55 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from relanium.yandex.ru (relanium.yandex.ru [213.180.193.88]) by mx1.freebsd.org (Postfix) with ESMTP id B9C9C13C447 for ; Thu, 4 Oct 2007 20:59:54 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [87.250.227.227] (v3-227-227.yandex.net [87.250.227.227]) by relanium.yandex.ru (8.14.1/8.14.1) with ESMTP id l94KxnLm002311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2007 00:59:50 +0400 (MSD) (envelope-from wawa@yandex-team.ru) Message-ID: <47055447.3020206@yandex-team.ru> Date: Fri, 05 Oct 2007 00:59:51 +0400 From: Vladimir Ivanov Organization: Yandex LLC User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: rmkml , "freebsd-net@freebsd.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: Dr.Web (R) for Mail Servers on relanium.yandex.ru host X-Antivirus-Code: 100000 Cc: Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2007 20:59:55 -0000 rmkml wrote: > Hi Vladimir, > very thank for your work on intel em driver ! > just commented line 772 and added 773 : > 771: /* Send a copy of the frame to the BPF listener */ > 772: /* ETHER_BPF_MTAP(ifp, m_head); */ > 773: BPF_MTAP(ifp, m_head); > what is ETHER_BPF_MTAP() ? look at RELENG_6. They've moved vlan promisc hack from driver level into ethersubr. Briefly: we've to disable hardware vlan tagging if we want to tcpdump or bridge trunked port. > Best Regards > Rmkml Regards, Vladimir From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 21:38: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 8DCFE16A421 for ; Thu, 4 Oct 2007 21:38:20 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from relanium.yandex.ru (relanium.yandex.ru [213.180.193.88]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD0913C46E for ; Thu, 4 Oct 2007 21:38:19 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [87.250.227.227] (v3-227-227.yandex.net [87.250.227.227]) by relanium.yandex.ru (8.14.1/8.14.1) with ESMTP id l94Lc7wc008088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2007 01:38:16 +0400 (MSD) (envelope-from wawa@yandex-team.ru) Message-ID: <47055D3A.2020604@yandex-team.ru> Date: Fri, 05 Oct 2007 01:38:02 +0400 From: Vladimir Ivanov Organization: Yandex LLC User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: rmkml , "freebsd-net@freebsd.org" References: <47055447.3020206@yandex-team.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: Dr.Web (R) for Mail Servers on relanium.yandex.ru host X-Antivirus-Code: 100000 Cc: Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2007 21:38:20 -0000 rmkml wrote: > thx Vladimir, > I have litle tested your em driver, > quick comparaison : > kernel: sys=10% intr=25% user=15% > kernel+polling: sys=7% intr=5% user=15% > kernel+yandex_em: sys=30% intr=1% user=15% > same trafic (tcpreplay ~230Mbps) > fbsd62release_amd64 on intel core 2 duo E6600+4Go > It is possible reduce sys cpu ? I'm not sure what that digits mean :-). There is one more (see RX_KTHREADS_NUM) than usual thread started by the driver. That's why the results isn't easy to compare. Much of L/A calculation techniques depends of "number of running threads". > Regards > Rmkml > > > On Fri, 5 Oct 2007, Vladimir Ivanov wrote: > >> Date: Fri, 05 Oct 2007 00:59:51 +0400 >> From: Vladimir Ivanov >> To: rmkml , "freebsd-net@freebsd.org" >> >> Subject: Re: SMPable version of EM driver >> >> rmkml wrote: >>> Hi Vladimir, >>> very thank for your work on intel em driver ! >>> just commented line 772 and added 773 : >>> 771: /* Send a copy of the frame to the BPF listener */ >>> 772: /* ETHER_BPF_MTAP(ifp, m_head); */ >>> 773: BPF_MTAP(ifp, m_head); >>> what is ETHER_BPF_MTAP() ? >> >> look at RELENG_6. >> They've moved vlan promisc hack from driver level into ethersubr. >> Briefly: we've to disable hardware vlan tagging if we want to tcpdump >> or bridge trunked port. >> >>> Best Regards >>> Rmkml >> >> Regards, >> Vladimir >> >> From owner-freebsd-net@FreeBSD.ORG Thu Oct 4 22:31: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 92D0116A41A for ; Thu, 4 Oct 2007 22:31:00 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 529F013C4B8 for ; Thu, 4 Oct 2007 22:31:00 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IdZDP-0003l8-A5 for freebsd-net@freebsd.org; Thu, 04 Oct 2007 22:30:43 +0000 Received: from 89-172-44-103.adsl.net.t-com.hr ([89.172.44.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Oct 2007 22:30:43 +0000 Received: from ivoras by 89-172-44-103.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Oct 2007 22:30:43 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 05 Oct 2007 00:30:26 +0200 Lines: 28 Message-ID: References: <4703F9C3.2060601@net.utcluj.ro> <4532.192.168.2.137.1191451931.squirrel@www.codeangels.com> <470535D6.7020601@net.utcluj.ro> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1410B62233B6FBEF399CA137" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-44-103.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <470535D6.7020601@net.utcluj.ro> X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: FreeBSD as a gigabit 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, 04 Oct 2007 22:31:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1410B62233B6FBEF399CA137 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cristian KLEIN wrote: > Also, I used this setup to avoid TCPs > congestion control mecachnism and sub-maximum bandwidth. iperf can also run UDP tests. --------------enig1410B62233B6FBEF399CA137 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBWmDldnAQVacBcgRAstzAJ9GEduCkrZcqcgM1w+RVZVbvIVHJgCgv0i1 PX+IVXwwN5yJuJ0plpsF1fs= =NewN -----END PGP SIGNATURE----- --------------enig1410B62233B6FBEF399CA137-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 05:18: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 C7C1716A419 for ; Fri, 5 Oct 2007 05:18:51 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from alf.aws-net.org.ua (alf.aws-net.org.ua [85.90.196.192]) by mx1.freebsd.org (Postfix) with ESMTP id BF00813C45A for ; Fri, 5 Oct 2007 05:18:48 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from [192.168.32.4] (aviko.aws-net.org.ua [192.168.32.4]) by alf.aws-net.org.ua (8.13.8/8.13.8) with ESMTP id l954eKWM058045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2007 07:40:26 +0300 (EEST) (envelope-from artem@aws-net.org.ua) Message-ID: <4705C035.1020403@aws-net.org.ua> Date: Fri, 05 Oct 2007 07:40:21 +0300 From: Artyom Viklenko Organization: Art&Co. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cristian KLEIN References: <4703F9C3.2060601@net.utcluj.ro> <4532.192.168.2.137.1191451931.squirrel@www.codeangels.com> <470535D6.7020601@net.utcluj.ro> In-Reply-To: <470535D6.7020601@net.utcluj.ro> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-3.0 (alf.aws-net.org.ua [192.168.32.253]); Fri, 05 Oct 2007 07:40:27 +0300 (EEST) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on alf.aws-net.org.ua X-Virus-Status: Clean Cc: lists@codeangels.com, freebsd-net@freebsd.org Subject: Re: FreeBSD as a gigabit 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, 05 Oct 2007 05:18:51 -0000 Cristian KLEIN wrote: > Thank you all for your replies. > > Kirill Ponazdyr wrote: >>> Hi list, >>> >>> A few days ago I tested whether a FreeBSD 7 box is able to handle Gigabit >>> Can anybody point me what the bottleneck of this configuration is? CPU was >>> mostly idle and PCIe 1x should carry way more. Or is the experiment >>> perhaps >>> fundamentally flawed? >> ICMP is not a good way to perform such tests as many have mentioned, >> better use iperf. > > I used this test, because it proved perfect when, almost a decade ago, gigabit > appeared. There wasn't anything at that time that could fill 1 Gbps, so we used > the routers themselves to do the job. Also, I used this setup to avoid TCPs > congestion control mecachnism and sub-maximum bandwidth. > > Of course, when I said "ping -f", I didn't mean a single "ping -f", but rather > enough ping -f so that the looping packets would saturate the link. You can use option -i instead of -f: ping -nqs 1472 -i 0.00001 1.2.3.4 will generate large enougth amount of 1500 bytes packets. Even more, use size more than 1472 and number of packets will be increased. Value of -i parameter can be increased too. But remember about sysctl variable net.inet.ip.maxfragsperpacket. By default, in FreeBSD 6.x it's value is 16. > >> We have a FreeBSD 6.2 / pf box handling 2Gbps of traffic, real traffic, it >> will probably handle more, we just had no capacities or need to test. >> >> Hardware is a Single 2.4 Ghz Xeon with 2 x Intel Quad Pro 1000MT PCI-X >> Controllers on separate PCI-X Busses. > > Could you tell me, is there any difference between 1000PT and 1000MT, except the > slot type? Also, is there any difference between Intel Desktop and Intel Server > adaptors, or are these just marketing buzzwords? > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 11:50:38 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 22AEA16A417 for ; Fri, 5 Oct 2007 11:50:38 +0000 (UTC) (envelope-from vinuvm@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id CA6F413C447 for ; Fri, 5 Oct 2007 11:50:37 +0000 (UTC) (envelope-from vinuvm@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1001977pyb for ; Fri, 05 Oct 2007 04:50:37 -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=f579abSreQHXUv2nGn8v2XglcBAsznyNYRmWGQ51fF4=; b=qF5kgHadIbloLoqrVNev3q/PMwuYO7CrkVGCBAFuDr3Kl0hDrSJ6YsfHlMWgXmHwCQTfLlWm4pd1iJaMSrzQbWgjtaMF5XxJqmPJDC1xoEVWF1aHlRVhNYlbVldR1hBnIneX+iSAVNnYODqY8QNn6Kv1KW17qymkrZ1ty89PYzA= 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=LL93ZOJcG1BSBD0Xm0k7Gga1NNi5N0V8SJKivUbPKfzXP6JRMIfQwcBqk4otXVknqGqekSwRqGnD3+POsgtckbpUidqMSBpDLI8UthGrNnP16vHvocO/W5HlYPCSfCQjsIYCGWVEmvHRj7XsI37DWNx9tNNy1c/wsvJ/LozxG2A= Received: by 10.65.116.10 with SMTP id t10mr18426608qbm.1191583467349; Fri, 05 Oct 2007 04:24:27 -0700 (PDT) Received: by 10.65.203.1 with HTTP; Fri, 5 Oct 2007 04:24:27 -0700 (PDT) Message-ID: <8de278a20710050424t68cf95eap99cd34a13e8ce594@mail.gmail.com> Date: Fri, 5 Oct 2007 16:54:27 +0530 From: "Vinod VM" 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: cant compile - undefined reference to `bpfattach' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Oct 2007 11:50:38 -0000 Hi, I'm having trouble in compiling my code with gcc on release 6.2 I've included the following headers, stdlib.h sys/types.h sys/socket.h net/if.h net/if_var.h net/if_types.h net/bpf.h When compiling the code, i'm getting the following error message /var/tmp//ccphxfRO.o(.text+0x3c): In function `main': : undefined reference to `bpfattach' What am I doing wrong? Sorry for asking such a newbie question! From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 12:04: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 312CB16A417 for ; Fri, 5 Oct 2007 12:04:13 +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 CD05B13C49D for ; Fri, 5 Oct 2007 12:04:12 +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=oDqmaw6EwAx5MYEfry2Ezc2Dn/oLNwOMk0JBbg72NGjngP+UqdIbFBAfSVdgfveLCmEvIHaqZkFzv5JcTOkcNNq6YoefgQ0XvB1iOIyMIkGgumVIkEQ/zdTxpSNARxqdvUC3ZA/g6zM1kBPRJFqKBmSPBfmZ0hyixrgtTioQWDA=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Idlud-0009jM-Kw; Fri, 05 Oct 2007 16:04:11 +0400 Date: Fri, 5 Oct 2007 16:04:07 +0400 From: Eygene Ryabinkin To: Vinod VM Message-ID: <20071005120406.GQ971@void.codelabs.ru> References: <8de278a20710050424t68cf95eap99cd34a13e8ce594@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <8de278a20710050424t68cf95eap99cd34a13e8ce594@mail.gmail.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_20 Cc: freebsd-net@freebsd.org Subject: Re: cant compile - undefined reference to `bpfattach' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Oct 2007 12:04:13 -0000 Good day. Fri, Oct 05, 2007 at 04:54:27PM +0530, Vinod VM wrote: > I'm having trouble in compiling my code with gcc on release 6.2 > > I've included the following headers, > > stdlib.h > sys/types.h > sys/socket.h > net/if.h > net/if_var.h > net/if_types.h > net/bpf.h > > When compiling the code, i'm getting the following error message > > /var/tmp//ccphxfRO.o(.text+0x3c): In function `main': > : undefined reference to `bpfattach' If I am correct, bpfattach is the kernel-level function. And you're trying to write some user-space utility, aren't you? If you're trying to capture packets, you'll probably want to consult the pcap(3) manual page. -- Eygene From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 13:59: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 A182216A417 for ; Fri, 5 Oct 2007 13:59:41 +0000 (UTC) (envelope-from vinuvm@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id 5368813C459 for ; Fri, 5 Oct 2007 13:59:41 +0000 (UTC) (envelope-from vinuvm@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so395964nzf for ; Fri, 05 Oct 2007 06:59:40 -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=ok2z0C7xIcp0j0G1yaWdxwRBxBj425/CDsdurOk2p74=; b=GWK87yvfVNIQauuAfB1zLoaGEk0q1bOVOcl1jxUWLXNdfMX5u0k2CFz24uIyfqQkMVvhiI8PY12JpeDgSCbz0DG1BGvpia03n7P1dJk3ZY5QHicGjw84EOD4ZosFkoJKK2WJdhylInDjJePpXeZHa2n1wQOvajJxCmId4OtiEyM= 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=pPgvE5zO2Q2dD+zQsfWBvpzR7cXCFk2LnxKsT2yF64kSiz+lr2rmrbMPWJh46o0KJ8UBbxSVU4DoV2CCuE42I5jeFo60VsRtr7+wNaT3Lk1gD+vOWjdFn+LpF5PRKsTCdYKk+H9bAEucgs5L8aY9pbS/YNqQuzvT/T8vZEAny1U= Received: by 10.65.40.16 with SMTP id s16mr18230252qbj.1191592775933; Fri, 05 Oct 2007 06:59:35 -0700 (PDT) Received: by 10.65.203.1 with HTTP; Fri, 5 Oct 2007 06:59:35 -0700 (PDT) Message-ID: <8de278a20710050659y55cbc312le303f1b44452b605@mail.gmail.com> Date: Fri, 5 Oct 2007 19:29:35 +0530 From: "Vinod VM" To: "Eygene Ryabinkin" In-Reply-To: <20071005120406.GQ971@void.codelabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8de278a20710050424t68cf95eap99cd34a13e8ce594@mail.gmail.com> <20071005120406.GQ971@void.codelabs.ru> Cc: freebsd-net@freebsd.org Subject: Re: cant compile - undefined reference to `bpfattach' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Oct 2007 13:59:41 -0000 Thanks for the reply! On 10/5/07, Eygene Ryabinkin wrote: > Fri, Oct 05, 2007 at 04:54:27PM +0530, Vinod VM wrote: > > /var/tmp//ccphxfRO.o(.text+0x3c): In function `main': > > : undefined reference to `bpfattach' > > If I am correct, bpfattach is the kernel-level function. And you're > trying to write some user-space utility, aren't you? Yes. I am trying to write a program to capture from an interface and inject them to another, kind of like bcrelay functionality in poptop [http://www.poptop.org/] > If you're trying to capture packets, you'll probably want to > consult the pcap(3) manual page. Thanks! Does it support injecting packets into an interface? vinod From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 14:41: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 7D2F216A468 for ; Fri, 5 Oct 2007 14:41:35 +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 25DA313C4AC for ; Fri, 5 Oct 2007 14:41:34 +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=ROxAYlFzus3RMBefjIlh+I1+jWoEisooV1Mt42/Kw4xWPY5zA5VKJlC/jZmRxWUXQLN8NbFlzE40oiQ5/uKnkez323xdvBfT4Ac3dQKhr0ztcSJpP4CyqomQQU3tuZvLAPb4TIV/OZAQrQji5e+Uni5CaGnNAfKHIaU6yHkRlPE=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1IdoMu-000AcI-Vf; Fri, 05 Oct 2007 18:41:33 +0400 Date: Fri, 5 Oct 2007 18:41:28 +0400 From: Eygene Ryabinkin To: Vinod VM Message-ID: <20071005144128.GU971@void.codelabs.ru> References: <8de278a20710050424t68cf95eap99cd34a13e8ce594@mail.gmail.com> <20071005120406.GQ971@void.codelabs.ru> <8de278a20710050659y55cbc312le303f1b44452b605@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <8de278a20710050659y55cbc312le303f1b44452b605@mail.gmail.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_20 Cc: freebsd-net@freebsd.org Subject: Re: cant compile - undefined reference to `bpfattach' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Oct 2007 14:41:35 -0000 Fri, Oct 05, 2007 at 07:29:35PM +0530, Vinod VM wrote: > Yes. I am trying to write a program to capture from an interface and > inject them to another, kind of like bcrelay functionality in poptop > [http://www.poptop.org/] You can examine the divert sockets in FreeBSD: seems like that this will suite you too. 'man 4 divert' will give you some clues. The example of divert sockets usage is the natd program. > > If you're trying to capture packets, you'll probably want to > > consult the pcap(3) manual page. > > Thanks! Does it support injecting packets into an interface? Yes, pcap_inject and pcap_sendpacket. But this can be done via the raw sockets too. Again, 'man 3 pcap' is your friend ;)) -- Eygene From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 17:35: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 226C616A478 for ; Fri, 5 Oct 2007 17:35:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outM.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id ED74713C4C1 for ; Fri, 5 Oct 2007 17:35:45 +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, 05 Oct 2007 10:35:44 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 7AED91265D0; Fri, 5 Oct 2007 10:35:44 -0700 (PDT) Message-ID: <470675F4.7030502@elischer.org> Date: Fri, 05 Oct 2007 10:35:48 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Artyom Viklenko References: <4703F9C3.2060601@net.utcluj.ro> <4532.192.168.2.137.1191451931.squirrel@www.codeangels.com> <470535D6.7020601@net.utcluj.ro> <4705C035.1020403@aws-net.org.ua> In-Reply-To: <4705C035.1020403@aws-net.org.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: lists@codeangels.com, Cristian KLEIN , freebsd-net@freebsd.org Subject: Re: FreeBSD as a gigabit 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, 05 Oct 2007 17:35:46 -0000 Artyom Viklenko wrote: > Cristian KLEIN wrote: >> Thank you all for your replies. >> >> Kirill Ponazdyr wrote: >>>> Hi list, >>>> >>>> A few days ago I tested whether a FreeBSD 7 box is able to handle >>>> Gigabit >>>> Can anybody point me what the bottleneck of this configuration is? >>>> CPU was >>>> mostly idle and PCIe 1x should carry way more. Or is the experiment >>>> perhaps >>>> fundamentally flawed? >>> ICMP is not a good way to perform such tests as many have mentioned, >>> better use iperf. >> >> I used this test, because it proved perfect when, almost a decade ago, >> gigabit >> appeared. There wasn't anything at that time that could fill 1 Gbps, >> so we used >> the routers themselves to do the job. Also, I used this setup to avoid >> TCPs >> congestion control mecachnism and sub-maximum bandwidth. >> >> Of course, when I said "ping -f", I didn't mean a single "ping -f", >> but rather >> enough ping -f so that the looping packets would saturate the link. > > You can use option -i instead of -f: > > ping -nqs 1472 -i 0.00001 1.2.3.4 > > will generate large enougth amount of 1500 bytes packets. > Even more, use size more than 1472 and number of packets > will be increased. Value of -i parameter can be increased too. > > But remember about sysctl variable net.inet.ip.maxfragsperpacket. > By default, in FreeBSD 6.x it's value is 16. > >> >>> We have a FreeBSD 6.2 / pf box handling 2Gbps of traffic, real >>> traffic, it >>> will probably handle more, we just had no capacities or need to test. >>> >>> Hardware is a Single 2.4 Ghz Xeon with 2 x Intel Quad Pro 1000MT PCI-X >>> Controllers on separate PCI-X Busses. >> >> Could you tell me, is there any difference between 1000PT and 1000MT, >> except the >> slot type? Also, is there any difference between Intel Desktop and >> Intel Server >> adaptors, or are these just marketing buzzwords? >> >> >> _______________________________________________ >> 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" > > you can use the netgraph source node that is an in-kernel packet source. From owner-freebsd-net@FreeBSD.ORG Fri Oct 5 17:57: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 9537616A417 for ; Fri, 5 Oct 2007 17:57:47 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD5513C480 for ; Fri, 5 Oct 2007 17:57:47 +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, 05 Oct 2007 10:57:46 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 82DEE1265C7; Fri, 5 Oct 2007 10:57:45 -0700 (PDT) Message-ID: <47067B16.4020907@elischer.org> Date: Fri, 05 Oct 2007 10:57:42 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Vinod VM References: <8de278a20710050424t68cf95eap99cd34a13e8ce594@mail.gmail.com> <20071005120406.GQ971@void.codelabs.ru> <8de278a20710050659y55cbc312le303f1b44452b605@mail.gmail.com> In-Reply-To: <8de278a20710050659y55cbc312le303f1b44452b605@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: cant compile - undefined reference to `bpfattach' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 05 Oct 2007 17:57:47 -0000 Vinod VM wrote: > Thanks for the reply! > > On 10/5/07, Eygene Ryabinkin wrote: >> Fri, Oct 05, 2007 at 04:54:27PM +0530, Vinod VM wrote: >>> /var/tmp//ccphxfRO.o(.text+0x3c): In function `main': >>> : undefined reference to `bpfattach' >> If I am correct, bpfattach is the kernel-level function. And you're >> trying to write some user-space utility, aren't you? > > Yes. I am trying to write a program to capture from an interface and > inject them to another, kind of like bcrelay functionality in poptop > [http://www.poptop.org/] > >> If you're trying to capture packets, you'll probably want to >> consult the pcap(3) manual page. > > Thanks! Does it support injecting packets into an interface? hmmm have a look at netgraph at least some of the following node types may be useful to you, and writing new ones is easy. ng_async(4), ng_atm(4), ng_atmllc(4), ng_atmpif(4), ng_bluetooth(4), ng_bpf(4), ng_bridge(4), ng_bt3c(4), ng_btsocket(4), ng_cisco(4), ng_device(4), ng_echo(4), ng_eiface(4), ng_etf(4), ng_ether(4), ng_fec(4), ng_frame_relay(4), ng_gif(4), ng_gif_demux(4), ng_h4(4), ng_hci(4), ng_hole(4), ng_hub(4), ng_iface(4), ng_ip_input(4), ng_ksocket(4), ng_l2cap(4), ng_l2tp(4), ng_lmi(4), ng_mppc(4), ng_netflow(4), ng_one2many(4), ng_ppp(4), ng_pppoe(4), ng_pptpgre(4), ng_rfc1490(4), ng_socket(4), ng_split(4), ng_sppp(4), ng_sscfu(4), ng_sscop(4), ng_tee(4), ng_tty(4), ng_ubt(4), ng_UI(4), ng_uni(4), ng_vjc(4), ng_vlan(4), ngctl(8), nghook(8) > > vinod > _______________________________________________ > 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"