From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 00:25:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B05816A4CE for ; Sun, 28 Nov 2004 00:25:24 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C374F43D62 for ; Sun, 28 Nov 2004 00:25:23 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id iAS0T2ic020871 for freebsd-net@freebsd.org.checked; Sun, 28 Nov 2004 03:29:02 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id iAS0Smex020861; Sun, 28 Nov 2004 03:28:48 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <41A91816.30807@cronyx.ru> Date: Sun, 28 Nov 2004 03:13:10 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-hackers@FreeBSD.org, FreeBSD Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: MPSAFE sppp(+fr support) cp cx ctau X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2004 00:25:24 -0000 Hi, I am glad to announce stable version of patches for sppp, cp, ctau and cx drivers with support of mpsafe. SPPP: Sppp will work in mpsafe mode only for adapters that do not have IFF_NEEDSGIANT flag. Also this patch contains if_spppfr.c with fr support for sppp (4). CP/CX/CTAU: Adapters will work in mpsafe mode only if both debug.mpsafenet and debug.{cp|cx|ctau}.mpsafenet set to 1. Patches (relative current) can be downloaded from: http://people.freebsd.org/~rik/rik_netperf_20041128-1.pch Please test them and let me know if you have any problems. Patches were tested on Tau-PCI - Cisco 2500 at speed 4M on Dual CPU system with ping-f and uptime ~one week. rik From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 15:58:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5BBF16A4CE for ; Sun, 28 Nov 2004 15:58:44 +0000 (GMT) Received: from poczta.o2.pl (mx.go2.pl [193.17.41.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0202343D58 for ; Sun, 28 Nov 2004 15:58:40 +0000 (GMT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (aaf223.warszawa.sdi.tpnet.pl [217.97.85.223]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by poczta.o2.pl (Postfix) with ESMTP id 232D313779A for ; Sun, 28 Nov 2004 16:58:36 +0100 (CET) Message-ID: <001601c4d563$4de0e740$df5561d9@ALFA> From: "Heinz Knocke" To: Date: Sun, 28 Nov 2004 16:59:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Why using timestamp based RTTM simplifies TCP sender? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2004 15:58:44 -0000 Hi everybody! While reading quite old but important RFC 1323 in chapter on RTT = measurement based on timestamps I found an opinion that:=20 " A solution to these problems (rough RTT estimation) which actually = simplifies the sender substantially, is as follows: using TCP options, = the sender places a timestamp in each data segment, and the receiver = reflects these timestamps back in ACK segments ..." and "Furthermore, the option is probably useful for all TCP's, since it = simplifies the sender" I really coldn't find many arguments, why adding another option will = simplify sender's code. I think that no matter what it does, it cannot = simplify because the stack needs to be backward compatible, so all = previous solutions must stay. Maybe Van Jacobson thought about the = situation when timestamp option becomes compulsory, making removal of = some old bytes possible?=20 Could any of you guys who are deep into TCP stack code could give me = some hints?=20 Thanks in advance! H.K From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 17:04:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A1A616A4CE for ; Sun, 28 Nov 2004 17:04:40 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B3BD43D70 for ; Sun, 28 Nov 2004 17:04:39 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iASH2c10000415; Sun, 28 Nov 2004 12:02:38 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iASH2cfV000412; Sun, 28 Nov 2004 17:02:38 GMT (envelope-from robert@fledge.watson.org) Date: Sun, 28 Nov 2004 17:02:37 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Kevin Day In-Reply-To: <35FC873E-40BF-11D9-8850-000A95A8A1F2@dragondata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2004 17:04:40 -0000 On Sat, 27 Nov 2004, Kevin Day wrote: > I recently upgraded to 5.3 on a system, and manually upgraded > src/sys/dev/em/* to the latest RELENG_5 versions. (1.44.2.4 of if_em.c) I'm able to reproduce problems using the below configuration is 6.x also, and am investigating. Thanks for the report, hope to get back to you shortly with something concrete. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > While the VLAN side of things works better than the stock 5.3 version, > there still is this problem: > > > ifconfig vlan1 create > ifconfig vlan1 vlan 1 vlandev em1 link0 > ifconfig vlan2 create > ifconfig vlan2 vlan 2 vlandev em1 link0 > ifconfig vlan3 create > ifconfig vlan3 vlan 3 vlandev em1 link0 > > ifconfig vlan1 inet 192.aaa.bbb.129 netmask 255.255.255.0 > ifconfig vlan2 inet 64.ccc.ddd.61 netmask 255.255.255.192 > ifconfig vlan3 inet 64.eee.fff.61 netmask 255.255.255.192 > > ifconfig em1 up > ifconfig em1 promisc > > If I do this, vlan1 and vlan3 work fine. Vlan2 can receive packets, but > anything sent out vlan2 doesn't seem to be heard by any foreign hosts. > Setting "ifconfig em1 -promisc" makes all vlans work properly. > > This is better than the stock 5.3 version of em(4) where none of the > vlans worked, but something still isn't right. > > Is this a known problem still or am I just doing something wrong? > > > > From owner-freebsd-net@FreeBSD.ORG Sun Nov 28 19:49:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3255B16A4CE for ; Sun, 28 Nov 2004 19:49:17 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 8727F43D3F for ; Sun, 28 Nov 2004 19:49:16 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 60401 invoked from network); 28 Nov 2004 19:49:15 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 28 Nov 2004 19:49:15 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 28 Nov 2004 13:49:14 -0600 (CST) From: Mike Silbersack To: Heinz Knocke In-Reply-To: <001601c4d563$4de0e740$df5561d9@ALFA> Message-ID: <20041128134535.K50193@odysseus.silby.com> References: <001601c4d563$4de0e740$df5561d9@ALFA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: Why using timestamp based RTTM simplifies TCP sender? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2004 19:49:17 -0000 On Sun, 28 Nov 2004, Heinz Knocke wrote: > Hi everybody! > > While reading quite old but important RFC 1323 in chapter on RTT > measurement based on timestamps I found an opinion that: > > " A solution to these problems (rough RTT estimation) which actually > simplifies the sender substantially, is as follows: using TCP options, > the sender places a timestamp in each data segment, and the receiver > reflects these timestamps back in ACK segments ..." > > I really coldn't find many arguments, why adding another option will > simplify sender's code. I think that no matter what it does, it cannot > simplify because the stack needs to be backward compatible, so all > previous solutions must stay. Maybe Van Jacobson thought about the > situation when timestamp option becomes compulsory, making removal of > some old bytes possible? I think what Van Jacobson meant is that without timestamps, you run into problems when you have packets dropped. If you've retransmitted a packet, then receive an ACK for that packet, you will not know whether that's a highly delayed ACK for the original transmission, or the ACK for the retransmission. Therefore, timing is difficult. Comparatively, with timestamps, you never have to worry about such timing problems. You are correct that the non-TS code must remain in the TCP stack. However, I don't think complexity of the old code is what he was referring to. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 00:26:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1316216A4CE for ; Mon, 29 Nov 2004 00:26:28 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id A995643D31 for ; Mon, 29 Nov 2004 00:26:27 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.250] (pool-68-161-115-118.ny325.east.verizon.net [68.161.115.118]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id iAT0QITM066364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Nov 2004 19:26:19 -0500 (EST) Message-ID: <41AA6CA9.6020008@mac.com> Date: Sun, 28 Nov 2004 19:26:17 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Seguin References: <007f01c4d3b2$12597af0$cad435a1@mojlaptop> In-Reply-To: <007f01c4d3b2$12597af0$cad435a1@mojlaptop> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.6 required=5.5 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on pi.codefab.com cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 5.3 Networking performance problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 00:26:28 -0000 Andrew Seguin wrote: > We have about 100 computers active, generating a stream of approximately > 80-90K packets per minute for a load I estimate* to be a little under > 10Mbps. Overall the firewall will need to filter for a /24 subnet. OK. > *Configuration: > Hardware: > The firewall is a Celeron 900Mhz with 128MB ram (more on the way) with one > rl and one sis based network cards. My first suggestion would be to bin the rl NIC and replace it with an fxp or dc-based NIC. Realtek NICs are infamous for working poorly or not working reliably at all under load. [ ... ] > I then tested with the whole school going through the firewall: very bad. > packets were being droped and ping times were around 600ms. Internet was > pretty much unuseable. This report sounds consistent, although you could also have a bad cable or switch port, too. It would be useful to you to look into the output of "netstat -i" and "netstat -s", and any statistics which might be available on your switches (if they have management & per-port stats). -- -Chuck From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 07:26:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 151E116A4CE for ; Mon, 29 Nov 2004 07:26:03 +0000 (GMT) Received: from web53201.mail.yahoo.com (web53201.mail.yahoo.com [206.190.39.217]) by mx1.FreeBSD.org (Postfix) with SMTP id BFF1343D2F for ; Mon, 29 Nov 2004 07:26:02 +0000 (GMT) (envelope-from tommyhadiwibowo@yahoo.com) Received: (qmail 1304 invoked by uid 60001); 29 Nov 2004 07:26:02 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=m2Red47NAuGMbfh8t2H4dN5oqwChlAru2lgtURfnIcdebyz/QhNcLOXo8YSN0SF66QD6vw0E6E9YivKTN9B9C7SaYs9/4bTxX4fq5myiEr3ArKeq0jJFbZyr8zhyRTGtjmZaTWDgTUs9WfN9Rrg9REal1EMv+4SPK/zUP+O9Vx8= ; Message-ID: <20041129072602.1302.qmail@web53201.mail.yahoo.com> Received: from [202.133.84.3] by web53201.mail.yahoo.com via HTTP; Sun, 28 Nov 2004 23:26:02 PST Date: Sun, 28 Nov 2004 23:26:02 -0800 (PST) From: tommy barabai To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Networking and TCP/IP with FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 07:26:03 -0000 __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 10:09:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A89DE16A4CE for ; Mon, 29 Nov 2004 10:09:53 +0000 (GMT) Received: from amsfep18-int.chello.nl (amsfep18-int.chello.nl [213.46.243.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id D042943D46 for ; Mon, 29 Nov 2004 10:09:52 +0000 (GMT) (envelope-from joost@jodocus.org) Received: from bps.jodocus.org ([80.57.157.16]) by amsfep18-int.chello.nl (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041129100950.BSXM7692.amsfep18-int.chello.nl@bps.jodocus.org>; Mon, 29 Nov 2004 11:09:50 +0100 Received: from jodocus.org (localhost [127.0.0.1]) by bps.jodocus.org (8.13.1/8.13.1) with ESMTP id iATA9oAB019585; Mon, 29 Nov 2004 11:09:50 +0100 (CET) (envelope-from joost@jodocus.org) Received: (from joost@localhost) by jodocus.org (8.13.1/8.13.1/Submit) id iATA9nWx019584; Mon, 29 Nov 2004 11:09:49 +0100 (CET) (envelope-from joost) Date: Mon, 29 Nov 2004 11:09:49 +0100 From: Joost Bekkers To: freebsd-net@freebsd.org Message-ID: <20041129100949.GA19560@bps.jodocus.org> Mail-Followup-To: Joost Bekkers , freebsd-net@freebsd.org, Ari Suutari Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: (review request) ipfw and ipsec processing order for outgoing packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 10:09:53 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi A while ago there was a discussion about passing packet through pfil before they are processed by ipsec. I've posted a rough patch back then and I've finally had time to polish it. Although the changes seem very invasive at first glance, the .o files created are identical as long as IPSEC_FILTERGIF is not defined. With FAST_IPSEC diff(1) will tell you otherwise, but that is due to changed linenumbers which are used as arguments in two places. I've checked for differences by disassembling (objdump -d) the .o files. The attached patch is against 5.3R I'm running it myself with FAST_IPSEC. The combination of this patch and the kame ipsec could do with some more testing. -- greetz Joost joost@jodocus.org --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipsec_filtergif.diff" *** sys/netinet/dist/ip_output.c Sat Nov 27 20:56:56 2004 --- sys/netinet/ip_output.c Mon Nov 29 10:59:48 2004 *************** *** 405,410 **** --- 405,515 ---- } sendit: + + /* Ok, some really weird wizardry going on here. The goal is to pass + * packets that are going to be ipsec encapsulated pass through the + * firewall first. + * + * The PFIL code is split into two pieces: + * 1) the main part, which calls the pfil hooks and cleans up after them + * 2) a part that handles forwarding (if option IPFIREWALL_FORWARD is in the config) + * + * Because part 2 is not always include the #defines are done in two steps. + * + * There are five possible scenarios for this piece of code: + * + * 1) no ipsec at all -> pfil + * 2) Kame IPSEC without IPSEC_FILTERGIF -> ipsec, pfil + * 3) Kame IPSEC with IPSEC_FILTERGIF -> pfil, ipsec, pfil + * 4) FAST_IPSEC without IPSEC_FILTERGIF -> ipsec, pfil + * 5) FAST_IPSEC with IPSEC_FILTERGIF -> pfil, ipsec + * + * The first pfil location is therefor only used if IPSEC_FILTERGIF is defined. + * The second location is used if IPSEC_FILTERGIF is not defined of FAST_IPSEC + * is not defined. + * + * The difference in the kame and fast scenarios is caused by fast reinserting + * the encapsulated package and 'goto done' where kame will change the current + * package to be the encapsulated one. This also causes the strange location of + * the first PFIL(); In case of Kame ipsec the code should only be executed if + * the packet is actually going to be ipsec-ed. We don't want one packet going + * through the firewall twice. + */ + + #define PFIL_RUN_HOOKS(PASSOUT) \ + /* Jump over all PFIL processing if hooks are not active. */ \ + if (inet_pfil_hook.ph_busy_count == -1) \ + goto PASSOUT; \ + \ + /* Run through list of hooks for output packets. */ \ + odst.s_addr = ip->ip_dst.s_addr; \ + error = pfil_run_hooks(&inet_pfil_hook, &m, ifp, PFIL_OUT, inp); \ + if (error != 0 || m == NULL) \ + goto done; \ + \ + ip = mtod(m, struct ip *); \ + \ + /* See if destination IP address was changed by packet filter. */ \ + if (odst.s_addr != ip->ip_dst.s_addr) { \ + m->m_flags |= M_SKIP_FIREWALL; \ + if (in_localip(ip->ip_dst)) { \ + m->m_flags |= M_FASTFWD_OURS; \ + if (m->m_pkthdr.rcvif == NULL) \ + m->m_pkthdr.rcvif = loif; \ + if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { \ + m->m_pkthdr.csum_flags |= \ + CSUM_DATA_VALID | CSUM_PSEUDO_HDR; \ + m->m_pkthdr.csum_data = 0xffff; \ + } \ + m->m_pkthdr.csum_flags |= \ + CSUM_IP_CHECKED | CSUM_IP_VALID; \ + \ + error = netisr_queue(NETISR_IP, m); \ + goto done; \ + } else \ + goto again; \ + } + + #define PFIL_FORWARD \ + /* See if local, if yes, send it to netisr with IP_FASTFWD_OURS. */ \ + if (m->m_flags & M_FASTFWD_OURS) { \ + if (m->m_pkthdr.rcvif == NULL) \ + m->m_pkthdr.rcvif = loif; \ + if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { \ + m->m_pkthdr.csum_flags |= \ + CSUM_DATA_VALID | CSUM_PSEUDO_HDR; \ + m->m_pkthdr.csum_data = 0xffff; \ + } \ + m->m_pkthdr.csum_flags |= \ + CSUM_IP_CHECKED | CSUM_IP_VALID; \ + \ + error = netisr_queue(NETISR_IP, m); \ + goto done; \ + } \ + /* Or forward to some other address? */ \ + fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL); \ + if (fwd_tag) { \ + if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) { \ + dst = (struct sockaddr_in *)&ro->ro_dst; \ + bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in)); \ + m->m_flags |= M_SKIP_FIREWALL; \ + m_tag_delete(m, fwd_tag); \ + goto again; \ + } else { \ + m_tag_delete(m, fwd_tag); \ + /* Continue. */ \ + } \ + } + + #ifdef IPFIREWALL_FORWARD + #define PFIL(endlabel) PFIL_RUN_HOOKS(endlabel) \ + PFIL_FORWARD \ + endlabel: + #else + #define PFIL(endlabel) PFIL_RUN_HOOKS(endlabel) \ + endlabel: + #endif + #ifdef IPSEC /* get SP for this packet */ if (inp == NULL) *************** *** 447,452 **** --- 552,564 ---- default: printf("ip_output: Invalid policy found. %d\n", sp->policy); } + #endif + + #ifdef IPSEC_FILTERGIF + PFIL(passout1) + #endif + + #ifdef IPSEC { struct ipsec_output_state state; bzero(&state, sizeof(state)); *************** *** 654,725 **** spd_done: #endif /* FAST_IPSEC */ ! /* Jump over all PFIL processing if hooks are not active. */ ! if (inet_pfil_hook.ph_busy_count == -1) ! goto passout; ! ! /* Run through list of hooks for output packets. */ ! odst.s_addr = ip->ip_dst.s_addr; ! error = pfil_run_hooks(&inet_pfil_hook, &m, ifp, PFIL_OUT, inp); ! if (error != 0 || m == NULL) ! goto done; ! ! ip = mtod(m, struct ip *); ! ! /* See if destination IP address was changed by packet filter. */ ! if (odst.s_addr != ip->ip_dst.s_addr) { ! m->m_flags |= M_SKIP_FIREWALL; ! if (in_localip(ip->ip_dst)) { ! m->m_flags |= M_FASTFWD_OURS; ! if (m->m_pkthdr.rcvif == NULL) ! m->m_pkthdr.rcvif = loif; ! if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { ! m->m_pkthdr.csum_flags |= ! CSUM_DATA_VALID | CSUM_PSEUDO_HDR; ! m->m_pkthdr.csum_data = 0xffff; ! } ! m->m_pkthdr.csum_flags |= ! CSUM_IP_CHECKED | CSUM_IP_VALID; ! ! error = netisr_queue(NETISR_IP, m); ! goto done; ! } else ! goto again; ! } ! ! #ifdef IPFIREWALL_FORWARD ! /* See if local, if yes, send it to netisr with IP_FASTFWD_OURS. */ ! if (m->m_flags & M_FASTFWD_OURS) { ! if (m->m_pkthdr.rcvif == NULL) ! m->m_pkthdr.rcvif = loif; ! if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { ! m->m_pkthdr.csum_flags |= ! CSUM_DATA_VALID | CSUM_PSEUDO_HDR; ! m->m_pkthdr.csum_data = 0xffff; ! } ! m->m_pkthdr.csum_flags |= ! CSUM_IP_CHECKED | CSUM_IP_VALID; ! ! error = netisr_queue(NETISR_IP, m); ! goto done; ! } ! /* Or forward to some other address? */ ! fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL); ! if (fwd_tag) { ! if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) { ! dst = (struct sockaddr_in *)&ro->ro_dst; ! bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in)); ! m->m_flags |= M_SKIP_FIREWALL; ! m_tag_delete(m, fwd_tag); ! goto again; ! } else { ! m_tag_delete(m, fwd_tag); ! /* Continue. */ ! } ! } #endif - passout: /* 127/8 must not appear on wire - RFC1122. */ if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET || (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) { --- 766,779 ---- spd_done: #endif /* FAST_IPSEC */ ! #if !defined FAST_IPSEC || !defined IPSEC_FILTERGIF ! PFIL(passout2) #endif + #undef PFIL + #undef PFIL_RUN_HOOKS + #undef PFIL_FORWARD + /* 127/8 must not appear on wire - RFC1122. */ if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET || (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) { --CE+1k2dSO48ffgeK-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 10:14:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A148416A4CE for ; Mon, 29 Nov 2004 10:14:55 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC19043D3F for ; Mon, 29 Nov 2004 10:14:54 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 223 invoked from network); 29 Nov 2004 10:06:30 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2004 10:06:30 -0000 Message-ID: <41AAF696.6ED81FBF@freebsd.org> Date: Mon, 29 Nov 2004 11:14:46 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Joost Bekkers References: <20041129100949.GA19560@bps.jodocus.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order for outgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 10:14:55 -0000 Joost Bekkers wrote: > > Hi > > A while ago there was a discussion about passing packet through pfil before > they are processed by ipsec. I've posted a rough patch back then and I've > finally had time to polish it. > > Although the changes seem very invasive at first glance, the .o files created > are identical as long as IPSEC_FILTERGIF is not defined. With FAST_IPSEC diff(1) > will tell you otherwise, but that is due to changed linenumbers which are used > as arguments in two places. I've checked for differences by disassembling (objdump -d) > the .o files. > > The attached patch is against 5.3R Please post unified diffs. > I'm running it myself with FAST_IPSEC. The combination of this patch and the kame > ipsec could do with some more testing. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 10:30:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBC1916A4CE for ; Mon, 29 Nov 2004 10:30:58 +0000 (GMT) Received: from amsfep16-int.chello.nl (amsfep16-int.chello.nl [213.46.243.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC74C43D41 for ; Mon, 29 Nov 2004 10:30:57 +0000 (GMT) (envelope-from joost@jodocus.org) Received: from bps.jodocus.org ([80.57.157.16]) by amsfep19-int.chello.nl ESMTP <20041129103032.QFCD23658.amsfep19-int.chello.nl@bps.jodocus.org>; Mon, 29 Nov 2004 11:30:32 +0100 Received: from jodocus.org (localhost [127.0.0.1]) by bps.jodocus.org (8.13.1/8.13.1) with ESMTP id iATAUVwl019901; Mon, 29 Nov 2004 11:30:31 +0100 (CET) (envelope-from joost@jodocus.org) Received: (from joost@localhost) by jodocus.org (8.13.1/8.13.1/Submit) id iATAUVdN019900; Mon, 29 Nov 2004 11:30:31 +0100 (CET) (envelope-from joost) Date: Mon, 29 Nov 2004 11:30:31 +0100 From: Joost Bekkers To: Andre Oppermann Message-ID: <20041129103031.GA19828@bps.jodocus.org> Mail-Followup-To: Joost Bekkers , Andre Oppermann , freebsd-net@freebsd.org References: <20041129100949.GA19560@bps.jodocus.org> <41AAF696.6ED81FBF@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <41AAF696.6ED81FBF@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order for outgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 10:30:58 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 29, 2004 at 11:14:46AM +0100, Andre Oppermann wrote: > > > > The attached patch is against 5.3R > > Please post unified diffs. > Ok, here you go. -- greetz Joost joost@jodocus.org --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipsec_filtergif_2.diff" --- sys/netinet/dist/ip_output.c Sat Nov 27 20:56:56 2004 +++ sys/netinet/ip_output.c Mon Nov 29 10:59:48 2004 @@ -405,6 +405,111 @@ } sendit: + +/* Ok, some really weird wizardry going on here. The goal is to pass + * packets that are going to be ipsec encapsulated pass through the + * firewall first. + * + * The PFIL code is split into two pieces: + * 1) the main part, which calls the pfil hooks and cleans up after them + * 2) a part that handles forwarding (if option IPFIREWALL_FORWARD is in the config) + * + * Because part 2 is not always include the #defines are done in two steps. + * + * There are five possible scenarios for this piece of code: + * + * 1) no ipsec at all -> pfil + * 2) Kame IPSEC without IPSEC_FILTERGIF -> ipsec, pfil + * 3) Kame IPSEC with IPSEC_FILTERGIF -> pfil, ipsec, pfil + * 4) FAST_IPSEC without IPSEC_FILTERGIF -> ipsec, pfil + * 5) FAST_IPSEC with IPSEC_FILTERGIF -> pfil, ipsec + * + * The first pfil location is therefor only used if IPSEC_FILTERGIF is defined. + * The second location is used if IPSEC_FILTERGIF is not defined of FAST_IPSEC + * is not defined. + * + * The difference in the kame and fast scenarios is caused by fast reinserting + * the encapsulated package and 'goto done' where kame will change the current + * package to be the encapsulated one. This also causes the strange location of + * the first PFIL(); In case of Kame ipsec the code should only be executed if + * the packet is actually going to be ipsec-ed. We don't want one packet going + * through the firewall twice. + */ + +#define PFIL_RUN_HOOKS(PASSOUT) \ + /* Jump over all PFIL processing if hooks are not active. */ \ + if (inet_pfil_hook.ph_busy_count == -1) \ + goto PASSOUT; \ + \ + /* Run through list of hooks for output packets. */ \ + odst.s_addr = ip->ip_dst.s_addr; \ + error = pfil_run_hooks(&inet_pfil_hook, &m, ifp, PFIL_OUT, inp); \ + if (error != 0 || m == NULL) \ + goto done; \ + \ + ip = mtod(m, struct ip *); \ + \ + /* See if destination IP address was changed by packet filter. */ \ + if (odst.s_addr != ip->ip_dst.s_addr) { \ + m->m_flags |= M_SKIP_FIREWALL; \ + if (in_localip(ip->ip_dst)) { \ + m->m_flags |= M_FASTFWD_OURS; \ + if (m->m_pkthdr.rcvif == NULL) \ + m->m_pkthdr.rcvif = loif; \ + if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { \ + m->m_pkthdr.csum_flags |= \ + CSUM_DATA_VALID | CSUM_PSEUDO_HDR; \ + m->m_pkthdr.csum_data = 0xffff; \ + } \ + m->m_pkthdr.csum_flags |= \ + CSUM_IP_CHECKED | CSUM_IP_VALID; \ + \ + error = netisr_queue(NETISR_IP, m); \ + goto done; \ + } else \ + goto again; \ + } + +#define PFIL_FORWARD \ + /* See if local, if yes, send it to netisr with IP_FASTFWD_OURS. */ \ + if (m->m_flags & M_FASTFWD_OURS) { \ + if (m->m_pkthdr.rcvif == NULL) \ + m->m_pkthdr.rcvif = loif; \ + if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { \ + m->m_pkthdr.csum_flags |= \ + CSUM_DATA_VALID | CSUM_PSEUDO_HDR; \ + m->m_pkthdr.csum_data = 0xffff; \ + } \ + m->m_pkthdr.csum_flags |= \ + CSUM_IP_CHECKED | CSUM_IP_VALID; \ + \ + error = netisr_queue(NETISR_IP, m); \ + goto done; \ + } \ + /* Or forward to some other address? */ \ + fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL); \ + if (fwd_tag) { \ + if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) { \ + dst = (struct sockaddr_in *)&ro->ro_dst; \ + bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in)); \ + m->m_flags |= M_SKIP_FIREWALL; \ + m_tag_delete(m, fwd_tag); \ + goto again; \ + } else { \ + m_tag_delete(m, fwd_tag); \ + /* Continue. */ \ + } \ + } + +#ifdef IPFIREWALL_FORWARD + #define PFIL(endlabel) PFIL_RUN_HOOKS(endlabel) \ + PFIL_FORWARD \ + endlabel: +#else + #define PFIL(endlabel) PFIL_RUN_HOOKS(endlabel) \ + endlabel: +#endif + #ifdef IPSEC /* get SP for this packet */ if (inp == NULL) @@ -447,6 +552,13 @@ default: printf("ip_output: Invalid policy found. %d\n", sp->policy); } +#endif + +#ifdef IPSEC_FILTERGIF + PFIL(passout1) +#endif + +#ifdef IPSEC { struct ipsec_output_state state; bzero(&state, sizeof(state)); @@ -654,72 +766,14 @@ spd_done: #endif /* FAST_IPSEC */ - /* Jump over all PFIL processing if hooks are not active. */ - if (inet_pfil_hook.ph_busy_count == -1) - goto passout; - - /* Run through list of hooks for output packets. */ - odst.s_addr = ip->ip_dst.s_addr; - error = pfil_run_hooks(&inet_pfil_hook, &m, ifp, PFIL_OUT, inp); - if (error != 0 || m == NULL) - goto done; - - ip = mtod(m, struct ip *); - - /* See if destination IP address was changed by packet filter. */ - if (odst.s_addr != ip->ip_dst.s_addr) { - m->m_flags |= M_SKIP_FIREWALL; - if (in_localip(ip->ip_dst)) { - m->m_flags |= M_FASTFWD_OURS; - if (m->m_pkthdr.rcvif == NULL) - m->m_pkthdr.rcvif = loif; - if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { - m->m_pkthdr.csum_flags |= - CSUM_DATA_VALID | CSUM_PSEUDO_HDR; - m->m_pkthdr.csum_data = 0xffff; - } - m->m_pkthdr.csum_flags |= - CSUM_IP_CHECKED | CSUM_IP_VALID; - - error = netisr_queue(NETISR_IP, m); - goto done; - } else - goto again; - } - -#ifdef IPFIREWALL_FORWARD - /* See if local, if yes, send it to netisr with IP_FASTFWD_OURS. */ - if (m->m_flags & M_FASTFWD_OURS) { - if (m->m_pkthdr.rcvif == NULL) - m->m_pkthdr.rcvif = loif; - if (m->m_pkthdr.csum_flags & CSUM_DELAY_DATA) { - m->m_pkthdr.csum_flags |= - CSUM_DATA_VALID | CSUM_PSEUDO_HDR; - m->m_pkthdr.csum_data = 0xffff; - } - m->m_pkthdr.csum_flags |= - CSUM_IP_CHECKED | CSUM_IP_VALID; - - error = netisr_queue(NETISR_IP, m); - goto done; - } - /* Or forward to some other address? */ - fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL); - if (fwd_tag) { - if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) { - dst = (struct sockaddr_in *)&ro->ro_dst; - bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in)); - m->m_flags |= M_SKIP_FIREWALL; - m_tag_delete(m, fwd_tag); - goto again; - } else { - m_tag_delete(m, fwd_tag); - /* Continue. */ - } - } +#if !defined FAST_IPSEC || !defined IPSEC_FILTERGIF + PFIL(passout2) #endif +#undef PFIL +#undef PFIL_RUN_HOOKS +#undef PFIL_FORWARD + -passout: /* 127/8 must not appear on wire - RFC1122. */ if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET || (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) { --9jxsPFA5p3P2qPhR-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 11:02:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68BFD16A4CE for ; Mon, 29 Nov 2004 11:02:04 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A57A43D64 for ; Mon, 29 Nov 2004 11:02:04 +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.1/8.13.1) with ESMTP id iATB24uU008073 for ; Mon, 29 Nov 2004 11:02:04 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iATB232Z008066 for freebsd-net@freebsd.org; Mon, 29 Nov 2004 11:02:03 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 29 Nov 2004 11:02:03 GMT Message-Id: <200411291102.iATB232Z008066@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 11:02:04 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 11:04:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 917FB16A4CE for ; Mon, 29 Nov 2004 11:04:30 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C123A43D55 for ; Mon, 29 Nov 2004 11:04:29 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id iATB4PYB036135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Nov 2004 14:04:26 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iATB4OVu002546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Nov 2004 14:04:25 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iATB4OQ7002545; Mon, 29 Nov 2004 14:04:24 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 29 Nov 2004 14:04:24 +0300 From: Gleb Smirnoff To: Roman Kurakin Message-ID: <20041129110424.GA2329@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Roman Kurakin , freebsd-net@freebsd.org References: <41A91816.30807@cronyx.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41A91816.30807@cronyx.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: freebsd-net@freebsd.org Subject: Re: MPSAFE sppp(+fr support) cp cx ctau X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 11:04:30 -0000 On Sun, Nov 28, 2004 at 03:13:10AM +0300, Roman Kurakin wrote: R> Patches were tested on Tau-PCI - Cisco 2500 at speed 4M R> on Dual CPU system with ping-f and uptime ~one week. One Tau adapter or more than one? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 11:44:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4539016A4CE; Mon, 29 Nov 2004 11:44:13 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 872C443D6B; Mon, 29 Nov 2004 11:44:12 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CYjwu-0001ER-OQ; Mon, 29 Nov 2004 13:44:08 +0200 Message-ID: <41AB0B98.6020600@OTEL.net> Date: Mon, 29 Nov 2004 13:44:24 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 11:44:13 -0000 Robert Watson wrote: >On Sat, 27 Nov 2004, Kevin Day wrote: > > > >>I recently upgraded to 5.3 on a system, and manually upgraded >>src/sys/dev/em/* to the latest RELENG_5 versions. (1.44.2.4 of if_em.c) >> >> > >I'm able to reproduce problems using the below configuration is 6.x also, >and am investigating. Thanks for the report, hope to get back to you >shortly with something concrete. > >Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >robert@fledge.watson.org Principal Research Scientist, McAfee Research > > > > >>While the VLAN side of things works better than the stock 5.3 version, >>there still is this problem: >> >> >>ifconfig vlan1 create >>ifconfig vlan1 vlan 1 vlandev em1 link0 >>ifconfig vlan2 create >>ifconfig vlan2 vlan 2 vlandev em1 link0 >>ifconfig vlan3 create >>ifconfig vlan3 vlan 3 vlandev em1 link0 >> >>ifconfig vlan1 inet 192.aaa.bbb.129 netmask 255.255.255.0 >>ifconfig vlan2 inet 64.ccc.ddd.61 netmask 255.255.255.192 >>ifconfig vlan3 inet 64.eee.fff.61 netmask 255.255.255.192 >> >>ifconfig em1 up >>ifconfig em1 promisc >> >>If I do this, vlan1 and vlan3 work fine. Vlan2 can receive packets, but >>anything sent out vlan2 doesn't seem to be heard by any foreign hosts. >>Setting "ifconfig em1 -promisc" makes all vlans work properly. >> >>This is better than the stock 5.3 version of em(4) where none of the >>vlans worked, but something still isn't right. >> >>Is this a known problem still or am I just doing something wrong? >> >> >> >> >> >> Saddly I can just confirm that :( regards From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 11:49:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 538CE16A4CE for ; Mon, 29 Nov 2004 11:49:33 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9985E43D31 for ; Mon, 29 Nov 2004 11:49:32 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id iATBrCQe098768 for freebsd-net@freebsd.org.checked; Mon, 29 Nov 2004 14:53:12 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from [144.206.181.94] (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id iATBoiia098731; Mon, 29 Nov 2004 14:50:44 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <41AB0CA0.8070901@cronyx.ru> Date: Mon, 29 Nov 2004 14:48:48 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <41A91816.30807@cronyx.ru> <20041129110424.GA2329@cell.sick.ru> In-Reply-To: <20041129110424.GA2329@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: MPSAFE sppp(+fr support) cp cx ctau X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 11:49:33 -0000 Gleb Smirnoff wrote: >On Sun, Nov 28, 2004 at 03:13:10AM +0300, Roman Kurakin wrote: >R> Patches were tested on Tau-PCI - Cisco 2500 at speed 4M >R> on Dual CPU system with ping-f and uptime ~one week. > >One Tau adapter or more than one? > > Good question. :-) Actually one channel of the one adapter in last tests. But there were plugged two of them,. second (unused) was with two E1 interfaces with one second interrupt for each interface or in loop mode with attemts of ppp to set up connection. Right now I turned off machine that was working from Friday with one channel of Tau-ISA in loop mode. Did you get any problems? I'll set up additional channels this evening to see if this will hurt last version of driver. Thanks for reminder! rik From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 11:54:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B70A16A4CE for ; Mon, 29 Nov 2004 11:54:27 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B143A43D39 for ; Mon, 29 Nov 2004 11:54:26 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id iATBsJ7m036839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Nov 2004 14:54:19 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iATBsIs5003005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Nov 2004 14:54:18 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iATBsHbQ003004; Mon, 29 Nov 2004 14:54:18 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 29 Nov 2004 14:54:17 +0300 From: Gleb Smirnoff To: Roman Kurakin Message-ID: <20041129115417.GA2986@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Roman Kurakin , freebsd-net@freebsd.org References: <41A91816.30807@cronyx.ru> <20041129110424.GA2329@cell.sick.ru> <41AB0CA0.8070901@cronyx.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41AB0CA0.8070901@cronyx.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: freebsd-net@freebsd.org Subject: Re: MPSAFE sppp(+fr support) cp cx ctau X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 11:54:27 -0000 On Mon, Nov 29, 2004 at 02:48:48PM +0300, Roman Kurakin wrote: R> >On Sun, Nov 28, 2004 at 03:13:10AM +0300, Roman Kurakin wrote: R> >R> Patches were tested on Tau-PCI - Cisco 2500 at speed 4M R> >R> on Dual CPU system with ping-f and uptime ~one week. R> > R> >One Tau adapter or more than one? R> > R> > R> Good question. :-) R> Actually one channel of the one adapter in last tests. But there were R> plugged two of R> them,. second (unused) was with two E1 interfaces with one second R> interrupt for R> each interface or in loop mode with attemts of ppp to set up connection. R> Right now R> I turned off machine that was working from Friday with one channel of R> Tau-ISA in R> loop mode. R> R> Did you get any problems? Haven't tried, yet. Would it be easy to run patchset on RELENG_5? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 12:07:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FA9C16A4CE for ; Mon, 29 Nov 2004 12:07:32 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87C8C43D2D for ; Mon, 29 Nov 2004 12:07:31 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id iATCBDvg099299 for freebsd-net@freebsd.org.checked; Mon, 29 Nov 2004 15:11:13 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from [144.206.181.94] (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id iATC9A07099026; Mon, 29 Nov 2004 15:09:10 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <41AB10F2.40407@cronyx.ru> Date: Mon, 29 Nov 2004 15:07:14 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <41A91816.30807@cronyx.ru> <20041129110424.GA2329@cell.sick.ru> <41AB0CA0.8070901@cronyx.ru> <20041129115417.GA2986@cell.sick.ru> In-Reply-To: <20041129115417.GA2986@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: MPSAFE sppp(+fr support) cp cx ctau X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 12:07:32 -0000 Gleb Smirnoff wrote: >On Mon, Nov 29, 2004 at 02:48:48PM +0300, Roman Kurakin wrote: >R> >On Sun, Nov 28, 2004 at 03:13:10AM +0300, Roman Kurakin wrote: >R> >R> Patches were tested on Tau-PCI - Cisco 2500 at speed 4M >R> >R> on Dual CPU system with ping-f and uptime ~one week. >R> > >R> >One Tau adapter or more than one? >R> > >R> > >R> Good question. :-) >R> Actually one channel of the one adapter in last tests. But there were >R> plugged two of >R> them,. second (unused) was with two E1 interfaces with one second >R> interrupt for >R> each interface or in loop mode with attemts of ppp to set up connection. >R> Right now >R> I turned off machine that was working from Friday with one channel of >R> Tau-ISA in >R> loop mode. >R> >R> Did you get any problems? > >Haven't tried, yet. Would it be easy to run patchset on RELENG_5? > > Tty infrastructure has changed, so it wouldn't be easy, especially for cx(4) driver since it is able to work in async mode. I plan to start merging these changes to Cronyx repo, so I guess I'll have code that could be diffed relative any branch to produce working patches. rik From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 13:16:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9699616A4CE for ; Mon, 29 Nov 2004 13:16:12 +0000 (GMT) Received: from borgtech.ca (borgtech.ca [216.187.106.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F7AD43D58 for ; Mon, 29 Nov 2004 13:16:12 +0000 (GMT) (envelope-from asegu@borgtech.ca) Received: from webdev (unknown [161.53.212.198]) by borgtech.ca (Postfix) with ESMTP id 16DCF54A5 for ; Mon, 29 Nov 2004 13:30:38 +0000 (GMT) From: "Andrew Seguin" To: Date: Mon, 29 Nov 2004 14:16:16 +0100 Message-ID: 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: <41AA6CA9.6020008@mac.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcTVrBQCZYoeeIOiQXmoBWBzDsoVrgAXcTMQ Subject: RE: FreeBSD 5.3 Networking performance problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 13:16:12 -0000 Deep thanks to both of you have replied to date, showing me the poor quality of the Realtec chipset (which btw, was on a D-Link card?). Today, once back on campus, I have tested with the one functional card I could find of different chipset (some no-brand-name card that comes up as 'dc' under FreeBSD). The results were still very poor even though it seems the box did not drop any packets. Ping times were quite variable, from 2 to 2126ms, with the firewall in place, quite stable without (1-2ms). I show below the results of "netstat -i" and the pings from a separate pc while the firewall was in position. I investigated the possibility of the cable being poor quality... but I have only one cross-over and otherwise it seems fine. The other cable seemed to be working as well. I'm therefore going to order as soon as possible some new nic cards and cables. When I have something new, I'll let you know of the developments, in the mean time, sincere thanks for the tips! Andrew =========================== Results from "netstat -i": nic Ipkts Ierr Opkts Oerr sis0 6757 140 3328 0 # Note: facing internet. dc0 3728 32 6569 0 # Note: facing network. =========================== Results from ping, separate PC on network, while firewall in place. ... Reply from xxx.yyy.zzz.1: bytes=32 time=272ms TTL=255 Reply from xxx.yyy.zzz.1: bytes=32 time=2052ms TTL=255 Reply from xxx.yyy.zzz.1: bytes=32 time=2ms TTL=255 Reply from xxx.yyy.zzz.1: bytes=32 time=831ms TTL=255 Reply from xxx.yyy.zzz.1: bytes=32 time=2126ms TTL=255 Reply from xxx.yyy.zzz.1: bytes=32 time=51ms TTL=255 Reply from xxx.yyy.zzz.1: bytes=32 time=1370ms TTL=255 Reply from xxx.yyy.zzz.1: bytes=32 time=3ms TTL=255 ... From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 15:04:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65BBB16A4CF for ; Mon, 29 Nov 2004 15:04:19 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C37AE43D70 for ; Mon, 29 Nov 2004 15:04:18 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 2087 invoked from network); 29 Nov 2004 14:55:52 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2004 14:55:52 -0000 Message-ID: <41AB3A74.8C05601D@freebsd.org> Date: Mon, 29 Nov 2004 16:04:20 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Joost Bekkers References: <20041129100949.GA19560@bps.jodocus.org> <41AAF696.6ED81FBF@freebsd.org> <20041129103031.GA19828@bps.jodocus.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order for outgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 15:04:19 -0000 Joost Bekkers wrote: > > On Mon, Nov 29, 2004 at 11:14:46AM +0100, Andre Oppermann wrote: > > > > > > The attached patch is against 5.3R > > > > Please post unified diffs. > > > > Ok, here you go. While this way of 'fixing' the IPSEC problem works it is rather gross and not very stylish. I prefer not to have this in the tree as makes maintainance a lot harder. I have some stuff wrt [Fast]IPSEC and your problem in the works and it should become ready around christmas time (loadable [Fast]IPSEC, at least for IPv4). -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 15:14:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75C3F16A4CE for ; Mon, 29 Nov 2004 15:14:00 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91A4343D46 for ; Mon, 29 Nov 2004 15:13:59 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 2184 invoked from network); 29 Nov 2004 15:05:33 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2004 15:05:33 -0000 Message-ID: <41AB3CB9.598BB2FB@freebsd.org> Date: Mon, 29 Nov 2004 16:14:01 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041125140641.GA78210@cell.sick.ru> <20041126091316.GA84369@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org cc: James Subject: Re: route cacheing for gif(4) should be optional X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 15:14:00 -0000 Gleb Smirnoff wrote: > > On Thu, Nov 25, 2004 at 09:55:10PM -0500, James wrote: > J> On Thu, Nov 25, 2004 at 05:06:41PM +0300, Gleb Smirnoff wrote: > J> > Back to this problem: > J> > > J> > http://freebsd.rambler.ru/bsdmail/freebsd-net_2004/msg01305.html > J> > > J> > I've found two more people who dislike this feature of gif(4). > J> > So I'd like to make it optional. > J> > > J> > We already have LINK2 flag removing sourceroute filter from gif(4), > J> > which is commonly used in asymmetrically routed networks. I suggest > J> > to use this flag also for disabling route cacheing, since asymmetricity > J> > often appears in dynamically routed networks, and if one runs dynamic > J> > routing, he probably wants to remove route cacheing, too. > J> > J> I'd think we should create a separate option for removing the route > J> cache. Sometimes, certain people want to use the tunnel at the highest > J> maximum performance possible with both sourceroute filter disabled > J> and tunneling routes allocated at their creation time. Perhaps link3 is a > J> good place for this option? > > There is no LINK3 flag :) > > However, gif(4) does not use LINK0 flag. It was used in past. We can utilize > it now. Any objections? IMO you should scrap it altogether. However there have been reasons for storing the rtentry pointer in struct gif. In the old days ip_output() required an rtentry pointer to be passed on, this is no longer the case. And it was sort of a safe-guard to make it harder to send the gif encapsulated packets back through the same gif interface. That didn't work really well and as I say it should be scapped instead of rigged on somewhere else with yet another obscure option. ;) -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 16:15:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43C1116A4CE; Mon, 29 Nov 2004 16:15:34 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FBE043D45; Mon, 29 Nov 2004 16:15:33 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id iATGFUO9040518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Nov 2004 19:15:31 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id iATGFUAJ004804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Nov 2004 19:15:30 +0300 (MSK) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id iATGFTui004803; Mon, 29 Nov 2004 19:15:29 +0300 (MSK) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 29 Nov 2004 19:15:29 +0300 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20041129161529.GA4770@cell.sick.ru> References: <20041125140641.GA78210@cell.sick.ru> <20041126025510.GA44246@scylla.towardex.com> <20041126091316.GA84369@cell.sick.ru> <41AB3CB9.598BB2FB@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <41AB3CB9.598BB2FB@freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20041013, clamav-milter version 0.75l on 127.0.0.1 X-Virus-Status: Clean cc: net@freebsd.org cc: James Subject: Re: route cacheing for gif(4) should be optional X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 16:15:34 -0000 On Mon, Nov 29, 2004 at 04:14:01PM +0100, Andre Oppermann wrote: A> > On Thu, Nov 25, 2004 at 09:55:10PM -0500, James wrote: A> > J> On Thu, Nov 25, 2004 at 05:06:41PM +0300, Gleb Smirnoff wrote: A> > J> > Back to this problem: A> > J> > A> > J> > http://freebsd.rambler.ru/bsdmail/freebsd-net_2004/msg01305.html A> > J> > A> > J> > I've found two more people who dislike this feature of gif(4). A> > J> > So I'd like to make it optional. A> > J> > A> > J> > We already have LINK2 flag removing sourceroute filter from gif(4), A> > J> > which is commonly used in asymmetrically routed networks. I suggest A> > J> > to use this flag also for disabling route cacheing, since asymmetricity A> > J> > often appears in dynamically routed networks, and if one runs dynamic A> > J> > routing, he probably wants to remove route cacheing, too. A> > J> A> > J> I'd think we should create a separate option for removing the route A> > J> cache. Sometimes, certain people want to use the tunnel at the highest A> > J> maximum performance possible with both sourceroute filter disabled A> > J> and tunneling routes allocated at their creation time. Perhaps link3 is a A> > J> good place for this option? A> > A> > There is no LINK3 flag :) A> > A> > However, gif(4) does not use LINK0 flag. It was used in past. We can utilize A> > it now. Any objections? A> A> IMO you should scrap it altogether. Well, we have a spare flag at the moment. And splitting flags separately will make one of our users happier. Let us make it separate. Ok? A> However there have been reasons for A> storing the rtentry pointer in struct gif. In the old days ip_output() A> required an rtentry pointer to be passed on, this is no longer the case. A> And it was sort of a safe-guard to make it harder to send the gif encapsulated A> packets back through the same gif interface. That didn't work really well A> and as I say it should be scapped instead of rigged on somewhere else with A> yet another obscure option. ;) As soon as I make route cacheing optional, I'd like to make it off by default. Let me explain: FreeBSD is stable by default, not fast. Routecacheing is not stable. When a route flap occurs in dynamicly routed network my gif tunnels are stuck. I'll describe in manpage, that more performance can be achieved by enabling this route cacheing. Any objections on this default? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 16:24:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 288BD16A4CE for ; Mon, 29 Nov 2004 16:24:24 +0000 (GMT) Received: from server.interecho.com (server.interecho.com [213.25.86.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6241A43D55 for ; Mon, 29 Nov 2004 16:24:23 +0000 (GMT) (envelope-from my-buziaki@interecho.com) Received: from [192.168.3.13] (helo=localhost.localdomain) by server.interecho.com with esmtp (8.12.10/8.12.9) id 1CYoIY-0007HZ-0i for ; Mon, 29 Nov 2004 17:22:46 +0100 From: Tomek Tylec To: freebsd-net@freebsd.org Content-Type: text/plain Date: Mon, 29 Nov 2004 17:24:18 +0100 Message-Id: <1101745458.913.2.camel@agape> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Network traffic: ttl X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 16:24:24 -0000 I found that gateway I use, sometimes receives packets from my FreeBSD 5.3 box with ttl 63. But when I dumped tcp packets (with tcpdump) that are send from my computer, they always got ttl 64. Moreover Linux (Fedora Core 2) running on same computer don't have such problems. Also older versions of FreeBSD (5.2.1 for example) work fine (ttl is always correct). It's specially important for me, because my ISP, that owns gateway, use simple method to check if he have illegal clients - firewall on gateway drops packets with odd ttl. From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 16:38:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C03E16A4CF for ; Mon, 29 Nov 2004 16:38:10 +0000 (GMT) Received: from mx1.nersc.gov (mx1.nersc.gov [128.55.6.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E04C443D5C for ; Mon, 29 Nov 2004 16:38:09 +0000 (GMT) (envelope-from dart@nersc.gov) Received: by mx1.nersc.gov (Postfix, from userid 4002) id BD4401F399; Mon, 29 Nov 2004 08:38:09 -0800 (PST) Received: from mx1.nersc.gov (localhost [127.0.0.1]) by localhost.nersc.gov (Postfix) with ESMTP id 0EB9E1F3CA; Mon, 29 Nov 2004 08:38:05 -0800 (PST) Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111]) by mx1.nersc.gov (Postfix) with ESMTP id CC90C1F399; Mon, 29 Nov 2004 08:38:04 -0800 (PST) Received: from gemini.nersc.gov (localhost [127.0.0.1]) by gemini.nersc.gov (Postfix) with ESMTP id A16E4F987; Mon, 29 Nov 2004 08:38:02 -0800 (PST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Andrew Seguin , freebsd-net@freebsd.org In-Reply-To: Message from Chuck Swiger of "Sun, 28 Nov 2004 19:26:17 EST." <41AA6CA9.6020008@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-399181420P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 29 Nov 2004 08:38:02 -0800 From: Eli Dart Message-Id: <20041129163802.A16E4F987@gemini.nersc.gov> X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx1.nersc.gov Subject: Re: FreeBSD 5.3 Networking performance problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 16:38:10 -0000 --==_Exmh_-399181420P Content-Type: text/plain; charset=us-ascii > [ ... ] > > I then tested with the whole school going through the firewall: very bad. > > packets were being droped and ping times were around 600ms. Internet was > > pretty much unuseable. > > This report sounds consistent, although you could also have a bad cable or > switch port, too. It would be useful to you to look into the output of > "netstat -i" and "netstat -s", and any statistics which might be available on > your switches (if they have management & per-port stats). The other thing to check is your duplex settings. Your host interface and/or switch interface may be picking the wrong setting when it attempts to autonegotiate. If you have an unmanaged switch (or don't have access) you can manually set the interface to full or half duplex using ifconfig. In my experience, Foundry switches tend to autoneg correctly if the host side is set to auto, and guess wrong if the host is set to a specific setting. Cisco switches are variable, depending on model and IOS version. Note that if your interface is set to full duplex and the switch is set to half, you'll see lousy performance and very likely see no errors on your side. --eli > > -- > -Chuck > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --==_Exmh_-399181420P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQFBq1BqLTFEeF+CsrMRAh+mAJ4gNR0XD2bIojO7WRkklILBrZLyMACfTjom IL8hepsJCh/g3Olr98kXEJU= =CweZ -----END PGP SIGNATURE----- --==_Exmh_-399181420P-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 16:52:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E39D16A4CE for ; Mon, 29 Nov 2004 16:52:15 +0000 (GMT) Received: from borgtech.ca (borgtech.ca [216.187.106.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5EC543D45 for ; Mon, 29 Nov 2004 16:52:14 +0000 (GMT) (envelope-from asegu@borgtech.ca) Received: from webdev (unknown [161.53.212.198]) by borgtech.ca (Postfix) with ESMTP id EDBC854A5; Mon, 29 Nov 2004 17:06:42 +0000 (GMT) From: "Andrew Seguin" To: "'Eli Dart'" , Date: Mon, 29 Nov 2004 17:52:06 +0100 Message-ID: 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: <20041129163802.A16E4F987@gemini.nersc.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcTWM9bhL1Xr5kZ3TBieAf1ak7MKYwAAXOzw Subject: RE: FreeBSD 5.3 Networking performance problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 16:52:15 -0000 Thank you for your reply. > Note that if your interface is set to full duplex and the switch is > set to half, you'll see lousy performance and very likely see no > errors on your side. I have to question though... could this explain a stable ping time of 2ms when the load is around 2-4mbps and unstable ping times of 2ms to 2s, at 10mbps? If so, I shall give it a try tomorrow. I've already ordered Intel pro nics (which I use for all my servers on my small network at borgtech.ca with great results in a similar but lesser bandwidth situation) and new cables (I needed slightly longer ones anyways to put the server in it's final place rather then it's testing spot). Equipment that the firewall sits between is a Cisco 2600 router (internet side) and an HP Procurve switch facing the local LAN. Again thank you, Andrew From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 17:49:57 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A46A416A4CE; Mon, 29 Nov 2004 17:49:57 +0000 (GMT) Received: from amsfep18-int.chello.nl (amsfep18-int.chello.nl [213.46.243.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8567343D4C; Mon, 29 Nov 2004 17:49:56 +0000 (GMT) (envelope-from joost@jodocus.org) Received: from bps.jodocus.org ([80.57.157.16]) by amsfep18-int.chello.nl (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041129174954.WWVN7692.amsfep18-int.chello.nl@bps.jodocus.org>; Mon, 29 Nov 2004 18:49:54 +0100 Received: from jodocus.org (localhost [127.0.0.1]) by bps.jodocus.org (8.13.1/8.13.1) with ESMTP id iATHnsRx026832; Mon, 29 Nov 2004 18:49:54 +0100 (CET) (envelope-from joost@jodocus.org) Received: (from joost@localhost) by jodocus.org (8.13.1/8.13.1/Submit) id iATHns1Y026831; Mon, 29 Nov 2004 18:49:54 +0100 (CET) (envelope-from joost) Date: Mon, 29 Nov 2004 18:49:54 +0100 From: Joost Bekkers To: Andre Oppermann Message-ID: <20041129174954.GA26532@bps.jodocus.org> Mail-Followup-To: Joost Bekkers , Andre Oppermann , freebsd-net@freebsd.org References: <20041129100949.GA19560@bps.jodocus.org> <41AAF696.6ED81FBF@freebsd.org> <20041129103031.GA19828@bps.jodocus.org> <41AB3A74.8C05601D@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41AB3A74.8C05601D@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order for outgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 17:49:57 -0000 On Mon, Nov 29, 2004 at 04:04:20PM +0100, Andre Oppermann wrote: > Joost Bekkers wrote: > > > > On Mon, Nov 29, 2004 at 11:14:46AM +0100, Andre Oppermann wrote: > > > > > > > > The attached patch is against 5.3R > > > > > > Please post unified diffs. > > > > > > > Ok, here you go. > > While this way of 'fixing' the IPSEC problem works it is rather gross > and not very stylish. I prefer not to have this in the tree as makes > maintainance a lot harder. > I totaly agree that it is not pretty. I was trying to avoid duplicating the code (so every change would have to be made twice) and making it a function didn't sit right for some reason. Hints/tips for dealing with this kind of situation are welcome, but maybe better off-list. > I have some stuff wrt [Fast]IPSEC and your problem in the works and > it should become ready around christmas time (loadable [Fast]IPSEC, at > least for IPv4). > Looking forward to it. -- greetz Joost joost@jodocus.org From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 18:08:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E546316A4CE for ; Mon, 29 Nov 2004 18:08:51 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15FCB43D4C for ; Mon, 29 Nov 2004 18:08:49 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 3413 invoked from network); 29 Nov 2004 18:00:21 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2004 18:00:21 -0000 Message-ID: <41AB65B2.A18534BF@freebsd.org> Date: Mon, 29 Nov 2004 19:08:50 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Joost Bekkers References: <20041129100949.GA19560@bps.jodocus.org> <41AAF696.6ED81FBF@freebsd.org> <20041129103031.GA19828@bps.jodocus.org> <41AB3A74.8C05601D@freebsd.org> <20041129174954.GA26532@bps.jodocus.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order for outgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 18:08:52 -0000 Joost Bekkers wrote: > > On Mon, Nov 29, 2004 at 04:04:20PM +0100, Andre Oppermann wrote: > > Joost Bekkers wrote: > > > > > > On Mon, Nov 29, 2004 at 11:14:46AM +0100, Andre Oppermann wrote: > > > > > > > > > > The attached patch is against 5.3R > > > > > > > > Please post unified diffs. > > > > > > > > > > Ok, here you go. > > > > While this way of 'fixing' the IPSEC problem works it is rather gross > > and not very stylish. I prefer not to have this in the tree as makes > > maintainance a lot harder. > > > > I totaly agree that it is not pretty. I was trying to avoid duplicating > the code (so every change would have to be made twice) and making it a > function didn't sit right for some reason. Hints/tips for dealing with > this kind of situation are welcome, but maybe better off-list. As things currently are with IPSEC code weaved directly into ip_input() and ip_output() there is no better way than what you have proposed. > > I have some stuff wrt [Fast]IPSEC and your problem in the works and > > it should become ready around christmas time (loadable [Fast]IPSEC, at > > least for IPv4). > > > > Looking forward to it. It will solve it much more nicely. :) -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 18:44:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53C1516A4D9 for ; Mon, 29 Nov 2004 18:44:38 +0000 (GMT) Received: from mx2.nersc.gov (mx2.nersc.gov [128.55.6.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F8EE43D2F for ; Mon, 29 Nov 2004 18:44:38 +0000 (GMT) (envelope-from dart@nersc.gov) Received: by mx2.nersc.gov (Postfix, from userid 4002) id DD17E7767; Mon, 29 Nov 2004 10:44:37 -0800 (PST) Received: from mx2.nersc.gov (localhost [127.0.0.1]) by localhost.nersc.gov (Postfix) with ESMTP id A30417778; Mon, 29 Nov 2004 10:44:30 -0800 (PST) Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111]) by mx2.nersc.gov (Postfix) with ESMTP id 5A0FE7767; Mon, 29 Nov 2004 10:44:30 -0800 (PST) Received: from gemini.nersc.gov (localhost [127.0.0.1]) by gemini.nersc.gov (Postfix) with ESMTP id 212B2F987; Mon, 29 Nov 2004 10:44:28 -0800 (PST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: "Andrew Seguin" In-Reply-To: Message from "Andrew Seguin" Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-90732756P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 29 Nov 2004 10:44:28 -0800 From: Eli Dart Message-Id: <20041129184428.212B2F987@gemini.nersc.gov> X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx2.nersc.gov cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 5.3 Networking performance problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 18:44:38 -0000 --==_Exmh_-90732756P Content-Type: text/plain; charset=us-ascii In reply to "Andrew Seguin" : > Thank you for your reply. > > > Note that if your interface is set to full duplex and the switch is > > set to half, you'll see lousy performance and very likely see no > > errors on your side. > > I have to question though... could this explain a stable ping time of 2ms > when the load is around 2-4mbps and unstable ping times of 2ms to 2s, at > 10mbps? Hmmm....I typically see much lower throughput with a duplex mismatch (50 to 80 kbytes a second) so this may not be the problem. The things to look for in your switch and router port statistics are the speed and duplex settings (obviously) and late collisions. The presence of late collisions often point to a duplex mismatch. I would check this stuff anyway, if only to eliminate it as a variable.... If you don't have access to the router and/or switch, ask the folks who do for the output of "show interface" for whatever interfaces are connected to your firewall. --eli > > If so, I shall give it a try tomorrow. I've already ordered Intel pro nics > (which I use for all my servers on my small network at borgtech.ca with > great results in a similar but lesser bandwidth situation) and new cables (I > needed slightly longer ones anyways to put the server in it's final place > rather then it's testing spot). > > Equipment that the firewall sits between is a Cisco 2600 router (internet > side) and an HP Procurve switch facing the local LAN. > > Again thank you, > Andrew > --==_Exmh_-90732756P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQFBq24MLTFEeF+CsrMRAgevAJ9XzzI4A9IxmscXYvBwf52y1hoI3gCgp0U+ 77I1AGXqNoZfJN7moOuYIv4= =BdiE -----END PGP SIGNATURE----- --==_Exmh_-90732756P-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 30 14:40:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BEE716A4D1 for ; Tue, 30 Nov 2004 14:40:26 +0000 (GMT) Received: from mx2.aiidatapro.com (mx2.aiidatapro.com [195.47.193.16]) by mx1.FreeBSD.org (Postfix) with SMTP id C477343D1D for ; Tue, 30 Nov 2004 14:40:22 +0000 (GMT) (envelope-from genius@aiidatapro.com) Received: (qmail 9197 invoked by uid 1001); 30 Nov 2004 14:40:21 -0000 Received: from 192.168.1.10 by vpn (envelope-from , uid 64011) with qmail-scanner-1.24st (clamdscan: 0.80/572. spamassassin: 3.0.0. perlscan: 1.24st. Clear:RC:1(192.168.1.10):SA:0(-5.9/3.0):. Processed in 0.269607 secs); 30 Nov 2004 14:40:21 -0000 X-Spam-Status: No, hits=-5.9 required=3.0 X-Spam-Report: SA TESTS -2.9 ALL_TRUSTED Did not pass through any untrusted hosts 2.5 DOMAIN_RATIO BODY: Message body mentions many internet domains -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.6 AWL AWL: From: address is in the auto white-list X-Qmail-Scanner-Mail-From: genius@aiidatapro.com via vpn X-Qmail-Scanner: 1.24st (Clear:RC:1(192.168.1.10):SA:0(-5.9/3.0):. Processed in 0.269607 secs Process 9187) Received: from unknown (HELO mailserver.aiidatapro.com) (192.168.1.10) by vpn.aiidatapro.com with SMTP; 30 Nov 2004 14:40:20 -0000 Received: (qmail 20355 invoked from network); 30 Nov 2004 14:40:09 -0000 Received: from unknown (HELO as.aiidatapro.com) (192.168.1.37) by zmei.aiidatapro.com with SMTP; 30 Nov 2004 14:40:09 -0000 To: freebsd-net@freebsd.org From: "Georgi Ivanov" Organization: IT Content-Type: text/plain; format=flowed; delsp=yes; charset=windows-1251 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Tue, 30 Nov 2004 16:41:07 +0200 Message-ID: User-Agent: Opera M2/7.54 (FreeBSD, build 751) Subject: freebsd-net-unsubscribe@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 14:40:26 -0000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 13:26:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5341C16A4CE for ; Wed, 1 Dec 2004 13:26:07 +0000 (GMT) Received: from smtp.astra.net.uk (smtp.astra.net.uk [212.47.64.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37D8943D55 for ; Wed, 1 Dec 2004 13:26:06 +0000 (GMT) (envelope-from mike@nux.co.uk) Received: from imap.nux.co.uk (unknown [194.165.198.17]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp.astra.net.uk (Postfix) with ESMTP id E469E3BE97 for ; Wed, 1 Dec 2004 13:25:58 +0000 (GMT) Received: (qmail 51147 invoked from network); 1 Dec 2004 11:20:43 -0000 Received: from unknown (HELO black.eros.office) (192.168.5.130) by imap.nux.co.uk with AES256-SHA encrypted SMTP; 1 Dec 2004 11:20:43 -0000 Received: (qmail 50224 invoked by uid 2223); 30 Nov 2004 19:12:21 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Nov 2004 19:12:21 -0000 Date: Tue, 30 Nov 2004 19:12:21 +0000 (GMT) From: Mike Wolman X-X-Sender: mike@black.eros.office To: net@freebsd.org Message-ID: <20041130190844.S50208@black.eros.office> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: em, vlan and pf troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 13:26:07 -0000 Hi, I am having a problem with 5.3 release with pf, vlans and the em device. The machine is being used as a firewall with about 30 vlans behind it. When this was first setup things worked as expected. However today the machine froze with no messages or dump on the console. After the reboot the client vlans were having intermittant problems connecting to the internet. From a client workstation it is not possible to now ping a vlan interface on the machine eg from 192.168.0.12 (workstation) pinging to 192.168.0.1 (this machine) # tcpdump -eni vlan23 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan23, link-type EN10MB (Ethernet), capture size 96 bytes 15:56:36.858496 00:08:74:4d:93:9c > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.12 15:56:36.858525 00:0c:f1:9d:af:04 > 00:08:74:4d:93:9c, ethertype ARP (0x0806), length 42: arp reply 192.168.0.1 is-at 00:0c:f1:9d:af:04 15:56:39.857172 00:08:74:4d:93:9c > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.12 15:56:39.857200 00:0c:f1:9d:af:04 > 00:08:74:4d:93:9c, ethertype ARP (0x0806), length 42: arp reply 192.168.0.1 is-at 00:0c:f1:9d:af:04 15:56:45.885248 00:08:74:4d:93:9c > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.12 15:56:45.885274 00:0c:f1:9d:af:04 > 00:08:74:4d:93:9c, ethertype ARP (0x0806), length 42: arp reply 192.168.0.1 is-at 00:0c:f1:9d:af:04 The arp request never makes it back to the client workstation. However the client is able to sometimes able ping past the firewall to a destination beyond it so nat looks like it is working as they have other intermitant connectivity. This particular host is the default gateway for just 2 of the vlans, there is another freebsd 5.2.1-RELEASE-p9 box as the main firewall - all machines are connected to the same switch stack (netgear) - both boxes are dells using the onboard em0 interfaces - the 5.2 box has not caused any problems. I have had a hunt on the lists and found: http://marc.theaimsgroup.com/?l=freebsd-net&m=110172867801777&w=2 I am not sure if this is related but suspect it is - if so will adding a differnet card from a different vendor fix this? Below are dmesgs, pf.conf and rc.conf, Any help would be much appreciated, Mike. ----------------------------------------- rc.conf: defaultrouter="135.196.3.9" gateway_enable="YES" hostname="thxgate2.thx.office" ifconfig_fxp0="inet 135.196.x.yy netmask 255.255.255.248" ifconfig_xl0="inet 10.2.254.2 netmask 255.255.255.0" cloned_interfaces="vlan1 vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 vlan8 vlan9 vlan10 vlan11 vlan12 vlan13 vlan14 vlan15 vlan16 vlan17 vlan18 vlan19 vlan20 vlan23 vlan24 vlan25 vlan26 vlan27 vlan28 vlan29 vlan30 vlan53" ifconfig_em0="up" ifconfig_vlan1="inet 10.2.101.2 netmask 255.255.255.0 vlan 101 vlandev em0" ifconfig_vlan2="inet 10.2.102.2 netmask 255.255.255.0 vlan 102 vlandev em0" ifconfig_vlan3="inet 10.2.103.2 netmask 255.255.255.0 vlan 103 vlandev em0" ifconfig_vlan4="inet 10.2.104.2 netmask 255.255.255.0 vlan 104 vlandev em0" ifconfig_vlan5="inet 10.2.105.2 netmask 255.255.255.0 vlan 105 vlandev em0" ifconfig_vlan6="inet 10.2.106.2 netmask 255.255.255.0 vlan 106 vlandev em0" ifconfig_vlan7="inet 10.2.107.2 netmask 255.255.255.0 vlan 107 vlandev em0" ifconfig_vlan8="inet 10.2.108.2 netmask 255.255.255.0 vlan 108 vlandev em0" ifconfig_vlan9="inet 10.2.109.2 netmask 255.255.255.0 vlan 109 vlandev em0" ifconfig_vlan10="inet 10.2.110.2 netmask 255.255.255.0 vlan 110 vlandev em0" ifconfig_vlan11="inet 10.2.111.2 netmask 255.255.255.0 vlan 111 vlandev em0" ifconfig_vlan12="inet 10.2.112.2 netmask 255.255.255.0 vlan 112 vlandev em0" ifconfig_vlan13="inet 10.2.113.2 netmask 255.255.255.0 vlan 113 vlandev em0" ifconfig_vlan14="inet 10.2.114.2 netmask 255.255.255.0 vlan 114 vlandev em0" ifconfig_vlan15="inet 10.2.115.2 netmask 255.255.255.0 vlan 115 vlandev em0" ifconfig_vlan16="inet 10.2.116.2 netmask 255.255.255.0 vlan 116 vlandev em0" ifconfig_vlan17="inet 10.2.117.2 netmask 255.255.255.0 vlan 117 vlandev em0" ifconfig_vlan18="inet 10.2.118.2 netmask 255.255.255.0 vlan 118 vlandev em0" ifconfig_vlan19="inet 172.16.13.1 netmask 255.255.255.0 vlan 119 vlandev em0" ifconfig_vlan20="inet 10.2.120.2 netmask 255.255.255.0 vlan 120 vlandev em0" ifconfig_vlan23="inet 192.168.0.1 netmask 255.255.255.0 vlan 123 vlandev em0" ifconfig_vlan24="inet 10.2.124.2 netmask 255.255.255.0 vlan 124 vlandev em0" ifconfig_vlan25="inet 10.2.125.2 netmask 255.255.255.0 vlan 125 vlandev em0" ifconfig_vlan26="inet 10.2.126.2 netmask 255.255.255.0 vlan 126 vlandev em0" ifconfig_vlan27="inet 10.2.127.2 netmask 255.255.255.0 vlan 127 vlandev em0" ifconfig_vlan28="inet 10.2.128.2 netmask 255.255.255.0 vlan 128 vlandev em0" ifconfig_vlan29="inet 10.2.129.2 netmask 255.255.255.0 vlan 129 vlandev em0" ifconfig_vlan30="inet 10.2.130.2 netmask 255.255.255.0 vlan 130 vlandev em0" ifconfig_vlan53="inet 10.2.253.2 netmask 255.255.255.0 vlan 253 vlandev em0" keymap="uk.cp850" sshd_enable="YES" usbd_enable="NO" background_fsck="NO" inetd_enable="YES" pf_enable="YES" # Set to YES to enable packet filter (pf) pflog_enable="YES" ------------------------------------------------------------------------ [thxgate2] /etc# cat /etc/pf.conf ext_if = "fxp0" mgmt_if = "xl0" vnet_101 = "vlan1" vnet_102 = "vlan2" vnet_103 = "vlan3" vnet_104 = "vlan4" vnet_105 = "vlan5" vnet_106 = "vlan6" vnet_107 = "vlan7" vnet_108 = "vlan8" vnet_109 = "vlan9" vnet_110 = "vlan10" vnet_111 = "vlan11" vnet_112 = "vlan12" vnet_113 = "vlan13" vnet_114 = "vlan14" vnet_115 = "vlan15" vnet_116 = "vlan16" vnet_117 = "vlan17" vnet_118 = "vlan18" vnet_119 = "vlan19" vnet_120 = "vlan20" vnet_123 = "vlan23" vnet_124 = "vlan24" vnet_125 = "vlan25" vnet_126 = "vlan26" vnet_127 = "vlan27" vnet_128 = "vlan28" vnet_129 = "vlan29" vnet_130 = "vlan30" vnet_253 = "vlan53" thxmgmt1 = "10.2.254.3" thxmgmt2 = "10.2.254.4" thxm = "10.2.253.50" sqmail = "10.2.253.54" internal_net = "10.2.0.0/16" nuance_net = "172.16.13.0/24" other_net = "192.168.0.0/24" eros_office_ip = "194.165.yy.xx" #Tables table { xx.xxx.xx.xx yy.yy.yy.yy } table { 10.2.0.0/16 172.16.13.0/24 192.168.0.0/24 } # Options set limit { states 10000, frags 10000 } set loginterface em0 set optimization normal set block-policy drop set fingerprints "/etc/pf.os" # Normalization scrub in all # Translation nat/rdr #normal nat on ext_if1 and ext_if3 for 10.2.0.0/16 nat on $ext_if from {$internal_net} to any -> ($ext_if) #special case vlan but gets routed through ext_if nat on $ext_if from {"192.168.0.0/24"} to any -> ($ext_if) #special case get their own connection nat on $ext_if from {"172.16.13.0/24"} to any -> ($ext_if) #rdr for nagios and eros access rdr pass on $ext_if proto tcp from { } to $ext_if port 2022 -> $thxmgmt2 port 22 # rdr outgoing FTP requests to the ftp-proxy rdr on $vnet_101 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_102 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_103 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_104 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_105 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_106 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_107 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_108 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_109 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_110 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_111 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_112 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_113 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_114 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_115 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_116 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_117 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_118 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_120 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_123 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_124 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_125 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_126 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_127 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_128 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_129 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_130 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_253 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_119 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $mgmt_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 #FILTERING block log all block in quick from any to 255.255.255.255 label "$if:broadcast:drop" # Loopback lo0 pass in quick on lo0 all label "lo0:$if:in" pass out quick on lo0 all label "lo0:$if:out" #mgmt_if pass in quick log on $mgmt_if from 10.2.254.0/24 to $mgmt_if label "mgmt_net:$if:to:$if:$proto" pass in log on $mgmt_if route-to lo0 proto tcp from $mgmt_if to any port 8021 keep state label "mgmt_net:$if:$dstport" pass in log on $mgmt_if proto tcp from any to any flags S/SA keep state label "mgmt_net:$if:in:$proto" pass in log on $mgmt_if proto { udp, icmp } from any to any keep state label "mgmt_net:$if:in:$proto" pass out log on $mgmt_if all keep state label "mgmt_net:$if:out" # INTERNAL VLANS # em0 interface (internal vlan host interface) pass in quick on em0 all label "internal_vlan_parent_if:$if:in" pass out quick on em0 all label "internal_vlan_parent_if:$if:in" #Standard Vlans #block in quick log on $vnet_101 from "10.0.0.0/16" pass in log on $vnet_101 from any to ! keep state pass out log on $vnet_101 all keep state pass in log on $vnet_102 from any to ! keep state pass out log on $vnet_102 all keep state pass in log on $vnet_103 from any to ! keep state pass out log on $vnet_103 all keep state pass in log on $vnet_104 from any to ! keep state pass out log on $vnet_104 all keep state pass in log on $vnet_105 from any to ! keep state pass out log on $vnet_105 all keep state pass in log on $vnet_106 from any to ! keep state pass out log on $vnet_106 all keep state pass in log on $vnet_107 from any to ! keep state pass out log on $vnet_107 all keep state pass in log on $vnet_108 from any to ! keep state pass out log on $vnet_108 all keep state pass in log on $vnet_109 from any to ! keep state pass out log on $vnet_109 all keep state pass in log on $vnet_110 from any to ! keep state pass out log on $vnet_110 all keep state pass in log on $vnet_111 from any to ! keep state pass out log on $vnet_111 all keep state pass in log on $vnet_112 from any to ! keep state pass out log on $vnet_112 all keep state pass in log on $vnet_113 from any to ! keep state pass out log on $vnet_113 all keep state pass in log on $vnet_114 from any to ! keep state pass out log on $vnet_114 all keep state pass in log on $vnet_115 from any to ! keep state pass out log on $vnet_115 all keep state pass in log on $vnet_116 from any to ! keep state pass out log on $vnet_116 all keep state pass in log on $vnet_117 from any to ! keep state pass out log on $vnet_117 all keep state pass in log on $vnet_118 from any to ! keep state pass out log on $vnet_118 all keep state pass in log on $vnet_119 from any to ! keep state pass out log on $vnet_119 all keep state pass in log on $vnet_120 from any to ! keep state pass out log on $vnet_120 all keep state pass in log on $vnet_123 from any to ! keep state pass out log on $vnet_123 all keep state pass in log on $vnet_124 from any to ! keep state pass out log on $vnet_124 all keep state pass in log on $vnet_125 from any to ! keep state pass out log on $vnet_125 all keep state pass in log on $vnet_126 from any to ! keep state pass out log on $vnet_126 all keep state pass in log on $vnet_253 from any to ! keep state pass out log on $vnet_253 all keep state # External Interfaces # [silently drop broadcasts (cable modem noise. etc)] #block in quick on $ext_if from any to 255.255.255.255 label "ext1:$if:broadcast:drop" #antispoof log for $ext_if label "ext1:$if:antispoof" #antispoof log for all label "$if:antispoof" block quick on $ext_if proto {tcp,udp} from any to any port {137,138,139,445} label "ext1:$if:$dstport:block" #allow eros_ips to connect to ssh pass in log quick on $ext_if proto tcp from { } to $ext_if port 22 keep state label "ext1:$if:$dstport:pass" pass in log quick on $ext_if proto tcp from { } to $ext_if port 80 keep state label "ext1:$if:$dstport:pass" #allow ping from certain ips to both interfaces pass in on $ext_if inet proto icmp from { } icmp-type 8 code 0 keep state label "ext1:$if:ping:pass" # general "pass out" rules for external interfaces pass out log on $ext_if proto tcp from any to any flags S/SA keep state pass out log on $ext_if proto { udp, icmp, gre, esp, ipencap } from any to any keep state ------------------------------------------------------------------------- uname -a FreeBSD thxgate2.thx.office 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 ------------------------------------------------------------------------- dmesg: Copyright (c) 1992-2004 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 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.40GHz (2394.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff real memory = 267862016 (255 MB) avail memory = 252563456 (240 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf0000000-0xf7ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 uhci0: port 0xff80-0xff9f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff60-0xff7f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xff20-0xff3f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0xdcf0-0xdcff mem 0xfe000000-0xfe7fffff irq 22 at device 1.0 on pci2 twe0: [GIANT-LOCKED] twe0: 2 ports, Firmware FE7X 1.05.00.063, BIOS BE7X 1.08.00.048 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdd80-0xddff mem 0xfe8ddf80-0xfe8ddfff irq 17 at device 2.0 on pci2 miibus0: on xl0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:75:f4:6f:16 fxp0: port 0xdd00-0xdd3f mem 0xfe900000-0xfe9fffff,0xfe8df000-0xfe8dffff irq 19 at device 3.0 on pci2 miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:5b:38:ee em0: port 0xdd40-0xdd7f mem 0xfe8e0000-0xfe8fffff irq 18 at device 12.0 on pci2 em0: Ethernet address: 00:0c:f1:9d:af:04 em0: Speed:N/A Duplex:N/A isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 18 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atapci1: port 0xfea0-0xfeaf,0xfe30-0xfe33,0xfe20-0xfe27,0xfe10-0xfe13,0xfe00-0xfe07 irq 18 at device 31.2 on p ci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x778-0x77f,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xcb800-0xcbfff,0xca000-0xcb7ff,0xc9800-0xc9fff,0xc9000-0xc97ff,0xc8000-0xc8fff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2394014348 Hz quality 800 Timecounters tick every 10.000 msec acd0: CDROM at ata1-master UDMA33 twed0: on twe0 twed0: 38145MB (78122952 sectors) Mounting root from ufs:/dev/twed0s1a From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 13:26:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DDA716A4CF for ; Wed, 1 Dec 2004 13:26:07 +0000 (GMT) Received: from smtp.astra.net.uk (smtp.astra.net.uk [212.47.64.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37BF043D54 for ; Wed, 1 Dec 2004 13:26:06 +0000 (GMT) (envelope-from mike@nux.co.uk) Received: from imap.nux.co.uk (unknown [194.165.198.17]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp.astra.net.uk (Postfix) with ESMTP id E79CF3BEC7 for ; Wed, 1 Dec 2004 13:25:58 +0000 (GMT) Received: (qmail 51146 invoked from network); 1 Dec 2004 11:20:43 -0000 Received: from unknown (HELO black.eros.office) (192.168.5.130) by imap.nux.co.uk with AES256-SHA encrypted SMTP; 1 Dec 2004 11:20:43 -0000 Received: (qmail 50782 invoked by uid 2223); 30 Nov 2004 21:17:32 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Nov 2004 21:17:32 -0000 Date: Tue, 30 Nov 2004 21:17:32 +0000 (GMT) From: Mike Wolman X-X-Sender: mike@black.eros.office To: freebsd-net@freebsd.org Message-ID: <20041130204100.A50634@black.eros.office> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: em, vlan and pf troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 13:26:07 -0000 Hi, I am having a problem with 5.3 release with pf, vlans and the em device. The machine is being used as a firewall with about 30 vlans behind it. When this was first setup things worked as expected. However today the machine froze with no messages or dump on the console. After the reboot the client vlans were having intermittent problems connecting to the internet. From a client workstation it is not possible to now ping a vlan interface on the machine eg from 192.168.0.12 (workstation) pinging to 192.168.0.1 (this machine) # tcpdump -eni vlan23 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan23, link-type EN10MB (Ethernet), capture size 96 bytes 15:56:36.858496 00:08:74:4d:93:9c > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.12 15:56:36.858525 00:0c:f1:9d:af:04 > 00:08:74:4d:93:9c, ethertype ARP (0x0806), length 42: arp reply 192.168.0.1 is-at 00:0c:f1:9d:af:04 15:56:39.857172 00:08:74:4d:93:9c > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.12 15:56:39.857200 00:0c:f1:9d:af:04 > 00:08:74:4d:93:9c, ethertype ARP (0x0806), length 42: arp reply 192.168.0.1 is-at 00:0c:f1:9d:af:04 15:56:45.885248 00:08:74:4d:93:9c > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.1 tell 192.168.0.12 15:56:45.885274 00:0c:f1:9d:af:04 > 00:08:74:4d:93:9c, ethertype ARP (0x0806), length 42: arp reply 192.168.0.1 is-at 00:0c:f1:9d:af:04 The arp request never makes it back to the client workstation. However the client is able to sometimes able ping past the firewall to a destination beyond it so nat looks like it is working as they have other intermittent connectivity. This particular host is the default gateway for just 2 of the vlans, there is another freebsd 5.2.1-RELEASE-p9 box as the main firewall - all machines are connected to the same switch stack (netgear) - both boxes are dells using the onboard em0 interfaces - the 5.2 box has not caused any problems. I have had a hunt on the lists and found: http://marc.theaimsgroup.com/?l=freebsd-net&m=110172867801777&w=2 I am not sure if this is related but suspect it is - if so will adding a different card from a different vendor fix this? (the machine is at a remote location but if this will fix the problem off i go) Other oddities noted are that arp requests from the machine to a client workstation does not get properly tagged when leaving when tcpdumping on the parent vlan interface (em0): 20:35:56.440045 00:0c:f1:9d:af:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.7 tell 192.168.0.1 20:35:57.441227 00:0c:f1:9d:af:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.7 tell 192.168.0.1 20:35:58.451243 00:0c:f1:9d:af:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.7 tell 192.168.0.1 20:35:59.461268 00:0c:f1:9d:af:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.7 tell 192.168.0.1 I checked this against a similar setup but with openbsd and the arp requests are properly tagged: 20:07:49.170233 0:c0:9f:30:ab:1 ff:ff:ff:ff:ff:ff 8100 46: 802.1Q vid 131 pri 0 arp who-has 10.3.131.7 tell 10.3.131.1 20:07:50.180047 0:c0:9f:30:ab:1 ff:ff:ff:ff:ff:ff 8100 46: 802.1Q vid 131 pri 0 arp who-has 10.3.131.7 tell 10.3.131.1 20:07:51.190023 0:c0:9f:30:ab:1 ff:ff:ff:ff:ff:ff 8100 46: 802.1Q vid 131 pri 0 arp who-has 10.3.131.7 tell 10.3.131.1 20:07:52.200021 0:c0:9f:30:ab:1 ff:ff:ff:ff:ff:ff 8100 46: 802.1Q vid 131 pri 0 arp who-has 10.3.131.7 tell 10.3.131.1 However for a client arp request things seem ok: 20:54:10.310243 00:01:e6:a4:4b:95 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 119, p 0, ethertype ARP, arp who-has 172.16.13.57 tell 172.16.13.205 20:54:27.463083 00:01:e6:a4:4b:95 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 119, p 0, ethertype ARP, arp who-has 172.16.13.57 tell 172.16.13.205 20:54:44.615286 00:01:e6:a4:4b:95 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 119, p 0, ethertype ARP, arp who-has 172.16.13.57 tell 172.16.13.205 When trying to connect to the machine from a vlaned computer the tcpdump on em0 again shows the arp request entering with a vlan tag and the reply leaving with no vlan tag. 21:00:37.204082 00:c0:9f:31:82:f1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 253, p 0, ethertype ARP, arp who-has 10.2.253.2 (6f:6c:3d:49:4d:41) tell 10.2.253.50 21:00:37.204123 00:0c:f1:9d:af:04 > 00:c0:9f:31:82:f1, ethertype ARP (0x0806), length 42: arp reply 10.2.253.2 is-at 00:0c:f1:9d:af:04 Below are dmesgs, pf.conf and rc.conf, Any help would be much appreciated, Mike. ----------------------------------------- rc.conf: defaultrouter="135.196.3.9" gateway_enable="YES" hostname="thxgate2.thx.office" ifconfig_fxp0="inet 135.196.x.yy netmask 255.255.255.248" ifconfig_xl0="inet 10.2.254.2 netmask 255.255.255.0" cloned_interfaces="vlan1 vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 vlan8 vlan9 vlan10 vlan11 vlan12 vlan13 vlan14 vlan15 vlan16 vlan17 vlan18 vlan19 vlan20 vlan23 vlan24 vlan25 vlan26 vlan27 vlan28 vlan29 vlan30 vlan53" ifconfig_em0="up" ifconfig_vlan1="inet 10.2.101.2 netmask 255.255.255.0 vlan 101 vlandev em0" ifconfig_vlan2="inet 10.2.102.2 netmask 255.255.255.0 vlan 102 vlandev em0" ifconfig_vlan3="inet 10.2.103.2 netmask 255.255.255.0 vlan 103 vlandev em0" ifconfig_vlan4="inet 10.2.104.2 netmask 255.255.255.0 vlan 104 vlandev em0" ifconfig_vlan5="inet 10.2.105.2 netmask 255.255.255.0 vlan 105 vlandev em0" ifconfig_vlan6="inet 10.2.106.2 netmask 255.255.255.0 vlan 106 vlandev em0" ifconfig_vlan7="inet 10.2.107.2 netmask 255.255.255.0 vlan 107 vlandev em0" ifconfig_vlan8="inet 10.2.108.2 netmask 255.255.255.0 vlan 108 vlandev em0" ifconfig_vlan9="inet 10.2.109.2 netmask 255.255.255.0 vlan 109 vlandev em0" ifconfig_vlan10="inet 10.2.110.2 netmask 255.255.255.0 vlan 110 vlandev em0" ifconfig_vlan11="inet 10.2.111.2 netmask 255.255.255.0 vlan 111 vlandev em0" ifconfig_vlan12="inet 10.2.112.2 netmask 255.255.255.0 vlan 112 vlandev em0" ifconfig_vlan13="inet 10.2.113.2 netmask 255.255.255.0 vlan 113 vlandev em0" ifconfig_vlan14="inet 10.2.114.2 netmask 255.255.255.0 vlan 114 vlandev em0" ifconfig_vlan15="inet 10.2.115.2 netmask 255.255.255.0 vlan 115 vlandev em0" ifconfig_vlan16="inet 10.2.116.2 netmask 255.255.255.0 vlan 116 vlandev em0" ifconfig_vlan17="inet 10.2.117.2 netmask 255.255.255.0 vlan 117 vlandev em0" ifconfig_vlan18="inet 10.2.118.2 netmask 255.255.255.0 vlan 118 vlandev em0" ifconfig_vlan19="inet 172.16.13.1 netmask 255.255.255.0 vlan 119 vlandev em0" ifconfig_vlan20="inet 10.2.120.2 netmask 255.255.255.0 vlan 120 vlandev em0" ifconfig_vlan23="inet 192.168.0.1 netmask 255.255.255.0 vlan 123 vlandev em0" ifconfig_vlan24="inet 10.2.124.2 netmask 255.255.255.0 vlan 124 vlandev em0" ifconfig_vlan25="inet 10.2.125.2 netmask 255.255.255.0 vlan 125 vlandev em0" ifconfig_vlan26="inet 10.2.126.2 netmask 255.255.255.0 vlan 126 vlandev em0" ifconfig_vlan27="inet 10.2.127.2 netmask 255.255.255.0 vlan 127 vlandev em0" ifconfig_vlan28="inet 10.2.128.2 netmask 255.255.255.0 vlan 128 vlandev em0" ifconfig_vlan29="inet 10.2.129.2 netmask 255.255.255.0 vlan 129 vlandev em0" ifconfig_vlan30="inet 10.2.130.2 netmask 255.255.255.0 vlan 130 vlandev em0" ifconfig_vlan53="inet 10.2.253.2 netmask 255.255.255.0 vlan 253 vlandev em0" keymap="uk.cp850" sshd_enable="YES" usbd_enable="NO" background_fsck="NO" inetd_enable="YES" pf_enable="YES" # Set to YES to enable packet filter (pf) pflog_enable="YES" ------------------------------------------------------------------------ [thxgate2] /etc# cat /etc/pf.conf ext_if = "fxp0" mgmt_if = "xl0" vnet_101 = "vlan1" vnet_102 = "vlan2" vnet_103 = "vlan3" vnet_104 = "vlan4" vnet_105 = "vlan5" vnet_106 = "vlan6" vnet_107 = "vlan7" vnet_108 = "vlan8" vnet_109 = "vlan9" vnet_110 = "vlan10" vnet_111 = "vlan11" vnet_112 = "vlan12" vnet_113 = "vlan13" vnet_114 = "vlan14" vnet_115 = "vlan15" vnet_116 = "vlan16" vnet_117 = "vlan17" vnet_118 = "vlan18" vnet_119 = "vlan19" vnet_120 = "vlan20" vnet_123 = "vlan23" vnet_124 = "vlan24" vnet_125 = "vlan25" vnet_126 = "vlan26" vnet_127 = "vlan27" vnet_128 = "vlan28" vnet_129 = "vlan29" vnet_130 = "vlan30" vnet_253 = "vlan53" thxmgmt1 = "10.2.254.3" thxmgmt2 = "10.2.254.4" thxm = "10.2.253.50" sqmail = "10.2.253.54" internal_net = "10.2.0.0/16" nuance_net = "172.16.13.0/24" other_net = "192.168.0.0/24" eros_office_ip = "194.165.yy.xx" #Tables table { xx.xxx.xx.xx yy.yy.yy.yy } table { 10.2.0.0/16 172.16.13.0/24 192.168.0.0/24 } # Options set limit { states 10000, frags 10000 } set loginterface em0 set optimization normal set block-policy drop set fingerprints "/etc/pf.os" # Normalization scrub in all # Translation nat/rdr #normal nat on ext_if1 and ext_if3 for 10.2.0.0/16 nat on $ext_if from {$internal_net} to any -> ($ext_if) #special case vlan but gets routed through ext_if nat on $ext_if from {"192.168.0.0/24"} to any -> ($ext_if) #special case get their own connection nat on $ext_if from {"172.16.13.0/24"} to any -> ($ext_if) #rdr for nagios and eros access rdr pass on $ext_if proto tcp from { } to $ext_if port 2022 -> $thxmgmt2 port 22 # rdr outgoing FTP requests to the ftp-proxy rdr on $vnet_101 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_102 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_103 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_104 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_105 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_106 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_107 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_108 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_109 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_110 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_111 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_112 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_113 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_114 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_115 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_116 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_117 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_118 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_120 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_123 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_124 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_125 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_126 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_127 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_128 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_129 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_130 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_253 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $vnet_119 proto tcp from any to any port ftp -> 127.0.0.1 port 8021 rdr on $mgmt_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021 #FILTERING block log all block in quick from any to 255.255.255.255 label "$if:broadcast:drop" # Loopback lo0 pass in quick on lo0 all label "lo0:$if:in" pass out quick on lo0 all label "lo0:$if:out" #mgmt_if pass in quick log on $mgmt_if from 10.2.254.0/24 to $mgmt_if label "mgmt_net:$if:to:$if:$proto" pass in log on $mgmt_if route-to lo0 proto tcp from $mgmt_if to any port 8021 keep state label "mgmt_net:$if:$dstport" pass in log on $mgmt_if proto tcp from any to any flags S/SA keep state label "mgmt_net:$if:in:$proto" pass in log on $mgmt_if proto { udp, icmp } from any to any keep state label "mgmt_net:$if:in:$proto" pass out log on $mgmt_if all keep state label "mgmt_net:$if:out" # INTERNAL VLANS # em0 interface (internal vlan host interface) pass in quick on em0 all label "internal_vlan_parent_if:$if:in" pass out quick on em0 all label "internal_vlan_parent_if:$if:in" #Standard Vlans #block in quick log on $vnet_101 from "10.0.0.0/16" pass in log on $vnet_101 from any to ! keep state pass out log on $vnet_101 all keep state pass in log on $vnet_102 from any to ! keep state pass out log on $vnet_102 all keep state pass in log on $vnet_103 from any to ! keep state pass out log on $vnet_103 all keep state pass in log on $vnet_104 from any to ! keep state pass out log on $vnet_104 all keep state pass in log on $vnet_105 from any to ! keep state pass out log on $vnet_105 all keep state pass in log on $vnet_106 from any to ! keep state pass out log on $vnet_106 all keep state pass in log on $vnet_107 from any to ! keep state pass out log on $vnet_107 all keep state pass in log on $vnet_108 from any to ! keep state pass out log on $vnet_108 all keep state pass in log on $vnet_109 from any to ! keep state pass out log on $vnet_109 all keep state pass in log on $vnet_110 from any to ! keep state pass out log on $vnet_110 all keep state pass in log on $vnet_111 from any to ! keep state pass out log on $vnet_111 all keep state pass in log on $vnet_112 from any to ! keep state pass out log on $vnet_112 all keep state pass in log on $vnet_113 from any to ! keep state pass out log on $vnet_113 all keep state pass in log on $vnet_114 from any to ! keep state pass out log on $vnet_114 all keep state pass in log on $vnet_115 from any to ! keep state pass out log on $vnet_115 all keep state pass in log on $vnet_116 from any to ! keep state pass out log on $vnet_116 all keep state pass in log on $vnet_117 from any to ! keep state pass out log on $vnet_117 all keep state pass in log on $vnet_118 from any to ! keep state pass out log on $vnet_118 all keep state pass in log on $vnet_119 from any to ! keep state pass out log on $vnet_119 all keep state pass in log on $vnet_120 from any to ! keep state pass out log on $vnet_120 all keep state pass in log on $vnet_123 from any to ! keep state pass out log on $vnet_123 all keep state pass in log on $vnet_124 from any to ! keep state pass out log on $vnet_124 all keep state pass in log on $vnet_125 from any to ! keep state pass out log on $vnet_125 all keep state pass in log on $vnet_126 from any to ! keep state pass out log on $vnet_126 all keep state pass in log on $vnet_253 from any to ! keep state pass out log on $vnet_253 all keep state # External Interfaces # [silently drop broadcasts (cable modem noise. etc)] #block in quick on $ext_if from any to 255.255.255.255 label "ext1:$if:broadcast:drop" #antispoof log for $ext_if label "ext1:$if:antispoof" #antispoof log for all label "$if:antispoof" block quick on $ext_if proto {tcp,udp} from any to any port {137,138,139,445} label "ext1:$if:$dstport:block" #allow eros_ips to connect to ssh pass in log quick on $ext_if proto tcp from { } to $ext_if port 22 keep state label "ext1:$if:$dstport:pass" pass in log quick on $ext_if proto tcp from { } to $ext_if port 80 keep state label "ext1:$if:$dstport:pass" #allow ping from certain ips to both interfaces pass in on $ext_if inet proto icmp from { } icmp-type 8 code 0 keep state label "ext1:$if:ping:pass" # general "pass out" rules for external interfaces pass out log on $ext_if proto tcp from any to any flags S/SA keep state pass out log on $ext_if proto { udp, icmp, gre, esp, ipencap } from any to any keep state ------------------------------------------------------------------------- uname -a FreeBSD thxgate2.thx.office 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 ------------------------------------------------------------------------- dmesg: Copyright (c) 1992-2004 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 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.40GHz (2394.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff real memory = 267862016 (255 MB) avail memory = 252563456 (240 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf0000000-0xf7ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 uhci0: port 0xff80-0xff9f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff60-0xff7f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xff20-0xff3f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0xdcf0-0xdcff mem 0xfe000000-0xfe7fffff irq 22 at device 1.0 on pci2 twe0: [GIANT-LOCKED] twe0: 2 ports, Firmware FE7X 1.05.00.063, BIOS BE7X 1.08.00.048 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdd80-0xddff mem 0xfe8ddf80-0xfe8ddfff irq 17 at device 2.0 on pci2 miibus0: on xl0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:75:f4:6f:16 fxp0: port 0xdd00-0xdd3f mem 0xfe900000-0xfe9fffff,0xfe8df000-0xfe8dffff irq 19 at device 3.0 on pci2 miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:5b:38:ee em0: port 0xdd40-0xdd7f mem 0xfe8e0000-0xfe8fffff irq 18 at device 12.0 on pci2 em0: Ethernet address: 00:0c:f1:9d:af:04 em0: Speed:N/A Duplex:N/A isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 18 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atapci1: port 0xfea0-0xfeaf,0xfe30-0xfe33,0xfe20-0xfe27,0xfe10-0xfe13,0xfe00-0xfe07 irq 18 at device 31.2 on p ci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x778-0x77f,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xcb800-0xcbfff,0xca000-0xcb7ff,0xc9800-0xc9fff,0xc9000-0xc97ff,0xc8000-0xc8fff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2394014348 Hz quality 800 Timecounters tick every 10.000 msec acd0: CDROM at ata1-master UDMA33 twed0: on twe0 twed0: 38145MB (78122952 sectors) Mounting root from ufs:/dev/twed0s1a From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 01:13:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6876216A4CE for ; Wed, 1 Dec 2004 01:13:16 +0000 (GMT) Received: from hotmail.com (bay16-f17.bay16.hotmail.com [65.54.186.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3961743D2F for ; Wed, 1 Dec 2004 01:13:16 +0000 (GMT) (envelope-from zhao_xiaowen@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Nov 2004 17:13:15 -0800 Message-ID: Received: from 202.104.245.165 by by16fd.bay16.hotmail.msn.com with HTTP; Wed, 01 Dec 2004 01:12:55 GMT X-Originating-IP: [202.104.245.165] X-Originating-Email: [zhao_xiaowen@hotmail.com] X-Sender: zhao_xiaowen@hotmail.com From: =?gb2312?B?1dQgz/7OxA==?= To: freebsd-net@freebsd.org Date: Wed, 01 Dec 2004 09:12:55 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed X-OriginalArrivalTime: 01 Dec 2004 01:13:15.0338 (UTC) FILETIME=[EF279AA0:01C4D742] X-Mailman-Approved-At: Wed, 01 Dec 2004 13:40:40 +0000 Subject: pim6sd ipv6 mulitcast routing problem! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 01:13:16 -0000 Hi everybody: I'm setting up a Freebsd router box to perform ipv6 unicast & multicast routing, but I cannot make multicast routing work. Unicast routing just works well. The router box is set up as follow: 1) FreeBSD 5.2.1 with kame-20041101-freebsd521-snap; 2) Quagga (zebra) 0.96.5 for ipv6 unicast routing; 3) Pim6sd for ipv6 multicast routing (use the default pim6sd.conf). The router box has 3 ethernet interfaces, each of them are connect to a separate subnet: bsdrouter# ifconfig xl0: flags=8a43 mtu 1500 options=b inet6 fe80::201:3ff:fe26:8bba%xl0 prefixlen 64 scopeid 0x1 inet6 2001:250:3003:240::1 prefixlen 64 xl1: flags=8a43 mtu 1500 options=b inet6 fe80::201:3ff:fee2:1dc3%xl1 prefixlen 64 scopeid 0x2 inet6 2001:250:3003:202::1 prefixlen 64 vr0: flags=8a43 mtu 1500 inet6 fe80::20d:88ff:fe4a:d970%vr0 prefixlen 64 scopeid 0x3 inet6 2001:250:3003:250::1 prefixlen 64 After finishing the configuration of BSD router, I then use Robust Audio Tool (RAT) to test ipv6 multicast routing. 3 RAT user from the foresaid subnet, joining the multicast group "ff1e::240:100". But it seems that the router dose not forward multicast packet from an interface to others. tcpdump and pim6stat indicate that MLD message between router and host works with no problem. But the routing table is empty! The following is the ouput of "pim6stat" command: PIM Neighbor List Mif PhyIF Address Timer MLD Querier List Mif PhyIF Address Timer Last 0 xl0 fe80::201:3ff:fe26:8bba 255 1h7m27s 1 xl1 fe80::201:3ff:fee2:1dc3 255 1h7m27s 2 vr0 fe80::20d:88ff:fe4a:d970 255 1h7m27s Reported MLD Group Mif PhyIF Group(Group-Timer,MLD-ver(Filter-Mode,Compat-Timer))/Source(TimerID) 0 xl0 ff1e::240:100 (#897 (v1 EX #0)) (any source) (-) 1 xl1 ff1e::240:100 (#894 (v1 EX #0)) (any source) (-) 2 vr0 ff1e::240:100 (#896 (v1 EX #0)) (any source) (-) Multicast Routing Table Source Group RP-addr Flags --------------------------(*,*,RP)-------------------------- Number of Groups: 0 Number of Cache MIRRORs: 0 ---------------------------RP-Set---------------------------- "pim6stat -s" shows that "forwarding cache miss" occur on every interface. The following is the ouput of "pim6stat -s": bsdrouter# /usr/local/v6/sbin/pim6stat -s pim6sd per-interface statistics Mif=0, PhyIF=xl0 139 pim6 hello sent 38 MLD report received 2 MLD done received 38 MLD query sent 1452 forwarding cache miss 1452 forwarding cache miss and not created Mif=1, PhyIF=xl1 139 pim6 hello sent 37 MLD report received 2 MLD done received 38 MLD query sent 1163 forwarding cache miss 1163 forwarding cache miss and not created Mif=2, PhyIF=vr0 139 pim6 hello sent 6 MLD report received 34 MLD query sent 1071 forwarding cache miss 1071 forwarding cache miss and not created "netstat -gs" also says "multicast forwarding cache misses": bsdrouter# netstat -gs netstat: sysctl: net.inet.ip.mrtstat: No such file or directory No IPv4 multicast routing compiled into this system. IPv6 multicast forwarding: 22110 multicast forwarding cache lookups 22110 multicast forwarding cache misses 2937 upcalls to mrouted 15683 upcall queue overflows 0 upcalls dropped due to full socket buffer 2936 cache cleanups 22110 datagrams with no route for origin 0 datagrams arrived with bad tunneling So, what's wrong with my setup? How can I correct it and make ipv6 multicast routing work? Thanks! Vincent _________________________________________________________________ ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com From owner-freebsd-net@FreeBSD.ORG Wed Dec 1 14:08:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89FDC16A4CE for ; Wed, 1 Dec 2004 14:08:55 +0000 (GMT) Received: from mail.citiz.net (ws17.citiz.net [218.1.66.102]) by mx1.FreeBSD.org (Postfix) with SMTP id 4F24443D2D for ; Wed, 1 Dec 2004 14:08:51 +0000 (GMT) (envelope-from edrt@citiz.net) Received: (umta 5857 invoked by alias); 1 Dec 2004 14:08:48 -0000 X-Lasthop: 220.112.125.248 Received: from unknown (HELO a) (unknown@220.112.125.248) by localhost with SMTP; 1 Dec 2004 14:08:48 -0000 Date: Wed, 1 Dec 2004 22:11:22 +0800 From: "edrt" To: "=?gb2312?B?1dQgz/7OxA==?=" , "freebsd-net@freebsd.org" X-mailer: Foxmail 5.0 beta1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20041201140851.4F24443D2D@mx1.FreeBSD.org> cc: edrt Subject: Re: pim6sd ipv6 mulitcast routing problem! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 14:08:55 -0000 >So, what's wrong with my setup? How can I correct it and make ipv6 >multicast routing work? >Thanks! > >Vincent > Hi Vincent pim6stat shows that RP-set is empty. If you are using PIM-SM in ASM mode, you must configure RP/BSR information #syntax :