From owner-freebsd-net@FreeBSD.ORG Sun Jun 18 13:20:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E5AD16A492 for ; Sun, 18 Jun 2006 13:20:17 +0000 (UTC) (envelope-from nightstalker.micronta@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8156443D45 for ; Sun, 18 Jun 2006 13:20:16 +0000 (GMT) (envelope-from nightstalker.micronta@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so684387wxd for ; Sun, 18 Jun 2006 06:20:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:to:subject:date:mime-version:content-type:x-mailer:thread-index:x-mimeole:from:message-id; b=FcUK1PhYspRoHa3bOuPQ57/Wo1+ugjB8SW4yonoudEVT+r8qaIpqU9VOvEh3+5yo32qfUGeVJtrfsIfFtUPvY5Rq6ACCjy9ibaIUUs/IbUboG9X8lSH/MNvU8D/NjpjLJf3KTUnATtH81mHFw8DeW8IJcuwtvfUq+M5ONCGwfY0= Received: by 10.70.24.3 with SMTP id 3mr6891943wxx; Sun, 18 Jun 2006 06:20:15 -0700 (PDT) Received: from nsmws ( [24.129.19.2]) by mx.gmail.com with ESMTP id h16sm4420389wxd.2006.06.18.06.20.15; Sun, 18 Jun 2006 06:20:15 -0700 (PDT) To: Date: Sun, 18 Jun 2006 09:20:14 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcaS2e71kh6vP+0dSWKEYa8uXQ41GA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 From: "Roger T. Harvey" Message-ID: <4495530f.265f68ff.360d.48fa@mx.gmail.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Simple LAN IP accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jun 2006 13:20:17 -0000 Ok, I've done research, and found this example to track bytes per ip on LAN: $IPFW pipe 1 config mask src-ip 0xffffffff buckets 512 $IPFW pipe 2 config mask dst-ip 0xffffffff buckets 512 $IPFW add 32001 pipe 1 src-ip 192.168.110.0/24 bridged $IPFW add 32002 pipe 2 dst-ip 192.168.110.0/24 bridged Now that's all well and good, and I saw the output as well. However, im not running bridged. or does that make a difference in this instance? Also, is there any scripts, etc to format the pipe info into a nice readable format (pref html) Doesn't need graphs, etc. Just Daily and Monthly totals would be nice. (I am running MySQL so it can store the data) Concidered to this list, you can call me a newbie for sure. as I only know how to Do a handful of things and that's about it. which is why im asking here. TIA to everyone From owner-freebsd-net@FreeBSD.ORG Sun Jun 18 14:21:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF73816A47A for ; Sun, 18 Jun 2006 14:21:24 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F6143D45 for ; Sun, 18 Jun 2006 14:21:24 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 9AD875DF9; Sun, 18 Jun 2006 10:21:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFZKm90Nz6qG; Sun, 18 Jun 2006 10:21:22 -0400 (EDT) Received: from [192.168.1.251] (pool-68-160-201-170.ny325.east.verizon.net [68.160.201.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 9FEE95D3A; Sun, 18 Jun 2006 10:21:22 -0400 (EDT) Message-ID: <4495615E.3050604@mac.com> Date: Sun, 18 Jun 2006 10:21:18 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Roger T. Harvey" References: <4495530f.265f68ff.360d.48fa@mx.gmail.com> In-Reply-To: <4495530f.265f68ff.360d.48fa@mx.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Simple LAN IP accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jun 2006 14:21:24 -0000 Roger T. Harvey wrote: > $IPFW pipe 1 config mask src-ip 0xffffffff buckets 512 > $IPFW pipe 2 config mask dst-ip 0xffffffff buckets 512 > $IPFW add 32001 pipe 1 src-ip 192.168.110.0/24 bridged > $IPFW add 32002 pipe 2 dst-ip 192.168.110.0/24 bridged > > Now that's all well and good, and I saw the output as well. > However, im not running bridged. or does that make a difference in this > instance? It means you should create pipe rules which match the traffic you want to count, rather than using the "bridged" keyword (which would match none of your traffic). Something like "in via fxp0" and "out via fxp0" might be right, assuming for the sake of example that you had an Intel "Fast EEPro" card which was the interface on the subnet whose traffic you want to count. > Also, is there any scripts, etc to format the pipe info into a nice readable > format (pref html) > > Doesn't need graphs, etc. Just Daily and Monthly totals would be nice. > (I am running MySQL so it can store the data) This kind of thing tends to be fairly idiosyncratic, and you'll probably have to modify or write something for your specific case...perhaps others have more useful sample scripts to contribute. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sun Jun 18 14:26:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 834D916A482 for ; Sun, 18 Jun 2006 14:26:45 +0000 (UTC) (envelope-from trashy_bumper@yahoo.com) Received: from web36304.mail.mud.yahoo.com (web36304.mail.mud.yahoo.com [209.191.84.234]) by mx1.FreeBSD.org (Postfix) with SMTP id EF5DC43D49 for ; Sun, 18 Jun 2006 14:26:44 +0000 (GMT) (envelope-from trashy_bumper@yahoo.com) Received: (qmail 81733 invoked by uid 60001); 18 Jun 2006 14:26:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fsu54gaeqdEE1gB1Y6FHn4NI4dLJ/N5SBbpU01UwuQOJMKG3/+ScH3IYaawER+rYCk1jfTiwc8mcFW2vEYoWZ3rIVRsxo6TeBOWPlVGIYyKb2N1CYPYrTPOH60nVkNNpqwurwweG3BdNPJBzSA7WcpCsjYczR8jVEBzzlXuWBbw= ; Message-ID: <20060618142644.81731.qmail@web36304.mail.mud.yahoo.com> Received: from [213.227.206.11] by web36304.mail.mud.yahoo.com via HTTP; Sun, 18 Jun 2006 07:26:44 PDT Date: Sun, 18 Jun 2006 07:26:44 -0700 (PDT) From: Nash Nipples To: freebsd-net@freebsd.org In-Reply-To: <4495530f.265f68ff.360d.48fa@mx.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Simple LAN IP accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jun 2006 14:26:45 -0000 ipfw add 5 skipto 500 ip from 192.168.110.1 to any out via tun0 ipfw add 10 skipto 500 ip from any to 192.168.110.1 to any in via tun0 ipfw add .. skipto 500 ip from 192.168.110... to any out via tun0 ... ipfw add 500 divert from any to any in via tun0 #back to normal rules ipfw show 00005 274943 64986791 ip from 192.168.110.1 to any out via tun0 00010 274943 64986791 ip from any to 192.168.110.1 in via tun0 thats pretty stupid but works. and you need a program to proccess the output thats what im working on time to time :) it doesnt overload the filter cuz a matching rule is passed once at a time and the unmatched skipped to normal rules. if you get out of ipfw rules limits you might consider to split.. lol anyone else? nash "Roger T. Harvey" wrote: Ok, I've done research, and found this example to track bytes per ip on LAN: $IPFW pipe 1 config mask src-ip 0xffffffff buckets 512 $IPFW pipe 2 config mask dst-ip 0xffffffff buckets 512 $IPFW add 32001 pipe 1 src-ip 192.168.110.0/24 bridged $IPFW add 32002 pipe 2 dst-ip 192.168.110.0/24 bridged Now that's all well and good, and I saw the output as well. However, im not running bridged. or does that make a difference in this instance? Also, is there any scripts, etc to format the pipe info into a nice readable format (pref html) Doesn't need graphs, etc. Just Daily and Monthly totals would be nice. (I am running MySQL so it can store the data) Concidered to this list, you can call me a newbie for sure. as I only know how to Do a handful of things and that's about it. which is why im asking here. TIA to everyone _______________________________________________ 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" --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --------------------------------- Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta. From owner-freebsd-net@FreeBSD.ORG Sun Jun 18 15:36:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10AFD16A479; Sun, 18 Jun 2006 15:36:26 +0000 (UTC) (envelope-from flag@newluxor.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 631B543D45; Sun, 18 Jun 2006 15:36:24 +0000 (GMT) (envelope-from flag@newluxor.wired.org) Received: from newluxor.wired.org (ip-79-107.sn1.eutelia.it [62.94.79.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 6F16D11AE82; Sun, 18 Jun 2006 17:36:10 +0200 (CEST) Received: from newluxor.wired.org (localhost [127.0.0.1]) by newluxor.wired.org (8.13.6/8.13.6) with ESMTP id k5IFZZnt069956; Sun, 18 Jun 2006 17:35:35 +0200 (CEST) (envelope-from flag@newluxor.wired.org) Received: (from flag@localhost) by newluxor.wired.org (8.13.6/8.13.6/Submit) id k5IFZZ0U069955; Sun, 18 Jun 2006 17:35:35 +0200 (CEST) (envelope-from flag) Date: Sun, 18 Jun 2006 17:35:32 +0200 From: Paolo Pisati To: FreeBSD_Net Message-ID: <20060618153532.GA69905@tin.it> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: Subject: Libalias modules and ipfw nat for HEAD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jun 2006 15:36:26 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached is the final patch for HEAD of my soc2005 work about ipfw and libalias. Please take a look at it and reprt any problem you'll find, cause i would like to commit it ASAP. There are no fundamental differences between this patch and the previous one: i just merged all the documentation into ipfw.8 and libalias.3. If you want to know exactly what we get with this patch: http://wikitest.freebsd.org/Libalias bye -- Paolo Piso's first law: nothing works as expected! --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="libalias_ipfw_final.patch" diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/etc/Makefile /home/flag/src/freebsd7/src/etc/Makefile *** /home/flag/src/freebsd7_vanilla/src/etc/Makefile Wed May 3 17:14:46 2006 --- /home/flag/src/freebsd7/src/etc/Makefile Sun Jun 11 18:59:46 2006 *************** *** 11,17 **** crontab csh.cshrc csh.login csh.logout devd.conf devfs.conf \ dhclient.conf disktab fbtab ftpusers gettytab group \ hosts hosts.allow hosts.equiv hosts.lpd \ ! inetd.conf login.access login.conf mac.conf motd \ netconfig network.subr networks newsyslog.conf nsswitch.conf \ portsnap.conf pf.conf pf.os phones profile protocols \ rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless \ --- 11,17 ---- crontab csh.cshrc csh.login csh.logout devd.conf devfs.conf \ dhclient.conf disktab fbtab ftpusers gettytab group \ hosts hosts.allow hosts.equiv hosts.lpd \ ! inetd.conf libalias.conf login.access login.conf mac.conf motd \ netconfig network.subr networks newsyslog.conf nsswitch.conf \ portsnap.conf pf.conf pf.os phones profile protocols \ rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless \ diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/etc/libalias.conf /home/flag/src/freebsd7/src/etc/libalias.conf *** /home/flag/src/freebsd7_vanilla/src/etc/libalias.conf Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/etc/libalias.conf Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,7 ---- + /usr/lib/libalias_cuseeme.so + /usr/lib/libalias_ftp.so + /usr/lib/libalias_irc.so + /usr/lib/libalias_nbt.so + /usr/lib/libalias_pptp.so + /usr/lib/libalias_skinny.so + /usr/lib/libalias_smedia.so diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/lib/libalias/Makefile /home/flag/src/freebsd7/src/lib/libalias/Makefile *** /home/flag/src/freebsd7_vanilla/src/lib/libalias/Makefile Fri Jul 22 19:18:59 2005 --- /home/flag/src/freebsd7/src/lib/libalias/Makefile Sun Jun 11 19:01:50 2006 *************** *** 1,16 **** # $FreeBSD: src/lib/libalias/Makefile,v 1.31 2005/07/22 17:18:59 kensmith Exp $ ! ! .PATH: ${.CURDIR}/../../sys/netinet/libalias ! ! LIB= alias ! SHLIBDIR?= /lib ! SHLIB_MAJOR= 5 ! MAN= libalias.3 ! SRCS= alias.c alias_cuseeme.c alias_db.c alias_ftp.c alias_irc.c \ ! alias_nbt.c alias_pptp.c alias_proxy.c alias_skinny.c alias_smedia.c \ ! alias_util.c alias_old.c ! INCS= alias.h ! WARNS?= 6 ! NO_WERROR= ! ! .include --- 1,12 ---- # $FreeBSD: src/lib/libalias/Makefile,v 1.31 2005/07/22 17:18:59 kensmith Exp $ ! SUBDIR= lib-cuseeme \ ! lib-dummy \ ! lib-ftp \ ! lib-irc \ ! lib-libalias \ ! lib-nbt \ ! lib-pptp \ ! lib-skinny \ ! lib-smedia ! ! .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-cuseeme/Makefile /home/flag/src/freebsd7/src/lib/libalias/lib-cuseeme/Makefile *** /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-cuseeme/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/lib/libalias/lib-cuseeme/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,11 ---- + .PATH: ${.CURDIR}/../../../sys/netinet/libalias + + LIB= alias_cuseeme + SHLIBDIR?= /lib + SHLIB_MAJOR= 4 + SRCS= alias_cuseeme.c + INCS= alias_mod.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-dummy/Makefile /home/flag/src/freebsd7/src/lib/libalias/lib-dummy/Makefile *** /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-dummy/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/lib/libalias/lib-dummy/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,11 ---- + .PATH: ${.CURDIR}/../../../sys/netinet/libalias + + LIB= alias_dummy + SHLIBDIR?= /lib + SHLIB_MAJOR= 4 + SRCS= alias_dummy.c + INCS= alias_mod.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-ftp/Makefile /home/flag/src/freebsd7/src/lib/libalias/lib-ftp/Makefile *** /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-ftp/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/lib/libalias/lib-ftp/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,11 ---- + .PATH: ${.CURDIR}/../../../sys/netinet/libalias + + LIB= alias_ftp + SHLIBDIR?= /lib + SHLIB_MAJOR= 4 + SRCS= alias_ftp.c + INCS= alias_mod.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-irc/Makefile /home/flag/src/freebsd7/src/lib/libalias/lib-irc/Makefile *** /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-irc/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/lib/libalias/lib-irc/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,11 ---- + .PATH: ${.CURDIR}/../../../sys/netinet/libalias + + LIB= alias_irc + SHLIBDIR?= /lib + SHLIB_MAJOR= 4 + SRCS= alias_irc.c + INCS= alias_mod.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-libalias/Makefile /home/flag/src/freebsd7/src/lib/libalias/lib-libalias/Makefile *** /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-libalias/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/lib/libalias/lib-libalias/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,14 ---- + # $FreeBSD: src/lib/libalias/Makefile,v 1.30.2.1 2005/07/22 17:29:02 kensmith Exp $ + + .PATH: ${.CURDIR}/../../../sys/netinet/libalias + + LIB= alias + SHLIBDIR?= /lib + SHLIB_MAJOR= 5 + MAN= libalias.3 + SRCS= alias.c alias_db.c alias_proxy.c alias_util.c alias_old.c alias_mod.c + INCS= alias.h alias_mod.h + WARNS?= 6 + NO_WERROR= + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-nbt/Makefile /home/flag/src/freebsd7/src/lib/libalias/lib-nbt/Makefile *** /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-nbt/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/lib/libalias/lib-nbt/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,11 ---- + .PATH: ${.CURDIR}/../../../sys/netinet/libalias + + LIB= alias_nbt + SHLIBDIR?= /lib + SHLIB_MAJOR= 4 + SRCS= alias_nbt.c + INCS= alias_mod.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-pptp/Makefile /home/flag/src/freebsd7/src/lib/libalias/lib-pptp/Makefile *** /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-pptp/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/lib/libalias/lib-pptp/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,11 ---- + .PATH: ${.CURDIR}/../../../sys/netinet/libalias + + LIB= alias_pptp + SHLIBDIR?= /lib + SHLIB_MAJOR= 4 + SRCS= alias_pptp.c + INCS= alias_mod.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-skinny/Makefile /home/flag/src/freebsd7/src/lib/libalias/lib-skinny/Makefile *** /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-skinny/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/lib/libalias/lib-skinny/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,11 ---- + .PATH: ${.CURDIR}/../../../sys/netinet/libalias + + LIB= alias_skinny + SHLIBDIR?= /lib + SHLIB_MAJOR= 4 + SRCS= alias_skinny.c + INCS= alias_mod.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-smedia/Makefile /home/flag/src/freebsd7/src/lib/libalias/lib-smedia/Makefile *** /home/flag/src/freebsd7_vanilla/src/lib/libalias/lib-smedia/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/lib/libalias/lib-smedia/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,11 ---- + .PATH: ${.CURDIR}/../../../sys/netinet/libalias + + LIB= alias_smedia + SHLIBDIR?= /lib + SHLIB_MAJOR= 4 + SRCS= alias_smedia.c + INCS= alias_mod.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sbin/ipfw/ipfw.8 /home/flag/src/freebsd7/src/sbin/ipfw/ipfw.8 *** /home/flag/src/freebsd7_vanilla/src/sbin/ipfw/ipfw.8 Wed May 24 15:09:55 2006 --- /home/flag/src/freebsd7/src/sbin/ipfw/ipfw.8 Sun Jun 18 16:10:14 2006 *************** *** 2027,2032 **** --- 2027,2124 ---- If no socket is bound to the destination port, or if the divert module is not loaded, or if the kernel was not compiled with divert socket support, the packets are dropped. + .Sh IPFW NAT + To support nat operations inside ipfw, the syntax was extended with a + new action: nat. + Then, to configure/handle nat instances the following syntax was + added (trying to follow closely pipe|queue options): + .Bd -ragged -offset indent + .Bk -words + .Cm nat + .Ar nat_number + .Cm config + .Ar options + .Ek + .Ed + .Pp + where + .Ar options + is one or more mandatory fields that can assume the + following values: + .Bl -tag -width indent + .It Cm ip Ar ip_address + Define an ip address to use for aliasing + .It Cm if Ar nic + Use ip addres of NIC for aliasing, dynamically changing + it if NIC's ip address change + .It Cm log + Enable logging on this nat instance + .It Cm deny_in + Deny any incoming connection from outside world + .It Cm same_ports + Try to leave the alias port numbers unchanged from + the actual local port numbers + .It Cm unreg_only + Traffic on the local network not originating from an + unregistered address spaces will be ignored + .It Cm reset + Reset table of the packet aliasing engine on address change + .It Cm reverse + Reverse the way libalias handles aliasing + .It Cm proxy_only + Obey transparent proxy rules only, packet aliasing is not performed + .El + .Pp + For more information about aliasing modes, take a look + at libalias( + .Xr libalias 3 + ). + .Pp + Other commands to manipulate nats are: + .Bd -ragged -offset indent + .Bk -words + .Cm nat + .Ar nat_number + .Cm show + .Cm config + .Ek + .Ed + .Pp + to see nat configuration of + .Ar nat_number + . + .Pp + .Bd -ragged -offset indent + .Bk -words + .Cm nat + .Ar nat_number + .Cm show + .Ek + .Ed + .Pp + to see the logs of + .Ar nat_number + (if any) + .Pp + In these two previous examples + .Ar nat_number + could be a single number to see the configuration of that + instance (i.e. 123, a range of numbers (i.e 333-555) to see the + configurations all the instances in that range or nothing, to see all + the configured instances. + .Pp + See Section + .Sx EXAMPLES + for some examples on how to use nat. + .Sh REDIRECT AND LSNAT SUPPORT IN IPFW + Redirect and LSNAT support follow closely the syntax used in natd: refer to natd's man page + for syntax details. + The only difference between natd's redirect and ipfw redirect is: + instead of redirect_[addr|port|prot] i chose redir_[addr|port|proto]. + .Pp + See Section + .Sx EXAMPLES + for some examples on how to do redirect and lsnat. .Sh SYSCTL VARIABLES A set of .Xr sysctl 8 *************** *** 2406,2411 **** --- 2498,2552 ---- Otherwise, e.g.\& if you cannot access your box, the ruleset will be disabled after the sleep terminates thus restoring the previous situation. + .Ss NAT, REDIRECT AND LSNAT + First redirect all the traffic to nat instance 123: + .Pp + .Dl "ipfw add nat 123 all from any to any" + .Pp + Then to configure nat instance 123 to alias all the outgoing traffic with ip + 192.168.0.123, blocking all incoming connections, trying to keep + same ports on both sides, clearing aliasing table on address change + and keeping a log of traffic/link statistics: + .Pp + .Dl "ipfw nat 123 config ip 192.168.0.123 log deny_in reset same_ports" + .Pp + Or to change address of instance 123, aliasing table will be cleared (see + reset option): + .Pp + .Dl "ipfw nat 123 config ip 10.0.0.1" + .Pp + To see configuration of nat instance 123: + .Pp + .Dl "ipfw nat 123 show config" + .Pp + To show logs of all the instances in range 111-999: + .Pp + .Dl "ipfw nat 111-999 show" + .Pp + To see configurations of all instances: + .Pp + .Dl "ipfw nat show config" + .Pp + Or a redirect rule with mixed modes could looks like: + .Pp + .Dl "ipfw nat 123 config redir_addr 10.0.0.1 10.0.0.66" + .Dl " redir_port tcp 192.168.0.1:80 500" + .Dl " redir_proto udp 192.168.1.43 192.168.1.1" + .Dl " redir_addr 192.168.0.10,192.168.0.11" + .Dl " 10.0.0.100 # LSNAT" + .Dl " redir_port tcp 192.168.0.1:80,192.168.0.10:22" + .Dl " 500 # LSNAT" + .Pp + or it could be splitted in: + .Pp + .Dl "ipfw nat 1 config redir_addr 10.0.0.1 10.0.0.66" + .Dl "ipfw nat 2 config redir_port tcp 192.168.0.1:80 500" + .Dl "ipfw nat 3 config redir_proto udp 192.168.1.43 192.168.1.1" + .Dl "ipfw nat 4 config redir_addr 192.168.0.10,192.168.0.11,192.168.0.12" + .Dl " 10.0.0.100" + .Dl "ipfw nat 5 config redir_port tcp" + .Dl " 192.168.0.1:80,192.168.0.10:22,192.168.0.20:25 500" + .Pp .Sh SEE ALSO .Xr cpp 1 , .Xr m4 1 , *************** *** 2446,2451 **** --- 2587,2597 ---- API based upon code written by .An Daniel Boulet for BSDI. + .Pp + .An -nosplit + In-kernel NAT support written by + .An Paolo Pisati Aq piso@FreeBSD.org + as part of a Summer of Code 2005 project. .Pp Work on .Xr dummynet 4 diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sbin/ipfw/ipfw2.c /home/flag/src/freebsd7/src/sbin/ipfw/ipfw2.c *** /home/flag/src/freebsd7_vanilla/src/sbin/ipfw/ipfw2.c Fri Jun 2 07:17:17 2006 --- /home/flag/src/freebsd7/src/sbin/ipfw/ipfw2.c Sun Jun 11 18:57:26 2006 *************** *** 48,53 **** --- 48,54 ---- #include #include + #include #include #include /* def. of struct route */ #include *************** *** 59,70 **** --- 60,73 ---- #include #include #include + #include int do_resolv, /* Would try to resolve all */ do_time, /* Show time stamps */ do_quiet, /* Be quiet in add and flush */ do_pipe, /* this cmd refers to a pipe */ + do_nat, /* nat configuration */ do_sort, /* field to sort results (0 = no) */ do_dynamic, /* display dynamic rules */ do_expired, /* display expired dynamic rules */ *************** *** 218,223 **** --- 221,227 ---- TOK_RESET, TOK_UNREACH, TOK_CHECKSTATE, + TOK_NAT, TOK_ALTQ, TOK_LOG, *************** *** 280,285 **** --- 284,301 ---- TOK_DROPTAIL, TOK_PROTO, TOK_WEIGHT, + TOK_IP, + TOK_IF, + TOK_LOG, + TOK_DENY_INC, + TOK_SAME_PORTS, + TOK_UNREG_ONLY, + TOK_RESET_ADDR, + TOK_ALIAS_REV, + TOK_PROXY_ONLY, + TOK_REDIR_ADDR, + TOK_REDIR_PORT, + TOK_REDIR_PROTO, TOK_IPV6, TOK_FLOWID, *************** *** 322,327 **** --- 338,359 ---- { NULL, 0 } /* terminator */ }; + struct _s_x nat_params[] = { + { "ip", TOK_IP }, + { "if", TOK_IF }, + { "log", TOK_LOG }, + { "deny_in", TOK_DENY_INC }, + { "same_ports", TOK_SAME_PORTS }, + { "unreg_only", TOK_UNREG_ONLY }, + { "reset", TOK_RESET_ADDR }, + { "reverse", TOK_ALIAS_REV }, + { "proxy_only", TOK_PROXY_ONLY }, + { "redir_addr", TOK_REDIR_ADDR }, + { "redir_port", TOK_REDIR_PORT }, + { "redir_proto", TOK_REDIR_PROTO }, + { NULL, 0 } /* terminator */ + }; + struct _s_x rule_actions[] = { { "accept", TOK_ACCEPT }, { "pass", TOK_ACCEPT }, *************** *** 346,351 **** --- 378,384 ---- { "unreach", TOK_UNREACH }, { "check-state", TOK_CHECKSTATE }, { "//", TOK_COMMENT }, + { "nat", TOK_NAT}, { NULL, 0 } /* terminator */ }; *************** *** 453,459 **** { static int s = -1; /* the socket */ int i; ! if (test_only) return 0; --- 486,492 ---- { static int s = -1; /* the socket */ int i; ! if (test_only) return 0; *************** *** 464,470 **** if (optname == IP_FW_GET || optname == IP_DUMMYNET_GET || optname == IP_FW_ADD || optname == IP_FW_TABLE_LIST || ! optname == IP_FW_TABLE_GETSIZE) i = getsockopt(s, IPPROTO_IP, optname, optval, (socklen_t *)optlen); else --- 497,504 ---- if (optname == IP_FW_GET || optname == IP_DUMMYNET_GET || optname == IP_FW_ADD || optname == IP_FW_TABLE_LIST || ! optname == IP_FW_TABLE_GETSIZE || optname == IP_FW_NAT_GET_CONFIG || ! optname == IP_FW_NAT_GET_LOG) i = getsockopt(s, IPPROTO_IP, optname, optval, (socklen_t *)optlen); else *************** *** 1520,1525 **** --- 1554,1563 ---- tagptr = cmd; break; + case O_NAT: + printf("nat %u", cmd->arg1); + break; + default: printf("** unrecognized action %d len %d ", cmd->opcode, cmd->len); *************** *** 2583,2595 **** "add [num] [set N] [prob x] RULE-BODY\n" "{pipe|queue} N config PIPE-BODY\n" "[pipe|queue] {zero|delete|show} [N{,N}]\n" "set [disable N... enable N...] | move [rule] X to Y | swap X Y | show\n" "table N {add ip[/bits] [value] | delete ip[/bits] | flush | list}\n" "\n" "RULE-BODY: check-state [PARAMS] | ACTION [PARAMS] ADDR [OPTION_LIST]\n" "ACTION: check-state | allow | count | deny | unreach{,6} CODE |\n" " skipto N | {divert|tee} PORT | forward ADDR |\n" ! " pipe N | queue N\n" "PARAMS: [log [logamount LOGLIMIT]] [altq QUEUE_NAME]\n" "ADDR: [ MAC dst src ether_type ] \n" " [ ip from IPADDR [ PORT ] to IPADDR [ PORTLIST ] ]\n" --- 2621,2636 ---- "add [num] [set N] [prob x] RULE-BODY\n" "{pipe|queue} N config PIPE-BODY\n" "[pipe|queue] {zero|delete|show} [N{,N}]\n" + "nat N config {ip IPADDR|if IFNAME|log|deny_in|same_ports|unreg_only|reset|\n" + " reverse|proxy_only|redir_addr linkspec| redir_port linkspec|\n" + " redir_proto linkspec}\n" "set [disable N... enable N...] | move [rule] X to Y | swap X Y | show\n" "table N {add ip[/bits] [value] | delete ip[/bits] | flush | list}\n" "\n" "RULE-BODY: check-state [PARAMS] | ACTION [PARAMS] ADDR [OPTION_LIST]\n" "ACTION: check-state | allow | count | deny | unreach{,6} CODE |\n" " skipto N | {divert|tee} PORT | forward ADDR |\n" ! " pipe N | queue N | nat N\n" "PARAMS: [log [logamount LOGLIMIT]] [altq QUEUE_NAME]\n" "ADDR: [ MAC dst src ether_type ] \n" " [ ip from IPADDR [ PORT ] to IPADDR [ PORTLIST ] ]\n" *************** *** 3098,3104 **** /* Rule number */ while (ac && isdigit(**av)) { i = atoi(*av); av++; ac--; ! if (do_pipe) { if (do_pipe == 1) p.pipe_nr = i; else --- 3139,3152 ---- /* Rule number */ while (ac && isdigit(**av)) { i = atoi(*av); av++; ac--; ! if (do_nat) { ! exitval = do_cmd(IP_FW_NAT_DEL, &i, sizeof i); ! if (exitval) { ! exitval = EX_UNAVAILABLE; ! warn("rule %u not available", ! i); ! } ! } else if (do_pipe) { if (do_pipe == 1) p.pipe_nr = i; else *************** *** 3123,3129 **** exit(exitval); } - /* * fill the interface structure. We do not check the name as we can * create interfaces dynamically, so checking them at insert time --- 3171,3176 ---- *************** *** 3147,3152 **** --- 3194,3946 ---- errx(EX_DATAERR, "bad ip address ``%s''", arg); } + /* + * Search for interface with name "ifn", and fill n accordingly: + * + * n->ip ip address of interface "ifn" + * n->if_name copy of interface name "ifn" + */ + static void + set_addr_dynamic(const char *ifn, struct cfg_nat *n) + { + size_t needed; + int mib[6]; + char *buf, *lim, *next; + struct if_msghdr *ifm; + struct ifa_msghdr *ifam; + struct sockaddr_dl *sdl; + struct sockaddr_in *sin; + int ifIndex, ifMTU; + + mib[0] = CTL_NET; + mib[1] = PF_ROUTE; + mib[2] = 0; + mib[3] = AF_INET; /* Only IP addresses please */ + mib[4] = NET_RT_IFLIST; + mib[5] = 0; /* ifIndex??? */ + /* + * Get interface data. + */ + if (sysctl(mib, 6, NULL, &needed, NULL, 0) == -1) + err(1, "iflist-sysctl-estimate"); + if ((buf = malloc(needed)) == NULL) + errx(1, "malloc failed"); + if (sysctl(mib, 6, buf, &needed, NULL, 0) == -1) + err(1, "iflist-sysctl-get"); + lim = buf + needed; + /* + * Loop through interfaces until one with + * given name is found. This is done to + * find correct interface index for routing + * message processing. + */ + ifIndex = 0; + next = buf; + while (next < lim) { + ifm = (struct if_msghdr *)next; + next += ifm->ifm_msglen; + if (ifm->ifm_version != RTM_VERSION) { + if (verbose) + warnx("routing message version %d " + "not understood", ifm->ifm_version); + continue; + } + if (ifm->ifm_type == RTM_IFINFO) { + sdl = (struct sockaddr_dl *)(ifm + 1); + if (strlen(ifn) == sdl->sdl_nlen && + strncmp(ifn, sdl->sdl_data, sdl->sdl_nlen) == 0) { + ifIndex = ifm->ifm_index; + ifMTU = ifm->ifm_data.ifi_mtu; + break; + } + } + } + if (!ifIndex) + errx(1, "unknown interface name %s", ifn); + /* + * Get interface address. + */ + sin = NULL; + while (next < lim) { + ifam = (struct ifa_msghdr *)next; + next += ifam->ifam_msglen; + if (ifam->ifam_version != RTM_VERSION) { + if (verbose) + warnx("routing message version %d " + "not understood", ifam->ifam_version); + continue; + } + if (ifam->ifam_type != RTM_NEWADDR) + break; + if (ifam->ifam_addrs & RTA_IFA) { + int i; + char *cp = (char *)(ifam + 1); + + for (i = 1; i < RTA_IFA; i <<= 1) + if (ifam->ifam_addrs & i) + cp += SA_SIZE((struct sockaddr *)cp); + if (((struct sockaddr *)cp)->sa_family == AF_INET) { + sin = (struct sockaddr_in *)cp; + break; + } + } + } + if (sin == NULL) + errx(1, "%s: cannot get interface address", ifn); + + n->ip = sin->sin_addr; + strncpy(n->if_name, ifn, IF_NAMESIZE); + + free(buf); + } + + /* + * XXX: the following functions, macros and definitions come from natd.c: + * it would be better to move them outside of natd.c, in a file + * (redirect_support.[ch]?) shared by ipfw and natd, but for now i can live + * with it... + */ + + /* + * Definition of a port range, and macros to deal with values. + * FORMAT: HI 16-bits == first port in range, 0 == all ports. + * LO 16-bits == number of ports in range + * NOTES: - Port values are not stored in network byte order. + */ + + #define port_range u_long + + #define GETLOPORT(x) ((x) >> 0x10) + #define GETNUMPORTS(x) ((x) & 0x0000ffff) + #define GETHIPORT(x) (GETLOPORT((x)) + GETNUMPORTS((x))) + + /* Set y to be the low-port value in port_range variable x. */ + #define SETLOPORT(x,y) ((x) = ((x) & 0x0000ffff) | ((y) << 0x10)) + + /* Set y to be the number of ports in port_range variable x. */ + #define SETNUMPORTS(x,y) ((x) = ((x) & 0xffff0000) | (y)) + + static void + StrToAddr (const char* str, struct in_addr* addr) + { + struct hostent* hp; + + if (inet_aton (str, addr)) + return; + + hp = gethostbyname (str); + if (!hp) + errx (1, "unknown host %s", str); + + memcpy (addr, hp->h_addr, sizeof (struct in_addr)); + } + + static int + StrToPortRange (const char* str, const char* proto, port_range *portRange) + { + char* sep; + struct servent* sp; + char* end; + u_short loPort; + u_short hiPort; + + /* First see if this is a service, return corresponding port if so. */ + sp = getservbyname (str,proto); + if (sp) { + SETLOPORT(*portRange, ntohs(sp->s_port)); + SETNUMPORTS(*portRange, 1); + return 0; + } + + /* Not a service, see if it's a single port or port range. */ + sep = strchr (str, '-'); + if (sep == NULL) { + SETLOPORT(*portRange, strtol(str, &end, 10)); + if (end != str) { + /* Single port. */ + SETNUMPORTS(*portRange, 1); + return 0; + } + + /* Error in port range field. */ + errx (EX_DATAERR, "%s/%s: unknown service", str, proto); + } + + /* Port range, get the values and sanity check. */ + sscanf (str, "%hu-%hu", &loPort, &hiPort); + SETLOPORT(*portRange, loPort); + SETNUMPORTS(*portRange, 0); /* Error by default */ + if (loPort <= hiPort) + SETNUMPORTS(*portRange, hiPort - loPort + 1); + + if (GETNUMPORTS(*portRange) == 0) + errx (EX_DATAERR, "invalid port range %s", str); + + return 0; + } + + static int + StrToProto (const char* str) + { + if (!strcmp (str, "tcp")) + return IPPROTO_TCP; + + if (!strcmp (str, "udp")) + return IPPROTO_UDP; + + errx (EX_DATAERR, "unknown protocol %s. Expected tcp or udp", str); + } + + static int + StrToAddrAndPortRange (const char* str, struct in_addr* addr, char* proto, port_range *portRange) + { + char* ptr; + + ptr = strchr (str, ':'); + if (!ptr) + errx (EX_DATAERR, "%s is missing port number", str); + + *ptr = '\0'; + ++ptr; + + StrToAddr (str, addr); + return StrToPortRange (ptr, proto, portRange); + } + + /* end of stuff taken from natd.c */ + + #define INC_ARGCV() do { \ + (*_av)++; \ + (*_ac)--; \ + av = *_av; \ + ac = *_ac; \ + } while(0) + + /* + * The next 3 functions add support for the addr, port and proto redirect and + * their logic is loosely based on SetupAddressRedirect(), SetupPortRedirect() + * and SetupProtoRedirect() from natd.c. + * + * Every setup_* function fills at least one redirect entry + * (struct cfg_redir) and zero or more server pool entry (struct cfg_spool) + * in buf. + * + * The format of data in buf is: + * + * + * cfg_nat cfg_redir cfg_spool ...... cfg_spool + * + * ------------------------------------- ------------ + * | | .....X ... | | | | ..... + * ------------------------------------- ...... ------------ + * ^ + * spool_cnt n=0 ...... n=(X-1) + * + * len points to the amount of available space in buf + * space counts the memory consumed by every function + * + * XXX - Every function get all the argv params so it + * has to check, in optional parameters, that the next + * args is a valid option for the redir entry and not + * another token. Only redir_port and redir_proto are + * affected by this. + */ + + static int + setup_redir_addr(char *spool_buf, int len, + int *_ac, char ***_av) + { + char **av = *_av, *sep; /* token separator */ + /* temporary buffer used to hold server pool ip's */ + char tmp_spool_buf[NAT_BUF_LEN]; + int ac = *_ac, i, space = 0, lsnat = 0; + int sof_redir = sizeof(struct cfg_redir); + struct cfg_redir *r; + + if (len >= sof_redir) { + r = (struct cfg_redir *)spool_buf; + /* skip cfg_redir at beginning of buf */ + spool_buf = &spool_buf[sof_redir]; + space = sof_redir; + len -= sof_redir; + } else + goto nospace; + r->mode = REDIR_ADDR; + /* extract local address */ + if (ac == 0) + errx(EX_DATAERR, "redir_addr: missing local address"); + sep = strchr(*av, ','); + if (sep) { /* LSNAT redirection syntax. */ + r->laddr.s_addr = INADDR_NONE; + /* preserve av, copy spool servers to tmp_spool_buf */ + strncpy(tmp_spool_buf, *av, strlen(*av)+1); + lsnat = 1; + } else + StrToAddr(*av, &r->laddr); + INC_ARGCV(); + + /* extract public address */ + if (ac == 0) + errx(EX_DATAERR, "redir_addr: missing public address"); + StrToAddr(*av, &r->paddr); + INC_ARGCV(); + + /* setup LSNAT server pool */ + if (sep) { + int sof_spool = sizeof(struct cfg_spool); + struct cfg_spool *tmp; + + sep = strtok(tmp_spool_buf, ","); + while (sep != NULL) { + tmp = (struct cfg_spool *)spool_buf; + if (len < sof_spool) + goto nospace; + len -= sof_spool; + space += sof_spool; + StrToAddr(sep, &tmp->addr); + tmp->port = ~0; + r->spool_cnt++; + /* point to the next possible cfg_spool */ + spool_buf = &spool_buf[sof_spool]; + sep = strtok(NULL, ","); + } + } + return(space); + nospace: + errx(EX_DATAERR, "redir_addr: buf is too small\n"); + } + + static int + setup_redir_port(char *spool_buf, int len, + int *_ac, char ***_av) + { + char **av = *_av, *sep, *protoName; + char tmp_spool_buf[NAT_BUF_LEN]; + int ac = *_ac, space = 0, lsnat = 0; + int sof_redir = sizeof(struct cfg_redir); + struct cfg_redir *r; + u_short numLocalPorts = 0; + port_range portRange; + + if (len >= sof_redir) { + r = (struct cfg_redir *)spool_buf; + /* skip cfg_redir at beginning of buf */ + spool_buf = &spool_buf[sof_redir]; + space = sof_redir; + len -= sof_redir; + } else + goto nospace; + r->mode = REDIR_PORT; + /* + * Extract protocol. + */ + if (ac == 0) + errx (EX_DATAERR, "redirect_port: missing protocol"); + r->proto = StrToProto(*av); + protoName = *av; + INC_ARGCV(); + + /* + * Extract local address. + */ + if (ac == 0) + errx (EX_DATAERR, "redirect_port: missing local address"); + + sep = strchr(*av, ','); + if (sep) { /* LSNAT redirection syntax. */ + r->laddr.s_addr = INADDR_NONE; + r->lport = ~0; + numLocalPorts = 1; + /* preserve av, copy spool servers to tmp_spool_buf */ + strncpy(tmp_spool_buf, *av, strlen(*av)+1); + lsnat = 1; + } else { + if ( StrToAddrAndPortRange (*av, &r->laddr, protoName, &portRange) != 0 ) + errx (EX_DATAERR, "redirect_port: invalid local port range"); + + r->lport = GETLOPORT(portRange); + numLocalPorts = GETNUMPORTS(portRange); + } + INC_ARGCV(); + + /* + * Extract public port and optionally address. + */ + if (ac == 0) + errx (EX_DATAERR, "redirect_port: missing public port"); + + sep = strchr (*av, ':'); + if (sep) { + if (StrToAddrAndPortRange (*av, &r->paddr, protoName, &portRange) != 0 ) + errx (EX_DATAERR, "redirect_port: invalid public port range"); + } else { + r->paddr.s_addr = INADDR_ANY; + if (StrToPortRange (*av, protoName, &portRange) != 0) + errx (EX_DATAERR, "redirect_port: invalid public port range"); + } + + r->pport = GETLOPORT(portRange); + r->pport_cnt = GETNUMPORTS(portRange); + INC_ARGCV(); + + /* + * Extract remote address and optionally port. + */ + /* + * isalpha(**av) => we've to check that next parameter is really an + * option for this redirect entry, else stop here processing arg[cv] + */ + if (ac != 0 && !isalpha(**av)) { + sep = strchr (*av, ':'); + if (sep) { + if (StrToAddrAndPortRange (*av, &r->raddr, protoName, &portRange) != 0) + errx (EX_DATAERR, "redirect_port: invalid remote port range"); + } else { + SETLOPORT(portRange, 0); + SETNUMPORTS(portRange, 1); + StrToAddr (*av, &r->raddr); + } + INC_ARGCV(); + } else { + SETLOPORT(portRange, 0); + SETNUMPORTS(portRange, 1); + r->raddr.s_addr = INADDR_ANY; + } + r->rport = GETLOPORT(portRange); + r->rport_cnt = GETNUMPORTS(portRange); + + /* + * Make sure port ranges match up, then add the redirect ports. + */ + if (numLocalPorts != r->pport_cnt) + errx(EX_DATAERR, "redirect_port: port ranges must be equal in size"); + + /* Remote port range is allowed to be '0' which means all ports. */ + if (r->rport_cnt != numLocalPorts && (r->rport_cnt != 1 || r->rport != 0)) + errx(EX_DATAERR, "redirect_port: remote port must be 0 or equal to local port range in size"); + + /* + * Setup LSNAT server pool. + */ + if (lsnat) { + int sof_spool = sizeof(struct cfg_spool); + struct cfg_spool *tmp; + + sep = strtok(tmp_spool_buf, ","); + while (sep != NULL) { + tmp = (struct cfg_spool *)spool_buf; + if (len < sof_spool) + goto nospace; + len -= sof_spool; + space += sof_spool; + if (StrToAddrAndPortRange(sep, &tmp->addr, protoName, &portRange) != 0) + errx(EX_DATAERR, "redirect_port: invalid local port range"); + if (GETNUMPORTS(portRange) != 1) + errx(EX_DATAERR, "redirect_port: local port must be single in this context"); + tmp->port = GETLOPORT(portRange); + r->spool_cnt++; + /* point to the next possible cfg_spool */ + spool_buf = &spool_buf[sof_spool]; + sep = strtok(NULL, ","); + } + } + return(space); + nospace: + errx(EX_DATAERR, "redir_port: buf is too small\n"); + } + + static int + setup_redir_proto(char *spool_buf, int len, + int *_ac, char ***_av) + { + char **av = *_av; + int ac = *_ac, i, space; + struct protoent *protoent; + int sof_redir = sizeof(struct cfg_redir); + struct cfg_redir *r; + + if (len >= sof_redir) { + r = (struct cfg_redir *)spool_buf; + /* skip cfg_redir at beginning of buf */ + spool_buf = &spool_buf[sof_redir]; + space = sof_redir; + len -= sof_redir; + } else + goto nospace; + r->mode = REDIR_PROTO; + /* + * Extract protocol. + */ + if (ac == 0) + errx(EX_DATAERR, "redirect_proto: missing protocol"); + + protoent = getprotobyname(*av); + if (protoent == NULL) + errx(EX_DATAERR, "redirect_proto: unknown protocol %s", *av); + else + r->proto = protoent->p_proto; + + INC_ARGCV(); + + /* + * Extract local address. + */ + if (ac == 0) + errx(EX_DATAERR, "redirect_proto: missing local address"); + else + StrToAddr(*av, &r->laddr); + + INC_ARGCV(); + + /* + * Extract optional public address. + */ + if (ac == 0) { + r->paddr.s_addr = INADDR_ANY; + r->raddr.s_addr = INADDR_ANY; + } else { + /* see above in setup_redir_port() */ + if (!isalpha(**av)) { + StrToAddr(*av, &r->paddr); + INC_ARGCV(); + + /* + * Extract optional remote address. + */ + /* see above in setup_redir_port() */ + if (ac!=0 && !isalpha(**av)) { + StrToAddr(*av, &r->raddr); + INC_ARGCV(); + } + } + } + return(space); + nospace: + errx(EX_DATAERR, "redir_proto: buf is too small\n"); + } + + static void + show_nat(int ac, char **av); + + static void + print_nat_config(char *buf) { + struct cfg_nat *n = (struct cfg_nat *)buf; + int i, cnt, flag = 1, off = sizeof(*n); + int sof_redir = sizeof(struct cfg_redir); + int sof_spool = sizeof(struct cfg_spool); + struct cfg_redir *t; + struct cfg_spool *s; + struct protoent *p; + + printf("ipfw nat %u config", n->id); + if (strlen(n->if_name) != 0) + printf(" if %s", n->if_name); + else if (n->ip.s_addr != 0) + printf(" ip %s", inet_ntoa(n->ip)); + while (n->mode != 0) { + if (n->mode & PKT_ALIAS_LOG) { + printf(" log"); + n->mode &= ~PKT_ALIAS_LOG; + } else if (n->mode & PKT_ALIAS_DENY_INCOMING) { + printf(" deny_in"); + n->mode &= ~PKT_ALIAS_DENY_INCOMING; + } else if (n->mode & PKT_ALIAS_SAME_PORTS) { + printf(" same_ports"); + n->mode &= ~PKT_ALIAS_SAME_PORTS; + } else if (n->mode & PKT_ALIAS_UNREGISTERED_ONLY) { + printf(" unreg_only"); + n->mode &= ~PKT_ALIAS_UNREGISTERED_ONLY; + } else if (n->mode & PKT_ALIAS_RESET_ON_ADDR_CHANGE) { + printf(" reset"); + n->mode &= ~PKT_ALIAS_RESET_ON_ADDR_CHANGE; + } else if (n->mode & PKT_ALIAS_REVERSE) { + printf(" reverse"); + n->mode &= ~PKT_ALIAS_REVERSE; + } else if (n->mode & PKT_ALIAS_PROXY_ONLY) { + printf(" proxy_only"); + n->mode &= ~PKT_ALIAS_PROXY_ONLY; + } + } + /* print all the redirect's data configuration */ + for (cnt=0; cnt < n->redir_cnt; cnt++) { + t = (struct cfg_redir *)&buf[off]; + off += sof_redir; + switch(t->mode) { + case REDIR_ADDR: + printf(" redir_addr"); + if (t->spool_cnt == 0) + printf(" %s", inet_ntoa(t->laddr)); + else + for (i=0; ispool_cnt; i++) { + s = (struct cfg_spool *)&buf[off]; + if (i) + printf(","); + else + printf(" "); + printf("%s", inet_ntoa(s->addr)); + off += sof_spool; + } + printf(" %s", inet_ntoa(t->paddr)); + break; + case REDIR_PORT: + p = getprotobynumber(t->proto); + printf(" redir_port %s ", p->p_name); + if (!t->spool_cnt) { + printf("%s:%u", inet_ntoa(t->laddr), t->lport); + if (t->pport_cnt > 1) + printf("-%u", t->lport+t->pport_cnt-1); + } else + for (i=0; ispool_cnt; i++) { + s = (struct cfg_spool *)&buf[off]; + if (i) + printf(","); + printf("%s:%u", inet_ntoa(s->addr), s->port); + off += sof_spool; + } + + printf(" "); + if (t->paddr.s_addr) + printf("%s:", inet_ntoa(t->paddr)); + printf("%u", t->pport); + if (!t->spool_cnt && t->pport_cnt>1) + printf("-%u", t->pport+t->pport_cnt-1); + + if (t->raddr.s_addr) { + printf(" %s", inet_ntoa(t->raddr)); + if (t->rport) { + printf(":%u", t->rport); + if (!t->spool_cnt && t->rport_cnt>1) + printf("-%u", t->rport+t->rport_cnt-1); + } + } + break; + case REDIR_PROTO: + p = getprotobynumber(t->proto); + printf(" redir_proto %s %s", p->p_name, + inet_ntoa(t->laddr)); + if (t->paddr.s_addr != 0) { + printf(" %s", inet_ntoa(t->paddr)); + if (t->raddr.s_addr) + printf(" %s", inet_ntoa(t->raddr)); + } + break; + default: + errx(EX_DATAERR, "unknown redir mode"); + break; + } + } + printf("\n"); + } + + static void + config_nat(int ac, char **av) + { + struct cfg_nat *n; /* nat instance configuration */ + struct in_addr ip; + int i, len = NAT_BUF_LEN; + /* offset in buf: save space for a n at the beginning */ + int off=sizeof(*n); + char *id, buf[NAT_BUF_LEN]; /* buffer for serialized data */ + + memset(buf, 0, sizeof(buf)); + n = (struct cfg_nat *)buf; + + av++; ac--; + /* Nat id */ + if (ac && isdigit(**av)) { + id = *av; + i = atoi(*av); av++; ac--; + n->id = i; + } else errx(EX_DATAERR, "missing nat id"); + if (ac == 0) errx(EX_DATAERR, "missing option"); + + while (ac > 0) { + int tok = match_token(nat_params, *av); + int sof_redir = sizeof(struct cfg_redir); + + ac--; av++; + + switch(tok) { + case TOK_IP: + if (ac == 0) errx(EX_DATAERR, "missing option"); + if (!inet_aton(av[0], &(n->ip))) + errx(EX_DATAERR, "bad ip address ``%s''", av[0]); + ac--; av++; + break; + + case TOK_IF: + set_addr_dynamic(av[0], n); + ac--; av++; + break; + + case TOK_LOG: + n->mode |= PKT_ALIAS_LOG; + break; + + case TOK_DENY_INC: + n->mode |= PKT_ALIAS_DENY_INCOMING; + break; + + case TOK_SAME_PORTS: + n->mode |= PKT_ALIAS_SAME_PORTS; + break; + + case TOK_UNREG_ONLY: + n->mode |= PKT_ALIAS_UNREGISTERED_ONLY; + break; + + case TOK_RESET_ADDR: + n->mode |= PKT_ALIAS_RESET_ON_ADDR_CHANGE; + break; + + case TOK_ALIAS_REV: + n->mode |= PKT_ALIAS_REVERSE; + break; + + case TOK_PROXY_ONLY: + n->mode |= PKT_ALIAS_PROXY_ONLY; + break; + + /* + * all the setup_redir_* functions work directly in the final + * buffer, see above for details + */ + case TOK_REDIR_ADDR: + case TOK_REDIR_PORT: + case TOK_REDIR_PROTO: + switch(tok) { + case TOK_REDIR_ADDR: + i = setup_redir_addr(&buf[off], len, &ac, &av); + break; + + case TOK_REDIR_PORT: + i = setup_redir_port(&buf[off], len, &ac, &av); + break; + + case TOK_REDIR_PROTO: + i = setup_redir_proto(&buf[off], len, &ac, &av); + break; + } + n->redir_cnt++; + off += i; + len -= i; + break; + + default: + errx(EX_DATAERR, "unrecognised option ``%s''", av[-1]); + } + } + + i = do_cmd(IP_FW_NAT_CFG, buf, off); + if (i) + err(1, "setsockopt(%s)", "IP_FW_NAT_CFG"); + + /* after every rule modification, we show the resultant rule */ + int _ac = 3; + char *_av[] = {"show", "config", id}; + show_nat(_ac, _av); + } + static void config_pipe(int ac, char **av) { *************** *** 3999,4004 **** --- 4793,4806 ---- ac++; av--; /* go back... */ break; + case TOK_NAT: + action->opcode = O_NAT; + action->len = F_INSN_SIZE(ipfw_insn_nat); + NEED1("missing nat number"); + action->arg1 = strtoul(*av, NULL, 10); + ac--; av++; + break; + default: errx(EX_DATAERR, "invalid action %s\n", av[-1]); } *************** *** 4942,4947 **** --- 5744,5811 ---- errx(EX_USAGE, "invalid table command %s", *av); } + static void + show_nat(int ac, char **av) { + struct cfg_nat *n; + struct cfg_redir *e; + int cmd, i, nbytes, do_cfg, do_rule = 0, frule, lrule, nalloc = 1024, + size = 0, loop, r; + u_int8_t *data = NULL, *p; + char **lav, *endptr; + + av++; ac--; + + /* parse parameters */ + for (cmd = IP_FW_NAT_GET_LOG, do_cfg = 0; ac != 0; ac--, av++) { + if (!strncmp(av[0], "config", strlen(av[0]))) { + cmd = IP_FW_NAT_GET_CONFIG, do_cfg = 1; continue; + } + /* convert command line rule # */ + frule = lrule = strtoul(av[0], &endptr, 10); + if (*endptr == '-') + lrule = strtoul(endptr+1, &endptr, 10); + if (lrule == 0) + err(EX_USAGE, "invalid rule number: %s", av[0]); + do_rule = 1; + } + + nbytes = nalloc; + while (nbytes >= nalloc) { + nalloc = nalloc * 2; + nbytes = nalloc; + if ((data = realloc(data, nbytes)) == NULL) + err(EX_OSERR, "realloc"); + if (do_cmd(cmd, data, (uintptr_t)&nbytes) < 0) + err(EX_OSERR, "getsockopt(IP_FW_GET_%s)", + (cmd == IP_FW_NAT_GET_LOG) ? "LOG" : "CONFIG"); + } + if (nbytes == 0) exit(0); + if (do_cfg) { + for (i = 0, loop = 1; loop; ) { + n = (struct cfg_nat *)&data[i]; + if (n->next == NULL) loop = 0; + if (do_rule) + if (!(frule <= n->id && lrule >= n->id)) continue; + print_nat_config(&data[i]); + i += sizeof(struct cfg_nat); + e = (struct cfg_redir *)&data[i]; + if (e->mode == REDIR_ADDR || e->mode == REDIR_PORT || + e->mode == REDIR_PROTO) + i += sizeof(struct cfg_redir) + e->spool_cnt * + sizeof(struct cfg_spool); + } + } else { + for (i = 0; 1; i += LIBALIAS_BUF_SIZE + sizeof(int)) { + p = &data[i]; + if (p == data + nbytes) break; + bcopy(p, &r, sizeof(int)); + if (do_rule) + if (!(frule <= r && lrule >= r)) continue; + printf("nat %u: %s\n", r, p+sizeof(int)); + } + } + } + /* * Called with the arguments (excluding program name). * Returns 0 if successful, 1 if empty command, errx() in case of errors. *************** *** 5130,5154 **** } /* ! * optional: pipe or queue */ do_pipe = 0; ! if (_substrcmp(*av, "pipe") == 0) do_pipe = 1; else if (_substrcmp(*av, "queue") == 0) do_pipe = 2; ! if (do_pipe) { ac--; av++; } NEED1("missing command"); /* ! * For pipes and queues we normally say 'pipe NN config' ! * but the code is easier to parse as 'pipe config NN' * so we swap the two arguments. */ ! if (do_pipe > 0 && ac > 1 && isdigit(*av[0])) { char *p = av[0]; av[0] = av[1]; --- 5994,6021 ---- } /* ! * optional: pipe, queue or nat */ + do_nat = 0; do_pipe = 0; ! if (!strncmp(*av, "nat", strlen(*av))) ! do_nat = 1; ! else if (!strncmp(*av, "pipe", strlen(*av))) do_pipe = 1; else if (_substrcmp(*av, "queue") == 0) do_pipe = 2; ! if (do_pipe || do_nat) { ac--; av++; } NEED1("missing command"); /* ! * For pipes, queues and nats we normally say 'nat|pipe NN config' ! * but the code is easier to parse as 'nat|pipe config NN' * so we swap the two arguments. */ ! if ((do_pipe || do_nat) && ac > 1 && isdigit(*av[0])) { char *p = av[0]; av[0] = av[1]; *************** *** 5157,5164 **** --- 6024,6035 ---- if (_substrcmp(*av, "add") == 0) add(ac, av); + else if (do_nat && _substrcmp(*av, "show") == 0) + show_nat(ac, av); else if (do_pipe && _substrcmp(*av, "config") == 0) config_pipe(ac, av); + else if (do_nat && _substrcmp(*av, "config") == 0) + config_nat(ac, av); else if (_substrcmp(*av, "delete") == 0) delete(ac, av); else if (_substrcmp(*av, "flush") == 0) diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sbin/natd/natd.c /home/flag/src/freebsd7/src/sbin/natd/natd.c *** /home/flag/src/freebsd7_vanilla/src/sbin/natd/natd.c Mon May 2 12:13:38 2005 --- /home/flag/src/freebsd7/src/sbin/natd/natd.c Sun Jun 11 18:57:26 2006 *************** *** 349,354 **** --- 349,358 ---- siginterrupt(SIGHUP, 1); signal (SIGTERM, InitiateShutdown); signal (SIGHUP, RefreshAddr); + + /* Load all libalias modules */ + LibAliasRefreshModules(); + /* * Set alias address if it has been given. */ *************** *** 970,976 **** static void RefreshAddr (int sig __unused) { ! if (mip->ifName) mip->assignAliasAddr = 1; } --- 974,981 ---- static void RefreshAddr (int sig __unused) { ! LibAliasRefreshModules(); ! if (mip && mip->ifName) mip->assignAliasAddr = 1; } diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/conf/files /home/flag/src/freebsd7/src/sys/conf/files *** /home/flag/src/freebsd7_vanilla/src/sys/conf/files Fri Jun 9 08:13:45 2006 --- /home/flag/src/freebsd7/src/sys/conf/files Sun Jun 11 18:57:26 2006 *************** *** 1702,1717 **** netinet/tcp_usrreq.c optional inet netinet/udp_usrreq.c optional inet netinet/libalias/alias.c optional libalias - netinet/libalias/alias_cuseeme.c optional libalias netinet/libalias/alias_db.c optional libalias - netinet/libalias/alias_ftp.c optional libalias - netinet/libalias/alias_irc.c optional libalias - netinet/libalias/alias_nbt.c optional libalias - netinet/libalias/alias_pptp.c optional libalias netinet/libalias/alias_proxy.c optional libalias - netinet/libalias/alias_skinny.c optional libalias - netinet/libalias/alias_smedia.c optional libalias netinet/libalias/alias_util.c optional libalias netinet6/ah_aesxcbcmac.c optional ipsec netinet6/ah_core.c optional ipsec netinet6/ah_input.c optional ipsec --- 1702,1712 ---- netinet/tcp_usrreq.c optional inet netinet/udp_usrreq.c optional inet netinet/libalias/alias.c optional libalias netinet/libalias/alias_db.c optional libalias netinet/libalias/alias_proxy.c optional libalias netinet/libalias/alias_util.c optional libalias + netinet/libalias/alias_old.c optional libalias + netinet/libalias/alias_mod.c optional libalias netinet6/ah_aesxcbcmac.c optional ipsec netinet6/ah_core.c optional ipsec netinet6/ah_input.c optional ipsec diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/Makefile /home/flag/src/freebsd7/src/sys/modules/libalias/Makefile *** /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/Makefile Mon Jun 20 10:33:29 2005 --- /home/flag/src/freebsd7/src/sys/modules/libalias/Makefile Sun Jun 11 18:57:26 2006 *************** *** 1,33 **** ! # $FreeBSD: src/sys/modules/libalias/Makefile,v 1.2 2005/06/20 08:33:29 glebius Exp $ ! .PATH: ${.CURDIR}/../../netinet/libalias ! ! KMOD= libalias ! SRCS= alias.c alias_cuseeme.c alias_db.c alias_ftp.c alias_irc.c \ ! alias_nbt.c alias_pptp.c alias_proxy.c alias_skinny.c alias_smedia.c \ ! alias_util.c ! INCS= alias.h ! ! EXPORT_SYMS= LibAliasInit \ ! LibAliasUninit \ ! LibAliasSetAddress \ ! LibAliasSetMode \ ! LibAliasSkinnyPort \ ! LibAliasIn \ ! LibAliasOut \ ! LibAliasRedirectPort \ ! LibAliasRedirectAddr \ ! LibAliasAddServer \ ! LibAliasRedirectDynamic \ ! LibAliasRedirectDelete \ ! LibAliasProxyRule \ ! LibAliasRedirectProto \ ! LibAliasSaveFragment \ ! LibAliasGetFragment \ ! LibAliasFragmentIn \ ! LibAliasSetTarget \ ! LibAliasCheckNewLink \ ! LibAliasInternetChecksum \ ! LibAliasUnaliasOut ! ! .include --- 1,11 ---- ! SUBDIR= kld-cuseeme \ ! kld-dummy \ ! kld-ftp \ ! kld-irc \ ! kld-libalias \ ! kld-nbt \ ! kld-pptp \ ! kld-skinny \ ! kld-smedia ! .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-cuseeme/Makefile /home/flag/src/freebsd7/src/sys/modules/libalias/kld-cuseeme/Makefile *** /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-cuseeme/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/modules/libalias/kld-cuseeme/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,9 ---- + .PATH: ${.CURDIR}/../../../netinet/libalias + + KMOD= alias_cuseeme + SRCS= alias_cuseeme.c + INCS= alias.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-dummy/Makefile /home/flag/src/freebsd7/src/sys/modules/libalias/kld-dummy/Makefile *** /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-dummy/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/modules/libalias/kld-dummy/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,9 ---- + .PATH: ${.CURDIR}/../../../netinet/libalias + + KMOD= alias_dummy + SRCS= alias_dummy.c + INCS= alias.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-ftp/Makefile /home/flag/src/freebsd7/src/sys/modules/libalias/kld-ftp/Makefile *** /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-ftp/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/modules/libalias/kld-ftp/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,9 ---- + .PATH: ${.CURDIR}/../../../netinet/libalias + + KMOD= alias_ftp + SRCS= alias_ftp.c + INCS= alias.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-irc/Makefile /home/flag/src/freebsd7/src/sys/modules/libalias/kld-irc/Makefile *** /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-irc/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/modules/libalias/kld-irc/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,9 ---- + .PATH: ${.CURDIR}/../../../netinet/libalias + + KMOD= alias_irc + SRCS= alias_irc.c + INCS= alias.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-libalias/Makefile /home/flag/src/freebsd7/src/sys/modules/libalias/kld-libalias/Makefile *** /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-libalias/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/modules/libalias/kld-libalias/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,33 ---- + .PATH: ${.CURDIR}/../../../netinet/libalias + + KMOD= libalias + SRCS= alias.c alias_db.c alias_proxy.c alias_util.c alias_old.c alias_mod.c + INCS= alias.h + + EXPORT_SYMS= LibAliasInit \ + LibAliasUninit \ + LibAliasSetAddress \ + LibAliasSetMode \ + LibAliasSkinnyPort \ + LibAliasIn \ + LibAliasOut \ + LibAliasRedirectPort \ + LibAliasRedirectAddr \ + LibAliasAddServer \ + LibAliasRedirectDynamic \ + LibAliasRedirectDelete \ + LibAliasProxyRule \ + LibAliasRedirectProto \ + LibAliasSaveFragment \ + LibAliasGetFragment \ + LibAliasFragmentIn \ + LibAliasSetTarget \ + LibAliasCheckNewLink \ + LibAliasInternetChecksum \ + LibAliasUnaliasOut \ + attach_handler \ + detach_handler + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-nbt/Makefile /home/flag/src/freebsd7/src/sys/modules/libalias/kld-nbt/Makefile *** /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-nbt/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/modules/libalias/kld-nbt/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,9 ---- + .PATH: ${.CURDIR}/../../../netinet/libalias + + KMOD= alias_nbt + SRCS= alias_nbt.c + INCS= alias.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-pptp/Makefile /home/flag/src/freebsd7/src/sys/modules/libalias/kld-pptp/Makefile *** /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-pptp/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/modules/libalias/kld-pptp/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,9 ---- + .PATH: ${.CURDIR}/../../../netinet/libalias + + KMOD= alias_pptp + SRCS= alias_pptp.c + INCS= alias.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-skinny/Makefile /home/flag/src/freebsd7/src/sys/modules/libalias/kld-skinny/Makefile *** /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-skinny/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/modules/libalias/kld-skinny/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,9 ---- + .PATH: ${.CURDIR}/../../../netinet/libalias + + KMOD= alias_skinny + SRCS= alias_skinny.c + INCS= alias.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-smedia/Makefile /home/flag/src/freebsd7/src/sys/modules/libalias/kld-smedia/Makefile *** /home/flag/src/freebsd7_vanilla/src/sys/modules/libalias/kld-smedia/Makefile Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/modules/libalias/kld-smedia/Makefile Sun Jun 11 18:57:26 2006 *************** *** 0 **** --- 1,9 ---- + .PATH: ${.CURDIR}/../../../netinet/libalias + + KMOD= alias_smedia + SRCS= alias_smedia.c + INCS= alias.h + + CFLAGS+= -Werror + + .include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/in.h /home/flag/src/freebsd7/src/sys/netinet/in.h *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/in.h Sun May 14 16:22:49 2006 --- /home/flag/src/freebsd7/src/sys/netinet/in.h Sun Jun 11 18:57:26 2006 *************** *** 410,415 **** --- 410,420 ---- #define IP_FW_GET 54 /* get entire firewall rule chain */ #define IP_FW_RESETLOG 55 /* reset logging counters */ + #define IP_FW_NAT_CFG 56 /* add/config a nat rule */ + #define IP_FW_NAT_DEL 57 /* delete a nat rule */ + #define IP_FW_NAT_GET_CONFIG 58 /* get configuration of a nat rule */ + #define IP_FW_NAT_GET_LOG 59 /* get log of a nat rule */ + #define IP_DUMMYNET_CONFIGURE 60 /* add/configure a dummynet pipe */ #define IP_DUMMYNET_DEL 61 /* delete a dummynet pipe from chain */ #define IP_DUMMYNET_FLUSH 62 /* flush dummynet */ diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/ip_fw.h /home/flag/src/freebsd7/src/sys/netinet/ip_fw.h *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/ip_fw.h Wed May 24 15:09:55 2006 --- /home/flag/src/freebsd7/src/sys/netinet/ip_fw.h Sun Jun 11 18:57:26 2006 *************** *** 124,129 **** --- 124,130 ---- O_TEE, /* arg1=port number */ O_FORWARD_IP, /* fwd sockaddr */ O_FORWARD_MAC, /* fwd mac */ + O_NAT, /* nope */ /* * More opcodes. *************** *** 307,312 **** --- 308,372 ---- u_int32_t log_left; /* how many left to log */ } ipfw_insn_log; + /* + * "syntactic sugar for compiler": used in HOOK_REDIR|SPOOL in ip_fw2.c. + * + * WARNING: don't move the field "next" in the subsequent cfg_* structs, + * it has to be the first. + */ + struct _chain { + struct _chain *next; + }; + + /* Server pool support (LSNAT) */ + struct cfg_spool { + struct cfg_spool *next; /* chain of spool instances */ + struct in_addr addr; + u_short port; + }; + + /* Redirect modes id */ + #define REDIR_ADDR 0x01 + #define REDIR_PORT 0x02 + #define REDIR_PROTO 0x04 + + /* Nat redirect configuration */ + struct cfg_redir { + struct cfg_redir *next; /* chain of redir instances */ + u_int16_t mode; /* type of redirect mode */ + struct in_addr laddr; /* local ip address */ + struct in_addr paddr; /* public ip address */ + struct in_addr raddr; /* remote ip address */ + u_short lport; /* local port */ + u_short pport; /* public port */ + u_short rport; /* remote port */ + u_short pport_cnt; /* number of public ports */ + u_short rport_cnt; /* number of remote ports */ + int proto; /* protocol: tcp/udp */ + struct alias_link **alink; + u_int16_t spool_cnt; /* number of entry in spool chain */ + struct cfg_spool *spool_chain; /* chain of spool instances */ + }; + + #define NAT_BUF_LEN 1024 + /* Nat configuration data struct */ + struct cfg_nat { + struct cfg_nat *next; /* chain of nat instances */ + int id; /* nat id */ + struct in_addr ip; /* nat ip address */ + char if_name[IF_NAMESIZE]; /* interface name */ + int mode; /* aliasing mode */ + struct libalias *lib; /* libalias instance */ + int redir_cnt; /* number of entry in spool chain */ + struct cfg_redir *redir_chain; /* chain of redir instances */ + }; + + /* Nat command */ + typedef struct _ipfw_insn_nat { + ipfw_insn o; + struct cfg_nat *nat; + } ipfw_insn_nat; + /* Apply ipv6 mask on ipv6 addr */ #define APPLY_MASK(addr,mask) \ (addr)->__u6_addr.__u6_addr32[0] &= (mask)->__u6_addr.__u6_addr32[0]; \ *************** *** 483,488 **** --- 543,549 ---- IP_FW_DUMMYNET, IP_FW_NETGRAPH, IP_FW_NGTEE, + IP_FW_NAT, }; /* flags for divert mtag */ diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/ip_fw2.c /home/flag/src/freebsd7/src/sys/netinet/ip_fw2.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/ip_fw2.c Thu Jun 8 13:27:45 2006 --- /home/flag/src/freebsd7/src/sys/netinet/ip_fw2.c Sun Jun 11 18:57:26 2006 *************** *** 46,51 **** --- 46,52 ---- #include #include #include + #include #include #include #include *************** *** 55,60 **** --- 56,62 ---- #include #include #include + #include #include #include #include *************** *** 78,84 **** #include #include #include ! #include #include --- 80,87 ---- #include #include #include ! #include ! #include #include #include *************** *** 296,301 **** --- 299,360 ---- #endif /* INET6 */ #endif /* SYSCTL_NODE */ + MODULE_DEPEND(ipfw, libalias, 1, 1, 1); + + struct _nat_chain { + struct cfg_nat *chain; + struct mtx mtx; /* lock guarding rule list */ + int busy_count; /* busy count for rw locks */ + int want_write; + struct cv cv; + } nat_chain; + + #define NAT_LOCK_INIT(_chain) \ + mtx_init(&(_chain)->mtx, "NAT instances", NULL, \ + MTX_DEF | MTX_RECURSE) + #define NAT_LOCK_DESTROY(_chain) mtx_destroy(&(_chain)->mtx) + #define NAT_WLOCK_ASSERT(_chain) do { \ + mtx_assert(&(_chain)->mtx, MA_OWNED); \ + NET_ASSERT_GIANT(); \ + } while (0) + + static __inline void + NAT_RLOCK(struct _nat_chain *chain) + { + mtx_lock(&chain->mtx); + chain->busy_count++; + mtx_unlock(&chain->mtx); + } + + static __inline void + NAT_RUNLOCK(struct _nat_chain *chain) + { + mtx_lock(&chain->mtx); + chain->busy_count--; + if (chain->busy_count == 0 && chain->want_write) + cv_signal(&chain->cv); + mtx_unlock(&chain->mtx); + } + + static __inline void + NAT_WLOCK(struct _nat_chain *chain) + { + mtx_lock(&chain->mtx); + chain->want_write++; + while (chain->busy_count > 0) + cv_wait(&chain->cv, &chain->mtx); + } + + static __inline void + NAT_WUNLOCK(struct _nat_chain *chain) + { + chain->want_write--; + cv_signal(&chain->cv); + mtx_unlock(&chain->mtx); + } + + static eventhandler_tag ifaddr_event_tag; + static int fw_deny_unknown_exthdrs = 1; *************** *** 853,858 **** --- 912,920 ---- snprintf(SNPARGS(action2, 0), "Ngtee %d", cmd->arg1); break; + case O_NAT: + action = "Nat"; + break; default: action = "UNKNOWN"; break; *************** *** 1964,1969 **** --- 2026,2294 ---- return match; } + /* FIX for 5.x and 4.x branch: m_move_pkthdr is not mbuf_cluster safe there */ + #if __FreeBSD_version > 600000 + static void + mym_move_pkthdr(struct mbuf *to, struct mbuf *from) { + m_move_pkthdr(to, from); + } + #else + /* + * "Move" mbuf pkthdr from "from" to "to". + * "from" must have M_PKTHDR set, and "to" must be empty. + */ + static void + mym_move_pkthdr(struct mbuf *to, struct mbuf *from) + { + + #ifdef MAC + /* + * XXXMAC: It could be this should also occur for non-MAC? + */ + if (to->m_flags & M_PKTHDR) + m_tag_delete_chain(to, NULL); + #endif + to->m_flags = (from->m_flags & M_COPYFLAGS) | (to->m_flags & M_EXT); + if ((to->m_flags & M_EXT) == 0) + to->m_data = to->m_pktdat; + to->m_pkthdr = from->m_pkthdr; /* especially tags */ + SLIST_INIT(&from->m_pkthdr.tags); /* purge tags from src */ + from->m_flags &= ~M_PKTHDR; + } + #endif + + /* + * m_megapullup() function is a big hack. (from ng_nat.c) + * + * It allocates an mbuf with cluster and copies the whole + * chain into cluster, so that it is all contigous and the + * whole packet can be accessed via char pointer. + * This is required, because libalias doesn't have idea + * about mbufs. + * + * On success, m_megapullup returns an mbuf with cluster + * containing the input packet, on failure NULL. + * In both cases, the input packet is consumed. + */ + static struct mbuf * + m_megapullup(struct mbuf *m, int len) { + struct mbuf *mcl; + caddr_t cp; + + if (len > MCLBYTES) + goto bad; + + if ((mcl = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR)) == NULL) + goto bad; + + cp = mtod(mcl, caddr_t); + m_copydata(m, 0, len, cp); + mym_move_pkthdr(mcl, m); + mcl->m_len = mcl->m_pkthdr.len; + m_freem(m); + + return (mcl); + bad: + m_freem(m); + return (NULL); + } + + static void + flush_nat_ptrs(const int i) { + struct ip_fw *rule; + + IPFW_WLOCK(&layer3_chain); + for (rule = layer3_chain.rules; rule; rule = rule->next) { + ipfw_insn_nat *cmd = (ipfw_insn_nat *)ACTION_PTR(rule); + + if (cmd->o.opcode != O_NAT) + continue; + if (cmd->nat != NULL && cmd->nat->id == i) + cmd->nat = NULL; + } + IPFW_WUNLOCK(&layer3_chain); + } + + static struct cfg_nat * + lookup_nat(const int i) { + struct cfg_nat *ptr; + + for (ptr = nat_chain.chain; ptr != NULL; ptr = ptr->next) + if (ptr->id == i) return(ptr); + return(NULL); + } + + /* attach p to b chain */ + static void + hook_entry(struct _chain **b, struct _chain *p) { + + /* XXX better to make an in-order addition... */ + for(; *b != NULL; b = &((*b)->next)) + ; + *b = p; + } + + /* remove p from b chain */ + static void + unhook_entry(struct _chain **b, struct _chain *p) { + + NAT_WLOCK_ASSERT(&nat_chain); + for(; *b != p; b = &((*b)->next)) + ; + *b = p->next; + } + + #define HOOK_NAT(b, p) do { \ + NAT_WLOCK_ASSERT(&nat_chain); \ + hook_entry((struct _chain **)b, (struct _chain *)p); \ + } while (0) + + #define UNHOOK_NAT(b, p) do { \ + NAT_WLOCK_ASSERT(&nat_chain); \ + unhook_entry((struct _chain **)b, (struct _chain *)p); \ + } while (0) + + #define HOOK_REDIR(b, p) do { \ + hook_entry((struct _chain **)b, (struct _chain *)p); \ + } while (0) + + #define HOOK_SPOOL(b, p) do { \ + hook_entry((struct _chain **)b, (struct _chain *)p); \ + } while (0) + + static void + del_redir_spool_cfg(struct cfg_nat *n, struct cfg_redir *r) { + struct cfg_redir *tmp_r; + struct cfg_spool *tmp_s; + int i, num; + + while(r) { + num = 1; /* number of alias_link to delete */ + switch(r->mode) { + case REDIR_PORT: + num = r->pport_cnt; + case REDIR_ADDR: + case REDIR_PROTO: + /* delete all libalias redirect entry */ + for (i = 0; i < num; i++) + LibAliasRedirectDelete(n->lib, + r->alink[i]); + /* del spool cfg if any */ + while(r->spool_chain) { + tmp_s = r->spool_chain->next; + free(r->spool_chain, M_IPFW); + r->spool_chain = tmp_s; + } + tmp_r = r->next; + free(r->alink, M_IPFW); + free(r, M_IPFW); + r = tmp_r; + break; + default: + printf("unknown redirect mode: %u\n", r->mode); + /* XXX - panic?!?!? */ + break; + } + } + n->redir_chain = NULL; + } + + static int + add_redir_spool_cfg(char *buf, struct cfg_nat *ptr) { + int sof_alinkp = sizeof(struct alias_link *); + int sof_redir = sizeof(struct cfg_redir); + int sof_spool = sizeof(struct cfg_spool); + struct cfg_redir *r, *ser_r; + struct cfg_spool *s, *ser_s; + int cnt, off, i; + + for(cnt=0, off = 0; cntredir_cnt; cnt++) { + ser_r = (struct cfg_redir *)&buf[off]; + r = malloc(sof_redir, M_IPFW, M_NOWAIT | M_ZERO); + if (r == NULL) { + /* try to recover: + * set the actual number of redir entries + * that were hooked succesfully + */ + ptr->redir_cnt = cnt; + del_redir_spool_cfg(ptr, ptr->redir_chain); + // XXX - NAT_WUNLOCK... + return (ENOSPC); + } + memcpy(r, ser_r, sof_redir); + off += sof_redir; + r->alink = malloc(sof_alinkp*r->pport_cnt, + M_IPFW, M_NOWAIT | M_ZERO); + if (r->alink == NULL) { + r->pport_cnt = 0; + del_redir_spool_cfg(ptr, ptr->redir_chain); + // XXX - NAT_WUNLOCK... + return (ENOSPC); + } + switch(r->mode) { + case REDIR_ADDR: + { + r->alink[0] = LibAliasRedirectAddr(ptr->lib, + r->laddr, + r->paddr); + } + break; + case REDIR_PORT: + for (i = 0 ; i < r->pport_cnt; i++) { + /* If remotePort is all ports, set it to 0. */ + u_short remotePortCopy = r->rport + i; + if (r->rport_cnt == 1 && r->rport == 0) + remotePortCopy = 0; + r->alink[i] = LibAliasRedirectPort (ptr->lib, r->laddr, + htons(r->lport + i), + r->raddr, + htons(remotePortCopy), + r->paddr, + htons(r->pport + i), + r->proto); + if (r->alink[i] == NULL) { + r->alink[0] = NULL; + break; + } + } + break; + case REDIR_PROTO: + r->alink[0] = LibAliasRedirectProto(ptr->lib, + r->laddr, + r->raddr, + r->paddr, + r->proto); + break; + default: + printf("unknown redirect mode: %u\n", r->mode); + break; + } + if (r->alink[0] == NULL) { /* panic?!?!? */ + free(r->alink, M_IPFW); + printf("previous LibAliasRedirect* returned NULL!!!\n"); + } else /* handles LSNAT */ + for (i=0; ispool_cnt; i++) { + ser_s = (struct cfg_spool *)&buf[off]; + s = malloc(sof_redir, M_IPFW, M_NOWAIT | M_ZERO); + if (s == NULL) { + r->spool_cnt = i; + del_redir_spool_cfg(ptr, r); + return (ENOSPC); + } + memcpy(s, ser_s, sof_spool); + LibAliasAddServer(ptr->lib, r->alink[0], // XXX - what about RedirectPort with many alink? + s->addr, + htons(s->port)); + off += sof_spool; + /* hook spool entry */ + HOOK_SPOOL(&r->spool_chain, s); + } + /* and finally hook this redir entry */ + HOOK_REDIR(&ptr->redir_chain, r); + } + return(1); + } + /* * The main check routine for the firewall. * *************** *** 3138,3143 **** --- 3463,3625 ---- IP_FW_NETGRAPH : IP_FW_NGTEE; goto done; + case O_NAT: { + struct cfg_nat *t; + struct mbuf *mcl; + /* XXX - libalias duct tape */ + int ldt = 0; + char *c; + + args->rule = f; /* report matching rule */ + retval = 0; + t = ((ipfw_insn_nat *)cmd)->nat; + if (t == NULL) { + NAT_RLOCK(&nat_chain); + t = lookup_nat(cmd->arg1); + if (t == NULL) { + retval = IP_FW_DENY; + goto done; + } else ((ipfw_insn_nat *)cmd)->nat = t; + } + if ((mcl = m_megapullup(m, m->m_pkthdr.len)) == NULL) + goto badnat; + ip = mtod(mcl, struct ip *); + /* + * XXX - workaround for host-byte-order 4.x BSD well_known_bug: + * due to 4.x BSD legacy, some fields in layer-3 packet COULD be + * in host byte order instead of network byte order, so we have + * to manually swap it before passing mbuf to libalias... + */ + if (args->eh == NULL) { /* host byte order */ + ip->ip_len = htons(ip->ip_len); + ip->ip_off = htons(ip->ip_off); + } + + /* + * XXX - libalias checksum offload 'duct tape': + * + * locally generated packets have only pseudo-header + * checksum calculated and libalias will screw it[1], + * so mark them for later fix. + * Moreover there are cases when libalias modify tcp + * packet data[2], mark it for later fix too. + * + * [1] libalias was never meant to run in kernel, so + * it doesn't have any knowledge about checksum + * offloading, and it expects a packet with a full + * internet checksum. Unfortunately, packets + * generated locally will have just the pseudo + * header calculated, and when libalias tries to + * adjust the checksum it will actually screw it. + * + * [2] when libalias modify tcp's data content, + * full TCP checksum has to be recomputed: + * the problem is that libalias doesn't have any + * idea about checksum offloading + * To workaround this, we do not do checksumming + * in LibAlias, but only mark the packets in th_x2 + * field. If we receive a marked packet, we + * calculate correct checksum for it aware of + * offloading. + * Why such a terrible hack instead of + * recalculating checksum for each packet? + * Because the previous checksum was not checked! + * Recalculating checksums for EVERY packet will + * hide ALL transmission errors. Yes, marked packets + * still suffer from this problem. But, sigh, natd(8) + * has this problem, too. + * + * TODO: + * -make libalias mbuf aware (so it can handle + * delayed checksum) + * -maybe shrink the api? do we really need 23 + * functions? + */ + + if (mcl->m_pkthdr.rcvif == NULL && + mcl->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { + ldt = 1; + } + + c = mtod(mcl, char *); + if (oif == NULL) + retval = LibAliasIn(t->lib, c, MCLBYTES); + else + retval = LibAliasOut(t->lib, c, MCLBYTES); + if (retval != PKT_ALIAS_OK) { + /* XXX - should i add some logging ? */ + m_free(mcl); + badnat: + args->m = NULL; + retval = IP_FW_DENY; + goto done; + } + mcl->m_pkthdr.len = mcl->m_len = ntohs(ip->ip_len); + + /* + * XXX - libalias checksum offload + * 'duct tape' (see above) + */ + + if ((ip->ip_off & htons(IP_OFFMASK)) == 0 && + ip->ip_p == IPPROTO_TCP) { + struct tcphdr *th = (struct tcphdr *)(ip + 1); + + if (th->th_x2) + ldt = 1; + } + + if (ldt) { + struct tcphdr *th; + struct udphdr *uh; + u_short cksum; + + ip->ip_len = ntohs(ip->ip_len); + cksum = in_pseudo( + ip->ip_src.s_addr, + ip->ip_dst.s_addr, + htons(ip->ip_p + ip->ip_len - (ip->ip_hl << 2)) + ); + + switch(ip->ip_p) { + case IPPROTO_TCP: + th = (struct tcphdr *)(ip + 1); + /* maybe it was set in libalias... */ + th->th_x2 = 0; + th->th_sum = cksum; + mcl->m_pkthdr.csum_data = + offsetof(struct tcphdr, + th_sum); + break; + case IPPROTO_UDP: + uh = (struct udphdr *)(ip + 1); + uh->uh_sum = cksum; + mcl->m_pkthdr.csum_data = + offsetof(struct udphdr, + uh_sum); + break; + + } + /* no hw checksum offloading: do it by ourself */ + if ((mcl->m_pkthdr.csum_flags & CSUM_DELAY_DATA) == 0) { + in_delayed_cksum(mcl); + mcl->m_pkthdr.csum_flags &= ~CSUM_DELAY_DATA; + } + ip->ip_len = htons(ip->ip_len); + } + + /* XXX - swap again some fields... see above */ + if (args->eh == NULL) { /* host byte order */ + ip->ip_len = ntohs(ip->ip_len); + ip->ip_off = ntohs(ip->ip_off); + } + + args->m = mcl; + retval = IP_FW_NAT; + NAT_RUNLOCK(&nat_chain); + goto done; + } + default: panic("-- unknown opcode %d\n", cmd->opcode); } /* end of switch() on opcodes */ *************** *** 3707,3712 **** --- 4189,4198 ---- return EINVAL; else goto check_size; + case O_NAT: + if (cmdlen != F_INSN_SIZE(ipfw_insn_nat)) + goto bad_size; + goto check_action; case O_FORWARD_MAC: /* XXX not implemented yet */ case O_CHECK_STATE: case O_COUNT: *************** *** 3860,3865 **** --- 4346,4377 ---- } + static void + ifaddr_change(void *arg __unused, struct ifnet *ifp) { + struct cfg_nat *ptr; + struct ifaddr *ifa; + + NAT_WLOCK(&nat_chain); + /* find every nat entry...*/ + for (ptr = nat_chain.chain; ptr; ptr = ptr->next) { + /* ...using nic 'ifp->if_xname' as dynamic alias address */ + if (strncmp(ptr->if_name, ifp->if_xname, IF_NAMESIZE) == 0) { + mtx_lock(&ifp->if_addr_mtx); + TAILQ_FOREACH(ifa, &ifp->if_addrlist, ifa_list) { + if (ifa->ifa_addr == NULL) + continue; + if (ifa->ifa_addr->sa_family != AF_INET) + continue; + ptr->ip = ((struct sockaddr_in *) + (ifa->ifa_addr))->sin_addr; + LibAliasSetAddress(ptr->lib, ptr->ip); + } + mtx_unlock(&ifp->if_addr_mtx); + } + } + NAT_WUNLOCK(&nat_chain); + } + /** * {set|get}sockopt parser. */ *************** *** 4085,4090 **** --- 4597,4750 ---- } break; + case IP_FW_NAT_CFG: + { + struct cfg_nat *ptr, *ser_n; + char *buf; + int err=0; + + buf = malloc(NAT_BUF_LEN, M_IPFW, M_NOWAIT | M_ZERO); + if (buf == NULL) + return (ENOSPC); + + error = sooptcopyin(sopt, buf, NAT_BUF_LEN, sizeof(struct cfg_nat)); + ser_n = (struct cfg_nat *)buf; + + /* FIND/CREATE NAT RULE */ + NAT_WLOCK(&nat_chain); + ptr = lookup_nat(ser_n->id); + if (ptr == NULL) { /* new rule: allocate and init new instance */ + ptr = malloc(sizeof(struct cfg_nat), M_IPFW, M_NOWAIT | M_ZERO); + if (ptr == NULL) { + free(buf, M_IPFW); + NAT_WUNLOCK(&nat_chain); + return (ENOSPC); + } + ptr->lib = LibAliasInit(NULL); + if (ptr->lib == NULL) { + free(ptr, M_IPFW); + free(buf, M_IPFW); + NAT_WUNLOCK(&nat_chain); + return(EINVAL); + } + } else { /* entry already present: temporarly unhook it */ + UNHOOK_NAT(&nat_chain.chain, ptr); + flush_nat_ptrs(ser_n->id); + } + NAT_WUNLOCK(&nat_chain); + + /* BASIC NAT CONFIGURATION */ + ptr->id = ser_n->id; + /* + * XXX - what if this rule doesn't nat any ip and just redirect? + * do we set aliasaddress to 0.0.0.0? is it correct? + */ + ptr->ip = ser_n->ip; + ptr->redir_cnt = ser_n->redir_cnt; + ptr->mode = ser_n->mode; + LibAliasSetMode(ptr->lib, ser_n->mode, ser_n->mode); + LibAliasSetAddress(ptr->lib, ptr->ip); + memcpy(ptr->if_name, ser_n->if_name, IF_NAMESIZE); + + /* REDIR AND LSNAT CONFIGURATION */ + del_redir_spool_cfg(ptr, ptr->redir_chain); /* delete old cfgs */ + err = add_redir_spool_cfg(&buf[(sizeof(struct cfg_nat))], + ptr); /* add new entries */ + free(buf, M_IPFW); + if (err == 1) { + NAT_WLOCK(&nat_chain); + HOOK_NAT(&nat_chain.chain, ptr); + NAT_WUNLOCK(&nat_chain); + } else /* something bad happened, redir cfg not added */ + return(EINVAL); + } + break; + + case IP_FW_NAT_DEL: + { + struct cfg_nat *ptr; + int i; + + error = sooptcopyin(sopt, &i, sizeof i, sizeof i); + NAT_WLOCK(&nat_chain); + ptr = lookup_nat(i); + if (ptr == NULL) { + error = EINVAL; + NAT_WUNLOCK(&nat_chain); + break; + } + UNHOOK_NAT(&nat_chain.chain, ptr); + NAT_WUNLOCK(&nat_chain); + flush_nat_ptrs(i); + del_redir_spool_cfg(ptr, ptr->redir_chain); + LibAliasUninit(ptr->lib); + free(ptr, M_IPFW); + } + break; + + case IP_FW_NAT_GET_CONFIG: + { + u_int8_t *data; + struct cfg_nat *n; + struct cfg_redir *r; + struct cfg_spool *s; + int sof_nat = sizeof(struct cfg_nat); + int sof_redir = sizeof(struct cfg_redir); + int sof_spool = sizeof(struct cfg_spool); + int off = 0; + + data = malloc(NAT_BUF_LEN, M_IPFW, M_NOWAIT | M_ZERO); + if (data == NULL) + return (ENOSPC); + NAT_RLOCK(&nat_chain); + /* serialize all the data */ + for (n = nat_chain.chain; (n && (off + sof_nat < NAT_BUF_LEN)); + n = n->next) { + bcopy(n, &data[off], sof_nat); + off += sof_nat; + for (r = n->redir_chain; (r && (off + sof_redir < NAT_BUF_LEN)); + r = r->next) { + bcopy(r, &data[off], sof_redir); + off += sof_redir; + for (s = r->spool_chain; (s && (off + sof_spool < NAT_BUF_LEN)); + s = s->next) { + bcopy(s, &data[off], sof_spool); + off += sof_spool; + } + } + } + NAT_RUNLOCK(&nat_chain); + + error = sooptcopyout(sopt, data, NAT_BUF_LEN); + free(data, M_IPFW); + } + break; + + case IP_FW_NAT_GET_LOG: + { + u_int8_t *data = NULL; + struct cfg_nat *ptr; + int sof = LIBALIAS_BUF_SIZE; + int i, size, cnt = 0; + + NAT_RLOCK(&nat_chain); + for (ptr = nat_chain.chain, size = i = 0; ptr; ptr = ptr->next) { + if (ptr->lib->logDesc == NULL) continue; + cnt++; + size = cnt * (sof + sizeof(int)); + data = realloc(data, size, M_IPFW, M_NOWAIT | M_ZERO); + if (data == NULL) return (ENOSPC); + bcopy(&ptr->id, &data[i], sizeof(int)); + i += sizeof(int); + bcopy(ptr->lib->logDesc, &data[i], sof); + i += sof; + } + NAT_RUNLOCK(&nat_chain); + error = sooptcopyout(sopt, data, size); + free(data, M_IPFW); + } + break; + default: printf("ipfw: ipfw_ctl invalid option %d\n", sopt->sopt_name); error = EINVAL; *************** *** 4256,4263 **** } ip_fw_ctl_ptr = ipfw_ctl; ip_fw_chk_ptr = ipfw_chk; ! callout_reset(&ipfw_timeout, hz, ipfw_tick, NULL); ! return (0); } --- 4916,4928 ---- } ip_fw_ctl_ptr = ipfw_ctl; ip_fw_chk_ptr = ipfw_chk; ! callout_reset(&ipfw_timeout, hz, ipfw_tick, NULL); ! nat_chain.chain = NULL; ! nat_chain.busy_count = 0; ! nat_chain.want_write = 0; ! NAT_LOCK_INIT(&nat_chain); ! ifaddr_event_tag = EVENTHANDLER_REGISTER(ifaddr_event, ifaddr_change, ! NULL, EVENTHANDLER_PRI_ANY); return (0); } *************** *** 4265,4276 **** --- 4930,4952 ---- ipfw_destroy(void) { struct ip_fw *reap; + struct cfg_nat *ptr, *ptr_temp; ip_fw_chk_ptr = NULL; ip_fw_ctl_ptr = NULL; callout_drain(&ipfw_timeout); IPFW_WLOCK(&layer3_chain); flush_tables(&layer3_chain); + NAT_WLOCK(&nat_chain); + for (ptr = nat_chain.chain; ptr; ptr = ptr_temp) { + ptr_temp = ptr->next; + del_redir_spool_cfg(ptr, ptr->redir_chain); + LibAliasUninit(ptr->lib); + free(ptr, M_IPFW); + } + NAT_WUNLOCK(&nat_chain); + EVENTHANDLER_DEREGISTER(ifaddr_event, ifaddr_event_tag); + NAT_LOCK_DESTROY(&nat_chain); layer3_chain.reap = NULL; free_chain(&layer3_chain, 1 /* kill default rule */); reap = layer3_chain.reap, layer3_chain.reap = NULL; diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/ip_fw_pfil.c /home/flag/src/freebsd7/src/sys/netinet/ip_fw_pfil.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/ip_fw_pfil.c Fri May 12 06:41:27 2006 --- /home/flag/src/freebsd7/src/sys/netinet/ip_fw_pfil.c Sun Jun 11 18:57:26 2006 *************** *** 189,194 **** --- 189,197 ---- if (!NG_IPFW_LOADED) goto drop; return ng_ipfw_input_p(m0, NG_IPFW_IN, &args, 0); + + case IP_FW_NAT: + goto again; /* continue with packet */ default: KASSERT(0, ("%s: unknown retval", __func__)); *************** *** 315,320 **** --- 318,326 ---- goto drop; return ng_ipfw_input_p(m0, NG_IPFW_OUT, &args, 0); + case IP_FW_NAT: + goto again; /* continue with packet */ + default: KASSERT(0, ("%s: unknown retval", __func__)); } diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias.c Tue Jun 28 00:21:42 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias.c Sun Jun 11 18:57:26 2006 *************** *** 113,121 **** --- 113,128 ---- #ifdef _KERNEL #include + #include + #include + #include #else #include + #include #include + #include + #include + #include #endif #include *************** *** 128,149 **** #ifdef _KERNEL #include #include #else #include "alias.h" #include "alias_local.h" #endif - #define NETBIOS_NS_PORT_NUMBER 137 - #define NETBIOS_DGM_PORT_NUMBER 138 - #define FTP_CONTROL_PORT_NUMBER 21 - #define IRC_CONTROL_PORT_NUMBER_1 6667 - #define IRC_CONTROL_PORT_NUMBER_2 6668 - #define CUSEEME_PORT_NUMBER 7648 - #define RTSP_CONTROL_PORT_NUMBER_1 554 - #define RTSP_CONTROL_PORT_NUMBER_2 7070 - #define TFTP_PORT_NUMBER 69 - #define PPTP_CONTROL_PORT_NUMBER 1723 - static __inline int twowords(void *p) { --- 135,147 ---- #ifdef _KERNEL #include #include + #include #else #include "alias.h" #include "alias_local.h" + #include "alias_mod.h" #endif static __inline int twowords(void *p) { *************** *** 725,748 **** struct in_addr original_address; u_short alias_port; int accumulate; ! int r = 0; alias_address = GetAliasAddress(lnk); original_address = GetOriginalAddress(lnk); alias_port = ud->uh_dport; ud->uh_dport = GetOriginalPort(lnk); ! /* Special processing for IP encoding protocols */ ! if (ntohs(ud->uh_dport) == CUSEEME_PORT_NUMBER) ! AliasHandleCUSeeMeIn(la, pip, original_address); ! /* If NETBIOS Datagram, It should be alias address in UDP Data, too */ ! else if (ntohs(ud->uh_dport) == NETBIOS_DGM_PORT_NUMBER ! || ntohs(ud->uh_sport) == NETBIOS_DGM_PORT_NUMBER) ! r = AliasHandleUdpNbt(la, pip, lnk, &original_address, ud->uh_dport); ! else if (ntohs(ud->uh_dport) == NETBIOS_NS_PORT_NUMBER ! || ntohs(ud->uh_sport) == NETBIOS_NS_PORT_NUMBER) ! r = AliasHandleUdpNbtNS(la, pip, lnk, &alias_address, &alias_port, ! &original_address, &ud->uh_dport); /* If UDP checksum is not zero, then adjust since destination port */ /* is being unaliased and destination address is being altered. */ --- 723,748 ---- struct in_addr original_address; u_short alias_port; int accumulate; ! int r = 0, err; ! struct alias_data ad = { ! lnk, ! &original_address, ! &alias_address, ! &alias_port, ! &ud->uh_sport, ! &ud->uh_dport, ! 0 /* maxpacketsize */ ! }; alias_address = GetAliasAddress(lnk); original_address = GetOriginalAddress(lnk); alias_port = ud->uh_dport; ud->uh_dport = GetOriginalPort(lnk); ! /* walk out chain */ ! err = find_handler(IN, UDP, la, pip, &ad); ! if (err == EHDNOF) ! ; /* If UDP checksum is not zero, then adjust since destination port */ /* is being unaliased and destination address is being altered. */ *************** *** 774,779 **** --- 774,780 ---- { struct udphdr *ud; struct alias_link *lnk; + int err; /* Return if proxy-only mode is enabled */ if (la->packetAliasMode & PKT_ALIAS_PROXY_ONLY) *************** *** 787,815 **** if (lnk != NULL) { u_short alias_port; struct in_addr alias_address; alias_address = GetAliasAddress(lnk); alias_port = GetAliasPort(lnk); ! /* Special processing for IP encoding protocols */ ! if (ntohs(ud->uh_dport) == CUSEEME_PORT_NUMBER) ! AliasHandleCUSeeMeOut(la, pip, lnk); ! /* If NETBIOS Datagram, It should be alias address in UDP Data, too */ ! else if (ntohs(ud->uh_dport) == NETBIOS_DGM_PORT_NUMBER ! || ntohs(ud->uh_sport) == NETBIOS_DGM_PORT_NUMBER) ! AliasHandleUdpNbt(la, pip, lnk, &alias_address, alias_port); ! else if (ntohs(ud->uh_dport) == NETBIOS_NS_PORT_NUMBER ! || ntohs(ud->uh_sport) == NETBIOS_NS_PORT_NUMBER) ! AliasHandleUdpNbtNS(la, pip, lnk, &pip->ip_src, &ud->uh_sport, ! &alias_address, &alias_port); ! /* ! * We don't know in advance what TID the TFTP server will choose, ! * so we create a wilcard link (destination port is unspecified) ! * that will match any TID from a given destination. ! */ ! else if (ntohs(ud->uh_dport) == TFTP_PORT_NUMBER) ! FindRtspOut(la, pip->ip_src, pip->ip_dst, ! ud->uh_sport, alias_port, IPPROTO_UDP); /* If UDP checksum is not zero, adjust since source port is */ /* being aliased and source address is being altered */ --- 788,810 ---- if (lnk != NULL) { u_short alias_port; struct in_addr alias_address; + struct alias_data ad = { + lnk, + NULL, /* original address */ + &alias_address, + &alias_port, + &ud->uh_sport, + &ud->uh_dport, + 0 /* maxpacketsize */ + }; alias_address = GetAliasAddress(lnk); alias_port = GetAliasPort(lnk); ! /* walk out chain */ ! err = find_handler(OUT, UDP, la, pip, &ad); ! if (err == EHDNOF) ! ; /* If UDP checksum is not zero, adjust since source port is */ /* being aliased and source address is being altered */ *************** *** 855,869 **** struct in_addr proxy_address; u_short alias_port; u_short proxy_port; ! int accumulate; ! /* Special processing for IP encoding protocols */ ! if (ntohs(tc->th_dport) == PPTP_CONTROL_PORT_NUMBER ! || ntohs(tc->th_sport) == PPTP_CONTROL_PORT_NUMBER) ! AliasHandlePptpIn(la, pip, lnk); ! else if (la->skinnyPort != 0 && (ntohs(tc->th_dport) == la->skinnyPort ! || ntohs(tc->th_sport) == la->skinnyPort)) ! AliasHandleSkinny(la, pip, lnk); alias_address = GetAliasAddress(lnk); original_address = GetOriginalAddress(lnk); --- 850,878 ---- struct in_addr proxy_address; u_short alias_port; u_short proxy_port; ! int accumulate, err; ! /* ! * XXX - the init of MANY vars is a bit below, but ! * aliashandlepptpin seems to need the destination port ! * that came within the packet and not the original one ! * looks below [*] ! */ ! ! struct alias_data ad = { ! lnk, ! NULL, /* original address */ ! NULL, /* alias address */ ! NULL, /* alias port */ ! &tc->th_sport, ! &tc->th_dport, ! 0 /* maxpacketsize */ ! }; ! ! /* walk out chain */ ! err = find_handler(IN, TCP, la, pip, &ad); ! if (err == EHDNOF) ! ; alias_address = GetAliasAddress(lnk); original_address = GetOriginalAddress(lnk); *************** *** 872,877 **** --- 881,908 ---- tc->th_dport = GetOriginalPort(lnk); proxy_port = GetProxyPort(lnk); + /* + * XXX - [*] looks above, if anyone is going to add + * find_handler AFTER this aliashandlepptpin/point, please redo + * alias_data too. + * Uncommenting the piece here below should be enough. + */ + + /* struct alias_data ad = { */ + /* lnk, */ + /* &original_address, */ + /* &alias_address, */ + /* &alias_port, */ + /* &ud->uh_sport, */ + /* &ud->uh_dport, */ + /* 0 /\* maxpacketsize *\/ */ + /* }; */ + + /* /\* walk out chain *\/ */ + /* err = find_handler(la, pip, &ad); */ + /* if (err == EHDNOF) */ + /* printf("Protocol handler not found\n"); */ + /* Adjust TCP checksum since destination port is being unaliased */ /* and destination port is being altered. */ accumulate = alias_port; *************** *** 926,932 **** static int TcpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int create) { ! int proxy_type; u_short dest_port; u_short proxy_server_port; struct in_addr dest_address; --- 957,963 ---- static int TcpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int create) { ! int proxy_type, err; u_short dest_port; u_short proxy_server_port; struct in_addr dest_address; *************** *** 973,978 **** --- 1004,1018 ---- u_short alias_port; struct in_addr alias_address; int accumulate; + struct alias_data ad = { + lnk, + NULL, /* original address */ + &alias_address, + &alias_port, + &tc->th_sport, + &tc->th_dport, + maxpacketsize + }; /* Save original destination address, if this is a proxy packet. Also modify packet to include destination encoding. This may *************** *** 989,1013 **** /* Monitor TCP connection state */ TcpMonitorOut(pip, lnk); ! ! /* Special processing for IP encoding protocols */ ! if (ntohs(tc->th_dport) == FTP_CONTROL_PORT_NUMBER ! || ntohs(tc->th_sport) == FTP_CONTROL_PORT_NUMBER) ! AliasHandleFtpOut(la, pip, lnk, maxpacketsize); ! else if (ntohs(tc->th_dport) == IRC_CONTROL_PORT_NUMBER_1 ! || ntohs(tc->th_dport) == IRC_CONTROL_PORT_NUMBER_2) ! AliasHandleIrcOut(la, pip, lnk, maxpacketsize); ! else if (ntohs(tc->th_dport) == RTSP_CONTROL_PORT_NUMBER_1 ! || ntohs(tc->th_sport) == RTSP_CONTROL_PORT_NUMBER_1 ! || ntohs(tc->th_dport) == RTSP_CONTROL_PORT_NUMBER_2 ! || ntohs(tc->th_sport) == RTSP_CONTROL_PORT_NUMBER_2) ! AliasHandleRtspOut(la, pip, lnk, maxpacketsize); ! else if (ntohs(tc->th_dport) == PPTP_CONTROL_PORT_NUMBER ! || ntohs(tc->th_sport) == PPTP_CONTROL_PORT_NUMBER) ! AliasHandlePptpOut(la, pip, lnk); ! else if (la->skinnyPort != 0 && (ntohs(tc->th_sport) == la->skinnyPort ! || ntohs(tc->th_dport) == la->skinnyPort)) ! AliasHandleSkinny(la, pip, lnk); /* Adjust TCP checksum since source port is being aliased */ /* and source address is being altered */ --- 1029,1039 ---- /* Monitor TCP connection state */ TcpMonitorOut(pip, lnk); ! ! /* walk out chain */ ! err = find_handler(OUT, TCP, la, pip, &ad); ! if (err == EHDNOF) ! ; /* Adjust TCP checksum since source port is being aliased */ /* and source address is being altered */ *************** *** 1208,1220 **** case IPPROTO_TCP: iresult = TcpAliasIn(la, pip); break; ! case IPPROTO_GRE: ! if (la->packetAliasMode & PKT_ALIAS_PROXY_ONLY || ! AliasHandlePptpGreIn(la, pip) == 0) iresult = PKT_ALIAS_OK; else iresult = ProtoAliasIn(la, pip); ! break; default: iresult = ProtoAliasIn(la, pip); break; --- 1234,1261 ---- case IPPROTO_TCP: iresult = TcpAliasIn(la, pip); break; ! case IPPROTO_GRE: { ! int err; ! struct alias_data ad = { ! NULL, ! NULL, ! NULL, ! NULL, ! NULL, ! NULL, ! 0 ! }; ! ! /* walk out chain */ ! err = find_handler(IN, IP, la, pip, &ad); ! if (err == EHDNOF) ! ; ! if (err == OK) iresult = PKT_ALIAS_OK; else iresult = ProtoAliasIn(la, pip); ! } ! break; default: iresult = ProtoAliasIn(la, pip); break; *************** *** 1321,1332 **** case IPPROTO_TCP: iresult = TcpAliasOut(la, pip, maxpacketsize, create); break; ! case IPPROTO_GRE: ! if (AliasHandlePptpGreOut(la, pip) == 0) ! iresult = PKT_ALIAS_OK; ! else ! iresult = ProtoAliasOut(la, pip, create); ! break; default: iresult = ProtoAliasOut(la, pip, create); break; --- 1362,1388 ---- case IPPROTO_TCP: iresult = TcpAliasOut(la, pip, maxpacketsize, create); break; ! case IPPROTO_GRE: { ! int err; ! struct alias_data ad = { ! NULL, ! NULL, ! NULL, ! NULL, ! NULL, ! NULL, ! 0 ! }; ! /* walk out chain */ ! err = find_handler(OUT, IP, la, pip, &ad); ! if (err == EHDNOF) ! ; ! if (err == OK) ! iresult = PKT_ALIAS_OK; ! else ! iresult = ProtoAliasOut(la, pip, create); ! } ! break; default: iresult = ProtoAliasOut(la, pip, create); break; *************** *** 1443,1445 **** --- 1499,1592 ---- return (iresult); } + + #ifndef _KERNEL + + int + LibAliasRefreshModules(void) { + char buf[256], conf[] = "/etc/libalias.conf"; + FILE *fd; + struct dll *t; + struct proto_handler *p; + int len; + + fd = fopen(conf, "r"); + if (fd == NULL) { + strcpy(buf, "cannot open config file "); + strcat(buf, conf); + perror(buf); + exit(-1); + } + + LibAliasUnLoadAllModule(); + + while (1) { + fgets(buf, 256, fd); + if feof(fd) break; + len = strlen(buf); + if (len > 1) { + buf[len - 1] = '\0'; + printf("Loading %s\n", buf); + LibAliasLoadModule(buf); + } + } + return (OK); + } + + int + LibAliasLoadModule(char *path) { + struct dll *t; + void *handle; + struct proto_handler *m; + const char *error; + moduledata_t *p; + + handle = dlopen (path, RTLD_LAZY); + if (!handle) { + fputs (dlerror(), stderr); + return (NOK); + } + + p = dlsym(handle, "alias_mod"); + if ((error = dlerror()) != NULL) { + fputs(error, stderr); + return (NOK); + } + + t = malloc(sizeof(struct dll)); + if (t == NULL) + return (ENOMEM); + strncpy(t->name, p->name, DLL_LEN); + t->handle = handle; + if (attach_dll(t) == EHDCON) { + free(t); + fputs("dll conflict", stderr); + return (NOK); + } + + m = dlsym(t->handle, "handlers"); + if ((error = dlerror()) != NULL) { + fputs(error, stderr); + return (NOK); + } + + attach_handlers(m); + return (OK); + } + + int + LibAliasUnLoadAllModule(void) { + struct dll *t; + struct proto_handler *p; + + /* unload all modules then reload everything */ + while ((p = first_handler()) != NULL) { + detach_handler(p); + } + while ((t = walk_dll_chain()) != NULL) { + dlclose(t->handle); + free(t); + } + } + + #endif diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias.h /home/flag/src/freebsd7/src/sys/netinet/libalias/alias.h *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias.h Thu May 5 23:53:17 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias.h Sun Jun 11 18:57:26 2006 *************** *** 39,51 **** #ifndef _ALIAS_H_ #define _ALIAS_H_ #ifdef _KERNEL /* ! * The kernel version of libalias does not support these features. */ #define NO_FW_PUNCH - #define NO_LOGGING #define NO_USE_SOCKETS #endif /* --- 39,56 ---- #ifndef _ALIAS_H_ #define _ALIAS_H_ + #include + #include + #include + + #define LIBALIAS_BUF_SIZE 128 #ifdef _KERNEL /* ! * The kernel version of libalias does not support these features... */ #define NO_FW_PUNCH #define NO_USE_SOCKETS + #endif /* *************** *** 180,200 **** /* Transparent proxying routines. */ int LibAliasProxyRule(struct libalias *, const char *_cmd); /* * Mode flags and other constants. */ - /* Mode flags, set using PacketAliasSetMode() */ /* * If PKT_ALIAS_LOG is set, a message will be printed to /var/log/alias.log * every time a link is created or deleted. This is useful for debugging. */ - #ifndef NO_LOGGING #define PKT_ALIAS_LOG 0x01 - #endif /* * If PKT_ALIAS_DENY_INCOMING is set, then incoming connections (e.g. to ftp, --- 185,206 ---- /* Transparent proxying routines. */ int LibAliasProxyRule(struct libalias *, const char *_cmd); + /* Module handling API */ + int LibAliasLoadModule(char *); + int LibAliasUnLoadAllModule(void); + int LibAliasRefreshModules(void); /* * Mode flags and other constants. */ /* Mode flags, set using PacketAliasSetMode() */ /* * If PKT_ALIAS_LOG is set, a message will be printed to /var/log/alias.log * every time a link is created or deleted. This is useful for debugging. */ #define PKT_ALIAS_LOG 0x01 /* * If PKT_ALIAS_DENY_INCOMING is set, then incoming connections (e.g. to ftp, diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_cuseeme.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_cuseeme.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_cuseeme.c Thu May 5 23:55:17 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_cuseeme.c Sun Jun 11 18:57:26 2006 *************** *** 31,37 **** --- 31,47 ---- #ifdef _KERNEL #include + #include + #include + #include + #include + #include + #include + #include + #include + #include #else + #include #include #include #endif *************** *** 44,51 **** --- 54,142 ---- #ifdef _KERNEL #include #include + #include #else #include "alias_local.h" + #include "alias_mod.h" + #endif + + #define CUSEEME_PORT_NUMBER 7648 + + static void + AliasHandleCUSeeMeOut(struct libalias *la, struct ip *pip, + struct alias_link *lnk); + + static void + AliasHandleCUSeeMeIn(struct libalias *la, struct ip *pip, + struct in_addr original_addr); + #ifdef _KERNEL + static + #endif + int + fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (ah->dport == NULL || ah->original_address == NULL) + return (NOK); + if (ntohs(*ah->dport) == CUSEEME_PORT_NUMBER) + return (OK); + return (NOK); + } + + #ifdef _KERNEL + static + #endif + int + protohandlerin(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + AliasHandleCUSeeMeIn(la, pip, *ah->original_address); + return (OK); + } + + #ifdef _KERNEL + static + #endif + int + protohandlerout(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + AliasHandleCUSeeMeOut(la, pip, ah->lnk); + return (OK); + } + + /* Kernel module definition. */ + struct proto_handler handlers[] = {{120, OUT, UDP, &fingerprint, &protohandlerout}, + {120, IN, UDP, &fingerprint, &protohandlerin}, {EOH}}; + + static int + mod_handler(module_t mod, int type, void *data) + { + int error; + + switch (type) { + case MOD_LOAD: + error = 0; + attach_handlers(handlers); + break; + case MOD_UNLOAD: + error = 0; + detach_handlers(handlers); + break; + default: + error = EINVAL; + } + return (error); + } + + #ifdef _KERNEL + static + #endif + moduledata_t alias_mod = { + "alias_cuseeme", mod_handler, NULL + }; + + #ifdef _KERNEL + DECLARE_MODULE(alias_cuseeme, alias_mod, SI_SUB_DRIVERS, SI_ORDER_SECOND); + MODULE_VERSION(alias_cuseeme, 1); + MODULE_DEPEND(alias_cuseeme, libalias, 1, 1, 1); #endif /* CU-SeeMe Data Header */ *************** *** 77,82 **** --- 168,176 ---- * counts etc */ }; + #ifdef _KERNEL + static + #endif void AliasHandleCUSeeMeOut(struct libalias *la, struct ip *pip, struct alias_link *lnk) { *************** *** 100,105 **** --- 194,202 ---- } } + #ifdef _KERNEL + static + #endif void AliasHandleCUSeeMeIn(struct libalias *la, struct ip *pip, struct in_addr original_addr) { diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_db.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_db.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_db.c Tue Sep 20 00:31:45 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_db.c Sun Jun 11 18:57:27 2006 *************** *** 143,150 **** --- 143,152 ---- */ #ifdef _KERNEL + #include #include #else + #include #include #endif *************** *** 156,168 **** #ifdef _KERNEL #include #include #include #include #else #include #include #include - #include #endif /* BSD network include files */ --- 158,171 ---- #ifdef _KERNEL #include #include + #include #include #include + #include #else #include #include #include #endif /* BSD network include files */ *************** *** 171,187 **** #include #include ! #ifdef _KERNEL #include #include #else #include "alias.h" #include "alias_local.h" #endif static LIST_HEAD(, libalias) instancehead = LIST_HEAD_INITIALIZER(instancehead); - /* Constants (note: constants are also defined near relevant functions or structs) --- 174,193 ---- #include #include ! #ifdef _KERNEL #include #include + #include + #include + #include #else #include "alias.h" #include "alias_local.h" + #include "alias_mod.h" #endif static LIST_HEAD(, libalias) instancehead = LIST_HEAD_INITIALIZER(instancehead); /* Constants (note: constants are also defined near relevant functions or structs) *************** *** 350,355 **** --- 356,368 ---- MODULE_VERSION(libalias, 1); + /* Use kernel allocator. */ + #if defined(_SYS_MALLOC_H_) + #define malloc(x) malloc(x, M_ALIAS, M_NOWAIT|M_ZERO) + #define calloc(x, n) malloc(x*n) + #define free(x) free(x, M_ALIAS) + #endif + static int alias_mod_handler(module_t mod, int type, void *data) { *************** *** 358,373 **** switch (type) { case MOD_LOAD: error = 0; break; case MOD_QUIESCE: case MOD_UNLOAD: ! finishoff(); error = 0; break; default: error = EINVAL; } - return (error); } --- 371,389 ---- switch (type) { case MOD_LOAD: error = 0; + handler_chain_init(); break; + #if __FreeBSD_version >= 500000 case MOD_QUIESCE: + #endif case MOD_UNLOAD: ! handler_chain_destroy(); ! finishoff(); error = 0; break; default: error = EINVAL; } return (error); } *************** *** 409,420 **** #endif - #ifndef NO_LOGGING /* Log file control */ static void ShowAliasStats(struct libalias *); ! static void InitPacketAliasLog(struct libalias *); static void UninitPacketAliasLog(struct libalias *); - #endif static u_int StartPointIn(struct in_addr alias_addr, --- 425,434 ---- #endif /* Log file control */ static void ShowAliasStats(struct libalias *); ! static int InitPacketAliasLog(struct libalias *); static void UninitPacketAliasLog(struct libalias *); static u_int StartPointIn(struct in_addr alias_addr, *************** *** 462,498 **** return (ntohl(y) - ntohl(x)); } - #ifndef NO_LOGGING static void ! ShowAliasStats(struct libalias *la) ! { ! /* Used for debugging */ ! if (la->monitorFile) { ! fprintf(la->monitorFile, ! "icmp=%d, udp=%d, tcp=%d, pptp=%d, proto=%d, frag_id=%d frag_ptr=%d", ! la->icmpLinkCount, ! la->udpLinkCount, ! la->tcpLinkCount, ! la->pptpLinkCount, ! la->protoLinkCount, ! la->fragmentIdLinkCount, ! la->fragmentPtrLinkCount); ! ! fprintf(la->monitorFile, " / tot=%d (sock=%d)\n", ! la->icmpLinkCount + la->udpLinkCount ! + la->tcpLinkCount ! + la->pptpLinkCount ! + la->protoLinkCount ! + la->fragmentIdLinkCount ! + la->fragmentPtrLinkCount, ! la->sockCount); ! fflush(la->monitorFile); } } - #endif /* Internal routines for finding, deleting and adding links --- 476,528 ---- return (ntohl(y) - ntohl(x)); } + #ifdef _KERNEL static void ! AliasLog(char * str, const char * format, ...) { ! va_list ap; ! ! va_start(ap, format); ! vsnprintf(str, LIBALIAS_BUF_SIZE, format, ap); ! log(LOG_SECURITY | LOG_INFO, "%s\n", str); ! va_end(ap); ! } ! #else ! static void ! AliasLog(FILE * stream, const char * format, ...) { ! va_list ap; ! ! va_start(ap, format); ! vfprintf(stream, format, ap); ! va_end(ap); ! fflush(stream); ! } ! #endif ! static void ! ShowAliasStats(struct libalias *la) { ! /* Used for debugging */ ! if (la->logDesc) { ! int tot = la->icmpLinkCount + la->udpLinkCount + ! la->tcpLinkCount + la->pptpLinkCount + ! la->protoLinkCount + la->fragmentIdLinkCount + ! la->fragmentPtrLinkCount; ! ! AliasLog(la->logDesc, ! "icmp=%u, udp=%u, tcp=%u, pptp=%u, proto=%u, frag_id=%u frag_ptr=%u / tot=%u", ! la->icmpLinkCount, ! la->udpLinkCount, ! la->tcpLinkCount, ! la->pptpLinkCount, ! la->protoLinkCount, ! la->fragmentIdLinkCount, ! la->fragmentPtrLinkCount, tot); ! #ifndef _KERNEL ! AliasLog(la->logDesc, " (sock=%u)\n", la->sockCount); ! #endif } } /* Internal routines for finding, deleting and adding links *************** *** 929,940 **** /* Free memory */ free(lnk); - #ifndef NO_LOGGING /* Write statistics, if logging enabled */ if (la->packetAliasMode & PKT_ALIAS_LOG) { ShowAliasStats(la); } - #endif } --- 959,968 ---- *************** *** 1013,1019 **** switch (link_type) { struct tcp_dat *aux_tcp; ! case LINK_ICMP: la->icmpLinkCount++; break; case LINK_UDP: --- 1041,1047 ---- switch (link_type) { struct tcp_dat *aux_tcp; ! case LINK_ICMP: la->icmpLinkCount++; break; case LINK_UDP: *************** *** 1072,1082 **** fprintf(stderr, "malloc() call failed.\n"); #endif } - #ifndef NO_LOGGING if (la->packetAliasMode & PKT_ALIAS_LOG) { ShowAliasStats(la); } - #endif return (lnk); } --- 1100,1108 ---- *************** *** 2203,2232 **** } } - #ifndef NO_LOGGING /* Init the log file and enable logging */ ! static void InitPacketAliasLog(struct libalias *la) { ! if ((~la->packetAliasMode & PKT_ALIAS_LOG) ! && (la->monitorFile = fopen("/var/log/alias.log", "w"))) { la->packetAliasMode |= PKT_ALIAS_LOG; - fprintf(la->monitorFile, - "PacketAlias/InitPacketAliasLog: Packet alias logging enabled.\n"); } } /* Close the log-file and disable logging. */ static void UninitPacketAliasLog(struct libalias *la) { ! if (la->monitorFile) { ! fclose(la->monitorFile); ! la->monitorFile = NULL; ! } la->packetAliasMode &= ~PKT_ALIAS_LOG; } - #endif /* Outside world interfaces --- 2229,2267 ---- } } /* Init the log file and enable logging */ ! static int InitPacketAliasLog(struct libalias *la) { ! if (~la->packetAliasMode & PKT_ALIAS_LOG) { ! #ifdef _KERNEL ! if ((la->logDesc = malloc(LIBALIAS_BUF_SIZE))) ! ; ! #else ! if ((la->logDesc = fopen("/var/log/alias.log", "w"))) ! fprintf(la->logDesc, "PacketAlias/InitPacketAliasLog: Packet alias logging enabled.\n"); ! #endif ! else ! return(ENOMEM); /* log initialization failed */ la->packetAliasMode |= PKT_ALIAS_LOG; } + return(1); } /* Close the log-file and disable logging. */ static void UninitPacketAliasLog(struct libalias *la) { ! if (la->logDesc) { ! #ifdef _KERNEL ! free(la->logDesc); ! #else ! fclose(la->logDesc); ! #endif ! la->logDesc = NULL; ! } la->packetAliasMode &= ~PKT_ALIAS_LOG; } /* Outside world interfaces *************** *** 2498,2510 **** la->deleteAllLinks = 1; CleanupAliasData(la); la->deleteAllLinks = 0; - #ifndef NO_LOGGING UninitPacketAliasLog(la); - #endif #ifndef NO_FW_PUNCH UninitPunchFW(la); #endif ! LIST_REMOVE(la, instancelist); free(la); } --- 2533,2543 ---- la->deleteAllLinks = 1; CleanupAliasData(la); la->deleteAllLinks = 0; UninitPacketAliasLog(la); #ifndef NO_FW_PUNCH UninitPunchFW(la); #endif ! LIST_REMOVE(la, instancelist); free(la); } *************** *** 2517,2532 **** * do a probe for flag values) */ ) { - #ifndef NO_LOGGING /* Enable logging? */ if (flags & mask & PKT_ALIAS_LOG) { ! InitPacketAliasLog(la); /* Do the enable */ } else /* _Disable_ logging? */ if (~flags & mask & PKT_ALIAS_LOG) { UninitPacketAliasLog(la); } - #endif #ifndef NO_FW_PUNCH /* Start punching holes in the firewall? */ if (flags & mask & PKT_ALIAS_PUNCH_FW) { --- 2550,2565 ---- * do a probe for flag values) */ ) { /* Enable logging? */ if (flags & mask & PKT_ALIAS_LOG) { ! /* Do the enable */ ! if (InitPacketAliasLog(la) == ENOMEM) ! return(-1); } else /* _Disable_ logging? */ if (~flags & mask & PKT_ALIAS_LOG) { UninitPacketAliasLog(la); } #ifndef NO_FW_PUNCH /* Start punching holes in the firewall? */ if (flags & mask & PKT_ALIAS_PUNCH_FW) { *************** *** 2560,2566 **** --- 2593,2604 ---- /* Firewall include files */ #include + + #if __FreeBSD__ < 5 + #include + #else #include + #endif #include #include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_dummy.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_dummy.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_dummy.c Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_dummy.c Sun Jun 11 18:57:27 2006 *************** *** 0 **** --- 1,160 ---- + /*- + * Copyright (c) 2005 Paolo Pisati + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + + #include + + /* + * Alias_dummy is just an empty skeleton used to demostrate how to write + * a module for libalias, that will run unalterated in userland or in + * kernel land + */ + + /* Includes */ + #ifdef _KERNEL + #include + #include + #include + #include + #include + #include + #include + #include + #include + #else + #include + #include + #include + #include + #include + #endif + + #include + #include + #include + #include + + #ifdef _KERNEL + #include + #include + #include + #else + #include "alias_local.h" + #include "alias_mod.h" + #endif + + static void + AliasHandleDummy(struct libalias *la, struct ip *ip, struct alias_data *ah); + + #ifdef _KERNEL + static + #endif + int + fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + /* + * check here all the data that will be used later, if any field + * is empy/NULL, return a NOK value + */ + if (ah->dport == NULL || ah->sport == NULL || ah->lnk == NULL || + ah->maxpacketsize == 0) + return (NOK); + /* + * fingerprint the incoming packet, if it matches any conditions + * return an OK value + */ + if (ntohs(*ah->dport) == 123 + || ntohs(*ah->sport) == 456) + return (OK); /* i know how to handle it... */ + return (NOK); /* i don't know this packet... */ + } + + /* + * Wrap in this general purpose function, the real function used to alias the + * packets + */ + + #ifdef _KERNEL + static + #endif + int + protohandler(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + AliasHandleDummy(la, pip, ah); + return (OK); + } + + /* + * NOTA BENE: these 2 variables MUST NOT be renamed in any case if you want + * your module to work in userland, cause they are used to find and use all + * the protocol handlers present in every module. + * So WATCH OUT, your module needs these 2 variables, and it needs them with + * THEIR EXACT NAMES: handlers and entries. + */ + + struct proto_handler handlers [] = {{666, IN|OUT, UDP|TCP, &fingerprint, + &protohandler}, {EOH}}; + + static int + mod_handler(module_t mod, int type, void *data) + { + int error; + + switch (type) { + case MOD_LOAD: + error = 0; + attach_handlers(handlers); + break; + case MOD_UNLOAD: + error = 0; + detach_handlers(handlers); + break; + default: + error = EINVAL; + } + return (error); + } + + #ifdef _KERNEL + static + #endif + moduledata_t alias_mod = { + "alias_dummy", mod_handler, NULL + }; + + #ifdef _KERNEL + DECLARE_MODULE(alias_dummy, alias_mod, SI_SUB_DRIVERS, SI_ORDER_SECOND); + MODULE_VERSION(alias_dummy, 1); + MODULE_DEPEND(alias_dummy, libalias, 1, 1, 1); + #endif + + #ifdef _KERNEL + static + #endif + void + AliasHandleDummy(struct libalias *la, struct ip *ip, struct alias_data *ah) { + ; /* dummy */ + } + diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_ftp.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_ftp.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_ftp.c Mon Jun 27 09:36:02 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_ftp.c Sun Jun 11 18:57:27 2006 *************** *** 73,79 **** --- 73,86 ---- #include #include #include + #include + #include + #include + #include + #include + #include #else + #include #include #include #include *************** *** 88,95 **** --- 95,171 ---- #ifdef _KERNEL #include #include + #include #else #include "alias_local.h" + #include "alias_mod.h" + #endif + + #define FTP_CONTROL_PORT_NUMBER 21 + + static void + AliasHandleFtpOut(struct libalias *, struct ip *, struct alias_link *, + int maxpacketsize); + + #ifdef _KERNEL + static + #endif + int + fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (ah->dport == NULL || ah->sport == NULL || ah->lnk == NULL || + ah->maxpacketsize == 0) + return (NOK); + if (ntohs(*ah->dport) == FTP_CONTROL_PORT_NUMBER + || ntohs(*ah->sport) == FTP_CONTROL_PORT_NUMBER) + return (OK); + return (NOK); + } + + #ifdef _KERNEL + static + #endif + int + protohandler(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + AliasHandleFtpOut(la, pip, ah->lnk, ah->maxpacketsize); + return (OK); + } + + struct proto_handler handlers[] = {{80, OUT, TCP, &fingerprint, + &protohandler}, {EOH}}; + + static int + mod_handler(module_t mod, int type, void *data) + { + int error; + + switch (type) { + case MOD_LOAD: + error = 0; + attach_handlers(handlers); + break; + case MOD_UNLOAD: + error = 0; + detach_handlers(handlers); + break; + default: + error = EINVAL; + } + return (error); + } + + #ifdef _KERNEL + static + #endif + moduledata_t alias_mod = { + "alias_ftp", mod_handler, NULL + }; + + #ifdef _KERNEL + DECLARE_MODULE(alias_ftp, alias_mod, SI_SUB_DRIVERS, SI_ORDER_SECOND); + MODULE_VERSION(alias_ftp, 1); + MODULE_DEPEND(alias_ftp, libalias, 1, 1, 1); #endif #define FTP_CONTROL_PORT_NUMBER 21 *************** *** 112,117 **** --- 188,196 ---- static int ParseFtp229Reply(struct libalias *la, char *, int); static void NewFtpMessage(struct libalias *la, struct ip *, struct alias_link *, int, int); + #ifdef _KERNEL + static + #endif void AliasHandleFtpOut( struct libalias *la, diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_irc.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_irc.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_irc.c Mon Jun 27 09:36:02 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_irc.c Sun Jun 11 18:57:27 2006 *************** *** 52,59 **** --- 52,70 ---- #include #include #include + #include + #include + #include + #include + #include + #include + #if __FreeBSD_version < 500000 + #include + #else #include + #endif #else + #include #include #include #include *************** *** 69,82 **** --- 80,165 ---- #ifdef _KERNEL #include #include + #include #else #include "alias_local.h" + #include "alias_mod.h" #endif + #define IRC_CONTROL_PORT_NUMBER_1 6667 + #define IRC_CONTROL_PORT_NUMBER_2 6668 + /* Local defines */ #define DBprintf(a) + static void + AliasHandleIrcOut(struct libalias *, struct ip *, struct alias_link *, + int maxpacketsize); + + #ifdef _KERNEL + static + #endif + int + fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (ah->dport == NULL || ah->dport == NULL || ah->lnk == NULL || + ah->maxpacketsize == 0) + return (NOK); + if (ntohs(*ah->dport) == IRC_CONTROL_PORT_NUMBER_1 + || ntohs(*ah->dport) == IRC_CONTROL_PORT_NUMBER_2) + return (OK); + return (NOK); + } + + #ifdef _KERNEL + static + #endif + int + protohandler(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + AliasHandleIrcOut(la, pip, ah->lnk, ah->maxpacketsize); + return (OK); + } + struct proto_handler handlers[] = {{90, OUT, TCP, &fingerprint, + &protohandler}, {EOH}}; + + static int + mod_handler(module_t mod, int type, void *data) { + int error; + + switch (type) { + case MOD_LOAD: + error = 0; + attach_handlers(handlers); + break; + case MOD_UNLOAD: + error = 0; + detach_handlers(handlers); + break; + default: + error = EINVAL; + } + return (error); + } + + #ifdef _KERNEL + static + #endif + moduledata_t alias_mod = { + "alias_irc", mod_handler, NULL + }; + + /* Kernel module definition. */ + #ifdef _KERNEL + DECLARE_MODULE(alias_irc, alias_mod, SI_SUB_DRIVERS, SI_ORDER_SECOND); + MODULE_VERSION(alias_irc, 1); + MODULE_DEPEND(alias_irc, libalias, 1, 1, 1); + #endif + + #ifdef _KERNEL + static + #endif void AliasHandleIrcOut(struct libalias *la, struct ip *pip, /* IP packet to examine */ diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_local.h /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_local.h *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_local.h Mon Jun 27 09:36:02 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_local.h Sun Jun 11 18:57:27 2006 *************** *** 47,59 **** #define _ALIAS_LOCAL_H_ #include ! /* Use kernel allocator. */ ! #if defined(_KERNEL) && defined(_SYS_MALLOC_H_) ! MALLOC_DECLARE(M_ALIAS); ! #define malloc(x) malloc(x, M_ALIAS, M_NOWAIT|M_ZERO) ! #define calloc(x, n) malloc(x*n) ! #define free(x) free(x, M_ALIAS) #endif /* XXX: LibAliasSetTarget() uses this constant. */ --- 47,66 ---- #define _ALIAS_LOCAL_H_ #include + #include + #include ! #ifdef _KERNEL ! #if __FreeBSD_version >= 500000 ! #include ! #include ! #include ! #include ! #include ! #else ! #include ! #include ! #endif #endif /* XXX: LibAliasSetTarget() uses this constant. */ *************** *** 116,125 **** int deleteAllLinks; /* If equal to zero, DeleteLink() */ /* will not remove permanent links */ ! #ifndef NO_LOGGING ! FILE *monitorFile; /* File descriptor for link */ #endif ! /* statistics monitoring file */ int newDefaultLink; /* Indicates if a new aliasing */ /* link has been created after a */ --- 123,136 ---- int deleteAllLinks; /* If equal to zero, DeleteLink() */ /* will not remove permanent links */ ! ! /* log descriptor */ ! #ifdef _KERNEL ! char *logDesc; ! #else ! FILE *logDesc; #endif ! /* statistics monitoring */ int newDefaultLink; /* Indicates if a new aliasing */ /* link has been created after a */ *************** *** 296,338 **** /* Tcp specfic routines */ /* lint -save -library Suppress flexelint warnings */ - /* FTP routines */ - void - AliasHandleFtpOut(struct libalias *la, struct ip *_pip, struct alias_link *_lnk, - int _maxpacketsize); - - /* IRC routines */ - void - AliasHandleIrcOut(struct libalias *la, struct ip *_pip, struct alias_link *_lnk, - int _maxsize); - - /* RTSP routines */ - void - AliasHandleRtspOut(struct libalias *la, struct ip *_pip, struct alias_link *_lnk, - int _maxpacketsize); - - /* PPTP routines */ - void AliasHandlePptpOut(struct libalias *la, struct ip *_pip, struct alias_link *_lnk); - void AliasHandlePptpIn(struct libalias *la, struct ip *_pip, struct alias_link *_lnk); - int AliasHandlePptpGreOut(struct libalias *la, struct ip *_pip); - int AliasHandlePptpGreIn(struct libalias *la, struct ip *_pip); - - /* NetBIOS routines */ - int - AliasHandleUdpNbt(struct libalias *la, struct ip *_pip, struct alias_link *_lnk, - struct in_addr *_alias_address, u_short _alias_port); - int - AliasHandleUdpNbtNS(struct libalias *la, struct ip *_pip, struct alias_link *_lnk, - struct in_addr *_alias_address, u_short * _alias_port, - struct in_addr *_original_address, u_short * _original_port); - - /* CUSeeMe routines */ - void AliasHandleCUSeeMeOut(struct libalias *la, struct ip *_pip, struct alias_link *_lnk); - void AliasHandleCUSeeMeIn(struct libalias *la, struct ip *_pip, struct in_addr _original_addr); - - /* Skinny routines */ - void AliasHandleSkinny(struct libalias *la, struct ip *_pip, struct alias_link *_lnk); - /* Transparent proxy routines */ int ProxyCheck(struct libalias *la, struct ip *_pip, struct in_addr *_proxy_server_addr, --- 307,312 ---- *************** *** 372,378 **** return ((void *)(udphdr + 1)); } #endif - - /*lint -restore */ #endif /* !_ALIAS_LOCAL_H_ */ --- 346,350 ---- diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_mod.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_mod.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_mod.c Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_mod.c Sun Jun 11 18:57:27 2006 *************** *** 0 **** --- 1,388 ---- + /*- + * Copyright (c) 2005 Paolo Pisati + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + + #ifdef _KERNEL + #include + #include + #else + #include + #include + #include + #endif + + #include + #include + #include + #include + #include + #include + + #include + #include + #include + + #ifdef _KERNEL + #include + #include + #else + #include "alias.h" + #include "alias_local.h" + #include "alias_mod.h" + #endif + + #include + + #if __FreeBSD_version >= 500000 + /* XXX - make the compiler happy... */ + int strncmp(const char *s1, const char *s2, size_t len); + #endif + + /* protocol and userland module handlers chains */ + struct chain handler_chain, dll_chain; + + #ifdef _KERNEL + + #if __FreeBSD_version >= 500000 + + /* Fine grained locking for 5.x, 6.x and 7.x */ + + #define LIBALIAS_LOCK_INIT(_chain) \ + mtx_init(&(_chain)->mtx, "libalias list of proto-handlers", NULL, \ + MTX_DEF | MTX_RECURSE) + #define LIBALIAS_LOCK_DESTROY(_chain) mtx_destroy(&(_chain)->mtx) + #define LIBALIAS_WLOCK_ASSERT(_chain) do { \ + mtx_assert(&(_chain)->mtx, MA_OWNED); \ + NET_ASSERT_GIANT(); \ + } while (0) + + static __inline void + LIBALIAS_RLOCK(struct chain *chain) + { + mtx_lock(&chain->mtx); + chain->busy_count++; + mtx_unlock(&chain->mtx); + } + + static __inline void + LIBALIAS_RUNLOCK(struct chain *chain) + { + mtx_lock(&chain->mtx); + chain->busy_count--; + if (chain->busy_count == 0 && chain->want_write) + cv_signal(&chain->cv); + mtx_unlock(&chain->mtx); + } + + static __inline void + LIBALIAS_WLOCK(struct chain *chain) + { + mtx_lock(&chain->mtx); + chain->want_write++; + while (chain->busy_count > 0) + cv_wait(&chain->cv, &chain->mtx); + } + + static __inline void + LIBALIAS_WUNLOCK(struct chain *chain) + { + chain->want_write--; + cv_signal(&chain->cv); + mtx_unlock(&chain->mtx); + } + + static void + _handler_chain_init(struct chain *c) { + + if (!mtx_initialized(&c->mtx)) + LIBALIAS_LOCK_INIT(c); + } + + static void + _handler_chain_destroy(struct chain *c) { + + if (mtx_initialized(&c->mtx)) + LIBALIAS_LOCK_DESTROY(c); + } + #else + + /* Good old spl*() locking for 4.x */ + /* + * XXX - i'm not sure about mutex & conditional var + * conversion that i did using spl*()... + */ + + #define LIBALIAS_LOCK_INIT(_chain) (_chain)->spl = 0 + #define LIBALIAS_LOCK_DESTROY(_chain) + #define LIBALIAS_WLOCK_ASSERT(_chain) do { \ + KASSERT(_chain->spl != 0, ("chain not locked")); \ + } while (0) + + static __inline void + LIBALIAS_RLOCK(struct chain *chain) + { + chain->spl = splimp(); + } + + static __inline void + LIBALIAS_RUNLOCK(struct chain *chain) + { + splx(chain->spl); + } + + static __inline void + LIBALIAS_WLOCK(struct chain *chain) + { + LIBALIAS_RLOCK(chain); + } + + static __inline void + LIBALIAS_WUNLOCK(struct chain *chain) + { + LIBALIAS_RUNLOCK(chain); + } + + static void + _handler_chain_init(struct chain *c) { + + c->spl = 0; + } + + static void + _handler_chain_destroy(struct chain *c) { + + ; + } + + #endif + #else + + #define LIBALIAS_LOCK_INIT(_chain) ; + #define LIBALIAS_LOCK_DESTROY(_chain) ; + #define LIBALIAS_WLOCK_ASSERT(_chain) ; + + static __inline void + LIBALIAS_RLOCK(struct chain *chain __unused) + { + ; + } + + static __inline void + LIBALIAS_RUNLOCK(struct chain *chain __unused) + { + ; + } + + static __inline void + LIBALIAS_WLOCK(struct chain *chain __unused) + { + ; + } + + static __inline void + LIBALIAS_WUNLOCK(struct chain *chain __unused) + { + ; + } + + static void + _handler_chain_init(struct chain *c __unused) { + ; + } + + static void + _handler_chain_destroy(struct chain *c __unused) { + ; + } + + #endif + + void + handler_chain_init(void) { + _handler_chain_init(&handler_chain); + } + + void + handler_chain_destroy(void) { + _handler_chain_destroy(&handler_chain); + } + + static int + _attach_handler(struct chain *c, struct proto_handler *p) { + struct proto_handler **b; + int i = 0; + + LIBALIAS_WLOCK_ASSERT(c); + b = (struct proto_handler **)&c->chain; + p->next = NULL; /* i'm paranoid... */ + for(; *b != NULL; b = &((*b)->next), i++) { + if (((*b)->pri == p->pri) && ((*b)->dir == p->dir) && + ((*b)->proto == p->proto)) + return (EHDCON); /* priority conflict */ + if ((*b)->pri > p->pri) { + p->next = *b; break; + } + } + /* end of list or got right position, insert here */ + *b = p; + return (OK); + } + + static int + _detach_handler(struct chain *c, struct proto_handler *p) { + struct proto_handler **b; + + LIBALIAS_WLOCK_ASSERT(c); + b = (struct proto_handler **)&c->chain; + for(; (*b != NULL) && (*b != p); b = &((*b)->next)) + ; + if (*b == p) *b = p->next; + else return (EHDNOF); /* handler not found */ + return (OK); + } + + int + attach_handlers(struct proto_handler *_p) { + int i, res = NOK; + + LIBALIAS_WLOCK(&handler_chain); + for (i=0; 1; i++) { + if (*((int *)&_p[i]) == EOH) break; + res = _attach_handler(&handler_chain, &_p[i]); + if (res != OK) break; + } + LIBALIAS_WUNLOCK(&handler_chain); + return (res); + } + + int + detach_handlers(struct proto_handler *_p) { + int i, res = NOK; + + LIBALIAS_WLOCK(&handler_chain); + for (i=0; 1; i++) { + if (*((int *)&_p[i]) == EOH) break; + res = _detach_handler(&handler_chain, &_p[i]); + if (res != OK) break; + } + LIBALIAS_WUNLOCK(&handler_chain); + return (res); + } + + int + detach_handler(struct proto_handler *_p) { + int res = NOK; + + LIBALIAS_WLOCK(&handler_chain); + res = _detach_handler(&handler_chain, _p); + LIBALIAS_WUNLOCK(&handler_chain); + return (res); + } + + int + find_handler(int8_t dir, int8_t proto, struct libalias *la, struct ip *pip, struct alias_data *ad) { + struct proto_handler *p; + int err; + + LIBALIAS_RLOCK(&handler_chain); + for (p = handler_chain.chain, err = EHDNOF; p != NULL; p = p->next) + if ((p->dir & dir) && (p->proto & proto)) + if (p->fingerprint(la, pip, ad) == OK) { + err = p->protohandler(la, pip, ad); + break; + } + LIBALIAS_RUNLOCK(&handler_chain); + return (err); + } + + struct proto_handler * + first_handler(void) { + + return (handler_chain.chain); + } + + static int + _attach_dll(struct chain *c, struct dll *p) { + struct dll **b; + int i = 0; + + LIBALIAS_WLOCK_ASSERT(c); + b = (struct dll **)&c->chain; + p->next = NULL; /* i'm paranoid... */ + for(; *b != NULL; b = &((*b)->next), i++) + if (!strncmp((*b)->name, p->name, DLL_LEN)) + return (EHDCON); /* dll name conflict */ + /* end of list, insert here */ + *b = p; + return (OK); + } + + static void * + _detach_dll(struct chain *c, char *p) { + struct dll **b; + void *err = NULL; + + LIBALIAS_WLOCK_ASSERT(c); + b = (struct dll **)&c->chain; + for(; *b != NULL; b = &((*b)->next)) + if (!strncmp((*b)->name, p, DLL_LEN)) { + err = *b; + *b = (*b)->next; + break; + } + return (err); + } + + int + attach_dll(struct dll *p) { + int i; + + LIBALIAS_WLOCK(&dll_chain); + i = _attach_dll(&dll_chain, p); + LIBALIAS_WUNLOCK(&dll_chain); + return (i); + } + + void * + detach_dll(char *p) { + void *i; + + LIBALIAS_WLOCK(&dll_chain); + i = _detach_dll(&dll_chain, p); + LIBALIAS_WUNLOCK(&dll_chain); + return (i); + } + + struct dll * + walk_dll_chain(void) { + struct dll *t, **b = (struct dll **)&dll_chain.chain; + + for(t = *b; *b != NULL;) { + *b = (*b)->next; + break; + } + return (t); + } diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_mod.h /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_mod.h *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_mod.h Thu Jan 1 01:00:00 1970 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_mod.h Sun Jun 11 18:57:27 2006 *************** *** 0 **** --- 1,183 ---- + /*- + * Copyright (c) 2005 Paolo Pisati + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + + /*- + * Alias_mod.h defines the outside world interfaces for the packet aliasing + * modular framework + */ + + #ifndef _ALIAS_MOD_H_ + #define _ALIAS_MOD_H_ + + /* protocol handlers struct & function*/ + + /* packet flow direction */ + #define IN 1 + #define OUT 2 + + /* working protocol */ + #define IP 1 + #define TCP 2 + #define UDP 4 + #define ICMP 8 + + /* + * Data passed to protocol handler module, it must be filled + * right before calling find_handler() to determine which + * module is elegible to be called + */ + + struct alias_data { + + struct alias_link *lnk; + struct in_addr *original_address; + struct in_addr *alias_address; + u_short *alias_port; + u_int16_t *sport, *dport; + int maxpacketsize; + }; + + /* + * This structure contains all the information necessary to make + * a protocol handler correctly work. + */ + + struct proto_handler { + + u_int pri; /* handler priority */ + int16_t dir; /* flow direction */ + int16_t proto; /* working protocol */ + int (*fingerprint)(struct libalias *la, /* fingerprint * function */ + struct ip *pip, struct alias_data *ah); + int (*protohandler)(struct libalias *la, /* aliasing * function */ + struct ip *pip, struct alias_data *ah); + struct proto_handler *next; + }; + + #if __FreeBSD_version >= 500000 + struct chain { + + void *chain; + struct mtx mtx; /* lock guarding list */ + int busy_count; /* busy count for rw locks */ + int want_write; + struct cv cv; + }; + #else + struct chain { + + void *chain; + int spl; + }; + #endif + + /* + * Used only in userland when libalias needs to keep track of all + * module loaded. In kernel land (kld mode) we don't need to care + * care about libalias modules cause it's kld to do it for us + */ + + #define DLL_LEN 32 + struct dll { + + char name[DLL_LEN]; /* name of module */ + void *handle; /* + * ptr to shared obj obtained through + * dlopen() - use this ptr to get access + * to any symbols from a loaded module + * via dlsym() + */ + struct dll *next; + }; + + /* functions used with protocol handlers */ + + void handler_chain_init(void); + void handler_chain_destroy(void); + int attach_handlers(struct proto_handler *); + int detach_handlers(struct proto_handler *); + int detach_handler(struct proto_handler *); + int find_handler(int8_t, int8_t, struct libalias *, + struct ip *, struct alias_data *); + struct proto_handler *first_handler(void); + + /* functions used with dll module */ + + void dll_chain_init(void); + void dll_chain_destroy(void); + int attach_dll(struct dll *); + void *detach_dll(char *); + struct dll *walk_dll_chain(void); + + /* general condition of success & failure */ + #define OK 1 + #define NOK -1 + + /* end of handlers */ + #define EOH -1 + + /* + * handler/dll conflict - tried to attach a protocol handleror a dll, + * but found another one with same priority, direction and working + * protocol(proto handler) or name (dll) already in chain + */ + + #define EHDCON 2 + + /* + * handler/dll not found - tried to detach/search a protocol module + * handler or a dll not present in chain + */ + + #define EHDNOF 3 + + /* + * Some defines borrowed from sys/module.h used to compile a kld + * in userland as a shared lib + */ + + #ifndef _KERNEL + typedef enum modeventtype { + MOD_LOAD, + MOD_UNLOAD, + MOD_SHUTDOWN, + MOD_QUIESCE + } modeventtype_t; + + typedef struct module *module_t; + typedef int (*modeventhand_t)(module_t, int /* modeventtype_t */, void *); + + /* + * Struct for registering modules statically via SYSINIT. + */ + typedef struct moduledata { + const char *name; /* module name */ + modeventhand_t evhand; /* event handler */ + void *priv; /* extra data */ + } moduledata_t; + #endif + + #endif /* !_ALIAS_MOD_H_ */ diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_nbt.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_nbt.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_nbt.c Fri May 6 13:07:49 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_nbt.c Sun Jun 11 18:57:27 2006 *************** *** 45,56 **** #include #include #include #else #include #include #include #include - #include #endif #include --- 45,62 ---- #include #include #include + #include + #include + #include + #include + #include + #include #else + #include #include #include #include #include #endif #include *************** *** 62,69 **** --- 68,175 ---- #ifdef _KERNEL #include #include + #include #else #include "alias_local.h" + #include "alias_mod.h" + #endif + + #define NETBIOS_NS_PORT_NUMBER 137 + #define NETBIOS_DGM_PORT_NUMBER 138 + + static int + AliasHandleUdpNbt(struct libalias *, struct ip *, struct alias_link *, + struct in_addr *, u_short); + + static int + AliasHandleUdpNbtNS(struct libalias *, struct ip *, struct alias_link *, + struct in_addr *, u_short *, struct in_addr *, u_short *); + #ifdef _KERNEL + static + #endif + int + fingerprint1(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (ah->dport == NULL || ah->sport == NULL || ah->lnk == NULL || + ah->alias_address == NULL || ah->alias_port == NULL) + return (NOK); + if (ntohs(*ah->dport) == NETBIOS_DGM_PORT_NUMBER + || ntohs(*ah->sport) == NETBIOS_DGM_PORT_NUMBER) + return (OK); + return (NOK); + } + + #ifdef _KERNEL + static + #endif + int + protohandler1(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + AliasHandleUdpNbt(la, pip, ah->lnk, ah->alias_address, *ah->alias_port); + return (OK); + } + + #ifdef _KERNEL + static + #endif + int + fingerprint2(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (ah->dport == NULL || ah->sport == NULL || ah->lnk == NULL || + ah->alias_address == NULL || ah->alias_port == NULL) + return (NOK); + if (ntohs(*ah->dport) == NETBIOS_NS_PORT_NUMBER + || ntohs(*ah->sport) == NETBIOS_NS_PORT_NUMBER) + return (OK); + return (NOK); + } + + #ifdef _KERNEL + static + #endif + int + protohandler2(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + AliasHandleUdpNbtNS(la, pip, ah->lnk, &pip->ip_src, ah->sport, + ah->alias_address, ah->alias_port); + return (OK); + } + + /* Kernel module definition. */ + struct proto_handler handlers[] = {{130, IN|OUT, UDP, &fingerprint1, &protohandler1}, + {140, IN|OUT, UDP, &fingerprint2, &protohandler2}, {EOH}}; + + static int + mod_handler(module_t mod, int type, void *data) + { + int error; + + switch (type) { + case MOD_LOAD: + error = 0; + attach_handlers(handlers); + break; + case MOD_UNLOAD: + error = 0; + detach_handlers(handlers); + break; + default: + error = EINVAL; + } + return (error); + } + + #ifdef _KERNEL + static + #endif + moduledata_t alias_mod = { + "alias_nbt", mod_handler, NULL + }; + + #ifdef _KERNEL + DECLARE_MODULE(alias_nbt, alias_mod, SI_SUB_DRIVERS, SI_ORDER_SECOND); + MODULE_VERSION(alias_nbt, 1); + MODULE_DEPEND(alias_nbt, libalias, 1, 1, 1); #endif typedef struct { *************** *** 212,217 **** --- 318,326 ---- #define DGM_POSITIVE_RES 0x15 #define DGM_NEGATIVE_RES 0x16 + #ifdef _KERNEL + static + #endif int AliasHandleUdpNbt( struct libalias *la, *************** *** 640,645 **** --- 749,757 ---- return ((u_char *) q); } + #ifdef _KERNEL + static + #endif int AliasHandleUdpNbtNS( struct libalias *la, diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_old.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_old.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_old.c Thu May 5 21:27:32 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_old.c Sun Jun 11 18:57:27 2006 *************** *** 29,34 **** --- 29,35 ---- #ifdef _KERNEL #include + #include #else #include #include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_pptp.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_pptp.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_pptp.c Thu May 5 23:55:17 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_pptp.c Sun Jun 11 18:57:27 2006 *************** *** 39,44 **** --- 39,206 ---- #include __FBSDID("$FreeBSD: src/sys/netinet/libalias/alias_pptp.c,v 1.14 2005/05/05 21:55:17 glebius Exp $"); + /* Includes */ + #ifdef _KERNEL + #if __FreeBSD__ >= 5 + #include + #else + #include + #endif + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #else + #include + #include + #include + #include + #endif + + #include + #include + #include + #include + + #ifdef _KERNEL + #include + #include + #include + #else + #include "alias.h" + #include "alias_local.h" + #include "alias_mod.h" + #endif + + #define PPTP_CONTROL_PORT_NUMBER 1723 + + static void + AliasHandlePptpOut(struct libalias *, struct ip *, struct alias_link *); + + static void + AliasHandlePptpIn(struct libalias *, struct ip *, struct alias_link *); + + static int + AliasHandlePptpGreOut(struct libalias *, struct ip *); + + static int + AliasHandlePptpGreIn(struct libalias *, struct ip *); + + #ifdef _KERNEL + static + #endif + int + fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (ah->dport == NULL || ah->sport == NULL || ah->lnk == NULL) + return (NOK); + if (ntohs(*ah->dport) == PPTP_CONTROL_PORT_NUMBER + || ntohs(*ah->sport) == PPTP_CONTROL_PORT_NUMBER) + return (OK); + return (NOK); + } + + #ifdef _KERNEL + static + #endif + int + fingerprintgre(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + return (OK); + } + + #ifdef _KERNEL + static + #endif + int + protohandlerin(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + AliasHandlePptpIn(la, pip, ah->lnk); + return (OK); + } + + #ifdef _KERNEL + static + #endif + int + protohandlerout(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + AliasHandlePptpOut(la, pip, ah->lnk); + return (OK); + } + + #ifdef _KERNEL + static + #endif + int + protohandlergrein(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (la->packetAliasMode & PKT_ALIAS_PROXY_ONLY || + AliasHandlePptpGreIn(la, pip) == 0) + return (OK); + return (NOK); + } + + #ifdef _KERNEL + static + #endif + int + protohandlergreout(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (AliasHandlePptpGreOut(la, pip) == 0) + return (OK); + return (NOK); + } + + /* Kernel module definition. */ + struct proto_handler handlers[] = {{200, IN, TCP, &fingerprint, &protohandlerin}, + {210, OUT, TCP, &fingerprint, &protohandlerout}, + /* + * WATCH OUT!!! these 2 handlers NEED a priority of INT_MAX (highest possible) + * cause they will ALWAYS process packets, so they must be the last one + * in chain: look fingerprintgre() above. + */ + {INT_MAX, IN, IP, &fingerprintgre, &protohandlergrein}, + {INT_MAX, OUT, IP, &fingerprintgre, &protohandlergreout}, {EOH}}; + static int + mod_handler(module_t mod, int type, void *data) + { + int error; + + switch (type) { + case MOD_LOAD: + error = 0; + attach_handlers(handlers); + break; + case MOD_UNLOAD: + error = 0; + detach_handlers(handlers); + break; + default: + error = EINVAL; + } + return (error); + } + + #ifdef _KERNEL + static + #endif + moduledata_t alias_mod = { + "alias_pptp", mod_handler, NULL + }; + + #ifdef _KERNEL + DECLARE_MODULE(alias_pptp, alias_mod, SI_SUB_DRIVERS, SI_ORDER_SECOND); + MODULE_VERSION(alias_pptp, 1); + MODULE_DEPEND(alias_pptp, libalias, 1, 1, 1); + #endif + /* Alias_pptp.c performs special processing for PPTP sessions under TCP. Specifically, watch PPTP control messages and alias the Call ID or the *************** *** 65,90 **** */ - /* Includes */ - #ifdef _KERNEL - #include - #else - #include - #include - #endif - - #include - #include - #include - #include - - #ifdef _KERNEL - #include - #include - #else - #include "alias_local.h" - #endif - /* * PPTP definitions */ --- 227,232 ---- *************** *** 153,158 **** --- 295,303 ---- static PptpCallId AliasVerifyPptp(struct ip *, u_int16_t *); + #ifdef _KERNEL + static + #endif void AliasHandlePptpOut(struct libalias *la, struct ip *pip, /* IP packet to examine/patch */ *************** *** 225,230 **** --- 370,378 ---- } } + #ifdef _KERNEL + static + #endif void AliasHandlePptpIn(struct libalias *la, struct ip *pip, /* IP packet to examine/patch */ *************** *** 328,334 **** return (PptpCallId) (hptr + 1); } ! int AliasHandlePptpGreOut(struct libalias *la, struct ip *pip) { --- 476,484 ---- return (PptpCallId) (hptr + 1); } ! #ifdef _KERNEL ! static ! #endif int AliasHandlePptpGreOut(struct libalias *la, struct ip *pip) { *************** *** 353,359 **** return (0); } ! int AliasHandlePptpGreIn(struct libalias *la, struct ip *pip) { --- 503,511 ---- return (0); } ! #ifdef _KERNEL ! static ! #endif int AliasHandlePptpGreIn(struct libalias *la, struct ip *pip) { diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_proxy.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_proxy.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_proxy.c Mon Jun 27 09:36:02 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_proxy.c Sun Jun 11 18:57:27 2006 *************** *** 60,75 **** #include #include #include #include #else #include #include #include #include #include - #include #include ! #include #endif /* BSD IPV4 includes */ --- 60,78 ---- #include #include #include + #if __FreeBSD_version < 500000 + #include + #else #include + #endif #else #include #include #include #include #include #include ! #include #endif /* BSD IPV4 includes */ *************** *** 156,161 **** --- 159,173 ---- static void ProxyEncodeIpHeader(struct ip *, int); #ifdef _KERNEL + + /* Use kernel allocator. */ + #if defined(_SYS_MALLOC_H_) + MALLOC_DECLARE(M_ALIAS); + #define malloc(x) malloc(x, M_ALIAS, M_NOWAIT|M_ZERO) + #define calloc(x, n) malloc(x*n) + #define free(x) free(x, M_ALIAS) + #endif + static int inet_aton(cp, addr) const char *cp; diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_skinny.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_skinny.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_skinny.c Mon Jun 27 09:36:02 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_skinny.c Sun Jun 11 18:57:27 2006 *************** *** 32,44 **** #ifdef _KERNEL #include #else #include #include #include #include #include - #include #endif #include --- 32,52 ---- #ifdef _KERNEL #include + #include + #include + #include + #include + #include + #include + #include + #include #else + #include #include #include #include #include #include #endif #include *************** *** 50,57 **** --- 58,130 ---- #ifdef _KERNEL #include #include + #include #else #include "alias_local.h" + #include "alias_mod.h" + #endif + + static void + AliasHandleSkinny(struct libalias *, struct ip *, struct alias_link *); + + #ifdef _KERNEL + static + #endif + int + fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (ah->dport == NULL || ah->sport == NULL || ah->lnk == NULL) + return (NOK); + if (la->skinnyPort != 0 && (ntohs(*ah->sport) == la->skinnyPort || + ntohs(*ah->dport) == la->skinnyPort)) + return (OK); + return (NOK); + } + + #ifdef _KERNEL + static + #endif + int + protohandler(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + AliasHandleSkinny(la, pip, ah->lnk); + return (OK); + } + + struct proto_handler handlers[] = {{110, IN|OUT, TCP, &fingerprint, + &protohandler}, {EOH}}; + + static int + mod_handler(module_t mod, int type, void *data) + { + int error; + + switch (type) { + case MOD_LOAD: + error = 0; + attach_handlers(handlers); + break; + case MOD_UNLOAD: + error = 0; + detach_handlers(handlers); + break; + default: + error = EINVAL; + } + return (error); + } + + #ifdef _KERNEL + static + #endif + moduledata_t alias_mod = { + "alias_skinny", mod_handler, NULL + }; + + #ifdef _KERNEL + DECLARE_MODULE(alias_skinny, alias_mod, SI_SUB_DRIVERS, SI_ORDER_SECOND); + MODULE_VERSION(alias_skinny, 1); + MODULE_DEPEND(alias_skinny, libalias, 1, 1, 1); #endif /* *************** *** 233,238 **** --- 306,314 ---- return (0); } + #ifdef _KERNEL + static + #endif void AliasHandleSkinny(struct libalias *la, struct ip *pip, struct alias_link *lnk) { diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_smedia.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_smedia.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_smedia.c Mon Jun 27 09:36:02 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_smedia.c Sun Jun 11 18:57:27 2006 *************** *** 101,107 **** --- 101,114 ---- #ifdef _KERNEL #include #include + #include + #include + #include + #include + #include + #include #else + #include #include #include #include *************** *** 116,123 **** --- 123,206 ---- #ifdef _KERNEL #include #include + #include #else #include "alias_local.h" + #include "alias_mod.h" + #endif + + #define RTSP_CONTROL_PORT_NUMBER_1 554 + #define RTSP_CONTROL_PORT_NUMBER_2 7070 + #define TFTP_PORT_NUMBER 69 + + static void + AliasHandleRtspOut(struct libalias *, struct ip *, struct alias_link *, + int maxpacketsize); + #ifdef _KERNEL + static + #endif + int + fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (ah->dport == NULL || ah->sport == NULL || ah->lnk == NULL || + ah->maxpacketsize == 0) + return (NOK); + if (ntohs(*ah->dport) == RTSP_CONTROL_PORT_NUMBER_1 + || ntohs(*ah->sport) == RTSP_CONTROL_PORT_NUMBER_1 + || ntohs(*ah->dport) == RTSP_CONTROL_PORT_NUMBER_2 + || ntohs(*ah->sport) == RTSP_CONTROL_PORT_NUMBER_2 + || ntohs(*ah->dport) == TFTP_PORT_NUMBER) + return (OK); + return (NOK); + } + + #ifdef _KERNEL + static + #endif + int + protohandler(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + if (ntohs(*ah->dport) == TFTP_PORT_NUMBER) + FindRtspOut(la, pip->ip_src, pip->ip_dst, + *ah->sport, *ah->alias_port, IPPROTO_UDP); + else AliasHandleRtspOut(la, pip, ah->lnk, ah->maxpacketsize); + return (OK); + } + + struct proto_handler handlers[] = {{100, OUT, TCP|UDP, &fingerprint, + &protohandler}, {EOH}}; + + static int + mod_handler(module_t mod, int type, void *data) + { + int error; + + switch (type) { + case MOD_LOAD: + error = 0; + attach_handlers(handlers); + break; + case MOD_UNLOAD: + error = 0; + detach_handlers(handlers); + break; + default: + error = EINVAL; + } + return (error); + } + + #ifdef _KERNEL + static + #endif + moduledata_t alias_mod = { + "alias_smedia", mod_handler, NULL + }; + + #ifdef _KERNEL + DECLARE_MODULE(alias_smedia, alias_mod, SI_SUB_DRIVERS, SI_ORDER_SECOND); + MODULE_VERSION(alias_smedia, 1); + MODULE_DEPEND(alias_smedia, libalias, 1, 1, 1); #endif #define RTSP_CONTROL_PORT_NUMBER_1 554 *************** *** 392,397 **** --- 475,483 ---- return (0); } + #ifdef _KERNEL + static + #endif void AliasHandleRtspOut(struct libalias *la, struct ip *pip, struct alias_link *lnk, int maxpacketsize) { diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_util.c /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_util.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/alias_util.c Mon Jun 27 09:36:02 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/alias_util.c Sun Jun 11 18:57:27 2006 *************** *** 45,50 **** --- 45,51 ---- #ifdef _KERNEL #include + #include #else #include #include diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/libalias.3 /home/flag/src/freebsd7/src/sys/netinet/libalias/libalias.3 *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/libalias/libalias.3 Thu Nov 24 15:17:35 2005 --- /home/flag/src/freebsd7/src/sys/netinet/libalias/libalias.3 Sun Jun 18 16:09:34 2006 *************** *** 893,898 **** --- 893,901 ---- added support for RTSP/PNA. .An Ruslan Ermilov Aq ru@FreeBSD.org added support for PPTP and LSNAT as well as general hacking. + .An Paolo Pisati Aq piso@FreeBSD.org + made the library modular, moving support for all + the protocols (except for IP, TCP and UDP) to external modules. .Sh ACKNOWLEDGMENTS Listed below, in approximate chronological order, are individuals who have provided valuable comments and/or debugging assistance. *************** *** 1011,1016 **** --- 1014,1385 ---- a unique aliasing link can be established. In an alternate operating mode, the first choice of an aliasing port is also random and unrelated to the local port number. + .Sh Modular architecture (and ipfw support) + One of the latest improvement of libalias was to make its support + for new protocols independent from the rest of the library, giving it + the ability to load/unload at runtime support for new protocols. + To achieve this feature, all the code for protocols handling was moved + to a series of modules outside of the main library. + These modules are compiled from the same source base but works in a + different ways, according if they are compiled to work inside a kernel + or as part of a user land library. + .Ss Libalias modules in kernel land + When compiled to be part of a kernel, libalias modules are plain + simple kld, installed as default with all the other kernel modules: + .Pp + .Bd -ragged -offset indent + .An -split + .An /boot/kernel/alias_cuseeme.ko + .An /boot/kernel/alias_dummy.ko + .An /boot/kernel/alias_ftp.ko + .An /boot/kernel/alias_irc.ko + .An /boot/kernel/alias_nbt.ko + .An /boot/kernel/alias_pptp.ko + .An /boot/kernel/alias_skinny.ko + .An /boot/kernel/alias_smedia.ko + .Ed + .Pp + To load a new protocol just kldload it: + .Pp + kldload alias_ftp # add support for ftp protocol to kernel libalias + .Pp + and when you don't need it anymore, you can unload it: + .Pp + kldunload alias_ftp + .Pp + .Ss Libalias modules in user land + Due to the differences between kernel and user land (no kld mechanism, + many different address spaces, etc etc), we had to change a bit how to + handle modules loading/tracking/unloading in user land. + .Pp + While compiled for a user land libalias, all the modules are installed + in /usr/lib: + .Pp + .Bd -ragged -offset indent + .An -split + .An /usr/lib/libalias_cuseeme.a + .An /usr/lib/libalias_cuseeme.so -> /lib/libalias_cuseeme.so.4 + .An /usr/lib/libalias_cuseeme_p.a + .An /usr/lib/libalias_dummy.a + .An /usr/lib/libalias_dummy.so -> /lib/libalias_dummy.so.4 + .An /usr/lib/libalias_dummy_p.a + .An /usr/lib/libalias_ftp.a + .An /usr/lib/libalias_ftp.so -> /lib/libalias_ftp.so.4 + .An /usr/lib/libalias_ftp_p.a + .An /usr/lib/libalias_irc.a + .An /usr/lib/libalias_irc.so -> /lib/libalias_irc.so.4 + .An /usr/lib/libalias_irc_p.a + .An /usr/lib/libalias_nbt.a + .An /usr/lib/libalias_nbt.so -> /lib/libalias_nbt.so.4 + .An /usr/lib/libalias_nbt_p.a + .An /usr/lib/libalias_pptp.a + .An /usr/lib/libalias_pptp.so -> /lib/libalias_pptp.so.4 + .An /usr/lib/libalias_pptp_p.a + .An /usr/lib/libalias_skinny.a + .An /usr/lib/libalias_skinny.so -> /lib/libalias_skinny.so.4 + .An /usr/lib/libalias_skinny_p.a + .An /usr/lib/libalias_smedia.a + .An /usr/lib/libalias_smedia.so -> /lib/libalias_smedia.so.4 + .An /usr/lib/libalias_smedia_p.a + .Ed + .Pp + To take advantage of modules, an application must be + patched to handle SIGHUP signal and call LibAliasRefreshModules() + whenever it receives that signal (see below for details). + .Pp + If you have correctly installed libalias, in /etc you should + find a file called libalias.conf with the following contents (or + similar): + .Pp + .Bd -ragged -offset indent + .An -split + .An /usr/lib/libalias_cuseeme.so + .An /usr/lib/libalias_ftp.so + .An /usr/lib/libalias_irc.so + .An /usr/lib/libalias_nbt.so + .An /usr/lib/libalias_pptp.so + .An /usr/lib/libalias_skinny.so + .An /usr/lib/libalias_smedia.so + .Ed + .Pp + this file contains the paths to the modules that libalias will load. + To load/unload a new module just add its path to libalias.conf and + send a SIGHUP signal to the application that needs the new module: + .Pp + kill -HUP + .Pp + .Sh Modular architecture: how it works + The modular architecture of libalias work (almost) the same when it's + running inside kernel or in user land. From alias_mod.c: + .Bd -literal + /* protocol and user land module handlers chains */ + struct chain handler_chain, dll_chain; + + handler_chain keep tracks of all the protocol handlers loaded, while + ddl_chain takes care of userland modules loaded. + + handler_chain is composed of struct proto_handler entries: + + struct proto_handler { + + /* handler priority */ + int pri; + /* flow direction */ + int16_t dir; + /* working protocol */ + int16_t proto; + /* fingerprint * function */ + int (*fingerprint)(struct libalias *la, + struct ip *pip, struct alias_data *ah); + /* aliasing * function */ + int (*protohandler)(struct libalias *la, + struct ip *pip, struct alias_data *ah); + struct proto_handler *next; + }; + .Ed + .Pp + where: + .Pp + pri is the priority assigned to a protocol handler, lower + is better. + .Pp + dir is the direction of packets: ingoing or outgoing. + .Pp + proto says at which protocol this packet belongs: IP, TCP or UDP + .Pp + fingerprint points to the fingerprint function while protohandler points + to the protocol handler function. + .Pp + The fingerprint function has the double of scope of checking if the + incoming packet is sound and if it belongs to any categories that this + module can handle. + .Pp + The protocol handler function is the function that actually manipulates + the packet to make libalias correctly nat it. + .Pp + When a packet enters libalias, if it meets a module hook, + libalias scan handler_chain to see if there's an handler that match + this type of packet (it checks protocol and direction of packet), then if + more then one handler is found, it starts with the module with + a lower priority number: it calls fingerprints and read the result. + .Pp + If the result value is equal to OK, then it calls the protocol handler + of this handler and return, else it skip to the fingerprint function + of the next eligible module, till the end of handler_chain + .Pp + Inside libalias, the module hook looks like this: + .Bd -literal + struct alias_data ad = { + lnk, + &original_address, + &alias_address, + &alias_port, + &ud->uh_sport, /* original source port */ + &ud->uh_dport, /* original dest port */ + 256 /* maxpacketsize */ + }; + + ... + + /* walk out chain */ + err = find_handler(IN, UDP, la, pip, &ad); + if (err == EHDNOF) + ; + .Ed + all data useful to a module are gathered together in a alias_data + structure, then find_handler is called. + find_handler is the function responsible of walking out the handler + chain, it receives as input parameters: + .Pp + IN: direction + .Pp + UDP: working protocol + .Pp + la: pointer to this instance of libalias + .Pp + pip: pointer to a struct ip + .Pp + ad: pointer to struct alias_data (see above) + .Pp + in this case, find_handler will search only for modules registered for + supporting INcoming UDP packets. + .Pp + As i said earlier, libalias in userland is a bit different, cause we + have to take care of module handling too (avoiding duplicate load of + module, avoiding module with same name, etc etc) so dll_chain was + introduced. + .Pp + dll_chain contains a list of all user land libalias modules loaded. + .Pp + When an application calls LibAliasRefreshModules(), libalias first unload + all the loaded modules, then reload all the modules listed in + /etc/libalias.conf: for every module loaded, a new entry to dll_chain + is added. + .Pp + dll_chain is composed of struct dll entries: + .Bd -literal + struct dll { + /* name of module */ + char name[DLL_LEN]; + /* + * ptr to shared obj obtained through + * dlopen() - use this ptr to get access + * to any symbols from a loaded module + * via dlsym() + */ + void *handle; + struct dll *next; + }; + .Ed + name is the name of the module + .Pp + handle is a pointer to the module obtained through dlopen() + .Pp + Whenever a module is loaded in user land, an entry is added to + dll_chain, than every protocol handler present in that module + is resolved and registered in handler_chain. + .Ss How to write a module for libalias + There's a module (called alias_dummy.[ch]) in libalias that can be + used as a skeleton for future work, here we analyse some parts of that + module. + From alias_dummy.c: + .Bd -literal + struct proto_handler handlers [] = {{666, IN|OUT, UDP|TCP, + &fingerprint, &protohandler}}; + .Ed + .Pp + The variable 'handlers' is the 'most important thing' in your module, + cause it describes the handlers present and let the outside world use + it in an opaque way. + .Pp + It must ALWAYS be present in every module, and it MUST retain + the name 'handlers', else if you'll try to load + this module in userland, it will complain about missing symbols: for + more info about module load/unload, please refer to + LibAliasRefreshModules, LibAliasLoadModule and LibAliasUnloadModule in + alias.c + .Pp + handlers[] contains all the proto_handler structures present in a + module. + .Bd -literal + static int + mod_handler(module_t mod, int type, void *data) + { + int error; + + switch (type) { + case MOD_LOAD: + error = 0; + attach_handlers(handlers); + break; + case MOD_UNLOAD: + error = 0; + detach_handlers(handlers; + break; + default: + error = EINVAL; + } + return (error); + } + .Ed + When running as kld, mod_handler register/deregister the module using + attach_handlers/detach_handlers respectively. + .Pp + Every module must contain at least 2 functions: one fingerprint + function and a protocol handler function. + .Bd -literal + #ifdef _KERNEL + static + #endif + int + fingerprint(struct libalias *la, struct ip *pip, struct alias_data *ah) { + + ... + } + + #ifdef _KERNEL + static + #endif + int + protohandler(struct libalias *la, struct ip *pip, + struct alias_data *ah) { + + ... + } + .Ed + and they must accept exactly these input parameters. + .Ss Patching an application for user land libalias modules + If you have any application that uses libalias and you want to add it + support for libalias modules, then follow this simple 5 steps + procedure. + .Bd -ragged -offset indent + .An -split + .An 1) first, figure out which file is the main file of your program + .An (let's call it main.c) + + .An 2) add this to the header section of main,c, if not already + .An present: + .Pp + .An #include + .Pp + .An 3) and this just after the header section: + .Pp + .An static void signal_handler(int); + .Pp + .An 4) add this line in the init function of you program or, if it + .An doesn't have any init function, put it in main(): + .Pp + .An signal(SIGHUP, signal_handler); + .Pp + .An 5) and place this function somewhere in main.c: + .Pp + .An static void + .An signal_handler(int sig) { + .Pp + .An LibAliasRefreshModules(); + .An } + .Pp + .An else, if your program already trap SIGHUP signal, just add a call + .An to LibAliasRefreshModules() in the function serving that signal. + .Pp + .An For example, to patch natd to use libalias modules, just add + .An the following line to RefreshAddr (int sig __unused): + .Pp + .An LibAliasRefreshModules() + .Pp + .An recompile and you are done. + .Ed + .Pp + .Ss Logging support in kernel land + .Pp + While working as kld, libalias now have log support that + happens on a buffer allocated inside struct libalias(from alias_local.h): + .Bd -literal + struct libalias { + ... + + /* log descriptor */ + #ifdef KERNEL_LOG + char *logDesc; /* + * ptr to an auto-malloced + * memory buffer when libalias + * works as kld + */ + #else + FILE *logDesc; /* + * ptr to /var/log/alias.log + * when libalias runs as a + * userland lib + */ + #endif + + ... + } + .Ed + so all the applications using libalias, will be able to handle their + own logs, if they want, accessing logDesc. + Moreover, every change to log buffer is automatically added to syslog + with facilities security and info. .Sh BUGS PPTP aliasing does not work when more than one internal client connects to the same external server at the same time, because diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/sys/netinet/raw_ip.c /home/flag/src/freebsd7/src/sys/netinet/raw_ip.c *** /home/flag/src/freebsd7_vanilla/src/sys/netinet/raw_ip.c Sun May 21 21:28:46 2006 --- /home/flag/src/freebsd7/src/sys/netinet/raw_ip.c Sun Jun 11 18:57:27 2006 *************** *** 378,383 **** --- 378,385 ---- case IP_FW_GET: case IP_FW_TABLE_GETSIZE: case IP_FW_TABLE_LIST: + case IP_FW_NAT_GET_CONFIG: + case IP_FW_NAT_GET_LOG: error = suser(curthread); if (error != 0) return (error); *************** *** 443,448 **** --- 445,452 ---- case IP_FW_TABLE_ADD: case IP_FW_TABLE_DEL: case IP_FW_TABLE_FLUSH: + case IP_FW_NAT_CFG: + case IP_FW_NAT_DEL: error = suser(curthread); if (error != 0) return (error); diff -rNPc --exclude=CVS /home/flag/src/freebsd7_vanilla/src/usr.sbin/ppp/main.c /home/flag/src/freebsd7/src/usr.sbin/ppp/main.c *** /home/flag/src/freebsd7_vanilla/src/usr.sbin/ppp/main.c Tue Dec 21 12:12:05 2004 --- /home/flag/src/freebsd7/src/usr.sbin/ppp/main.c Sun Jun 11 18:57:27 2006 *************** *** 328,333 **** --- 328,334 ---- #ifndef NONAT PacketAliasInit(); + LibAliasRefreshModules(); #endif label = ProcessArgs(argc, argv, &sw); --wac7ysb48OaltWcw-- From owner-freebsd-net@FreeBSD.ORG Sun Jun 18 18:09:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81F8C16A479 for ; Sun, 18 Jun 2006 18:09:58 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from rune.pobox.com (rune.pobox.com [208.210.124.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16C3B43D45 for ; Sun, 18 Jun 2006 18:09:58 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id BF7347A51D; Sun, 18 Jun 2006 14:10:18 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 1283A7A51B; Sun, 18 Jun 2006 14:10:16 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1Fs1iZ-0009fU-Tz; Sun, 18 Jun 2006 19:09:52 +0100 Date: Sun, 18 Jun 2006 19:09:51 +0100 From: Brian Candler To: Nash Nipples Message-ID: <20060618180951.GA37133@uk.tiscali.com> References: <4495530f.265f68ff.360d.48fa@mx.gmail.com> <20060618142644.81731.qmail@web36304.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060618142644.81731.qmail@web36304.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Simple LAN IP accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jun 2006 18:09:58 -0000 On Sun, Jun 18, 2006 at 07:26:44AM -0700, Nash Nipples wrote: > ipfw add 5 skipto 500 ip from 192.168.110.1 to any out via tun0 > ipfw add 10 skipto 500 ip from any to 192.168.110.1 to any in via tun0 > ipfw add .. skipto 500 ip from 192.168.110... to any out via tun0 > ... > ipfw add 500 divert from any to any in via tun0 #back to normal rules > > ipfw show > 00005 274943 64986791 ip from 192.168.110.1 to any out via tun0 > 00010 274943 64986791 ip from any to 192.168.110.1 in via tun0 > > thats pretty stupid but works. and you need a program to proccess the output > thats what im working on time to time :) > > it doesnt overload the filter cuz a matching rule is passed once at a time and the unmatched skipped to normal rules. if you get out of ipfw rules limits you might consider to split.. lol > > anyone else? Another approach is to capture absolutely everything using libpcap into a userland process, and then post-process afterwards. This is how 'ntop' works. At a very simplistic level you could just use tcpdump -w to capture the packets (or packet headers) into a file, and then tcpdump -r to pipe them into a script to analyse them, such as totalising the sizes of all packets to/from a particular IP address. Another approach is to use statistical sampling - pick packets at random, so that overall you capture, say, 1 packet in 128, and analyse those. This is the approach used by sflow. If you have an sflow-capable switch, this is a very efficient way of doing this analysis. You can turn the sflow data into simple CSV records using 'sflowtool', or ntop has an sflow module. This assumes that taking the sampled data and multiplying it by 128 will be sufficiently accurate for your purposes, of course. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Sun Jun 18 18:21:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9CA916A47A for ; Sun, 18 Jun 2006 18:21:57 +0000 (UTC) (envelope-from regnauld@macbook.catpipe.net) Received: from macbook.catpipe.net (x0.dk [62.242.165.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7410D43D45 for ; Sun, 18 Jun 2006 18:21:57 +0000 (GMT) (envelope-from regnauld@macbook.catpipe.net) Received: by macbook.catpipe.net (Postfix, from userid 1001) id D89D8CD692; Sun, 18 Jun 2006 20:21:51 +0200 (CEST) Date: Sun, 18 Jun 2006 20:21:51 +0200 From: Phil Regnauld To: Brian Candler Message-ID: <20060618182151.GB2627@catpipe.net> References: <4495530f.265f68ff.360d.48fa@mx.gmail.com> <20060618142644.81731.qmail@web36304.mail.mud.yahoo.com> <20060618180951.GA37133@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060618180951.GA37133@uk.tiscali.com> X-Operating-System: Darwin 8.6.1 i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Nash Nipples Subject: Re: Simple LAN IP accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jun 2006 18:21:57 -0000 Brian Candler (B.Candler) writes: > > Another approach is to capture absolutely everything using libpcap into a > userland process, and then post-process afterwards. ports/net/ipfm - been using it for some years now. > Another approach is to use statistical sampling - pick packets at random, so > that overall you capture, say, 1 packet in 128, and analyse those. This is > the approach used by sflow. One can also achieve this using good old netflow -- there's a boatload of netflow collectors -- and probes as well, see ng_netflow. > very efficient way of doing this analysis. You can turn the sflow data into > simple CSV records using 'sflowtool', or ntop has an sflow module. Ntop just seems very unreliable and bloated to me, at least after version 1. Has it changed ? > This assumes that taking the sampled data and multiplying it by 128 will be > sufficiently accurate for your purposes, of course. +/- 2% according to some large ISPs who use it, which is apparently considers acceptable. From owner-freebsd-net@FreeBSD.ORG Sun Jun 18 19:40:50 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13FBD16A474; Sun, 18 Jun 2006 19:40:50 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93D4643D53; Sun, 18 Jun 2006 19:40:48 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (og7r2qmqpfp7cv9u@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k5IJemLd074135; Sun, 18 Jun 2006 12:40:48 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k5IJejCW074134; Sun, 18 Jun 2006 12:40:45 -0700 (PDT) (envelope-from jmg) Date: Sun, 18 Jun 2006 12:40:44 -0700 From: John-Mark Gurney To: John Polstra Message-ID: <20060618194044.GC1142@funkthat.com> Mail-Followup-To: John Polstra , Robert Watson , freebsd-net@FreeBSD.org References: <20060615115738.J2512@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-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, Robert Watson Subject: Re: IF_HANDOFF vs. IFQ_HANDOFF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 19:40:50 -0000 John Polstra wrote this message on Thu, Jun 15, 2006 at 09:18 -0700: > in the HW but have not yet completed. When the completion interrupt > comes in, the driver is supposed to check the if_snd queue for more > mbufs and process them. Only when the transmit side of the HW goes > totally idle should IFF_OACTIVE be cleared again. Most of our drivers > set the flag only when they run out of transmit descriptors (i.e., > practically never), which is just plain wrong. But the problem is that for small packets, this can mean that there will be a delay in handling the ring if we wait to process packets once the tx ring is empty.. if we ever want to max out gige w/ 64byte packets, we have to clear OACTIVE whenever tx approches running out of packets before we can send this.. In most cases we don't know how long that is (since we don't keep track of packet sizes, etc), so it's easiest/best to clear it whenever the tx ring is not full... Please read the archive of when I changed if_re to use this "correct" intereptation of OACTIVE and the fall out because of it first... -- 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 Sun Jun 18 20:54:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A08E16A479 for ; Sun, 18 Jun 2006 20:54:23 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D17343D46 for ; Sun, 18 Jun 2006 20:54:23 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 3488028D87; Sun, 18 Jun 2006 16:54:22 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id EABFC551E3; Sun, 18 Jun 2006 16:54:19 -0400 (EDT) Received: from brian by mappit.local.linnet.org with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1Fs4Hi-0009m3-E4; Sun, 18 Jun 2006 21:54:18 +0100 Date: Sun, 18 Jun 2006 21:54:18 +0100 From: Brian Candler To: Phil Regnauld Message-ID: <20060618205418.GA37548@uk.tiscali.com> References: <4495530f.265f68ff.360d.48fa@mx.gmail.com> <20060618142644.81731.qmail@web36304.mail.mud.yahoo.com> <20060618180951.GA37133@uk.tiscali.com> <20060618182151.GB2627@catpipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060618182151.GB2627@catpipe.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, Nash Nipples Subject: Re: Simple LAN IP accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jun 2006 20:54:23 -0000 On Sun, Jun 18, 2006 at 08:21:51PM +0200, Phil Regnauld wrote: > > very efficient way of doing this analysis. You can turn the sflow data into > > simple CSV records using 'sflowtool', or ntop has an sflow module. > > Ntop just seems very unreliable and bloated to me, at least after > version 1. Has it changed ? I don't know. I looked at it briefly recently, but it didn't do what I wanted (which was to be able to export and analyse *all* flows seen). At least, there was an "export" function, but it was broken. If you just want something to visualize your top 20 traffic sources and protocols, i.e. keep an eye on your network and notice sudden new large sources such as viruses or P2P nodes, it may be useful. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Sun Jun 18 21:59:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66BBF16A47F for ; Sun, 18 Jun 2006 21:59:06 +0000 (UTC) (envelope-from olsson@puffy.nu) Received: from mail-srv1.teleservice.net (mail-srv1.teleservice.net [85.30.129.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF6D243D49 for ; Sun, 18 Jun 2006 21:59:04 +0000 (GMT) (envelope-from olsson@puffy.nu) Received: from [85.30.133.54] by mail-srv1.sydskane.nu (GMS 11.01.3365/NU2793.00.3c1025a7) with SMTP id dtaksgaa for freebsd-net@freebsd.org; Sun, 18 Jun 2006 23:58:59 +0200 Message-ID: <06f801c69322$5f8969d0$0800a8c0@kaka> From: "Philip Olsson" To: "Brian Candler" , "Phil Regnauld" References: <4495530f.265f68ff.360d.48fa@mx.gmail.com><20060618142644.81731.qmail@web36304.mail.mud.yahoo.com><20060618180951.GA37133@uk.tiscali.com><20060618182151.GB2627@catpipe.net> <20060618205418.GA37548@uk.tiscali.com> Date: Sun, 18 Jun 2006 23:58:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Cc: freebsd-net@freebsd.org, Nash Nipples Subject: Re: Simple LAN IP accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jun 2006 21:59:06 -0000 > On Sun, Jun 18, 2006 at 08:21:51PM +0200, Phil Regnauld wrote: >> > very efficient way of doing this analysis. You can turn the sflow data >> > into >> > simple CSV records using 'sflowtool', or ntop has an sflow module. >> >> Ntop just seems very unreliable and bloated to me, at least after >> version 1. Has it changed ? > > I don't know. I looked at it briefly recently, but it didn't do what I > wanted (which was to be able to export and analyse *all* flows seen). At > least, there was an "export" function, but it was broken. > > If you just want something to visualize your top 20 traffic sources and > protocols, i.e. keep an eye on your network and notice sudden new large > sources such as viruses or P2P nodes, it may be useful. > Ntop is horribly unstable if you push some traffic. The memory usage increases and then later on crashes. It does not matter if you use libpcap or netflow. Something in the design seems wrong. I tested it recently and a year ago, same problem. The system does not run out of resources. // Philip From owner-freebsd-net@FreeBSD.ORG Sun Jun 18 22:15:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30D3916A47B for ; Sun, 18 Jun 2006 22:15:19 +0000 (UTC) (envelope-from yb@bashibuzuk.net) Received: from a.6f2.net (a.6f2.net [213.189.5.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6E0943D48 for ; Sun, 18 Jun 2006 22:15:18 +0000 (GMT) (envelope-from yb@bashibuzuk.net) Received: by a.6f2.net (Postfix, from userid 66) id 1E999BF90BF; Mon, 19 Jun 2006 00:15:17 +0200 (CEST) Received: by cc.bashibuzuk.net (Postfix, from userid 1001) id 9E9D7C0E6; Mon, 19 Jun 2006 00:15:15 +0200 (CEST) Date: Mon, 19 Jun 2006 00:15:15 +0200 From: Yann Berthier To: "Roger T. Harvey" Message-ID: <20060618221515.GA1557@bashibuzuk.net> References: <4495530f.265f68ff.360d.48fa@mx.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4495530f.265f68ff.360d.48fa@mx.gmail.com> X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: Simple LAN IP accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Jun 2006 22:15:19 -0000 On Sun, 18 Jun 2006, at 09:20, Roger T. Harvey wrote: > Ok, I've done research, and found this example to track bytes per ip on LAN: As suggested, ng_netflow() coupled with net-mgmt/nfdump may well do what you need. net-mgmt/nfsen on top of that if you change your mind regarding graphs. good luck, - yan From owner-freebsd-net@FreeBSD.ORG Mon Jun 19 02:24:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1CB816A474 for ; Mon, 19 Jun 2006 02:24:59 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyadd226.zyxel.com.tw (zyadd226.zyxel.com.tw [61.222.65.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACB8F43D45 for ; Mon, 19 Jun 2006 02:24:56 +0000 (GMT) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by smtp.zyxel.com.tw with InterScan Messaging Security Suite; Mon, 19 Jun 2006 10:08:52 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 10:00:40 +0800 Received: from [172.23.18.2] ([172.23.18.2]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 10:00:39 +0800 Message-ID: <449604D0.8090701@zyxel.com.tw> Date: Mon, 19 Jun 2006 09:58:40 +0800 From: Blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2006 02:00:39.0912 (UTC) FILETIME=[2A0BE680:01C69344] Subject: [freeBSD-6.1RELEASE] wonderings about function tcp_input() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jun 2006 02:24:59 -0000 Hi, all: I have a question about line 1765 to 1776 in tcp_input(): /* * If the ACK bit is off: if in SYN-RECEIVED state or SENDSYN * flag is on (half-synchronized state), then queue data for * later processing; else drop segment and return. */ if ((thflags & TH_ACK) == 0) { if (tp->t_state == TCPS_SYN_RECEIVED || (tp->t_flags & TF_NEEDSYN)) goto step6; else goto drop; } My question is: if we are currently in TCPS_SYN_RECEIVED state, why does a segment without ACK bother? Why we need to store the segment and process it? Without considering T/TCP, the code should be: if ((thflags & TH_ACK) == 0) { goto drop; } Best regards, blue From owner-freebsd-net@FreeBSD.ORG Mon Jun 19 07:21:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 698AE16A47A for ; Mon, 19 Jun 2006 07:21:21 +0000 (UTC) (envelope-from trashy_bumper@yahoo.com) Received: from web36304.mail.mud.yahoo.com (web36304.mail.mud.yahoo.com [209.191.84.234]) by mx1.FreeBSD.org (Postfix) with SMTP id C38B443D46 for ; Mon, 19 Jun 2006 07:21:20 +0000 (GMT) (envelope-from trashy_bumper@yahoo.com) Received: (qmail 20542 invoked by uid 60001); 19 Jun 2006 07:21:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fA2QjYnZ+1t5tBkBpRpSQY2GPPrhNsrBuTiRGjsIccqrZxtbnoXt5eqH5CITbX8UfP8UtHYOJLUN+QJNQF9+qcgPy6TjogfZm3nKot3z1opHBtkTaWoGgSKAUhZZ1Swie3YAhRONjPw4w5UMAxhMhS16Awg6CETqisSjRHybHHE= ; Message-ID: <20060619072120.20540.qmail@web36304.mail.mud.yahoo.com> Received: from [213.227.206.11] by web36304.mail.mud.yahoo.com via HTTP; Mon, 19 Jun 2006 00:21:20 PDT Date: Mon, 19 Jun 2006 00:21:20 -0700 (PDT) From: Nash Nipples To: freebsd-net@freebsd.org In-Reply-To: <20060618180951.GA37133@uk.tiscali.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Simple LAN IP accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jun 2006 07:21:21 -0000 Oh come on guys, are we talking about accounting or packets sniffing? if so, i believe that tcpdump should be rewritten into tcpacc with no ability to see packets. and make it more flexible. i believe there are number of reasons why guys at FreeBSD do not document the traffic accounting process. They not just 'missed out' the matter for so many years. That could be because 1. Its Free, so if you want to make profit you better invest into commercial applications. 2. There is no standard approach to satisfy everyone's needs and security considerations for automated hijacking of resources as soon as standard is derived. 3. at this point you should really be able to make it what you want it to be. Ofcourse we can end up blaming all the ports because the authors shared what they did and left the sources for people who need them different. I also believe that a custom accounting program would be a big deal of programming experience handling strings, streams, various types of data and pretty formatted output with no limits but time against needs and talk against deeds. nash p.s. i like to write this crap lol! Brian Candler wrote: On Sun, Jun 18, 2006 at 07:26:44AM -0700, Nash Nipples wrote: > ipfw add 5 skipto 500 ip from 192.168.110.1 to any out via tun0 > ipfw add 10 skipto 500 ip from any to 192.168.110.1 to any in via tun0 > ipfw add .. skipto 500 ip from 192.168.110... to any out via tun0 > ... > ipfw add 500 divert from any to any in via tun0 #back to normal rules > > ipfw show > 00005 274943 64986791 ip from 192.168.110.1 to any out via tun0 > 00010 274943 64986791 ip from any to 192.168.110.1 in via tun0 > > thats pretty stupid but works. and you need a program to proccess the output > thats what im working on time to time :) > > it doesnt overload the filter cuz a matching rule is passed once at a time and the unmatched skipped to normal rules. if you get out of ipfw rules limits you might consider to split.. lol > > anyone else? Another approach is to capture absolutely everything using libpcap into a userland process, and then post-process afterwards. This is how 'ntop' works. At a very simplistic level you could just use tcpdump -w to capture the packets (or packet headers) into a file, and then tcpdump -r to pipe them into a script to analyse them, such as totalising the sizes of all packets to/from a particular IP address. Another approach is to use statistical sampling - pick packets at random, so that overall you capture, say, 1 packet in 128, and analyse those. This is the approach used by sflow. If you have an sflow-capable switch, this is a very efficient way of doing this analysis. You can turn the sflow data into simple CSV records using 'sflowtool', or ntop has an sflow module. This assumes that taking the sampled data and multiplying it by 128 will be sufficiently accurate for your purposes, of course. Regards, Brian. --------------------------------- Yahoo! Groups gets better. Check out the new email design. Plus there’s much more to come. From owner-freebsd-net@FreeBSD.ORG Mon Jun 19 08:04:34 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5095016A479; Mon, 19 Jun 2006 08:04:34 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC700440E8; Mon, 19 Jun 2006 08:04:33 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 8C1CD329330; Mon, 19 Jun 2006 18:04:30 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5J84QxG025511; Mon, 19 Jun 2006 18:04:27 +1000 Date: Mon, 19 Jun 2006 18:04:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John-Mark Gurney In-Reply-To: <20060618194044.GC1142@funkthat.com> Message-ID: <20060619162819.F44832@delplex.bde.org> References: <20060615115738.J2512@fledge.watson.org> <20060618194044.GC1142@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, Robert Watson , John Polstra Subject: Re: IF_HANDOFF vs. IFQ_HANDOFF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jun 2006 08:04:34 -0000 On Sun, 18 Jun 2006, John-Mark Gurney wrote: > John Polstra wrote this message on Thu, Jun 15, 2006 at 09:18 -0700: >> in the HW but have not yet completed. When the completion interrupt >> comes in, the driver is supposed to check the if_snd queue for more >> mbufs and process them. Only when the transmit side of the HW goes >> totally idle should IFF_OACTIVE be cleared again. Most of our drivers >> set the flag only when they run out of transmit descriptors (i.e., >> practically never), which is just plain wrong. > > But the problem is that for small packets, this can mean that there > will be a delay in handling the ring if we wait to process packets > once the tx ring is empty.. if we ever want to max out gige w/ 64byte > packets, we have to clear OACTIVE whenever tx approches running out > of packets before we can send this.. In most cases we don't know how > long that is (since we don't keep track of packet sizes, etc), so it's > easiest/best to clear it whenever the tx ring is not full... To max out the link without unmaxing CPU for other uses, you do have to know when the tx approaches running out of packets. This is best done using watermark stuff. There should be a nearly-complete interrupt at low water, and (only after low water is reached and the interrupt handler doesn't refill the tx ring to be above low water again) a completion interrupt at actual completion. My version of the sk driver does this. It arrange for the nearly-complete interrupt at about 32 fragments (min 128 uS) before the tx runs dry, and no other tx interrupts unless the queue length stays below 32, while the -current driver gets an interrupt after every packet. It does this mainly to reduce the tx interrupt load from 1 per packet to (under load) 1 per 480 fragments. The correct handling of OACTIVE is obtained as a side effect almost automatically. It must be decided when to interrupt (sk hardware allows interrupting or not interrupting after every fragment), and it would be obviously wrong to interrupt only after the last fragment in the ring since the tx might run dry then (even if the tx interrupt occurs when the last fragment is removed by the hardware from the ring but before it is sent, it only takes a few uS to send it so the tx would often run dry due to software latency). I'm not very familiar with NIC hardware and don't know how other NICs support timing of tx interrupts, but watermark stuff like the above is routine for serial devices/drivers. sk's support for interrupting on any fragment is too flexible to be good (it is painful to program, and there doesn't seem to be a good way to time out if there is no good fragment to interrupt on or when you program the interruption on a wrong fragment). Related serial device programming: 8250-16650 UARTs interrupt when the last character is removed from the tx "ring". This is not programmable, but the delay is long enough at low speeds (87 uS at 115200 bps). The 16950 UART has a programmable tx interrupt trigger level which defaults to 1 character time. The delay from this is too short at higher speeds (11 uS at 921600 bps...). I use 16. The "tx" ring size of a 16950 is 128 characters. Timing for characters in a UART at 921600 bps is similar to timing for normal packets in 1G bps ethernet (1G/921600 ~= 1K ~= 1500+ normal ethernet packet size), so similar ring sizes and trigger levels are good (smaller ones would be better for smaller packets). Strangely, at 921600 bps, the tx trigger levels become more critical for maxing out the device than the rx trigger levels, since rx is forced to keep up by the external device (provided that maxes out the connection and it is possible to keep up), while poorly chosen tx trigger levels ensure significant dead time when the tx runs dry. BTW, I can't see any significant effect (good or bad) from sk's interrupt moderation, at least with tx changed as above. sk's interrupt moderation is very primitive compared with that of some NICs (it's just a single timer for tx and rx). Interrupting on every packet gives too many interrupts, and my changes fix this much better than any simple timeout-based moderation could do. My changes don't help at all for rx, and interrupt moderation doesn't seem to help either. OTOH, fxp's interrupt moderation works well in practice (I don't know how) and em's interrupt moderation works well in theory (I understand its documentation but haven't used any em devices). em has several independent trigger levels and timeouts, and the problem of using them effectively for rx is one of predicting future traffic. IIRC, em has sysctls to move this problem to the user. In the current sk driver, I think keeping IFF_OACTIVE set for longer would work, and you can also keep track of the queue lenghth, because of the excessive interrupts -- you get an interrupt after every packet (modulo interrupt moderation), not just on completion, and the interrupt handler can both keep the h/w queue full while IFF_OACTIVE is set and keep track of the queue length as needed for deciding when to set IFF_OACTIVE. The CPU usage is thus large no matter whether IFF_ACTIVE is set correctly. Interrupt moderation complicates things and unmaxes the link. The interrupt moderation timeout is normally set to 100 uS. This allows significant tx-dry times (the worst case (if IFF_OACTIVE is not set incorrectly) is sending a tnygram in 4uS, idling for ~96 uS, ...) but isn't very moderate since sending or receiving a normal packet takes about 15uS. I think the interrupt moderation timeout for sk is purely periodic, while for better hardware (even 16550 UARTs!) at least rx timeouts only occur after the device (in the relevant direction) has been idle for some time. Bruce From owner-freebsd-net@FreeBSD.ORG Mon Jun 19 09:47:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9567E16A479 for ; Mon, 19 Jun 2006 09:47:07 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyadd226.zyxel.com.tw (zyadd226.zyxel.com.tw [61.222.65.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 170AF43D48 for ; Mon, 19 Jun 2006 09:47:02 +0000 (GMT) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by smtp.zyxel.com.tw with InterScan Messaging Security Suite; Mon, 19 Jun 2006 17:55:11 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 17:46:59 +0800 Received: from [172.23.18.2] ([172.23.18.2]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 17:46:58 +0800 Message-ID: <4496721C.5030008@zyxel.com.tw> Date: Mon, 19 Jun 2006 17:45:00 +0800 From: Blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2006 09:46:58.0946 (UTC) FILETIME=[4ED9AE20:01C69385] Subject: [FreeBSD-6.1RELEASE] tcp in TIME_WAIT state X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jun 2006 09:47:07 -0000 Hi, all: In function tcp_timewait(), which will be called when receiving a segment as current TCP state at TIME_WAIT. However, in the body of the function definition, it simply goes to "drop" before generating RST or RST/ACK towards the unicast source. Is the behavior correct because the followed codes (from line 2228 to line 3261) would never be reached! Best regards, blue From owner-freebsd-net@FreeBSD.ORG Mon Jun 19 11:03:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBD4616A537 for ; Mon, 19 Jun 2006 11:03:01 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4BF043D45 for ; Mon, 19 Jun 2006 11:03:01 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5JB319N064250 for ; Mon, 19 Jun 2006 11:03:01 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5JB30jH064245 for freebsd-net@freebsd.org; Mon, 19 Jun 2006 11:03:00 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 19 Jun 2006 11:03:00 GMT Message-Id: <200606191103.k5JB30jH064245@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 11:03:02 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro f [2006/02/12] kern/93220 net [inet6] nd6_lookup: failed to add route f 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2006/04/03] kern/95267 net packet drops periodically appear 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 19 12:28:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9450F16A482 for ; Mon, 19 Jun 2006 12:28:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E16343D73 for ; Mon, 19 Jun 2006 12:27:57 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so560163nzf for ; Mon, 19 Jun 2006 05:27:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Ltz+dozSvOvU/JWOozPSUjLDMngm4qbde9qJkke4fBUeURPNDi2i4nK2LmNV1NmRWlsHI3SrUfKUAi4GT3BTB4yNPYM1BrqFr7YOb/fBzib6qlytXxie/Vkdy7N8Uyj/Ga5TWM5FhdbvMLwKKMUIwMMuWv6fqEP6lAUTG1KY/o8= Received: by 10.36.250.42 with SMTP id x42mr7384937nzh; Mon, 19 Jun 2006 05:27:57 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 14sm3249363nzp.2006.06.19.05.27.54; Mon, 19 Jun 2006 05:27:56 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k5JCRvuO006745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jun 2006 21:27:57 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k5JCRrIB006744; Mon, 19 Jun 2006 21:27:53 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 19 Jun 2006 21:27:53 +0900 From: Pyun YongHyeon To: Bruce Evans Message-ID: <20060619122753.GA5600@cdnetworks.co.kr> References: <20060615115738.J2512@fledge.watson.org> <20060618194044.GC1142@funkthat.com> <20060619162819.F44832@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060619162819.F44832@delplex.bde.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.org, John-Mark Gurney , Robert Watson , John Polstra Subject: Re: IF_HANDOFF vs. IFQ_HANDOFF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 12:28:16 -0000 On Mon, Jun 19, 2006 at 06:04:26PM +1000, Bruce Evans wrote: > On Sun, 18 Jun 2006, John-Mark Gurney wrote: > > >John Polstra wrote this message on Thu, Jun 15, 2006 at 09:18 -0700: > >>in the HW but have not yet completed. When the completion interrupt > >>comes in, the driver is supposed to check the if_snd queue for more > >>mbufs and process them. Only when the transmit side of the HW goes > >>totally idle should IFF_OACTIVE be cleared again. Most of our drivers > >>set the flag only when they run out of transmit descriptors (i.e., > >>practically never), which is just plain wrong. > > > >But the problem is that for small packets, this can mean that there > >will be a delay in handling the ring if we wait to process packets > >once the tx ring is empty.. if we ever want to max out gige w/ 64byte > >packets, we have to clear OACTIVE whenever tx approches running out > >of packets before we can send this.. In most cases we don't know how > >long that is (since we don't keep track of packet sizes, etc), so it's > >easiest/best to clear it whenever the tx ring is not full... > > To max out the link without unmaxing CPU for other uses, you do have > to know when the tx approaches running out of packets. This is best > done using watermark stuff. There should be a nearly-complete interrupt > at low water, and (only after low water is reached and the interrupt > handler doesn't refill the tx ring to be above low water again) a > completion interrupt at actual completion. My version of the sk driver > does this. It arrange for the nearly-complete interrupt at about 32 > fragments (min 128 uS) before the tx runs dry, and no other tx interrupts > unless the queue length stays below 32, while the -current driver gets > an interrupt after every packet. It does this mainly to reduce the > tx interrupt load from 1 per packet to (under load) 1 per 480 fragments. > The correct handling of OACTIVE is obtained as a side effect almost > automatically. It must be decided when to interrupt (sk hardware > allows interrupting or not interrupting after every fragment), and it > would be obviously wrong to interrupt only after the last fragment in > the ring since the tx might run dry then (even if the tx interrupt > occurs when the last fragment is removed by the hardware from the ring > but before it is sent, it only takes a few uS to send it so the tx > would often run dry due to software latency). > > I'm not very familiar with NIC hardware and don't know how other NICs > support timing of tx interrupts, but watermark stuff like the above > is routine for serial devices/drivers. sk's support for interrupting > on any fragment is too flexible to be good (it is painful to program, > and there doesn't seem to be a good way to time out if there is no > good fragment to interrupt on or when you program the interruption on > a wrong fragment). > > Related serial device programming: 8250-16650 UARTs interrupt when the > last character is removed from the tx "ring". This is not programmable, > but the delay is long enough at low speeds (87 uS at 115200 bps). The > 16950 UART has a programmable tx interrupt trigger level which defaults > to 1 character time. The delay from this is too short at higher speeds > (11 uS at 921600 bps...). I use 16. The "tx" ring size of a 16950 > is 128 characters. Timing for characters in a UART at 921600 bps is > similar to timing for normal packets in 1G bps ethernet (1G/921600 ~= > 1K ~= 1500+ normal ethernet packet size), so similar ring sizes and > trigger levels are good (smaller ones would be better for smaller > packets). Strangely, at 921600 bps, the tx trigger levels become more > critical for maxing out the device than the rx trigger levels, since > rx is forced to keep up by the external device (provided that maxes > out the connection and it is possible to keep up), while poorly chosen > tx trigger levels ensure significant dead time when the tx runs dry. > > BTW, I can't see any significant effect (good or bad) from sk's > interrupt moderation, at least with tx changed as above. sk's interrupt > moderation is very primitive compared with that of some NICs (it's > just a single timer for tx and rx). Interrupting on every packet gives > too many interrupts, and my changes fix this much better than any > simple timeout-based moderation could do. My changes don't help at > all for rx, and interrupt moderation doesn't seem to help either. > OTOH, fxp's interrupt moderation works well in practice (I don't know > how) and em's interrupt moderation works well in theory (I understand > its documentation but haven't used any em devices). em has several > independent trigger levels and timeouts, and the problem of using them > effectively for rx is one of predicting future traffic. IIRC, em has > sysctls to move this problem to the user. > > In the current sk driver, I think keeping IFF_OACTIVE set for longer > would work, and you can also keep track of the queue lenghth, because > of the excessive interrupts -- you get an interrupt after every packet > (modulo interrupt moderation), not just on completion, and the interrupt > handler can both keep the h/w queue full while IFF_OACTIVE is set and > keep track of the queue length as needed for deciding when to set > IFF_OACTIVE. The CPU usage is thus large no matter whether IFF_ACTIVE > is set correctly. Interrupt moderation complicates things and unmaxes > the link. The interrupt moderation timeout is normally set to 100 uS. > This allows significant tx-dry times (the worst case (if IFF_OACTIVE > is not set incorrectly) is sending a tnygram in 4uS, idling for ~96 > uS, ...) but isn't very moderate since sending or receiving a normal > packet takes about 15uS. I think the interrupt moderation timeout for > sk is purely periodic, while for better hardware (even 16550 UARTs!) > at least rx timeouts only occur after the device (in the relevant > direction) has been idle for some time. > AFAIK SK GENESIS has no programming interface for a watermark. Some advanced hardware provides a way to interrupt when it reaches a programmed threshold but SK does not. It just provides a way whether hardware should raise an interrupt depending on Tx descriptor value. By tracking number of index it's possible to generate an interrupt for every N frames instead of every frame(1 <= N <= MAX Tx. Desc.). We may also need to add a routine to reclaim pending Tx descriptors before sending frames in sk_start if number of available Tx descriptors are less then a threshold. However I don't know how the driver should handle transmit errors occurred between interrupt-less Tx operations. Just flushing all committed frames would result in poor TCP performance. The difference between Yukon and SK hardware also make it hard to implement above interrupt-less Tx operations. There is no publicly available documentation for Yukon adapters and Yukon seems to use completely different registers for FIFO handling and flow control. This is one of main reason why I couldn't implement polling(4) for sk(4). It is also known to me Yukon adapters have a bug which loses Tx completion interrupts under certain conditions. BTW, as SK adapters have no limit on the number of Tx/Rx descriptors how about increasing the number of Tx descriptors(i.e. 1024 or 2048) to reduce the chance of running out of Tx descriptors? It does not decrease number of interrupts generated but it would help to push the hardware to the limit without much overhead, I guess. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Jun 19 13:49:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94F5C16A479 for ; Mon, 19 Jun 2006 13:49:54 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C268D43D6A for ; Mon, 19 Jun 2006 13:49:51 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 48583 invoked from network); 19 Jun 2006 13:49:34 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Jun 2006 13:49:34 -0000 Message-ID: <4496AB80.5040306@freebsd.org> Date: Mon, 19 Jun 2006 15:49:52 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Blue References: <449604D0.8090701@zyxel.com.tw> In-Reply-To: <449604D0.8090701@zyxel.com.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [freeBSD-6.1RELEASE] wonderings about function tcp_input() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jun 2006 13:49:54 -0000 Blue wrote: > Hi, all: > > I have a question about line 1765 to 1776 in tcp_input(): > > /* > * If the ACK bit is off: if in SYN-RECEIVED state or SENDSYN > * flag is on (half-synchronized state), then queue data for > * later processing; else drop segment and return. > */ > if ((thflags & TH_ACK) == 0) { > if (tp->t_state == TCPS_SYN_RECEIVED || > (tp->t_flags & TF_NEEDSYN)) > goto step6; > else > goto drop; > } > > My question is: if we are currently in TCPS_SYN_RECEIVED state, why does > a segment without ACK bother? Why we need to store the segment and > process it? Without considering T/TCP, the code should be: > > if ((thflags & TH_ACK) == 0) { > goto drop; > } This code is dead at the moment since most of T/TCP (RFC1644) was removed and the SYN_RECEIVED case is no longer handled here but in tcp_syncache.c. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jun 19 14:14:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11E1B16A47A for ; Mon, 19 Jun 2006 14:14:54 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EB9843D72 for ; Mon, 19 Jun 2006 14:14:47 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 48809 invoked from network); 19 Jun 2006 14:14:31 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Jun 2006 14:14:31 -0000 Message-ID: <4496B158.3090907@freebsd.org> Date: Mon, 19 Jun 2006 16:14:48 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Blue References: <4496721C.5030008@zyxel.com.tw> In-Reply-To: <4496721C.5030008@zyxel.com.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [FreeBSD-6.1RELEASE] tcp in TIME_WAIT state X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jun 2006 14:14:54 -0000 Blue wrote: > Hi, all: > > In function tcp_timewait(), which will be called when receiving a > segment as current TCP state at TIME_WAIT. However, in the body of the > function definition, it simply goes to "drop" before generating RST or > RST/ACK towards the unicast source. Is the behavior correct because the > followed codes (from line 2228 to line 3261) would never be reached! Yes, this code was never used. After the 'goto drop;' there used to be a 'reset:' label. However it was never used and got lost in rev. 1.254 because of compiler warnings. The code is related to the comment earlier in the function: "NOTE: for FIN_WAIT_2 (to be added later), must validate sequence number before accepting RST". I agree that is very confusing and I shall put an appropriate comment next to it. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jun 19 21:55:05 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E74416A47B; Mon, 19 Jun 2006 21:55:05 +0000 (UTC) (envelope-from rodrigc@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1487043D48; Mon, 19 Jun 2006 21:55:05 +0000 (GMT) (envelope-from rodrigc@FreeBSD.org) Received: from freefall.freebsd.org (rodrigc@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5JLt4oV006809; Mon, 19 Jun 2006 21:55:04 GMT (envelope-from rodrigc@freefall.freebsd.org) Received: (from rodrigc@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5JLt47B006804; Mon, 19 Jun 2006 21:55:04 GMT (envelope-from rodrigc) Date: Mon, 19 Jun 2006 21:55:04 GMT From: Craig Rodrigues Message-Id: <200606192155.k5JLt47B006804@freefall.freebsd.org> To: rodrigc@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/99188: [tcp] [patch] FIN in same packet as duplicate ACK is lost X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jun 2006 21:55:05 -0000 Synopsis: [tcp] [patch] FIN in same packet as duplicate ACK is lost Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: rodrigc Responsible-Changed-When: Mon Jun 19 21:54:45 UTC 2006 Responsible-Changed-Why: Send to maintainers http://www.freebsd.org/cgi/query-pr.cgi?pr=99188 From owner-freebsd-net@FreeBSD.ORG Mon Jun 19 23:22:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9882116A479 for ; Mon, 19 Jun 2006 23:22:42 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDA2743D45 for ; Mon, 19 Jun 2006 23:22:41 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from t30.polstra.com (adsl-sj-10-81.rockisland.net [64.119.10.81]) by blake.polstra.com (8.13.1/8.13.1) with ESMTP id k5JNMdwu002941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Jun 2006 16:22:40 -0700 (PDT) (envelope-from jdp@mail.polstra.com) Received: from t30.polstra.com (localhost [127.0.0.1]) by t30.polstra.com (8.12.11/8.12.11) with ESMTP id k5JNMXCL003732; Mon, 19 Jun 2006 16:22:33 -0700 (PDT) (envelope-from jdp@t30.polstra.com) Received: (from jdp@localhost) by t30.polstra.com (8.12.11/8.12.11/Submit) id k5JNMXJ7003731; Mon, 19 Jun 2006 16:22:33 -0700 (PDT) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20060618194044.GC1142@funkthat.com> Date: Mon, 19 Jun 2006 16:22:33 -0700 (PDT) From: John Polstra To: John-Mark Gurney Cc: freebsd-net@freebsd.org Subject: Re: IF_HANDOFF vs. IFQ_HANDOFF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 19 Jun 2006 23:22:42 -0000 On 18-Jun-2006 John-Mark Gurney wrote: > John Polstra wrote this message on Thu, Jun 15, 2006 at 09:18 -0700: >> in the HW but have not yet completed. When the completion interrupt >> comes in, the driver is supposed to check the if_snd queue for more >> mbufs and process them. Only when the transmit side of the HW goes >> totally idle should IFF_OACTIVE be cleared again. Most of our drivers >> set the flag only when they run out of transmit descriptors (i.e., >> practically never), which is just plain wrong. > > But the problem is that for small packets, this can mean that there > will be a delay in handling the ring if we wait to process packets > once the tx ring is empty.. if we ever want to max out gige w/ 64byte > packets, we have to clear OACTIVE whenever tx approches running out > of packets before we can send this.. Yes, I see your point. > In most cases we don't know how long that is (since we don't keep > track of packet sizes, etc), so it's easiest/best to clear it > whenever the tx ring is not full... I guess it depends on when you get interrupts from the particular network adapter. If you're taking an interrupt on every transmit completion, it's best to check the if_snd queue at that point, when you've already entered the driver anyway. In that case, you might as well leave OACTIVE set until the adapter goes idle, to suppress the redundant calls to if_start. (The transmitter won't go idle if there is enough traffic to max out the link capacity.) But if you only get an interrupt when the transmitter has gone idle then I agree, if_start needs to be called in order to keep the descriptor ring full enough. John From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 01:17:19 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9799B16A474 for ; Tue, 20 Jun 2006 01:17:19 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37BE443D49 for ; Tue, 20 Jun 2006 01:17:17 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id AEA074CD73 for ; Tue, 20 Jun 2006 01:17:34 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 53E174CD72 for ; Tue, 20 Jun 2006 01:17:34 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id 47C348A046; Tue, 20 Jun 2006 11:17:15 +1000 (EST) Received: from [192.168.46.102] (unknown [192.168.46.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id 333C18A037; Tue, 20 Jun 2006 11:17:15 +1000 (EST) Message-ID: <44974C9A.7010004@thebeastie.org> Date: Tue, 20 Jun 2006 11:17:14 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060404 X-Accept-Language: en-us, en To: Brian Candler References: <449228FA.50303@thebeastie.org> <20060616122855.GA29279@uk.tiscali.com> In-Reply-To: <20060616122855.GA29279@uk.tiscali.com> Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: VPN with FAST_IPSEC and ipsec tools X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 01:17:19 -0000 Brian Candler wrote: On Fri, Jun 16, 2006 at 01:43:54PM +1000, Michael Vince wrote: I have setup the GRE tunneling and that is working fine doing pings and tracerts when I disable ipsec and ipsec-tools, its just the encryption side thats the problem. Ah, I guess this means you're following the instructions in the FreeBSD handbook, which last time I looked gave a most bizarre and unnecessary way of setting up IPSEC (GIF tunneling running on top of IPSEC *tunnel* mode). I raised it on this list before. Most people are better off just setting up IPSEC tunnel mode. A few use GIF running on top of IPSEC _transport_ mode (e.g. those running routing protocols like OSPF over tunnels) Regards, Brian. Yeah I did build it based on the Handbook howto on VPNs, I had no idea it wasn't right. Interestingly I have managed to get this type of setting going with Checkpoint. Mike From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 06:02:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FB8416A47A for ; Tue, 20 Jun 2006 06:02:59 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyadd226.zyxel.com.tw (zyadd226.zyxel.com.tw [61.222.65.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE92943D45 for ; Tue, 20 Jun 2006 06:02:56 +0000 (GMT) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by smtp.zyxel.com.tw with InterScan Messaging Security Suite; Tue, 20 Jun 2006 14:11:04 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:02:52 +0800 Received: from [172.23.18.2] ([172.23.18.2]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:02:51 +0800 Message-ID: <44978F16.9010005@zyxel.com.tw> Date: Tue, 20 Jun 2006 14:00:54 +0800 From: Blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 06:02:52.0011 (UTC) FILETIME=[2A43FBB0:01C6942F] Subject: TIME_WAIT state check in in_pcblookup_local() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 06:02:59 -0000 Hi, All: I have a doubt in in_pcblookup_local() and in6_pcblookup_local() functions in in_pcb.c/in6_pcb.c in FreeBSD-6.1RELEASE. In v4 version (that is, in_pcblookup_local), the inp would be checked to see if the prospective port is used in TCP TIME_WAIT state. If so, it will call tcp_twrecycleable() to see if recycling is possible. However, I noticed that in v6 version (that is, in6_pcblookup_local) would not do such examination. In my opinion, the check should be removed since the connection is still alive in TIME_WAIT state and the port number should be considered unavailable. Best regards, blue From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 07:11:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ADD616A474; Tue, 20 Jun 2006 07:11:25 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id D06C043D46; Tue, 20 Jun 2006 07:11:24 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 003C732A603; Tue, 20 Jun 2006 17:11:22 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5K7BIOo018324; Tue, 20 Jun 2006 17:11:19 +1000 Date: Tue, 20 Jun 2006 17:11:18 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Pyun YongHyeon In-Reply-To: <20060619122753.GA5600@cdnetworks.co.kr> Message-ID: <20060620154425.Q48009@delplex.bde.org> References: <20060615115738.J2512@fledge.watson.org> <20060618194044.GC1142@funkthat.com> <20060619162819.F44832@delplex.bde.org> <20060619122753.GA5600@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, John-Mark Gurney , Robert Watson , John Polstra Subject: Re: IF_HANDOFF vs. IFQ_HANDOFF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 07:11:25 -0000 On Mon, 19 Jun 2006, Pyun YongHyeon wrote: Please trim quotes. > On Mon, Jun 19, 2006 at 06:04:26PM +1000, Bruce Evans wrote: > > To max out the link without unmaxing CPU for other uses, you do have > > to know when the tx approaches running out of packets. This is best > > done using watermark stuff. There should be a nearly-complete interrupt > > at low water, and (only after low water is reached and the interrupt > > handler doesn't refill the tx ring to be above low water again) a > > completion interrupt at actual completion. My version of the sk driver > > does this. It arrange for the nearly-complete interrupt at about 32 > > fragments (min 128 uS) before the tx runs dry, and no other tx interrupts > > unless the queue length stays below 32, while the -current driver gets > > an interrupt after every packet. It does this mainly to reduce the > > tx interrupt load from 1 per packet to (under load) 1 per 480 fragments. > > The correct handling of OACTIVE is obtained as a side effect almost > > automatically. ... > > > > I'm not very familiar with NIC hardware and don't know how other NICs > > support timing of tx interrupts, but watermark stuff like the above > > is routine for serial devices/drivers. sk's support for interrupting > > on any fragment is too flexible to be good (it is painful to program, > > and there doesn't seem to be a good way to time out if there is no > > good fragment to interrupt on or when you program the interruption on > > a wrong fragment). > > ... > AFAIK SK GENESIS has no programming interface for a watermark. > Some advanced hardware provides a way to interrupt when it reaches > a programmed threshold but SK does not. It just provides a way whether > hardware should raise an interrupt depending on Tx descriptor value. > By tracking number of index it's possible to generate an interrupt > for every N frames instead of every frame(1 <= N <= MAX Tx. Desc.). I only have a Yukon, and think that's what I do, with a very variable N. (Do we mean the same thing by the "Tx descriptor value"? I mean SK_TXCTL_EOF_INTR. Surely that's portable -- it's used in all versions of sk with no ifdefs for GENESIS.). My sk_start() tries to fill the tx ring (to length 512) and then put an interrupt mark only on the last fragment in a packet nearest to 32 from the end, so in the best case N is about 480, but it us less if tx is not streaming. Cases where there is not much choice are harder to program. I had some success with removing interrupt marks and with dummy packets of length 0 whose purpose is just to hold an interrupt mark, but I don't trust those methods. I didn't try putting an interrupt mark on fragments in the middle of a packet. That would be simpler if it works. > We may also need to add a routine to reclaim pending Tx descriptors > before sending frames in sk_start if number of available Tx descriptors > are less then a threshold. I'm not sure what you mean here. If there are < 32 tx descriptors available, AND there is an (active) descriptor with an interrupt mark, then my sk_start() just sets IFF_OACTIVE and returns. The case where there are < 32 tx descriptors but no descriptor with an interrupt mark is trickier: a mark must be added, and I don't trust adding it to an active packet, so it must be added to a new packet, but it might be impossible to add one for the following reasons: - no space. The magic 32 is hopefully enough. - no packets in the ifq. My sk_start() tries to leave a spare one when one might be needed, but I think upper layers can eat it. A dummy packet of length 0 can be used to handle both cases but may be bad for the network -- does the hardware send a frame with no data? > However I don't know how the driver should handle transmit errors > occurred between interrupt-less Tx operations. Just flushing all > committed frames would result in poor TCP performance. Doesn't the hardware just proceed to the next packet without interrupting (except possibly for a special error interrupt), and anyway act the same as if the interrupt were delayed by interrupt moderation? Errors for individual packets don't seem to be detected or reported in either case. > The difference between Yukon and SK hardware also make it hard to > implement above interrupt-less Tx operations. There is no publicly My version is not interrupless, but tries to use tx interrupts for everything, just not many of them. > available documentation for Yukon adapters and Yukon seems to use > completely different registers for FIFO handling and flow control. > This is one of main reason why I couldn't implement polling(4) for > sk(4). It is also known to me Yukon adapters have a bug which loses > Tx completion interrupts under certain conditions. Anything that prevents implementation of polling is good. > BTW, as SK adapters have no limit on the number of Tx/Rx descriptors > how about increasing the number of Tx descriptors(i.e. 1024 or 2048) > to reduce the chance of running out of Tx descriptors? > It does not decrease number of interrupts generated but it would help > to push the hardware to the limit without much overhead, I guess. I tried this instead of increasing the ifq length (*) and seemed to hit a limit. I don't understand the problem of running out of tx descriptors -- see above. (*) It's necessary to have an enormous number of descriptors to avoid the tx running dry afer poor handling of ENOBUFS. select() doesn't work right for sockets, so at least test programs like ttcp retry after an unshort sleep. The old sgi ttcp tries to sleep for 18000 uS. This may have been long enough for 1Mbps ethernet, but for sk it's 4500 packet times with minimal packets, and for better hardware it would be a multiple instead of a factor of 18000 packet times. Newer versions of ttcp uses a shorter sleep or a busy-wait. Neither works well. The shortest sleep length averages 1.5/HZ seconds and I use HZ = 100 so this is almost the same as the old sgi sleep time (but 18000 gets rounded up to an average of 25000). Busy-waiting results in ttcp taking 100% of the CPU and the system and driver parts of this being harder to distinguish. In sk, I use an ifq length scaled by hz to ensure that the queue doesn't run dry during several 1/HZ's of sleeping and ttcp works right. This gives an enormous ifq with HZ = 100 (5-10 thousand descriptors). An unchanged fxp behaves like an unchanged sk here, but an unhanged bge behaves differently. bge apparently never returns ENOBUFS, but busy-waits in the kernel. Bruce From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 09:54:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51FAA16A47B for ; Tue, 20 Jun 2006 09:54:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id D759743D46 for ; Tue, 20 Jun 2006 09:54:22 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id m7so781059nzf for ; Tue, 20 Jun 2006 02:54:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=bZI0mHce9ahGIRymWfJ5ITYIO3cMP4JNDYBiYg+rQJXKIRghDybiqIraPJKWLmus0HtcyAiQO9J+Wh5+PxjRSMXdQJrtSCSSHdihQIcmEbcGeJDvdYqZtnTxRxpxjvsg+FSAGyw20FnP7Jip4k6NB7y1uggb8OsoSmWZpiQ7+60= Received: by 10.36.250.42 with SMTP id x42mr8755279nzh; Tue, 20 Jun 2006 02:54:22 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 39sm11143801nzk.2006.06.20.02.54.19; Tue, 20 Jun 2006 02:54:22 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k5K9sYaM010467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jun 2006 18:54:34 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k5K9sVYq010466; Tue, 20 Jun 2006 18:54:31 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 20 Jun 2006 18:54:31 +0900 From: Pyun YongHyeon To: Bruce Evans Message-ID: <20060620095431.GB8645@cdnetworks.co.kr> References: <20060615115738.J2512@fledge.watson.org> <20060618194044.GC1142@funkthat.com> <20060619162819.F44832@delplex.bde.org> <20060619122753.GA5600@cdnetworks.co.kr> <20060620154425.Q48009@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060620154425.Q48009@delplex.bde.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, John-Mark Gurney , Robert Watson , John Polstra Subject: Re: IF_HANDOFF vs. IFQ_HANDOFF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 09:54:26 -0000 On Tue, Jun 20, 2006 at 05:11:18PM +1000, Bruce Evans wrote: > On Mon, 19 Jun 2006, Pyun YongHyeon wrote: > > Please trim quotes. > > >On Mon, Jun 19, 2006 at 06:04:26PM +1000, Bruce Evans wrote: > > >> To max out the link without unmaxing CPU for other uses, you do have > >> to know when the tx approaches running out of packets. This is best > >> done using watermark stuff. There should be a nearly-complete interrupt > >> at low water, and (only after low water is reached and the interrupt > >> handler doesn't refill the tx ring to be above low water again) a > >> completion interrupt at actual completion. My version of the sk driver > >> does this. It arrange for the nearly-complete interrupt at about 32 > >> fragments (min 128 uS) before the tx runs dry, and no other tx interrupts > >> unless the queue length stays below 32, while the -current driver gets > >> an interrupt after every packet. It does this mainly to reduce the > >> tx interrupt load from 1 per packet to (under load) 1 per 480 fragments. > >> The correct handling of OACTIVE is obtained as a side effect almost > >> automatically. ... > >> > >> I'm not very familiar with NIC hardware and don't know how other NICs > >> support timing of tx interrupts, but watermark stuff like the above > >> is routine for serial devices/drivers. sk's support for interrupting > >> on any fragment is too flexible to be good (it is painful to program, > >> and there doesn't seem to be a good way to time out if there is no > >> good fragment to interrupt on or when you program the interruption on > >> a wrong fragment). > >> ... > > >AFAIK SK GENESIS has no programming interface for a watermark. > >Some advanced hardware provides a way to interrupt when it reaches > >a programmed threshold but SK does not. It just provides a way whether > >hardware should raise an interrupt depending on Tx descriptor value. > >By tracking number of index it's possible to generate an interrupt > >for every N frames instead of every frame(1 <= N <= MAX Tx. Desc.). > > I only have a Yukon, and think that's what I do, with a very variable N. > (Do we mean the same thing by the "Tx descriptor value"? I mean Yes. > SK_TXCTL_EOF_INTR. Surely that's portable -- it's used in all versions > of sk with no ifdefs for GENESIS.). > > My sk_start() tries to fill the tx ring (to length 512) and then put > an interrupt mark only on the last fragment in a packet nearest to 32 > from the end, so in the best case N is about 480, but it us less if > tx is not streaming. Cases where there is not much choice are harder > to program. I had some success with removing interrupt marks and with > dummy packets of length 0 whose purpose is just to hold an interrupt > mark, but I don't trust those methods. I didn't try putting an > interrupt mark on fragments in the middle of a packet. That would be > simpler if it works. > I think it would take a long time to generate an Tx completion interrupt for committed frames(every frame vs. the last frame) The hardware may have some free Tx descriptors before generating an Tx completion interrupt. I guess it would be more efficient if we know there are some free Tx descriptors and use it before waiting for an Tx completion interrupt. Just waiting for a completion interrupt would add additional latency. Anyway, I have to experiment it. > >We may also need to add a routine to reclaim pending Tx descriptors > >before sending frames in sk_start if number of available Tx descriptors > >are less then a threshold. > > I'm not sure what you mean here. If there are < 32 tx descriptors > available, AND there is an (active) descriptor with an interrupt mark, > then my sk_start() just sets IFF_OACTIVE and returns. The case where > there are < 32 tx descriptors but no descriptor with an interrupt mark > is trickier: a mark must be added, and I don't trust adding it to an > active packet, so it must be added to a new packet, but it might be > impossible to add one for the following reasons: > - no space. The magic 32 is hopefully enough. > - no packets in the ifq. My sk_start() tries to leave a spare one when > one might be needed, but I think upper layers can eat it. > A dummy packet of length 0 can be used to handle both cases but may be > bad for the network -- does the hardware send a frame with no data? I can't sure. Since you know when you have to insert interrupt mark in sk_encap I think you can use m_defrag and set SK_TXCTL_EOF_INTR. > > >However I don't know how the driver should handle transmit errors > >occurred between interrupt-less Tx operations. Just flushing all > >committed frames would result in poor TCP performance. > > Doesn't the hardware just proceed to the next packet without interrupting > (except possibly for a special error interrupt), and anyway act the same > as if the interrupt were delayed by interrupt moderation? Errors for > individual packets don't seem to be detected or reported in either case. > Yes that is the problem. It seems that there is no way to know which packet caused Tx errors and I think we have no choice but flushing entire FIFOs. SK just flushes all frames in FIFO if it detect Tx FIFO underrun or Rx FIFO overflow. But I can't sure how Yukon should handle this case. The flushing routine in sk is guess work from Linux skge implementation and I don't know internal details of Yukon hardware. Since Yukon uses defferent registers to flush FIFOs and the existence of unique registers related with interrupt and FIFOs I guess it uses completely different approach. > >The difference between Yukon and SK hardware also make it hard to > >implement above interrupt-less Tx operations. There is no publicly > > My version is not interrupless, but tries to use tx interrupts for > everything, just not many of them. > Ok, I'll take your idea and will try to experiment it next week. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 11:03:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92C7416A474; Tue, 20 Jun 2006 11:03:44 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id E991F43D45; Tue, 20 Jun 2006 11:03:43 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 5735810988B; Tue, 20 Jun 2006 21:03:42 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5KB3cGW004886; Tue, 20 Jun 2006 21:03:39 +1000 Date: Tue, 20 Jun 2006 21:03:38 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Pyun YongHyeon In-Reply-To: <20060620095431.GB8645@cdnetworks.co.kr> Message-ID: <20060620201148.Q48586@delplex.bde.org> References: <20060615115738.J2512@fledge.watson.org> <20060618194044.GC1142@funkthat.com> <20060619162819.F44832@delplex.bde.org> <20060619122753.GA5600@cdnetworks.co.kr> <20060620154425.Q48009@delplex.bde.org> <20060620095431.GB8645@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, John-Mark Gurney , Robert Watson , John Polstra Subject: Re: IF_HANDOFF vs. IFQ_HANDOFF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 11:03:44 -0000 On Tue, 20 Jun 2006, Pyun YongHyeon wrote: > On Tue, Jun 20, 2006 at 05:11:18PM +1000, Bruce Evans wrote: > > On Mon, 19 Jun 2006, Pyun YongHyeon wrote: > > My sk_start() tries to fill the tx ring (to length 512) and then put > > an interrupt mark only on the last fragment in a packet nearest to 32 > > from the end, so in the best case N is about 480, but it us less if > > tx is not streaming. Cases where there is not much choice are harder > > to program. I had some success with removing interrupt marks and with > > dummy packets of length 0 whose purpose is just to hold an interrupt > > mark, but I don't trust those methods. I didn't try putting an > > interrupt mark on fragments in the middle of a packet. That would be > > simpler if it works. > > I think it would take a long time to generate an Tx completion > interrupt for committed frames(every frame vs. the last frame) The > hardware may have some free Tx descriptors before generating an > Tx completion interrupt. I guess it would be more efficient if we > know there are some free Tx descriptors and use it before waiting for > an Tx completion interrupt. Just waiting for a completion interrupt > would add additional latency. Anyway, I have to experiment it. Having hundreds or thousands if packets in flight already gives large latency for new packets. Then it makes little difference to latency when tx interrupts occur. New packets don't go out faster if tx interrupts occur earlier -- they just get put into the h/w queue earlier and wait there longer if that queue is long, They might go out slower if they get reordered in higher queues. > > >We may also need to add a routine to reclaim pending Tx descriptors > > >before sending frames in sk_start if number of available Tx descriptors > > >are less then a threshold. > > > > I'm not sure what you mean here. If there are < 32 tx descriptors > > available, AND there is an (active) descriptor with an interrupt mark, > > then my sk_start() just sets IFF_OACTIVE and returns. The case where > > there are < 32 tx descriptors but no descriptor with an interrupt mark > > is trickier: a mark must be added, and I don't trust adding it to an > > active packet, so it must be added to a new packet, but it might be > > impossible to add one for the following reasons: > > - no space. The magic 32 is hopefully enough. > > - no packets in the ifq. My sk_start() tries to leave a spare one when > > one might be needed, but I think upper layers can eat it. > > A dummy packet of length 0 can be used to handle both cases but may be > > bad for the network -- does the hardware send a frame with no data? > > I can't sure. > Since you know when you have to insert interrupt mark in sk_encap > I think you can use m_defrag and set SK_TXCTL_EOF_INTR. Yes, that might work well. I don't actually know where to insert the interrupt mark in sk_encap(). My sk encap() doesn't set either SK_TXCTL_EOF_INTR or SK_TXCTL_OWN. Then after filling the tx ring as far as possible, sk_start() checks the ring indexes to determine where to put SK_TXCTL_EOF_INTR and puts SK_TXCTL_EOF_INTR on one fragment and SK_TXCTL_OWN on all the fragments that it just queued. It is necessary to determine the final ring state in some way before deciding where to put SK_TXCTL_EOF_INTR, and this way seems best. > > >However I don't know how the driver should handle transmit errors > > >occurred between interrupt-less Tx operations. Just flushing all > > >committed frames would result in poor TCP performance. > > > > Doesn't the hardware just proceed to the next packet without interrupting > > (except possibly for a special error interrupt), and anyway act the same > > as if the interrupt were delayed by interrupt moderation? Errors for > > individual packets don't seem to be detected or reported in either case. > > Yes that is the problem. It seems that there is no way to know which > packet caused Tx errors and I think we have no choice but flushing > entire FIFOs. SK just flushes all frames in FIFO if it detect Tx > FIFO underrun or Rx FIFO overflow. But I can't sure how Yukon should > handle this case. The flushing routine in sk is guess work from > Linux skge implementation and I don't know internal details of Yukon > hardware. Since Yukon uses defferent registers to flush FIFOs and the > existence of unique registers related with interrupt and FIFOs I guess > it uses completely different approach. The old version that I use doesn't even reference if_oerrors :-). Do you mean flushing the whole ring? Ideally there would be an error mark on old unOWNed packets but there would be no point in flushing those, and if the interrupt is delayed there would just be more old packets and fewer OWNed packets that would be lost by flushing the whole ring. Bruce From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 13:55:21 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6432E16A4D4 for ; Tue, 20 Jun 2006 13:55:21 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 842E3441BC for ; Tue, 20 Jun 2006 13:26:23 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 399E94C822 for ; Tue, 20 Jun 2006 13:26:42 +0000 (GMT) Received: from [192.168.0.6] (ppp157-158.static.internode.on.net [150.101.157.158]) by p4.roq.com (Postfix) with ESMTP id 9B0604C820 for ; Tue, 20 Jun 2006 13:26:41 +0000 (GMT) Message-ID: <4497F777.4040206@thebeastie.org> Date: Tue, 20 Jun 2006 23:26:15 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20060526 X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Subject: FAST_IPSEC and NAT-T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 13:55:21 -0000 Hey All, When installing the ipsec-tools it says if you want NAT-T you need to install this patch, http://ipsec-tools.sourceforge.net/freebsd6-natt.diff Can any one tell me if this patch works with Fast_ipsec or is it just for the other ipsec? Cheers, Mike From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 13:59:58 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB74916A47A for ; Tue, 20 Jun 2006 13:59:58 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from leia.fdn.fr (ns0.fdn.org [80.67.169.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 121EB43D45 for ; Tue, 20 Jun 2006 13:59:57 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by leia.fdn.fr (8.13.3/8.13.3/FDN) with ESMTP id k5KDxibU007479; Tue, 20 Jun 2006 15:59:51 +0200 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 471FD3F17; Tue, 20 Jun 2006 15:59:39 +0200 (CEST) Date: Tue, 20 Jun 2006 15:59:39 +0200 From: VANHULLEBUS Yvan To: Michael Vince Message-ID: <20060620135939.GB28424@zen.inc> References: <4497F777.4040206@thebeastie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4497F777.4040206@thebeastie.org> User-Agent: All mail clients suck. This one just sucks less. Cc: net@freebsd.org Subject: Re: FAST_IPSEC and NAT-T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 13:59:58 -0000 On Tue, Jun 20, 2006 at 11:26:15PM +1000, Michael Vince wrote: > Hey All, > When installing the ipsec-tools it says if you want NAT-T you need to > install this patch, http://ipsec-tools.sourceforge.net/freebsd6-natt.diff > Can any one tell me if this patch works with Fast_ipsec or is it just > for the other ipsec? Hi. I didn't have time to port it to FAST_IPSEC now, so it currently only works with IPSEC. But FAST_IPSEC support is on my TODO list, and shouldn't be too difficult.... when I'll have time to work on it, and when we'll synchronize with other people who are actually working on IPSec stacks. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 14:41:56 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7084216A481 for ; Tue, 20 Jun 2006 14:41:56 +0000 (UTC) (envelope-from worm@chm.org.ua) Received: from support2.cyfra.ua (support2.cyfra.ua [62.80.160.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 138F243D45 for ; Tue, 20 Jun 2006 14:41:55 +0000 (GMT) (envelope-from worm@chm.org.ua) Received: from localhost ([127.0.0.1]) by support2.cyfra.ua with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1FshQ9-0002aQ-S1; Tue, 20 Jun 2006 17:41:49 +0300 Message-ID: <4498091E.2040302@chm.org.ua> Date: Tue, 20 Jun 2006 17:41:34 +0300 From: Victor Melnichenko User-Agent: Thunderbird 1.5.0.4 (X11/20060609) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Check: ClamAV 0.88.2/1551 on support2.cyfra.ua at Tue, 20 Jun 2006 17:41:49 +0300 Subject: [Q]/usr/src/sys/net/bridge.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 14:41:56 -0000 Hello everyone! Who can explain me why BDG_MAX_PORTS 128 (/usr/src/sys/net/bridge.h) have maximum number of bridge interfaces 128? Thanks! P.S. Sorry for my bad eng. -- With Best Regards, Victor V. Melnichenko VVM7-UANIC From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 15:20:19 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E97F316A4D1 for ; Tue, 20 Jun 2006 15:20:19 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BF4F43D48 for ; Tue, 20 Jun 2006 15:20:18 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 261CE4CD9C; Tue, 20 Jun 2006 15:20:37 +0000 (GMT) Received: from [192.168.0.6] (ppp157-158.static.internode.on.net [150.101.157.158]) by p4.roq.com (Postfix) with ESMTP id 1E9734CD72; Tue, 20 Jun 2006 15:20:35 +0000 (GMT) Message-ID: <44981231.4060001@thebeastie.org> Date: Wed, 21 Jun 2006 01:20:17 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20060526 X-Accept-Language: en-us, en MIME-Version: 1.0 To: VANHULLEBUS Yvan References: <4497F777.4040206@thebeastie.org> <20060620135939.GB28424@zen.inc> In-Reply-To: <20060620135939.GB28424@zen.inc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: net@freebsd.org Subject: Re: FAST_IPSEC and NAT-T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 15:20:20 -0000 VANHULLEBUS Yvan wrote: >On Tue, Jun 20, 2006 at 11:26:15PM +1000, Michael Vince wrote: > > >>Hey All, >>When installing the ipsec-tools it says if you want NAT-T you need to >>install this patch, http://ipsec-tools.sourceforge.net/freebsd6-natt.diff >>Can any one tell me if this patch works with Fast_ipsec or is it just >>for the other ipsec? >> >> > >Hi. > >I didn't have time to port it to FAST_IPSEC now, so it currently only >works with IPSEC. > >But FAST_IPSEC support is on my TODO list, and shouldn't be too >difficult.... when I'll have time to work on it, and when we'll >synchronize with other people who are actually working on IPSec >stacks. > > >Yvan. > > OK cool, the thing that really turns my off about that IPSec is when I reboot with it compiled in says "Expect reduced performance" because its not mpsafe. Also I just tried to compile a kernel with that Nat-T patch on the other IPSEC kernel on 6.1-release and it failed. I can't think of anything I have done wrong on this machine its pretty fresh, I did cvsup with "RELENG_6_1" before hand maybe there is a tiny enough about of changes since the RELENG_6_1_0 release for it to fail but I didn't notice anything serious changed, I also used the new pure C csup over cvsup client. The patch installed fine with no errors but the kernel failed to compile ending with this.. /usr/src/sys/netinet/udp_usrreq.c:1046: warning: 'udp4_espinudp' defined but not used The kernel was quite generic listed here below, the GENERIC2 just missing a few things like scsi and raid bits this machine doesn't need. include GENERIC2 ident FIREWALL options DEVICE_POLLING options HZ=1000 options IPSEC options IPSEC_ESP options IPSEC_DEBUG #options FAST_IPSEC #device crypto #device cryptodev options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ Mike From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 15:30:18 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 021D116A4CD for ; Tue, 20 Jun 2006 15:30:17 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from leia.fdn.fr (ns0.fdn.org [80.67.169.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE57E43D46 for ; Tue, 20 Jun 2006 15:30:15 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by leia.fdn.fr (8.13.3/8.13.3/FDN) with ESMTP id k5KFUC4q001031; Tue, 20 Jun 2006 17:30:14 +0200 Received: by smtp.zeninc.net (smtpd, from userid 1000) id DB6623F17; Tue, 20 Jun 2006 17:30:06 +0200 (CEST) Date: Tue, 20 Jun 2006 17:30:06 +0200 From: VANHULLEBUS Yvan To: Michael Vince Message-ID: <20060620153006.GA30732@zen.inc> References: <4497F777.4040206@thebeastie.org> <20060620135939.GB28424@zen.inc> <44981231.4060001@thebeastie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44981231.4060001@thebeastie.org> User-Agent: All mail clients suck. This one just sucks less. Cc: net@freebsd.org Subject: Re: FAST_IPSEC and NAT-T X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 15:30:18 -0000 On Wed, Jun 21, 2006 at 01:20:17AM +1000, Michael Vince wrote: [NAT-T patch] > OK cool, the thing that really turns my off about that IPSec is when I > reboot with it compiled in says "Expect reduced performance" because its > not mpsafe. > > Also I just tried to compile a kernel with that Nat-T patch on the other > IPSEC kernel on 6.1-release and it failed. > I can't think of anything I have done wrong on this machine its pretty > fresh, I did cvsup with "RELENG_6_1" before hand > maybe there is a tiny enough about of changes since the RELENG_6_1_0 > release for it to fail but I didn't notice anything serious changed, I > also used the new pure C csup over cvsup client. > > The patch installed fine with no errors but the kernel failed to compile > ending with this.. > > /usr/src/sys/netinet/udp_usrreq.c:1046: warning: 'udp4_espinudp' defined > but not used You are compiling without NAT-T support, and this function is not properly #ifdef'ed in the public version of the patch. It has been fixed in the new (not yet available) version, which also provide new features (mainly support for multiple peers behind the same public IP). As ipsec-tools 0.6.6 is out now, I'll update the patch on ipsec-tools website. [....] > options IPSEC > options IPSEC_ESP > options IPSEC_DEBUG Add "options IPSEC_NAT_T" here and it will compile. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 17:47:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF4DC16A481 for ; Tue, 20 Jun 2006 17:47:45 +0000 (UTC) (envelope-from enderw@chattingaway.com) Received: from smtp110.sbc.mail.re2.yahoo.com (smtp110.sbc.mail.re2.yahoo.com [68.142.229.95]) by mx1.FreeBSD.org (Postfix) with SMTP id C270043D49 for ; Tue, 20 Jun 2006 17:47:43 +0000 (GMT) (envelope-from enderw@chattingaway.com) Received: (qmail 54649 invoked from network); 20 Jun 2006 17:47:43 -0000 Received: from unknown (HELO ?4.158.204.148?) (kc5vdj@prodigy.net@4.158.204.148 with plain) by smtp110.sbc.mail.re2.yahoo.com with SMTP; 20 Jun 2006 17:47:41 -0000 Message-ID: <449834CA.2030005@chattingaway.com> Date: Tue, 20 Jun 2006 12:47:54 -0500 From: Jim Bryant User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060113) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-sparc64@freebsd.org, freebsd-drivers@freebsd.org, freebsd-platforms@freebsd.org, freebsd-hardware@freebsd.org Subject: Problem: fpa(4) on sparc64 6.1-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 17:47:45 -0000 I am getting a panic with a GENERIC with all non-available hardware drivers stripped out with "device fddi" and "device fpa" in the config. The only things I added to GENERIC after stripping out the unneeded things was the fddi, the sound, and the openfirmware. The system boots fine with the fddi stuff commented out of the config. Any suggestions? Is anyone working on this? Console log follows: ------------------------------------------------------------------------------------------------ screen not found. Can't open input device. Keyboard not present. Using ttya for input and output. SPARCengine(tm)Ultra(tm) AXi (UltraSPARC-IIi 300MHz), No Keyboard OpenBoot 3.10.4 SME, 256 MB memory installed, Serial #10425242. Ethernet address 8:0:20:9f:13:9a, Host ID: 809f139a. Initializing Memory ok boot Boot device: disk:a File and args: >> FreeBSD/sparc64 boot block Boot path: /pci@1f,0/pci@1/scsi@1/disk@0,0:a Boot loader: /boot/loader Consoles: Open Firmware console FreeBSD/sparc64 bootstrap loader, Revision 1.0 (root@s-dallas.cse.buffalo.edu, Sun May 7 07:03:17 UTC 2006) bootpath="/pci@1f,0/pci@1/scsi@1/disk@0,0:a" Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x36b508+0x52e58 syms=[0x8+0x59a60+0x8+0x4af83] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Booting [/boot/kernel/kernel] in 8 seconds... Booting [/boot/kernel/kernel]... nothing to autoload yet. jumping to kernel entry at 0xc0058000. Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE #0: Tue Jun 20 02:01:14 CDT 2006 root@ren.prodigy.net:/usr/obj/usr/src/sys/REN Timecounter "tick" frequency 300008484 Hz quality 1000 real memory = 268435456 (256 MB) avail memory = 241123328 (229 MB) cpu0: Sun Microsystems UltraSparc-IIi Processor (300.01 MHz CPU) nexus0: pcib0: on nexus0 pcib0: Sabre, impl 0, version 0, ign 0x7c0, bus A pcib0: [FAST] pcib0: [FAST] pcib0: [GIANT-LOCKED] pcib0: [GIANT-LOCKED] pcib0 dvma: DVMA map: 0xc0000000 to 0xc3ffffff pci0: on pcib0 pcib1: at device 1.1 on pci0 pci1: on pcib1 ebus0: mem 0xf0000000-0xf0ffffff,0xf1000000-0xf17fffff at device 1.0 on pci1 auxio0: addr 0x1400726000-0x1400726003,0x1400728000-0x1400728003,0x140072a000-0x140072a003,0x140072c000-0x140072c003,0x140072f000-0x140072f003 on ebus0 ebus0: addr 0x1400724000-0x1400724003 irq 37 (no driver attached) ebus0: addr 0x1400504000-0x1400504002 (no driver attached) puc0: addr 0x1400400000-0x140040007f irq 43 on ebus0 uart0: on puc0 uart0: CTS oflow uart0: console (38400,n,8,1) uart1: on puc0 uart1: CTS oflow uart2: <16550 or compatible> addr 0x14003803f8-0x14003803ff irq 41 on ebus0 uart2: keyboard (1200,n,8,1) uart2: keyboard not present uart3: <16550 or compatible> addr 0x14003602f8-0x14003602ff irq 42 on ebus0 ebus0: addr 0x1400340278-0x1400340287,0x140030015c-0x140030015d,0x1400700000-0x140070000f irq 34 (no driver attached) ebus0: addr 0x14003203f0-0x14003203f7,0x1400706000-0x140070600f,0x1400720000-0x1400720003 irq 39 (no driver attached) eeprom0: addr 0x1400000000-0x1400001fff on ebus0 eeprom0: model mk48t59 eeprom0: hostid 809f139a ebus0: addr 0x1000000000-0x10000fffff (no driver attached) ebus0: addr 0x1400722000-0x1400722003 (no driver attached) ebus0: addr 0x1400600000-0x1400600003 irq 40,37 (no driver attached) hme0: mem 0x40008000-0x4000ffff at device 1.1 on pci1 miibus0: on hme0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto hme0: Ethernet address: 08:00:20:9f:13:9a pcm0: port 0x800400-0x80043f at device 4.0 on pci1 pcm0: pcm0: pcib2: at device 1.0 on pci0 pci2: on pcib2 sym0: <875> port 0x400-0x4ff mem 0x1000-0x10ff,0x2000-0x2fff at device 1.0 on pci2 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym0: [GIANT-LOCKED] sym1: <875> port 0x800-0x8ff mem 0x3000-0x30ff,0x4000-0x4fff at device 1.1 on pci2 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: [GIANT-LOCKED] fpa0: port 0xc00-0xc7f mem 0x5000-0x507f,0x10000-0x1ffff at device 2.0 on pci2 panic: trap: fast data access mmu miss Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Resetting ... From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 19:50:24 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B329C16A479 for ; Tue, 20 Jun 2006 19:50:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 620AA43D58 for ; Tue, 20 Jun 2006 19:50:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k5KJoNJM093224 for ; Tue, 20 Jun 2006 19:50:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k5KJoNxW093223; Tue, 20 Jun 2006 19:50:23 GMT (envelope-from gnats) Date: Tue, 20 Jun 2006 19:50:23 GMT Message-Id: <200606201950.k5KJoNxW093223@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Staffan Ulfberg Cc: Subject: Re: kern/99188: [tcp] [patch] FIN in same packet as duplicate ACK is lost X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Staffan Ulfberg List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 19:50:24 -0000 The following reply was made to PR kern/99188; it has been noted by GNATS. From: Staffan Ulfberg To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/99188: [tcp] [patch] FIN in same packet as duplicate ACK is lost Date: 20 Jun 2006 21:49:16 +0200 I forgot to say that the Windows XP test code in the PR was compiled using the "cl" command line compiler from Microsoft Visual Studio. Anyway, when runnging the test code in the report, the following is a dump of the last packets captured by tcpdumpa dn presented by ethereal: No. Time Source Destination Protocol Info 135 23:48:02.409915 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=122401 Ack=1 Win=65535 Len=1360 136 23:48:02.409922 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=123761 Ack=1 Win=65535 Len=1360 137 23:48:02.409926 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=125121 Ack=1 Win=65535 Len=1360 138 23:48:02.409932 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=126481 Ack=1 Win=65535 Len=1360 139 23:48:02.409936 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=127841 Ack=1 Win=65535 Len=1360 140 23:48:02.409939 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=129201 Ack=1 Win=65535 Len=1360 141 23:48:02.410012 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=1 Ack=121041 Win=65535 Len=0 142 23:48:02.410029 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=130561 Ack=1 Win=65535 Len=1360 143 23:48:02.410033 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=131921 Ack=1 Win=65535 Len=1360 144 23:48:02.410037 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [ACK] Seq=133281 Ack=1 Win=65535 Len=1360 145 23:48:02.431375 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=1 Ack=125121 Win=65535 Len=0 146 23:48:02.431378 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=1 Ack=127841 Win=65535 Len=0 147 23:48:02.431380 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=1 Ack=131921 Win=65535 Len=0 148 23:48:02.431382 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=1 Ack=134641 Win=65535 Len=0 149 23:48:02.431384 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [FIN, ACK] Seq=1 Ack=134641 Win=65535 Len=0 150 23:48:02.431399 172.22.32.206 10.0.3.5 TCP 5000 > 1327 [PSH, ACK] Seq=134641 Ack=1 Win=65535 Len=1360 151 23:48:02.647004 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [ACK] Seq=2 Ack=136001 Win=65535 Len=0 152 23:48:03.413573 10.0.3.5 172.22.32.206 TCP 1327 > 5000 [RST, ACK] Seq=2 Ack=136001 Win=0 Len=0 10.0.3.5 was the client computer, and 172.22.32.206 was the server. After the session above, the socket on the server was in "ESTABLISHED" state. Staffan From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 20:56:25 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D267416A570 for ; Tue, 20 Jun 2006 20:56:25 +0000 (UTC) (envelope-from brett@lariat.org) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B00543D6E for ; Tue, 20 Jun 2006 20:56:24 +0000 (GMT) (envelope-from brett@lariat.org) Received: from Anne (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id OAA14381 for ; Tue, 20 Jun 2006 14:56:21 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <7.0.1.0.2.20060620143845.06662330@lariat.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 20 Jun 2006 14:56:12 -0600 To: net@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Best way to block a long list of IPs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 20:56:26 -0000 Everyone: I've got an application in which I must block incoming TCP connections to a FreeBSD server from a potentially large list of IP addresses. Using IPFW is not a very efficient way to accomplish this, because it must do a linear search of a list (either one address per rule or an "or" list in a rule) and this could slow down every packet entering the machine dramatically. Could entering blackhole routes into the routing table possibly be more efficient? (It would allow SYNs to come in, but with SYN cookies enabled there'd be almost no overhead and the SYN-ACK would never make it back to the center.) Is there any other mechanism I should be looking at (e.g. a custom "divert" filter for SYNs)? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 20:57:33 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25E9416A474 for ; Tue, 20 Jun 2006 20:57:33 +0000 (UTC) (envelope-from regnauld@macbook.catpipe.net) Received: from macbook.catpipe.net (x0.dk [62.242.165.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF18043D5E for ; Tue, 20 Jun 2006 20:57:32 +0000 (GMT) (envelope-from regnauld@macbook.catpipe.net) Received: by macbook.catpipe.net (Postfix, from userid 1001) id B9CB4D7D53; Tue, 20 Jun 2006 22:57:30 +0200 (CEST) Date: Tue, 20 Jun 2006 22:57:30 +0200 From: Phil Regnauld To: Brett Glass Message-ID: <20060620205730.GC3968@catpipe.net> References: <7.0.1.0.2.20060620143845.06662330@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20060620143845.06662330@lariat.org> X-Operating-System: Darwin 8.6.1 i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.11 Cc: net@freebsd.org Subject: Re: Best way to block a long list of IPs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 20:57:33 -0000 Brett Glass (brett) writes: > > I've got an application in which I must block incoming TCP > connections to a FreeBSD server from a potentially large list of IP > addresses. Using IPFW is not a very efficient way to accomplish > this, because it must do a linear search of a list (either one > address per rule or an "or" list in a rule) and this could slow > down every packet entering the machine dramatically. pf tables are VERY efficient -- man pf.conf From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 21:07:36 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88D9616A47A for ; Tue, 20 Jun 2006 21:07:36 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2639043D6B for ; Tue, 20 Jun 2006 21:07:36 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k5KL7NJV001245; Tue, 20 Jun 2006 14:07:23 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k5KL7M0W001244; Tue, 20 Jun 2006 14:07:22 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Jun 2006 14:07:22 -0700 From: Luigi Rizzo To: Brett Glass , net@freebsd.org, Phil Regnauld Message-ID: <20060620140722.A1192@xorpc.icir.org> References: <7.0.1.0.2.20060620143845.06662330@lariat.org> <20060620205730.GC3968@catpipe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20060620205730.GC3968@catpipe.net>; from regnauld@catpipe.net on Tue, Jun 20, 2006 at 10:57:30PM +0200 Cc: Subject: Re: Best way to block a long list of IPs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 21:07:36 -0000 On Tue, Jun 20, 2006 at 10:57:30PM +0200, Phil Regnauld wrote: > Brett Glass (brett) writes: > > > > I've got an application in which I must block incoming TCP > > connections to a FreeBSD server from a potentially large list of IP > > addresses. Using IPFW is not a very efficient way to accomplish > > this, because it must do a linear search of a list (either one > > address per rule or an "or" list in a rule) and this could slow > > down every packet entering the machine dramatically. > > pf tables are VERY efficient -- man pf.conf there are efficient tables in ipfw as well, which Ruslan implemented some time ago -- yet another reason we should be grateful to him http://people.freebsd.org/~ru/help/en/ and also, if your address are in the same /24 subnet, you can use the ipfw address set format which looks like this 1.2.3.0/24{10,20,21,30,34,55} and can deal in constant time for up to 256 randomly distributed hosts. man ipfw has all the details. cheers luigi > _______________________________________________ > 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 Jun 20 21:10:17 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 406CB16A4AB for ; Tue, 20 Jun 2006 21:10:16 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D74CF43D46 for ; Tue, 20 Jun 2006 21:10:13 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by wx-out-0102.google.com with SMTP id t5so3826wxc for ; Tue, 20 Jun 2006 14:10:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DxyAHJOrSJVx9JV0O32ncTTm4SWgMjZ3xeEEo40zqoz71SB62y3f0h7c5rjxse6gJLH2XKqO1i+TF6MOIJTk8bZU5QNUytEskDsUM+gCu2QUgr4gjotVhZ8TGpT48ruxX7edWC1j8MQ7032GFRzrzlsLLbHGOIUg1gqFStc1qYE= Received: by 10.70.19.6 with SMTP id 6mr11076599wxs; Tue, 20 Jun 2006 14:10:12 -0700 (PDT) Received: by 10.70.83.15 with HTTP; Tue, 20 Jun 2006 14:10:12 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 01:10:12 +0400 From: "Andrew Pantyukhin" To: "Brett Glass" , "Phil Regnauld" In-Reply-To: <7.0.1.0.2.20060620143845.06662330@lariat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7.0.1.0.2.20060620143845.06662330@lariat.org> Cc: net@freebsd.org Subject: Re: Best way to block a long list of IPs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 21:10:17 -0000 On 6/21/06, Brett Glass wrote: > Everyone: > > I've got an application in which I must block incoming TCP > connections to a FreeBSD server from a potentially large list of IP > addresses. Using IPFW is not a very efficient way to accomplish > this, because it must do a linear search of a list (either one > address per rule or an "or" list in a rule) and this could slow > down every packet entering the machine dramatically. ipfw tables are stored in Radix trees, which are very efficient. From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 21:23:24 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE8B116A474 for ; Tue, 20 Jun 2006 21:23:24 +0000 (UTC) (envelope-from brett@lariat.org) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E83A243D66 for ; Tue, 20 Jun 2006 21:23:23 +0000 (GMT) (envelope-from brett@lariat.org) Received: from Anne (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id PAA14978; Tue, 20 Jun 2006 15:23:11 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <7.0.1.0.2.20060620151013.042be3f8@lariat.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 20 Jun 2006 15:22:46 -0600 To: Luigi Rizzo , net@freebsd.org, Phil Regnauld From: Brett Glass In-Reply-To: <20060620140722.A1192@xorpc.icir.org> References: <7.0.1.0.2.20060620143845.06662330@lariat.org> <20060620205730.GC3968@catpipe.net> <20060620140722.A1192@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Subject: Re: Best way to block a long list of IPs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 21:23:24 -0000 At 03:07 PM 6/20/2006, Luigi Rizzo wrote: >there are efficient tables in ipfw as well, which Ruslan implemented >some time ago -- yet another reason we should be grateful to him How would I build a table of arbitrary IP addresses and be able to update it atomically (i.e. add and delete individual addresses and not lose all filtering when there was a modification)? >and also, if your address are in the same /24 subnet, you can use >the ipfw address set format which looks like this > 1.2.3.0/24{10,20,21,30,34,55} >and can deal in constant time for up to 256 randomly distributed hosts. Not random enough. Each of these IP addresses could be anywhere in the 32 bit IPv4 address range. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 21:26:51 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16C0E16A494 for ; Tue, 20 Jun 2006 21:26:51 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1263343D7F for ; Tue, 20 Jun 2006 21:26:50 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k5KLQl9E001395; Tue, 20 Jun 2006 14:26:47 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k5KLQl0X001394; Tue, 20 Jun 2006 14:26:47 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Jun 2006 14:26:47 -0700 From: Luigi Rizzo To: Brett Glass Message-ID: <20060620142647.A1333@xorpc.icir.org> References: <7.0.1.0.2.20060620143845.06662330@lariat.org> <20060620205730.GC3968@catpipe.net> <20060620140722.A1192@xorpc.icir.org> <7.0.1.0.2.20060620151013.042be3f8@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <7.0.1.0.2.20060620151013.042be3f8@lariat.org>; from brett@lariat.org on Tue, Jun 20, 2006 at 03:22:46PM -0600 Cc: net@freebsd.org Subject: Re: Best way to block a long list of IPs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 21:26:51 -0000 On Tue, Jun 20, 2006 at 03:22:46PM -0600, Brett Glass wrote: > At 03:07 PM 6/20/2006, Luigi Rizzo wrote: > > >there are efficient tables in ipfw as well, which Ruslan implemented > >some time ago -- yet another reason we should be grateful to him > > How would I build a table of arbitrary IP addresses and be able > to update it atomically (i.e. add and delete individual addresses > and not lose all filtering when there was a modification)? please have a look at the ipfw manpage, the relevant commands are ipfw table number add addr[/masklen] [value] ipfw table number delete addr[/masklen] and the matching is as fast as a route lookup as it uses the same type of data structure. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 21:31:53 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D51BD16A4D1 for ; Tue, 20 Jun 2006 21:31:53 +0000 (UTC) (envelope-from brett@lariat.org) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18D0F43D68 for ; Tue, 20 Jun 2006 21:31:52 +0000 (GMT) (envelope-from brett@lariat.org) Received: from Anne (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id PAA15163; Tue, 20 Jun 2006 15:31:49 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <7.0.1.0.2.20060620152540.06cc64e8@lariat.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 20 Jun 2006 15:26:25 -0600 To: Luigi Rizzo , net@freebsd.org, Phil Regnauld From: Brett Glass In-Reply-To: <7.0.1.0.2.20060620151013.042be3f8@lariat.org> References: <7.0.1.0.2.20060620143845.06662330@lariat.org> <20060620205730.GC3968@catpipe.net> <20060620140722.A1192@xorpc.icir.org> <7.0.1.0.2.20060620151013.042be3f8@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Subject: Re: Best way to block a long list of IPs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 21:31:53 -0000 Oh, by the way: I should mention that the server is running FreeBSD 4.11. It's doing file-intensive work, and file system performance in FreeBSD 6.x is noticeably slower. Your message does suggest another possible solution, though. Would blackhole routes be more efficient than using IPFW? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Tue Jun 20 21:36:42 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9347416A47E for ; Tue, 20 Jun 2006 21:36:42 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C8F343D48 for ; Tue, 20 Jun 2006 21:36:42 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k5KLaeRi001531; Tue, 20 Jun 2006 14:36:40 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k5KLaeol001530; Tue, 20 Jun 2006 14:36:40 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Jun 2006 14:36:40 -0700 From: Luigi Rizzo To: Brett Glass Message-ID: <20060620143640.B1416@xorpc.icir.org> References: <7.0.1.0.2.20060620143845.06662330@lariat.org> <20060620205730.GC3968@catpipe.net> <20060620140722.A1192@xorpc.icir.org> <7.0.1.0.2.20060620151013.042be3f8@lariat.org> <7.0.1.0.2.20060620152540.06cc64e8@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <7.0.1.0.2.20060620152540.06cc64e8@lariat.org>; from brett@lariat.org on Tue, Jun 20, 2006 at 03:26:25PM -0600 Cc: net@freebsd.org Subject: Re: Best way to block a long list of IPs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Jun 2006 21:36:42 -0000 On Tue, Jun 20, 2006 at 03:26:25PM -0600, Brett Glass wrote: > Oh, by the way: I should mention that the server is running FreeBSD > 4.11. It's doing file-intensive work, and file system performance > in FreeBSD 6.x is noticeably slower. ipfw tables are also in 4.11 > Your message does suggest another possible solution, though. Would > blackhole routes be more efficient than using IPFW? > > --Brett Glass From owner-freebsd-net@FreeBSD.ORG Wed Jun 21 06:32:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62D7F16A502; Wed, 21 Jun 2006 06:32:00 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2F2943D45; Wed, 21 Jun 2006 06:31:59 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr4.xs4all.nl (8.13.6/8.13.6) with ESMTP id k5L6VvTe001097; Wed, 21 Jun 2006 08:31:58 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.6/8.13.3) with ESMTP id k5L6VvHt065701; Wed, 21 Jun 2006 08:31:57 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.6/8.13.6/Submit) id k5L6VutP065700; Wed, 21 Jun 2006 08:31:56 +0200 (CEST) (envelope-from wb) Date: Wed, 21 Jun 2006 08:31:56 +0200 From: Wilko Bulte To: Jim Bryant Message-ID: <20060621063156.GB65647@freebie.xs4all.nl> References: <449834CA.2030005@chattingaway.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449834CA.2030005@chattingaway.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org, freebsd-platforms@freebsd.org, freebsd-net@freebsd.org, freebsd-sparc64@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Problem: fpa(4) on sparc64 6.1-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jun 2006 06:32:00 -0000 On Tue, Jun 20, 2006 at 12:47:54PM -0500, Jim Bryant wrote.. > I am getting a panic with a GENERIC with all non-available hardware > drivers stripped out with "device fddi" and "device fpa" in the config. > The only things I added to GENERIC after stripping out the unneeded > things was the fddi, the sound, and the openfirmware. The system boots > fine with the fddi stuff commented out of the config. > > Any suggestions? Is anyone working on this? fpa(4) was/is also toast on FreeBSD/alpha. It used to work once, but since a long time it only worked on i386. Don't expect anyone to work on it, FDDI is quite rare and the original driver writer is gone IIRC. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Wed Jun 21 06:32:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62F9316A47A for ; Wed, 21 Jun 2006 06:32:48 +0000 (UTC) (envelope-from gurdiga@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id C567943D45 for ; Wed, 21 Jun 2006 06:32:47 +0000 (GMT) (envelope-from gurdiga@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so1680061uge for ; Tue, 20 Jun 2006 23:32:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FoHOIknjbdPL4Qq9Xa4PAO8TT4qJBS95Qt2jxeL1tPX56fH/p4KhJ33zBfqGSCSPeaXaLSzEM9mFxxfYlifQhXn2hlPvO7NtvJrSnhP6/L9yyd9tZp03OfH2NDf4WLyvrcP3N5M7roVD0zuTNY2cmEbPIs3cPc+NvWwBMS7ZoAs= Received: by 10.78.42.7 with SMTP id p7mr3159363hup; Tue, 20 Jun 2006 23:25:38 -0700 (PDT) Received: by 10.78.12.10 with HTTP; Tue, 20 Jun 2006 23:25:38 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 09:25:38 +0300 From: "Vlad GURDIGA" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: nat question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 06:32:48 -0000 Hello, I could not figureout the answer to a question. Here is the situation: PC A: Windows XP Pro. PC B: FreeBSD 6.1, connected to internet, acting as a gateway for PC A, with NAT (built by hanbook instructions http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-natd.html), open firewall, no restrictions. For long time I have used the PC A with PC B as gateway and everything worked just fine, but now PC A can only ping any host (by IP) in Internet. No other traffic (DNS queries, FTP or HTTP) does not reach the Internet comming back with TTL exceeded response apparently from de destination host (I've seen this on PC B with Ethereal). Question: Is there any way my ISP can 'see' and cut out NATted traffic from PC A letting only the traffic from PC B pass?! How?! From owner-freebsd-net@FreeBSD.ORG Wed Jun 21 07:49:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAEC616A474; Wed, 21 Jun 2006 07:49:46 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx0.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 406E143D46; Wed, 21 Jun 2006 07:49:45 +0000 (GMT) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx0.rink.nu (Postfix) with ESMTP id DC66717072; Wed, 21 Jun 2006 09:50:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx0.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu+z-aJWnzzX; Wed, 21 Jun 2006 09:49:56 +0200 (CEST) Received: by mx0.rink.nu (Postfix, from userid 1678) id 1358F1706D; Wed, 21 Jun 2006 09:49:56 +0200 (CEST) Date: Wed, 21 Jun 2006 09:49:56 +0200 From: Rink Springer To: Wilko Bulte Message-ID: <20060621074955.GC91963@rink.nu> References: <449834CA.2030005@chattingaway.com> <20060621063156.GB65647@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0lnxQi9hkpPO77W3" Content-Disposition: inline In-Reply-To: <20060621063156.GB65647@freebie.xs4all.nl> User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org, freebsd-drivers@freebsd.org, freebsd-platforms@freebsd.org, freebsd-sparc64@freebsd.org, freebsd-net@freebsd.org, Jim Bryant Subject: Re: Problem: fpa(4) on sparc64 6.1-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jun 2006 07:49:46 -0000 --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jun 21, 2006 at 08:31:56AM +0200, Wilko Bulte wrote: > On Tue, Jun 20, 2006 at 12:47:54PM -0500, Jim Bryant wrote.. > > I am getting a panic with a GENERIC with all non-available hardware=20 > > drivers stripped out with "device fddi" and "device fpa" in the config.= =20 > > The only things I added to GENERIC after stripping out the unneeded=20 > > things was the fddi, the sound, and the openfirmware. The system boots= =20 > > fine with the fddi stuff commented out of the config. > >=20 > > Any suggestions? Is anyone working on this? >=20 > fpa(4) was/is also toast on FreeBSD/alpha. It used to work once, but sin= ce > a long time it only worked on i386. fpa(4) is also broken on most i386 systems (it fails to attach). The Linux driver has no such problems, however. If anyone is willing to look at this, I have a couple fpa(4) cards available for donation. Contact me off-list if anyone is interested. --=20 Rink P.W. Springer - http://rink.nu "Richter: Tribute? You steal men's souls, and make them your slaves! Dracula: Perhaps the same could be said of all religions." - Castlevania: Symphony of the Night --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEmPojb3O60uztv/8RAoOjAKCwO+b/8hlPWbDn02N/K9QqbvMy3gCeLPFk +HQvxv2/nAY8Szx6YIkKubE= =kfwL -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 21 09:58:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55B2616A526; Wed, 21 Jun 2006 09:58:55 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1796943D96; Wed, 21 Jun 2006 09:58:51 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp4-g19.free.fr (Postfix) with ESMTP id B09C6866C; Wed, 21 Jun 2006 11:58:50 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 6F03C9C3C5; Wed, 21 Jun 2006 09:59:20 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 5EB3D40A5; Wed, 21 Jun 2006 11:41:05 +0200 (CEST) Date: Wed, 21 Jun 2006 11:41:04 +0200 From: Jeremie Le Hen To: "Andrey V. Elsukov" Message-ID: <20060621094104.GB7019@obiwan.tataz.chchile.org> References: <44618B0A.60504@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44618B0A.60504@yandex.ru> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org, Julian Elischer , freebsd-ipfw@freebsd.org Subject: Re: [fbsd] [patch] ipfw packet tagging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jun 2006 09:58:55 -0000 Hi Andrey, On Wed, May 10, 2006 at 10:41:14AM +0400, Andrey V. Elsukov wrote: > Hi, All! > > I have written a small patch for a packets > tagging with ipfw. > > The description of OpenBSD packet tagging is here: > http://www.openbsd.org/faq/pf/tagging.html > > An IPFW tags is not compatible with PF tags. > > This feature can be usable with some netgraph modules. > We can create a netgraph node that marks packets with some tags > and use this node with other nodes. IPFW can detect and filter > packets with tags. > > Also we can mark packets before NAT and detect tagged packets > after translation. > NAT based on divert sockets do not allow this, but i think > ng_nat can.. > > Patches can be found here: > http://butcher.heavennet.ru/patches/kernel/ipfw_tags/ Looking at the patch lets me see that you are using the generic mbuf tags. This means the tag should be available along the packet's trip through the kernel. Would it be possible to slightly modify the routing code in order to make those tags a routing criteria ? Julian Elischer also has a neat patch that modifies the ipfw table but he hasn't provided it so far [1]. [1] http://lists.freebsd.org/pipermail/freebsd-net/2006-May/010563.html Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Wed Jun 21 10:10:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D62D16A492; Wed, 21 Jun 2006 10:10:42 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8764243D78; Wed, 21 Jun 2006 10:10:39 +0000 (GMT) (envelope-from vadimnuclight@tpu.ru) Received: by relay1.tpu.ru (Postfix, from userid 501) id 965D21C806E; Wed, 21 Jun 2006 17:10:37 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 6CC9510D8D2; Wed, 21 Jun 2006 17:10:37 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 17:10:37 +0700 Received: from nuclight.avtf.net ([82.117.64.107]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 17:10:36 +0700 To: "Jeremie Le Hen" , "Andrey V. Elsukov" References: <44618B0A.60504@yandex.ru> <20060621094104.GB7019@obiwan.tataz.chchile.org> Message-ID: Date: Wed, 21 Jun 2006 17:09:42 +0700 From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20060621094104.GB7019@obiwan.tataz.chchile.org> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 21 Jun 2006 10:10:36.0812 (UTC) FILETIME=[F0CA5CC0:01C6951A] Cc: freebsd-net@freebsd.org, Julian Elischer , freebsd-ipfw@freebsd.org Subject: Re: [fbsd] [patch] ipfw packet tagging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jun 2006 10:10:42 -0000 21.06.06 @ 16:41 Jeremie Le Hen wrote: > Looking at the patch lets me see that you are using the generic mbuf > tags. This means the tag should be available along the packet's > trip through the kernel. Would it be possible to slightly modify > the routing code in order to make those tags a routing criteria ? > > Julian Elischer also has a neat patch that modifies the ipfw table > but he hasn't provided it so far [1]. > > [1] http://lists.freebsd.org/pipermail/freebsd-net/2006-May/010563.html The ipfw packet tagging patch was committed to src tree and will be MFCed to RELENG_6 about this weekend. I am currently working on ng_tag(4) netgraph node which could deal with tags (see http://antigreen.org/vadim/freebsd/ng_tag/) - I think, in theory it is possible to tag-based routing inside netgraph onto netgraph interfaces. -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Wed Jun 21 10:20:43 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF6F316A580; Wed, 21 Jun 2006 10:20:43 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mx18.yandex.ru (smtp2.yandex.ru [213.180.200.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5298043D72; Wed, 21 Jun 2006 10:20:41 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([81.18.142.225]:274 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S3378103AbWFUKUk (ORCPT + 1 other); Wed, 21 Jun 2006 14:20:40 +0400 X-Comment: RFC 2476 MSA function at smtp2.yandex.ru logged sender identity as: bu7cher Message-ID: <44991D76.9010809@yandex.ru> Date: Wed, 21 Jun 2006 14:20:38 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Jeremie Le Hen References: <44618B0A.60504@yandex.ru> <20060621094104.GB7019@obiwan.tataz.chchile.org> In-Reply-To: <20060621094104.GB7019@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer , freebsd-ipfw@freebsd.org Subject: Re: [fbsd] [patch] ipfw packet tagging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jun 2006 10:20:44 -0000 Jeremie Le Hen wrote: > trip through the kernel. Would it be possible to slightly modify > the routing code in order to make those tags a routing criteria ? You can use tags with a fwd rules, like a: # ipfw add fwd $gw_addr ip from any to any tagged $N And as i know, oleg@ has committed a new patch that uses a tableargs feature with ipfw_tags to CURRENT: http://docs.freebsd.org/cgi/mid.cgi?200606150939.k5F9dMrB019958 -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Wed Jun 21 11:32:26 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B93916A482 for ; Wed, 21 Jun 2006 11:32:26 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFF8E43D60 for ; Wed, 21 Jun 2006 11:31:34 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k5LBV1Yb016651; Wed, 21 Jun 2006 14:31:01 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Wed, 21 Jun 2006 14:31:01 +0300 (EEST) From: Dmitry Pryanishnikov To: Luigi Rizzo In-Reply-To: <20060620143640.B1416@xorpc.icir.org> Message-ID: <20060621141816.T41119@atlantis.atlantis.dp.ua> References: <7.0.1.0.2.20060620143845.06662330@lariat.org> <20060620205730.GC3968@catpipe.net> <20060620140722.A1192@xorpc.icir.org> <7.0.1.0.2.20060620151013.042be3f8@lariat.org> <7.0.1.0.2.20060620152540.06cc64e8@lariat.org> <20060620143640.B1416@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Brett Glass , net@freebsd.org Subject: Re: Best way to block a long list of IPs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jun 2006 11:32:26 -0000 Hello! On Tue, 20 Jun 2006, Luigi Rizzo wrote: > On Tue, Jun 20, 2006 at 03:26:25PM -0600, Brett Glass wrote: >> Oh, by the way: I should mention that the server is running FreeBSD >> 4.11. It's doing file-intensive work, and file system performance >> in FreeBSD 6.x is noticeably slower. > > ipfw tables are also in 4.11 Just don't forget to switch your system to ipfw2 (RELENG_4 uses ipfw1 by default). Switching is described in "USING IPFW2 IN FreeBSD-STABLE" section of ipfw(8). Manpage suggests recompiling /sbin/ipfw and /usr/lib/libalias along with the kernel, but /sbin/natd is statically linked against libalias in RELENG_4, so it also must be recompiled. Don't forget that you can't mix kernel compiled with "options IPFW2" and ipfw1-based binaries (compiled w/o IPFW2 defined) and vice versa (ipfw1-based kernel with ipfw2-based userland), so follow a standard upgrade path to be safe: 1) build (don't install) new binaries, 2) build and install new kernel, 3) reboot to single-user mode, 4) install new binaries, 5) reboot. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Jun 21 18:15:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96AD616A47F; Wed, 21 Jun 2006 18:15:34 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82DDC43D6A; Wed, 21 Jun 2006 18:15:25 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.7/8.13.7/Debian-1) with ESMTP id k5LIFAcO024229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2006 21:15:12 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.7/8.13.7) with ESMTP id k5LIF5Oa001405; Wed, 21 Jun 2006 21:15:05 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.7/8.13.7/Submit) id k5LIF5rT001404; Wed, 21 Jun 2006 21:15:05 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Wed, 21 Jun 2006 21:15:04 +0300 From: Giorgos Keramidas To: Doug Barton Message-ID: <20060621181504.GA1381@gothmog.pc> References: <449228FA.50303@thebeastie.org> <20060616122855.GA29279@uk.tiscali.com> <20060616154306.GA18578@verio.net> <44930029.5050308@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44930029.5050308@FreeBSD.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.34, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 1.06, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-net@freebsd.org Subject: Re: VPN with FAST_IPSEC and ipsec tools X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Jun 2006 18:15:34 -0000 On 2006-06-16 12:02, Doug Barton wrote: > David DeSimone wrote: > > I ran into the same thing when analyzing the handbook's examples, and > > quickly abandoned the handbook when writing my own configs. > > Those who are more knowledgeable on this topic might want to > consider writing an update, or an entirely new section for > this. You don't need to learn the docbook stuff to do this, > there are folks on freebsd-doc@ who would be glad to take that > on as a project. Indeed. I don't know a lot about IPSEC or GIF tunnels, but I can handle the SGML part of things... - Giorgos From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 00:49:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59C2316A575 for ; Fri, 23 Jun 2006 00:49:44 +0000 (UTC) (envelope-from cybercorecentre@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FE49455BC for ; Thu, 22 Jun 2006 23:43:48 +0000 (GMT) (envelope-from cybercorecentre@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so797424uge for ; Thu, 22 Jun 2006 16:43:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=Hyymuy3RAfiD22MP3X19m3PI2ZMFBLPAn81VASkLoe8ra0T4NHoPrIf2fDmdnD51p0OKm0M/MpwZZh7ijf9b0+2OTTTgAAfCz4y85f/Cy/pobdOM3YlDqolBOKY2R+klFcqfaE8oD4U7GJ7PjXlupb+/KJZUkQ6iT2UcQ8MieWY= Received: by 10.67.26.7 with SMTP id d7mr1608797ugj; Thu, 22 Jun 2006 16:43:46 -0700 (PDT) Received: from ?192.0.0.1? ( [62.77.228.138]) by mx.gmail.com with ESMTP id c1sm1465695ugf.2006.06.22.16.43.46; Thu, 22 Jun 2006 16:43:46 -0700 (PDT) Message-ID: <449B2A99.6060500@gmail.com> Date: Fri, 23 Jun 2006 01:41:13 +0200 From: Jax User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: traffic shaping FreeBSD vs MiCrotiC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jun 2006 00:49:44 -0000 Hi all! I'm new on this list, so greetings everyone. I want to build a reliable bridge which do traffic shaping for my little home network (but nothing else, i don't need firewall, dns, dhcp or any other future on this mashine). The reason why the other software is microtic ( http://www.microtic.com ), because i already have it so it's my decision which will i use (so pls don't tell me fbsd better because it's free :-) First of all I'm not expert in traffic shaping, but I use bsd,linux for many different other task. It seems to be a little harder for me to setup traffic in freebsd, but it can't be a reason to don't use it. BTW I read this article: http://info.iet.unipi.it/~luigi/ip_dummynet/ so i can use this picobsd image too. I want your advice which one is better for traffic shaping and _why_? And is there anything in traffic shaping which i can't do in the other OS? Regards, Jax From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 03:17:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 060F916A47C for ; Fri, 23 Jun 2006 03:17:42 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 598D843D45 for ; Fri, 23 Jun 2006 03:17:39 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id E17174CD52 for ; Fri, 23 Jun 2006 03:18:03 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 8444B4CD39 for ; Fri, 23 Jun 2006 03:18:03 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id 61C6F8A029; Fri, 23 Jun 2006 13:17:37 +1000 (EST) Received: from [192.168.46.102] (unknown [192.168.46.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id 5D82A8A027; Fri, 23 Jun 2006 13:17:37 +1000 (EST) Message-ID: <449B5D50.8000700@thebeastie.org> Date: Fri, 23 Jun 2006 13:17:36 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060404 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David DeSimone References: <449228FA.50303@thebeastie.org> <20060616122855.GA29279@uk.tiscali.com> <20060616154306.GA18578@verio.net> In-Reply-To: <20060616154306.GA18578@verio.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org, B.Candler@pobox.com Subject: Re: VPN with FAST_IPSEC and ipsec tools X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jun 2006 03:17:42 -0000 David DeSimone wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Brian Candler wrote: > > >>Ah, I guess this means you're following the instructions in the >>FreeBSD handbook, which last time I looked gave a most bizarre and >>unnecessary way of setting up IPSEC (GIF tunneling running on top of >>IPSEC *tunnel* mode). I raised it on this list before. >> >> > >I ran into the same thing when analyzing the handbook's examples, and >quickly abandoned the handbook when writing my own configs. > > > >>Most people are better off just setting up IPSEC tunnel mode. A few >>use GIF running on top of IPSEC _transport_ mode (e.g. those running >>routing protocols like OSPF over tunnels) >> >> > >The main reason to use IPSEC tunnel mode and avoid GIF is that such a >config is interoperable with other IPSEC implementations (Cisco, >Checkpoint, etc), and thus is much more useful in the real world. > >- -- >David DeSimone == Network Admin == fox@verio.net > OK that said, how do you create a network to network tunnel based VPN without using the gif or gre devices? I been trying to link up 2 networks between to VPN gateways and I have kind of given up, all the examples out there use a gif tunnel or a gre tunnel. I simply haven't been able to work out the routes or how to make ipsec-tools trigger based on seeing interesting traffic, its using a preshared key configuration. I have been using the typical ipsec.conf settings that most examples give for tunnel configurations but still no luck. At first I thought it was a NAT-T problem as the reason the IKE wasn't kicking in but after testing with pure internet IPs and no nat I realized it wasn't that. If I could just have an example to look at I think it could really help. Thanks Mike From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 06:22:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8D8216A492 for ; Fri, 23 Jun 2006 06:22:29 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F97143D45 for ; Fri, 23 Jun 2006 06:22:29 +0000 (GMT) (envelope-from fox@verio.net) Received: from [129.250.36.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp id 1Ftf3h-0006QW-Nn for freebsd-net@freebsd.org; Fri, 23 Jun 2006 06:22:25 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp2.email.verio.net with esmtp id 1Ftf3h-0001Ya-EA for freebsd-net@freebsd.org; Fri, 23 Jun 2006 06:22:25 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id E273D8E2CC; Fri, 23 Jun 2006 01:22:21 -0500 (CDT) Date: Fri, 23 Jun 2006 01:22:21 -0500 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20060623062221.GA23272@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <449228FA.50303@thebeastie.org> <20060616122855.GA29279@uk.tiscali.com> <20060616154306.GA18578@verio.net> <449B5D50.8000700@thebeastie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <449B5D50.8000700@thebeastie.org> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: VPN with FAST_IPSEC and ipsec tools X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 06:22:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Vince wrote: > > > The main reason to use IPSEC tunnel mode and avoid GIF is that such > > a config is interoperable with other IPSEC implementations, and thus > > is much more useful in the real world. > > OK that said, how do you create a network to network tunnel based VPN > without using the gif or gre devices? Ok, here's a typical setup that I've used. Suppose you have two gateways: Gateway 1 IP = 1.2.3.4 Networks behind it: 192.168.1.0/24 192.168.2.0/24 Gateway 2 IP = 5.6.7.8 Networks behind it: 192.168.11.0/24 192.168.12.0/24 Most of the examples you'll find will teach you to use IPSEC in Transport mode. But Transport mode is only used for one endpoint to talk to another endpoint. What you want here (and what other gateways like Cisco will implement) is Tunnel mode, where the traffic is encapsulated rather than merely encrypted. First you must define your SA's (security associations) in ipsec.conf. SA's are defined from the perspective of the gateway. What is "inbound" on one gateway is "outbound" on the other. You can't use the same ipsec.conf on each endpoint; you have to tailor it to match what it should expect to see. Gateway 1's ipsec.conf: # This is ipsec.conf # Load it using: setkey -f /etc/ipsec.conf spdflush; # If you ever reload you will want to start fresh # Outbound traffic spdadd 192.168.1.0/24 192.168.11.0/24 any \ -P out ipsec esp/tunnel/1.2.3.4-5.6.7.8/unique; spdadd 192.168.2.0/24 192.168.11.0/24 any \ -P out ipsec esp/tunnel/1.2.3.4-5.6.7.8/unique; spdadd 192.168.1.0/24 192.168.12.0/24 any \ -P out ipsec esp/tunnel/1.2.3.4-5.6.7.8/unique; spdadd 192.168.2.0/24 192.168.12.0/24 any \ -P out ipsec esp/tunnel/1.2.3.4-5.6.7.8/unique; # Inbound traffic spdadd 192.168.11.0/24 192.168.1.0/24 any \ -P in ipsec esp/tunnel/5.6.7.8-1.2.3.4/unique; spdadd 192.168.12.0/24 192.168.1.0/24 any \ -P in ipsec esp/tunnel/5.6.7.8-1.2.3.4/unique; spdadd 192.168.11.0/24 192.168.2.0/24 any \ -P in ipsec esp/tunnel/5.6.7.8-1.2.3.4/unique; spdadd 192.168.12.0/24 192.168.2.0/24 any \ -P in ipsec esp/tunnel/5.6.7.8-1.2.3.4/unique; Things to notice: There are 8 SA's defined, because each gateway has two subnets, and each unique subnet needs an SA defined IN EACH DIRECTION. So, 2 subnets here x 2 subnets there x 2 directions = 8 SA's total. Half of the SA's will be from the perspective of inbound traffic, (using "-P in") and the other half will be output ("-P out"). When an SA is inbound ("-P in"), the tunnel descriptor will have the remote gateway listed first, followed by the local gateway. Inbound traffic flows FROM the remote gateway (5.6.7.8) TO the local gateway (1.2.3.4), leading to a descriptor of "esp/tunnel/5.6.7.8-1.2.3.4/unique;" When an SA is outbound ("-P out"), the descriptor will be reversed, showing traffic FROM this gateway TO the remote, as in "esp/tunnel/1.2.3.4-5.6.7.8/unique;" When an SA is inbound ("-P in"), the remote gateway's network will appear first (because it is the source), followed by the local gateway's network (the destination). That is why the first inbound specification reads "spdadd 192.168.11.0/24 192.168.1.0/24 any", specifying traffic coming FROM a remote network TO a local network. An output SA specifies a local network followed by a remote network. I hope you can see the pattern. Gateway 2's ipsec.conf: # This is ipsec.conf # Load it using: setkey -f /etc/ipsec.conf spdflush; # If you ever reload you will want to start fresh # Inbound traffic spdadd 192.168.11.0/24 192.168.1.0/24 any \ -P out ipsec esp/tunnel/5.6.7.8-1.2.3.4/unique; spdadd 192.168.12.0/24 192.168.1.0/24 any \ -P out ipsec esp/tunnel/5.6.7.8-1.2.3.4/unique; spdadd 192.168.11.0/24 192.168.2.0/24 any \ -P out ipsec esp/tunnel/5.6.7.8-1.2.3.4/unique; spdadd 192.168.12.0/24 192.168.2.0/24 any \ -P out ipsec esp/tunnel/5.6.7.8-1.2.3.4/unique; # Outbound traffic spdadd 192.168.1.0/24 192.168.11.0/24 any \ -P in ipsec esp/tunnel/1.2.3.4-5.6.7.8/unique; spdadd 192.168.2.0/24 192.168.11.0/24 any \ -P in ipsec esp/tunnel/1.2.3.4-5.6.7.8/unique; spdadd 192.168.1.0/24 192.168.12.0/24 any \ -P in ipsec esp/tunnel/1.2.3.4-5.6.7.8/unique; spdadd 192.168.2.0/24 192.168.12.0/24 any \ -P in ipsec esp/tunnel/1.2.3.4-5.6.7.8/unique; Things to notice: The pattern is exactly the same, but what was defined as "-P out" on the other gateway shows up as "-P in" on this gateway, and vice-versa. This configuration is sufficient to define the necessary SA prototypes, but in order to negotiate keys and parameters, you need IKE, and for that you need the ipsec-tools port, in order to get racoon(8). Just as each gateway has its own tailored ipsec.conf, each gateway also has its own racoon.conf. There is of course more than one way to set up an IKE daemon. These are the settings that I use. Gateway 1's racoon.conf: # This is racoon.conf # Loaded by racoon when it starts, or when receiving a HUP. log notify; # notify(*), debug, debug2 path pre_shared_key "/etc/ipsec.keys"; path pidfile "/var/run/racoon.pid"; listen { isakmp 1.2.3.4; strict_address; # Needed? } remote 5.6.7.8 { exchange_mode aggressive,main,base; my_identifier address 1.2.3.4; peers_identifier address 5.6.7.8; verify_identifier off; proposal_check claim; # obey, strict, claim(*), exact(*) proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; lifetime time 24 hours; } } sainfo address 192.168.1.0/24 any address 192.168.11.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.2.0/24 any address 192.168.11.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.1.0/24 any address 192.168.12.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.2.0/24 any address 192.168.12.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.11.0/24 any address 192.168.1.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.11.0/24 any address 192.168.2.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.12.0/24 any address 192.168.1.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.12.0/24 any address 192.168.2.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } Things to notice: Some people feel aggressive mode is not as secure. If you don't like it, remove it. There should be one "remote" section for each gateway that you converse with. In my config, I specify IP's as identifiers. I am not sure if this is actually necessary, which is why I turn verification off. I have not tested this portion strongly, but the config does work. The main use of proposal_check is to decide what to do when the two gateways do not agree on lifetime parameters. It is best for the gateways to never disagree, of course. :) The proposal section sets encryption and verification parameters for Phase 1 of IKE, where the gateways first establish trust. My config uses pre-shared secrets. I have not (yet) experimented with certificate-based authentication. The "sainfo" sections duplicate the information found in ipsec.conf. For every SA, there needs to be an "sainfo" section describing the exact same pair of networks. Yes, it is cumbersome. I have wished that racoon could just read the information out of the kernel, but I believe the problem is that the kernel only keeps track of networks that match SA's. The other parameters (lifetime, encryption, etc) are not stored anywhere else. They come from racoon negotiating these parameters with the remote system. If you are really lucky, and all your tunnels use exactly the same encryption parameters, you could instead use a single "anonymous" sainfo section like so: sainfo anonymous { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } This will avoid a lot of repetitive data entry. However, if you have different tunnels with different peers who want different parameters, you will have to specify them explicitly. Yes, you must specify the compression algorithm, even if you are not going to use compression. Racoon demands it. Gateway 2's racoon.conf: # This is racoon.conf # Loaded by racoon when it starts, or when receiving a HUP. log notify; # notify(*), debug, debug2 path pre_shared_key "/etc/ipsec.keys"; path pidfile "/var/run/racoon.pid"; listen { isakmp 5.6.7.8; strict_address; # Needed? } remote 1.2.3.4 { exchange_mode aggressive,main,base; my_identifier address 5.6.7.8; peers_identifier address 1.2.3.4; verify_identifier off; proposal_check claim; # obey, strict, claim(*), exact(*) proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; lifetime time 24 hours; } } sainfo address 192.168.1.0/24 any address 192.168.11.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.2.0/24 any address 192.168.11.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.1.0/24 any address 192.168.12.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.2.0/24 any address 192.168.12.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.11.0/24 any address 192.168.1.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.11.0/24 any address 192.168.2.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.12.0/24 any address 192.168.1.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } sainfo address 192.168.12.0/24 any address 192.168.2.0/24 any { lifetime time 1 hour; encryption_algorithm aes; authentication_algorithm hmac_sha1; compression_algorithm deflate; } Things to notice: Yes, this file is almost exactly the same, with the IP's swapped. What is local here is remote there, and vice-versa. The "sainfo" sections must be left unchanged. If they were different, the two racoons would not agree on parameter negotiations, and would fail to negotiate a tunnel. Finally, you must specify the keys. Each gateway needs to define the keys used on the other gateways. Gateway 1's ipsec.keys: # Keys for IKE 5.6.7.8 SECRET_KEY Gateway 2's ipsec.keys: # Keys for IKE 1.2.3.4 SECRET_KEY Things to notice: Each gateway has keys defined for OTHER gateways. The OTHER gateway has to have the SAME key defined for THIS gateway. This ipsec.keys file MUST BE PROTECTED. If you do not have it set to permissions 0600, racoon will silently IGNORE the file, and your IKE negotiation will fail, and there will be no indication in the logs as to why. Check your permissions! With these parameters a pair of gateways should be able to establish IPSEC sessions with each other, even if the other gateway is some other standards-compliant IPSEC implementation, such as found on Cisco or Checkpoint devices. I have tested specifically with those implementations, and have had no problems. I suppose I should talk about PF. All my gateways use PF, so I have not tested with any other firewall methods such as ipfw. You must certainly allow your gateways to speak IKE and ESP to each other if you want them to work. I use a table called IPSEC_PEERS which I load with the IP's of my peer gateways, and then I use these rules to pass traffic: EXTIP="(fxp0)" pass in quick proto udp from to $EXTIP port 500 keep state pass in quick proto esp from to $EXTIP keep state pass out quick from self keep state I am not convinced that "keep state" is needed or even useful here, since neither UDP nor ESP are stateful protocols, and even if PF did not keep state the traffic would still be allowed anyway. An interesting side effect of IPSEC is that PF cannot track the full state of it ("enc0" patches notwithstanding). Traffic arrives on an internal interface, and then if it becomes encrypted, the traffic "mysteriously disappears" as far as PF can tell. The traffic never goes out another interface. However, reply traffic from the other side of the tunnel does magically "appear" from nowhere. A typical gateway will have an "outbound" rule like this: pass in quick on { $INT } all keep state where $INT defines the interfaces on the internal side. Since "keep state" is specified, reply traffic from the external net will have no trouble coming back in. However, VPN traffic does not come in through the external network... at least, not in any way that PF can determine. The traffic comes in as seemingly-unrelated ESP, is decrypted in the kernel, then magically appears decrypted on the internal interface for the first time. Your firewall will not understand this and will block the traffic unless you add a rule like this: # VPN traffic appears here...? pass out quick on { $INT } to $INT:network keep state So, traffic appearing suddenly on an internal interface, destined for an internal network, is permitted, on the assumption that it must have come from an external VPN. Naturally you can (and probably should) set up much more prohibitive rules, but keep in mind that the first chance you will have to sense inbound VPN traffic is when it is headed OUTBOUND on your INTERNAL interfaces. - -- David DeSimone == Network Admin == fox@verio.net "It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEm4idFSrKRjX5eCoRAkFEAJ9QCbodDJUvwG3RG0fuQTXlKRX2dwCbBUhG Q2QZv3RX582uXHSwBeyQuUk= =LxYq -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 08:27:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13FDE16A492 for ; Fri, 23 Jun 2006 08:27:40 +0000 (UTC) (envelope-from reddie@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 4ABF343D46 for ; Fri, 23 Jun 2006 08:27:39 +0000 (GMT) (envelope-from reddie@gmx.net) Received: (qmail 31536 invoked by uid 0); 23 Jun 2006 08:27:37 -0000 Received: from 24.132.187.184 by www107.gmx.net with HTTP; Fri, 23 Jun 2006 10:27:37 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 23 Jun 2006 10:27:37 +0200 From: "reddie crack" Message-ID: <20060623082737.197360@gmx.net> MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Authenticated: #520211 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 Content-Transfer-Encoding: 8bit Subject: getsockopt: SOL_SOCKET: failed to get type: Socket operation on non-socket X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jun 2006 08:27:40 -0000 Hello, i'm running FreeBSD 5.1-RELEASE as mailserver. Yesterday i had an reboot after 760 days because a power disfunction. After the reboot my messages log was full with the message: imaps[1653]: getsockopt: SOL_SOCKET: failed to get type: Socket operation on non-socket does somebody understand this error? Jun 23 10:29:15 redserv master[1534]: service imaps pid 23128 in READY state: terminated abnormally Jun 23 10:29:15 redserv master[1534]: service lmtpunix pid 23129 in READY state: terminated abnormally Jun 23 10:29:15 redserv lmtpunix[23132]: getsockopt: SOL_SOCKET: failed to get type: Socket operation on non-socket Jun 23 10:29:15 redserv imaps[23131]: getsockopt: SOL_SOCKET: failed to get type: Socket operation on non-socket Jun 23 10:29:15 redserv master[1534]: service lmtpunix pid 23132 in READY state: terminated abnormally Jun 23 10:29:15 redserv master[1534]: service imaps pid 23131 in READY state: terminated abnormally Jun 23 10:29:15 redserv lmtpunix[23134]: getsockopt: SOL_SOCKET: failed to get type: Socket operation on non-socket Don't no where to find the error to solve it? Does somebody got a clue? -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 09:09:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15CA916A49A for ; Fri, 23 Jun 2006 09:09:12 +0000 (UTC) (envelope-from peter@bgnett.no) Received: from skapet.datadok.no (skapet.datadok.no [194.54.107.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79B5F43D48 for ; Fri, 23 Jun 2006 09:09:11 +0000 (GMT) (envelope-from peter@bgnett.no) Received: from amidala.datadok.no ([194.54.103.98] helo=amidala.datadok.no.bsdly.net ident=peter) by skapet.datadok.no with esmtp (Exim 4.60) (envelope-from ) id 1Fthf3-0003XV-TT for freebsd-net@freebsd.org; Fri, 23 Jun 2006 11:09:09 +0200 To: freebsd-net@freebsd.org References: <7.0.1.0.2.20060620151013.042be3f8@lariat.org> From: peter@bgnett.no (Peter N. M. Hansteen) Date: Fri, 23 Jun 2006 11:09:08 +0200 In-Reply-To: <7.0.1.0.2.20060620151013.042be3f8@lariat.org> (Brett Glass's message of "Tue, 20 Jun 2006 15:22:46 -0600") Message-ID: <87ejxg2q8b.fsf@amidala.datadok.no> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Best way to block a long list of IPs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jun 2006 09:09:12 -0000 Brett Glass writes: >>there are efficient tables in ipfw as well, which Ruslan implemented >>some time ago -- yet another reason we should be grateful to him > > How would I build a table of arbitrary IP addresses and be able > to update it atomically (i.e. add and delete individual addresses > and not lose all filtering when there was a modification)? This sounds very much like what PF's tables was made for. You can add or remove addresses from the command line (see eg http://www.bgnett.no/~peter/pf/en/tables.html) and there are ways to add and remove individual addresses automatically as well (see eg http://www.bgnett.no/~peter/pf/en/bruteforce.html). -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ "First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales" 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 10:40:12 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3510016A47E for ; Fri, 23 Jun 2006 10:40:12 +0000 (UTC) (envelope-from outsidefactor@iinet.net.au) Received: from mail-ihug.icp-qv1-irony6.iinet.net.au (ihug-mail.icp-qv1-irony6.iinet.net.au [203.59.1.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B0C343D46 for ; Fri, 23 Jun 2006 10:40:10 +0000 (GMT) (envelope-from outsidefactor@iinet.net.au) Received: from 124-168-5-137.dyn.iinet.net.au (HELO SAURON) ([124.168.5.137]) by mail-ihug.icp-qv1-irony6.iinet.net.au with ESMTP; 23 Jun 2006 18:40:06 +0800 Message-Id: <52se08$ad99g9@iinet-mail.icp-qv1-irony6.iinet.net.au> X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,168,1149436800"; d="scan'208"; a="349480457:sNHT17873352" From: "Christopher Martin" To: "FreeBSD Net Mailing list" Date: Fri, 23 Jun 2006 20:40:09 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcaWsWXT8jjrVr/ZSJ2PUwWts5Q6tA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Subject: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 10:40:12 -0000 There is probably some good reason for this, but there is just one thing that seems very lacking from FreeBSD, and that's the ability to put in multiple routes in the table the same destination. Now, I am sure a lot of people are saying "You idiot, use OSPF/BGP/RIP if you want fail over!" But that's not what I want! In the case of just about every other OS today you can put in as many routes as you like, and it will use any routes to a destination in a round robin, assuming they have equivalent, preferable metrics. Sort of poor mans load balancing. This also prevents protocols like OSPF from entering multiple routes to destination networks even if they have the same cost. People have tried to overcome this in the past with ipfw rules: http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/093285.html The best this solution (more of a hack, really) can do is route sessions back out the same interface they came in. Is there a good reason? If there isn't one, how much work will it take to fix? I have to admit that it frustrates me enough to at least have a crack at fixing it myself, even though I am no expert 1337 coder. Please pardon my ignorance! C Martin From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 12:02:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 730BC16A49A for ; Fri, 23 Jun 2006 12:02:16 +0000 (UTC) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2F6543DB4 for ; Fri, 23 Jun 2006 12:02:15 +0000 (GMT) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (localhost.foo.is [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id BC1FCDA85D; Fri, 23 Jun 2006 12:02:11 +0000 (GMT) Received: by gremlin.foo.is (Postfix, from userid 1000) id 05528DA842; Fri, 23 Jun 2006 12:02:09 +0000 (GMT) Date: Fri, 23 Jun 2006 12:02:08 +0000 From: Baldur Gislason To: Christopher Martin Message-ID: <20060623120208.GH36671@gremlin.foo.is> References: <52se08$ad99g9@iinet-mail.icp-qv1-irony6.iinet.net.au> In-Reply-To: <52se08$ad99g9@iinet-mail.icp-qv1-irony6.iinet.net.au> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, score=-5.9 required=6.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Cc: FreeBSD Net Mailing list Subject: Re: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 12:02:16 -0000 Well, round robin is really not what you want with IP packets. And how are you going to detect that a route is good without a routing protocol? Baldur On Fri, Jun 23, 2006 at 08:40:09PM +1000, Christopher Martin wrote: > There is probably some good reason for this, but there is just one thing > that seems very lacking from FreeBSD, and that's the ability to put in > multiple routes in the table the same destination. > > Now, I am sure a lot of people are saying "You idiot, use OSPF/BGP/RIP if > you want fail over!" But that's not what I want! In the case of just about > every other OS today you can put in as many routes as you like, and it will > use any routes to a destination in a round robin, assuming they have > equivalent, preferable metrics. Sort of poor mans load balancing. This also > prevents protocols like OSPF from entering multiple routes to destination > networks even if they have the same cost. > > People have tried to overcome this in the past with ipfw rules: > http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/093285.html > > The best this solution (more of a hack, really) can do is route sessions > back out the same interface they came in. > > Is there a good reason? If there isn't one, how much work will it take to > fix? I have to admit that it frustrates me enough to at least have a crack > at fixing it myself, even though I am no expert 1337 coder. > > Please pardon my ignorance! > > C Martin > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 12:19:05 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CC1616A492 for ; Fri, 23 Jun 2006 12:19:05 +0000 (UTC) (envelope-from outsidefactor@iinet.net.au) Received: from mail-ihug.icp-qv1-irony1.iinet.net.au (ihug-mail.icp-qv1-irony1.iinet.net.au [203.59.1.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64EFF43D46 for ; Fri, 23 Jun 2006 12:19:03 +0000 (GMT) (envelope-from outsidefactor@iinet.net.au) Received: from 124-168-19-56.dyn.iinet.net.au (HELO SAURON) ([124.168.19.56]) by mail-ihug.icp-qv1-irony1.iinet.net.au with ESMTP; 23 Jun 2006 20:19:02 +0800 Message-Id: <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,168,1149436800"; d="scan'208"; a="536806125:sNHT66680928" From: "Christopher Martin" To: "'Baldur Gislason'" Date: Fri, 23 Jun 2006 22:19:06 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20060623120208.GH36671@gremlin.foo.is> Thread-Index: AcaWvOzyHFNF9fnPSvWON/ACgL9xogAAKZiw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Cc: 'FreeBSD Net Mailing list' Subject: RE: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 12:19:05 -0000 > -----Original Message----- > From: Baldur Gislason [mailto:baldur@foo.is] > Sent: Friday, 23 June 2006 10:02 PM > To: Christopher Martin > Cc: FreeBSD Net Mailing list > Subject: Re: Multiple routes to the same destination > > Well, round robin is really not what you want with IP packets. > And how are you going to detect that a route is good without a routing > protocol? > Actually, round robin is exactly what I want. And I am not saying I don't use a routing protocol, in fact I do, but I want packets to be able to use two or more diverse paths of equivalent cost. It would seem that you are assuming that I want to load balance two internet connections which are NATed, in which case round robin might have issues with lost TCP sessions and weird reactions from servers as the apparent source address changes from packet to packet, but in a routed internal network the source address will not be changed by the router, thus negating that issue. It did seem at some stage someone was going to include it in OpenBSD: http://undeadly.org/cgi?action=article&sid=20040425183024&mode=expanded To quote: "...OSPF also supports multipath equal cost routing". It's more of a case where we would like to use BSD as a router/packet filtering firewall for sites with multiple WAN links between each site, of equal size, and not have one site idle until the other fails over. Round robin is better than what we have: nothing. From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 12:25:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C571016A49A for ; Fri, 23 Jun 2006 12:25:27 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id E851943D55 for ; Fri, 23 Jun 2006 12:25:25 +0000 (GMT) (envelope-from vadimnuclight@tpu.ru) Received: by relay1.tpu.ru (Postfix, from userid 501) id 4970810DA23; Fri, 23 Jun 2006 19:25:24 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id 2FCC410DA12; Fri, 23 Jun 2006 19:25:24 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 19:25:23 +0700 Received: from nuclight.avtf.net ([82.117.64.107]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 19:25:23 +0700 To: "Christopher Martin" , "'Baldur Gislason'" References: <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> Message-ID: Date: Fri, 23 Jun 2006 19:24:40 +0700 From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 23 Jun 2006 12:25:23.0398 (UTC) FILETIME=[1998F660:01C696C0] Cc: 'FreeBSD Net Mailing list' Subject: Re: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 12:25:27 -0000 23.06.06 @ 19:19 Christopher Martin wrote: >> Well, round robin is really not what you want with IP packets. >> And how are you going to detect that a route is good without a routing >> protocol? >> > Actually, round robin is exactly what I want. And I am not saying I don't > use a routing protocol, in fact I do, but I want packets to be able to > use two or more diverse paths of equivalent cost. You can try to use ng_one2many(4) netgraph node for simple round-robin, if this all what you want. -- WBR, Vadim Goncharov From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 12:40:39 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7503816A492 for ; Fri, 23 Jun 2006 12:40:39 +0000 (UTC) (envelope-from trashy_bumper@yahoo.com) Received: from web36315.mail.mud.yahoo.com (web36315.mail.mud.yahoo.com [209.191.84.245]) by mx1.FreeBSD.org (Postfix) with SMTP id 00F5743D53 for ; Fri, 23 Jun 2006 12:40:38 +0000 (GMT) (envelope-from trashy_bumper@yahoo.com) Received: (qmail 12176 invoked by uid 60001); 23 Jun 2006 12:40:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NQdGww7QfG5KjCyUjEe4/MFzOGquYFo67XhnZmr4H/Kpc1Z2Y79kqdUHf9e5652sBMGolZcT3LQ+jW7EofFdfNKL3hEnlYRljaxfnc6yjjOucx25pYc6GGlL/pQJR4juwhRYMektYQP/zrSBVANC+unpeOdRUk7lxUhF+fFG+Hc= ; Message-ID: <20060623124038.12174.qmail@web36315.mail.mud.yahoo.com> Received: from [213.227.206.11] by web36315.mail.mud.yahoo.com via HTTP; Fri, 23 Jun 2006 05:40:38 PDT Date: Fri, 23 Jun 2006 05:40:38 -0700 (PDT) From: Nash Nipples To: Christopher Martin In-Reply-To: <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: RE: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 12:40:39 -0000 1. how did you uninstall routed? 2. why not alter routes in a script, you are not going to send packets belonging to the same session in multiple routes would ya? Christopher Martin wrote: > -----Original Message----- > From: Baldur Gislason [mailto:baldur@foo.is] > Sent: Friday, 23 June 2006 10:02 PM > To: Christopher Martin > Cc: FreeBSD Net Mailing list > Subject: Re: Multiple routes to the same destination > > Well, round robin is really not what you want with IP packets. > And how are you going to detect that a route is good without a routing > protocol? > Actually, round robin is exactly what I want. And I am not saying I don't use a routing protocol, in fact I do, but I want packets to be able to use two or more diverse paths of equivalent cost. It would seem that you are assuming that I want to load balance two internet connections which are NATed, in which case round robin might have issues with lost TCP sessions and weird reactions from servers as the apparent source address changes from packet to packet, but in a routed internal network the source address will not be changed by the router, thus negating that issue. It did seem at some stage someone was going to include it in OpenBSD: http://undeadly.org/cgi?action=article&sid=20040425183024&mode=expanded To quote: "...OSPF also supports multipath equal cost routing". It's more of a case where we would like to use BSD as a router/packet filtering firewall for sites with multiple WAN links between each site, of equal size, and not have one site idle until the other fails over. Round robin is better than what we have: nothing. _______________________________________________ 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" --------------------------------- How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates. From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 13:37:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FB4E16A49E for ; Fri, 23 Jun 2006 13:37:27 +0000 (UTC) (envelope-from outsidefactor@iinet.net.au) Received: from mail-ihug.icp-qv1-irony1.iinet.net.au (ihug-mail.icp-qv1-irony1.iinet.net.au [203.59.1.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D2A543D5D for ; Fri, 23 Jun 2006 13:37:19 +0000 (GMT) (envelope-from outsidefactor@iinet.net.au) Received: from 124-168-19-56.dyn.iinet.net.au (HELO SAURON) ([124.168.19.56]) by mail-ihug.icp-qv1-irony1.iinet.net.au with ESMTP; 23 Jun 2006 21:37:16 +0800 Message-Id: <50v528$g00bv4@iinet-mail.icp-qv1-irony1.iinet.net.au> X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,169,1149436800"; d="scan'208"; a="536883172:sNHT97374522" From: "Christopher Martin" To: "'Nash Nipples'" Date: Fri, 23 Jun 2006 23:37:18 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20060623124038.12174.qmail@web36315.mail.mud.yahoo.com> Thread-Index: AcaWwjyHOzOHsZYFT7CB3h2jYBbzqwABvMxw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Cc: freebsd-net@freebsd.org Subject: RE: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 13:37:27 -0000 Sorry for the mangled reply, html mail is irritating. ________________________________________ From: Nash Nipples [mailto:trashy_bumper@yahoo.com] Sent: Friday, 23 June 2006 10:41 PM To: Christopher Martin Cc: freebsd-net@freebsd.org Subject: RE: Multiple routes to the same destination 1. how did you uninstall routed? 2. why not alter routes in a script, you are not going to send packets belonging to the same session in multiple routes would ya? 1) I don't, didn't and never was using, or even talking about, routed 2) The point is to load balance, not fail over. As said in my first reply, I have fail over covered. My question in return would be why use a custom script setup (using ping or such to detect the link state) for fail over when there are so many better ways of doing it? And, yes, I do want packets from one session going over multiple links. That's what load balancing is... Sure it's not going to account for packet size, it's not going to be perfectly efficient, but as said before it's better than nothing! From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 13:50:13 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 433F016A47B for ; Fri, 23 Jun 2006 13:50:13 +0000 (UTC) (envelope-from outsidefactor@iinet.net.au) Received: from mail-ihug.icp-qv1-irony6.iinet.net.au (ihug-mail.icp-qv1-irony6.iinet.net.au [203.59.1.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F8D343D45 for ; Fri, 23 Jun 2006 13:50:11 +0000 (GMT) (envelope-from outsidefactor@iinet.net.au) Received: from 124-168-19-56.dyn.iinet.net.au (HELO SAURON) ([124.168.19.56]) by mail-ihug.icp-qv1-irony6.iinet.net.au with ESMTP; 23 Jun 2006 21:50:01 +0800 Message-Id: <52se08$adeqot@iinet-mail.icp-qv1-irony6.iinet.net.au> X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,169,1149436800"; d="scan'208"; a="349661981:sNHT29535724" From: "Christopher Martin" To: "'Vadim Goncharov'" , "'Baldur Gislason'" Date: Fri, 23 Jun 2006 23:50:05 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcaWwFbAgeTlo7UxSIyg770yeDP4NQACd7xQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Cc: 'FreeBSD Net Mailing list' Subject: RE: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 13:50:13 -0000 > > Actually, round robin is exactly what I want. And I am not saying I > don't > > use a routing protocol, in fact I do, but I want packets to be able to > > use two or more diverse paths of equivalent cost. > > You can try to use ng_one2many(4) netgraph node for simple round-robin, if > this all what you want. I guess I could, but I would resent the need, if for no other reason than it isn't required anywhere but BSD. Even Windows does this. And I'd have to do extra work to get quagga/openospf to work with netgraph. And I'd have to setup each node manually for each possible destination. And it couldn't auto learn new multipaths automatically through OSPF, I'd have to re-visit every router each time I brought new paths online. And, from what I read I need to have a card for every path (read it here: http://www.gsp.com/cgi-bin/man.cgi?section=4&topic=ng_one2many). Seems like a lot of work for something that is just there everywhere else. My original points were: 1) Why isn't it there and why not, and is there good reason it isn't 2) If it's just a case of no-one doing it, can anyone give a quick appraisal in their opinion of how much effort it would take to include? From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 13:51:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3C8A16A49E for ; Fri, 23 Jun 2006 13:51:46 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09ACD43D5A for ; Fri, 23 Jun 2006 13:51:45 +0000 (GMT) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 27245 invoked by uid 1001); 23 Jun 2006 13:51:44 -0000 Date: Fri, 23 Jun 2006 15:51:21 +0200 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20060623135144.GD12611@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org References: <20060623120208.GH36671@gremlin.foo.is> <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> User-Agent: Mutt/1.5.11 Subject: Re: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 13:51:46 -0000 On Fri, Jun 23, 2006 at 10:19:06PM +1000, Christopher Martin wrote: > > > > -----Original Message----- > > From: Baldur Gislason [mailto:baldur@foo.is] > > Sent: Friday, 23 June 2006 10:02 PM > > To: Christopher Martin > > Cc: FreeBSD Net Mailing list > > Subject: Re: Multiple routes to the same destination > > > > Well, round robin is really not what you want with IP packets. > > And how are you going to detect that a route is good without a routing > > protocol? > > > > Actually, round robin is exactly what I want. And I am not saying I don't > use a routing protocol, in fact I do, but I want packets to be able to use > two or more diverse paths of equivalent cost. I doubt that. Doing a per packet round robin over different pathes will kill your tcp performance because of out of order packets. > > It would seem that you are assuming that I want to load balance two internet > connections which are NATed, in which case round robin might have issues > with lost TCP sessions and weird reactions from servers as the apparent > source address changes from packet to packet, but in a routed internal > network the source address will not be changed by the router, thus negating > that issue. > > It did seem at some stage someone was going to include it in OpenBSD: > http://undeadly.org/cgi?action=article&sid=20040425183024&mode=expanded > That's just part of the it. The rest was added in the last couple of days because multipath routing and accepting more than one route per destination is a scary thing. Additionally dead nexthop detection is not available. > To quote: > "...OSPF also supports multipath equal cost routing". > Yes it does but often you try to avoid that. > It's more of a case where we would like to use BSD as a router/packet > filtering firewall for sites with multiple WAN links between each site, of > equal size, and not have one site idle until the other fails over. Round > robin is better than what we have: nothing. OpenBSD is on the way to support this but it is still a long journey till all issues are resolved. Btw. OpenBSD uses a hash-threshold mechanism to select paths based on source/destination IP address pairs (round robin will never be supported). -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 14:04:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56D2416A494 for ; Fri, 23 Jun 2006 14:04:25 +0000 (UTC) (envelope-from outsidefactor@iinet.net.au) Received: from mail-ihug.icp-qv1-irony5.iinet.net.au (ihug-mail.icp-qv1-irony5.iinet.net.au [203.59.1.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CE0143D53 for ; Fri, 23 Jun 2006 14:04:23 +0000 (GMT) (envelope-from outsidefactor@iinet.net.au) Received: from 124-168-19-56.dyn.iinet.net.au (HELO SAURON) ([124.168.19.56]) by mail-ihug.icp-qv1-irony5.iinet.net.au with ESMTP; 23 Jun 2006 22:04:21 +0800 Message-Id: <53binj$o6s2np@iinet-mail.icp-qv1-irony5.iinet.net.au> X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,169,1149436800"; d="scan'208"; a="812518137:sNHT18389364" From: "Christopher Martin" To: "'Claudio Jeker'" , Date: Sat, 24 Jun 2006 00:04:25 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20060623135144.GD12611@diehard.n-r-g.com> Thread-Index: AcaWzGsKWBmWhgS7Tle4xlcR/ce61QAAGlRg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Cc: Subject: RE: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 14:04:25 -0000 > I doubt that. Doing a per packet round robin over different pathes will > kill your tcp performance because of out of order packets. Noted. That's a very good reason. Maybe if there was a may to round robin on a session basis to mitigate this. Not really going to be an easy fix, however, so your point is very valid. > > > > It would seem that you are assuming that I want to load balance two > internet > > connections which are NATed, in which case round robin might have issues > > with lost TCP sessions and weird reactions from servers as the apparent > > source address changes from packet to packet, but in a routed internal > > network the source address will not be changed by the router, thus > negating > > that issue. > > > > It did seem at some stage someone was going to include it in OpenBSD: > > http://undeadly.org/cgi?action=article&sid=20040425183024&mode=expanded > > > > That's just part of the it. The rest was added in the last couple of days > because multipath routing and accepting more than one route per > destination is a scary thing. Additionally dead nexthop detection is not > available. I would have thought OSPF would have provided your dead hop issues, however it does not resolve your point above, so we still seem out of luck. > > To quote: > > "...OSPF also supports multipath equal cost routing". > > > > Yes it does but often you try to avoid that. Because of your point above? Besides that, can you provide a couple of examples of why we would try and avoid it? > > It's more of a case where we would like to use BSD as a router/packet > > filtering firewall for sites with multiple WAN links between each site, > of > > equal size, and not have one site idle until the other fails over. Round > > robin is better than what we have: nothing. > > OpenBSD is on the way to support this but it is still a long journey till > all issues are resolved. Btw. OpenBSD uses a hash-threshold mechanism to > select paths based on source/destination IP address pairs (round robin > will never be supported). Again, another good point. And it also answers the other query as to the level of work involved in making it work. Thanks Claudio! From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 14:28:09 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0389316A4A7 for ; Fri, 23 Jun 2006 14:28:09 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2E5043D72 for ; Fri, 23 Jun 2006 14:28:04 +0000 (GMT) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 4231 invoked by uid 1001); 23 Jun 2006 14:28:03 -0000 Date: Fri, 23 Jun 2006 16:27:40 +0159 From: 'Claudio Jeker' To: freebsd-net@freebsd.org Message-ID: <20060623142803.GG12611@diehard.n-r-g.com> Mail-Followup-To: 'Claudio Jeker' , freebsd-net@freebsd.org References: <20060623135144.GD12611@diehard.n-r-g.com> <53binj$o6s2np@iinet-mail.icp-qv1-irony5.iinet.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53binj$o6s2np@iinet-mail.icp-qv1-irony5.iinet.net.au> User-Agent: Mutt/1.5.11 Subject: Re: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 14:28:09 -0000 On Sat, Jun 24, 2006 at 12:04:25AM +1000, Christopher Martin wrote: > > > I doubt that. Doing a per packet round robin over different pathes will > > kill your tcp performance because of out of order packets. > > Noted. That's a very good reason. Maybe if there was a may to round robin on > a session basis to mitigate this. Not really going to be an easy fix, > however, so your point is very valid. > Most implementation do a per source/dst IP address hashing which should result in a similar distribution. > > > > > > It would seem that you are assuming that I want to load balance two > > internet > > > connections which are NATed, in which case round robin might have issues > > > with lost TCP sessions and weird reactions from servers as the apparent > > > source address changes from packet to packet, but in a routed internal > > > network the source address will not be changed by the router, thus > > negating > > > that issue. > > > > > > It did seem at some stage someone was going to include it in OpenBSD: > > > http://undeadly.org/cgi?action=article&sid=20040425183024&mode=expanded > > > > > > > That's just part of the it. The rest was added in the last couple of days > > because multipath routing and accepting more than one route per > > destination is a scary thing. Additionally dead nexthop detection is not > > available. > > I would have thought OSPF would have provided your dead hop issues, however > it does not resolve your point above, so we still seem out of luck. > OpenOSPFD will learn to cope with multipath routes in the next few weeks but it will only work on OpenBSD. > > > To quote: > > > "...OSPF also supports multipath equal cost routing". > > > > > > > Yes it does but often you try to avoid that. > > Because of your point above? Besides that, can you provide a couple of > examples of why we would try and avoid it? > Multipath setups are harder to debug as packets may flow differently. Often it is easier to use a layer 2 trunk to aggregate links. It depends on your network layout, etc. > > > It's more of a case where we would like to use BSD as a router/packet > > > filtering firewall for sites with multiple WAN links between each site, > > of > > > equal size, and not have one site idle until the other fails over. Round > > > robin is better than what we have: nothing. > > > > OpenBSD is on the way to support this but it is still a long journey till > > all issues are resolved. Btw. OpenBSD uses a hash-threshold mechanism to > > select paths based on source/destination IP address pairs (round robin > > will never be supported). > > Again, another good point. And it also answers the other query as to the > level of work involved in making it work. > I hope that we can get more routing stuff done in the next few weeks but the way routing is implemented in BSD makes it harder then necessary. I bet andre@ will start to port features to FreeBSD as soon as the stabilised in OpenBSD. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 14:42:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0980F16A492 for ; Fri, 23 Jun 2006 14:42:23 +0000 (UTC) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FA2043D45 for ; Fri, 23 Jun 2006 14:42:22 +0000 (GMT) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (localhost.foo.is [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id C890FDA85D; Fri, 23 Jun 2006 14:42:21 +0000 (GMT) Received: by gremlin.foo.is (Postfix, from userid 1000) id 2AA40DA849; Fri, 23 Jun 2006 14:42:18 +0000 (GMT) Date: Fri, 23 Jun 2006 14:42:18 +0000 From: Baldur Gislason To: Christopher Martin Message-ID: <20060623144218.GI36671@gremlin.foo.is> References: <20060623120208.GH36671@gremlin.foo.is> <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> In-Reply-To: <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, score=-5.9 required=6.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Cc: 'FreeBSD Net Mailing list' Subject: Re: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 14:42:23 -0000 Problem with packet based round robin is you can mess the order of packets. Thats why there are protocols like LACP and PAgP for ethernet aggregation. Baldur On Fri, Jun 23, 2006 at 10:19:06PM +1000, Christopher Martin wrote: > > > > -----Original Message----- > > From: Baldur Gislason [mailto:baldur@foo.is] > > Sent: Friday, 23 June 2006 10:02 PM > > To: Christopher Martin > > Cc: FreeBSD Net Mailing list > > Subject: Re: Multiple routes to the same destination > > > > Well, round robin is really not what you want with IP packets. > > And how are you going to detect that a route is good without a routing > > protocol? > > > > Actually, round robin is exactly what I want. And I am not saying I don't > use a routing protocol, in fact I do, but I want packets to be able to use > two or more diverse paths of equivalent cost. > > It would seem that you are assuming that I want to load balance two internet > connections which are NATed, in which case round robin might have issues > with lost TCP sessions and weird reactions from servers as the apparent > source address changes from packet to packet, but in a routed internal > network the source address will not be changed by the router, thus negating > that issue. > > It did seem at some stage someone was going to include it in OpenBSD: > http://undeadly.org/cgi?action=article&sid=20040425183024&mode=expanded > > To quote: > "...OSPF also supports multipath equal cost routing". > > It's more of a case where we would like to use BSD as a router/packet > filtering firewall for sites with multiple WAN links between each site, of > equal size, and not have one site idle until the other fails over. Round > robin is better than what we have: nothing. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 14:53:26 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F44F16A47C for ; Fri, 23 Jun 2006 14:53:26 +0000 (UTC) (envelope-from outsidefactor@iinet.net.au) Received: from mail-ihug.icp-qv1-irony3.iinet.net.au (ihug-mail.icp-qv1-irony3.iinet.net.au [203.59.1.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8873343D45 for ; Fri, 23 Jun 2006 14:53:19 +0000 (GMT) (envelope-from outsidefactor@iinet.net.au) Received: from 124-168-19-56.dyn.iinet.net.au (HELO SAURON) ([124.168.19.56]) by mail-ihug.icp-qv1-irony3.iinet.net.au with ESMTP; 23 Jun 2006 22:53:18 +0800 Message-Id: <51n3a6$otinia@iinet-mail.icp-qv1-irony3.iinet.net.au> X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,169,1149436800"; d="scan'208"; a="836329034:sNHT27533008" From: "Christopher Martin" To: "'Claudio Jeker'" Date: Sat, 24 Jun 2006 00:53:21 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20060623142803.GG12611@diehard.n-r-g.com> Thread-Index: AcaW0UspELCuJVmnRBi9I7SF2mHLzwAAMGQg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Cc: freebsd-net@freebsd.org Subject: RE: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 14:53:26 -0000 > -----Original Message----- > On Behalf Of 'Claudio Jeker' > Sent: Saturday, 24 June 2006 12:29 AM > > Most implementation do a per source/dst IP address hashing which should > result in a similar distribution. > > OpenOSPFD will learn to cope with multipath routes in the next few weeks > but it will only work on OpenBSD. That's good news. Maybe I should take another look at OpenBSD, especially since the SMP support's a few years old now and pretty stable. > > Multipath setups are harder to debug as packets may flow differently. > Often it is easier to use a layer 2 trunk to aggregate links. It depends > on your network layout, etc. One place I am implementing OSPF in community wireless networks. We have a few sections of network that are very stable and have diverse paths. We currently have a lot of success with failover, but at times it seems a waste to have idle paths when others running in the same direction. Not that I wasn't expecting the difference in arrival time of packets not to effect performance in that scenario, but not to the extent you suggest. I guess we could stick with OpenWRT routers, but it would have been so nice to move in more BSD! > I hope that we can get more routing stuff done in the next few weeks but > the way routing is implemented in BSD makes it harder then necessary. > I bet andre@ will start to port features to FreeBSD as soon as the > stabilised in OpenBSD. I guess I will go and try it out on OpenBSD. If nothing else it's one more install being tested and making a more compelling argument to merge it into FreeBSD. I look forward to seeing what is on its way. From owner-freebsd-net@FreeBSD.ORG Fri Jun 23 19:24:21 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98B5916A4A6 for ; Fri, 23 Jun 2006 19:24:21 +0000 (UTC) (envelope-from ozkan@mersin.edu.tr) Received: from mail.mersin.edu.tr (mail.mersin.edu.tr [193.255.128.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0148043D49 for ; Fri, 23 Jun 2006 19:24:20 +0000 (GMT) (envelope-from ozkan@mersin.edu.tr) Received: from localhost (localhost.mersin.edu.tr [127.0.0.1]) by mail.mersin.edu.tr (Postfix) with ESMTP id A3B514526E; Fri, 23 Jun 2006 22:26:08 +0300 (EEST) X-Virus-Scanned: by amavisd-new at mersin.edu.tr Received: from mail.mersin.edu.tr ([127.0.0.1]) by localhost (mail.mersin.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4Sm3r6rYKbp; Fri, 23 Jun 2006 22:26:06 +0300 (EEST) Received: from [81.213.166.209] (unknown [81.213.166.209]) by mail.mersin.edu.tr (Postfix) with ESMTP id E880045260; Fri, 23 Jun 2006 22:26:05 +0300 (EEST) Message-ID: <449C3FDA.6010802@mersin.edu.tr> Date: Fri, 23 Jun 2006 22:24:10 +0300 From: =?ISO-8859-9?Q?=D6zkan_KIRIK?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050927) X-Accept-Language: tr-TR, tr, en-US, en MIME-Version: 1.0 To: Christopher Martin , freebsd-net@freebsd.org References: <52se08$ad99g9@iinet-mail.icp-qv1-irony6.iinet.net.au> In-Reply-To: <52se08$ad99g9@iinet-mail.icp-qv1-irony6.iinet.net.au> Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 19:24:21 -0000 I think policy routing can solve this problem, you can use ipfw's fwd action to route packets. this method doesn't work as round robbin, but it can solve your problem. No routing protocol need. expamle config: first router = 10.0.0.1 second router = 10.0.0.2 ipfw add check-state ipfw add prob 0.5 fwd 10.0.0.1 all from any to not 10.0.0.0/24 keep-state ipfw add fwd 10.0.0.2 all from any to not 10.0.0.0/24 keep-state ... With this solution, if a connection established over first router, the packets belongs to same connection uses first router as gateway. Özkan KIRIK Christopher Martin yazmış: >There is probably some good reason for this, but there is just one thing >that seems very lacking from FreeBSD, and that's the ability to put in >multiple routes in the table the same destination. > >Now, I am sure a lot of people are saying "You idiot, use OSPF/BGP/RIP if >you want fail over!" But that's not what I want! In the case of just about >every other OS today you can put in as many routes as you like, and it will >use any routes to a destination in a round robin, assuming they have >equivalent, preferable metrics. Sort of poor mans load balancing. This also >prevents protocols like OSPF from entering multiple routes to destination >networks even if they have the same cost. > >People have tried to overcome this in the past with ipfw rules: >http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/093285.html > >The best this solution (more of a hack, really) can do is route sessions >back out the same interface they came in. > >Is there a good reason? If there isn't one, how much work will it take to >fix? I have to admit that it frustrates me enough to at least have a crack >at fixing it myself, even though I am no expert 1337 coder. > >Please pardon my ignorance! > >C Martin >_______________________________________________ >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 Jun 24 17:35:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A22416A494 for ; Sat, 24 Jun 2006 17:35:58 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CEB243D60 for ; Sat, 24 Jun 2006 17:35:57 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 573EA16EE8; Sat, 24 Jun 2006 13:35:56 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 261854AC2C; Sat, 24 Jun 2006 13:35:58 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17565.30718.106118.318863@canoe.dclg.ca> Date: Sat, 24 Jun 2006 13:35:58 -0400 To: "Christopher Martin" In-Reply-To: <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> References: <20060623120208.GH36671@gremlin.foo.is> <50v528$fvu0nd@iinet-mail.icp-qv1-irony1.iinet.net.au> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Cc: 'Baldur Gislason' , 'FreeBSD Net Mailing list' Subject: RE: Multiple routes to the same destination X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 17:35:58 -0000 >>>>> "Christopher" == Christopher Martin writes: Christopher> Actually, round robin is exactly what I want. And I am Christopher> not saying I don't use a routing protocol, in fact I do, Christopher> but I want packets to be able to use two or more diverse Christopher> paths of equivalent cost. No. round-robin will deliver packets out-of-order. TCP will behave very badly with this (at the very least, smart selective-ack hosts will transmit a lot of selective-ack packets --- but dumb non-selective-ack hosts will start asking for a lot of retransmission). Other protocols tolerance for OOO packets varies. Generally devices that use multiple routes (like a cisco) rather than things that simply accept multiple routes (like windoze) have some set of rules that generally deliver all traffic for a set of hosts down one of the available routes. "Etherchannel" (a simple layer two bonding that is available in FreeBSD as ng_fec) does this by XORing the last couple of bits of the MAC addresses (source and dest) and uses this to choose one of two or one of four links to forward the packet. I suspect equal-cost-multipath on Ciscos does the same with IP addresses. Linux does all this with it's flow table --- that is each 5-tuple of source ip,port dest ip,port (and protocol) is stored as a "flow" in a big hash table. The table stores things like the next-hop interface and destination. Now... this is an unscalble solution --- it's reasonably trivial to knock over a linux router with a simple DOS ... details left to the interested reader. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================