From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 05:42:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92FC616A417 for ; Sun, 27 Jan 2008 05:42:14 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (host-122-100-2-232.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id 52D0F13C442 for ; Sun, 27 Jan 2008 05:42:13 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id 041FA142AA; Sun, 27 Jan 2008 16:42:12 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from anzac.hos (132.169.233.220.exetel.com.au [220.233.169.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id 16F98142A6 for ; Sun, 27 Jan 2008 16:42:08 +1100 (EST) Message-ID: <479C19AF.3080407@modulus.org> Date: Sun, 27 Jan 2008 16:42:07 +1100 From: Andrew Snow User-Agent: Thunderbird 2.0.0.0 (X11/20070426) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <008701c8602f$29d1bdc0$b6db87d4@multiplay.co.uk> <2a41acea0801261214g73e75fe3v213a41cf8d0764e4@mail.gmail.com> In-Reply-To: <2a41acea0801261214g73e75fe3v213a41cf8d0764e4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally Options X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 05:42:14 -0000 Jack Vogel wrote: > But I do not think we need more debugging at this point, when the > new code is checked in it will be great to have everyone that has seen > the issue test it though. Will look forward to testing it, though its intermittent nature for me means I might have trouble reproducing it. It seems to happen mainly when doing a warm reboot. Congratulations and thank you for your work on the em driver by the way. Between two recent Xeon servers running 7.0-RC1 with onboard Intel Pro1000, I achieved 99 megabytes per second transfer rate using very little CPU time using geom_gate to mirror disks of the network. TSO seems to be working well :-) - Andrew From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 11:02:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 184AE16A4C0 for ; Sun, 27 Jan 2008 11:02:05 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id BC76F13C4CC for ; Sun, 27 Jan 2008 11:02:04 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 9B2071B10EDC; Sun, 27 Jan 2008 12:02:03 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 09B461B10EA4; Sun, 27 Jan 2008 12:02:01 +0100 (CET) Message-ID: <479C64A8.6020308@moneybookers.com> Date: Sun, 27 Jan 2008 13:02:00 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: Vladimir Ivanov References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> <20071003111737.U14276@delplex.bde.org> <47037246.2070400@yandex-team.ru> <47040D83.9010706@delphij.net> <47200537.8070708@room52.net> <472028C0.4040004@delphij.net> <47220853.90206@yandex-team.ru> <20071214113434.GD63588@uafug.org.ua> <4762796B.3090608@yandex-team.ru> <479B5C27.2010201@moneybookers.com> <479BC043.8020007@yandex-team.ru> In-Reply-To: <479BC043.8020007@yandex-team.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5574/Sun Jan 27 11:03:42 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: "freebsd-net@freebsd.org" Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 11:02:05 -0000 Hi Vladimir, Vladimir Ivanov wrote: > Hi, Stefan > > Stefan Lambrev wrote: >> Hi Vladimir, >> >> Will http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.28.tar.gz >> work out of the box on FreeBSD 7, or it's just for 6.X? > We use (and debug) it w/RELENG_6. I seem it can be used w/CURRENT but > I didn't test it yet. > Also, pls use 1.30 revision instead (I've fixed rare stuck condition > in txirq-less code). Thanks for your reply. I'll give a try of your latest driver and will let you know if it works with 7_0. Do you have some stats that compare pps throughput with both drivers? > > WBR, > Vladimir > _______________________________________________ > 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" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 13:05:42 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2122E16A41A; Sun, 27 Jan 2008 13:05:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EC74413C442; Sun, 27 Jan 2008 13:05:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0RD5fh3001142; Sun, 27 Jan 2008 13:05:41 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0RD5fG2001138; Sun, 27 Jan 2008 13:05:41 GMT (envelope-from rwatson) Date: Sun, 27 Jan 2008 13:05:41 GMT Message-Id: <200801271305.m0RD5fG2001138@freefall.freebsd.org> To: dgilbert@daveg.ca, rwatson@FreeBSD.org, freebsd-net@FreeBSD.org From: rwatson@FreeBSD.org Cc: Subject: Re: kern/115360: [ipv6] IPv6 address and if_bridge don't play well together. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 13:05:42 -0000 Synopsis: [ipv6] IPv6 address and if_bridge don't play well together. State-Changed-From-To: feedback->closed State-Changed-By: rwatson State-Changed-When: Sun Jan 27 13:04:33 UTC 2008 State-Changed-Why: Close due to feedback timeout (>2 months). If you have further information to help debug this problem, please follow up on the PR and we can reopen it. http://www.freebsd.org/cgi/query-pr.cgi?pr=115360 From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 15:09:15 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 259BB16A418; Sun, 27 Jan 2008 15:09:15 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F1CF313C4D1; Sun, 27 Jan 2008 15:09:14 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from freefall.freebsd.org (mav@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0RF9EvY010266; Sun, 27 Jan 2008 15:09:14 GMT (envelope-from mav@freefall.freebsd.org) Received: (from mav@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0RF9ERE010262; Sun, 27 Jan 2008 15:09:14 GMT (envelope-from mav) Date: Sun, 27 Jan 2008 15:09:14 GMT Message-Id: <200801271509.m0RF9ERE010262@freefall.freebsd.org> To: louie@transsys.com, mav@FreeBSD.org, freebsd-net@FreeBSD.org From: mav@FreeBSD.org Cc: Subject: Re: kern/119839: [ng_netflow] ng_netflow can consume large sums of memory if export hook isn't connected X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 15:09:15 -0000 Synopsis: [ng_netflow] ng_netflow can consume large sums of memory if export hook isn't connected State-Changed-From-To: open->closed State-Changed-By: mav State-Changed-When: Sun Jan 27 15:02:12 UTC 2008 State-Changed-Why: Fixed in HEAD. Expire does not depends on export hook any more. It allows node to be used with flowctl, but without export. http://www.freebsd.org/cgi/query-pr.cgi?pr=119839 From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 15:20:02 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B57C216A420 for ; Sun, 27 Jan 2008 15:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A23DC13C4E5 for ; Sun, 27 Jan 2008 15:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0RFK27R012524 for ; Sun, 27 Jan 2008 15:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0RFK27B012523; Sun, 27 Jan 2008 15:20:02 GMT (envelope-from gnats) Date: Sun, 27 Jan 2008 15:20:02 GMT Message-Id: <200801271520.m0RFK27B012523@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.org (dfilter service) Cc: Subject: Re: kern/119839: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 15:20:02 -0000 The following reply was made to PR kern/119839; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/119839: commit references a PR Date: Sun, 27 Jan 2008 15:01:24 +0000 (UTC) mav 2008-01-27 15:01:16 UTC FreeBSD src repository Modified files: sys/netgraph/netflow ng_netflow.c Log: Run expire even without export hook connected. PR: kern/119839 Revision Changes Path 1.15 +4 -8 src/sys/netgraph/netflow/ng_netflow.c _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 15:53:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06CA316A417 for ; Sun, 27 Jan 2008 15:53:27 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from pop-mx00.ca.mci.com (pop-mx00.ca.mci.com [142.77.1.56]) by mx1.freebsd.org (Postfix) with ESMTP id CE10013C4EF for ; Sun, 27 Jan 2008 15:53:26 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by pop-mx00.ca.mci.com (Postfix) with ESMTP id E1284D921C for ; Sun, 27 Jan 2008 10:53:25 -0500 (EST) Received: from [70.82.117.235] (account kfl@xiphos.ca HELO [10.0.0.241]) by mail.net (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1704347614; Sun, 27 Jan 2008 10:53:25 -0500 Message-ID: <479CA8F5.8050902@xiplink.com> Date: Sun, 27 Jan 2008 10:53:25 -0500 From: Karim Fodil-Lemelin User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Karim Fodil-Lemelin References: <479A2284.3080300@xiplink.com> <479A4CC1.1040006@FreeBSD.org> In-Reply-To: <479A4CC1.1040006@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: vm_zone corruption 4.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 15:53:27 -0000 Doug Barton wrote: > Karim Fodil-Lemelin wrote: > >> I have stumbled into a strange problem where my FBSD 4.x box > > FreeBSD 4.x is no longer supported. Your best bet at this point would > be to evaluate the 7.0 release candidates, since that branch has a lot > of both stability and performance enhancements. > > Good luck, > > Doug > Going to the latest FreeBSD version is certainly in the pipeline but unfortunately, it is not that easy for me to switch to a more recent version of FreeBSD. This box is out in the wild and is certainly being attacked by random port/scanning/worms traffic. I was wondering if there might be someone that would remember having a similar experience back on 4.x. From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 16:19:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A14116A418 for ; Sun, 27 Jan 2008 16:19:49 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id C310013C46E for ; Sun, 27 Jan 2008 16:19:48 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 215371B10EE7; Sun, 27 Jan 2008 17:19:47 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 5D27A1B10EDC; Sun, 27 Jan 2008 17:19:44 +0100 (CET) Message-ID: <479CAF1F.4010900@moneybookers.com> Date: Sun, 27 Jan 2008 18:19:43 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: Vladimir Ivanov References: <46B07931.3080300@yandex-team.ru> <2a41acea0708010923m7b21095ajc2ee84c37e0d5354@mail.gmail.com> <470280F6.9070009@yandex-team.ru> <20071003111737.U14276@delplex.bde.org> <47037246.2070400@yandex-team.ru> <47040D83.9010706@delphij.net> <47200537.8070708@room52.net> <472028C0.4040004@delphij.net> <47220853.90206@yandex-team.ru> <20071214113434.GD63588@uafug.org.ua> <4762796B.3090608@yandex-team.ru> <479B5C27.2010201@moneybookers.com> <479BC043.8020007@yandex-team.ru> In-Reply-To: <479BC043.8020007@yandex-team.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5574/Sun Jan 27 11:03:42 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: "freebsd-net@freebsd.org" Subject: Re: SMPable version of EM driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 16:19:49 -0000 Hi Vladimir, Vladimir Ivanov wrote: > Hi, Stefan > > Stefan Lambrev wrote: >> Hi Vladimir, >> >> Will http://people.yandex-team.ru/~wawa/em-6.7.3-yandex-1.28.tar.gz >> work out of the box on FreeBSD 7, or it's just for 6.X? > We use (and debug) it w/RELENG_6. I seem it can be used w/CURRENT but > I didn't test it yet. > Also, pls use 1.30 revision instead (I've fixed rare stuck condition > in txirq-less code). I'm unable to get this driver working under releng_7_0. It builds without problems but panic my machine when I load it. May be I'll wait until you have "official" version for FreeBSD 7.0 or changes get merged into Intel's driver :) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 06:09:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9572B16A417 for ; Mon, 28 Jan 2008 06:09:02 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 5FF4B13C507 for ; Mon, 28 Jan 2008 06:09:02 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2835579waf.3 for ; Sun, 27 Jan 2008 22:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=8YC7yjU3+ZI5VoYNwvDa4jnfUEtMZFw4eyIqOsn7/F8=; b=tMs/EST17Wvs78m00LQaKbTk5xBBbwpUBlhRAbI4AQaLrOMK0e82vaNNoOPj2djpKGGRXc5/9AINEGS3rVhb4dB2TfJ68ayXc4u+PdvC/nsAK8VId9Jc8hBvfCJTLz6sUhF9qvk3xOwcs/M6FYGbqr7RO0CwF+wtwMN/LhxWCH0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=hRig5N9HWZhQznI14GYOHA25OqYvZT4HiWLXQaNtwDzykAlvamQosfsiVZQ0nhkFQNqjOGhQlNADXneMKS7fRxS6hf8fzEIIuERyNbDncaXVxubxzG03kKmM2qnDQ9tD02K9P2oEVTxcqSd+wRXFsXpotJ0VrxOX4GfMa6NSNhU= Received: by 10.114.78.1 with SMTP id a1mr983988wab.14.1201500541746; Sun, 27 Jan 2008 22:09:01 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id j29sm10783780waf.18.2008.01.27.22.08.58 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Jan 2008 22:09:00 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m0S68sh7002085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jan 2008 15:08:54 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m0S68s7n002084; Mon, 28 Jan 2008 15:08:54 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 28 Jan 2008 15:08:54 +0900 From: Pyun YongHyeon To: Yousif Hassan Message-ID: <20080128060854.GA1240@cdnetworks.co.kr> References: <1201125022.2106.67.camel@localhost> <20080123222047.GA14264@lor.one-eyed-alien.net> <1201190313.2591.7.camel@localhost> <20080124163634.GA25331@lor.one-eyed-alien.net> <1201198042.19736.5.camel@localhost> <20080125051059.GA22410@cdnetworks.co.kr> <1201275694.1537.13.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201275694.1537.13.camel@localhost> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, Brooks Davis , "Bruce M. Simpson" Subject: Re: network interface monitoring? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2008 06:09:02 -0000 On Fri, Jan 25, 2008 at 10:41:34AM -0500, Yousif Hassan wrote: > Hi Pyun YongHyeon, > > First, I'd like to say thank you for sending this and trying to resolve > my (and others') problems with bfe driver. > > First the good news - your patch appears to solve nearly all of the > issues I've discovered and/or reported. After installing the kernel > with your patch, under normal circumstances, link up and down events are > detected automatically by the kernel now, and passed to userland. I > tested this with some customd devd scripts to make sure the devd > notification from if_net.c was ok, and it was. This is greatly improved > behavior! > > A couple minor nits - > > First: The first hunk out of the first file in the patch didn't apply > cleanly for me but it could be because I'm on a different file revision? > I'll attach the .rej file. It's no big deal, because it was trivial to > adjust it by hand, then I was able to compile. > > Second: There's one last remaining issue. If I set the bfe0_enable > parameter in rc.conf to "DHCP NOAUTO" (so that it doesn't try to do > anything on boot, because it can slow the process down while it's > negotiating an address), then the link state changes get queued up (as > before) until I manually run ifconfig once. After that one time, > everything from that point on is fine (meaning your changes are > working). For all I know, this might be unrelated to your driver patch, > but it was interesting. Setting the bfe0_enable to "DHCP" meant > everything worked fine from the start. Setting it to "UP" also was fine > in terms of your link state changes working (although in this > case /etc/rc.d/dhclient script won't work because the interface needs to > be configured in rc.conf to use DHCP; I must run "/sbin/dhclient bfe0" > manually in that case). > I guess that is not related with link state handling of bfe(4). I'll commit the change to HEAD. > In all cases, THANK YOU - this is much much much better than before and > I can live with using bfe0_enable="DHCP" instead of "DHCP NOAUTO". Feel > free to ask me for more testing if you want to try and investigate the > one remaining queue issue. > Thanks for testing and feedback! > --Yousif > > On Fri, 2008-01-25 at 14:10 +0900, Pyun YongHyeon wrote: > > On Thu, Jan 24, 2008 at 01:07:22PM -0500, Yousif Hassan wrote: > > > On Thu, 2008-01-24 at 10:36 -0600, Brooks Davis wrote: > > > > On Thu, Jan 24, 2008 at 10:58:33AM -0500, Yousif Hassan wrote: > > > > > Thank you to all who responded. > > > > > > > > > > The suggestion was made to use devd or ifstated. Both sound like > > > > > excellent tools, but I'm currently being tripped up by a core problem - > > > > > both tools rely on the kernel to notify userland of link state changes > > > > > (which makes complete sense!). This is all well and good - but the > > > > > current issue I'm seeing is that the link state doesn't get updated > > > > > without running "ifconfig" again - is this by design? A known "issue?" > > > > > > > > > > An example: > > > > > 1. Unplug network cable from bfe0 > > > > > 2. I run ifconfig > > > > > 3. I see that interface bfe0's status is "no carrier". Good. > > > > > 4. I plug the cable into bfe0 > > > > > 5. Wait... wait... look in /var/log/messages... wait more.. NO STATE > > > > > CHANGE - the longest I've waited was 2 minutes, which is already too > > > > > long > > > > > 6. run "ifconfig" again > > > > > 7. Link state immediately changes, logs to /var/log/messages, devd > > > > > scripts run > > > > > > > > > > Is this a known behavior? It seems like the link state changes should > > > > > happen automatically, without something to "trigger" them. Isn't there > > > > > some kind of poll or interrupt sequence? I'm on 6.3 RC2 (will upgrade > > > > > to 6.3-RELEASE imminently) but can't imagine this code changed? Does > > > > > this work differently/better in 7.0? > > > > > > > > It's known but not well understood and is a driver bug. > > > > > > I was afraid you'd say that. Thanks for the info. > > > > > > I found PR kern/109733: [bge] bge link state issues (regression) > > > which, while referring to a different driver, has some of the same > > > symptoms. > > > > > > In the meantime, I scripted something that calls ifconfig every 30 > > > seconds or so, redirected its output to null, and put it in the > > > background and nice'd it; this seems to do the trick, albeit via a > > > horrid hack. Due to the bug you mentioned, sometimes link state events > > > queue up, too, and get passed to userland at once, which is no kind of > > > fun, but the script still works. > > > > > > > Try attached patch. I don't know whether it works or not but it > > seems that link state was not correctly tracked down by stock bfe(4). > > The attached patch does the following. > > - conversion to callout(9) API. > > - added missing lock in bfe_ifmedia_sts(). > > - implemented miibus_statchg method to track link state. > > - use our callout to drive watchdog timer. > > - restart Tx routine if pending queued packets are present in > > watchdog handler. > > - fixed blindly resetting watchdog timer in bfe_txeof(). > > > > I guess the above is minimal patch to get correct link state. > > If I had the hardware I would have rewritten bfe_encap/bfe_newbuf > > to use bus_dmamap_load_mbuf_sg(9). :( > > -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 09:46:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9388616A417 for ; Mon, 28 Jan 2008 09:46:32 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id F00BA13C4CC for ; Mon, 28 Jan 2008 09:46:31 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 90414 invoked from network); 28 Jan 2008 09:07:02 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 28 Jan 2008 09:07:02 -0000 Message-ID: <479DA47C.6090905@freebsd.org> Date: Mon, 28 Jan 2008 10:46:36 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Maxim Konovalov References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> <47988A2A.5010506@freebsd.org> <20080124164704.X15031@mp2.macomnet.net> <47989E3C.4030700@freebsd.org> <20080124171957.N15031@mp2.macomnet.net> <20080125073623.F15031@mp2.macomnet.net> <479A7B55.6050302@freebsd.org> <20080126132516.I15031@mp2.macomnet.net> In-Reply-To: <20080126132516.I15031@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2008 09:46:32 -0000 Maxim Konovalov wrote: >>> http://maxim.int.ru/stuff/adsl.dmp.gz >>> >>> 192.168.1.1 -- adsl box >>> 192.168.1.250 -- FreeBSD >> The trace looks perfectly fine with regard to timestamps. They are >> sent and properly reflected by the adsl box. Everything else looks >> fine too. No anomalies seen. >> >> The syncache check for timestamps wouldn't be triggered anyway >> because it only applies to incoming connections. Not segments in >> general. Connections initiated by the FreeBSD box never go through >> syncache. >> >> To track down the problem you saw back then, which is very probably >> unrelated to the syncache issue, I would need a trace of a failed >> connection. For that you need to downgrade. If you can find time >> for the downgrade I'm happy to find the root cause. >> > I find a kernel from September sitting in /boot. There are two new > dumps now: > > http://maxim.int.ru/stuff/adsl.failed.dmp.gz > > The adsl router displays login page but never returns the second page. Timestamps are fine. The problem seems to be related to the window scale option. The adsl router advertises support of the window scale option but doesn't make use of it (wcale=1) itself. FreeBSD sends a wscale of 8 (multiply by 256). Two things seem to go wrong on the adsl router. First it *seems* to divide the value in the tcp headers window size field by 256 instead of multiplying it (could be a byte order issue). That's why it stalls. It thinks the socket buffer on FreeBSD is full and has insufficient space for the next segment it wants to send. Second it then *seems* to try to do window probes (which are correctly answered by FreeBSD). The window probes aren't correct either as they do not contain the one byte payload that should accompany them. The sequence number of the pseudo window probe is one below snd_nxt on top of it too (a retransmit of an already ACK'd byte). The TCP implementation of the adsl router (Asustek by the MAC address) looks like it is really broken and incomplete in multiple ways. I'd say its socket buffers work segment based and it can't split up an already created segment when the target window is too small. The fault really lies at the adsl router choking on the larger window scale. It'll fall over with Windows Vista too which also started using larger wscale values. It would have been better if the router didn't even advertise wscale in its SYN as it doesn't use it itself and implements it completely wrong. Newer FreeBSD kernels work again because Silby changed the way our wscale in computed. Previously it was scaled as high as possible while retaining the smallest allowable MSS as smallest granularity. Now it is scaled as high as necessary to fit the largest allowed socket buffer as defined by kern.ipc.maxsockbuf. The scale factor is now 3 (multiply by 8) and doesn't through the adsl modem as far off as 8 does. Who's fault is it? Clearly the adsl modem. It's tcp is utterly broken. Should FreeBSD work around it? In this case I don't think so. Normally yes if it is an edge case in a specification or some generally made mistake. This is not the case with the adsl modem. It's really broken and in complete disregard of even the basic standards. The vendor should fix it, not us work around it. > http://maxim.int.ru/stuff/adsl.rfc1323=0.dmp.gz > > This one works. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 11:06:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0E3C16A4A7; Mon, 28 Jan 2008 11:06:27 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 5356813C459; Mon, 28 Jan 2008 11:06:26 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id m0SB6Pbc062589; Mon, 28 Jan 2008 14:06:25 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Mon, 28 Jan 2008 14:06:25 +0300 (MSK) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <479DA47C.6090905@freebsd.org> Message-ID: <20080128140354.Y29850@mp2.macomnet.net> References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> <47988A2A.5010506@freebsd.org> <20080124164704.X15031@mp2.macomnet.net> <47989E3C.4030700@freebsd.org> <20080124171957.N15031@mp2.macomnet.net> <20080125073623.F15031@mp2.macomnet.net> <479A7B55.6050302@freebsd.org> <20080126132516.I15031@mp2.macomnet.net> <479DA47C.6090905@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2008 11:06:27 -0000 [...] > Who's fault is it? Clearly the adsl modem. It's tcp is utterly > broken. Should FreeBSD work around it? In this case I don't think > so. Normally yes if it is an edge case in a specification or some > generally made mistake. This is not the case with the adsl modem. > It's really broken and in complete disregard of even the basic > standards. The vendor should fix it, not us work around it. > It used to work for years and works now. I see no point to make FreeBSD to not work with countless devices around the world. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 11:07:06 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB06F16A498 for ; Mon, 28 Jan 2008 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A843C13C468 for ; Mon, 28 Jan 2008 11:07:06 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0SB765E016398 for ; Mon, 28 Jan 2008 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0SB76rB016394 for freebsd-net@FreeBSD.org; Mon, 28 Jan 2008 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Jan 2008 11:07:06 GMT Message-Id: <200801281107.m0SB76rB016394@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2008 11:07:06 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue f kern/62374 net panic: free: multiple frees s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash (regression) o kern/118880 net [ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem f kern/119548 net [pf] [ath] [patch] PF Altq with ath hostap problem 32 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands f kern/118722 net [tcp] Many old TCP connections in SYN_RCVD state o kern/118727 net [ng] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118975 net [bge] [patch] Broadcom 5906 not handled by FreeBSD o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol 22 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 13:41:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AA1016A41A for ; Mon, 28 Jan 2008 13:41:31 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8BFA113C442 for ; Mon, 28 Jan 2008 13:41:30 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 98845 invoked from network); 28 Jan 2008 13:01:59 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 28 Jan 2008 13:01:59 -0000 Message-ID: <479DDB8E.1040504@freebsd.org> Date: Mon, 28 Jan 2008 14:41:34 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Maxim Konovalov References: <200711200656.lAK6u4bc021279@repoman.freebsd.org> <4797B77E.2090605@freebsd.org> <20080124005006.D93697@odysseus.silby.com> <47986F27.10401@freebsd.org> <20080124145713.K15031@mp2.macomnet.net> <47988A2A.5010506@freebsd.org> <20080124164704.X15031@mp2.macomnet.net> <47989E3C.4030700@freebsd.org> <20080124171957.N15031@mp2.macomnet.net> <20080125073623.F15031@mp2.macomnet.net> <479A7B55.6050302@freebsd.org> <20080126132516.I15031@mp2.macomnet.net> <479DA47C.6090905@freebsd.org> <20080128140354.Y29850@mp2.macomnet.net> In-Reply-To: <20080128140354.Y29850@mp2.macomnet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2008 13:41:31 -0000 Maxim Konovalov wrote: > [...] >> Who's fault is it? Clearly the adsl modem. It's tcp is utterly >> broken. Should FreeBSD work around it? In this case I don't think >> so. Normally yes if it is an edge case in a specification or some >> generally made mistake. This is not the case with the adsl modem. >> It's really broken and in complete disregard of even the basic >> standards. The vendor should fix it, not us work around it. >> > It used to work for years and works now. I see no point to make > FreeBSD to not work with countless devices around the world. In this case the issue was fixed by changing the window scaling algorithm because many stateful firewalls get this wrong too (configuration problem by not tracking the initial SYN with the wscale parameter). Otherwise I don't agree that we have to bend over backwards to support a broken device that doesn't even implement the basic TCP RFCs remotely correct. I don't say we should brake it for the sake of braking it but if there are compelling and RFC compliant arguments *for* a change that breaks these totally non-compliant devices then so be it. Call your vendor and have them make it TCP RFC compliant. Here the simplest fix for their source code would be to just disable support of window scaling since it doesn't need it anyway. A compelling argument for a change may be support of higher speed links with high latency (like 100Mbit/s with 200ms). This time we were able to solve this issue in a compatible way (for the Asustek adsl router). The next it may not be so lucky. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 13:05:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A99FB16A419 for ; Tue, 29 Jan 2008 13:05:12 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id 67F4F13C478 for ; Tue, 29 Jan 2008 13:05:12 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so3018815pyb.10 for ; Tue, 29 Jan 2008 05:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=daZn4SqxrEUONu17ixaxqtgKqJzq25uk16BDYU7mCQU=; b=wtGn19qf2s/9Buu9h5332Z0zfkvj4CBQaWU//UU2KgHDzDjdw/l/3rGmGIIyFJhbKpShpmtct5rDvMCt1kUqZEE4OYiy2H7EbtNpzYf+ZBBA4/OjcrYIrauAXvSfEraWrNgYi3j+1xJLmgCcjC7lxZZVDQaPclu8XG38WrTAC9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=E4fTTUzkcGNlRHduQbQ+90cyfnrpVvNYEYknDMkw5xB9uHX6W9XkkEqTqblZHD3Y1iRa6qzNcLCIpT1ggEHt+j4nzxbUEBRMa3HdLa3w+kDulOLWdQh/XTtLru/J4MrwZm51wrTtFOoJ4W43JZSLjoRMnl1STi3GK3hh0jb/FTw= Received: by 10.65.54.9 with SMTP id g9mr14218736qbk.3.1201610371136; Tue, 29 Jan 2008 04:39:31 -0800 (PST) Received: by 10.64.184.9 with HTTP; Tue, 29 Jan 2008 04:39:31 -0800 (PST) Message-ID: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> Date: Tue, 29 Jan 2008 10:39:31 -0200 From: "Alexandre Biancalana" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 13:05:12 -0000 Hi list, I changed the company gateway implementing vlan concept and now I have a lot of slow and packet loss. I'm running FreeBSD FW1 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: Fri Jan 25 10:36:18 UTC 2008 root@FW1:/usr/obj/usr/src/sys/FW amd64 This server is an Dell Power Edge 1950, QuadCore 2.83, 2Gb Ram, one bce gigabit interface connected to a gigabit port of a Cisco 4500 in trunk mode. There are 10 vlans configured on top of bce1 interface. I made this change last night and with small traffic all was ok, but with the increase of the traffic during normal daily usage, we are experiencing too much packet loss and slow connections. I change the mtu of bce to 9000, this help something but I still have bad performance. I think that this could be related with mtu, but I don't know where and what to change. Googling around I found some references that said to test mtu with ping and here are the results: # ping -D -s 1473 192.168.0.5 PING 192.168.0.5 (192.168.0.5): 1473 data bytes ping: sendto: Message too long ping: sendto: Message too long --- 192.168.0.5 ping statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss # ping -D -s 1400 10.2.0.36 PING 10.2.0.36 (10.2.0.36): 1400 data bytes 1408 bytes from 10.2.0.36: icmp_seq=0 ttl=64 time=86.026 ms 1408 bytes from 10.2.0.36: icmp_seq=1 ttl=64 time=5.558 ms --- 10.2.0.36 ping statistics --- 3 packets transmitted, 2 packets received, 33% packet loss round-trip min/avg/max/stddev = 5.558/45.792/86.026/40.234 ms Looking at netstat -ni output I have output errors too: # netstat -niW Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll bce0* 1500 00:1d:09:67:8d:f1 0 0 0 0 0 bce1 9000 00:1d:09:67:8d:ef 83289870 0 80535996 0 0 pflog0 33160 0 0 1153529 0 0 lo0 16384 516657 0 516661 0 0 lo0 16384 127.0.0.0/8 127.0.0.1 4041401 - 516661 - - pfsync0 1460 0 0 0 0 0 vlan2 1500 00:1d:09:67:8d:ef 37445062 0 32727529 1047565 0 vlan2 1500 10.2.0.0/16 10.2.0.36 636786 - 3000823 - - vlan11 1500 00:1d:09:67:8d:ef 33865371 0 36676651 993848 0 vlan11 1500 10.11.0.0/16 10.11.0.1 51270 - 1147250 - - vlan16 1500 00:1d:09:67:8d:ef 388 0 19 0 0 vlan16 1500 10.16.0.0/24 10.16.0.1 5 - 13 - - vlan20 1500 00:1d:09:67:8d:ef 1483 0 1 0 0 vlan20 1500 10.20.0.0/24 10.20.0.1 636 - 0 - - vlan200 1500 00:1d:09:67:8d:ef 390 0 3 0 0 vlan200 1500 10.200.0.0/30 10.200.0.1 0 - 0 - - vlan201 1500 00:1d:09:67:8d:ef 19153 0 19274 3408 0 vlan201 1500 10.200.0.4/30 10.200.0.5 0 - 0 - - vlan202 1500 00:1d:09:67:8d:ef 8338 0 6694 1074 0 vlan202 1500 10.200.0.8/30 10.200.0.9 0 - 0 - - vlan203 1528 00:1d:09:67:8d:ef 1691886 0 1429174 86768 0 vlan203 1528 192.168.0.0/2 192.168.0.1 35672 - 31375 - - vlan204 1500 00:1d:09:67:8d:ef 1256 0 3 0 0 vlan204 1500 10.0.0.84/30 10.0.0.85 0 - 0 - - vlan205 1500 00:1d:09:67:8d:ef 10256373 0 9676750 626525 0 vlan205 1500 10.0.0.8/30 10.0.0.9 2509909 - 2667896 - - Any help is very appreciated, Regards, Alexandre Biancalana PS: Please cc me, because I'm not subscribed in the list. From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 13:10:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64B7916A417; Tue, 29 Jan 2008 13:10:25 +0000 (UTC) (envelope-from mel.xyzzy@rachie.is-a-geek.net) Received: from snoogles.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3461F13C4D5; Tue, 29 Jan 2008 13:10:25 +0000 (UTC) (envelope-from mel.xyzzy@rachie.is-a-geek.net) Received: from localhost (localhost [127.0.0.1]) by snoogles.rachie.is-a-geek.net (Postfix) with ESMTP id 7137C1CC8B; Tue, 29 Jan 2008 03:54:09 -0900 (AKST) From: Mel Organization: rachie.is-a-geek.net To: linimon@freebsd.org Date: Tue, 29 Jan 2008 13:53:46 +0100 User-Agent: KMail/1.9.7 References: <200801111744.m0BHiJ6m059337@freefall.freebsd.org> In-Reply-To: <200801111744.m0BHiJ6m059337@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801291353.47509.mel@rachie.is-a-geek.net> Cc: freebsd-net@freebsd.org Subject: Re: kern/119548: [pf] [ath] [patch] PF Altq with ath hostap problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 13:10:25 -0000 On Friday 11 January 2008 18:44:19 linimon@freebsd.org wrote: > Old Synopsis: [pf] [ath] PF Altq with ath hostap problem > New Synopsis: [pf] [ath] [patch] PF Altq with ath hostap problem > > State-Changed-From-To: open->feedback > State-Changed-By: linimon > State-Changed-When: Fri Jan 11 17:43:47 UTC 2008 > State-Changed-Why: > To submitter: a patch has been created, can you give it a try please? Sure, where is it? -- Mel From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 14:55:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A010616A41A for ; Tue, 29 Jan 2008 14:55:03 +0000 (UTC) (envelope-from steinarl@stud.ntnu.no) Received: from bene1.itea.ntnu.no (bene1.itea.ntnu.no [IPv6:2001:700:300:3::56]) by mx1.freebsd.org (Postfix) with ESMTP id 245D613C467 for ; Tue, 29 Jan 2008 14:55:02 +0000 (UTC) (envelope-from steinarl@stud.ntnu.no) Received: from localhost (localhost [127.0.0.1]) by bene1.itea.ntnu.no (Postfix) with ESMTP id 193E03E24D for ; Tue, 29 Jan 2008 15:55:01 +0100 (CET) Received: from webmail.ntnu.no (textus12.itea.ntnu.no [129.241.56.162]) by bene1.itea.ntnu.no (Postfix) with ESMTP id C08FF3E23E for ; Tue, 29 Jan 2008 15:54:53 +0100 (CET) Received: from kybpc555.ad.ime.ntnu.no (kybpc555.ad.ime.ntnu.no [129.241.187.195]) by webmail.ntnu.no (Horde MIME library) with HTTP; Tue, 29 Jan 2008 15:54:53 +0100 Message-ID: <20080129155453.xg5ikocw0w8k8g8w@webmail.ntnu.no> Date: Tue, 29 Jan 2008 15:54:53 +0100 From: steinarl@stud.ntnu.no To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.5) X-Virus-Scanned: Debian amavisd-new at bene1.itea.ntnu.no Subject: Diffserv implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 14:55:03 -0000 Hi, I am looking for the implementation of Diffserv in the current version of FreeBSD. Can anyone give me a brief overview of which parts of the source I should look at? Regards, Steinar Lieng Fredriksen From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 15:54:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5889416A417 for ; Tue, 29 Jan 2008 15:54:39 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id EC72313C4CC for ; Tue, 29 Jan 2008 15:54:38 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from localhost (localhost [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 2161D34197; Tue, 29 Jan 2008 15:54:37 +0000 (GMT) Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+BRBy5vAABG; Tue, 29 Jan 2008 15:54:36 +0000 (GMT) Received: from [192.168.255.6] (unknown [192.168.255.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 7553F34098; Tue, 29 Jan 2008 15:54:36 +0000 (GMT) Message-ID: <479F4C3C.5070801@tomjudge.com> Date: Tue, 29 Jan 2008 15:54:36 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Alexandre Biancalana References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> In-Reply-To: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 15:54:39 -0000 Alexandre Biancalana wrote: > Hi list, > > I changed the company gateway implementing vlan concept and now I > have a lot of slow and packet loss. > > I'm running FreeBSD FW1 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: > Fri Jan 25 10:36:18 UTC 2008 root@FW1:/usr/obj/usr/src/sys/FW > amd64 > > This server is an Dell Power Edge 1950, QuadCore 2.83, 2Gb Ram, one > bce gigabit interface connected to a gigabit port of a Cisco 4500 in > trunk mode. There are 10 vlans configured on top of bce1 interface. I > made this change last night and with small traffic all was ok, but > with the increase of the traffic during normal daily usage, we are > experiencing too much packet loss and slow connections. > > I change the mtu of bce to 9000, this help something but I still > have bad performance. I think that this could be related with mtu, but > I don't know where and what to change. I have seen some problems if you try to run more than one MTU on different VLANS with the same parent interface. For example if you set the parent interface MTU and vlan1 to 9000 and then tried to change vlan2 to have a 1500 byte mtu then the change of mtuon the vlan would also change the mtu on the parent. If you are not running jumbo frames or nested vlans I don't think that changing the mtu of the interface is going to help you. The output of ifconfig would also help people give you more help with this. Tom > > Googling around I found some references that said to test mtu with > ping and here are the results: > > # ping -D -s 1473 192.168.0.5 > PING 192.168.0.5 (192.168.0.5): 1473 data bytes > ping: sendto: Message too long > ping: sendto: Message too long > --- 192.168.0.5 ping statistics --- > 6 packets transmitted, 0 packets received, 100.0% packet loss > > # ping -D -s 1400 10.2.0.36 > PING 10.2.0.36 (10.2.0.36): 1400 data bytes > 1408 bytes from 10.2.0.36: icmp_seq=0 ttl=64 time=86.026 ms > 1408 bytes from 10.2.0.36: icmp_seq=1 ttl=64 time=5.558 ms > --- 10.2.0.36 ping statistics --- > 3 packets transmitted, 2 packets received, 33% packet loss > round-trip min/avg/max/stddev = 5.558/45.792/86.026/40.234 ms > > > Looking at netstat -ni output I have output errors too: > > # netstat -niW > Name Mtu Network Address Ipkts Ierrs Opkts > Oerrs Coll > bce0* 1500 00:1d:09:67:8d:f1 0 0 0 > 0 0 > bce1 9000 00:1d:09:67:8d:ef 83289870 0 80535996 > 0 0 > pflog0 33160 0 0 1153529 > 0 0 > lo0 16384 516657 0 516661 > 0 0 > lo0 16384 127.0.0.0/8 127.0.0.1 4041401 - 516661 > - - > pfsync0 1460 0 0 0 > 0 0 > vlan2 1500 00:1d:09:67:8d:ef 37445062 0 32727529 > 1047565 0 > vlan2 1500 10.2.0.0/16 10.2.0.36 636786 - 3000823 > - - > vlan11 1500 00:1d:09:67:8d:ef 33865371 0 36676651 > 993848 0 > vlan11 1500 10.11.0.0/16 10.11.0.1 51270 - 1147250 > - - > vlan16 1500 00:1d:09:67:8d:ef 388 0 19 > 0 0 > vlan16 1500 10.16.0.0/24 10.16.0.1 5 - 13 > - - > vlan20 1500 00:1d:09:67:8d:ef 1483 0 1 > 0 0 > vlan20 1500 10.20.0.0/24 10.20.0.1 636 - 0 > - - > vlan200 1500 00:1d:09:67:8d:ef 390 0 3 > 0 0 > vlan200 1500 10.200.0.0/30 10.200.0.1 0 - 0 > - - > vlan201 1500 00:1d:09:67:8d:ef 19153 0 19274 > 3408 0 > vlan201 1500 10.200.0.4/30 10.200.0.5 0 - 0 > - - > vlan202 1500 00:1d:09:67:8d:ef 8338 0 6694 > 1074 0 > vlan202 1500 10.200.0.8/30 10.200.0.9 0 - 0 > - - > vlan203 1528 00:1d:09:67:8d:ef 1691886 0 1429174 > 86768 0 > vlan203 1528 192.168.0.0/2 192.168.0.1 35672 - 31375 > - - > vlan204 1500 00:1d:09:67:8d:ef 1256 0 3 > 0 0 > vlan204 1500 10.0.0.84/30 10.0.0.85 0 - 0 > - - > vlan205 1500 00:1d:09:67:8d:ef 10256373 0 9676750 > 626525 0 > vlan205 1500 10.0.0.8/30 10.0.0.9 2509909 - 2667896 > - - > > > Any help is very appreciated, > > Regards, > Alexandre Biancalana > > PS: Please cc me, because I'm not subscribed in the list. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 16:30:08 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5053F16A417 for ; Tue, 29 Jan 2008 16:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 40E0613C46A for ; Tue, 29 Jan 2008 16:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0TGU34T061528 for ; Tue, 29 Jan 2008 16:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0TGU3Sa061522; Tue, 29 Jan 2008 16:30:03 GMT (envelope-from gnats) Date: Tue, 29 Jan 2008 16:30:03 GMT Message-Id: <200801291630.m0TGU3Sa061522@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Mel Cc: Subject: Re: kern/119548: [pf] [ath] [patch] PF Altq with ath hostap problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 16:30:08 -0000 The following reply was made to PR kern/119548; it has been noted by GNATS. From: Mel To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/119548: [pf] [ath] [patch] PF Altq with ath hostap problem Date: Tue, 29 Jan 2008 17:04:42 +0100 On Friday 11 January 2008 18:44:19 linimon@freebsd.org wrote: > Old Synopsis: [pf] [ath] PF Altq with ath hostap problem > New Synopsis: [pf] [ath] [patch] PF Altq with ath hostap problem > > State-Changed-From-To: open->feedback > State-Changed-By: linimon > State-Changed-When: Fri Jan 11 17:43:47 UTC 2008 > State-Changed-Why: > To submitter: a patch has been created, can you give it a try please? Sure, where is it? -- Mel From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 16:42:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9A6216A41A for ; Tue, 29 Jan 2008 16:42:40 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 72C5B13C44B for ; Tue, 29 Jan 2008 16:42:40 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so3094743pyb.10 for ; Tue, 29 Jan 2008 08:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=bn4OM2mtPZtHaIhrjux5VfmrdyCisGhaTc7dezN7JH8=; b=QVDNTbirOBrAzOKh4LH+xCAWEO4jzjAcVQ1VOWZAUhiqBiuPpMfBnfYOkiydM0P6oOeUBaWfwftK1N/o+HG6eADHDzdRT9nCvpMxvZvMkv1qTRSzdXzXPivGKS2oMg5cDe2kXqXbUnbLPOFy+/7M7GBmqZYm+3OjKkANSGaytak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ccUWfNIAWYy1r4IDZWlwdS8Yaxv/mT0vjx+5bXyMyGdKEu7RJ/58Cs+3LhU8FoGUPgOp5+nColBhezLpRS/g3RYe3k27vDZT+GZNh9N76ck3gNIJM+fCJiaA2OaJ+9GpOuGq4GxkxqKSNPqusy0xMw11gGiSnTD/j8dXlASMTIM= Received: by 10.65.81.10 with SMTP id i10mr14617257qbl.75.1201624959162; Tue, 29 Jan 2008 08:42:39 -0800 (PST) Received: by 10.64.184.9 with HTTP; Tue, 29 Jan 2008 08:42:39 -0800 (PST) Message-ID: <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> Date: Tue, 29 Jan 2008 14:42:39 -0200 From: "Alexandre Biancalana" To: "Tom Judge" In-Reply-To: <479F4C3C.5070801@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 16:42:40 -0000 Hi Tom ! Thanks for your help! I had to step back the chance an put the "old" gateway back, the performance was unacceptable :-( Looking closer I see that still have the problem using the old gateway too, in a small scale because I only use vlan to external links. This old gateway is running 6.2-STABLE and have 4 network interfaces: fxp0, fxp1, sk0 and sk1. fxp0, sk0 and sk1 are no parent of any vlans, are connected to internal networks and work without problems, follow the ifconfig ouput: fxp0: flags=8843 mtu 1500 options=8 inet 10.11.0.1 netmask 0xffff0000 broadcast 10.11.255.255 ether 00:02:a5:41:c6:b2 media: Ethernet autoselect (100baseTX ) status: active sk0: flags=8843 mtu 1500 options=b inet 10.2.0.36 netmask 0xffff0000 broadcast 10.2.255.255 ether 00:0a:5e:5c:9e:2e media: Ethernet autoselect (1000baseTX ) status: active sk1: flags=8843 mtu 1500 options=b inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:0a:5e:5c:27:ef media: Ethernet autoselect (100baseTX ) status: active fxp1 is parent of 7 vlan interfaces: vlan16, vlan20, vlan200, vlan201, vlan202 and vlan205 that connect my internal network to some external links, follow the ifconfig output: vlan16: flags=8843 mtu 1500 inet 10.16.0.1 netmask 0xffffff00 broadcast 10.16.0.255 ether 00:0c:f1:ac:91:09 media: Ethernet autoselect (100baseTX ) status: active vlan: 16 parent interface: fxp1 vlan20: flags=8843 mtu 1500 inet 10.20.0.1 netmask 0xffffff00 broadcast 10.20.0.255 ether 00:0c:f1:ac:91:09 media: Ethernet autoselect (100baseTX ) status: active vlan: 20 parent interface: fxp1 vlan200: flags=8843 mtu 1500 inet 10.200.0.1 netmask 0xfffffffc broadcast 10.200.0.3 ether 00:0c:f1:ac:91:09 media: Ethernet autoselect (100baseTX ) status: active vlan: 200 parent interface: fxp1 vlan201: flags=8843 mtu 1500 inet 10.200.0.5 netmask 0xfffffffc broadcast 10.200.0.7 ether 00:0c:f1:ac:91:09 media: Ethernet autoselect (100baseTX ) status: active vlan: 201 parent interface: fxp1 vlan202: flags=8843 mtu 1500 inet 10.200.0.9 netmask 0xfffffffc broadcast 10.200.0.11 ether 00:0c:f1:ac:91:09 media: Ethernet autoselect (100baseTX ) status: active vlan: 202 parent interface: fxp1 vlan204: flags=8843 mtu 1500 inet 10.0.0.85 netmask 0xfffffffc broadcast 10.0.0.87 ether 00:0c:f1:ac:91:09 media: Ethernet autoselect (100baseTX ) status: active vlan: 204 parent interface: fxp1 vlan205: flags=8943 mtu 1500 inet 10.0.0.9 netmask 0xfffffffc broadcast 10.0.0.11 ether 00:0c:f1:ac:91:09 media: Ethernet autoselect (100baseTX ) status: active Like seen before netstat -niW show output errors in vlan interfaces # netstat -niW Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll fxp0 1500 00:02:a5:41:c6:b2 80737726 0 93763586 0 0 fxp0 1500 10.11/16 10.11.0.1 39361 - 781153 - - sk0 1500 00:0a:5e:5c:9e:2e 95954343 3 85444921 0 0 sk0 1500 10.2/16 10.2.0.36 1504482 - 2626656 - - sk1 1500 00:0a:5e:5c:27:ef 7852065 0 5623251 0 0 sk1 1500 192.168.0 192.168.0.1 22824 - 16590 - - fxp1 1500 00:0c:f1:ac:91:09 9790593 0 9423268 1 0 lo0 16384 2519 0 2519 0 0 lo0 16384 127 127.0.0.1 1592519 - 2519 - - vlan2* 1500 00:00:00:00:00:00 0 0 0 0 0 vlan11* 1500 00:00:00:00:00:00 0 0 0 0 0 vlan16 1500 00:0c:f1:ac:91:09 1369 0 1 0 0 vlan16 1500 10.16/24 10.16.0.1 0 - 0 - - vlan20 1500 00:0c:f1:ac:91:09 0 0 1 0 0 vlan20 1500 10.20/24 10.20.0.1 0 - 0 - - vlan200 1500 00:0c:f1:ac:91:09 1373 0 1 0 0 vlan200 1500 10.200/30 10.200.0.1 0 - 0 - - vlan201 1500 00:0c:f1:ac:91:09 53524 0 52234 63 0 vlan201 1500 10.200.0.4/30 10.200.0.5 0 - 0 - - vlan202 1500 00:0c:f1:ac:91:09 5907 0 4421 4 0 vlan202 1500 10.200.0.8/30 10.200.0.9 0 - 0 - - vlan203 1500 00:00:00:00:00:00 0 0 0 0 0 vlan204 1500 00:0c:f1:ac:91:09 1459 0 1 0 0 vlan204 1500 10.0.0.84/30 10.0.0.85 0 - 0 - - vlan205 1500 00:0c:f1:ac:91:09 9728659 0 9373148 87025 0 vlan205 1500 10.0.0.8/30 10.0.0.9 2453956 - 2417754 - - tun0 1450 0 0 0 0 0 tun0 1450 10 10.169.1.2 0 - 0 - - (the vlan205 is the most used and the output error is increasing...) Trying to ping with no fragmentation flag a packet bigger than 1472 bytes throught vlan205 give me the message "Message too long" # ping -D -s 1472 10.0.0.10 PING 10.0.0.10 (10.0.0.10): 1472 data bytes 1480 bytes from 10.0.0.10: icmp_seq=0 ttl=255 time=5.199 ms 1480 bytes from 10.0.0.10: icmp_seq=1 ttl=255 time=4.905 ms 1480 bytes from 10.0.0.10: icmp_seq=2 ttl=255 time=5.036 ms ^C --- 10.0.0.10 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.905/5.047/5.199/0.120 ms # ping -D -s 1473 10.0.0.10 PING 10.0.0.10 (10.0.0.10): 1473 data bytes ping: sendto: Message too long ping: sendto: Message too long ping: sendto: Message too long ^C --- 10.0.0.10 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss Let me know if you need more information. Regards, Alexandre From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 17:01:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A11816A473 for ; Tue, 29 Jan 2008 17:01:32 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from rn-out-0102.google.com (rn-out-0910.google.com [64.233.170.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1386813C465 for ; Tue, 29 Jan 2008 17:01:31 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by rn-out-0102.google.com with SMTP id s42so281872rnb.13 for ; Tue, 29 Jan 2008 09:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LRtiNNbeAYMgb2gAr5oMMj4T6P1ddcemXIQZRK4aCXE=; b=YlOLTCH4wk6YjPtxnE13Z2vWCi55eEHpEonKK/FUZ5t9336hGDvUWaQVF/g/CCe0nF3gaY38EdhPkv+NVbIe9WXBa2usGgQY6WWk/YGrBA2JBKs/fTwlTzWBScJpxjSQsmSGluO19fzVsWR6v2wm4Hj654bfW32kAYuhh0pT4L0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fl/FSmkK8dpnn5x+3kI9R/rZvYHHHQJLIyXB3X2XSg+XkhGH3ehW0mgYtiYCc25PJkpLvNbytHS89STMvtg+vUqJo1zEeAu5MJeLP+7YDuNokm3APopLx/LtEB/pMjrzqUXwvqU2pxUvWaZMspv56whZMJTVeeN/ifHNoDuDFPY= Received: by 10.142.158.17 with SMTP id g17mr3434780wfe.106.1201626090535; Tue, 29 Jan 2008 09:01:30 -0800 (PST) Received: by 10.142.171.7 with HTTP; Tue, 29 Jan 2008 09:01:30 -0800 (PST) Message-ID: Date: Wed, 30 Jan 2008 01:01:30 +0800 From: "Sepherosa Ziehau" To: Mel In-Reply-To: <200801291353.47509.mel@rachie.is-a-geek.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801111744.m0BHiJ6m059337@freefall.freebsd.org> <200801291353.47509.mel@rachie.is-a-geek.net> Cc: freebsd-net@freebsd.org, linimon@freebsd.org Subject: Re: kern/119548: [pf] [ath] [patch] PF Altq with ath hostap problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 17:01:32 -0000 On Jan 29, 2008 8:53 PM, Mel wrote: > On Friday 11 January 2008 18:44:19 linimon@freebsd.org wrote: > > Old Synopsis: [pf] [ath] PF Altq with ath hostap problem > > New Synopsis: [pf] [ath] [patch] PF Altq with ath hostap problem > > > > State-Changed-From-To: open->feedback > > State-Changed-By: linimon > > State-Changed-When: Fri Jan 11 17:43:47 UTC 2008 > > State-Changed-Why: > > To submitter: a patch has been created, can you give it a try please? > > Sure, where is it? http://people.freebsd.org/~sephe/ieee80211_input.c.6_3.diff Best Regards, sephe -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 17:06:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB0216A41B for ; Tue, 29 Jan 2008 17:06:08 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 2792C13C442 for ; Tue, 29 Jan 2008 17:06:08 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from localhost (localhost [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id D3ADD34197; Tue, 29 Jan 2008 17:06:06 +0000 (GMT) Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Athu21DP638k; Tue, 29 Jan 2008 17:06:06 +0000 (GMT) Received: from [192.168.255.6] (unknown [192.168.255.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 69D6034098; Tue, 29 Jan 2008 17:06:05 +0000 (GMT) Message-ID: <479F5CFD.5040904@tomjudge.com> Date: Tue, 29 Jan 2008 17:06:05 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Alexandre Biancalana References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> In-Reply-To: <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 17:06:08 -0000 Alexandre Biancalana wrote: > Hi Tom ! Thanks for your help! > > I had to step back the chance an put the "old" gateway back, the > performance was unacceptable :-( Where these 2 systems connected to the same switch port and cabling? Could you post the interface error counters from the switch port? > > Looking closer I see that still have the problem using the old gateway > too, in a small scale because I only use vlan to external links. > > This old gateway is running 6.2-STABLE and have 4 network interfaces: > fxp0, fxp1, sk0 and sk1. > > fxp0, sk0 and sk1 are no parent of any vlans, are connected to > internal networks and work without problems, follow the ifconfig > ouput: > > fxp0: flags=8843 mtu 1500 > options=8 > inet 10.11.0.1 netmask 0xffff0000 broadcast 10.11.255.255 > ether 00:02:a5:41:c6:b2 > media: Ethernet autoselect (100baseTX ) > status: active > sk0: flags=8843 mtu 1500 > options=b > inet 10.2.0.36 netmask 0xffff0000 broadcast 10.2.255.255 > ether 00:0a:5e:5c:9e:2e > media: Ethernet autoselect (1000baseTX ) > status: active > sk1: flags=8843 mtu 1500 > options=b > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > ether 00:0a:5e:5c:27:ef > media: Ethernet autoselect (100baseTX ) > status: active > > fxp1 is parent of 7 vlan interfaces: vlan16, vlan20, vlan200, vlan201, > vlan202 and vlan205 that connect my internal network to some external > links, follow the ifconfig output: > > vlan16: flags=8843 mtu 1500 > inet 10.16.0.1 netmask 0xffffff00 broadcast 10.16.0.255 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 16 parent interface: fxp1 > vlan20: flags=8843 mtu 1500 > inet 10.20.0.1 netmask 0xffffff00 broadcast 10.20.0.255 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 20 parent interface: fxp1 > vlan200: flags=8843 mtu 1500 > inet 10.200.0.1 netmask 0xfffffffc broadcast 10.200.0.3 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 200 parent interface: fxp1 > vlan201: flags=8843 mtu 1500 > inet 10.200.0.5 netmask 0xfffffffc broadcast 10.200.0.7 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 201 parent interface: fxp1 > vlan202: flags=8843 mtu 1500 > inet 10.200.0.9 netmask 0xfffffffc broadcast 10.200.0.11 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 202 parent interface: fxp1 > vlan204: flags=8843 mtu 1500 > inet 10.0.0.85 netmask 0xfffffffc broadcast 10.0.0.87 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 204 parent interface: fxp1 > vlan205: flags=8943 mtu 1500 > inet 10.0.0.9 netmask 0xfffffffc broadcast 10.0.0.11 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > > Like seen before netstat -niW show output errors in vlan interfaces > > # netstat -niW > Name Mtu Network Address Ipkts Ierrs Opkts > Oerrs Coll > fxp0 1500 00:02:a5:41:c6:b2 80737726 0 93763586 > 0 0 > fxp0 1500 10.11/16 10.11.0.1 39361 - 781153 > - - > sk0 1500 00:0a:5e:5c:9e:2e 95954343 3 85444921 > 0 0 > sk0 1500 10.2/16 10.2.0.36 1504482 - 2626656 > - - > sk1 1500 00:0a:5e:5c:27:ef 7852065 0 5623251 > 0 0 > sk1 1500 192.168.0 192.168.0.1 22824 - 16590 > - - > fxp1 1500 00:0c:f1:ac:91:09 9790593 0 9423268 > 1 0 > lo0 16384 2519 0 2519 > 0 0 > lo0 16384 127 127.0.0.1 1592519 - 2519 > - - > vlan2* 1500 00:00:00:00:00:00 0 0 0 > 0 0 > vlan11* 1500 00:00:00:00:00:00 0 0 0 > 0 0 > vlan16 1500 00:0c:f1:ac:91:09 1369 0 1 > 0 0 > vlan16 1500 10.16/24 10.16.0.1 0 - 0 > - - > vlan20 1500 00:0c:f1:ac:91:09 0 0 1 > 0 0 > vlan20 1500 10.20/24 10.20.0.1 0 - 0 > - - > vlan200 1500 00:0c:f1:ac:91:09 1373 0 1 > 0 0 > vlan200 1500 10.200/30 10.200.0.1 0 - 0 > - - > vlan201 1500 00:0c:f1:ac:91:09 53524 0 52234 > 63 0 > vlan201 1500 10.200.0.4/30 10.200.0.5 0 - 0 > - - > vlan202 1500 00:0c:f1:ac:91:09 5907 0 4421 > 4 0 > vlan202 1500 10.200.0.8/30 10.200.0.9 0 - 0 > - - > vlan203 1500 00:00:00:00:00:00 0 0 0 > 0 0 > vlan204 1500 00:0c:f1:ac:91:09 1459 0 1 > 0 0 > vlan204 1500 10.0.0.84/30 10.0.0.85 0 - 0 > - - > vlan205 1500 00:0c:f1:ac:91:09 9728659 0 9373148 > 87025 0 > vlan205 1500 10.0.0.8/30 10.0.0.9 2453956 - 2417754 > - - > tun0 1450 0 0 0 > 0 0 > tun0 1450 10 10.169.1.2 0 - 0 > - - > > (the vlan205 is the most used and the output error is increasing...) > > Trying to ping with no fragmentation flag a packet bigger than 1472 > bytes throught vlan205 give me the message "Message too long" > > # ping -D -s 1472 10.0.0.10 > PING 10.0.0.10 (10.0.0.10): 1472 data bytes > 1480 bytes from 10.0.0.10: icmp_seq=0 ttl=255 time=5.199 ms > 1480 bytes from 10.0.0.10: icmp_seq=1 ttl=255 time=4.905 ms > 1480 bytes from 10.0.0.10: icmp_seq=2 ttl=255 time=5.036 ms > ^C > --- 10.0.0.10 ping statistics --- > 3 packets transmitted, 3 packets received, 0% packet loss > round-trip min/avg/max/stddev = 4.905/5.047/5.199/0.120 ms > # ping -D -s 1473 10.0.0.10 > PING 10.0.0.10 (10.0.0.10): 1473 data bytes > ping: sendto: Message too long > ping: sendto: Message too long > ping: sendto: Message too long > ^C > --- 10.0.0.10 ping statistics --- > 3 packets transmitted, 0 packets received, 100% packet loss > This error is because 1473 bytes as a pay load makes your icmp packet 1501 bytes long and you have set the do not fragment bit in the IP header so with an interface mtu of 1500 bytes this will not work. Tom From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 17:18:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A76AA16A41B for ; Tue, 29 Jan 2008 17:18:19 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6332613C50B for ; Tue, 29 Jan 2008 17:18:19 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so3107685pyb.10 for ; Tue, 29 Jan 2008 09:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=FQ9FcNKFWtu/JNDIsI3BGCPNaSsCGbOFyUmWZ9QDX2g=; b=Nlc+YSRY9gOaefOQ8CPCaG1mZ/LdBA+Ce51YFB1kpoeXV/n7VigvyxewtPnBKw2+BOKF4NHpy29OEnSdYH9Vp4HSLj2Y6xdsYNLetQk254r8lvmcFanhVm1b4kKDDyiLf5L7eYxlpgEcF00xHl+sX3wgPMM+MWb5ZTPTOydJpF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ABNzRcMhd4qJIR1HyQ6QwlwPmxiCwbuzhU+y5KuqPOoPtXUQr157YvunQupHNlI9bopyX6xJnvkV4BGt203jZiDF2D4eomR6MU104LnhLr/pf9B4oPI9B/WHN/S2M3d3QpBWybxbLoAqBPJgRIiTXNoyGvX+5iFHFqh/A2IQM0w= Received: by 10.65.44.5 with SMTP id w5mr14796043qbj.45.1201627097503; Tue, 29 Jan 2008 09:18:17 -0800 (PST) Received: by 10.64.184.9 with HTTP; Tue, 29 Jan 2008 09:18:17 -0800 (PST) Message-ID: <8e10486b0801290918l1a81e078sf4c539078e9138c7@mail.gmail.com> Date: Tue, 29 Jan 2008 15:18:17 -0200 From: "Alexandre Biancalana" To: "Tom Judge" In-Reply-To: <479F5CFD.5040904@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> <479F5CFD.5040904@tomjudge.com> Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 17:18:19 -0000 On 1/29/08, Tom Judge wrote: > Alexandre Biancalana wrote: > > Hi Tom ! Thanks for your help! > > > > I had to step back the chance an put the "old" gateway back, the > > performance was unacceptable :-( > > Where these 2 systems connected to the same switch port and cabling? > Could you post the interface error counters from the switch port? All the external links are connected to a 2950. The new gateway have only one gigabit ethernet interface connected to our 4506 core switch, that is parent of all vlans, in this case all the internal networks and external links are vlans. The parent interface of the vlans in the old gateway is connected to the same 2950. #sh interfaces fastEthernet 0/11 FastEthernet0/11 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 000b.be44.3ccb (bia 000b.be44.3ccb) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 10/255, rxload 5/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, media type is 100BaseTX input flow-control is unsupported output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 2032000 bits/sec, 865 packets/sec 5 minute output rate 4296000 bits/sec, 911 packets/sec 608489542 packets input, 3377246124 bytes, 0 no buffer Received 5492 broadcasts (0 multicast) 0 runts, 0 giants, 0 throttles 3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 595743491 packets output, 2124861910 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out > > This error is because 1473 bytes as a pay load makes your icmp packet > 1501 bytes long and you have set the do not fragment bit in the IP > header so with an interface mtu of 1500 bytes this will not work. Right, I'm just guessing.... because I don't understand why I start to lost packets when I enable all networks as vlans.... From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 18:36:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72F3116A418 for ; Tue, 29 Jan 2008 18:36:46 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id BF46313C44B for ; Tue, 29 Jan 2008 18:36:45 +0000 (UTC) (envelope-from if@xip.at) Received: (qmail 29798 invoked from network); 29 Jan 2008 19:10:02 +0100 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Jan 2008 19:10:02 +0100 Date: Tue, 29 Jan 2008 19:10:02 +0100 (CET) From: Ingo Flaschberger To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 18:36:46 -0000 Hi, linux does already support tcp-md5 checks for incomming connections, but freebsd not. I would like to implement this feature into freebsd. Any hints/wishes/considerations that I should consider? Kind regards, ingo flaschberger geschaeftsleitung --------------------------- netstorage-crossip-flat:fee powered by crossip communications gmbh --------------------------- sebastian kneipp gasse 1 a-1020 wien fix: +43-1-726 15 22-217 fax: +43-1-726 15 22-111 --------------------------- From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 19:20:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B73E16A419; Tue, 29 Jan 2008 19:20:45 +0000 (UTC) (envelope-from mel.xyzzy@rachie.is-a-geek.net) Received: from snoogles.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1460713C457; Tue, 29 Jan 2008 19:20:45 +0000 (UTC) (envelope-from mel.xyzzy@rachie.is-a-geek.net) Received: from localhost (localhost [127.0.0.1]) by snoogles.rachie.is-a-geek.net (Postfix) with ESMTP id 1B7371CC8B; Tue, 29 Jan 2008 10:20:44 -0900 (AKST) From: Mel To: "Sepherosa Ziehau" Date: Tue, 29 Jan 2008 20:20:41 +0100 User-Agent: KMail/1.9.7 References: <200801111744.m0BHiJ6m059337@freefall.freebsd.org> <200801291353.47509.mel@rachie.is-a-geek.net> In-Reply-To: Organization: rachie.is-a-geek.net MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801292020.42582.mel@rachie.is-a-geek.net> Cc: freebsd-net@freebsd.org, bug-followup@FreeBSD.org, linimon@freebsd.org Subject: Re: kern/119548: [pf] [ath] [patch] PF Altq with ath hostap problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 19:20:45 -0000 On Tuesday 29 January 2008 18:01:30 Sepherosa Ziehau wrote: > On Jan 29, 2008 8:53 PM, Mel wrote: > > On Friday 11 January 2008 18:44:19 linimon@freebsd.org wrote: > > > Old Synopsis: [pf] [ath] PF Altq with ath hostap problem > > > New Synopsis: [pf] [ath] [patch] PF Altq with ath hostap problem > > > > > > State-Changed-From-To: open->feedback > > > State-Changed-By: linimon > > > State-Changed-When: Fri Jan 11 17:43:47 UTC 2008 > > > State-Changed-Why: > > > To submitter: a patch has been created, can you give it a try please? > > > > Sure, where is it? > > http://people.freebsd.org/~sephe/ieee80211_input.c.6_3.diff Confirmed it fixes the problem. Thanks a bundle! -- Mel From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 19:30:02 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5B8B16A417 for ; Tue, 29 Jan 2008 19:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B452F13C4E3 for ; Tue, 29 Jan 2008 19:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0TJU2jg075185 for ; Tue, 29 Jan 2008 19:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0TJU2va075178; Tue, 29 Jan 2008 19:30:02 GMT (envelope-from gnats) Date: Tue, 29 Jan 2008 19:30:02 GMT Message-Id: <200801291930.m0TJU2va075178@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Mel Cc: Subject: Re: kern/119548: [pf] [ath] [patch] PF Altq with ath hostap problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 19:30:02 -0000 The following reply was made to PR kern/119548; it has been noted by GNATS. From: Mel To: "Sepherosa Ziehau" Cc: linimon@freebsd.org, freebsd-net@freebsd.org, bug-followup@FreeBSD.org Subject: Re: kern/119548: [pf] [ath] [patch] PF Altq with ath hostap problem Date: Tue, 29 Jan 2008 20:20:41 +0100 On Tuesday 29 January 2008 18:01:30 Sepherosa Ziehau wrote: > On Jan 29, 2008 8:53 PM, Mel wrote: > > On Friday 11 January 2008 18:44:19 linimon@freebsd.org wrote: > > > Old Synopsis: [pf] [ath] PF Altq with ath hostap problem > > > New Synopsis: [pf] [ath] [patch] PF Altq with ath hostap problem > > > > > > State-Changed-From-To: open->feedback > > > State-Changed-By: linimon > > > State-Changed-When: Fri Jan 11 17:43:47 UTC 2008 > > > State-Changed-Why: > > > To submitter: a patch has been created, can you give it a try please? > > > > Sure, where is it? > > http://people.freebsd.org/~sephe/ieee80211_input.c.6_3.diff Confirmed it fixes the problem. Thanks a bundle! -- Mel From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 19:38:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AAA216A418 for ; Tue, 29 Jan 2008 19:38:26 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id A5CE013C458 for ; Tue, 29 Jan 2008 19:38:25 +0000 (UTC) (envelope-from if@xip.at) Received: (qmail 9902 invoked from network); 29 Jan 2008 20:38:23 +0100 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Jan 2008 20:38:23 +0100 Date: Tue, 29 Jan 2008 20:38:23 +0100 (CET) From: Ingo Flaschberger To: freebsd-net@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 19:38:26 -0000 Hi, > linux does already support tcp-md5 checks for incomming connections, but > freebsd not. > > I would like to implement this feature into freebsd. > Any hints/wishes/considerations that I should consider? I have forgotten to mention, that there was already a patch for md5 check on incomming: http://arkiv.freebsd.se/?ml=freebsd-net&a=2004-04&m=116948 Can I start with this patch? Kind regards, Ingo Flaschberger From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 19:46:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC8C716A41A for ; Tue, 29 Jan 2008 19:46:49 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp807.mail.ird.yahoo.com (smtp807.mail.ird.yahoo.com [217.146.188.67]) by mx1.freebsd.org (Postfix) with SMTP id 4D76B13C4CC for ; Tue, 29 Jan 2008 19:46:49 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 52365 invoked from network); 29 Jan 2008 19:20:08 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.239.10 with plain) by smtp807.mail.ird.yahoo.com with SMTP; 29 Jan 2008 19:20:08 -0000 X-YMail-OSG: graJxVQVM1m1moBaqAcx6AODnjMt36DCox3aR9xWPYiSbkxsyAnfzBokZ90YvOpaYn_GMg36CA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <479F7C7A.5080605@tomjudge.com> Date: Tue, 29 Jan 2008 19:20:26 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Alexandre Biancalana References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> In-Reply-To: <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 19:46:49 -0000 Alexandre Biancalana wrote: > Hi Tom ! Thanks for your help! > > I had to step back the chance an put the "old" gateway back, the > performance was unacceptable :-( > > Looking closer I see that still have the problem using the old gateway > too, in a small scale because I only use vlan to external links. > > This old gateway is running 6.2-STABLE and have 4 network interfaces: > fxp0, fxp1, sk0 and sk1. > > fxp0, sk0 and sk1 are no parent of any vlans, are connected to > internal networks and work without problems, follow the ifconfig > ouput: > > fxp0: flags=8843 mtu 1500 > options=8 > inet 10.11.0.1 netmask 0xffff0000 broadcast 10.11.255.255 > ether 00:02:a5:41:c6:b2 > media: Ethernet autoselect (100baseTX ) > status: active > sk0: flags=8843 mtu 1500 > options=b > inet 10.2.0.36 netmask 0xffff0000 broadcast 10.2.255.255 > ether 00:0a:5e:5c:9e:2e > media: Ethernet autoselect (1000baseTX ) > status: active > sk1: flags=8843 mtu 1500 > options=b > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > ether 00:0a:5e:5c:27:ef > media: Ethernet autoselect (100baseTX ) > status: active > > fxp1 is parent of 7 vlan interfaces: vlan16, vlan20, vlan200, vlan201, > vlan202 and vlan205 that connect my internal network to some external > links, follow the ifconfig output: > > vlan200: flags=8843 mtu 1500 > inet 10.200.0.1 netmask 0xfffffffc broadcast 10.200.0.3 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 200 parent interface: fxp1 > vlan201: flags=8843 mtu 1500 > inet 10.200.0.5 netmask 0xfffffffc broadcast 10.200.0.7 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 201 parent interface: fxp1 > vlan202: flags=8843 mtu 1500 > inet 10.200.0.9 netmask 0xfffffffc broadcast 10.200.0.11 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 202 parent interface: fxp1 > vlan205: flags=8943 mtu 1500 > inet 10.0.0.9 netmask 0xfffffffc broadcast 10.0.0.11 > ether 00:0c:f1:ac:91:09 > media: Ethernet autoselect (100baseTX ) > status: active > > Like seen before netstat -niW show output errors in vlan interfaces > > # netstat -niW > Name Mtu Network Address Ipkts Ierrs Opkts > Oerrs Coll > vlan201 1500 00:0c:f1:ac:91:09 53524 0 52234 > 63 0 > vlan202 1500 00:0c:f1:ac:91:09 5907 0 4421 > 4 0 > vlan205 1500 00:0c:f1:ac:91:09 9728659 0 9373148 > 87025 0 > > (the vlan205 is the most used and the output error is increasing...) > Taking a quick look through if_vlan.c it seems that the output error counter (ifp->if_oerrors) is only incremented in 3 places: 1) Then padding short frames that are valid with the vlan tag but runts when they have the tag stripped. 2) When inserting the VLAN tag in to the packet when the underlying interface does not support vlan hardware tagging. 3) When IFW_HANDOFF fails to hand the packet off to the parent interface. Do you have any error messages on the console in dmesg? ('cannot pad short frame', 'unable to prepend vlan header' for example). Tom From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 20:17:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D482A16A418 for ; Tue, 29 Jan 2008 20:17:41 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from n126.sc0.he.tucows.com (smtpout1123.sc0.he.tucows.com [64.97.144.123]) by mx1.freebsd.org (Postfix) with ESMTP id A8CC313C4EA for ; Tue, 29 Jan 2008 20:17:41 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from sc0-out01.emaildefenseservice.com (64.97.131.2) by n126.sc0.he.tucows.com (7.2.069.1) id 479CC1B50015C656 for freebsd-net@freebsd.org; Tue, 29 Jan 2008 20:07:28 +0000 X-SpamScore: 2 X-Spamcatcher-Summary: 2, 0, 0, 4ea46229800bfb23, 8fa981c1a3a1b70e, eagletree@hughes.net, -, RULES_HIT:355:379:541:617:945:946:960:966:973:988:989:1260:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1766:1792:1801:2196:2199:2393:2559:2562:2739:2861:3354:3636:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4039:4250:4362:4385:4605:5007:6119:7652, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spamcatcher-Explanation: Received: from [192.168.0.3] (dpc6744118153.direcpc.com [67.44.118.153]) (Authenticated sender: eagletree@hughes.net) by sc0-out01.emaildefenseservice.com (Postfix) with ESMTP for ; Tue, 29 Jan 2008 20:07:22 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3D322B10-E36E-4194-95DD-5242498F02FC@hughes.net> Content-Transfer-Encoding: 7bit From: Chris Date: Tue, 29 Jan 2008 11:58:53 -0800 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.752.2) Subject: Multiple if_bridge devices X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: snagit@cbpratt.prohosting.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 20:17:42 -0000 (I am reposting this. I posted to FreeBSD-Questions but it appears OT for that list. I didn't come here first because I felt it was too non-technical, but I'd appreciate any insights) I have 3 transparent firewalls on 3 T1s with a LAN behind each supporting multiple servers. Existing: Servers1<->Switch1<->FreeBSD Firewall1<->T1 Router1 Servers2<->Switch2<->FreeBSD Firewall2<->T1 Router2 Servers3<->Switch3<->FreeBSD Firewall3<->T1 Router3 These firewalls are workstation class computers running FreeBSD 6.2, if_bridge and ipfw. This has worked quite well with the exception of hardware failures because of the workstations hardware. I can afford one server-class blade with 3 2-port NICs, but not three complete quality servers. I would like to get to one firewall machine yet maintain the isolation of the circuits and servers. Target: 1 firewall, 4 nics, if_bridge (1 bridge) and ipfw AllServers<->Switch<->FreeBSD Firewall<->T1 Router1 <->T1 Router2 <->T1 Router3 or 1 firewall 6 nics, if_bridge (3 bridges) and ipfw Servers1<->Switch1<->FreeBSD Firewall<->T1 Router1 Servers2<->Switch2<-> <->T1 Router2 Servers3<->Switch3<-> <->T1 Router3 Initially I designed the replacement using a single if_bridge with a single LAN backbone as shown first here. After trying to design the rules, I concluded that it was either illogical or beyond my ipfw rule skills. Then it occurred to me to try to run three if_bridge devices as shown in the second Target One box, 6 NICs, 3 networks kept isolated for arp but IP-managed in a single instance of ipfw. I got as far as attempting this: ifconfig bridge0 create ifconfig bridge0 addm rl0 addm em0 up ifconfig bridge1 create ifconfig bridge1 addm vx0 up It created the devices but obviously is not something I could test to see if it actually worked as two discrete bridges. I've no additional hardware, but before I buy anything, I thought I could simply ask if if_bridge is meant to do this. I have googled, checked man (if_bridge, ipfirewall, ipfw), and the handbook, but I can't find anywhere that specifically says if_bridge is designed to support multiple bridges on one computer. My questions are: 1. Is if_bridge designed to support more than one bridge on a single machine by creating multiple bridge devices (only, of course with multiple NICs on the second and tertiary bridges)? 2. If so, does it retain complete isolation of the bridges (e.g. for ARP) while allowing ipfw to examine all three simultaneously? 3. Should I be exploring a different FreeBSD route to implement this. Thank you, Chris Pratt From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 20:27:08 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB0EB16A41A; Tue, 29 Jan 2008 20:27:08 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C3A7C13C468; Tue, 29 Jan 2008 20:27:08 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0TKR8FF079304; Tue, 29 Jan 2008 20:27:08 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0TKR8sG079300; Tue, 29 Jan 2008 20:27:08 GMT (envelope-from linimon) Date: Tue, 29 Jan 2008 20:27:08 GMT Message-Id: <200801292027.m0TKR8sG079300@freefall.freebsd.org> To: Mel@rachie.is-a-geek.net, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/119548: [pf] [ath] [patch] PF Altq with ath hostap problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 20:27:09 -0000 Synopsis: [pf] [ath] [patch] PF Altq with ath hostap problem State-Changed-From-To: feedback->open State-Changed-By: linimon State-Changed-When: Tue Jan 29 20:26:33 UTC 2008 State-Changed-Why: Feedback received. http://www.freebsd.org/cgi/query-pr.cgi?pr=119548 From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 20:31:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8C0716A46E for ; Tue, 29 Jan 2008 20:31:24 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 78DE513C46A for ; Tue, 29 Jan 2008 20:31:24 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id E00B2787F; Wed, 30 Jan 2008 09:31:22 +1300 (NZDT) Date: Wed, 30 Jan 2008 09:31:22 +1300 From: Andrew Thompson To: snagit@cbpratt.prohosting.com Message-ID: <20080129203122.GC40505@heff.fud.org.nz> References: <3D322B10-E36E-4194-95DD-5242498F02FC@hughes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D322B10-E36E-4194-95DD-5242498F02FC@hughes.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org Subject: Re: Multiple if_bridge devices X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 20:31:24 -0000 On Tue, Jan 29, 2008 at 11:58:53AM -0800, Chris wrote: > (I am reposting this. I posted to FreeBSD-Questions but > it appears OT for that list. I didn't come here first > because I felt it was too non-technical, but I'd appreciate > any insights) > > I have 3 transparent firewalls on 3 T1s with a LAN behind each > supporting multiple servers. > > Existing: > Servers1<->Switch1<->FreeBSD Firewall1<->T1 Router1 > Servers2<->Switch2<->FreeBSD Firewall2<->T1 Router2 > Servers3<->Switch3<->FreeBSD Firewall3<->T1 Router3 > ... > I got as far as attempting this: > > ifconfig bridge0 create > ifconfig bridge0 addm rl0 addm em0 up > ifconfig bridge1 create > ifconfig bridge1 addm vx0 up > > It created the devices but obviously is not something I could > test to see if it actually worked as two discrete bridges. I've > no additional hardware, but before I buy anything, I thought > I could simply ask if if_bridge is meant to do this. I have > googled, checked man (if_bridge, ipfirewall, ipfw), and the > handbook, but I can't find anywhere that specifically says > if_bridge is designed to support multiple bridges on one > computer. > > My questions are: > > 1. Is if_bridge designed to support more than one bridge > on a single machine by creating multiple bridge devices (only, > of course with multiple NICs on the second and tertiary > bridges)? Yes, the number of bridges are unlimited except by resources (memory). > 2. If so, does it retain complete isolation of the bridges (e.g. > for ARP) while allowing ipfw to examine all three simultaneously? The bridges are completly seperate. Note that you can only add a nic to one bridge at a time, so you could have 6 nics, two per bridge. > 3. Should I be exploring a different FreeBSD route to > implement this. Maybe the private flag on interfaces could help you here? You can put the three server networks on different nics (or vlans) and set the private flag, this stops all traffic going between them. See the bridging section of the Handbook for an example or my slides here http://conference.nznog.org/presentations/20080125_01-01-bridge-seperation_andrew-thompson.pdf cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 21:40:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C28B16A417 for ; Tue, 29 Jan 2008 21:40:26 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from n120.sc0.he.tucows.com (smtpout1084.sc0.he.tucows.com [64.97.144.84]) by mx1.freebsd.org (Postfix) with ESMTP id 63C7313C461 for ; Tue, 29 Jan 2008 21:40:26 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from sc0-out09.emaildefenseservice.com (64.97.131.2) by n120.sc0.he.tucows.com (7.2.069.1) id 476BFC81006B17BF for freebsd-net@freebsd.org; Tue, 29 Jan 2008 21:40:25 +0000 X-SpamScore: 50 X-Spamcatcher-Summary: 50, 0, 0, a895ef4f8b28835b, 9ea80b2d0065c3c3, eagletree@hughes.net, -, RULES_HIT:355:379:541:599:601:945:960:966:967:973:988:989:1260:1261:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1766:1792:2194:2196:2199:2200:2393:2525:2553:2560:2563:2682:2685:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3355:3743:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:4039:4250:4321:4362:4385:5007:6119: 7652:7679, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spamcatcher-Explanation: Received: from [192.168.0.3] (dpc6744118153.direcpc.com [67.44.118.153]) (Authenticated sender: eagletree@hughes.net) by sc0-out09.emaildefenseservice.com (Postfix) with ESMTP for ; Tue, 29 Jan 2008 21:40:18 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20080129203122.GC40505@heff.fud.org.nz> References: <3D322B10-E36E-4194-95DD-5242498F02FC@hughes.net> <20080129203122.GC40505@heff.fud.org.nz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FA60D7D-8B56-4B7D-85AA-B66EFB5D29DA@hughes.net> Content-Transfer-Encoding: 7bit From: Chris Pratt Date: Tue, 29 Jan 2008 13:31:47 -0800 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.752.2) Subject: Re: Multiple if_bridge devices X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 21:40:26 -0000 On Jan 29, 2008, at 12:31 PM, Andrew Thompson wrote: > On Tue, Jan 29, 2008 at 11:58:53AM -0800, Chris wrote: >> (I am reposting this. I posted to FreeBSD-Questions but >> it appears OT for that list. I didn't come here first >> because I felt it was too non-technical, but I'd appreciate >> any insights) >> >> I have 3 transparent firewalls on 3 T1s with a LAN behind each >> supporting multiple servers. >> >> Existing: >> Servers1<->Switch1<->FreeBSD Firewall1<->T1 Router1 >> Servers2<->Switch2<->FreeBSD Firewall2<->T1 Router2 >> Servers3<->Switch3<->FreeBSD Firewall3<->T1 Router3 >> > ... >> I got as far as attempting this: >> >> ifconfig bridge0 create >> ifconfig bridge0 addm rl0 addm em0 up >> ifconfig bridge1 create >> ifconfig bridge1 addm vx0 up >> >> It created the devices but obviously is not something I could >> test to see if it actually worked as two discrete bridges. I've >> no additional hardware, but before I buy anything, I thought >> I could simply ask if if_bridge is meant to do this. I have >> googled, checked man (if_bridge, ipfirewall, ipfw), and the >> handbook, but I can't find anywhere that specifically says >> if_bridge is designed to support multiple bridges on one >> computer. >> >> My questions are: >> >> 1. Is if_bridge designed to support more than one bridge >> on a single machine by creating multiple bridge devices (only, >> of course with multiple NICs on the second and tertiary >> bridges)? > > Yes, the number of bridges are unlimited except by resources (memory). > >> 2. If so, does it retain complete isolation of the bridges (e.g. >> for ARP) while allowing ipfw to examine all three simultaneously? > > The bridges are completly seperate. Note that you can only add a > nic to > one bridge at a time, so you could have 6 nics, two per bridge. > >> 3. Should I be exploring a different FreeBSD route to >> implement this. > > Maybe the private flag on interfaces could help you here? You can put > the three server networks on different nics (or vlans) and set the > private flag, this stops all traffic going between them. See the > bridging section of the Handbook for an example or my slides here > http://conference.nznog.org/presentations/20080125_01-01-bridge- > seperation_andrew-thompson.pdf Thank you very much. That gives me enough assurance to proceed as it looks like either method would be safe for the routers. I missed the significance of the private flag in the handbook first time. It suggests a bridge0-only implementation would restrict the routers from receiving each others arp if the 3 WAN interfaces had it set. Thanks again. From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 22:38:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4388B16A41B for ; Tue, 29 Jan 2008 22:38:57 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id CF50C13C461 for ; Tue, 29 Jan 2008 22:38:56 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so3242761pyb.10 for ; Tue, 29 Jan 2008 14:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=3+FwzZBhYLOWue3hGNnZ1Iyr44OsQbmP5tmLQFY9a9c=; b=nwxArpRVBHkheQ0L5RfdNqrq39hpPzbdg69/mtQd5+U1SS8wQrQwU4kax8RGOucMx7LJTTcJPPx19qfCWkeqgdF50aG7qDjEax4UFB6P4afWCw9I0C54ECk44TIYmk1igm+ATxooiGZ+ocRN26avDKQNMPA9s8dTYl/o9j8OSUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=chZxcsMy+UwQETssNCNCisbPbdHseDK+TAhZCSWMfe39YtosY06JvI4MxVolQp2KaZkK6CmhlQFV89fUzlVzpOAhfPZHpO81ZiMpRdZ4+M/5KzOpxYtbymQH7EJmatTCAEi//iOORdEs7leVkscp7Ge08oyuOEWhKyEf+GYVIug= Received: by 10.64.203.4 with SMTP id a4mr3022qbg.6.1201646335562; Tue, 29 Jan 2008 14:38:55 -0800 (PST) Received: by 10.64.184.9 with HTTP; Tue, 29 Jan 2008 14:38:55 -0800 (PST) Message-ID: <8e10486b0801291438n51ca5bcdue2d7ef531ffefaae@mail.gmail.com> Date: Tue, 29 Jan 2008 20:38:55 -0200 From: "Alexandre Biancalana" To: "Tom Judge" In-Reply-To: <479F7C7A.5080605@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> <479F7C7A.5080605@tomjudge.com> Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2008 22:38:57 -0000 On 1/29/08, Tom Judge wrote: > Alexandre Biancalana wrote: > > Hi Tom ! Thanks for your help! > > > > I had to step back the chance an put the "old" gateway back, the > > performance was unacceptable :-( > > > > Looking closer I see that still have the problem using the old gateway > > too, in a small scale because I only use vlan to external links. > > > > This old gateway is running 6.2-STABLE and have 4 network interfaces: > > fxp0, fxp1, sk0 and sk1. > > > > fxp0, sk0 and sk1 are no parent of any vlans, are connected to > > internal networks and work without problems, follow the ifconfig > > ouput: > > > > fxp0: flags=8843 mtu 1500 > > options=8 > > inet 10.11.0.1 netmask 0xffff0000 broadcast 10.11.255.255 > > ether 00:02:a5:41:c6:b2 > > media: Ethernet autoselect (100baseTX ) > > status: active > > sk0: flags=8843 mtu 1500 > > options=b > > inet 10.2.0.36 netmask 0xffff0000 broadcast 10.2.255.255 > > ether 00:0a:5e:5c:9e:2e > > media: Ethernet autoselect (1000baseTX ) > > status: active > > sk1: flags=8843 mtu 1500 > > options=b > > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > > ether 00:0a:5e:5c:27:ef > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > fxp1 is parent of 7 vlan interfaces: vlan16, vlan20, vlan200, vlan201, > > vlan202 and vlan205 that connect my internal network to some external > > links, follow the ifconfig output: > > > > > vlan200: flags=8843 mtu 1500 > > inet 10.200.0.1 netmask 0xfffffffc broadcast 10.200.0.3 > > ether 00:0c:f1:ac:91:09 > > media: Ethernet autoselect (100baseTX ) > > status: active > > vlan: 200 parent interface: fxp1 > > vlan201: flags=8843 mtu 1500 > > inet 10.200.0.5 netmask 0xfffffffc broadcast 10.200.0.7 > > ether 00:0c:f1:ac:91:09 > > media: Ethernet autoselect (100baseTX ) > > status: active > > vlan: 201 parent interface: fxp1 > > vlan202: flags=8843 mtu 1500 > > inet 10.200.0.9 netmask 0xfffffffc broadcast 10.200.0.11 > > ether 00:0c:f1:ac:91:09 > > media: Ethernet autoselect (100baseTX ) > > status: active > > vlan: 202 parent interface: fxp1 > > > vlan205: flags=8943 mtu 1500 > > inet 10.0.0.9 netmask 0xfffffffc broadcast 10.0.0.11 > > ether 00:0c:f1:ac:91:09 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > Like seen before netstat -niW show output errors in vlan interfaces > > > > # netstat -niW > > Name Mtu Network Address Ipkts Ierrs Opkts > > Oerrs Coll > > vlan201 1500 00:0c:f1:ac:91:09 53524 0 52234 > > 63 0 > > vlan202 1500 00:0c:f1:ac:91:09 5907 0 4421 > > 4 0 > > > vlan205 1500 00:0c:f1:ac:91:09 9728659 0 9373148 > > 87025 0 > > > > > (the vlan205 is the most used and the output error is increasing...) > > > > Taking a quick look through if_vlan.c it seems that the output error > counter (ifp->if_oerrors) is only incremented in 3 places: > > 1) Then padding short frames that are valid with the vlan tag but runts > when they have the tag stripped. > > 2) When inserting the VLAN tag in to the packet when the underlying > interface does not support vlan hardware tagging. > > 3) When IFW_HANDOFF fails to hand the packet off to the parent interface. > > Do you have any error messages on the console in dmesg? ('cannot pad > short frame', 'unable to prepend vlan header' for example). no :( From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 00:23:56 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DF8A16A417; Wed, 30 Jan 2008 00:23:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 234DF13C468; Wed, 30 Jan 2008 00:23:56 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0U0Nutx000966; Wed, 30 Jan 2008 00:23:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0U0NuTt000962; Wed, 30 Jan 2008 00:23:56 GMT (envelope-from linimon) Date: Wed, 30 Jan 2008 00:23:56 GMT Message-Id: <200801300023.m0U0NuTt000962@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/120130: [carp] [panic] carp causes kernel panics in any constellation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 00:23:56 -0000 Old Synopsis: carp causes kernel panics in any constellation New Synopsis: [carp] [panic] carp causes kernel panics in any constellation Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 30 00:23:04 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=120130 From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 03:35:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DC7C16A420 for ; Wed, 30 Jan 2008 03:35:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7EC13C46B for ; Wed, 30 Jan 2008 03:35:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 72FE58E1AD; Tue, 29 Jan 2008 22:35:56 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 29 Jan 2008 22:35:56 -0500 X-Sasl-enc: a+mykZw+ZxPcb29RCyapzB5APv0tYkIf2X4U9PK6xipb 1201664156 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 01E4B25138; Tue, 29 Jan 2008 22:35:55 -0500 (EST) Message-ID: <479FF09B.4050705@FreeBSD.org> Date: Wed, 30 Jan 2008 03:35:55 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Ingo Flaschberger 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: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 03:35:57 -0000 Ingo Flaschberger wrote: > Hi, > > linux does already support tcp-md5 checks for incomming connections, > but freebsd not. > > I would like to implement this feature into freebsd. > Any hints/wishes/considerations that I should consider? Someone(tm) keeps threatening to do this every 9-12 months, but I've yet to see patches. - Another example of open sorce (What's missing? U!) Inbound processing for tcp-md5 isn't really that big a deal, I'm amazed it hasn't been deprecated and replaced with something less gnarly, but that's the inertia of stuff at internet exchanges for you and with good reason too. I don't have free time to do any of this (volunteer work doesn't pay the rent, and the costs of living spiral ever upwards), but I can try to make time to review patches if Someone(tm) writes the support. I believe one of the KAME guys took this and ran with it in NetBSD, so look there first, pretty sure it checks the inbound. And of course Kip needs to be in the loop so it works with TOE. One of the things which I didn't finish was integrating TCP-MD5 with the SPD too instead of only the SADB. This meant gnarly syntax for setkey(8). later BMS From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 08:45:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 081B716A417 for ; Wed, 30 Jan 2008 08:45:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id ADEB613C44B for ; Wed, 30 Jan 2008 08:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 112D541C733; Wed, 30 Jan 2008 09:45:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id VfZ7o5zdKOUz; Wed, 30 Jan 2008 09:45:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 90A4C41C712; Wed, 30 Jan 2008 09:45:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id BFFEE4448D5; Wed, 30 Jan 2008 08:40:16 +0000 (UTC) Date: Wed, 30 Jan 2008 08:40:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: "Bruce M. Simpson" In-Reply-To: <479FF09B.4050705@FreeBSD.org> Message-ID: <20080130083105.S36482@maildrop.int.zabbadoz.net> References: <479FF09B.4050705@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Ingo Flaschberger Subject: Re: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 08:45:08 -0000 On Wed, 30 Jan 2008, Bruce M. Simpson wrote: Hi, > Ingo Flaschberger wrote: >> Hi, >> >> linux does already support tcp-md5 checks for incomming connections, but >> freebsd not. >> >> I would like to implement this feature into freebsd. >> Any hints/wishes/considerations that I should consider? > > Someone(tm) keeps threatening to do this every 9-12 months, but I've yet to > see patches. > ... As a result of fixing tcp-md5 end of last year, both of this (incoming validation + SPD integ) is on my TODO list on position 10 (I am currently working on item 3) and there is more ipsec work in the middle. I also have tcp-md5 for IPv6 implementation on the same card. I am willing to help or review patches in case someone wants to do it now. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 10:17:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F28F16A419 for ; Wed, 30 Jan 2008 10:17:45 +0000 (UTC) (envelope-from antik@bsd.ee) Received: from zzz.ee (kalah.zzz.ee [194.204.30.253]) by mx1.freebsd.org (Postfix) with ESMTP id 1992413C459 for ; Wed, 30 Jan 2008 10:17:45 +0000 (UTC) (envelope-from antik@bsd.ee) Received: by zzz.ee (Postfix, from userid 3019) id 587BA687558; Wed, 30 Jan 2008 11:59:28 +0200 (EET) X-Spam-Checker-Version: SpamAssassin on spamassassin.zzz.ee X-Spam-Level: X-Spam-Guessed-Language: en X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,BAYES_40 X-Spam-Checker-URL: http://info.zzz.ee Received: from andrei.demo (adsl215.uninet.ee [194.204.62.215]) by zzz.ee (Postfix) with ESMTP id 66F77687556 for ; Wed, 30 Jan 2008 11:59:27 +0200 (EET) From: Andrei Kolu To: freebsd-net@freebsd.org Date: Wed, 30 Jan 2008 11:59:26 +0200 User-Agent: KMail/1.9.7 References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> In-Reply-To: <479F4C3C.5070801@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801301159.26641.antik@bsd.ee> Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 10:17:45 -0000 > Alexandre Biancalana wrote: > > This server is an Dell Power Edge 1950, QuadCore 2.83, 2Gb Ram, one > > bce gigabit interface connected to a gigabit port of a Cisco 4500 in > > trunk mode. Why you are using trunk mode? IIRC then "trunk" is used only between Cisco switches and routers and your server should be in "access" mode. From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 11:21:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EFEB16A46C for ; Wed, 30 Jan 2008 11:21:41 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id E785E13C4E1 for ; Wed, 30 Jan 2008 11:21:40 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from localhost (localhost [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 2A562341C3; Wed, 30 Jan 2008 11:21:39 +0000 (GMT) Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce0uh9XXA3zl; Wed, 30 Jan 2008 11:21:38 +0000 (GMT) Received: from [192.168.255.6] (unknown [192.168.255.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 7D7C634178; Wed, 30 Jan 2008 11:21:38 +0000 (GMT) Message-ID: <47A05DC1.3080807@tomjudge.com> Date: Wed, 30 Jan 2008 11:21:37 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Andrei Kolu References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <200801301159.26641.antik@bsd.ee> In-Reply-To: <200801301159.26641.antik@bsd.ee> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 11:21:41 -0000 Andrei Kolu wrote: >> Alexandre Biancalana wrote: >>> This server is an Dell Power Edge 1950, QuadCore 2.83, 2Gb Ram, one >>> bce gigabit interface connected to a gigabit port of a Cisco 4500 in >>> trunk mode. > > Why you are using trunk mode? IIRC then "trunk" is used only between Cisco > switches and routers and your server should be in "access" mode. Trunk mode is perfectly valid in this configuration. Access mode afaik only allows the port to be configured into 1 untagged vlan, or that is how it is on the dell PowerConnect's we have, it may be different on cisco. Tom From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 11:59:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 311F116A418 for ; Wed, 30 Jan 2008 11:59:32 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (www.unsane.co.uk [85.233.185.162]) by mx1.freebsd.org (Postfix) with ESMTP id AAAFB13C44B for ; Wed, 30 Jan 2008 11:59:31 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from prawn.unsane.co.uk (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id m0UBSpON000284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2008 11:28:52 GMT (envelope-from jhary@unsane.co.uk) Message-ID: <47A05FD9.3050802@unsane.co.uk> Date: Wed, 30 Jan 2008 11:30:33 +0000 From: Vince Hoffman User-Agent: Thunderbird 2.0.0.9 (X11/20080124) MIME-Version: 1.0 To: Tom Judge References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <200801301159.26641.antik@bsd.ee> <47A05DC1.3080807@tomjudge.com> In-Reply-To: <47A05DC1.3080807@tomjudge.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrei Kolu , freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 11:59:32 -0000 Tom Judge wrote: > Andrei Kolu wrote: >>> Alexandre Biancalana wrote: >>>> This server is an Dell Power Edge 1950, QuadCore 2.83, 2Gb Ram, one >>>> bce gigabit interface connected to a gigabit port of a Cisco 4500 in >>>> trunk mode. >> >> Why you are using trunk mode? IIRC then "trunk" is used only between >> Cisco switches and routers and your server should be in "access" mode. > > > Trunk mode is perfectly valid in this configuration. Access mode afaik > only allows the port to be configured into 1 untagged vlan, or that is > how it is on the dell PowerConnect's we have, it may be different on cisco. > Its the same on Cisco kit. > Tom > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 13:01:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91E2216A419 for ; Wed, 30 Jan 2008 13:01:06 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp810.mail.ird.yahoo.com (smtp810.mail.ird.yahoo.com [217.146.188.70]) by mx1.freebsd.org (Postfix) with SMTP id EF3E513C4D9 for ; Wed, 30 Jan 2008 13:01:05 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 22155 invoked from network); 30 Jan 2008 13:01:03 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.239.10 with plain) by smtp810.mail.ird.yahoo.com with SMTP; 30 Jan 2008 13:01:03 -0000 X-YMail-OSG: PH_LkMoVM1kgA_R2xfrN8VwR_8FwS8EzAs9slN5q.t2QXtwZoF7Ef4W_heHI4wKk2g9YbjO8ng-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <47A07525.9080201@tomjudge.com> Date: Wed, 30 Jan 2008 13:01:25 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Alexandre Biancalana References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> <479F7C7A.5080605@tomjudge.com> <8e10486b0801291438n51ca5bcdue2d7ef531ffefaae@mail.gmail.com> In-Reply-To: <8e10486b0801291438n51ca5bcdue2d7ef531ffefaae@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 13:01:06 -0000 Alexandre Biancalana wrote: > On 1/29/08, Tom Judge wrote: >> Alexandre Biancalana wrote: >>> Hi Tom ! Thanks for your help! >>> >>> I had to step back the chance an put the "old" gateway back, the >>> performance was unacceptable :-( >>> >>> Looking closer I see that still have the problem using the old gateway >>> too, in a small scale because I only use vlan to external links. >>> >>> This old gateway is running 6.2-STABLE and have 4 network interfaces: >>> fxp0, fxp1, sk0 and sk1. >>> >>> fxp0, sk0 and sk1 are no parent of any vlans, are connected to >>> internal networks and work without problems, follow the ifconfig >>> ouput: >>> >>> fxp0: flags=8843 mtu 1500 >>> options=8 >>> inet 10.11.0.1 netmask 0xffff0000 broadcast 10.11.255.255 >>> ether 00:02:a5:41:c6:b2 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> sk0: flags=8843 mtu 1500 >>> options=b >>> inet 10.2.0.36 netmask 0xffff0000 broadcast 10.2.255.255 >>> ether 00:0a:5e:5c:9e:2e >>> media: Ethernet autoselect (1000baseTX ) >>> status: active >>> sk1: flags=8843 mtu 1500 >>> options=b >>> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 >>> ether 00:0a:5e:5c:27:ef >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> >>> fxp1 is parent of 7 vlan interfaces: vlan16, vlan20, vlan200, vlan201, >>> vlan202 and vlan205 that connect my internal network to some external >>> links, follow the ifconfig output: >>> >>> vlan200: flags=8843 mtu 1500 >>> inet 10.200.0.1 netmask 0xfffffffc broadcast 10.200.0.3 >>> ether 00:0c:f1:ac:91:09 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> vlan: 200 parent interface: fxp1 >>> vlan201: flags=8843 mtu 1500 >>> inet 10.200.0.5 netmask 0xfffffffc broadcast 10.200.0.7 >>> ether 00:0c:f1:ac:91:09 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> vlan: 201 parent interface: fxp1 >>> vlan202: flags=8843 mtu 1500 >>> inet 10.200.0.9 netmask 0xfffffffc broadcast 10.200.0.11 >>> ether 00:0c:f1:ac:91:09 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> vlan: 202 parent interface: fxp1 >>> vlan205: flags=8943 mtu 1500 >>> inet 10.0.0.9 netmask 0xfffffffc broadcast 10.0.0.11 >>> ether 00:0c:f1:ac:91:09 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> >>> Like seen before netstat -niW show output errors in vlan interfaces >>> >>> # netstat -niW >>> Name Mtu Network Address Ipkts Ierrs Opkts >>> Oerrs Coll >>> vlan201 1500 00:0c:f1:ac:91:09 53524 0 52234 >>> 63 0 >>> vlan202 1500 00:0c:f1:ac:91:09 5907 0 4421 >>> 4 0 >>> vlan205 1500 00:0c:f1:ac:91:09 9728659 0 9373148 >>> 87025 0 >>> (the vlan205 is the most used and the output error is increasing...) >>> >> Taking a quick look through if_vlan.c it seems that the output error >> counter (ifp->if_oerrors) is only incremented in 3 places: >> >> 1) Then padding short frames that are valid with the vlan tag but runts >> when they have the tag stripped. >> >> 2) When inserting the VLAN tag in to the packet when the underlying >> interface does not support vlan hardware tagging. >> >> 3) When IFW_HANDOFF fails to hand the packet off to the parent interface. >> >> Do you have any error messages on the console in dmesg? ('cannot pad >> short frame', 'unable to prepend vlan header' for example). > > no :( Sorry I'm fresh out of ideas now... Unless you could be should of ram what does netstat -m look like? Also you could look at changing if_vlan.c to print the error number of the error if IFQ_HANDOFF fails. Tom From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 13:56:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45DB216A41B for ; Wed, 30 Jan 2008 13:56:11 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 0316913C461 for ; Wed, 30 Jan 2008 13:56:10 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so356216pyb.10 for ; Wed, 30 Jan 2008 05:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=kNM+O4oR5PiIUnZTtnIj0ZQhoE07xiK+hX7VO4f5d1E=; b=MVGrPTrC226ipAl+TyLqh9Z46wHI3gGNa9RQV5U4lELR6vZ7pouEnfdp+U9ClqGrl+Obni5KUCIqn8CqR8JT0bPN0UjzourRf4IrmgjxuZW2Sl5+VewT0J36vXUVg3hNHwDhIKHAwtWkzMZC6+i6Ah6/zoRpy3EDWXuuAjkrTOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=g/r5MN2OW79HRe9SUd3j4tsWHHbTsYmKOEWCfKEI07KhIvV22QwaRFgZz1a5zmQvlPoR+56ChzRpJb0+o7Llmt6oeNUgiqJrOOp57CWwtGrTVOwSjp7alLvYktJ+Nwg4pCH2ATJrw8oCxw42MVMXKoE43hi/7AK2SyoHfHBDthI= Received: by 10.64.150.18 with SMTP id x18mr1595269qbd.87.1201701370096; Wed, 30 Jan 2008 05:56:10 -0800 (PST) Received: by 10.64.184.9 with HTTP; Wed, 30 Jan 2008 05:56:10 -0800 (PST) Message-ID: <8e10486b0801300556o3dfcd25el3511b0f7845d2607@mail.gmail.com> Date: Wed, 30 Jan 2008 11:56:10 -0200 From: "Alexandre Biancalana" To: "Andrei Kolu" In-Reply-To: <200801301159.26641.antik@bsd.ee> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <200801301159.26641.antik@bsd.ee> Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 13:56:11 -0000 On 1/30/08, Andrei Kolu wrote: > > Alexandre Biancalana wrote: > > > This server is an Dell Power Edge 1950, QuadCore 2.83, 2Gb Ram, one > > > bce gigabit interface connected to a gigabit port of a Cisco 4500 in > > > trunk mode. > > Why you are using trunk mode? IIRC then "trunk" is used only between Cisco > switches and routers and your server should be in "access" mode. I think you don't read the entire thread.... I use trunk mode to "pass" more than one vlan to the same port. Do you have any other idea on how to configure this ? From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 14:10:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C7E216A41B for ; Wed, 30 Jan 2008 14:10:18 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id 9829C13C457 for ; Wed, 30 Jan 2008 14:10:17 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so361013pyb.10 for ; Wed, 30 Jan 2008 06:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=MmscofaQQbI7SpkSnQ9i11wc4ov7LFc4qqo7XbDnpCE=; b=vc9+heyVj8fbWn7tJky7AbOXU7RrVkxkj8fLDtsw07OK7DjpISgUvDBhvYBI6NQSoUH6W2mHoN5GMuu/FHsTwmtxJw/7fBYzUT60RiBxiA6S745ipZ2FCwz6TXei5NUdVC9enOWwXGXkIiQvDzBlYrtQDHcj1y7n8JbhGHhtqTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CEcIic53NtiIVaT67vyBNqY50ndAZHdJiXlGxo5NWh7vJ2RpGndyXjFqnottF5Z9TuldIT5Nugub0Me/0Zc9bqNGw1gpP+hR/ILoiKzrCVZ+rO0MS/1zKrYE9JzrQh3Jto/ieZWcHO2NlxwBJBtkHIewVh0FSKc/l3dv4Y+oHts= Received: by 10.64.199.2 with SMTP id w2mr1718730qbf.11.1201702216291; Wed, 30 Jan 2008 06:10:16 -0800 (PST) Received: by 10.64.184.9 with HTTP; Wed, 30 Jan 2008 06:10:16 -0800 (PST) Message-ID: <8e10486b0801300610jf0b3f88tc3c06dab76268917@mail.gmail.com> Date: Wed, 30 Jan 2008 12:10:16 -0200 From: "Alexandre Biancalana" To: "Tom Judge" In-Reply-To: <47A07525.9080201@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> <479F7C7A.5080605@tomjudge.com> <8e10486b0801291438n51ca5bcdue2d7ef531ffefaae@mail.gmail.com> <47A07525.9080201@tomjudge.com> Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 14:10:18 -0000 On 1/30/08, Tom Judge wrote: .... > >> Do you have any error messages on the console in dmesg? ('cannot pad > >> short frame', 'unable to prepend vlan header' for example). > > > > no :( > > Sorry I'm fresh out of ideas now... Unless you could be should of ram > what does netstat -m look like? Also you could look at changing > if_vlan.c to print the error number of the error if IFQ_HANDOFF fails. Me too... This should be much simple... I can't imagine why so much trouble in this configuration, I have a similar setup with linux :( and have no problem at all... # netstat -m 938/2347/3285 mbufs in use (current/cache/total) 936/1860/2796/32768 mbuf clusters in use (current/cache/total/max) 936/1860 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 2109K/4306K/6415K bytes allocated to network (current/cache/total) 0/3/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/7/4544 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 229 calls to protocol drain routines Is the vlan solution designed to work with multiple concurrent 100M networks using the same Gbit interface ? or Am I thinking in a wrong ? I want to have a central firewall in my network, filtering ALL the traffic between ALL internal networks and external links. I already done that using physical nics, ( I had one machine with 8 nic) but now I have one machine with 2 gigabit nics and want to configure multiple vlan on top this for the internal networks and external links. Am I wrong to think that this should work ?? From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 14:53:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E0BB16A468 for ; Wed, 30 Jan 2008 14:53:40 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id E635D13C459 for ; Wed, 30 Jan 2008 14:53:39 +0000 (UTC) (envelope-from if@xip.at) Received: (qmail 7887 invoked from network); 30 Jan 2008 15:53:37 +0100 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jan 2008 15:53:37 +0100 Date: Wed, 30 Jan 2008 15:53:36 +0100 (CET) From: Ingo Flaschberger To: "Bjoern A. Zeeb" In-Reply-To: <20080130083105.S36482@maildrop.int.zabbadoz.net> Message-ID: References: <479FF09B.4050705@FreeBSD.org> <20080130083105.S36482@maildrop.int.zabbadoz.net> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 14:53:40 -0000 Hi Bjoern, > both of this (incoming validation + SPD integ) is on my TODO list on > position 10 (I am currently working on item 3) and there is more ipsec > work in the middle. > > I also have tcp-md5 for IPv6 implementation on the same card. > > I am willing to help or review patches in case someone wants to do it > now. Yes, I want todo it now. So rules how it should implemented would be great. (I can do it, but just to be shure that I have to to write the patch twice.) netbsd hint is also a good idea. Kind regards, Ingo Flaschberger From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 15:22:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7090C16A41A for ; Wed, 30 Jan 2008 15:22:38 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp803.mail.ird.yahoo.com (smtp803.mail.ird.yahoo.com [217.146.188.63]) by mx1.freebsd.org (Postfix) with SMTP id E701713C442 for ; Wed, 30 Jan 2008 15:22:37 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 93243 invoked from network); 30 Jan 2008 15:22:36 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.139.239.10 with plain) by smtp803.mail.ird.yahoo.com with SMTP; 30 Jan 2008 15:22:36 -0000 X-YMail-OSG: H7OBwX0VM1luRtjI.gyEmbRPEAJei5.wH0C4UYBNIjI3cgTqOccjkDDzsSOGGzvKyFWwI6pl1bNevqfw9tqZtUkSkgyL X-Yahoo-Newman-Property: ymail-3 Message-ID: <47A09652.5070103@tomjudge.com> Date: Wed, 30 Jan 2008 15:22:58 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Alexandre Biancalana References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <8e10486b0801290842l5d65bb3fk8a02d731c3ad1b91@mail.gmail.com> <479F7C7A.5080605@tomjudge.com> <8e10486b0801291438n51ca5bcdue2d7ef531ffefaae@mail.gmail.com> <47A07525.9080201@tomjudge.com> <8e10486b0801300610jf0b3f88tc3c06dab76268917@mail.gmail.com> In-Reply-To: <8e10486b0801300610jf0b3f88tc3c06dab76268917@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------020500070408080304020907" Cc: freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 15:22:38 -0000 This is a multi-part message in MIME format. --------------020500070408080304020907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alexandre Biancalana wrote: > On 1/30/08, Tom Judge wrote: > > .... > >>>> Do you have any error messages on the console in dmesg? ('cannot pad >>>> short frame', 'unable to prepend vlan header' for example). >>> no :( >> Sorry I'm fresh out of ideas now... Unless you could be should of ram >> what does netstat -m look like? Also you could look at changing >> if_vlan.c to print the error number of the error if IFQ_HANDOFF fails. > > Me too... This should be much simple... I can't imagine why so much > trouble in this configuration, I have a similar setup with linux :( > and have no problem at all... > > # netstat -m > 938/2347/3285 mbufs in use (current/cache/total) > 936/1860/2796/32768 mbuf clusters in use (current/cache/total/max) > 936/1860 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) > 2109K/4306K/6415K bytes allocated to network (current/cache/total) > 0/3/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/7/4544 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 229 calls to protocol drain routines > Cant see any issues here. > > Is the vlan solution designed to work with multiple concurrent 100M > networks using the same Gbit interface ? or Am I thinking in a wrong ? > > I want to have a central firewall in my network, filtering ALL the > traffic between ALL internal networks and external links. I already > done that using physical nics, ( I had one machine with 8 nic) but now > I have one machine with 2 gigabit nics and want to configure multiple > vlan on top this for the internal networks and external links. > > Am I wrong to think that this should work ?? The concepts and configuration seems fine to me. Do you by any change have Q-in-Q enabled anywhere on your network? Could you try this patch (attached) to see what error you are getting from IFQ_HANDOFF? (you will need to apply if from in sys/net and rebuild your kernel or vlan module). Tom --------------020500070408080304020907 Content-Type: text/x-patch; name="if_vlan.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_vlan.patch" --- if_vlan.c.orig 2008-01-30 15:09:46.000000000 +0000 +++ if_vlan.c 2008-01-30 15:20:29.000000000 +0000 @@ -864,10 +864,12 @@ * We are already running at splimp. */ IFQ_HANDOFF(p, m, error); - if (!error) + if (!error) { ifp->if_opackets++; - else + } else { ifp->if_oerrors++; + if_printf(ifp, "error during IFQ_HANDOFF: %d\n", error); + } } } --------------020500070408080304020907-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 17:37:48 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47C9A16A417 for ; Wed, 30 Jan 2008 17:37:48 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 361C913C465 for ; Wed, 30 Jan 2008 17:37:48 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 946B43C0450; Wed, 30 Jan 2008 09:18:26 -0800 (PST) Date: Wed, 30 Jan 2008 09:18:26 -0800 From: Christopher Cowart To: Alexandre Biancalana Message-ID: <20080130171826.GE41095@hal.rescomp.berkeley.edu> Mail-Followup-To: Alexandre Biancalana , Andrei Kolu , freebsd-net@freebsd.org References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <200801301159.26641.antik@bsd.ee> <8e10486b0801300556o3dfcd25el3511b0f7845d2607@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L5Ks5Ey27iMz7PUy" Content-Disposition: inline In-Reply-To: <8e10486b0801300556o3dfcd25el3511b0f7845d2607@mail.gmail.com> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Andrei Kolu , freebsd-net@freebsd.org Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2008 17:37:48 -0000 --L5Ks5Ey27iMz7PUy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 30, 2008 at 11:56:10AM -0200, Alexandre Biancalana wrote: >On 1/30/08, Andrei Kolu wrote: >>>Alexandre Biancalana wrote: >>>>This server is an Dell Power Edge 1950, QuadCore 2.83, 2Gb Ram, one >>>>bce gigabit interface connected to a gigabit port of a Cisco 4500 in >>>>trunk mode. >> >>Why you are using trunk mode? IIRC then "trunk" is used only between Cisco >>switches and routers and your server should be in "access" mode. > >I think you don't read the entire thread.... > >I use trunk mode to "pass" more than one vlan to the same port. Do you >have any other idea on how to configure this ? Trunking is definitely what you want. I'm using it successfully=20 between Cisco switches and FreeBSD in a number of places. Here's IOS: | interface GigabitEthernet1/0/8 | description dev-wireless-aux | switchport trunk encapsulation dot1q | switchport trunk native vlan 8 | switchport trunk allowed vlan 88,665,679 | switchport mode trunk | spanning-tree bpduguard enable Here's rc.conf: | ifconfig_fxp1=3D"up" | ifconfig_vlan88=3D"inet 10.8.0.2 netmask 0xffffc000 vlan 88=20 | vlandev fxp1" | ifconfig_vlan88_alias0=3D"inet 10.8.0.1 netmask 0xffffffff" | ifconfig_vlan665=3D"inet 169.229.65.132 netmask 0xffffffc0 vlan 665=20 | vlandev fxp1" | ifconfig_vlan679=3D"inet 169.229.79.132 netmask 0xffffff80 vlan 679=20 | vlandev fxp1" You may have already done so, but make sure your trunk is in dot1q mode. The default trunking protocol is a Cisco proprietary something, if I understand correctly. --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --L5Ks5Ey27iMz7PUy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBR6CxYiPHEDszU3zYAQImPBAAh5KM1dLl4jfZz0ZA5f8EL/TGU4xBT1kT 85lHdhBb2L7oGS+N3iZsL8cuIKGRP03k7h4geLCeO28X1sEtD1KmR5hrsYhzjPJT 2naCnUV9GAVobVwen76W9tMpD1ITzImru+bd/vkA8Wul29oUBbzS7T6eBewqhfn8 QLWgEuQTxz7vxHP1A7CAqlT2Mu/txwIWtTeTZxJ+EYvZmFn4G8ymBKSqQ3n2EfYx KxZrlKQItduYnR8USpKFVwBVJx8fmQJBVv+C1rjgg0PW1qyXzgwVtmBs+Kz3CB3a ggjxyHngSfVenoVn0LirWsFpIkfk8ysb/XCXRRhul1TzeYaCXw54Ct8GJXZYxtGk 7rzRZdd37K5N73djbg0MSTPeBBXPgdzDYxheYVpon9TakYYl/rYfjnRMfEgnHWRv 7sgjYSMrQbX0TXNMqaNzWxTT5hd4j0VMQ5ulSFFg1Aj1sfzgYF0j/HfHR9akmO7O uRGHOYoc1LMWnn2OV/SksNa7LVamJKvzljTb3Vrjyg81t23LJH71hdTmhjYRP4lU MGh32snhb8ax0oEkxiIrDaCzbhaesb1CF08YW2PZkHd/XH+3Zbs+GDoDl16r6SPA nqEqxOwNCnRiDbuG7jbC6VJxij8LY07rzVnsTL0P3EH8vm5gsfU8T9EhDE56WbQg fCefUMYbSO8= =3otD -----END PGP SIGNATURE----- --L5Ks5Ey27iMz7PUy-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 00:39:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3909B16A418 for ; Thu, 31 Jan 2008 00:39:28 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id 8051613C4EB for ; Thu, 31 Jan 2008 00:39:26 +0000 (UTC) (envelope-from if@xip.at) Received: (qmail 13626 invoked from network); 31 Jan 2008 01:39:25 +0100 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 31 Jan 2008 01:39:25 +0100 Date: Thu, 31 Jan 2008 01:39:24 +0100 (CET) From: Ingo Flaschberger To: "Bjoern A. Zeeb" In-Reply-To: <20080130083105.S36482@maildrop.int.zabbadoz.net> Message-ID: References: <479FF09B.4050705@FreeBSD.org> <20080130083105.S36482@maildrop.int.zabbadoz.net> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 00:39:28 -0000 Dear Bjoern, Bruce, Looking trough linux, netbsd and Bruce old patch (which works with minimal modification at my freebsd 6.2) I have 3 ideas how md5 could be integrated. 1) netbsd method: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/tcp_input.c?rev=1.277&content-type=text/x-cvsweb-markup Look for TCP_SIGNATURE. The main-code part is handled in tcp_dooptions The have modified the return value of tcp_dooptions from void to int. If md5 fails, -1 is returned (ony md5 use this return feature) and in the tcp_input the return value of tcp_dooptions is checked and handled. -> for freebsd: change the retutn value of tcp_dooptions and add little logic to tcp_input function. 2) linux method: Look for CONFIG_TCP_MD5SIG in linux-2.6.24/net/ipv4/tcp_ipv4.c (sorry no weblink..) They check and block md5-packets early in tcp_v4_do_rcv. afinet.c -> tcp_v4_rcv -> tcp_v4_do_rcv -> for Freebsd: place some logic early in tcp_input function and call a new function to check md5. 3) Bruce extended method: http://lists.freebsd.org/pipermail/freebsd-net/2004-April/003761.html Use his code and add at severall places in tcp_input function similar checks. Options: *) enable disable it via sysctl *) count total, good and bad packets via sysctl Kind regards, Ingo Flaschberger anytwo(tm) From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 05:19:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74DBC16A41A for ; Thu, 31 Jan 2008 05:19:38 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 4484E13C457 for ; Thu, 31 Jan 2008 05:19:38 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 6713E8E600; Thu, 31 Jan 2008 00:19:37 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 31 Jan 2008 00:19:37 -0500 X-Sasl-enc: 5zZ6rak/6ydx9P6JiMQP1PKOj4xgymfaq9QSXAvtJoxJ 1201756777 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id D601C25359; Thu, 31 Jan 2008 00:19:36 -0500 (EST) Message-ID: <47A15A67.9000605@FreeBSD.org> Date: Thu, 31 Jan 2008 05:19:35 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Ingo Flaschberger References: <479FF09B.4050705@FreeBSD.org> <20080130083105.S36482@maildrop.int.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 05:19:38 -0000 The bigger issue w/tcp-md5 is getting security policy 'right'. bz has more IPSEC hacking experience than I, so I defer to his advice in this area. The way the socket option was originally specified was that once it was set, all further activity on the socket had to be tcp-md5'd. For an outgoing connect() this is pretty much assumed in the beginning. For a listen() and bind(), it means all further sessions on that port must use tcp-md5 to be accepted. However this obviously poses problems if you want to be able to accept connections on the same port from non tcp-md5 peers. And for BGP, which can open the underlying tcp session in either direction ('passive open', jittered) it's also important that the tcp-md5 state of the socket is in sync with the routing process's notion of policy. ospf sidestepped all this by using raw IP datagrams, so there was no need to implement authentication in the network transport layer. So, the SPD seems like the way to go! Trouble is, routing daemons aren't IPSEC daemons, nor do they speak the RFC specified protocol for this, PF_KEY. I toyed with the idea of rolling one for XORP but there hasn't been any demand. cheers BMS From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 05:58:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A65C16A417 for ; Thu, 31 Jan 2008 05:58:41 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id 1B34913C4D1 for ; Thu, 31 Jan 2008 05:58:40 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so482552rvb.43 for ; Wed, 30 Jan 2008 21:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=RPnJfJSI4Mdtt/5cazVkKHKCFG+rYMHGG1R8VMKj9NE=; b=dejbRMw3XTYuxxBKPfma2WU90MgX73ZKbniSo5h919aSLj0tcAGQ6rQV2rwo5xthwlZ4iV45zmQd1B74sCdvoIS8XPZtoO5JtVlh9lDtNM9YtTyBib9sSqxYd2MBGCD0HOo7Wkbv+X8ulSUalX190eu4kIMM9Nhqu39H2eNlyrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gUhfndah8DI8k+b9dXCJMAbD/8LcSzNzEAZojWoyPl4lOD6RNsKTJZldUGbxwzFC1mET2rjpwJ294L+lRc1RSIB3oq53vVPtUKjd+X2Ku7Jou8FszN71/1qZgBhUiQHWLn3WTMEAsayl2lI6foVNAbupO7ndkMKarQhmdFawQQA= Received: by 10.141.99.4 with SMTP id b4mr1207784rvm.40.1201759120324; Wed, 30 Jan 2008 21:58:40 -0800 (PST) Received: by 10.141.170.18 with HTTP; Wed, 30 Jan 2008 21:58:40 -0800 (PST) Message-ID: <2e77fc10801302158y7e4d0764s96669bf2dc44881e@mail.gmail.com> Date: Thu, 31 Jan 2008 07:58:40 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: "Bruce M. Simpson" In-Reply-To: <47A15A67.9000605@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <479FF09B.4050705@FreeBSD.org> <20080130083105.S36482@maildrop.int.zabbadoz.net> <47A15A67.9000605@FreeBSD.org> X-Google-Sender-Auth: b4203daf5f2b0246 Cc: "Bjoern A. Zeeb" , Ingo Flaschberger , freebsd-net@freebsd.org Subject: Re: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 05:58:41 -0000 On Jan 31, 2008 7:19 AM, Bruce M. Simpson wrote: > The bigger issue w/tcp-md5 is getting security policy 'right'. > bz has more IPSEC hacking experience than I, so I defer to his advice in > this area. > > The way the socket option was originally specified was that once it was > set, all further activity on the socket had to be tcp-md5'd. For an > outgoing connect() this is pretty much assumed in the beginning. For a > listen() and bind(), it means all further sessions on that port must use > tcp-md5 to be accepted. > > However this obviously poses problems if you want to be able to accept > connections on the same port from non tcp-md5 peers. And for BGP, which > can open the underlying tcp session in either direction ('passive open', > jittered) it's also important that the tcp-md5 state of the socket is in > sync with the routing process's notion of policy. > > ospf sidestepped all this by using raw IP datagrams, so there was no > need to implement authentication in the network transport layer. > > So, the SPD seems like the way to go! Trouble is, routing daemons aren't > IPSEC daemons, nor do they speak the RFC specified protocol for this, > PF_KEY. I toyed with the idea of rolling one for XORP but there hasn't > been any demand. > OpenBGPD on OpenBSD seems to do exactly this. It supports the PF_KEY interface and one can configure either TCP_MD5_SIG or IPSEC security associations for the bgp peers right in the bgpd.conf config file. -- Niki From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 10:02:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2518D16A46C for ; Thu, 31 Jan 2008 10:02:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7C27013C45A for ; Thu, 31 Jan 2008 10:02:36 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 8231 invoked from network); 31 Jan 2008 09:22:33 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Jan 2008 09:22:33 -0000 Message-ID: <47A19CC2.4070609@freebsd.org> Date: Thu, 31 Jan 2008 11:02:42 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Ingo Flaschberger References: <479FF09B.4050705@FreeBSD.org> <20080130083105.S36482@maildrop.int.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , "Bruce M. Simpson" , freebsd-net@freebsd.org Subject: Re: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 10:02:37 -0000 Ingo Flaschberger wrote: > Dear Bjoern, Bruce, > > Looking trough linux, netbsd and Bruce old patch > (which works with minimal modification at my freebsd 6.2) > I have 3 ideas how md5 could be integrated. > > 1) netbsd method: > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet/tcp_input.c?rev=1.277&content-type=text/x-cvsweb-markup > > Look for TCP_SIGNATURE. > The main-code part is handled in tcp_dooptions > The have modified the return value of tcp_dooptions from void to > int. If md5 fails, -1 is returned (ony md5 use this return > feature) and in the tcp_input the return value of > tcp_dooptions is checked and handled. > -> for freebsd: change the retutn value of tcp_dooptions and > add little logic to tcp_input function. Please do not use this method. tcp_dooptions should not have any side- effects other than parsing the tcp options. It sets a flag if TCPOPT_SIGNATURE was detected and give you the pointer to the hash in to_signature. > 2) linux method: > Look for CONFIG_TCP_MD5SIG in linux-2.6.24/net/ipv4/tcp_ipv4.c > (sorry no weblink..) > They check and block md5-packets early in tcp_v4_do_rcv. > afinet.c -> tcp_v4_rcv -> tcp_v4_do_rcv > -> for Freebsd: place some logic early in tcp_input function > and call a new function to check md5. IMHO calling a special function that does the check (like in tcp_output) is the way to go. This function should be run as late as possible after the other segment validity checks to prevent easy cpu exhaustion attacks with packets that only get the port numbers right. In tcp_new there is a natural place to perform the check. tcp_input will show up this weekend. This doesn't prevent your work on the current code at all as tcp_new won't show up in -current for a long time and when it does it will not get MFC'd. > 3) Bruce extended method: > http://lists.freebsd.org/pipermail/freebsd-net/2004-April/003761.html > Use his code and add at severall places in tcp_input function > similar checks. > > Options: > *) enable disable it via sysctl > *) count total, good and bad packets via sysctl This belongs into struct tcpstat, not a new sysctl. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 12:15:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FC6016A41B for ; Thu, 31 Jan 2008 12:15:15 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id E0B1013C45B for ; Thu, 31 Jan 2008 12:15:14 +0000 (UTC) (envelope-from if@xip.at) Received: (qmail 12005 invoked from network); 31 Jan 2008 13:15:12 +0100 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 31 Jan 2008 13:15:12 +0100 Date: Thu, 31 Jan 2008 13:15:12 +0100 (CET) From: Ingo Flaschberger To: Andre Oppermann In-Reply-To: <47A19CC2.4070609@freebsd.org> Message-ID: References: <479FF09B.4050705@FreeBSD.org> <20080130083105.S36482@maildrop.int.zabbadoz.net> <47A19CC2.4070609@freebsd.org> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bjoern A. Zeeb" , "Bruce M. Simpson" , freebsd-net@freebsd.org Subject: Re: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 12:15:15 -0000 Dear Andre, >> 2) linux method: >> Look for CONFIG_TCP_MD5SIG in linux-2.6.24/net/ipv4/tcp_ipv4.c >> (sorry no weblink..) >> They check and block md5-packets early in tcp_v4_do_rcv. >> afinet.c -> tcp_v4_rcv -> tcp_v4_do_rcv >> -> for Freebsd: place some logic early in tcp_input function >> and call a new function to check md5. > > IMHO calling a special function that does the check (like in tcp_output) > is the way to go. This function should be run as late as possible after > the other segment validity checks to prevent easy cpu exhaustion attacks > with packets that only get the port numbers right. > > In tcp_new there is a natural place to perform the check. tcp_input will > show up this weekend. This doesn't prevent your work on the current code > at all as tcp_new won't show up in -current for a long time and when it > does it will not get MFC'd. Ok. I will do the first patch for freebsd 6.2 (as my system uses it) and do the a port to current (and I thing 6.3 too). Regardding Bruce: I would prefer to implement md5 via the old setkey api as I also have todo my daily business. >> 3) Bruce extended method: >> http://lists.freebsd.org/pipermail/freebsd-net/2004-April/003761.html >> Use his code and add at severall places in tcp_input function >> similar checks. >> >> Options: >> *) enable disable it via sysctl >> *) count total, good and bad packets via sysctl > > This belongs into struct tcpstat, not a new sysctl. Ok. With which tool can this counters be read? Should I add the on/off feature? Via which tool? Kind regards, Ingo From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 17:23:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64AB216A41B for ; Thu, 31 Jan 2008 17:23:37 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 313A113C45D for ; Thu, 31 Jan 2008 17:23:36 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so43448waf.3 for ; Thu, 31 Jan 2008 09:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=PMsKAMSzQK+pLCanfxvcb1a7bQLICtd5YQpQo5qCba8=; b=Ea2H8w1zu3Qmw0tcyZwxz7YrXYn6UMaQcWAGr9v39pEMrNgKjaLeA65m7WbDEc72PdgkvSe9WWMldoZR3mJ+cgptWUYo/DxPNorJVOmA4Qos0Kn62nAoGMdcypg37ztrBdutGaEiVjjydDejOElVMF7TMH38slOFLqr3NwpQD14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gfaL70Iru2V1aFKcxtsYvZPfDZG0iqb6ZwwQto275gukdqggNnxY3gXCakZVDXQUOQAJuDTM40VonJnleRG6gDuESasTXD00HuasKB6B+w6Nd8Ow/d3/1MdSDAmguqaNDMfxp+b13QG18NZOwVfZId3dLMuWVEwQqIQ1uOOMBS8= Received: by 10.115.90.1 with SMTP id s1mr2698676wal.41.1201800216594; Thu, 31 Jan 2008 09:23:36 -0800 (PST) Received: by 10.114.76.12 with HTTP; Thu, 31 Jan 2008 09:23:36 -0800 (PST) Message-ID: <8e10486b0801310923h6cce985bx4c3243de1b5b7ffd@mail.gmail.com> Date: Thu, 31 Jan 2008 14:23:36 -0300 From: "Alexandre Biancalana" To: freebsd-net@freebsd.org In-Reply-To: <20080130171826.GE41095@hal.rescomp.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0801290439y77568aeby6c6dbfbb5132f61d@mail.gmail.com> <479F4C3C.5070801@tomjudge.com> <200801301159.26641.antik@bsd.ee> <8e10486b0801300556o3dfcd25el3511b0f7845d2607@mail.gmail.com> <20080130171826.GE41095@hal.rescomp.berkeley.edu> Subject: Re: VLAN problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 17:23:37 -0000 On 1/30/08, Christopher Cowart wrote: > > Trunking is definitely what you want. I'm using it successfully > between Cisco switches and FreeBSD in a number of places. > > Here's IOS: > | interface GigabitEthernet1/0/8 > | description dev-wireless-aux > | switchport trunk encapsulation dot1q > | switchport trunk native vlan 8 > | switchport trunk allowed vlan 88,665,679 > | switchport mode trunk > | spanning-tree bpduguard enable Here is my IOS: interface GigabitEthernet3/18 description Novo FW01 switchport trunk encapsulation dot1q switchport trunk allowed vlan 2,11,16,20,200-205 switchport mode trunk > > Here's rc.conf: > | ifconfig_fxp1="up" > | ifconfig_vlan88="inet 10.8.0.2 netmask 0xffffc000 vlan 88 > | vlandev fxp1" > | ifconfig_vlan88_alias0="inet 10.8.0.1 netmask 0xffffffff" > | ifconfig_vlan665="inet 169.229.65.132 netmask 0xffffffc0 vlan 665 > | vlandev fxp1" > | ifconfig_vlan679="inet 169.229.79.132 netmask 0xffffff80 vlan 679 > | vlandev fxp1" > > You may have already done so, but make sure your trunk is in dot1q mode. > The default trunking protocol is a Cisco proprietary something, if I > understand correctly. My rc.conf is similar too... But I think that I find the problem... I setup a test environment similar to the production and to simulate the the traffic I'm using netperf, here is the environment. FW1 --- ----- M1 | | --- cisco 4506 -- | ----- M2 The FW1 is the gateway connected to cisco 4506 throught bce1 gigabit interface, on top of bce1 are configured the vlan2 and vlan5, M1 is a machine connected to vlan2 and M2 is a machine connected to vlan5. I'm running pf to filter the traffic between vlan in FW1, Here is the result when I run netperf from M5 connecting M2 netserver with FW1 pf enabled: # netperf -H 10.2.0.46 -p 1025 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.2.0.46 (10.2.0.46) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 32768 32768 17.11 8.03 Here is the result when I run netperf from M5 connecting M2 netserver with FW1 pf *disabled*: # netperf -H 10.2.0.46 -p 1025 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.2.0.46 (10.2.0.46) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 65536 32768 32768 11.45 92.35 I would expect some slow down or latency by enable pf, but not have a 10 times slow down. Any other idea ? Is Max Laier subscribed -net ? From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 19:40:26 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9360116A46B for ; Thu, 31 Jan 2008 19:40:26 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 9A44013C4EC for ; Thu, 31 Jan 2008 19:40:20 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so684668rvb.43 for ; Thu, 31 Jan 2008 11:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=dRKKLnEPdptsI+WrESjJt6Mz5JjYLCXkvHykDrXv2mg=; b=NAopZH9ieVICw3510slp5ELyx0O3mKlqMqU6qWaT3PcOMa8wEt6+yj6pAvBVwBwgb2teyfgUxo1x9INJqTFvHJrILCmidMgbOOwhf/5X5OdnDQa/c7AWABex0pPv3znuQIpnVt+ukiVQWHC8DoNbBdEjVO57mCv4JTXSWN70b0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jzjQDrO6Q2LXSj8D/nETgbIQOK1QAPPaq3nkDLBenSFMAXBJBnjz2oMv6MxxkNi7w5x6CWyf5RwhfqUN/q1YPEAR1hAHga1LeOGf1udyqzE7INaQX8HiyzpVjT6tbJSir7yqoqVrVzdIt3/nllWWJuf31UJJer5/L2l+Uc5iKVU= Received: by 10.141.13.16 with SMTP id q16mr1795102rvi.99.1201808417272; Thu, 31 Jan 2008 11:40:17 -0800 (PST) Received: by 10.141.170.18 with HTTP; Thu, 31 Jan 2008 11:40:17 -0800 (PST) Message-ID: <2e77fc10801311140i7ed440fcp9337c28b4b9aa179@mail.gmail.com> Date: Thu, 31 Jan 2008 21:40:17 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: freebsd-net@freebsd.org In-Reply-To: <2e77fc10801211326t21239b58o5b5c7604a2980543@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2e77fc10801210142g560f6f65p9908957d0c7a799e@mail.gmail.com> <2e77fc10801211326t21239b58o5b5c7604a2980543@mail.gmail.com> X-Google-Sender-Auth: 7a5abfa02e3c7dce Subject: Re: [PATCH] "/etc/rc.d/pf reload" fails if there are macros defined in pf_flags rcvar. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 19:40:26 -0000 On Jan 21, 2008 11:26 PM, Niki Denev wrote: > > On Jan 21, 2008 11:42 AM, Niki Denev wrote: > > Hi, > > > > I'm using the pf_flags rc var to set macros for pf.conf files i use in > > redundant router configuration. > > This way i can have exactly the same pf.conf on all of the routers, > > and still set host specific > > options as "hostid" used by pfsync via rc.conf > > The problem is that when i use "/etc/rc.d/pf reload" to reload the rules, > > the rc.d/pf script first executes pfctl with -n option to check the > > pf.conf syntax, but fails to include > > the $pf_flags var, and fails because of undefined macros. > > The following patch fixed this for me. > > > > --- pf.orig 2008-01-21 11:18:27.000000000 +0200 > > +++ pf 2008-01-21 11:29:56.000000000 +0200 > > @@ -50,7 +50,7 @@ > > pf_reload() > > { > > echo "Reloading pf rules." > > - $pf_program -n -f "$pf_rules" || return 1 > > + $pf_program -n -f "$pf_rules" $pf_flags || return 1 > > # Flush everything but existing state entries that way when > > # rules are read in, it doesn't break established connections. > > $pf_program -Fnat -Fqueue -Frules -FSources -Finfo -FTables > > -Fosfp > /dev/null 2>&1 > > > > > > > > -- > > Niki > > > > Just filed under misc/119874 > The patch in the PR is incomplete, this one adds $pf_flags also to pf_check() : --- pf.orig 2008-01-31 21:30:33.000000000 +0200 +++ pf 2008-01-31 21:34:23.000000000 +0200 @@ -44,13 +44,13 @@ pf_check() { echo "Checking pf rules." - $pf_program -n -f "$pf_rules" + $pf_program -n -f "$pf_rules" $pf_flags } pf_reload() { echo "Reloading pf rules." - $pf_program -n -f "$pf_rules" || return 1 + $pf_program -n -f "$pf_rules" $pf_flags || return 1 # Flush everything but existing state entries that way when # rules are read in, it doesn't break established connections. $pf_program -Fnat -Fqueue -Frules -FSources -Finfo -FTables -Fosfp > /dev/null 2>&1 -- Niki From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 21:10:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6809916A41B for ; Thu, 31 Jan 2008 21:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 656E613C4DB for ; Thu, 31 Jan 2008 21:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0VLA3YE012117 for ; Thu, 31 Jan 2008 21:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0VLA3B1012116; Thu, 31 Jan 2008 21:10:03 GMT (envelope-from gnats) Date: Thu, 31 Jan 2008 21:10:03 GMT Message-Id: <200801312110.m0VLA3B1012116@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Max Laier" Cc: Subject: Re: kern/120130: [carp] [panic] carp causes kernel panics in any constellation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Max Laier List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2008 21:10:03 -0000 The following reply was made to PR kern/120130; it has been noted by GNATS. From: "Max Laier" To: bug-followup@freebsd.org Cc: cwf-ml@arcor.de, glebius@freebsd.org Subject: Re: kern/120130: [carp] [panic] carp causes kernel panics in any constellation Date: Thu, 31 Jan 2008 22:03:46 +0100 (CET) ------=_20080131220346_45398 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Looks like rev. 1.49 of ip_carp.c needs to be MFC'ed. Patch attached, please test and report back. Thank you. -- Max ------=_20080131220346_45398 Content-Type: text/x-diff; name="carp.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="carp.diff" Index: ip_carp.c =================================================================== RCS file: /mnt/mlaier/fcvs/src/sys/netinet/ip_carp.c,v retrieving revision 1.27.2.11 diff -u -r1.27.2.11 ip_carp.c --- ip_carp.c 6 Jun 2007 16:20:50 -0000 1.27.2.11 +++ ip_carp.c 31 Jan 2008 21:00:25 -0000 @@ -1881,8 +1881,12 @@ cif = (struct carp_if *)sc->sc_carpdev->if_carp; TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) if (vr != sc && - vr->sc_vhid == carpr.carpr_vhid) - return EEXIST; + vr->sc_vhid == carpr.carpr_vhid) { + error = EEXIST; + break; + } + if (error == EEXIST) + break; } sc->sc_vhid = carpr.carpr_vhid; IFP2ENADDR(sc->sc_ifp)[0] = 0; ------=_20080131220346_45398-- From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 05:50:59 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3E6816A41A for ; Fri, 1 Feb 2008 05:50:59 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id A23A813C45B for ; Fri, 1 Feb 2008 05:50:59 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m115ow7T067118; Thu, 31 Jan 2008 21:50:59 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m115ovKk075537; Thu, 31 Jan 2008 21:50:57 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (61.204.211.246.customerlink.pwd.ne.jp [61.204.211.246]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m115ou9W023964; Thu, 31 Jan 2008 21:50:56 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Fri, 01 Feb 2008 14:50:55 +0900 Message-ID: From: gnn@freebsd.org To: Ingo Flaschberger In-Reply-To: References: <479FF09B.4050705@FreeBSD.org> <20080130083105.S36482@maildrop.int.zabbadoz.net> <47A19CC2.4070609@freebsd.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.10.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Bjoern A. Zeeb" , Andre Oppermann , "Bruce M. Simpson" , freebsd-net@freebsd.org Subject: Re: tcp-md5 check for incomming connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2008 05:50:59 -0000 At Thu, 31 Jan 2008 13:15:12 +0100 (CET), Ingo Flaschberger wrote: > > Dear Andre, > > >> 2) linux method: > >> Look for CONFIG_TCP_MD5SIG in linux-2.6.24/net/ipv4/tcp_ipv4.c > >> (sorry no weblink..) > >> They check and block md5-packets early in tcp_v4_do_rcv. > >> afinet.c -> tcp_v4_rcv -> tcp_v4_do_rcv > >> -> for Freebsd: place some logic early in tcp_input function > >> and call a new function to check md5. > > > > IMHO calling a special function that does the check (like in tcp_output) > > is the way to go. This function should be run as late as possible after > > the other segment validity checks to prevent easy cpu exhaustion attacks > > with packets that only get the port numbers right. > > > > In tcp_new there is a natural place to perform the check. tcp_input will > > show up this weekend. This doesn't prevent your work on the current code > > at all as tcp_new won't show up in -current for a long time and when it > > does it will not get MFC'd. > > Ok. > I will do the first patch for freebsd 6.2 (as my system uses it) and do > the a port to current (and I thing 6.3 too). > > Regardding Bruce: > I would prefer to implement md5 via the old setkey api as I also have todo > my daily business. > > >> 3) Bruce extended method: > >> http://lists.freebsd.org/pipermail/freebsd-net/2004-April/003761.html > >> Use his code and add at severall places in tcp_input function > >> similar checks. > >> > >> Options: > >> *) enable disable it via sysctl > >> *) count total, good and bad packets via sysctl > > > > This belongs into struct tcpstat, not a new sysctl. > > Ok. > With which tool can this counters be read? > Should I add the on/off feature? Via which tool? > Enable/disable via sysctl. Read via netstat. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 14:30:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5C6916A46E for ; Fri, 1 Feb 2008 14:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B6E6113C4D5 for ; Fri, 1 Feb 2008 14:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m11EU3Cf095450 for ; Fri, 1 Feb 2008 14:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m11EU3VT095447; Fri, 1 Feb 2008 14:30:03 GMT (envelope-from gnats) Date: Fri, 1 Feb 2008 14:30:03 GMT Message-Id: <200802011430.m11EU3VT095447@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: kern/120130: carp causes kernel panics in any constellation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2008 14:30:03 -0000 The following reply was made to PR kern/120130; it has been noted by GNATS. From: Gleb Smirnoff To: Christoph Weber-Fahr Cc: bug-followup@FreeBSD.org Subject: Re: kern/120130: carp causes kernel panics in any constellation Date: Fri, 1 Feb 2008 17:04:45 +0300 Christoph, > 2.) is is alsow possible to have a crash using only one crap interface. We > found the following script to reliably produce a kernel panic within > 15-20 minutes: > > while [ 1 ] > do > /etc/rc.d/netif restart > sleep 35 > ifconfig carp0 destroy > sleep 35 > done This reproduce recipe will be complete only if you give configuration of network interface in rc.conf. Can you supply this information, please? Also, have you tried to produce kernel coredump or at least backtrace, when kernel panics? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sat Feb 2 01:30:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5C6316A418 for ; Sat, 2 Feb 2008 01:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8EA0113C43E for ; Sat, 2 Feb 2008 01:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m121U4SM042571 for ; Sat, 2 Feb 2008 01:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m121U484042568; Sat, 2 Feb 2008 01:30:04 GMT (envelope-from gnats) Date: Sat, 2 Feb 2008 01:30:04 GMT Message-Id: <200802020130.m121U484042568@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Christoph Weber-Fahr Cc: Subject: Re: kern/120130: carp causes kernel panics in any constellation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christoph Weber-Fahr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2008 01:30:04 -0000 The following reply was made to PR kern/120130; it has been noted by GNATS. From: Christoph Weber-Fahr To: Gleb Smirnoff Cc: bug-followup@FreeBSD.org Subject: Re: kern/120130: carp causes kernel panics in any constellation Date: Sat, 02 Feb 2008 01:33:42 +0100 Hello, Gleb Smirnoff schrieb am 01.02.2008 15:04:45: > This reproduce recipe will be complete only if you give configuration > of network interface in rc.conf. Can you supply this information, please? rc.conf: ifconfig_em3="inet XX.XX.XX.XX/28 media 100baseTX mediaopt full-duplex" firewall_enable="YES" firewall_type="open" cloned_interfaces="carp0" ifconfig_carp0="vhid 20 advskew 140 pass heimLich XX.XX.XX.XY netmask 255.255.255.255" Script: #!/bin/bash while [ 1 ] do /etc/rc.d/netif restart sleep 30 ifconfig carp0 destroy sleep 30 done Crash after 10 minutes at 18:25h I append the first few lines of dmesg at the end. > Also, have you tried to produce kernel coredump or at least backtrace, > when kernel panics? No. But if you tell me what you want me to do, I could give it a try on Monday. Right now I wouldn't even know how to produce kernel dumps and backtraces. Regards Christoph Weber-Fahr dmesg: Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE #0: Fri Jan 25 21:34:42 CET 2008 root@XX.XX.XX.XX:/usr/obj/usr/src/sys/DL380 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3056.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 Logical CPUs per core: 2 real memory = 1073717248 (1023 MB) avail memory = 1041592320 (993 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 6 cpu1 (AP): APIC ID: 7 MADT: Forcing active-low polarity and level trigger for SCI From owner-freebsd-net@FreeBSD.ORG Sat Feb 2 12:18:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B036B16A419 for ; Sat, 2 Feb 2008 12:18:08 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 2498613C457 for ; Sat, 2 Feb 2008 12:18:07 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sat, 02 Feb 2008 13:06:14 +0100 id 0002E035.47A45CB6.0000A2BB From: Milan Obuch To: freebsd-net@freebsd.org Date: Sat, 2 Feb 2008 13:07:43 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802021307.44140.freebsd-net@dino.sk> Subject: Weird rc.conf problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2008 12:18:08 -0000 Hi, I am getting weird problem with network configuration. In rc.conf I have (just for demonstation, only part) ifconfig_em0="polling" cloned_interfaces="vlan2" ifconfig_vlan2="vlan 2 vlandev em0" ifconfig_vlan2_name="em0.2" Result is incorrect: em0.2: flags=8003 mtu 1500 ether 00:00:00:00:00:00 vlan: 0 parent interface: If I use ifconfig_em0="polling up" cloned_interfaces="vlan2" ifconfig_vlan2="vlan 2 vlandev em0 name em0.2" Result is correct: em0.2: flags=8003 mtu 1500 ether 00:11:22:33:44:55 vlan: 2 parent interface: em0 In the latter case I am getting some ifconfig: interface vlan2 does not exist messages in dmesg, which I was trying to avoid. This was done on 6.3-STABLE cvsupped and rebuilt some hours ago on amd64. If anybody has an idea (or a patch) I would like to test it. Error messages in the second case are a bit annoying only, not too bad, but the first config makes actually interface renaming feature with vlan interface dangerous, as the resulting configuration does not work as expected. Regards, Milan -- This address is used only for mailing list response. Do not send any personal messages to it, use milan in address instead. From owner-freebsd-net@FreeBSD.ORG Sat Feb 2 16:59:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C9DA16A417 for ; Sat, 2 Feb 2008 16:59:16 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from loki.netlab.sk (loki.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 7A2AB13C44B for ; Sat, 2 Feb 2008 16:59:15 +0000 (UTC) (envelope-from freebsd-net@dino.sk) Received: from fox.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Sat, 02 Feb 2008 17:57:22 +0100 id 0002E02F.47A4A0F2.0000ABBE From: Milan Obuch To: freebsd-net@freebsd.org Date: Sat, 2 Feb 2008 17:58:46 +0100 User-Agent: KMail/1.9.7 References: <200802021307.44140.freebsd-net@dino.sk> In-Reply-To: <200802021307.44140.freebsd-net@dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802021758.47316.freebsd-net@dino.sk> Subject: Re: Weird rc.conf problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2008 16:59:16 -0000 On Saturday 02 February 2008, Milan Obuch wrote: > Hi, > I am getting weird problem with network configuration. > > In rc.conf I have (just for demonstation, only part) > > ifconfig_em0="polling" > > cloned_interfaces="vlan2" > ifconfig_vlan2="vlan 2 vlandev em0" > ifconfig_vlan2_name="em0.2" > > Result is incorrect: > > em0.2: flags=8003 mtu 1500 > ether 00:00:00:00:00:00 > vlan: 0 parent interface: > > If I use > > ifconfig_em0="polling up" > > cloned_interfaces="vlan2" > ifconfig_vlan2="vlan 2 vlandev em0 name em0.2" > > Result is correct: > > em0.2: flags=8003 mtu 1500 > ether 00:11:22:33:44:55 > vlan: 2 parent interface: em0 > > In the latter case I am getting some > > ifconfig: interface vlan2 does not exist > > messages in dmesg, which I was trying to avoid. > It seems today is not my best, I found the simplest solution at last... All I need is just one line in rc.conf: cloned_interfaces="em0.2 em1.16 em1.28" And one line in loader.conf: if_vlan_load=YES That's it. I have no if_vlan in kernel config, this was the reason I can't find this solution, which really works like I expected. One should not mix too much old and new features I think. Milan -- This address is used only for mailing list response. Do not send any personal messages to it, use milan in address instead. From owner-freebsd-net@FreeBSD.ORG Sat Feb 2 21:22:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A0A216A418 for ; Sat, 2 Feb 2008 21:22:00 +0000 (UTC) (envelope-from lysergius2001@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.249]) by mx1.freebsd.org (Postfix) with ESMTP id 0660A13C467 for ; Sat, 2 Feb 2008 21:21:59 +0000 (UTC) (envelope-from lysergius2001@gmail.com) Received: by hs-out-2122.google.com with SMTP id h53so1615379hsh.11 for ; Sat, 02 Feb 2008 13:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=cy8cEvisyOAnepqx6FpqAdO87ON3hZMyWem/hBMtvKY=; b=HjBBBhqeFqHIIuOBCiJB+E8UItcaZkavA5p37Vsr7zeDKEnE0p1GUK5B5zwogehpxTdFM1+RAo/d3Cc9K96ONuFS5qFBi8B65WOoaO4wIL7LIBE6OzSsL3zi124UdSwaWJwTgpaq8bV3wnEpmZ+LnmJpUzAwxKTz7fDkY4x7BMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=bDhgVN4KIGikDSgjn7tPXn7KRHVXxF3E7HzddBjWR1s1OddcYzyWq81DTGuqt99l/adiy8W+NNilobS3J5A9b3KOFU7NWNQbOU1omMkyrGhNXLNckMgi83VyBikYQ1wIz100qxFVgRBUDOlWdvt6xazdjVUVu0vOpcvpMEmpTQU= Received: by 10.142.11.2 with SMTP id 2mr2873608wfk.223.1201985783772; Sat, 02 Feb 2008 12:56:23 -0800 (PST) Received: by 10.142.203.4 with HTTP; Sat, 2 Feb 2008 12:56:23 -0800 (PST) Message-ID: Date: Sat, 2 Feb 2008 20:56:23 +0000 From: lysergius2001 To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: modifying permissions in /dev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2008 21:22:00 -0000 Hi Recently installed AMD64 6.3-stable and I am having a problem with devfs.conf and /dev. I understand the entries in devfs.conf should modify the permissions on devices in /dev. For some reason or other this is not happening. Can anyone shed some light on this? What am I doing wrong? This is the core of devfs.conf # Access ATAPI CDROM own /dev/acd0 root:wheel perm /dev/acd0 0666 # Access SCSI CDROM own /dev/cd0 root:wheel perm /dev/cd0 0666 # Access floppy disk own /dev/fd0 root:wheel perm /dev/fd0 0666 # Access printer own lpt0 root:wheel perm lpt0 0660 #Access ATAPICAM devices perm xpt0 0666 perm xpt1 0666 perm pass0 0666 perm pass1 0666 # Access USB devices own /dev/da0 root:wheel perm /dev/da* 0666 Thanks -- Lysergius says "Stay light and trust gravity" From owner-freebsd-net@FreeBSD.ORG Sat Feb 2 22:19:49 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C35416A421 for ; Sat, 2 Feb 2008 22:19:49 +0000 (UTC) (envelope-from oskar-FreeBSD@eyb.de) Received: from beastie.eyb.de (beastie.eyb.de [85.214.103.56]) by mx1.freebsd.org (Postfix) with ESMTP id 59E5F13C468 for ; Sat, 2 Feb 2008 22:19:48 +0000 (UTC) (envelope-from oskar-FreeBSD@eyb.de) Received: from chuck.ath.cx (dslb-088-067-045-006.pools.arcor-ip.net [88.67.45.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by beastie.eyb.de (Postfix) with ESMTP id 924C78B798C for ; Sat, 2 Feb 2008 23:02:30 +0100 (CET) Received: from [10.0.0.3] (saturn.intra.eyb.de [10.0.0.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chuck.ath.cx (Postfix) with ESMTP id 94C6711852E0 for ; Sat, 2 Feb 2008 23:03:53 +0100 (CET) Message-ID: <47A4E868.7000500@eyb.de> Date: Sat, 02 Feb 2008 23:02:16 +0100 From: Oskar Eyb User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: syncache_timer: Response timeout and other msgs, whats up? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2008 22:19:49 -0000 Hello! A remote MTA cannot deliver me any email. the admin gets the following errors: "retry time not reached for any host after a long failure period" and "retry timeout exceeded". After I cant find anything related to this server in my postfix log, I grep'ed for in /var/log/* and got the following hits: [...] dmesg.yesterday:TCP: [85.214.42.62]:43127 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK dmesg.yesterday:TCP: [85.214.42.62]:43127 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK dmesg.yesterday:TCP: [85.214.42.62]:43127 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (2) SYN|ACK dmesg.yesterday:TCP: [85.214.42.62]:43127 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (3) SYN|ACK dmesg.yesterday:TCP: [85.214.42.62]:43127 to [172.16.0.2]:25; syncache_timer: Retransmits exhausted, giving up and removing syncache entry 85.214.42.62 is the other MTA, 172.16.0.2 is my jail. I use PF with rdr/nat on FreeBSD 7 RC4. in the daily security email I get dozens of messages like this, also to other tcp ports (e.g. 80) default-values for: net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 Can anybody help me out of this? Greets, Oskar +TCP: [58.182.131.11]:4216 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4216 to [172.16.0.2]:25 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4216 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4217 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4217 to [172.16.0.2]:25 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4217 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4218 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4218 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4219 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4219 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4220 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4220 to [172.16.0.2]:25 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4220 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4221 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4221 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4222 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4222 to [172.16.0.2]:25 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4222 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4223 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4223 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4224 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4224 to [172.16.0.2]:25 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4224 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4225 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4225 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4226 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4226 to [172.16.0.2]:25 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4226 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4227 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4227 to [172.16.0.2]:25 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4227 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4228 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4228 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4229 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4230 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4231 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4232 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4230 to [172.16.0.2]:25 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4231 to [172.16.0.2]:25 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4234 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4234 to [172.16.0.2]:25 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4234 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4235 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4235 to [172.16.0.2]:25 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4235 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4236 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4236 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [58.182.131.11]:4233 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [58.182.131.11]:4233 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 6 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [58.182.131.11]:4233 to [172.16.0.2]:25 tcpflags 0x18; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +Connection attempt to UDP 172.16.0.2:57897 from 85.214.103.56:53 +Connection attempt to UDP 172.16.0.2:60521 from 85.214.103.56:53 +TCP: [59.189.18.5]:1332 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [59.189.18.5]:1332 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [59.189.18.5]:1332 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [59.189.18.5]:1332 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [59.189.18.5]:1332 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (2) SYN|ACK +TCP: [59.189.18.5]:1332 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (3) SYN|ACK +TCP: [59.189.18.5]:1700 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [59.189.18.5]:1700 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [59.189.18.5]:1700 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [59.189.18.5]:1700 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [59.189.18.5]:1332 to [172.16.0.2]:25; syncache_timer: Retransmits exhausted, giving up and removing syncache entry +TCP: [59.189.18.5]:1700 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [59.189.18.5]:1700 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (2) SYN|ACK +TCP: [59.189.18.5]:1700 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (3) SYN|ACK +Connection attempt to UDP 85.214.103.56:57111 from 88.191.254.7:53 +TCP: [59.189.18.5]:2189 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [83.40.210.36]:27836 to [172.16.0.2]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored +TCP: [59.189.18.5]:2189 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [59.189.18.5]:1700 to [172.16.0.2]:25; syncache_timer: Retransmits exhausted, giving up and removing syncache entry +TCP: [59.189.18.5]:2189 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [59.189.18.5]:2189 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [59.189.18.5]:2189 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (2) SYN|ACK +TCP: [59.189.18.5]:2189 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (3) SYN|ACK +TCP: [213.5.169.184]:62636 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [213.5.169.184]:62636 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [213.5.169.184]:62636 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [213.5.169.184]:62636 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [59.189.18.5]:2189 to [172.16.0.2]:25; syncache_timer: Retransmits exhausted, giving up and removing syncache entry +TCP: [213.5.169.184]:62636 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (2) SYN|ACK +TCP: [213.5.169.184]:62636 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (3) SYN|ACK +TCP: [193.43.150.242]:60772 to [85.214.103.56]:22 tcpflags 0x2; tcp_input: Connection attempt to closed port +Connection attempt to UDP 172.16.0.2:59259 from 85.214.103.56:53 +Connection attempt to UDP 172.16.0.2:52025 from 85.214.103.56:53 +TCP: [213.5.169.184]:62636 to [172.16.0.2]:25; syncache_timer: Retransmits exhausted, giving up and removing syncache entry +TCP: [64.237.204.59]:64347 to [172.16.0.2]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored +Connection attempt to UDP 172.16.0.2:49575 from 85.214.103.56:53 +Connection attempt to UDP 172.16.0.2:49201 from 85.214.103.56:53 +Connection attempt to UDP 172.16.0.2:53140 from 85.214.103.56:53 +Connection attempt to UDP 172.16.0.2:60597 from 85.214.103.56:53 +TCP: [209.223.48.146]:36342 to [172.16.0.2]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored +TCP: [189.132.247.46]:3006 to [172.16.0.2]:25 tcpflags 0x14; syncache_chkrst: Spurious RST with ACK, SYN or FIN flag set, segment ignored +TCP: [190.142.56.104]:1990 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [190.142.56.104]:1990 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [190.142.56.104]:2350 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [72.52.143.18]:38333 to [172.16.0.2]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored +TCP: [65.19.179.9]:1973 to [172.16.0.2]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored +TCP: [88.67.29.27]:62531 to [172.16.0.2]:25 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [88.67.29.27]:62531 to [172.16.0.2]:25 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) +TCP: [195.4.92.9]:25 to [172.16.0.2]:57654 tcpflags 0x18; tcp_do_segment: FIN_WAIT_1: Received 69 bytes of data after socket was closed, sending RST and removing tcpcb +TCP: [213.133.109.71]:47054 to [172.16.0.2]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored +TCP: [202.164.234.72]:3775 to [172.16.0.2]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored +TCP: [207.217.120.84]:54387 to [172.16.0.2]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored +TCP: [207.217.120.84]:54387 to [172.16.0.2]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored +TCP: [220.226.52.141]:3655 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [220.226.52.141]:3655 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [220.226.52.141]:3655 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK +TCP: [220.226.52.141]:3655 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [217.255.195.182]:61347 to [172.16.0.2]:25 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored +TCP: [220.226.52.141]:4446 to [172.16.0.2]:25; syncache_timer: Response timeout, retransmitting (1) SYN|ACK +TCP: [220.226.52.141]:4446 to [172.16.0.2]:25 tcpflags 0x2; syncache_add: Received duplicate SYN, resetting timer and retransmitting SYN|ACK