From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 00:50:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4172416A4CE for ; Sun, 5 Sep 2004 00:50:32 +0000 (GMT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2A4A43D1F for ; Sun, 5 Sep 2004 00:50:29 +0000 (GMT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.13.1/8.13.1) with ESMTP id i850oJel073040; Sat, 4 Sep 2004 20:50:19 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.13.1/8.13.1/Submit) id i850oJFU073039; Sat, 4 Sep 2004 20:50:19 -0400 (EDT) (envelope-from barney) Date: Sat, 4 Sep 2004 20:50:19 -0400 From: Barney Wolff To: vxp Message-ID: <20040905005019.GA72836@pit.databus.com> References: <20040904093042.B37306@digital-security.org> <20040904175028.GA25772@csh.rit.edu> <20040904132345.A38065@digital-security.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040904132345.A38065@digital-security.org> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.44 cc: freebsd-net@freebsd.org cc: Colin Alston cc: Wesley Shields Subject: Re: fooling nmap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 00:50:32 -0000 On Sat, Sep 04, 2004 at 01:28:28PM -0400, vxp wrote: > > in other words, what would you guys say be a _proper_ bsd-style thing to > do, if this were to be done? Nothing. If you want to pollute your kernel with nonsense of this sort, go right ahead, but leave mine alone. Adding frills detracts from security, even when they're only enabled by compile-time switches. The netinet code is already a challenge to follow or keep in mind all at once. Anything that makes the problem worse without a really big payoff is insane. Aside from the above, nmap is a moving target, and is not the only OS fingerprinter around. Getting into spy-vs-spy with Fyodor is a waste of time. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 02:05:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3A5E16A4CE for ; Sun, 5 Sep 2004 02:05:31 +0000 (GMT) Received: from e028121.vtacs.vt.edu (e028121.vtacs.vt.edu [63.164.28.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D35043D1F for ; Sun, 5 Sep 2004 02:05:31 +0000 (GMT) (envelope-from gaylord@dirtcheapemail.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by e028121.vtacs.vt.edu (Postfix) with ESMTP id BB9EF11418; Sat, 4 Sep 2004 22:05:26 -0400 (EDT) Message-ID: <413A7464.4090204@dirtcheapemail.com> Date: Sat, 04 Sep 2004 22:05:24 -0400 From: Clark Gaylord User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barney Wolff References: <20040904093042.B37306@digital-security.org> <20040904175028.GA25772@csh.rit.edu> <20040904132345.A38065@digital-security.org> <20040905005019.GA72836@pit.databus.com> In-Reply-To: <20040905005019.GA72836@pit.databus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Wesley Shields cc: Colin Alston cc: vxp Subject: Re: fooling nmap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 02:05:31 -0000 Barney Wolff wrote: > On Sat, Sep 04, 2004 at 01:28:28PM -0400, vxp wrote: >>in other words, what would you guys say be a _proper_ bsd-style thing to >>do, if this were to be done? > > Nothing. If you want to pollute your kernel with nonsense of this > sort, go right ahead, but leave mine alone. Adding frills detracts > from security, even when they're only enabled by compile-time > switches. The netinet code is already a challenge to follow or > keep in mind all at once. Anything that makes the problem worse > without a really big payoff is insane. I very much concur with Barney's sentiment, but I would also point out that our decisions for various sysctl settings should be based on sound network engineering practices. If we mimic some OS by trying to replicate something stupid that it does, then we've compromised sound network engineering. It reeks of the "deny ICMP" stupidity you so often see in firewall configs. OTOH, I think understanding why different OSes fingerprint differently is an extremely interesting pursuit, and good studies describing the many different strategies are fascinating if done well (not just the usual "this OS has its head up its ass" commentary, but really delve in to see "oh *that's* why they do that"). This "comparative literature" approach could build consensus for what the "right" approaches are and understanding of the reasonable alternatives. It may be that more consensus in approach would change the viability of fingerprinting anyway, and then for good reasons. --ckg From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 12:11:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B02B16A4DA; Sun, 5 Sep 2004 12:11:15 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 365CD43D1D; Sun, 5 Sep 2004 12:11:14 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i85CBCwg078341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Sep 2004 16:11:12 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i85CBCUe078340; Sun, 5 Sep 2004 16:11:12 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Sun, 5 Sep 2004 16:11:11 +0400 From: Gleb Smirnoff To: net@freebsd.org Message-ID: <20040905121111.GA78276@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 12:11:15 -0000 Collegues, here is netgraph module which implements Netflow traffic accounting, which I'm going to add to CURRENT in recent future: http://cell.sick.ru/~glebius/ng_netflow/ng_netflow-0.3-snap-20040905.tar.gz It is quite different to ng_netflow in ports/net, because its expiry thread is running outside of netgraph context, adding more parrallelizm on flow processing. I've been testing it for last week on loaded 100Mbit Ethernet which serves 9 ASes, 12 prefixes :) And it works stable. P.S. Please reply only to net@ list. I've added current@ just because more people are reading it. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 19:24:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CDC716A4CE for ; Sun, 5 Sep 2004 19:24:10 +0000 (GMT) Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE4D443D3F for ; Sun, 5 Sep 2004 19:24:09 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.160.193.218]) by out009.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040905192409.SSQV23440.out009.verizon.net@[192.168.1.3]>; Sun, 5 Sep 2004 14:24:09 -0500 Message-ID: <413B67C3.1090106@mac.com> Date: Sun, 05 Sep 2004 15:23:47 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vxp References: <20040904093042.B37306@digital-security.org> <20040904175028.GA25772@csh.rit.edu> <413A15DB.5010702@karnaugh.za.net> <20040904135129.L38122@digital-security.org> In-Reply-To: <20040904135129.L38122@digital-security.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out009.verizon.net from [68.160.193.218] at Sun, 5 Sep 2004 14:24:08 -0500 cc: freebsd-net@freebsd.org Subject: Re: fooling nmap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 19:24:10 -0000 vxp wrote: > On Sat, 4 Sep 2004, Colin Alston wrote: >> My point was if it provides no security, then there is no point to it at >> all. > > oh, but it does. it prevents them from gathering accurate information > about your system. that's an extremely important part of the attack. From your perspective, certainly, but you aren't a computer worm or virus. The overwhelming majority of worms and viruses launch their attacks by sweeping ranges of IP space-- generally starting on the local subnet, then scanning in a more-or-less random fashion from there. They don't care what your TCP stack looks like to nmap. They don't care what OS is running at that IP address. Frankly, worms don't even care much whether the TCP or UDP port they are trying to use is even open, they'll just move on to the next IP. >> Most attackers are going to exploit things at a service level >> anyway. What is the point of changing the fingerprint? > > ok, say your apache is vulnerable to whatever. an exploit for that apache > under linux is one thing, under freebsd is another, under windows another, > etc. the 'service level' won't work, if you got the OS wrong. If your protection depends upon the attacking guessing the OS wrong, you're screwed. The worm which assumes all machines have a cmd.com won't get through, you're right, but that doesn't mean that a worm which assumes all machines are FreeBSD machines is going to leave your IP alone just because you pretend otherwise. > there's very very few cross-platform vulnerabilities that share the _same_ > exploit code on _all_ platforms. actually, there's not a 'few'. there's > none. You're either not looking, or you don't understand what you see. Google for "Perl vulnerabilities" or "SQL injection". -- -Chuck PS: Not trying to give you a hard time. If you think you can make changes to src/sys/netinet/tcp_input.c and tcp_output.c which give you OS concealment, and make the existing code smaller or better, by all means, I'd be happy to take a look at those changes, and recommend them to others. From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 20:52:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC15A16A4CE; Sun, 5 Sep 2004 20:52:52 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E793943D39; Sun, 5 Sep 2004 20:52:51 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i85Kqne6081379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Sep 2004 00:52:50 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i85KqnMw081378; Mon, 6 Sep 2004 00:52:49 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 6 Sep 2004 00:52:49 +0400 From: Gleb Smirnoff To: luigi@freebsd.org Message-ID: <20040905205249.GA81337@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org cc: net@freebsd.org Subject: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 20:52:53 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Luigi, I see that bridge callbacks are still living in if_ed.c from FreeBSD 2.x times. See if_ed.c:2816. I think this is not correct. Bridge code is called from ether_input(), which is indirectly called from if_ed.c:2836. Any objections about attached patch? [ccing hackers@ and net@ to get more eyes reviewing] -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="if_ed.c.diff" Index: if_ed.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ed/if_ed.c,v retrieving revision 1.233 diff -u -r1.233 if_ed.c --- if_ed.c 13 Aug 2004 23:04:23 -0000 1.233 +++ if_ed.c 5 Sep 2004 20:48:19 -0000 @@ -2810,26 +2810,9 @@ eh = mtod(m, struct ether_header *); /* - * Don't read in the entire packet if we know we're going to drop it - * and no bpf is active. + * Get packet, including link layer address, from interface. */ - if (!ifp->if_bpf && BDG_ACTIVE( (ifp) ) ) { - struct ifnet *bif; - - ed_ring_copy(sc, buf, (char *)eh, ETHER_HDR_LEN); - bif = bridge_in_ptr(ifp, eh) ; - if (bif == BDG_DROP) { - m_freem(m); - return; - } - if (len > ETHER_HDR_LEN) - ed_ring_copy(sc, buf + ETHER_HDR_LEN, - (char *)(eh + 1), len - ETHER_HDR_LEN); - } else - /* - * Get packet, including link layer address, from interface. - */ - ed_ring_copy(sc, buf, (char *)eh, len); + ed_ring_copy(sc, buf, (char *)eh, len); m->m_pkthdr.len = m->m_len = len; --sdtB3X0nJg68CQEu-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 21:20:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 309BA16A4CE; Sun, 5 Sep 2004 21:20:37 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5A1A43D41; Sun, 5 Sep 2004 21:20:36 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i85LKaIb023271; Sun, 5 Sep 2004 14:20:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i85LKaVv023270; Sun, 5 Sep 2004 14:20:36 -0700 (PDT) (envelope-from rizzo) Date: Sun, 5 Sep 2004 14:20:36 -0700 From: Luigi Rizzo To: Gleb Smirnoff Message-ID: <20040905142036.A23213@xorpc.icir.org> References: <20040905205249.GA81337@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040905205249.GA81337@cell.sick.ru>; from glebius@freebsd.org on Mon, Sep 06, 2004 at 12:52:49AM +0400 cc: hackers@freebsd.org cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 21:20:37 -0000 On Mon, Sep 06, 2004 at 12:52:49AM +0400, Gleb Smirnoff wrote: > Luigi, > > I see that bridge callbacks are still living in if_ed.c > from FreeBSD 2.x times. See if_ed.c:2816. I think this is > not correct. > > Bridge code is called from ether_input(), which is > indirectly called from if_ed.c:2836. > > Any objections about attached patch? there are performance reasons to do this way -- grabbing the entire packet is expensive because it is done via programmed I/O, so the current code only grabs the header, does the filtering, and grabs the rest of the packet only if needed. Probably the current code runs bridge_in_ptr() twice, but I believe this is still cheaper than grabbing all packets entirely. I'd rather not apply the patch unless you can show that the current code leads to incorrect behaviour. cheers luigi > [ccing hackers@ and net@ to get more eyes reviewing] > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > Index: if_ed.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/ed/if_ed.c,v > retrieving revision 1.233 > diff -u -r1.233 if_ed.c > --- if_ed.c 13 Aug 2004 23:04:23 -0000 1.233 > +++ if_ed.c 5 Sep 2004 20:48:19 -0000 > @@ -2810,26 +2810,9 @@ > eh = mtod(m, struct ether_header *); > > /* > - * Don't read in the entire packet if we know we're going to drop it > - * and no bpf is active. > + * Get packet, including link layer address, from interface. > */ > - if (!ifp->if_bpf && BDG_ACTIVE( (ifp) ) ) { > - struct ifnet *bif; > - > - ed_ring_copy(sc, buf, (char *)eh, ETHER_HDR_LEN); > - bif = bridge_in_ptr(ifp, eh) ; > - if (bif == BDG_DROP) { > - m_freem(m); > - return; > - } > - if (len > ETHER_HDR_LEN) > - ed_ring_copy(sc, buf + ETHER_HDR_LEN, > - (char *)(eh + 1), len - ETHER_HDR_LEN); > - } else > - /* > - * Get packet, including link layer address, from interface. > - */ > - ed_ring_copy(sc, buf, (char *)eh, len); > + ed_ring_copy(sc, buf, (char *)eh, len); > > m->m_pkthdr.len = m->m_len = len; > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 21:37:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82C4216A4CE; Sun, 5 Sep 2004 21:37:31 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E4D443D1D; Sun, 5 Sep 2004 21:37:31 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i85LbVla053076; Sun, 5 Sep 2004 14:37:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i85LbV1V053075; Sun, 5 Sep 2004 14:37:31 -0700 (PDT) (envelope-from dillon) Date: Sun, 5 Sep 2004 14:37:31 -0700 (PDT) From: Matthew Dillon Message-Id: <200409052137.i85LbV1V053075@apollo.backplane.com> To: Luigi Rizzo References: <20040905205249.GA81337@cell.sick.ru> <20040905142036.A23213@xorpc.icir.org> cc: hackers@freebsd.org cc: Gleb Smirnoff cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 21:37:31 -0000 Well, wait a second... are we talking about a lot of packets being discarded by the filter in 'normal' operation, or are we talking about an attack? Because if we are takling about an attack the LAST ethernet device anyone would ever want to use would be ED. i.e. they would be under a major cpu load anyway and would be far better served using a better ethernet card. It seems silly to leave a major hack in the system just to support attacks on an ethernet device that nobody in their right mind would use if they expected to be attacked! Also, most ED devices are limited to 10BaseT (?), it's hard to imagine how the added load could possibly make things any worse then they would otherwise be, and similarly hard to imagine why anyone would want to use a programmed-I/O interface at 100BaseT or greater speeds (I'd say that the poor guy would deserve what he gets from that!). -Matt :there are performance reasons to do this way -- grabbing :the entire packet is expensive because it is done via programmed :I/O, so the current code only grabs the header, does the :filtering, and grabs the rest of the packet only if :needed. : :Probably the current code runs bridge_in_ptr() twice, but I :believe this is still cheaper than grabbing all packets :entirely. : :I'd rather not apply the patch unless you can show that :the current code leads to incorrect behaviour. : :cheers :luigi From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 21:38:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B473916A4CE; Sun, 5 Sep 2004 21:38:26 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id F178F43D45; Sun, 5 Sep 2004 21:38:25 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i85LcNiE081695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Sep 2004 01:38:24 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i85LcNHO081694; Mon, 6 Sep 2004 01:38:23 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 6 Sep 2004 01:38:23 +0400 From: Gleb Smirnoff To: Luigi Rizzo Message-ID: <20040905213823.GA81610@cell.sick.ru> References: <20040905205249.GA81337@cell.sick.ru> <20040905142036.A23213@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040905142036.A23213@xorpc.icir.org> User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 21:38:26 -0000 On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote: L> > I see that bridge callbacks are still living in if_ed.c L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is L> > not correct. L> > L> > Bridge code is called from ether_input(), which is L> > indirectly called from if_ed.c:2836. L> > L> > Any objections about attached patch? L> L> there are performance reasons to do this way -- grabbing L> the entire packet is expensive because it is done via programmed L> I/O, so the current code only grabs the header, does the L> filtering, and grabs the rest of the packet only if L> needed. Well, what percentage of packets is usually dropped by bridge in normal operation? Performance degradation applies only to them. L> Probably the current code runs bridge_in_ptr() twice, but I L> believe this is still cheaper than grabbing all packets L> entirely. L> I'd rather not apply the patch unless you can show that L> the current code leads to incorrect behaviour. The problem is with layer intermixing. ed(4) is a device driver, it must pass its frames to Ethernet stack without any hacks. By the way ed(4) is the only driver which does this. Actually I'm working on the problem decribed here http://lists.freebsd.org/mailman/htdig/freebsd-net/2004-May/003881.html and one of the approaches I'm considering is to push the block (lines 569-615) from if_ethersubr.c into bridge.c. This probably requires small changes to bridge_in()/bdg_forward() logic, so it's caller must take care. We have only two callers now - ether_input(), which is OK and if_ed, which looks like a hack. P.S. Sam said, that there are plans to convert bridge to use pfil-hooks. If this happens, the code in if_ed.c will be on the way again. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 21:53:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B80BD16A4CE for ; Sun, 5 Sep 2004 21:53:44 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2FBA43D48 for ; Sun, 5 Sep 2004 21:53:43 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26414 invoked from network); 5 Sep 2004 21:50:42 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Sep 2004 21:50:42 -0000 Message-ID: <413B8AE7.F211C23@freebsd.org> Date: Sun, 05 Sep 2004 23:53:43 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905205249.GA81337@cell.sick.ru> <20040905213823.GA81610@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: hackers@freebsd.org cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 21:53:45 -0000 Gleb Smirnoff wrote: > > On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote: > L> > I see that bridge callbacks are still living in if_ed.c > L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is > L> > not correct. > L> > > L> > Bridge code is called from ether_input(), which is > L> > indirectly called from if_ed.c:2836. > L> > > L> > Any objections about attached patch? > L> > L> there are performance reasons to do this way -- grabbing > L> the entire packet is expensive because it is done via programmed > L> I/O, so the current code only grabs the header, does the > L> filtering, and grabs the rest of the packet only if > L> needed. > > Well, what percentage of packets is usually dropped by bridge in > normal operation? Performance degradation applies only to them. That depends on how many systems are behind the bridge. Every packet not needing to go to the other side is dropped. > L> Probably the current code runs bridge_in_ptr() twice, but I > L> believe this is still cheaper than grabbing all packets > L> entirely. > L> I'd rather not apply the patch unless you can show that > L> the current code leads to incorrect behaviour. > > The problem is with layer intermixing. ed(4) is a device > driver, it must pass its frames to Ethernet stack > without any hacks. By the way ed(4) is the only driver > which does this. Yes. And I fully agree with Matt here. Nobody in their right mind would use ed(4) for *anything* these days. The best would probably to remove ed(4) alltogether. (Only half kidding). I fully support removing this hack from ed(4) to get the API right again. *If* someone is actually affected by this I'm going to buy him a shiny fxp card off Ebay for $3.59. I don't want to offend Luigi at all but the times are over to support such major layering violations these days for such an obscure piece of hardware. This 6-current now and we don't even support 386 CPUs anymore. > Actually I'm working on the problem decribed here > > http://lists.freebsd.org/mailman/htdig/freebsd-net/2004-May/003881.html > > and one of the approaches I'm considering is to push the > block (lines 569-615) from if_ethersubr.c into bridge.c. This > probably requires small changes to bridge_in()/bdg_forward() > logic, so it's caller must take care. We have only two callers > now - ether_input(), which is OK and if_ed, which looks like > a hack. I'm not sure if I can follow the graph correctly. Shouldn't the straight line between where ng_ether_input and ng_ether_rcvdata branch be disconnected? The way it is drawn there looks like the packet is arrving double in the upper half? > P.S. Sam said, that there are plans to convert bridge to use pfil-hooks. > If this happens, the code in if_ed.c will be on the way again. No. What will move to pfil_hooks is the firewalling within the bridge code and the layer2 ethernet firewalling. The bridging code as such will stay where it is. -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 22:03:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 860E116A4CF; Sun, 5 Sep 2004 22:03:58 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C27F743D31; Sun, 5 Sep 2004 22:03:57 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i85M3tLI081899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Sep 2004 02:03:56 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i85M3t80081898; Mon, 6 Sep 2004 02:03:55 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 6 Sep 2004 02:03:55 +0400 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20040905220355.GA81839@cell.sick.ru> References: <20040905205249.GA81337@cell.sick.ru> <20040905142036.A23213@xorpc.icir.org> <20040905213823.GA81610@cell.sick.ru> <413B8AE7.F211C23@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <413B8AE7.F211C23@freebsd.org> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: ng_ether vs bridge Was: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 22:03:58 -0000 On Sun, Sep 05, 2004 at 11:53:43PM +0200, Andre Oppermann wrote: A> > Actually I'm working on the problem decribed here A> > A> > http://lists.freebsd.org/mailman/htdig/freebsd-net/2004-May/003881.html A> > A> > and one of the approaches I'm considering is to push the A> > block (lines 569-615) from if_ethersubr.c into bridge.c. This A> > probably requires small changes to bridge_in()/bdg_forward() A> > logic, so it's caller must take care. We have only two callers A> > now - ether_input(), which is OK and if_ed, which looks like A> > a hack. A> A> I'm not sure if I can follow the graph correctly. Shouldn't the A> straight line between where ng_ether_input and ng_ether_rcvdata A> branch be disconnected? The way it is drawn there looks like the A> packet is arrving double in the upper half? Yep, this is an error in originators email. Vertical line should be removed. What we need to achieve is to return from netgraph into the same place we were sent to netgraph. You should have received a patch from me, which splits ether_input() in 2 parts. It is a hacky PoC, but it is working. What I'd like to do is "push block (lines 569-615) from if_ethersubr.c into bridge.c". That will not be a hack and will also remove another intermixing. A> > P.S. Sam said, that there are plans to convert bridge to use pfil-hooks. A> > If this happens, the code in if_ed.c will be on the way again. A> A> No. What will move to pfil_hooks is the firewalling within the bridge A> code and the layer2 ethernet firewalling. The bridging code as such A> will stay where it is. Thanks for this information. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 22:12:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD40E16A4CE for ; Sun, 5 Sep 2004 22:12:07 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EF7843D41 for ; Sun, 5 Sep 2004 22:12:07 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26550 invoked from network); 5 Sep 2004 22:09:05 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Sep 2004 22:09:05 -0000 Message-ID: <413B8F36.75419987@freebsd.org> Date: Mon, 06 Sep 2004 00:12:06 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905121111.GA78276@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 22:12:07 -0000 Gleb Smirnoff wrote: > > Collegues, > > here is netgraph module which implements Netflow traffic > accounting, which I'm going to add to CURRENT in recent future: > > http://cell.sick.ru/~glebius/ng_netflow/ng_netflow-0.3-snap-20040905.tar.gz > > It is quite different to ng_netflow in ports/net, because its > expiry thread is running outside of netgraph context, adding > more parrallelizm on flow processing. > > I've been testing it for last week on loaded 100Mbit Ethernet > which serves 9 ASes, 12 prefixes :) And it works stable. I'll have a closer look at it this week. -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 23:01:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1824216A4CE; Sun, 5 Sep 2004 23:01:03 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 387CF43D1F; Sun, 5 Sep 2004 23:01:03 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i85N11ip082369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Sep 2004 03:01:02 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i85N10r6082352; Mon, 6 Sep 2004 03:01:00 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 6 Sep 2004 03:01:00 +0400 From: Gleb Smirnoff To: Luigi Rizzo Message-ID: <20040905230100.GA82214@cell.sick.ru> References: <20040905205249.GA81337@cell.sick.ru> <20040905142036.A23213@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040905142036.A23213@xorpc.icir.org> User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 23:01:04 -0000 On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote: L> there are performance reasons to do this way -- grabbing L> the entire packet is expensive because it is done via programmed L> I/O, so the current code only grabs the header, does the L> filtering, and grabs the rest of the packet only if L> needed. Well, thinking deeply I have to admit that percentage of dropped packets can be high under normal operation. If we are connected to non-swithced network (e.g. coax) percentage of dropped packets is high... But my position didn't change, I absolutely agree with Andre. We can't keep this hack for the sake of very old and rare hardware. L> I'd rather not apply the patch unless you can show that L> the current code leads to incorrect behaviour. I suspect that packets dropped by bridge_in() called from if_ed will not be captured by bpf(4). This is incorrect. System administrators expect bpf(4) to be at the lowest possible layer, thinking "if packet came on wire - tcpdump must show it". -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 23:19:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48A0316A4CE; Sun, 5 Sep 2004 23:19:47 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6FF443D1D; Sun, 5 Sep 2004 23:19:46 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i85NJkWi080781 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 5 Sep 2004 16:19:46 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-net@freebsd.org Date: Sun, 5 Sep 2004 16:23:59 -0700 User-Agent: KMail/1.6.2 References: <20040905205249.GA81337@cell.sick.ru> <20040905213823.GA81610@cell.sick.ru> <413B8AE7.F211C23@freebsd.org> In-Reply-To: <413B8AE7.F211C23@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409051623.59851.sam@errno.com> cc: hackers@freebsd.org cc: Luigi Rizzo cc: Gleb Smirnoff cc: Andre Oppermann cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 23:19:47 -0000 On Sunday 05 September 2004 02:53 pm, Andre Oppermann wrote: > Gleb Smirnoff wrote: > > On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote: > > L> > I see that bridge callbacks are still living in if_ed.c > > L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is > > L> > not correct. > > L> > > > L> > Bridge code is called from ether_input(), which is > > L> > indirectly called from if_ed.c:2836. > > L> > > > L> > Any objections about attached patch? > > L> > > L> there are performance reasons to do this way -- grabbing > > L> the entire packet is expensive because it is done via programmed > > L> I/O, so the current code only grabs the header, does the > > L> filtering, and grabs the rest of the packet only if > > L> needed. > > > > Well, what percentage of packets is usually dropped by bridge in > > normal operation? Performance degradation applies only to them. > > That depends on how many systems are behind the bridge. Every packet > not needing to go to the other side is dropped. > > > L> Probably the current code runs bridge_in_ptr() twice, but I > > L> believe this is still cheaper than grabbing all packets > > L> entirely. > > L> I'd rather not apply the patch unless you can show that > > L> the current code leads to incorrect behaviour. > > > > The problem is with layer intermixing. ed(4) is a device > > driver, it must pass its frames to Ethernet stack > > without any hacks. By the way ed(4) is the only driver > > which does this. > > Yes. And I fully agree with Matt here. Nobody in their right mind > would use ed(4) for *anything* these days. The best would probably > to remove ed(4) alltogether. (Only half kidding). > > I fully support removing this hack from ed(4) to get the API right > again. *If* someone is actually affected by this I'm going to buy > him a shiny fxp card off Ebay for $3.59. I don't want to offend > Luigi at all but the times are over to support such major layering > violations these days for such an obscure piece of hardware. This > 6-current now and we don't even support 386 CPUs anymore. > > > Actually I'm working on the problem decribed here > > > > http://lists.freebsd.org/mailman/htdig/freebsd-net/2004-May/003881.html > > > > and one of the approaches I'm considering is to push the > > block (lines 569-615) from if_ethersubr.c into bridge.c. This > > probably requires small changes to bridge_in()/bdg_forward() > > logic, so it's caller must take care. We have only two callers > > now - ether_input(), which is OK and if_ed, which looks like > > a hack. > > I'm not sure if I can follow the graph correctly. Shouldn't the > straight line between where ng_ether_input and ng_ether_rcvdata > branch be disconnected? The way it is drawn there looks like the > packet is arrving double in the upper half? > > > P.S. Sam said, that there are plans to convert bridge to use pfil-hooks. > > If this happens, the code in if_ed.c will be on the way again. > > No. What will move to pfil_hooks is the firewalling within the bridge > code and the layer2 ethernet firewalling. The bridging code as such > will stay where it is. Well, that's what _you_ want to do :). What I started on last year was a complete purge of special-purpose hooks in the network stack; replacing them with pfil hooks (adding new hooks to do this). Revamping the bridge code was part of this work and to do it I had to eliminate the API used by the ed driver. As to whether you're planning to follow the path I started is another matter (I pointed Gleb at you because you seemed to be going in that direction and I figured you'd "see the light" after looking at the p4 branch code I sent you :)). Back to the original question, the issue is that for some devices you can save a lot by fetching only the header in order to do the bridge-routing logic. However since modern devices dma the entire packet into a pre-allocated buffer you typically gain little by this optimizatoin. This can still be a win as you can short-circuit some work by making this check before forming a complete packet and passing it up the stack but for most systems I don't figure this is important. If you're trying to build a high-performance bridge you're likely going to collapse a lot of this logic anyway and the bridge code in question would be combined with other logic. So my vote is to nuke the special code in the ed driver (and anywhere else; I recall there being one other driver that had similar logic) and make the bridge api more opaque. Sam From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 23:19:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48A0316A4CE; Sun, 5 Sep 2004 23:19:47 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6FF443D1D; Sun, 5 Sep 2004 23:19:46 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i85NJkWi080781 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 5 Sep 2004 16:19:46 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-net@freebsd.org Date: Sun, 5 Sep 2004 16:23:59 -0700 User-Agent: KMail/1.6.2 References: <20040905205249.GA81337@cell.sick.ru> <20040905213823.GA81610@cell.sick.ru> <413B8AE7.F211C23@freebsd.org> In-Reply-To: <413B8AE7.F211C23@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409051623.59851.sam@errno.com> cc: hackers@freebsd.org cc: Luigi Rizzo cc: Gleb Smirnoff cc: Andre Oppermann cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 23:19:47 -0000 On Sunday 05 September 2004 02:53 pm, Andre Oppermann wrote: > Gleb Smirnoff wrote: > > On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote: > > L> > I see that bridge callbacks are still living in if_ed.c > > L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is > > L> > not correct. > > L> > > > L> > Bridge code is called from ether_input(), which is > > L> > indirectly called from if_ed.c:2836. > > L> > > > L> > Any objections about attached patch? > > L> > > L> there are performance reasons to do this way -- grabbing > > L> the entire packet is expensive because it is done via programmed > > L> I/O, so the current code only grabs the header, does the > > L> filtering, and grabs the rest of the packet only if > > L> needed. > > > > Well, what percentage of packets is usually dropped by bridge in > > normal operation? Performance degradation applies only to them. > > That depends on how many systems are behind the bridge. Every packet > not needing to go to the other side is dropped. > > > L> Probably the current code runs bridge_in_ptr() twice, but I > > L> believe this is still cheaper than grabbing all packets > > L> entirely. > > L> I'd rather not apply the patch unless you can show that > > L> the current code leads to incorrect behaviour. > > > > The problem is with layer intermixing. ed(4) is a device > > driver, it must pass its frames to Ethernet stack > > without any hacks. By the way ed(4) is the only driver > > which does this. > > Yes. And I fully agree with Matt here. Nobody in their right mind > would use ed(4) for *anything* these days. The best would probably > to remove ed(4) alltogether. (Only half kidding). > > I fully support removing this hack from ed(4) to get the API right > again. *If* someone is actually affected by this I'm going to buy > him a shiny fxp card off Ebay for $3.59. I don't want to offend > Luigi at all but the times are over to support such major layering > violations these days for such an obscure piece of hardware. This > 6-current now and we don't even support 386 CPUs anymore. > > > Actually I'm working on the problem decribed here > > > > http://lists.freebsd.org/mailman/htdig/freebsd-net/2004-May/003881.html > > > > and one of the approaches I'm considering is to push the > > block (lines 569-615) from if_ethersubr.c into bridge.c. This > > probably requires small changes to bridge_in()/bdg_forward() > > logic, so it's caller must take care. We have only two callers > > now - ether_input(), which is OK and if_ed, which looks like > > a hack. > > I'm not sure if I can follow the graph correctly. Shouldn't the > straight line between where ng_ether_input and ng_ether_rcvdata > branch be disconnected? The way it is drawn there looks like the > packet is arrving double in the upper half? > > > P.S. Sam said, that there are plans to convert bridge to use pfil-hooks. > > If this happens, the code in if_ed.c will be on the way again. > > No. What will move to pfil_hooks is the firewalling within the bridge > code and the layer2 ethernet firewalling. The bridging code as such > will stay where it is. Well, that's what _you_ want to do :). What I started on last year was a complete purge of special-purpose hooks in the network stack; replacing them with pfil hooks (adding new hooks to do this). Revamping the bridge code was part of this work and to do it I had to eliminate the API used by the ed driver. As to whether you're planning to follow the path I started is another matter (I pointed Gleb at you because you seemed to be going in that direction and I figured you'd "see the light" after looking at the p4 branch code I sent you :)). Back to the original question, the issue is that for some devices you can save a lot by fetching only the header in order to do the bridge-routing logic. However since modern devices dma the entire packet into a pre-allocated buffer you typically gain little by this optimizatoin. This can still be a win as you can short-circuit some work by making this check before forming a complete packet and passing it up the stack but for most systems I don't figure this is important. If you're trying to build a high-performance bridge you're likely going to collapse a lot of this logic anyway and the bridge code in question would be combined with other logic. So my vote is to nuke the special code in the ed driver (and anywhere else; I recall there being one other driver that had similar logic) and make the bridge api more opaque. Sam From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 23:35:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB2A516A4D0 for ; Sun, 5 Sep 2004 23:35:01 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 028AD43D58 for ; Sun, 5 Sep 2004 23:35:01 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 27045 invoked from network); 5 Sep 2004 23:31:58 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Sep 2004 23:31:58 -0000 Message-ID: <413BA2A3.6E1FD0DF@freebsd.org> Date: Mon, 06 Sep 2004 01:34:59 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Leffler References: <20040905205249.GA81337@cell.sick.ru> <20040905213823.GA81610@cell.sick.ru> <413B8AE7.F211C23@freebsd.org> <200409051623.59851.sam@errno.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: freebsd-net@freebsd.org cc: Luigi Rizzo cc: Gleb Smirnoff cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 23:35:02 -0000 Sam Leffler wrote: > > No. What will move to pfil_hooks is the firewalling within the bridge > > code and the layer2 ethernet firewalling. The bridging code as such > > will stay where it is. > > Well, that's what _you_ want to do :). What I started on last year was a > complete purge of special-purpose hooks in the network stack; replacing them > with pfil hooks (adding new hooks to do this). Revamping the bridge code was > part of this work and to do it I had to eliminate the API used by the ed > driver. As to whether you're planning to follow the path I started is > another matter (I pointed Gleb at you because you seemed to be going in that > direction and I figured you'd "see the light" after looking at the p4 branch > code I sent you :)). Ok, I still haven't looked at your code in p4. Will do that together with mlaier and then we'll make up our mind. ;-) P4web seems to be working fine again. Even if we take the one-step-at-a-time approach there is nothing preventing us from going the full way eventually and implementing your vision. -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 23:35:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E268216A4D1 for ; Sun, 5 Sep 2004 23:35:01 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E92D543D49 for ; Sun, 5 Sep 2004 23:35:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 27045 invoked from network); 5 Sep 2004 23:31:58 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Sep 2004 23:31:58 -0000 Message-ID: <413BA2A3.6E1FD0DF@freebsd.org> Date: Mon, 06 Sep 2004 01:34:59 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sam Leffler References: <20040905205249.GA81337@cell.sick.ru> <20040905213823.GA81610@cell.sick.ru> <413B8AE7.F211C23@freebsd.org> <200409051623.59851.sam@errno.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: freebsd-net@freebsd.org cc: Luigi Rizzo cc: Gleb Smirnoff cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Sep 2004 23:35:02 -0000 Sam Leffler wrote: > > No. What will move to pfil_hooks is the firewalling within the bridge > > code and the layer2 ethernet firewalling. The bridging code as such > > will stay where it is. > > Well, that's what _you_ want to do :). What I started on last year was a > complete purge of special-purpose hooks in the network stack; replacing them > with pfil hooks (adding new hooks to do this). Revamping the bridge code was > part of this work and to do it I had to eliminate the API used by the ed > driver. As to whether you're planning to follow the path I started is > another matter (I pointed Gleb at you because you seemed to be going in that > direction and I figured you'd "see the light" after looking at the p4 branch > code I sent you :)). Ok, I still haven't looked at your code in p4. Will do that together with mlaier and then we'll make up our mind. ;-) P4web seems to be working fine again. Even if we take the one-step-at-a-time approach there is nothing preventing us from going the full way eventually and implementing your vision. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 05:04:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5930916A4CF for ; Mon, 6 Sep 2004 05:04:37 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFB8043D55 for ; Mon, 6 Sep 2004 05:04:36 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 17636 invoked from network); 6 Sep 2004 05:04:36 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Sep 2004 05:04:36 -0000 Received: from hydrogen.funkthat.com (bixsto@localhost.funkthat.com [127.0.0.1])i8654ZuU072384; Sun, 5 Sep 2004 22:04:36 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i8654ZQZ072383; Sun, 5 Sep 2004 22:04:35 -0700 (PDT) Date: Sun, 5 Sep 2004 22:04:35 -0700 From: John-Mark Gurney To: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Message-ID: <20040906050435.GA72089@funkthat.com> Mail-Followup-To: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: better MTU support... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 05:04:37 -0000 In a recent experiment w/ Jumbo frames, I found out that sending ip frames completely ignores the MTU set on host routes. This makes it difficult (or next to impossible) to support a network that has both regular and jumbo frames on it as you can't restrict some hosts to the smaller frames. I now have a patch to ip_output that makes it obay the MTU set on the route instead of that of the interface. Please review: http://people.FreeBSD.org/~jmg/ip_mtu.diff Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 05:29:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7E7C16A4CE; Mon, 6 Sep 2004 05:29:54 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92E2343D53; Mon, 6 Sep 2004 05:29:54 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i865TsIb026559; Sun, 5 Sep 2004 22:29:54 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i865TsCM026558; Sun, 5 Sep 2004 22:29:54 -0700 (PDT) (envelope-from rizzo) Date: Sun, 5 Sep 2004 22:29:54 -0700 From: Luigi Rizzo To: Gleb Smirnoff Message-ID: <20040905222954.A26501@xorpc.icir.org> References: <20040905205249.GA81337@cell.sick.ru> <20040905142036.A23213@xorpc.icir.org> <20040905230100.GA82214@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040905230100.GA82214@cell.sick.ru>; from glebius@freebsd.org on Mon, Sep 06, 2004 at 03:01:00AM +0400 cc: hackers@freebsd.org cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 Sep 2004 05:29:54 -0000 On Mon, Sep 06, 2004 at 03:01:00AM +0400, Gleb Smirnoff wrote: ... > L> I'd rather not apply the patch unless you can show that > L> the current code leads to incorrect behaviour. > > I suspect that packets dropped by bridge_in() called from if_ed will > not be captured by bpf(4). This is incorrect. if you read the code you see that the bpf behaviour is as it should be, and your suspect is unfounded. - if (!ifp->if_bpf && BDG_ACTIVE( (ifp) ) ) { (my summary and pov on the discussion in a separate email) cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 06:14:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF31A16A4CE; Mon, 6 Sep 2004 06:14:24 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B115743D1F; Mon, 6 Sep 2004 06:14:24 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i866ELIb026902; Sun, 5 Sep 2004 23:14:21 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i866ELXh026901; Sun, 5 Sep 2004 23:14:21 -0700 (PDT) (envelope-from rizzo) Date: Sun, 5 Sep 2004 23:14:21 -0700 From: Luigi Rizzo To: Matthew Dillon Message-ID: <20040905231421.B26501@xorpc.icir.org> References: <20040905205249.GA81337@cell.sick.ru> <20040905142036.A23213@xorpc.icir.org> <200409052137.i85LbV1V053075@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200409052137.i85LbV1V053075@apollo.backplane.com>; from dillon@apollo.backplane.com on Sun, Sep 05, 2004 at 02:37:31PM -0700 cc: hackers@freebsd.org cc: Gleb Smirnoff cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? (My pov) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 Sep 2004 06:14:25 -0000 On Sun, Sep 05, 2004 at 02:37:31PM -0700, Matthew Dillon wrote: > Well, wait a second... are we talking about a lot of packets being > discarded by the filter in 'normal' operation, or are we talking about > an attack? Because if we are takling about an attack the LAST ethernet ... Sure, in this thread we are talking of a performance hack for a specific piece of hardware, which may be obsolete and poorly performing, but is also one of the few widespread ones supporting coax. Once upon a time, this hack was basically the only way to make a coax bridge perform decently and not saturate the bus (ISA or PCMCIA). Granted, these days maybe nobody uses coax anymore or has a desire to upgrade these boxes. If the existing code is broken (but please make a reasonable effort to prove it, don't just hint things) or gets in the way because e.g. it would complicate locking for everyone else, or because the bridge_in_ptr() or BDG_ACTIVE() calls disappear from the API, then i am all for the suggested change. But if the suggested change is something in preparation for other changes that may never see the light, then i'd rather just add a comment/reminder in the relevant bridging file, and nuke the code in if_ed.c and everywhere else when this becomes necessary. After all the problem (alleged layering violation) is well understood, and the offender (assuming this is the only one -- the way to check would be rename bridge_in_ptr() and BDG_ACTIVE() to something different and try a build of the kernel and modules) and the trivial fix are known so postponing the change is not going to harm anyone. Speaking about layering violation -- sure, the above bridge thing is a small one, but there are much worse (and more critical) offenders. E.g. the device driver preferably should not know who is going to consume its packets, and you are pointing the finger at the bridging code -- but this applies to bpf as well, yet several drivers still have explicit if (ifp->if_bpf) bpf_mtap(ifp, m_head); or implicit BPF_MTAP(ifp, m_head); bpf hooks. And another huge one is the support for delayed checksums, which permeates the entire network stack and breaks bpf feeding it with packets carrying invalid checksums. I guess the above means "do what you like, just don't put an 'Approved by: luigi' line in the commit msg" :) cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 06:33:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7B8A16A4CE; Mon, 6 Sep 2004 06:33:16 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB85443D58; Mon, 6 Sep 2004 06:33:15 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i866XDMU084419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Sep 2004 10:33:14 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i866XD2u084418; Mon, 6 Sep 2004 10:33:13 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 6 Sep 2004 10:33:13 +0400 From: Gleb Smirnoff To: Luigi Rizzo Message-ID: <20040906063313.GB84269@cell.sick.ru> References: <20040905205249.GA81337@cell.sick.ru> <20040905142036.A23213@xorpc.icir.org> <20040905230100.GA82214@cell.sick.ru> <20040905222954.A26501@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040905222954.A26501@xorpc.icir.org> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 Sep 2004 06:33:16 -0000 On Sun, Sep 05, 2004 at 10:29:54PM -0700, Luigi Rizzo wrote: L> > L> I'd rather not apply the patch unless you can show that L> > L> the current code leads to incorrect behaviour. L> > L> > I suspect that packets dropped by bridge_in() called from if_ed will L> > not be captured by bpf(4). This is incorrect. L> L> if you read the code you see that the bpf behaviour is L> as it should be, and your suspect is unfounded. L> L> - if (!ifp->if_bpf && BDG_ACTIVE( (ifp) ) ) { You are right, sorry. But the packets dropped by bridge will not enter lower hook of ng_ether(4), like they do in case of other interfaces. L> (my summary and pov on the discussion in a separate email) Actually, I'm working on better interaction of ng_ether and bridge, and this hack in if_ed is on the way. And this "will se the light" quite soon. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 07:24:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B898E16A4CE for ; Mon, 6 Sep 2004 07:24:32 +0000 (GMT) Received: from techno.sub.ru (webmail.sub.ru [213.247.139.22]) by mx1.FreeBSD.org (Postfix) with SMTP id 15C2B43D46 for ; Mon, 6 Sep 2004 07:24:32 +0000 (GMT) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 33929 invoked by uid 0); 6 Sep 2004 07:21:16 -0000 Received: from webmail.sub.ru (HELO tarkhil.over.ru) (213.247.139.22) by techno.sub.ru with SMTP; 6 Sep 2004 07:21:16 -0000 Date: Mon, 6 Sep 2004 11:24:26 +0400 From: Alex Povolotsky To: freebsd-net@freebsd.org Message-Id: <20040906112426.7a575414@tarkhil.over.ru> Organization: sub.ru X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: help needed with dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 Sep 2004 07:24:32 -0000 Hello! I've read man ipfw several times but still did not catch the following thing: I want to make ssh traffic 'top priority', giving it all bandwidth it wants, without explicitly limiting other kinds of traffic. man ipfw is quite unclear on queue usage, can anyone give me a working example? -- Alex. From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 11:02:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 220C416A4CE for ; Mon, 6 Sep 2004 11:02:56 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1903043D2F for ; Mon, 6 Sep 2004 11:02:56 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i86B2tTC094409 for ; Mon, 6 Sep 2004 11:02:55 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i86B2tht094403 for freebsd-net@freebsd.org; Mon, 6 Sep 2004 11:02:55 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 6 Sep 2004 11:02:55 GMT Message-Id: <200409061102.i86B2tht094403@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 Sep 2004 11:02:56 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2002/10/21] kern/44355 net After deletion of an IPv6 alias, the rout o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 17:35:45 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D751116A4CF for ; Mon, 6 Sep 2004 17:35:45 +0000 (GMT) Received: from web40413.mail.yahoo.com (web40413.mail.yahoo.com [66.218.78.110]) by mx1.FreeBSD.org (Postfix) with SMTP id C17B543D31 for ; Mon, 6 Sep 2004 17:35:45 +0000 (GMT) (envelope-from c0sine@yahoo.com) Message-ID: <20040906173545.91306.qmail@web40413.mail.yahoo.com> Received: from [69.196.154.220] by web40413.mail.yahoo.com via HTTP; Mon, 06 Sep 2004 10:35:45 PDT Date: Mon, 6 Sep 2004 10:35:45 -0700 (PDT) From: George S To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: ipfw dynamic tcp rule issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 Sep 2004 17:35:46 -0000 Hello all, I've been having some trouble with this strange ipfw configuration and I am pretty sure it is probably a bug. I posted a note to freebsd-ipfw a little while ago, but I think the problem is better demonstrated with a figure. If anyone can take a look at this, I would be very appreciative. Kindest regards, George __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 18:02:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1E1516A4CE for ; Mon, 6 Sep 2004 18:02:51 +0000 (GMT) Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 855C443D46 for ; Mon, 6 Sep 2004 18:02:51 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.160.193.218]) by out002.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040906180250.GWJE6722.out002.verizon.net@[192.168.1.3]>; Mon, 6 Sep 2004 13:02:50 -0500 Message-ID: <413CA630.8040606@mac.com> Date: Mon, 06 Sep 2004 14:02:24 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Povolotsky References: <20040906112426.7a575414@tarkhil.over.ru> In-Reply-To: <20040906112426.7a575414@tarkhil.over.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out002.verizon.net from [68.160.193.218] at Mon, 6 Sep 2004 13:02:50 -0500 cc: freebsd-net@freebsd.org Subject: Re: help needed with dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 Sep 2004 18:02:52 -0000 Alex Povolotsky wrote: > I want to make ssh traffic 'top priority', giving it all bandwidth it > wants, without explicitly limiting other kinds of traffic. OK. Consider something like the following: ipfw pipe 1 config ipfw queue 1 config pipe 1 weight 100 ipfw queue 2 config pipe 1 weight 1 ipfw add queue 1 tcp from any to any ssh ipfw add queue 2 ip from any to any -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 07:10:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D4A716A4CE for ; Tue, 7 Sep 2004 07:10:30 +0000 (GMT) Received: from web13007.mail.yahoo.com (web13007.mail.yahoo.com [216.136.174.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 307C543D5E for ; Tue, 7 Sep 2004 07:10:30 +0000 (GMT) (envelope-from rosey_kc@yahoo.com) Message-ID: <20040907071030.53611.qmail@web13007.mail.yahoo.com> Received: from [202.51.78.5] by web13007.mail.yahoo.com via HTTP; Tue, 07 Sep 2004 00:10:30 PDT Date: Tue, 7 Sep 2004 00:10:30 -0700 (PDT) From: kamal kc To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: help:: configuring two network interfaces--message->>ifconfig: ioctl (SIOCAIFADDR): File exists X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 07 Sep 2004 07:10:30 -0000 i have run into a mysterious problem. The thing is that i wanted to configure to NIC cards. I just put the card in the slot and booted FreeBSD. The card was detected. When i wanted to configure the nic card using the ifconfig command the following error message was reported. ifconfig: ioctl (SIOCAIFADDR): File exists The same message was reported when i configured the rc.conf file and rebooted the computer. Below i have copied the output of ifconfig and the rc.conf file in case it could help solve the problem. ----------------------------------------------------- kamal# ifconfig rl0: flags=8843 mtu 1500 inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 inet6 fe80::250:fcff:feb6:4e1%rl0 prefixlen 64 scopeid 0x1 ether 00:50:fc:b6:04:e1 media: Ethernet autoselect (none) status: no carrier rl1: flags=8843 mtu 1500 inet6 fe80::2e0:4cff:feb0:cc%rl1 prefixlen 64 scopeid 0x2 ether 00:e0:4c:b0:00:cc media: Ethernet autoselect (none) status: no carrier lp0: flags=8810 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 ---------------------------------------------- kamal# ifconfig rl1 192.168.10.2 ifconfig: ioctl (SIOCAIFADDR): File exists kamal# ---------------------------------------------- kamal# cat rc.conf i # -- sysinstall generated deltas -- # Tue Jan 1 00:34:50 2002 # Created: Tue Jan 1 00:34:50 2002 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. linux_enable="YES" sendmail_enable="YES" gateway_enable="YES" sshd_enable="YES" hostname="kamal.com" ifconfig_rl1="inet 192.168.10.1 netmask 255.255.255.0" ifconfig_rl0="inet 192.168.10.2 netmask 255.255.255.0" # -- sysinstall generated deltas -- # Tue Jan 1 01:29:12 2002 moused_enable="YES" kamal# ------------------------------------------------------------ The nic card is detected and configurable in WINDOWS xp and Redhat Linux 9 Another info--- one of the nic is built in with the board and another in add on. please help!! --------------------------------- Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 07:19:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF26916A4CE; Tue, 7 Sep 2004 07:19:57 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EA4343D39; Tue, 7 Sep 2004 07:19:57 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1C4aGe-0005bD-00; Tue, 07 Sep 2004 09:19:52 +0200 To: George S From: Ian FREISLICH In-Reply-To: Message from George S <20040906173545.91306.qmail@web40413.mail.yahoo.com> Date: Tue, 07 Sep 2004 09:19:52 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: ipfw dynamic tcp rule issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 07 Sep 2004 07:19:58 -0000 George S wrote: > Hello all, > > I've been having some trouble with this strange ipfw configuration and I am > pretty sure it is probably a bug. I posted a note to freebsd-ipfw a little > while ago, but I think the problem is better demonstrated with a figure. Are you sure that you perormed the test you described and the results (count updated etc) actually occured? I would expect rule 9 to catch the packet on its way back and rule 11 never to be triggered. Maybe rule 9 should be a checkstate rule. Ian -- Ian Freislich From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 07:33:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4492D16A4CE for ; Tue, 7 Sep 2004 07:33:39 +0000 (GMT) Received: from mail.star-sw.com (mail.star-sw.com [217.195.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F52D43D2F for ; Tue, 7 Sep 2004 07:33:38 +0000 (GMT) (envelope-from nkritsky@star-sw.com) Received: from ARGON.star-sw.com (argon.star-sw.com [217.195.82.10]) by mail.star-sw.com (8.12.11/8.12.11) with ESMTP id i877XaVf064320; Tue, 7 Sep 2004 11:33:36 +0400 (MSD) Received: from ibmka.star-sw.com ([192.168.32.230]) by ARGON.star-sw.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Sep 2004 11:33:36 +0400 Date: Tue, 7 Sep 2004 11:33:35 +0400 From: "Nickolay A. Kritsky" X-Mailer: The Bat! (v1.49) Personal X-Priority: 3 (Normal) Message-ID: <15766907203.20040907113335@star-sw.com> To: kamal kc In-reply-To: <20040907071030.53611.qmail@web13007.mail.yahoo.com> References: <20040907071030.53611.qmail@web13007.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Sep 2004 07:33:36.0071 (UTC) FILETIME=[FC425D70:01C494AC] cc: freebsd-net@freebsd.org Subject: Re: help:: configuring two network interfaces--message->>ifconfig: ioctl (SIOCAIFADDR): File exists X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Nickolay A. Kritsky" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 07:33:39 -0000 Hello kamal, I am not sure but this may be the result of the attempt to assign inet address from the subnet that is already used on the rl0 iface. If you are sure that that you need this behaviour, use netmask of -1 on the rl1 iface. Tuesday, September 07, 2004, 11:10:30 AM, kamal kc wrote: kk> i have run into a mysterious problem. kk> The thing is that i wanted to configure to NIC cards. kk> I just put the card in the slot and booted FreeBSD. The kk> card was detected. When i wanted to configure the nic card using the kk> ifconfig command the following error message was reported. kk> ifconfig: ioctl (SIOCAIFADDR): File exists kk> The same message was reported when i configured the rc.conf file and kk> rebooted the computer. kk> Below i have copied the output of ifconfig and the rc.conf file kk> in case it could help solve the problem. kk> ----------------------------------------------------- kk> kamal# ifconfig kk> rl0: flags=8843 mtu 1500 kk> inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255 kk> inet6 fe80::250:fcff:feb6:4e1%rl0 prefixlen 64 scopeid 0x1 kk> ether 00:50:fc:b6:04:e1 kk> media: Ethernet autoselect (none) kk> status: no carrier kk> rl1: flags=8843 mtu 1500 kk> inet6 fe80::2e0:4cff:feb0:cc%rl1 prefixlen 64 scopeid 0x2 kk> ether 00:e0:4c:b0:00:cc kk> media: Ethernet autoselect (none) kk> status: no carrier kk> lp0: flags=8810 mtu 1500 kk> lo0: flags=8049 mtu 16384 kk> inet6 ::1 prefixlen 128 kk> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 kk> inet 127.0.0.1 netmask 0xff000000 kk> ---------------------------------------------- kk> kamal# ifconfig rl1 192.168.10.2 kk> ifconfig: ioctl (SIOCAIFADDR): File exists kk> kamal# kk> ---------------------------------------------- kk> kamal# cat rc.conf kk> i kk> # -- sysinstall generated deltas -- # Tue Jan 1 00:34:50 2002 kk> # Created: Tue Jan 1 00:34:50 2002 kk> # Enable network daemons for user convenience. kk> # Please make all changes to this file, not to /etc/defaults/rc.conf. kk> # This file now contains just the overrides from /etc/defaults/rc.conf. kk> linux_enable="YES" kk> sendmail_enable="YES" kk> gateway_enable="YES" kk> sshd_enable="YES" kk> hostname="kamal.com" kk> ifconfig_rl1="inet 192.168.10.1 netmask 255.255.255.0" kk> ifconfig_rl0="inet 192.168.10.2 netmask 255.255.255.0" kk> # -- sysinstall generated deltas -- # Tue Jan 1 01:29:12 2002 kk> moused_enable="YES" kk> kamal# kk> ------------------------------------------------------------ kk> The nic card is detected and configurable in WINDOWS xp and kk> Redhat Linux 9 kk> Another info--- kk> one of the nic is built in with the board and another in add on. kk> please help!! kk> --------------------------------- kk> Do you Yahoo!? kk> Win 1 of 4,000 free domain names from Yahoo! Enter now. kk> _______________________________________________ kk> freebsd-net@freebsd.org mailing list kk> http://lists.freebsd.org/mailman/listinfo/freebsd-net kk> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best regards, ; Nickolay A. Kritsky ; SysAdmin STAR Software LLC ; mailto:nkritsky@star-sw.com From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 07:38:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 502E716A4CE for ; Tue, 7 Sep 2004 07:38:29 +0000 (GMT) Received: from ubtc.kharkov.ua (relay.inprombank.com.ua [212.113.47.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 831C043D46 for ; Tue, 7 Sep 2004 07:38:27 +0000 (GMT) (envelope-from da@ubtc.kharkov.ua) Received: from sa.ubtc.kharkov.ua (sa.ubtc.kharkov.ua [192.168.3.1]) by ubtc.kharkov.ua (8.12.10/8.11.3) with ESMTP id i877cN0G003899; Tue, 7 Sep 2004 10:38:23 +0300 Date: Tue, 7 Sep 2004 10:38:23 +0300 (EEST) From: "Dmitriy V. Andrushko" To: kamal kc In-Reply-To: <20040907071030.53611.qmail@web13007.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: help:: configuring two network interfaces--message->>ifconfig: ioctl (SIOCAIFADDR): File exists X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 07 Sep 2004 07:38:29 -0000 > ifconfig_rl1="inet 192.168.10.1 netmask 255.255.255.0" > ifconfig_rl0="inet 192.168.10.2 netmask 255.255.255.0" You can't have two network interfaces on the same subnet. You can configure your net next way: ifconfig_rl1="inet 192.168.10.1 netmask 255.255.255.0" ifconfig_rl0="inet 192.168.20.1 netmask 255.255.255.0" From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 08:39:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E34316A4CE for ; Tue, 7 Sep 2004 08:39:49 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id C112E43D31 for ; Tue, 7 Sep 2004 08:39:48 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C4bVX-0000LV-5d; Tue, 07 Sep 2004 12:39:19 +0400 From: Vladimir Grebenschikov To: "Dmitriy V. Andrushko" In-Reply-To: References: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Tue, 07 Sep 2004 12:39:18 +0400 Message-Id: <1094546358.1010.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: kamal kc cc: freebsd-net@freebsd.org Subject: Re: help:: configuring two network interfaces--message->>ifconfig: ioctl (SIOCAIFADDR): File exists X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2004 08:39:49 -0000 =F7 =D7=D4, 07/09/2004 =D7 10:38 +0300, Dmitriy V. Andrushko =D0=C9=DB=C5= =D4: > > ifconfig_rl1=3D"inet 192.168.10.1 netmask 255.255.255.0" > > ifconfig_rl0=3D"inet 192.168.10.2 netmask 255.255.255.0" >=20 > You can't have two network interfaces on the same subnet. You can > configure your net next way: > ifconfig_rl1=3D"inet 192.168.10.1 netmask 255.255.255.0" > ifconfig_rl0=3D"inet 192.168.20.1 netmask 255.255.255.0" Actually you can # ifconfig ndis0 10.111.0.1/24 # route delete 10.111.0.0/24 delete net 10.111.0.0 # ifconfig fxp0 10.111.0.2/24 # ifconfig -a lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000=20 fxp0: flags=3D8943 mtu 1500 options=3D8 inet 10.111.0.2 netmask 0xffffff00 broadcast 10.111.0.255 ether 08:00:46:c8:45:b3 media: Ethernet autoselect (100baseTX) status: active ndis0: flags=3D8843 mtu 1500 inet 10.111.0.1 netmask 0xffffff00 broadcast 10.111.0.255 ether 00:0e:35:03:82:74 media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid "" channel -1 authmode OPEN powersavemode OFF powersavesleep 100 rtsthreshold 2312 protmode CTS wepmode OFF weptxkey 1 But you should select what target interface will be for routing to this subnet, in my example, after configuration of ndis0, I have removed route of subnet 10.111.0.0/24 to this interface, and then add address and routing to subnet on fxp0 interface. now expecting routing table: # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 10.111/24 link#2 UC 0 0 fxp0 127.0.0.1 127.0.0.1 UH 1 756 lo0 We see, subnet routed to fxp0, but ndis0 still can receive traffic as configured. But such configuration is very specific, and you should very understand what you do. --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 12:36:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C2EC16A4D0 for ; Tue, 7 Sep 2004 12:36:01 +0000 (GMT) Received: from web40405.mail.yahoo.com (web40405.mail.yahoo.com [66.218.78.102]) by mx1.FreeBSD.org (Postfix) with SMTP id E990C43D1D for ; Tue, 7 Sep 2004 12:36:00 +0000 (GMT) (envelope-from c0sine@yahoo.com) Message-ID: <20040907123600.11325.qmail@web40405.mail.yahoo.com> Received: from [69.196.154.220] by web40405.mail.yahoo.com via HTTP; Tue, 07 Sep 2004 05:36:00 PDT Date: Tue, 7 Sep 2004 05:36:00 -0700 (PDT) From: George S To: Ian FREISLICH In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: ipfw dynamic tcp rule issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 07 Sep 2004 12:36:01 -0000 Hi Ian, Thanks for your response. Yes, the behaviour is exactly as I describe. What happens is that on its way back, the SYN+ACK packet with DST IP/PORT 10.0.0.2 and SRC IP/PORT 69.196.154.5/80 hits rule #1 where there is a keep-state. This causes ipfw to check all dynamic rules implicitly (as per the ipfw manpage). Since the SYN+ACK packet is part of a recently setup connection, there is a skipto to rule #10. Rule #10 does not match because there SRC/DST are not correct, so it then passes to rule #11, which does match (and its counters are updated). The problem is that the packet never finds itself on the fxp0 wire. I will give your check-state suggestion a try but I think the check-state is implicit within rule #1. Kindest regards, George --- Ian FREISLICH wrote: > George S wrote: > > Hello all, > > > > I've been having some trouble with this strange ipfw configuration and I > am > > pretty sure it is probably a bug. I posted a note to freebsd-ipfw a > little > > while ago, but I think the problem is better demonstrated with a figure. > http://www.geocities.com/c0sine/fbsdipfw.gif > Are you sure that you perormed the test you described and the results > (count updated etc) actually occured? I would expect rule 9 to > catch the packet on its way back and rule 11 never to be triggered. > > Maybe rule 9 should be a checkstate rule. > > Ian > > -- > Ian Freislich > _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 13:14:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC04716A4CE for ; Tue, 7 Sep 2004 13:14:56 +0000 (GMT) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.FreeBSD.org (Postfix) with SMTP id 6714B43D2F for ; Tue, 7 Sep 2004 13:14:49 +0000 (GMT) (envelope-from ofsen@enderunix.org) Received: (qmail 1017 invoked by uid 89); 7 Sep 2004 13:15:02 -0000 Message-ID: <20040907131502.1015.qmail@istanbul.enderunix.org> From: Omer Faruk Sen To: freebsd-net@freebsd.org Date: Tue, 07 Sep 2004 16:15:02 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-9" Content-Transfer-Encoding: 7bit Subject: FreeBSD VPN performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 07 Sep 2004 13:14:57 -0000 Hi, I have given a work to test VPN performance of FreeBSD IPSEC subsystem. I am not that familiar with ipsec terms. (just started to read IPSEC documents about 5 days ago)I wanted to share my observations: My hardware is : P IV 2.8, 256 MB, fxp NIC First of all I have used FreeBSD 4.10 Stable not FreeBSD5 (maybe I have to test FreeBSD 5 too. I think especially MP safe network stack and multhreaded kernel gives better performance? FAST_IPSEC currently works faster than IPSEC even if I don't use a hardware accelerator. I have used rijndael-cbc(192 bit) and hmac-sha1(160bit) for my test. I have used 3des(192 bit) and hmac-md5 (128 bit) but it gives less performcance. Here is my kernel configuration ( I have a problem with my kernel configuration after booting with this kernel top,vmstat refused to run. I am not sure if it is just a kernel system incompatibility(4.10Relese system vs 4.10Stable kernel) problem or a missing option in my kernel ): machine i386 cpu I686_CPU makeoptions COPTFLAGS="-O2 -pipe -funroll-loops -ffast-math" ident IPSEC maxusers 0 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options SYSVSHM #SYSV-style shared memory options NSWAPDEV=1 options NFS_NOSERVER options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies device pci device isa device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0 at atkbdc? irq 12 device vga0 at isa? # syscons is the default console driver, resembling an SCO console device npx0 at nexus? port IO_NPX irq 13 # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 #device sio1 at isa? port IO_COM2 irq 3 device miibus # MII bus support device fxp # Intel EtherExpress PRO/100B (82557, 82558) device vr # VIA Rhine, Rhine II # Pseudo devices - the number indicates how many units to allocate. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device gif # IPv6 and IPv4 tunneling pseudo-device bpf 4 #Berkeley packet filter #options IPSEC #IP security #options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options FAST_IPSEC #new IPsec pseudo-device crypto # core crypto support pseudo-device cryptodev # /dev/crypto for access to h/w options RANDOM_IP_ID options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN options HZ=2000 options DEVICE_POLLING options NMBCLUSTERS=65536 #This may not required since we can tweak #it on /boot/loader.conf #Make console nonchangable options SC_NO_CUTPASTE options SC_NO_FONT_LOADING options SC_NO_SYSMOUSE options VGA_NO_FONT_LOADING # don't save/load font options VGA_NO_MODE_CHANGE # don't change video modes My loader.conf is set to: kern.ipc.nmbclusters="65536" My sysctl.conf: net.inet.ip.forwarding=1 vfs.vmiodirenable=1 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=8192 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.rfc1323=1 net.inet.tcp.sendspace=32768 net.inet.tcp.recvspace=65536 net.inet.udp.recvspace=65536 net.inet.udp.maxdgram=65536 net.local.stream.recvspace=65536 net.local.stream.sendspace=65536 net.inet.icmp.bmcastecho=0 net.inet.icmp.maskrepl=0 net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 #net.inet.icmp.log_redirect=1 net.inet.icmp.drop_redirect=1 net.inet.tcp.delayed_ack=1 kern.ps_showallprocs=0 net.inet.tcp.inflight_enable=1 #HTT icin gerekli machdep.hlt_logical_cpus=0 kern.polling.enable=1 I have installed racoon as IKE but I have lived some problems with it and after reading kame racoon ml (http://www.kame.net/racoon/racoon-ml/msg00605.html) I have used this patch along with 20040818a version of racoon and it seems that problems have solved. I want to try isakmpd since it seems to give a better performance. Here is my racoon.conf: remote anonymous { #exchange_mode main,aggressive; exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; #my_identifier address; #my_identifier user_fqdn "sakane@kame.net"; #peers_identifier user_fqdn "sakane@kame.net"; #certificate_type x509 "mycert" "mypriv"; nonce_size 16; lifetime time 12 hour; # sec,min,hour initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm rijndael; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 12 hour; encryption_algorithm rijndael; authentication_algorithm hmac_sha1; compression_algorithm deflate ; } With this configuration we have received about 68mbits/s without any packet loss. But after raising the limit (Shomiti Surveyor used for that) packets started to get lost. I know this is a long and terribly formated mail but can someone give me adivce for raising the performance of my FreeBSD VPN system? It has just came to my mind that maybe changing kern.poll gives me a better performance? I am planning to write a FreeBSD VPN performance paper if I gain a better performance.. PS: By the way if I use manually created keys I get better performance. But it seems peculiar to me since I have set key lifetime to 12 hours, then I have decided that racoon (IKE daemons) has an affect on VPN performance. Is that true? If it is true can you explain it why it has affect on performance with a keylife time of 12 hours. ----------------------- Omer Faruk Sen http://www.EnderUNIX.ORG Software Development Team @ Turkey http://www.Faruk.NET For Public key: http://www.enderunix.org/ofsen/ofsen.asc ******************************************************** First Turkish FreeBSD book is out! Go check it. Duydunuz mu! Turkiye'nin ilk FreeBSD kitabi cikti. http://www.acikkod.com/freebsd.php ----------------------- Omer Faruk Sen http://www.EnderUNIX.ORG Software Development Team @ Turkey http://www.Faruk.NET For Public key: http://www.enderunix.org/ofsen/ofsen.asc ******************************************************** First Turkish FreeBSD book is out! Go check it. Duydunuz mu! Turkiye'nin ilk FreeBSD kitabi cikti. http://www.acikkod.com/freebsd.php From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 13:53:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0154616A4CE for ; Tue, 7 Sep 2004 13:53:50 +0000 (GMT) Received: from sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FE6D43D5D for ; Tue, 7 Sep 2004 13:53:49 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: by sun-fish.com (Postfix, from userid 1008) id D877914A9A; Tue, 7 Sep 2004 15:53:45 +0200 (CEST) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id 37F8D14A8E for ; Tue, 7 Sep 2004 15:53:45 +0200 (CEST) Date: Tue, 7 Sep 2004 16:53:45 +0300 From: Vladimir Terziev To: freebsd-net@freebsd.org Message-Id: <20040907165345.359dd5b6@daemon.cmotd.com> Organization: SunFish Ltd. X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-unknown-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Tunneling HTTPS with Squid X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 07 Sep 2004 13:53:50 -0000 Hi all, I have the following prolem: Our ISP makes audit of all web traffic going to our servers in order to prevent different kind of attacks against them. The ISP then forwards the traffic which is clean using Squid. Our web application needs to know the client computer IP in order to make different kind of checks. When HTTP traffic is forwarded with Squid all is ok, because the proper X-FORWARDED-FOR header is set and we are able to identify the request issuer. When Squid forwards HTTPS traffic to us, situation is different, because the only IP which we are able to "see" is that one of the Squid server. Now, my question ... is there a way to instruct Squid to create some kind of tunnel and to forward the HTTPS traffic through it? 10x in advance! Vladimir From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 15:08:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33C3B16A4CE; Tue, 7 Sep 2004 15:08:14 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A778B43D48; Tue, 7 Sep 2004 15:08:13 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1C4hUx-0007tW-00; Tue, 07 Sep 2004 17:03:07 +0200 To: George S From: Ian FREISLICH In-reply-to: Your message of "Tue, 07 Sep 2004 05:36:00 MST." <20040907123600.11325.qmail@web40405.mail.yahoo.com> X-Attribution: BOFH Date: Tue, 07 Sep 2004 17:03:07 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: ipfw dynamic tcp rule issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 07 Sep 2004 15:08:14 -0000 George S wrote: > Hi Ian, > > Thanks for your response. > > Yes, the behaviour is exactly as I describe. What happens is that on its way > back, the SYN+ACK packet with DST IP/PORT 10.0.0.2 and SRC IP/PORT > 69.196.154.5/80 hits rule #1 where there is a keep-state. This causes ipfw > to check all dynamic rules implicitly (as per the ipfw manpage). > > Since the SYN+ACK packet is part of a recently setup connection, there is a > skipto to rule #10. Rule #10 does not match because there SRC/DST are not > correct, so it then passes to rule #11, which does match (and its counters > are updated). > > The problem is that the packet never finds itself on the fxp0 wire. I will > give your check-state suggestion a try but I think the check-state is > implicit within rule #1. I thought you had to explicitly state the check-state. Anyway, I've just noticed that your last rule is #65655 which is higher than the max for an unsigned short. Depending how this overflow is handled, you might get odd behaviour. This might just result in the packet being denied by the default deny rule on the way out of fxp0. Try adding a rule just before the default deny to log matches. It's almost always useful to do this anyway when playing with the ruleset until everything works. I would have done the rules as follows: ipfw add 00010 fwd 10.0.0.1 tcp from 10.0.0.2 to any in via fxp0 ipfw add 00020 fwd 192.168.1.1 tcp from any to 10.0.0.2 in via fxp1 ipfw add 65534 allow ip from any to any Is there any particular reason for wanting a stateful firewall in this case? Ian -- Ian Freislich From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 16:03:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A19D16A4CE for ; Tue, 7 Sep 2004 16:03:39 +0000 (GMT) Received: from unsane.co.uk (unsane.co.uk [82.152.23.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D93043D48 for ; Tue, 7 Sep 2004 16:03:38 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (localhost [127.0.0.1]) by unsane.co.uk (8.12.11/8.12.10) with ESMTP id i87G2pP9098710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Sep 2004 17:02:51 +0100 (BST) (envelope-from jhary@unsane.co.uk) Received: from localhost (jhary@localhost) by unsane.co.uk (8.12.11/8.12.10/Submit) with ESMTP id i87G2nMR098707; Tue, 7 Sep 2004 17:02:51 +0100 (BST) (envelope-from jhary@unsane.co.uk) Date: Tue, 7 Sep 2004 17:02:49 +0100 (BST) From: Vince Hoffman To: Omer Faruk Sen In-Reply-To: <20040907131502.1015.qmail@istanbul.enderunix.org> Message-ID: <20040907165451.B97892@unsane.co.uk> References: <20040907131502.1015.qmail@istanbul.enderunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: FreeBSD VPN performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 07 Sep 2004 16:03:39 -0000 On Tue, 7 Sep 2004, Omer Faruk Sen wrote: > Hi, > > I have given a work to test VPN performance of FreeBSD IPSEC subsystem. I am > not that familiar with ipsec terms. (just started to read IPSEC documents > about 5 days ago)I wanted to share my observations: > > My hardware is : P IV 2.8, 256 MB, fxp NIC > > First of all I have used FreeBSD 4.10 Stable not FreeBSD5 (maybe I have to > test FreeBSD 5 too. I think especially MP safe network stack and multhreaded > kernel gives better performance? > > FAST_IPSEC currently works faster than IPSEC even if I don't use a hardware > accelerator. I have used rijndael-cbc(192 bit) and hmac-sha1(160bit) for my > test. I have used 3des(192 bit) and hmac-md5 (128 bit) but it gives less > performcance. > > Here is my kernel configuration ( I have a problem with my kernel > configuration after booting with this kernel top,vmstat refused to run. I am > not sure if it is just a kernel system incompatibility(4.10Relese system vs > 4.10Stable kernel) problem or a missing option in my kernel ): Often implys your userland is out of sync. i'd follow the instructions in /usr/src/Makefile to update your userland. > > machine i386 > cpu I686_CPU > makeoptions COPTFLAGS="-O2 -pipe -funroll-loops -ffast-math" > ident IPSEC > maxusers 0 > > > options INET #InterNETworking > options FFS #Berkeley Fast Filesystem > options FFS_ROOT #FFS usable as root device [keep > this!] > options SOFTUPDATES #Enable FFS soft updates support > options UFS_DIRHASH #Improve performance on big > directories > options CD9660 #ISO 9660 Filesystem > options PROCFS #Process filesystem > options COMPAT_43 #Compatible with BSD 4.3 [KEEP > THIS!] > options UCONSOLE #Allow users to grab the console > options USERCONFIG #boot -c editor > options VISUAL_USERCONFIG #visual boot -c editor > options SYSVSHM #SYSV-style shared memory > options NSWAPDEV=1 > options NFS_NOSERVER > options SYSVMSG #SYSV-style message queues > options SYSVSEM #SYSV-style semaphores > options P1003_1B #Posix P1003_1B real-time extensions > options _KPOSIX_PRIORITY_SCHEDULING > options ICMP_BANDLIM #Rate limit bad replies > > device pci > device isa > > device ata0 at isa? port IO_WD1 irq 14 > device ata1 at isa? port IO_WD2 irq 15 > device ata > device atadisk # ATA disk drives > device atapicd # ATAPI CDROM drives > options ATA_STATIC_ID #Static device numbering > > > device atkbdc0 at isa? port IO_KBD > device atkbd0 at atkbdc? irq 1 flags 0x1 > device psm0 at atkbdc? irq 12 > > device vga0 at isa? > > > # syscons is the default console driver, resembling an SCO console > > device npx0 at nexus? port IO_NPX irq 13 > > # Serial (COM) ports > device sio0 at isa? port IO_COM1 flags 0x10 irq 4 > #device sio1 at isa? port IO_COM2 irq 3 > > > device miibus # MII bus support > device fxp # Intel EtherExpress PRO/100B (82557, 82558) > device vr # VIA Rhine, Rhine II > > # Pseudo devices - the number indicates how many units to allocate. > pseudo-device loop # Network loopback > pseudo-device ether # Ethernet support > pseudo-device pty # Pseudo-ttys (telnet etc) > pseudo-device gif # IPv6 and IPv4 tunneling > > pseudo-device bpf 4 #Berkeley packet filter > > #options IPSEC #IP security > #options IPSEC_ESP #IP security (crypto; define w/ > IPSEC) > options FAST_IPSEC #new IPsec > pseudo-device crypto # core crypto support > pseudo-device cryptodev # /dev/crypto for access to h/w > > > > options RANDOM_IP_ID > options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN > options HZ=2000 > options DEVICE_POLLING > options NMBCLUSTERS=65536 #This may not required since we can tweak > #it on /boot/loader.conf > > #Make console nonchangable > options SC_NO_CUTPASTE > options SC_NO_FONT_LOADING > options SC_NO_SYSMOUSE > options VGA_NO_FONT_LOADING # don't save/load font > options VGA_NO_MODE_CHANGE # don't change video modes > > My loader.conf is set to: > > kern.ipc.nmbclusters="65536" > > My sysctl.conf: > net.inet.ip.forwarding=1 > vfs.vmiodirenable=1 > kern.ipc.maxsockbuf=2097152 > kern.ipc.somaxconn=8192 > kern.maxfiles=65536 > kern.maxfilesperproc=32768 > net.inet.tcp.rfc1323=1 > net.inet.tcp.sendspace=32768 > net.inet.tcp.recvspace=65536 > net.inet.udp.recvspace=65536 > net.inet.udp.maxdgram=65536 > net.local.stream.recvspace=65536 > net.local.stream.sendspace=65536 > net.inet.icmp.bmcastecho=0 > net.inet.icmp.maskrepl=0 > net.inet.ip.accept_sourceroute=0 > net.inet.ip.sourceroute=0 > #net.inet.icmp.log_redirect=1 > net.inet.icmp.drop_redirect=1 > net.inet.tcp.delayed_ack=1 > kern.ps_showallprocs=0 > net.inet.tcp.inflight_enable=1 > #HTT icin gerekli > machdep.hlt_logical_cpus=0 > kern.polling.enable=1 > > > I have installed racoon as IKE but I have lived some problems with it and > after reading kame racoon ml > (http://www.kame.net/racoon/racoon-ml/msg00605.html) I have used this patch > along with 20040818a version of racoon and it seems that problems have > solved. I want to try isakmpd since it seems to give a better performance. > Here is my racoon.conf: > > remote anonymous > { > #exchange_mode main,aggressive; > exchange_mode aggressive,main; > doi ipsec_doi; > situation identity_only; > > #my_identifier address; > #my_identifier user_fqdn "sakane@kame.net"; > #peers_identifier user_fqdn "sakane@kame.net"; > #certificate_type x509 "mycert" "mypriv"; > > nonce_size 16; > lifetime time 12 hour; # sec,min,hour > initial_contact on; > support_mip6 on; > proposal_check obey; # obey, strict or claim > > proposal { > encryption_algorithm rijndael; > hash_algorithm sha1; > authentication_method pre_shared_key ; > dh_group 2 ; > } > } > > sainfo anonymous > { > pfs_group 1; > lifetime time 12 hour; > encryption_algorithm rijndael; > authentication_algorithm hmac_sha1; > compression_algorithm deflate ; > } > > > With this configuration we have received about 68mbits/s without any packet > loss. But after raising the limit (Shomiti Surveyor used for that) packets > started to get lost. > > I know this is a long and terribly formated mail but can someone give me > adivce for raising the performance of my FreeBSD VPN system? It has just > came to my mind that maybe changing kern.poll gives me a better performance? > I am planning to write a FreeBSD VPN performance paper if I gain a better > performance.. > > PS: By the way if I use manually created keys I get better performance. But > it seems peculiar to me since I have set key lifetime to 12 hours, then I > have decided that racoon (IKE daemons) has an affect on VPN performance. Is > that true? If it is true can you explain it why it has affect on performance > with a keylife time of 12 hours. > > ----------------------- > Omer Faruk Sen > http://www.EnderUNIX.ORG > Software Development Team @ Turkey > http://www.Faruk.NET > For Public key: http://www.enderunix.org/ofsen/ofsen.asc > ******************************************************** > > > First Turkish FreeBSD book is out! Go check it. > Duydunuz mu! Turkiye'nin ilk FreeBSD kitabi cikti. > http://www.acikkod.com/freebsd.php > > > ----------------------- > Omer Faruk Sen > http://www.EnderUNIX.ORG > Software Development Team @ Turkey > http://www.Faruk.NET > For Public key: http://www.enderunix.org/ofsen/ofsen.asc > ******************************************************** > > > First Turkish FreeBSD book is out! Go check it. > Duydunuz mu! Turkiye'nin ilk FreeBSD kitabi cikti. > http://www.acikkod.com/freebsd.php > > > _______________________________________________ > 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 Sep 7 17:08:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C001F16A4CE for ; Tue, 7 Sep 2004 17:08:29 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B07943D1F for ; Tue, 7 Sep 2004 17:08:29 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i87H8Sao029773; Tue, 7 Sep 2004 10:08:29 -0700 (PDT) Received: from [10.1.1.245] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)i87H8Qj5015941; Tue, 7 Sep 2004 10:08:27 -0700 (PDT) In-Reply-To: <20040907165345.359dd5b6@daemon.cmotd.com> References: <20040907165345.359dd5b6@daemon.cmotd.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <86B15E9E-00F0-11D9-A3E8-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 7 Sep 2004 13:08:23 -0400 To: Vladimir Terziev X-Mailer: Apple Mail (2.619) cc: freebsd-net@freebsd.org Subject: Re: Tunneling HTTPS with Squid X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 07 Sep 2004 17:08:29 -0000 On Sep 7, 2004, at 9:53 AM, Vladimir Terziev wrote: > When HTTP traffic is forwarded with Squid all is ok, because the > proper X-FORWARDED-FOR header is set and we are able to identify the > request issuer. When Squid forwards HTTPS traffic to us, situation is > different, because the only IP which we are able to "see" is that one > of the Squid server. > Now, my question ... is there a way to instruct Squid to create some > kind of tunnel and to forward the HTTPS traffic through it? Hmm. Squid supports proxying https connections, and it will create a tunnel between itself and the SSL server on the other side (using DIRECT rather than an HTTP GET method). However, once you've gotten that SSL tunnel formed, what goes through it is opaque to Squid: Squid cannot add headers or do anything of that sort without violating the encryption. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 04:05:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CC6316A4CE for ; Wed, 8 Sep 2004 04:05:51 +0000 (GMT) Received: from mail0.jaist.ac.jp (mail0.jaist.ac.jp [150.65.5.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4BD443D45 for ; Wed, 8 Sep 2004 04:05:49 +0000 (GMT) (envelope-from zrelli@jaist.ac.jp) Received: from smtp.jaist.ac.jp (proxy-isc.jaist.ac.jp [150.65.5.30]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id i8845mN05489; Wed, 8 Sep 2004 13:05:48 +0900 (JST) Received: from www.jaist.ac.jp (www.jaist.ac.jp [150.65.5.208]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id i8844KY18923; Wed, 8 Sep 2004 13:04:20 +0900 (JST) Received: from 203.178.159.102 (SquirrelMail authenticated user zrelli); by www.jaist.ac.jp with HTTP; Wed, 8 Sep 2004 13:05:47 +0900 (JST) Message-ID: <32818.203.178.159.102.1094616347.squirrel@203.178.159.102> In-Reply-To: <413CA630.8040606@mac.com> References: <20040906112426.7a575414@tarkhil.over.ru> <413CA630.8040606@mac.com> Date: Wed, 8 Sep 2004 13:05:47 +0900 (JST) From: "Saber Zrelli" To: "Chuck Swiger" User-Agent: SquirrelMail/1.4.3-RC1 X-Mailer: SquirrelMail/1.4.3-RC1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: freebsd-net@freebsd.org cc: Alex Povolotsky Subject: Re: help needed with dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: zrelli@jaist.ac.jp List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 04:05:51 -0000 Hi , checkout the 'netnice' tool , here is the link : http://www.netnice.org/ you can use 'netnice' just like the well know 'nice' except the fact that the ressource managed by 'nice' is the cpu , while 'netnice' manages the network interface access. Enjoy , -- Saber On Tue, September 7, 2004 3:02 am, Chuck Swiger said: > Alex Povolotsky wrote: >> I want to make ssh traffic 'top priority', giving it all bandwidth it >> wants, without explicitly limiting other kinds of traffic. > > OK. Consider something like the following: > > ipfw pipe 1 config > ipfw queue 1 config pipe 1 weight 100 > ipfw queue 2 config pipe 1 weight 1 > ipfw add queue 1 tcp from any to any ssh > ipfw add queue 2 ip from any to any > > -- > -Chuck > _______________________________________________ > 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" > ------------------------------------------------------------------- Saber Zrelli Japan Advanced Institute of Science and Technology School of Informations Science , Shinoda Lab. Url : www.jaist.ac.jp/~zrelli Gpg key-id : E3A7EC6C From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 04:44:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A80716A4CE for ; Wed, 8 Sep 2004 04:44:23 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3ED243D5D for ; Wed, 8 Sep 2004 04:44:22 +0000 (GMT) (envelope-from windsok@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so240699rnl for ; Tue, 07 Sep 2004 21:44:15 -0700 (PDT) Received: by 10.38.74.61 with SMTP id w61mr2489339rna; Tue, 07 Sep 2004 21:44:15 -0700 (PDT) Received: by 10.38.209.30 with HTTP; Tue, 7 Sep 2004 21:44:15 -0700 (PDT) Message-ID: <4a64a1b8040907214468a3877c@mail.gmail.com> Date: Wed, 8 Sep 2004 14:44:15 +1000 From: Glenn Thomas To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: strange pppoe/adsl issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Glenn Thomas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 04:44:23 -0000 I recently swaped ADSL isp's and have been experiencing pppoe issues ever since. Basically the issue is this, ppp connects fine, and the connection will work, but after around 45seconds the connection will stop receving data, even though all analysis reveals that we are still connected. After much fiddling with my config that was previously working fine with my old isp, I eventually gave up and decided to try connecting from other operating systems, this produced some strange results. Windows 2K + raspppoe: Exact same issue as FreeBSD Windows XP: Worked Flawlessly IPCOP (linux): Worked Flawlessly Linksys WRT54G (linux): Worked Flawlessly This to me is really confusing, why should FreeBSD and Win2K with raspppoe have the same problems, but Windows XP and Linux be unaffected? Shouldn't all the implementations be essentially the same? I tested FreeBSD 4.10, 4-STABLE, 5.2.1 and 5.3-BETA2 and all had the same issue. In any case, i am now quite sure that the problem is at the ISP end, and have got them to look into it, hopefully they can find a solution, but it still leaves me very confused, has anyone got any clues on what might be causing the problem? Thanks, Glenn. From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 06:54:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0089C16A4CE for ; Wed, 8 Sep 2004 06:54:33 +0000 (GMT) Received: from orion.erdves.lt (ns2.lrtc.net [217.9.240.98]) by mx1.FreeBSD.org (Postfix) with SMTP id 926C843D4C for ; Wed, 8 Sep 2004 06:54:31 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: (qmail 24580 invoked from network); 8 Sep 2004 06:54:29 -0000 Received: from p2p-241-242-ird.vln0.lrtc.net (HELO donatas) (217.9.241.242) by orion.erdves.lt with SMTP; 8 Sep 2004 06:54:29 -0000 Message-ID: <03e801c49570$af734760$9f90a8c0@donatas> From: "donatas" To: Date: Wed, 8 Sep 2004 09:54:27 +0300 Organization: AB Lietuvos Radijo ir Televizijos Centras MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: netgraph cpcsinit + vcc parrameters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: donatas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 06:54:33 -0000 hello, I use netgraph for : hatm: <-------------> atmllc <--------->em also I use vcc chanels: ngctl msg hatm0: cpcsinit {name=3D"sig1" aal=3D5 vci=3D55} I need to set some more vcc parameters ( ubr, pixel-rate, burst-size) it was possible to do using atmconfig ( atmconfig natm add 1.1.1.1 hatm0 0 55 LLC/SNAP vbr 1331 1330 50) but how to realize those settings using cpcsinit ? it sets some default = values any ideas? thanx ps: google seems unable to help in this case From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 08:11:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 423DB16A4D1 for ; Wed, 8 Sep 2004 08:11:36 +0000 (GMT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DF5043D46 for ; Wed, 8 Sep 2004 08:11:35 +0000 (GMT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i888BV2577652; Wed, 8 Sep 2004 10:11:31 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) i888BUI66824; Wed, 8 Sep 2004 10:11:30 +0200 Received: from beagle.kn.op.dlr.de (opkndnwsbsd178 [129.247.173.178]) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i888BTe20950; Wed, 8 Sep 2004 10:11:30 +0200 (MET DST) Date: Wed, 8 Sep 2004 10:11:30 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt@beagle.kn.op.dlr.de To: donatas In-Reply-To: <03e801c49570$af734760$9f90a8c0@donatas> Message-ID: <20040908100728.P23565@beagle.kn.op.dlr.de> References: <03e801c49570$af734760$9f90a8c0@donatas> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: netgraph cpcsinit + vcc parrameters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 08:11:36 -0000 On Wed, 8 Sep 2004, donatas wrote: d>hello, d>I use netgraph for : d> d>hatm: <-------------> atmllc <--------->em d> d>also I use vcc chanels: d> d>ngctl msg hatm0: cpcsinit {name="sig1" aal=5 vci=55} d> d>I need to set some more vcc parameters ( ubr, pixel-rate, burst-size) d> d>it was possible to do using atmconfig d>( atmconfig natm add 1.1.1.1 hatm0 0 55 LLC/SNAP vbr 1331 1330 50) d> d>but how to realize those settings using cpcsinit ? it sets some default values That's easy. Have a look at /usr/include/netgraph/atm/ng_atm.h and locate the definition of NGM_ATM_CPCS_INIT_INFO. There you see all the applicable paremeters to cpcsinit. 'traffic' is the traffic type - see /usr/include/net/if_atm.h for the ATMIO_TRAFFIC_* values. Note however, that for UBR there is no sense in specifying PCR or burst size. Perhaps you mean VBR? If you need VBR you must use an IDT77252 based card - the others don't support VBR. harti From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 08:16:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7831A16A4CE for ; Wed, 8 Sep 2004 08:16:33 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE82A43D54 for ; Wed, 8 Sep 2004 08:16:31 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i888GRw1000940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Sep 2004 12:16:28 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i888GRJi000938; Wed, 8 Sep 2004 12:16:27 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 8 Sep 2004 12:16:26 +0400 From: Gleb Smirnoff To: Glenn Thomas Message-ID: <20040908081626.GB597@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Glenn Thomas , freebsd-net@freebsd.org References: <4a64a1b8040907214468a3877c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4a64a1b8040907214468a3877c@mail.gmail.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: strange pppoe/adsl issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 08:16:33 -0000 Glenn, On Wed, Sep 08, 2004 at 02:44:15PM +1000, Glenn Thomas wrote: G> In any case, i am now quite sure that the problem is at the ISP end, G> and have got them to look into it, hopefully they can find a solution, G> but it still leaves me very confused, has anyone got any clues on what G> might be causing the problem? Even if the problem is on your ISP end, we should investigate it and find at least a workaround for you. Can you provide me with full tcpdumps of PPPoE session under problem? Use tcpdump -w dumpfile -npi fxp0, where fxp0 is your network card. Problematic part of ppp.log should be helpful, too. Are you using ppp(8)? If you do can you try mpd from ports? In opposite case can you try ppp(8)? :) -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 08:51:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2599C16A4CE; Wed, 8 Sep 2004 08:51:09 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8494C43D55; Wed, 8 Sep 2004 08:51:08 +0000 (GMT) (envelope-from Patrick.Guelat@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i888ovZs057084; Wed, 8 Sep 2004 10:50:58 +0200 (CEST) (envelope-from Patrick.Guelat@imp.ch) Received: from murphy.imp.ch (murphy.imp.ch [157.161.4.77]) by nbs.imp.ch (8.12.10/8.12.3) with ESMTP id i888ouir45485181; Wed, 8 Sep 2004 10:50:57 +0200 (MES) Date: Wed, 8 Sep 2004 10:43:34 +0000 (UTC) From: Patrick.Guelat@imp.ch X-X-Sender: patg@murphy.imp.ch To: Gleb Smirnoff In-Reply-To: <20040905121111.GA78276@cell.sick.ru> Message-ID: <20040908103529.V97761@murphy.imp.ch> References: <20040905121111.GA78276@cell.sick.ru> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1967303019-1094640214=:97761" X-Spam-Checksum: 9e8d27feef3e0325e4c386892579fe55 X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0010 seconds" X-Spam-Status: No, hits=-4.893 required=5 scantime="4.6567 seconds" tests=BAYES_00,NO_REAL_NAME, SMILEY X-Scanned-By: MIMEDefang 2.44 cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 08:51:09 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1967303019-1094640214=:97761 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Ave Glebius On Sun, 5 Sep 2004, Gleb Smirnoff wrote: > here is netgraph module which implements Netflow traffic > accounting, which I'm going to add to CURRENT in recent future: >[..] > I've been testing it for last week on loaded 100Mbit Ethernet > which serves 9 ASes, 12 prefixes :) And it works stable. Did some tests here, looks very nice ! At least our netflow-collector is happy with the data ;-) flowctl did not work for me, to which node do you have to send the msg to ? I attached two netflow nodes on a tee, one right2left and one left2right to catch both directions. -Patrick -- Patrick Guélat, ImproWare AG Network Services, CH-4133 Pratteln Mail: Patrick.Guelat@imp.ch - Phone: +41 61 826 93 00 (ext: 13) --0-1967303019-1094640214=:97761-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 08:56:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93E4616A4CE for ; Wed, 8 Sep 2004 08:56:11 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D1A643D31 for ; Wed, 8 Sep 2004 08:56:10 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i888u7Ge001391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Sep 2004 12:56:08 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i888u7mX001390; Wed, 8 Sep 2004 12:56:07 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Wed, 8 Sep 2004 12:56:07 +0400 From: Gleb Smirnoff To: Patrick.Guelat@imp.ch Message-ID: <20040908085607.GG597@cell.sick.ru> References: <20040905121111.GA78276@cell.sick.ru> <20040908103529.V97761@murphy.imp.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040908103529.V97761@murphy.imp.ch> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 08:56:11 -0000 On Wed, Sep 08, 2004 at 10:43:34AM +0000, Patrick.Guelat@imp.ch wrote: P> > here is netgraph module which implements Netflow traffic P> >accounting, which I'm going to add to CURRENT in recent future: P> >[..] P> >I've been testing it for last week on loaded 100Mbit Ethernet P> >which serves 9 ASes, 12 prefixes :) And it works stable. P> P> Did some tests here, looks very nice ! At least our netflow-collector P> is happy with the data ;-) The only empty fields are ASNs :) I hope to fill them in future. P> flowctl did not work for me, to which P> node do you have to send the msg to ? I usually call node "netflow" using 'ngctl name', and then call 'flowctl netflow show'. P> I attached two netflow nodes on a tee, one right2left and one left2right P> to catch both directions. This is working solution, but not correct. :) To catch both directions you should feed ng_netflow with incoming traffic from all interfaces. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 09:26:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FAD816A4CE for ; Wed, 8 Sep 2004 09:26:32 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E26B43D31 for ; Wed, 8 Sep 2004 09:26:31 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 25CB465216; Wed, 8 Sep 2004 10:26:29 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 71078-01; Wed, 8 Sep 2004 10:26:28 +0100 (BST) Received: from empiric.dek.spc.org (adsl-67-124-246-28.dsl.snfc21.pacbell.net [67.124.246.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 5A5BA65213; Wed, 8 Sep 2004 10:26:27 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 64D4763B1; Wed, 8 Sep 2004 02:26:24 -0700 (PDT) Date: Wed, 8 Sep 2004 02:26:24 -0700 From: Bruce M Simpson To: freebsd-net@FreeBSD.org, tcpdump-workers@tcpdump.org Message-ID: <20040908092624.GD793@empiric.icir.org> Mail-Followup-To: freebsd-net@FreeBSD.org, tcpdump-workers@tcpdump.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p2kqVDKq5asng8Dg" Content-Disposition: inline Subject: [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 09:26:32 -0000 --p2kqVDKq5asng8Dg Content-Type: multipart/mixed; boundary="xXmbgvnjoT4axfJE" Content-Disposition: inline --xXmbgvnjoT4axfJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's a patch against 5.3 to add a per-instance switch which allows the user to specify if captured packets should be timestamped (and, if so, whether microtime() or the faster but less accurate getmicrotime() call should be used). Comments/flames/etc to the usual... BMS --xXmbgvnjoT4axfJE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bpf-tstamp.diff" Content-Transfer-Encoding: quoted-printable Index: bpf.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/net/bpf.c,v retrieving revision 1.130 diff -u -p -r1.130 bpf.c --- bpf.c 5 Jul 2004 16:28:31 -0000 1.130 +++ bpf.c 8 Sep 2004 09:22:09 -0000 @@ -347,6 +347,7 @@ bpfopen(dev, flags, fmt, td) d->bd_bufsize =3D bpf_bufsize; d->bd_sig =3D SIGIO; d->bd_seesent =3D 1; + d->bd_tstamp =3D BPF_TSTAMP_MICROTIME; #ifdef MAC mac_init_bpfdesc(d); mac_create_bpfdesc(td->td_ucred, d); @@ -629,6 +630,7 @@ reset_d(d) * BIOCSHDRCMPLT Set "header already complete" flag * BIOCGSEESENT Get "see packets sent" flag * BIOCSSEESENT Set "see packets sent" flag + * BIOCSTSTAMP Set "timestamp preference" flag */ /* ARGSUSED */ static int @@ -880,6 +882,13 @@ bpfioctl(dev, cmd, addr, flags, td) d->bd_seesent =3D *(u_int *)addr; break; =20 + /* + * Set "timestamp preference" flag + */ + case BIOCSTSTAMP: + d->bd_tstamp =3D *(u_int *)addr; + break; + case FIONBIO: /* Non-blocking I/O */ break; =20 @@ -1331,7 +1340,14 @@ catchpacket(d, pkt, pktlen, snaplen, cpf * Append the bpf header. */ hp =3D (struct bpf_hdr *)(d->bd_sbuf + curlen); - microtime(&hp->bh_tstamp); + /* + * Only prepend a timestamp if instructed to do so. + * getmicrotime() is less accurate but potentially faster. + */ + if (d->bd_tstamp =3D=3D BPF_TSTAMP_MICROTIME) + microtime(&hp->bh_tstamp); + else if (d->bd_tstamp =3D=3D BPF_TSTAMP_GETMICROTIME) + getmicrotime(&hp->bh_tstamp); hp->bh_datalen =3D pktlen; hp->bh_hdrlen =3D hdrlen; /* Index: bpf.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/net/bpf.h,v retrieving revision 1.36 diff -u -p -r1.36 bpf.h --- bpf.h 30 May 2004 17:03:48 -0000 1.36 +++ bpf.h 8 Sep 2004 09:15:35 -0000 @@ -113,6 +113,7 @@ struct bpf_version { #define BIOCSSEESENT _IOW('B',119, u_int) #define BIOCSDLT _IOW('B',120, u_int) #define BIOCGDLTLIST _IOWR('B',121, struct bpf_dltlist) +#define BIOCSTSTAMP _IOW('B',122, u_int) =20 /* * Structure prepended to each packet. @@ -491,4 +492,13 @@ u_int bpf_filter(const struct bpf_insn=20 */ #define BPF_MEMWORDS 16 =20 +/* + * Defines to specify timestamping preference for a BPF instance. + * BPF_TSTAMP_MICROTIME is the default when none is specified. + * Other settings may increase BPF capture performance under load. + */ +#define BPF_TSTAMP_NONE 0x00 /* Don't timestamp packets */ +#define BPF_TSTAMP_MICROTIME 0x01 /* Use microtime() (slower) */ +#define BPF_TSTAMP_GETMICROTIME 0x02 /* Use getmicrotime() */ + #endif /* _NET_BPF_H_ */ Index: bpfdesc.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/net/bpfdesc.h,v retrieving revision 1.27 diff -u -p -r1.27 bpfdesc.h --- bpfdesc.h 7 Apr 2004 20:46:11 -0000 1.27 +++ bpfdesc.h 8 Sep 2004 09:17:16 -0000 @@ -73,6 +73,7 @@ struct bpf_d { u_char bd_promisc; /* true if listening promiscuously */ u_char bd_state; /* idle, waiting, or timed out */ u_char bd_immediate; /* true to return on packet arrival */ + u_char bd_tstamp; /* timestamping preferences */ int bd_hdrcmplt; /* false to fill in src lladdr automatically */ int bd_seesent; /* true if bpf should see sent packets */ int bd_async; /* non-zero if packet reception should generate signal */ --xXmbgvnjoT4axfJE-- --p2kqVDKq5asng8Dg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBPtA/ueUpAYYNtTsRAniIAKCCmT2iQ2Y0VicC4xIbmfjBIi8hhgCdFIaZ H536iAZXbcNRYpq4E924s5k= =9VmV -----END PGP SIGNATURE----- --p2kqVDKq5asng8Dg-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 10:33:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D67B16A4CE for ; Wed, 8 Sep 2004 10:33:05 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F02A43D48 for ; Wed, 8 Sep 2004 10:33:05 +0000 (GMT) (envelope-from windsok@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so254582rnl for ; Wed, 08 Sep 2004 03:33:04 -0700 (PDT) Received: by 10.38.15.76 with SMTP id 76mr296401rno; Wed, 08 Sep 2004 03:33:03 -0700 (PDT) Received: by 10.38.209.30 with HTTP; Wed, 8 Sep 2004 03:33:03 -0700 (PDT) Message-ID: <4a64a1b8040908033379eada47@mail.gmail.com> Date: Wed, 8 Sep 2004 20:33:03 +1000 From: Glenn Thomas To: Gleb Smirnoff , Glenn Thomas , freebsd-net@freebsd.org In-Reply-To: <20040908081626.GB597@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4a64a1b8040907214468a3877c@mail.gmail.com> <20040908081626.GB597@cell.sick.ru> Subject: Re: strange pppoe/adsl issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Glenn Thomas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 10:33:05 -0000 Hi Gleb, On Wed, 8 Sep 2004 12:16:26 +0400, Gleb Smirnoff wrote: > Even if the problem is on your ISP end, we should investigate it and > find at least a workaround for you. > Can you provide me with full tcpdumps of PPPoE session under problem? > Use tcpdump -w dumpfile -npi fxp0, where fxp0 is your network card. I have done this, and will email the file to your freebsd.org address. > Problematic part of ppp.log should be helpful, too. The ppp.log seems normal, no idication of any disconnections or anything. If you want me to try with specific log options set, i can do that. > Are you using ppp(8)? If you do can you try mpd from ports? In opposite > case can you try ppp(8)? :) I am using ppp(8), I once tried mpd but could net get a working config, I will try again, but if anyone has a working config for mpd using pppoe for ADSL, i would appreciate it :) Here is the ppp.conf I am using for ppp(8) by the way: default: adsl: set device PPPoE:fxp0 set mode ddial set authname username@provider.net.au set authkey password set speed sync set mru 1492 set mtu 1492 set ifaddr 0.0.0.0/0 0.0.0.0/0 255.255.255.0 0.0.0.0 add default HISADDR enable dns nat enable yes Regards, Glenn. From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 12:15:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB39916A4CE for ; Wed, 8 Sep 2004 12:15:59 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D69F43D2D for ; Wed, 8 Sep 2004 12:15:59 +0000 (GMT) (envelope-from windsok@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so259252rnl for ; Wed, 08 Sep 2004 05:15:55 -0700 (PDT) Received: by 10.38.82.8 with SMTP id f8mr2681398rnb; Wed, 08 Sep 2004 05:15:55 -0700 (PDT) Received: by 10.38.209.30 with HTTP; Wed, 8 Sep 2004 05:15:55 -0700 (PDT) Message-ID: <4a64a1b8040908051574be8492@mail.gmail.com> Date: Wed, 8 Sep 2004 22:15:55 +1000 From: Glenn Thomas To: Gleb Smirnoff , Glenn Thomas , freebsd-net@freebsd.org In-Reply-To: <20040908081626.GB597@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4a64a1b8040907214468a3877c@mail.gmail.com> <20040908081626.GB597@cell.sick.ru> Subject: Re: strange pppoe/adsl issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Glenn Thomas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 12:16:00 -0000 On Wed, 8 Sep 2004 12:16:26 +0400, Gleb Smirnoff wrote: > Are you using ppp(8)? If you do can you try mpd from ports? In opposite > case can you try ppp(8)? :) Ok, i tried mpd again and I can confirm that it has the exact same issue as I get with ppp(8). Regards, Glenn. From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 15:02:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26DC716A4CE for ; Wed, 8 Sep 2004 15:02:42 +0000 (GMT) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0E0743D64 for ; Wed, 8 Sep 2004 15:02:41 +0000 (GMT) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.1.113] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0)i88F2fwF027524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Sep 2004 10:02:41 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Message-ID: <413F1F16.5050303@palisadesys.com> Date: Wed, 08 Sep 2004 10:02:46 -0500 From: Guy Helmer User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <20040908092624.GD793@empiric.icir.org> In-Reply-To: <20040908092624.GD793@empiric.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: tcpdump-workers@tcpdump.org Subject: Re: [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 15:02:42 -0000 Bruce M Simpson wrote: >Here's a patch against 5.3 to add a per-instance switch which allows >the user to specify if captured packets should be timestamped (and, >if so, whether microtime() or the faster but less accurate >getmicrotime() call should be used). > > I like the idea (I've been using a hack to call getmicrotime() in bpf in my own kernels), but I wonder if it would be better as a sysctl? Then it wouldn't require changes to libpcap and/or tcpdump, and would work with any application. Thanks, Guy -- Guy Helmer, Ph.D., Principal System Architect, Palisade Systems, Inc. ghelmer@palisadesys.com ghelmer@freebsd.org From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 16:13:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C1E716A4D0 for ; Wed, 8 Sep 2004 16:13:53 +0000 (GMT) Received: from artis.latnet.lv (artis.latnet.lv [159.148.107.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4D4E43D48 for ; Wed, 8 Sep 2004 16:13:52 +0000 (GMT) (envelope-from artis@fbsd.lv) Received: from [127.0.0.1] (localhost [127.0.0.1]) by artis.latnet.lv (Postfix) with ESMTP id 9DA43B83D for ; Wed, 8 Sep 2004 19:17:38 +0300 (EEST) From: Artis Caune To: freebsd-net@freebsd.org Content-Type: text/plain Message-Id: <1094660258.1597.405.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 08 Sep 2004 19:17:38 +0300 Content-Transfer-Encoding: 7bit Subject: ifconfig.c && netmask X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 16:13:53 -0000 How come that ifconfig prints netmask in hex? Isn't "inet 127.0.0.1 netmask 255.0.0.0" more readable than "inet 127.0.0.1 netmask 0xff000000" why 'route get x.x.x.x' gives mask in decimal? ;)) Is it some posix standart or something historical or will it brake some scripts? I'm ok with hex, just want to know.. *** ! printf("netmask 0x%lx ", (unsigned long)ntohl(sin->sin_addr.s_addr)); ! printf("netmask %s ", inet_ntoa(sin->sin_addr)); *** -- Artis From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 18:13:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D7FF16A4CE; Wed, 8 Sep 2004 18:13:19 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68BD843D5D; Wed, 8 Sep 2004 18:13:19 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 0AE4E7A3D2; Wed, 8 Sep 2004 11:13:19 -0700 (PDT) Message-ID: <413F4BBE.1020304@elischer.org> Date: Wed, 08 Sep 2004 11:13:18 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905121111.GA78276@cell.sick.ru> <20040908103529.V97761@murphy.imp.ch> <20040908085607.GG597@cell.sick.ru> In-Reply-To: <20040908085607.GG597@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Patrick.Guelat@imp.ch cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 18:13:19 -0000 Gleb Smirnoff wrote: >On Wed, Sep 08, 2004 at 10:43:34AM +0000, Patrick.Guelat@imp.ch wrote: >P> > here is netgraph module which implements Netflow traffic >P> >accounting, which I'm going to add to CURRENT in recent future: >P> >[..] >P> >I've been testing it for last week on loaded 100Mbit Ethernet >P> >which serves 9 ASes, 12 prefixes :) And it works stable. >P> >P> Did some tests here, looks very nice ! At least our netflow-collector >P> is happy with the data ;-) > >The only empty fields are ASNs :) I hope to fill them in future. > >P> flowctl did not work for me, to which >P> node do you have to send the msg to ? > >I usually call node "netflow" using 'ngctl name', and then call >'flowctl netflow show'. > >P> I attached two netflow nodes on a tee, one right2left and one left2right >P> to catch both directions. > >This is working solution, but not correct. :) >To catch both directions you should feed ng_netflow with incoming traffic >from all interfaces. > using 'tee' means you are duplicating all packets. shouldn't you do collection "inline? or does this NEED to have copies of the packets? > > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 18:26:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F29E516A4CE for ; Wed, 8 Sep 2004 18:26:20 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D69243D5D for ; Wed, 8 Sep 2004 18:26:16 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 459557A3F9; Wed, 8 Sep 2004 11:26:16 -0700 (PDT) Message-ID: <413F4EC8.8030401@elischer.org> Date: Wed, 08 Sep 2004 11:26:16 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Bruce M Simpson References: <20040908092624.GD793@empiric.icir.org> In-Reply-To: <20040908092624.GD793@empiric.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: tcpdump-workers@tcpdump.org Subject: Re: [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 18:26:21 -0000 how much bandwidth change does this give? is teh timestamp really a big load? fo a 4% increase I wouldn't bother. for a 50% increase I would.. Bruce M Simpson wrote: >Here's a patch against 5.3 to add a per-instance switch which allows >the user to specify if captured packets should be timestamped (and, >if so, whether microtime() or the faster but less accurate >getmicrotime() call should be used). > >Comments/flames/etc to the usual... > >BMS > > >------------------------------------------------------------------------ > >Index: bpf.c >=================================================================== >RCS file: /home/ncvs/src/sys/net/bpf.c,v >retrieving revision 1.130 >diff -u -p -r1.130 bpf.c >--- bpf.c 5 Jul 2004 16:28:31 -0000 1.130 >+++ bpf.c 8 Sep 2004 09:22:09 -0000 >@@ -347,6 +347,7 @@ bpfopen(dev, flags, fmt, td) > d->bd_bufsize = bpf_bufsize; > d->bd_sig = SIGIO; > d->bd_seesent = 1; >+ d->bd_tstamp = BPF_TSTAMP_MICROTIME; > #ifdef MAC > mac_init_bpfdesc(d); > mac_create_bpfdesc(td->td_ucred, d); >@@ -629,6 +630,7 @@ reset_d(d) > * BIOCSHDRCMPLT Set "header already complete" flag > * BIOCGSEESENT Get "see packets sent" flag > * BIOCSSEESENT Set "see packets sent" flag >+ * BIOCSTSTAMP Set "timestamp preference" flag > */ > /* ARGSUSED */ > static int >@@ -880,6 +882,13 @@ bpfioctl(dev, cmd, addr, flags, td) > d->bd_seesent = *(u_int *)addr; > break; > >+ /* >+ * Set "timestamp preference" flag >+ */ >+ case BIOCSTSTAMP: >+ d->bd_tstamp = *(u_int *)addr; >+ break; >+ > case FIONBIO: /* Non-blocking I/O */ > break; > >@@ -1331,7 +1340,14 @@ catchpacket(d, pkt, pktlen, snaplen, cpf > * Append the bpf header. > */ > hp = (struct bpf_hdr *)(d->bd_sbuf + curlen); >- microtime(&hp->bh_tstamp); >+ /* >+ * Only prepend a timestamp if instructed to do so. >+ * getmicrotime() is less accurate but potentially faster. >+ */ >+ if (d->bd_tstamp == BPF_TSTAMP_MICROTIME) >+ microtime(&hp->bh_tstamp); >+ else if (d->bd_tstamp == BPF_TSTAMP_GETMICROTIME) >+ getmicrotime(&hp->bh_tstamp); > hp->bh_datalen = pktlen; > hp->bh_hdrlen = hdrlen; > /* >Index: bpf.h >=================================================================== >RCS file: /home/ncvs/src/sys/net/bpf.h,v >retrieving revision 1.36 >diff -u -p -r1.36 bpf.h >--- bpf.h 30 May 2004 17:03:48 -0000 1.36 >+++ bpf.h 8 Sep 2004 09:15:35 -0000 >@@ -113,6 +113,7 @@ struct bpf_version { > #define BIOCSSEESENT _IOW('B',119, u_int) > #define BIOCSDLT _IOW('B',120, u_int) > #define BIOCGDLTLIST _IOWR('B',121, struct bpf_dltlist) >+#define BIOCSTSTAMP _IOW('B',122, u_int) > > /* > * Structure prepended to each packet. >@@ -491,4 +492,13 @@ u_int bpf_filter(const struct bpf_insn > */ > #define BPF_MEMWORDS 16 > >+/* >+ * Defines to specify timestamping preference for a BPF instance. >+ * BPF_TSTAMP_MICROTIME is the default when none is specified. >+ * Other settings may increase BPF capture performance under load. >+ */ >+#define BPF_TSTAMP_NONE 0x00 /* Don't timestamp packets */ >+#define BPF_TSTAMP_MICROTIME 0x01 /* Use microtime() (slower) */ >+#define BPF_TSTAMP_GETMICROTIME 0x02 /* Use getmicrotime() */ >+ > #endif /* _NET_BPF_H_ */ >Index: bpfdesc.h >=================================================================== >RCS file: /home/ncvs/src/sys/net/bpfdesc.h,v >retrieving revision 1.27 >diff -u -p -r1.27 bpfdesc.h >--- bpfdesc.h 7 Apr 2004 20:46:11 -0000 1.27 >+++ bpfdesc.h 8 Sep 2004 09:17:16 -0000 >@@ -73,6 +73,7 @@ struct bpf_d { > u_char bd_promisc; /* true if listening promiscuously */ > u_char bd_state; /* idle, waiting, or timed out */ > u_char bd_immediate; /* true to return on packet arrival */ >+ u_char bd_tstamp; /* timestamping preferences */ > int bd_hdrcmplt; /* false to fill in src lladdr automatically */ > int bd_seesent; /* true if bpf should see sent packets */ > int bd_async; /* non-zero if packet reception should generate signal */ > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 18:44:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11C5616A4CE for ; Wed, 8 Sep 2004 18:44:01 +0000 (GMT) Received: from mail-svr1.cs.utah.edu (mail-svr1.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDEE343D49 for ; Wed, 8 Sep 2004 18:44:00 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.98.65.40]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id B5FD0346F3 for ; Wed, 8 Sep 2004 12:44:00 -0600 (MDT) Received: by faith.cs.utah.edu (Postfix, from userid 4969) id 3AC7F2EC21; Wed, 8 Sep 2004 12:43:58 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by faith.cs.utah.edu (Postfix) with ESMTP id 5D4E334406 for ; Wed, 8 Sep 2004 18:43:58 +0000 (UTC) Date: Wed, 8 Sep 2004 12:43:58 -0600 (MDT) From: Vaibhave Agarwal To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: carrier sensing in fxp drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 18:44:01 -0000 hi In ieee 802.3 CSMA/CD, is it possible that i could check a register value set by hardware card or by some other way i could detect in the driver, as soon as the card senses that there is a packet on the wire ( i.e. even before the reception of the whole packet). Anybody's help would be highly appreciated. thanks vaibhave From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 18:52:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F3CA16A4CE for ; Wed, 8 Sep 2004 18:52:32 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id F082443D48 for ; Wed, 8 Sep 2004 18:52:31 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id F13F87A3D2 for ; Wed, 8 Sep 2004 11:52:30 -0700 (PDT) Message-ID: <413F54EE.1020700@elischer.org> Date: Wed, 08 Sep 2004 11:52:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Content-Type: multipart/mixed; boundary="------------060900050207020902010207" Subject: [Fwd: TCP RTO] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 18:52:32 -0000 This is a multi-part message in MIME format. --------------060900050207020902010207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------060900050207020902010207 Content-Type: message/rfc822; name="TCP RTO" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="TCP RTO" Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by idiom.com (8.12.11/8.12.11) with ESMTP id i88GuhuR052312 for ; Wed, 8 Sep 2004 09:56:44 -0700 (PDT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 0DB8556CD1 for ; Wed, 8 Sep 2004 16:56:21 +0000 (GMT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: by hub.freebsd.org (Postfix) id DC3CB16A4CF; Wed, 8 Sep 2004 16:56:20 +0000 (GMT) Delivered-To: julian@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C1BAF16A4D0; Wed, 8 Sep 2004 16:56:20 +0000 (GMT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B04C416A4CE for ; Wed, 8 Sep 2004 16:43:39 +0000 (GMT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C0BD43D45 for ; Wed, 8 Sep 2004 16:43:39 +0000 (GMT) (envelope-from shchoi@gmail.com) Received: by mproxy.gmail.com with SMTP id w67so97456cwb for ; Wed, 08 Sep 2004 09:43:36 -0700 (PDT) Received: by 10.11.119.70 with SMTP id r70mr58105cwc; Wed, 08 Sep 2004 09:43:36 -0700 (PDT) Received: by 10.11.117.28 with HTTP; Wed, 8 Sep 2004 09:43:36 -0700 (PDT) Message-ID: <34b425c504090809435a949a03@mail.gmail.com> Date: Wed, 8 Sep 2004 17:43:36 +0100 From: Soo-Hyun Choi To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: TCP RTO X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Soo-Hyun Choi List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-Accessio-Status: NO, score=0.00,none version=6.0 count=0 X-Accessio-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on idiom.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Idiom-Reporting: If this was spam, please forward it to spambox@idiom.com Hi, I'm not sure if this list is appropriate to ask about the FreeBSD kernel source or not. If not, could somebody direct me in an appropriate list? My curiosity is if we see the tcp.cc code inside, there are two different version of srtt (smoothed rtt) and rttvar (smoothed mean deviation estimator). The one is simply 'srtt' and 'rttvar' and the other is 't_srtt' and 't_rttvar'. The unit of t_srtt is 'ticks * 8' and the unit of t_rttvar is 'ticks * 4'. These variables are used to calculate the TCP RTO. But why do they have the two different version of variables? The interesting thing is the 't_' variables are a fixed-point integer, and the original variables are just floating-point values. I assume the reason why they have is to avoid the floating-point arithmetic in the kernel. Is this really only reason for being two different version of those? Cheers, Soo-Hyun _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --------------060900050207020902010207-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 19:00:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E411C16A4D3 for ; Wed, 8 Sep 2004 19:00:32 +0000 (GMT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A972143D53 for ; Wed, 8 Sep 2004 19:00:32 +0000 (GMT) (envelope-from guy@alum.mit.edu) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i88J3NUL026847 for ; Wed, 8 Sep 2004 12:03:23 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com ; Wed, 8 Sep 2004 12:00:32 -0700 Received: from [17.202.40.208] (gharris.apple.com [17.202.40.208]) by relay4.apple.com (8.12.11/8.12.11) with ESMTP id i88J0UZw005243; Wed, 8 Sep 2004 12:00:30 -0700 (PDT) In-Reply-To: <20040908092624.GD793@empiric.icir.org> References: <20040908092624.GD793@empiric.icir.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5A076AAC-01C9-11D9-8193-000A958097E4@alum.mit.edu> Content-Transfer-Encoding: 7bit From: Guy Harris Date: Wed, 8 Sep 2004 12:00:29 -0700 To: tcpdump-workers@lists.tcpdump.org X-Mailer: Apple Mail (2.619) cc: freebsd-net@FreeBSD.org Subject: Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 19:00:33 -0000 On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote: > Here's a patch against 5.3 to add a per-instance switch which allows > the user to specify if captured packets should be timestamped (and, > if so, whether microtime() or the faster but less accurate > getmicrotime() call should be used). This is probably a pointless optimization, as you probably relatively rarely have multiple BPF devices bound to the same interface receiving the bulk of the packets (as opposed to some daemon with a filter that passes only the packets it's interested in), but would there be any advantage to having "bpf_tap()" and "bpf_mtap()" fetch the time stamp and pass that to "catchpacket()", so that in the case where there *is* more than one tap, the time stamp is only fetched once? That has the "disadvantage" that a tap might get a more accurate time stamp than it needs (the most accurate time stamp requested by a BPF device would be the one used). > Comments/flames/etc to the usual... If this is generally accepted as a good idea, it might be worth mentioning it to the other BSDs. From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 20:24:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88CD816A4CE for ; Wed, 8 Sep 2004 20:24:54 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE9AD43D31 for ; Wed, 8 Sep 2004 20:24:53 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i88KOlhL005207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Sep 2004 00:24:48 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i88KOlMX005206; Thu, 9 Sep 2004 00:24:47 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 9 Sep 2004 00:24:47 +0400 From: Gleb Smirnoff To: Julian Elischer Message-ID: <20040908202447.GA5179@cell.sick.ru> References: <20040905121111.GA78276@cell.sick.ru> <20040908103529.V97761@murphy.imp.ch> <20040908085607.GG597@cell.sick.ru> <413F4BBE.1020304@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <413F4BBE.1020304@elischer.org> User-Agent: Mutt/1.5.6i cc: Patrick.Guelat@imp.ch cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 20:24:54 -0000 On Wed, Sep 08, 2004 at 11:13:18AM -0700, Julian Elischer wrote: J> >This is working solution, but not correct. :) J> >To catch both directions you should feed ng_netflow with incoming traffic J> >from all interfaces. J> > J> J> using 'tee' means you are duplicating all packets. J> shouldn't you do collection "inline? or does this NEED to have copies of J> the packets? This is in my TODO and TOSEE list. I'm not yet sure that this would be better. There are some advantages in current state: packets are processed with no delay, and a copy is queued for netflow processing. In case of multiple interfaces attached to netflow node we can serve them simultaneosly, without waiting for lock on single netflow node. A good solution would be to send only IP and TCP header towards netflow node. Is there a standard way to do this? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 20:32:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C37B016A4CE for ; Wed, 8 Sep 2004 20:32:07 +0000 (GMT) Received: from forrie.com (forrie.ne.client2.attbi.com [24.147.45.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C24A43D39 for ; Wed, 8 Sep 2004 20:32:07 +0000 (GMT) (envelope-from forrie@forrie.com) Received: from [127.0.0.1] (i-25.forrie.net. [192.168.1.25]) by forrie.com with ESMTP id i88KVs0V041625 for ; Wed, 8 Sep 2004 16:31:57 -0400 (EDT) (envelope-from forrie@forrie.com) Message-ID: <413F6BBE.1050202@forrie.com> Date: Wed, 08 Sep 2004 16:29:50 -0400 From: Forrest Aldrich User-Agent: Mozilla Thunderbird 0.8 (Windows/20040907) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.0(snapshot 20010925) (forrie.ne.client2.attbi.com) X-MailScanner-LocalNet: Found to be clean Subject: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 20:32:07 -0000 Hi there, I'm considering testing the Vonage service, with my FreeBSD-4.10 system (maybe 5 or 6). I wonder if anyone here has a configuration they can share, or if there are any pages out there that detail the proper (and secure) setup. Thanks. From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 20:49:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33F0616A4CE for ; Wed, 8 Sep 2004 20:49:07 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFE2143D2F for ; Wed, 8 Sep 2004 20:49:06 +0000 (GMT) (envelope-from mcc@fid4.com) Received: from fid4.com (unknown[66.228.85.226]) by comcast.net (sccrmhc11) with SMTP id <200409082049050110010ahne> (Authid: m.cambria); Wed, 8 Sep 2004 20:49:06 +0000 Message-ID: <413F704A.9040705@fid4.com> Date: Wed, 08 Sep 2004 16:49:14 -0400 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <413F6BBE.1050202@forrie.com> In-Reply-To: <413F6BBE.1050202@forrie.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Forrest Aldrich Subject: Re: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 20:49:07 -0000 Forrest Aldrich wrote: > Hi there, > > I'm considering testing the Vonage service, with my FreeBSD-4.10 system > (maybe 5 or 6). > I wonder if anyone here has a configuration they can share, or if there > are any pages out there that detail the proper (and secure) setup. Will you be using your FreeBSD machine as the IP phone (e.g. kphone port) or will there be IP phones behind FreeBSD, ipfw (and natd?) acting as a router/firewall? MikeC From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 20:51:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8140416A4D3 for ; Wed, 8 Sep 2004 20:51:46 +0000 (GMT) Received: from forrie.com (forrie.ne.client2.attbi.com [24.147.45.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 240A443D5C for ; Wed, 8 Sep 2004 20:51:45 +0000 (GMT) (envelope-from forrie@forrie.com) Received: from [127.0.0.1] (i-25.forrie.net. [192.168.1.25]) by forrie.com with ESMTP id i88KpaHe042117; Wed, 8 Sep 2004 16:51:38 -0400 (EDT) (envelope-from forrie@forrie.com) Message-ID: <413F705B.40602@forrie.com> Date: Wed, 08 Sep 2004 16:49:31 -0400 From: Forrest Aldrich User-Agent: Mozilla Thunderbird 0.8 (Windows/20040907) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael C. Cambria" References: <413F6BBE.1050202@forrie.com> <413F704A.9040705@fid4.com> In-Reply-To: <413F704A.9040705@fid4.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.0(snapshot 20010925) (forrie.ne.client2.attbi.com) X-MailScanner-LocalNet: Found to be clean cc: freebsd-net@freebsd.org Subject: Re: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 20:51:46 -0000 Just going to use one VoIP phone, and it is a NAT firewall, so the phone would technically be behind that. Thanks. Michael C. Cambria wrote: > > > Forrest Aldrich wrote: > >> Hi there, >> >> I'm considering testing the Vonage service, with my FreeBSD-4.10 >> system (maybe 5 or 6). I wonder if anyone here has a configuration >> they can share, or if there are any pages out there that detail the >> proper (and secure) setup. > > > Will you be using your FreeBSD machine as the IP phone (e.g. kphone > port) or will there be IP phones behind FreeBSD, ipfw (and natd?) > acting as a router/firewall? > > MikeC > From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 21:06:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A70416A4CF for ; Wed, 8 Sep 2004 21:06:46 +0000 (GMT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DF7543D2D for ; Wed, 8 Sep 2004 21:06:46 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Sep 2004 16:06:45 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Sep 2004 16:06:45 -0500 Message-ID: <413F745F.3020306@savvis.net> Date: Wed, 08 Sep 2004 14:06:39 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Forrest Aldrich References: <413F6BBE.1050202@forrie.com> In-Reply-To: <413F6BBE.1050202@forrie.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2004 21:06:45.0442 (UTC) FILETIME=[BF675220:01C495E7] cc: freebsd-net@freebsd.org Subject: Re: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 21:06:46 -0000 Hello, > I'm considering testing the Vonage service, with my FreeBSD-4.10 > system (maybe 5 or 6). I wonder if anyone here has a configuration > they can share, or if there are any pages out there that detail the > proper (and secure) setup. i'm using lingo (www.lingo.com) - very similar to vonage. i use freebsd 4.10 as my firewall/nat/wireless access point/etc. the lingo box in behind freebsd box. it gets its ip (local) via dhcp and then talks to the lingo servers (via nat). it seems both providers are using sip, so i did not have to open anything on my nat/firewall, because the lingo box initiates the connection from the inside. if you block outgoing connecions from your lan then you will need to open a few ports. one thing i noticed about the lingo box is that it gets very upset (locks up) when it sees a lot of traffic not destined for it. i used to have hub behind freebsd and i had problems. i replaced hub with switch and now lingo box is very stable. i *do not* recommend to put lingo/vonage box in front of your firewall/router/etc. at least the lingo box is *very* open. i do not know about vonage box, but i suspect its the same class of hardware. i know manual suggests that you'd better put the box in front because it will do quality-of-service thing, but it does not make any difference (imo). i use this mostly for international calls. the quality is very good compare to regular voice. thanks, max From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 21:20:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32DD216A4CF for ; Wed, 8 Sep 2004 21:20:14 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id A536543D1F for ; Wed, 8 Sep 2004 21:20:13 +0000 (GMT) (envelope-from garycor@comcast.net) Received: from [10.56.78.111] (pcp09118143pcs.union01.nj.comcast.net[69.142.234.88]) by comcast.net (sccrmhc11) with ESMTP id <200409082120120110020jfde> (Authid: garycor); Wed, 8 Sep 2004 21:20:12 +0000 Message-ID: <413F79DC.1010204@comcast.net> Date: Wed, 08 Sep 2004 17:30:04 -0400 From: Gary Corcoran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maksim Yevmenkin References: <413F6BBE.1050202@forrie.com> <413F745F.3020306@savvis.net> In-Reply-To: <413F745F.3020306@savvis.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Forrest Aldrich Subject: Re: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 21:20:14 -0000 Maksim Yevmenkin wrote: > Hello, > >> I'm considering testing the Vonage service, with my FreeBSD-4.10 >> system (maybe 5 or 6). I wonder if anyone here has a configuration >> they can share, or if there are any pages out there that detail the >> proper (and secure) setup. > > > i'm using lingo (www.lingo.com) - very similar to vonage. i use freebsd > 4.10 as my firewall/nat/wireless access point/etc. the lingo box in > behind freebsd box. it gets its ip (local) via dhcp and then talks to > the lingo servers (via nat). it seems both providers are using sip, so i > did not have to open anything on my nat/firewall, because the lingo box > initiates the connection from the inside. I can understand how you can do outgoing calls behind a NAT firewall, because you initiate the connection. But can you receive *incoming* calls? Or are you always "connected" to the VOIP provider, and thus your firewall/reverse-nat is always open/setup? Thanks, Gary From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 21:28:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B1A016A4CF for ; Wed, 8 Sep 2004 21:28:20 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2994243D31 for ; Wed, 8 Sep 2004 21:28:20 +0000 (GMT) (envelope-from mcc@fid4.com) Received: from fid4.com (unknown[66.228.85.226]) by comcast.net (sccrmhc13) with SMTP id <2004090821281901600gqa3fe> (Authid: m.cambria); Wed, 8 Sep 2004 21:28:19 +0000 Message-ID: <413F797B.8010009@fid4.com> Date: Wed, 08 Sep 2004 17:28:27 -0400 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Forrest Aldrich References: <413F6BBE.1050202@forrie.com> <413F704A.9040705@fid4.com> <413F705B.40602@forrie.com> In-Reply-To: <413F705B.40602@forrie.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 21:28:20 -0000 Forrest Aldrich wrote: > Just going to use one VoIP phone, and it is a NAT firewall, so the phone > would technically be behind that. I don't use Vonage, but I do use FWD and iptel.org from FreeBSD, RH90 and XP systems behind my FreeBSD 4.10-Stable router running ipfw/natd. So the setup is similar. FWD's "netcheck" claims that my ipfw/natd setup is a port restricted cone NAT, but me thinks its confused. ipfw/natd behaves as symmetric NAT (someone please correct me if I'm wrong.) As a result, I use the 'relay" that FWD provides. Vonage will need to provide a similar device for your use. Inquire about this type of support before signing up. Using the relay helps in one respect. You only need one pair of rules in ipfw to allow RTP traffic to pass. With this rule, everything just worked. You can check out the configuration pages on www.freeworlddialup.com for more information. I suggest you start with FWD first, get that working, then move on to Vonage. Running ipfw/natd "open" initially will help as well. Another solution, if you don't use a relay, would be port forwarding, but this becomes problematic with the more phones you have. I also have started to run SER (see ports) with nathelper + rtpproxy on the ipfw/natd system. I prefer this solution. All my users can talk to each other via the private LAN(s), but still call out to the 'net (including iptel & FWD users) as well as receive calls. I'm still plugging away with this, so I haven't tested things beyond basic calls (e.g. conference) yet. Regards, MikeC From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 21:41:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E07C16A4CE for ; Wed, 8 Sep 2004 21:41:22 +0000 (GMT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07C4443D45 for ; Wed, 8 Sep 2004 21:41:22 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Sep 2004 16:41:21 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Sep 2004 16:41:20 -0500 Message-ID: <413F7C7F.2070603@savvis.net> Date: Wed, 08 Sep 2004 14:41:19 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Corcoran References: <413F6BBE.1050202@forrie.com> <413F745F.3020306@savvis.net> <413F79DC.1010204@comcast.net> In-Reply-To: <413F79DC.1010204@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2004 21:41:20.0133 (UTC) FILETIME=[94040B50:01C495EC] cc: freebsd-net@freebsd.org cc: Forrest Aldrich Subject: Re: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 21:41:22 -0000 Gary Corcoran wrote: > Maksim Yevmenkin wrote: > >> Hello, >> >>> I'm considering testing the Vonage service, with my FreeBSD-4.10 >>> system (maybe 5 or 6). I wonder if anyone here has a configuration >>> they can share, or if there are any pages out there that detail the >>> proper (and secure) setup. >> >> >> >> i'm using lingo (www.lingo.com) - very similar to vonage. i use >> freebsd 4.10 as my firewall/nat/wireless access point/etc. the lingo >> box in behind freebsd box. it gets its ip (local) via dhcp and then >> talks to the lingo servers (via nat). it seems both providers are >> using sip, so i did not have to open anything on my nat/firewall, >> because the lingo box initiates the connection from the inside. > > I can understand how you can do outgoing calls behind a NAT firewall, > because you initiate the connection. But can you receive *incoming* > calls? Or are you always "connected" to the VOIP provider, and thus > your firewall/reverse-nat is always open/setup? yes, the lingo box is 'always "connected"', so incoming calls work just fine. one more thing - i had to give ntp servers list in the dhcp response to the lingo box, otherwise caller id time was way off :) max From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 22:13:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D611516A4CE for ; Wed, 8 Sep 2004 22:13:17 +0000 (GMT) Received: from exchange.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 546B043D2D for ; Wed, 8 Sep 2004 22:13:17 +0000 (GMT) (envelope-from emaste@sandvine.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Date: Wed, 8 Sep 2004 11:40:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] Add ioctl to disable bpf timestamping Thread-Index: AcSVhf6W3LYJw2mITSaLnaY/RoG35gAMDjCQ From: "Ed Maste" To: , Subject: RE: [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 22:13:17 -0000 BMS wrote: > Here's a patch against 5.3 to add a per-instance switch which allows > the user to specify if captured packets should be timestamped (and, > if so, whether microtime() or the faster but less accurate > getmicrotime() call should be used). We've implemented this internally on 4.7, and have seen quite=20 impressive results. I have a test case that sends 512 byte packets and has the snap length set to get the whole packet. =20 Using microtime(), I am able to get about 120 kpps to my test=20 app. With no timestamp I can get 200 kpps. Without context=20 the absolute numbers don't mean much but the relative=20 improvement is quite impressive. Guy Helmer wrote: > I like the idea (I've been using a hack to call getmicrotime()=20 > in bpf in my own kernels), but I wonder if it would be better as a=20 > sysctl? Then it wouldn't require changes to libpcap and/or tcpdump, > and would work with any application. I think an ioctl is the right way to do it, since you could have=20 multiple BPF listeners with different requirements. For example, realtime inspection like Snort may not care about timestamps while manual inspection with tcpdump would. One way to allow the user to control this behaviour on a per- application basis would be to have libpcap check an env var in=20 order to decide if the ioctl should be set. Ed Maste Sandvine Inc. From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 22:30:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4F9216A4CE for ; Wed, 8 Sep 2004 22:30:37 +0000 (GMT) Received: from forrie.com (forrie.ne.client2.attbi.com [24.147.45.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D31B43D1D for ; Wed, 8 Sep 2004 22:30:37 +0000 (GMT) (envelope-from forrie@forrie.com) Received: from [127.0.0.1] (i-25.forrie.net. [192.168.1.25]) by forrie.com with ESMTP id i88MUNcx045272 for ; Wed, 8 Sep 2004 18:30:26 -0400 (EDT) (envelope-from forrie@forrie.com) Message-ID: <413F8782.5000606@forrie.com> Date: Wed, 08 Sep 2004 18:28:18 -0400 From: Forrest Aldrich User-Agent: Mozilla Thunderbird 0.8 (Windows/20040907) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <413F6BBE.1050202@forrie.com> <413F745F.3020306@savvis.net> <413F79DC.1010204@comcast.net> <413F7C7F.2070603@savvis.net> In-Reply-To: <413F7C7F.2070603@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.0(snapshot 20010925) (forrie.ne.client2.attbi.com) X-MailScanner-LocalNet: Found to be clean Subject: Re: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 22:30:38 -0000 I'm also speaking of specific ipfw configuration to support this functionality (QoS, traffic shaping, etc)... From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 22:37:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D70D16A4CE; Wed, 8 Sep 2004 22:37:07 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3106543D31; Wed, 8 Sep 2004 22:37:07 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 776867A43E; Wed, 8 Sep 2004 15:37:06 -0700 (PDT) Message-ID: <413F8992.1000900@elischer.org> Date: Wed, 08 Sep 2004 15:37:06 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905121111.GA78276@cell.sick.ru> <20040908103529.V97761@murphy.imp.ch> <20040908085607.GG597@cell.sick.ru> <413F4BBE.1020304@elischer.org> <20040908202447.GA5179@cell.sick.ru> In-Reply-To: <20040908202447.GA5179@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Patrick.Guelat@imp.ch cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 22:37:07 -0000 Gleb Smirnoff wrote: >On Wed, Sep 08, 2004 at 11:13:18AM -0700, Julian Elischer wrote: >J> >This is working solution, but not correct. :) >J> >To catch both directions you should feed ng_netflow with incoming traffic >J> >from all interfaces. >J> > >J> >J> using 'tee' means you are duplicating all packets. >J> shouldn't you do collection "inline? or does this NEED to have copies of >J> the packets? > >This is in my TODO and TOSEE list. I'm not yet sure that this would be better. >There are some advantages in current state: packets are processed with no delay, >and a copy is queued for netflow processing. In case of multiple interfaces >attached to netflow node we can serve them simultaneosly, without waiting for >lock on single netflow node. > >A good solution would be to send only IP and TCP header towards netflow node. >Is there a standard way to do this? > > that would be the ng_iphdr node that you are thining about writing? :-) > > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 22:48:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CFEC16A4CE for ; Wed, 8 Sep 2004 22:48:49 +0000 (GMT) Received: from out001.email.savvis.net (out001.apptix.savvis.net [216.91.32.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id F36AF43D2D for ; Wed, 8 Sep 2004 22:48:48 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out001.email.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Sep 2004 17:48:50 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Sep 2004 17:48:49 -0500 Message-ID: <413F8C4E.5040704@savvis.net> Date: Wed, 08 Sep 2004 15:48:46 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Forrest Aldrich References: <413F6BBE.1050202@forrie.com> <413F745F.3020306@savvis.net> <413F79DC.1010204@comcast.net> <413F7C7F.2070603@savvis.net> <413F8782.5000606@forrie.com> In-Reply-To: <413F8782.5000606@forrie.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2004 22:48:50.0092 (UTC) FILETIME=[01FABEC0:01C495F6] cc: freebsd-net@freebsd.org Subject: Re: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 22:48:49 -0000 Forrest Aldrich wrote: > I'm also speaking of specific ipfw configuration to support this > functionality (QoS, traffic shaping, etc)... i do not use any of it, and, i do not think it is even required. normally cable/dsl links are asymmetrical, so your outbound is already capped at 128k or whatever. inbound is whatever speed you have. i have 2mbit. at this speed i can run speed test (from dslreports.com) and talk on the phone at the same time and hardly notice anything. sometimes things may get bad for a few seconds (like bad cell phone), but normally it will recover. if you really want to do shaping then use dummynet(4). just create a pipe between vonage servers and your box and set it up the way you like. btw, a friend of mine uses vonage behind his smc barricade router. seems to work just fine. he said he did not have to open anything on the router. max From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 22:59:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3099F16A4CE for ; Wed, 8 Sep 2004 22:59:28 +0000 (GMT) Received: from exchange.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE8BA43D55 for ; Wed, 8 Sep 2004 22:59:27 +0000 (GMT) (envelope-from emaste@sandvine.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Date: Wed, 8 Sep 2004 18:59:27 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] Add ioctl to disable bpf timestamping Thread-Index: AcSVhf6W3LYJw2mITSaLnaY/RoG35gAcPc1w From: "Ed Maste" To: Subject: RE: [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 22:59:28 -0000 >From Bruce's patch: + if (d->bd_tstamp =3D=3D BPF_TSTAMP_MICROTIME) + microtime(&hp->bh_tstamp); + else if (d->bd_tstamp =3D=3D BPF_TSTAMP_GETMICROTIME) + getmicrotime(&hp->bh_tstamp); Perhaps set the timestamp to zero in the else case? Ed Maste Sandvine Inc. From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 23:04:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40F3E16A4CE for ; Wed, 8 Sep 2004 23:04:30 +0000 (GMT) Received: from web40409.mail.yahoo.com (web40409.mail.yahoo.com [66.218.78.106]) by mx1.FreeBSD.org (Postfix) with SMTP id 2D2C543D2D for ; Wed, 8 Sep 2004 23:04:30 +0000 (GMT) (envelope-from c0sine@yahoo.com) Message-ID: <20040908230429.35820.qmail@web40409.mail.yahoo.com> Received: from [69.196.154.220] by web40409.mail.yahoo.com via HTTP; Wed, 08 Sep 2004 16:04:29 PDT Date: Wed, 8 Sep 2004 16:04:29 -0700 (PDT) From: George S To: Ian FREISLICH In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: ipfw dynamic tcp rule issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 23:04:30 -0000 Hi Ian, --- Ian FREISLICH wrote: > George S wrote: > > Hi Ian, > > > > Thanks for your response. > > > > Yes, the behaviour is exactly as I describe. What happens is that on its > way > > back, the SYN+ACK packet with DST IP/PORT 10.0.0.2 and SRC IP/PORT > > 69.196.154.5/80 hits rule #1 where there is a keep-state. This causes > ipfw > > to check all dynamic rules implicitly (as per the ipfw manpage). > > > > Since the SYN+ACK packet is part of a recently setup connection, there > is a > > skipto to rule #10. Rule #10 does not match because there SRC/DST are > not > > correct, so it then passes to rule #11, which does match (and its > counters > > are updated). > > > > The problem is that the packet never finds itself on the fxp0 wire. I > will > > give your check-state suggestion a try but I think the check-state is > > implicit within rule #1. > > http://www.geocities.com/c0sine/fbsdipfw.gif > > I thought you had to explicitly state the check-state. Anyway, > I've just noticed that your last rule is #65655 which is higher > than the max for an unsigned short. Depending how this overflow > is handled, you might get odd behaviour. This might just result > in the packet being denied by the default deny rule on the way out > of fxp0. Try adding a rule just before the default deny to log > matches. It's almost always useful to do this anyway when playing > with the ruleset until everything works. Sorry, that was a typo on my part... the the last rule should be #65534. In any event, the packet rule counters are zero for this rule anyway. > I would have done the rules as follows: > > ipfw add 00010 fwd 10.0.0.1 tcp from 10.0.0.2 to any in via fxp0 > ipfw add 00020 fwd 192.168.1.1 tcp from any to 10.0.0.2 in via fxp1 > ipfw add 65534 allow ip from any to any > > Is there any particular reason for wanting a stateful firewall in > this case? Yes, it is to differentiate between the following cases of returning SYN+ACK packets received by fxp1: 1. A packet that is responding to the SYN packet originating from A (src ip 10.0.0.2) 2. A packet that is responding to a SYN packet originating from B (also with src ip 10.0.0.2) Indeed this works, because if I send my test SYN packet from B (src ip 10.0.0.2), the returning SYN+ACK triggers rule #9 (allow ip from any to any) and the packet is not forwarded out the fxp0 interface. I am still at a loss as to why the packet counts get updated and yet the packet itself is not written out on the wire. Any other suggestions? Kindest regards, George S __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 23:25:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7823C16A4D0 for ; Wed, 8 Sep 2004 23:25:26 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E48F43D2D for ; Wed, 8 Sep 2004 23:25:26 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i88NP3r2020055; Wed, 8 Sep 2004 16:25:04 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.1/8.12.2/meer) with ESMTP id i88NP1lL005461; Wed, 8 Sep 2004 16:25:01 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Thu, 09 Sep 2004 08:24:59 +0900 Message-ID: From: "George V. Neville-Neil" To: Artis Caune In-Reply-To: <1094660258.1597.405.camel@localhost> References: <1094660258.1597.405.camel@localhost> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: ifconfig.c && netmask X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 23:25:26 -0000 At Wed, 08 Sep 2004 19:17:38 +0300, Artis Caune wrote: > > How come that ifconfig prints netmask in hex? > > Isn't > "inet 127.0.0.1 netmask 255.0.0.0" > more readable than > "inet 127.0.0.1 netmask 0xff000000" > > why 'route get x.x.x.x' gives mask in decimal? > ;)) > > > Is it some posix standart or something historical or will it brake some > scripts? > It's historical. Later, George From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 23:32:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 328E816A4CE for ; Wed, 8 Sep 2004 23:32:46 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1449F43D45 for ; Wed, 8 Sep 2004 23:32:46 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i88NVYr4020161; Wed, 8 Sep 2004 16:31:36 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.1/8.12.2/meer) with ESMTP id i88NVXlL006634; Wed, 8 Sep 2004 16:31:33 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Thu, 09 Sep 2004 08:31:31 +0900 Message-ID: From: "George V. Neville-Neil" To: Julian Elischer In-Reply-To: <413F54EE.1020700@elischer.org> References: <413F54EE.1020700@elischer.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: [Fwd: TCP RTO] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 08 Sep 2004 23:32:46 -0000 At Wed, 08 Sep 2004 11:52:30 -0700, julian wrote: > My curiosity is if we see the tcp.cc code inside, tcp.cc ? That's not a kernel file. > there are two different version of srtt (smoothed rtt) and rttvar > (smoothed mean deviation estimator). The one is simply 'srtt' and > 'rttvar' and the other is 't_srtt' and 't_rttvar'. The unit of > t_srtt is 'ticks * 8' and the unit of t_rttvar is 'ticks * 4'. In -CURRENT, and I would suspect most recent versions of FreeBSD, the only variables I find are t_srtt and t_rttvar which are used as fixed point values. srtt and rttvar were variables used in the older (BSD 4.4?) code. I believe they were documented in Steven's TCP/IP Illustrated Volume 2 but I don't have my copy here so I can't check. Later, George From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 00:17:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4632D16A4CE for ; Thu, 9 Sep 2004 00:17:21 +0000 (GMT) Received: from forrie.com (forrie.ne.client2.attbi.com [24.147.45.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE54943D55 for ; Thu, 9 Sep 2004 00:17:20 +0000 (GMT) (envelope-from forrie@forrie.com) Received: from [127.0.0.1] (i-25.forrie.net. [192.168.1.25]) by forrie.com with ESMTP id i890HBkf047672 for ; Wed, 8 Sep 2004 20:17:13 -0400 (EDT) (envelope-from forrie@forrie.com) Message-ID: <413FA08A.3010803@forrie.com> Date: Wed, 08 Sep 2004 20:15:06 -0400 From: Forrest Aldrich User-Agent: Mozilla Thunderbird 0.8 (Windows/20040907) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <200409082255.i88MtPEO054166@f1.masterplan.org> In-Reply-To: <200409082255.i88MtPEO054166@f1.masterplan.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.0(snapshot 20010925) (forrie.ne.client2.attbi.com) X-MailScanner-LocalNet: Found to be clean Subject: Re: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 00:17:21 -0000 I see. I had imagined some traffic shaping and QoS necessities to manage the service (on the FreeBSD box, though I don't know how it's QoS works yet). I'd also be concerned about general security. Jason George wrote: >Subject: Re: VoIP and IPFW >To: forrie@forrie.com >Cc: > > > >>I'm also speaking of specific ipfw configuration to support this >>functionality (QoS, traffic shaping, etc)... >> >> >> >> > >I have the Vonage box behind my OpenBSD pf firewall. "It just works". > >The box grabs a DHCP address and then initiates a UDP connection to >the server at the Vonage end. Every 14 seconds, the box "polls" >the head-end. > >dew# tcpdump -i le1 host 192.168.4.11 >tcpdump: listening on le1 >16:44:40.790962 216.115.25.20.5061 > 192.168.4.11.5061: udp 478 (DF) >16:44:54.795825 192.168.4.11.5061 > 216.115.25.20.5061: udp 633 >16:44:54.884601 216.115.25.20.5061 > 192.168.4.11.5061: udp 479 (DF) >16:45:08.896124 192.168.4.11.5061 > 216.115.25.20.5061: udp 633 >16:45:08.984711 216.115.25.20.5061 > 192.168.4.11.5061: udp 479 (DF) >16:45:22.996351 192.168.4.11.5061 > 216.115.25.20.5061: udp 632 >16:45:23.121386 216.115.25.20.5061 > 192.168.4.11.5061: udp 478 (DF) >16:45:37.129823 192.168.4.11.5061 > 216.115.25.20.5061: udp 633 >16:45:37.218418 216.115.25.20.5061 > 192.168.4.11.5061: udp 479 (DF) >16:45:51.230049 192.168.4.11.5061 > 216.115.25.20.5061: udp 632 >16:45:51.425216 192.168.4.11.5061 > 216.115.25.20.5061: udp 632 >16:45:51.645703 216.115.25.20.5061 > 192.168.4.11.5061: udp 478 (DF) >16:45:51.650558 216.115.25.20.5061 > 192.168.4.11.5061: udp 478 (DF) >16:46:05.646906 192.168.4.11.5061 > 216.115.25.20.5061: udp 633 >16:46:05.735910 216.115.25.20.5061 > 192.168.4.11.5061: udp 479 (DF) >16:46:19.747073 192.168.4.11.5061 > 216.115.25.20.5061: udp 633 >16:46:19.849489 216.115.25.20.5061 > 192.168.4.11.5061: udp 479 (DF) >^C > >If an incoming call occurs, apparently the control message then causes >The box to initiate an outbound connection for the actual call completion. > >16:47:29.997893 192.168.4.11.10000 > 216.18.39.148.15974: udp 172 >16:47:30.017540 216.18.39.148.15974 > 192.168.4.11.10000: udp 172 (DF) >16:47:30.017803 192.168.4.11.10000 > 216.18.39.148.15974: udp 172 >16:47:30.038034 192.168.4.11.10000 > 216.18.39.148.15974: udp 172 >16:47:30.038671 216.18.39.148.15974 > 192.168.4.11.10000: udp 172 (DF) >16:47:30.056087 216.18.39.148.15974 > 192.168.4.11.10000: udp 172 (DF) >16:47:30.057945 192.168.4.11.10000 > 216.18.39.148.15974: udp 172 >16:47:30.075550 216.18.39.148.15974 > 192.168.4.11.10000: udp 172 (DF) >16:47:30.078019 192.168.4.11.10000 > 216.18.39.148.15974: udp 172 >16:47:30.096761 216.18.39.148.15974 > 192.168.4.11.10000: udp 172 (DF) >16:47:30.098179 192.168.4.11.10000 > 216.18.39.148.15974: udp 172 >16:47:30.117632 216.18.39.148.15974 > 192.168.4.11.10000: udp 172 (DF) >16:47:30.118223 192.168.4.11.10000 > 216.18.39.148.15974: udp 172 >16:47:30.138180 192.168.4.11.10000 > 216.18.39.148.15974: udp 172 >16:47:30.138571 216.18.39.148.15974 > 192.168.4.11.10000: udp 172 (DF) >16:47:30.154673 216.18.39.148.15974 > 192.168.4.11.10000: udp 172 (DF) > > >I actually haven't made any pf configuration changes, but I will be putting >in a QoS policy to guarantee ~100kbit/sec for the Vonage service. I >had some complaints about the quality of my voice at the far end when I was >uploading or emailing large attachments. (I'm using the highest-quality >setting on a 4Mbit/~400kbit down/up cablemodem connection.) > >Otherwise, on an unloaded link, it's just fine. > >I hope this helps...I don't have any specific IPFW settigs...sorry! > >--J >=== >Jason B. George, P.Eng., PMP - JGeorge@ResourceChain.com >ResourceChain Inc. - Project Consulting >(403) 703-5476 Cell (403) 668-0117 Office > > > > From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 06:13:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18F4C16A4CE for ; Thu, 9 Sep 2004 06:13:54 +0000 (GMT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD06F43D1D for ; Thu, 9 Sep 2004 06:13:53 +0000 (GMT) (envelope-from gharris@sonic.net) Received: from [192.168.0.5] (adsl-209-204-185-249.sonic.net [209.204.185.249]) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i896DqMT005512 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 8 Sep 2004 23:13:53 -0700 Message-ID: <413FF49F.2040000@sonic.net> Date: Wed, 08 Sep 2004 23:13:51 -0700 From: Guy Harris User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpdump-workers@lists.tcpdump.org References: <20040908092624.GD793@empiric.icir.org> <5A076AAC-01C9-11D9-8193-000A958097E4@alum.mit.edu> In-Reply-To: <5A076AAC-01C9-11D9-8193-000A958097E4@alum.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org Subject: Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 06:13:54 -0000 Guy Harris wrote: > This is probably a pointless optimization, "This" referring not to your change, but to having one time stamp call per packet. From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 06:53:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F5B716A4CE for ; Thu, 9 Sep 2004 06:53:16 +0000 (GMT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39E0043D46 for ; Thu, 9 Sep 2004 06:53:16 +0000 (GMT) (envelope-from guy@alum.mit.edu) Received: from [192.168.0.5] (adsl-209-204-185-249.sonic.net [209.204.185.249]) by a.mail.sonic.net (8.12.11/8.12.11) with ESMTP id i896rFQ0009769 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 8 Sep 2004 23:53:16 -0700 Message-ID: <413FFDDB.2000501@alum.mit.edu> Date: Wed, 08 Sep 2004 23:53:15 -0700 From: Guy Harris User-Agent: Mozilla Thunderbird 0.7.3 (Macintosh/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpdump-workers@lists.tcpdump.org References: <20040908092624.GD793@empiric.icir.org> <5A076AAC-01C9-11D9-8193-000A958097E4@alum.mit.edu> In-Reply-To: <5A076AAC-01C9-11D9-8193-000A958097E4@alum.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org Subject: Re: [tcpdump-workers] [PATCH] Add ioctl to disable bpf timestamping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 06:53:16 -0000 (Noise to defeat the duplicate-message detector for tcpdump-workers@tcpdump.org) Guy Harris wrote: > This is probably a pointless optimization, "This" referring not to Bruce's proposed change, but to my proposed change to have one time stamp call per packet. From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 10:09:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A895C16A4CE; Thu, 9 Sep 2004 10:09:29 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B66F43D3F; Thu, 9 Sep 2004 10:09:27 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) i89A9Dr2029333; Thu, 9 Sep 2004 03:09:14 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.1/8.12.2/meer) with ESMTP id i89A9Ah4089102; Thu, 9 Sep 2004 03:09:11 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Thu, 09 Sep 2004 19:09:09 +0900 Message-ID: From: "George V. Neville-Neil" To: snap-users@kame.net User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Thu_Sep__9_19:09:09_2004-1" cc: freebsd-net@freebsd.org cc: rwatson@freebsd.org cc: Bosko Milekic Subject: Patch for NetPIPE to support IPv6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 10:09:29 -0000 --Multipart_Thu_Sep__9_19:09:09_2004-1 Content-Type: text/plain; charset=US-ASCII Hi, I have created a patch for NetPIPE version 3.6.2 that makes it work with IPv6. If you're unfamiliar with NetPIPE then jump to here: http://www.scl.ameslab.gov/netpipe/ In short NetPIPE is a cool tool for generating packets and stressing/testing networks. I suggest reading the papers they have on their web site. I've submitted this patch to the nice folks at ameslab as well, and will be using it in my own work on locking down the IPv6 code in FreeBSD. Apply the patch like this: cd NetPIPE-3.2.2 patch -p0 < ~/netpipe.patch make tcp6 This will generate the program NPtcp6 which must be run as a client/server pair. server> ./NPtcp6 client> ./NPtcp6 -h You can specify IPv6 style addresses such as ::1 etc. for the -h argument. I have not tested the gethostbyname2() call yet as I'm trapped behind a NAT at the moment. It ought to work though. Bugs with the IPv6 version of this code should be sent to me, and not to the nice folks at ameslab who wrote the original. Later, George --Multipart_Thu_Sep__9_19:09:09_2004-1 Content-Type: application/octet-stream; type=patch Content-Disposition: attachment; filename="netpipe.patch" Content-Transfer-Encoding: base64 SW5kZXg6IG1ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvZ25uL1BlcnNvbmFsL0Nv ZGUvTmV0d29ya2luZy9OZXRQSVBFL21ha2VmaWxlLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEu MS4xCnJldHJpZXZpbmcgcmV2aXNpb24gMS4yCmRpZmYgLXUgLXIxLjEuMS4xIC1yMS4yCi0tLSBt YWtlZmlsZQk5IFNlcCAyMDA0IDA4OjI5OjIyIC0wMDAwCTEuMS4xLjEKKysrIG1ha2VmaWxlCTkg U2VwIDIwMDQgMDg6MzU6MDcgLTAwMDAJMS4yCkBAIC04MSw3ICs4MSwxMSBAQAogCiAKIHRjcDog JChTUkMpL3RjcC5jICQoU1JDKS9uZXRwaXBlLmMgJChTUkMpL25ldHBpcGUuaCAKLQkkKENDKSAk KENGTEFHUykgJChTUkMpL25ldHBpcGUuYyAkKFNSQykvdGNwLmMgLURUQ1AgIC1vIE5QdGNwIC1J JChTUkMpCisJJChDQykgJChDRkxBR1MpICQoU1JDKS9uZXRwaXBlLmMgJChTUkMpL3RjcC5jIC1E VENQIC1vIE5QdGNwIC1JJChTUkMpCisKK3RjcDY6ICQoU1JDKS90Y3AuYyAkKFNSQykvbmV0cGlw ZS5jICQoU1JDKS9uZXRwaXBlLmggCisJJChDQykgJChDRkxBR1MpICQoU1JDKS9uZXRwaXBlLmMg JChTUkMpL3RjcDYuYyAtRFRDUDYgXAorCQktbyBOUHRjcDYgLUkkKFNSQykKIAogbWVtY3B5OiAk KFNSQykvbWVtY3B5LmMgJChTUkMpL25ldHBpcGUuYyAkKFNSQykvbmV0cGlwZS5oCiAJJChDQykg JChDRkxBR1MpICQoU1JDKS9uZXRwaXBlLmMgJChTUkMpL21lbWNweS5jIFwKSW5kZXg6IGRveC9S RUFETUUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9nbm4vUGVyc29uYWwvQ29kZS9OZXR3b3Jr aW5nL05ldFBJUEUvZG94L1JFQURNRSx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEuMQpkaWZm IC11IC1yMS4xLjEuMSBSRUFETUUKLS0tIGRveC9SRUFETUUJOSBTZXAgMjAwNCAwODoyOTozNSAt MDAwMAkxLjEuMS4xCisrKyBkb3gvUkVBRE1FCTkgU2VwIDIwMDQgMDk6NTY6NTUgLTAwMDAKQEAg LTg1LDYgKzg1LDcgQEAKICAgbWFrZSBzaG1lbSAgICAgICgxLXNpZGVkIGxpYnJhcnkgZm9yIENy YXkgYW5kIFNHSSBzeXN0ZW1zKQogCiAgIG1ha2UgdGNwCisgIG1ha2UgdGNwNiAgICAgICAoZm9y IElQdjYgZW5hYmxlZCBzeXN0ZW1zKQogICBtYWtlIGdtICAgICAgICAgKGZvciBNeXJpbmV0IGNh cmRzLCB5b3Ugd2lsbCBuZWVkIHRvIHNldCBzb21lIHBhdGhzKQogICBtYWtlIHNobWVtICAgICAg KDEtc2lkZWQgbGlicmFyeSBmb3IgQ3JheSBhbmQgU0dJIHN5c3RlbXMpCiAgIG1ha2UgZ3BzaG1l bSAgICAoU0hNRU0gaW50ZXJmYWNlIGZvciBvdGhlciBtYWNoaW5lcykKQEAgLTE0NSw3ICsxNDYs NyBAQAogICAgICAgICAtMjogQmktZGlyZWN0aW9uYWwgY29tbXVuaWNhdGlvbnMuICBUcmFuc21p dCBpbiBib3RoIGRpcmVjdGlvbnMKICAgICAgICAgICAgIHNpbXVsdGFuZW91c2x5LgogCi0gICBU Q1AKKyAgIFRDUCBhbmQgVENQNgogICAgLS0tCiAKICAgICAgIENvbXBpbGUgTmV0UElQRSB1c2lu ZyAnbWFrZSB0Y3AnCkluZGV4OiBzcmMvbmV0cGlwZS5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9j dnMvZ25uL1BlcnNvbmFsL0NvZGUvTmV0d29ya2luZy9OZXRQSVBFL3NyYy9uZXRwaXBlLmgsdgpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMS4xLjEKcmV0cmlldmluZyByZXZpc2lvbiAxLjIKZGlmZiAt dSAtcjEuMS4xLjEgLXIxLjIKLS0tIHNyYy9uZXRwaXBlLmgJOSBTZXAgMjAwNCAwODoyOTozOCAt MDAwMAkxLjEuMS4xCisrKyBzcmMvbmV0cGlwZS5oCTkgU2VwIDIwMDQgMDg6MzU6MDcgLTAwMDAJ MS4yCkBAIC0yMyw2ICsyMywxMSBAQAogI2luY2x1ZGUgPHN0ZGxpYi5oPiAgICAgICAgIC8qIG1h bGxvYygzKSAqLwogI2luY2x1ZGUgPHVuaXN0ZC5oPiAgICAgICAgIC8qIGdldG9wdCwgcmVhZCwg d3JpdGUsIC4uLiAqLwogCisvKiBIYW5kbGUgdGhlIGNhc2Ugb2YgYnVpbGRpbmcgb24gTWFjT1Mg WCAqLworI2lmIGRlZmluZWQoX19BUFBMRV9fKQorI2luY2x1ZGUgPHN0ZGludC5oPgorI2VuZGlm IAorCiAjaWZkZWYgSU5GSU5JQkFORAogI2luY2x1ZGUgPGliX2RlZnMuaD4gLyogaWJfbXR1X3Qg Ki8KICNlbmRpZgpAQCAtODksNiArOTQsMjQgQEAKIH07CiAjZW5kaWYKIAorI2VsaWYgZGVmaW5l ZChUQ1A2KQorICAjaW5jbHVkZSA8bmV0ZGIuaD4KKyAgI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4K KyAgI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4KKyAgI2luY2x1ZGUgPG5ldGluZXQvdGNwLmg+Cisg ICNpbmNsdWRlIDxhcnBhL2luZXQuaD4KKyAgCisgIHR5cGVkZWYgc3RydWN0IHByb3RvY29sc3Ry dWN0IFByb3RvY29sU3RydWN0OworICBzdHJ1Y3QgcHJvdG9jb2xzdHJ1Y3QKKyAgeworICAgICAg c3RydWN0IHNvY2thZGRyX2luNiAgICAgc2luMTsgICAvKiBzb2NrZXQgc3RydWN0dXJlICMxICAg ICAgICAgICAgICAqLworICAgICAgc3RydWN0IHNvY2thZGRyX2luNiAgICAgc2luMjsgICAvKiBz b2NrZXQgc3RydWN0dXJlICMyICAgICAgICAgICAgICAqLworICAgICAgaW50ICAgICAgICAgICAg ICAgICAgICAgbm9kZWxheTsgIC8qIEZsYWcgZm9yIFRDUCBub2RlbGF5ICAgICAgICAgICAqLwor ICAgICAgc3RydWN0IGhvc3RlbnQgICAgICAgICAgKmFkZHI7ICAgIC8qIEFkZHJlc3Mgb2YgaG9z dCAgICAgICAgICAgICAgICAqLworICAgICAgaW50ICAgICAgICAgICAgICAgICAgICAgc25kYnVm c3o7IC8qIFNpemUgb2YgVENQIHNlbmQgYnVmZmVyICAgICAgICAqLworICAgICAgaW50ICAgICAg ICAgICAgICAgICAgICAgcmN2YnVmc3o7IC8qIFNpemUgb2YgVENQIHJlY2VpdmUgYnVmZmVyICAg ICAqLworICB9OworCiAjZWxpZiBkZWZpbmVkKE1QSSkKICAgdHlwZWRlZiBzdHJ1Y3QgcHJvdG9j b2xzdHJ1Y3QgUHJvdG9jb2xTdHJ1Y3Q7CiAgIHN0cnVjdCBwcm90b2NvbHN0cnVjdCAKQEAgLTE5 Nyw3ICsyMjAsNyBAQAogICB9OwogCiAjZWxzZQotICAjZXJyb3IgIk9uZSBvZiBUQ1AsIE1QSSwg UFZNLCBUQ0dNU0csIExBUEksIFNITUVNLCBBVE9MTCwgTUVNQ1BZLCBESVNLIG11c3QgYmUgZGVm aW5lZCBkdXJpbmcgY29tcGlsYXRpb24iCisgICNlcnJvciAiT25lIG9mIFRDUCwgVENQNiwgTVBJ LCBQVk0sIFRDR01TRywgTEFQSSwgU0hNRU0sIEFUT0xMLCBNRU1DUFksIERJU0sgbXVzdCBiZSBk ZWZpbmVkIGR1cmluZyBjb21waWxhdGlvbiIKIAogI2VuZGlmCiAKSW5kZXg6IHNyYy90Y3A2LmMK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQpSQ1MgZmlsZTogc3JjL3RjcDYuYwpkaWZmIC1OIHNyYy90Y3A2LmMKLS0tIC9k ZXYvbnVsbAkxIEphbiAxOTcwIDAwOjAwOjAwIC0wMDAwCisrKyBzcmMvdGNwNi5jCTkgU2VwIDIw MDQgMDg6MzU6MDcgLTAwMDAJMS4xCkBAIC0wLDAgKzEsNDQ0IEBACisvKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKiovCisvKiAiTmV0UElQRSIgLS0gTmV0d29yayBQcm90b2NvbCBJbmRlcGVuZGVudCBQZXJm b3JtYW5jZSBFdmFsdWF0b3IuICAgICAgICAgICovCisvKiBDb3B5cmlnaHQgMTk5NywgMTk5OCBJ b3dhIFN0YXRlIFVuaXZlcnNpdHkgUmVzZWFyY2ggRm91bmRhdGlvbiwgSW5jLiAgICAgICovCisv KiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICovCisvKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsg eW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeSAgICAgICovCisvKiBpdCB1bmRl ciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hl ZCBieSAgICAgICovCisvKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLiAgWW91IHNob3Vs ZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgICAgICovCisvKiBHTlUgR2VuZXJhbCBQdWJs aWMgTGljZW5zZSBhbG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUg ICovCisvKiBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4sIDY3NSBNYXNzIEF2ZSwgQ2Ft YnJpZGdlLCBNQSAwMjEzOSwgVVNBLiAgICovCisvKiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCisvKiBU Q1A2IGV4dGVuc2lvbiBDb3B5cmlnaHQgMjAwNCBHZW9yZ2UgVi4gTmV2aWxsZS1OZWlsIGFuZCBO ZXZpbGxlLU5laWwgICAgICovCisvKiBDb25zdWx0aW5nICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCisvKiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICovCisvKiAgICAgKiB0Y3A2LmMgICAgICAgICAtLS0tIFRDUCBvdmVyIElQdjYgY2Fs bHMgc291cmNlICAgICAgICAgICAgICAgICAgICAgICovCisvKiAgICAgKiB0Y3AuaCAgICAgICAg ICAtLS0tIEluY2x1ZGUgZmlsZSBmb3IgVENQNiBjYWxscyBhbmQgZGF0YSBzdHJ1Y3RzICAgICov CisvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKiovCisjaW5jbHVkZSAgICAibmV0cGlwZS5oIgorCisjaWYg ZGVmaW5lZCAoTVBMSVRFKQorI2luY2x1ZGUgIm1wbGl0ZS5oIgorI2VuZGlmCisKKworaW50IGRv aW5nX3Jlc2V0ID0gMDsKKwordm9pZCBJbml0KEFyZ1N0cnVjdCAqcCwgaW50KiBwYXJnYywgY2hh cioqKiBwYXJndikKK3sKKyAgICBwLT5yZXNldF9jb25uID0gMDsgLyogRGVmYXVsdCB0byBub3Qg cmVzZXR0aW5nIGNvbm5lY3Rpb24gKi8KKyAgICBwLT5wcm90LnNuZGJ1ZnN6ID0gcC0+cHJvdC5y Y3ZidWZzeiA9IDA7CisgICAgLyogVGhlIHRyYW5zbWl0dGVyIHdpbGwgYmUgc2V0IHVzaW5nIHRo ZSAtaCBob3N0IGZsYWcuICovCisgICAgcC0+dHIgPSAwOworICAgIHAtPnJjdiA9IDE7Cit9CisK K3ZvaWQgU2V0dXAoQXJnU3RydWN0ICpwKQoreworICAgIGludCBvbmUgPSAxOworICAgIGludCBz b2NrZmQgPSAtMTsKKyAgICAvKiBwdHIgdG8gc29ja2FkZHJfaW4gaW4gQXJnU3RydWN0ICovCisg ICAgc3RydWN0IHNvY2thZGRyX2luNiAqbHNpbjEsICpsc2luMjsgICAgICAKKyAgICAKKyAgICBj aGFyICpob3N0OworICAgIHN0cnVjdCBob3N0ZW50ICpocDsKKyAgICBzdHJ1Y3QgcHJvdG9lbnQg KnByb3RvOworICAgIGludCBzZW5kX3NpemUsIHJlY3Zfc2l6ZSwgc2l6ZW9maW50ID0gc2l6ZW9m KGludCk7CisJCisgICAgaG9zdCA9IHAtPmhvc3Q7ICAgICAgICAgICAgICAgICAgICAgICAgICAg LyogY29weSBwdHIgdG8gaG9zdG5hbWUgKi8gCisJCisgICAgbHNpbjEgPSAmKHAtPnByb3Quc2lu MSk7CisgICAgbHNpbjIgPSAmKHAtPnByb3Quc2luMik7CisJCisgICAgYnplcm8oKGNoYXIgKikg bHNpbjEsIHNpemVvZigqbHNpbjEpKTsKKyAgICBiemVybygoY2hhciAqKSBsc2luMiwgc2l6ZW9m KCpsc2luMikpOworCisgICAgaWYgKChzb2NrZmQgPSBzb2NrZXQoQUZfSU5FVDYsIFNPQ0tfU1RS RUFNLCAwKSkgPCAwKXsKKwlwcmludGYoIk5ldFBJUEU6IGNhbid0IG9wZW4gc3RyZWFtIHNvY2tl dCEgZXJybm89JWRcbiIsIGVycm5vKTsKKwlleGl0KC00KTsKKyAgICB9CisKKyAgICBpZighKHBy b3RvID0gZ2V0cHJvdG9ieW5hbWUoInRjcCIpKSl7CisJcHJpbnRmKCJOZXRQSVBFOiBwcm90b2Nv bCAndGNwJyB1bmtub3duIVxuIik7CisJZXhpdCg1NTUpOworICAgIH0KKworICAgIC8qIEF0dGVt cHQgdG8gc2V0IFRDUF9OT0RFTEFZICovCisKKyAgICBpZihzZXRzb2Nrb3B0KHNvY2tmZCwgcHJv dG8tPnBfcHJvdG8sIFRDUF9OT0RFTEFZLCAmb25lLCBzaXplb2Yob25lKSkgPCAwKQorICAgIHsK KwlwcmludGYoIk5ldFBJUEU6IHNldHNvY2tvcHQ6IFRDUF9OT0RFTEFZIGZhaWxlZCEgZXJybm89 JWRcbiIsIGVycm5vKTsKKwlleGl0KDU1Nik7CisgICAgfQorCisgICAgLyogSWYgcmVxdWVzdGVk LCBzZXQgdGhlIHNlbmQgYW5kIHJlY2VpdmUgYnVmZmVyIHNpemVzICovCisKKyAgICBpZihwLT5w cm90LnNuZGJ1ZnN6ID4gMCkKKyAgICB7CisJaWYoc2V0c29ja29wdChzb2NrZmQsIFNPTF9TT0NL RVQsIFNPX1NOREJVRiwgJihwLT5wcm90LnNuZGJ1ZnN6KSwgCisJCSAgICAgIHNpemVvZihwLT5w cm90LnNuZGJ1ZnN6KSkgPCAwKQorCXsKKwkgICAgcHJpbnRmKCJOZXRQSVBFOiBzZXRzb2Nrb3B0 OiBTT19TTkRCVUYgZmFpbGVkISBlcnJubz0lZFxuIiwgZXJybm8pOworCSAgICBwcmludGYoIllv dSBtYXkgaGF2ZSBhc2tlZCBmb3IgYSBidWZmZXIgbGFyZ2VyIHRoYW4gdGhlIHN5c3RlbSBjYW4g aGFuZGxlXG4iKTsKKwkgICAgZXhpdCg1NTYpOworCX0KKwlpZihzZXRzb2Nrb3B0KHNvY2tmZCwg U09MX1NPQ0tFVCwgU09fUkNWQlVGLCAmKHAtPnByb3QucmN2YnVmc3opLCAKKwkJICAgICAgc2l6 ZW9mKHAtPnByb3QucmN2YnVmc3opKSA8IDApCisJeworCSAgICBwcmludGYoIk5ldFBJUEU6IHNl dHNvY2tvcHQ6IFNPX1JDVkJVRiBmYWlsZWQhIGVycm5vPSVkXG4iLCBlcnJubyk7CisJICAgIHBy aW50ZigiWW91IG1heSBoYXZlIGFza2VkIGZvciBhIGJ1ZmZlciBsYXJnZXIgdGhhbiB0aGUgc3lz dGVtIGNhbiBoYW5kbGVcbiIpOworCSAgICBleGl0KDU1Nik7CisJfQorICAgIH0KKyAgICBnZXRz b2Nrb3B0KHNvY2tmZCwgU09MX1NPQ0tFVCwgU09fU05EQlVGLAorCSAgICAgICAoY2hhciAqKSAm c2VuZF9zaXplLCAodm9pZCAqKSAmc2l6ZW9maW50KTsKKyAgICBnZXRzb2Nrb3B0KHNvY2tmZCwg U09MX1NPQ0tFVCwgU09fUkNWQlVGLAorCSAgICAgICAoY2hhciAqKSAmcmVjdl9zaXplLCAodm9p ZCAqKSAmc2l6ZW9maW50KTsKKyAKKyAgICBpZighZG9pbmdfcmVzZXQpIHsKKwlmcHJpbnRmKHN0 ZGVyciwiU2VuZCBhbmQgcmVjZWl2ZSBidWZmZXJzIGFyZSAlZCBhbmQgJWQgYnl0ZXNcbiIsCisJ CXNlbmRfc2l6ZSwgcmVjdl9zaXplKTsKKwlmcHJpbnRmKHN0ZGVyciwgIihBIGJ1ZyBpbiBMaW51 eCBkb3VibGVzIHRoZSByZXF1ZXN0ZWQgYnVmZmVyIHNpemVzKVxuIik7CisgICAgfQorCisgICAg aWYoIHAtPnRyICkgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogUHJpbWFyeSB0cmFu c21pdHRlciAqLworCisJbHNpbjEtPnNpbjZfZmFtaWx5ID0gQUZfSU5FVDY7CisKKwkvKiBGaXJz dCBhdHRlbXB0IHRvIGNvbnZlcnQgdGhlIHN0cmluZyB0byBhbiBJUHY2ICovCisJLyogYWRkcmVz cy4gKi8KKwkvKiBJZiB0aGUgdXNlciBzdXBwbGllZCBhIHJlYWwgaG9zdCBuYW1lIHRoaXMgd2ls bCBmYWlsIGFuZCAqLworICAJLyogd2UnbGwgdGhlbiBkbyBhIG5hbWUgbG9va3VwLiAqLworCisJ aWYgKGluZXRfcHRvbihBRl9JTkVUNiwgaG9zdCwgJmxzaW4xLT5zaW42X2FkZHIpID09IDApCisJ eworCSAgICBpZiAoKGhwID0gZ2V0aG9zdGJ5bmFtZTIoaG9zdCwgQUZfSU5FVDYpKSA9PSBOVUxM KQorCSAgICB7CisJCXByaW50ZigiTmV0UElQRTogaW52YWxpZCBob3N0bmFtZSAnJXMnXG4iLCBo b3N0KTsKKwkJZXhpdCgtNSk7CisJICAgIH0KKworCSAgICBpZiAoaHAtPmhfYWRkcnR5cGUgIT0g QUZfSU5FVDYpIAorCSAgICB7CisJCXByaW50ZigiTmV0UElQRTogaW52YWxpZCBob3N0bmFtZSAn JXMnXG4iLCBob3N0KTsKKwkJZXhpdCgtNSk7CisJICAgIH0KKwkgICAgYmNvcHkoaHAtPmhfYWRk ciwgKGNoYXIqKSAmKGxzaW4xLT5zaW42X2FkZHIpLCAKKwkJICBocC0+aF9sZW5ndGgpOworCX0K KworCWxzaW4xLT5zaW42X3BvcnQgPSBodG9ucyhwLT5wb3J0KTsKKwkKKwlwLT5jb21tZmQgPSBz b2NrZmQ7CisJCisgICAgfSBlbHNlIGlmKCBwLT5yY3YgKSB7ICAgICAgICAgICAgICAgICAgICAg Lyogd2UgYXJlIHRoZSByZWNlaXZlciAqLworCWJ6ZXJvKChjaGFyICopIGxzaW4xLCBzaXplb2Yo KmxzaW4xKSk7CisJbHNpbjEtPnNpbjZfZmFtaWx5ICA9IEFGX0lORVQ2OworCWxzaW4xLT5zaW42 X2xlbiAgICAgPSBzaXplb2YoKmxzaW4xKTsKKwlsc2luMS0+c2luNl9wb3J0ICAgID0gaHRvbnMo cC0+cG9ydCk7CisJLyogU2V0dGluZyB0aGlzIHRvIGFsbCAwIGlzIHRoZSAiQU5ZIiBhZGRyZXNz LiAqLworCWJ6ZXJvKCZsc2luMS0+c2luNl9hZGRyLCBzaXplb2YobHNpbjEtPnNpbjZfYWRkcikp OworICAgCisJaWYgKGJpbmQoc29ja2ZkLCAoc3RydWN0IHNvY2thZGRyICopIGxzaW4xLCBzaXpl b2YoKmxzaW4xKSkgPCAwKXsKKwkgICAgcHJpbnRmKCJOZXRQSVBFOiBzZXJ2ZXI6IGJpbmQgb24g bG9jYWwgYWRkcmVzcyBmYWlsZWQhIGVycm5vPSVkIiwgZXJybm8pOworCSAgICBleGl0KC02KTsK Kwl9CisKKwlwLT5zZXJ2aWNlZmQgPSBzb2NrZmQ7CisgICAgfQorICAgIHAtPnVwcGVyID0gc2Vu ZF9zaXplICsgcmVjdl9zaXplOworCisgICAgZXN0YWJsaXNoKHApOyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAvKiBFc3RhYmxpc2ggY29ubmVjdGlvbnMgKi8KKworfSAgIAorCitzdGF0 aWMgaW50CityZWFkRnVsbHkoaW50IGZkLCB2b2lkICpvYnVmLCBpbnQgbGVuKQoreworICAgIGlu dCBieXRlc0xlZnQgPSBsZW47CisgICAgY2hhciAqYnVmID0gKGNoYXIgKikgb2J1ZjsKKyAgICBp bnQgYnl0ZXNSZWFkID0gMDsKKworICAgIHdoaWxlIChieXRlc0xlZnQgPiAwICYmCisJICAgKGJ5 dGVzUmVhZCA9IHJlYWQoZmQsICh2b2lkICopIGJ1ZiwgYnl0ZXNMZWZ0KSkgPiAwKQorICAgIHsK KwlieXRlc0xlZnQgLT0gYnl0ZXNSZWFkOworCWJ1ZiArPSBieXRlc1JlYWQ7CisgICAgfQorICAg IGlmIChieXRlc1JlYWQgPD0gMCkgcmV0dXJuIGJ5dGVzUmVhZDsKKyAgICByZXR1cm4gbGVuOwor fQorCit2b2lkIFN5bmMoQXJnU3RydWN0ICpwKQoreworICAgIGNoYXIgc1tdID0gIlN5bmNNZSIs IHJlc3BvbnNlW10gPSAiICAgICAgIjsKKworICAgIGlmICh3cml0ZShwLT5jb21tZmQsIHMsIHN0 cmxlbihzKSkgPCAwIHx8ICAgICAgICAgICAvKiBXcml0ZSB0byBuYm9yICovCisJcmVhZEZ1bGx5 KHAtPmNvbW1mZCwgcmVzcG9uc2UsIHN0cmxlbihzKSkgPCAwKSAgLyogUmVhZCBmcm9tIG5ib3Ig Ki8KKyAgICB7CisJcGVycm9yKCJOZXRQSVBFOiBlcnJvciB3cml0aW5nIG9yIHJlYWRpbmcgc3lu Y2hyb25pemF0aW9uIHN0cmluZyIpOworCWV4aXQoMyk7CisgICAgfQorICAgIGlmIChzdHJuY21w KHMsIHJlc3BvbnNlLCBzdHJsZW4ocykpKQorICAgIHsKKwlmcHJpbnRmKHN0ZGVyciwgIk5ldFBJ UEU6IFN5bmNocm9uaXphdGlvbiBzdHJpbmcgaW5jb3JyZWN0ISB8JXN8XG4iLCByZXNwb25zZSk7 CisJZXhpdCgzKTsKKyAgICB9Cit9CisKK3ZvaWQgUHJlcGFyZVRvUmVjZWl2ZShBcmdTdHJ1Y3Qg KnApCit7CisgICAgLyoKKyAgICAgIFRoZSBCZXJrZWxleSBzb2NrZXRzIGludGVyZmFjZSBkb2Vz bid0IGhhdmUgYSBtZXRob2QgdG8gcHJlLXBvc3QKKyAgICAgIGEgYnVmZmVyIGZvciByZWNlcHRp b24gb2YgZGF0YS4KKyAgICAqLworfQorCit2b2lkIFNlbmREYXRhKEFyZ1N0cnVjdCAqcCkKK3sK KyAgICBpbnQgYnl0ZXNXcml0dGVuLCBieXRlc0xlZnQ7CisgICAgY2hhciAqcTsKKworICAgIGJ5 dGVzTGVmdCA9IHAtPmJ1ZmZsZW47CisgICAgYnl0ZXNXcml0dGVuID0gMDsKKyAgICBxID0gcC0+ c19wdHI7CisgICAgd2hpbGUgKGJ5dGVzTGVmdCA+IDAgJiYKKwkgICAoYnl0ZXNXcml0dGVuID0g d3JpdGUocC0+Y29tbWZkLCBxLCBieXRlc0xlZnQpKSA+IDApCisgICAgeworCWJ5dGVzTGVmdCAt PSBieXRlc1dyaXR0ZW47CisJcSArPSBieXRlc1dyaXR0ZW47CisgICAgfQorICAgIGlmIChieXRl c1dyaXR0ZW4gPT0gLTEpCisgICAgeworCXByaW50ZigiTmV0UElQRTogd3JpdGU6IGVycm9yIGVu Y291bnRlcmVkLCBlcnJubz0lZFxuIiwgZXJybm8pOworCWV4aXQoNDAxKTsKKyAgICB9Cit9CisK K3ZvaWQgUmVjdkRhdGEoQXJnU3RydWN0ICpwKQoreworICAgIGludCBieXRlc0xlZnQ7CisgICAg aW50IGJ5dGVzUmVhZDsKKyAgICBjaGFyICpxOworCisgICAgYnl0ZXNMZWZ0ID0gcC0+YnVmZmxl bjsKKyAgICBieXRlc1JlYWQgPSAwOworICAgIHEgPSBwLT5yX3B0cjsKKyAgICB3aGlsZSAoYnl0 ZXNMZWZ0ID4gMCAmJgorCSAgIChieXRlc1JlYWQgPSByZWFkKHAtPmNvbW1mZCwgcSwgYnl0ZXNM ZWZ0KSkgPiAwKQorICAgIHsKKwlieXRlc0xlZnQgLT0gYnl0ZXNSZWFkOworCXEgKz0gYnl0ZXNS ZWFkOworICAgIH0KKyAgICBpZiAoYnl0ZXNMZWZ0ID4gMCAmJiBieXRlc1JlYWQgPT0gMCkKKyAg ICB7CisJcHJpbnRmKCJOZXRQSVBFOiBcImVuZCBvZiBmaWxlXCIgZW5jb3VudGVyZWQgb24gcmVh ZGluZyBmcm9tIHNvY2tldFxuIik7CisgICAgfQorICAgIGVsc2UgaWYgKGJ5dGVzUmVhZCA9PSAt MSkKKyAgICB7CisJcHJpbnRmKCJOZXRQSVBFOiByZWFkOiBlcnJvciBlbmNvdW50ZXJlZCwgZXJy bm89JWRcbiIsIGVycm5vKTsKKwlleGl0KDQwMSk7CisgICAgfQorfQorCisvKiB1aW50MzJfdCBp cyB1c2VkIHRvIGluc3VyZSB0aGF0IHRoZSBpbnRlZ2VyIHNpemUgaXMgdGhlIHNhbWUgZXZlbiBp biB0ZXN0cyAKKyAqIGJldHdlZW4gNjQtYml0IGFuZCAzMi1iaXQgYXJjaGl0ZWN0dXJlcy4gKi8K Kwordm9pZCBTZW5kVGltZShBcmdTdHJ1Y3QgKnAsIGRvdWJsZSAqdCkKK3sKKyAgICB1aW50MzJf dCBsdGltZSwgbnRpbWU7CisKKyAgICAvKgorICAgICAgTXVsdGlwbHkgdGhlIG51bWJlciBvZiBz ZWNvbmRzIGJ5IDFlOCB0byBnZXQgdGltZSBpbiAwLjAxIG1pY3Jvc2Vjb25kcworICAgICAgYW5k IGNvbnZlcnQgdmFsdWUgdG8gYW4gdW5zaWduZWQgMzItYml0IGludGVnZXIuCisgICAgKi8KKyAg ICBsdGltZSA9ICh1aW50MzJfdCkoKnQgKiAxLmU4KTsKKworICAgIC8qIFNlbmQgdGltZSBpbiBu ZXR3b3JrIG9yZGVyICovCisgICAgbnRpbWUgPSBodG9ubChsdGltZSk7CisgICAgaWYgKHdyaXRl KHAtPmNvbW1mZCwgKGNoYXIgKikmbnRpbWUsIHNpemVvZih1aW50MzJfdCkpIDwgMCkKKyAgICB7 CisJcHJpbnRmKCJOZXRQSVBFOiB3cml0ZSBmYWlsZWQgaW4gU2VuZFRpbWU6IGVycm5vPSVkXG4i LCBlcnJubyk7CisJZXhpdCgzMDEpOworICAgIH0KK30KKwordm9pZCBSZWN2VGltZShBcmdTdHJ1 Y3QgKnAsIGRvdWJsZSAqdCkKK3sKKyAgICB1aW50MzJfdCBsdGltZSwgbnRpbWU7CisgICAgaW50 IGJ5dGVzUmVhZDsKKworICAgIGJ5dGVzUmVhZCA9IHJlYWRGdWxseShwLT5jb21tZmQsICh2b2lk ICopJm50aW1lLCBzaXplb2YodWludDMyX3QpKTsKKyAgICBpZiAoYnl0ZXNSZWFkIDwgMCkKKyAg ICB7CisJcHJpbnRmKCJOZXRQSVBFOiByZWFkIGZhaWxlZCBpbiBSZWN2VGltZTogZXJybm89JWRc biIsIGVycm5vKTsKKwlleGl0KDMwMik7CisgICAgfQorICAgIGVsc2UgaWYgKGJ5dGVzUmVhZCAh PSBzaXplb2YodWludDMyX3QpKQorICAgIHsKKwlmcHJpbnRmKHN0ZGVyciwgIk5ldFBJUEU6IHBh cnRpYWwgcmVhZCBpbiBSZWN2VGltZSBvZiAlZCBieXRlc1xuIiwKKwkJYnl0ZXNSZWFkKTsKKwll eGl0KDMwMyk7CisgICAgfQorICAgIGx0aW1lID0gbnRvaGwobnRpbWUpOworCisgICAgLyogUmVz dWx0IGlzIGx0aW1lIChpbiBtaWNyb3NlY29uZHMpIGRpdmlkZWQgYnkgMS4wZTggdG8gZ2V0IHNl Y29uZHMgKi8KKworICAgICp0ID0gKGRvdWJsZSlsdGltZSAvIDEuMGU4OworfQorCit2b2lkIFNl bmRSZXBlYXQoQXJnU3RydWN0ICpwLCBpbnQgcnB0KQoreworICAgIHVpbnQzMl90IGxycHQsIG5y cHQ7CisKKyAgICBscnB0ID0gcnB0OworICAgIC8qIFNlbmQgcmVwZWF0IGNvdW50IGFzIGEgbG9u ZyBpbiBuZXR3b3JrIG9yZGVyICovCisgICAgbnJwdCA9IGh0b25sKGxycHQpOworICAgIGlmICh3 cml0ZShwLT5jb21tZmQsICh2b2lkICopICZucnB0LCBzaXplb2YodWludDMyX3QpKSA8IDApCisg ICAgeworCXByaW50ZigiTmV0UElQRTogd3JpdGUgZmFpbGVkIGluIFNlbmRSZXBlYXQ6IGVycm5v PSVkXG4iLCBlcnJubyk7CisJZXhpdCgzMDQpOworICAgIH0KK30KKwordm9pZCBSZWN2UmVwZWF0 KEFyZ1N0cnVjdCAqcCwgaW50ICpycHQpCit7CisgICAgdWludDMyX3QgbHJwdCwgbnJwdDsKKyAg ICBpbnQgYnl0ZXNSZWFkOworCisgICAgYnl0ZXNSZWFkID0gcmVhZEZ1bGx5KHAtPmNvbW1mZCwg KHZvaWQgKikmbnJwdCwgc2l6ZW9mKHVpbnQzMl90KSk7CisgICAgaWYgKGJ5dGVzUmVhZCA8IDAp CisgICAgeworCXByaW50ZigiTmV0UElQRTogcmVhZCBmYWlsZWQgaW4gUmVjdlJlcGVhdDogZXJy bm89JWRcbiIsIGVycm5vKTsKKwlleGl0KDMwNSk7CisgICAgfQorICAgIGVsc2UgaWYgKGJ5dGVz UmVhZCAhPSBzaXplb2YodWludDMyX3QpKQorICAgIHsKKwlmcHJpbnRmKHN0ZGVyciwgIk5ldFBJ UEU6IHBhcnRpYWwgcmVhZCBpbiBSZWN2UmVwZWF0IG9mICVkIGJ5dGVzXG4iLAorCQlieXRlc1Jl YWQpOworCWV4aXQoMzA2KTsKKyAgICB9CisgICAgbHJwdCA9IG50b2hsKG5ycHQpOworCisgICAg KnJwdCA9IGxycHQ7Cit9CisKK3ZvaWQgZXN0YWJsaXNoKEFyZ1N0cnVjdCAqcCkKK3sKKyAgICBp bnQgb25lID0gMTsKKyAgICBzb2NrbGVuX3QgY2xlbjsKKyAgICBzdHJ1Y3QgcHJvdG9lbnQgKnBy b3RvOworCisgICAgY2xlbiA9IChzb2NrbGVuX3QpIHNpemVvZihwLT5wcm90LnNpbjIpOworCisg ICAgaWYoIHAtPnRyICl7CisKKwl3aGlsZSggY29ubmVjdChwLT5jb21tZmQsIChzdHJ1Y3Qgc29j a2FkZHIgKikgJihwLT5wcm90LnNpbjEpLAorCQkgICAgICAgc2l6ZW9mKHAtPnByb3Quc2luMSkp IDwgMCApIHsKKworCSAgICAvKiBJZiB3ZSBhcmUgZG9pbmcgYSByZXNldCBhbmQgd2UgZ2V0IGEg Y29ubmVjdGlvbiByZWZ1c2VkIGZyb20KKwkgICAgICogdGhlIGNvbm5lY3QoKSBjYWxsLCBhc3N1 bWUgdGhhdCB0aGUgb3RoZXIgbm9kZSBoYXMgbm90IHlldAorCSAgICAgKiBnb3R0ZW4gdG8gaXRz IGNvcnJlc3BvbmRpbmcgYWNjZXB0KCkgY2FsbCBhbmQga2VlcCB0cnlpbmcgdW50aWwKKwkgICAg ICogd2UgaGF2ZSBzdWNjZXNzLgorCSAgICAgKi8KKwkgICAgaWYoIWRvaW5nX3Jlc2V0IHx8IGVy cm5vICE9IEVDT05OUkVGVVNFRCkgeworCQlwcmludGYoIkNsaWVudDogQ2Fubm90IENvbm5lY3Qh IGVycm5vPSVkXG4iLGVycm5vKTsKKwkJZXhpdCgtMTApOworCSAgICB9IAorICAgICAgICAKKwl9 CisKKyAgICB9IGVsc2UgaWYoIHAtPnJjdiApIHsKKworCS8qIFNFUlZFUiAqLworCWxpc3Rlbihw LT5zZXJ2aWNlZmQsIDUpOworCXAtPmNvbW1mZCA9IGFjY2VwdChwLT5zZXJ2aWNlZmQsIChzdHJ1 Y3Qgc29ja2FkZHIgKikgJihwLT5wcm90LnNpbjIpLCAmY2xlbik7CisKKwlpZihwLT5jb21tZmQg PCAwKXsKKwkgICAgcHJpbnRmKCJTZXJ2ZXI6IEFjY2VwdCBGYWlsZWQhIGVycm5vPSVkXG4iLGVy cm5vKTsKKwkgICAgZXhpdCgtMTIpOworCX0KKworCS8qCisJICBBdHRlbXB0IHRvIHNldCBUQ1Bf Tk9ERUxBWS4gVENQX05PREVMQVkgbWF5IG9yIG1heSBub3QgYmUgcHJvcGFnYXRlZAorCSAgdG8g YWNjZXB0ZWQgc29ja2V0cy4KKwkqLworCWlmKCEocHJvdG8gPSBnZXRwcm90b2J5bmFtZSgidGNw IikpKXsKKwkgICAgcHJpbnRmKCJ1bmtub3duIHByb3RvY29sIVxuIik7CisJICAgIGV4aXQoNTU1 KTsKKwl9CisKKwlpZihzZXRzb2Nrb3B0KHAtPmNvbW1mZCwgcHJvdG8tPnBfcHJvdG8sIFRDUF9O T0RFTEFZLAorCQkgICAgICAmb25lLCBzaXplb2Yob25lKSkgPCAwKQorCXsKKwkgICAgcHJpbnRm KCJzZXRzb2Nrb3B0OiBUQ1BfTk9ERUxBWSBmYWlsZWQhIGVycm5vPSVkXG4iLCBlcnJubyk7CisJ ICAgIGV4aXQoNTU2KTsKKwl9CisKKwkvKiBJZiByZXF1ZXN0ZWQsIHNldCB0aGUgc2VuZCBhbmQg cmVjZWl2ZSBidWZmZXIgc2l6ZXMgKi8KKwlpZihwLT5wcm90LnNuZGJ1ZnN6ID4gMCkKKwl7Cisv KiAgICAgIHByaW50ZigiU2VuZCBhbmQgUmVjZWl2ZSBCdWZmZXJzIG9uIGFjY2VwdGVkIHNvY2tl dCBzZXQgdG8gJWQgYnl0ZXNcbiIsKi8KKy8qICAgICAgICAgICBwLT5wcm90LnNuZGJ1ZnN6KTsq LworCSAgICBpZihzZXRzb2Nrb3B0KHAtPmNvbW1mZCwgU09MX1NPQ0tFVCwgU09fU05EQlVGLCAm KHAtPnByb3Quc25kYnVmc3opLCAKKwkJCSAgc2l6ZW9mKHAtPnByb3Quc25kYnVmc3opKSA8IDAp CisJICAgIHsKKwkJcHJpbnRmKCJzZXRzb2Nrb3B0OiBTT19TTkRCVUYgZmFpbGVkISBlcnJubz0l ZFxuIiwgZXJybm8pOworCQlleGl0KDU1Nik7CisJICAgIH0KKwkgICAgaWYoc2V0c29ja29wdChw LT5jb21tZmQsIFNPTF9TT0NLRVQsIFNPX1JDVkJVRiwgJihwLT5wcm90LnJjdmJ1ZnN6KSwgCisJ CQkgIHNpemVvZihwLT5wcm90LnJjdmJ1ZnN6KSkgPCAwKQorCSAgICB7CisJCXByaW50Zigic2V0 c29ja29wdDogU09fUkNWQlVGIGZhaWxlZCEgZXJybm89JWRcbiIsIGVycm5vKTsKKwkJZXhpdCg1 NTYpOworCSAgICB9CisJfQorICAgIH0KK30KKwordm9pZCBDbGVhblVwKEFyZ1N0cnVjdCAqcCkK K3sKKyAgICBjaGFyICpxdWl0PSJRVUlUIjsKKworICAgIGlmIChwLT50cikgeworCisJd3JpdGUo cC0+Y29tbWZkLHF1aXQsIDUpOworCXJlYWQocC0+Y29tbWZkLCBxdWl0LCA1KTsKKwljbG9zZShw LT5jb21tZmQpOworCisgICAgfSBlbHNlIGlmKCBwLT5yY3YgKSB7CisKKwlyZWFkKHAtPmNvbW1m ZCxxdWl0LCA1KTsKKwl3cml0ZShwLT5jb21tZmQscXVpdCw1KTsKKwljbG9zZShwLT5jb21tZmQp OworCWNsb3NlKHAtPnNlcnZpY2VmZCk7CisKKyAgICB9Cit9CisKKwordm9pZCBSZXNldChBcmdT dHJ1Y3QgKnApCit7CisgIAorICAgIC8qIFJlc2V0IHNvY2tldHMgKi8KKworICAgIGlmKHAtPnJl c2V0X2Nvbm4pIHsKKworCWRvaW5nX3Jlc2V0ID0gMTsKKworCS8qIENsb3NlIHRoZSBzb2NrZXRz ICovCisKKwlDbGVhblVwKHApOworCisJLyogTm93IG9wZW4gYW5kIGNvbm5lY3QgbmV3IHNvY2tl dHMgKi8KKworCVNldHVwKHApOworCisgICAgfQorCit9CisKK3ZvaWQgQWZ0ZXJBbGlnbm1lbnRJ bml0KEFyZ1N0cnVjdCAqcCkKK3sKKworfQorCg== --Multipart_Thu_Sep__9_19:09:09_2004-1-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 10:33:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF6DB16A4CE; Thu, 9 Sep 2004 10:33:21 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08F0F43D39; Thu, 9 Sep 2004 10:33:21 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1C5MEu-000Ga8-00; Thu, 09 Sep 2004 12:33:16 +0200 To: George S From: Ian FREISLICH In-Reply-To: Message from George S <20040908230429.35820.qmail@web40409.mail.yahoo.com> Date: Thu, 09 Sep 2004 12:33:16 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: ipfw dynamic tcp rule issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 10:33:22 -0000 George S wrote: > > I thought you had to explicitly state the check-state. Anyway, > > I've just noticed that your last rule is #65655 which is higher > > than the max for an unsigned short. Depending how this overflow > > is handled, you might get odd behaviour. This might just result > > in the packet being denied by the default deny rule on the way out > > of fxp0. Try adding a rule just before the default deny to log > > matches. It's almost always useful to do this anyway when playing > > with the ruleset until everything works. > > Sorry, that was a typo on my part... the the last rule should be #65534. In > any event, the packet rule counters are zero for this rule anyway. > > > I would have done the rules as follows: > > > > ipfw add 00010 fwd 10.0.0.1 tcp from 10.0.0.2 to any in via fxp0 > > ipfw add 00020 fwd 192.168.1.1 tcp from any to 10.0.0.2 in via fxp1 > > ipfw add 65534 allow ip from any to any > > > > Is there any particular reason for wanting a stateful firewall in > > this case? > > Yes, it is to differentiate between the following cases of returning SYN+ACK > packets received by fxp1: > > 1. A packet that is responding to the SYN packet originating from A (src ip > 10.0.0.2) > 2. A packet that is responding to a SYN packet originating from B (also with > src ip 10.0.0.2) > > Indeed this works, because if I send my test SYN packet from B (src ip > 10.0.0.2), the returning SYN+ACK triggers rule #9 (allow ip from any to any) > and the packet is not forwarded out the fxp0 interface. > > I am still at a loss as to why the packet counts get updated and yet the > packet itself is not written out on the wire. Any other suggestions? Did you try the logging deny rule? If you did, then I am out of ideas. Ian -- Ian Freislich From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 16:22:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2708D16A4CE for ; Thu, 9 Sep 2004 16:22:44 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62EDC43D49 for ; Thu, 9 Sep 2004 16:22:43 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 55133 invoked from network); 9 Sep 2004 16:19:01 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 16:19:01 -0000 Message-ID: <4140834C.3000306@freebsd.org> Date: Thu, 09 Sep 2004 18:22:36 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905121111.GA78276@cell.sick.ru> In-Reply-To: <20040905121111.GA78276@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 16:22:44 -0000 Gleb Smirnoff wrote: > Collegues, > > here is netgraph module which implements Netflow traffic > accounting, which I'm going to add to CURRENT in recent future: > > http://cell.sick.ru/~glebius/ng_netflow/ng_netflow-0.3-snap-20040905.tar.gz > > It is quite different to ng_netflow in ports/net, because its > expiry thread is running outside of netgraph context, adding > more parrallelizm on flow processing. > > I've been testing it for last week on loaded 100Mbit Ethernet > which serves 9 ASes, 12 prefixes :) And it works stable. I haven't looked into every detail but overall it's a nice piece of work. :-) In the README you are talking Netflow 5 and AS path's. I don't undestand why you want to pass the AS path into the rtentry structure? Wouldn't the right- most AS sufficise? A couple of people from OpenBSD and us are thinking of updating and extending the routing code and rtsocket framework for things like this most importantly the interaction between different routing daemons (EGP & IGP). However this is a more long-term thing and more targeted at FreeBSD 6.0. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 17:05:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08F8116A4CE for ; Thu, 9 Sep 2004 17:05:14 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2951943D55 for ; Thu, 9 Sep 2004 17:05:13 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 55382 invoked from network); 9 Sep 2004 17:01:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 17:01:31 -0000 Message-ID: <41408D4C.E33B6F98@freebsd.org> Date: Thu, 09 Sep 2004 19:05:16 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John-Mark Gurney References: <20040906050435.GA72089@funkthat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org cc: freebsd-arch@FreeBSD.org Subject: Re: better MTU support... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 17:05:14 -0000 John-Mark Gurney wrote: > > In a recent experiment w/ Jumbo frames, I found out that sending ip > frames completely ignores the MTU set on host routes. This makes it > difficult (or next to impossible) to support a network that has both > regular and jumbo frames on it as you can't restrict some hosts to the > smaller frames. What you should do instead is to set the MTU on the interface to 9018 or so and then have a default route with MTU 1500 for everything else. Now you can specify larger MTUs for hosts that support it. Otherwise you are opening a can of worms... > I now have a patch to ip_output that makes it obay the MTU set on the > route instead of that of the interface. Your patch corrects a problem in ip_output where a smaller MTU on an rtentry was ignored but that is only for the non-TCP cases. When you open a TCP session the MTU will be honored (see tcp_subr.c:tcp_maxmtu). If not it would be a bug. Could you try your large MTU setup again using the procedure I desribed above? That should solve your immediate problem. For the general 'bug' in ip_output that it doesn't honour a smaller MTU on a route I'd like to do a more throughout fix. Routes should be created with MTU 0 if the MTU is not different from the if_mtu. Only in those cases where you want to have a lower MTU you set it. For cloned routes the MTU would be cloned from the parent. This range of changes is more intrusive. On top of that comes the new ARP code which will have a MTU field as well. This one is supposed to store different MTUs for mixed MTU L2 networks. How to transport the MTU information is a separate discussion. If the fix above works for you I'd like to do the real fix later (< end of year) and not change the current behaviour in ip_output at the moment. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 17:10:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DC0716A4CE; Thu, 9 Sep 2004 17:10:22 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8239943D2F; Thu, 9 Sep 2004 17:10:21 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i89HAJbN011587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Sep 2004 21:10:19 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i89HAJ6l011586; Thu, 9 Sep 2004 21:10:19 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 9 Sep 2004 21:10:18 +0400 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20040909171018.GA11540@cell.sick.ru> References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4140834C.3000306@freebsd.org> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 17:10:22 -0000 On Thu, Sep 09, 2004 at 06:22:36PM +0200, Andre Oppermann wrote: A> I haven't looked into every detail but overall it's a nice piece of work. A> :-) Thanks :) A> In the README you are talking Netflow 5 and AS path's. I don't undestand A> why A> you want to pass the AS path into the rtentry structure? Wouldn't the A> right-most AS sufficise? AFAIK, Cisco's netflow can be configured in two modes: "peer-as", when a left-most is put into exports, and "orig-as" when a right-most is put. "orig-as" mode is default one, since most interesting statistics can be taken from it. However, "peer-as" is used for billing purposes, when we need to know which peer was transit for this traffic. A> A couple of people from OpenBSD and us are thinking of updating and A> extending A> the routing code and rtsocket framework for things like this most A> importantly A> the interaction between different routing daemons (EGP & IGP). However A> this is A> a more long-term thing and more targeted at FreeBSD 6.0. I'm working on a patch, which will bring AS path support. AS paths are going to be stored separately from rtentries. The latter will have a reference to AS paths. Each AS path is going to have a reference counter in self. This feature is going to be utilized not only for Netflow, but also in ipfw/dummynet. I think it would be very nice to shape bandwidth or make policy routing decisions using AS path regexes in ipfw rules. P.S. And we should keep an eye on XORP. It is young now, but is going to be a BSD-licensed alternative to zebra. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 17:15:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0BB416A4CF for ; Thu, 9 Sep 2004 17:15:17 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3522E43D45 for ; Thu, 9 Sep 2004 17:15:17 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 29553 invoked from network); 9 Sep 2004 17:15:16 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 17:15:16 -0000 Received: from hydrogen.funkthat.com (uxoxqv@localhost.funkthat.com [127.0.0.1])i89HFGuU073713; Thu, 9 Sep 2004 10:15:16 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i89HFFCG073712; Thu, 9 Sep 2004 10:15:15 -0700 (PDT) Date: Thu, 9 Sep 2004 10:15:15 -0700 From: John-Mark Gurney To: Andre Oppermann Message-ID: <20040909171515.GL72089@funkthat.com> Mail-Followup-To: Andre Oppermann , freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org References: <20040906050435.GA72089@funkthat.com> <41408D4C.E33B6F98@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41408D4C.E33B6F98@freebsd.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: better MTU support... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2004 17:15:17 -0000 Andre Oppermann wrote this message on Thu, Sep 09, 2004 at 19:05 +0200: > John-Mark Gurney wrote: > > > > In a recent experiment w/ Jumbo frames, I found out that sending ip > > frames completely ignores the MTU set on host routes. This makes it > > difficult (or next to impossible) to support a network that has both > > regular and jumbo frames on it as you can't restrict some hosts to the > > smaller frames. > > What you should do instead is to set the MTU on the interface to 9018 > or so and then have a default route with MTU 1500 for everything else. > Now you can specify larger MTUs for hosts that support it. > > Otherwise you are opening a can of worms... Actually, this will still be broken, since host routes on the local segment will be cloned from the link/net route, and ip will still try to use the if mtu... which is set to 9018... TCP works fine, the problem is using UDP in a mixed environment... > > I now have a patch to ip_output that makes it obay the MTU set on the > > route instead of that of the interface. > > Your patch corrects a problem in ip_output where a smaller MTU on an > rtentry was ignored but that is only for the non-TCP cases. When you > open a TCP session the MTU will be honored (see tcp_subr.c:tcp_maxmtu). > If not it would be a bug. TCP works fine, the problem is with icmp and udp and other types.. duplicating the MTU logic in each would seem excesive... > Could you try your large MTU setup again using the procedure I desribed > above? Turns out that my hub can't do jumbo frames.. so I can't completely test it beyound the simulation of 1000 being the normal MTU, and 1500 being "jumbo"... > That should solve your immediate problem. As I said, I'm pretty sure this would still break other hosts, since the issue I'm talking about doesn't touch the default route... > For the general 'bug' in ip_output that it doesn't honour a smaller MTU > on a route I'd like to do a more throughout fix. Routes should be > created with MTU 0 if the MTU is not different from the if_mtu. Only > in those cases where you want to have a lower MTU you set it. For cloned > routes the MTU would be cloned from the parent. This range of changes is > more intrusive. On top of that comes the new ARP code which will have a > MTU field as well. This one is supposed to store different MTUs for mixed > MTU L2 networks. How to transport the MTU information is a separate > discussion. > > If the fix above works for you I'd like to do the real fix later (< end > of year) and not change the current behaviour in ip_output at the moment. Sorry, I can't test it.. :( I stupidly assumed that all gige equipment supported jumbo frames... it was never a high priority, but as gige stuff is cheap, this is going to become more of an issue, and wanted to preemptively fix it.. Esspecially how cool 5.3-R is from a networking perspective. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 17:33:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5402516A4CE for ; Thu, 9 Sep 2004 17:33:16 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 735F443D45 for ; Thu, 9 Sep 2004 17:33:15 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 55638 invoked from network); 9 Sep 2004 17:29:33 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 17:29:33 -0000 Message-ID: <414093DE.A6DC6E67@freebsd.org> Date: Thu, 09 Sep 2004 19:33:18 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 17:33:16 -0000 Gleb Smirnoff wrote: > A> In the README you are talking Netflow 5 and AS path's. I don't undestand > A> why > A> you want to pass the AS path into the rtentry structure? Wouldn't the > A> right-most AS sufficise? > > AFAIK, Cisco's netflow can be configured in two modes: "peer-as", when a > left-most is put into exports, and "orig-as" when a right-most is put. > "orig-as" mode is default one, since most interesting statistics > can be taken from it. However, "peer-as" is used for billing purposes, > when we need to know which peer was transit for this traffic. Ok, makes sense now. > A> A couple of people from OpenBSD and us are thinking of updating and > A> extending > A> the routing code and rtsocket framework for things like this most > A> importantly > A> the interaction between different routing daemons (EGP & IGP). However > A> this is > A> a more long-term thing and more targeted at FreeBSD 6.0. > > I'm working on a patch, which will bring AS path support. AS paths are going > to be stored separately from rtentries. The latter will have a reference to > AS paths. Each AS path is going to have a reference counter in self. Ugh, I don't like that at all. The AS path is of variable length and the kernel should not know anything about it. The only thing the kernel *may* know about is the right- and leftmost AS. It may be more efficient to send the netflow data through a small helper application that just fills in the two AS number based on a mrt dump. > This feature is going to be utilized not only for Netflow, but also > in ipfw/dummynet. I think it would be very nice to shape bandwidth or > make policy routing decisions using AS path regexes in ipfw rules. Ugh. No, better have a way to 'tag' routes and make your decision based on those tags. Keep all the policy definition out of the kernel table. Additionally you have the tables support in ipfw already. It's far easier to extend Quagga/Zebra/etc to properly feed that table than to mangle the whole kernel for those purposes. > P.S. And we should keep an eye on XORP. It is young now, but is going to > be a BSD-licensed alternative to zebra. Have a look at OpenBGPd in OpenBSD. Does a lot more, and is useable for production networks. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 18:05:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A1E516A4CE; Thu, 9 Sep 2004 18:05:11 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA56C43D41; Thu, 9 Sep 2004 18:05:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 781191FFDDB; Thu, 9 Sep 2004 20:05:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 486401FFDD6; Thu, 9 Sep 2004 20:05:06 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 3D83E15389; Thu, 9 Sep 2004 18:02:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 326DE15384; Thu, 9 Sep 2004 18:02:35 +0000 (UTC) Date: Thu, 9 Sep 2004 18:02:35 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Andre Oppermann In-Reply-To: <414093DE.A6DC6E67@freebsd.org> Message-ID: References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: Gleb Smirnoff cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 18:05:11 -0000 On Thu, 9 Sep 2004, Andre Oppermann wrote: > The only thing the kernel *may* know about is the right- and leftmost AS. > It may be more efficient to send the netflow data through a small helper > application that just fills in the two AS number based on a mrt dump. where and when ? that's not really possible I guess. Gleb currently sends the flows directly via a ksocket. Of course one could pass them to userspace but ... One would need sth like a "callback hook" into userspace to query a (routing) daemon before sending the flow. I once did an ugly posix local socket based lookup patch to zebra so traceroute could extract AS#s. and an extra hook, if connected ask the userspace daemon (be it the routing daemon or an intermediate) at the other end for the AS# once the flow starts and if you get an answer fill it in; if you don't leave it empty. What I'd like to ask but did not because I didn't really have a chance to view more than documentation is: - what is the memory impact of this node ? - can it cope with 50++ Mbit/s UDP worms scanning large subnets ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 18:10:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D082016A4CF for ; Thu, 9 Sep 2004 18:10:58 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1032A43D53 for ; Thu, 9 Sep 2004 18:10:58 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 55961 invoked from network); 9 Sep 2004 18:07:15 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 18:07:15 -0000 Message-ID: <41409CB5.836DE816@freebsd.org> Date: Thu, 09 Sep 2004 20:11:01 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org><414093DE.A6DC6E67@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Gleb Smirnoff cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 18:10:59 -0000 "Bjoern A. Zeeb" wrote: > > On Thu, 9 Sep 2004, Andre Oppermann wrote: > > > The only thing the kernel *may* know about is the right- and leftmost AS. > > It may be more efficient to send the netflow data through a small helper > > application that just fills in the two AS number based on a mrt dump. > > where and when ? that's not really possible I guess. > Gleb currently sends the flows directly via a ksocket. Of course one > could pass them to userspace but ... I was more thinking of doing that on the collector where the Netflow UDP packets are received, not where they are generated. > One would need sth like a "callback hook" into userspace to query a > (routing) daemon before sending the flow. > I once did an ugly posix local socket based lookup patch to zebra so > traceroute could extract AS#s. What is the point of Netflow accounting? (And I do run an ISP.) Is it to get overall AS to/from AS traffic statistics? Then Netflow is not very good for that. Do you really need information on every flow? Are you going to report to the customer he had 4575 TCP flows at $0.03 each at the end of the month? -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 19:03:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ABBE16A4CE for ; Thu, 9 Sep 2004 19:03:15 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CED743D53 for ; Thu, 9 Sep 2004 19:03:14 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 56285 invoked from network); 9 Sep 2004 18:59:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 18:59:31 -0000 Message-ID: <4140A8F5.92E4A2DF@freebsd.org> Date: Thu, 09 Sep 2004 21:03:17 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 19:03:15 -0000 Gleb Smirnoff wrote: > > On Thu, Sep 09, 2004 at 06:22:36PM +0200, Andre Oppermann wrote: > A> I haven't looked into every detail but overall it's a nice piece of work. > A> :-) > > Thanks :) BTW: You may be better off using pfil_hooks instead of netgraph for your tool. You'll save one m_copym and m_freem for each packet. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 19:30:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABF4816A4CE for ; Thu, 9 Sep 2004 19:30:13 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 010DC43D5C for ; Thu, 9 Sep 2004 19:30:13 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.12.11/8.12.11) with SMTP id i89JTvFR042943; Thu, 9 Sep 2004 20:29:57 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Thu, 9 Sep 2004 20:29:55 +0100 From: Brian Somers To: Hannes Mehnert Message-ID: <20040909202955.438a4327@dev.lan.Awfulhak.org> In-Reply-To: <20040714185248.GC70193@mehnert.org> References: <200406091423.31355.durian@boogie.com> <200407121532.18503.durian@boogie.com> <20040714185248.GC70193@mehnert.org> X-Mailer: Sylpheed-Claws 0.9.12a (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gw.lan.Awfulhak.org cc: freebsd-net@freebsd.org Subject: Re: Racoon breakage with recent kernel - what NOT to do X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 19:30:13 -0000 On Wed, 14 Jul 2004 20:52:48 +0200, Hannes Mehnert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > On Mon, Jul 12, 2004 at 03:32:18PM -0600, Mike Durian wrote: > > This is just a follow-up to say the problem still exists in a -current > > system I built from source yesterday (7/11/04). Does anyone know > > what's going on? > > > > And to clarify, the URL listed above does show the same problem I'm > > seeing. > > A workaround is setting MSIZE to 320 in your kernel config: > options MSIZE=320 Well, I applied this tweak to my kernel config file (some time ago!) and it fixed the racoon issue.... **BUT** doing this badly breaks dtom() - all sorts of issues turn up when a data pointer can't be turned back into its owning mbuf pointer. This explains all of the mis-aligned mbuf frees that turn up and panic the system. In fact, I can't really explain *why* dtom() actually works, but that's the content of my other posting.... -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 19:35:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E36D16A4CE; Thu, 9 Sep 2004 19:35:10 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE44843D41; Thu, 9 Sep 2004 19:35:09 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i89JZ7ms012188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Sep 2004 23:35:07 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i89JZ74N012187; Thu, 9 Sep 2004 23:35:07 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 9 Sep 2004 23:35:07 +0400 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20040909193507.GA12168@cell.sick.ru> References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <41409CB5.836DE816@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41409CB5.836DE816@freebsd.org> User-Agent: Mutt/1.5.6i cc: "Bjoern A. Zeeb" cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 19:35:10 -0000 On Thu, Sep 09, 2004 at 08:11:01PM +0200, Andre Oppermann wrote: A> What is the point of Netflow accounting? (And I do run an ISP.) A> Is it to get overall AS to/from AS traffic statistics? Then Netflow A> is not very good for that. Do you really need information on every A> flow? Are you going to report to the customer he had 4575 TCP flows A> at $0.03 each at the end of the month? it is already offtopic, but... Here in Russia (and other C.I.S. countries) there are different classes of traffic, so at the end of the month you have to report to your customer that he has X Gb of free traffic, Y Gb of cheap traffic and Z Gb of expensive. And he may request a detalization. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 19:41:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF53816A4CE; Thu, 9 Sep 2004 19:41:22 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3426543D2F; Thu, 9 Sep 2004 19:41:20 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i89JfICp012210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Sep 2004 23:41:19 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i89JfI0O012209; Thu, 9 Sep 2004 23:41:18 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 9 Sep 2004 23:41:17 +0400 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20040909194117.GB12168@cell.sick.ru> References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <414093DE.A6DC6E67@freebsd.org> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 19:41:23 -0000 On Thu, Sep 09, 2004 at 07:33:18PM +0200, Andre Oppermann wrote: A> > I'm working on a patch, which will bring AS path support. AS paths are going A> > to be stored separately from rtentries. The latter will have a reference to A> > AS paths. Each AS path is going to have a reference counter in self. A> A> Ugh, I don't like that at all. The AS path is of variable length and A> the kernel should not know anything about it. We already had this discussion in the past. I know your position. A> The only thing the kernel *may* know about is the right- and leftmost AS. A> It may be more efficient to send the netflow data through a small helper A> application that just fills in the two AS number based on a mrt dump. A> A> > This feature is going to be utilized not only for Netflow, but also A> > in ipfw/dummynet. I think it would be very nice to shape bandwidth or A> > make policy routing decisions using AS path regexes in ipfw rules. A> A> Ugh. No, better have a way to 'tag' routes and make your decision based A> on those tags. Keep all the policy definition out of the kernel table. Isn't reference to extended information a tag? A> Additionally you have the tables support in ipfw already. It's far easier A> to extend Quagga/Zebra/etc to properly feed that table than to mangle the A> whole kernel for those purposes. That is a good idea, too. A> > P.S. And we should keep an eye on XORP. It is young now, but is going to A> > be a BSD-licensed alternative to zebra. A> A> Have a look at OpenBGPd in OpenBSD. Does a lot more, and is useable for A> production networks. If it had a nice interaction with OSPF, like zebra does, I'd consider moving to it. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 19:57:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25A6216A4CE; Thu, 9 Sep 2004 19:57:30 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68D4043D1D; Thu, 9 Sep 2004 19:57:27 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i89JvPH4012316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Sep 2004 23:57:26 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i89JvPeZ012315; Thu, 9 Sep 2004 23:57:25 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Thu, 9 Sep 2004 23:57:25 +0400 From: Gleb Smirnoff To: "Bjoern A. Zeeb" Message-ID: <20040909195725.GC12168@cell.sick.ru> References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: Andre Oppermann cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 19:57:30 -0000 On Thu, Sep 09, 2004 at 06:02:35PM +0000, Bjoern A. Zeeb wrote: B> What I'd like to ask but did not because I didn't really have a B> chance to view more than documentation is: B> - what is the memory impact of this node ? It uses a static cache (default size 65k entries). One entry takes 56 bytes, if I don't mistake. B> - can it cope with 50++ Mbit/s UDP worms scanning large subnets ? I haven't tried 50++ Mbit/s of worms, but it works on 100Mbit/s of live traffic, which is full of worms. The answer is: it depends on how large is your CPU and how quick are your worms. Try it and tell me how it goes. :) -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 19:58:57 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA41916A4CE for ; Thu, 9 Sep 2004 19:58:57 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C903D43D54 for ; Thu, 9 Sep 2004 19:58:56 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 56852 invoked from network); 9 Sep 2004 19:55:13 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 19:55:13 -0000 Message-ID: <4140B603.8E979D72@freebsd.org> Date: Thu, 09 Sep 2004 21:58:59 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <41409CB5.836DE816@freebsd.org> <20040909193507.GA12168@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: "Bjoern A. Zeeb" cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 19:58:57 -0000 Gleb Smirnoff wrote: > > On Thu, Sep 09, 2004 at 08:11:01PM +0200, Andre Oppermann wrote: > A> What is the point of Netflow accounting? (And I do run an ISP.) > A> Is it to get overall AS to/from AS traffic statistics? Then Netflow > A> is not very good for that. Do you really need information on every > A> flow? Are you going to report to the customer he had 4575 TCP flows > A> at $0.03 each at the end of the month? > > it is already offtopic, but... It is not really off-topic because you seem to use that as justification to put AS path's into the kernel. > Here in Russia (and other C.I.S. countries) there are different classes > of traffic, so at the end of the month you have to report to your > customer that he has X Gb of free traffic, Y Gb of cheap traffic > and Z Gb of expensive. And he may request a detalization. Sure. I do understand that. What I question is the use of tools to do that. Especially if you are using the right tools to do that. Do you really log all Netflow packets to disk to be able to provide details to the customer? Or do you aggregate the details on the collector? -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 20:00:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B11716A4CE; Thu, 9 Sep 2004 20:00:55 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C455543D46; Thu, 9 Sep 2004 20:00:54 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i89K0rSm012386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2004 00:00:53 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i89K0rKb012385; Fri, 10 Sep 2004 00:00:53 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Fri, 10 Sep 2004 00:00:52 +0400 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20040909200052.GD12168@cell.sick.ru> References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <41409CB5.836DE816@freebsd.org> <20040909193507.GA12168@cell.sick.ru> <4140B603.8E979D72@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4140B603.8E979D72@freebsd.org> User-Agent: Mutt/1.5.6i cc: "Bjoern A. Zeeb" cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 20:00:55 -0000 On Thu, Sep 09, 2004 at 09:58:59PM +0200, Andre Oppermann wrote: A> Do you really log all Netflow packets to disk to be able to provide A> details to the customer? Or do you aggregate the details on the A> collector? Full netflow dumps are stored on disk for about 2-3 months, aggregated data goes into billing programs and is stored for years. This is common practice here. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 20:01:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAA8F16A4CE for ; Thu, 9 Sep 2004 20:01:23 +0000 (GMT) Received: from beagle2.mehnert.org (beagle2.mehnert.org [212.42.235.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id F03BD43D2D for ; Thu, 9 Sep 2004 20:01:22 +0000 (GMT) (envelope-from hannes@mehnert.org) Received: by beagle2.mehnert.org (Postfix, from userid 127) id 1A13695866; Thu, 9 Sep 2004 22:01:21 +0200 (CEST) Received: from localhost (port-212-202-198-33.dynamic.qsc.de [212.202.198.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Hannes Mehnert", Issuer "mehnert root CA" (verified OK)) by beagle2.mehnert.org (Postfix) with ESMTP id 1592895865; Thu, 9 Sep 2004 22:01:11 +0200 (CEST) Date: Thu, 9 Sep 2004 22:01:42 +0200 From: Hannes Mehnert To: Brian Somers Message-ID: <20040909200142.GD1128@mehnert.org> References: <200406091423.31355.durian@boogie.com> <200407121532.18503.durian@boogie.com> <20040714185248.GC70193@mehnert.org> <20040909202955.438a4327@dev.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909202955.438a4327@dev.lan.Awfulhak.org> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on beagle2.mehnert.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,RCVD_IN_SORBS_DUL autolearn=no version=2.64 X-Spam-Level: cc: freebsd-net@freebsd.org Subject: Re: Racoon breakage with recent kernel - what NOT to do X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 20:01:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Thu, Sep 09, 2004 at 08:29:55PM +0100, Brian Somers wrote: > On Wed, 14 Jul 2004 20:52:48 +0200, Hannes Mehnert wrote: > > On Mon, Jul 12, 2004 at 03:32:18PM -0600, Mike Durian wrote: > > > This is just a follow-up to say the problem still exists in a -current > > > system I built from source yesterday (7/11/04). Does anyone know > > > what's going on? > > > > > > And to clarify, the URL listed above does show the same problem I'm > > > seeing. > > > > A workaround is setting MSIZE to 320 in your kernel config: > > options MSIZE=320 > > Well, I applied this tweak to my kernel config file (some time ago!) and > it fixed the racoon issue.... **BUT** doing this badly breaks dtom() - all > sorts of issues turn up when a data pointer can't be turned back into its > owning mbuf pointer. I'm currently using MSIZE=512 and get no panic. Best Regards, Hannes Mehnert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBQLajRcuNlziBjRwRAgCuAJ9ajZ3Ha5k6nLp596rI1CgjDQku5ACgwEEa bSyjt6gknTfLznRBgqEhCkk= =WPaf -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 20:11:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FF2316A4CF for ; Thu, 9 Sep 2004 20:11:09 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BC3243D54 for ; Thu, 9 Sep 2004 20:11:08 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 56975 invoked from network); 9 Sep 2004 20:07:25 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 20:07:25 -0000 Message-ID: <4140B8DF.FB83435C@freebsd.org> Date: Thu, 09 Sep 2004 22:11:11 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <20040909194117.GB12168@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 20:11:09 -0000 Gleb Smirnoff wrote: > > On Thu, Sep 09, 2004 at 07:33:18PM +0200, Andre Oppermann wrote: > A> The only thing the kernel *may* know about is the right- and leftmost AS. > A> It may be more efficient to send the netflow data through a small helper > A> application that just fills in the two AS number based on a mrt dump. > A> > A> > This feature is going to be utilized not only for Netflow, but also > A> > in ipfw/dummynet. I think it would be very nice to shape bandwidth or > A> > make policy routing decisions using AS path regexes in ipfw rules. > A> > A> Ugh. No, better have a way to 'tag' routes and make your decision based > A> on those tags. Keep all the policy definition out of the kernel table. > > Isn't reference to extended information a tag? No. The information referenced by the tag (ie. a u_int32_t) is not stored in the kernel. It is a reference to 'external' information. Think of the kqueue API. There you can store a reference to anything in your program within the kevent structure and the kernel will present it to you when get that specific event. > A> Additionally you have the tables support in ipfw already. It's far easier > A> to extend Quagga/Zebra/etc to properly feed that table than to mangle the > A> whole kernel for those purposes. > > That is a good idea, too. If I remeber correctly it was written for exactly the purpose you are referring to. Distinguish between different classes of traffic based on source/destination prefixes. The ipfw tables concept is very powerful in this context. You put the prefixes for which the traffic is for free into one table, the prefixes which are cheap into another and everything else is expensive. The prefix tables are either managed from a live [BGP] feed or updated priodically. They alway err on the side of expesive. ;-) ipfw add 1000 permit ip from [custA] to table [free] out ipfw add 1000 permit ip from [custA] to table [cheap] out ipfw add 1000 permit ip from [custA] to any out This is easily coupled with dummynet too. Just because you have to use Netflow on Cisco IOS doesn't mean you don't have (or can invent) better tools on FreeBSD. > A> > P.S. And we should keep an eye on XORP. It is young now, but is going to > A> > be a BSD-licensed alternative to zebra. > A> > A> Have a look at OpenBGPd in OpenBSD. Does a lot more, and is useable for > A> production networks. > > If it had a nice interaction with OSPF, like zebra does, I'd consider moving > to it. It doesn't interact with OSPF at all at the moment. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 20:16:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C4C216A4D1 for ; Thu, 9 Sep 2004 20:16:38 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D22F43D53 for ; Thu, 9 Sep 2004 20:16:37 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 57047 invoked from network); 9 Sep 2004 20:12:53 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Sep 2004 20:12:53 -0000 Message-ID: <4140BA28.6D24FE75@freebsd.org> Date: Thu, 09 Sep 2004 22:16:40 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <41409CB5.836DE816@freebsd.org> <20040909193507.GA12168@cell.sick.ru> <4140B603.8E979D72@freebsd.org> <20040909200052.GD12168@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: "Bjoern A. Zeeb" cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 20:16:38 -0000 Gleb Smirnoff wrote: > > On Thu, Sep 09, 2004 at 09:58:59PM +0200, Andre Oppermann wrote: > A> Do you really log all Netflow packets to disk to be able to provide > A> details to the customer? Or do you aggregate the details on the > A> collector? > > Full netflow dumps are stored on disk for about 2-3 months, aggregated > data goes into billing programs and is stored for years. This is common > practice here. Ugh. How much disk space does that occupy? How many mbits are your upstreams? -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 20:41:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0456B16A4CE for ; Thu, 9 Sep 2004 20:41:30 +0000 (GMT) Received: from diaspar.rdsnet.ro (diaspar.rdsnet.ro [213.157.165.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1AE943D4C for ; Thu, 9 Sep 2004 20:41:28 +0000 (GMT) (envelope-from dudu@diaspar.rdsnet.ro) Received: (qmail 18294 invoked by uid 89); 9 Sep 2004 20:41:58 -0000 Received: from unknown (HELO snakepit) (dudu@diaspar.rdsnet.ro@62.231.127.38) by 0 with AES256-SHA encrypted SMTP; 9 Sep 2004 20:41:58 -0000 Date: Thu, 9 Sep 2004 23:41:26 +0300 From: Vlad GALU To: freebsd-net@freebsd.org Message-Id: <20040909234126.3f1c7cf3.dudu@diaspar.rdsnet.ro> In-Reply-To: <20040909200052.GD12168@cell.sick.ru> References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <41409CB5.836DE816@freebsd.org> <20040909193507.GA12168@cell.sick.ru> <4140B603.8E979D72@freebsd.org> <20040909200052.GD12168@cell.sick.ru> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 20:41:30 -0000 On Fri, 10 Sep 2004 00:00:52 +0400 Gleb Smirnoff wrote: > On Thu, Sep 09, 2004 at 09:58:59PM +0200, Andre Oppermann wrote: > A> Do you really log all Netflow packets to disk to be able to provide > A> details to the customer? Or do you aggregate the details on the > A> collector? > > Full netflow dumps are stored on disk for about 2-3 months, aggregated > data goes into billing programs and is stored for years. This is > common practice here. This made me raise my eyebrow. I wrote a small tool that we use in production at RDS: http://freshmeat.net/projects/glflow. The way I designed it, it is supposed to clean up the flow tree once in a while and remove 'old' flows (that haven't had any packet matching them in the last X seconds). The problem is that I currently have about 400-500k active flows on a 700Mbps link. Every 10 seconds the software removes about 100-200k of them in no more than 0.2-0.3 seconds. Of course, I couldn't possibly send them over a socket somewhere else at that speed,, and chose to open a tempfile, mmap() it, write the expired flows to the buffer. When the buffer exceeds a programatically chosen number of packets, it is msync()-ed, munmap()-ed and a new file is open. Do you accidentally have a better storage model ? I've been trying to dump these binary files to SQL but for a 42 meg binary log the necessary SQL storage went to about 150 megs, which is a bit over reasonable, considering the fact that the software dumps a binary file every 5 to 10 seconds. P.S. I haven't yet tried to aggregate the flows between reading them from the binary file and inserting the data into SQL. I thought it would take too much time to be able to keep up with the newly created dumps. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > _______________________________________________ > 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" > > !DSPAM:4140b6e2920391200521163! > ---- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 20:46:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 485B816A4CE for ; Thu, 9 Sep 2004 20:46:05 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9592243D54 for ; Thu, 9 Sep 2004 20:46:04 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.12.11/8.12.11) with SMTP id i89Kk1Hp043344 for ; Thu, 9 Sep 2004 21:46:01 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Thu, 9 Sep 2004 21:46:00 +0100 From: Brian Somers To: freebsd-net@FreeBSD.org Message-ID: <20040909214600.12bb5fd5@dev.lan.Awfulhak.org> X-Mailer: Sylpheed-Claws 0.9.12a (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gw.lan.Awfulhak.org Subject: uma_zcreate() call from kern_mbuf.c - bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 20:46:05 -0000 I'm a bit confused by this uma_zcreate() call in kern_mbuf.c: zone_mbuf = uma_zcreate("Mbuf", MSIZE, mb_ctor_mbuf, mb_dtor_mbuf, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_MAXBUCKET); Given that dtom() is defined as: #define dtom(x) ((struct mbuf *)((intptr_t)(x) & ~(MSIZE-1))) shouldn't this mean that the uma_zcreate should be: zone_mbuf = uma_zcreate("Mbuf", MSIZE, mb_ctor_mbuf, mb_dtor_mbuf, NULL, NULL, MSIZE - 1, UMA_ZONE_MAXBUCKET); Of course m_get() et. al. seem to manage to get MSIZE aligned pointers back from uma_zalloc_arg(zone_mbuf...) anyway, but surely that's an implementation side effect and the align argument should be corrected. There should probably also be a KASSERT here to ensure that MSIZE is sane (and to stop idiots like me from shooting themselves in the foot with ``options MSIZE=320''). Comments on this patch ? Index: kern_mbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_mbuf.c,v retrieving revision 1.3 diff -u -r1.3 kern_mbuf.c --- kern_mbuf.c 2 Aug 2004 00:18:35 -0000 1.3 +++ kern_mbuf.c 9 Sep 2004 20:24:46 -0000 @@ -131,11 +131,15 @@ mbuf_init(void *dummy) { + /* Ensure that MSIZE doesn't break dtom() */ + KASSERT((((MSIZE - 1) ^ MSIZE) + 1) >> 1 == MSIZE, + ("Invalid MSIZE - must only have a single bit set")); + /* * Configure UMA zones for Mbufs, Clusters, and Packets. */ zone_mbuf = uma_zcreate("Mbuf", MSIZE, mb_ctor_mbuf, mb_dtor_mbuf, - NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_MAXBUCKET); + NULL, NULL, MSIZE - 1, UMA_ZONE_MAXBUCKET); zone_clust = uma_zcreate("MbufClust", MCLBYTES, mb_ctor_clust, mb_dtor_clust, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_REFCNT); if (nmbclusters > 0) -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 20:49:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4423D16A4CE for ; Thu, 9 Sep 2004 20:49:21 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E46643D1D for ; Thu, 9 Sep 2004 20:49:20 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.12.11/8.12.11) with SMTP id i89KnGGP043390; Thu, 9 Sep 2004 21:49:17 +0100 (BST) (envelope-from brian@Awfulhak.org) Date: Thu, 9 Sep 2004 21:49:16 +0100 From: Brian Somers To: Hannes Mehnert Message-ID: <20040909214916.11f99cdb@dev.lan.Awfulhak.org> In-Reply-To: <20040909200142.GD1128@mehnert.org> References: <200406091423.31355.durian@boogie.com> <200407121532.18503.durian@boogie.com> <20040714185248.GC70193@mehnert.org> <20040909202955.438a4327@dev.lan.Awfulhak.org> <20040909200142.GD1128@mehnert.org> X-Mailer: Sylpheed-Claws 0.9.12a (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gw.lan.Awfulhak.org cc: freebsd-net@freebsd.org Subject: Re: Racoon breakage with recent kernel - what NOT to do X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 20:49:21 -0000 On Thu, 9 Sep 2004 22:01:42 +0200, Hannes Mehnert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > On Thu, Sep 09, 2004 at 08:29:55PM +0100, Brian Somers wrote: > > On Wed, 14 Jul 2004 20:52:48 +0200, Hannes Mehnert wrote: > > > On Mon, Jul 12, 2004 at 03:32:18PM -0600, Mike Durian wrote: > > > > This is just a follow-up to say the problem still exists in a -current > > > > system I built from source yesterday (7/11/04). Does anyone know > > > > what's going on? > > > > > > > > And to clarify, the URL listed above does show the same problem I'm > > > > seeing. > > > > > > A workaround is setting MSIZE to 320 in your kernel config: > > > options MSIZE=320 > > > > Well, I applied this tweak to my kernel config file (some time ago!) and > > it fixed the racoon issue.... **BUT** doing this badly breaks dtom() - all > > sorts of issues turn up when a data pointer can't be turned back into its > > owning mbuf pointer. > > I'm currently using MSIZE=512 and get no panic. Yes, MSIZE=512 works as it contains only one set bit. MSIZE=320 doesn't because there are two bits set. I've posted my other message to -net with a better description. Cheers. -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 20:59:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9559F16A4CE for ; Thu, 9 Sep 2004 20:59:01 +0000 (GMT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65B7B43D55 for ; Thu, 9 Sep 2004 20:59:01 +0000 (GMT) (envelope-from durian@boogie.com) Received: from cpe-66-87-52-132.co.sprintbbd.net ([66.87.52.132] helo=mailhost.boogie.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1C5W0P-0003yR-00; Thu, 09 Sep 2004 13:58:57 -0700 Received: from man.boogie.com (man.boogie.com [192.168.1.3]) by mailhost.boogie.com (8.13.1/8.13.1) with ESMTP id i89Kwr77092151; Thu, 9 Sep 2004 14:58:53 -0600 (MDT) (envelope-from durian@boogie.com) From: Mike Durian To: Hannes Mehnert Date: Thu, 9 Sep 2004 14:58:52 -0600 User-Agent: KMail/1.7 References: <200406091423.31355.durian@boogie.com> <20040909202955.438a4327@dev.lan.Awfulhak.org> <20040909200142.GD1128@mehnert.org> In-Reply-To: <20040909200142.GD1128@mehnert.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409091458.53088.durian@boogie.com> cc: Brian Somers cc: freebsd-net@freebsd.org Subject: Re: Racoon breakage with recent kernel - what NOT to do X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 09 Sep 2004 20:59:01 -0000 On Thursday 09 September 2004 02:01 pm, Hannes Mehnert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > On Thu, Sep 09, 2004 at 08:29:55PM +0100, Brian Somers wrote: > > On Wed, 14 Jul 2004 20:52:48 +0200, Hannes Mehnert wrote: > > > On Mon, Jul 12, 2004 at 03:32:18PM -0600, Mike Durian wrote: > > > > This is just a follow-up to say the problem still exists in a > > > > -current system I built from source yesterday (7/11/04). Does anyone > > > > know what's going on? > > > > > > > > And to clarify, the URL listed above does show the same problem I'm > > > > seeing. > > > > > > A workaround is setting MSIZE to 320 in your kernel config: > > > options MSIZE=320 > > > > Well, I applied this tweak to my kernel config file (some time ago!) and > > it fixed the racoon issue.... **BUT** doing this badly breaks dtom() - > > all sorts of issues turn up when a data pointer can't be turned back into > > its owning mbuf pointer. > > I'm currently using MSIZE=512 and get no panic. I agree. I too received kernel panics when I used MSIZE=320. After changing it to MSIZE=512 my panics disappeared and racoon started to work. Maybe this MSIZE change should become the default. mike From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 01:09:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DE4416A4CF; Fri, 10 Sep 2004 01:09:12 +0000 (GMT) Received: from terror.hungry.com (terror.hungry.com [199.181.107.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D7243D2F; Fri, 10 Sep 2004 01:09:12 +0000 (GMT) (envelope-from tspencer@hungry.com) Received: from [192.168.0.169] (nat.lindenlab.com [66.150.244.126]) (AUTH: LOGIN tspencer, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by terror.hungry.com with esmtp; Thu, 09 Sep 2004 18:09:11 -0700 In-Reply-To: <4140B8DF.FB83435C@freebsd.org> References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <20040909194117.GB12168@cell.sick.ru> <4140B8DF.FB83435C@freebsd.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tim Spencer Date: Thu, 9 Sep 2004 18:08:39 -0700 To: Andre Oppermann X-Mailer: Apple Mail (2.619) cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 01:09:12 -0000 On Sep 9, 2004, at 1:11 PM, Andre Oppermann wrote: > Just because you have to use Netflow on Cisco IOS doesn't mean you > don't > have (or can invent) better tools on FreeBSD. > Netflow is really useful for auditing and forensics. If you have it enabled for your routers, you can see who did what when, and how much they did it. Thus, if you have a breakin, you can go back and see what IP addresses they came from, what places they pulled their tools down from, and where else they went afterwards. You can also look at the logs that are generated and scan for "scary" or "odd" traffic, and thus see trends of what people are doing in your network. This allows you to get ahead of the curve and start thinking about what happens when everybody starts running that new VOIP thing that seems to send out millions of 64 byte packets or whatever. It also allows you to look at what has been filling up your pipe over the past few days, and thus be able to give precise answers to management when they ask why things have been so slow recently. The CAIDA flow-tools stuff allows you to visualize a lot of this stuff easily, and there are a lot of other good tools that work with standard netflow data out there as well. So believe me, netflow stuff is way cool! The more we can support it, the better! -tspencer From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 05:36:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEB0816A4CE for ; Fri, 10 Sep 2004 05:36:25 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id F209943D6D for ; Fri, 10 Sep 2004 05:36:24 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i8A5aKOB014587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Sep 2004 09:36:21 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i8A5aJju014586; Fri, 10 Sep 2004 09:36:19 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Fri, 10 Sep 2004 09:36:19 +0400 From: Gleb Smirnoff To: Vlad GALU Message-ID: <20040910053619.GB14470@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Vlad GALU , freebsd-net@freebsd.org References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <41409CB5.836DE816@freebsd.org> <20040909193507.GA12168@cell.sick.ru> <4140B603.8E979D72@freebsd.org> <20040909200052.GD12168@cell.sick.ru> <20040909234126.3f1c7cf3.dudu@diaspar.rdsnet.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040909234126.3f1c7cf3.dudu@diaspar.rdsnet.ro> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 05:36:26 -0000 On Thu, Sep 09, 2004 at 11:41:26PM +0300, Vlad GALU wrote: V> This made me raise my eyebrow. I wrote a small tool that we use in V> production at RDS: http://freshmeat.net/projects/glflow. The way I V> designed it, it is supposed to clean up the flow tree once in a while V> and remove 'old' flows (that haven't had any packet matching them in the V> last X seconds). The problem is that I currently have about 400-500k V> active flows on a 700Mbps link. Every 10 seconds the software removes V> about 100-200k of them in no more than 0.2-0.3 seconds. Of course, I V> couldn't possibly send them over a socket somewhere else at that speed,, V> and chose to open a tempfile, mmap() it, write the expired flows to the V> buffer. When the buffer exceeds a programatically chosen number of V> packets, it is msync()-ed, munmap()-ed and a new file is open. If you remove 100-200k of flows every 10 seconds, this means you have 10 - 20 kpps of worm traffic or more! Impressive. 200k flows expired in 10 seconds is 666 export dgrams per second, 7 times more than I usually have in my testbed. Not sure, that ng_netflow + ng_ksocket can do this. Do you collect all this traffic on a single router? V> Do you accidentally have a better storage model ? I've been trying to V> dump these binary files to SQL but for a 42 meg binary log the necessary V> SQL storage went to about 150 megs, which is a bit over reasonable, V> considering the fact that the software dumps a binary file every 5 to 10 V> seconds. Dumping to SQL is a bad idea. I have tried it, too :) V> P.S. I haven't yet tried to aggregate the flows between reading them V> from the binary file and inserting the data into SQL. I thought it would V> take too much time to be able to keep up with the newly created dumps. This is how many people do. However I don't know details. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 05:50:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ADF516A4CE for ; Fri, 10 Sep 2004 05:50:09 +0000 (GMT) Received: from diaspar.rdsnet.ro (diaspar.rdsnet.ro [213.157.165.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD1B943D46 for ; Fri, 10 Sep 2004 05:50:08 +0000 (GMT) (envelope-from dudu@diaspar.rdsnet.ro) Received: (qmail 620 invoked by uid 89); 10 Sep 2004 05:50:37 -0000 Received: from unknown (HELO diaspar.rdsnet.ro) (dudu@diaspar.rdsnet.ro@213.157.165.9) by 0 with AES256-SHA encrypted SMTP; 10 Sep 2004 05:50:37 -0000 Date: Fri, 10 Sep 2004 08:50:36 +0300 From: Vlad GALU To: freebsd-net@freebsd.org Message-Id: <20040910085036.11a5d3b3.dudu@diaspar.rdsnet.ro> In-Reply-To: <20040910053619.GB14470@cell.sick.ru> References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <41409CB5.836DE816@freebsd.org> <20040909193507.GA12168@cell.sick.ru> <4140B603.8E979D72@freebsd.org> <20040909200052.GD12168@cell.sick.ru> <20040909234126.3f1c7cf3.dudu@diaspar.rdsnet.ro> <20040910053619.GB14470@cell.sick.ru> Organization: Romania Data Systems X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 05:50:09 -0000 On Fri, 10 Sep 2004 09:36:19 +0400 Gleb Smirnoff wrote: > On Thu, Sep 09, 2004 at 11:41:26PM +0300, Vlad GALU wrote: > V> This made me raise my eyebrow. I wrote a small tool that we use > V> in > V> production at RDS: http://freshmeat.net/projects/glflow. The way I > V> designed it, it is supposed to clean up the flow tree once in a > V> while and remove 'old' flows (that haven't had any packet matching > V> them in the last X seconds). The problem is that I currently have > V> about 400-500k active flows on a 700Mbps link. Every 10 seconds the > V> software removes about 100-200k of them in no more than 0.2-0.3 > V> seconds. Of course, I couldn't possibly send them over a socket > V> somewhere else at that speed,, and chose to open a tempfile, mmap() > V> it, write the expired flows to the buffer. When the buffer exceeds > V> a programatically chosen number of packets, it is msync()-ed, > V> munmap()-ed and a new file is open. > > If you remove 100-200k of flows every 10 seconds, this means you have > 10 - 20 kpps of worm traffic or more! Impressive. That, and the fact that we get a DoS attack every minute :( > 200k flows expired in 10 seconds is 666 export dgrams per second, 7 > times more than I usually have in my testbed. Not sure, that > ng_netflow + ng_ksocket can do this. > > Do you collect all this traffic on a single router? > For now, yes. I've planned into developing this to a distributed solution, using the spread toolkit (www.spread.org). My goal is to have an instance of glflow running in every branch of our national backbone and filter the destination from the very source of the flood, so we can save traffic. Right now there's only one instance running at the entrypoint of our national backbone ring. However, since I'm going to leave RDS in a week or so, I'll probably find another testbed. I hope it will be one with at least half the traffic we have here. > V> Do you accidentally have a better storage model ? I've been > V> trying to > V> dump these binary files to SQL but for a 42 meg binary log the > V> necessary SQL storage went to about 150 megs, which is a bit over > V> reasonable, considering the fact that the software dumps a binary > V> file every 5 to 10 seconds. > > Dumping to SQL is a bad idea. I have tried it, too :) > > V> P.S. I haven't yet tried to aggregate the flows between reading > V> them from the binary file and inserting the data into SQL. I > V> thought it would take too much time to be able to keep up with the > V> newly created dumps. > > This is how many people do. However I don't know details. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > ---- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 09:57:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3FA116A4CE for ; Fri, 10 Sep 2004 09:57:11 +0000 (GMT) Received: from marcopolo.finecogroup.it (marcopolo.finecogroup.it [193.108.186.201]) by mx1.FreeBSD.org (Postfix) with SMTP id 696D443D31 for ; Fri, 10 Sep 2004 09:57:10 +0000 (GMT) (envelope-from m.amendola@finecogroup.it) Received: (qmail 22130 invoked from network); 10 Sep 2004 09:57:08 -0000 Received: from m.amendola@finecogroup.it by marcopolo by uid 1001 with qmail-scanner-1.14 (sweep: 2.10/3.63. Clear:. Processed in 8.081245 secs); 10 Sep 2004 09:57:08 -0000 Received: from unknown (HELO EXCHFINGRP.finecogrp.it) (192.168.209.206) by marcopolo.finecogrp.it with SMTP; 10 Sep 2004 09:57:00 -0000 Received: from fingrp87 ([192.168.215.35]) by EXCHFINGRP.finecogrp.it with Microsoft SMTPSVC(5.0.2195.6713); Fri, 10 Sep 2004 11:55:38 +0200 From: "amendola maurizio" To: Date: Fri, 10 Sep 2004 11:56:55 +0200 Message-ID: <000b01c4971c$84ad87e0$23d7a8c0@finecogrp.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-OriginalArrivalTime: 10 Sep 2004 09:55:38.0176 (UTC) FILETIME=[5311A400:01C4971C] Subject: netgraph and high availability(bonding) problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 09:57:12 -0000 Hi at all I have some problem to configure two network card in high availabilty = mode. I have done many test with some configurations but I desn't work. I have Freebsd 5.2.1 and I have also add a patch realized from Evgeny Dolgopiat about ng_one2many.c and ng_one2many.h. Test n.1 (with 2 cards on single switch(yes, i know that is not a best ha solution)=20 In this case I have had packets duplication but I have HA to get or put = a net cable. Test n2. (with 2 cards on differnet switch) In this case I = have not packets duplication but I haven't HA to get or put a net cable: if I = get a secondary cable It works but if I get the primary cable it doesn't = work all. This the configuration that I have testes: #from README of ng_one2many patch #!/bin/sh #Build ng_one2many module kldload /usr/src/sys/modules/netgraph/one2many/ng_one2many.ko #Stat about module kldstat #Create one pseudo interface ngctl mkpeer xl0: one2many upper many #Assegno il nome xl0 al nodo o2m ngctl name xl0: upper o2m #Creo un link tra xl0 e o2m usando many0 ngctl connect xl0: o2m: lower many0 #Creo un link tra xl1 e o2m usando many1 ngctl connect xl1: o2m: lower many1 #Metto in promisc mode xl1 ngctl msg xl1: setpromisc 1 #Metto xl1 in autosrc=3D0 ngctl msg xl1: setautosrc 0 ifconfig xl0 inet 192.168.168.239 netmask 255.255.255.0 ngctl msg o2m: setconfig { xmitAlg=3D1 failAlg=3D2 } # set heartbit algo ngctl msg o2m: sethbconfig { timeout=3D2 period=3D3 } # set time between ngctl list route add default 192.168.168.220 _______________________________________________ #IDS:port bonding and taps #in etherchannel ok # #!/bin/sh kldload /usr/src/sys/modules/netgraph/fec/ng_fec.ko kldstat ngctl list ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface '"xl0"' ngctl msg fec0: add_iface '"xl1"' ngctl msg fec0: set_mode_inet ngctl msg fec0: set_mode_mac ngctl msg fec0: set_mode_inet6 ngctl list ifconfig fec0 promisc ifconfig fec0 up ifconfig fec0 inet 192.168.168.239 netmask 255.255.255.0 route add default 192.168.168.220 __________________________________________________________ #!/bin/sh kldload /usr/src/sys/modules/netgraph/ether/ng_ether.ko kldload /usr/src/sys/modules/netgraph/one2many/ng_one2many.ko kldstat ngctl list ifconfig xl0 promisc -arp up ifconfig xl1 promisc -arp up ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many lower one ngctl connect xl0: ngeth0:lower lower many0 ngctl connect xl1: ngeth0:lower lower many1 ngctl list ifconfig ngeth0 up ifconfig ngeth0 inet 192.168.168.239 netmask 255.255.255.0 ifconfig -a = route add default 192.168.168.220 = _____________________________________________ #Taosecurity #!/bin/sh kldload /usr/src/sys/modules/netgraph/ether/ng_ether.ko kldstat ifconfig xl0 promisc -arp up ifconfig xl1 promisc -arp up ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many lower one ngctl connect xl0: ngeth0: lower lower many0 ngctl connect xl1: ngeth0: lower lower many1 ngctl list ifconfig ngeth0 -arp up ifconfig ngeth0 inet 192.168.168.239 netmask 255.255.255.0 ifconfig -a = route add default 192.168.168.220 ________________________________________ #Taosecurity modified 30/07/04 #!/bin/sh kldload /usr/src/sys/modules/netgraph/ether/ng_ether.ko kldstat ifconfig xl0 promisc -arp up ifconfig xl1 -arp up ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many lower one ngctl connect xl0: ngeth0: lower lower many0 ngctl connect xl1: ngeth0: lower lower many1 ngctl list ifconfig ngeth0 -arp up ifconfig ngeth0 inet 192.168.168.239 netmask 255.255.255.0 route add = default 192.168.168.220 ifconfig -a Any suggetion. Maurizio From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 10:08:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8583916A4CE for ; Fri, 10 Sep 2004 10:08:37 +0000 (GMT) Received: from mail.titaninternet.co.uk (mail.titaninternet.co.uk [217.77.176.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4CB443D5A for ; Fri, 10 Sep 2004 10:08:36 +0000 (GMT) (envelope-from dan@skyinternet.co.uk) Received: from localhost ([127.0.0.1]) by mail.titaninternet.co.uk (Merak 7.5.2) with SMTP id EZA37855 for ; Fri, 10 Sep 2004 11:08:33 +0100 Date: Fri, 10 Sep 2004 11:08:33 +0000 From: "Dan" To: freebsd-net@freebsd.org Message-ID: X-Mailer: IceWarp Web Mail 5.2.8 X-Originating-IP: 62.252.64.12 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Subject: Networking/Security Question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 10:08:37 -0000 Hello. My first post here, Hope you're all well and enjoying the summer. Okay, this is likely to be an extremely exhaustive post, so I'd really be grateful if you could spare the time to read and reply please... Let me first introduce you to the scenario. We are a not for profit organisation that I'm dealing with during free time. We have fortunately (as it's Internet based) had funds to get a Leased Line - after about a year of negotiating with various UK providers, we finally got the price completely down - although still scarily high as we're a not for profit. As mentioned, I do this in my spare time, and do not lie I have "expertise" in this field. However, I have researched, and compiled a very simple step by step guide of what I *think* I should be doing to a) install the Leased Line and get it working, and b) secure the network. Please have a look through and comment on whether you agree, or where I've completely gone wrong. The Leased Line is due to be installed in a few weeks time, so basically I want to have a completely clear set of instructions and knowing I'm doing everything right so I'm not stumped when the time comes! Okay... 1. Obviously complete the process to get the Leased Line. The will consist of 2 visits to the presmise, one to install an NTU and the other to install the circuit. 2. The router will come "preconfigured" - not quite sure what that exactly involves. The router itself will be a Cisco 1721. As I want to perhaps support up 4 or 5 PC's through the connection my new ISP's response regarding it was: "The 1721 will allow as many PC's as you wish to connect. The machines would need to be networking together but the whole network can be given access by a single router. With regards to IP's we will allocate a block of 8 IP's with the leased line. These could be assigned to individual machines (one will be needed for the router). To achieve this, as I'd ideally like each machine to have a "public" internet address. To explain myself: PC1: 211.167.0.1 -- running a HTTPD. -- running FreeBSD. PC2: 211.167.0.2 -- running a mail daemon. -- running FreeBSD. PC3: 211.167.0.3 -- just internet access. -- running XP. PC4: 211.167.0.4 -- again internet access. -- running XP. PC5: 211.167.0.5 -- internet access through a Netgear HE102 Access Point and Netgear HA501 PC card. -- running XP. I have no idea what the IPs would be, but I'm sure you'll get the point I'm trying to make... Therefore to achieve that, I'll need to purcahse a Switch that would plug into the Router itself. I want to use an External Switch to link all the PC's to the connection. With advice from some people, it seems people prefer Swithces to Hubs because it only directs data when it's needed. Are you able to recommend a decent 8 port external switch that'd be suited? I searched sites like dabs.com and there's just so many, I don't which are suitable. 3. This switch would need to be connected to the Router with a Cat5 cable - could you advise what port it'd go into? I tried reading the guide at http://www.cisco.com/univercd/cc/td...hig/1721ovw.htm about the Ethernet, Auxilary, and Console port, and I *think* it's the Auxiliry one? Is the "Ethernet" port used to actually connect the router to the NTU? 4. Each PC wanting to access the connection, including 3 PC's and one laptop would need to do the following: 2 x FreeBSD servers would need a Cat5 cable from an Ethernet card in the Boxes to the Switch. 1 x Windows machine would need a Cat5 cable from an Ethernet card in the box to the switch. 1 x Laptop (Netgear HE102 Access Point) talking to a HA501 PC card on the Laptop. In the FreeBSD machines, I'd need to use the following in /etc/rc.conf: ifconfig_sis0="inet the.ip.here netmask 255.255.255.0" where sis0 is the Ethernet in that particular machine, "the.ip.here" the public IP assigned to me by the ISP (I'll be getting a block of them) and ensure /etc/hosts and /etc/resolv.conf are all set. I'd also need to repeat this on the 2 Windows machines, though their setup is very simple... Do you agree this is the right idea for the actual "network setup"? Now my questions begin regarding security for the services in particular. Would it be "sufficient" to just run IPFW rules on each of the FreeBSD servers, and software firewalls on the Windows machines? Or, could you recommend a Hardware Firewall that and how it'd integrate into the above setup please? For the FreeBSD machines I thought the following fules (again researching to find these - but I may very well be incorrect): # Define the firewall command (as in /etc/rc.firewall) for easy # reference. Helps to make it easier to read. fwcmd="/sbin/ipfw" # Force a flushing of the current rules before we reload. $fwcmd -f flush # Allow all connections that have dynamic rules built for them, # but deny established connections that don't have a dynamic rule. # See ipfw(8) for details. $fwcmd add check-state $fwcmd add pass tcp from any to any keep-state # Allow all localhost connections $fwcmd add 100 pass all from any to any via lo0 $fwcmd add 200 deny log all from any to 127.0.0.0/8 $fwcmd add 300 deny log ip from 127.0.0.0/8 to any # Allow all connections from my network card that I initiate $fwcmd add allow tcp from me to any out xmit any setup keep-state $fwcmd add deny log tcp from me to any $fwcmd add allow ip from me to any out xmit any keep-state $fwcmd add allow all from 192.168.0.0/24 to any # Everyone on the Internet is allowed to connect to the following # services on the machine. This example specifically allows connections # to sshd and a webserver. $fwcmd add allow tcp from any to any keep-state $fwcmd add allow tcp from any to me 80 setup # This sends a RESET to all ident packets. $fwcmd add reset log tcp from any to me 113 in recv any # Enable ICMP: remove type 8 if you don't want your host to be pingable $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 # Deny all the rest. $fwcmd add deny log ip from any to any How's this? Obviously, for each there'd be different rules as they'll be running different daemons, so I'd just alter the $fwcmd add allow tcp from any to me 80 setup line... Thanks very much for reading, and I hope I've been clear in explaining this "scenario" - I really appreciate your advice, and our community thanks you. Regards, From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 13:10:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BF0816A4CE for ; Fri, 10 Sep 2004 13:10:59 +0000 (GMT) Received: from charade.trit.org (charade.trit.org [65.19.139.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 174F543D45 for ; Fri, 10 Sep 2004 13:10:59 +0000 (GMT) (envelope-from dd@freebsd.org) Received: by charade.trit.org (Postfix, from userid 408) id EAE2441; Fri, 10 Sep 2004 13:10:58 +0000 (UTC) Received: from harpoon.trit.org (pub-4.ica.trit.net [69.107.245.244]) by charade.trit.org (Postfix) with ESMTP id CB83066; Fri, 10 Sep 2004 13:10:57 +0000 (UTC) Received: from harpoon.trit.org (localhost [127.0.0.1]) by harpoon.trit.org (8.13.1/8.12.9) with ESMTP id i8ADAVHp007631; Fri, 10 Sep 2004 13:10:31 GMT (envelope-from dd@freebsd.org) Received: (from dima@localhost) by harpoon.trit.org (8.13.1/8.12.11/Submit) id i8ADAVcX007630; Fri, 10 Sep 2004 13:10:31 GMT (envelope-from dd@freebsd.org) X-Authentication-Warning: harpoon.trit.org: dima set sender to dd@freebsd.org using -f Date: Fri, 10 Sep 2004 13:10:31 +0000 From: Dima Dorfman To: Brian Somers Message-ID: <20040910131030.GB7453@trit.org> References: <20040909214600.12bb5fd5@dev.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040909214600.12bb5fd5@dev.lan.Awfulhak.org> User-Agent: Mutt/1.4i X-PGP-Key: 69FAE582 (http://www.trit.org/~dima/dima.asc) X-PGP-Fingerprint: B340 8338 7DA3 4D61 7632 098E 0730 055B 69FA E582 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on charade.trit.org X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 cc: freebsd-net@freebsd.org Subject: Re: uma_zcreate() call from kern_mbuf.c - bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 13:10:59 -0000 Brian Somers wrote: > Of course m_get() et. al. seem to manage to get MSIZE aligned pointers back > from uma_zalloc_arg(zone_mbuf...) anyway, but surely that's an implementation > side effect and the align argument should be corrected. This change looks right to me, but I'm hardly an expert here. > There should probably also be a KASSERT here to ensure that MSIZE is sane This might be better as a CTASSERT: Index: kern_mbuf.c =================================================================== RCS file: /ref/cvsf/src/sys/kern/kern_mbuf.c,v retrieving revision 1.3 diff -u -r1.3 kern_mbuf.c --- kern_mbuf.c 2 Aug 2004 00:18:35 -0000 1.3 +++ kern_mbuf.c 10 Sep 2004 06:53:10 -0000 @@ -123,6 +123,9 @@ static void mb_reclaim(void *); static void mbuf_init(void *); +/* Ensure that MSIZE doesn't break dtom(). */ +CTASSERT((((MSIZE - 1) ^ MSIZE) + 1) >> 1 == MSIZE); + /* * Initialize FreeBSD Network buffer allocation. */ @@ -135,7 +138,7 @@ * Configure UMA zones for Mbufs, Clusters, and Packets. */ zone_mbuf = uma_zcreate("Mbuf", MSIZE, mb_ctor_mbuf, mb_dtor_mbuf, - NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_MAXBUCKET); + NULL, NULL, MSIZE - 1, UMA_ZONE_MAXBUCKET); zone_clust = uma_zcreate("MbufClust", MCLBYTES, mb_ctor_clust, mb_dtor_clust, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_REFCNT); if (nmbclusters > 0) From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 13:14:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B92E16A4CE; Fri, 10 Sep 2004 13:14:00 +0000 (GMT) Received: from gw.Awfulhak.org (awfulhak.demon.co.uk [80.177.173.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7452243D5A; Fri, 10 Sep 2004 13:13:59 +0000 (GMT) (envelope-from brian@Awfulhak.org) Received: from mail.awfulhak.org (www@localhost [127.0.0.1]) by gw.Awfulhak.org (8.12.11/8.12.11) with ESMTP id i8ADDc2b001768; Fri, 10 Sep 2004 14:13:38 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from 192.18.1.9 (SquirrelMail authenticated user brian); by mail.Awfulhak.org with HTTP; Fri, 10 Sep 2004 14:13:38 +0100 (BST) Message-ID: <42009.192.18.1.9.1094822018.squirrel@192.18.1.9> In-Reply-To: <20040910131030.GB7453@trit.org> References: <20040909214600.12bb5fd5@dev.lan.Awfulhak.org> <20040910131030.GB7453@trit.org> Date: Fri, 10 Sep 2004 14:13:38 +0100 (BST) From: "Brian Somers" To: "Dima Dorfman" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on gw.lan.Awfulhak.org cc: Brian Somers cc: freebsd-net@freebsd.org Subject: Re: uma_zcreate() call from kern_mbuf.c - bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 13:14:00 -0000 > Brian Somers wrote: >> Of course m_get() et. al. seem to manage to get MSIZE aligned pointers >> back >> from uma_zalloc_arg(zone_mbuf...) anyway, but surely that's an >> implementation >> side effect and the align argument should be corrected. > > This change looks right to me, but I'm hardly an expert here. > >> There should probably also be a KASSERT here to ensure that MSIZE is >> sane > > This might be better as a CTASSERT: > > Index: kern_mbuf.c > =================================================================== > RCS file: /ref/cvsf/src/sys/kern/kern_mbuf.c,v > retrieving revision 1.3 > diff -u -r1.3 kern_mbuf.c > --- kern_mbuf.c 2 Aug 2004 00:18:35 -0000 1.3 > +++ kern_mbuf.c 10 Sep 2004 06:53:10 -0000 > @@ -123,6 +123,9 @@ > static void mb_reclaim(void *); > static void mbuf_init(void *); > > +/* Ensure that MSIZE doesn't break dtom(). */ > +CTASSERT((((MSIZE - 1) ^ MSIZE) + 1) >> 1 == MSIZE); > + > /* > * Initialize FreeBSD Network buffer allocation. > */ > @@ -135,7 +138,7 @@ > * Configure UMA zones for Mbufs, Clusters, and Packets. > */ > zone_mbuf = uma_zcreate("Mbuf", MSIZE, mb_ctor_mbuf, mb_dtor_mbuf, > - NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_MAXBUCKET); > + NULL, NULL, MSIZE - 1, UMA_ZONE_MAXBUCKET); > zone_clust = uma_zcreate("MbufClust", MCLBYTES, mb_ctor_clust, > mb_dtor_clust, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_REFCNT); > if (nmbclusters > 0) > > Agreed. I didn't know about CTASSERT()! Cheers. -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 17:54:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A18C316A4CE for ; Fri, 10 Sep 2004 17:54:09 +0000 (GMT) Received: from phoenix.gargantuan.com (rrcs-24-73-171-238.se.biz.rr.com [24.73.171.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 012E043D55 for ; Fri, 10 Sep 2004 17:54:09 +0000 (GMT) (envelope-from michael@gargantuan.com) Received: from localhost (localhost.gargantuan.com [127.0.0.1]) by spamassassin-injector (Postfix) with SMTP id 5988FF8; Thu, 9 Sep 2004 14:40:50 -0400 (EDT) Received: by phoenix.gargantuan.com (Postfix, from userid 1001) id 025D74A4; Thu, 9 Sep 2004 14:40:13 -0400 (EDT) Date: Thu, 9 Sep 2004 14:40:12 -0400 From: "Michael W. Oliver" To: Forrest Aldrich Message-ID: <20040909184012.GA11503@gargantuan.com> Mail-Followup-To: Forrest Aldrich , freebsd-net@freebsd.org References: <413F6BBE.1050202@forrie.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <413F6BBE.1050202@forrie.com> X-WWW-Site: http://michael.gargantuan.com X-PGP-Public-Key: $X-WWW-Site/gnupg/pubkey.asc X-PGP-Fingerprint: 2694 0179 AE3F BFAE 0916 0BF5 B16B FBAB C5FA A3C9 X-Home-Phone: +1-863-816-8091 X-Mobile-Phone: +1-863-738-2334 X-Home-Address0: 8008 Apache Lane X-Home-Address1: Lakeland, FL X-Home-Address2: 33810-2172 X-Home-Address3: United States of America X-Good-Question-Guide: http://www.catb.org/~esr/faqs/smart-questions.html X-Netiquette-Guidelines: http://www.ietf.org/rfc/rfc1855.txt User-Agent: Mutt/1.5.6i X-Spam-DCC: : X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on phoenix.gargantuan.com X-Spam-Level: X-Spam-Status: No, hits=-103.4 required=5.0 tests=AWL,BAYES_00, NO_DNS_FOR_FROM,USER_IN_WHITELIST autolearn=no version=2.64 cc: freebsd-net@freebsd.org Subject: Re: VoIP and IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 17:54:09 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004-09-08T16:29:50-0400, Forrest Aldrich wrote: > Hi there, >=20 > I'm considering testing the Vonage service, with my FreeBSD-4.10 system= =20 > (maybe 5 or 6). =20 >=20 > I wonder if anyone here has a configuration they can share, or if there= =20 > are any pages out there that detail the proper (and secure) setup. Sure! I am using IPFW2+NATD and the following (partial) configuration works well for me... --8<--------------- vonage_ata=3D"10.0.0.192" ipfw pipe 2 config bw "200Kbit/s" ipfw pipe 4 config bw "200Kbit/s" ipfw pipe 6 config bw "99800Kbit/s" ipfw pipe 8 config bw "384Kbit/s" ipfw queue 20 config weight 100 pipe 2 ipfw queue 40 config weight 100 pipe 4 ipfw queue 60 config weight 5 pipe 6 ipfw queue 80 config weight 5 pipe 8 ${fwcmd} add pass udp from ${vonage_ata} to any in recv ${lan_if} ${fwcmd} add queue 40 udp from ${wan_ip} to any src-port 5060-5061 out xmit= ${wan_if} ${fwcmd} add queue 40 udp from ${wan_ip} to any src-port 10000-20000 out xm= it ${wan_if} ${fwcmd} add pass udp from any to ${vonage_ata} in recv ${wan_if} ${fwcmd} add queue 20 udp from any to ${vonage_ata} out xmit ${lan_if} # ${fwcmd} add pass udp from ${vonage_ata} to any dst-port 53 in recv ${lan_i= f} ${fwcmd} add queue 80 udp from ${wan_ip} to any dst-port 53 out xmit ${wan_= if} ${fwcmd} add pass udp from any to ${vonage_ata} src-port 53 in recv ${wan_i= f} ${fwcmd} add queue 60 udp from any to ${vonage_ata} src-port 53 out xmit ${= lan_if} # ${fwcmd} add pass udp from ${vonage_ata} to any dst-port 69 in recv ${lan_i= f} ${fwcmd} add queue 80 udp from ${wan_ip} to any dst-port 69 out xmit ${wan_= if} ${fwcmd} add pass udp from any to ${vonage_ata} src-port 69 in recv ${wan_i= f} ${fwcmd} add queue 60 udp from any to ${vonage_ata} src-port 69 out xmit ${= lan_if} --8<--------------- I am using this with RoadRunner, which gives me 2Mb/s down and 384kb/s up, which is why the pipes are configured the way that they are. Naturally, you would want to change those values to match your up/down speed. In addition, you need to make sure that you are queueing your other traffic as well, using queues 60 and 80 for non-VoIP traffic. I hope that this helps. --=20 Mike perl -e 'print unpack("u","88V]N=3D&%C=3D\"!I;F9O(&EN(&AE861E Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADA3E16A4CE for ; Fri, 10 Sep 2004 19:18:37 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1A8743D2D for ; Fri, 10 Sep 2004 19:18:36 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id i8AJIVIR084254 for ; Fri, 10 Sep 2004 22:18:33 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.11/8.12.11/Submit) id i8AJIVnW084251 for net@freebsd.org; Fri, 10 Sep 2004 22:18:31 +0300 (EEST) (envelope-from netch) Date: Fri, 10 Sep 2004 22:18:31 +0300 From: Valentin Nechayev To: net@freebsd.org Message-ID: <20040910191831.GP89036@lucky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) Subject: original interface name? (5.*) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 19:18:37 -0000 Hi, is there a stable way to determine original interface name (before any renaming) in 5.3? I.e. as driver + sequence number? -netch- From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 19:31:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A718416A4CE for ; Fri, 10 Sep 2004 19:31:47 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62D3943D2F for ; Fri, 10 Sep 2004 19:31:47 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C5r7P-00041t-00; Fri, 10 Sep 2004 21:31:35 +0200 Received: from [84.128.142.188] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C5r7O-0004XV-00; Fri, 10 Sep 2004 21:31:34 +0200 From: Max Laier To: netch@lucky.net Date: Fri, 10 Sep 2004 21:30:11 +0200 User-Agent: KMail/1.6.2 References: <20040910191831.GP89036@lucky.net> In-Reply-To: <20040910191831.GP89036@lucky.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_MDgQBKN0Xcm6tOy"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409102130.20287.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-net@freebsd.org Subject: Re: original interface name? (5.*) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 19:31:47 -0000 --Boundary-02=_MDgQBKN0Xcm6tOy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 10 September 2004 21:18, Valentin Nechayev wrote: > Hi, > is there a stable way to determine original interface name (before > any renaming) in 5.3? I.e. as driver + sequence number? =46rom inside the kernel you can use ifnet.if_dname + ifnet.if_dunit, from = the=20 userland I don't know if it's possible to get a look at those fields. In any way, I suggest not to do that. ifnet.if_xname is supposed to be *the= *=20 name of the interface. There is no such thing as "original name". =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 --Boundary-02=_MDgQBKN0Xcm6tOy Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBQgDMXyyEoT62BG0RAoDgAJ45SYqFkDakQZgvpwT9cimFMzoWrwCfXosL NdvRlnDr1rHKwEau8KeMW6o= =UOD1 -----END PGP SIGNATURE----- --Boundary-02=_MDgQBKN0Xcm6tOy-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 19:31:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18A0F16A4CE for ; Fri, 10 Sep 2004 19:31:56 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDABE43D1F for ; Fri, 10 Sep 2004 19:31:55 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8AJW2xG004915; Fri, 10 Sep 2004 12:32:02 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8AJW2oo004914; Fri, 10 Sep 2004 12:32:02 -0700 Date: Fri, 10 Sep 2004 12:32:02 -0700 From: Brooks Davis To: Valentin Nechayev Message-ID: <20040910193202.GB28085@odin.ac.hmc.edu> References: <20040910191831.GP89036@lucky.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline In-Reply-To: <20040910191831.GP89036@lucky.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: net@freebsd.org Subject: Re: original interface name? (5.*) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 19:31:56 -0000 --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 10, 2004 at 10:18:31PM +0300, Valentin Nechayev wrote: > Hi, > is there a stable way to determine original interface name (before > any renaming) in 5.3? I.e. as driver + sequence number? What do you want it for and where do you want it? I think there were plans to export if_dname and if_dunit via sysctls, but I don't think that ever happened and they aren't really ment to be user visiable. There's also no requirement that ("%s%d", if_dname, if_dunit) ever have been the name of the interface (for instance in enhanced cloners such as stf(4) and vlan(4)). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBQgExXY6L6fI4GtQRAtwyAKDWcavjBLvkM2KxwA2ixsCopgR3swCfbrpc hNUeEO4hfRUnq31S4bm5RcA= =lV0M -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 19:34:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0820B16A4CE for ; Fri, 10 Sep 2004 19:34:40 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7F3F43D5C for ; Fri, 10 Sep 2004 19:34:39 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8AJYkR2005389; Fri, 10 Sep 2004 12:34:46 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8AJYku3005388; Fri, 10 Sep 2004 12:34:46 -0700 Date: Fri, 10 Sep 2004 12:34:46 -0700 From: Brooks Davis To: Max Laier Message-ID: <20040910193446.GC28085@odin.ac.hmc.edu> References: <20040910191831.GP89036@lucky.net> <200409102130.20287.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ" Content-Disposition: inline In-Reply-To: <200409102130.20287.max@love2party.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: netch@lucky.net cc: freebsd-net@freebsd.org Subject: Re: original interface name? (5.*) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 19:34:40 -0000 --ZmUaFz6apKcXQszQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 10, 2004 at 09:30:11PM +0200, Max Laier wrote: > On Friday 10 September 2004 21:18, Valentin Nechayev wrote: > > Hi, > > is there a stable way to determine original interface name (before > > any renaming) in 5.3? I.e. as driver + sequence number? >=20 > From inside the kernel you can use ifnet.if_dname + ifnet.if_dunit, from = the=20 > userland I don't know if it's possible to get a look at those fields. >=20 > In any way, I suggest not to do that. ifnet.if_xname is supposed to be *t= he*=20 > name of the interface. There is no such thing as "original name". Yes, for that matter, the name should not be considered to be a reliable handle to an interface unless you know it won't change. This means it's OK for rc.conf or ifconfig, but not OK for a long running, general purpose monitoring program. In 6-CURRENT, and hopefully 5.3, the correct unique identification of an interface will be its index and the value of ifi_epoch. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ZmUaFz6apKcXQszQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBQgHVXY6L6fI4GtQRAnaPAKC/IivPwR3ixhHdmDq5WbftElmfoACcCXO9 xCdUSJGUxvx75CRZnq7LbUU= =0Wum -----END PGP SIGNATURE----- --ZmUaFz6apKcXQszQ-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 19:46:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4751116A4CE for ; Fri, 10 Sep 2004 19:46:51 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F7043D4C for ; Fri, 10 Sep 2004 19:46:50 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id i8AJkgag090025; Fri, 10 Sep 2004 22:46:45 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.11/8.12.11/Submit) id i8AJkgAQ090022; Fri, 10 Sep 2004 22:46:42 +0300 (EEST) (envelope-from netch) Date: Fri, 10 Sep 2004 22:46:42 +0300 From: Valentin Nechayev To: Max Laier Message-ID: <20040910194642.GC84228@lucky.net> References: <20040910191831.GP89036@lucky.net> <200409102130.20287.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409102130.20287.max@love2party.net> X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) cc: freebsd-net@freebsd.org Subject: Re: original interface name? (5.*) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 19:46:51 -0000 Fri, Sep 10, 2004 at 21:30:11, max wrote about "Re: original interface name? (5.*)": >> Hi, >> is there a stable way to determine original interface name (before >> any renaming) in 5.3? I.e. as driver + sequence number? > From inside the kernel you can use ifnet.if_dname + ifnet.if_dunit, from the > userland I don't know if it's possible to get a look at those fields. > In any way, I suggest not to do that. ifnet.if_xname is supposed to be *the* > name of the interface. There is no such thing as "original name". Having driver name one can determine essential capabilities of the interface, including VLAN support, possibility and allowed style of media specification, etc. Device number among with driver name are enough to determine needed information based on driver information and boot logs. It is pointless to use interface without such information, and it is pointless to do manual logging as the only source. > In any way, I suggest not to do that. What about good old principle "Tools, not policy"? -netch- From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 19:46:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A11C316A4F8 for ; Fri, 10 Sep 2004 19:46:58 +0000 (GMT) Received: from cobalt.antimatter.net (cobalt.antimatter.net [69.55.224.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F35943D2F for ; Fri, 10 Sep 2004 19:46:58 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from glenn-mobile.antimatter.net (66-27-95-123.san.rr.com [66.27.95.123]) (authenticated bits=0)i8AJjrhN003628 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 10 Sep 2004 12:45:54 -0700 Message-Id: <6.1.0.6.2.20040910123827.102512d0@cobalt.antimatter.net> X-Sender: glenn@cobalt.antimatter.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Fri, 10 Sep 2004 12:46:41 -0700 To: freebsd-net@freebsd.org From: Glenn Dawson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: dyn buckets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 19:46:58 -0000 I have a firewall running 4.10 that handles around 20mbits/sec of traffic and has around 500 ipfw rules. Lately I've noticed that net.inet.ip.fw.curr_dyn_buckets seems to be maxing out. I've increased net.inet.ip.fw.dyn_buckets a few times, but they seem to max out each time. Is there any problem with increasing net.inet.ip.fw.dyn_buckets far beyond the default? (I'm at 2048 now) -Glenn From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 19:51:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8C3916A4CE for ; Fri, 10 Sep 2004 19:51:50 +0000 (GMT) Received: from exchange.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2509F43D41 for ; Fri, 10 Sep 2004 19:51:50 +0000 (GMT) (envelope-from don@sandvine.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Date: Fri, 10 Sep 2004 15:51:48 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dyn buckets Thread-Index: AcSXbxyyy5LUs30AT4GK4vSl3vC2XgAAJVCg From: "Don Bowman" To: "Glenn Dawson" , Subject: RE: dyn buckets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 19:51:50 -0000 From: owner-freebsd-net@freebsd.org > I have a firewall running 4.10 that handles around=20 > 20mbits/sec of traffic=20 > and has around 500 ipfw rules. >=20 > Lately I've noticed that net.inet.ip.fw.curr_dyn_buckets=20 > seems to be maxing=20 > out. I've increased net.inet.ip.fw.dyn_buckets a few times,=20 > but they seem=20 > to max out each time. >=20 > Is there any problem with increasing=20 > net.inet.ip.fw.dyn_buckets far beyond=20 > the default? (I'm at 2048 now) I use=20 net.inet.ip.fw.dyn_buckets=3D16384 net.inet.ip.fw.dyn_syn_lifetime=3D5 net.inet.ip.fw.dyn_max=3D32000 From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 19:58:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDD2916A4CE for ; Fri, 10 Sep 2004 19:58:19 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE3A743D1F for ; Fri, 10 Sep 2004 19:58:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8AJwRxg009045; Fri, 10 Sep 2004 12:58:27 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8AJwRFu009044; Fri, 10 Sep 2004 12:58:27 -0700 Date: Fri, 10 Sep 2004 12:58:26 -0700 From: Brooks Davis To: Valentin Nechayev Message-ID: <20040910195826.GE28085@odin.ac.hmc.edu> References: <20040910191831.GP89036@lucky.net> <200409102130.20287.max@love2party.net> <20040910194642.GC84228@lucky.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o0ZfoUVt4BxPQnbU" Content-Disposition: inline In-Reply-To: <20040910194642.GC84228@lucky.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: original interface name? (5.*) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 19:58:20 -0000 --o0ZfoUVt4BxPQnbU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 10, 2004 at 10:46:42PM +0300, Valentin Nechayev wrote: > Fri, Sep 10, 2004 at 21:30:11, max wrote about "Re: original interface n= ame? (5.*)":=20 >=20 > >> Hi, > >> is there a stable way to determine original interface name (before > >> any renaming) in 5.3? I.e. as driver + sequence number? > > From inside the kernel you can use ifnet.if_dname + ifnet.if_dunit, fro= m the=20 > > userland I don't know if it's possible to get a look at those fields. > > In any way, I suggest not to do that. ifnet.if_xname is supposed to be = *the*=20 > > name of the interface. There is no such thing as "original name". > Having driver name one can determine essential capabilities of the interf= ace, > including VLAN support, possibility and allowed style of media specificat= ion, > etc. The output of ifconfig -m contains this information. > Device number among with driver name are enough to determine needed > information based on driver information and boot logs. > It is pointless to use interface without such information, and it is poin= tless > to do manual logging as the only source. This is a better reason, but if you want the logs to make sense, you will have to be aware of changes. Hmm, we may want to log(9) renames. I'm considering adding an ifconfig -v option that would imply -m and add more details like index, epoch, dname, dunit, etc. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --o0ZfoUVt4BxPQnbU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBQgdiXY6L6fI4GtQRAhhyAKDZFYJrSCMhnyhpr/I7LiVV8bh1kgCfYzr2 Va6lfwDkoCHry3gEPSrpdrk= =am40 -----END PGP SIGNATURE----- --o0ZfoUVt4BxPQnbU-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 20:03:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85DC816A4CE for ; Fri, 10 Sep 2004 20:03:11 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC8AD43D49 for ; Fri, 10 Sep 2004 20:03:10 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id i8AK32SH093390; Fri, 10 Sep 2004 23:03:05 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.11/8.12.11/Submit) id i8AK32YK093387; Fri, 10 Sep 2004 23:03:02 +0300 (EEST) (envelope-from netch) Date: Fri, 10 Sep 2004 23:03:02 +0300 From: Valentin Nechayev To: Brooks Davis Message-ID: <20040910200302.GD84228@lucky.net> References: <20040910191831.GP89036@lucky.net> <200409102130.20287.max@love2party.net> <20040910194642.GC84228@lucky.net> <20040910195826.GE28085@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040910195826.GE28085@odin.ac.hmc.edu> X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) cc: freebsd-net@freebsd.org Subject: Re: original interface name? (5.*) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 20:03:11 -0000 Fri, Sep 10, 2004 at 12:58:26, brooks wrote about "Re: original interface name? (5.*)": >> Device number among with driver name are enough to determine needed >> information based on driver information and boot logs. >> It is pointless to use interface without such information, and it is pointless >> to do manual logging as the only source. > This is a better reason, but if you want the logs to make sense, you > will have to be aware of changes. Hmm, we may want to log(9) renames. > I'm considering adding an ifconfig -v option that would imply -m and add > more details like index, epoch, dname, dunit, etc. Well, both ideas (logging renames and a switch to print more info) are highly pleasant. Thanks in advance for implementation. -netch- From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 20:04:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C83C516A4CE for ; Fri, 10 Sep 2004 20:04:59 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 360B743D39 for ; Fri, 10 Sep 2004 20:04:59 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 65020 invoked from network); 10 Sep 2004 20:01:05 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Sep 2004 20:01:05 -0000 Message-ID: <414208EE.B7F43DB6@freebsd.org> Date: Fri, 10 Sep 2004 22:05:02 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis References: <20040910191831.GP89036@lucky.net> <20040910194642.GC84228@lucky.net> <20040910195826.GE28085@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Valentin Nechayev cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: original interface name? (5.*) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 20:04:59 -0000 Brooks Davis wrote: > I'm considering adding an ifconfig -v option that would imply -m and add > more details like index, epoch, dname, dunit, etc. That would be great! -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 20:18:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F013216A4CE; Fri, 10 Sep 2004 20:18:44 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 785E543D3F; Fri, 10 Sep 2004 20:18:44 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i8AKIg8g038015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Fri, 10 Sep 2004 16:18:43 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i8AKIgg2038012; Fri, 10 Sep 2004 16:18:42 -0400 (EDT) (envelope-from wollman) Date: Fri, 10 Sep 2004 16:18:42 -0400 (EDT) From: Garrett Wollman Message-Id: <200409102018.i8AKIgg2038012@khavrinen.lcs.mit.edu> To: Andre Oppermann In-Reply-To: <414208EE.B7F43DB6@freebsd.org> References: <20040910191831.GP89036@lucky.net> <20040910194642.GC84228@lucky.net> <20040910195826.GE28085@odin.ac.hmc.edu> <414208EE.B7F43DB6@freebsd.org> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@FreeBSD.ORG Subject: Re: original interface name? (5.*) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 20:18:45 -0000 < said: > Brooks Davis wrote: >> I'm considering adding an ifconfig -v option that would imply -m and add >> more details like index, epoch, dname, dunit, etc. > That would be great! A particularly relevant feature would give `ifconfig' an option to emit the current configuration of the interface in a form which would be acceptable on the `ifconfig' command line. -GAWollman From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 21:32:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5463616A4CF for ; Fri, 10 Sep 2004 21:32:25 +0000 (GMT) Received: from e028121.vtacs.vt.edu (e028121.vtacs.vt.edu [63.164.28.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAF6443D41 for ; Fri, 10 Sep 2004 21:32:24 +0000 (GMT) (envelope-from gaylord@dirtcheapemail.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by e028121.vtacs.vt.edu (Postfix) with ESMTP id BB11711418 for ; Fri, 10 Sep 2004 17:32:23 -0400 (EDT) Message-ID: <41421D66.2030902@dirtcheapemail.com> Date: Fri, 10 Sep 2004 17:32:22 -0400 From: Clark Gaylord User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <41409CB5.836DE816@freebsd.org> <20040909193507.GA12168@cell.sick.ru> <4140B603.8E979D72@freebsd.org> <20040909200052.GD12168@cell.sick.ru> <20040909234126.3f1c7cf3.dudu@diaspar.rdsnet.ro> <20040910053619.GB14470@cell.sick.ru> In-Reply-To: <20040910053619.GB14470@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 21:32:25 -0000 Gleb Smirnoff wrote: > Dumping to SQL is a bad idea. I have tried it, too :) Certainly dumping to MySQL is typically wretched ... to a real database much less so. --ckg From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 21:48:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F114E16A4CE for ; Fri, 10 Sep 2004 21:48:05 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id B98B343D54 for ; Fri, 10 Sep 2004 21:48:05 +0000 (GMT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id AAD635C942; Fri, 10 Sep 2004 14:48:05 -0700 (PDT) Date: Fri, 10 Sep 2004 14:48:05 -0700 From: Bill Fumerola To: Clark Gaylord Message-ID: <20040910214805.GN54568@elvis.mu.org> References: <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <41409CB5.836DE816@freebsd.org> <20040909193507.GA12168@cell.sick.ru> <4140B603.8E979D72@freebsd.org> <20040909200052.GD12168@cell.sick.ru> <20040909234126.3f1c7cf3.dudu@diaspar.rdsnet.ro> <20040910053619.GB14470@cell.sick.ru> <41421D66.2030902@dirtcheapemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41421D66.2030902@dirtcheapemail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.10-MUORG-20040525 i386 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 cc: freebsd-net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 21:48:06 -0000 On Fri, Sep 10, 2004 at 05:32:22PM -0400, Clark Gaylord wrote: > Certainly dumping to MySQL is typically wretched ... to a real database > much less so. works just fine if you aggregate the flows and build lookup tables instead of just dumping raw flows straight into a database. i think it's great that a freebsd netflow implementation exists, it's just a shame that you have to configure netkitchensink to use it.. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 23:08:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45CDF16A4CE for ; Fri, 10 Sep 2004 23:08:26 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2B2243D2F for ; Fri, 10 Sep 2004 23:08:25 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i8AN81Jt015738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Sep 2004 19:08:01 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i8AN7rgh060421; Fri, 10 Sep 2004 19:07:53 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16706.13257.676586.513738@grasshopper.cs.duke.edu> Date: Fri, 10 Sep 2004 19:07:53 -0400 (EDT) To: freebsd-net@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: packet generator X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Sep 2004 23:08:26 -0000 Does anybody have a free, in-kernel tool to generate packets quicky and send them out a particular etherent interface on FreeBSD? Something similar to pktgen on linux? I'm trying to excersize just the send-side of programmable firmware based NIC. The recieve side of the NIC firmware is not yet written, but I want to get started tuning and shaking the bugs out of the send side while the firmware author does the recieve path. The packets just get dropped on the floor by the NIC, so its a good way to test the interface.. I can add an arp entry and ping -l HUGEVAL, but that only generates 205K pkts/sec (where *think* I see 1.1 million pkts/sec with pktgen on linux, but I'm not sure I trust it). Thanks, Drew From owner-freebsd-net@FreeBSD.ORG Sat Sep 11 00:32:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D0DB16A4CE for ; Sat, 11 Sep 2004 00:32:14 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3728F43D45 for ; Sat, 11 Sep 2004 00:32:13 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 66301 invoked from network); 10 Sep 2004 23:28:16 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Sep 2004 23:28:16 -0000 Message-ID: <4142397E.A167AE94@freebsd.org> Date: Sat, 11 Sep 2004 01:32:14 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Gallatin References: <16706.13257.676586.513738@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: packet generator X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 00:32:14 -0000 Andrew Gallatin wrote: > > Does anybody have a free, in-kernel tool to generate packets quicky > and send them out a particular etherent interface on FreeBSD? > Something similar to pktgen on linux? > > I'm trying to excersize just the send-side of programmable firmware > based NIC. The recieve side of the NIC firmware is not yet written, > but I want to get started tuning and shaking the bugs out of the send > side while the firmware author does the recieve path. The packets > just get dropped on the floor by the NIC, so its a good way to test > the interface.. > > I can add an arp entry and ping -l HUGEVAL, but that only generates 205K > pkts/sec (where *think* I see 1.1 million pkts/sec with pktgen on > linux, but I'm not sure I trust it). netgraph/ng_source.c Doesn't have a man page though. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Sep 11 01:05:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9703616A4D0 for ; Sat, 11 Sep 2004 01:05:23 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C04243D3F for ; Sat, 11 Sep 2004 01:05:17 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id E96D17A3D2; Fri, 10 Sep 2004 18:05:16 -0700 (PDT) Message-ID: <41424F4C.5020506@elischer.org> Date: Fri, 10 Sep 2004 18:05:16 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Andrew Gallatin References: <16706.13257.676586.513738@grasshopper.cs.duke.edu> In-Reply-To: <16706.13257.676586.513738@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: packet generator X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 01:05:23 -0000 yes ther e is a netgraph source ng_source from memory.. Andrew Gallatin wrote: >Does anybody have a free, in-kernel tool to generate packets quicky >and send them out a particular etherent interface on FreeBSD? >Something similar to pktgen on linux? > >I'm trying to excersize just the send-side of programmable firmware >based NIC. The recieve side of the NIC firmware is not yet written, >but I want to get started tuning and shaking the bugs out of the send >side while the firmware author does the recieve path. The packets >just get dropped on the floor by the NIC, so its a good way to test >the interface.. > >I can add an arp entry and ping -l HUGEVAL, but that only generates 205K >pkts/sec (where *think* I see 1.1 million pkts/sec with pktgen on >linux, but I'm not sure I trust it). > >Thanks, > >Drew >_______________________________________________ >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 Sat Sep 11 03:18:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D268C16A4CE for ; Sat, 11 Sep 2004 03:18:14 +0000 (GMT) Received: from exchange.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AF8F43D5A for ; Sat, 11 Sep 2004 03:18:14 +0000 (GMT) (envelope-from don@sandvine.com) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 Date: Fri, 10 Sep 2004 23:18:13 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: packet generator Thread-Index: AcSXizgZAAxwpp5FQfWhBP0cv7gA2gAIjPsA From: "Don Bowman" To: "Andrew Gallatin" , Subject: RE: packet generator X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 03:18:14 -0000 From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Andrew Gallatin > Sent: September 10, 2004 19:08 PM > To: freebsd-net@freebsd.org > Subject: packet generator >=20 > Does anybody have a free, in-kernel tool to generate packets quicky > and send them out a particular etherent interface on FreeBSD? > Something similar to pktgen on linux? >=20 > I'm trying to excersize just the send-side of programmable firmware > based NIC. The recieve side of the NIC firmware is not yet written, > but I want to get started tuning and shaking the bugs out of the send > side while the firmware author does the recieve path. The packets > just get dropped on the floor by the NIC, so its a good way to test > the interface.. >=20 ng_source was a netgraph module we wrote and contributed. It can transmit ~800Kpps on a PCI-X system. The code is in src/sys/netgraph/ng_source.c. I drive it with a tcl library that can create arbitrary packets with an object-oriented model, let me know if you'd like to try that. --don From owner-freebsd-net@FreeBSD.ORG Sat Sep 11 10:11:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D8DE16A4CE for ; Sat, 11 Sep 2004 10:11:39 +0000 (GMT) Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F0BD43D45 for ; Sat, 11 Sep 2004 10:11:39 +0000 (GMT) (envelope-from ach@meta-x.org) Received: from ciscvn (83.157.49.97) by mail.libertysurf.net (6.5.036) id 4142837C000869CE for freebsd-net@freebsd.org; Sat, 11 Sep 2004 12:11:38 +0200 Message-ID: <4142837C000869CE@mail06.pds.libertysurf.fr> (added by postmaster@libertysurf.fr) From: "Alexandre Chauvin-Hameau" To: Date: Sat, 11 Sep 2004 12:11:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20040910214805.GN54568@elvis.mu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSXf9talLStD5duSe2fAiq+uf04TwAZ2seQ Importance: Low Subject: Netgraph module in Ipsec concentrator X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 10:11:39 -0000 Hi all, Is it possible to install a ng_* module in the middle of an Ipsec concentrator. Let assume we have 2 clients connected through an Ipsec tunnel to a freebsd router and we would like to use ng_netflow to get stats on this client to client communication. Any idea ? Thanks in advance, Alex. From owner-freebsd-net@FreeBSD.ORG Sat Sep 11 11:12:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EACC16A4CF for ; Sat, 11 Sep 2004 11:12:06 +0000 (GMT) Received: from unsane.co.uk (unsane.co.uk [82.152.23.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED96D43D46 for ; Sat, 11 Sep 2004 11:12:04 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (localhost [127.0.0.1]) by unsane.co.uk (8.12.11/8.12.10) with ESMTP id i8BBBC8S076718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Sep 2004 12:11:12 +0100 (BST) (envelope-from jhary@unsane.co.uk) Received: from localhost (jhary@localhost) by unsane.co.uk (8.12.11/8.12.10/Submit) with ESMTP id i8BBBB4S076715; Sat, 11 Sep 2004 12:11:12 +0100 (BST) (envelope-from jhary@unsane.co.uk) Date: Sat, 11 Sep 2004 12:11:11 +0100 (BST) From: Vince Hoffman To: Dan In-Reply-To: Message-ID: <20040911105538.L45404@unsane.co.uk> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Networking/Security Question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 11:12:06 -0000 On Fri, 10 Sep 2004, Dan wrote: > Hello. Hi Dan, > My first post here, Hope you're all well and enjoying the summer. > Okay, this is likely to be an extremely exhaustive post, so I'd really be grateful if you could spare the time to read and reply please... > > Let me first introduce you to the scenario. We are a not for profit organisation that I'm dealing with during free time. We have fortunately (as it's Internet based) had funds to get a Leased Line - after about a year of negotiating with various UK providers, we finally got the price completely down - although still scarily high as we're a not for profit. > > As mentioned, I do this in my spare time, and do not lie I have "expertise" in this field. However, I have researched, and compiled a very simple step by step guide of what I *think* I should be doing to a) install the Leased Line and get it working, and b) secure the network. > > Please have a look through and comment on whether you agree, or where I've completely gone wrong. The Leased Line is due to be installed in a few weeks time, so basically I want to have a completely clear set of instructions and knowing I'm doing everything right so I'm not stumped when the time comes! > > Okay... > > 1. > Obviously complete the process to get the Leased Line. > The will consist of 2 visits to the presmise, one to install an NTU and the other to install the circuit. > Sounds right, I'm assuming a BT tail (ie you will get a BT box no matter who your ISP is,) Although it can mean more or less visits for no reason i've ever worked out ;) > 2. > The router will come "preconfigured" - not quite sure what that exactly involves. The router itself will be a Cisco 1721. > If it means the same as where i work (small ISP) then it means that they will have the router configured and connected and you shouldnt touch it, other than to plug your switch/firewall in unless they say to. If they dont connect it all you need to do is plug the router in, attach the router to the MTU (this can be in a number of ways but i'll assume an E1 (2Mbps) line which is normaly presented as X.21 (uses a thickish blue green cable whith a D plug at each end, the cisco end has a higher density of pins) As i say though your ISP should connect this or talk you through it. > As I want to perhaps support up 4 or 5 PC's through the connection my new >ISP's response regarding it was: "The 1721 will allow as many PC's as >you >wish to connect. The machines would need to be networking together but >the >whole network can be given access by a single router. With regards to >IP's we >will allocate a block of 8 IP's with the leased line. These could be >assigned >to individual machines (one will be needed for the router). > quick comment here. 8 IPs = /29 or 255.255.255.248 netmask. this does not mean 8 usable IPS. it means 6 usable (minus broadcask and network number) minus the router gives 5 usable, just enough but no spare unless -- see my prefered setup below. > To achieve this, as I'd ideally like each machine to have a "public" >internet address. To explain myself: > > PC1: 211.167.0.1 -- running a HTTPD. -- running FreeBSD. > PC2: 211.167.0.2 -- running a mail daemon. -- running FreeBSD. > PC3: 211.167.0.3 -- just internet access. -- running XP. > PC4: 211.167.0.4 -- again internet access. -- running XP. > PC5: 211.167.0.5 -- internet access through a Netgear HE102 Access >Point and Netgear HA501 PC card. -- running XP. > > I have no idea what the IPs would be, but I'm sure you'll get the point >I'm trying to make... > Therefore to achieve that, I'll need to purcahse a Switch that would >plug into the Router itself. > > I want to use an External Switch to link all the PC's to the connection. > With advice from some people, it seems people prefer Swithces to Hubs >because it only directs data when it's needed. Are you able to recommend >a decent 8 port external switch that'd be suited? I searched sites like >dabs.com and there's just so many, I don't which are suitable. Again down to personal preference realy, get the best you can afford. > > 3. > This switch would need to be connected to the Router with a Cat5 cable >- could you advise what port it'd go into? > I tried reading the guide at >http://www.cisco.com/univercd/cc/td...hig/1721ovw.htm about the Ethernet, >Auxilary, and Console port, and I *think* it's the Auxiliry one? > Is the "Ethernet" port used to actually connect the router to the NTU? No the Ethernet is for your use, plug the router into the ethernet port. > > 4. > Each PC wanting to access the connection, including 3 PC's and one >laptop would need to do the following: > 2 x FreeBSD servers would need a Cat5 cable from an Ethernet card in >the Boxes to the Switch. > 1 x Windows machine would need a Cat5 cable from an Ethernet card in >the box to the switch. > 1 x Laptop (Netgear HE102 Access Point) talking to a HA501 PC card on >the Laptop. > > In the FreeBSD machines, I'd need to use the following in /etc/rc.conf: > ifconfig_sis0="inet the.ip.here netmask 255.255.255.0" No 8 IPS is not 255.255.255.0, use the netmask your ISP provides, (most likely /29 == 255.255.255.248 > > where sis0 is the Ethernet in that particular machine, "the.ip.here" >the public IP assigned to me by the ISP (I'll be getting a block of them) > and ensure /etc/hosts and /etc/resolv.conf are all set. > I'd also need to repeat this on the 2 Windows machines, though their >setup is very simple... > > Do you agree this is the right idea for the actual "network setup"? > Couple of points, unless you are expecting very high traffic and or the website is a complex scripted thing with a sql backend, Web and Mail can easily run from one box/IP but thats a personal preference thing, Also is there a reason for each workstation to have a real IP ? Windows directly exposed to the internet is rarely a good thing, even with XP sp2 having the firewall on by default. My prefered setup here would be to have a freebsd firewall (2 network cards) connected to the router with a crossover cable, and to the switch with the other network card. the firewall has all the external IPs assigned to its external interface, and a private IP on its internal interface. Give your mail and web servers internal IPs, Setup IPFW/IPF and NATD/IPNAT as prefered to NAT all traffic sent to the IP you want to belong to your mailserver to the mailservers private IP, and the same with the webserver. Setup appropriate firewall rules limiting access to your web and mail server. 1 set of firewall rules to maintain instead of many. NAT your workstations to another IP and possibly seup a DHCP server on one of your FreeBSD servers for your windows clients, this allows more flexability for growth in network usage ie. you have a visitor with a laptop wants to access the internet via the netgear access point, cant be done with your setup unless someone else gives up their IP. This way also leaves one external IP spare for future useage. setup the Firewall to have te router as its default route and everything else to have the firewall internals IP as their gateway, make sure the firewall has gateway_enable="YES" in rc.conf. Talking of access points, make sure you use some kind of security on it. WEP is still probably the easiest and better than nothing, but have a look what your AP and clients support. > Now my questions begin regarding security for the services in >particular. Would it be "sufficient" to just run IPFW rules on each of >the FreeBSD servers, and software firewalls on the Windows machines? Or, >could you recommend a Hardware Firewall that and how it'd integrate into >the above setup please? See above. I use ipf so i cant realy comment on IPFW commands. (IPFW seems very good i have just never got round to learning it.) > For the FreeBSD machines I thought the following fules (again >researching to find these - but I may very well be incorrect): > > # Define the firewall command (as in /etc/rc.firewall) for easy > # reference. Helps to make it easier to read. > fwcmd="/sbin/ipfw" > > # Force a flushing of the current rules before we reload. > $fwcmd -f flush > > # Allow all connections that have dynamic rules built for them, > # but deny established connections that don't have a dynamic rule. > # See ipfw(8) for details. > $fwcmd add check-state > $fwcmd add pass tcp from any to any keep-state > > # Allow all localhost connections > $fwcmd add 100 pass all from any to any via lo0 > $fwcmd add 200 deny log all from any to 127.0.0.0/8 > $fwcmd add 300 deny log ip from 127.0.0.0/8 to any > > # Allow all connections from my network card that I initiate > $fwcmd add allow tcp from me to any out xmit any setup keep-state > $fwcmd add deny log tcp from me to any > $fwcmd add allow ip from me to any out xmit any keep-state > $fwcmd add allow all from 192.168.0.0/24 to any > > # Everyone on the Internet is allowed to connect to the following > # services on the machine. This example specifically allows connections > # to sshd and a webserver. > $fwcmd add allow tcp from any to any keep-state > $fwcmd add allow tcp from any to me 80 setup > > # This sends a RESET to all ident packets. > $fwcmd add reset log tcp from any to me 113 in recv any > > # Enable ICMP: remove type 8 if you don't want your host to be pingable > $fwcmd add allow icmp from any to any icmptypes 0,3,8,11,12,13,14 > > # Deny all the rest. > $fwcmd add deny log ip from any to any > > How's this? > > Obviously, for each there'd be different rules as they'll be running different daemons, so I'd just alter the $fwcmd add allow tcp from any to >me 80 setup line... > > Thanks very much for reading, and I hope I've been clear in explaining >this "scenario" - I really appreciate your advice, and our community >thanks you. Your welcome. Your suggestions look like they will work fine, but as i say, with no room for growth, and slightly more complex to maintain (more sets of firewall rules etc,) if slightly easier to seup. Vince > > Regards, > _______________________________________________ > 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 Sat Sep 11 12:22:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61BD316A4CF for ; Sat, 11 Sep 2004 12:22:41 +0000 (GMT) Received: from FreeBSD.SharkTECH.net (usr1-123.sharktech.net [66.90.92.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D181D43D48 for ; Sat, 11 Sep 2004 12:22:40 +0000 (GMT) (envelope-from freebsd@sharktech.net) Received: (qmail 46146 invoked from network); 11 Sep 2004 12:22:37 -0000 Received: from unknown (HELO psyxakias) (212.54.222.248) by 66.90.92.240 with SMTP; 11 Sep 2004 12:22:37 -0000 Message-ID: <005f01c497fa$06aa2a90$dec2fea9@psyxakias> From: "SharkTECH Maillists" To: Date: Sat, 11 Sep 2004 15:22:36 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-7"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Interface Bonding & Bridging problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 12:22:41 -0000 Hello, I have been running a FreeBSD 4.10-STABLE server having 3 nics installed but was using only 2 of them (1 for uplink and 1 for switch) to monitor, filter and shape my network and had absolutely no problems at all. However, in order to increase the ability of handling even more packets (especially while filtering incoming DDoS), I decided to get a 2nd uplink from backbone, connect it to em1, bond em0/em1 (uplinks) to ngeth0/fec0 (virtual interface) and bridge ngeth0/fec0 with em2 (switch link). In order for this to work, etherchanneling is enabled between uplink1/uplink2 at the backbone side. The problem is although bonding seems to work fine as I can assign IPs at fec0/ngeth0 and send/receive packet with both cards using the virtual interface, I cannot get bridging to work at all between ngeth0/fec0(virtual) and em2(switch). There are no errors in logs, it just doesn't seem to bridge. After doing a 2 days research in Google, FreeBSD maillists, web articles and asking for help in freebsdhelp IRC channels, I ended up that someone in FreeBSD maillists may be able to help me providing me a different bonding/bridging way or even by applying a patch. I was thinking that the solution may be to do both bonding & bridging using netgraph, and not bridging using FreeBSD's kernel bridge. I'd be glad to try this but unfortunately I haven't figured out how, even after reading several articles. So if anyone can help me on this step-by-step, please do. I will appreciate any replies after you take a look at the diagrams and settings below, that are showing what exactly I have done until now. Best Regards, Angelos Pantazopoulos freebsd@sharktech.net SharkTECH Internet Services ==================================================== S E T T I N G S ==================================================== Using 1 uplink settings (works excellent) ----------------------------------------- #bridging# (options BRIDGE in kernel) ifconfig em0 -arp sysctl net.link.ether.bridge=1 sysctl net.link.ether.bridge_cfg=em0,em1 sysctl net.link.ether.bridge_ipfw=1 Using 2 uplinks with ng_fec (bridging problem) ---------------------------------------------- #bonding# kldload ng_ether kldload ng_fec ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface '"em0"' ngctl msg fec0: add_iface '"em1"' ngctl msg fec0: set_mode_inet ifconfig em0 promisc ifconfig em1 promisc ifconfig fec0 promisc #bridging# (options BRIDGE in kernel) sysctl net.link.ether.bridge=1 sysctl net.link.ether.bridge_cfg=fec0,em2 sysctl net.link.ether.bridge_ipfw=1 Using 2 uplinks with ng_one2many (bridging problem) --------------------------------------------------- #bonding# kldload ng_ether kldload ng_one2many ifconfig em0 promisc -arp up ifconfig em1 promisc -arp up ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many lower one ngctl connect em0: ngeth0:lower lower many0 ngctl connect em1: ngeth0:lower lower many1 ifconfig ngeth0 -arp up #bridging# (options BRIDGE in kernel) sysctl net.link.ether.bridge=1 sysctl net.link.ether.bridge_cfg=ngeth0,em2 sysctl net.link.ether.bridge_ipfw=1 ==================================================== D I A G R A M S ==================================================== Using 1 uplink (works excellent): ---------------------- INTERNET UPLINK ---------------------- | | em0 *************** FREEBSD BOX FOR <<-- Bridging em0 and em2 IPFW FILTERING *************** em2 | | ---------------------- SWITCH ---------------------- Using 2 uplinks (bridging problem): ---------------------- INTERNET UPLINK ---------------------- | | | | em0 em1 \ / \ / (virtual) *************** FREEBSD BOX FOR <<-- Bonding em0/em1 and bridging with em2 IPFW FILTERING *************** em2 | | ---------------------- SWITCH ---------------------- From owner-freebsd-net@FreeBSD.ORG Sat Sep 11 12:46:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFF6C16A4CE for ; Sat, 11 Sep 2004 12:46:42 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29F1E43D6D for ; Sat, 11 Sep 2004 12:46:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-120-131-100.dsl.snfc21.pacbell.net [68.120.131.100])i8BCkd3d148558 for ; Sat, 11 Sep 2004 08:46:40 -0400 Message-ID: <4142F3AF.9030409@elischer.org> Date: Sat, 11 Sep 2004 05:46:39 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fwd: Interface Bonding & Bridging problem] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 12:46:42 -0000 -------- Original Message -------- Subject: Interface Bonding & Bridging problem Date: Sat, 11 Sep 2004 15:22:38 +0300 From: SharkTECH Maillists To: Hello, I have been running a FreeBSD 4.10-STABLE server having 3 nics installed but was using only 2 of them (1 for uplink and 1 for switch) to monitor, filter and shape my network and had absolutely no problems at all. However, in order to increase the ability of handling even more packets (especially while filtering incoming DDoS), I decided to get a 2nd uplink from backbone, connect it to em1, bond em0/em1 (uplinks) to ngeth0/fec0 (virtual interface) and bridge ngeth0/fec0 with em2 (switch link). In order for this to work, etherchanneling is enabled between uplink1/uplink2 at the backbone side. The problem is although bonding seems to work fine as I can assign IPs at fec0/ngeth0 and send/receive packet with both cards using the virtual interface, I cannot get bridging to work at all between ngeth0/fec0(virtual) and em2(switch). There are no errors in logs, it just doesn't seem to bridge. After doing a 2 days research in Google, FreeBSD maillists, web articles and asking for help in freebsdhelp IRC channels, I ended up that someone in FreeBSD maillists may be able to help me providing me a different bonding/bridging way or even by applying a patch. I was thinking that the solution may be to do both bonding & bridging using netgraph, and not bridging using FreeBSD's kernel bridge. I'd be glad to try this but unfortunately I haven't figured out how, even after reading several articles. So if anyone can help me on this step-by-step, please do. I will appreciate any replies after you take a look at the diagrams and settings below, that are showing what exactly I have done until now. Best Regards, Angelos Pantazopoulos freebsd@sharktech.net SharkTECH Internet Services ==================================================== S E T T I N G S ==================================================== Using 1 uplink settings (works excellent) ----------------------------------------- #bridging# (options BRIDGE in kernel) ifconfig em0 -arp sysctl net.link.ether.bridge=1 sysctl net.link.ether.bridge_cfg=em0,em1 sysctl net.link.ether.bridge_ipfw=1 Using 2 uplinks with ng_fec (bridging problem) ---------------------------------------------- #bonding# kldload ng_ether kldload ng_fec ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface '"em0"' ngctl msg fec0: add_iface '"em1"' ngctl msg fec0: set_mode_inet ifconfig em0 promisc ifconfig em1 promisc ifconfig fec0 promisc #bridging# (options BRIDGE in kernel) sysctl net.link.ether.bridge=1 sysctl net.link.ether.bridge_cfg=fec0,em2 sysctl net.link.ether.bridge_ipfw=1 Using 2 uplinks with ng_one2many (bridging problem) --------------------------------------------------- #bonding# kldload ng_ether kldload ng_one2many ifconfig em0 promisc -arp up ifconfig em1 promisc -arp up ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many lower one ngctl connect em0: ngeth0:lower lower many0 ngctl connect em1: ngeth0:lower lower many1 ifconfig ngeth0 -arp up #bridging# (options BRIDGE in kernel) sysctl net.link.ether.bridge=1 sysctl net.link.ether.bridge_cfg=ngeth0,em2 sysctl net.link.ether.bridge_ipfw=1 ==================================================== D I A G R A M S ==================================================== Using 1 uplink (works excellent): ---------------------- INTERNET UPLINK ---------------------- | | em0 *************** FREEBSD BOX FOR <<-- Bridging em0 and em2 IPFW FILTERING *************** em2 | | ---------------------- SWITCH ---------------------- Using 2 uplinks (bridging problem): ---------------------- INTERNET UPLINK ---------------------- | | | | em0 em1 \ / \ / (virtual) *************** FREEBSD BOX FOR <<-- Bonding em0/em1 and bridging with em2 IPFW FILTERING *************** em2 | | ---------------------- SWITCH ---------------------- _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Sep 11 13:24:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07ECC16A4CE for ; Sat, 11 Sep 2004 13:24:13 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E261843D46 for ; Sat, 11 Sep 2004 13:24:12 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i8BDO6Ib037614; Sat, 11 Sep 2004 06:24:06 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i8BDO624037613; Sat, 11 Sep 2004 06:24:06 -0700 (PDT) (envelope-from rizzo) Date: Sat, 11 Sep 2004 06:24:06 -0700 From: Luigi Rizzo To: Don Bowman Message-ID: <20040911062406.A37565@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from don@sandvine.com on Fri, Sep 10, 2004 at 03:51:48PM -0400 cc: freebsd-net@freebsd.org cc: Glenn Dawson Subject: Re: dyn buckets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 13:24:13 -0000 On Fri, Sep 10, 2004 at 03:51:48PM -0400, Don Bowman wrote: > From: owner-freebsd-net@freebsd.org > > I have a firewall running 4.10 that handles around > > 20mbits/sec of traffic > > and has around 500 ipfw rules. > > > > Lately I've noticed that net.inet.ip.fw.curr_dyn_buckets > > seems to be maxing > > out. I've increased net.inet.ip.fw.dyn_buckets a few times, what hits the limit is the number of rules not the number of buckets -- try raising net.inet.ip.fw.dyn_max as suggested. cheers luigi > > but they seem > > to max out each time. > > > > Is there any problem with increasing > > net.inet.ip.fw.dyn_buckets far beyond > > the default? (I'm at 2048 now) > > I use > net.inet.ip.fw.dyn_buckets=16384 > net.inet.ip.fw.dyn_syn_lifetime=5 > net.inet.ip.fw.dyn_max=32000 > > > _______________________________________________ > 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 Sat Sep 11 23:48:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2804316A4CE for ; Sat, 11 Sep 2004 23:48:48 +0000 (GMT) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id C47E843D31 for ; Sat, 11 Sep 2004 23:48:47 +0000 (GMT) (envelope-from ababurko@adelphia.net) Received: from ample.adelphia.net ([24.52.224.96]) by mta10.adelphia.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040911234847.VWAA9204.mta10.adelphia.net@ample.adelphia.net> for ; Sat, 11 Sep 2004 19:48:47 -0400 Message-Id: <5.2.1.1.0.20040911194241.01c0e928@mail.dc2.adelphia.net> X-Sender: ababurko@mail.dc2.adelphia.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 11 Sep 2004 19:48:46 -0400 To: freebsd-net@FreeBSD.org From: Bob Ababurko Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: gateway for separate networks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2004 23:48:48 -0000 Hello all- I want to install another NIC in my box running 5.2.1 to access another network. Since I have never done this before, I have a question about the gateway that the second NIC will use....more specifically, where do I configure the gateway for the second NIC. I have the defaultrouter in the rc.conf file for the first, do I do the same or do I add routes to tackle this. If someone could show me any resources on the web that deals with this,that would be great. thanks, Bob