From owner-freebsd-net@FreeBSD.ORG Sun Dec 5 02:30:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2255B16A4CE; Sun, 5 Dec 2004 02:30:33 +0000 (GMT) Received: from ford.blinkenlights.nl (handtekeningenactie.lelystedeling.nl [213.204.211.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 765EF43D41; Sun, 5 Dec 2004 02:30:32 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from tea.blinkenlights.nl (tea.blinkenlights.nl [192.168.1.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ford.blinkenlights.nl (Postfix) with ESMTP id 750BE3E434; Sun, 5 Dec 2004 03:30:30 +0100 (CET) Received: by tea.blinkenlights.nl (Postfix, from userid 101) id E8E1125F; Sun, 5 Dec 2004 03:30:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tea.blinkenlights.nl (Postfix) with ESMTP id D0B3C2E; Sun, 5 Dec 2004 03:30:29 +0100 (CET) Date: Sun, 5 Dec 2004 03:30:29 +0100 (CET) From: Sten Spans To: "Bjoern A. Zeeb" In-Reply-To: Message-ID: References: <344de28704120412333e70fb76@mail.gmail.com> <344de28704120413306b410608@mail.gmail.com> <41B23C51.5B4207AC@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org cc: Andre Oppermann Subject: Re: INADDR_ANY bind in a multiip jail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2004 02:30:33 -0000 On Sat, 4 Dec 2004, Bjoern A. Zeeb wrote: > On Sat, 4 Dec 2004, Andre Oppermann wrote: > >>> i just found a patch from Pawel Jakub Dawidek(mijail5) which do not > ... >> Do you have a link? I'd like to have a look at the code. > > http://garage.freebsd.pl/ This code is borken on 5.3, because of mfc's. There is a somewhat fixed version at: http://blog.mombe.org/data/systems/mijail5.asis which seems to function reasonably. Although the site which hosts it is quite hard to reach. I use this patch to run webservers with vrrp redundant ip's, and apache with multiple ip's ( ssl ) in a jail. Aka, I have multiple active ips in apache, but not all of them active on each box which basically means inaddr_any. And I do have a need for jailing user scripting ( evil suexec-like tricks ). The inaddr_any need can be "fixed" with ips on loopback, and some routing or natd tricks. And one could run a seperate apache for each ip. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From owner-freebsd-net@FreeBSD.ORG Sun Dec 5 13:50:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9479316A4CE for ; Sun, 5 Dec 2004 13:50:08 +0000 (GMT) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 048D343D2D for ; Sun, 5 Dec 2004 13:50:04 +0000 (GMT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with SMTP id AAA16102; Mon, 6 Dec 2004 00:49:56 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 6 Dec 2004 00:49:55 +1100 (EST) From: Ian Smith To: Chuck Swiger In-Reply-To: <41B1CC8A.6090509@mac.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: ipfw and bridging [was: pf and bridging] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2004 13:50:08 -0000 On Sat, 4 Dec 2004, Chuck Swiger wrote: > Ian Smith wrote: > [ ... ] > > Read those ones for interest, but it leaves me wondering: can you use > > stateful filtering in ipfw, then? (here ipfw1 on a 4.8-RELEASE box with > > BRIDGE in kernel so far, but I imagine this would apply also to ipfw2?) > > Yes, you ought to be able to perform stateful packet filtering with either > ipfw1 or 2. Thanks for that, Chuck. It did seem to be working, so I'd assumed that ipfw stateful inspection must only be on inbound packets, for bridged packets at least. > > I'm aware that one can only filter incoming packets, so I've always > > wondered whether stateful rules made any sense in a bridge context? > > A firewall filters packets which pass through it (ie, either via routing, > bridging, or whatever the topology is). Yes, you can do stateful filtering on > a bridge but you need to pay attention to the fact that you have both layer-2 > and layer-3 traffic involved. You also need to enable a sysctl to have IPFW > apply its rules to bridged traffic. Indeed. Now I'm curious; must find some time to look at the code a bit. Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sun Dec 5 19:09:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0635516A4CE; Sun, 5 Dec 2004 19:09:31 +0000 (GMT) Received: from ithil.ics.muni.cz (ithil.ics.muni.cz [147.251.4.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27B3843D39; Sun, 5 Dec 2004 19:09:30 +0000 (GMT) (envelope-from hopet@ics.muni.cz) Received: from KLOBOUCEK (kloboucek.ics.muni.cz [147.251.3.38]) (user=hopet@META mech=LOGIN bits=0) by ithil.ics.muni.cz (8.12.1/8.12.1) with ESMTP id iB5J9Sgu006394 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 5 Dec 2004 20:09:28 +0100 From: "Petr Holub" To: "Andre Oppermann" , "Max Laier" Date: Sun, 5 Dec 2004 20:09:29 +0100 Message-ID: <05c101c4dafd$f24166d0$2603fb93@KLOBOUCEK> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <41B23352.2E07D115@freebsd.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Muni-Spam-TestIP: 147.251.3.38 X-Muni-Virus-Test: Clean cc: freebsd-net@freebsd.org Subject: RE: pf and bridging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2004 19:09:31 -0000 > I'll do the Layer 2 ipfw pfil_hook conversion next when I've finished > the rewrite of TCP reassembly in a few days. That's a great news! I've reported Max privately, that I've experimentally verified Daniele's comments in > > http://lists.freebsd.org/pipermail/freebsd-pf/2004-December/000631.html so that after resolving the issue with invisible outbound packets, it might work just perfectly. Petr ================================================================ Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZ Masaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: Petr.Holub@cesnet.cz phone: +420-549493944 fax: +420-541212747 e-mail: hopet@ics.muni.cz From owner-freebsd-net@FreeBSD.ORG Mon Dec 6 11:02:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB4F816A4F7 for ; Mon, 6 Dec 2004 11:02:24 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD02943D4C for ; Mon, 6 Dec 2004 11:02:24 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iB6B2OOW027395 for ; Mon, 6 Dec 2004 11:02:24 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iB6B2OUr027389 for freebsd-net@freebsd.org; Mon, 6 Dec 2004 11:02:24 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 6 Dec 2004 11:02:24 GMT Message-Id: <200412061102.iB6B2OUr027389@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 11:02:25 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 6 11:36:00 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FC3616A4CE; Mon, 6 Dec 2004 11:36:00 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DB8843D5A; Mon, 6 Dec 2004 11:36:00 +0000 (GMT) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iB6BZxBO035915; Mon, 6 Dec 2004 11:35:59 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iB6BZxIt035911; Mon, 6 Dec 2004 11:35:59 GMT (envelope-from andre) Date: Mon, 6 Dec 2004 11:35:59 GMT From: Andre Oppermann Message-Id: <200412061135.iB6BZxIt035911@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org Subject: Re: kern/24959: proper TCP_NOPUSH/TCP_CORK compatibility X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 11:36:00 -0000 Synopsis: proper TCP_NOPUSH/TCP_CORK compatibility Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Mon Dec 6 11:35:38 GMT 2004 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=24959 From owner-freebsd-net@FreeBSD.ORG Mon Dec 6 11:55:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0398416A4CE for ; Mon, 6 Dec 2004 11:55:16 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3877443D48 for ; Mon, 6 Dec 2004 11:55:14 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id iB6BsBZg020394 for ; Mon, 6 Dec 2004 22:24:11 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Mon, 6 Dec 2004 22:25:07 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id iB6BkjQ29768 for ; Mon, 6 Dec 2004 22:16:45 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK36FXWQ; Mon, 6 Dec 2004 22:16:34 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id iB6BkkS8001157 for ; Mon, 6 Dec 2004 22:16:46 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id iB6Bkkij001156 for freebsd-net@freebsd.org; Mon, 6 Dec 2004 22:16:46 +1030 (CST) (envelope-from wilkinsa) Date: Mon, 6 Dec 2004 22:16:46 +1030 From: "Wilkinson, Alex" To: freebsd-net@freebsd.org Message-ID: <20041206114646.GD999@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-net@freebsd.org References: <20041115222310.GA93130@scylla.towardex.com> <41B1EB4E.78490459@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <41B1EB4E.78490459@freebsd.org> User-Agent: Mutt/1.5.6i Subject: Re: Initial review request for IPv6 Fast Forwarding and IP6STEALTH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 11:55:16 -0000 0n Sat, Dec 04, 2004 at 05:52:30PM +0100, Andre Oppermann wrote: > Nice, needs some cleanup though. Once you have cleaned it up you can run > it either through me or gnn@. He is more of a IPv6 fan than I am (in my > book IPv6 is broken by design^TM). Why ? - aW From owner-freebsd-net@FreeBSD.ORG Mon Dec 6 13:44:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D24816A4CE; Mon, 6 Dec 2004 13:44:43 +0000 (GMT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0940143D1D; Mon, 6 Dec 2004 13:44:43 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (unknown [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id A3720C035; Mon, 6 Dec 2004 14:44:41 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 56798412C; Mon, 6 Dec 2004 14:43:16 +0100 (CET) Date: Mon, 6 Dec 2004 14:43:15 +0100 From: Jeremie Le Hen To: Andre Oppermann Message-ID: <20041206134315.GF79919@obiwan.tataz.chchile.org> References: <20041129100949.GA19560@bps.jodocus.org> <41AAF696.6ED81FBF@freebsd.org> <20041129103031.GA19828@bps.jodocus.org> <41AB3A74.8C05601D@freebsd.org> <20041129174954.GA26532@bps.jodocus.org> <41AB65B2.A18534BF@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41AB65B2.A18534BF@freebsd.org> User-Agent: Mutt/1.5.6i cc: Joost Bekkers cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order for outgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 13:44:43 -0000 > > > > I have some stuff wrt [Fast]IPSEC and your problem in the works and > > > > it should become ready around christmas time (loadable [Fast]IPSEC, at > > > > least for IPv4). > > > > > > While this way of 'fixing' the IPSEC problem works it is rather gross > > > and not very stylish. I prefer not to have this in the tree as makes > > > maintainance a lot harder. > > > > I totaly agree that it is not pretty. I was trying to avoid duplicating > > the code (so every change would have to be made twice) and making it a > > function didn't sit right for some reason. Hints/tips for dealing with > > this kind of situation are welcome, but maybe better off-list. > > As things currently are with IPSEC code weaved directly into ip_input() > and ip_output() there is no better way than what you have proposed. > > It will solve it much more nicely. :) If I understand correctly, either Joost's patch or your nice changes that-should-appear-before-christmas will achieve what the OpenBSD enc(4) interface provides [1]. It would be really wonderful. But I may be missing something because I can see no way in firewall rules to distinguish between the before IPSec processing hook and the after IPSec processing one. Could you clarify this for me please ? Thanks in advance. Best regards, -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-net@FreeBSD.ORG Mon Dec 6 14:32:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 798CD16A4CE for ; Mon, 6 Dec 2004 14:32:22 +0000 (GMT) Received: from gatekeeper.syskonnect.de (gatekeeper.syskonnect.de [213.144.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7F5043D2F for ; Mon, 6 Dec 2004 14:32:21 +0000 (GMT) (envelope-from gheinig@syskonnect.de) Received: from syskonnect.de (skd.de [10.9.15.1])iB6EWjcx026085 for ; Mon, 6 Dec 2004 15:32:45 +0100 (MET) Received: from syskonnect.de (localhost [127.0.0.1]) by syskonnect.de (8.12.11/8.12.11) with ESMTP id iB6EWK8x008553 for ; Mon, 6 Dec 2004 15:32:20 +0100 (MET) Message-ID: <41B46D6D.7080702@syskonnect.de> Date: Mon, 06 Dec 2004 15:32:13 +0100 From: Gerald Heinig User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: ping counter overflow X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 14:32:22 -0000 Hi all, I've run into a possible bug in ping(8) while investigating a strange duplicate packet effect in our driver. The effect shows up on other drivers and I believe it's due to a counter overflow in ping. Basically, leave ping -f on a gigabit link for a few days (for medium to large values of "a few", ie. at least 3 or 4). Stop the ping and get lots of duplicate packets. I changed the 5 counter variables (nmissedmax, npackets, nreceived, nrepeats, ntransmitted) to short (from long) to reduce the time taken to overflow and managed to get the effect very easily - it takes about 3 seconds on a gigabit link. Changing these variables to their unsigned counterparts solved the problem. My question: shouldn't these counters be unsigned? (ie. unsigned long, instead of long) Regards, Gerald From owner-freebsd-net@FreeBSD.ORG Mon Dec 6 16:13:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E06E016A4CE for ; Mon, 6 Dec 2004 16:13:41 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 046F443D67 for ; Mon, 6 Dec 2004 16:13:41 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])iB6GDddg014814; Mon, 6 Dec 2004 18:13:39 +0200 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) iB6GDaTR091667; Mon, 6 Dec 2004 18:13:36 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost)iB6GDZLq091666; Mon, 6 Dec 2004 18:13:35 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 6 Dec 2004 18:13:35 +0200 From: Giorgos Keramidas To: Gerald Heinig Message-ID: <20041206161335.GA91583@orion.daedalusnetworks.priv> References: <41B46D6D.7080702@syskonnect.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B46D6D.7080702@syskonnect.de> cc: freebsd-net@freebsd.org Subject: Re: ping counter overflow X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 16:13:42 -0000 On 2004-12-06 15:32, Gerald Heinig wrote: > Hi all, > > I've run into a possible bug in ping(8) while investigating a strange > duplicate packet effect in our driver. > The effect shows up on other drivers and I believe it's due to a counter > overflow in ping. > Basically, leave ping -f on a gigabit link for a few days (for medium to > large values of "a few", ie. at least 3 or 4). Stop the ping and get > lots of duplicate packets. > I changed the 5 counter variables (nmissedmax, npackets, nreceived, > nrepeats, ntransmitted) to short (from long) to reduce the time taken to > overflow and managed to get the effect very easily - it takes about 3 > seconds on a gigabit link. > Changing these variables to their unsigned counterparts solved the problem. > My question: shouldn't these counters be unsigned? (ie. unsigned long, > instead of long) They can probably be switched to uint64_t too. I'm not sure how much time this will buy us though on links with so very high speeds. A quick calculation with a link that can push 8 Mpps indicates it will take a few dozen thousands of years to overflow a 64-bit counter, unless my Python-foo has failed me: >>> (2**64) / (365*24*3600*8000000) 73117L From owner-freebsd-net@FreeBSD.ORG Mon Dec 6 17:21:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34BC316A4CE for ; Mon, 6 Dec 2004 17:21:02 +0000 (GMT) Received: from smtp2.jazztel.es (smtp2.jazztel.es [62.14.3.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FBB743D6A for ; Mon, 6 Dec 2004 17:21:01 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from antivirus by smtp2.jazztel.es with antivirus id 1CbMXi-0001qQ-00 Mon, 06 Dec 2004 18:20:58 +0100 Received: from [212.106.236.196] (helo=rguez.homeunix.net) by smtp2.jazztel.es with esmtp id 1CbMXi-0001pp-00 Mon, 06 Dec 2004 18:20:58 +0100 Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) by rguez.homeunix.net (8.13.1/8.13.1) with ESMTP id iB6HKx9S002300; Mon, 6 Dec 2004 18:20:59 +0100 (CET) (envelope-from freebsd@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.1/8.13.1/Submit) id iB6HL6KG000980; Mon, 6 Dec 2004 18:21:06 +0100 (CET) (envelope-from freebsd@redesjm.local) From: Jose M Rodriguez To: freebsd-net@freebsd.org, netch@lucky.net Date: Mon, 6 Dec 2004 18:21:05 +0100 User-Agent: KMail/1.7.1 References: <20041126125758.T21747@superior.local.non-standard.net> <20041204221900.GB18236@lucky.net> In-Reply-To: <20041204221900.GB18236@lucky.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200412061821.05928.freebsd@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1; AVE: 6.28.0.19; VDF: 6.28.0.104; host: antares.redesjm.local) X-Virus-Scanned: by antivirus cc: Anthony Volodkin Subject: Re: FreeBSD kernel pppd - mppe/mschapv1/2/radius support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 17:21:02 -0000 El S=E1bado, 4 de Diciembre de 2004 23:19, Valentin Nechayev escribi=F3: > Fri, Nov 26, 2004 at 13:24:31, anthonyv wrote about "FreeBSD kernel=20 pppd - mppe/mschapv1/2/radius support": > > After extensively googling FreeBSD pppd's support for mppe, > > mschapv1, mschapv2 and radius, I've stumbled into a mess of patches > > for very random versions of pppd and FreeBSD. > > Does anyone have a running setup of FreeBSD's pppd with support for > > these features, or perhaps a patch that encompasses all of these > > features, making a complete solution? > > If not, any comments on the matter are still appreciated. (And > > yes, I've tried mpd and user-ppp, but neither one suits my needs > > sufficiently) > > MPPE isn't possible due to lack of support in kernel for PPP terminal > discipline. > For others, you can use port (net/pppd23) as base. This is the most > reasonable variant now (2.4 aren't ported to *BSD, 2.3.11 is last > 2.3) > Not really, NetBSD pppd is 2.4 based. =2D- josemi From owner-freebsd-net@FreeBSD.ORG Mon Dec 6 19:21:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F331616A4CE for ; Mon, 6 Dec 2004 19:21:22 +0000 (GMT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAB3843D69 for ; Mon, 6 Dec 2004 19:21:22 +0000 (GMT) (envelope-from niyamas@gmail.com) Received: by mproxy.gmail.com with SMTP id q44so67696cwc for ; Mon, 06 Dec 2004 11:20:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=tPsWd1YiyqQqyMmtDax6jdTR8k5HCcvD+oy1alozAbuUI0OpxRfvRpbCgwLjA9TWNBdfvfnZlAEv7B31xqkGdYjNDZpBUYeci16FVrcvEeCAWZWBXB/So3CoE9qvKcBmH2IUvBNqZNmNoR9WJMYDdagdXhp60yy/jfKj6C6RWOM= Received: by 10.11.99.55 with SMTP id w55mr371919cwb; Mon, 06 Dec 2004 11:20:52 -0800 (PST) Received: by 10.11.94.31 with HTTP; Mon, 6 Dec 2004 11:20:52 -0800 (PST) Message-ID: <4f9c6b6d04120611206e86dcdc@mail.gmail.com> Date: Mon, 6 Dec 2004 14:20:52 -0500 From: NiY To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Load Balancing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Niy@extacy.homeip.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 19:21:23 -0000 Greetings! I have yet to find a definitive answer on this subject, so I was hoping someone would let me know the official way to go about this, or if it's even possible. We have two ADSL services coming into out building. We would like to use them both on one network, using a multi-homed FreeBSD box, if possible. So the scenario would like this. ADSL1----\ / -- Host Freebsd Load Balancer / NATD ---- Switch -- Host ADSL2----/ \ --Host Can it be done? From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 02:59:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B6FE16A4CF for ; Tue, 7 Dec 2004 02:59:18 +0000 (GMT) Received: from web42103.mail.yahoo.com (web42103.mail.yahoo.com [66.218.93.196]) by mx1.FreeBSD.org (Postfix) with SMTP id 9EFEA43D6A for ; Tue, 7 Dec 2004 02:59:17 +0000 (GMT) (envelope-from toddcook41@yahoo.com) Received: (qmail 43857 invoked by uid 60001); 7 Dec 2004 02:59:17 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=eCEnW4EnWIVZGXpSVKwJ6jQpeaeMKvF6fTzSiNMp6U/SjHzPWx4ukzQ+9etNqvxpmO6z+/wgUkiGzQcDo95v+X1off5Q2Tfyq7KlLcu8yxsTBSAk50JLnt0XAUHh5tIAljABUBzu9RsukzDfQutasZ63MVyxzdGZ5yY8F0bvHVM= ; Message-ID: <20041207025917.43855.qmail@web42103.mail.yahoo.com> Received: from [68.49.148.23] by web42103.mail.yahoo.com via HTTP; Mon, 06 Dec 2004 18:59:17 PST Date: Mon, 6 Dec 2004 18:59:17 -0800 (PST) From: asdfasdfasd asdfds To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: TCPDUMP bandwidth capability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 02:59:18 -0000 Hello, For those who use TCPDUMP, how much bandwidth have you been able to monitor with it without dropping packets? I'm considering putting some new servers running BSD in place purely for sniffing capability, and am quite content with TCPDUMP, but it won't be a very wise investment if I start losing packets at, say, 100Mbps. I've seen it said that BSD is much better for this type of thing than Linux, but numbers are heard to come by. Right the right NICs and processing power, is line-rate 1Gbps possible? Thanks, Todd __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 07:24:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C86BE16A4CE for ; Tue, 7 Dec 2004 07:24:39 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 333F843D1F for ; Tue, 7 Dec 2004 07:24:38 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id iB77N8Z0003004; Tue, 7 Dec 2004 09:23:09 +0200 (EET) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.12.11/8.12.11/Submit) id iB77N7Ua002997; Tue, 7 Dec 2004 09:23:07 +0200 (EET) (envelope-from netch) Date: Tue, 7 Dec 2004 09:23:07 +0200 From: Valentin Nechayev To: Jose M Rodriguez Message-ID: <20041207072307.GJ3080@lucky.net> References: <20041126125758.T21747@superior.local.non-standard.net> <20041204221900.GB18236@lucky.net> <200412061821.05928.freebsd@redesjm.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412061821.05928.freebsd@redesjm.local> X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) X-Antivirus: Dr.Web (R) for Mail Servers on kozlik.carrier.kiev.ua host X-Antivirus-Code: 100000 cc: Anthony Volodkin cc: freebsd-net@freebsd.org Subject: Re: FreeBSD kernel pppd - mppe/mschapv1/2/radius support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 07:24:39 -0000 Mon, Dec 06, 2004 at 18:21:05, josemi wrote about "Re: FreeBSD kernel pppd - mppe/mschapv1/2/radius support": >> MPPE isn't possible due to lack of support in kernel for PPP terminal >> discipline. >> For others, you can use port (net/pppd23) as base. This is the most >> reasonable variant now (2.4 aren't ported to *BSD, 2.3.11 is last >> 2.3) > Not really, NetBSD pppd is 2.4 based. Thank for information; I were watching only for central distribution (on samba.org). If porting NetBSD's one, it can help in most listed features. -netch- From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 08:43:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FCA216A4CE for ; Tue, 7 Dec 2004 08:43:21 +0000 (GMT) Received: from poison2.syncrontech.com (adsl-nat.syncrontech.com [213.28.98.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id A665643D55 for ; Tue, 7 Dec 2004 08:43:19 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57])iB78hDOe054231; Tue, 7 Dec 2004 10:43:13 +0200 (EET) (envelope-from ari@suutari.iki.fi) Received: from coffee (coffee.syncrontech.com [62.71.8.37]) iB78hFwk011627; Tue, 7 Dec 2004 10:43:16 +0200 (EET) (envelope-from ari@suutari.iki.fi) Message-ID: <01a801c4dc38$c59b8700$2508473e@sad.syncrontech.com> From: "Ari Suutari" To: "Jeremie Le Hen" References: <20041129100949.GA19560@bps.jodocus.org><41AAF696.6ED81FBF@freebsd.org> <20041129103031.GA19828@bps.jodocus.org><41AB3A74.8C05601D@freebsd.org> <20041129174954.GA26532@bps.jodocus.org><41AB65B2.A18534BF@freebsd.org> <20041206134315.GF79919@obiwan.tataz.chchile.org> Date: Tue, 7 Dec 2004 10:43:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order foroutgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 08:43:21 -0000 Hi, > But I may be > missing something because I can see no way in firewall rules to > distinguish between the before IPSec processing hook and the after IPSec > processing one. Could you clarify this for me please ? There is a keyword "ipsec" in ipfw2, which matches if packet has emerged from ipsec tunnel. To match packet before ipsec stack, use protocol esp/ah in ipfw rule. To match packet after ipsec stack, use tcp/udp/ip as protocol and "ipsec" keyword. The problem is that this doesn't work for outgoing packets, which breaks at least statefull rules. Ari S. From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 10:06:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C3D516A4CE for ; Tue, 7 Dec 2004 10:06:55 +0000 (GMT) Received: from mail.loyalness.com (ns1.orgazma.org [84.94.229.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2CB043D66 for ; Tue, 7 Dec 2004 10:06:53 +0000 (GMT) (envelope-from sody@royalshells.com) Received: from localhost (unknown [127.0.0.1]) by mail.loyalness.com (Postfix) with ESMTP id 1B60636 for ; Tue, 7 Dec 2004 13:13:36 +0000 (GMT) Received: from mail.loyalness.com ([127.0.0.1]) by localhost (loyalness.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 92299-03 for ; Tue, 7 Dec 2004 13:13:33 +0000 (GMT) Received: from loyalness.com (localhost [127.0.0.1]) by mail.loyalness.com (Postfix) with ESMTP id 81C5035 for ; Tue, 7 Dec 2004 13:13:33 +0000 (GMT) Received: (from sody@localhost) by loyalness.com (8.12.9p2/8.12.9/Submit) id iB7DDWo3094709; Tue, 7 Dec 2004 13:13:32 GMT (envelope-from sody@royalshells.com) Date: Tue, 7 Dec 2004 13:13:32 GMT X-Authentication-Warning: loyalness.com: sody set sender to sody@royalshells.com using -f From: "RoyalShells Admin" To: freebsd-net@freebsd.org Cc: X-Originating-IP: 128.139.226.34 X-Mailer: Usermin 1.070 Message-Id: <1102425212.94706@loyalness.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1102425212" X-Virus-Scanned: by amavisd-new at royalshells.com Subject: WATCHING DDOS ATTACKS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 10:06:55 -0000 This is a multi-part message in MIME format. --bound1102425212 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, I have problem with D.o.S and DD.o.S attacks. I wonder if someone already wrote/know about a module that works like pop_before_smtp, it watches /var/log/security and if it sees that in the past 30 seconds many packets were received to an IP it unbinds its (ifconfig em0 ip delete), and tracks the list of unbounded IPs, tries to readd the IP again after 5 minutes (for example). Thanks in advance, Sami --bound1102425212-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 10:09:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2451F16A4CE for ; Tue, 7 Dec 2004 10:09:29 +0000 (GMT) Received: from mail.loyalness.com (ns1.orgazma.org [84.94.229.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDEAF43D62 for ; Tue, 7 Dec 2004 10:09:28 +0000 (GMT) (envelope-from sody@royalshells.com) Received: from localhost (unknown [127.0.0.1]) by mail.loyalness.com (Postfix) with ESMTP id 5FF1836 for ; Tue, 7 Dec 2004 13:16:11 +0000 (GMT) Received: from mail.loyalness.com ([127.0.0.1]) by localhost (loyalness.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 94568-01 for ; Tue, 7 Dec 2004 13:16:09 +0000 (GMT) Received: from loyalness.com (localhost [127.0.0.1]) by mail.loyalness.com (Postfix) with ESMTP id C5D8635 for ; Tue, 7 Dec 2004 13:16:09 +0000 (GMT) Received: (from sody@localhost) by loyalness.com (8.12.9p2/8.12.9/Submit) id iB7DG8xP094903; Tue, 7 Dec 2004 13:16:08 GMT (envelope-from sody@royalshells.com) Date: Tue, 7 Dec 2004 13:16:08 GMT X-Authentication-Warning: loyalness.com: sody set sender to sody@royalshells.com using -f From: "Sami" To: freebsd-net@freebsd.org Cc: X-Originating-IP: 128.139.226.34 X-Mailer: Usermin 1.070 Message-Id: <1102425368.94900@loyalness.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bound1102425368" X-Virus-Scanned: by amavisd-new at royalshells.com Subject: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 10:09:29 -0000 This is a multi-part message in MIME format. --bound1102425368 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, (sorry for last long mail) I have problem with D.o.S and DD.o.S attacks. I wonder if someone already wrote/know about a module that works like pop_before_smtp, it watches /var/log/security and if it sees that in the past 30 seconds many packets were received to an IP it unbinds its (ifconfig em0 ip delete), and tracks the list of unbounded IPs, tries to readd the IP again after 5 minutes (for example). Thanks in advance, Sami --bound1102425368-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 13:31:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B5A016A4CE; Tue, 7 Dec 2004 13:31:22 +0000 (GMT) Received: from blah.sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE3EE43D6E; Tue, 7 Dec 2004 13:31:21 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: by blah.sun-fish.com (Postfix, from userid 599) id D57E43418B; Tue, 7 Dec 2004 14:31:17 +0100 (CET) Received: from sun-fish.com (fs.cmotd.com [192.168.3.253]) by blah.sun-fish.com (Postfix) with ESMTP id BBC1C3415A; Tue, 7 Dec 2004 14:31:17 +0100 (CET) Received: from sun-fish.com (localhost.cmotd.com [127.0.0.1]) by sun-fish.com (Postfix) with ESMTP id 48C3E38408; Tue, 7 Dec 2004 14:27:02 +0100 (CET) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id D6B6038404; Tue, 7 Dec 2004 14:27:01 +0100 (CET) Date: Tue, 7 Dec 2004 15:31:17 +0200 From: Vladimir Terziev To: hackers@freebsd.org, net@freebsd.org Message-Id: <20041207153117.536b9399@daemon.cmotd.com> Organization: SunFish Ltd., Sofia X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-unknown-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV Subject: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 13:31:22 -0000 Hi, i need to implement gateway redundancy for our server farm. I found UCARP ( http://www.ucarp.org ) as a potential solution, but it is written it is tested successfully only on Linux, OpenBSD and NetBSD. Did anybody have luck with it under FreeBSD ? Vladimir From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 13:33:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 371CB16A4CE; Tue, 7 Dec 2004 13:33:32 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6F7643D41; Tue, 7 Dec 2004 13:33:31 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CbfT6-0003Jb-00; Tue, 07 Dec 2004 14:33:28 +0100 Received: from [217.227.158.40] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CbfT5-0000J0-00; Tue, 07 Dec 2004 14:33:28 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Tue, 7 Dec 2004 14:34:13 +0100 User-Agent: KMail/1.7.1 References: <20041207153117.536b9399@daemon.cmotd.com> In-Reply-To: <20041207153117.536b9399@daemon.cmotd.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1707164.RM0QoL5sKV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412071434.15547.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: hackers@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 13:33:32 -0000 --nextPart1707164.RM0QoL5sKV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 07 December 2004 14:31, Vladimir Terziev wrote: > Hi, > > i need to implement gateway redundancy for our server farm. I found UCARP > ( http://www.ucarp.org ) as a potential solution, but it is written it is > tested successfully only on Linux, OpenBSD and NetBSD. > > Did anybody have luck with it under FreeBSD ? Take a look at: http://people.freebsd.org/~mlaier/CARP/ I hope to get this commit ready soon (maybe over the holydays). It's *worki= ng*=20 for the default case very well already and peers with OpenBSD like a charm. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1707164.RM0QoL5sKV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBtbFXXyyEoT62BG0RAq+/AJ9YmK/LgG5VVpuRr0vBGvjxwkNgIgCfYs4x 2hcUxwZuA96E3HNJs3t/jb0= =6vMT -----END PGP SIGNATURE----- --nextPart1707164.RM0QoL5sKV-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 13:40:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6488A16A4CE for ; Tue, 7 Dec 2004 13:40:09 +0000 (GMT) Received: from blah.sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id B36A643D46 for ; Tue, 7 Dec 2004 13:40:08 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: by blah.sun-fish.com (Postfix, from userid 599) id C73ED3418E; Tue, 7 Dec 2004 14:40:06 +0100 (CET) Received: from sun-fish.com (fs.cmotd.com [192.168.3.253]) by blah.sun-fish.com (Postfix) with ESMTP id AC9A834182; Tue, 7 Dec 2004 14:40:06 +0100 (CET) Received: from sun-fish.com (localhost.cmotd.com [127.0.0.1]) by sun-fish.com (Postfix) with ESMTP id 0A5553840C; Tue, 7 Dec 2004 14:35:49 +0100 (CET) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id CDE263840B; Tue, 7 Dec 2004 14:35:48 +0100 (CET) Date: Tue, 7 Dec 2004 15:40:07 +0200 From: Vladimir Terziev To: Max Laier Message-Id: <20041207154007.61a19f43@daemon.cmotd.com> In-Reply-To: <200412071434.15547.max@love2party.net> References: <20041207153117.536b9399@daemon.cmotd.com> <200412071434.15547.max@love2party.net> Organization: SunFish Ltd., Sofia X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-unknown-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV cc: freebsd-net@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 13:40:09 -0000 I know it, but it is for FreeBSD 5.x . My gateways run FreeBSD 4.10 and i don't have plans to upgrade them for now. Vladimir On Tue, 7 Dec 2004 14:34:13 +0100 Max Laier wrote: > On Tuesday 07 December 2004 14:31, Vladimir Terziev wrote: > > Hi, > > > > i need to implement gateway redundancy for our server farm. I found UCARP > > ( http://www.ucarp.org ) as a potential solution, but it is written it is > > tested successfully only on Linux, OpenBSD and NetBSD. > > > > Did anybody have luck with it under FreeBSD ? > > Take a look at: > > http://people.freebsd.org/~mlaier/CARP/ > > I hope to get this commit ready soon (maybe over the holydays). It's *working* > for the default case very well already and peers with OpenBSD like a charm. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 14:21:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4505A16A4CE; Tue, 7 Dec 2004 14:21:55 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65B9943D48; Tue, 7 Dec 2004 14:21:54 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CbgDv-0006II-5y; Tue, 07 Dec 2004 16:21:51 +0200 Message-ID: <41B5BC98.2080408@OTEL.net> Date: Tue, 07 Dec 2004 16:22:16 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Iasen Kostov References: <41AB0B98.6020600@OTEL.net> In-Reply-To: <41AB0B98.6020600@OTEL.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Robert Watson Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 14:21:55 -0000 Iasen Kostov wrote: > Robert Watson wrote: > >> On Sat, 27 Nov 2004, Kevin Day wrote: >> >> >> >>> I recently upgraded to 5.3 on a system, and manually upgraded >>> src/sys/dev/em/* to the latest RELENG_5 versions. (1.44.2.4 of >>> if_em.c) >> >> >> I'm able to reproduce problems using the below configuration is 6.x >> also, >> and am investigating. Thanks for the report, hope to get back to you >> shortly with something concrete. >> >> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >> robert@fledge.watson.org Principal Research Scientist, McAfee >> Research >> >> >> >> >>> While the VLAN side of things works better than the stock 5.3 version, >>> there still is this problem: >>> >>> ifconfig vlan1 create >>> ifconfig vlan1 vlan 1 vlandev em1 link0 >>> ifconfig vlan2 create >>> ifconfig vlan2 vlan 2 vlandev em1 link0 >>> ifconfig vlan3 create >>> ifconfig vlan3 vlan 3 vlandev em1 link0 >>> >>> ifconfig vlan1 inet 192.aaa.bbb.129 netmask 255.255.255.0 >>> ifconfig vlan2 inet 64.ccc.ddd.61 netmask 255.255.255.192 >>> ifconfig vlan3 inet 64.eee.fff.61 netmask 255.255.255.192 >>> >>> ifconfig em1 up >>> ifconfig em1 promisc >>> >>> If I do this, vlan1 and vlan3 work fine. Vlan2 can receive packets, >>> but anything sent out vlan2 doesn't seem to be heard by any foreign >>> hosts. Setting "ifconfig em1 -promisc" makes all vlans work properly. >>> >>> This is better than the stock 5.3 version of em(4) where none of the >>> vlans worked, but something still isn't right. >>> >>> Is this a known problem still or am I just doing something wrong? >>> >>> >>> >>> >>> >> > Saddly I can just confirm that :( > > regards > > _______________________________________________ > 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" > Is there an update on this case or I should find a way to disable all hw "things" in the driver ?:) (because things are getting hot here :). regards From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 14:59:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AC9816A4FC; Tue, 7 Dec 2004 14:59:37 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F378E43D49; Tue, 7 Dec 2004 14:59:35 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iB7ExYRV087761; Tue, 7 Dec 2004 16:59:34 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 95690-13; Tue, 7 Dec 2004 16:59:33 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iB7ExXXC087758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2004 16:59:33 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iB7ExWKs001567; Tue, 7 Dec 2004 16:59:32 +0200 (EET) (envelope-from ru) Date: Tue, 7 Dec 2004 16:59:32 +0200 From: Ruslan Ermilov To: Max Laier Message-ID: <20041207145932.GA1336@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tjCHc7DPkfUGtrlw" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: net@FreeBSD.org Subject: Another bug with netmasked aliases (with fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 14:59:37 -0000 --tjCHc7DPkfUGtrlw Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Max, I played today with "netmasked aliases", and found what appears to be another bug. Adding an alias to the Ethernet interface with the same netmask results in this address not being pingable from this host -- it just spits ARP requests to the wire and never hears back (most Ethernets are simplex devices). I knew what the fix should look like, and then quickly found a ready to commit solution in OpenBSD rev. 1.47. When testing the attached patch, make sure you do *not* have a (host) route for the alias being added. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Content-Transfer-Encoding: quoted-printable Index: if_ether.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/if_ether.c,v retrieving revision 1.131 diff -u -p -r1.131 if_ether.c --- if_ether.c 26 Oct 2004 03:31:58 -0000 1.131 +++ if_ether.c 7 Dec 2004 14:24:57 -0000 @@ -162,6 +162,7 @@ arp_rtrequest(req, rt, info) struct sockaddr *gate; struct llinfo_arp *la; static struct sockaddr_dl null_sdl =3D {sizeof(null_sdl), AF_LINK}; + struct in_ifaddr *ia; =20 RT_LOCK_ASSERT(rt); =20 @@ -250,8 +251,13 @@ arp_rtrequest(req, rt, info) } #endif =20 - if (SIN(rt_key(rt))->sin_addr.s_addr =3D=3D - (IA_SIN(rt->rt_ifa))->sin_addr.s_addr) { + TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { + if (ia->ia_ifp =3D=3D rt->rt_ifp && + SIN(rt_key(rt))->sin_addr.s_addr =3D=3D + (IA_SIN(ia))->sin_addr.s_addr) + break; + } + if (ia) { /* * This test used to be * if (loif.if_flags & IFF_UP) --YiEDa0DAkWCtVeE4-- --tjCHc7DPkfUGtrlw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBtcVUqRfpzJluFF4RAsa7AJ448geE832N3HiApQ3HQuWrolupXgCgj7pk Z7MGBypn6gtAh7z72r7cY48= =JBx6 -----END PGP SIGNATURE----- --tjCHc7DPkfUGtrlw-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 15:29:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2632E16A4CE for ; Tue, 7 Dec 2004 15:29:19 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FC9043D46 for ; Tue, 7 Dec 2004 15:29:18 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id iB7FWlOj040513 for freebsd-net@freebsd.org.checked; Tue, 7 Dec 2004 18:32:47 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from [144.206.181.94] (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id iB7FVExk040485; Tue, 7 Dec 2004 18:31:14 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <41B5CC5B.1090404@cronyx.ru> Date: Tue, 07 Dec 2004 18:29:31 +0300 From: Roman Kurakin User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Niy@extacy.homeip.net References: <4f9c6b6d04120611206e86dcdc@mail.gmail.com> In-Reply-To: <4f9c6b6d04120611206e86dcdc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Load Balancing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 15:29:19 -0000 NiY wrote: >Greetings! I have yet to find a definitive answer on this subject, so >I was hoping someone would let me know the official way to go about >this, or if it's even possible. > >We have two ADSL services coming into out building. We would like to >use them both on one network, using a multi-homed FreeBSD box, if >possible. So the scenario would like this. > > >ADSL1----\ / -- Host > Freebsd Load Balancer / NATD ---- Switch -- Host >ADSL2----/ \ --Host > > IMHO depends on many factors. Does both links from the same ISP? Is it possible to make smth from ISP side or this should be ISP unaware solution. etc. >Can it be done? >_______________________________________________ >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 Dec 7 16:43:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E61B16A4CE for ; Tue, 7 Dec 2004 16:43:59 +0000 (GMT) Received: from vampire.homelinux.org (pD9E39E28.dip.t-dialin.net [217.227.158.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AF5043D39 for ; Tue, 7 Dec 2004 16:43:58 +0000 (GMT) (envelope-from mlaier@vampire.homelinux.org) Received: (qmail 94068 invoked by uid 1001); 7 Dec 2004 16:42:21 -0000 Date: Tue, 7 Dec 2004 17:42:21 +0100 From: Max Laier To: Ruslan Ermilov Message-ID: <20041207164221.GA94019@router.laiers.local> References: <20041207145932.GA1336@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041207145932.GA1336@ip.net.ua> User-Agent: Mutt/1.4.2.1i cc: net@FreeBSD.org Subject: Re: Another bug with netmasked aliases (with fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 16:43:59 -0000 On Tue, Dec 07, 2004 at 04:59:32PM +0200, Ruslan Ermilov wrote: > Hi Max, > > I played today with "netmasked aliases", and found what > appears to be another bug. > > Adding an alias to the Ethernet interface with the same > netmask results in this address not being pingable from > this host -- it just spits ARP requests to the wire and > never hears back (most Ethernets are simplex devices). > > I knew what the fix should look like, and then quickly > found a ready to commit solution in OpenBSD rev. 1.47. Ahh, that is part of my CARP-patch IIRC (can't easily check as I am at my university right now), will make sure later. > When testing the attached patch, make sure you do *not* > have a (host) route for the alias being added. Thanks for the HEADSUP, I'll research in depth when I get back home. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 19:08:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1DE016A4CE for ; Tue, 7 Dec 2004 19:08:38 +0000 (GMT) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 1647A43D5C for ; Tue, 7 Dec 2004 19:08:37 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 31068 invoked by uid 0); 7 Dec 2004 11:42:00 -0200 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 Clear:RC:1(200.251.184.62):. Processed in 0.298805 secs); 07 Dec 2004 13:42:00 -0000 Received: from unknown (HELO freebsdbrasil.com.br) (200.251.184.62) by capeta.freebsdbrasil.com.br with SMTP; 7 Dec 2004 11:42:00 -0200 Message-ID: <41B5B321.5020607@freebsdbrasil.com.br> Date: Tue, 07 Dec 2004 11:41:53 -0200 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031207 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladimir Terziev References: <20041207153117.536b9399@daemon.cmotd.com> In-Reply-To: <20041207153117.536b9399@daemon.cmotd.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: net@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 19:08:38 -0000 Vladimir Terziev wrote: > Hi, > > i need to implement gateway redundancy for our server farm. I found UCARP ( http://www.ucarp.org ) as a potential solution, but it is written it is tested successfully only on Linux, OpenBSD and NetBSD. > > Did anybody have luck with it under FreeBSD ? Try CARP, not a variant. MLaier's been very successfull at porting it to FreeBSD. The available patches just apply fine against 5.3-RELEASE and it works *very well*. Reffer to OBSD's CARP documentation to get it to work. http://people.freebsd.org/~mlaier/CARP/ -- Atenciosamente, Patrick Tracanelli FreeBSD Brasil LTDA. The FreeBSD pt_BR Documentation Project http://www.freebsdbrasil.com.br Fone/Fax: (31) 3281-9633 "Long live Hanin Elias, Kim Deal!" From owner-freebsd-net@FreeBSD.ORG Tue Dec 7 23:29:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C50216A4CE; Tue, 7 Dec 2004 23:29:26 +0000 (GMT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id D14DF43D1D; Tue, 7 Dec 2004 23:29:24 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (unknown [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id 38172FC42; Tue, 7 Dec 2004 22:47:26 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 8FF65412C; Tue, 7 Dec 2004 22:45:55 +0100 (CET) Date: Tue, 7 Dec 2004 22:45:54 +0100 From: Jeremie Le Hen To: Vladimir Terziev Message-ID: <20041207214554.GK79919@obiwan.tataz.chchile.org> References: <20041207153117.536b9399@daemon.cmotd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041207153117.536b9399@daemon.cmotd.com> User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org cc: net@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2004 23:29:26 -0000 > i need to implement gateway redundancy for our server farm. I found > UCARP ( http://www.ucarp.org ) as a potential solution, but it is > written it is tested successfully only on Linux, OpenBSD and NetBSD. > > Did anybody have luck with it under FreeBSD ? I've just discovered UCARP thanks to you. It didn't have time to give it a try, however I looked at the documentation. It seems that UCARP is a userland tool and thus should work quite well on FreeBSD, more especially if it works on other BSD systems. I think now that the 'U' in UCARP means "Userland" :-). If you successfully run it on FreeBSD-4, it would be nice to keep us informed, at least for the archives. Regards, -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 02:11:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 324E616A4CE; Wed, 8 Dec 2004 02:11:23 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id A82B243D77; Wed, 8 Dec 2004 02:11:22 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CbrIV-0005i9-Ms; Wed, 08 Dec 2004 04:11:19 +0200 Message-ID: <41B662E1.1040303@OTEL.net> Date: Wed, 08 Dec 2004 04:11:45 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Tony Ackerman References: <41AB0B98.6020600@OTEL.net> <41B5BC98.2080408@OTEL.net> <20041207232408.GA26544@hub.freebsd.org> In-Reply-To: <20041207232408.GA26544@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 02:11:23 -0000 Tony Ackerman wrote: >What is the purpose of putting em1 in promiscuous mode below? Is >the required or did you just notice the issue with this configuration? > >There was a change added some months ago in order to allow the >bridging of vlans. In order for vlan briding to work the interface >had to have vlan tagging/stripping disabled when promisc mode is >invoked (which is how bridge works). The side effect is that now >tcpdump which puts the interface in promisc mode by default will >in effect cripple the interface. > >However, if "tcpdump -p" does not put the interface in promisc mode >and it works just fine. > > > What about bridge over VLAN ? If you can make a bridge over vlans without putting interfaces in promisc mode I won't have some of the problems - but I don't think it is possible ... More, if you forget to put -p after tcpdump (or trafshow) in ssh session ... BOOM. At least until sshd times out and drops the session and kills tcpdump but of course this is rather annoying :). And some traffic accounters go into background so they won't die with the ssh session making you say large amount of not so nice words before calling the support asking them to reboot the machine :). >On Tue, Dec 07, 2004 at 04:22:16PM +0200, Iasen Kostov wrote: > > >>Iasen Kostov wrote: >> >> >> >>>Robert Watson wrote: >>> >>> >>> >>>>On Sat, 27 Nov 2004, Kevin Day wrote: >>>> >>>> >>>> >>>> >>>> >>>>>I recently upgraded to 5.3 on a system, and manually upgraded >>>>>src/sys/dev/em/* to the latest RELENG_5 versions. (1.44.2.4 of >>>>>if_em.c) >>>>> >>>>> >>>>I'm able to reproduce problems using the below configuration is 6.x >>>>also, >>>>and am investigating. Thanks for the report, hope to get back to you >>>>shortly with something concrete. >>>> >>>>Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >>>>robert@fledge.watson.org Principal Research Scientist, McAfee >>>>Research >>>> >>>> >>>> >>>> >>>> >>>> >>>>>While the VLAN side of things works better than the stock 5.3 version, >>>>>there still is this problem: >>>>> >>>>>ifconfig vlan1 create >>>>>ifconfig vlan1 vlan 1 vlandev em1 link0 >>>>>ifconfig vlan2 create >>>>>ifconfig vlan2 vlan 2 vlandev em1 link0 >>>>>ifconfig vlan3 create >>>>>ifconfig vlan3 vlan 3 vlandev em1 link0 >>>>> >>>>>ifconfig vlan1 inet 192.aaa.bbb.129 netmask 255.255.255.0 >>>>>ifconfig vlan2 inet 64.ccc.ddd.61 netmask 255.255.255.192 >>>>>ifconfig vlan3 inet 64.eee.fff.61 netmask 255.255.255.192 >>>>> >>>>>ifconfig em1 up >>>>>ifconfig em1 promisc >>>>> >>>>>If I do this, vlan1 and vlan3 work fine. Vlan2 can receive packets, >>>>>but anything sent out vlan2 doesn't seem to be heard by any foreign >>>>>hosts. Setting "ifconfig em1 -promisc" makes all vlans work properly. >>>>> >>>>>This is better than the stock 5.3 version of em(4) where none of the >>>>>vlans worked, but something still isn't right. >>>>> >>>>>Is this a known problem still or am I just doing something wrong? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>Saddly I can just confirm that :( >>> >>> regards >>> >>>_______________________________________________ >>>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" >>> >>> >>> >> Is there an update on this case or I should find a way to disable >>all hw "things" in the driver ?:) (because things are getting hot here :). >> >> regards >> >> > > > From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 02:40:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEBD116A4CE for ; Wed, 8 Dec 2004 02:40:42 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 396BF43D64 for ; Wed, 8 Dec 2004 02:40:42 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1CbrkE-00084c-8x for freebsd-net@freebsd.org; Wed, 08 Dec 2004 04:39:58 +0200 Message-ID: <41B66998.9070104@OTEL.net> Date: Wed, 08 Dec 2004 04:40:24 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <41AB0B98.6020600@OTEL.net> <41B5BC98.2080408@OTEL.net> <20041207232408.GA26544@hub.freebsd.org> <41B662E1.1040303@OTEL.net> In-Reply-To: <41B662E1.1040303@OTEL.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 02:40:42 -0000 Iasen Kostov wrote: > Tony Ackerman wrote: > >> What is the purpose of putting em1 in promiscuous mode below? Is >> the required or did you just notice the issue with this configuration? >> >> There was a change added some months ago in order to allow the >> bridging of vlans. In order for vlan briding to work the interface >> had to have vlan tagging/stripping disabled when promisc mode is >> invoked (which is how bridge works). The side effect is that now >> tcpdump which puts the interface in promisc mode by default will >> in effect cripple the interface. >> >> However, if "tcpdump -p" does not put the interface in promisc mode >> and it works just fine. >> >> > What about bridge over VLAN ? If you can make a bridge over vlans > without putting > interfaces in promisc mode I won't have some of the problems - but I > don't think it is possible ... > More, if you forget to put -p after tcpdump (or trafshow) in ssh > session ... BOOM. > At least until sshd times out and drops the session and kills tcpdump > but of course this is rather > annoying :). And some traffic accounters go into background so they > won't die with the > ssh session making you say large amount of not so nice words before > calling the support > asking them to reboot the machine :). > >> On Tue, Dec 07, 2004 at 04:22:16PM +0200, Iasen Kostov wrote: >> >> >>> Iasen Kostov wrote: >>> >>> >>> >>>> Robert Watson wrote: >>>> >>>> >>>> >>>>> On Sat, 27 Nov 2004, Kevin Day wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> I recently upgraded to 5.3 on a system, and manually upgraded >>>>>> src/sys/dev/em/* to the latest RELENG_5 versions. (1.44.2.4 of >>>>>> if_em.c) >>>>> >>>>> I'm able to reproduce problems using the below configuration is >>>>> 6.x also, >>>>> and am investigating. Thanks for the report, hope to get back to you >>>>> shortly with something concrete. >>>>> >>>>> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >>>>> robert@fledge.watson.org Principal Research Scientist, McAfee >>>>> Research >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> While the VLAN side of things works better than the stock 5.3 >>>>>> version, >>>>>> there still is this problem: >>>>>> >>>>>> ifconfig vlan1 create >>>>>> ifconfig vlan1 vlan 1 vlandev em1 link0 >>>>>> ifconfig vlan2 create >>>>>> ifconfig vlan2 vlan 2 vlandev em1 link0 >>>>>> ifconfig vlan3 create >>>>>> ifconfig vlan3 vlan 3 vlandev em1 link0 >>>>>> >>>>>> ifconfig vlan1 inet 192.aaa.bbb.129 netmask 255.255.255.0 >>>>>> ifconfig vlan2 inet 64.ccc.ddd.61 netmask 255.255.255.192 >>>>>> ifconfig vlan3 inet 64.eee.fff.61 netmask 255.255.255.192 >>>>>> >>>>>> ifconfig em1 up >>>>>> ifconfig em1 promisc >>>>>> >>>>>> If I do this, vlan1 and vlan3 work fine. Vlan2 can receive >>>>>> packets, but anything sent out vlan2 doesn't seem to be heard by >>>>>> any foreign hosts. Setting "ifconfig em1 -promisc" makes all >>>>>> vlans work properly. >>>>>> >>>>>> This is better than the stock 5.3 version of em(4) where none of >>>>>> the vlans worked, but something still isn't right. >>>>>> >>>>>> Is this a known problem still or am I just doing something wrong? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> Saddly I can just confirm that :( >>>> >>>> regards >>>> >>>> _______________________________________________ >>>> 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" >>>> >>>> >>> >>> Is there an update on this case or I should find a way to disable >>> all hw "things" in the driver ?:) (because things are getting hot >>> here :). >>> >>> regards >>> >> >> >> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Funny, it works when I load the module from loader.conf ... I mean everything - bridge, tcpdump. Network adapter is changed too but the model is the same. I realy didn't get it :(. From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 02:47:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 368D716A4CE for ; Wed, 8 Dec 2004 02:47:48 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id B78F343D60 for ; Wed, 8 Dec 2004 02:47:47 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1Cbrrl-0008Pw-Ng; Wed, 08 Dec 2004 04:47:45 +0200 Message-ID: <41B66B6C.8060105@OTEL.net> Date: Wed, 08 Dec 2004 04:48:12 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Iasen Kostov References: <41AB0B98.6020600@OTEL.net> <41B5BC98.2080408@OTEL.net> <20041207232408.GA26544@hub.freebsd.org> <41B662E1.1040303@OTEL.net> <41B66998.9070104@OTEL.net> In-Reply-To: <41B66998.9070104@OTEL.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 02:47:48 -0000 Iasen Kostov wrote: > Iasen Kostov wrote: > >> Tony Ackerman wrote: >> >>> What is the purpose of putting em1 in promiscuous mode below? Is >>> the required or did you just notice the issue with this configuration? >>> >>> There was a change added some months ago in order to allow the >>> bridging of vlans. In order for vlan briding to work the interface >>> had to have vlan tagging/stripping disabled when promisc mode is >>> invoked (which is how bridge works). The side effect is that now >>> tcpdump which puts the interface in promisc mode by default will >>> in effect cripple the interface. >>> >>> However, if "tcpdump -p" does not put the interface in promisc mode >>> and it works just fine. >>> >>> >> What about bridge over VLAN ? If you can make a bridge over vlans >> without putting >> interfaces in promisc mode I won't have some of the problems - but I >> don't think it is possible ... >> More, if you forget to put -p after tcpdump (or trafshow) in ssh >> session ... BOOM. >> At least until sshd times out and drops the session and kills tcpdump >> but of course this is rather >> annoying :). And some traffic accounters go into background so they >> won't die with the >> ssh session making you say large amount of not so nice words before >> calling the support >> asking them to reboot the machine :). >> >>> On Tue, Dec 07, 2004 at 04:22:16PM +0200, Iasen Kostov wrote: >>> >>> >>>> Iasen Kostov wrote: >>>> >>>> >>>> >>>>> Robert Watson wrote: >>>>> >>>>> >>>>> >>>>>> On Sat, 27 Nov 2004, Kevin Day wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I recently upgraded to 5.3 on a system, and manually upgraded >>>>>>> src/sys/dev/em/* to the latest RELENG_5 versions. (1.44.2.4 of >>>>>>> if_em.c) >>>>>> >>>>>> >>>>>> I'm able to reproduce problems using the below configuration is >>>>>> 6.x also, >>>>>> and am investigating. Thanks for the report, hope to get back to >>>>>> you >>>>>> shortly with something concrete. >>>>>> >>>>>> Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >>>>>> robert@fledge.watson.org Principal Research Scientist, >>>>>> McAfee Research >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> While the VLAN side of things works better than the stock 5.3 >>>>>>> version, >>>>>>> there still is this problem: >>>>>>> >>>>>>> ifconfig vlan1 create >>>>>>> ifconfig vlan1 vlan 1 vlandev em1 link0 >>>>>>> ifconfig vlan2 create >>>>>>> ifconfig vlan2 vlan 2 vlandev em1 link0 >>>>>>> ifconfig vlan3 create >>>>>>> ifconfig vlan3 vlan 3 vlandev em1 link0 >>>>>>> >>>>>>> ifconfig vlan1 inet 192.aaa.bbb.129 netmask 255.255.255.0 >>>>>>> ifconfig vlan2 inet 64.ccc.ddd.61 netmask 255.255.255.192 >>>>>>> ifconfig vlan3 inet 64.eee.fff.61 netmask 255.255.255.192 >>>>>>> >>>>>>> ifconfig em1 up >>>>>>> ifconfig em1 promisc >>>>>>> >>>>>>> If I do this, vlan1 and vlan3 work fine. Vlan2 can receive >>>>>>> packets, but anything sent out vlan2 doesn't seem to be heard by >>>>>>> any foreign hosts. Setting "ifconfig em1 -promisc" makes all >>>>>>> vlans work properly. >>>>>>> >>>>>>> This is better than the stock 5.3 version of em(4) where none of >>>>>>> the vlans worked, but something still isn't right. >>>>>>> >>>>>>> Is this a known problem still or am I just doing something wrong? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> Saddly I can just confirm that :( >>>>> >>>>> regards >>>>> >>>>> _______________________________________________ >>>>> 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" >>>>> >>>>> >>>> >>>> >>>> Is there an update on this case or I should find a way to disable >>>> all hw "things" in the driver ?:) (because things are getting hot >>>> here :). >>>> >>>> regards >>>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > Funny, it works when I load the module from loader.conf ... I mean > everything - bridge, tcpdump. Network adapter is changed too > but the model is the same. I realy didn't get it :(. > More fun it now works flawlessly ... wherever you load the if_em and I'm 100% sure that it didn't work with old adapter. I don't know I hope it was some kind ot hardware problem. From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 04:15:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BA8016A4CE for ; Wed, 8 Dec 2004 04:15:51 +0000 (GMT) Received: from BASE.OTEL.net (BASE.OTEL.net [212.36.8.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id F060C43D49 for ; Wed, 8 Dec 2004 04:15:50 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by BASE.OTEL.net with esmtp (Exim 4.30; FreeBSD) id 1CbtEz-0002pU-Gk; Wed, 08 Dec 2004 06:15:49 +0200 Message-ID: <41B68010.3060206@OTEL.net> Date: Wed, 08 Dec 2004 06:16:16 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Iasen Kostov References: <41AB0B98.6020600@OTEL.net> <41B5BC98.2080408@OTEL.net> <20041207232408.GA26544@hub.freebsd.org> <41B662E1.1040303@OTEL.net> <41B66998.9070104@OTEL.net> <41B66B6C.8060105@OTEL.net> In-Reply-To: <41B66B6C.8060105@OTEL.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 04:15:51 -0000 Sorry for that much posts but something weird is going on ... I left bridge for a while (more than route/arp cache period) and then the stopped. Same happens when you clear the arp cache as I find out. And as I expected arps didn't get from the bridge to the host (wherever who-has ot is-on). And something else - if the Host has never send an IP packet to the bridge nothing could pass from bridge to host. I'm clueless but this make bridge unusable with "em" and vlans. From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 05:41:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA6DB16A4FE for ; Wed, 8 Dec 2004 05:41:36 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7716843D41 for ; Wed, 8 Dec 2004 05:41:36 +0000 (GMT) (envelope-from chip.gwyn@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so345600wri for ; Tue, 07 Dec 2004 21:41:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=QY7q+P7/uNsM+Q7oRjECxedqZyXgaRbLyJw9IIaRIpXaLDzLgxi773GOlY9s+6Npa1qpepg8eq21HXHGWReBl5eLEzGmG2wGJNZJZJLYlE6fV8oTeOG2leQhrgeOyouHt+Z6VRsDIJXAk+PDCqOUFK1jXNYwspZgH4QpglAujcM= Received: by 10.54.48.59 with SMTP id v59mr1143242wrv; Tue, 07 Dec 2004 21:41:35 -0800 (PST) Received: by 10.54.57.6 with HTTP; Tue, 7 Dec 2004 21:41:35 -0800 (PST) Message-ID: <64a8ad980412072141247659e9@mail.gmail.com> Date: Wed, 8 Dec 2004 00:41:35 -0500 From: chip To: freebsd-net@freebsd.org In-Reply-To: <20041207025917.43855.qmail@web42103.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041207025917.43855.qmail@web42103.mail.yahoo.com> Subject: Re: TCPDUMP bandwidth capability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: chip List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 05:41:37 -0000 On Mon, 6 Dec 2004 18:59:17 -0800 (PST), asdfasdfasd asdfds wrote: > Hello, > > For those who use TCPDUMP, how much bandwidth have you > been able to monitor with it without dropping packets? > I've seen it said that BSD is much better for this > type of thing than Linux, but numbers are heard to > come by. Right the right NICs and processing power, > is line-rate 1Gbps possible? > > Thanks, > Todd Take a look at http://luca.ntop.org/Ring.pdf It has some real numbers to look at that should guide you in your quest for monitoring bliss. You might also want to check the NANOG mailing list archives (http://nanog.org) for some further information. I think there was a fairly recent discussion of this. --chip -- Just my $.02, your mileage may vary, batteries not included, etc.... From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 09:58:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6B0416A4CE; Wed, 8 Dec 2004 09:58:51 +0000 (GMT) Received: from blah.sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id D42EE43D75; Wed, 8 Dec 2004 09:58:50 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: by blah.sun-fish.com (Postfix, from userid 599) id C01C134183; Wed, 8 Dec 2004 10:58:48 +0100 (CET) Received: from sun-fish.com (fs.cmotd.com [192.168.3.253]) by blah.sun-fish.com (Postfix) with ESMTP id B0E6B34164; Wed, 8 Dec 2004 10:58:48 +0100 (CET) Received: from sun-fish.com (localhost.cmotd.com [127.0.0.1]) by sun-fish.com (Postfix) with ESMTP id 637223840A; Wed, 8 Dec 2004 10:58:26 +0100 (CET) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id 2BBDB38404; Wed, 8 Dec 2004 10:58:26 +0100 (CET) Date: Wed, 8 Dec 2004 11:58:49 +0200 From: Vladimir Terziev To: Jeremie Le Hen Message-Id: <20041208115849.06de4961@daemon.cmotd.com> In-Reply-To: <20041207214554.GK79919@obiwan.tataz.chchile.org> References: <20041207153117.536b9399@daemon.cmotd.com> <20041207214554.GK79919@obiwan.tataz.chchile.org> Organization: SunFish Ltd., Sofia X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-unknown-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV cc: hackers@freebsd.org cc: net@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 09:58:51 -0000 Hi Jeremie, I've managed to build UCARP binary on FreeBSD 4.x without any problem. Now i have to test it how good it works. Vladimir On Tue, 7 Dec 2004 22:45:54 +0100 Jeremie Le Hen wrote: > > i need to implement gateway redundancy for our server farm. I found > > UCARP ( http://www.ucarp.org ) as a potential solution, but it is > > written it is tested successfully only on Linux, OpenBSD and NetBSD. > > > > Did anybody have luck with it under FreeBSD ? > > I've just discovered UCARP thanks to you. It didn't have time to give > it a try, however I looked at the documentation. It seems that UCARP > is a userland tool and thus should work quite well on FreeBSD, more > especially if it works on other BSD systems. > > I think now that the 'U' in UCARP means "Userland" :-). > > If you successfully run it on FreeBSD-4, it would be nice to keep us > informed, at least for the archives. > > Regards, > -- > Jeremie Le Hen > jeremie@le-hen.org From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 10:33:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E80916A4CE for ; Wed, 8 Dec 2004 10:33:04 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5C3D43D39 for ; Wed, 8 Dec 2004 10:33:03 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iB8AUbLV098489; Wed, 8 Dec 2004 05:30:37 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iB8AUaQs098486; Wed, 8 Dec 2004 10:30:37 GMT (envelope-from robert@fledge.watson.org) Date: Wed, 8 Dec 2004 10:30:36 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Iasen Kostov In-Reply-To: <41B5BC98.2080408@OTEL.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 10:33:04 -0000 On Tue, 7 Dec 2004, Iasen Kostov wrote: > Is there an update on this case or I should find a way to disable > all hw "things" in the driver ?:) (because things are getting hot here > :). Try the attached patch? The vlan header in promisc mode was getting inserted after the mbuf was mapped for dma, so under some circumstances the remainder of the packet but not the header would be sent. Given that the previous change tested fine before, I'm wondering if the recent busdma changes have triggered this bug. I'm beginning to think the right fix here is actually to always leave the hardware turned on and to re-insert the vlan header on receive, not insert on transmit, in order to avoid races for queued packets during state transitions. I'll have a chance to investigate that before going on travel Friday, I hope. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research Index: if_em.c =================================================================== RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v retrieving revision 1.54 diff -u -r1.54 if_em.c --- if_em.c 14 Nov 2004 20:20:28 -0000 1.54 +++ if_em.c 8 Dec 2004 10:30:03 -0000 @@ -1203,36 +1203,6 @@ } } - /* - * Map the packet for DMA. - */ - if (bus_dmamap_create(adapter->txtag, BUS_DMA_NOWAIT, &q.map)) { - adapter->no_tx_map_avail++; - return (ENOMEM); - } - error = bus_dmamap_load_mbuf(adapter->txtag, q.map, - m_head, em_tx_cb, &q, BUS_DMA_NOWAIT); - if (error != 0) { - adapter->no_tx_dma_setup++; - bus_dmamap_destroy(adapter->txtag, q.map); - return (error); - } - KASSERT(q.nsegs != 0, ("em_encap: empty packet")); - - if (q.nsegs > adapter->num_tx_desc_avail) { - adapter->no_tx_desc_avail2++; - bus_dmamap_destroy(adapter->txtag, q.map); - return (ENOBUFS); - } - - - if (ifp->if_hwassist > 0) { - em_transmit_checksum_setup(adapter, m_head, - &txd_upper, &txd_lower); - } else - txd_upper = txd_lower = 0; - - /* Find out if we are in vlan mode */ #if __FreeBSD_version < 500000 if ((m_head->m_flags & (M_PROTO1|M_PKTHDR)) == (M_PROTO1|M_PKTHDR) && @@ -1256,20 +1226,17 @@ m_head = m_pullup(m_head, sizeof(eh)); if (m_head == NULL) { *m_headp = NULL; - bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } eh = *mtod(m_head, struct ether_header *); M_PREPEND(m_head, sizeof(*evl), M_DONTWAIT); if (m_head == NULL) { *m_headp = NULL; - bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } m_head = m_pullup(m_head, sizeof(*evl)); if (m_head == NULL) { *m_headp = NULL; - bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } evl = mtod(m_head, struct ether_vlan_header *); @@ -1282,6 +1249,36 @@ *m_headp = m_head; } + /* + * Map the packet for DMA. + */ + if (bus_dmamap_create(adapter->txtag, BUS_DMA_NOWAIT, &q.map)) { + adapter->no_tx_map_avail++; + return (ENOMEM); + } + error = bus_dmamap_load_mbuf(adapter->txtag, q.map, + m_head, em_tx_cb, &q, BUS_DMA_NOWAIT); + if (error != 0) { + adapter->no_tx_dma_setup++; + bus_dmamap_destroy(adapter->txtag, q.map); + return (error); + } + KASSERT(q.nsegs != 0, ("em_encap: empty packet")); + + if (q.nsegs > adapter->num_tx_desc_avail) { + adapter->no_tx_desc_avail2++; + bus_dmamap_destroy(adapter->txtag, q.map); + return (ENOBUFS); + } + + + if (ifp->if_hwassist > 0) { + em_transmit_checksum_setup(adapter, m_head, + &txd_upper, &txd_lower); + } else + txd_upper = txd_lower = 0; + + i = adapter->next_avail_tx_desc; if (adapter->pcix_82544) { txd_saved = i; From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 10:58:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8DF916A4CE; Wed, 8 Dec 2004 10:58:05 +0000 (GMT) Received: from BASE.OTEL.net (BASE.OTEL.net [212.36.8.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BE9043D1F; Wed, 8 Dec 2004 10:58:05 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by BASE.OTEL.net with esmtp (Exim 4.30; FreeBSD) id 1CbzWG-0007GN-R0; Wed, 08 Dec 2004 12:58:04 +0200 Message-ID: <41B6DE57.4030909@OTEL.net> Date: Wed, 08 Dec 2004 12:58:31 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 10:58:06 -0000 Robert Watson wrote: >On Tue, 7 Dec 2004, Iasen Kostov wrote: > > > >> Is there an update on this case or I should find a way to disable >>all hw "things" in the driver ?:) (because things are getting hot here >>:). >> >> > >Try the attached patch? The vlan header in promisc mode was getting >inserted after the mbuf was mapped for dma, so under some circumstances >the remainder of the packet but not the header would be sent. Given that >the previous change tested fine before, I'm wondering if the recent busdma >changes have triggered this bug. > >I'm beginning to think the right fix here is actually to always leave the >hardware turned on and to re-insert the vlan header on receive, not insert >on transmit, in order to avoid races for queued packets during state >transitions. I'll have a chance to investigate that before going on >travel Friday, I hope. > > > The patch generates .rej against this version: /*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 rwatson Exp $*/ *************** *** 1273,1292 **** m_head = m_pullup(m_head, sizeof(eh)); if (m_head == NULL) { *m_headp = NULL; - bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } eh = *mtod(m_head, struct ether_header *); M_PREPEND(m_head, sizeof(*evl), M_DONTWAIT); if (m_head == NULL) { *m_headp = NULL; - bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } m_head = m_pullup(m_head, sizeof(*evl)); if (m_head == NULL) { *m_headp = NULL; - bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } evl = mtod(m_head, struct ether_vlan_header *); --- 1243,1259 ---- m_head = m_pullup(m_head, sizeof(eh)); if (m_head == NULL) { *m_headp = NULL; return (ENOBUFS); } eh = *mtod(m_head, struct ether_header *); M_PREPEND(m_head, sizeof(*evl), M_DONTWAIT); if (m_head == NULL) { *m_headp = NULL; return (ENOBUFS); } m_head = m_pullup(m_head, sizeof(*evl)); if (m_head == NULL) { *m_headp = NULL; return (ENOBUFS); } evl = mtod(m_head, struct ether_vlan_header *); should I use the version from -CURRENT or it is possible (adjusted patch) to work with this one ? From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 11:06:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7720F16A4CE for ; Wed, 8 Dec 2004 11:06:48 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2249643D49 for ; Wed, 8 Dec 2004 11:06:48 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iB8B4M38098863; Wed, 8 Dec 2004 06:04:22 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iB8B4M9u098860; Wed, 8 Dec 2004 11:04:22 GMT (envelope-from robert@fledge.watson.org) Date: Wed, 8 Dec 2004 11:04:22 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Iasen Kostov In-Reply-To: <41B6DE57.4030909@OTEL.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 11:06:48 -0000 On Wed, 8 Dec 2004, Iasen Kostov wrote: > The patch generates .rej against this version: > > /*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 > rwatson Exp $*/ > should I use the version from -CURRENT or it is possible (adjusted > patch) to work with this one ? Odd. I successfully applied the patch against RELENG_5 here before sending it out, and against the same revision. Could you try deleting if_em, re-updating, and re-applying? The change to remove the busdma map deletion is needed because in the patched version, those failures occur before the mapping is allocated. There was a revision of if_em after initial attempts to fix the problem that didn't properly free the mappings, but I think it was the .3 revision in RELENG_5. One might expect the new patch to reject against that older revision because the deletions had not yet been inserted (so to speak). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 11:42:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2621716A4CE; Wed, 8 Dec 2004 11:42:18 +0000 (GMT) Received: from BASE.OTEL.net (BASE.OTEL.net [212.36.8.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id C804A43D53; Wed, 8 Dec 2004 11:42:17 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by BASE.OTEL.net with esmtp (Exim 4.30; FreeBSD) id 1Cc0D2-0008Lg-MX; Wed, 08 Dec 2004 13:42:16 +0200 Message-ID: <41B6E8B3.8090009@OTEL.net> Date: Wed, 08 Dec 2004 13:42:43 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 11:42:18 -0000 Robert Watson wrote: >On Wed, 8 Dec 2004, Iasen Kostov wrote: > > > >>The patch generates .rej against this version: >> >>/*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 >>rwatson Exp $*/ >> >> > > > >>should I use the version from -CURRENT or it is possible (adjusted >>patch) to work with this one ? >> >> > >Odd. I successfully applied the patch against RELENG_5 here before >sending it out, and against the same revision. Could you try deleting >if_em, re-updating, and re-applying? The change to remove the busdma map >deletion is needed because in the patched version, those failures occur >before the mapping is allocated. There was a revision of if_em after >initial attempts to fix the problem that didn't properly free the >mappings, but I think it was the .3 revision in RELENG_5. One might >expect the new patch to reject against that older revision because the >deletions had not yet been inserted (so to speak). > > #:> ls -l if_em.c -rw-r--r-- 1 root wheel 109829 Nov 24 00:28 if_em.c root@DraGoN:/usr/src/sys/dev/em on ttypf #:> patch < if_em.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: if_em.c |=================================================================== |RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v |retrieving revision 1.54 |diff -u -r1.54 if_em.c |--- if_em.c 14 Nov 2004 20:20:28 -0000 1.54 |+++ if_em.c 8 Dec 2004 10:30:03 -0000 -------------------------- Patching file if_em.c using Plan A... Hunk #1 succeeded at 1220 (offset 17 lines). Hunk #2 failed at 1243. Hunk #3 succeeded at 1266 with fuzz 2 (offset 17 lines). 1 out of 3 hunks failed--saving rejects to if_em.c.rej done #:> ident if_em.c if_em.c: $FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 rwatson Exp $ I've deleted the whole dir and cvsuped. Does 1.54 differs much from 1.44.2.4 ? From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 11:47:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52F7E16A4CE; Wed, 8 Dec 2004 11:47:58 +0000 (GMT) Received: from BASE.OTEL.net (BASE.OTEL.net [212.36.8.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1A4043D2F; Wed, 8 Dec 2004 11:47:57 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by BASE.OTEL.net with esmtp (Exim 4.30; FreeBSD) id 1Cc0IX-0008fR-6y; Wed, 08 Dec 2004 13:47:57 +0200 Message-ID: <41B6EA08.9020008@OTEL.net> Date: Wed, 08 Dec 2004 13:48:24 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Iasen Kostov References: <41B6E8B3.8090009@OTEL.net> In-Reply-To: <41B6E8B3.8090009@OTEL.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Robert Watson Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 11:47:58 -0000 Iasen Kostov wrote: > Robert Watson wrote: > >> On Wed, 8 Dec 2004, Iasen Kostov wrote: >> >> >> >>> The patch generates .rej against this version: >>> >>> /*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 >>> rwatson Exp $*/ >>> >> >> >> >>> should I use the version from -CURRENT or it is possible (adjusted >>> patch) to work with this one ? >>> >> >> >> Odd. I successfully applied the patch against RELENG_5 here before >> sending it out, and against the same revision. Could you try deleting >> if_em, re-updating, and re-applying? The change to remove the busdma >> map >> deletion is needed because in the patched version, those failures occur >> before the mapping is allocated. There was a revision of if_em after >> initial attempts to fix the problem that didn't properly free the >> mappings, but I think it was the .3 revision in RELENG_5. One might >> expect the new patch to reject against that older revision because the >> deletions had not yet been inserted (so to speak). >> >> > #:> ls -l if_em.c > -rw-r--r-- 1 root wheel 109829 Nov 24 00:28 if_em.c #:> ls -l if_em.c -rw-r--r-- 1 root wheel 109829 Dec 8 13:40 if_em.c That's weird - I've delete everything from the dir and cvsuped and the first one apears. Now it is the second one only dates differs. Is that a side effect of disk caches (dirhash possibly) ? :) > > root@DraGoN:/usr/src/sys/dev/em on ttypf > #:> patch < if_em.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: if_em.c > |=================================================================== > |RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v > |retrieving revision 1.54 > |diff -u -r1.54 if_em.c > |--- if_em.c 14 Nov 2004 20:20:28 -0000 1.54 > |+++ if_em.c 8 Dec 2004 10:30:03 -0000 > -------------------------- > Patching file if_em.c using Plan A... > Hunk #1 succeeded at 1220 (offset 17 lines). > Hunk #2 failed at 1243. > Hunk #3 succeeded at 1266 with fuzz 2 (offset 17 lines). > 1 out of 3 hunks failed--saving rejects to if_em.c.rej > done > > #:> ident if_em.c > if_em.c: > $FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 > rwatson Exp $ > > I've deleted the whole dir and cvsuped. Does 1.54 differs much from > 1.44.2.4 ? > > > _______________________________________________ > 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 Dec 8 11:49:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFC7416A4CE; Wed, 8 Dec 2004 11:49:48 +0000 (GMT) Received: from BASE.OTEL.net (BASE.OTEL.net [212.36.8.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AA1943D39; Wed, 8 Dec 2004 11:49:48 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by BASE.OTEL.net with esmtp (Exim 4.30; FreeBSD) id 1Cc0KJ-0008k5-KO; Wed, 08 Dec 2004 13:49:47 +0200 Message-ID: <41B6EA76.7050200@OTEL.net> Date: Wed, 08 Dec 2004 13:50:14 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Iasen Kostov References: <41B6E8B3.8090009@OTEL.net> <41B6EA08.9020008@OTEL.net> In-Reply-To: <41B6EA08.9020008@OTEL.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Robert Watson Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 11:49:48 -0000 Iasen Kostov wrote: > Iasen Kostov wrote: > >> Robert Watson wrote: >> >>> On Wed, 8 Dec 2004, Iasen Kostov wrote: >>> >>> >>> >>>> The patch generates .rej against this version: >>>> >>>> /*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 >>>> rwatson Exp $*/ >>>> >>> >>> >>> >>> >>>> should I use the version from -CURRENT or it is possible (adjusted >>>> patch) to work with this one ? >>>> >>> >>> >>> >>> Odd. I successfully applied the patch against RELENG_5 here before >>> sending it out, and against the same revision. Could you try deleting >>> if_em, re-updating, and re-applying? The change to remove the >>> busdma map >>> deletion is needed because in the patched version, those failures occur >>> before the mapping is allocated. There was a revision of if_em after >>> initial attempts to fix the problem that didn't properly free the >>> mappings, but I think it was the .3 revision in RELENG_5. One might >>> expect the new patch to reject against that older revision because the >>> deletions had not yet been inserted (so to speak). >>> >>> >> #:> ls -l if_em.c >> -rw-r--r-- 1 root wheel 109829 Nov 24 00:28 if_em.c > > > > #:> ls -l if_em.c > -rw-r--r-- 1 root wheel 109829 Dec 8 13:40 if_em.c > > That's weird - I've delete everything from the dir and cvsuped and the > first one apears. > Now it is the second one only dates differs. Is that a side effect of > disk caches (dirhash possibly) ? :) Uh this is side effect of "not enough sleep" - scratch that :) - this is result of patch -R. > >> >> root@DraGoN:/usr/src/sys/dev/em on ttypf >> #:> patch < if_em.patch >> Hmm... Looks like a unified diff to me... >> The text leading up to this was: >> -------------------------- >> |Index: if_em.c >> |=================================================================== >> |RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v >> |retrieving revision 1.54 >> |diff -u -r1.54 if_em.c >> |--- if_em.c 14 Nov 2004 20:20:28 -0000 1.54 >> |+++ if_em.c 8 Dec 2004 10:30:03 -0000 >> -------------------------- >> Patching file if_em.c using Plan A... >> Hunk #1 succeeded at 1220 (offset 17 lines). >> Hunk #2 failed at 1243. >> Hunk #3 succeeded at 1266 with fuzz 2 (offset 17 lines). >> 1 out of 3 hunks failed--saving rejects to if_em.c.rej >> done >> >> #:> ident if_em.c >> if_em.c: >> $FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 >> rwatson Exp $ >> >> I've deleted the whole dir and cvsuped. Does 1.54 differs much from >> 1.44.2.4 ? >> >> >> _______________________________________________ >> 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 Dec 8 11:54:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A85A116A4D0 for ; Wed, 8 Dec 2004 11:54:21 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DCF243D5C for ; Wed, 8 Dec 2004 11:54:21 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iB8BpsUZ099489; Wed, 8 Dec 2004 06:51:54 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iB8BpsMc099486; Wed, 8 Dec 2004 11:51:54 GMT (envelope-from robert@fledge.watson.org) Date: Wed, 8 Dec 2004 11:51:54 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Iasen Kostov In-Reply-To: <41B6E8B3.8090009@OTEL.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 11:54:21 -0000 On Wed, 8 Dec 2004, Iasen Kostov wrote: > #:> ident if_em.c > if_em.c: > $FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 > rwatson Exp $ > > I've deleted the whole dir and cvsuped. Does 1.54 differs much from > 1.44.2.4 ? Very odd. I have 1.44.2.4 checked out here, and if_em.diff applied without a hitch. Here's a version of the patch generated using cvs diff against the older revision. It should be basically identical to the version I sent you before, though. Diffing the two diffs generates only line number differences. If this doesn't work, drop me a copy of your if_em.c and I'll apply the change manually. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research Index: if_em.c =================================================================== RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v retrieving revision 1.44.2.4 diff -u -r1.44.2.4 if_em.c --- if_em.c 23 Nov 2004 22:28:40 -0000 1.44.2.4 +++ if_em.c 8 Dec 2004 11:01:19 -0000 @@ -1220,36 +1220,6 @@ } } - /* - * Map the packet for DMA. - */ - if (bus_dmamap_create(adapter->txtag, BUS_DMA_NOWAIT, &q.map)) { - adapter->no_tx_map_avail++; - return (ENOMEM); - } - error = bus_dmamap_load_mbuf(adapter->txtag, q.map, - m_head, em_tx_cb, &q, BUS_DMA_NOWAIT); - if (error != 0) { - adapter->no_tx_dma_setup++; - bus_dmamap_destroy(adapter->txtag, q.map); - return (error); - } - KASSERT(q.nsegs != 0, ("em_encap: empty packet")); - - if (q.nsegs > adapter->num_tx_desc_avail) { - adapter->no_tx_desc_avail2++; - bus_dmamap_destroy(adapter->txtag, q.map); - return (ENOBUFS); - } - - - if (ifp->if_hwassist > 0) { - em_transmit_checksum_setup(adapter, m_head, - &txd_upper, &txd_lower); - } else - txd_upper = txd_lower = 0; - - /* Find out if we are in vlan mode */ #if __FreeBSD_version < 500000 if ((m_head->m_flags & (M_PROTO1|M_PKTHDR)) == (M_PROTO1|M_PKTHDR) && @@ -1273,20 +1243,17 @@ m_head = m_pullup(m_head, sizeof(eh)); if (m_head == NULL) { *m_headp = NULL; - bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } eh = *mtod(m_head, struct ether_header *); M_PREPEND(m_head, sizeof(*evl), M_DONTWAIT); if (m_head == NULL) { *m_headp = NULL; - bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } m_head = m_pullup(m_head, sizeof(*evl)); if (m_head == NULL) { *m_headp = NULL; - bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } evl = mtod(m_head, struct ether_vlan_header *); @@ -1299,6 +1266,36 @@ *m_headp = m_head; } + /* + * Map the packet for DMA. + */ + if (bus_dmamap_create(adapter->txtag, BUS_DMA_NOWAIT, &q.map)) { + adapter->no_tx_map_avail++; + return (ENOMEM); + } + error = bus_dmamap_load_mbuf(adapter->txtag, q.map, + m_head, em_tx_cb, &q, BUS_DMA_NOWAIT); + if (error != 0) { + adapter->no_tx_dma_setup++; + bus_dmamap_destroy(adapter->txtag, q.map); + return (error); + } + KASSERT(q.nsegs != 0, ("em_encap: empty packet")); + + if (q.nsegs > adapter->num_tx_desc_avail) { + adapter->no_tx_desc_avail2++; + bus_dmamap_destroy(adapter->txtag, q.map); + return (ENOBUFS); + } + + + if (ifp->if_hwassist > 0) { + em_transmit_checksum_setup(adapter, m_head, + &txd_upper, &txd_lower); + } else + txd_upper = txd_lower = 0; + + i = adapter->next_avail_tx_desc; if (adapter->pcix_82544) { txd_saved = i; From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 12:22:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB9F616A4CE for ; Wed, 8 Dec 2004 12:22:05 +0000 (GMT) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB01543D54 for ; Wed, 8 Dec 2004 12:22:04 +0000 (GMT) (envelope-from Konstantin.Kabassanov@lip6.fr) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) iB8CM3uY009112 for ; Wed, 8 Dec 2004 13:22:03 +0100 X-pt: isis.lip6.fr Received: from gargamel (rp [132.227.74.3]) by tibre.lip6.fr (8.11.6p3/8.11.6) with ESMTP id iB8CM3624948 for ; Wed, 8 Dec 2004 13:22:03 +0100 (CET) From: "Konstantin KABASSANOV" To: Date: Wed, 8 Dec 2004 13:22:10 +0100 Message-ID: <003101c4dd20$8ab9f070$8748e384@ipv6.lip6.fr> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_002D_01C4DD28.E7C5B260"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.5.10 (isis.lip6.fr [132.227.60.2]); Wed, 08 Dec 2004 13:22:03 +0100 (CET) X-Scanned-By: isis.lip6.fr Subject: the correct ipv6 behavior for interfaces with gif tunnel on them X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 12:22:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C4DD28.E7C5B260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I have a freebsd box with a gif tunnel configured. I observed that even if ifconfig displays MTU 1500 for both gif and physical interface, 1300 bytes ipv6 packets transiting on the gif interface are systematically fragmented while transiting on the lower physical interface to 1280 bytes. Is it the normal behavior? Thanks. Konstantin _________________________________ Konstantin K. KABASSANOV LIP6/CNRS 8, rue du Capitaine Scott 75015 Paris, France Phone: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: konstantin@kabassanov.com Web: http://www.kabassanov.com _________________________________ IMPORTANT! If you have tried to reply to this mail and you received a stupid message, announcing that the mail had been rejected as spam, please, resend your reply to the address above. The certificate used to sign this e-mail can be verified at: http://igc.services.cnrs.fr/CNRS-Standard/recherche.html "Too much is never enough." ( Me ;) ) ------=_NextPart_000_002D_01C4DD28.E7C5B260 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILszCCA2Qw ggJMoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwKzELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMx DTALBgNVBAMTBENOUlMwHhcNMDEwNDI3MDU0NDM2WhcNMjEwNDIyMDU0NDM2WjArMQswCQYDVQQG EwJGUjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SUzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAN13q/Hq/Hi1FKHcd2JWl4wvt1TCTFSm1H0iR3t0qffjrXxVshTwSF2YjwK9khG2 iE/EFfVvWFv3ibUn6q+g/KCOiIaPnyS2kE4k3GfQT49+Vi0bKAdysRdnoA7bQk7DfLQloviMBLGp gl2Mj9SDe+6qn9fS2/ZbbsKBENaaq12IHDbKBWRoS4uewFCUI/22KLWvXaTdpsXT2FcrPvi1usTY /xIiXyRpB2LkNEoId8owu+zT7XWQaKKMcXIn3hUmLCUhhCqeVxiBciO9Zh8P47e9F9oSuhlU9Bwt j3FSM7G2KLZ6aMuaTVI4+kiMwUuJlo/GF1vLuQ4OgVwaxzQ5V70CAwEAAaOBkjCBjzAMBgNVHRME BTADAQH/MB0GA1UdDgQWBBRW62i50lx+mLWlU8ORb2NYxPlrtzBTBgNVHSMETDBKgBRW62i50lx+ mLWlU8ORb2NYxPlrt6EvpC0wKzELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxDTALBgNVBAMT BENOUlOCAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4IBAQA418MpvHp3ol4WR0mGXtAZ OGregQgCuaegAqaIuA3iSTXO5qqiNNL5o4Q3mhXpWSu3vcwRrikhj4+ROfqdd+LoOersLtbKSEci TGWx07ZvWBs0LooQnRKEdKR5UlcAUxTImN6BbsULdada59M1CEWI9YRQmPAHPsWGPi4JWqLctqBr ezernwNwbt31nMAOBey1hFsjtIkhEIit+y0I5AATHFWzj3e+IKzcARx5fGcMWl9PuZSJvquaLBKx qGPGYoAD/Uxwlb3G6AXay74Jph/pbdKFLkPTHxpcdv4TdmFg+WTUWHi/f+/lc6ND2ip/d9s0eXLZ juWl7VLQxEZMXxuqMIIDbTCCAlWgAwIBAgIBAjANBgkqhkiG9w0BAQQFADArMQswCQYDVQQGEwJG UjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SUzAeFw0wMTA0MjcwNTQ2NDlaFw0xMTA0MjUw NTQ2NDlaMDQxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRYwFAYDVQQDEw1DTlJTLVN0YW5k YXJkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3OEeIT0Gi+q9XrSI2w+Tl7RtBz2G YgAtyv+1So7nVqSPYSzxoCqr9irdfCy/73VVC6wJTudOYcDnDPCQFUUSAsKM68MSZOJjEBguywcx 2YHl3CmCmzFW4oEeim+n6KlYEURWg12zTnhwLd+2/XKBRdXx7k3O777VPQyQIEWaCYCvD0zaIA6A vzqz6yeAwLkPwKFOQNw6/Woqv0DVLHGA+fi6a+TqKgCrL76a8Kd2bZgpnA8v8ELyGJdbyfbMGV+6 wr4S0lywkJTAt8sGBO+PMO0yLXpK95O7oAmktO4zy9CDm7W1s5DejpAeWZwg1Use7ddMT4b6HDoq oemsBaCdvwIDAQABo4GSMIGPMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFGdZpeUHdEkD7wXPzC6k GNUQyJ48MFMGA1UdIwRMMEqAFFbraLnSXH6YtaVTw5FvY1jE+Wu3oS+kLTArMQswCQYDVQQGEwJG UjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SU4IBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADggEBAAYDR4NyRZDCTuEh16sXqQFVBspAbVWiHV7r4hQjWeQJ4pD2PI02Bg9LpyYjZcLq Bppyu7iMy4pf73k2JX4A1/MGlPuDRCkmN8fu6YfObIaAG3E90mKv9s1ibFMP5nqTAIx7LjPgQR2q vmWYdvGVB3Sz5j9TddVLBjZLKcT23I4TgEAQc4KtFXsEcVC1NzPyyGS7oRB+Nsatr29wUqbRrszM urDoWRKPYg2tA91LKuiJOYhRL+1h6Lcwh9snVW1mh6NRCYBhcVEFvhMd2UEw/HVfCpabGP++kIG0 E8ByEQj9appqB730gyy0YDZkB/o9aqewkAR2g90zyzTiF5gEC6EwggTWMIIDvqADAgECAgILQTAN BgkqhkiG9w0BAQQFADA0MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzEWMBQGA1UEAxMNQ05S Uy1TdGFuZGFyZDAeFw0wNDAxMDUxMjE4MzFaFw0wNTAxMDUxMjE4MzFaMHwxCzAJBgNVBAYTAkZS MQ0wCwYDVQQKEwRDTlJTMRAwDgYDVQQLEwdVTVI3NjA2MR4wHAYDVQQDExVLb25zdGFudGluIEth YmFzc2Fub3YxLDAqBgkqhkiG9w0BCQEWHUtvbnN0YW50aW4uS2FiYXNzYW5vdkBsaXA2LmZyMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMyNgVgMXjrGwkogB8dH3FSBbwkqD6t1XmVV 55yDfdmf+YGsujHf1LYvF6fRCvgm81JufqeyLc3LSlgglXl5QeUOW37Ospp/iAdIh/ZURZiWA1RX imvqo9iTUvx2zUTwqIP8dRJye5bgYGBEJRCmE0TYMwSkmHSmTERpvoDNBNCFVGOrsZTOPYXtNsKf iAfNi7pFdfxE9Ij6/gQNM/0Q3RNiiXmO5IkHAlxgwwqHABx1Ld169HlSfoKAeq6KTsOECkOxAijj mQtgJs/eE5MtMST9IfqQkmhpt7intE2k2TrZ1tEo92pErYkNrNKhYqdM2/jMeGJsdvnlgUsa1HiI mQIDAQABo4IBqDCCAaQwDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBLAwDgYDVR0PAQH/ BAQDAgXgMHgGCWCGSAGG+EIBDQRrFmlDZXJ0aWZpY2F0IENOUlMtU3RhbmRhcmQuIFBvdXIgdG91 dGUgaW5mb3JtYXRpb24gc2UgcmVwb3J0ZXIg4CBodHRwOi8vaWdjLnNlcnZpY2VzLmNucnMuZnIv Q05SUy1TdGFuZGFyZC8wHQYDVR0OBBYEFBw5elbdCpZR0WnR27EsQjmRr3/EMFMGA1UdIwRMMEqA FGdZpeUHdEkD7wXPzC6kGNUQyJ48oS+kLTArMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzEN MAsGA1UEAxMEQ05SU4IBAjAoBgNVHREEITAfgR1Lb25zdGFudGluLkthYmFzc2Fub3ZAbGlwNi5m cjBZBgNVHR8EUjBQME6gTKBKhkhodHRwOi8vaWdjLnNlcnZpY2VzLmNucnMuZnIvY2dpLWJpbi9s b2FkLmNybD9DQT1DTlJTLVN0YW5kYXJkJmZvcm1hdD1ERVIwDQYJKoZIhvcNAQEEBQADggEBAD8m erny2WgvzJkuFcYNqqWA9g/7n1qF32uEgzbb+/lDejf7URAuuZqAeMxzF4uvRgDc8pr3EowjoKuD 5OsPdKboekM7B3Kn5J9IoF/Zq9FIw4A63k+KczTMlmFZXbvqBKHVLmG+Y8/FoEcC3xbYFDvKLP/q OOdXgcDOe60b4886fMFDUSOODryacoDAhCNWzuS6+v9JvZ5vFvR0hbkzGuzn/5ZR1H97BirD6ZlS f/bo3awEbsWEXcdj/tltVvc6kW61l1PieIyTd1RPtU99uhpmcUDtT7v5+Y7tjtvemfONmHHa2Jmp fohq8/1IFkhv0r3xHU0xROff+4sQrt3KjLgxggLDMIICvwIBATA6MDQxCzAJBgNVBAYTAkZSMQ0w CwYDVQQKEwRDTlJTMRYwFAYDVQQDEw1DTlJTLVN0YW5kYXJkAgILQTAJBgUrDgMCGgUAoIIBXjAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEyMDgxMjIyMDNaMCMG CSqGSIb3DQEJBDEWBBRg4TzAPLPqEjvdoNsW+msBL0goiDBJBgkrBgEEAYI3EAQxPDA6MDQxCzAJ BgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRYwFAYDVQQDEw1DTlJTLVN0YW5kYXJkAgILQTBLBgsq hkiG9w0BCRACCzE8oDowNDELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxFjAUBgNVBAMTDUNO UlMtU3RhbmRhcmQCAgtBMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBALpHScEBFXkhVQwkIqTvsKs74Wd/gyFaa+9frlFIGGDR F2elbgiTK8J5PBYUpi8ReBTLjcyJ+w20KrDjCqTUUK9PpTcasu8UjTelNPfUnyNKgvPnvVxEE9VM hT57tDd+f+v9/ug8cLigomyPciKS8IAgaMn3ZN/TBQ2lBGfolmKc8dxRc/Il/Z6AkiTkdr3tN95m xiqYhdUpA65Z+bGKGb77K6hthVf/TUJcYICSCb3FuWNTEFnMKzEldk898+yr0SiU/1DxVOh982/6 U438KWdf8+U1X/25yZ7wkcbx7J97g1FYNB0bpz2MfJb8nIVpMxzq3/T88s2bGN/G6IGUe2AAAAAA AAA= ------=_NextPart_000_002D_01C4DD28.E7C5B260-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 13:04:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F04916A4CE; Wed, 8 Dec 2004 13:04:48 +0000 (GMT) Received: from BASE.OTEL.net (BASE.OTEL.net [212.36.8.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id C922843D46; Wed, 8 Dec 2004 13:04:46 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by BASE.OTEL.net with esmtp (Exim 4.30; FreeBSD) id 1Cc1Ur-0009uc-HF; Wed, 08 Dec 2004 15:04:45 +0200 Message-ID: <41B6FC08.5080905@OTEL.net> Date: Wed, 08 Dec 2004 15:05:12 +0200 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041117 X-Accept-Language: bg, en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------060804070402080204060705" cc: freebsd-net@freebsd.org Subject: Re: em(4) VLAN + PROMISC still doesn't work with latest CVS version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 13:04:48 -0000 This is a multi-part message in MIME format. --------------060804070402080204060705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Robert Watson wrote: >On Wed, 8 Dec 2004, Iasen Kostov wrote: > > > >>#:> ident if_em.c >>if_em.c: >> $FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 >>rwatson Exp $ >> >>I've deleted the whole dir and cvsuped. Does 1.54 differs much from >>1.44.2.4 ? >> >> > >Very odd. I have 1.44.2.4 checked out here, and if_em.diff applied >without a hitch. Here's a version of the patch generated using cvs diff >against the older revision. It should be basically identical to the >version I sent you before, though. Diffing the two diffs generates only >line number differences. > >If this doesn't work, drop me a copy of your if_em.c and I'll apply the >change manually. > > > Same happens - here is the if_em.c --------------060804070402080204060705 Content-Type: text/plain; name="if_em.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="if_em.c" /************************************************************************** Copyright (c) 2001-2003, Intel Corporation All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the Intel Corporation nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ***************************************************************************/ /*$FreeBSD: src/sys/dev/em/if_em.c,v 1.44.2.4 2004/11/23 22:28:40 rwatson Exp $*/ #include /********************************************************************* * Set this to one to display debug statistics *********************************************************************/ int em_display_debug_stats = 0; /********************************************************************* * Linked list of board private structures for all NICs found *********************************************************************/ struct adapter *em_adapter_list = NULL; /********************************************************************* * Driver version *********************************************************************/ char em_driver_version[] = "1.7.35"; /********************************************************************* * PCI Device ID Table * * Used by probe to select devices to load on * Last field stores an index into em_strings * Last entry must be all 0s * * { Vendor ID, Device ID, SubVendor ID, SubDevice ID, String Index } *********************************************************************/ static em_vendor_info_t em_vendor_info_array[] = { /* Intel(R) PRO/1000 Network Connection */ { 0x8086, 0x1000, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1001, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1004, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1008, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1009, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x100C, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x100D, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x100E, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x100F, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1010, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1011, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1012, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1013, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1015, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1016, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1017, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1018, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1019, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x101A, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x101D, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x101E, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1026, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1027, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1028, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1075, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1076, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1077, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1078, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x1079, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x107A, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x107B, PCI_ANY_ID, PCI_ANY_ID, 0}, { 0x8086, 0x107C, PCI_ANY_ID, PCI_ANY_ID, 0}, /* required last entry */ { 0, 0, 0, 0, 0} }; /********************************************************************* * Table of branding strings for all supported NICs. *********************************************************************/ static char *em_strings[] = { "Intel(R) PRO/1000 Network Connection" }; /********************************************************************* * Function prototypes *********************************************************************/ static int em_probe(device_t); static int em_attach(device_t); static int em_detach(device_t); static int em_shutdown(device_t); static void em_intr(void *); static void em_start(struct ifnet *); static int em_ioctl(struct ifnet *, u_long, caddr_t); static void em_watchdog(struct ifnet *); static void em_init(void *); static void em_init_locked(struct adapter *); static void em_stop(void *); static void em_media_status(struct ifnet *, struct ifmediareq *); static int em_media_change(struct ifnet *); static void em_identify_hardware(struct adapter *); static int em_allocate_pci_resources(struct adapter *); static void em_free_pci_resources(struct adapter *); static void em_local_timer(void *); static int em_hardware_init(struct adapter *); static void em_setup_interface(device_t, struct adapter *); static int em_setup_transmit_structures(struct adapter *); static void em_initialize_transmit_unit(struct adapter *); static int em_setup_receive_structures(struct adapter *); static void em_initialize_receive_unit(struct adapter *); static void em_enable_intr(struct adapter *); static void em_disable_intr(struct adapter *); static void em_free_transmit_structures(struct adapter *); static void em_free_receive_structures(struct adapter *); static void em_update_stats_counters(struct adapter *); static void em_clean_transmit_interrupts(struct adapter *); static int em_allocate_receive_structures(struct adapter *); static int em_allocate_transmit_structures(struct adapter *); static void em_process_receive_interrupts(struct adapter *, int); static void em_receive_checksum(struct adapter *, struct em_rx_desc *, struct mbuf *); static void em_transmit_checksum_setup(struct adapter *, struct mbuf *, u_int32_t *, u_int32_t *); static void em_set_promisc(struct adapter *); static void em_disable_promisc(struct adapter *); static void em_set_multi(struct adapter *); static void em_print_hw_stats(struct adapter *); static void em_print_link_status(struct adapter *); static int em_get_buf(int i, struct adapter *, struct mbuf *); static void em_enable_vlans(struct adapter *); static int em_encap(struct adapter *, struct mbuf **); static void em_smartspeed(struct adapter *); static int em_82547_fifo_workaround(struct adapter *, int); static void em_82547_update_fifo_head(struct adapter *, int); static int em_82547_tx_fifo_reset(struct adapter *); static void em_82547_move_tail(void *arg); static void em_82547_move_tail_locked(struct adapter *); static int em_dma_malloc(struct adapter *, bus_size_t, struct em_dma_alloc *, int); static void em_dma_free(struct adapter *, struct em_dma_alloc *); static void em_print_debug_info(struct adapter *); static int em_is_valid_ether_addr(u_int8_t *); static int em_sysctl_stats(SYSCTL_HANDLER_ARGS); static int em_sysctl_debug_info(SYSCTL_HANDLER_ARGS); static u_int32_t em_fill_descriptors (u_int64_t address, u_int32_t length, PDESC_ARRAY desc_array); static int em_sysctl_int_delay(SYSCTL_HANDLER_ARGS); static void em_add_int_delay_sysctl(struct adapter *, const char *, const char *, struct em_int_delay_info *, int, int); /********************************************************************* * FreeBSD Device Interface Entry Points *********************************************************************/ static device_method_t em_methods[] = { /* Device interface */ DEVMETHOD(device_probe, em_probe), DEVMETHOD(device_attach, em_attach), DEVMETHOD(device_detach, em_detach), DEVMETHOD(device_shutdown, em_shutdown), {0, 0} }; static driver_t em_driver = { "em", em_methods, sizeof(struct adapter ), }; static devclass_t em_devclass; DRIVER_MODULE(em, pci, em_driver, em_devclass, 0, 0); MODULE_DEPEND(em, pci, 1, 1, 1); MODULE_DEPEND(em, ether, 1, 1, 1); /********************************************************************* * Tunable default values. *********************************************************************/ #define E1000_TICKS_TO_USECS(ticks) ((1024 * (ticks) + 500) / 1000) #define E1000_USECS_TO_TICKS(usecs) ((1000 * (usecs) + 512) / 1024) static int em_tx_int_delay_dflt = E1000_TICKS_TO_USECS(EM_TIDV); static int em_rx_int_delay_dflt = E1000_TICKS_TO_USECS(EM_RDTR); static int em_tx_abs_int_delay_dflt = E1000_TICKS_TO_USECS(EM_TADV); static int em_rx_abs_int_delay_dflt = E1000_TICKS_TO_USECS(EM_RADV); TUNABLE_INT("hw.em.tx_int_delay", &em_tx_int_delay_dflt); TUNABLE_INT("hw.em.rx_int_delay", &em_rx_int_delay_dflt); TUNABLE_INT("hw.em.tx_abs_int_delay", &em_tx_abs_int_delay_dflt); TUNABLE_INT("hw.em.rx_abs_int_delay", &em_rx_abs_int_delay_dflt); /********************************************************************* * Device identification routine * * em_probe determines if the driver should be loaded on * adapter based on PCI vendor/device id of the adapter. * * return 0 on success, positive on failure *********************************************************************/ static int em_probe(device_t dev) { em_vendor_info_t *ent; u_int16_t pci_vendor_id = 0; u_int16_t pci_device_id = 0; u_int16_t pci_subvendor_id = 0; u_int16_t pci_subdevice_id = 0; char adapter_name[60]; INIT_DEBUGOUT("em_probe: begin"); pci_vendor_id = pci_get_vendor(dev); if (pci_vendor_id != EM_VENDOR_ID) return(ENXIO); pci_device_id = pci_get_device(dev); pci_subvendor_id = pci_get_subvendor(dev); pci_subdevice_id = pci_get_subdevice(dev); ent = em_vendor_info_array; while (ent->vendor_id != 0) { if ((pci_vendor_id == ent->vendor_id) && (pci_device_id == ent->device_id) && ((pci_subvendor_id == ent->subvendor_id) || (ent->subvendor_id == PCI_ANY_ID)) && ((pci_subdevice_id == ent->subdevice_id) || (ent->subdevice_id == PCI_ANY_ID))) { sprintf(adapter_name, "%s, Version - %s", em_strings[ent->index], em_driver_version); device_set_desc_copy(dev, adapter_name); return(0); } ent++; } return(ENXIO); } /********************************************************************* * Device initialization routine * * The attach entry point is called when the driver is being loaded. * This routine identifies the type of hardware, allocates all resources * and initializes the hardware. * * return 0 on success, positive on failure *********************************************************************/ static int em_attach(device_t dev) { struct adapter * adapter; int tsize, rsize; int error = 0; INIT_DEBUGOUT("em_attach: begin"); /* Allocate, clear, and link in our adapter structure */ if (!(adapter = device_get_softc(dev))) { printf("em: adapter structure allocation failed\n"); return(ENOMEM); } bzero(adapter, sizeof(struct adapter )); adapter->dev = dev; adapter->osdep.dev = dev; adapter->unit = device_get_unit(dev); EM_LOCK_INIT(adapter, device_get_nameunit(dev)); if (em_adapter_list != NULL) em_adapter_list->prev = adapter; adapter->next = em_adapter_list; em_adapter_list = adapter; /* SYSCTL stuff */ sysctl_ctx_init(&adapter->sysctl_ctx); adapter->sysctl_tree = SYSCTL_ADD_NODE(&adapter->sysctl_ctx, SYSCTL_STATIC_CHILDREN(_hw), OID_AUTO, device_get_nameunit(dev), CTLFLAG_RD, 0, ""); if (adapter->sysctl_tree == NULL) { error = EIO; goto err_sysctl; } SYSCTL_ADD_PROC(&adapter->sysctl_ctx, SYSCTL_CHILDREN(adapter->sysctl_tree), OID_AUTO, "debug_info", CTLTYPE_INT|CTLFLAG_RW, (void *)adapter, 0, em_sysctl_debug_info, "I", "Debug Information"); SYSCTL_ADD_PROC(&adapter->sysctl_ctx, SYSCTL_CHILDREN(adapter->sysctl_tree), OID_AUTO, "stats", CTLTYPE_INT|CTLFLAG_RW, (void *)adapter, 0, em_sysctl_stats, "I", "Statistics"); callout_init(&adapter->timer, CALLOUT_MPSAFE); callout_init(&adapter->tx_fifo_timer, CALLOUT_MPSAFE); /* Determine hardware revision */ em_identify_hardware(adapter); /* Set up some sysctls for the tunable interrupt delays */ em_add_int_delay_sysctl(adapter, "rx_int_delay", "receive interrupt delay in usecs", &adapter->rx_int_delay, E1000_REG_OFFSET(&adapter->hw, RDTR), em_rx_int_delay_dflt); em_add_int_delay_sysctl(adapter, "tx_int_delay", "transmit interrupt delay in usecs", &adapter->tx_int_delay, E1000_REG_OFFSET(&adapter->hw, TIDV), em_tx_int_delay_dflt); if (adapter->hw.mac_type >= em_82540) { em_add_int_delay_sysctl(adapter, "rx_abs_int_delay", "receive interrupt delay limit in usecs", &adapter->rx_abs_int_delay, E1000_REG_OFFSET(&adapter->hw, RADV), em_rx_abs_int_delay_dflt); em_add_int_delay_sysctl(adapter, "tx_abs_int_delay", "transmit interrupt delay limit in usecs", &adapter->tx_abs_int_delay, E1000_REG_OFFSET(&adapter->hw, TADV), em_tx_abs_int_delay_dflt); } /* Parameters (to be read from user) */ adapter->num_tx_desc = EM_MAX_TXD; adapter->num_rx_desc = EM_MAX_RXD; adapter->hw.autoneg = DO_AUTO_NEG; adapter->hw.wait_autoneg_complete = WAIT_FOR_AUTO_NEG_DEFAULT; adapter->hw.autoneg_advertised = AUTONEG_ADV_DEFAULT; adapter->hw.tbi_compatibility_en = TRUE; adapter->rx_buffer_len = EM_RXBUFFER_2048; /* * These parameters control the automatic generation(Tx) and * response(Rx) to Ethernet PAUSE frames. */ adapter->hw.fc_high_water = FC_DEFAULT_HI_THRESH; adapter->hw.fc_low_water = FC_DEFAULT_LO_THRESH; adapter->hw.fc_pause_time = FC_DEFAULT_TX_TIMER; adapter->hw.fc_send_xon = TRUE; adapter->hw.fc = em_fc_full; adapter->hw.phy_init_script = 1; adapter->hw.phy_reset_disable = FALSE; #ifndef EM_MASTER_SLAVE adapter->hw.master_slave = em_ms_hw_default; #else adapter->hw.master_slave = EM_MASTER_SLAVE; #endif /* * Set the max frame size assuming standard ethernet * sized frames */ adapter->hw.max_frame_size = ETHERMTU + ETHER_HDR_LEN + ETHER_CRC_LEN; adapter->hw.min_frame_size = MINIMUM_ETHERNET_PACKET_SIZE + ETHER_CRC_LEN; /* * This controls when hardware reports transmit completion * status. */ adapter->hw.report_tx_early = 1; if (em_allocate_pci_resources(adapter)) { printf("em%d: Allocation of PCI resources failed\n", adapter->unit); error = ENXIO; goto err_pci; } /* Initialize eeprom parameters */ em_init_eeprom_params(&adapter->hw); tsize = EM_ROUNDUP(adapter->num_tx_desc * sizeof(struct em_tx_desc), 4096); /* Allocate Transmit Descriptor ring */ if (em_dma_malloc(adapter, tsize, &adapter->txdma, BUS_DMA_NOWAIT)) { printf("em%d: Unable to allocate tx_desc memory\n", adapter->unit); error = ENOMEM; goto err_tx_desc; } adapter->tx_desc_base = (struct em_tx_desc *) adapter->txdma.dma_vaddr; rsize = EM_ROUNDUP(adapter->num_rx_desc * sizeof(struct em_rx_desc), 4096); /* Allocate Receive Descriptor ring */ if (em_dma_malloc(adapter, rsize, &adapter->rxdma, BUS_DMA_NOWAIT)) { printf("em%d: Unable to allocate rx_desc memory\n", adapter->unit); error = ENOMEM; goto err_rx_desc; } adapter->rx_desc_base = (struct em_rx_desc *) adapter->rxdma.dma_vaddr; /* Initialize the hardware */ if (em_hardware_init(adapter)) { printf("em%d: Unable to initialize the hardware\n", adapter->unit); error = EIO; goto err_hw_init; } /* Copy the permanent MAC address out of the EEPROM */ if (em_read_mac_addr(&adapter->hw) < 0) { printf("em%d: EEPROM read error while reading mac address\n", adapter->unit); error = EIO; goto err_mac_addr; } if (!em_is_valid_ether_addr(adapter->hw.mac_addr)) { printf("em%d: Invalid mac address\n", adapter->unit); error = EIO; goto err_mac_addr; } bcopy(adapter->hw.mac_addr, adapter->interface_data.ac_enaddr, ETHER_ADDR_LEN); /* Setup OS specific network interface */ em_setup_interface(dev, adapter); /* Initialize statistics */ em_clear_hw_cntrs(&adapter->hw); em_update_stats_counters(adapter); adapter->hw.get_link_status = 1; em_check_for_link(&adapter->hw); /* Print the link status */ if (adapter->link_active == 1) { em_get_speed_and_duplex(&adapter->hw, &adapter->link_speed, &adapter->link_duplex); printf("em%d: Speed:%d Mbps Duplex:%s\n", adapter->unit, adapter->link_speed, adapter->link_duplex == FULL_DUPLEX ? "Full" : "Half"); } else printf("em%d: Speed:N/A Duplex:N/A\n", adapter->unit); /* Identify 82544 on PCIX */ em_get_bus_info(&adapter->hw); if(adapter->hw.bus_type == em_bus_type_pcix && adapter->hw.mac_type == em_82544) { adapter->pcix_82544 = TRUE; } else { adapter->pcix_82544 = FALSE; } INIT_DEBUGOUT("em_attach: end"); return(0); err_mac_addr: err_hw_init: em_dma_free(adapter, &adapter->rxdma); err_rx_desc: em_dma_free(adapter, &adapter->txdma); err_tx_desc: err_pci: em_free_pci_resources(adapter); sysctl_ctx_free(&adapter->sysctl_ctx); err_sysctl: return(error); } /********************************************************************* * Device removal routine * * The detach entry point is called when the driver is being removed. * This routine stops the adapter and deallocates all the resources * that were allocated for driver operation. * * return 0 on success, positive on failure *********************************************************************/ static int em_detach(device_t dev) { struct adapter * adapter = device_get_softc(dev); struct ifnet *ifp = &adapter->interface_data.ac_if; INIT_DEBUGOUT("em_detach: begin"); EM_LOCK(adapter); adapter->in_detach = 1; em_stop(adapter); em_phy_hw_reset(&adapter->hw); EM_UNLOCK(adapter); #if __FreeBSD_version < 500000 ether_ifdetach(&adapter->interface_data.ac_if, ETHER_BPF_SUPPORTED); #else ether_ifdetach(&adapter->interface_data.ac_if); #endif em_free_pci_resources(adapter); bus_generic_detach(dev); /* Free Transmit Descriptor ring */ if (adapter->tx_desc_base) { em_dma_free(adapter, &adapter->txdma); adapter->tx_desc_base = NULL; } /* Free Receive Descriptor ring */ if (adapter->rx_desc_base) { em_dma_free(adapter, &adapter->rxdma); adapter->rx_desc_base = NULL; } /* Free the sysctl tree */ sysctl_ctx_free(&adapter->sysctl_ctx); /* Remove from the adapter list */ if (em_adapter_list == adapter) em_adapter_list = adapter->next; if (adapter->next != NULL) adapter->next->prev = adapter->prev; if (adapter->prev != NULL) adapter->prev->next = adapter->next; EM_LOCK_DESTROY(adapter); ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE); ifp->if_timer = 0; return(0); } /********************************************************************* * * Shutdown entry point * **********************************************************************/ static int em_shutdown(device_t dev) { struct adapter *adapter = device_get_softc(dev); EM_LOCK(adapter); em_stop(adapter); EM_UNLOCK(adapter); return(0); } /********************************************************************* * Transmit entry point * * em_start is called by the stack to initiate a transmit. * The driver will remain in this routine as long as there are * packets to transmit and transmit resources are available. * In case resources are not available stack is notified and * the packet is requeued. **********************************************************************/ static void em_start_locked(struct ifnet *ifp) { struct mbuf *m_head; struct adapter *adapter = ifp->if_softc; mtx_assert(&adapter->mtx, MA_OWNED); if (!adapter->link_active) return; while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); if (m_head == NULL) break; /* * em_encap() can modify our pointer, and or make it NULL on * failure. In that event, we can't requeue. */ if (em_encap(adapter, &m_head)) { if (m_head == NULL) break; ifp->if_flags |= IFF_OACTIVE; IFQ_DRV_PREPEND(&ifp->if_snd, m_head); break; } /* Send a copy of the frame to the BPF listener */ #if __FreeBSD_version < 500000 if (ifp->if_bpf) bpf_mtap(ifp, m_head); #else BPF_MTAP(ifp, m_head); #endif /* Set timeout in case hardware has problems transmitting */ ifp->if_timer = EM_TX_TIMEOUT; } return; } static void em_start(struct ifnet *ifp) { struct adapter *adapter = ifp->if_softc; EM_LOCK(adapter); em_start_locked(ifp); EM_UNLOCK(adapter); return; } /********************************************************************* * Ioctl entry point * * em_ioctl is called when the user wants to configure the * interface. * * return 0 on success, positive on failure **********************************************************************/ static int em_ioctl(struct ifnet *ifp, u_long command, caddr_t data) { int mask, reinit, error = 0; struct ifreq *ifr = (struct ifreq *) data; struct adapter * adapter = ifp->if_softc; if (adapter->in_detach) return(error); switch (command) { case SIOCSIFADDR: case SIOCGIFADDR: IOCTL_DEBUGOUT("ioctl rcv'd: SIOCxIFADDR (Get/Set Interface Addr)"); ether_ioctl(ifp, command, data); break; case SIOCSIFMTU: IOCTL_DEBUGOUT("ioctl rcv'd: SIOCSIFMTU (Set Interface MTU)"); if (ifr->ifr_mtu > MAX_JUMBO_FRAME_SIZE - ETHER_HDR_LEN) { error = EINVAL; } else { EM_LOCK(adapter); ifp->if_mtu = ifr->ifr_mtu; adapter->hw.max_frame_size = ifp->if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN; em_init_locked(adapter); EM_UNLOCK(adapter); } break; case SIOCSIFFLAGS: IOCTL_DEBUGOUT("ioctl rcv'd: SIOCSIFFLAGS (Set Interface Flags)"); EM_LOCK(adapter); if (ifp->if_flags & IFF_UP) { if (!(ifp->if_flags & IFF_RUNNING)) { em_init_locked(adapter); } em_disable_promisc(adapter); em_set_promisc(adapter); } else { if (ifp->if_flags & IFF_RUNNING) { em_stop(adapter); } } EM_UNLOCK(adapter); break; case SIOCADDMULTI: case SIOCDELMULTI: IOCTL_DEBUGOUT("ioctl rcv'd: SIOC(ADD|DEL)MULTI"); if (ifp->if_flags & IFF_RUNNING) { EM_LOCK(adapter); em_disable_intr(adapter); em_set_multi(adapter); if (adapter->hw.mac_type == em_82542_rev2_0) { em_initialize_receive_unit(adapter); } #ifdef DEVICE_POLLING if (!(ifp->if_flags & IFF_POLLING)) #endif em_enable_intr(adapter); EM_UNLOCK(adapter); } break; case SIOCSIFMEDIA: case SIOCGIFMEDIA: IOCTL_DEBUGOUT("ioctl rcv'd: SIOCxIFMEDIA (Get/Set Interface Media)"); error = ifmedia_ioctl(ifp, ifr, &adapter->media, command); break; case SIOCSIFCAP: IOCTL_DEBUGOUT("ioctl rcv'd: SIOCSIFCAP (Set Capabilities)"); reinit = 0; mask = ifr->ifr_reqcap ^ ifp->if_capenable; if (mask & IFCAP_POLLING) ifp->if_capenable ^= IFCAP_POLLING; if (mask & IFCAP_HWCSUM) { ifp->if_capenable ^= IFCAP_HWCSUM; reinit = 1; } if (mask & IFCAP_VLAN_HWTAGGING) { ifp->if_capenable ^= IFCAP_VLAN_HWTAGGING; reinit = 1; } if (reinit && (ifp->if_flags & IFF_RUNNING)) em_init(adapter); break; default: IOCTL_DEBUGOUT1("ioctl received: UNKNOWN (0x%x)", (int)command); error = EINVAL; } return(error); } /********************************************************************* * Watchdog entry point * * This routine is called whenever hardware quits transmitting. * **********************************************************************/ static void em_watchdog(struct ifnet *ifp) { struct adapter * adapter; adapter = ifp->if_softc; /* If we are in this routine because of pause frames, then * don't reset the hardware. */ if (E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF) { ifp->if_timer = EM_TX_TIMEOUT; return; } if (em_check_for_link(&adapter->hw)) printf("em%d: watchdog timeout -- resetting\n", adapter->unit); ifp->if_flags &= ~IFF_RUNNING; em_init(adapter); ifp->if_oerrors++; return; } /********************************************************************* * Init entry point * * This routine is used in two ways. It is used by the stack as * init entry point in network interface structure. It is also used * by the driver as a hw/sw initialization routine to get to a * consistent state. * * return 0 on success, positive on failure **********************************************************************/ static void em_init_locked(struct adapter * adapter) { struct ifnet *ifp; uint32_t pba; ifp = &adapter->interface_data.ac_if; INIT_DEBUGOUT("em_init: begin"); mtx_assert(&adapter->mtx, MA_OWNED); em_stop(adapter); /* Packet Buffer Allocation (PBA) * Writing PBA sets the receive portion of the buffer * the remainder is used for the transmit buffer. * * Devices before the 82547 had a Packet Buffer of 64K. * Default allocation: PBA=48K for Rx, leaving 16K for Tx. * After the 82547 the buffer was reduced to 40K. * Default allocation: PBA=30K for Rx, leaving 10K for Tx. * Note: default does not leave enough room for Jumbo Frame >10k. */ if(adapter->hw.mac_type < em_82547) { /* Total FIFO is 64K */ if(adapter->rx_buffer_len > EM_RXBUFFER_8192) pba = E1000_PBA_40K; /* 40K for Rx, 24K for Tx */ else pba = E1000_PBA_48K; /* 48K for Rx, 16K for Tx */ } else { /* Total FIFO is 40K */ if(adapter->hw.max_frame_size > EM_RXBUFFER_8192) { pba = E1000_PBA_22K; /* 22K for Rx, 18K for Tx */ } else { pba = E1000_PBA_30K; /* 30K for Rx, 10K for Tx */ } adapter->tx_fifo_head = 0; adapter->tx_head_addr = pba << EM_TX_HEAD_ADDR_SHIFT; adapter->tx_fifo_size = (E1000_PBA_40K - pba) << EM_PBA_BYTES_SHIFT; } INIT_DEBUGOUT1("em_init: pba=%dK",pba); E1000_WRITE_REG(&adapter->hw, PBA, pba); /* Get the latest mac address, User can use a LAA */ bcopy(adapter->interface_data.ac_enaddr, adapter->hw.mac_addr, ETHER_ADDR_LEN); /* Initialize the hardware */ if (em_hardware_init(adapter)) { printf("em%d: Unable to initialize the hardware\n", adapter->unit); return; } if (ifp->if_capenable & IFCAP_VLAN_HWTAGGING) em_enable_vlans(adapter); /* Prepare transmit descriptors and buffers */ if (em_setup_transmit_structures(adapter)) { printf("em%d: Could not setup transmit structures\n", adapter->unit); em_stop(adapter); return; } em_initialize_transmit_unit(adapter); /* Setup Multicast table */ em_set_multi(adapter); /* Prepare receive descriptors and buffers */ if (em_setup_receive_structures(adapter)) { printf("em%d: Could not setup receive structures\n", adapter->unit); em_stop(adapter); return; } em_initialize_receive_unit(adapter); /* Don't loose promiscuous settings */ em_set_promisc(adapter); ifp->if_flags |= IFF_RUNNING; ifp->if_flags &= ~IFF_OACTIVE; if (adapter->hw.mac_type >= em_82543) { if (ifp->if_capenable & IFCAP_TXCSUM) ifp->if_hwassist = EM_CHECKSUM_FEATURES; else ifp->if_hwassist = 0; } callout_reset(&adapter->timer, 2*hz, em_local_timer, adapter); em_clear_hw_cntrs(&adapter->hw); #ifdef DEVICE_POLLING /* * Only enable interrupts if we are not polling, make sure * they are off otherwise. */ if (ifp->if_flags & IFF_POLLING) em_disable_intr(adapter); else #endif /* DEVICE_POLLING */ em_enable_intr(adapter); /* Don't reset the phy next time init gets called */ adapter->hw.phy_reset_disable = TRUE; return; } static void em_init(void *arg) { struct adapter * adapter = arg; EM_LOCK(adapter); em_init_locked(adapter); EM_UNLOCK(adapter); return; } #ifdef DEVICE_POLLING static poll_handler_t em_poll; static void em_poll_locked(struct ifnet *ifp, enum poll_cmd cmd, int count) { struct adapter *adapter = ifp->if_softc; u_int32_t reg_icr; mtx_assert(&adapter->mtx, MA_OWNED); if (!(ifp->if_capenable & IFCAP_POLLING)) { ether_poll_deregister(ifp); cmd = POLL_DEREGISTER; } if (cmd == POLL_DEREGISTER) { /* final call, enable interrupts */ em_enable_intr(adapter); return; } if (cmd == POLL_AND_CHECK_STATUS) { reg_icr = E1000_READ_REG(&adapter->hw, ICR); if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { callout_stop(&adapter->timer); adapter->hw.get_link_status = 1; em_check_for_link(&adapter->hw); em_print_link_status(adapter); callout_reset(&adapter->timer, 2*hz, em_local_timer, adapter); } } if (ifp->if_flags & IFF_RUNNING) { em_process_receive_interrupts(adapter, count); em_clean_transmit_interrupts(adapter); } if (ifp->if_flags & IFF_RUNNING && !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) em_start_locked(ifp); } static void em_poll(struct ifnet *ifp, enum poll_cmd cmd, int count) { struct adapter *adapter = ifp->if_softc; EM_LOCK(adapter); em_poll_locked(ifp, cmd, count); EM_UNLOCK(adapter); } #endif /* DEVICE_POLLING */ /********************************************************************* * * Interrupt Service routine * **********************************************************************/ static void em_intr(void *arg) { u_int32_t loop_cnt = EM_MAX_INTR; u_int32_t reg_icr; struct ifnet *ifp; struct adapter *adapter = arg; EM_LOCK(adapter); ifp = &adapter->interface_data.ac_if; #ifdef DEVICE_POLLING if (ifp->if_flags & IFF_POLLING) { EM_UNLOCK(adapter); return; } if ((ifp->if_capenable & IFCAP_POLLING) && ether_poll_register(em_poll, ifp)) { em_disable_intr(adapter); em_poll_locked(ifp, 0, 1); EM_UNLOCK(adapter); return; } #endif /* DEVICE_POLLING */ reg_icr = E1000_READ_REG(&adapter->hw, ICR); if (!reg_icr) { EM_UNLOCK(adapter); return; } /* Link status change */ if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { callout_stop(&adapter->timer); adapter->hw.get_link_status = 1; em_check_for_link(&adapter->hw); em_print_link_status(adapter); callout_reset(&adapter->timer, 2*hz, em_local_timer, adapter); } while (loop_cnt > 0) { if (ifp->if_flags & IFF_RUNNING) { em_process_receive_interrupts(adapter, -1); em_clean_transmit_interrupts(adapter); } loop_cnt--; } if (ifp->if_flags & IFF_RUNNING && !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) em_start_locked(ifp); EM_UNLOCK(adapter); return; } /********************************************************************* * * Media Ioctl callback * * This routine is called whenever the user queries the status of * the interface using ifconfig. * **********************************************************************/ static void em_media_status(struct ifnet *ifp, struct ifmediareq *ifmr) { struct adapter * adapter = ifp->if_softc; INIT_DEBUGOUT("em_media_status: begin"); em_check_for_link(&adapter->hw); if (E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_LU) { if (adapter->link_active == 0) { em_get_speed_and_duplex(&adapter->hw, &adapter->link_speed, &adapter->link_duplex); adapter->link_active = 1; } } else { if (adapter->link_active == 1) { adapter->link_speed = 0; adapter->link_duplex = 0; adapter->link_active = 0; } } ifmr->ifm_status = IFM_AVALID; ifmr->ifm_active = IFM_ETHER; if (!adapter->link_active) return; ifmr->ifm_status |= IFM_ACTIVE; if (adapter->hw.media_type == em_media_type_fiber) { ifmr->ifm_active |= IFM_1000_SX | IFM_FDX; } else { switch (adapter->link_speed) { case 10: ifmr->ifm_active |= IFM_10_T; break; case 100: ifmr->ifm_active |= IFM_100_TX; break; case 1000: #if __FreeBSD_version < 500000 ifmr->ifm_active |= IFM_1000_TX; #else ifmr->ifm_active |= IFM_1000_T; #endif break; } if (adapter->link_duplex == FULL_DUPLEX) ifmr->ifm_active |= IFM_FDX; else ifmr->ifm_active |= IFM_HDX; } return; } /********************************************************************* * * Media Ioctl callback * * This routine is called when the user changes speed/duplex using * media/mediopt option with ifconfig. * **********************************************************************/ static int em_media_change(struct ifnet *ifp) { struct adapter * adapter = ifp->if_softc; struct ifmedia *ifm = &adapter->media; INIT_DEBUGOUT("em_media_change: begin"); if (IFM_TYPE(ifm->ifm_media) != IFM_ETHER) return(EINVAL); switch (IFM_SUBTYPE(ifm->ifm_media)) { case IFM_AUTO: adapter->hw.autoneg = DO_AUTO_NEG; adapter->hw.autoneg_advertised = AUTONEG_ADV_DEFAULT; break; case IFM_1000_SX: #if __FreeBSD_version < 500000 case IFM_1000_TX: #else case IFM_1000_T: #endif adapter->hw.autoneg = DO_AUTO_NEG; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; break; case IFM_100_TX: adapter->hw.autoneg = FALSE; adapter->hw.autoneg_advertised = 0; if ((ifm->ifm_media & IFM_GMASK) == IFM_FDX) adapter->hw.forced_speed_duplex = em_100_full; else adapter->hw.forced_speed_duplex = em_100_half; break; case IFM_10_T: adapter->hw.autoneg = FALSE; adapter->hw.autoneg_advertised = 0; if ((ifm->ifm_media & IFM_GMASK) == IFM_FDX) adapter->hw.forced_speed_duplex = em_10_full; else adapter->hw.forced_speed_duplex = em_10_half; break; default: printf("em%d: Unsupported media type\n", adapter->unit); } /* As the speed/duplex settings my have changed we need to * reset the PHY. */ adapter->hw.phy_reset_disable = FALSE; em_init(adapter); return(0); } static void em_tx_cb(void *arg, bus_dma_segment_t *seg, int nsegs, bus_size_t mapsize, int error) { struct em_q *q = arg; if (error) return; KASSERT(nsegs <= EM_MAX_SCATTER, ("Too many DMA segments returned when mapping tx packet")); q->nsegs = nsegs; bcopy(seg, q->segs, nsegs * sizeof(seg[0])); } /********************************************************************* * * This routine maps the mbufs to tx descriptors. * * return 0 on success, positive on failure **********************************************************************/ static int em_encap(struct adapter *adapter, struct mbuf **m_headp) { u_int32_t txd_upper; u_int32_t txd_lower, txd_used = 0, txd_saved = 0; int i, j, error; u_int64_t address; struct mbuf *m_head; /* For 82544 Workaround */ DESC_ARRAY desc_array; u_int32_t array_elements; u_int32_t counter; #if __FreeBSD_version < 500000 struct ifvlan *ifv = NULL; #else struct m_tag *mtag; #endif struct em_q q; struct em_buffer *tx_buffer = NULL; struct em_tx_desc *current_tx_desc = NULL; struct ifnet *ifp = &adapter->interface_data.ac_if; m_head = *m_headp; /* * Force a cleanup if number of TX descriptors * available hits the threshold */ if (adapter->num_tx_desc_avail <= EM_TX_CLEANUP_THRESHOLD) { em_clean_transmit_interrupts(adapter); if (adapter->num_tx_desc_avail <= EM_TX_CLEANUP_THRESHOLD) { adapter->no_tx_desc_avail1++; return(ENOBUFS); } } /* * Map the packet for DMA. */ if (bus_dmamap_create(adapter->txtag, BUS_DMA_NOWAIT, &q.map)) { adapter->no_tx_map_avail++; return (ENOMEM); } error = bus_dmamap_load_mbuf(adapter->txtag, q.map, m_head, em_tx_cb, &q, BUS_DMA_NOWAIT); if (error != 0) { adapter->no_tx_dma_setup++; bus_dmamap_destroy(adapter->txtag, q.map); return (error); } KASSERT(q.nsegs != 0, ("em_encap: empty packet")); if (q.nsegs > adapter->num_tx_desc_avail) { adapter->no_tx_desc_avail2++; bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } if (ifp->if_hwassist > 0) { em_transmit_checksum_setup(adapter, m_head, &txd_upper, &txd_lower); } else txd_upper = txd_lower = 0; /* Find out if we are in vlan mode */ #if __FreeBSD_version < 500000 if ((m_head->m_flags & (M_PROTO1|M_PKTHDR)) == (M_PROTO1|M_PKTHDR) && m_head->m_pkthdr.rcvif != NULL && m_head->m_pkthdr.rcvif->if_type == IFT_L2VLAN) ifv = m_head->m_pkthdr.rcvif->if_softc; #else mtag = VLAN_OUTPUT_TAG(ifp, m_head); #endif /* * When operating in promiscuous mode, hardware encapsulation for * packets is disabled. This means we have to add the vlan * encapsulation in the driver, since it will have come down from the * VLAN layer with a tag instead of a VLAN header. */ if (mtag != NULL && adapter->em_insert_vlan_header) { struct ether_vlan_header *evl; struct ether_header eh; m_head = m_pullup(m_head, sizeof(eh)); if (m_head == NULL) { *m_headp = NULL; bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } eh = *mtod(m_head, struct ether_header *); M_PREPEND(m_head, sizeof(*evl), M_DONTWAIT); if (m_head == NULL) { *m_headp = NULL; bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } m_head = m_pullup(m_head, sizeof(*evl)); if (m_head == NULL) { *m_headp = NULL; bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } evl = mtod(m_head, struct ether_vlan_header *); bcopy(&eh, evl, sizeof(*evl)); evl->evl_proto = evl->evl_encap_proto; evl->evl_encap_proto = htons(ETHERTYPE_VLAN); evl->evl_tag = htons(VLAN_TAG_VALUE(mtag)); m_tag_delete(m_head, mtag); mtag = NULL; *m_headp = m_head; } i = adapter->next_avail_tx_desc; if (adapter->pcix_82544) { txd_saved = i; txd_used = 0; } for (j = 0; j < q.nsegs; j++) { /* If adapter is 82544 and on PCIX bus */ if(adapter->pcix_82544) { array_elements = 0; address = htole64(q.segs[j].ds_addr); /* * Check the Address and Length combination and * split the data accordingly */ array_elements = em_fill_descriptors(address, htole32(q.segs[j].ds_len), &desc_array); for (counter = 0; counter < array_elements; counter++) { if (txd_used == adapter->num_tx_desc_avail) { adapter->next_avail_tx_desc = txd_saved; adapter->no_tx_desc_avail2++; bus_dmamap_destroy(adapter->txtag, q.map); return (ENOBUFS); } tx_buffer = &adapter->tx_buffer_area[i]; current_tx_desc = &adapter->tx_desc_base[i]; current_tx_desc->buffer_addr = htole64( desc_array.descriptor[counter].address); current_tx_desc->lower.data = htole32( (adapter->txd_cmd | txd_lower | (u_int16_t)desc_array.descriptor[counter].length)); current_tx_desc->upper.data = htole32((txd_upper)); if (++i == adapter->num_tx_desc) i = 0; tx_buffer->m_head = NULL; txd_used++; } } else { tx_buffer = &adapter->tx_buffer_area[i]; current_tx_desc = &adapter->tx_desc_base[i]; current_tx_desc->buffer_addr = htole64(q.segs[j].ds_addr); current_tx_desc->lower.data = htole32( adapter->txd_cmd | txd_lower | q.segs[j].ds_len); current_tx_desc->upper.data = htole32(txd_upper); if (++i == adapter->num_tx_desc) i = 0; tx_buffer->m_head = NULL; } } adapter->next_avail_tx_desc = i; if (adapter->pcix_82544) { adapter->num_tx_desc_avail -= txd_used; } else { adapter->num_tx_desc_avail -= q.nsegs; } #if __FreeBSD_version < 500000 if (ifv != NULL) { /* Set the vlan id */ current_tx_desc->upper.fields.special = htole16(ifv->ifv_tag); #else if (mtag != NULL) { /* Set the vlan id */ current_tx_desc->upper.fields.special = htole16(VLAN_TAG_VALUE(mtag)); #endif /* Tell hardware to add tag */ current_tx_desc->lower.data |= htole32(E1000_TXD_CMD_VLE); } tx_buffer->m_head = m_head; tx_buffer->map = q.map; bus_dmamap_sync(adapter->txtag, q.map, BUS_DMASYNC_PREWRITE); /* * Last Descriptor of Packet needs End Of Packet (EOP) */ current_tx_desc->lower.data |= htole32(E1000_TXD_CMD_EOP); /* * Advance the Transmit Descriptor Tail (Tdt), this tells the E1000 * that this frame is available to transmit. */ if (adapter->hw.mac_type == em_82547 && adapter->link_duplex == HALF_DUPLEX) { em_82547_move_tail_locked(adapter); } else { E1000_WRITE_REG(&adapter->hw, TDT, i); if (adapter->hw.mac_type == em_82547) { em_82547_update_fifo_head(adapter, m_head->m_pkthdr.len); } } return(0); } /********************************************************************* * * 82547 workaround to avoid controller hang in half-duplex environment. * The workaround is to avoid queuing a large packet that would span * the internal Tx FIFO ring boundary. We need to reset the FIFO pointers * in this case. We do that only when FIFO is quiescent. * **********************************************************************/ static void em_82547_move_tail_locked(struct adapter *adapter) { uint16_t hw_tdt; uint16_t sw_tdt; struct em_tx_desc *tx_desc; uint16_t length = 0; boolean_t eop = 0; EM_LOCK_ASSERT(adapter); hw_tdt = E1000_READ_REG(&adapter->hw, TDT); sw_tdt = adapter->next_avail_tx_desc; while (hw_tdt != sw_tdt) { tx_desc = &adapter->tx_desc_base[hw_tdt]; length += tx_desc->lower.flags.length; eop = tx_desc->lower.data & E1000_TXD_CMD_EOP; if(++hw_tdt == adapter->num_tx_desc) hw_tdt = 0; if(eop) { if (em_82547_fifo_workaround(adapter, length)) { adapter->tx_fifo_wrk_cnt++; callout_reset(&adapter->tx_fifo_timer, 1, em_82547_move_tail, adapter); break; } E1000_WRITE_REG(&adapter->hw, TDT, hw_tdt); em_82547_update_fifo_head(adapter, length); length = 0; } } return; } static void em_82547_move_tail(void *arg) { struct adapter *adapter = arg; EM_LOCK(adapter); em_82547_move_tail_locked(adapter); EM_UNLOCK(adapter); } static int em_82547_fifo_workaround(struct adapter *adapter, int len) { int fifo_space, fifo_pkt_len; fifo_pkt_len = EM_ROUNDUP(len + EM_FIFO_HDR, EM_FIFO_HDR); if (adapter->link_duplex == HALF_DUPLEX) { fifo_space = adapter->tx_fifo_size - adapter->tx_fifo_head; if (fifo_pkt_len >= (EM_82547_PKT_THRESH + fifo_space)) { if (em_82547_tx_fifo_reset(adapter)) { return(0); } else { return(1); } } } return(0); } static void em_82547_update_fifo_head(struct adapter *adapter, int len) { int fifo_pkt_len = EM_ROUNDUP(len + EM_FIFO_HDR, EM_FIFO_HDR); /* tx_fifo_head is always 16 byte aligned */ adapter->tx_fifo_head += fifo_pkt_len; if (adapter->tx_fifo_head >= adapter->tx_fifo_size) { adapter->tx_fifo_head -= adapter->tx_fifo_size; } return; } static int em_82547_tx_fifo_reset(struct adapter *adapter) { uint32_t tctl; if ( (E1000_READ_REG(&adapter->hw, TDT) == E1000_READ_REG(&adapter->hw, TDH)) && (E1000_READ_REG(&adapter->hw, TDFT) == E1000_READ_REG(&adapter->hw, TDFH)) && (E1000_READ_REG(&adapter->hw, TDFTS) == E1000_READ_REG(&adapter->hw, TDFHS)) && (E1000_READ_REG(&adapter->hw, TDFPC) == 0)) { /* Disable TX unit */ tctl = E1000_READ_REG(&adapter->hw, TCTL); E1000_WRITE_REG(&adapter->hw, TCTL, tctl & ~E1000_TCTL_EN); /* Reset FIFO pointers */ E1000_WRITE_REG(&adapter->hw, TDFT, adapter->tx_head_addr); E1000_WRITE_REG(&adapter->hw, TDFH, adapter->tx_head_addr); E1000_WRITE_REG(&adapter->hw, TDFTS, adapter->tx_head_addr); E1000_WRITE_REG(&adapter->hw, TDFHS, adapter->tx_head_addr); /* Re-enable TX unit */ E1000_WRITE_REG(&adapter->hw, TCTL, tctl); E1000_WRITE_FLUSH(&adapter->hw); adapter->tx_fifo_head = 0; adapter->tx_fifo_reset_cnt++; return(TRUE); } else { return(FALSE); } } static void em_set_promisc(struct adapter * adapter) { u_int32_t reg_rctl; u_int32_t ctrl; struct ifnet *ifp = &adapter->interface_data.ac_if; reg_rctl = E1000_READ_REG(&adapter->hw, RCTL); ctrl = E1000_READ_REG(&adapter->hw, CTRL); if (ifp->if_flags & IFF_PROMISC) { reg_rctl |= (E1000_RCTL_UPE | E1000_RCTL_MPE); E1000_WRITE_REG(&adapter->hw, RCTL, reg_rctl); /* Disable VLAN stripping in promiscous mode * This enables bridging of vlan tagged frames to occur * and also allows vlan tags to be seen in tcpdump */ ctrl &= ~E1000_CTRL_VME; E1000_WRITE_REG(&adapter->hw, CTRL, ctrl); adapter->em_insert_vlan_header = 1; } else if (ifp->if_flags & IFF_ALLMULTI) { reg_rctl |= E1000_RCTL_MPE; reg_rctl &= ~E1000_RCTL_UPE; E1000_WRITE_REG(&adapter->hw, RCTL, reg_rctl); adapter->em_insert_vlan_header = 0; } else adapter->em_insert_vlan_header = 0; return; } static void em_disable_promisc(struct adapter * adapter) { u_int32_t reg_rctl; reg_rctl = E1000_READ_REG(&adapter->hw, RCTL); reg_rctl &= (~E1000_RCTL_UPE); reg_rctl &= (~E1000_RCTL_MPE); E1000_WRITE_REG(&adapter->hw, RCTL, reg_rctl); em_enable_vlans(adapter); adapter->em_insert_vlan_header = 0; return; } /********************************************************************* * Multicast Update * * This routine is called whenever multicast address list is updated. * **********************************************************************/ static void em_set_multi(struct adapter * adapter) { u_int32_t reg_rctl = 0; u_int8_t mta[MAX_NUM_MULTICAST_ADDRESSES * ETH_LENGTH_OF_ADDRESS]; struct ifmultiaddr *ifma; int mcnt = 0; struct ifnet *ifp = &adapter->interface_data.ac_if; IOCTL_DEBUGOUT("em_set_multi: begin"); if (adapter->hw.mac_type == em_82542_rev2_0) { reg_rctl = E1000_READ_REG(&adapter->hw, RCTL); if (adapter->hw.pci_cmd_word & CMD_MEM_WRT_INVALIDATE) { em_pci_clear_mwi(&adapter->hw); } reg_rctl |= E1000_RCTL_RST; E1000_WRITE_REG(&adapter->hw, RCTL, reg_rctl); msec_delay(5); } #if __FreeBSD_version < 500000 LIST_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { #else TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { #endif if (ifma->ifma_addr->sa_family != AF_LINK) continue; if (mcnt == MAX_NUM_MULTICAST_ADDRESSES) break; bcopy(LLADDR((struct sockaddr_dl *)ifma->ifma_addr), &mta[mcnt*ETH_LENGTH_OF_ADDRESS], ETH_LENGTH_OF_ADDRESS); mcnt++; } if (mcnt >= MAX_NUM_MULTICAST_ADDRESSES) { reg_rctl = E1000_READ_REG(&adapter->hw, RCTL); reg_rctl |= E1000_RCTL_MPE; E1000_WRITE_REG(&adapter->hw, RCTL, reg_rctl); } else em_mc_addr_list_update(&adapter->hw, mta, mcnt, 0, 1); if (adapter->hw.mac_type == em_82542_rev2_0) { reg_rctl = E1000_READ_REG(&adapter->hw, RCTL); reg_rctl &= ~E1000_RCTL_RST; E1000_WRITE_REG(&adapter->hw, RCTL, reg_rctl); msec_delay(5); if (adapter->hw.pci_cmd_word & CMD_MEM_WRT_INVALIDATE) { em_pci_set_mwi(&adapter->hw); } } return; } /********************************************************************* * Timer routine * * This routine checks for link status and updates statistics. * **********************************************************************/ static void em_local_timer(void *arg) { struct ifnet *ifp; struct adapter * adapter = arg; ifp = &adapter->interface_data.ac_if; EM_LOCK(adapter); em_check_for_link(&adapter->hw); em_print_link_status(adapter); em_update_stats_counters(adapter); if (em_display_debug_stats && ifp->if_flags & IFF_RUNNING) { em_print_hw_stats(adapter); } em_smartspeed(adapter); callout_reset(&adapter->timer, 2*hz, em_local_timer, adapter); EM_UNLOCK(adapter); return; } static void em_print_link_status(struct adapter * adapter) { if (E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_LU) { if (adapter->link_active == 0) { em_get_speed_and_duplex(&adapter->hw, &adapter->link_speed, &adapter->link_duplex); printf("em%d: Link is up %d Mbps %s\n", adapter->unit, adapter->link_speed, ((adapter->link_duplex == FULL_DUPLEX) ? "Full Duplex" : "Half Duplex")); adapter->link_active = 1; adapter->smartspeed = 0; } } else { if (adapter->link_active == 1) { adapter->link_speed = 0; adapter->link_duplex = 0; printf("em%d: Link is Down\n", adapter->unit); adapter->link_active = 0; } } return; } /********************************************************************* * * This routine disables all traffic on the adapter by issuing a * global reset on the MAC and deallocates TX/RX buffers. * **********************************************************************/ static void em_stop(void *arg) { struct ifnet *ifp; struct adapter * adapter = arg; ifp = &adapter->interface_data.ac_if; mtx_assert(&adapter->mtx, MA_OWNED); INIT_DEBUGOUT("em_stop: begin"); em_disable_intr(adapter); em_reset_hw(&adapter->hw); callout_stop(&adapter->timer); callout_stop(&adapter->tx_fifo_timer); em_free_transmit_structures(adapter); em_free_receive_structures(adapter); /* Tell the stack that the interface is no longer active */ ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE); return; } /********************************************************************* * * Determine hardware revision. * **********************************************************************/ static void em_identify_hardware(struct adapter * adapter) { device_t dev = adapter->dev; /* Make sure our PCI config space has the necessary stuff set */ adapter->hw.pci_cmd_word = pci_read_config(dev, PCIR_COMMAND, 2); if (!((adapter->hw.pci_cmd_word & PCIM_CMD_BUSMASTEREN) && (adapter->hw.pci_cmd_word & PCIM_CMD_MEMEN))) { printf("em%d: Memory Access and/or Bus Master bits were not set!\n", adapter->unit); adapter->hw.pci_cmd_word |= (PCIM_CMD_BUSMASTEREN | PCIM_CMD_MEMEN); pci_write_config(dev, PCIR_COMMAND, adapter->hw.pci_cmd_word, 2); } /* Save off the information about this board */ adapter->hw.vendor_id = pci_get_vendor(dev); adapter->hw.device_id = pci_get_device(dev); adapter->hw.revision_id = pci_read_config(dev, PCIR_REVID, 1); adapter->hw.subsystem_vendor_id = pci_read_config(dev, PCIR_SUBVEND_0, 2); adapter->hw.subsystem_id = pci_read_config(dev, PCIR_SUBDEV_0, 2); /* Identify the MAC */ if (em_set_mac_type(&adapter->hw)) printf("em%d: Unknown MAC Type\n", adapter->unit); if(adapter->hw.mac_type == em_82541 || adapter->hw.mac_type == em_82541_rev_2 || adapter->hw.mac_type == em_82547 || adapter->hw.mac_type == em_82547_rev_2) adapter->hw.phy_init_script = TRUE; return; } static int em_allocate_pci_resources(struct adapter * adapter) { int i, val, rid; device_t dev = adapter->dev; rid = EM_MMBA; adapter->res_memory = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); if (!(adapter->res_memory)) { printf("em%d: Unable to allocate bus resource: memory\n", adapter->unit); return(ENXIO); } adapter->osdep.mem_bus_space_tag = rman_get_bustag(adapter->res_memory); adapter->osdep.mem_bus_space_handle = rman_get_bushandle(adapter->res_memory); adapter->hw.hw_addr = (uint8_t *)&adapter->osdep.mem_bus_space_handle; if (adapter->hw.mac_type > em_82543) { /* Figure our where our IO BAR is ? */ rid = EM_MMBA; for (i = 0; i < 5; i++) { val = pci_read_config(dev, rid, 4); if (val & 0x00000001) { adapter->io_rid = rid; break; } rid += 4; } adapter->res_ioport = bus_alloc_resource_any(dev, SYS_RES_IOPORT, &adapter->io_rid, RF_ACTIVE); if (!(adapter->res_ioport)) { printf("em%d: Unable to allocate bus resource: ioport\n", adapter->unit); return(ENXIO); } adapter->hw.io_base = rman_get_start(adapter->res_ioport); } rid = 0x0; adapter->res_interrupt = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, RF_SHAREABLE | RF_ACTIVE); if (!(adapter->res_interrupt)) { printf("em%d: Unable to allocate bus resource: interrupt\n", adapter->unit); return(ENXIO); } if (bus_setup_intr(dev, adapter->res_interrupt, INTR_TYPE_NET | INTR_MPSAFE, (void (*)(void *)) em_intr, adapter, &adapter->int_handler_tag)) { printf("em%d: Error registering interrupt handler!\n", adapter->unit); return(ENXIO); } adapter->hw.back = &adapter->osdep; return(0); } static void em_free_pci_resources(struct adapter * adapter) { device_t dev = adapter->dev; if (adapter->res_interrupt != NULL) { bus_teardown_intr(dev, adapter->res_interrupt, adapter->int_handler_tag); bus_release_resource(dev, SYS_RES_IRQ, 0, adapter->res_interrupt); } if (adapter->res_memory != NULL) { bus_release_resource(dev, SYS_RES_MEMORY, EM_MMBA, adapter->res_memory); } if (adapter->res_ioport != NULL) { bus_release_resource(dev, SYS_RES_IOPORT, adapter->io_rid, adapter->res_ioport); } return; } /********************************************************************* * * Initialize the hardware to a configuration as specified by the * adapter structure. The controller is reset, the EEPROM is * verified, the MAC address is set, then the shared initialization * routines are called. * **********************************************************************/ static int em_hardware_init(struct adapter * adapter) { INIT_DEBUGOUT("em_hardware_init: begin"); /* Issue a global reset */ em_reset_hw(&adapter->hw); /* When hardware is reset, fifo_head is also reset */ adapter->tx_fifo_head = 0; /* Make sure we have a good EEPROM before we read from it */ if (em_validate_eeprom_checksum(&adapter->hw) < 0) { printf("em%d: The EEPROM Checksum Is Not Valid\n", adapter->unit); return(EIO); } if (em_read_part_num(&adapter->hw, &(adapter->part_num)) < 0) { printf("em%d: EEPROM read error while reading part number\n", adapter->unit); return(EIO); } if (em_init_hw(&adapter->hw) < 0) { printf("em%d: Hardware Initialization Failed", adapter->unit); return(EIO); } em_check_for_link(&adapter->hw); if (E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_LU) adapter->link_active = 1; else adapter->link_active = 0; if (adapter->link_active) { em_get_speed_and_duplex(&adapter->hw, &adapter->link_speed, &adapter->link_duplex); } else { adapter->link_speed = 0; adapter->link_duplex = 0; } return(0); } /********************************************************************* * * Setup networking device structure and register an interface. * **********************************************************************/ static void em_setup_interface(device_t dev, struct adapter * adapter) { struct ifnet *ifp; INIT_DEBUGOUT("em_setup_interface: begin"); ifp = &adapter->interface_data.ac_if; if_initname(ifp, device_get_name(dev), device_get_unit(dev)); ifp->if_mtu = ETHERMTU; ifp->if_baudrate = 1000000000; ifp->if_init = em_init; ifp->if_softc = adapter; ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_ioctl = em_ioctl; ifp->if_start = em_start; ifp->if_watchdog = em_watchdog; IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 1); ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; IFQ_SET_READY(&ifp->if_snd); #if __FreeBSD_version < 500000 ether_ifattach(ifp, ETHER_BPF_SUPPORTED); #else ether_ifattach(ifp, adapter->interface_data.ac_enaddr); #endif ifp->if_capabilities = ifp->if_capenable = 0; if (adapter->hw.mac_type >= em_82543) { ifp->if_capabilities |= IFCAP_HWCSUM; ifp->if_capenable |= IFCAP_HWCSUM; } /* * Tell the upper layer(s) we support long frames. */ ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); #if __FreeBSD_version >= 500000 ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU; ifp->if_capenable |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU; #endif #ifdef DEVICE_POLLING ifp->if_capabilities |= IFCAP_POLLING; ifp->if_capenable |= IFCAP_POLLING; #endif /* * Specify the media types supported by this adapter and register * callbacks to update media and link information */ ifmedia_init(&adapter->media, IFM_IMASK, em_media_change, em_media_status); if (adapter->hw.media_type == em_media_type_fiber) { ifmedia_add(&adapter->media, IFM_ETHER | IFM_1000_SX | IFM_FDX, 0, NULL); ifmedia_add(&adapter->media, IFM_ETHER | IFM_1000_SX, 0, NULL); } else { ifmedia_add(&adapter->media, IFM_ETHER | IFM_10_T, 0, NULL); ifmedia_add(&adapter->media, IFM_ETHER | IFM_10_T | IFM_FDX, 0, NULL); ifmedia_add(&adapter->media, IFM_ETHER | IFM_100_TX, 0, NULL); ifmedia_add(&adapter->media, IFM_ETHER | IFM_100_TX | IFM_FDX, 0, NULL); #if __FreeBSD_version < 500000 ifmedia_add(&adapter->media, IFM_ETHER | IFM_1000_TX | IFM_FDX, 0, NULL); ifmedia_add(&adapter->media, IFM_ETHER | IFM_1000_TX, 0, NULL); #else ifmedia_add(&adapter->media, IFM_ETHER | IFM_1000_T | IFM_FDX, 0, NULL); ifmedia_add(&adapter->media, IFM_ETHER | IFM_1000_T, 0, NULL); #endif } ifmedia_add(&adapter->media, IFM_ETHER | IFM_AUTO, 0, NULL); ifmedia_set(&adapter->media, IFM_ETHER | IFM_AUTO); return; } /********************************************************************* * * Workaround for SmartSpeed on 82541 and 82547 controllers * **********************************************************************/ static void em_smartspeed(struct adapter *adapter) { uint16_t phy_tmp; if(adapter->link_active || (adapter->hw.phy_type != em_phy_igp) || !adapter->hw.autoneg || !(adapter->hw.autoneg_advertised & ADVERTISE_1000_FULL)) return; if(adapter->smartspeed == 0) { /* If Master/Slave config fault is asserted twice, * we assume back-to-back */ em_read_phy_reg(&adapter->hw, PHY_1000T_STATUS, &phy_tmp); if(!(phy_tmp & SR_1000T_MS_CONFIG_FAULT)) return; em_read_phy_reg(&adapter->hw, PHY_1000T_STATUS, &phy_tmp); if(phy_tmp & SR_1000T_MS_CONFIG_FAULT) { em_read_phy_reg(&adapter->hw, PHY_1000T_CTRL, &phy_tmp); if(phy_tmp & CR_1000T_MS_ENABLE) { phy_tmp &= ~CR_1000T_MS_ENABLE; em_write_phy_reg(&adapter->hw, PHY_1000T_CTRL, phy_tmp); adapter->smartspeed++; if(adapter->hw.autoneg && !em_phy_setup_autoneg(&adapter->hw) && !em_read_phy_reg(&adapter->hw, PHY_CTRL, &phy_tmp)) { phy_tmp |= (MII_CR_AUTO_NEG_EN | MII_CR_RESTART_AUTO_NEG); em_write_phy_reg(&adapter->hw, PHY_CTRL, phy_tmp); } } } return; } else if(adapter->smartspeed == EM_SMARTSPEED_DOWNSHIFT) { /* If still no link, perhaps using 2/3 pair cable */ em_read_phy_reg(&adapter->hw, PHY_1000T_CTRL, &phy_tmp); phy_tmp |= CR_1000T_MS_ENABLE; em_write_phy_reg(&adapter->hw, PHY_1000T_CTRL, phy_tmp); if(adapter->hw.autoneg && !em_phy_setup_autoneg(&adapter->hw) && !em_read_phy_reg(&adapter->hw, PHY_CTRL, &phy_tmp)) { phy_tmp |= (MII_CR_AUTO_NEG_EN | MII_CR_RESTART_AUTO_NEG); em_write_phy_reg(&adapter->hw, PHY_CTRL, phy_tmp); } } /* Restart process after EM_SMARTSPEED_MAX iterations */ if(adapter->smartspeed++ == EM_SMARTSPEED_MAX) adapter->smartspeed = 0; return; } /* * Manage DMA'able memory. */ static void em_dmamap_cb(void *arg, bus_dma_segment_t *segs, int nseg, int error) { if (error) return; *(bus_addr_t*) arg = segs->ds_addr; return; } static int em_dma_malloc(struct adapter *adapter, bus_size_t size, struct em_dma_alloc *dma, int mapflags) { int r; r = bus_dma_tag_create(NULL, /* parent */ PAGE_SIZE, 0, /* alignment, bounds */ BUS_SPACE_MAXADDR, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ size, /* maxsize */ 1, /* nsegments */ size, /* maxsegsize */ BUS_DMA_ALLOCNOW, /* flags */ NULL, /* lockfunc */ NULL, /* lockarg */ &dma->dma_tag); if (r != 0) { printf("em%d: em_dma_malloc: bus_dma_tag_create failed; " "error %u\n", adapter->unit, r); goto fail_0; } r = bus_dmamem_alloc(dma->dma_tag, (void**) &dma->dma_vaddr, BUS_DMA_NOWAIT, &dma->dma_map); if (r != 0) { printf("em%d: em_dma_malloc: bus_dmammem_alloc failed; " "size %ju, error %d\n", adapter->unit, (uintmax_t)size, r); goto fail_2; } r = bus_dmamap_load(dma->dma_tag, dma->dma_map, dma->dma_vaddr, size, em_dmamap_cb, &dma->dma_paddr, mapflags | BUS_DMA_NOWAIT); if (r != 0) { printf("em%d: em_dma_malloc: bus_dmamap_load failed; " "error %u\n", adapter->unit, r); goto fail_3; } dma->dma_size = size; return (0); fail_3: bus_dmamap_unload(dma->dma_tag, dma->dma_map); fail_2: bus_dmamem_free(dma->dma_tag, dma->dma_vaddr, dma->dma_map); bus_dma_tag_destroy(dma->dma_tag); fail_0: dma->dma_map = NULL; dma->dma_tag = NULL; return (r); } static void em_dma_free(struct adapter *adapter, struct em_dma_alloc *dma) { bus_dmamap_unload(dma->dma_tag, dma->dma_map); bus_dmamem_free(dma->dma_tag, dma->dma_vaddr, dma->dma_map); bus_dma_tag_destroy(dma->dma_tag); } /********************************************************************* * * Allocate memory for tx_buffer structures. The tx_buffer stores all * the information needed to transmit a packet on the wire. * **********************************************************************/ static int em_allocate_transmit_structures(struct adapter * adapter) { if (!(adapter->tx_buffer_area = (struct em_buffer *) malloc(sizeof(struct em_buffer) * adapter->num_tx_desc, M_DEVBUF, M_NOWAIT))) { printf("em%d: Unable to allocate tx_buffer memory\n", adapter->unit); return ENOMEM; } bzero(adapter->tx_buffer_area, sizeof(struct em_buffer) * adapter->num_tx_desc); return 0; } /********************************************************************* * * Allocate and initialize transmit structures. * **********************************************************************/ static int em_setup_transmit_structures(struct adapter * adapter) { /* * Setup DMA descriptor areas. */ if (bus_dma_tag_create(NULL, /* parent */ 1, 0, /* alignment, bounds */ BUS_SPACE_MAXADDR, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ MCLBYTES * 8, /* maxsize */ EM_MAX_SCATTER, /* nsegments */ MCLBYTES * 8, /* maxsegsize */ BUS_DMA_ALLOCNOW, /* flags */ NULL, /* lockfunc */ NULL, /* lockarg */ &adapter->txtag)) { printf("em%d: Unable to allocate TX DMA tag\n", adapter->unit); return (ENOMEM); } if (em_allocate_transmit_structures(adapter)) return (ENOMEM); bzero((void *) adapter->tx_desc_base, (sizeof(struct em_tx_desc)) * adapter->num_tx_desc); adapter->next_avail_tx_desc = 0; adapter->oldest_used_tx_desc = 0; /* Set number of descriptors available */ adapter->num_tx_desc_avail = adapter->num_tx_desc; /* Set checksum context */ adapter->active_checksum_context = OFFLOAD_NONE; return (0); } /********************************************************************* * * Enable transmit unit. * **********************************************************************/ static void em_initialize_transmit_unit(struct adapter * adapter) { u_int32_t reg_tctl; u_int32_t reg_tipg = 0; u_int64_t bus_addr; INIT_DEBUGOUT("em_initialize_transmit_unit: begin"); /* Setup the Base and Length of the Tx Descriptor Ring */ bus_addr = adapter->txdma.dma_paddr; E1000_WRITE_REG(&adapter->hw, TDBAL, (u_int32_t)bus_addr); E1000_WRITE_REG(&adapter->hw, TDBAH, (u_int32_t)(bus_addr >> 32)); E1000_WRITE_REG(&adapter->hw, TDLEN, adapter->num_tx_desc * sizeof(struct em_tx_desc)); /* Setup the HW Tx Head and Tail descriptor pointers */ E1000_WRITE_REG(&adapter->hw, TDH, 0); E1000_WRITE_REG(&adapter->hw, TDT, 0); HW_DEBUGOUT2("Base = %x, Length = %x\n", E1000_READ_REG(&adapter->hw, TDBAL), E1000_READ_REG(&adapter->hw, TDLEN)); /* Set the default values for the Tx Inter Packet Gap timer */ switch (adapter->hw.mac_type) { case em_82542_rev2_0: case em_82542_rev2_1: reg_tipg = DEFAULT_82542_TIPG_IPGT; reg_tipg |= DEFAULT_82542_TIPG_IPGR1 << E1000_TIPG_IPGR1_SHIFT; reg_tipg |= DEFAULT_82542_TIPG_IPGR2 << E1000_TIPG_IPGR2_SHIFT; break; default: if (adapter->hw.media_type == em_media_type_fiber) reg_tipg = DEFAULT_82543_TIPG_IPGT_FIBER; else reg_tipg = DEFAULT_82543_TIPG_IPGT_COPPER; reg_tipg |= DEFAULT_82543_TIPG_IPGR1 << E1000_TIPG_IPGR1_SHIFT; reg_tipg |= DEFAULT_82543_TIPG_IPGR2 << E1000_TIPG_IPGR2_SHIFT; } E1000_WRITE_REG(&adapter->hw, TIPG, reg_tipg); E1000_WRITE_REG(&adapter->hw, TIDV, adapter->tx_int_delay.value); if(adapter->hw.mac_type >= em_82540) E1000_WRITE_REG(&adapter->hw, TADV, adapter->tx_abs_int_delay.value); /* Program the Transmit Control Register */ reg_tctl = E1000_TCTL_PSP | E1000_TCTL_EN | (E1000_COLLISION_THRESHOLD << E1000_CT_SHIFT); if (adapter->link_duplex == 1) { reg_tctl |= E1000_FDX_COLLISION_DISTANCE << E1000_COLD_SHIFT; } else { reg_tctl |= E1000_HDX_COLLISION_DISTANCE << E1000_COLD_SHIFT; } E1000_WRITE_REG(&adapter->hw, TCTL, reg_tctl); /* Setup Transmit Descriptor Settings for this adapter */ adapter->txd_cmd = E1000_TXD_CMD_IFCS | E1000_TXD_CMD_RS; if (adapter->tx_int_delay.value > 0) adapter->txd_cmd |= E1000_TXD_CMD_IDE; return; } /********************************************************************* * * Free all transmit related data structures. * **********************************************************************/ static void em_free_transmit_structures(struct adapter * adapter) { struct em_buffer *tx_buffer; int i; INIT_DEBUGOUT("free_transmit_structures: begin"); if (adapter->tx_buffer_area != NULL) { tx_buffer = adapter->tx_buffer_area; for (i = 0; i < adapter->num_tx_desc; i++, tx_buffer++) { if (tx_buffer->m_head != NULL) { bus_dmamap_unload(adapter->txtag, tx_buffer->map); bus_dmamap_destroy(adapter->txtag, tx_buffer->map); m_freem(tx_buffer->m_head); } tx_buffer->m_head = NULL; } } if (adapter->tx_buffer_area != NULL) { free(adapter->tx_buffer_area, M_DEVBUF); adapter->tx_buffer_area = NULL; } if (adapter->txtag != NULL) { bus_dma_tag_destroy(adapter->txtag); adapter->txtag = NULL; } return; } /********************************************************************* * * The offload context needs to be set when we transfer the first * packet of a particular protocol (TCP/UDP). We change the * context only if the protocol type changes. * **********************************************************************/ static void em_transmit_checksum_setup(struct adapter * adapter, struct mbuf *mp, u_int32_t *txd_upper, u_int32_t *txd_lower) { struct em_context_desc *TXD; struct em_buffer *tx_buffer; int curr_txd; if (mp->m_pkthdr.csum_flags) { if (mp->m_pkthdr.csum_flags & CSUM_TCP) { *txd_upper = E1000_TXD_POPTS_TXSM << 8; *txd_lower = E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D; if (adapter->active_checksum_context == OFFLOAD_TCP_IP) return; else adapter->active_checksum_context = OFFLOAD_TCP_IP; } else if (mp->m_pkthdr.csum_flags & CSUM_UDP) { *txd_upper = E1000_TXD_POPTS_TXSM << 8; *txd_lower = E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D; if (adapter->active_checksum_context == OFFLOAD_UDP_IP) return; else adapter->active_checksum_context = OFFLOAD_UDP_IP; } else { *txd_upper = 0; *txd_lower = 0; return; } } else { *txd_upper = 0; *txd_lower = 0; return; } /* If we reach this point, the checksum offload context * needs to be reset. */ curr_txd = adapter->next_avail_tx_desc; tx_buffer = &adapter->tx_buffer_area[curr_txd]; TXD = (struct em_context_desc *) &adapter->tx_desc_base[curr_txd]; TXD->lower_setup.ip_fields.ipcss = ETHER_HDR_LEN; TXD->lower_setup.ip_fields.ipcso = ETHER_HDR_LEN + offsetof(struct ip, ip_sum); TXD->lower_setup.ip_fields.ipcse = htole16(ETHER_HDR_LEN + sizeof(struct ip) - 1); TXD->upper_setup.tcp_fields.tucss = ETHER_HDR_LEN + sizeof(struct ip); TXD->upper_setup.tcp_fields.tucse = htole16(0); if (adapter->active_checksum_context == OFFLOAD_TCP_IP) { TXD->upper_setup.tcp_fields.tucso = ETHER_HDR_LEN + sizeof(struct ip) + offsetof(struct tcphdr, th_sum); } else if (adapter->active_checksum_context == OFFLOAD_UDP_IP) { TXD->upper_setup.tcp_fields.tucso = ETHER_HDR_LEN + sizeof(struct ip) + offsetof(struct udphdr, uh_sum); } TXD->tcp_seg_setup.data = htole32(0); TXD->cmd_and_length = htole32(adapter->txd_cmd | E1000_TXD_CMD_DEXT); tx_buffer->m_head = NULL; if (++curr_txd == adapter->num_tx_desc) curr_txd = 0; adapter->num_tx_desc_avail--; adapter->next_avail_tx_desc = curr_txd; return; } /********************************************************************** * * Examine each tx_buffer in the used queue. If the hardware is done * processing the packet then free associated resources. The * tx_buffer is put back on the free queue. * **********************************************************************/ static void em_clean_transmit_interrupts(struct adapter * adapter) { int i, num_avail; struct em_buffer *tx_buffer; struct em_tx_desc *tx_desc; struct ifnet *ifp = &adapter->interface_data.ac_if; mtx_assert(&adapter->mtx, MA_OWNED); if (adapter->num_tx_desc_avail == adapter->num_tx_desc) return; #ifdef DBG_STATS adapter->clean_tx_interrupts++; #endif num_avail = adapter->num_tx_desc_avail; i = adapter->oldest_used_tx_desc; tx_buffer = &adapter->tx_buffer_area[i]; tx_desc = &adapter->tx_desc_base[i]; while (tx_desc->upper.fields.status & E1000_TXD_STAT_DD) { tx_desc->upper.data = 0; num_avail++; if (tx_buffer->m_head) { ifp->if_opackets++; bus_dmamap_sync(adapter->txtag, tx_buffer->map, BUS_DMASYNC_POSTWRITE); bus_dmamap_unload(adapter->txtag, tx_buffer->map); bus_dmamap_destroy(adapter->txtag, tx_buffer->map); m_freem(tx_buffer->m_head); tx_buffer->m_head = NULL; } if (++i == adapter->num_tx_desc) i = 0; tx_buffer = &adapter->tx_buffer_area[i]; tx_desc = &adapter->tx_desc_base[i]; } adapter->oldest_used_tx_desc = i; /* * If we have enough room, clear IFF_OACTIVE to tell the stack * that it is OK to send packets. * If there are no pending descriptors, clear the timeout. Otherwise, * if some descriptors have been freed, restart the timeout. */ if (num_avail > EM_TX_CLEANUP_THRESHOLD) { ifp->if_flags &= ~IFF_OACTIVE; if (num_avail == adapter->num_tx_desc) ifp->if_timer = 0; else if (num_avail == adapter->num_tx_desc_avail) ifp->if_timer = EM_TX_TIMEOUT; } adapter->num_tx_desc_avail = num_avail; return; } /********************************************************************* * * Get a buffer from system mbuf buffer pool. * **********************************************************************/ static int em_get_buf(int i, struct adapter *adapter, struct mbuf *nmp) { register struct mbuf *mp = nmp; struct em_buffer *rx_buffer; struct ifnet *ifp; bus_addr_t paddr; int error; ifp = &adapter->interface_data.ac_if; if (mp == NULL) { mp = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); if (mp == NULL) { adapter->mbuf_cluster_failed++; return(ENOBUFS); } mp->m_len = mp->m_pkthdr.len = MCLBYTES; } else { mp->m_len = mp->m_pkthdr.len = MCLBYTES; mp->m_data = mp->m_ext.ext_buf; mp->m_next = NULL; } if (ifp->if_mtu <= ETHERMTU) { m_adj(mp, ETHER_ALIGN); } rx_buffer = &adapter->rx_buffer_area[i]; /* * Using memory from the mbuf cluster pool, invoke the * bus_dma machinery to arrange the memory mapping. */ error = bus_dmamap_load(adapter->rxtag, rx_buffer->map, mtod(mp, void *), mp->m_len, em_dmamap_cb, &paddr, 0); if (error) { m_free(mp); return(error); } rx_buffer->m_head = mp; adapter->rx_desc_base[i].buffer_addr = htole64(paddr); bus_dmamap_sync(adapter->rxtag, rx_buffer->map, BUS_DMASYNC_PREREAD); return(0); } /********************************************************************* * * Allocate memory for rx_buffer structures. Since we use one * rx_buffer per received packet, the maximum number of rx_buffer's * that we'll need is equal to the number of receive descriptors * that we've allocated. * **********************************************************************/ static int em_allocate_receive_structures(struct adapter * adapter) { int i, error; struct em_buffer *rx_buffer; if (!(adapter->rx_buffer_area = (struct em_buffer *) malloc(sizeof(struct em_buffer) * adapter->num_rx_desc, M_DEVBUF, M_NOWAIT))) { printf("em%d: Unable to allocate rx_buffer memory\n", adapter->unit); return(ENOMEM); } bzero(adapter->rx_buffer_area, sizeof(struct em_buffer) * adapter->num_rx_desc); error = bus_dma_tag_create(NULL, /* parent */ 1, 0, /* alignment, bounds */ BUS_SPACE_MAXADDR, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ MCLBYTES, /* maxsize */ 1, /* nsegments */ MCLBYTES, /* maxsegsize */ BUS_DMA_ALLOCNOW, /* flags */ NULL, /* lockfunc */ NULL, /* lockarg */ &adapter->rxtag); if (error != 0) { printf("em%d: em_allocate_receive_structures: " "bus_dma_tag_create failed; error %u\n", adapter->unit, error); goto fail_0; } rx_buffer = adapter->rx_buffer_area; for (i = 0; i < adapter->num_rx_desc; i++, rx_buffer++) { error = bus_dmamap_create(adapter->rxtag, BUS_DMA_NOWAIT, &rx_buffer->map); if (error != 0) { printf("em%d: em_allocate_receive_structures: " "bus_dmamap_create failed; error %u\n", adapter->unit, error); goto fail_1; } } for (i = 0; i < adapter->num_rx_desc; i++) { error = em_get_buf(i, adapter, NULL); if (error != 0) { adapter->rx_buffer_area[i].m_head = NULL; adapter->rx_desc_base[i].buffer_addr = 0; return(error); } } return(0); fail_1: bus_dma_tag_destroy(adapter->rxtag); fail_0: adapter->rxtag = NULL; free(adapter->rx_buffer_area, M_DEVBUF); adapter->rx_buffer_area = NULL; return (error); } /********************************************************************* * * Allocate and initialize receive structures. * **********************************************************************/ static int em_setup_receive_structures(struct adapter * adapter) { bzero((void *) adapter->rx_desc_base, (sizeof(struct em_rx_desc)) * adapter->num_rx_desc); if (em_allocate_receive_structures(adapter)) return ENOMEM; /* Setup our descriptor pointers */ adapter->next_rx_desc_to_check = 0; return(0); } /********************************************************************* * * Enable receive unit. * **********************************************************************/ static void em_initialize_receive_unit(struct adapter * adapter) { u_int32_t reg_rctl; u_int32_t reg_rxcsum; struct ifnet *ifp; u_int64_t bus_addr; INIT_DEBUGOUT("em_initialize_receive_unit: begin"); ifp = &adapter->interface_data.ac_if; /* Make sure receives are disabled while setting up the descriptor ring */ E1000_WRITE_REG(&adapter->hw, RCTL, 0); /* Set the Receive Delay Timer Register */ E1000_WRITE_REG(&adapter->hw, RDTR, adapter->rx_int_delay.value | E1000_RDT_FPDB); if(adapter->hw.mac_type >= em_82540) { E1000_WRITE_REG(&adapter->hw, RADV, adapter->rx_abs_int_delay.value); /* Set the interrupt throttling rate. Value is calculated * as DEFAULT_ITR = 1/(MAX_INTS_PER_SEC * 256ns) */ #define MAX_INTS_PER_SEC 8000 #define DEFAULT_ITR 1000000000/(MAX_INTS_PER_SEC * 256) E1000_WRITE_REG(&adapter->hw, ITR, DEFAULT_ITR); } /* Setup the Base and Length of the Rx Descriptor Ring */ bus_addr = adapter->rxdma.dma_paddr; E1000_WRITE_REG(&adapter->hw, RDBAL, (u_int32_t)bus_addr); E1000_WRITE_REG(&adapter->hw, RDBAH, (u_int32_t)(bus_addr >> 32)); E1000_WRITE_REG(&adapter->hw, RDLEN, adapter->num_rx_desc * sizeof(struct em_rx_desc)); /* Setup the HW Rx Head and Tail Descriptor Pointers */ E1000_WRITE_REG(&adapter->hw, RDH, 0); E1000_WRITE_REG(&adapter->hw, RDT, adapter->num_rx_desc - 1); /* Setup the Receive Control Register */ reg_rctl = E1000_RCTL_EN | E1000_RCTL_BAM | E1000_RCTL_LBM_NO | E1000_RCTL_RDMTS_HALF | (adapter->hw.mc_filter_type << E1000_RCTL_MO_SHIFT); if (adapter->hw.tbi_compatibility_on == TRUE) reg_rctl |= E1000_RCTL_SBP; switch (adapter->rx_buffer_len) { default: case EM_RXBUFFER_2048: reg_rctl |= E1000_RCTL_SZ_2048; break; case EM_RXBUFFER_4096: reg_rctl |= E1000_RCTL_SZ_4096 | E1000_RCTL_BSEX | E1000_RCTL_LPE; break; case EM_RXBUFFER_8192: reg_rctl |= E1000_RCTL_SZ_8192 | E1000_RCTL_BSEX | E1000_RCTL_LPE; break; case EM_RXBUFFER_16384: reg_rctl |= E1000_RCTL_SZ_16384 | E1000_RCTL_BSEX | E1000_RCTL_LPE; break; } if (ifp->if_mtu > ETHERMTU) reg_rctl |= E1000_RCTL_LPE; /* Enable 82543 Receive Checksum Offload for TCP and UDP */ if ((adapter->hw.mac_type >= em_82543) && (ifp->if_capenable & IFCAP_RXCSUM)) { reg_rxcsum = E1000_READ_REG(&adapter->hw, RXCSUM); reg_rxcsum |= (E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL); E1000_WRITE_REG(&adapter->hw, RXCSUM, reg_rxcsum); } /* Enable Receives */ E1000_WRITE_REG(&adapter->hw, RCTL, reg_rctl); return; } /********************************************************************* * * Free receive related data structures. * **********************************************************************/ static void em_free_receive_structures(struct adapter *adapter) { struct em_buffer *rx_buffer; int i; INIT_DEBUGOUT("free_receive_structures: begin"); if (adapter->rx_buffer_area != NULL) { rx_buffer = adapter->rx_buffer_area; for (i = 0; i < adapter->num_rx_desc; i++, rx_buffer++) { if (rx_buffer->map != NULL) { bus_dmamap_unload(adapter->rxtag, rx_buffer->map); bus_dmamap_destroy(adapter->rxtag, rx_buffer->map); } if (rx_buffer->m_head != NULL) m_freem(rx_buffer->m_head); rx_buffer->m_head = NULL; } } if (adapter->rx_buffer_area != NULL) { free(adapter->rx_buffer_area, M_DEVBUF); adapter->rx_buffer_area = NULL; } if (adapter->rxtag != NULL) { bus_dma_tag_destroy(adapter->rxtag); adapter->rxtag = NULL; } return; } /********************************************************************* * * This routine executes in interrupt context. It replenishes * the mbufs in the descriptor and sends data which has been * dma'ed into host memory to upper layer. * * We loop at most count times if count is > 0, or until done if * count < 0. * *********************************************************************/ static void em_process_receive_interrupts(struct adapter * adapter, int count) { struct ifnet *ifp; struct mbuf *mp; #if __FreeBSD_version < 500000 struct ether_header *eh; #endif u_int8_t accept_frame = 0; u_int8_t eop = 0; u_int16_t len, desc_len, prev_len_adj; int i; /* Pointer to the receive descriptor being examined. */ struct em_rx_desc *current_desc; mtx_assert(&adapter->mtx, MA_OWNED); ifp = &adapter->interface_data.ac_if; i = adapter->next_rx_desc_to_check; current_desc = &adapter->rx_desc_base[i]; if (!((current_desc->status) & E1000_RXD_STAT_DD)) { #ifdef DBG_STATS adapter->no_pkts_avail++; #endif return; } while ((current_desc->status & E1000_RXD_STAT_DD) && (count != 0)) { mp = adapter->rx_buffer_area[i].m_head; bus_dmamap_sync(adapter->rxtag, adapter->rx_buffer_area[i].map, BUS_DMASYNC_POSTREAD); accept_frame = 1; prev_len_adj = 0; desc_len = le16toh(current_desc->length); if (current_desc->status & E1000_RXD_STAT_EOP) { count--; eop = 1; if (desc_len < ETHER_CRC_LEN) { len = 0; prev_len_adj = ETHER_CRC_LEN - desc_len; } else { len = desc_len - ETHER_CRC_LEN; } } else { eop = 0; len = desc_len; } if (current_desc->errors & E1000_RXD_ERR_FRAME_ERR_MASK) { u_int8_t last_byte; u_int32_t pkt_len = desc_len; if (adapter->fmp != NULL) pkt_len += adapter->fmp->m_pkthdr.len; last_byte = *(mtod(mp, caddr_t) + desc_len - 1); if (TBI_ACCEPT(&adapter->hw, current_desc->status, current_desc->errors, pkt_len, last_byte)) { em_tbi_adjust_stats(&adapter->hw, &adapter->stats, pkt_len, adapter->hw.mac_addr); if (len > 0) len--; } else { accept_frame = 0; } } if (accept_frame) { if (em_get_buf(i, adapter, NULL) == ENOBUFS) { adapter->dropped_pkts++; em_get_buf(i, adapter, mp); if (adapter->fmp != NULL) m_freem(adapter->fmp); adapter->fmp = NULL; adapter->lmp = NULL; break; } /* Assign correct length to the current fragment */ mp->m_len = len; if (adapter->fmp == NULL) { mp->m_pkthdr.len = len; adapter->fmp = mp; /* Store the first mbuf */ adapter->lmp = mp; } else { /* Chain mbuf's together */ mp->m_flags &= ~M_PKTHDR; /* * Adjust length of previous mbuf in chain if we * received less than 4 bytes in the last descriptor. */ if (prev_len_adj > 0) { adapter->lmp->m_len -= prev_len_adj; adapter->fmp->m_pkthdr.len -= prev_len_adj; } adapter->lmp->m_next = mp; adapter->lmp = adapter->lmp->m_next; adapter->fmp->m_pkthdr.len += len; } if (eop) { adapter->fmp->m_pkthdr.rcvif = ifp; ifp->if_ipackets++; #if __FreeBSD_version < 500000 eh = mtod(adapter->fmp, struct ether_header *); /* Remove ethernet header from mbuf */ m_adj(adapter->fmp, sizeof(struct ether_header)); em_receive_checksum(adapter, current_desc, adapter->fmp); if (current_desc->status & E1000_RXD_STAT_VP) VLAN_INPUT_TAG(eh, adapter->fmp, (current_desc->special & E1000_RXD_SPC_VLAN_MASK)); else ether_input(ifp, eh, adapter->fmp); #else em_receive_checksum(adapter, current_desc, adapter->fmp); if (current_desc->status & E1000_RXD_STAT_VP) VLAN_INPUT_TAG(ifp, adapter->fmp, (current_desc->special & E1000_RXD_SPC_VLAN_MASK), adapter->fmp = NULL); if (adapter->fmp != NULL) { EM_UNLOCK(adapter); (*ifp->if_input)(ifp, adapter->fmp); EM_LOCK(adapter); } #endif adapter->fmp = NULL; adapter->lmp = NULL; } } else { adapter->dropped_pkts++; em_get_buf(i, adapter, mp); if (adapter->fmp != NULL) m_freem(adapter->fmp); adapter->fmp = NULL; adapter->lmp = NULL; } /* Zero out the receive descriptors status */ current_desc->status = 0; /* Advance the E1000's Receive Queue #0 "Tail Pointer". */ E1000_WRITE_REG(&adapter->hw, RDT, i); /* Advance our pointers to the next descriptor */ if (++i == adapter->num_rx_desc) { i = 0; current_desc = adapter->rx_desc_base; } else current_desc++; } adapter->next_rx_desc_to_check = i; return; } /********************************************************************* * * Verify that the hardware indicated that the checksum is valid. * Inform the stack about the status of checksum so that stack * doesn't spend time verifying the checksum. * *********************************************************************/ static void em_receive_checksum(struct adapter *adapter, struct em_rx_desc *rx_desc, struct mbuf *mp) { /* 82543 or newer only */ if ((adapter->hw.mac_type < em_82543) || /* Ignore Checksum bit is set */ (rx_desc->status & E1000_RXD_STAT_IXSM)) { mp->m_pkthdr.csum_flags = 0; return; } if (rx_desc->status & E1000_RXD_STAT_IPCS) { /* Did it pass? */ if (!(rx_desc->errors & E1000_RXD_ERR_IPE)) { /* IP Checksum Good */ mp->m_pkthdr.csum_flags = CSUM_IP_CHECKED; mp->m_pkthdr.csum_flags |= CSUM_IP_VALID; } else { mp->m_pkthdr.csum_flags = 0; } } if (rx_desc->status & E1000_RXD_STAT_TCPCS) { /* Did it pass? */ if (!(rx_desc->errors & E1000_RXD_ERR_TCPE)) { mp->m_pkthdr.csum_flags |= (CSUM_DATA_VALID | CSUM_PSEUDO_HDR); mp->m_pkthdr.csum_data = htons(0xffff); } } return; } static void em_enable_vlans(struct adapter *adapter) { uint32_t ctrl; E1000_WRITE_REG(&adapter->hw, VET, ETHERTYPE_VLAN); ctrl = E1000_READ_REG(&adapter->hw, CTRL); ctrl |= E1000_CTRL_VME; E1000_WRITE_REG(&adapter->hw, CTRL, ctrl); return; } static void em_enable_intr(struct adapter * adapter) { E1000_WRITE_REG(&adapter->hw, IMS, (IMS_ENABLE_MASK)); return; } static void em_disable_intr(struct adapter *adapter) { E1000_WRITE_REG(&adapter->hw, IMC, (0xffffffff & ~E1000_IMC_RXSEQ)); return; } static int em_is_valid_ether_addr(u_int8_t *addr) { char zero_addr[6] = { 0, 0, 0, 0, 0, 0 }; if ((addr[0] & 1) || (!bcmp(addr, zero_addr, ETHER_ADDR_LEN))) { return (FALSE); } return(TRUE); } void em_write_pci_cfg(struct em_hw *hw, uint32_t reg, uint16_t *value) { pci_write_config(((struct em_osdep *)hw->back)->dev, reg, *value, 2); } void em_read_pci_cfg(struct em_hw *hw, uint32_t reg, uint16_t *value) { *value = pci_read_config(((struct em_osdep *)hw->back)->dev, reg, 2); return; } void em_pci_set_mwi(struct em_hw *hw) { pci_write_config(((struct em_osdep *)hw->back)->dev, PCIR_COMMAND, (hw->pci_cmd_word | CMD_MEM_WRT_INVALIDATE), 2); return; } void em_pci_clear_mwi(struct em_hw *hw) { pci_write_config(((struct em_osdep *)hw->back)->dev, PCIR_COMMAND, (hw->pci_cmd_word & ~CMD_MEM_WRT_INVALIDATE), 2); return; } uint32_t em_io_read(struct em_hw *hw, unsigned long port) { return(inl(port)); } void em_io_write(struct em_hw *hw, unsigned long port, uint32_t value) { outl(port, value); return; } /********************************************************************* * 82544 Coexistence issue workaround. * There are 2 issues. * 1. Transmit Hang issue. * To detect this issue, following equation can be used... * SIZE[3:0] + ADDR[2:0] = SUM[3:0]. * If SUM[3:0] is in between 1 to 4, we will have this issue. * * 2. DAC issue. * To detect this issue, following equation can be used... * SIZE[3:0] + ADDR[2:0] = SUM[3:0]. * If SUM[3:0] is in between 9 to c, we will have this issue. * * * WORKAROUND: * Make sure we do not have ending address as 1,2,3,4(Hang) or 9,a,b,c (DAC) * *** *********************************************************************/ static u_int32_t em_fill_descriptors (u_int64_t address, u_int32_t length, PDESC_ARRAY desc_array) { /* Since issue is sensitive to length and address.*/ /* Let us first check the address...*/ u_int32_t safe_terminator; if (length <= 4) { desc_array->descriptor[0].address = address; desc_array->descriptor[0].length = length; desc_array->elements = 1; return desc_array->elements; } safe_terminator = (u_int32_t)((((u_int32_t)address & 0x7) + (length & 0xF)) & 0xF); /* if it does not fall between 0x1 to 0x4 and 0x9 to 0xC then return */ if (safe_terminator == 0 || (safe_terminator > 4 && safe_terminator < 9) || (safe_terminator > 0xC && safe_terminator <= 0xF)) { desc_array->descriptor[0].address = address; desc_array->descriptor[0].length = length; desc_array->elements = 1; return desc_array->elements; } desc_array->descriptor[0].address = address; desc_array->descriptor[0].length = length - 4; desc_array->descriptor[1].address = address + (length - 4); desc_array->descriptor[1].length = 4; desc_array->elements = 2; return desc_array->elements; } /********************************************************************** * * Update the board statistics counters. * **********************************************************************/ static void em_update_stats_counters(struct adapter *adapter) { struct ifnet *ifp; if(adapter->hw.media_type == em_media_type_copper || (E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_LU)) { adapter->stats.symerrs += E1000_READ_REG(&adapter->hw, SYMERRS); adapter->stats.sec += E1000_READ_REG(&adapter->hw, SEC); } adapter->stats.crcerrs += E1000_READ_REG(&adapter->hw, CRCERRS); adapter->stats.mpc += E1000_READ_REG(&adapter->hw, MPC); adapter->stats.scc += E1000_READ_REG(&adapter->hw, SCC); adapter->stats.ecol += E1000_READ_REG(&adapter->hw, ECOL); adapter->stats.mcc += E1000_READ_REG(&adapter->hw, MCC); adapter->stats.latecol += E1000_READ_REG(&adapter->hw, LATECOL); adapter->stats.colc += E1000_READ_REG(&adapter->hw, COLC); adapter->stats.dc += E1000_READ_REG(&adapter->hw, DC); adapter->stats.rlec += E1000_READ_REG(&adapter->hw, RLEC); adapter->stats.xonrxc += E1000_READ_REG(&adapter->hw, XONRXC); adapter->stats.xontxc += E1000_READ_REG(&adapter->hw, XONTXC); adapter->stats.xoffrxc += E1000_READ_REG(&adapter->hw, XOFFRXC); adapter->stats.xofftxc += E1000_READ_REG(&adapter->hw, XOFFTXC); adapter->stats.fcruc += E1000_READ_REG(&adapter->hw, FCRUC); adapter->stats.prc64 += E1000_READ_REG(&adapter->hw, PRC64); adapter->stats.prc127 += E1000_READ_REG(&adapter->hw, PRC127); adapter->stats.prc255 += E1000_READ_REG(&adapter->hw, PRC255); adapter->stats.prc511 += E1000_READ_REG(&adapter->hw, PRC511); adapter->stats.prc1023 += E1000_READ_REG(&adapter->hw, PRC1023); adapter->stats.prc1522 += E1000_READ_REG(&adapter->hw, PRC1522); adapter->stats.gprc += E1000_READ_REG(&adapter->hw, GPRC); adapter->stats.bprc += E1000_READ_REG(&adapter->hw, BPRC); adapter->stats.mprc += E1000_READ_REG(&adapter->hw, MPRC); adapter->stats.gptc += E1000_READ_REG(&adapter->hw, GPTC); /* For the 64-bit byte counters the low dword must be read first. */ /* Both registers clear on the read of the high dword */ adapter->stats.gorcl += E1000_READ_REG(&adapter->hw, GORCL); adapter->stats.gorch += E1000_READ_REG(&adapter->hw, GORCH); adapter->stats.gotcl += E1000_READ_REG(&adapter->hw, GOTCL); adapter->stats.gotch += E1000_READ_REG(&adapter->hw, GOTCH); adapter->stats.rnbc += E1000_READ_REG(&adapter->hw, RNBC); adapter->stats.ruc += E1000_READ_REG(&adapter->hw, RUC); adapter->stats.rfc += E1000_READ_REG(&adapter->hw, RFC); adapter->stats.roc += E1000_READ_REG(&adapter->hw, ROC); adapter->stats.rjc += E1000_READ_REG(&adapter->hw, RJC); adapter->stats.torl += E1000_READ_REG(&adapter->hw, TORL); adapter->stats.torh += E1000_READ_REG(&adapter->hw, TORH); adapter->stats.totl += E1000_READ_REG(&adapter->hw, TOTL); adapter->stats.toth += E1000_READ_REG(&adapter->hw, TOTH); adapter->stats.tpr += E1000_READ_REG(&adapter->hw, TPR); adapter->stats.tpt += E1000_READ_REG(&adapter->hw, TPT); adapter->stats.ptc64 += E1000_READ_REG(&adapter->hw, PTC64); adapter->stats.ptc127 += E1000_READ_REG(&adapter->hw, PTC127); adapter->stats.ptc255 += E1000_READ_REG(&adapter->hw, PTC255); adapter->stats.ptc511 += E1000_READ_REG(&adapter->hw, PTC511); adapter->stats.ptc1023 += E1000_READ_REG(&adapter->hw, PTC1023); adapter->stats.ptc1522 += E1000_READ_REG(&adapter->hw, PTC1522); adapter->stats.mptc += E1000_READ_REG(&adapter->hw, MPTC); adapter->stats.bptc += E1000_READ_REG(&adapter->hw, BPTC); if (adapter->hw.mac_type >= em_82543) { adapter->stats.algnerrc += E1000_READ_REG(&adapter->hw, ALGNERRC); adapter->stats.rxerrc += E1000_READ_REG(&adapter->hw, RXERRC); adapter->stats.tncrs += E1000_READ_REG(&adapter->hw, TNCRS); adapter->stats.cexterr += E1000_READ_REG(&adapter->hw, CEXTERR); adapter->stats.tsctc += E1000_READ_REG(&adapter->hw, TSCTC); adapter->stats.tsctfc += E1000_READ_REG(&adapter->hw, TSCTFC); } ifp = &adapter->interface_data.ac_if; /* Fill out the OS statistics structure */ ifp->if_ibytes = adapter->stats.gorcl; ifp->if_obytes = adapter->stats.gotcl; ifp->if_imcasts = adapter->stats.mprc; ifp->if_collisions = adapter->stats.colc; /* Rx Errors */ ifp->if_ierrors = adapter->dropped_pkts + adapter->stats.rxerrc + adapter->stats.crcerrs + adapter->stats.algnerrc + adapter->stats.rlec + adapter->stats.mpc + adapter->stats.cexterr; /* Tx Errors */ ifp->if_oerrors = adapter->stats.ecol + adapter->stats.latecol; } /********************************************************************** * * This routine is called only when em_display_debug_stats is enabled. * This routine provides a way to take a look at important statistics * maintained by the driver and hardware. * **********************************************************************/ static void em_print_debug_info(struct adapter *adapter) { int unit = adapter->unit; uint8_t *hw_addr = adapter->hw.hw_addr; printf("em%d: Adapter hardware address = %p \n", unit, hw_addr); printf("em%d:CTRL = 0x%x\n", unit, E1000_READ_REG(&adapter->hw, CTRL)); printf("em%d:RCTL = 0x%x PS=(0x8402)\n", unit, E1000_READ_REG(&adapter->hw, RCTL)); printf("em%d:tx_int_delay = %d, tx_abs_int_delay = %d\n", unit, E1000_READ_REG(&adapter->hw, TIDV), E1000_READ_REG(&adapter->hw, TADV)); printf("em%d:rx_int_delay = %d, rx_abs_int_delay = %d\n", unit, E1000_READ_REG(&adapter->hw, RDTR), E1000_READ_REG(&adapter->hw, RADV)); #ifdef DBG_STATS printf("em%d: Packets not Avail = %ld\n", unit, adapter->no_pkts_avail); printf("em%d: CleanTxInterrupts = %ld\n", unit, adapter->clean_tx_interrupts); #endif printf("em%d: fifo workaround = %lld, fifo_reset = %lld\n", unit, (long long)adapter->tx_fifo_wrk_cnt, (long long)adapter->tx_fifo_reset_cnt); printf("em%d: hw tdh = %d, hw tdt = %d\n", unit, E1000_READ_REG(&adapter->hw, TDH), E1000_READ_REG(&adapter->hw, TDT)); printf("em%d: Num Tx descriptors avail = %d\n", unit, adapter->num_tx_desc_avail); printf("em%d: Tx Descriptors not avail1 = %ld\n", unit, adapter->no_tx_desc_avail1); printf("em%d: Tx Descriptors not avail2 = %ld\n", unit, adapter->no_tx_desc_avail2); printf("em%d: Std mbuf failed = %ld\n", unit, adapter->mbuf_alloc_failed); printf("em%d: Std mbuf cluster failed = %ld\n", unit, adapter->mbuf_cluster_failed); printf("em%d: Driver dropped packets = %ld\n", unit, adapter->dropped_pkts); return; } static void em_print_hw_stats(struct adapter *adapter) { int unit = adapter->unit; printf("em%d: Excessive collisions = %lld\n", unit, (long long)adapter->stats.ecol); printf("em%d: Symbol errors = %lld\n", unit, (long long)adapter->stats.symerrs); printf("em%d: Sequence errors = %lld\n", unit, (long long)adapter->stats.sec); printf("em%d: Defer count = %lld\n", unit, (long long)adapter->stats.dc); printf("em%d: Missed Packets = %lld\n", unit, (long long)adapter->stats.mpc); printf("em%d: Receive No Buffers = %lld\n", unit, (long long)adapter->stats.rnbc); printf("em%d: Receive length errors = %lld\n", unit, (long long)adapter->stats.rlec); printf("em%d: Receive errors = %lld\n", unit, (long long)adapter->stats.rxerrc); printf("em%d: Crc errors = %lld\n", unit, (long long)adapter->stats.crcerrs); printf("em%d: Alignment errors = %lld\n", unit, (long long)adapter->stats.algnerrc); printf("em%d: Carrier extension errors = %lld\n", unit, (long long)adapter->stats.cexterr); printf("em%d: XON Rcvd = %lld\n", unit, (long long)adapter->stats.xonrxc); printf("em%d: XON Xmtd = %lld\n", unit, (long long)adapter->stats.xontxc); printf("em%d: XOFF Rcvd = %lld\n", unit, (long long)adapter->stats.xoffrxc); printf("em%d: XOFF Xmtd = %lld\n", unit, (long long)adapter->stats.xofftxc); printf("em%d: Good Packets Rcvd = %lld\n", unit, (long long)adapter->stats.gprc); printf("em%d: Good Packets Xmtd = %lld\n", unit, (long long)adapter->stats.gptc); return; } static int em_sysctl_debug_info(SYSCTL_HANDLER_ARGS) { int error; int result; struct adapter *adapter; result = -1; error = sysctl_handle_int(oidp, &result, 0, req); if (error || !req->newptr) return (error); if (result == 1) { adapter = (struct adapter *)arg1; em_print_debug_info(adapter); } return error; } static int em_sysctl_stats(SYSCTL_HANDLER_ARGS) { int error; int result; struct adapter *adapter; result = -1; error = sysctl_handle_int(oidp, &result, 0, req); if (error || !req->newptr) return (error); if (result == 1) { adapter = (struct adapter *)arg1; em_print_hw_stats(adapter); } return error; } static int em_sysctl_int_delay(SYSCTL_HANDLER_ARGS) { struct em_int_delay_info *info; struct adapter *adapter; u_int32_t regval; int error; int usecs; int ticks; int s; info = (struct em_int_delay_info *)arg1; adapter = info->adapter; usecs = info->value; error = sysctl_handle_int(oidp, &usecs, 0, req); if (error != 0 || req->newptr == NULL) return error; if (usecs < 0 || usecs > E1000_TICKS_TO_USECS(65535)) return EINVAL; info->value = usecs; ticks = E1000_USECS_TO_TICKS(usecs); s = splimp(); regval = E1000_READ_OFFSET(&adapter->hw, info->offset); regval = (regval & ~0xffff) | (ticks & 0xffff); /* Handle a few special cases. */ switch (info->offset) { case E1000_RDTR: case E1000_82542_RDTR: regval |= E1000_RDT_FPDB; break; case E1000_TIDV: case E1000_82542_TIDV: if (ticks == 0) { adapter->txd_cmd &= ~E1000_TXD_CMD_IDE; /* Don't write 0 into the TIDV register. */ regval++; } else adapter->txd_cmd |= E1000_TXD_CMD_IDE; break; } E1000_WRITE_OFFSET(&adapter->hw, info->offset, regval); splx(s); return 0; } static void em_add_int_delay_sysctl(struct adapter *adapter, const char *name, const char *description, struct em_int_delay_info *info, int offset, int value) { info->adapter = adapter; info->offset = offset; info->value = value; SYSCTL_ADD_PROC(&adapter->sysctl_ctx, SYSCTL_CHILDREN(adapter->sysctl_tree), OID_AUTO, name, CTLTYPE_INT|CTLFLAG_RW, info, 0, em_sysctl_int_delay, "I", description); } --------------060804070402080204060705-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 14:51:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24AE116A4CE; Wed, 8 Dec 2004 14:51:11 +0000 (GMT) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3848C43D46; Wed, 8 Dec 2004 14:51:10 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from [127.0.0.1] (ss.eunet.cz. [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id iB8EoqJq003092; Wed, 8 Dec 2004 15:50:52 +0100 (CET) (envelope-from mime@traveller.cz) Message-ID: <41B714DA.6090505@traveller.cz> Date: Wed, 08 Dec 2004 15:51:06 +0100 From: Michal Mertl User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; cs-CZ; rv:1.7.3) Gecko/20041117 X-Accept-Language: cs, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------030904050009000006050607" cc: Andre Oppermann cc: Robert Watson Subject: New ICMP limits X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 14:51:11 -0000 This is a multi-part message in MIME format. --------------030904050009000006050607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I think some network administrators may want to set different maximum rate for different types of ICMP replies. Currently the limit net.inet.icmp.icmplim is enforced independently for the following cases - ICMP echo-reply, ICMP timestamp reply, ICMP port unreachable (generated as a response to a packet received on a UDP port with no listening application). It's in addition a bit misused (or at least misnamed) for limiting sending of TCP reset packets on closed and open ports. Andre Oppermann wrote a patch which adds support for limiting the sending of ICMP host unreachable messages. These are generated by a router when it can't send the packet to the destination, such as when it's about to send to an unused IP address on a directly connected network. I think we should look at what other similar packets we generate and if it makes any sense to limit their rate too. I'm aware of about only ICMP mask reply but there may be others. Special case are ICMP packets which could be returned by firewalls - filter prohibited and others but these may be better handled inside the firewall packages. I checked only ipfw2 and it uses icmp_error to send the response, co we could limit the rate there too. I wrote a patch which extends on net.inet.icmp.icmplim sysctl. It adds new sysctl branch net.inet.icmp.limits and all different types of ICMP (and TCP RST) replies have separate entries. It also changes the meaning of the value <=0. If the limit is set to 0, no limit is enforces, and if the limit is set to <0 packet is never sent. Setting the limit to <0 has rather interesting effects similar to blackhole(4) for tcp and udp and special with ICMP replies. The attached patch integrates Andre's patch for limiting the rate of ICMP host-unreachables. What do you think? -- Michal Mertl --------------030904050009000006050607 Content-Type: text/plain; name="icmp_limits.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="icmp_limits.patch" Index: icmp_var.h =================================================================== RCS file: /home/fcvs/cvs/src/sys/netinet/icmp_var.h,v retrieving revision 1.24 diff -u -r1.24 icmp_var.h --- icmp_var.h 16 Aug 2004 18:32:07 -0000 1.24 +++ icmp_var.h 5 Dec 2004 17:35:39 -0000 @@ -57,32 +57,18 @@ u_long icps_noroute; /* no route back */ }; -/* - * Names for ICMP sysctl objects - */ -#define ICMPCTL_MASKREPL 1 /* allow replies to netmask requests */ -#define ICMPCTL_STATS 2 /* statistics (read-only) */ -#define ICMPCTL_ICMPLIM 3 -#define ICMPCTL_MAXID 4 - -#define ICMPCTL_NAMES { \ - { 0, 0 }, \ - { "maskrepl", CTLTYPE_INT }, \ - { "stats", CTLTYPE_STRUCT }, \ - { "icmplim", CTLTYPE_INT }, \ -} - #ifdef _KERNEL SYSCTL_DECL(_net_inet_icmp); extern struct icmpstat icmpstat; /* icmp statistics */ extern int badport_bandlim(int); #define BANDLIM_UNLIMITED -1 #define BANDLIM_ICMP_UNREACH 0 -#define BANDLIM_ICMP_ECHO 1 -#define BANDLIM_ICMP_TSTAMP 2 -#define BANDLIM_RST_CLOSEDPORT 3 /* No connection, and no listeners */ -#define BANDLIM_RST_OPENPORT 4 /* No connection, listener */ -#define BANDLIM_MAX 4 +#define BANDLIM_ICMP_UNREACH_HOST 1 +#define BANDLIM_ICMP_ECHO 2 +#define BANDLIM_ICMP_TSTAMP 3 +#define BANDLIM_RST_CLOSEDPORT 4 /* No connection, and no listeners */ +#define BANDLIM_RST_OPENPORT 5 /* No connection, listener */ +#define BANDLIM_MAX 5 #endif #endif Index: ip_icmp.c =================================================================== RCS file: /home/fcvs/cvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.97 diff -u -r1.97 ip_icmp.c --- ip_icmp.c 15 Sep 2004 20:13:26 -0000 1.97 +++ ip_icmp.c 5 Dec 2004 18:20:21 -0000 @@ -79,11 +79,11 @@ */ struct icmpstat icmpstat; -SYSCTL_STRUCT(_net_inet_icmp, ICMPCTL_STATS, stats, CTLFLAG_RW, +SYSCTL_STRUCT(_net_inet_icmp, OID_AUTO, stats, CTLFLAG_RW, &icmpstat, icmpstat, ""); static int icmpmaskrepl = 0; -SYSCTL_INT(_net_inet_icmp, ICMPCTL_MASKREPL, maskrepl, CTLFLAG_RW, +SYSCTL_INT(_net_inet_icmp, OID_AUTO, maskrepl, CTLFLAG_RW, &icmpmaskrepl, 0, "Reply to ICMP Address Mask Request packets."); static u_int icmpmaskfake = 0; @@ -98,9 +98,37 @@ SYSCTL_INT(_net_inet_icmp, OID_AUTO, log_redirect, CTLFLAG_RW, &log_redirect, 0, ""); -static int icmplim = 200; -SYSCTL_INT(_net_inet_icmp, ICMPCTL_ICMPLIM, icmplim, CTLFLAG_RW, - &icmplim, 0, ""); +SYSCTL_NODE(_net_inet_icmp, OID_AUTO, limits, CTLFLAG_RW, 0, + "ICMP replies limits"); + +static int icmplim_unreach_port = 200; +SYSCTL_INT(_net_inet_icmp_limits, BANDLIM_ICMP_UNREACH, unreach_port, + CTLFLAG_RW, &icmplim_unreach_port, 0, + "Maximum rate of ICMP port unreachables"); + +static int icmplim_unreach_host = 10; +SYSCTL_INT(_net_inet_icmp_limits, BANDLIM_ICMP_UNREACH_HOST, + unreach_host, CTLFLAG_RW, &icmplim_unreach_host, 0, + "Maximum rate of ICMP host unreachables"); + +static int icmplim_echo = 200; +SYSCTL_INT(_net_inet_icmp_limits, BANDLIM_ICMP_ECHO, echo, + CTLFLAG_RW, &icmplim_echo, 0,"Maximum rate of ICMP echo replies"); + +static int icmplim_tstamp = 200; +SYSCTL_INT(_net_inet_icmp_limits, BANDLIM_ICMP_TSTAMP, tstamp, + CTLFLAG_RW, &icmplim_tstamp, 0, + "Maximum rate of ICMP tstamp replies"); + +static int icmplim_rst_closed = 200; +SYSCTL_INT(_net_inet_icmp_limits, BANDLIM_RST_CLOSEDPORT, rst_closed, + CTLFLAG_RW, &icmplim_rst_closed, 0, + "Maximum rate of RSTs of closed ports"); + +static int icmplim_rst_open = 200; +SYSCTL_INT(_net_inet_icmp_limits, BANDLIM_RST_OPENPORT, rst_open, + CTLFLAG_RW, &icmplim_rst_open, 0, + "Maximum rate of RSTs of open ports"); static int icmplim_output = 1; SYSCTL_INT(_net_inet_icmp, OID_AUTO, icmplim_output, CTLFLAG_RW, @@ -172,6 +200,18 @@ if (n->m_flags & (M_BCAST|M_MCAST)) goto freeit; /* + * Limit sending of ICMP host unreachable messages. + * If we are acting as a router and someone is doing a sweep + * scan (eg. nmap and/or numerous windows worms) for destinations + * we are the gateway for but are not reachable (ie. a /24 on a + * interface and only a couple of hosts on the ethernet) we would + * generate a storm of ICMP host unreachable messages. + */ + if (type == ICMP_UNREACH && code == ICMP_UNREACH_HOST) { + if (badport_bandlim(BANDLIM_ICMP_UNREACH_HOST) < 0) + goto freeit; + } + /* * First, formulate icmp message */ m = m_gethdr(M_DONTWAIT, MT_HEADER); @@ -893,31 +933,60 @@ struct timeval lasttime; int curpps; } rates[BANDLIM_MAX+1] = { - { "icmp unreach response" }, + { "icmp unreach port response" }, + { "icmp unreach host response" }, { "icmp ping response" }, { "icmp tstamp response" }, { "closed port RST response" }, { "open port RST response" } }; - - /* - * Return ok status if feature disabled or argument out of range. - */ - if (icmplim > 0 && (u_int) which < N(rates)) { - struct rate *r = &rates[which]; - int opps = r->curpps; - - if (!ppsratecheck(&r->lasttime, &r->curpps, icmplim)) - return -1; /* discard packet */ - /* - * If we've dropped below the threshold after having - * rate-limited traffic print the message. This preserves - * the previous behaviour at the expense of added complexity. - */ - if (icmplim_output && opps > icmplim) - printf("Limiting %s from %d to %d packets/sec\n", - r->type, opps, icmplim); + struct rate *r; + int opps; + int limit; + + /* Return ok status if argument is out of range. */ + switch (which) { + case BANDLIM_ICMP_UNREACH: + limit = icmplim_unreach_port; + break; + case BANDLIM_ICMP_UNREACH_HOST: + limit = icmplim_unreach_host; + break; + case BANDLIM_ICMP_ECHO: + limit = icmplim_echo; + break; + case BANDLIM_ICMP_TSTAMP: + limit = icmplim_tstamp; + break; + case BANDLIM_RST_CLOSEDPORT: + limit = icmplim_rst_closed; + break; + case BANDLIM_RST_OPENPORT: + limit = icmplim_rst_open; + break; + default: + return (0); } + /* Return ok status if limit is 0 (unlimited) */ + if (limit == 0) + return (0); + /* Return fail status if limit is <0 (never send) */ + if (limit < 0) + return (-1); + + /* Do the actual rate check */ + r = &rates[which]; + opps = r->curpps; + if (!ppsratecheck(&r->lasttime, &r->curpps, limit)) + return -1; /* discard packet */ + /* + * If we've dropped below the threshold after having + * rate-limited traffic print the message. This preserves + * the previous behaviour at the expense of added complexity. + */ + if (icmplim_output && opps > limit) + printf("Limiting %s from %d to %d packets/sec\n", + r->type, opps, limit); return 0; /* okay to send packet */ #undef N } --------------030904050009000006050607-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 14:53:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E856616A4CF for ; Wed, 8 Dec 2004 14:53:05 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D2F943D55 for ; Wed, 8 Dec 2004 14:53:05 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 76510 invoked from network); 8 Dec 2004 14:43:01 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Dec 2004 14:43:01 -0000 Message-ID: <41B71553.278B66A4@freebsd.org> Date: Wed, 08 Dec 2004 15:53:07 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michal Mertl References: <41B714DA.6090505@traveller.cz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Robert Watson Subject: Re: New ICMP limits X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 14:53:06 -0000 Michal Mertl wrote: > > Hello, > > I think some network administrators may want to set different maximum rate > for different types of ICMP replies. Currently the limit > net.inet.icmp.icmplim is enforced independently for the following cases - > ICMP echo-reply, ICMP timestamp reply, ICMP port unreachable (generated as a > response to a packet received on a UDP port with no listening application). > It's in addition a bit misused (or at least misnamed) for limiting sending > of TCP reset packets on closed and open ports. > > Andre Oppermann wrote a patch which adds support for limiting the sending of > ICMP host unreachable messages. These are generated by a router when it > can't send the packet to the destination, such as when it's about to send to > an unused IP address on a directly connected network. Michael, I'll take care of this but I'm busy right now. Look into it later this week. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 19:02:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29E3D16A4CF for ; Wed, 8 Dec 2004 19:02:11 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2B5B43D5C for ; Wed, 8 Dec 2004 19:02:10 +0000 (GMT) (envelope-from sferris@gmail.com) Received: by rproxy.gmail.com with SMTP id y7so757491rne for ; Wed, 08 Dec 2004 11:02:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=dD1qGdbO+OJYryLKeZD+6cfqKf+8ipRzMEmcxnZwQciigmpabd3slbERRDD1EBnAiuCo3MyE3RAT+8CEFza+yDSlZ+qOcHdGwXmtaNuz3ezBuGuo4OSNVOYy8rvHM5SOkB+sVU9AUaaoWxKSW276fjOC/OSmOPWb9lNENcoLbns= Received: by 10.38.208.43 with SMTP id f43mr437702rng; Wed, 08 Dec 2004 11:02:10 -0800 (PST) Received: by 10.38.83.5 with HTTP; Wed, 8 Dec 2004 11:02:09 -0800 (PST) Message-ID: <1eea89cd04120811026b06b288@mail.gmail.com> Date: Wed, 8 Dec 2004 13:02:09 -0600 From: "Scott M. Ferris" To: Vladimir Terziev In-Reply-To: <20041208115849.06de4961@daemon.cmotd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041207153117.536b9399@daemon.cmotd.com> <20041207214554.GK79919@obiwan.tataz.chchile.org> <20041208115849.06de4961@daemon.cmotd.com> cc: hackers@freebsd.org cc: Jeremie Le Hen cc: net@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Scott M. Ferris" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 19:02:11 -0000 On Wed, 8 Dec 2004 11:58:49 +0200, Vladimir Terziev wrote: > > Hi Jeremie, > > I've managed to build UCARP binary on FreeBSD 4.x without any problem. > Now i have to test it how good it works. ucarp will compile and run, but will silently fail to send heartbeats due to the way libpcap opens bpf on FreeBSD. You can find a patch to libpcap in PR 72814. http://www.freebsd.org/cgi/query-pr.cgi?pr=72814 -- Scott M. Ferris From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 19:33:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1514C16A4CE for ; Wed, 8 Dec 2004 19:33:30 +0000 (GMT) Received: from mail.dragondata.com (server3-a.your.org [64.202.112.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96E5843D5F for ; Wed, 8 Dec 2004 19:33:29 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from localhost (localhost.your.org [127.0.0.1]) by mail.dragondata.com (Postfix) with ESMTP id 207223D1DA6 for ; Wed, 8 Dec 2004 13:33:29 -0600 (CST) Received: from mail.dragondata.com ([127.0.0.1]) by localhost (server3.dragondata.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 45869-01-32 for ; Wed, 8 Dec 2004 13:33:28 -0600 (CST) Received: by mail.dragondata.com (Postfix, from userid 1000) id EC89B3D1D9F; Wed, 8 Dec 2004 13:33:28 -0600 (CST) Received: from [69.31.99.45] (pool045.dhcp.your.org [69.31.99.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.dragondata.com (Postfix) with ESMTP id 889FD3D1D9E for ; Wed, 8 Dec 2004 13:33:27 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <12FC45EB-4950-11D9-81D0-000A95A8A1F2@dragondata.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-net@freebsd.org From: Kevin Day Date: Wed, 8 Dec 2004 13:33:44 -0600 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server3.dragondata.com X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63 languages=en bayes=0.5 X-Virus-Scanned: by amavisd-new at dragondata.com Subject: Very strange kevent problem possibly to do with vinum X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 19:33:30 -0000 I have a really really strange kevent problem(i think anyway) that has really stumped me. Here's the scenario: Three mostly identical servers running 5.2.1 or 5.3 (problem exists on both). All three running thttpd sending out large files to thousands of clients. Thttpd internally uses kqueue/kevent and sendfile to send files rather quickly. All three have the same configuration, are getting approximately the same numbers of requests, and are sending approximately the same files. (I can swap IP addresses between the servers to confirm that the request distribution stays the same between the servers) Server #3 is able to send 400mbps or more of traffic through without breaking a sweat. Thttpd is either in "RUN", "biord" "sfbufa" or "*Giant" when I watch it in top, and I still have 80-90% idle time. Servers #1 and #2 seem to top out around 80mbps, and are constantly in "RUN" or "CPUx" states. I don't get any errors anywhere, but they just aren't capable of going any faster. Looking at ktrace on thttpd on all three servers, I see that server 3 calls kevent, and gets 20-100 sockets in response back, that each get serviced. Servers 1 and 2 never seem to get more than 1 socket back from kevent. Even if the event is just that the socket was disconnected, nothing needs to be done on it, and kevent can be called again immediately, there's only 1 socket returned next time. I ran ktrace on thttpd for more than 15 minutes and produced a humongous ktrace file, and there were only a handful of times that kevent returned more than one socket with something to do on it. Contrasting that to server 3, where i never saw kevent returning less than a half dozen sockets at a time when it had a few hundred mbps flowing through it. The ONLY difference between servers 1 and 2 and server 3 is the disk subsystem. Servers 1/2 use an "ahc" SCSI controller and vinum RAID5. Server 3 uses an "aac" hardware RAID. However, disk activity is really truly minimal on all of these servers. Most of the data remains cached, since 99% of the requests are for the same handful of files. systat/vmstat shows that the disks are busy less than 10% of the time, and artificially creating a bunch of disk load on any of the servers doesn't seem to affect anything. I'm not sure if the kevent difference is the cause of the problem (thttpd doesn't seem to handle going through its event loop over and over again for just one socket at a time, it makes some rather expensive syscalls from that loop), or if it's just a symptom. Is something in vinum possibly waking my process up somewhat prematurely? Is that even possible if the files are being sent through sendfile? Sorry for the vagueness, but I really don't know where else to look. -- Kevin From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 20:06:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA1CF16A4CE; Wed, 8 Dec 2004 20:06:28 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3896343D1D; Wed, 8 Dec 2004 20:06:28 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Cc84u-0003qx-00; Wed, 08 Dec 2004 21:06:24 +0100 Received: from [84.128.135.121] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1Cc84t-0004Dr-00; Wed, 08 Dec 2004 21:06:24 +0100 From: Max Laier To: Ruslan Ermilov Date: Wed, 8 Dec 2004 21:06:58 +0100 User-Agent: KMail/1.7.1 References: <20041207145932.GA1336@ip.net.ua> In-Reply-To: <20041207145932.GA1336@ip.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1904829.TKSjV2iQAs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412082107.05872.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: net@freebsd.org Subject: Re: Another bug with netmasked aliases (with fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 20:06:29 -0000 --nextPart1904829.TKSjV2iQAs Content-Type: multipart/mixed; boundary="Boundary-01=_k71tBder1E5eMss" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_k71tBder1E5eMss Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 07 December 2004 15:59, Ruslan Ermilov wrote: > Hi Max, > > I played today with "netmasked aliases", and found what > appears to be another bug. > > Adding an alias to the Ethernet interface with the same > netmask results in this address not being pingable from > this host -- it just spits ARP requests to the wire and > never hears back (most Ethernets are simplex devices). > > I knew what the fix should look like, and then quickly > found a ready to commit solution in OpenBSD rev. 1.47. > > When testing the attached patch, make sure you do *not* > have a (host) route for the alias being added. Took a little longer, busy times :-\ I didn't have this change in my carp patches (and was actually banging my h= ead=20 as it solves a long-standing problem) - Thanks. Any reason you didn't include the following (also part of OpenBSD rev. 1.47= )?: | /* | * make sure to set rt->rt_ifa to the interface | * address we are using, otherwise we will have trouble | * with source address selection. | */ | ifa =3D &ia->ia_ifa; | if (ifa !=3D rt->rt_ifa) { | IFAFREE(rt->rt_ifa); | ifa->ifa_refcnt++; | rt->rt_ifa =3D ifa; | } Updated diff attached. Not sure if it makes any difference? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_k71tBder1E5eMss Content-Type: text/x-diff; charset="iso-8859-1"; name="if_ether.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="if_ether.c.diff" Index: if_ether.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/netinet/if_ether.c,v retrieving revision 1.131 diff -u -r1.131 if_ether.c =2D-- if_ether.c 26 Oct 2004 03:31:58 -0000 1.131 +++ if_ether.c 8 Dec 2004 20:05:41 -0000 @@ -162,6 +162,8 @@ struct sockaddr *gate; struct llinfo_arp *la; static struct sockaddr_dl null_sdl =3D {sizeof(null_sdl), AF_LINK}; + struct in_ifaddr *ia; + struct ifaddr *ifa; =20 RT_LOCK_ASSERT(rt); =20 @@ -250,8 +252,13 @@ } #endif =20 =2D if (SIN(rt_key(rt))->sin_addr.s_addr =3D=3D =2D (IA_SIN(rt->rt_ifa))->sin_addr.s_addr) { + TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { + if (ia->ia_ifp =3D=3D rt->rt_ifp && + SIN(rt_key(rt))->sin_addr.s_addr =3D=3D + (IA_SIN(ia))->sin_addr.s_addr) + break; + } + if (ia) { /* * This test used to be * if (loif.if_flags & IFF_UP) @@ -268,6 +275,17 @@ if (useloopback) rt->rt_ifp =3D loif; =20 + /* + * make sure to set rt->rt_ifa to the interface + * address we are using, otherwise we will have trouble + * with source address selection. + */ + ifa =3D &ia->ia_ifa; + if (ifa !=3D rt->rt_ifa) { + IFAFREE(rt->rt_ifa); + IFAREF(ifa); + rt->rt_ifa =3D ifa; + } } break; =20 --Boundary-01=_k71tBder1E5eMss-- --nextPart1904829.TKSjV2iQAs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBt17pXyyEoT62BG0RAs+hAJ0T3L3Ztz4frN2xLplCURGbuTIurACdEVQd F+nxiF2YyoojGvToSSoxu4U= =HtJm -----END PGP SIGNATURE----- --nextPart1904829.TKSjV2iQAs-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 20:50:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7059616A4CE for ; Wed, 8 Dec 2004 20:50:19 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AE1743D5A for ; Wed, 8 Dec 2004 20:50:19 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) iB8KoHwN067651; Wed, 8 Dec 2004 12:50:18 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (fa0-1-wlan-rtr.corp.yahoo.com [216.145.49.5]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id iB8Knu2X094438; Wed, 8 Dec 2004 12:49:56 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Wed, 08 Dec 2004 12:49:52 -0800 Message-ID: From: gnn@freebsd.org To: "Konstantin KABASSANOV" In-Reply-To: <003101c4dd20$8ab9f070$8748e384@ipv6.lip6.fr> References: <003101c4dd20$8ab9f070$8748e384@ipv6.lip6.fr> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: the correct ipv6 behavior for interfaces with gif tunnel on them X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 20:50:19 -0000 At Wed, 8 Dec 2004 13:22:10 +0100, Konstantin KABASSANOV wrote: > > [1 ] > Hello, > > I have a freebsd box with a gif tunnel configured. I observed that even if > ifconfig displays MTU 1500 for both gif and physical interface, 1300 bytes > ipv6 packets transiting on the gif interface are systematically fragmented > while transiting on the lower physical interface to 1280 bytes. Is it the > normal behavior? The default MTU of IPv6 is 1280 bytes. From RFC 2460: It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC-1981], in order to discover and take advantage of path MTUs greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery. If the connection over the tunnel is not use Path MTU Discovery then this number may not change. Later, George From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 21:11:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D28416A4CE for ; Wed, 8 Dec 2004 21:11:25 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67C1C43D5A for ; Wed, 8 Dec 2004 21:11:24 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iB8LBN2v097854; Wed, 8 Dec 2004 23:11:23 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 57275-18; Wed, 8 Dec 2004 23:11:22 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iB8LBMcG097851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Dec 2004 23:11:22 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iB8LBMV5000101; Wed, 8 Dec 2004 23:11:22 +0200 (EET) (envelope-from ru) Date: Wed, 8 Dec 2004 23:11:22 +0200 From: Ruslan Ermilov To: Max Laier Message-ID: <20041208211121.GB61146@ip.net.ua> References: <20041207145932.GA1336@ip.net.ua> <200412082107.05872.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZfOjI3PrQbgiZnxM" Content-Disposition: inline In-Reply-To: <200412082107.05872.max@love2party.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: net@freebsd.org Subject: Re: Another bug with netmasked aliases (with fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 21:11:25 -0000 --ZfOjI3PrQbgiZnxM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Max, On Wed, Dec 08, 2004 at 09:06:58PM +0100, Max Laier wrote: > Any reason you didn't include the following (also part > of OpenBSD rev. 1.47)?: >=20 I developed it independently of OpenBSD, and only later found that OpenBSD also had it, so I missed this part. It's indeed needed. > | /* > | * make sure to set rt->rt_ifa to the interface > | * address we are using, otherwise we will have trouble > | * with source address selection. > | */ > | ifa =3D &ia->ia_ifa; > | if (ifa !=3D rt->rt_ifa) { > | IFAFREE(rt->rt_ifa); > | ifa->ifa_refcnt++; > | rt->rt_ifa =3D ifa; > | } >=20 >=20 > Updated diff attached. Not sure if it makes any difference? >=20 Of course it does. Without it, "ping " comes from the main address, where it should come from . Reviewed. Please commit. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ZfOjI3PrQbgiZnxM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBt235qRfpzJluFF4RAm8QAKCPFKnIlVpJVwId9mRGj6iBYhLKoQCeIhPb gNHjyU1iix/vGpbU8LoMPgc= =KQw/ -----END PGP SIGNATURE----- --ZfOjI3PrQbgiZnxM-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 8 23:39:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF3B216A4CE for ; Wed, 8 Dec 2004 23:39:56 +0000 (GMT) Received: from mta08-winn.mailhost.ntl.com (mailhost.ntl.com [212.250.162.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D33F43D2F for ; Wed, 8 Dec 2004 23:39:55 +0000 (GMT) (envelope-from andywhite@ntlworld.ie) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP <20041208233954.IEMK24423.mta08-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com> for ; Wed, 8 Dec 2004 23:39:54 +0000 Received: from HOMEBREW ([81.98.95.65]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20041208233954.HXJM1456.aamta06-winn.mailhost.ntl.com@HOMEBREW> for ; Wed, 8 Dec 2004 23:39:54 +0000 From: "Andrew White" To: Date: Wed, 8 Dec 2004 23:43:31 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTdf7kwsbdYKzI+R6Wuq69N8qD3Bg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20041208233954.HXJM1456.aamta06-winn.mailhost.ntl.com@HOMEBREW> Subject: Best layer 2 bridge over IP solution ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 23:39:56 -0000 I'm looking for suggestions to the problem below, any help appreciated !! I have several offices which use LAT MOP and IPX. This works over the existing WAN as it is a combination of bridging and routing (routed IP ). I would like to move to a pure IP network, but need to transport these protocols until we can remove them entirely from the network. Is Vtun and netgraph the way to go ? Or is there a simple more stable/proven method of achiving this ? Thanks in advance !! .Andrew From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 02:06:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 063E916A4CE; Thu, 9 Dec 2004 02:06:30 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ECEB43D5D; Thu, 9 Dec 2004 02:06:29 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 05DC865428; Thu, 9 Dec 2004 02:06:24 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19552-03-2; Thu, 9 Dec 2004 02:06:23 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id C26D5651EB; Thu, 9 Dec 2004 02:06:16 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 6ADE56710; Wed, 8 Dec 2004 18:05:25 -0800 (PST) Date: Wed, 8 Dec 2004 18:05:25 -0800 From: Bruce M Simpson To: "Scott M. Ferris" Message-ID: <20041209020525.GA691@empiric.icir.org> References: <20041207153117.536b9399@daemon.cmotd.com> <20041207214554.GK79919@obiwan.tataz.chchile.org> <20041208115849.06de4961@daemon.cmotd.com> <1eea89cd04120811026b06b288@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1eea89cd04120811026b06b288@mail.gmail.com> cc: hackers@freebsd.org cc: Jeremie Le Hen cc: net@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 02:06:30 -0000 On Wed, Dec 08, 2004 at 01:02:09PM -0600, Scott M. Ferris wrote: > ucarp will compile and run, but will silently fail to send heartbeats > due to the way libpcap > opens bpf on FreeBSD. You can find a patch to libpcap in PR 72814. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=72814 This is something else which needs a pcap/tcpdump update. Currently there is no way to specify this behaviour at runtime. Hopefully this should be resolved at the next import. BMS From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 02:21:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF25516A4CE; Thu, 9 Dec 2004 02:21:09 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id B31F643D62; Thu, 9 Dec 2004 02:21:09 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id C24A96542A; Thu, 9 Dec 2004 02:21:08 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19620-04-5; Thu, 9 Dec 2004 02:21:08 +0000 (GMT) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 2396165428; Thu, 9 Dec 2004 02:21:08 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 605C66710; Wed, 8 Dec 2004 18:21:07 -0800 (PST) Date: Wed, 8 Dec 2004 18:21:07 -0800 From: Bruce M Simpson To: Andre Oppermann Message-ID: <20041209022107.GB691@empiric.icir.org> Mail-Followup-To: Andre Oppermann , Michal Mertl , freebsd-net@freebsd.org, Robert Watson References: <41B714DA.6090505@traveller.cz> <41B71553.278B66A4@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41B71553.278B66A4@freebsd.org> cc: freebsd-net@freebsd.org cc: Michal Mertl cc: Robert Watson Subject: Re: New ICMP limits X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 02:21:10 -0000 On Wed, Dec 08, 2004 at 03:53:07PM +0100, Andre Oppermann wrote: > I'll take care of this but I'm busy right now. Look into it later this week. Thanks for looking into this, this is one of the items which came up on the TODO lists of three separate projects (TowardEX's, XORP's, and the Network Junta's). If you aren't able to look at it let us know so someone else can step up to the mic. Of course, the sooner we can remove ARP's special meaning from RTF_REJECT, the better - that would let us implement RTF_REJECT in the fastforwarding path without further worry. Best, BMS From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 04:02:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CA1116A4CE; Thu, 9 Dec 2004 04:02:54 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75FA243D46; Thu, 9 Dec 2004 04:02:54 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id EA1682F946; Wed, 8 Dec 2004 23:02:53 -0500 (EST) Date: Wed, 8 Dec 2004 23:02:53 -0500 From: James To: Andre Oppermann , Michal Mertl , freebsd-net@freebsd.org, Robert Watson Message-ID: <20041209040253.GA2417@scylla.towardex.com> References: <41B714DA.6090505@traveller.cz> <41B71553.278B66A4@freebsd.org> <20041209022107.GB691@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041209022107.GB691@empiric.icir.org> User-Agent: Mutt/1.4.1i Subject: Re: New ICMP limits X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 04:02:54 -0000 On Wed, Dec 08, 2004 at 06:21:07PM -0800, Bruce M Simpson wrote: > On Wed, Dec 08, 2004 at 03:53:07PM +0100, Andre Oppermann wrote: > > I'll take care of this but I'm busy right now. Look into it later this week. > > Thanks for looking into this, this is one of the items which came up on > the TODO lists of three separate projects (TowardEX's, XORP's, and the > Network Junta's). If you aren't able to look at it let us know so someone > else can step up to the mic. > > Of course, the sooner we can remove ARP's special meaning from RTF_REJECT, > the better - that would let us implement RTF_REJECT in the fastforwarding > path without further worry. When we have routing table cleaned up (e.g. remove arp off of it), I'll look into getting out some patch for installing /32 host routes for all receive-adjacent addresses. This way we don't have to run a hash lookup at ip_fastforward() to find out whether address belongs to us. We can simply either route it to lo0 as a receive-path (like in Cisco GSR/7500 rcvpath and Juniper loopback path) or send it to a separate input handling routine with packet filtering before returning to ip_input. Unless ofcourse, someone already has it made up and ready to go -- in that case there is no need ;) Thanks, -J -- James Jun TowardEX Technologies, Inc. Technical Lead Boston IPv4/IPv6 Web Hosting, Colocation and james@towardex.com Network design/consulting & configuration services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 04:53:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B322216A4CE for ; Thu, 9 Dec 2004 04:53:25 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0697643D54 for ; Thu, 9 Dec 2004 04:53:24 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:b130:5937:253a:915f]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 40D1C1521E; Thu, 9 Dec 2004 13:53:17 +0900 (JST) Date: Thu, 09 Dec 2004 13:53:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Konstantin KABASSANOV" In-Reply-To: <003101c4dd20$8ab9f070$8748e384@ipv6.lip6.fr> References: <003101c4dd20$8ab9f070$8748e384@ipv6.lip6.fr> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: the correct ipv6 behavior for interfaces with gif tunnel on them X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 04:53:25 -0000 >>>>> On Wed, 8 Dec 2004 13:22:10 +0100, >>>>> "Konstantin KABASSANOV" said: > I have a freebsd box with a gif tunnel configured. I observed that even if > ifconfig displays MTU 1500 for both gif and physical interface, 1300 bytes > ipv6 packets transiting on the gif interface are systematically fragmented > while transiting on the lower physical interface to 1280 bytes. Is it the > normal behavior? Please provide more detailed network configuration. Are you talking about a router box forwarding packets onto gif and physical interfaces? Please also specify the OS name (which I guess is FreeBSD) and its version. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 07:54:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E074D16A4CE; Thu, 9 Dec 2004 07:54:32 +0000 (GMT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E44F43D54; Thu, 9 Dec 2004 07:54:32 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (unknown [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id 47D53255A3B; Thu, 9 Dec 2004 08:54:31 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 98E04412C; Thu, 9 Dec 2004 08:52:53 +0100 (CET) Date: Thu, 9 Dec 2004 08:52:53 +0100 From: Jeremie Le Hen To: Bruce M Simpson Message-ID: <20041209075253.GY79919@obiwan.tataz.chchile.org> References: <20041207153117.536b9399@daemon.cmotd.com> <20041207214554.GK79919@obiwan.tataz.chchile.org> <20041208115849.06de4961@daemon.cmotd.com> <1eea89cd04120811026b06b288@mail.gmail.com> <20041209020525.GA691@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041209020525.GA691@empiric.icir.org> User-Agent: Mutt/1.5.6i cc: "Scott M. Ferris" cc: hackers@freebsd.org cc: Jeremie Le Hen cc: net@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 07:54:33 -0000 > This is something else which needs a pcap/tcpdump update. Currently there > is no way to specify this behaviour at runtime. > > Hopefully this should be resolved at the next import. Do you know when it is scheduled ? -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 08:52:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F382516A4CE for ; Thu, 9 Dec 2004 08:52:04 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A8C343D3F for ; Thu, 9 Dec 2004 08:52:04 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:200:0:8002:b130:5937:253a:915f]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 88B491521A; Thu, 9 Dec 2004 17:52:03 +0900 (JST) Date: Thu, 09 Dec 2004 17:52:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Wilkinson, Alex" In-Reply-To: <20041206114646.GD999@squash.dsto.defence.gov.au> References: <20041115222310.GA93130@scylla.towardex.com> <41B1EB4E.78490459@freebsd.org> <20041206114646.GD999@squash.dsto.defence.gov.au> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Initial review request for IPv6 Fast Forwarding and IP6STEALTH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 08:52:05 -0000 >>>>> On Mon, 6 Dec 2004 22:16:46 +1030, >>>>> "Wilkinson, Alex" said: >> Nice, needs some cleanup though. Once you have cleaned it up you can run >> it either through me or gnn@. He is more of a IPv6 fan than I am (in my >> book IPv6 is broken by design^TM). > Why ? (Perhaps this is slightly an off-topic for this list, but) I'm also interested in the reason, but it's not surprising that someone in the world has a negative impression on a big feature like IPv6 or IPsec, since such a thing has typically both pros and cons. And whatever the reason is, the important thing I believe is to keep IPv6 implementation as good as IPv4 one on FreeBSD, in terms of both stability and functionality. I'm quite sure the fact that FreeBSD has provided a good IPv6 implementation has enlarged the user base of this particular operating system, comparing to, e.g., Linux. So, I hope core FreeBSD developers to care about the quality of IPv6 implementation as seriously as that of IPv4 implementation, regardless of their own position on IPv6 itself. As an IPv6-related person, I'm willing to help that process if I can do something in that area. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 13:46:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7F9516A4CF for ; Thu, 9 Dec 2004 13:46:14 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A6F43D3F for ; Thu, 9 Dec 2004 13:46:14 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 85141 invoked from network); 9 Dec 2004 13:36:00 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Dec 2004 13:36:00 -0000 Message-ID: <41B85729.40F00890@freebsd.org> Date: Thu, 09 Dec 2004 14:46:17 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeremie Le Hen References: <20041129100949.GA19560@bps.jodocus.org> <41AAF696.6ED81FBF@freebsd.org> <20041129103031.GA19828@bps.jodocus.org> <41AB3A74.8C05601D@freebsd.org> <20041129174954.GA26532@bps.jodocus.org> <41AB65B2.A18534BF@freebsd.org> <20041206134315.GF79919@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Joost Bekkers cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order for outgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 13:46:14 -0000 Jeremie Le Hen wrote: > > > > > > I have some stuff wrt [Fast]IPSEC and your problem in the works and > > > > > it should become ready around christmas time (loadable [Fast]IPSEC, at > > > > > least for IPv4). > > > > > > > > While this way of 'fixing' the IPSEC problem works it is rather gross > > > > and not very stylish. I prefer not to have this in the tree as makes > > > > maintainance a lot harder. > > > > > > I totaly agree that it is not pretty. I was trying to avoid duplicating > > > the code (so every change would have to be made twice) and making it a > > > function didn't sit right for some reason. Hints/tips for dealing with > > > this kind of situation are welcome, but maybe better off-list. > > > > As things currently are with IPSEC code weaved directly into ip_input() > > and ip_output() there is no better way than what you have proposed. > > > > It will solve it much more nicely. :) > > If I understand correctly, either Joost's patch or your nice changes > that-should-appear-before-christmas will achieve what the OpenBSD enc(4) > interface provides [1]. It would be really wonderful. But I may be > missing something because I can see no way in firewall rules to > distinguish between the before IPSec processing hook and the after IPSec > processing one. Could you clarify this for me please ? With the changes you can chose whether you want to do firewallig before ipsec processing or after but not both. The enc(4) pseudo device looks interesting but I haven't looked at the code. Maybe that makes things easier. I'll look into it. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 13:52:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EE3916A4CE; Thu, 9 Dec 2004 13:52:20 +0000 (GMT) Received: from mail.tacorp.net (mail.tacorp.net [64.246.111.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C865243D31; Thu, 9 Dec 2004 13:52:19 +0000 (GMT) (envelope-from raistlin@tacorp.net) Received: from mail.tacorp.net (raistlin@localhost [127.0.0.1]) by mail.tacorp.net (8.13.1/8.12.10) with ESMTP id iB9DtlJV066624; Thu, 9 Dec 2004 08:55:47 -0500 (EST) (envelope-from raistlin@tacorp.net) Received: from localhost (raistlin@localhost)iB9DtlLY066621; Thu, 9 Dec 2004 08:55:47 -0500 (EST) (envelope-from raistlin@tacorp.net) X-Authentication-Warning: mail.tacorp.net: raistlin owned process doing -bs Date: Thu, 9 Dec 2004 08:55:47 -0500 (EST) From: Jason Slagle To: "Scott M. Ferris" In-Reply-To: <1eea89cd04120811026b06b288@mail.gmail.com> Message-ID: <20041209085435.J53452@mail.tacorp.net> References: <20041207153117.536b9399@daemon.cmotd.com> <20041208115849.06de4961@daemon.cmotd.com> <1eea89cd04120811026b06b288@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: hackers@freebsd.org cc: Jeremie Le Hen cc: net@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 13:52:20 -0000 On Wed, 8 Dec 2004, Scott M. Ferris wrote: > ucarp will compile and run, but will silently fail to send heartbeats > due to the way libpcap > opens bpf on FreeBSD. You can find a patch to libpcap in PR 72814. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=72814 I submitted a similiar pr over a year ago to try to get it fixed so emulators (PDP-11 etc) which use pcap to send packets work. I was unable to find a committer to commit it. Perhaps this will be a more important issue than that was as I'd love to see the patch committed. Jason -- Jason Slagle - CCNP - CCDP /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 15:19:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B07916A4CE for ; Thu, 9 Dec 2004 15:19:14 +0000 (GMT) Received: from manian.sics.se (manian.sics.se [193.10.66.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCC5043D6E for ; Thu, 9 Dec 2004 15:19:13 +0000 (GMT) (envelope-from bg@sics.se) Received: from manian.sics.se (localhost [127.0.0.1]) by manian.sics.se (8.13.1/8.13.1) with SMTP id iB9FIt3i004135; Thu, 9 Dec 2004 16:18:55 +0100 (CET) (envelope-from bg@sics.se) Date: Thu, 9 Dec 2004 16:18:55 +0100 From: =?ISO-8859-1?Q?Bj=F6rn_Gr=F6nvall?= To: Bruce M Simpson , alfred@FreeBSD.org Message-ID: <20041209161855.30952220@manian.sics.se> In-Reply-To: <20041125215225.GF733@empiric.icir.org> References: <20041125201812.609e50f9@manian.sics.se> <20041125215225.GF733@empiric.icir.org> Organization: SICS X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit cc: lennox@cs.columbia.edu cc: freebsd-net@FreeBSD.org cc: kris@FreeBSD.org cc: dnelson@allantgroup.com Subject: Re: Linux compatible rpc.lockd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 15:19:14 -0000 On Thu, 25 Nov 2004 13:52:25 -0800 Bruce M Simpson wrote: Hi all, > On Thu, Nov 25, 2004 at 08:18:12PM +0100, Björn Grönvall wrote: > > I have made a patch to address PR kern/56461, in short the patch > > provides two different options to be compatible with Linux lockd > > implementations. It can also serve as a basis for a future more robust > > rpc.lockd. > > Thank you for this. I looked at this around 8 months ago but abandoned > further work on it because the approach I was taking required that > nfs be refactored to use the nmount() API, and because I am not currently > using NFS. It looks as though the two options implemented here helps to > address the problems I was having with making sure Linux servers got > the right lock cookie response. > > Have you tested this in production and does it work well? If so I believe > it should be committed, but I'd defer to Alfred for further review. I now believe that the patch has been tested enough. Its been running on a rather busy fileserver for almost 3 weeks now and we have observed no problems this far. To ensure that rpc.lockd works correctly on 64 bit machines I think this patch should also be applied. Cheers, Björn --- kern.c~ Thu Nov 25 19:43:44 2004 +++ kern.c Fri Nov 26 14:16:17 2004 @@ -44,6 +44,7 @@ #include #include #include +#include #include #include #include @@ -290,6 +291,12 @@ } res; int cookie_len; + /* union XXX */ + assert((void *)&res.res.cookie == &res.res4.cookie); + assert((void *)&res.res.stat.stat == &res.res4.stat.stat); + assert((void *)&res.res.stat.nlm_testrply_u.holder.svid == + &res.res4.stat.nlm4_testrply_u.holder.svid); + if (asynchronous_client_rpc) cookie_len = client_cookie_len; /* Long cookies */ else @@ -388,6 +395,10 @@ } res; int cookie_len; + /* union XXX */ + assert((void *)&res.res.cookie == &res.res4.cookie); + assert((void *)&res.res.stat.stat == &res.res4.stat.stat); + if (asynchronous_client_rpc) cookie_len = client_cookie_len; /* Long cookies */ else @@ -493,6 +504,10 @@ } res; int cookie_len; + /* union XXX */ + assert((void *)&res.res.cookie == &res.res4.cookie); + assert((void *)&res.res.stat.stat == &res.res4.stat.stat); + if (asynchronous_client_rpc) cookie_len = client_cookie_len; /* Long cookies */ else @@ -560,7 +575,7 @@ } else { touch_client(cli); lock_answer(msg->lm_msg_ident.pid, - &res.res.cookie, + &res.res.cookie, /* union XXX */ res.res.stat.stat, NULL, nlm_version); -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 '---------------' From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 16:15:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55A6916A4CE; Thu, 9 Dec 2004 16:15:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B88B443D39; Thu, 9 Dec 2004 16:15:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id BA41D1FF91D; Thu, 9 Dec 2004 17:15:07 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id D063D1FF90C; Thu, 9 Dec 2004 17:15:05 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id DDADF15767; Thu, 9 Dec 2004 16:10:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id DAFB815766; Thu, 9 Dec 2004 16:10:24 +0000 (UTC) Date: Thu, 9 Dec 2004 16:10:24 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Andre Oppermann In-Reply-To: <41B85729.40F00890@freebsd.org> Message-ID: References: <20041129100949.GA19560@bps.jodocus.org> <41AAF696.6ED81FBF@freebsd.org><41AB3A74.8C05601D@freebsd.org> <41AB65B2.A18534BF@freebsd.org><41B85729.40F00890@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order for outgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 16:15:10 -0000 On Thu, 9 Dec 2004, Andre Oppermann wrote: Hi, > With the changes you can chose whether you want to do firewallig before > ipsec processing or after but not both. I am unsure if I get that right but that's what the ipsec flag in ipfw2 is for and it is heavily used to filter ipsec encrypted traffic and the same traffic, tagged to come from an ipsec tunnel, afterwards. If your changes won't handle this you will break too many IPSec GWs I think. > The enc(4) pseudo device looks > interesting but I haven't looked at the code. Maybe that makes things > easier. I'll look into it. the code is quite simple and helpfull for debugging but not for a lot more with our current ipsec implementations (at least that had been the case about a year ago). -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 17:12:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A24B716A4CE for ; Thu, 9 Dec 2004 17:12:27 +0000 (GMT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A17A43D1D for ; Thu, 9 Dec 2004 17:12:25 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (unknown [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id E25E9C186; Thu, 9 Dec 2004 18:12:21 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 34CE2412C; Thu, 9 Dec 2004 18:10:40 +0100 (CET) Date: Thu, 9 Dec 2004 18:10:39 +0100 From: Jeremie Le Hen To: Vladimir Terziev Message-ID: <20041209171039.GE79919@obiwan.tataz.chchile.org> References: <20041207153117.536b9399@daemon.cmotd.com> <200412071434.15547.max@love2party.net> <20041207154007.61a19f43@daemon.cmotd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041207154007.61a19f43@daemon.cmotd.com> User-Agent: Mutt/1.5.6i cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 17:12:27 -0000 > I know it, but it is for FreeBSD 5.x . My gateways run FreeBSD 4.10 > and i don't have plans to upgrade them for now. I found on the "pf4freebsd" website [1] that there is an existing patch for DragonFlyBSD which *should* work on 4.x. I know this site has been deprecated by the new one [2], but the latter does not include this patch. Regards, [1] http://pf4freebsd.love2party.net/carp.html [2] http://people.freebsd.org/~mlaier/CARP/ -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 17:20:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D90E16A4CE for ; Thu, 9 Dec 2004 17:20:14 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E53543D49 for ; Thu, 9 Dec 2004 17:20:14 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) iB9HKAwR097993; Thu, 9 Dec 2004 09:20:13 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (h229.neville-neil.com [209.157.133.229] (may be forged)) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id iB9HK18r082107; Thu, 9 Dec 2004 09:20:02 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Thu, 09 Dec 2004 09:19:58 -0800 Message-ID: From: gnn@FreeBSD.org To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-Reply-To: References: <20041115222310.GA93130@scylla.towardex.com> <41B1EB4E.78490459@freebsd.org> <20041206114646.GD999@squash.dsto.defence.gov.au> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@FreeBSD.org Subject: Re: Initial review request for IPv6 Fast Forwarding and IP6STEALTH X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 17:20:14 -0000 At Thu, 09 Dec 2004 17:52:15 +0900, jinmei wrote: > (Perhaps this is slightly an off-topic for this list, but) I'm also > interested in the reason, but it's not surprising that someone in the > world has a negative impression on a big feature like IPv6 or IPsec, > since such a thing has typically both pros and cons. I'd really hope that this thread does not "devolve" around this issue, and perhaps Andre could answer this privately, as it really is off topic. > So, I hope core FreeBSD developers to care about the quality of IPv6 > implementation as seriously as that of IPv4 implementation, regardless > of their own position on IPv6 itself. As an IPv6-related person, I'm > willing to help that process if I can do something in that area. And as a new committer who's mostly working on IPv6 I can tell you that there are those of us who are working to make sure that the IPv6 in FreeBSD remains top notch. Later, George From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 17:28:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F91916A4CE for ; Thu, 9 Dec 2004 17:28:25 +0000 (GMT) Received: from parrot.aev.net (host29-15.pool8174.interbusiness.it [81.74.15.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DD0643D48 for ; Thu, 9 Dec 2004 17:28:22 +0000 (GMT) (envelope-from andrea.venturoli@netfence.it) Received: from soth.ventu (adsl-ull-78-5.41-151.net24.it [151.41.5.78]) (authenticated bits=128) by parrot.aev.net (8.13.1/8.13.1) with ESMTP id iB9HZBBd073707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Dec 2004 18:35:18 +0100 (CET) (envelope-from andrea.venturoli@netfence.it) Received: from netfence.it (xanatar.ventu [10.1.2.6]) by soth.ventu (8.13.1/8.12.10) with ESMTP id iB9HQaIf076903; Thu, 9 Dec 2004 18:26:36 +0100 (CET) (envelope-from andrea.venturoli@netfence.it) Message-ID: <41B88B45.4040407@netfence.it> Date: Thu, 09 Dec 2004 18:28:37 +0100 From: Andrea Venturoli Organization: NetFence User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: it,en,fr,de MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000105030507000008060907" X-Scanned-By: MIMEDefang 2.45 Subject: panic with 4.10p4 and ipfw2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 17:28:25 -0000 This is a cryptographically signed message in MIME format. --------------ms000105030507000008060907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello. A box of mine, which acts as firewall/bridge, is experiencing frequent panics. As said in the subject line, it's a 4.10-RELEASE-p4 with ipfw2 enabled in the kernel. I've run through post mortem kernel analisys and found out that the crashes are always related to ipfw2; specifically I get: > panic: free: multiple frees Here is the complete backtrack: > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 > #1 0xc0150993 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 > #2 0xc0150db8 in poweroff_wait (junk=0xc02354ac, howto=-1071427665) > at /usr/src/sys/kern/kern_shutdown.c:595 > #3 0xc0208a3e in trap_fatal (frame=0xc023a3e4, eva=48) > at /usr/src/sys/i386/i386/trap.c:974 > #4 0xc0208711 in trap_pfault (frame=0xc023a3e4, usermode=0, eva=48) > at /usr/src/sys/i386/i386/trap.c:867 > #5 0xc02082fb in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, > tf_esi = 0, tf_ebp = -1071406036, tf_isp = -1071406064, > tf_ebx = -1071330820, tf_edx = 6864896, tf_ecx = -1054588914, > tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071892584, tf_cs = 8, > tf_eflags = 66182, tf_esp = -967647568, tf_ss = 0}) > at /usr/src/sys/i386/i386/trap.c:466 > #6 0xc01c3798 in acquire_lock (lk=0xc024c9fc) > at /usr/src/sys/ufs/ffs/ffs_softdep.c:266 > #7 0xc01c8e7c in softdep_count_dependencies (bp=0xc652deb0, wantcount=0) > at /usr/src/sys/ufs/ffs/ffs_softdep.c:4792 > #8 0xc01cc0d8 in ffs_fsync (ap=0xc023a4a0) > at /usr/src/sys/ufs/ffs/ffs_vnops.c:168 > #9 0xc01cabab in ffs_sync (mp=0xc123fc00, waitfor=2, cred=0xc0a3e800, > p=0xc026dbe0) at vnode_if.h:558 > #10 0xc0181737 in sync (p=0xc026dbe0, uap=0x0) > at /usr/src/sys/kern/vfs_syscalls.c:583 > #11 0xc015072e in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:235 > #12 0xc0150db8 in poweroff_wait (junk=0xc0218cff, howto=-1051816704) > at /usr/src/sys/kern/kern_shutdown.c:595 > #13 0xc014c41f in free (addr=0xc18fc100, type=0xc0249420) > at /usr/src/sys/kern/kern_malloc.c:385 > #14 0xc01a56ce in lookup_dyn_rule (pkt=0xc023a650, match_direction=0xc023a5c8, > tcp=0xc0b26b50) at /usr/src/sys/netinet/ip_fw2.c:784 > #15 0xc01a6ae7 in ipfw_chk (args=0xc023a630) > at /usr/src/sys/netinet/ip_fw2.c:1900 > #16 0xc01aa5f5 in ip_output (m0=0xc0b26b00, opt=0x0, ro=0xd0bfb0fc, flags=0, > imo=0x0, inp=0xd0bfb0c0) at /usr/src/sys/netinet/ip_output.c:733 > #17 0xc01afc51 in tcp_output (tp=0xd0bfb180) > at /usr/src/sys/netinet/tcp_output.c:953 > #18 0xc01ae977 in tcp_input (m=0xc0b26b00, off0=20, proto=6) > at /usr/src/sys/netinet/tcp_input.c:2229 > #19 0xc01a8f1c in ip_input (m=0xc0b26b00) > at /usr/src/sys/netinet/ip_input.c:934 > #20 0xc01a8f7b in ipintr () at /usr/src/sys/netinet/ip_input.c:955 > #21 0xc01fbd89 in swi_net_next () > #22 0xc0156a69 in softclock () at /usr/src/sys/kern/kern_timeout.c:131 > #23 0xc01fbd43 in doreti_swi () So, free is called from the following fragment: > /** > * lookup a dynamic rule. > */ > static ipfw_dyn_rule * > lookup_dyn_rule(struct ipfw_flow_id *pkt, int *match_direction, > struct tcphdr *tcp) > { > /* > * stateful ipfw extensions. > * Lookup into dynamic session queue > */ > #define MATCH_REVERSE 0 > #define MATCH_FORWARD 1 > #define MATCH_NONE 2 > #define MATCH_UNKNOWN 3 > int i, dir = MATCH_NONE; > ipfw_dyn_rule *prev, *q=NULL; > > if (ipfw_dyn_v == NULL) > goto done; /* not found */ > i = hash_packet( pkt ); > for (prev=NULL, q = ipfw_dyn_v[i] ; q != NULL ; ) { > if (q->dyn_type == O_LIMIT_PARENT && q->count) > goto next; > if (TIME_LEQ( q->expire, time_second)) { /* expire entry */ > => UNLINK_DYN_RULE(prev, ipfw_dyn_v[i], q); > continue; > } > if (pkt->proto == q->id.proto && > q->dyn_type != O_LIMIT_PARENT) { I'm no kernel expert, so take my observation for what they might be worth, but: > (kgdb) p *q > $24 = {next = 0xc18a2d00, rule = 0xc6523b3c, parent = 0xd0001, > pcnt = 13916504069872025600, bcnt = 11709303859986432, id = {dst_ip = 0, > src_ip = 0, dst_port = 15744, src_port = 49469, proto = 164 '\244', > flags = 129 '\201'}, expire = 0, bucket = 4294967295, state = 4294967295, > ack_fwd = 0, ack_rev = 0, dyn_type = 0, count = 0} > (kgdb) These values do not make much sense to me... maybe the mess has already happened? Any hint? Is ipfw2 known to be broken in 4_10? Should I upgrade to 4_STABLE? Or is it just a matter of finding a better configuration for all the relevant sysctl (which are all set to their default values)? Really any help is appreciated!!! bye & Thanks av. --------------ms000105030507000008060907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHdDCC A7YwggMfoAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwgZExCzAJBgNVBAYTAklUMRAwDgYDVQQI EwdCb2xvZ25hMRAwDgYDVQQHEwdCb2xvZ25hMREwDwYDVQQKEwhOZXRGZW5jZTEkMCIGA1UE AxMbTmV0RmVuY2UgQ2VydGlmaWNhdGUgTWFzdGVyMSUwIwYJKoZIhvcNAQkBFhZwb3N0bWFz dGVyQG5ldGZlbmNlLml0MB4XDTA0MDcwNjE0NTczM1oXDTA3MDcwNjE0NTczM1owgY4xCzAJ BgNVBAYTAklUMRAwDgYDVQQIEwdCb2xvZ25hMRIwEAYDVQQHEwlWaWxsYW5vdmExETAPBgNV BAoTCE5ldEZlbmNlMRkwFwYDVQQDExBBbmRyZWEgVmVudHVyb2xpMSswKQYJKoZIhvcNAQkB FhxhbmRyZWEudmVudHVyb2xpQG5ldGZlbmNlLml0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDNut5pvhl9kcTaS4DwvTZA7I6G2cuNTi0zVYf3ObXn+eV5KPrUe+iIj5tsJHhZSFie Mmr/sU8+tmtL9w4F+IYqoJZMrj3pyBLwUuyG/UCA97j7iOunDXdQaezt3RjPTHDgZ1Estw42 O/tdOksw1RGz/Pcl1nYDAx3Qxb1s+CQDwwIDAQABo4IBHTCCARkwCQYDVR0TBAIwADAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFL+G 85rXpNrBqicRBxrsKKXAbTqxMIG+BgNVHSMEgbYwgbOAFGuQcrsEAmOxnk0uGCXT6UCTGFCD oYGXpIGUMIGRMQswCQYDVQQGEwJJVDEQMA4GA1UECBMHQm9sb2duYTEQMA4GA1UEBxMHQm9s b2duYTERMA8GA1UEChMITmV0RmVuY2UxJDAiBgNVBAMTG05ldEZlbmNlIENlcnRpZmljYXRl IE1hc3RlcjElMCMGCSqGSIb3DQEJARYWcG9zdG1hc3RlckBuZXRmZW5jZS5pdIIBADANBgkq hkiG9w0BAQQFAAOBgQCmYkfL9jqgRsIobKrZstcYZZXA0hMVKfMwUYddCKWJYjpoynV7k5pC CKo8ZLdfj9mhCnOkGLbhVpQL7ySMzAH5IbD2qgowAf06zV3rsmzmspw5iyL6iZQsJpoT+owg FtSpw2UgUuhWmq004PqgasdzlaJg3LRS1ACHmyPZKRUYaTCCA7YwggMfoAMCAQICAQQwDQYJ KoZIhvcNAQEEBQAwgZExCzAJBgNVBAYTAklUMRAwDgYDVQQIEwdCb2xvZ25hMRAwDgYDVQQH EwdCb2xvZ25hMREwDwYDVQQKEwhOZXRGZW5jZTEkMCIGA1UEAxMbTmV0RmVuY2UgQ2VydGlm aWNhdGUgTWFzdGVyMSUwIwYJKoZIhvcNAQkBFhZwb3N0bWFzdGVyQG5ldGZlbmNlLml0MB4X DTA0MDcwNjE0NTczM1oXDTA3MDcwNjE0NTczM1owgY4xCzAJBgNVBAYTAklUMRAwDgYDVQQI EwdCb2xvZ25hMRIwEAYDVQQHEwlWaWxsYW5vdmExETAPBgNVBAoTCE5ldEZlbmNlMRkwFwYD VQQDExBBbmRyZWEgVmVudHVyb2xpMSswKQYJKoZIhvcNAQkBFhxhbmRyZWEudmVudHVyb2xp QG5ldGZlbmNlLml0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDNut5pvhl9kcTaS4Dw vTZA7I6G2cuNTi0zVYf3ObXn+eV5KPrUe+iIj5tsJHhZSFieMmr/sU8+tmtL9w4F+IYqoJZM rj3pyBLwUuyG/UCA97j7iOunDXdQaezt3RjPTHDgZ1Estw42O/tdOksw1RGz/Pcl1nYDAx3Q xb1s+CQDwwIDAQABo4IBHTCCARkwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNT TCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFL+G85rXpNrBqicRBxrsKKXAbTqx MIG+BgNVHSMEgbYwgbOAFGuQcrsEAmOxnk0uGCXT6UCTGFCDoYGXpIGUMIGRMQswCQYDVQQG EwJJVDEQMA4GA1UECBMHQm9sb2duYTEQMA4GA1UEBxMHQm9sb2duYTERMA8GA1UEChMITmV0 RmVuY2UxJDAiBgNVBAMTG05ldEZlbmNlIENlcnRpZmljYXRlIE1hc3RlcjElMCMGCSqGSIb3 DQEJARYWcG9zdG1hc3RlckBuZXRmZW5jZS5pdIIBADANBgkqhkiG9w0BAQQFAAOBgQCmYkfL 9jqgRsIobKrZstcYZZXA0hMVKfMwUYddCKWJYjpoynV7k5pCCKo8ZLdfj9mhCnOkGLbhVpQL 7ySMzAH5IbD2qgowAf06zV3rsmzmspw5iyL6iZQsJpoT+owgFtSpw2UgUuhWmq004Pqgasdz laJg3LRS1ACHmyPZKRUYaTGCA0swggNHAgEBMIGXMIGRMQswCQYDVQQGEwJJVDEQMA4GA1UE CBMHQm9sb2duYTEQMA4GA1UEBxMHQm9sb2duYTERMA8GA1UEChMITmV0RmVuY2UxJDAiBgNV BAMTG05ldEZlbmNlIENlcnRpZmljYXRlIE1hc3RlcjElMCMGCSqGSIb3DQEJARYWcG9zdG1h c3RlckBuZXRmZW5jZS5pdAIBBDAJBgUrDgMCGgUAoIICCTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEyMDkxNzI4MzdaMCMGCSqGSIb3DQEJBDEWBBRp WQVh/yO00Tcqkmx8QypKk6IP9DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBqAYJ KwYBBAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJJVDEQMA4GA1UECBMHQm9sb2duYTEQMA4G A1UEBxMHQm9sb2duYTERMA8GA1UEChMITmV0RmVuY2UxJDAiBgNVBAMTG05ldEZlbmNlIENl cnRpZmljYXRlIE1hc3RlcjElMCMGCSqGSIb3DQEJARYWcG9zdG1hc3RlckBuZXRmZW5jZS5p dAIBBDCBqgYLKoZIhvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAklUMRAwDgYDVQQIEwdC b2xvZ25hMRAwDgYDVQQHEwdCb2xvZ25hMREwDwYDVQQKEwhOZXRGZW5jZTEkMCIGA1UEAxMb TmV0RmVuY2UgQ2VydGlmaWNhdGUgTWFzdGVyMSUwIwYJKoZIhvcNAQkBFhZwb3N0bWFzdGVy QG5ldGZlbmNlLml0AgEEMA0GCSqGSIb3DQEBAQUABIGAcxFATotdGXQj6j/sPjSigS4GnkMB 97BRnUtslBCQLXRX2k6MACIfmqFInFIKy5xyFojwqJpS5YYHsAwhTm+Q/zZ8tZNmOlUYmPRL ANyMi6Xs81jwe62a3IFNUBaJ06RKf5JJV2Ru1yoCw0mXeuleGnxeUro/3kwEXNo2cxQjCnMA AAAAAAA= --------------ms000105030507000008060907-- From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 17:35:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FEC416A4CE for ; Thu, 9 Dec 2004 17:35:36 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2A0E43D54 for ; Thu, 9 Dec 2004 17:35:35 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CcSCN-0005d9-00; Thu, 09 Dec 2004 18:35:27 +0100 Received: from [84.128.137.142] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CcSCN-0002rC-00; Thu, 09 Dec 2004 18:35:27 +0100 From: Max Laier To: Jeremie Le Hen Date: Thu, 9 Dec 2004 18:36:11 +0100 User-Agent: KMail/1.7.1 References: <20041207153117.536b9399@daemon.cmotd.com> <20041207154007.61a19f43@daemon.cmotd.com> <20041209171039.GE79919@obiwan.tataz.chchile.org> In-Reply-To: <20041209171039.GE79919@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1451351.44AjVPlyM8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412091836.14223.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: freebsd-net@freebsd.org Subject: Re: UCARP support for FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 17:35:36 -0000 --nextPart1451351.44AjVPlyM8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 09 December 2004 18:10, Jeremie Le Hen wrote: > > I know it, but it is for FreeBSD 5.x . My gateways run FreeBSD 4.10 > > and i don't have plans to upgrade them for now. > > I found on the "pf4freebsd" website [1] that there is an existing patch f= or > DragonFlyBSD which *should* work on 4.x. I know this site has been > deprecated by the new one [2], but the latter does not include this patch. > > Regards, > > [1] http://pf4freebsd.love2party.net/carp.html > [2] http://people.freebsd.org/~mlaier/CARP/ I haven't touched the 4.x/DragonFly patch since then (so it's lagging a lot= of=20 fixes). If somebody wants to take on, I suggest to start anew and use this= =20 only as reference. Somebody on the DragonFly lists also talked about doing= =20 it, but I haven't heard anything since. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1451351.44AjVPlyM8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBuI0OXyyEoT62BG0RAoGMAKCAJY6YjbfFClE4HxBBgpdoYTEg0ACaAihQ VvqPw+W4nV3Tcoxd/OkiozI= =zEFZ -----END PGP SIGNATURE----- --nextPart1451351.44AjVPlyM8-- From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 17:53:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB1AB16A4CE for ; Thu, 9 Dec 2004 17:53:42 +0000 (GMT) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C58B43D58 for ; Thu, 9 Dec 2004 17:53:41 +0000 (GMT) (envelope-from Konstantin.Kabassanov@lip6.fr) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) iB9HrdUk023800 ; Thu, 9 Dec 2004 18:53:39 +0100 X-pt: isis.lip6.fr Received: from gargamel (rp [132.227.74.3]) by tibre.lip6.fr (8.11.6p3/8.11.6) with ESMTP id iB9Hrd601911; Thu, 9 Dec 2004 18:53:39 +0100 (CET) From: "Konstantin KABASSANOV" To: =?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?= Date: Thu, 9 Dec 2004 18:53:37 +0100 MIME-Version: 1.0 Message-ID: <002601c4de18$02b64ea0$8748e384@ipv6.lip6.fr> X-Priority: 3 (Normal) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0022_01C4DE20.62C5B3A0" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.5.10 (isis.lip6.fr [132.227.60.2]); Thu, 09 Dec 2004 18:53:40 +0100 (CET) X-Scanned-By: isis.lip6.fr cc: net@freebsd.org Subject: RE: the correct ipv6 behavior for interfaces with gif tunnel on them X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 17:53:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C4DE20.62C5B3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: JINMEI Tatuya / =90_=96=BE=92B=8D=C6 = [mailto:jinmei@isl.rdc.toshiba.co.jp] >Sent: jeudi 9 d=E9cembre 2004 05:53 >To: Konstantin KABASSANOV >Cc: net@freebsd.org >Subject: Re: the correct ipv6 behavior for interfaces with gif tunnel = on >them > >>>>>> On Wed, 8 Dec 2004 13:22:10 +0100, >>>>>> "Konstantin KABASSANOV" said: > >> I have a freebsd box with a gif tunnel configured. I observed that = even >if >> ifconfig displays MTU 1500 for both gif and physical interface, 1300 >bytes >> ipv6 packets transiting on the gif interface are systematically >fragmented >> while transiting on the lower physical interface to 1280 bytes. Is it the >> normal behavior? > >Please provide more detailed network configuration. Are you talking >about a router box forwarding packets onto gif and physical >interfaces? Well, this is a router box with 2 physical interfaces (say xl0 and rl0). Rl0 has a gif tunnel (gif0) over it. Xl0,rl0 and gif0 announce in their ifconfig an MTU of 1500, but 1300 bytes traffic generated from this box and sent through the gif0 interface is fragmented by the rl0 interface = to 1280 bytes... =20 Please also specify the OS name (which I guess is >FreeBSD) and its version. FreeBSD 4.7 (yes it is a little bit old, but I think the problem still persist in more recent versions)... And that's why I'm asking if this behavior is normal or not... Thanks. Konstantin ------=_NextPart_000_0022_01C4DE20.62C5B3A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILszCCA2Qw ggJMoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwKzELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMx DTALBgNVBAMTBENOUlMwHhcNMDEwNDI3MDU0NDM2WhcNMjEwNDIyMDU0NDM2WjArMQswCQYDVQQG EwJGUjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SUzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAN13q/Hq/Hi1FKHcd2JWl4wvt1TCTFSm1H0iR3t0qffjrXxVshTwSF2YjwK9khG2 iE/EFfVvWFv3ibUn6q+g/KCOiIaPnyS2kE4k3GfQT49+Vi0bKAdysRdnoA7bQk7DfLQloviMBLGp gl2Mj9SDe+6qn9fS2/ZbbsKBENaaq12IHDbKBWRoS4uewFCUI/22KLWvXaTdpsXT2FcrPvi1usTY /xIiXyRpB2LkNEoId8owu+zT7XWQaKKMcXIn3hUmLCUhhCqeVxiBciO9Zh8P47e9F9oSuhlU9Bwt j3FSM7G2KLZ6aMuaTVI4+kiMwUuJlo/GF1vLuQ4OgVwaxzQ5V70CAwEAAaOBkjCBjzAMBgNVHRME BTADAQH/MB0GA1UdDgQWBBRW62i50lx+mLWlU8ORb2NYxPlrtzBTBgNVHSMETDBKgBRW62i50lx+ mLWlU8ORb2NYxPlrt6EvpC0wKzELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxDTALBgNVBAMT BENOUlOCAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4IBAQA418MpvHp3ol4WR0mGXtAZ OGregQgCuaegAqaIuA3iSTXO5qqiNNL5o4Q3mhXpWSu3vcwRrikhj4+ROfqdd+LoOersLtbKSEci TGWx07ZvWBs0LooQnRKEdKR5UlcAUxTImN6BbsULdada59M1CEWI9YRQmPAHPsWGPi4JWqLctqBr ezernwNwbt31nMAOBey1hFsjtIkhEIit+y0I5AATHFWzj3e+IKzcARx5fGcMWl9PuZSJvquaLBKx qGPGYoAD/Uxwlb3G6AXay74Jph/pbdKFLkPTHxpcdv4TdmFg+WTUWHi/f+/lc6ND2ip/d9s0eXLZ juWl7VLQxEZMXxuqMIIDbTCCAlWgAwIBAgIBAjANBgkqhkiG9w0BAQQFADArMQswCQYDVQQGEwJG UjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SUzAeFw0wMTA0MjcwNTQ2NDlaFw0xMTA0MjUw NTQ2NDlaMDQxCzAJBgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRYwFAYDVQQDEw1DTlJTLVN0YW5k YXJkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3OEeIT0Gi+q9XrSI2w+Tl7RtBz2G YgAtyv+1So7nVqSPYSzxoCqr9irdfCy/73VVC6wJTudOYcDnDPCQFUUSAsKM68MSZOJjEBguywcx 2YHl3CmCmzFW4oEeim+n6KlYEURWg12zTnhwLd+2/XKBRdXx7k3O777VPQyQIEWaCYCvD0zaIA6A vzqz6yeAwLkPwKFOQNw6/Woqv0DVLHGA+fi6a+TqKgCrL76a8Kd2bZgpnA8v8ELyGJdbyfbMGV+6 wr4S0lywkJTAt8sGBO+PMO0yLXpK95O7oAmktO4zy9CDm7W1s5DejpAeWZwg1Use7ddMT4b6HDoq oemsBaCdvwIDAQABo4GSMIGPMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFGdZpeUHdEkD7wXPzC6k GNUQyJ48MFMGA1UdIwRMMEqAFFbraLnSXH6YtaVTw5FvY1jE+Wu3oS+kLTArMQswCQYDVQQGEwJG UjENMAsGA1UEChMEQ05SUzENMAsGA1UEAxMEQ05SU4IBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADggEBAAYDR4NyRZDCTuEh16sXqQFVBspAbVWiHV7r4hQjWeQJ4pD2PI02Bg9LpyYjZcLq Bppyu7iMy4pf73k2JX4A1/MGlPuDRCkmN8fu6YfObIaAG3E90mKv9s1ibFMP5nqTAIx7LjPgQR2q vmWYdvGVB3Sz5j9TddVLBjZLKcT23I4TgEAQc4KtFXsEcVC1NzPyyGS7oRB+Nsatr29wUqbRrszM urDoWRKPYg2tA91LKuiJOYhRL+1h6Lcwh9snVW1mh6NRCYBhcVEFvhMd2UEw/HVfCpabGP++kIG0 E8ByEQj9appqB730gyy0YDZkB/o9aqewkAR2g90zyzTiF5gEC6EwggTWMIIDvqADAgECAgILQTAN BgkqhkiG9w0BAQQFADA0MQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzEWMBQGA1UEAxMNQ05S Uy1TdGFuZGFyZDAeFw0wNDAxMDUxMjE4MzFaFw0wNTAxMDUxMjE4MzFaMHwxCzAJBgNVBAYTAkZS MQ0wCwYDVQQKEwRDTlJTMRAwDgYDVQQLEwdVTVI3NjA2MR4wHAYDVQQDExVLb25zdGFudGluIEth YmFzc2Fub3YxLDAqBgkqhkiG9w0BCQEWHUtvbnN0YW50aW4uS2FiYXNzYW5vdkBsaXA2LmZyMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMyNgVgMXjrGwkogB8dH3FSBbwkqD6t1XmVV 55yDfdmf+YGsujHf1LYvF6fRCvgm81JufqeyLc3LSlgglXl5QeUOW37Ospp/iAdIh/ZURZiWA1RX imvqo9iTUvx2zUTwqIP8dRJye5bgYGBEJRCmE0TYMwSkmHSmTERpvoDNBNCFVGOrsZTOPYXtNsKf iAfNi7pFdfxE9Ij6/gQNM/0Q3RNiiXmO5IkHAlxgwwqHABx1Ld169HlSfoKAeq6KTsOECkOxAijj mQtgJs/eE5MtMST9IfqQkmhpt7intE2k2TrZ1tEo92pErYkNrNKhYqdM2/jMeGJsdvnlgUsa1HiI mQIDAQABo4IBqDCCAaQwDAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCBLAwDgYDVR0PAQH/ BAQDAgXgMHgGCWCGSAGG+EIBDQRrFmlDZXJ0aWZpY2F0IENOUlMtU3RhbmRhcmQuIFBvdXIgdG91 dGUgaW5mb3JtYXRpb24gc2UgcmVwb3J0ZXIg4CBodHRwOi8vaWdjLnNlcnZpY2VzLmNucnMuZnIv Q05SUy1TdGFuZGFyZC8wHQYDVR0OBBYEFBw5elbdCpZR0WnR27EsQjmRr3/EMFMGA1UdIwRMMEqA FGdZpeUHdEkD7wXPzC6kGNUQyJ48oS+kLTArMQswCQYDVQQGEwJGUjENMAsGA1UEChMEQ05SUzEN MAsGA1UEAxMEQ05SU4IBAjAoBgNVHREEITAfgR1Lb25zdGFudGluLkthYmFzc2Fub3ZAbGlwNi5m cjBZBgNVHR8EUjBQME6gTKBKhkhodHRwOi8vaWdjLnNlcnZpY2VzLmNucnMuZnIvY2dpLWJpbi9s b2FkLmNybD9DQT1DTlJTLVN0YW5kYXJkJmZvcm1hdD1ERVIwDQYJKoZIhvcNAQEEBQADggEBAD8m erny2WgvzJkuFcYNqqWA9g/7n1qF32uEgzbb+/lDejf7URAuuZqAeMxzF4uvRgDc8pr3EowjoKuD 5OsPdKboekM7B3Kn5J9IoF/Zq9FIw4A63k+KczTMlmFZXbvqBKHVLmG+Y8/FoEcC3xbYFDvKLP/q OOdXgcDOe60b4886fMFDUSOODryacoDAhCNWzuS6+v9JvZ5vFvR0hbkzGuzn/5ZR1H97BirD6ZlS f/bo3awEbsWEXcdj/tltVvc6kW61l1PieIyTd1RPtU99uhpmcUDtT7v5+Y7tjtvemfONmHHa2Jmp fohq8/1IFkhv0r3xHU0xROff+4sQrt3KjLgxggLDMIICvwIBATA6MDQxCzAJBgNVBAYTAkZSMQ0w CwYDVQQKEwRDTlJTMRYwFAYDVQQDEw1DTlJTLVN0YW5kYXJkAgILQTAJBgUrDgMCGgUAoIIBXjAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEyMDkxNzUzMzVaMCMG CSqGSIb3DQEJBDEWBBRwvd11e06A/JEowNn7dxBB4rbh0zBJBgkrBgEEAYI3EAQxPDA6MDQxCzAJ BgNVBAYTAkZSMQ0wCwYDVQQKEwRDTlJTMRYwFAYDVQQDEw1DTlJTLVN0YW5kYXJkAgILQTBLBgsq hkiG9w0BCRACCzE8oDowNDELMAkGA1UEBhMCRlIxDTALBgNVBAoTBENOUlMxFjAUBgNVBAMTDUNO UlMtU3RhbmRhcmQCAgtBMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAI3nWIGu8EnJjRRUclNJnhVGdeHL/lbpGFN9bWK82tJD k5m4ZUwmAvWQLvnmUabXqpJo1khCS5nxlcO4KYu6Al9iW4J/+88qjgkel22fJsYu5aDcJBXH5AUn kL4E9lQzDH2iRjiafScpeKNbeR5W9bu5EiS0oVLFusvDETjGc7FiSVMGfpsGQfrHRH2D5IdcVb4E MT1mTXqBIf084FFWZcLha+W5kNAjRNOgUbeRBuPmiDk/CWbPDYD00p8KFyoJH6hKcc368yUZNLOk 8iLp6uL7FW0rpdj1joBzPiMtasaf2cecNhNEfSGSHz0ueVkVa3GvXkF8CrjA/+JCy3hMtuIAAAAA AAA= ------=_NextPart_000_0022_01C4DE20.62C5B3A0-- From owner-freebsd-net@FreeBSD.ORG Thu Dec 9 22:13:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F49F16A4CE for ; Thu, 9 Dec 2004 22:13:38 +0000 (GMT) Received: from linares.terra.com.br (linares.terra.com.br [200.154.55.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id E611843D53 for ; Thu, 9 Dec 2004 22:13:37 +0000 (GMT) (envelope-from freezumba@terra.com.br) Received: from merida.terra.com.br (merida.terra.com.br [200.154.55.132]) by linares.terra.com.br (Postfix) with ESMTP id BED5FDDCBD0 for ; Thu, 9 Dec 2004 20:13:36 -0200 (BRST) X-Terra-Karma: -2% X-Terra-Hash: ee8f81b51f01a629f721df8167cc8804 Received: from 200-193-149-118.ctame7014.dsl.brasiltelecom.net.br (200-193-149-118.ctame7014.dsl.brasiltelecom.net.br [200.193.149.118]) (authenticated user freezumba@terra.com.br) by merida.terra.com.br (Postfix) with ESMTP id 858C83C041 for ; Thu, 9 Dec 2004 20:13:36 -0200 (BRST) From: "Paulo Fonseca Jr." To: freebsd-net@freebsd.org Date: Thu, 9 Dec 2004 20:13:26 -0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200412092013.26958.freezumba@terra.com.br> Subject: dhcpd error - IF host.myisp.com.br IN A rrset doesn't exist add: timed out X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2004 22:13:38 -0000 Hi, I'm receiving the folowing error when a windows machine to try a connection= =20 with internet through freebsd adsl (ppp) gateway: "IF windows.myisp.com.br = IN=20 A rrset doesn't exist add windows.myisp.com.br 300 IN A 192.168.0.3: timed= =20 out." I'm not running a dns server on freebsd gateway. I'm using a dns serv= er=20 from my ISP. My dhcpd.conf: =A0option domain-name "myisp.com.br"; =A0option domain-name-servers 200.215.1.3; =A0ddns-update-style ad-hoc; =A0log-facility daemon;=20 =A0option routers 192.168.0.1; =A0subnet 192.168.0.0 netmask 255.255.255.0 { =A0 range 192.168.0.2 192.168.0.254 =A0} In my rc.conf: =A0... =A0ifconfig_xl0=3D"inet 192.168.0.1 netmask 255.255.255.0" =A0dhcp_options=3D"xl0" =A0dhcpd_enable=3D"yes" =A0... Anybody can help me! thanks! Zumba. From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 00:48:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14A4516A4CF for ; Fri, 10 Dec 2004 00:48:25 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3857443D46 for ; Fri, 10 Dec 2004 00:48:24 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 90224 invoked from network); 10 Dec 2004 00:38:05 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Dec 2004 00:38:05 -0000 Message-ID: <41B8F259.641FF6E7@freebsd.org> Date: Fri, 10 Dec 2004 01:48:25 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce M Simpson References: <41B714DA.6090505@traveller.cz> <41B71553.278B66A4@freebsd.org> <20041209022107.GB691@empiric.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Michal Mertl cc: Robert Watson Subject: Re: New ICMP limits X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 00:48:25 -0000 Bruce M Simpson wrote: > > On Wed, Dec 08, 2004 at 03:53:07PM +0100, Andre Oppermann wrote: > > I'll take care of this but I'm busy right now. Look into it later this week. > > Thanks for looking into this, this is one of the items which came up on > the TODO lists of three separate projects (TowardEX's, XORP's, and the > Network Junta's). If you aren't able to look at it let us know so someone > else can step up to the mic. > > Of course, the sooner we can remove ARP's special meaning from RTF_REJECT, > the better - that would let us implement RTF_REJECT in the fastforwarding > path without further worry. This is different animal. Qing Li is on that one. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 02:50:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C4AF16A4D0 for ; Fri, 10 Dec 2004 02:50:30 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id E302043D69 for ; Fri, 10 Dec 2004 02:50:29 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:5c31:4b60:a406:2638]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B13B915210; Fri, 10 Dec 2004 11:50:28 +0900 (JST) Date: Fri, 10 Dec 2004 11:50:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Konstantin KABASSANOV" In-Reply-To: <002601c4de18$02b64ea0$8748e384@ipv6.lip6.fr> References: <002601c4de18$02b64ea0$8748e384@ipv6.lip6.fr> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: the correct ipv6 behavior for interfaces with gif tunnel on them X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 02:50:30 -0000 >>>>> On Thu, 9 Dec 2004 18:53:37 +0100, >>>>> "Konstantin KABASSANOV" said: >> Please provide more detailed network configuration. Are you talking >> about a router box forwarding packets onto gif and physical >> interfaces? > Well, this is a router box with 2 physical interfaces (say xl0 and rl0). > Rl0 has a gif tunnel (gif0) over it. Xl0,rl0 and gif0 announce in their > ifconfig an MTU of 1500, but 1300 bytes traffic generated from this box > and sent through the gif0 interface is fragmented by the rl0 interface to > 1280 bytes... > Please also specify the OS name (which I guess is >> FreeBSD) and its version. > FreeBSD 4.7 (yes it is a little bit old, but I think the problem still > persist in more recent versions)... And that's why I'm asking if this > behavior is normal or not... This is not the intended behavior, and seems to be fixed at least on FreeBSD 5.3. I don't know whether the change is merged into 4.x. At least it's not the case with FreeBSD 4.10. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 03:35:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B92D116A4CE for ; Fri, 10 Dec 2004 03:35:52 +0000 (GMT) Received: from webmail-outgoing.us4.outblaze.com (webmail-outgoing.us4.outblaze.com [205.158.62.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ED6043D5E for ; Fri, 10 Dec 2004 03:35:52 +0000 (GMT) (envelope-from ksaraf@linuxmail.org) Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180])129BE18002AF for ; Fri, 10 Dec 2004 03:35:52 +0000 (GMT) X-OB-Received: from unknown (205.158.62.148) by wfilter.us4.outblaze.com; 10 Dec 2004 03:35:51 -0000 Received: by ws5-6.us4.outblaze.com (Postfix, from userid 1001) id BB05821AFF9; Fri, 10 Dec 2004 03:35:51 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [69.233.160.201] by ws5-6.us4.outblaze.com with http for ksaraf@linuxmail.org; Fri, 10 Dec 2004 11:35:51 +0800 From: "K sarraf" To: freebsd-net@freebsd.org Date: Fri, 10 Dec 2004 11:35:51 +0800 X-Originating-Ip: 69.233.160.201 X-Originating-Server: ws5-6.us4.outblaze.com Message-Id: <20041210033551.BB05821AFF9@ws5-6.us4.outblaze.com> cc: rnorman@ikaika.com Subject: Problem with Interface Link Down Detection in Routing Deamon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 03:35:52 -0000 Hi All, I need to solve a problem with link-fail detect signal getting up to the ro= uting deamon on my FreeBSD 4.10 systems. The problem is as follows: This is a question regarding backup routes in zebra/quagga running OSPFv2. Say I have edge router A and edge router B connected via two parallel paths= . Each path has several intermediate routers with different number of hops= . In the normal condition, after route convergence the path with the small= est number of hops will be chosen as the best path. See figure below A | +--+--+ | | Path 1 path 2 | | +--+--+ | B Now if a link in path 1 breaks, path 2 should be immediately chosen since i= t is a backup route. In IP infusions ZebOS implementation, if I unplug a link in path 1, it will= instantly switch over to path 2 without skipping a beat. In Quagga, it will take up to 10 seconds before it discovers that path 1 is= no longer available, and I lose data for 10 seconds until the paths reconv= erge. I'm using hello interval 2 sec and router dead interval of 5 sec. Not a good problem to have=85 So I think there is a flag that needs to be passed up from the Network Driv= ers up to the deamon. Is there a specific signal the Quagga routing deamon= needs to listen for. BTW Quagga has a lot in common with former Zebra rou= ting code. I already tried the Quagga mailing list and didn=92t get an ans= wer.=20=20 My quagga configuration follows if anyone is interested. I already use the flag =93link-detect=94 in the Quagga/Zebra config file. thanks in advance. =3D=3D=3D=3D=3Dzebra.conf=3D=3D=3D=3D=3D=3D ! hostname Router password zebra enable password zebra log file /tmp/quagga.log ! interface lo0 ! interface lo1 ! interface lp0 ! interface sl0 ! interface gif0 link-detect !ipv6 nd suppress-ra ! interface gif1 link-detect !ipv6 nd suppress-ra ! interface gif2 link-detect !ipv6 nd suppress-ra ! interface gif3 link-detect !ipv6 nd suppress-ra ! interface gif4 link-detect !ipv6 nd suppress-ra ! interface gif5 link-detect !ipv6 nd suppress-ra ! interface fxp0 link-detect ! interface ppp0 ! interface faith0 ! ! ip route 224.0.0.5/32 127.0.0.1 ip route 224.0.0.6/32 127.0.0.1 ! =3D=3D=3D=3Dospfd.conf=3D=3D=3D=3D ! Zebra configuration saved from vty ! hostname ospfd password zebra !log stdout ! debug ospf zebra debug ospf event ! ! interface gif0 ip ospf network point-to-point ip ospf dead-interval 5 ip ospf hello-interval 2 ! interface gif1 ip ospf network point-to-point ip ospf dead-interval 5 ip ospf hello-interval 2 ! interface gif2 ip ospf network point-to-point ip ospf dead-interval 5 ip ospf hello-interval 2 ! interface gif3 ip ospf network point-to-point ip ospf dead-interval 5 ip ospf hello-interval 2 ! interface gif4 ip ospf network point-to-point ip ospf dead-interval 5 ip ospf hello-interval 2 ! interface gif5 ip ospf network point-to-point ip ospf dead-interval 5 ip ospf hello-interval 2 ! interface fxp0 description Physical Ethernet Interface=20 ! ! router ospf compatible rfc1583 ! timers spf 2 2 passive-interface fxp0 network 0.0.0.0/0 area 0 ! network 10.77.0.0/16 area 0 ! redistribute static redistribute kernel redistribute connected ! !access-list filter deny 10.0.0.0/24 ! line vty ! log file /tmp/ospfd.log =20 =3D=3D=3D=3Dospf6d.conf=3D=3D=3D=3D=3D ! Zebra configuration saved from vty ! hostname ospfd password zebra log file /tmp/ospf6d.log log stdout ! debug ospf6 message dbdesc debug ospf6 message lsreq debug ospf6 message lsupdate debug ospf6 message lsack debug ospf6 neighbor debug ospf6 interface debug ospf6 lsa debug ospf6 zebra debug ospf6 config debug ospf6 dbex debug ospf6 spf debug ospf6 route debug ospf6 area ! interface fxp0 ipv6 ospf6 passive ! interface gif0 ipv6 ospf6 hello-interval 2 ipv6 ospf6 dead-interval 5 ! interface gif1 ipv6 ospf6 hello-interval 2 ipv6 ospf6 dead-interval 5 ! interface gif2 ipv6 ospf6 hello-interval 2 ipv6 ospf6 dead-interval 5 ! interface gif3 ipv6 ospf6 hello-interval 2 ipv6 ospf6 dead-interval 5 ! interface gif4 ipv6 ospf6 hello-interval 2 ipv6 ospf6 dead-interval 5 ! interface gif5 ipv6 ospf6 hello-interval 2 ipv6 ospf6 dead-interval 5 ! ! router ospf6 router-id 0.0.0.1 redistribute connected redistribute static interface gif0 area 0.0.0.0 interface gif1 area 0.0.0.0 interface gif2 area 0.0.0.0 interface gif3 area 0.0.0.0 interface gif4 area 0.0.0.0 interface gif5 area 0.0.0.0 interface fxp0 area 0.0.0.0 ! line vty ! --=20 ______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org=20 This allows you to send and receive SMS through your mailbox. Powered by Outblaze From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 04:15:10 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AB3C16A4CE for ; Fri, 10 Dec 2004 04:15:10 +0000 (GMT) Received: from ns.yar.post.ru (ns.yar.post.ru [213.187.102.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0FC343D1F for ; Fri, 10 Dec 2004 04:15:08 +0000 (GMT) (envelope-from liettneff@bk.ru) Received: from gate-corbina.km.vibrators.ru (km.yar.post.ru [213.187.105.186]) by ns.yar.post.ru (8.12.9p2/8.12.9) with ESMTP id iBA4F6ql097727 for ; Fri, 10 Dec 2004 07:15:07 +0300 (MSK) (envelope-from liettneff@bk.ru) Received: from comp-reaper ([192.168.1.100])iBA4ExYe070391 for ; Fri, 10 Dec 2004 07:15:00 +0300 (MSK) (envelope-from liettneff@bk.ru) Date: Fri, 10 Dec 2004 07:14:59 +0300 From: Michael Lednev X-Mailer: The Bat! (v2.01) Business Organization: none X-Priority: 3 (Normal) Message-ID: <196116794593.20041210071459@bk.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: KAME mip6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: liettneff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 04:15:10 -0000 Hello, freebsd-net. is there any chance, that kame mip6 stack will work with freebsd-5.3 out of the box soon? -- Regards, Michael mailto:liettneff@bk.ru From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 05:39:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52E8916A4CE for ; Fri, 10 Dec 2004 05:39:54 +0000 (GMT) Received: from smtp2.cistron.nl (smtp2.cistron.nl [62.216.30.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id D801943D3F for ; Fri, 10 Dec 2004 05:39:53 +0000 (GMT) (envelope-from robert@guldan.demon.nl) Received: from cust.13.38.adsl.cistron.nl ([62.216.13.38] helo=guldan.demon.nl) by smtp2.cistron.nl with esmtp (Exim 3.35 #1 (Debian)) id 1CcdVM-0008Eb-00; Fri, 10 Dec 2004 06:39:48 +0100 Received: from bombur.guldan.demon.nl ([192.168.201.3] helo=localhost) by guldan.demon.nl with esmtp (Exim 4.24; FreeBSD) id 1CcdVI-0004pz-VH; Fri, 10 Dec 2004 06:39:44 +0100 Date: Fri, 10 Dec 2004 06:39:44 +0100 From: Robert Blacquiere To: "Paulo Fonseca Jr." Message-ID: <20041210053944.GE36602@bombur.guldan.demon.nl> References: <200412092013.26958.freezumba@terra.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412092013.26958.freezumba@terra.com.br> User-Agent: Mutt/1.4.1i X-Disclaimer: running FreeBSD X-Spam-Score: 0.0 (/) cc: freebsd-net@freebsd.org Subject: Re: dhcpd error - IF host.myisp.com.br IN A rrset doesn't exist add: timed out X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 05:39:54 -0000 On Thu, Dec 09, 2004 at 08:13:26PM -0200, Paulo Fonseca Jr. wrote: > Hi, > > I'm receiving the folowing error when a windows machine to try a connection > with internet through freebsd adsl (ppp) gateway: "IF windows.myisp.com.br IN > A rrset doesn't exist add windows.myisp.com.br 300 IN A 192.168.0.3: timed > out." I'm not running a dns server on freebsd gateway. I'm using a dns server > from my ISP. > > My dhcpd.conf: > ?option domain-name "myisp.com.br"; > ?option domain-name-servers 200.215.1.3; > ?ddns-update-style ad-hoc; ddns-update-style should be none. It tries now to update the dns server from your provider with data provided from de dhcp request in this case a machine with the name windows. Your provider does not permit dns updates from your dhcp server. > ?log-facility daemon; > ?option routers 192.168.0.1; > ?subnet 192.168.0.0 netmask 255.255.255.0 { > ? range 192.168.0.2 192.168.0.254 > ?} > > In my rc.conf: > ?... > ?ifconfig_xl0="inet 192.168.0.1 netmask 255.255.255.0" > ?dhcp_options="xl0" > ?dhcpd_enable="yes" > ?... > > Anybody can help me! > > thanks! > Zumba. > > _______________________________________________ > 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" -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: Hey guys you left some holes out there! From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 06:45:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74B5516A4CE; Fri, 10 Dec 2004 06:45:56 +0000 (GMT) Received: from poison2.syncrontech.com (adsl-nat.syncrontech.com [213.28.98.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F4B243D1D; Fri, 10 Dec 2004 06:45:54 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57])iBA6jk86064974; Fri, 10 Dec 2004 08:45:46 +0200 (EET) (envelope-from ari@suutari.iki.fi) Received: from coffee (coffee.syncrontech.com [62.71.8.37]) iBA6jep5021601; Fri, 10 Dec 2004 08:45:45 +0200 (EET) (envelope-from ari@suutari.iki.fi) Message-ID: <08f001c4de83$dfbb1b80$2508473e@sad.syncrontech.com> From: "Ari Suutari" To: "Bjoern A. Zeeb" , "Andre Oppermann" References: <20041129100949.GA19560@bps.jodocus.org><41AAF696.6ED81FBF@freebsd.org><41AB3A74.8C05601D@freebsd.org><41AB65B2.A18534BF@freebsd.org><41B85729.40F00890@freebsd.org> Date: Fri, 10 Dec 2004 08:45:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order foroutgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 06:45:56 -0000 Hi, >> With the changes you can chose whether you want to do firewallig before >> ipsec processing or after but not both. > > I am unsure if I get that right but that's what the ipsec flag in > ipfw2 is for and it is heavily used to filter ipsec encrypted traffic > and the same traffic, tagged to come from an ipsec tunnel, afterwards. > > If your changes won't handle this you will break too many IPSec GWs I > think. > At least I do filtering both before and after ipsec. Typical case is that before ipsec I allow only esp from peer's ipsec box, after ipsec I allow some tcp ports if (and only if) the packet has originated from ipsec (I use ipsec flag). So being able to filter traffic both before and after is necessary, it is very well possible right now, if one uses IPSEC_FILTERGIF kernel option and ipfw "ipsec" flag. Please don't break this, it has been broken more or less in various releases (or at least there have been differences how firewalling works with ipsec stuff). However, feel free to fix the remaining problems for *outgoing* traffic. Ari S. From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 11:01:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2130516A4CE for ; Fri, 10 Dec 2004 11:01:19 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id B450543D3F for ; Fri, 10 Dec 2004 11:01:17 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id iBAB1B3g034372; Fri, 10 Dec 2004 14:01:11 +0300 (MSK) (envelope-from is@rambler-co.ru) Date: Fri, 10 Dec 2004 14:01:11 +0300 (MSK) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: Kevin Day In-Reply-To: <12FC45EB-4950-11D9-81D0-000A95A8A1F2@dragondata.com> Message-ID: <20041210140020.E51581@is.park.rambler.ru> References: <12FC45EB-4950-11D9-81D0-000A95A8A1F2@dragondata.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Very strange kevent problem possibly to do with vinum X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 11:01:19 -0000 On Wed, 8 Dec 2004, Kevin Day wrote: > I have a really really strange kevent problem(i think anyway) that has > really stumped me. > > Here's the scenario: > > Three mostly identical servers running 5.2.1 or 5.3 (problem exists on > both). All three running thttpd sending out large files to thousands of > clients. Thttpd internally uses kqueue/kevent and sendfile to send > files rather quickly. > > All three have the same configuration, are getting approximately the > same numbers of requests, and are sending approximately the same files. > (I can swap IP addresses between the servers to confirm that the > request distribution stays the same between the servers) > > Server #3 is able to send 400mbps or more of traffic through without > breaking a sweat. Thttpd is either in "RUN", "biord" "sfbufa" or > "*Giant" when I watch it in top, and I still have 80-90% idle time. > > Servers #1 and #2 seem to top out around 80mbps, and are constantly in > "RUN" or "CPUx" states. I don't get any errors anywhere, but they just > aren't capable of going any faster. > > Looking at ktrace on thttpd on all three servers, I see that server 3 > calls kevent, and gets 20-100 sockets in response back, that each get > serviced. Servers 1 and 2 never seem to get more than 1 socket back > from kevent. Even if the event is just that the socket was > disconnected, nothing needs to be done on it, and kevent can be called > again immediately, there's only 1 socket returned next time. I ran > ktrace on thttpd for more than 15 minutes and produced a humongous > ktrace file, and there were only a handful of times that kevent > returned more than one socket with something to do on it. Contrasting > that to server 3, where i never saw kevent returning less than a half > dozen sockets at a time when it had a few hundred mbps flowing through > it. > > The ONLY difference between servers 1 and 2 and server 3 is the disk > subsystem. Servers 1/2 use an "ahc" SCSI controller and vinum RAID5. > Server 3 uses an "aac" hardware RAID. However, disk activity is really > truly minimal on all of these servers. Most of the data remains cached, > since 99% of the requests are for the same handful of files. > systat/vmstat shows that the disks are busy less than 10% of the time, > and artificially creating a bunch of disk load on any of the servers > doesn't seem to affect anything. > > I'm not sure if the kevent difference is the cause of the problem > (thttpd doesn't seem to handle going through its event loop over and > over again for just one socket at a time, it makes some rather > expensive syscalls from that loop), or if it's just a symptom. Is > something in vinum possibly waking my process up somewhat prematurely? > Is that even possible if the files are being sent through sendfile? What does "systat -vm" show on these machines ? Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 11:05:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF63F16A4CE for ; Fri, 10 Dec 2004 11:05:40 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFD8343D1D for ; Fri, 10 Dec 2004 11:05:39 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 93764 invoked from network); 10 Dec 2004 10:55:16 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Dec 2004 10:55:16 -0000 Message-ID: <41B98307.50D01EDB@freebsd.org> Date: Fri, 10 Dec 2004 12:05:43 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ari Suutari References: <20041129100949.GA19560@bps.jodocus.org><41AAF696.6ED81FBF@freebsd.org><41AB3A74.8C05601D@freebsd.org><41AB65B2.A18534BF@freebsd.org><41B85729.40F00890@freebsd.org> <08f001c4de83$dfbb1b80$2508473e@sad.syncrontech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: "Bjoern A. Zeeb" cc: freebsd-net@freebsd.org Subject: Re: (review request) ipfw and ipsec processing order foroutgoingpackets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 11:05:40 -0000 Ari Suutari wrote: > > Hi, > >> With the changes you can chose whether you want to do firewallig before > >> ipsec processing or after but not both. > > > > I am unsure if I get that right but that's what the ipsec flag in > > ipfw2 is for and it is heavily used to filter ipsec encrypted traffic > > and the same traffic, tagged to come from an ipsec tunnel, afterwards. > > > > If your changes won't handle this you will break too many IPSec GWs I > > think. > > > > At least I do filtering both before and after ipsec. Typical case > is that before ipsec I allow only esp from peer's ipsec box, after > ipsec I allow some tcp ports if (and only if) the packet has > originated from ipsec (I use ipsec flag). > > So being able to filter traffic both before and after is necessary, > it is very well possible right now, if one uses IPSEC_FILTERGIF > kernel option and ipfw "ipsec" flag. Please don't break this, it has > been broken > more or less in various releases (or at least there have been > differences how firewalling works with ipsec stuff). > > However, feel free to fix the remaining problems for *outgoing* > traffic. All I intend to provide is a way to specify whether you want IPSEC before or after pfil_hooks. By default it will be as it is today and work exactly the same. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 14:16:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD52116A4CE for ; Fri, 10 Dec 2004 14:16:30 +0000 (GMT) Received: from mail.dragondata.com (server3-a.your.org [64.202.112.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08D5743D4C for ; Fri, 10 Dec 2004 14:16:30 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from localhost (localhost.your.org [127.0.0.1]) by mail.dragondata.com (Postfix) with ESMTP id 7632A3D194F; Fri, 10 Dec 2004 08:16:29 -0600 (CST) Received: from mail.dragondata.com ([127.0.0.1]) by localhost (server3.dragondata.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 45639-01; Fri, 10 Dec 2004 08:16:29 -0600 (CST) Received: by mail.dragondata.com (Postfix, from userid 1000) id 162FD3D18F0; Fri, 10 Dec 2004 08:16:29 -0600 (CST) Received: from [69.31.99.45] (pool045.dhcp.your.org [69.31.99.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.dragondata.com (Postfix) with ESMTP id 742363D1850; Fri, 10 Dec 2004 08:16:27 -0600 (CST) In-Reply-To: <20041210140020.E51581@is.park.rambler.ru> References: <12FC45EB-4950-11D9-81D0-000A95A8A1F2@dragondata.com> <20041210140020.E51581@is.park.rambler.ru> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <25799D48-4AB6-11D9-81D0-000A95A8A1F2@dragondata.com> From: Kevin Day Date: Fri, 10 Dec 2004 08:16:55 -0600 To: Igor Sysoev X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server3.dragondata.com X-Spam-Level: X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.63 languages= bayes=0.5 X-Virus-Scanned: by amavisd-new at dragondata.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org Subject: Re: Very strange kevent problem possibly to do with vinum X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 14:16:31 -0000 On Dec 10, 2004, at 5:01 AM, Igor Sysoev wrote: > On Wed, 8 Dec 2004, Kevin Day wrote: > >> I have a really really strange kevent problem(i think anyway) that has >> really stumped me. > > What does "systat -vm" show on these machines ? > > From one of the servers that is having problems: 1 users Load 0.35 0.22 0.18 Dec 10 08:12 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 25908 2528 95248 4180 75624 count All 2045316 4704 1717416 7796 pages 320 zfod Interrupts Proc:r p d s w Csw Trp Sys Int Sof Flt cow 4672 total 1 75 12864 76812224 8384 192 448 150848 wire 1: atkb 32104 act 6: fdc0 50.0%Sys 0.0%Intr 0.0%User 0.0%Nice 50.0%Idl 1792248 inact 128 8: rtc | | | | | | | | | | 72628 cache 13: npx ========================= 2996 free 14: ata daefr 2816 28: bge Namei Name-cache Dir-cache prcfr 1600 29: bge Calls hits % hits % react 30: ahc 52 52 100 pdwak 31: ahc pdpgs 128 0: clk Disks da0 da1 da2 da3 da4 pass0 pass1 intrn KB/t 0.00 0.00 0.00 0.00 0.00 0.00 0.00 93456 buf tps 0 0 0 0 0 0 0 7 dirtybuf MB/s 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100000 desiredvnodes % busy 0 0 0 0 0 0 0 90243 numvnodes 79704 freevnodes (currently sending around 80mbps) From one that is working correctly: 1 users Load 0.50 0.60 0.65 Dec 10 08:08 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 38132 2628 66944 4364 92244 count All 2047208 3628 3255500 6044 pages Interrupts Proc:r p d s w Csw Trp Sys Int Sof Flt cow 8414 total 1 24 39782 2 115720205 183 291140 wire 6: fdc0 53080 act 128 8: rtc 4.0%Sys 9.3%Intr 0.3%User 0.0%Nice 86.4%Idl 1614860 inact 13: npx | | | | | | | | | | 89248 cache stray 1 ==+++++ 2996 free 14: ata daefr 2083 28: bge Namei Name-cache Dir-cache prcfr 6064 29: bge Calls hits % hits % react 39 30: aac 186 186 100 pdwak 100 0: clk zfod pdpgs Disks aacd0 fd0 ofod intrn KB/t 84.31 0.00 %slo-z 114464 buf tps 28 0 578 tfree 18 dirtybuf MB/s 2.31 0.00 134371 desiredvnodes % busy 22 0 98167 numvnodes 86885 freevnodes (currently sending around 250mbps) A ktrace example of what I'm talking about with kevent on one of the slow servers: 468 thttpd 0.000015 CALL kevent(0x4,0x8090000,0,0x80fd000,0x2b57,0xbfbfe898) 468 thttpd 0.000160 RET kevent 1 468 thttpd 0.000037 CALL gettimeofday(0xbfbfe914,0) 468 thttpd 0.000025 RET gettimeofday 0 468 thttpd 0.000023 CALL sendfile(0x52,0x13a,0x9df1000,0,0x2011c38,0,0xbfbfe878,0) 468 thttpd 0.000057 RET sendfile -1 errno 35 Resource temporarily unavailable 468 thttpd 0.000015 CALL kevent(0x4,0x8090000,0,0x80fd000,0x2b57,0xbfbfe898) 468 thttpd 0.000183 RET kevent 1 468 thttpd 0.000031 CALL gettimeofday(0xbfbfe914,0) 468 thttpd 0.000020 RET gettimeofday 0 468 thttpd 0.000035 CALL sendfile(0xcb,0x6b,0xd9f000,0,0x28ae934,0,0xbfbfe878,0) 468 thttpd 0.000058 RET sendfile -1 errno 35 Resource temporarily unavailable 468 thttpd 0.000018 CALL kevent(0x4,0x8090000,0,0x80fd000,0x2b57,0xbfbfe898) 468 thttpd 0.000563 RET kevent 1 468 thttpd 0.000036 CALL gettimeofday(0xbfbfe914,0) 468 thttpd 0.000018 RET gettimeofday 0 468 thttpd 0.000009 CALL sendfile(0x52,0x13a,0x9df2000,0,0x2010c38,0,0xbfbfe878,0) 468 thttpd 0.000088 RET sendfile -1 errno 35 Resource temporarily unavailable 468 thttpd 0.000012 CALL kevent(0x4,0x8090000,0,0x80fd000,0x2b57,0xbfbfe898) 468 thttpd 0.000018 RET kevent 1 468 thttpd 0.000020 CALL gettimeofday(0xbfbfe914,0) 468 thttpd 0.000015 RET gettimeofday 0 468 thttpd 0.000034 CALL sendfile(0x52,0x13a,0x9df4000,0,0x200ec38,0,0xbfbfe878,0) 468 thttpd 0.000056 RET sendfile -1 errno 35 Resource temporarily unavailable 468 thttpd 0.000016 CALL kevent(0x4,0x8090000,0,0x80fd000,0x2b57,0xbfbfe898) 468 thttpd 0.001385 RET kevent 1 468 thttpd 0.000041 CALL gettimeofday(0xbfbfe914,0) 468 thttpd 0.000024 RET gettimeofday 0 468 thttpd 0.000024 CALL sendfile(0x113,0x139,0x87df000,0,0x7208034,0,0xbfbfe878,0) 468 thttpd 0.000055 RET sendfile -1 errno 35 Resource temporarily unavailable 468 thttpd 0.000017 CALL kevent(0x4,0x8090000,0,0x80fd000,0x2b57,0xbfbfe898) 468 thttpd 0.004689 RET kevent 1 468 thttpd 0.000033 CALL gettimeofday(0xbfbfe914,0) 468 thttpd 0.000025 RET gettimeofday 0 468 thttpd 0.000024 CALL sendfile(0x64,0x97,0x1e000,0,0x2e6d96,0,0xbfbfe878,0) 468 thttpd 0.000025 RET sendfile -1 errno 35 Resource temporarily unavailable Here's a ktrace on the fast server: 91919 thttpd 0.000022 CALL kevent(0x4,0x80f7000,0x6,0x8377000,0x10000,0xbfbfe658) 91919 thttpd 0.000668 RET kevent 1241/0x4d9 91919 thttpd 0.000035 CALL gettimeofday(0xbfbfe6d4,0) 91919 thttpd 0.000008 RET gettimeofday 0 91919 thttpd 0.000008 CALL sendfile(0x128,0x807,0xb5a1000,0,0x13254a,0,0xbfbfe638,0) 91919 thttpd 0.000300 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000013 CALL sendfile(0x128,0x721,0xb2a6000,0,0x42d54a,0,0xbfbfe638,0) 91919 thttpd 0.000229 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000011 CALL sendfile(0x128,0x210,0xa978000,0,0xd5b54a,0,0xbfbfe638,0) 91919 thttpd 0.000276 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000023 CALL sendfile(0x128,0x773,0xa781000,0,0xf5254a,0,0xbfbfe638,0) 91919 thttpd 0.000241 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000058 CALL sendfile(0x33,0x4ec,0xa30a000,0,0x3b3dca,0,0xbfbfe638,0) 91919 thttpd 0.000285 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000014 CALL sendfile(0x1f3,0x3c3,0xb5a5000,0,0x148efc0,0,0xbfbfe638,0) 91919 thttpd 0.000274 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000019 CALL sendfile(0x3e4,0x448,0xa1c5000,0,0x1c3dc38,0,0xbfbfe638,0) 91919 thttpd 0.000197 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000007 CALL sendfile(0x128,0x523,0x9daa000,0,0x192954a,0,0xbfbfe638,0) 91919 thttpd 0.000264 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000018 CALL sendfile(0x128,0x85e,0xa7e0000,0,0xef354a,0,0xbfbfe638,0) 91919 thttpd 0.000418 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000027 CALL sendfile(0x33,0x7b7,0x9e80000,0,0x83ddca,0,0xbfbfe638,0) 91919 thttpd 0.000299 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000022 CALL sendfile(0x128,0xfd,0xb348000,0,0x38b54a,0,0xbfbfe638,0) 91919 thttpd 0.000231 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000006 CALL sendfile(0xd2,0x160,0x6681000,0,0x129a6d6,0,0xbfbfe638,0) 91919 thttpd 0.000231 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000010 CALL sendfile(0x128,0x46f,0xa15f000,0,0x157454a,0,0xbfbfe638,0) 91919 thttpd 0.000223 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000007 CALL sendfile(0x128,0x88,0xac4d000,0,0xa8654a,0,0xbfbfe638,0) 91919 thttpd 0.000226 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000006 CALL sendfile(0x128,0x85c,0xa538000,0,0x119b54a,0,0xbfbfe638,0) 91919 thttpd 0.000197 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000007 CALL sendfile(0x128,0x1ac,0x51b0000,0,0x652354a,0,0xbfbfe638,0) 91919 thttpd 0.000270 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000008 CALL sendfile(0x128,0x856,0x996e000,0,0x1d6554a,0,0xbfbfe638,0) 91919 thttpd 0.000304 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000008 CALL sendfile(0x128,0x7a8,0xa505000,0,0x11ce54a,0,0xbfbfe638,0) 91919 thttpd 0.000218 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000008 CALL sendfile(0x33,0x7cd,0xa51b000,0,0x1a2dca,0,0xbfbfe638,0) 91919 thttpd 0.000292 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000024 CALL sendfile(0x128,0x1e0,0x8b64000,0,0x2b6f54a,0,0xbfbfe638,0) 91919 thttpd 0.000211 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000006 CALL sendfile(0x128,0x907,0x9933000,0,0x1da054a,0,0xbfbfe638,0) 91919 thttpd 0.000097 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000008 CALL sendfile(0xd2,0x2db,0x6c6f000,0,0xcac6d6,0,0xbfbfe638,0) 91919 thttpd 0.000286 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000040 CALL sendfile(0x128,0x845,0xafab000,0,0x72854a,0,0xbfbfe638,0) 91919 thttpd 0.000273 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000020 CALL sendfile(0x128,0x873,0x9968000,0,0x1d6b54a,0,0xbfbfe638,0) 91919 thttpd 0.000136 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000006 CALL sendfile(0xd2,0x2ba,0x5bae000,0,0x1d6d6d6,0,0xbfbfe638,0) 91919 thttpd 0.000230 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000006 CALL sendfile(0x33,0x1df,0xa564000,0,0x159dca,0,0xbfbfe638,0) 91919 thttpd 0.000195 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000006 CALL sendfile(0x128,0x13,0x6abf000,0,0x4c1454a,0,0xbfbfe638,0) 91919 thttpd 0.000258 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000015 CALL sendfile(0x9,0x2ae,0x7ff1000,0,0x30bc204,0,0xbfbfe638,0) 91919 thttpd 0.000499 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000036 CALL sendfile(0x128,0x2ce,0x4c4e000,0,0x6a8554a,0,0xbfbfe638,0) 91919 thttpd 0.000201 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000007 CALL sendfile(0x33,0x27e,0x5df5000,0,0x48c8dca,0,0xbfbfe638,0) 91919 thttpd 0.000193 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000007 CALL sendfile(0x128,0x22e,0x567b000,0,0x605854a,0,0xbfbfe638,0) 91919 thttpd 0.000235 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000007 CALL sendfile(0x128,0x77,0x9199000,0,0x253a54a,0,0xbfbfe638,0) 91919 thttpd 0.000324 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000028 CALL sendfile(0x33,0x4d3,0x98e2000,0,0xddbdca,0,0xbfbfe638,0) 91919 thttpd 0.000241 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000007 CALL sendfile(0x128,0x17b,0x4e27000,0,0x68ac54a,0,0xbfbfe638,0) 91919 thttpd 0.000250 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000016 CALL sendfile(0x128,0x25b,0x48ca000,0,0x6e0954a,0,0xbfbfe638,0) 91919 thttpd 0.000380 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000024 CALL sendfile(0x128,0x6c1,0xb0eb000,0,0x5e854a,0,0xbfbfe638,0) 91919 thttpd 0.000466 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000050 CALL sendfile(0x128,0x620,0xa517000,0,0x11bc54a,0,0xbfbfe638,0) 91919 thttpd 0.001469 RET sendfile -1 errno 35 Resource temporarily unavailable 91919 thttpd 0.000043 CALL sendfile(0x33,0x43d,0xa5fd000,0,0xc0dca,0,0xbfbfe638,0) 91919 thttpd 0.005250 RET sendfile -1 errno 35 Resource temporarily unavailable From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 20:01:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 906B516A4CE for ; Fri, 10 Dec 2004 20:01:21 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E33743D62 for ; Fri, 10 Dec 2004 20:01:20 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 96897 invoked from network); 10 Dec 2004 19:50:52 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Dec 2004 19:50:52 -0000 Message-ID: <41BA0088.9000107@freebsd.org> Date: Fri, 10 Dec 2004 21:01:12 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041122 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: gallatin@cs.duke.edu Subject: Rewritten TCP reassembly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 20:01:21 -0000 I've totally rewritten the TCP reassembly function to be a lot more efficient. In tests with normal bw*delay products and packet loss plus severe reordering I've measured an improvment of at least 30% in performance. For high and very high bw*delay product links the performance improvement is most likely much higher. The main property of the new code is O(1) insert for 95% of all normal reassembly cases. If there is more than one hole the insert time is O(holes). If a packet arrives that closes a hole the chains to the left and right are merged. Artificially constructed worst case is O(n). No malloc's are done for new segments. The old code was O(n) in all cases plus n*malloc for a describing structure. There are some problems with the new code I will fix before committing it to the tree. One is it can't handle non-writeable mbuf's and the other is too little leading space in the mbuf (found only on loopback interface, but there we don't have packet loss). Once these two are dealed with it is ready to go in. Nothing is perfect and this code is only a first significant step over what we have currently in the tree, especially for transfers over lossy (wireless) and high speed links with and without packet reordering. I have the next steps already in the works which will further optimize (worst case O(windowsize/mclusters) instead of O(n)) and simplify a bit more again. The patch can be found here: http://www.nrg4u.com/freebsd/tcp_reass-20041210.patch Please test and report good and bad news back. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 20:17:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70ADD16A4CE for ; Fri, 10 Dec 2004 20:17:25 +0000 (GMT) Received: from smtp.uol.com.br (smtpout1.uol.com.br [200.221.4.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30C7243D5F for ; Fri, 10 Dec 2004 20:17:25 +0000 (GMT) (envelope-from giulianocm@uol.com.br) Received: from [200.168.128.181] (200-168-128-181.dsl.telesp.net.br [200.168.128.181]) by scorpion1.uol.com.br (Postfix) with ESMTP id 345308D24 for ; Fri, 10 Dec 2004 18:17:22 -0200 (BRST) Message-ID: <41BA044F.5070209@uol.com.br> Date: Fri, 10 Dec 2004 18:17:19 -0200 From: Giuliano Cardozo Medalha User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: network implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: giulianocm@uol.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 20:17:25 -0000 Hi, I am a new FreeBSD user and I am looking for new TCP implementation in FreeBSD to test them with some logn distance networks to implement remote machining control. Its possible to use FreeBSD with the following implementations: FAST TCP TCP RENO TCP new RENO Reno 16 ? Thanks a lot. From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 23:05:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2336716A4CE; Fri, 10 Dec 2004 23:05:36 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5713A43D31; Fri, 10 Dec 2004 23:05:33 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.1/8.13.1) with ESMTP id iBAN5W0Y018539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Dec 2004 18:05:32 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id iBAN5RZF047494; Fri, 10 Dec 2004 18:05:27 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16826.11191.630110.592646@grasshopper.cs.duke.edu> Date: Fri, 10 Dec 2004 18:05:27 -0500 (EST) To: Andre Oppermann In-Reply-To: <41BA0088.9000107@freebsd.org> References: <41BA0088.9000107@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-net@freebsd.org Subject: Re: Rewritten TCP reassembly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 23:05:36 -0000 Andre Oppermann writes: > I've totally rewritten the TCP reassembly function to be a lot more > efficient. In tests with normal bw*delay products and packet loss > plus severe reordering I've measured an improvment of at least 30% in > performance. For high and very high bw*delay product links the > performance improvement is most likely much higher. > I ran netperf with 20 times for each of 3 socket buffer sizes (128KB, 256KB, and 1MB) before and after patching. All tests were run with net.isr.enable=1, and machdep.cpu_idle_hlt=0. CPU was pretty much maxed thoughout. (SMP kernel, 1 HTT p4). I'm not sure how much weight you should give these result. I still haven't gotten around to fixing kttcp, so the memory copy overhead is pretty high. For xmit, b/w goes from 2.90Gb/sec to 3.95Gb/sec when sendfile is used. (linux receiver on same hw). I've also not gotten around to making any of Robert's suggested driver optimizations. I noticed that at least systat was not printing the number of tcp out-of-order packets after applying the patch. I forgot to check netstat itself. Drew x before.131072 + after.131072 +--------------------------------------------------------------------------+ | ++ x + x x| |+ *+ + + ++ +xx++ x +x* ++ + xx+x x x + x x xxxx| | |_____________AM|___________|_______AM__________________| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 20 3336.63 3516.95 3449.87 3447.838 52.708815 + 20 3323 3466.34 3391.97 3389.686 37.154513 Difference at 95.0% confidence -58.152 +/- 29.1859 -1.68662% +/- 0.846499% (Student's t, pooled s = 45.5998) x before.262144 + after.262144 +--------------------------------------------------------------------------+ | + | | + x | |+ ++ + ++ x x x | |+ + ++++++++ + + x x x x x xx xxx xxxx x x| | |______A______| |_______AM_______| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 20 3197.77 3421.67 3316.64 3314.8555 59.787371 + 20 2889.64 3122.17 2965.01 2964.9865 50.076867 Difference at 95.0% confidence -349.869 +/- 35.2961 -10.5546% +/- 1.06479% (Student's t, pooled s = 55.1463) x before.1048576 + after.1048576 +--------------------------------------------------------------------------+ | x + | |xx x + x xx + x+x++x * x* x+*x+x+* x*+ + + + ++| | |_________________|A____M__________A__M____________| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 20 2658.05 2732.45 2706.91 2700.1955 23.318833 + 20 2676.13 2748.97 2724.07 2719.9665 20.531036 Difference at 95.0% confidence 19.771 +/- 14.0613 0.732206% +/- 0.52075% (Student's t, pooled s = 21.9692) From owner-freebsd-net@FreeBSD.ORG Fri Dec 10 23:20:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 687D216A4CE for ; Fri, 10 Dec 2004 23:20:36 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ECFE43D4C for ; Fri, 10 Dec 2004 23:20:35 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 98490 invoked from network); 10 Dec 2004 23:10:06 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Dec 2004 23:10:06 -0000 Message-ID: <41BA2F45.4CB61B37@freebsd.org> Date: Sat, 11 Dec 2004 00:20:37 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Gallatin References: <41BA0088.9000107@freebsd.org> <16826.11191.630110.592646@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Rewritten TCP reassembly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2004 23:20:36 -0000 Andrew Gallatin wrote: > > Andre Oppermann writes: > > I've totally rewritten the TCP reassembly function to be a lot more > > efficient. In tests with normal bw*delay products and packet loss > > plus severe reordering I've measured an improvment of at least 30% in > > performance. For high and very high bw*delay product links the > > performance improvement is most likely much higher. > > > > I ran netperf with 20 times for each of 3 socket buffer sizes (128KB, > 256KB, and 1MB) before and after patching. All tests were run with > net.isr.enable=1, and machdep.cpu_idle_hlt=0. CPU was pretty much > maxed thoughout. (SMP kernel, 1 HTT p4). HTT is not really good with FreeBSD's schedulers. Most of the time it hurts performance more than it helps. > I'm not sure how much weight you should give these result. I still > haven't gotten around to fixing kttcp, so the memory copy overhead is > pretty high. For xmit, b/w goes from 2.90Gb/sec to 3.95Gb/sec when > sendfile is used. (linux receiver on same hw). Ok. > I've also not gotten around to making any of Robert's suggested driver > optimizations. Ok. > I noticed that at least systat was not printing the number of tcp > out-of-order packets after applying the patch. I forgot to check > netstat itself. Duh, that's missing in the patch. Good you noticed. Regarding your measurements, did you measure the bandwidth as reported by Netperf? Is a FreeBSD box on both sides (you mentioned Linux)? -- Andre > Drew > > x before.131072 > + after.131072 > +--------------------------------------------------------------------------+ > | ++ x + x x| > |+ *+ + + ++ +xx++ x +x* ++ + xx+x x x + x x xxxx| > | |_____________AM|___________|_______AM__________________| | > +--------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 20 3336.63 3516.95 3449.87 3447.838 52.708815 > + 20 3323 3466.34 3391.97 3389.686 37.154513 > Difference at 95.0% confidence > -58.152 +/- 29.1859 > -1.68662% +/- 0.846499% > (Student's t, pooled s = 45.5998) > > x before.262144 > + after.262144 > +--------------------------------------------------------------------------+ > | + | > | + x | > |+ ++ + ++ x x x | > |+ + ++++++++ + + x x x x x xx xxx xxxx x x| > | |______A______| |_______AM_______| | > +--------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 20 3197.77 3421.67 3316.64 3314.8555 59.787371 > + 20 2889.64 3122.17 2965.01 2964.9865 50.076867 > Difference at 95.0% confidence > -349.869 +/- 35.2961 > -10.5546% +/- 1.06479% > (Student's t, pooled s = 55.1463) > > x before.1048576 > + after.1048576 > +--------------------------------------------------------------------------+ > | x + | > |xx x + x xx + x+x++x * x* x+*x+x+* x*+ + + + ++| > | |_________________|A____M__________A__M____________| | > +--------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 20 2658.05 2732.45 2706.91 2700.1955 23.318833 > + 20 2676.13 2748.97 2724.07 2719.9665 20.531036 > Difference at 95.0% confidence > 19.771 +/- 14.0613 > 0.732206% +/- 0.52075% > (Student's t, pooled s = 21.9692) From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 01:03:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98DEF16A4CE; Sat, 11 Dec 2004 01:03:34 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E2D043D73; Sat, 11 Dec 2004 01:03:34 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.1/8.13.1) with ESMTP id iBB13XcL000090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Dec 2004 20:03:33 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id iBB13SiL047620; Fri, 10 Dec 2004 20:03:28 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16826.18272.340836.813046@grasshopper.cs.duke.edu> Date: Fri, 10 Dec 2004 20:03:28 -0500 (EST) To: Andre Oppermann In-Reply-To: <41BA2F45.4CB61B37@freebsd.org> References: <41BA0088.9000107@freebsd.org> <16826.11191.630110.592646@grasshopper.cs.duke.edu> <41BA2F45.4CB61B37@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-net@freebsd.org Subject: Re: Rewritten TCP reassembly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 01:03:34 -0000 Andre Oppermann writes: > > Regarding your measurements, did you measure the bandwidth as reported > by Netperf? Is a FreeBSD box on both sides (you mentioned Linux)? Yes, all the numbers were in Mb/sec. The sender was running linux-2.6.6 (also SMP on a single HTT P4). Drew From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 01:36:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FA4916A4CE for ; Sat, 11 Dec 2004 01:36:23 +0000 (GMT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id D178843D41 for ; Sat, 11 Dec 2004 01:36:22 +0000 (GMT) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail.bluecoat.com (bcs-mail.bluecoat.com [216.52.23.69]) by whisker.bluecoat.com (8.13.0/8.13.0) with ESMTP id iBB1aMK0028181 for ; Fri, 10 Dec 2004 17:36:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Dec 2004 17:36:22 -0800 Message-ID: <00CDF9AA240E204FA6E923BD35BC643607AD87E2@bcs-mail.internal.cacheflow.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP simul-open not working Thread-Index: AcTfIdGodmJLAwlLQAKf+OupLIVm8A== From: "Li, Qing" To: X-Scanned-By: MIMEDefang 2.49 on 216.52.23.28 Subject: TCP simul-open not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 01:36:23 -0000 TCP simultaneous open does not seem to work in the current code. I've verified the behavior through ANVL.=20 I will file a pr unless someone has any comment on it. =09 -- Qing From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 03:22:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60A1D16A4CE; Sat, 11 Dec 2004 03:22:56 +0000 (GMT) Received: from server1.astraldream.net (astraldream.net [69.20.5.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA83643D1D; Sat, 11 Dec 2004 03:22:53 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.20] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated (0 bits)) by server1.astraldream.net (8.11.6/8.11.6) with ESMTP id iBB3McQ06187 verified NO); Fri, 10 Dec 2004 22:22:45 -0500 From: Suleiman Souhlal To: Michal Mertl In-Reply-To: <41B714DA.6090505@traveller.cz> References: <41B714DA.6090505@traveller.cz> Content-Type: text/plain Message-Id: <1102735360.5281.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 10 Dec 2004 22:22:41 -0500 Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org cc: Andre Oppermann Subject: Re: New ICMP limits X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 03:22:56 -0000 Hi, On Wed, 2004-12-08 at 09:51, Michal Mertl wrote: > What do you think? Wouldn't it be better to move all the calls to badport_bandlim() to inside icmp_error()? Bye -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 09:02:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7D6216A4CE for ; Sat, 11 Dec 2004 09:02:36 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A17543D45 for ; Sat, 11 Dec 2004 09:02:36 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id D4DE9A7; Sat, 11 Dec 2004 10:02:35 +0100 (CET) Date: Sat, 11 Dec 2004 10:02:35 +0100 From: Andrea Campi To: net@freebsd.org Message-ID: <20041211090235.GD11190@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 09:02:36 -0000 Hi all, just a quick note to let concerned parties know I have started working on the howl port. As mentioned on the dingo page, the goal is to have a fully working BSD-licensed implementation of zeroconf. At the moment I have autoipd working for me and slightly tested; I plan to do more tests during the next weeks. The next step will be getting nifd to work (that should be quite easy) and verifying everything together. I will probably start publishing and regularly updating patches on my website shortly. There are at least a couple of bugs I'd like to get fixed upstream as they are in architecture-neutral parts and they should affect other platforms as well. I need help from people in the know, mainly in the shape of eyes over my code. In particular, although it's hardly science fiction, I am uncertain on whether I do things the canonical way or we have better ways; a sort of best practices if you will. One more point I'd like to get feedback on. The "canonical" way to run autoipd, that is the way it recommends in documentation, is to have it start when dhclient fails to grab an IP and let it manage IP assignments on the interface (i.e., set the IP with SIOCSIFADDR). I dislike this approach for several reasons, the more relevant one being that since both dhclient and autoipd keep running they might get into an ioctl war that's a sure way to get no networking at all. :-/ The way I'm addressing this is to have autoipd use SIOCAIFADDR and manage exactly one address in the 169.254/16 block. This means you will ALWAYS have an IP address in that range; if you also run dhclient, you might have an additional IP and a default route. Thoughts? Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 09:41:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9175716A4CE for ; Sat, 11 Dec 2004 09:41:37 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C4DA43D46 for ; Sat, 11 Dec 2004 09:41:37 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.250] (pool-68-160-207-47.ny325.east.verizon.net [68.160.207.47]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id iBB9fYfw001163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Dec 2004 04:41:36 -0500 (EST) Message-ID: <41BAC0BD.7000706@mac.com> Date: Sat, 11 Dec 2004 04:41:17 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi References: <20041211090235.GD11190@webcom.it> In-Reply-To: <20041211090235.GD11190@webcom.it> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 09:41:37 -0000 Andrea Campi wrote: [ ... ] > The way I'm addressing this is to have autoipd use SIOCAIFADDR > and manage exactly one address in the 169.254/16 block. This > means you will ALWAYS have an IP address in that range; if you > also run dhclient, you might have an additional IP and a default > route. > > Thoughts? See http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt: 1.9. When to configure an IPv4 Link-Local address Having addresses of multiple different scopes assigned to an interface, with no adequate way to determine in what circumstances each address should be used, leads to complexity for applications and confusion for users. A host with an address on a link can communicate with all other devices on that link, whether those devices use Link- Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface. ...but there is more there to read. It's fine to let an interface have a 169.254/16 IP and a "real" IP (assigned by DHCP, the user, etc) for a little while during transitions, but not forever. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 10:16:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 359FA16A4CE; Sat, 11 Dec 2004 10:16:26 +0000 (GMT) Received: from mail2out.barnet.com.au (mail2out.barnet.com.au [202.83.176.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BCB643D5E; Sat, 11 Dec 2004 10:16:25 +0000 (GMT) (envelope-from edwin@mavetju.org) Received: by mail2out.barnet.com.au (Postfix, from userid 27) id 0EDF5707441; Sat, 11 Dec 2004 21:16:24 +1100 (EST) X-Viruscan-Id: <41BAC8F70000CC4CADDDA8@BarNet> Received: from mail2-auth.barnet.com.au (mail2.barnet.com.au [202.83.176.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by mail2.barnet.com.au (Postfix) with ESMTP id C2DD270743E; Sat, 11 Dec 2004 21:16:23 +1100 (EST) Received: from k7.mavetju (edwin.adsl.barnet.com.au [203.111.122.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Certificate Authority" (verified OK)) by mail2-auth.barnet.com.au (Postfix) with ESMTP id 2ED6170743C; Sat, 11 Dec 2004 21:16:23 +1100 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 27D7E60DC; Sat, 11 Dec 2004 21:16:22 +1100 (EST) Date: Sat, 11 Dec 2004 21:16:22 +1100 From: Edwin Groothuis To: Gleb Smirnoff Message-ID: <20041211101622.GA1430@k7.mavetju> References: <200412021322.iB2DMxLj066304@freefall.freebsd.org> <20041202134041.GB32699@cell.sick.ru> <41B2200F.FB46E28A@freebsd.org> <20041205005101.H44692@mp2.macomnet.net> <20041204221449.GC49503@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041204221449.GC49503@cell.sick.ru> User-Agent: Mutt/1.5.6i cc: Andre Oppermann cc: net@freebsd.org Subject: Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 10:16:26 -0000 On Sun, Dec 05, 2004 at 01:14:49AM +0300, Gleb Smirnoff wrote: > On Sun, Dec 05, 2004 at 12:53:52AM +0300, Maxim Konovalov wrote: > M> IMHO restoring the historic behaviour (even broken in some respects) > M> is the best thing we can do at the moment. > > + my vote. Mine too. > Using 'ipfw fwd' on packets just being nated, is a very common and used > technique. I know several places where people are delaying move from RELENG_4 to > RELENG_5 because of this problem. It doesn't happen often that I break the transparent WWW proxy, the POP3 virus scanner and the SMTP interceptor with one upgrade :-) Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/ From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 10:28:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74F2A16A4CE for ; Sat, 11 Dec 2004 10:28:26 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E95C43D54 for ; Sat, 11 Dec 2004 10:28:26 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id 50BF8A6; Sat, 11 Dec 2004 11:28:25 +0100 (CET) Date: Sat, 11 Dec 2004 11:28:25 +0100 From: Andrea Campi To: Chuck Swiger Message-ID: <20041211102825.GB12803@webcom.it> References: <20041211090235.GD11190@webcom.it> <41BAC0BD.7000706@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41BAC0BD.7000706@mac.com> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 10:28:26 -0000 On Sat, Dec 11, 2004 at 04:41:17AM -0500, Chuck Swiger wrote: > Andrea Campi wrote: > [ ... ] > >The way I'm addressing this is to have autoipd use SIOCAIFADDR > >and manage exactly one address in the 169.254/16 block. This > >means you will ALWAYS have an IP address in that range; if you > >also run dhclient, you might have an additional IP and a default > >route. > > > >Thoughts? > > See http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt: > > 1.9. When to configure an IPv4 Link-Local address > > Having addresses of multiple different scopes assigned to an > interface, with no adequate way to determine in what circumstances > each address should be used, leads to complexity for applications and > confusion for users. A host with an address on a link can > communicate with all other devices on that link, whether those > devices use Link- Local addresses, or routable addresses. For these > reasons, a host SHOULD NOT have both an operable routable address and > an IPv4 Link-Local address configured on the same interface. > > ...but there is more there to read. It's fine to let an interface have a > 169.254/16 IP and a "real" IP (assigned by DHCP, the user, etc) for a > little while during transitions, but not forever. Uhm. Yes, I can see the point about added complexity, and that was my main concern as well. I forgot that the RFC explicitely mentioned this however. Still, what's worse, having two correct but potentially confusing addresses, and everything still working; or having DHCP and autoipd fighting over which one determines the one and only IP address? I'll have to check how Mac OS X handles this, but unless we merge zeroconf in dhclient (ugh!) or vice versa, I don't see an alternative which is as convenient for the user. Do you? Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 10:42:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BC5316A4CE; Sat, 11 Dec 2004 10:42:53 +0000 (GMT) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 343B643D5A; Sat, 11 Dec 2004 10:42:52 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from [127.0.0.1] (ss.eunet.cz. [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id iBBAgZvO033674; Sat, 11 Dec 2004 11:42:36 +0100 (CET) (envelope-from mime@traveller.cz) Message-ID: <41BACF27.4080008@traveller.cz> Date: Sat, 11 Dec 2004 11:42:47 +0100 From: Michal Mertl User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; cs-CZ; rv:1.7.3) Gecko/20041117 X-Accept-Language: cs, en-us, en MIME-Version: 1.0 To: Suleiman Souhlal References: <41B714DA.6090505@traveller.cz> <1102735360.5281.6.camel@localhost> In-Reply-To: <1102735360.5281.6.camel@localhost> Content-Type: multipart/mixed; boundary="------------090602040503050508090206" cc: freebsd-net@FreeBSD.org cc: Andre Oppermann Subject: Re: New ICMP limits X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 10:42:53 -0000 This is a multi-part message in MIME format. --------------090602040503050508090206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Suleiman Souhlal napsal(a): > Hi, > > On Wed, 2004-12-08 at 09:51, Michal Mertl wrote: > >>What do you think? > > > Wouldn't it be better to move all the calls to badport_bandlim() to > inside icmp_error()? It makes sense, yes. Unfortunately it isn't possible in most cases - echo/tstamp call icmp_reflect instead of icmp_errror from inside icmp_input. TCP RSTs aren't in fact ICMP packets. The only case, where it's easily doable is in udp_input for ICMP_PORT_UNREACHABLES. I changed my patch quite a bit after Andre's suggestions. I'm sending you the new version. -- Michal Mertl --------------090602040503050508090206 Content-Type: text/plain; name="icmp_limits.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="icmp_limits.patch" Index: icmp_var.h =================================================================== RCS file: /home/fcvs/cvs/src/sys/netinet/icmp_var.h,v retrieving revision 1.24 diff -u -r1.24 icmp_var.h --- icmp_var.h 16 Aug 2004 18:32:07 -0000 1.24 +++ icmp_var.h 10 Dec 2004 16:57:49 -0000 @@ -57,32 +57,16 @@ u_long icps_noroute; /* no route back */ }; -/* - * Names for ICMP sysctl objects - */ -#define ICMPCTL_MASKREPL 1 /* allow replies to netmask requests */ -#define ICMPCTL_STATS 2 /* statistics (read-only) */ -#define ICMPCTL_ICMPLIM 3 -#define ICMPCTL_MAXID 4 - -#define ICMPCTL_NAMES { \ - { 0, 0 }, \ - { "maskrepl", CTLTYPE_INT }, \ - { "stats", CTLTYPE_STRUCT }, \ - { "icmplim", CTLTYPE_INT }, \ -} - #ifdef _KERNEL SYSCTL_DECL(_net_inet_icmp); extern struct icmpstat icmpstat; /* icmp statistics */ extern int badport_bandlim(int); #define BANDLIM_UNLIMITED -1 -#define BANDLIM_ICMP_UNREACH 0 -#define BANDLIM_ICMP_ECHO 1 -#define BANDLIM_ICMP_TSTAMP 2 -#define BANDLIM_RST_CLOSEDPORT 3 /* No connection, and no listeners */ -#define BANDLIM_RST_OPENPORT 4 /* No connection, listener */ -#define BANDLIM_MAX 4 +#define BANDLIM_ICMP_UNREACH_PORT 0 +#define BANDLIM_ICMP_UNREACH 1 +#define BANDLIM_ICMP_ECHO 2 +#define BANDLIM_RST_CLOSEDPORT 3 /* No connection, and no listeners */ +#define BANDLIM_RST_OPENPORT 4 /* No connection, listener */ #endif #endif Index: ip_icmp.c =================================================================== RCS file: /home/fcvs/cvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.97 diff -u -r1.97 ip_icmp.c --- ip_icmp.c 15 Sep 2004 20:13:26 -0000 1.97 +++ ip_icmp.c 10 Dec 2004 16:59:19 -0000 @@ -79,11 +79,11 @@ */ struct icmpstat icmpstat; -SYSCTL_STRUCT(_net_inet_icmp, ICMPCTL_STATS, stats, CTLFLAG_RW, +SYSCTL_STRUCT(_net_inet_icmp, OID_AUTO, stats, CTLFLAG_RW, &icmpstat, icmpstat, ""); static int icmpmaskrepl = 0; -SYSCTL_INT(_net_inet_icmp, ICMPCTL_MASKREPL, maskrepl, CTLFLAG_RW, +SYSCTL_INT(_net_inet_icmp, OID_AUTO, maskrepl, CTLFLAG_RW, &icmpmaskrepl, 0, "Reply to ICMP Address Mask Request packets."); static u_int icmpmaskfake = 0; @@ -98,9 +98,28 @@ SYSCTL_INT(_net_inet_icmp, OID_AUTO, log_redirect, CTLFLAG_RW, &log_redirect, 0, ""); -static int icmplim = 200; -SYSCTL_INT(_net_inet_icmp, ICMPCTL_ICMPLIM, icmplim, CTLFLAG_RW, - &icmplim, 0, ""); +SYSCTL_NODE(_net_inet_icmp, OID_AUTO, limit, CTLFLAG_RW, 0, + "ICMP replies limits"); + +static int icmplim_unreach = 200; +SYSCTL_INT(_net_inet_icmp_limit, OID_AUTO, unreach, + CTLFLAG_RW, &icmplim_unreach, 0, + "Maximum rate of ICMP unreachables"); + +static int icmplim_echo = 200; +SYSCTL_INT(_net_inet_icmp_limit, OID_AUTO, echo, + CTLFLAG_RW, &icmplim_echo, 0, + "Maximum rate of ICMP echo/tstamp replies"); + +static int icmplim_tcp = 200; +SYSCTL_INT(_net_inet_icmp_limit, OID_AUTO, tcp, + CTLFLAG_RW, &icmplim_tcp, 0, + "Maximum rate of TCP RSTs"); + +static int icmplim_udp = 200; +SYSCTL_INT(_net_inet_icmp_limit, OID_AUTO, udp, + CTLFLAG_RW, &icmplim_udp, 0, + "Maximum rate of ICMP port unreachables"); static int icmplim_output = 1; SYSCTL_INT(_net_inet_icmp, OID_AUTO, icmplim_output, CTLFLAG_RW, @@ -171,6 +190,23 @@ /* Don't send error in response to a multicast or broadcast packet */ if (n->m_flags & (M_BCAST|M_MCAST)) goto freeit; + + if (type == ICMP_UNREACH && code != ICMP_UNREACH_NEEDFRAG) + /* + * Limit sending of ICMP unreachable messages except of + * ICMP_UNREACH_NEEDFRAG. + * This includes packets generated by firewall packages when + * dropping a packet. + * E.g.: "ipfw add 110 unreach filter-prohib tcp from any to any 25" + * It also limits sending of ICMP host unreachable messages + * generated if we are acting as a router and someone is doing a sweep + * scan (eg. nmap and/or numerous windows worms) for destinations + * we are the gateway for but are not reachable (ie. a /24 on a + * interface and only a couple of hosts on the ethernet) we would + * generate a storm of ICMP host unreachable messages. + */ + if (badport_bandlim(BANDLIM_ICMP_UNREACH) < 0) + goto freeit; /* * First, formulate icmp message */ @@ -489,7 +525,7 @@ icp->icmp_type = ICMP_TSTAMPREPLY; icp->icmp_rtime = iptime(); icp->icmp_ttime = icp->icmp_rtime; /* bogus, do later! */ - if (badport_bandlim(BANDLIM_ICMP_TSTAMP) < 0) + if (badport_bandlim(BANDLIM_ICMP_ECHO) < 0) goto freeit; else goto reflect; @@ -887,37 +923,55 @@ int badport_bandlim(int which) { -#define N(a) (sizeof (a) / sizeof (a[0])) static struct rate { const char *type; struct timeval lasttime; int curpps; - } rates[BANDLIM_MAX+1] = { + } rates[] = { + { "icmp port unreach response" }, { "icmp unreach response" }, - { "icmp ping response" }, - { "icmp tstamp response" }, + { "icmp echo/tstamp response" }, { "closed port RST response" }, { "open port RST response" } }; - - /* - * Return ok status if feature disabled or argument out of range. - */ - if (icmplim > 0 && (u_int) which < N(rates)) { - struct rate *r = &rates[which]; - int opps = r->curpps; - - if (!ppsratecheck(&r->lasttime, &r->curpps, icmplim)) - return -1; /* discard packet */ - /* - * If we've dropped below the threshold after having - * rate-limited traffic print the message. This preserves - * the previous behaviour at the expense of added complexity. - */ - if (icmplim_output && opps > icmplim) - printf("Limiting %s from %d to %d packets/sec\n", - r->type, opps, icmplim); + struct rate *r; + int opps; + int limit; + + /* Return ok status if argument is out of range. */ + switch (which) { + case BANDLIM_ICMP_UNREACH_PORT: + limit = icmplim_udp; + break; + case BANDLIM_ICMP_UNREACH: + limit = icmplim_unreach; + break; + case BANDLIM_ICMP_ECHO: + limit = icmplim_echo; + break; + case BANDLIM_RST_CLOSEDPORT: + case BANDLIM_RST_OPENPORT: + limit = icmplim_tcp; + break; + default: + return (0); } + /* Return ok status if limit is <=0 (unlimited) */ + if (limit <= 0) + return (0); + + /* Do the actual rate check */ + r = &rates[which]; + opps = r->curpps; + if (!ppsratecheck(&r->lasttime, &r->curpps, limit)) + return -1; /* discard packet */ + /* + * If we've dropped below the threshold after having + * rate-limited traffic print the message. This preserves + * the previous behaviour at the expense of added complexity. + */ + if (icmplim_output && opps > limit) + printf("Limiting %s from %d to %d packets/sec\n", + r->type, opps, limit); return 0; /* okay to send packet */ -#undef N } Index: udp_usrreq.c =================================================================== RCS file: /home/fcvs/cvs/src/sys/netinet/udp_usrreq.c,v retrieving revision 1.170 diff -u -r1.170 udp_usrreq.c --- udp_usrreq.c 8 Nov 2004 14:44:53 -0000 1.170 +++ udp_usrreq.c 10 Dec 2004 16:14:10 -0000 @@ -375,7 +375,7 @@ } if (blackhole) goto badheadlocked; - if (badport_bandlim(BANDLIM_ICMP_UNREACH) < 0) + if (badport_bandlim(BANDLIM_ICMP_UNREACH_PORT) < 0) goto badheadlocked; *ip = save_ip; ip->ip_len += iphlen; --------------090602040503050508090206-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 10:57:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8DAC16A4CE for ; Sat, 11 Dec 2004 10:57:58 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D65443D5A for ; Sat, 11 Dec 2004 10:57:58 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 1885 invoked from network); 11 Dec 2004 10:47:23 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Dec 2004 10:47:23 -0000 Message-ID: <41BAD2BA.C030B6DD@freebsd.org> Date: Sat, 11 Dec 2004 11:58:02 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Edwin Groothuis References: <200412021322.iB2DMxLj066304@freefall.freebsd.org> <20041202134041.GB32699@cell.sick.ru> <41B2200F.FB46E28A@freebsd.org> <20041205005101.H44692@mp2.macomnet.net> <20041204221449.GC49503@cell.sick.ru> <20041211101622.GA1430@k7.mavetju> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 10:57:59 -0000 Edwin Groothuis wrote: > > On Sun, Dec 05, 2004 at 01:14:49AM +0300, Gleb Smirnoff wrote: > > On Sun, Dec 05, 2004 at 12:53:52AM +0300, Maxim Konovalov wrote: > > M> IMHO restoring the historic behaviour (even broken in some respects) > > M> is the best thing we can do at the moment. > > > > + my vote. > > Mine too. I'll change it shortly. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 10:58:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F10D216A4CE for ; Sat, 11 Dec 2004 10:58:39 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60F1C43D48 for ; Sat, 11 Dec 2004 10:58:39 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 1902 invoked from network); 11 Dec 2004 10:48:05 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Dec 2004 10:48:05 -0000 Message-ID: <41BAD2E3.49D32318@freebsd.org> Date: Sat, 11 Dec 2004 11:58:43 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Li, Qing" References: <00CDF9AA240E204FA6E923BD35BC643607AD87E2@bcs-mail.internal.cacheflow.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: TCP simul-open not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 10:58:40 -0000 "Li, Qing" wrote: > > TCP simultaneous open does not seem to work in the current code. > I've verified the behavior through ANVL. > > I will file a pr unless someone has any comment on it. Please send me the PR number. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 18:47:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFE5016A4CE for ; Sat, 11 Dec 2004 18:47:21 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55C2E43D1D for ; Sat, 11 Dec 2004 18:47:21 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.250] (pool-68-160-207-47.ny325.east.verizon.net [68.160.207.47]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id iBBIlIZu038943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Dec 2004 13:47:20 -0500 (EST) Message-ID: <41BB40B7.5000907@mac.com> Date: Sat, 11 Dec 2004 13:47:19 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi References: <20041211090235.GD11190@webcom.it> <41BAC0BD.7000706@mac.com> <20041211102825.GB12803@webcom.it> In-Reply-To: <20041211102825.GB12803@webcom.it> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 18:47:21 -0000 Andrea Campi wrote: > On Sat, Dec 11, 2004 at 04:41:17AM -0500, Chuck Swiger wrote: >>...but there is more there to read. It's fine to let an interface have a >>169.254/16 IP and a "real" IP (assigned by DHCP, the user, etc) for a >>little while during transitions, but not forever. [ ... ] > Still, what's worse, having two correct but potentially confusing > addresses, and everything still working; or having DHCP and autoipd > fighting over which one determines the one and only IP address? I'll > have to check how Mac OS X handles this, but unless we merge zeroconf > in dhclient (ugh!) or vice versa, I don't see an alternative which is > as convenient for the user. Do you? If your first implementation happens to leave the interface with a 169.254 IP address, it's doing something it shouldn't, however that is likely to be mostly harmless until you or someone has a chance to improve the implementation. autoipd and DHCP/dhclient should never get into a fight, nor should autoipd conflict with a manually-assigned network config: autoipd should only try to configure a link-local address during the interval when nothing else has done so, or if autoipd has reason to believe that the existing configuration is invalid (ie, after the carrier drops). Any time dhclient gets a lease and assigns an IP address to an interface, autoipd needs to back out of the way. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 20:21:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0476D16A4CE for ; Sat, 11 Dec 2004 20:21:40 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id B65A643D1D for ; Sat, 11 Dec 2004 20:21:39 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id E187AA6; Sat, 11 Dec 2004 21:21:38 +0100 (CET) Date: Sat, 11 Dec 2004 21:21:38 +0100 From: Andrea Campi To: Chuck Swiger Message-ID: <20041211202138.GC12803@webcom.it> References: <20041211090235.GD11190@webcom.it> <41BAC0BD.7000706@mac.com> <20041211102825.GB12803@webcom.it> <41BB40B7.5000907@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41BB40B7.5000907@mac.com> User-Agent: Mutt/1.5.6i cc: Andrea Campi cc: net@freebsd.org Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 20:21:40 -0000 On Sat, Dec 11, 2004 at 01:47:19PM -0500, Chuck Swiger wrote: > If your first implementation happens to leave the interface with a 169.254 > IP address, it's doing something it shouldn't, however that is likely to be > mostly harmless until you or someone has a chance to improve the > implementation. Agreed. ;-) > autoipd and DHCP/dhclient should never get into a fight, nor should autoipd > conflict with a manually-assigned network config: autoipd should only try > to configure a link-local address during the interval when nothing else has > done so, or if autoipd has reason to believe that the existing > configuration is invalid (ie, after the carrier drops). Any time dhclient > gets a lease and assigns an IP address to an interface, autoipd needs to > back out of the way. Uhm. Yes, link state changes and possibly other events can reasonably be used for this. I guess I can use route change notifications from dhclient to notice something's up. Actually, all this is nifd's business, not autoipd proper; the two work in concert. Just to check my assumptions: is it reasonable to assume autoipd has total control over the 169.254 block? I don't want to have to bother about preserving any existing address in that range etc. OK, I'll do the straighforward implementation first but I'll keep an eye to DTRT. Thanks for beating me with clues! Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 20:56:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AEB316A4CE for ; Sat, 11 Dec 2004 20:56:37 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FC6743D54 for ; Sat, 11 Dec 2004 20:56:37 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.250] (pool-68-160-207-47.ny325.east.verizon.net [68.160.207.47]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id iBBKuXZD019216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Dec 2004 15:56:35 -0500 (EST) Message-ID: <41BB5F01.2050108@mac.com> Date: Sat, 11 Dec 2004 15:56:33 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi References: <20041211090235.GD11190@webcom.it> <41BAC0BD.7000706@mac.com> <20041211102825.GB12803@webcom.it> <41BB40B7.5000907@mac.com> <20041211202138.GC12803@webcom.it> In-Reply-To: <20041211202138.GC12803@webcom.it> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 20:56:37 -0000 Andrea Campi wrote: > On Sat, Dec 11, 2004 at 01:47:19PM -0500, Chuck Swiger wrote: [ ... ] >> autoipd and DHCP/dhclient should never get into a fight, nor should autoipd >> conflict with a manually-assigned network config: autoipd should only try >> to configure a link-local address during the interval when nothing else has >> done so, or if autoipd has reason to believe that the existing >> configuration is invalid (ie, after the carrier drops). Any time dhclient >> gets a lease and assigns an IP address to an interface, autoipd needs to >> back out of the way. > > Uhm. Yes, link state changes and possibly other events can > reasonably be used for this. I guess I can use route change > notifications from dhclient to notice something's up. The program ought to register for those, yes, and for interface link up/down messages (RTM_ADD, RTM_IFINFO, etc from "man 4 route"). > Actually, all this is nifd's business, not autoipd proper; the > two work in concert. OK. I am more familiar with zeroconf in terms of what it expects ARPOP_REQUEST and _REPLY to look like, and stuff like that, than I am with the two programs you have mentioned. :-) > Just to check my assumptions: is it reasonable to assume autoipd > has total control over the 169.254 block? I don't want to have to > bother about preserving any existing address in that range etc. No, it is not reasonable. Although if you make that assumption for the first implementation, it's probably mostly harmless again. However, zeroconf software needs to work as if it has no control over network allocation, and it needs to test the network to see whether a candidate IP address is already being used by something else...ARP-probing safely before it can claim a link-local IP address: "2.2. Claiming a Link-Local Address After it has selected an IPv4 Link-Local address, a host MUST test to see if the IPv4 Link-Local address is already in use before beginning to use it. When a network interface transitions from an inactive to an active state, the host does not have knowledge of what IPv4 Link- Local addresses may currently be in use on that link, since the point of attachment may have changed or the network interface may have been inactive when a conflicting address was claimed. Were the host to immediately begin using an IPv4 Link-Local address which is already in use by another host, this would be disruptive to that other host. Since it is possible that the host has changed its point of attachment, a routable address may be obtainable on the new network, and therefore it cannot be assumed that an IPv4 Link-Local address is to be preferred. Before using the IPv4 Link-Local address (e.g. using it as the source address in an IPv4 packet, or as the Sender IPv4 address in an ARP packet) a host MUST perform the probing test described below to achieve better confidence that using the IPv4 Link-Local address will not cause disruption. Examples of events that involve an interface becoming active include: Reboot/startup Wake from sleep (if network interface was inactive during sleep) Bringing up previously inactive network interface IEEE 802 hardware link-state change (appropriate for the media type and security mechanisms which apply) indicates that an interface has become active. Association with a wireless base station or adhoc network. A host MUST NOT perform this check periodically as a matter of course. This would be a waste of network bandwidth, and is unnecessary due to the ability of hosts to passively discover conflicts, as described in Section 2.5." ...and then it details the specific way to perform an ARPOP_REQUEST probe that all hosts on the local subnet will see without polluting their arp cache with wrong IP info. You might also want to consider this section: "2.11. Interaction between DHCPv4 client and IPv4 Link-Local State Machines As documented in Appendix A, early implementations of IPv4 Link-Local have modified the DHCP state machine. Field experience shows that these modifications reduce the reliability of the DHCP service. A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way." Consider the positive side, however: things a developer is restricted from implementing are tasks which don't have to be done, so to some extent the job becomes easier. Also, my memory suggests that the way FreeBSD generates and responds to ARP traffic is basicly what zeroconf would like to see, although the timeout algorithms and such are not identical. Anyway, perhaps my responses would be more helpful if you explained the use case you are trying to get going, first? -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sat Dec 11 23:14:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBFD716A4CE for ; Sat, 11 Dec 2004 23:14:35 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B9B243D49 for ; Sat, 11 Dec 2004 23:14:35 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id 8D9A5A6; Sun, 12 Dec 2004 00:14:34 +0100 (CET) Date: Sun, 12 Dec 2004 00:14:34 +0100 From: Andrea Campi To: Chuck Swiger Message-ID: <20041211231434.GA17233@webcom.it> References: <20041211090235.GD11190@webcom.it> <41BAC0BD.7000706@mac.com> <20041211102825.GB12803@webcom.it> <41BB40B7.5000907@mac.com> <20041211202138.GC12803@webcom.it> <41BB5F01.2050108@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41BB5F01.2050108@mac.com> User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: Working on howl port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2004 23:14:35 -0000 On Sat, Dec 11, 2004 at 03:56:33PM -0500, Chuck Swiger wrote: > >Just to check my assumptions: is it reasonable to assume autoipd > >has total control over the 169.254 block? I don't want to have to > >bother about preserving any existing address in that range etc. > > No, it is not reasonable. Although if you make that assumption for the > first implementation, it's probably mostly harmless again. However, Ah no, I meant on the local machine. What I mean is that by running zeroconf the user is giving total control of that block, and in particular is going to avoid explicitely configuring an interface with such an address. I figure that's quite reasonable. > Anyway, perhaps my responses would be more helpful if you explained the use > case you are trying to get going, first? Unless I'm mistaken, using SIOCAIFADDR instead of SIOCSIFADDR means that I do need to bother about other addresses in the same network on the same or on another interface. My plan is to replace any such address as needed, as long as I can trust they are not of any special meaning to the user. Additionally, if I can expect the user not to set a 169.254 address, I can assume RTM_ADD/RTM_NEWADDR messages for such an address come from dhclient failing to get a lease. Think of this scenario: - unconnected laptop on a bus, I get an addess by zeroconf; - I arrive at the office and the DHCP server gives out an address, zeroconf goes to sleep; - the DHCP server dies and come renew time dhclient notices and sets a 169.254 address. I'd like to be able to notice this case and decide it's really dhclient trying to tell me something, and not have to worry about a user trying to set a random IP address. Anyway, thinking again, this is probably less important than I first thought. I'm mostly thinking out aloud here. It just occurred to me that the second part can probably be better dealt with by having an useful set of scripts for dhclient. I think I should now get some more steps and expecially tests done, and come back when I have a clearer idea of how they interact. I'll still post some interim steps for feedback on the implementation. Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks.