From owner-freebsd-net@FreeBSD.ORG Sun Mar 11 06:24:22 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 932E916A400 for ; Sun, 11 Mar 2007 06:24:22 +0000 (UTC) (envelope-from keith.arner@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 1444F13C442 for ; Sun, 11 Mar 2007 06:24:21 +0000 (UTC) (envelope-from keith.arner@gmail.com) Received: by mu-out-0910.google.com with SMTP id g7so1595010muf for ; Sat, 10 Mar 2007 22:24:20 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Vsf8Yx32Ca04RWWQPWi9trS6JjOG2bUkxDi3IpwbcI4X7nWAMUU8kB1hE/9SzSWuD3csYozmVUW6CWqEb7gIfzlulcnAof7Kci8Up+qQ95hJlWtBsUU2MvPe0bqQD22u8IY3/x2jS8/1AqaDlqEfB1FrJUQnzS0nTMfy7Mx/LW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=tZuKvl3UANCsyua2zvNsCiQS2wH/EeQUvmS084mBhu7csEPT0+Ijdj/kLnCCxF/V3miX9rWnz1dEddZ3mjTLknHO/X8YNPz4P6pxIspALaCH5vBrTZokq4CoU77eM4QQtgygOwNAn8IV+DD5dk+JIpJFGdyBLT+YNWLsx0ctrhQ= Received: by 10.82.152.16 with SMTP id z16mr5871852bud.1173592675302; Sat, 10 Mar 2007 21:57:55 -0800 (PST) Received: by 10.82.121.1 with HTTP; Sat, 10 Mar 2007 21:57:55 -0800 (PST) Message-ID: <8e552a500703102157p1845926au65bb3adaf81c01c0@mail.gmail.com> Date: Sun, 11 Mar 2007 00:57:55 -0500 From: "Keith Arner" Sender: keith.arner@gmail.com To: "Robert Watson" In-Reply-To: <20070310035135.B30274@fledge.watson.org> MIME-Version: 1.0 References: <45C0CA5D.5090903@incunabulum.net> <45E6BEE0.2050307@FreeBSD.org> <45E6C22D.7060200@freebsd.org> <45E6D70C.10104@FreeBSD.org> <45EEB086.3050409@FreeBSD.org> <45F03269.7050705@FreeBSD.org> <45F08F1D.5080708@us.fujitsu.com> <20070310035135.B30274@fledge.watson.org> X-Google-Sender-Auth: 7cfc9a9f48ac426b Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Dave Baukus , net@freebsd.org Subject: Re: netisr_direct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 06:24:22 -0000 On 3/9/07, Robert Watson wrote: > It also introduces > parallelism in the in-bound network layer processing path by allowing > processing to occur in more than one thread at a time. However, you can > see >From the experimentation I've done, it seems that for TCP loads at least, the input path tends to bottleneck on INP_INFO_WLOCK(&tcbinfo), essentially reducing the input path to a single thread. reduced parallelism in some environments as the ithread no longer run > concurrently with the netisr. I would not use net.isr.direct in versions > of > FreeBSD before 6.1, but it should be pretty safe for 6.1 and later. > Admitedly, the experimentation I've done has been with 6.0, rather than 6.1. Have there been any changes in 6.1 that address the locking in the TCP input path? I'm very interested in being able to run highly parallel TCP loads. Keith From owner-freebsd-net@FreeBSD.ORG Sun Mar 11 07:11:04 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E81BC16A403 for ; Sun, 11 Mar 2007 07:11:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6BB13C4A8 for ; Sun, 11 Mar 2007 07:11:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8FF7646C1F; Sun, 11 Mar 2007 02:11:03 -0500 (EST) Date: Sun, 11 Mar 2007 08:11:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Keith Arner In-Reply-To: <8e552a500703102157p1845926au65bb3adaf81c01c0@mail.gmail.com> Message-ID: <20070311073249.R20646@fledge.watson.org> References: <45C0CA5D.5090903@incunabulum.net> <45E6BEE0.2050307@FreeBSD.org> <45E6C22D.7060200@freebsd.org> <45E6D70C.10104@FreeBSD.org> <45EEB086.3050409@FreeBSD.org> <45F03269.7050705@FreeBSD.org> <45F08F1D.5080708@us.fujitsu.com> <20070310035135.B30274@fledge.watson.org> <8e552a500703102157p1845926au65bb3adaf81c01c0@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Dave Baukus , net@freebsd.org Subject: Re: netisr_direct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 07:11:05 -0000 On Sun, 11 Mar 2007, Keith Arner wrote: > On 3/9/07, Robert Watson wrote: > >> It also introduces parallelism in the in-bound network layer processing >> path by allowing processing to occur in more than one thread at a time. >> However, you can see > > From the experimentation I've done, it seems that for TCP loads at least, > the input path tends to bottleneck on INP_INFO_WLOCK(&tcbinfo), essentially > reducing the input path to a single thread. Yes -- right now the in-bound TCP path is essentially serialized because of the tcbinfo lock. The reason for this is that the tcbinfo lock doesn't just protect the inpcb chains during lookup, but also effectively acts as a reference to prevent the inpcb from being freed during input processing. There are several ways we could start to reduce contention on that lock: (1) Introduce true references on inpcbs, which would prevent the inpcb from being freed even though the tcbinfo lock has been released. This would require reworking the TCP inpcb close/free model a bit, among other things. (2) Move from using a mutex supporting only exclusive locking on tcbinfo to a lock class supporting shared locks, and use shared locks in situations where exclusion isn't required (i.e., in cases where the connection may close, requiring the global lists to be modified). (3) Move towards greater granularity of locking for the tcbinfo: instead of a single mutex, move to more than one locks, so that different connections processed simultaneously are likely to involve different locks. For listen sockets, we would have to have a special case, such as a single lock to serialize simultaneous lock acquisitions of multiple chain locks (for example). I think all of these are reasonable approaches. Mohan and I have had plans to do (1) for at least a year or two now, but have not gotten to it yet. I experimented with (2), with the help of Attilio, a few months ago and ran into several issues (especially relating to recursion). I've not yet explored (3); for web servers with many connections, it is likely quite a good approach, but since it doesn't preclude "unlucky" hashing assignments of connections to chains that could lead to high contention. It might be quite easy to implement, however, which would be a big win :-). >> reduced parallelism in some environments as the ithread no longer run >> concurrently with the netisr. I would not use net.isr.direct in versions >> of FreeBSD before 6.1, but it should be pretty safe for 6.1 and later. > > Admitedly, the experimentation I've done has been with 6.0, rather than 6.1. Looking back from the CVS log, I see that the issue I was concerned about was fixed in 6.x before 6.0, rather than after, which was my fear. I'm not aware of specific bugs that might cause problems with direct dispatch in earlier 6.x releases, off hand. > Have there been any changes in 6.1 that address the locking in the TCP input > path? I'm very interested in being able to run highly parallel TCP loads. I'd have to look in detail at the logs to answer that -- I'm not aware of any significant changes. There are probably some minor ones to reduce contention in various ways, but I think the more important changes are all in 7.x only still. In 7.x, the pcbinfo lock is held significantly less in socket-side paths such as send/receive, which should improve contention issues. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 09:24:15 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACBE916A401; Mon, 12 Mar 2007 09:24:15 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 5D68813C46C; Mon, 12 Mar 2007 09:24:15 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HQglH-000NQi-P5; Mon, 12 Mar 2007 12:24:12 +0300 Date: Mon, 12 Mar 2007 12:24:06 +0300 From: Eygene Ryabinkin To: "Bruce M. Simpson" Message-ID: <20070312092406.GJ58523@codelabs.ru> References: <45E9F1E8.2000802@inse.ru> <20070304062203.GL80319@codelabs.ru> <45E9F1E8.2000802@inse.ru> <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <45ED900A.7050208@FreeBSD.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: rik@FreeBSD.org, freebsd-net@freebsd.org, glebius@FreeBSD.org, andre@FreeBSD.org, thompsa@FreeBSD.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 09:24:15 -0000 Bruce, good day! Tue, Mar 06, 2007 at 04:00:10PM +0000, Bruce M. Simpson wrote: > Eygene Ryabinkin wrote: > >I am awfully sorry, but you're seem to be mistaken: > Thanks for clarifying this. That'll be because I didn't read if_bridge that > far. ;^) In my original message I was just looking at if_ethersubr.c. > > I need to make sure any changes which are made to if_bridge to deal with vlan > problems are incorporated into bms_netdev so that after I commit M_PROMISC, it > does the right thing. OK, after discuissing the problem for a while, Roman Kurakin (rik@) decided to modify my patch: it will not just blindly rewriting the interface in the mbuf, but will apply an extra check for the physical incoming interface before checking the other bridge members. So it will hopefully do no harm to anything that was worked before and will cure the problem I spotted. Speaking about vlan problems: the original problem is to do something with VLAN interfaces only because they are sharing the MAC of their physical parent. The problem itself is not VLAN-specific -- if there will be two physical interfaces with the same MACs and they will be bridged, the problem will still be here. Will drop you a letter when the patch will be ready. -- Eygene From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 09:24:33 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D49816A400 for ; Mon, 12 Mar 2007 09:24:33 +0000 (UTC) (envelope-from achilov-rn@askd.ru) Received: from to-495.askd.ru (master.askd.ru [80.242.75.6]) by mx1.freebsd.org (Postfix) with ESMTP id DDC4513C43E for ; Mon, 12 Mar 2007 09:24:32 +0000 (UTC) (envelope-from achilov-rn@askd.ru) Received: from to-495.askd.ru (IDENT:shelton@localhost.askd.ru [127.0.0.1]) by to-495.askd.ru (8.13.8/8.13.6) with ESMTP id l2C8vNdq017938 for ; Mon, 12 Mar 2007 14:57:23 +0600 (NOVT) (envelope-from achilov-rn@askd.ru) Received: from localhost (localhost [[UNIX: localhost]]) by to-495.askd.ru (8.13.8/8.13.6/Submit) id l2C8vLmc017884 for freebsd-net@freebsd.org; Mon, 12 Mar 2007 14:57:21 +0600 (NOVT) (envelope-from achilov-rn@askd.ru) X-Authentication-Warning: to-495.askd.ru: shelton set sender to achilov-rn@askd.ru using -f From: "Rashid N. Achilov" Organization: =?koi8-r?b?7+/v?= "=?koi8-r?b?4fMt88nT1MXNwQ==?= =?koi8-r?b?IOvPzdDMxcvT?=" To: freebsd-net@freebsd.org Date: Mon, 12 Mar 2007 14:57:20 +0600 User-Agent: KMail/1.9.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703121457.20941.achilov-rn@askd.ru> Subject: Re: UltraVNC on freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Achilov, Rashid" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 09:24:33 -0000 On Friday 09 March 2007 15:16, Antonio Tommasi wrote: > Hi to all, > i've this scenario: > > one machine in a private network > one machine with a public machine > > i need to control with vnc the machine with private ip by the machine > with public ip. > > This is possibile installing ultravnc on the private machine (with > freebsd) so i can start the communication with public machine and > control the private machine? Which VNC? TightVNC or TridiaVNC. But encryption and file transmission will not available with these VNC's and UltraVNC at another end -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), Web: http://www.askd.ru/~shelton OOO "ACK" telecommunications administrator, e-mail: achilov-rn [at] askd.ru PGP: 83 CD E2 A7 37 4A D5 81 D6 D6 52 BF C9 2F 85 AF 97 BE CB 0A From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 09:31:14 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D042216A400 for ; Mon, 12 Mar 2007 09:31:14 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id AAF5A13C44C for ; Mon, 12 Mar 2007 09:31:14 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id CAE3F1F7BC0; Mon, 12 Mar 2007 05:31:14 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Mon, 12 Mar 2007 05:31:14 -0400 X-Sasl-enc: j9HBlA0FFq3Udi5WXZIwemEitsBCLR+U7sifMzXpZKQ0 1173691874 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 252131D1BC; Mon, 12 Mar 2007 05:31:13 -0400 (EDT) Message-ID: <45F51DE0.9050708@FreeBSD.org> Date: Mon, 12 Mar 2007 09:31:12 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: "Achilov, Rashid" References: <200703121457.20941.achilov-rn@askd.ru> In-Reply-To: <200703121457.20941.achilov-rn@askd.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: UltraVNC on freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 09:31:14 -0000 Rashid N. Achilov wrote: > > TightVNC or TridiaVNC. But encryption and file transmission will not available > with these VNC's and UltraVNC at another end > JFYI: I have heard corporate IT people who mostly work with Windows discuss UltraVNC. I don't see a port for it. It is on SourceForge so perhaps someone will step up to contribute a port. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 09:36:46 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5A7E16A402; Mon, 12 Mar 2007 09:36:46 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id A462413C46A; Mon, 12 Mar 2007 09:36:46 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id E117A1F8134; Mon, 12 Mar 2007 05:36:46 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 12 Mar 2007 05:36:46 -0400 X-Sasl-enc: R14vUwqq8AFMnn7L+I+M7xJw8SV4+u9oyLRvefbQDpqs 1173692206 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 8785E154CA; Mon, 12 Mar 2007 05:36:45 -0400 (EDT) Message-ID: <45F51F2B.5020906@FreeBSD.org> Date: Mon, 12 Mar 2007 09:36:43 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Eygene Ryabinkin References: <45E9F1E8.2000802@inse.ru> <20070304062203.GL80319@codelabs.ru> <45E9F1E8.2000802@inse.ru> <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> In-Reply-To: <20070312092406.GJ58523@codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: rik@FreeBSD.org, freebsd-net@freebsd.org, glebius@FreeBSD.org, andre@FreeBSD.org, thompsa@FreeBSD.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 09:36:46 -0000 Hi, Eygene Ryabinkin wrote: > > Speaking about vlan problems: the original problem is to do something > with VLAN interfaces only because they are sharing the MAC of their > physical parent. The problem itself is not VLAN-specific -- if there > will be two physical interfaces with the same MACs and they will be > bridged, the problem will still be here. > I see this also. What would be good is if there was a way to record additional MAC addresses for each ifnet, in addition to the if_lladdr member. This would cut down the cruft in ether_input(), if_bridge(4) and possibly also carp(4). For network cards with more than one perfect hash filter entry in the hardware, programming these into the card would *perhaps* be more efficient when trying to achieve line rate with gigabit and beyond. This would most likely require an ABI change. The VLAN handling problem doesn't go away; we will still need to check if a bridge member is a VLAN interface because we can't uniquely key off the MAC as you point out. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 11:08:30 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A20616A47E for ; Mon, 12 Mar 2007 11:08:30 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5496A13C484 for ; Mon, 12 Mar 2007 11:08:30 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2CB8Ul9065149 for ; Mon, 12 Mar 2007 11:08:30 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2CB8SAl065145 for freebsd-net@FreeBSD.org; Mon, 12 Mar 2007 11:08:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Mar 2007 11:08:28 GMT Message-Id: <200703121108.l2CB8SAl065145@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 11:08:30 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit o kern/106722 net [net] [patch] ifconfig may not connect an interface to o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi 7 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch a bin/94920 net [rpc] rpc.statd(8) conflict with cups over tcp and udp o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/100519 net [netisr] suggestion to fix suboptimal network polling a bin/100969 net [rpc.lockd] rpc.lockd conflict with cups over udp port o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net bridge interface given in rc.conf not taking an (stati 13 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 11:22:33 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 263AA16A400; Mon, 12 Mar 2007 11:22:33 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id C05E213C45E; Mon, 12 Mar 2007 11:22:31 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2CBKwQX062075; Mon, 12 Mar 2007 14:20:58 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2CBKuA3062068; Mon, 12 Mar 2007 14:20:57 +0300 (MSK) (envelope-from yar) Date: Mon, 12 Mar 2007 14:20:56 +0300 From: Yar Tikhiy To: "Bruce M. Simpson" Message-ID: <20070312112056.GC44732@comp.chem.msu.su> References: <45E9F1E8.2000802@inse.ru> <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45F51F2B.5020906@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: rik@freebsd.org, andre@freebsd.org, freebsd-net@freebsd.org, thompsa@freebsd.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 11:22:33 -0000 On Mon, Mar 12, 2007 at 09:36:43AM +0000, Bruce M. Simpson wrote: > Hi, > > Eygene Ryabinkin wrote: > > > >Speaking about vlan problems: the original problem is to do something > >with VLAN interfaces only because they are sharing the MAC of their > >physical parent. The problem itself is not VLAN-specific -- if there > >will be two physical interfaces with the same MACs and they will be > >bridged, the problem will still be here. > > > I see this also. > > What would be good is if there was a way to record additional MAC > addresses for each ifnet, in addition to the if_lladdr member. This > would cut down the cruft in ether_input(), if_bridge(4) and possibly > also carp(4). > > For network cards with more than one perfect hash filter entry in the > hardware, programming these into the card would *perhaps* be more > efficient when trying to achieve line rate with gigabit and beyond. > > This would most likely require an ABI change. The VLAN handling problem > doesn't go away; we will still need to check if a bridge member is a > VLAN interface because we can't uniquely key off the MAC as you point out. Guys, excuse me, but I still fail to see how the case of VLANs' sharing a single MAC differs from the case of several physical interfaces with the same MAC from the POV of a bridge. A bridge can have no own MAC addresses at all, it plays with foreign MAC addresses only. Therefore I can't see why our bridge code needs to know local MAC addresses, let alone why it fails when they're the same. Could you give me a hint? Thanks! -- Yar From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 11:56:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4DE7216A404; Mon, 12 Mar 2007 11:56:40 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 021CE13C44B; Mon, 12 Mar 2007 11:56:39 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HQj8o-000Nbq-HZ; Mon, 12 Mar 2007 14:56:38 +0300 Date: Mon, 12 Mar 2007 14:56:33 +0300 From: Eygene Ryabinkin To: Yar Tikhiy Message-ID: <20070312115632.GP58523@codelabs.ru> References: <45E9F1E8.2000802@inse.ru> <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070312112056.GC44732@comp.chem.msu.su> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: rik@freebsd.org, andre@freebsd.org, freebsd-net@freebsd.org, thompsa@freebsd.org, "Bruce M. Simpson" Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 11:56:40 -0000 Yar, good day. Mon, Mar 12, 2007 at 02:20:56PM +0300, Yar Tikhiy wrote: > On Mon, Mar 12, 2007 at 09:36:43AM +0000, Bruce M. Simpson wrote: > > Eygene Ryabinkin wrote: > > > > > >Speaking about vlan problems: the original problem is to do something > > >with VLAN interfaces only because they are sharing the MAC of their > > >physical parent. The problem itself is not VLAN-specific -- if there > > >will be two physical interfaces with the same MACs and they will be > > >bridged, the problem will still be here. > > > > > I see this also. > > > > What would be good is if there was a way to record additional MAC > > addresses for each ifnet, in addition to the if_lladdr member. This > > would cut down the cruft in ether_input(), if_bridge(4) and possibly > > also carp(4). > > > > For network cards with more than one perfect hash filter entry in the > > hardware, programming these into the card would *perhaps* be more > > efficient when trying to achieve line rate with gigabit and beyond. > > > > This would most likely require an ABI change. The VLAN handling problem > > doesn't go away; we will still need to check if a bridge member is a > > VLAN interface because we can't uniquely key off the MAC as you point out. > > Guys, excuse me, but I still fail to see how the case of VLANs' > sharing a single MAC differs from the case of several physical > interfaces with the same MAC from the POV of a bridge. It does not differ at all, you're right. VLAN case is just an illustration for the problem, but the problem itself is not limited to a VLAN interfaces. > A bridge can have no own MAC addresses at all, it plays with foreign MAC > addresses only. Therefore I can't see why our bridge code needs > to know local MAC addresses, let alone why it fails when they're > the same. Could you give me a hint? Thanks! This is a different point. The bridge wants to know about bridge members MACs just because it should catch the packets that are destined to the bridge members. It is the only way for an L2 thing that is operating in the promiscious mode. For our case (when MACs are the same): I think that rik@ has explained it rather good, so you should read his message once again. Perhaps, we can talk about this off-list and in Russian, if you prefer. -- Eygene From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 12:11:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D5A716A401; Mon, 12 Mar 2007 12:11:25 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C659D13C46A; Mon, 12 Mar 2007 12:11:24 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HQjN5-000Nci-1k; Mon, 12 Mar 2007 15:11:23 +0300 Date: Mon, 12 Mar 2007 15:11:17 +0300 From: Eygene Ryabinkin To: "Bruce M. Simpson" Message-ID: <20070312121117.GQ58523@codelabs.ru> References: <45E9F1E8.2000802@inse.ru> <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <45F51F2B.5020906@FreeBSD.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: rik@FreeBSD.org, freebsd-net@freebsd.org, glebius@FreeBSD.org, andre@FreeBSD.org, thompsa@FreeBSD.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 12:11:25 -0000 Bruce, Mon, Mar 12, 2007 at 09:36:43AM +0000, Bruce M. Simpson wrote: > > >Speaking about vlan problems: the original problem is to do something > >with VLAN interfaces only because they are sharing the MAC of their > >physical parent. The problem itself is not VLAN-specific -- if there > >will be two physical interfaces with the same MACs and they will be > >bridged, the problem will still be here. > > > I see this also. > > What would be good is if there was a way to record additional > MAC addresses for each ifnet, in addition to the if_lladdr member. > This would cut down the cruft in ether_input(), if_bridge(4) > and possibly also carp(4). Am I understand you correctly that you want to see many MAC addresses on the physical interface that is 'hosting' VLAN interfaces and each VLAN if will have its own MAC? >For network cards with more than one perfect hash filter entry in the hardware, > programming these into the card would *perhaps* be more efficient when trying > to achieve line rate with gigabit and beyond. Sure, but for the commodity hardware it will be the overhead to go into the promiscious mode and to filter the packets by multiple MACs. Or you see any other way to do it on the software. > >This would most likely require an ABI change. The VLAN handling problem doesn't > go away; we will still need to check if a bridge member is a VLAN interface > because we can't uniquely key off the MAC as you point out. We're not checking if the interface member is a VLAN interface. We just do the generic checks for the incoming interface. rik@ will send the patch today, at least he just promised me ;)) The only problem that will stay here after our patch is that the pfil will see the 'logical' interface, not the physical one. And if the logical destination interface will have non-unique MAC, then we will again fail to get the right one. But this problem is only pfil-specific: the stack will get the packet in any way, but pfil will get the wrong interface (see rik's long mail in this thread). I did the patch that enables the pfil to see the physical incoming interface for the bridge (it adds one more pfil pass for the packet). I will raise the topic when our patch will be committed (or will not be committed ;((). -- Eygene From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 13:09:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B049016A402; Mon, 12 Mar 2007 13:09:16 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC8913C44B; Mon, 12 Mar 2007 13:09:16 +0000 (UTC) (envelope-from rik@inse.ru) Received: from [127.0.0.1] (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTP id 55FFA33C4F; Mon, 12 Mar 2007 16:09:14 +0300 (MSK) Message-ID: <45F5520B.80709@inse.ru> Date: Mon, 12 Mar 2007 16:13:47 +0300 From: Roman Kurakin User-Agent: Thunderbird 1.5.0.7 (X11/20061110) MIME-Version: 1.0 To: Eygene Ryabinkin References: <45E9F1E8.2000802@inse.ru> <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312121117.GQ58523@codelabs.ru> In-Reply-To: <20070312121117.GQ58523@codelabs.ru> Content-Type: multipart/mixed; boundary="------------080308030607070800070004" Cc: rik@FreeBSD.org, andre@FreeBSD.org, freebsd-net@freebsd.org, glebius@FreeBSD.org, thompsa@FreeBSD.org, "Bruce M. Simpson" Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 13:09:16 -0000 This is a multi-part message in MIME format. --------------080308030607070800070004 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Eygene Ryabinkin wrote: > [...] > We're not checking if the interface member is a VLAN interface. We just > do the generic checks for the incoming interface. rik@ will send the > patch today, at least he just promised me ;)) > Here it is. I'll check it for compilation this evening and I hope Eygene will be able to put it in a production for testings. I've found one more strange place in the code. Probably it is not a problem but I do not understand smth. How common the situation that we get our own packets on the bridge? Probably we could do some optimization around this case ... From the original commit (in OpenBSD IIRC) that adds this check it is not clear why it was added. rik --------------080308030607070800070004 Content-Type: text/plain; name="fbsd070312-3.pch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fbsd070312-3.pch" Index: if_bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_bridge.c,v retrieving revision 1.94 diff -u -r1.94 if_bridge.c --- if_bridge.c 9 Mar 2007 19:34:55 -0000 1.94 +++ if_bridge.c 12 Mar 2007 12:50:45 -0000 @@ -2121,42 +2121,62 @@ return (m); } +#ifdef DEV_CARP +# define OR_CARP_CHECK_WE_ARE_DST(iface) \ + || ((iface)->if_carp \ + && carp_forus((iface)->if_carp, eh->ether_dhost)) +# define OR_CARP_CHECK_WE_ARE_SRC(iface) \ + || ((iface)->if_carp \ + && carp_forus((iface)->if_carp, eh->ether_shost)) +#else +# define OR_CARP_CHECK_WE_ARE_DST(iface) +# define OR_CARP_CHECK_WE_ARE_SRC(iface) +#endif + +#define GRAB_OUR_PACKETS(iface) \ + if ((iface)->if_type == IFT_GIF) \ + continue; \ + /* It is destined for us. */ \ + if (memcmp(IF_LLADDR((iface)), eh->ether_dhost, ETHER_ADDR_LEN) == 0 \ + OR_CARP_CHECK_WE_ARE_DST((iface)) \ + ) { \ + if (bif->bif_flags & IFBIF_LEARNING) \ + (void) bridge_rtupdate(sc, \ + eh->ether_shost, bif, 0, IFBAF_DYNAMIC); \ + m->m_pkthdr.rcvif = iface; \ + BRIDGE_UNLOCK(sc); \ + return (m); \ + } \ + \ + /* We just received a packet that we sent out. */ \ + if (memcmp(IF_LLADDR((iface)), eh->ether_shost, ETHER_ADDR_LEN) == 0 \ + OR_CARP_CHECK_WE_ARE_SRC((iface)) \ + ) { \ + BRIDGE_UNLOCK(sc); \ + m_freem(m); \ + return (NULL); \ + } + /* * Unicast. Make sure it's not for us. + * + * Give a chance for ifp at first priority. This will help when the + * packet comes through the interface like VLAN's with the same MACs + * on several interfaces from the same bridge. This also will save + * some CPU cycles in case the destination interface and the input + * interface (eq ifp) are the same. */ - LIST_FOREACH(bif2, &sc->sc_iflist, bif_next) { - if (bif2->bif_ifp->if_type == IFT_GIF) - continue; - /* It is destined for us. */ - if (memcmp(IF_LLADDR(bif2->bif_ifp), eh->ether_dhost, - ETHER_ADDR_LEN) == 0 -#ifdef DEV_CARP - || (bif2->bif_ifp->if_carp - && carp_forus(bif2->bif_ifp->if_carp, eh->ether_dhost)) -#endif - ) { - if (bif->bif_flags & IFBIF_LEARNING) - (void) bridge_rtupdate(sc, - eh->ether_shost, bif, 0, IFBAF_DYNAMIC); - m->m_pkthdr.rcvif = bif2->bif_ifp; - BRIDGE_UNLOCK(sc); - return (m); - } + do { GRAB_OUR_PACKETS(ifp) } while (0); - /* We just received a packet that we sent out. */ - if (memcmp(IF_LLADDR(bif2->bif_ifp), eh->ether_shost, - ETHER_ADDR_LEN) == 0 -#ifdef DEV_CARP - || (bif2->bif_ifp->if_carp - && carp_forus(bif2->bif_ifp->if_carp, eh->ether_shost)) -#endif - ) { - BRIDGE_UNLOCK(sc); - m_freem(m); - return (NULL); - } + /* Now check the all bridge members. */ + LIST_FOREACH(bif2, &sc->sc_iflist, bif_next) { + GRAB_OUR_PACKETS(bif2->bif_ifp) } +#undef OR_CARP_CHECK_WE_ARE_DST +#undef OR_CARP_CHECK_WE_ARE_SRC +#undef GRAB_OUR_PACKETS + /* Perform the bridge forwarding function. */ bridge_forward(sc, m); --------------080308030607070800070004-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 13:20:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0323616A400; Mon, 12 Mar 2007 13:20:54 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id C627913C4B9; Mon, 12 Mar 2007 13:20:53 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id E6E171F7C96; Mon, 12 Mar 2007 09:20:53 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 12 Mar 2007 09:20:53 -0400 X-Sasl-enc: Fc/TiznSOgSvhm+i/tPiH1GJn9aylV7uJFWktvc/AS/M 1173705653 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 4F5862292; Mon, 12 Mar 2007 09:20:51 -0400 (EDT) Message-ID: <45F553B2.6070508@FreeBSD.org> Date: Mon, 12 Mar 2007 13:20:50 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Eygene Ryabinkin References: <45E9F1E8.2000802@inse.ru> <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <20070312115632.GP58523@codelabs.ru> In-Reply-To: <20070312115632.GP58523@codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: rik@freebsd.org, andre@freebsd.org, Yar Tikhiy , thompsa@freebsd.org, freebsd-net@freebsd.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 13:20:54 -0000 Eygene Ryabinkin wrote: > This is a different point. The bridge wants to know about bridge > members MACs just because it should catch the packets that are > destined to the bridge members. It is the only way for an L2 thing > that is operating in the promiscious mode. > Correct. > For our case (when MACs are the same): I think that rik@ has explained > it rather good, so you should read his message once again. Perhaps, > we can talk about this off-list and in Russian, if you prefer. > The problem isn't going to go away. It will get bigger when 802.3ad trunking is introduced. Andrew Thompson is currently working on this code. It may also affect the 802.11 code in future, which as you know is layered around Ethernet. It would be good to have a well thought out architectural solution for this problem. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 13:26:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA58616A40B; Mon, 12 Mar 2007 13:26:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 89A0413C4B9; Mon, 12 Mar 2007 13:26:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id BA9071F7CC9; Mon, 12 Mar 2007 09:26:16 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Mon, 12 Mar 2007 09:26:16 -0400 X-Sasl-enc: QMbZKKF2Za0UmkU72edo6HttRUn1I+nlXSVTmAPsAmY8 1173705976 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id DDF3B1D2DB; Mon, 12 Mar 2007 09:26:14 -0400 (EDT) Message-ID: <45F554F5.8020505@FreeBSD.org> Date: Mon, 12 Mar 2007 13:26:13 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Yar Tikhiy References: <45E9F1E8.2000802@inse.ru> <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> In-Reply-To: <20070312112056.GC44732@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rik@freebsd.org, andre@freebsd.org, freebsd-net@freebsd.org, thompsa@freebsd.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 13:26:16 -0000 Yar Tikhiy wrote: > Guys, excuse me, but I still fail to see how the case of VLANs' > sharing a single MAC differs from the case of several physical > interfaces with the same MAC from the POV of a bridge. A bridge > can have no own MAC addresses at all, it plays with foreign MAC > addresses only. Therefore I can't see why our bridge code needs > to know local MAC addresses, let alone why it fails when they're > the same. Could you give me a hint? Thanks! > A few points: 1. A bridge *does* have a MAC address; it is automatically assigned one to participate in IEEE 802.1d Spanning Tree. 2. In the case where 802.3ad trunking is implemented, the same Ethernet address may be used by multiple physical interfaces. 3. As Eygene explained well: there are a number of consumers of Ethernet frames in the stack. As if_bridge may potentially be passed mbuf chains containing packets for these consumers first, it must examine the destination address to determine if it should claim the packet or not. Finally, because of the above points, the Ethernet destination address cannot be regarded as a unique key in the bridge code, or indeed the general Ethernet path, for where packets should be relayed in the stack as a whole. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 13:46:29 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0C3616A400 for ; Mon, 12 Mar 2007 13:46:29 +0000 (UTC) (envelope-from bohra@cs.rutgers.edu) Received: from mail.nec-labs.com (mail.nec-labs.com [138.15.200.209]) by mx1.freebsd.org (Postfix) with ESMTP id 7636513C459 for ; Mon, 12 Mar 2007 13:46:29 +0000 (UTC) (envelope-from bohra@cs.rutgers.edu) Received: from mail.nec-labs.com (localhost.localdomain [127.0.0.1]) by mail.nec-labs.com (8.13.6/8.13.6) with ESMTP id l2CDRP6g030555 for ; Mon, 12 Mar 2007 09:27:25 -0400 Received: from mailer.nec-labs.com (mailer.nec-labs.com [138.15.108.3]) by mail.nec-labs.com (8.13.6/8.13.6) with ESMTP id l2CDRPVf030549 for ; Mon, 12 Mar 2007 09:27:25 -0400 Received: from [138.15.109.80] ([138.15.109.80] unverified) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Mar 2007 09:28:40 -0400 Message-ID: <45F55575.9040401@cs.rutgers.edu> Date: Mon, 12 Mar 2007 09:28:21 -0400 From: Aniruddha Bohra User-Agent: Thunderbird 1.5.0.9 (X11/20070217) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------080009090601050000060200" X-OriginalArrivalTime: 12 Mar 2007 13:28:40.0599 (UTC) FILETIME=[59225A70:01C764AA] Subject: [PATCH] Removal of redundant entries from ifnet manpage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 13:46:29 -0000 This is a multi-part message in MIME format. --------------080009090601050000060200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The ifnet manpage contains entries for the following routines which do not exist in the ifnet struct. The attached patch removes these entries. if_done if_poll_recv if_poll_xmit if_poll_inttrn if_poll_slowinput Thanks Aniruddha --------------080009090601050000060200 Content-Type: text/x-patch; name="ifnet.9.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ifnet.9.patch" Index: ifnet.9 =================================================================== RCS file: /home/ncvs/src/share/man/man9/ifnet.9,v retrieving revision 1.52 diff -u -r1.52 ifnet.9 --- ifnet.9 14 Dec 2006 14:33:13 -0000 1.52 +++ ifnet.9 15 Nov 2006 18:01:46 -0000 @@ -103,19 +103,9 @@ .Ft void .Fn \*(lp*if_start\*(rp "struct ifnet *ifp" .Ft int -.Fn \*(lp*if_done\*(rp "struct ifnet *ifp" -.Ft int .Fn \*(lp*if_ioctl\*(rp "struct ifnet *ifp" "int cmd" "caddr_t data" .Ft void .Fn \*(lp*if_watchdog\*(rp "struct ifnet *ifp" -.Ft int -.Fn \*(lp*if_poll_recv\*(rp "struct ifnet *ifp" "int *quotap" -.Ft int -.Fn \*(lp*if_poll_xmit\*(rp "struct ifnet *ifp" "int *quotap" -.Ft void -.Fn \*(lp*if_poll_inttrn\*(rp "struct ifnet *ifp" -.Ft void -.Fn \*(lp*if_poll_slowinput\*(rp "struct ifnet *ifp" "struct mbuf *m" .Ft void .Fn \*(lp*if_init\*(rp "void *if_softc" .Ft int --------------080009090601050000060200-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 14:03:05 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DC4E16A400; Mon, 12 Mar 2007 14:03:05 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 1643713C469; Mon, 12 Mar 2007 14:03:03 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2CE2KkG067575; Mon, 12 Mar 2007 17:02:20 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2CE2KuK067574; Mon, 12 Mar 2007 17:02:20 +0300 (MSK) (envelope-from yar) Date: Mon, 12 Mar 2007 17:02:19 +0300 From: Yar Tikhiy To: "Bruce M. Simpson" Message-ID: <20070312140219.GE44732@comp.chem.msu.su> References: <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45F554F5.8020505@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: rik@FreeBSD.org, andre@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org, thompsa@FreeBSD.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 14:03:05 -0000 On Mon, Mar 12, 2007 at 01:26:13PM +0000, Bruce M. Simpson wrote: > Yar Tikhiy wrote: > >Guys, excuse me, but I still fail to see how the case of VLANs' > >sharing a single MAC differs from the case of several physical > >interfaces with the same MAC from the POV of a bridge. A bridge > >can have no own MAC addresses at all, it plays with foreign MAC > >addresses only. Therefore I can't see why our bridge code needs > >to know local MAC addresses, let alone why it fails when they're > >the same. Could you give me a hint? Thanks! > > > > A few points: > > 1. A bridge *does* have a MAC address; it is automatically assigned one > to participate in IEEE 802.1d Spanning Tree. Well, I'd say it *can* have a MAC address if it wants to participate in STP. > 2. In the case where 802.3ad trunking is implemented, the same Ethernet > address may be used by multiple physical interfaces. > > 3. As Eygene explained well: there are a number of consumers of > Ethernet frames in the stack. As if_bridge may potentially be passed > mbuf chains containing packets for these consumers first, it must > examine the destination address to determine if it should claim the > packet or not. > > Finally, because of the above points, the Ethernet destination address > cannot be regarded as a unique key in the bridge code, or indeed the > general Ethernet path, for where packets should be relayed in the stack > as a whole. But why are we relying solely on the Ethernet destination address? Each frame was received via a particular interface, which is recorded in mbuf's recvif. As the frame moves between levels of abstraction, such as a physical interface, vlan, bridge, recvif can change, but at each level the pointer to an entity in the previous level should be enough, shouldn't it? E.g., if several vlan interfaces are bridged, if_bridge shouldn't need to know which physical interfaces are used by the vlans. OTOH, it can know which particular vlan the frame came through, although vlan MACs can be the same. -- Yar From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 14:38:21 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F74C16A402; Mon, 12 Mar 2007 14:38:21 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 2FCAD13C46A; Mon, 12 Mar 2007 14:38:21 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HQlfF-000Np3-1j; Mon, 12 Mar 2007 17:38:17 +0300 Date: Mon, 12 Mar 2007 17:38:11 +0300 From: Eygene Ryabinkin To: Yar Tikhiy Message-ID: <20070312143811.GA58523@codelabs.ru> References: <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070312140219.GE44732@comp.chem.msu.su> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: rik@FreeBSD.org, andre@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org, thompsa@FreeBSD.org, "Bruce M. Simpson" Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 14:38:21 -0000 Yar, > > 2. In the case where 802.3ad trunking is implemented, the same Ethernet > > address may be used by multiple physical interfaces. > > > > 3. As Eygene explained well: there are a number of consumers of > > Ethernet frames in the stack. As if_bridge may potentially be passed > > mbuf chains containing packets for these consumers first, it must > > examine the destination address to determine if it should claim the > > packet or not. > > > > Finally, because of the above points, the Ethernet destination address > > cannot be regarded as a unique key in the bridge code, or indeed the > > general Ethernet path, for where packets should be relayed in the stack > > as a whole. > > But why are we relying solely on the Ethernet destination address? Probably because if_bridge is written for Ethernet, 802.11 and may be some other 802 interfaces: ----- DESCRIPTION The if_bridge driver creates a logical link between two or more IEEE 802 networks that use the same (or ``similar enough'') framing format. For example, it is possible to bridge Ethernet and 802.11 networks together, but it is not possible to bridge Ethernet and Token Ring together. ----- > Each frame was received via a particular interface, which is recorded > in mbuf's recvif. As the frame moves between levels of abstraction, > such as a physical interface, vlan, bridge, recvif can change, but > at each level the pointer to an entity in the previous level should > be enough, shouldn't it? Excuse me, but are we talking about the problem that is cured by our patch, or about some general points? If about the former, then this problem shows up only for the packet that is destined for the local interface at the L2. And the pfil gots the wrong interface name due to the bug. > E.g., if several vlan interfaces are > bridged, if_bridge shouldn't need to know which physical interfaces > are used by the vlans. OTOH, it can know which particular vlan the > frame came through, although vlan MACs can be the same. And who is saying that if_bridge should need to know about the underlying (parent) interface for the VLAN? The word 'physical' that we use here denotes the VLAN interface in which the packet showed up at ether_input. And the word 'logical' means the interface that the L2 packet is destined for. Perhaps it is the source of confusion? -- Eygene From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 15:00:09 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C121A16A403 for ; Mon, 12 Mar 2007 15:00:09 +0000 (UTC) (envelope-from ale@seudns.net) Received: from connectmed.com.br (s200-189-171-55.ipb.diveo.net.br [200.189.171.55]) by mx1.freebsd.org (Postfix) with SMTP id E456113C4B8 for ; Mon, 12 Mar 2007 15:00:08 +0000 (UTC) (envelope-from ale@seudns.net) Received: (qmail 16999 invoked from network); 12 Mar 2007 14:30:14 -0000 Received: from unknown (HELO caco-new) (200.189.171.49) by donald.connectmed.com.br with SMTP; 12 Mar 2007 14:30:14 -0000 Received: (qmail 13294 invoked from network); 12 Mar 2007 14:33:26 -0000 Received: from unknown (HELO ?192.168.3.109?) (192.168.3.109) by localhost with SMTP; 12 Mar 2007 14:33:25 -0000 Message-ID: <45F564B5.10307@seudns.net> Date: Mon, 12 Mar 2007 11:33:25 -0300 From: Alexandre Biancalana User-Agent: Thunderbird 1.5.0.9 (X11/20070206) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 15:00:09 -0000 Hi List, I´m doing a firewall setup using 6-STABLE + PF with two internet links but I can't do the route-to rule function as I need. (default gw) ______ Link A <-----------> |int A | | | Link B <-----------> |int B | |______| FreeBSD FW A simple thing that I need to do is test the two Internet links to know if they are up or not. To do this I could ping or connect tcp ports on some external ips thought each link, using nc and hping I tried do this generate connections/packets from each network interface connected to each link but the packets always go out by the interface indicated by machines default route. I tried to add this rules in pf to force packets out by the right interface based in your source address, but this does not work, and the packets generated with ip of int B are going out by int A. pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to any pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to any Am I forgetting something ? Any comments ? Regards, Alexandre From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 16:47:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D70F816A402 for ; Mon, 12 Mar 2007 16:47:34 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog10.obsmtp.com (s200aog10.obsmtp.com [207.126.144.124]) by mx1.freebsd.org (Postfix) with SMTP id 289B613C4B9 for ; Mon, 12 Mar 2007 16:47:21 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob010.postini.com ([207.126.147.11]) with SMTP; Mon, 12 Mar 2007 16:47:20 UTC Received: from [10.0.0.79] (bwb.mintel.co.uk [10.0.0.79]) by rodney.mintel.co.uk (Postfix) with ESMTP id 3AA1C181428; Mon, 12 Mar 2007 16:47:20 +0000 (GMT) Message-ID: <45F58321.5050309@tomjudge.com> Date: Mon, 12 Mar 2007 16:43:13 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandre Biancalana References: <45F564B5.10307@seudns.net> In-Reply-To: <45F564B5.10307@seudns.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 16:47:34 -0000 Alexandre Biancalana wrote: > Hi List, > > > I´m doing a firewall setup using 6-STABLE + PF with two internet links > but I can't do the route-to rule function as I need. > > > (default gw) ______ > Link A <-----------> |int A | > | | > Link B <-----------> |int B | > |______| > FreeBSD FW > > A simple thing that I need to do is test the two Internet links to know > if they are up or not. To do this I could ping or connect tcp ports on > some external ips thought each link, using nc and hping I tried do this > generate connections/packets from each network interface connected to > each link but the packets always go out by the interface indicated by > machines default route. > > I tried to add this rules in pf to force packets out by the right > interface based in your source address, but this does not work, and the > packets generated with ip of int B are going out by int A. > > pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to any > pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to any > > > Am I forgetting something ? Any comments ? > Have you tried setting the source IP address to int B when using ping your tcp sessions, this should force PF to do your source routing for you. Hope this helps Tom From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 16:52:29 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A415316A402; Mon, 12 Mar 2007 16:52:29 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id C7DCA13C457; Mon, 12 Mar 2007 16:52:27 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2CGppBV070105; Mon, 12 Mar 2007 19:51:51 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2CGpjmQ070100; Mon, 12 Mar 2007 19:51:45 +0300 (MSK) (envelope-from yar) Date: Mon, 12 Mar 2007 19:51:45 +0300 From: Yar Tikhiy To: Eygene Ryabinkin Message-ID: <20070312165145.GF44732@comp.chem.msu.su> References: <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070312143811.GA58523@codelabs.ru> User-Agent: Mutt/1.5.9i Cc: rik@FreeBSD.org, andre@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org, thompsa@FreeBSD.org, "Bruce M. Simpson" Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 16:52:29 -0000 On Mon, Mar 12, 2007 at 05:38:11PM +0300, Eygene Ryabinkin wrote: > Yar, > > > > 2. In the case where 802.3ad trunking is implemented, the same Ethernet > > > address may be used by multiple physical interfaces. > > > > > > 3. As Eygene explained well: there are a number of consumers of > > > Ethernet frames in the stack. As if_bridge may potentially be passed > > > mbuf chains containing packets for these consumers first, it must > > > examine the destination address to determine if it should claim the > > > packet or not. > > > > > > Finally, because of the above points, the Ethernet destination address > > > cannot be regarded as a unique key in the bridge code, or indeed the > > > general Ethernet path, for where packets should be relayed in the stack > > > as a whole. > > > > But why are we relying solely on the Ethernet destination address? > > Probably because if_bridge is written for Ethernet, 802.11 and > may be some other 802 interfaces: > ----- > DESCRIPTION > The if_bridge driver creates a logical link between two or more IEEE 802 > networks that use the same (or ``similar enough'') framing format. For > example, it is possible to bridge Ethernet and 802.11 networks together, > but it is not possible to bridge Ethernet and Token Ring together. > ----- The IEEE standards don't prevent us from keeping the pointer to the receive interface and using it to identify the interface unambiguously. That's what I meant. > > Each frame was received via a particular interface, which is recorded > > in mbuf's recvif. As the frame moves between levels of abstraction, > > such as a physical interface, vlan, bridge, recvif can change, but > > at each level the pointer to an entity in the previous level should > > be enough, shouldn't it? > > Excuse me, but are we talking about the problem that is cured by > our patch, or about some general points? If about the former, then > this problem shows up only for the packet that is destined for the > local interface at the L2. And the pfil gots the wrong interface name > due to the bug. A patch is unlikely to be correct if it's based on wrong assumptions. > > E.g., if several vlan interfaces are > > bridged, if_bridge shouldn't need to know which physical interfaces > > are used by the vlans. OTOH, it can know which particular vlan the > > frame came through, although vlan MACs can be the same. > > And who is saying that if_bridge should need to know about the > underlying (parent) interface for the VLAN? The word 'physical' that > we use here denotes the VLAN interface in which the packet showed up > at ether_input. And the word 'logical' means the interface that > the L2 packet is destined for. Perhaps it is the source of confusion? Quite likely. Even pfil is confused. ;^) As I've managed to figure out finally, the "physical" interface (in this discussion) is the interface the L2 packet actually came from, and the "logical" one just bears the MAC address equal to that in the destination field of the packet. The problem is that we cannot determine the "logical" interface reliably in the presence of interfaces sharing the same MAC address. No hacks can help us with that. Assume that a host has two physical interfaces, say, em0 and em1, with different MAC addresses. We set up a few vlans on the former and a few vlans on the latter, and then bridge all vlans together. Now an Ethernet packet comes via, say, em0.7, with its destination MAC address equal to that of em1 (and its vlans). Which of em1.* vlans would you "logically" assign the packet to, and why? I'm afraid there is a serious flaw in the very notion of such a "logical" interface. If it's true, we should start by admitting that the support for "logical" interfaces should be a side hack for compatibility, and not something that can live forever on the main code path. -- Yar From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 17:01:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B551916A400 for ; Mon, 12 Mar 2007 17:01:24 +0000 (UTC) (envelope-from ale@seudns.net) Received: from connectmed.com.br (s200-189-171-55.ipb.diveo.net.br [200.189.171.55]) by mx1.freebsd.org (Postfix) with SMTP id E5DB113C465 for ; Mon, 12 Mar 2007 17:01:19 +0000 (UTC) (envelope-from ale@seudns.net) Received: (qmail 24192 invoked from network); 12 Mar 2007 16:58:01 -0000 Received: from unknown (HELO caco-new) (200.189.171.49) by donald.connectmed.com.br with SMTP; 12 Mar 2007 16:58:01 -0000 Received: (qmail 30517 invoked from network); 12 Mar 2007 17:01:14 -0000 Received: from unknown (HELO ?192.168.3.109?) (192.168.3.109) by localhost with SMTP; 12 Mar 2007 17:01:12 -0000 Message-ID: <45F58758.6090103@seudns.net> Date: Mon, 12 Mar 2007 14:01:12 -0300 From: Alexandre Biancalana User-Agent: Thunderbird 1.5.0.9 (X11/20070206) MIME-Version: 1.0 To: Tom Judge References: <45F564B5.10307@seudns.net> <45F58321.5050309@tomjudge.com> In-Reply-To: <45F58321.5050309@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 17:01:24 -0000 Tom Judge wrote: > Alexandre Biancalana wrote: >> Hi List, >> >> >> I´m doing a firewall setup using 6-STABLE + PF with two internet >> links but I can't do the route-to rule function as I need. >> >> >> (default gw) ______ >> Link A <-----------> |int A | >> | | >> Link B <-----------> |int B | >> |______| >> FreeBSD FW >> >> A simple thing that I need to do is test the two Internet links to >> know if they are up or not. To do this I could ping or connect tcp >> ports on some external ips thought each link, using nc and hping I >> tried do this generate connections/packets from each network >> interface connected to each link but the packets always go out by the >> interface indicated by machines default route. >> >> I tried to add this rules in pf to force packets out by the right >> interface based in your source address, but this does not work, and >> the packets generated with ip of int B are going out by int A. >> >> pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to any >> pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to any >> >> >> Am I forgetting something ? Any comments ? >> > > Have you tried setting the source IP address to int B when using ping > your tcp sessions, this should force PF to do your source routing for > you. > > Hope this helps > > Tom Yes, I tried the following commands: ping -S nc -s hping -I All the commands generate the traffic with source address of int B, but the traffic always go out by int A... this is the problem, even with the rules: pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to any pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to any that should "correct" the interface used send this traffic out... right ?! I can provide more details if need, but I think that is a simple setup... I can't see why this does not work.... any other ideas ?? Regards, Alexandre From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 17:10:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 930AB16A41B for ; Mon, 12 Mar 2007 17:10:58 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog12.obsmtp.com (s200aog12.obsmtp.com [207.126.144.126]) by mx1.freebsd.org (Postfix) with SMTP id 7DAEE13C4C2 for ; Mon, 12 Mar 2007 17:10:46 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob012.postini.com ([207.126.147.11]) with SMTP; Mon, 12 Mar 2007 17:10:44 UTC Received: from [10.0.0.79] (bwb.mintel.co.uk [10.0.0.79]) by rodney.mintel.co.uk (Postfix) with ESMTP id 3F58B181449; Mon, 12 Mar 2007 17:10:44 +0000 (GMT) Message-ID: <45F5889C.3010806@tomjudge.com> Date: Mon, 12 Mar 2007 17:06:36 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandre Biancalana References: <45F564B5.10307@seudns.net> <45F58321.5050309@tomjudge.com> <45F58758.6090103@seudns.net> In-Reply-To: <45F58758.6090103@seudns.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 17:10:58 -0000 Alexandre Biancalana wrote: > Tom Judge wrote: >> Alexandre Biancalana wrote: >>> Hi List, >>> >>> >>> I´m doing a firewall setup using 6-STABLE + PF with two internet >>> links but I can't do the route-to rule function as I need. >>> >>> >>> (default gw) ______ >>> Link A <-----------> |int A | >>> | | >>> Link B <-----------> |int B | >>> |______| >>> FreeBSD FW >>> >>> A simple thing that I need to do is test the two Internet links to >>> know if they are up or not. To do this I could ping or connect tcp >>> ports on some external ips thought each link, using nc and hping I >>> tried do this generate connections/packets from each network >>> interface connected to each link but the packets always go out by the >>> interface indicated by machines default route. >>> >>> I tried to add this rules in pf to force packets out by the right >>> interface based in your source address, but this does not work, and >>> the packets generated with ip of int B are going out by int A. >>> >>> pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to any >>> pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to any >>> >>> >>> Am I forgetting something ? Any comments ? >>> >> >> Have you tried setting the source IP address to int B when using ping >> your tcp sessions, this should force PF to do your source routing for >> you. >> >> Hope this helps >> >> Tom > > Yes, I tried the following commands: > > ping -S > nc -s > hping -I > > All the commands generate the traffic with source address of int B, but > the traffic always go out by int A... this is the problem, even with the > rules: > > pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to any > pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to any > > that should "correct" the interface used send this traffic out... right ?! > > I can provide more details if need, but I think that is a simple > setup... I can't see why this does not work.... any other ideas ?? > Did you try: ping -S -I Tom From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 17:19:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C53A616A401 for ; Mon, 12 Mar 2007 17:19:19 +0000 (UTC) (envelope-from ale@seudns.net) Received: from connectmed.com.br (s200-189-171-55.ipb.diveo.net.br [200.189.171.55]) by mx1.freebsd.org (Postfix) with SMTP id F1DAC13C44C for ; Mon, 12 Mar 2007 17:19:18 +0000 (UTC) (envelope-from ale@seudns.net) Received: (qmail 4015 invoked from network); 12 Mar 2007 17:16:04 -0000 Received: from unknown (HELO caco-new) (200.189.171.49) by donald.connectmed.com.br with SMTP; 12 Mar 2007 17:16:04 -0000 Received: (qmail 32207 invoked from network); 12 Mar 2007 17:19:16 -0000 Received: from unknown (HELO ?192.168.3.109?) (192.168.3.109) by localhost with SMTP; 12 Mar 2007 17:19:16 -0000 Message-ID: <45F58B94.9000308@seudns.net> Date: Mon, 12 Mar 2007 14:19:16 -0300 From: Alexandre Biancalana User-Agent: Thunderbird 1.5.0.9 (X11/20070206) MIME-Version: 1.0 To: Tom Judge References: <45F564B5.10307@seudns.net> <45F58321.5050309@tomjudge.com> <45F58758.6090103@seudns.net> <45F5889C.3010806@tomjudge.com> In-Reply-To: <45F5889C.3010806@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 17:19:19 -0000 Tom Judge wrote: > Alexandre Biancalana wrote: >> Tom Judge wrote: >>> Alexandre Biancalana wrote: >>>> Hi List, >>>> >>>> >>>> I´m doing a firewall setup using 6-STABLE + PF with two internet >>>> links but I can't do the route-to rule function as I need. >>>> >>>> >>>> (default gw) ______ >>>> Link A <-----------> |int A | >>>> | | >>>> Link B <-----------> |int B | >>>> |______| >>>> FreeBSD FW >>>> >>>> A simple thing that I need to do is test the two Internet links to >>>> know if they are up or not. To do this I could ping or connect tcp >>>> ports on some external ips thought each link, using nc and hping I >>>> tried do this generate connections/packets from each network >>>> interface connected to each link but the packets always go out by >>>> the interface indicated by machines default route. >>>> >>>> I tried to add this rules in pf to force packets out by the right >>>> interface based in your source address, but this does not work, and >>>> the packets generated with ip of int B are going out by int A. >>>> >>>> pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to >>>> any >>>> pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to >>>> any >>>> >>>> >>>> Am I forgetting something ? Any comments ? >>>> >>> >>> Have you tried setting the source IP address to int B when using >>> ping your tcp sessions, this should force PF to do your source >>> routing for you. >>> >>> Hope this helps >>> >>> Tom >> >> Yes, I tried the following commands: >> >> ping -S >> nc -s >> hping -I >> >> All the commands generate the traffic with source address of int B, >> but the traffic always go out by int A... this is the problem, even >> with the rules: >> >> pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to any >> pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to any >> >> that should "correct" the interface used send this traffic out... >> right ?! >> >> I can provide more details if need, but I think that is a simple >> setup... I can't see why this does not work.... any other ideas ?? >> > > > Did you try: > > ping -S -I # ping -S -I ping: invalid multicast interface: `' but it should be ping -S -I , for the traffic go out by int B with int B source address right ? I tried too and the same error happens. From ping man page: [...] -I iface Source multicast packets with the given interface address. This flag only applies if the ping destination is a multicast address. [...] From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 17:28:26 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1D4016A400; Mon, 12 Mar 2007 17:28:26 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id E9A2513C44B; Mon, 12 Mar 2007 17:28:25 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2CH0i4V070199; Mon, 12 Mar 2007 20:00:44 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2CH0dn0070198; Mon, 12 Mar 2007 20:00:39 +0300 (MSK) (envelope-from yar) Date: Mon, 12 Mar 2007 20:00:39 +0300 From: Yar Tikhiy To: Bruce M Simpson Message-ID: <20070312170038.GG44732@comp.chem.msu.su> References: <45E1B629.6080607@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E1B629.6080607@incunabulum.net> User-Agent: Mutt/1.5.9i Cc: freebsd-gnats-submit@FreeBSD.org, Gleb Smirnoff , net@FreeBSD.org Subject: Re: kern/86848: [pf][multicast] destroying active syncdev leads to panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 17:28:26 -0000 On Sun, Feb 25, 2007 at 04:15:37PM +0000, Bruce M Simpson wrote: > > Please try the attached patch which should hopefully fix this issue > (untested). I'm sorry to come up with bad news, but the patch resulted in a different panic: -- Yar Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex pf task mtx r = 0 (0xc0679ee4) locked @ contrib/pf/net/if_ pfsync.c:1897 KDB: stack backtrace: db_trace_self_wrapper(c0625b0a) at db_trace_self_wrapper+0x25 kdb_backtrace(1,0,c,cccbcadc,cccbcad0,...) at kdb_backtrace+0x29 witness_warn(5,0,c0641504) at witness_warn+0x192 trap(cccbcadc) at trap+0x144 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc056a4ab, esp = 0xcccbcb1c, ebp = 0xcccbcb24 --- in_delmulti(c1982ae0,c1a1e4a0,cccbcb60,c055ae35,c19d5300,...) at in_delmulti+0xb pfsync_ifdetach(c19d5300,c19d0c00,c1a1a00c,0,c062ec24,...) at pfsync_ifdetach+0x 99 if_detach(c19d0c00,c19d0c00,c19d0c00,cccbcb8c,c1b12be8,...) at if_detach+0x2cd ether_ifdetach(c19d0c00,c19d0c00,c1b14840,2d,cccbcbc4,...) at ether_ifdetach+0x3 a vlan_clone_destroy(c1b14840,c19d0c00,c19d0c00,c1b133ee,c1b14870,0,c062f063,d6) a t vlan_clone_destroy+0x14 if_clone_destroyif(c1b14840,c19d0c00,80206979,c19aa720,cccbcbf4,...) at if_clone _destroyif+0xc7 if_clone_destroy(c19aa720,80206979,c1abee44,c19aa720,cccbcc1c,...) at if_clone_d estroy+0x81 ifioctl(c1abee44,80206979,c19aa720,c1ab36c0,0,...) at ifioctl+0xbe soo_ioctl(c1aa2480,80206979,c19aa720,c18f0d00,c1ab36c0) at soo_ioctl+0x2db kern_ioctl(c1ab36c0,3,80206979,c19aa720) at kern_ioctl+0x296 ioctl(c1ab36c0,cccbcd00) at ioctl+0xf1 syscall(cccbcd38) at syscall+0x256 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281582df, esp = 0xbfbfe52c, ebp = 0xbfbfe548 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc138 fault code = supervisor read, page not present instruction pointer = 0x20:0xc056a4ab stack pointer = 0x28:0xcccbcb1c frame pointer = 0x28:0xcccbcb24 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 144 (ifconfig) panic: from debugger Uptime: 1m52s Physical memory: 251 MB Dumping 16 MB: 1 #0 doadump () at pcpu.h:147 147 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:147 #1 0xc04e73d0 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #2 0xc04e767b in panic (fmt=0xc06150e1 "from debugger") at ../../../kern/kern_shutdown.c:563 #3 0xc045640e in db_panic (addr=-1068063573, have_addr=0, count=-1, modif=0xcccbc91c "") at ../../../ddb/db_command.c:433 #4 0xc04563a7 in db_command (last_cmdp=0xc067d804, cmd_table=0x0) at ../../../ddb/db_command.c:401 #5 0xc0456462 in db_command_loop () at ../../../ddb/db_command.c:453 #6 0xc04580ad in db_trap (type=12, code=0) at ../../../ddb/db_main.c:222 #7 0xc0505889 in kdb_trap (type=12, code=0, tf=0x0) at ../../../kern/subr_kdb.c:502 #8 0xc05fcc1d in trap_fatal (frame=0xcccbcadc, eva=3735929144) at ../../../i386/i386/trap.c:859 #9 0xc05fc2cc in trap (frame=0xcccbcadc) at ../../../i386/i386/trap.c:276 #10 0xc05e8ddb in calltrap () at ../../../i386/i386/exception.s:139 #11 0xc056a4ab in in_delmulti (inm=0xc1982ae0) at ../../../netinet/in.c:1052 #12 0xc0433f99 in pfsync_ifdetach (arg=0xc19d5300, ifp=0xc19cee00) at ../../../contrib/pf/net/if_pfsync.c:1908 #13 0xc055ae35 in if_detach (ifp=0xc19d0c00) at ../../../net/if.c:709 #14 0xc055fb9a in ether_ifdetach (ifp=0xc19d0c00) at ../../../net/if_ethersubr.c:917 #15 0xc1b12be8 in vlan_clone_destroy (ifc=0xc1b14840, ifp=0xc19d0c00) at /usr/src/sys/modules/if_vlan/../../net/if_vlan.c:766 #16 0xc055e27f in if_clone_destroyif (ifc=0xc1b14840, ifp=0xc19d0c00) at ../../../net/if_clone.c:218 #17 0xc055e1b1 in if_clone_destroy (name=0xc19aa720 "vlan0") at ../../../net/if_clone.c:196 #18 0xc055d03a in ifioctl (so=0xc1abee44, cmd=2149607801, data=0xc19aa720 "vlan0", td=0xc1ab36c0) at ../../../net/if.c:1810 #19 0xc0518237 in soo_ioctl (fp=0xc19cee00, cmd=2149607801, data=0xc19aa720, active_cred=0xc18f0d00, td=0xc1ab36c0) at ../../../kern/sys_socket.c:202 #20 0xc0512f7a in kern_ioctl (td=0xc1ab36c0, fd=3, com=2149607801, data=0xc19aa720 "vlan0") at file.h:266 #21 0xc0512c9d in ioctl (td=0xc1ab36c0, uap=0xcccbcd00) at ../../../kern/sys_generic.c:544 #22 0xc05fcf12 in syscall (frame=0xcccbcd38) at ../../../i386/i386/trap.c:1008 #23 0xc05e8e40 in Xint0x80_syscall () at ../../../i386/i386/exception.s:196 #24 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 11 #11 0xc056a4ab in in_delmulti (inm=0xc1982ae0) at ../../../netinet/in.c:1052 1052 ifp = inm->inm_ifp; (kgdb) p inm $4 = (struct in_multi *) 0xc1982ae0 (kgdb) p *inm $5 = {inm_link = {le_next = 0xdeadc0de, le_prev = 0xdeadc0de}, inm_addr = {s_addr = 3735929054}, inm_ifp = 0xdeadc0de, inm_ifma = 0xdeadc0de, inm_timer = 3735929054, inm_state = 3735929054, inm_rti = 0xc0665040} %%% EOF %%% From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 17:30:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F97316A406 for ; Mon, 12 Mar 2007 17:30:11 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog11.obsmtp.com (s200aog11.obsmtp.com [207.126.144.125]) by mx1.freebsd.org (Postfix) with SMTP id 10E6513C459 for ; Mon, 12 Mar 2007 17:29:57 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob011.postini.com ([207.126.147.11]) with SMTP; Mon, 12 Mar 2007 17:29:56 UTC Received: from [10.0.0.79] (bwb.mintel.co.uk [10.0.0.79]) by rodney.mintel.co.uk (Postfix) with ESMTP id 5900918141B; Mon, 12 Mar 2007 17:29:56 +0000 (GMT) Message-ID: <45F58D1D.8080304@tomjudge.com> Date: Mon, 12 Mar 2007 17:25:49 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandre Biancalana References: <45F564B5.10307@seudns.net> <45F58321.5050309@tomjudge.com> <45F58758.6090103@seudns.net> <45F5889C.3010806@tomjudge.com> <45F58B94.9000308@seudns.net> In-Reply-To: <45F58B94.9000308@seudns.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 17:30:11 -0000 Alexandre Biancalana wrote: > Tom Judge wrote: >> Alexandre Biancalana wrote: >>> Tom Judge wrote: >>>> Alexandre Biancalana wrote: >>>>> Hi List, >>>>> >>>>> >>>>> I´m doing a firewall setup using 6-STABLE + PF with two internet >>>>> links but I can't do the route-to rule function as I need. >>>>> >>>>> >>>>> (default gw) ______ >>>>> Link A <-----------> |int A | >>>>> | | >>>>> Link B <-----------> |int B | >>>>> |______| >>>>> FreeBSD FW >>>>> >>>>> A simple thing that I need to do is test the two Internet links to >>>>> know if they are up or not. To do this I could ping or connect tcp >>>>> ports on some external ips thought each link, using nc and hping I >>>>> tried do this generate connections/packets from each network >>>>> interface connected to each link but the packets always go out by >>>>> the interface indicated by machines default route. >>>>> >>>>> I tried to add this rules in pf to force packets out by the right >>>>> interface based in your source address, but this does not work, and >>>>> the packets generated with ip of int B are going out by int A. >>>>> >>>>> pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to >>>>> any >>>>> pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to >>>>> any >>>>> > # ping -S -I > ping: invalid multicast interface: `' > > but it should be ping -S -I , for the traffic go out > by int B with int B source address right ? I tried too and the same > error happens. > > > From ping man page: > > [...] > -I iface > Source multicast packets with the given interface address. > This > flag only applies if the ping destination is a multicast > address. > [...] My mistake, I only looked at the header of the ping man page. These are the rules that I would use in that situation: if_a=em0 ip_a=192.168.0.2 gw_a=192.168.0.1 net_a=192.168.0.0/24 if_b=em1 ip_a=192.168.1.2 gw_a=192.168.1.1 net_a=192.168.1.0/24 pass out log on $if_a route-to ( $if_b $gw_b ) from $ip_a to ! $net_b pass out log on $if_b route-to ( $if_a $gw_a ) from $ip_b to ! $net_a Tom From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 17:48:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AED8816A400 for ; Mon, 12 Mar 2007 17:48:08 +0000 (UTC) (envelope-from ale@seudns.net) Received: from connectmed.com.br (s200-189-171-55.ipb.diveo.net.br [200.189.171.55]) by mx1.freebsd.org (Postfix) with SMTP id D710B13C483 for ; Mon, 12 Mar 2007 17:48:07 +0000 (UTC) (envelope-from ale@seudns.net) Received: (qmail 24100 invoked from network); 12 Mar 2007 17:44:52 -0000 Received: from unknown (HELO caco-new) (200.189.171.49) by donald.connectmed.com.br with SMTP; 12 Mar 2007 17:44:52 -0000 Received: (qmail 35264 invoked from network); 12 Mar 2007 17:48:05 -0000 Received: from unknown (HELO ?192.168.3.109?) (192.168.3.109) by localhost with SMTP; 12 Mar 2007 17:48:04 -0000 Message-ID: <45F59254.2050907@seudns.net> Date: Mon, 12 Mar 2007 14:48:04 -0300 From: Alexandre Biancalana User-Agent: Thunderbird 1.5.0.9 (X11/20070206) MIME-Version: 1.0 To: Tom Judge References: <45F564B5.10307@seudns.net> <45F58321.5050309@tomjudge.com> <45F58758.6090103@seudns.net> <45F5889C.3010806@tomjudge.com> <45F58B94.9000308@seudns.net> <45F58D1D.8080304@tomjudge.com> In-Reply-To: <45F58D1D.8080304@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 17:48:08 -0000 Tom Judge wrote: > Alexandre Biancalana wrote: >> Tom Judge wrote: >>> Alexandre Biancalana wrote: >>>> Tom Judge wrote: >>>>> Alexandre Biancalana wrote: >>>>>> Hi List, >>>>>> >>>>>> >>>>>> I´m doing a firewall setup using 6-STABLE + PF with two internet >>>>>> links but I can't do the route-to rule function as I need. >>>>>> >>>>>> >>>>>> (default gw) ______ >>>>>> Link A <-----------> |int A | >>>>>> | | >>>>>> Link B <-----------> |int B | >>>>>> |______| >>>>>> FreeBSD FW >>>>>> >>>>>> A simple thing that I need to do is test the two Internet links >>>>>> to know if they are up or not. To do this I could ping or connect >>>>>> tcp ports on some external ips thought each link, using nc and >>>>>> hping I tried do this generate connections/packets from each >>>>>> network interface connected to each link but the packets always >>>>>> go out by the interface indicated by machines default route. >>>>>> >>>>>> I tried to add this rules in pf to force packets out by the right >>>>>> interface based in your source address, but this does not work, >>>>>> and the packets generated with ip of int B are going out by int A. >>>>>> >>>>>> pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b >>>>>> to any >>>>>> pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a >>>>>> to any >>>>>> > > > > My mistake, I only looked at the header of the ping man page. > > These are the rules that I would use in that situation: > > if_a=em0 > ip_a=192.168.0.2 > gw_a=192.168.0.1 > net_a=192.168.0.0/24 > if_b=em1 > ip_a=192.168.1.2 > gw_a=192.168.1.1 > net_a=192.168.1.0/24 > > > pass out log on $if_a route-to ( $if_b $gw_b ) from $ip_a to ! $net_b > pass out log on $if_b route-to ( $if_a $gw_a ) from $ip_b to ! $net_a The difference is that my rules are for internet traffic, I don't have fixed destinations.... From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 18:59:14 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5382916A403 for ; Mon, 12 Mar 2007 18:59:14 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp803.mail.ird.yahoo.com (smtp803.mail.ird.yahoo.com [217.146.188.63]) by mx1.freebsd.org (Postfix) with SMTP id D3D8213C44C for ; Mon, 12 Mar 2007 18:59:13 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 91126 invoked from network); 12 Mar 2007 18:59:12 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@81.157.42.3 with plain) by smtp803.mail.ird.yahoo.com with SMTP; 12 Mar 2007 18:59:12 -0000 X-YMail-OSG: JriBUbYVM1ntguQeuyB1gXSWvzzOWpo5GoLkG.A63RXea4ppix9BTMn3Ph0PDsgmQOKd9AUS8Pe74s5F3OCRApDAN9B_iEwGIdV5tbI00UgGG4DVdlBBt.Hw1PWgR14uAQCjSGZ4GU1IB2d9GpyMtMURWb2CbT7BlHbzxiLLrYyu4VTUN7Y- Message-ID: <45F5A395.9010309@tomjudge.com> Date: Mon, 12 Mar 2007 19:01:41 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandre Biancalana References: <45F564B5.10307@seudns.net> <45F58321.5050309@tomjudge.com> <45F58758.6090103@seudns.net> <45F5889C.3010806@tomjudge.com> <45F58B94.9000308@seudns.net> <45F58D1D.8080304@tomjudge.com> <45F59254.2050907@seudns.net> In-Reply-To: <45F59254.2050907@seudns.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 18:59:14 -0000 Alexandre Biancalana wrote: > Tom Judge wrote: >> Alexandre Biancalana wrote: >>> Tom Judge wrote: >>>> Alexandre Biancalana wrote: >>>>> Tom Judge wrote: >>>>>> Alexandre Biancalana wrote: >>>>>>> Hi List, >>>>>>> >>>>>>> >>>>>>> I´m doing a firewall setup using 6-STABLE + PF with two internet >>>>>>> links but I can't do the route-to rule function as I need. >>>>>>> >>>>>>> >>>>>>> (default gw) ______ >>>>>>> Link A <-----------> |int A | >>>>>>> | | >>>>>>> Link B <-----------> |int B | >>>>>>> |______| >>>>>>> FreeBSD FW >>>>>>> >>>>>>> A simple thing that I need to do is test the two Internet links >>>>>>> to know if they are up or not. To do this I could ping or connect >>>>>>> tcp ports on some external ips thought each link, using nc and >>>>>>> hping I tried do this generate connections/packets from each >>>>>>> network interface connected to each link but the packets always >>>>>>> go out by the interface indicated by machines default route. >>>>>>> >>>>>>> I tried to add this rules in pf to force packets out by the right >>>>>>> interface based in your source address, but this does not work, >>>>>>> and the packets generated with ip of int B are going out by int A. >>>>>>> >>>>>>> pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b >>>>>>> to any >>>>>>> pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a >>>>>>> to any >>>>>>> >> >> >> >> My mistake, I only looked at the header of the ping man page. >> >> These are the rules that I would use in that situation: >> >> if_a=em0 >> ip_a=192.168.0.2 >> gw_a=192.168.0.1 >> net_a=192.168.0.0/24 >> if_b=em1 >> ip_a=192.168.1.2 >> gw_a=192.168.1.1 >> net_a=192.168.1.0/24 >> >> >> pass out log on $if_a route-to ( $if_b $gw_b ) from $ip_a to ! $net_b >> pass out log on $if_b route-to ( $if_a $gw_a ) from $ip_b to ! $net_a > > > The difference is that my rules are for internet traffic, I don't have > fixed destinations.... > > Ok so substitute the private IP addresses and networks in the rules ( and the interfaces) an you should be sorted. We use exactly the same configuration but with both public IP Addresses on one interface. Then if you connect from $ip_b to a public IP address not in $net_b you should see it routed via if_b to $gw_b. The only time I have seen these rules fail is when the IPSec code in the kernel transmits ESP packets which seem to pass though pf with some weird interfaces set or don't pass through pf at all. All other traffic generated on ip_a or ip_b will always pass to the correct ISP's router. The fact that the example rules I posted used private IP addresses is neither here nor there, if you make the appropriate changes to: ip_[ab] gw_[ab] net_[ab] if_[ab] Then the example rules should do what you want. Tom From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 19:08:20 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1EAB116A402 for ; Mon, 12 Mar 2007 19:08:20 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp813.mail.ird.yahoo.com (smtp813.mail.ird.yahoo.com [217.146.188.73]) by mx1.freebsd.org (Postfix) with SMTP id 9BE1B13C4BB for ; Mon, 12 Mar 2007 19:08:19 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 91953 invoked from network); 12 Mar 2007 19:08:18 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@81.157.42.3 with plain) by smtp813.mail.ird.yahoo.com with SMTP; 12 Mar 2007 19:08:18 -0000 X-YMail-OSG: 8hnZbu4VM1lO3acyBYfj6PNwqP5L5f.iEUcJJPmcec.wpEGDyDbYuHOlxPqV68ynfTlPLK8k9IjNQmkg_HBm0U46sHPHxV0gbSlxQpRj_7xollOcBlCBqfcsvtlhNQnQeVHOFViQd14qZxZiGWEXXDM.jEXqdcV7 Message-ID: <45F5A5B8.3010307@tomjudge.com> Date: Mon, 12 Mar 2007 19:10:48 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandre Biancalana References: <45F564B5.10307@seudns.net> <45F58321.5050309@tomjudge.com> <45F58758.6090103@seudns.net> <45F5889C.3010806@tomjudge.com> <45F58B94.9000308@seudns.net> <45F58D1D.8080304@tomjudge.com> <45F59254.2050907@seudns.net> <45F5A395.9010309@tomjudge.com> In-Reply-To: <45F5A395.9010309@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 19:08:20 -0000 Tom Judge wrote: > Alexandre Biancalana wrote: >> Tom Judge wrote: >>> Alexandre Biancalana wrote: >>>> Tom Judge wrote: >>>>> Alexandre Biancalana wrote: >>>>>> Tom Judge wrote: >>>>>>> Alexandre Biancalana wrote: >>>>>>>> Hi List, >>>>>>>> >>>>>>>> >>>>>>>> I´m doing a firewall setup using 6-STABLE + PF with two internet >>>>>>>> links but I can't do the route-to rule function as I need. >>>>>>>> >>>>>>>> >>>>>>>> (default gw) ______ >>>>>>>> Link A <-----------> |int A | >>>>>>>> | | >>>>>>>> Link B <-----------> |int B | >>>>>>>> |______| >>>>>>>> FreeBSD FW >>>>>>>> >>>>>>>> A simple thing that I need to do is test the two Internet links >>>>>>>> to know if they are up or not. To do this I could ping or >>>>>>>> connect tcp ports on some external ips thought each link, using >>>>>>>> nc and hping I tried do this generate connections/packets from >>>>>>>> each network interface connected to each link but the packets >>>>>>>> always go out by the interface indicated by machines default route. >>>>>>>> >>>>>>>> I tried to add this rules in pf to force packets out by the >>>>>>>> right interface based in your source address, but this does not >>>>>>>> work, and the packets generated with ip of int B are going out >>>>>>>> by int A. >>>>>>>> >>>>>>>> pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b >>>>>>>> to any >>>>>>>> pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a >>>>>>>> to any >>>>>>>> >>> >>> >>> >>> My mistake, I only looked at the header of the ping man page. >>> >>> These are the rules that I would use in that situation: >>> >>> if_a=em0 >>> ip_a=192.168.0.2 >>> gw_a=192.168.0.1 >>> net_a=192.168.0.0/24 >>> if_b=em1 >>> ip_a=192.168.1.2 >>> gw_a=192.168.1.1 >>> net_a=192.168.1.0/24 >>> >>> >>> pass out log on $if_a route-to ( $if_b $gw_b ) from $ip_a to ! $net_b >>> pass out log on $if_b route-to ( $if_a $gw_a ) from $ip_b to ! $net_a >> >> >> The difference is that my rules are for internet traffic, I don't have >> fixed destinations.... >> >> > > Ok so substitute the private IP addresses and networks in the rules ( > and the interfaces) an you should be sorted. We use exactly the same > configuration but with both public IP Addresses on one interface. Then > if you connect from $ip_b to a public IP address not in $net_b you > should see it routed via if_b to $gw_b. The only time I have seen these > rules fail is when the IPSec code in the kernel transmits ESP packets > which seem to pass though pf with some weird interfaces set or don't > pass through pf at all. All other traffic generated on ip_a or ip_b > will always pass to the correct ISP's router. > > The fact that the example rules I posted used private IP addresses is > neither here nor there, if you make the appropriate changes to: > > ip_[ab] > gw_[ab] > net_[ab] > if_[ab] > > Then the example rules should do what you want. > I just had an idea of one way to possibly test this, add a static destination route to an external host, e.g. www.google.com, via gw_b then ping said host with the source address of ip_a, this should cause the packet from ip_a to pass out if_b. The rules i posted above will catch the packet and then change the route to gw_a and transmit the packet via if_a. This is totally untested and may not work but it should do. Tom From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 20:47:19 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E7FB16A403; Mon, 12 Mar 2007 20:47:19 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (inse.ru [144.206.128.1]) by mx1.freebsd.org (Postfix) with ESMTP id A873713C45A; Mon, 12 Mar 2007 20:47:18 +0000 (UTC) (envelope-from rik@inse.ru) Received: from [127.0.0.1] (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTP id 068C333C4C; Mon, 12 Mar 2007 23:47:16 +0300 (MSK) Message-ID: <45F5BD36.1070205@inse.ru> Date: Mon, 12 Mar 2007 23:51:02 +0300 From: Roman Kurakin User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Yar Tikhiy References: <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> In-Reply-To: <20070312165145.GF44732@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rik@FreeBSD.org, andre@FreeBSD.org, glebius@FreeBSD.org, thompsa@FreeBSD.org, freebsd-net@FreeBSD.org, "Bruce M. Simpson" Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 20:47:19 -0000 Yar Tikhiy wrote: > On Mon, Mar 12, 2007 at 05:38:11PM +0300, Eygene Ryabinkin wrote: > >> Yar, >> >> >>>> 2. In the case where 802.3ad trunking is implemented, the same Ethernet >>>> address may be used by multiple physical interfaces. >>>> >>>> 3. As Eygene explained well: there are a number of consumers of >>>> Ethernet frames in the stack. As if_bridge may potentially be passed >>>> mbuf chains containing packets for these consumers first, it must >>>> examine the destination address to determine if it should claim the >>>> packet or not. >>>> >>>> Finally, because of the above points, the Ethernet destination address >>>> cannot be regarded as a unique key in the bridge code, or indeed the >>>> general Ethernet path, for where packets should be relayed in the stack >>>> as a whole. >>>> >>> But why are we relying solely on the Ethernet destination address? >>> >> Probably because if_bridge is written for Ethernet, 802.11 and >> may be some other 802 interfaces: >> ----- >> DESCRIPTION >> The if_bridge driver creates a logical link between two or more IEEE 802 >> networks that use the same (or ``similar enough'') framing format. For >> example, it is possible to bridge Ethernet and 802.11 networks together, >> but it is not possible to bridge Ethernet and Token Ring together. >> ----- >> > > The IEEE standards don't prevent us from keeping the pointer to the > receive interface and using it to identify the interface unambiguously. > That's what I meant. > > >>> Each frame was received via a particular interface, which is recorded >>> in mbuf's recvif. As the frame moves between levels of abstraction, >>> such as a physical interface, vlan, bridge, recvif can change, but >>> at each level the pointer to an entity in the previous level should >>> be enough, shouldn't it? >>> >> Excuse me, but are we talking about the problem that is cured by >> our patch, or about some general points? If about the former, then >> this problem shows up only for the packet that is destined for the >> local interface at the L2. And the pfil gots the wrong interface name >> due to the bug. >> > > A patch is unlikely to be correct if it's based on wrong assumptions. > Read my "very long email" again. The model used by the bridge to deliver the packet for our host is not wrong. >>> E.g., if several vlan interfaces are >>> bridged, if_bridge shouldn't need to know which physical interfaces >>> are used by the vlans. OTOH, it can know which particular vlan the >>> frame came through, although vlan MACs can be the same. >>> >> And who is saying that if_bridge should need to know about the >> underlying (parent) interface for the VLAN? The word 'physical' that >> we use here denotes the VLAN interface in which the packet showed up >> at ether_input. And the word 'logical' means the interface that >> the L2 packet is destined for. Perhaps it is the source of confusion? >> > > Quite likely. Even pfil is confused. ;^) As I've managed to figure > out finally, the "physical" interface (in this discussion) is the > interface the L2 packet actually came from, and the "logical" one > just bears the MAC address equal to that in the destination field > of the packet. > > The problem is that we cannot determine the "logical" interface > reliably in the presence of interfaces sharing the same MAC address. > No hacks can help us with that. > > Assume that a host has two physical interfaces, say, em0 and em1, > with different MAC addresses. We set up a few vlans on the former > and a few vlans on the latter, and then bridge all vlans together. > Now an Ethernet packet comes via, say, em0.7, with its destination > MAC address equal to that of em1 (and its vlans). Which of em1.* > vlans would you "logically" assign the packet to, and why? > This problem was described in my "very long e-mail". And yes it can not be fixed. Only if we will try to assign the packet to every interfaces in bridge with the same MAC, until the rules for the one allow this packet. This is too heavy solution. But if we can't fix the all sides of this problem it doesn't mean we shouldn't try to fix one that possible. rik > I'm afraid there is a serious flaw in the very notion of such a > "logical" interface. If it's true, we should start by admitting > that the support for "logical" interfaces should be a side hack for > compatibility, and not something that can live forever on the main > code path. > > From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 21:49:41 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E79F16A404; Mon, 12 Mar 2007 21:49:41 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 55C0913C4B9; Mon, 12 Mar 2007 21:49:40 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2CLnbLo073283; Tue, 13 Mar 2007 00:49:37 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2CLnRN2073274; Tue, 13 Mar 2007 00:49:27 +0300 (MSK) (envelope-from yar) Date: Tue, 13 Mar 2007 00:49:26 +0300 From: Yar Tikhiy To: Roman Kurakin Message-ID: <20070312214926.GK44732@comp.chem.msu.su> References: <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> <45F5BD36.1070205@inse.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45F5BD36.1070205@inse.ru> User-Agent: Mutt/1.5.9i Cc: rik@FreeBSD.org, andre@FreeBSD.org, glebius@FreeBSD.org, thompsa@FreeBSD.org, freebsd-net@FreeBSD.org, "Bruce M. Simpson" Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 21:49:41 -0000 On Mon, Mar 12, 2007 at 11:51:02PM +0300, Roman Kurakin wrote: > Yar Tikhiy wrote: > >On Mon, Mar 12, 2007 at 05:38:11PM +0300, Eygene Ryabinkin wrote: > > > >>Yar, > >> > >> > >>>>2. In the case where 802.3ad trunking is implemented, the same Ethernet > >>>>address may be used by multiple physical interfaces. > >>>> > >>>>3. As Eygene explained well: there are a number of consumers of > >>>>Ethernet frames in the stack. As if_bridge may potentially be passed > >>>>mbuf chains containing packets for these consumers first, it must > >>>>examine the destination address to determine if it should claim the > >>>>packet or not. > >>>> > >>>>Finally, because of the above points, the Ethernet destination address > >>>>cannot be regarded as a unique key in the bridge code, or indeed the > >>>>general Ethernet path, for where packets should be relayed in the stack > >>>>as a whole. > >>>> > >>>But why are we relying solely on the Ethernet destination address? > >>> > >>Probably because if_bridge is written for Ethernet, 802.11 and > >>may be some other 802 interfaces: > >>----- > >>DESCRIPTION > >> The if_bridge driver creates a logical link between two or more IEEE > >> 802 > >> networks that use the same (or ``similar enough'') framing format. > >> For > >> example, it is possible to bridge Ethernet and 802.11 networks > >> together, > >> but it is not possible to bridge Ethernet and Token Ring together. > >>----- > >> > > > >The IEEE standards don't prevent us from keeping the pointer to the > >receive interface and using it to identify the interface unambiguously. > >That's what I meant. > > > > > >>>Each frame was received via a particular interface, which is recorded > >>>in mbuf's recvif. As the frame moves between levels of abstraction, > >>>such as a physical interface, vlan, bridge, recvif can change, but > >>>at each level the pointer to an entity in the previous level should > >>>be enough, shouldn't it? > >>> > >>Excuse me, but are we talking about the problem that is cured by > >>our patch, or about some general points? If about the former, then > >>this problem shows up only for the packet that is destined for the > >>local interface at the L2. And the pfil gots the wrong interface name > >>due to the bug. > >> > > > >A patch is unlikely to be correct if it's based on wrong assumptions. > > > Read my "very long email" again. The model used by the bridge to deliver the > packet for our host is not wrong. > >>>E.g., if several vlan interfaces are > >>>bridged, if_bridge shouldn't need to know which physical interfaces > >>>are used by the vlans. OTOH, it can know which particular vlan the > >>>frame came through, although vlan MACs can be the same. > >>> > >>And who is saying that if_bridge should need to know about the > >>underlying (parent) interface for the VLAN? The word 'physical' that > >>we use here denotes the VLAN interface in which the packet showed up > >>at ether_input. And the word 'logical' means the interface that > >>the L2 packet is destined for. Perhaps it is the source of confusion? > >> > > > >Quite likely. Even pfil is confused. ;^) As I've managed to figure > >out finally, the "physical" interface (in this discussion) is the > >interface the L2 packet actually came from, and the "logical" one > >just bears the MAC address equal to that in the destination field > >of the packet. > > > >The problem is that we cannot determine the "logical" interface > >reliably in the presence of interfaces sharing the same MAC address. > >No hacks can help us with that. > > > >Assume that a host has two physical interfaces, say, em0 and em1, > >with different MAC addresses. We set up a few vlans on the former > >and a few vlans on the latter, and then bridge all vlans together. > >Now an Ethernet packet comes via, say, em0.7, with its destination > >MAC address equal to that of em1 (and its vlans). Which of em1.* > >vlans would you "logically" assign the packet to, and why? > > > This problem was described in my "very long e-mail". And yes it can not be > fixed. Only if we will try to assign the packet to every interfaces in > bridge > with the same MAC, until the rules for the one allow this packet. This > is too > heavy solution. But if we can't fix the all sides of this problem it > doesn't mean > we shouldn't try to fix one that possible. See bms_netdev, it's rather promising: with it, we won't have to do duplicate checks for the destination MAC address. Namely see lines 642-682 of //depot/user/bms/netdev/sys/net/if_ethersubr.c#9. The things may need some moving around, but all code is already there. Then the bridge_input code will be able to make use of M_PROMISC to see if it must consume the packet or just update its forwarding table. So all the tangled if()s inside LIST_FOREACH() will be gone completely from bridge_input(). > rik > >I'm afraid there is a serious flaw in the very notion of such a > >"logical" interface. If it's true, we should start by admitting > >that the support for "logical" interfaces should be a side hack for > >compatibility, and not something that can live forever on the main > >code path. > > > > -- Yar From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 21:56:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 444CE16A400 for ; Mon, 12 Mar 2007 21:56:04 +0000 (UTC) (envelope-from hhw@pce-net.com) Received: from layered.pce-net.com (210.43.21.72.reverse.layeredtech.com [72.21.43.210]) by mx1.freebsd.org (Postfix) with ESMTP id 29A9313C44C for ; Mon, 12 Mar 2007 21:56:04 +0000 (UTC) (envelope-from hhw@pce-net.com) Received: from [192.168.2.8] (S010600d0b7af3369.vc.shawcable.net [24.85.243.157]) by layered.pce-net.com (Postfix) with ESMTP id BB59D4AC23; Mon, 12 Mar 2007 15:34:09 -0600 (CST) Message-ID: <45F5C750.4000804@pce-net.com> Date: Mon, 12 Mar 2007 14:34:08 -0700 From: Han Hwei Woo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Alexandre Biancalana References: <45F564B5.10307@seudns.net> In-Reply-To: <45F564B5.10307@seudns.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 21:56:04 -0000 Just to be certain, are you aware that for PF, the last matching rule is applied? Also, you can use the command: # pfctl -vv -sr to examine how your rules are being matched. Cheers, Han Alexandre Biancalana wrote: > Hi List, > > > I´m doing a firewall setup using 6-STABLE + PF with two internet links > but I can't do the route-to rule function as I need. > > > (default gw) ______ > Link A <-----------> |int A | > | | > Link B <-----------> |int B | > |______| > FreeBSD FW > > A simple thing that I need to do is test the two Internet links to > know if they are up or not. To do this I could ping or connect tcp > ports on some external ips thought each link, using nc and hping I > tried do this generate connections/packets from each network interface > connected to each link but the packets always go out by the interface > indicated by machines default route. > > I tried to add this rules in pf to force packets out by the right > interface based in your source address, but this does not work, and > the packets generated with ip of int B are going out by int A. > > pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to any > pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to any > > > Am I forgetting something ? Any comments ? > > > Regards, > > Alexandre > _______________________________________________ > 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 Mon Mar 12 22:07:38 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6531816A403 for ; Mon, 12 Mar 2007 22:07:38 +0000 (UTC) (envelope-from ale@seudns.net) Received: from connectmed.com.br (s200-189-171-55.ipb.diveo.net.br [200.189.171.55]) by mx1.freebsd.org (Postfix) with SMTP id B2E3F13C459 for ; Mon, 12 Mar 2007 22:07:36 +0000 (UTC) (envelope-from ale@seudns.net) Received: (qmail 28549 invoked from network); 12 Mar 2007 22:04:22 -0000 Received: from unknown (HELO caco-new) (200.189.171.49) by donald.connectmed.com.br with SMTP; 12 Mar 2007 22:04:22 -0000 Received: (qmail 64614 invoked from network); 12 Mar 2007 22:07:35 -0000 Received: from unknown (HELO ?192.168.3.109?) (192.168.3.109) by localhost with SMTP; 12 Mar 2007 22:07:34 -0000 Message-ID: <45F5CF26.6070100@seudns.net> Date: Mon, 12 Mar 2007 19:07:34 -0300 From: Alexandre Biancalana User-Agent: Thunderbird 1.5.0.9 (X11/20070206) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <45F564B5.10307@seudns.net> <45F58321.5050309@tomjudge.com> <45F58758.6090103@seudns.net> <45F5889C.3010806@tomjudge.com> <45F58B94.9000308@seudns.net> <45F58D1D.8080304@tomjudge.com> <45F59254.2050907@seudns.net> <45F5A395.9010309@tomjudge.com> In-Reply-To: <45F5A395.9010309@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 22:07:38 -0000 Tom Judge wrote: > Alexandre Biancalana wrote: >> Tom Judge wrote: >>> Alexandre Biancalana wrote: >>>> Tom Judge wrote: >>>>> Alexandre Biancalana wrote: >>>>>> Tom Judge wrote: >>>>>>> Alexandre Biancalana wrote: >>>>>>>> Hi List, >>>>>>>> >>>>>>>> >>>>>>>> I´m doing a firewall setup using 6-STABLE + PF with two >>>>>>>> internet links but I can't do the route-to rule function as I >>>>>>>> need. >>>>>>>> >>>>>>>> >>>>>>>> (default gw) ______ >>>>>>>> Link A <-----------> |int A | >>>>>>>> | | >>>>>>>> Link B <-----------> |int B | >>>>>>>> |______| >>>>>>>> FreeBSD FW >>>>>>>> >>>>>>>> A simple thing that I need to do is test the two Internet links >>>>>>>> to know if they are up or not. To do this I could ping or >>>>>>>> connect tcp ports on some external ips thought each link, using >>>>>>>> nc and hping I tried do this generate connections/packets from >>>>>>>> each network interface connected to each link but the packets >>>>>>>> always go out by the interface indicated by machines default >>>>>>>> route. >>>>>>>> >>>>>>>> I tried to add this rules in pf to force packets out by the >>>>>>>> right interface based in your source address, but this does not >>>>>>>> work, and the packets generated with ip of int B are going out >>>>>>>> by int A. >>>>>>>> >>>>>>>> pass out log on $int_a route-to ( $int_b $int_b_gw ) from >>>>>>>> $int_b to any >>>>>>>> pass out log on $int_b route-to ( $int_a $int_a_gw ) from >>>>>>>> $int_a to any >>>>>>>> >>> >>> >>> >>> My mistake, I only looked at the header of the ping man page. >>> >>> These are the rules that I would use in that situation: >>> >>> if_a=em0 >>> ip_a=192.168.0.2 >>> gw_a=192.168.0.1 >>> net_a=192.168.0.0/24 >>> if_b=em1 >>> ip_a=192.168.1.2 >>> gw_a=192.168.1.1 >>> net_a=192.168.1.0/24 >>> >>> >>> pass out log on $if_a route-to ( $if_b $gw_b ) from $ip_a to ! $net_b >>> pass out log on $if_b route-to ( $if_a $gw_a ) from $ip_b to ! $net_a >> >> >> The difference is that my rules are for internet traffic, I don't >> have fixed destinations.... >> >> > > Ok so substitute the private IP addresses and networks in the rules ( > and the interfaces) an you should be sorted. We use exactly the same > configuration but with both public IP Addresses on one interface. > Then if you connect from $ip_b to a public IP address not in $net_b > you should see it routed via if_b to $gw_b. The only time I have seen > these rules fail is when the IPSec code in the kernel transmits ESP > packets which seem to pass though pf with some weird interfaces set or > don't pass through pf at all. All other traffic generated on ip_a or > ip_b will always pass to the correct ISP's router. > > The fact that the example rules I posted used private IP addresses is > neither here nor there, if you make the appropriate changes to: > > ip_[ab] > gw_[ab] > net_[ab] > if_[ab] > > Then the example rules should do what you want. > I understand that, I just don't see much difference in your rules and my rules example... the both examples should work... but here none off then work..... Adding a static destination route to an external host via gw_b and ping with int_a address, the packet exit by int_b with int_a source address... the same behavior... I tried your way: pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to ! int_b:network pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to ! int_a:network # pfctl -vv -sr @28 pass out log on int_a route-to (int_b int_b_gw) inet from int_b_ip to ! int_b:network [ Evaluations: 88 Packets: 0 Bytes: 0 States: 0 ] @29 pass out log on int_b route-to (int_a int_a_gw) inet from int_a to ! int_a:network [ Evaluations: 80 Packets: 0 Bytes: 0 States: 0 ] Any more hints ?! Alexandre From owner-freebsd-net@FreeBSD.ORG Mon Mar 12 22:25:44 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D27E116A504 for ; Mon, 12 Mar 2007 22:25:44 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp801.mail.ird.yahoo.com (smtp801.mail.ird.yahoo.com [217.146.188.61]) by mx1.freebsd.org (Postfix) with SMTP id 5C38813C44C for ; Mon, 12 Mar 2007 22:25:44 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 25988 invoked from network); 12 Mar 2007 22:25:43 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@81.157.42.3 with plain) by smtp801.mail.ird.yahoo.com with SMTP; 12 Mar 2007 22:25:42 -0000 X-YMail-OSG: rMTtCq8VM1m5YVNzjSKkb0Kh3mZj57SMopmykFMoKEQUkl5OTPfSNc00RgpnQZ5H6H9EFUh.B7JPxSokSpwh2pElCo3uzpnxywKIu43kXyM8L.Ixglw- Message-ID: <45F5D3FD.8070802@tomjudge.com> Date: Mon, 12 Mar 2007 22:28:13 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandre Biancalana References: <45F564B5.10307@seudns.net> <45F58321.5050309@tomjudge.com> <45F58758.6090103@seudns.net> <45F5889C.3010806@tomjudge.com> <45F58B94.9000308@seudns.net> <45F58D1D.8080304@tomjudge.com> <45F59254.2050907@seudns.net> <45F5A395.9010309@tomjudge.com> <45F5CF26.6070100@seudns.net> In-Reply-To: <45F5CF26.6070100@seudns.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 22:25:45 -0000 Alexandre Biancalana wrote: > Tom Judge wrote: >> Alexandre Biancalana wrote: >>> Tom Judge wrote: >>>> Alexandre Biancalana wrote: >>>>> Tom Judge wrote: >>>>>> Alexandre Biancalana wrote: >>>>>>> Tom Judge wrote: >>>>>>>> Alexandre Biancalana wrote: >>>>>>>>> Hi List, >>>>>>>>> >>>>>>>>> >>>>>>>>> I´m doing a firewall setup using 6-STABLE + PF with two >>>>>>>>> internet links but I can't do the route-to rule function as I >>>>>>>>> need. >>>>>>>>> >>>>>>>>> >>>>>>>>> (default gw) ______ >>>>>>>>> Link A <-----------> |int A | >>>>>>>>> | | >>>>>>>>> Link B <-----------> |int B | >>>>>>>>> |______| >>>>>>>>> FreeBSD FW >>>>>>>>> >>>>>>>>> A simple thing that I need to do is test the two Internet links >>>>>>>>> to know if they are up or not. To do this I could ping or >>>>>>>>> connect tcp ports on some external ips thought each link, using >>>>>>>>> nc and hping I tried do this generate connections/packets from >>>>>>>>> each network interface connected to each link but the packets >>>>>>>>> always go out by the interface indicated by machines default >>>>>>>>> route. >>>>>>>>> >>>>>>>>> I tried to add this rules in pf to force packets out by the >>>>>>>>> right interface based in your source address, but this does not >>>>>>>>> work, and the packets generated with ip of int B are going out >>>>>>>>> by int A. >>>>>>>>> >>>>>>>>> pass out log on $int_a route-to ( $int_b $int_b_gw ) from >>>>>>>>> $int_b to any >>>>>>>>> pass out log on $int_b route-to ( $int_a $int_a_gw ) from >>>>>>>>> $int_a to any >>>>>>>>> > I understand that, I just don't see much difference in your rules and my > rules example... the both examples should work... but here none off then > work..... > > Adding a static destination route to an external host via gw_b and ping > with int_a address, the packet exit by int_b with int_a source > address... the same behavior... > > I tried your way: > > pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to ! > int_b:network > pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to ! > int_a:network > > > # pfctl -vv -sr > @28 pass out log on int_a route-to (int_b int_b_gw) inet from int_b_ip > to ! int_b:network > [ Evaluations: 88 Packets: 0 Bytes: 0 States: > 0 ] > @29 pass out log on int_b route-to (int_a int_a_gw) inet from int_a to ! > int_a:network > [ Evaluations: 80 Packets: 0 Bytes: 0 States: > 0 ] > > Any more hints ?! Han Hwei Woo wrote: > Just to be certain, are you aware that for PF, the last matching rule is > applied? Also, you can use the command: > # pfctl -vv -sr > to examine how your rules are being matched. Try the following which forces the first rule the packet matches (marked with quick) to be the final rule used to process the packet: pass out quick log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to ! int_b:network pass out quick log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to ! int_a:network Tom From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 03:25:07 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3032016A400 for ; Tue, 13 Mar 2007 03:25:07 +0000 (UTC) (envelope-from ale@seudns.net) Received: from mx1.e-filter.com.br (mx.e-filter.com.br [201.54.26.3]) by mx1.freebsd.org (Postfix) with SMTP id 44A0613C45B for ; Tue, 13 Mar 2007 03:25:00 +0000 (UTC) (envelope-from ale@seudns.net) Received: (qmail 25203 invoked from network); 13 Mar 2007 02:58:46 -0000 Received: from unknown (HELO ?192.168.100.20?) (192.168.100.20) by 0 with SMTP; 13 Mar 2007 02:58:46 -0000 Received-SPF: none (192.168.99.3: domain of ale@seudns.net does not designate permitted sender hosts) Message-ID: <45F61346.6050808@seudns.net> Date: Mon, 12 Mar 2007 23:58:14 -0300 From: Alexandre Biancalana User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Tom Judge References: <45F564B5.10307@seudns.net> <45F58321.5050309@tomjudge.com> <45F58758.6090103@seudns.net> <45F5889C.3010806@tomjudge.com> <45F58B94.9000308@seudns.net> <45F58D1D.8080304@tomjudge.com> <45F59254.2050907@seudns.net> <45F5A395.9010309@tomjudge.com> <45F5CF26.6070100@seudns.net> <45F5D3FD.8070802@tomjudge.com> In-Reply-To: <45F5D3FD.8070802@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: PF route-to behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 03:25:07 -0000 Tom Judge wrote: > Alexandre Biancalana wrote: >> Tom Judge wrote: >>> Alexandre Biancalana wrote: >>>> Tom Judge wrote: >>>>> Alexandre Biancalana wrote: >>>>>> Tom Judge wrote: >>>>>>> Alexandre Biancalana wrote: >>>>>>>> Tom Judge wrote: >>>>>>>>> Alexandre Biancalana wrote: >>>>>>>>>> Hi List, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I´m doing a firewall setup using 6-STABLE + PF with two >>>>>>>>>> internet links but I can't do the route-to rule function as I >>>>>>>>>> need. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> (default gw) ______ >>>>>>>>>> Link A <-----------> |int A | >>>>>>>>>> | | >>>>>>>>>> Link B <-----------> |int B | >>>>>>>>>> |______| >>>>>>>>>> FreeBSD FW >>>>>>>>>> >>>>>>>>>> A simple thing that I need to do is test the two Internet >>>>>>>>>> links to know if they are up or not. To do this I could ping >>>>>>>>>> or connect tcp ports on some external ips thought each link, >>>>>>>>>> using nc and hping I tried do this generate >>>>>>>>>> connections/packets from each network interface connected to >>>>>>>>>> each link but the packets always go out by the interface >>>>>>>>>> indicated by machines default route. >>>>>>>>>> >>>>>>>>>> I tried to add this rules in pf to force packets out by the >>>>>>>>>> right interface based in your source address, but this does >>>>>>>>>> not work, and the packets generated with ip of int B are >>>>>>>>>> going out by int A. >>>>>>>>>> >>>>>>>>>> pass out log on $int_a route-to ( $int_b $int_b_gw ) from >>>>>>>>>> $int_b to any >>>>>>>>>> pass out log on $int_b route-to ( $int_a $int_a_gw ) from >>>>>>>>>> $int_a to any >>>>>>>>>> > > > >> I understand that, I just don't see much difference in your rules and >> my rules example... the both examples should work... but here none >> off then work..... >> >> Adding a static destination route to an external host via gw_b and >> ping with int_a address, the packet exit by int_b with int_a source >> address... the same behavior... >> >> I tried your way: >> >> pass out log on $int_a route-to ( $int_b $int_b_gw ) from $int_b to ! >> int_b:network >> pass out log on $int_b route-to ( $int_a $int_a_gw ) from $int_a to ! >> int_a:network >> >> >> # pfctl -vv -sr >> @28 pass out log on int_a route-to (int_b int_b_gw) inet from >> int_b_ip to ! int_b:network >> [ Evaluations: 88 Packets: 0 Bytes: 0 >> States: 0 ] >> @29 pass out log on int_b route-to (int_a int_a_gw) inet from int_a >> to ! int_a:network >> [ Evaluations: 80 Packets: 0 Bytes: 0 >> States: 0 ] >> >> Any more hints ?! > > Han Hwei Woo wrote: > > Just to be certain, are you aware that for PF, the last matching > rule is > > applied? Also, you can use the command: > > # pfctl -vv -sr > > to examine how your rules are being matched. > > Try the following which forces the first rule the packet matches > (marked with quick) to be the final rule used to process the packet: > > pass out quick log on $int_a route-to ( $int_b $int_b_gw ) from $int_b > to ! int_b:network > pass out quick log on $int_b route-to ( $int_a $int_a_gw ) from $int_a > to ! int_a:network I added an keep state at end of each rule and now all works ! I will do more tests and report any problem... Thanks in advance !!! Alexandre From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 05:50:38 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F11BC16A401; Tue, 13 Mar 2007 05:50:37 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 870B113C44C; Tue, 13 Mar 2007 05:50:37 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HQzu7-000PEx-CX; Tue, 13 Mar 2007 08:50:36 +0300 Date: Tue, 13 Mar 2007 08:50:29 +0300 From: Eygene Ryabinkin To: Yar Tikhiy Message-ID: <20070313055029.GK58523@codelabs.ru> References: <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> <45F5BD36.1070205@inse.ru> <20070312214926.GK44732@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070312214926.GK44732@comp.chem.msu.su> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: rik@FreeBSD.org, Roman Kurakin , andre@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org, thompsa@FreeBSD.org, "Bruce M. Simpson" Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 05:50:38 -0000 Yar, good day. > > >>Probably because if_bridge is written for Ethernet, 802.11 and > > >>may be some other 802 interfaces: > > >>----- > > >>DESCRIPTION > > >> The if_bridge driver creates a logical link between two or more IEEE > > >> 802 > > >> networks that use the same (or ``similar enough'') framing format. > > >> For > > >> example, it is possible to bridge Ethernet and 802.11 networks > > >> together, > > >> but it is not possible to bridge Ethernet and Token Ring together. > > >>----- > > >> > > > > > >The IEEE standards don't prevent us from keeping the pointer to the > > >receive interface and using it to identify the interface unambiguously. > > >That's what I meant. OK, no problem: we can keep the actual incoming interface in the mbuf. > > >>>Each frame was received via a particular interface, which is recorded > > >>>in mbuf's recvif. As the frame moves between levels of abstraction, > > >>>such as a physical interface, vlan, bridge, recvif can change, but > > >>>at each level the pointer to an entity in the previous level should > > >>>be enough, shouldn't it? > > >>> > > >>Excuse me, but are we talking about the problem that is cured by > > >>our patch, or about some general points? If about the former, then > > >>this problem shows up only for the packet that is destined for the > > >>local interface at the L2. And the pfil gots the wrong interface name > > >>due to the bug. > > >> > > > > > >A patch is unlikely to be correct if it's based on wrong assumptions. Yes, it is based on the wrong assumptions that were made about 3-4 years ago in the NetBSD. And the real problem here is if we want to leave the current behaviour of locally destined packets or we want completely different thing. We asked in the list if someone uses the current behaviour, but no replies were received yet. > > >>And who is saying that if_bridge should need to know about the > > >>underlying (parent) interface for the VLAN? The word 'physical' that > > >>we use here denotes the VLAN interface in which the packet showed up > > >>at ether_input. And the word 'logical' means the interface that > > >>the L2 packet is destined for. Perhaps it is the source of confusion? > > >> > > > > > >Quite likely. Even pfil is confused. ;^) As I've managed to figure > > >out finally, the "physical" interface (in this discussion) is the > > >interface the L2 packet actually came from, and the "logical" one > > >just bears the MAC address equal to that in the destination field > > >of the packet. > > > > > >The problem is that we cannot determine the "logical" interface > > >reliably in the presence of interfaces sharing the same MAC address. > > >No hacks can help us with that. Sure. And that is why all switches that can bear the IP on their interfaces have distinct MACs for each interface or/and the only one interface can have the IP. And that is why I am going to add the paragraph to the if_bridge(4) describing the current situation and giving advice on the setting IP for the bridge members and the bridge itself. Will provide the patch in a day or two. > > >Assume that a host has two physical interfaces, say, em0 and em1, > > >with different MAC addresses. We set up a few vlans on the former > > >and a few vlans on the latter, and then bridge all vlans together. > > >Now an Ethernet packet comes via, say, em0.7, with its destination > > >MAC address equal to that of em1 (and its vlans). Which of em1.* > > >vlans would you "logically" assign the packet to, and why? > > > > > This problem was described in my "very long e-mail". And yes it can not be > > fixed. Only if we will try to assign the packet to every interfaces in > > bridge > > with the same MAC, until the rules for the one allow this packet. This > > is too > > heavy solution. But if we can't fix the all sides of this problem it > > doesn't mean > > we shouldn't try to fix one that possible. > > See bms_netdev, it's rather promising: with it, we won't have to do > duplicate checks for the destination MAC address. Namely see lines > 642-682 of //depot/user/bms/netdev/sys/net/if_ethersubr.c#9. > The things may need some moving around, but all code is already there. > Then the bridge_input code will be able to make use of M_PROMISC to > see if it must consume the packet or just update its forwarding table. I tried to understand this, because Bruce already gave me a patch, but I am a bit stupid: I do not see how M_PROMISC that is cleared unconditionally before BRIDGE_INPUT will help us to identify the right interface. As I see now, the BRIDGE_INPUT is called once from if_ethersubr.c, once from if_gif.c and once from ng_ether.c: http://fxr.watson.org/fxr/ident?i=BRIDGE_INPUT So there is no distinct code paths that can allow BRIDGE_INPUT to modify its behaviour based on the M_PROMISC flag. But I feel that I am wrong in some place and missing some discuission on the M_PROMISC. Can anyone point me to the right place? > So all the tangled if()s inside LIST_FOREACH() will be gone completely > from bridge_input(). But we still need to see if we want to consume the packet by the bridge or it members or to do forwarding. Am I missing something? > > >I'm afraid there is a serious flaw in the very notion of such a > > >"logical" interface. If it's true, we should start by admitting > > >that the support for "logical" interfaces should be a side hack for > > >compatibility, and not something that can live forever on the main > > >code path. I agree with you. That is why I patched if_bridge once again to enable the pfil hooks for the "physical" incoming interface. And there are two ways to solve the problem: - to give each VLAN interface the distinct MAC, as Bruce suggested, - to refuse the "logical" interfaces completely and to support only "physical" ones. It is what my very first (and very short) patch did. But this can break some existing firewall rulesets. And that should be discuissed -- we do not need the total breakage due to out changes. And you're right: the best way for this alternative is to leave the current behaviour as the compatibility sysctl that is turned off by default and move to the filtering on the "physical" interfaces by default. No problem, but skilled network people that are using FreeBSD as the bridge for VLANs should say if they are happy with it. -- Eygene From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 07:46:00 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D841716A405 for ; Tue, 13 Mar 2007 07:46:00 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id CD58713C448 for ; Tue, 13 Mar 2007 07:46:00 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l2D7jhu2054882; Mon, 12 Mar 2007 23:45:43 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l2D7jhJw054881; Tue, 13 Mar 2007 00:45:43 -0700 (PDT) (envelope-from rizzo) Date: Tue, 13 Mar 2007 00:45:43 -0700 From: Luigi Rizzo To: Yar Tikhiy Message-ID: <20070313004543.A54774@xorpc.icir.org> References: <20070310153534.GA35834@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070310153534.GA35834@comp.chem.msu.su>; from yar@comp.chem.msu.su on Sat, Mar 10, 2007 at 06:35:34PM +0300 Cc: freebsd-net@freebsd.org Subject: Re: Who is to load dummynet.ko? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 07:46:00 -0000 On Sat, Mar 10, 2007 at 06:35:34PM +0300, Yar Tikhiy wrote: > Hi folks, > > Just noticed that neither ipfw(8) nor /etc/rc.d/ipfw cares to load > dummynet.ko. It can result in a broken setup when one migrates > from a custom monolithic kernel to GENERIC with modules, which is > a nice way to reduce support headache today. > > There are at least two possible ways to deal with the issue. The > easy way is to give the task of loading dummynet.ko to /etc/rc.d/ipfw. > The problem with it is that the script cannot know in advance if > dummynet is really used by the ipfw rules to be loaded. The decision > whether to load the module is left to rc.conf(5) in this case. i think this is a reasonable option and the one to use for all ipfw extensions (divert, dummynet, in-kernel nat and so on). Making the load on demand would require a bit of additional code because it depends on the actual rules being loaded, and the rules are not parsed at load time. Plus, i believe that in a case like this the decision of which modules to load should be a conscious one taken upfront by the system administrator (i.e. end up in rc.conf or loader.conf) rather than be the result of the actual ipfw configuration. > The second way is to move the task of loading modules to ipfw(8). > Then it could load ipfw.ko, divert.ko, and dummynet.ko on demand. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 09:31:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6109716A403; Tue, 13 Mar 2007 09:31:50 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 17E7613C465; Tue, 13 Mar 2007 09:31:47 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HR3M7-000PRD-Iv; Tue, 13 Mar 2007 12:31:43 +0300 Date: Tue, 13 Mar 2007 12:31:38 +0300 From: Eygene Ryabinkin To: Roman Kurakin Message-ID: <20070313093137.GP58523@codelabs.ru> References: <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312121117.GQ58523@codelabs.ru> <45F5520B.80709@inse.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <45F5520B.80709@inse.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: rik@FreeBSD.org, andre@FreeBSD.org, freebsd-net@freebsd.org, glebius@FreeBSD.org, thompsa@FreeBSD.org, "Bruce M. Simpson" Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 09:31:50 -0000 > Here it is. I'll check it for compilation this evening and I hope Eygene will > be able to put it in a production for testings. The system with 6.2 and this patch is living since yesterday. No problems were spotted. I will try to put this patch into another, busier system, but this will not be the same patch: my own one will be applied on top of it. So this will not be the clear testcase. -- Eygene From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 09:40:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E786516A478 for ; Tue, 13 Mar 2007 09:40:11 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id AEA8E13C44B for ; Tue, 13 Mar 2007 09:40:11 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HR3UI-000PRp-Jl for freebsd-net@freebsd.org; Tue, 13 Mar 2007 12:40:10 +0300 Date: Tue, 13 Mar 2007 12:40:09 +0300 From: Eygene Ryabinkin To: freebsd-net@freebsd.org Message-ID: <20070313094008.GR58523@codelabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.1 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Subject: [ADVICE NEEDED] if_bridge and pfil hooks behaviour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 09:40:12 -0000 Good day. We are -- Eygene From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 09:53:06 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E07E316A401 for ; Tue, 13 Mar 2007 09:53:06 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id A567313C44B for ; Tue, 13 Mar 2007 09:53:06 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HR3gn-000PSW-3w for freebsd-net@freebsd.org; Tue, 13 Mar 2007 12:53:05 +0300 Date: Tue, 13 Mar 2007 12:53:00 +0300 From: Eygene Ryabinkin To: freebsd-net@freebsd.org Message-ID: <20070313095300.GS58523@codelabs.ru> References: <20070313094008.GR58523@codelabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070313094008.GR58523@codelabs.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Subject: Re: [ADVICE NEEDED] if_bridge and pfil hooks behaviour X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 09:53:07 -0000 Good day again. Sorry, hit the 'Send' button prematurely. So, we are currently trying to fix kern/109815 and the advice is needed on the current and the desired behaviour of L3 filtering on the if_bridge. We're talking about the case when the packets coming to the if_bridge interface are destined to some bridge member at the layer 2. So primarily it is the case when the bridged machine is acting as an L3 router. And the problem is about the interface the pfil hooks are seeing for such a packet. The current behaviour is the following: pfil hooks are getting the interface if the bridge for which the packet is destined (in L2). So it is not the "physical" interface on which the packet appeared, but the interface with the MAC address that is in the packet's destination field. And the current behaviour is not so good, because in the case of multiple interfaces that are sharing the same MAC in the bridge the bridge code will not be able to figure out the right one. By the way, BPF gets the "physical" interface, so the current behaviour of pfil hooks is inconsistent with the BPF. There can be alternative behaviour: pfil hooks will see the "physical" interface on which the packet appeared. And this is much better for the multiple identical MACs case, since there will be no confusion. But this will break the current (possibly erroneous) behaviour, that was introduced in a very first version of if_bridge.c that was doing the pfil hooks (at NetBSD, v 1.9: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net/if_bridge.c?rev=1.9&content-type=text/x-cvsweb-markup). So the question is: are there some reasons to keep the current behaviour as the default one, or we can move to the alternative behaviour possibly leaving the old one in the form of additional sysctl? Thank you! -- Eygene From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 11:36:59 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 909C316A404; Tue, 13 Mar 2007 11:36:59 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 4E49D13C45B; Tue, 13 Mar 2007 11:36:59 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 4B37A1F860F; Tue, 13 Mar 2007 07:36:59 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Tue, 13 Mar 2007 07:36:59 -0400 X-Sasl-enc: sXIkhSvRr/MhGs/UH+d10vRSpTYCwmIPGDaPwYFzY3GW 1173785818 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id B8B451637B; Tue, 13 Mar 2007 07:36:56 -0400 (EDT) Message-ID: <45F68CD6.2030300@FreeBSD.org> Date: Tue, 13 Mar 2007 11:36:54 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Eygene Ryabinkin References: <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> <45F5BD36.1070205@inse.ru> <20070312214926.GK44732@comp.chem.msu.su> <20070313055029.GK58523@codelabs.ru> In-Reply-To: <20070313055029.GK58523@codelabs.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: rik@FreeBSD.org, Roman Kurakin , andre@FreeBSD.org, Yar Tikhiy , glebius@FreeBSD.org, thompsa@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 11:36:59 -0000 Eygene Ryabinkin wrote: > I tried to understand this, because Bruce already gave me a patch, > but I am a bit stupid: I do not see how M_PROMISC that is cleared > unconditionally before BRIDGE_INPUT will help us to identify the > right interface. As I see now, the BRIDGE_INPUT is called once from > if_ethersubr.c, once from if_gif.c and once from ng_ether.c: > http://fxr.watson.org/fxr/ident?i=BRIDGE_INPUT > So there is no distinct code paths that can allow BRIDGE_INPUT to > modify its behaviour based on the M_PROMISC flag. > > But I feel that I am wrong in some place and missing some discuission > on the M_PROMISC. Can anyone point me to the right place? > In short: M_PROMISC exists to easily identify frames which were received promiscuously, to prevent infinite recursion, and to simplify code which needs to re-enter ether_input(). M_PROMISC is a flag introduced by NetBSD into their ethernet input path to deal with the case where an entity in the network stack needs to receive frames promiscuously, without necessarily passing those frames to the upper layers e.g. IPv4. It is not documented; the code is the documentation in this instance. It is cleared when an mbuf chain is passed to another entity which may consume the frame in that mbuf chain, in case the entity re-enters ether_input() with the same mbuf chain for local delivery (e.g. bridge, netgraph, vlan). I do not think M_PROMISC alone is sufficient to solve our architectural problems at Layer 2. > >> So all the tangled if()s inside LIST_FOREACH() will be gone completely >> from bridge_input(). >> > > But we still need to see if we want to consume the packet by the > bridge or it members or to do forwarding. Am I missing something? > Correct. Just because a frame was received promiscuously, does not imply that the bridge will be the only consumer of that frame. > >>>> I'm afraid there is a serious flaw in the very notion of such a >>>> "logical" interface. If it's true, we should start by admitting >>>> that the support for "logical" interfaces should be a side hack for >>>> compatibility, and not something that can live forever on the main >>>> code path. >>>> > > I agree with you. That is why I patched if_bridge once again to enable > the pfil hooks for the "physical" incoming interface. And there are > two ways to solve the problem: > - to give each VLAN interface the distinct MAC, as Bruce suggested, > I didn't suggest this. :-) I pointed out that the code matches on destination MAC only at the moment. vlan(4) is an abstraction of something which exists as part of the Ethernet framing, and is not a physical interface in its own right, as was correctly identified above. > - to refuse the "logical" interfaces completely and to support only > "physical" ones. It is what my very first (and very short) patch > did. But this can break some existing firewall rulesets. And that > should be discuissed -- we do not need the total breakage due to > out changes. And you're right: the best way for this alternative is to > leave the current behaviour as the compatibility sysctl that is turned > off by default and move to the filtering on the "physical" interfaces > by default. No problem, but skilled network people that are using > FreeBSD as the bridge for VLANs should say if they are happy with it. > I think it is acceptable for if_bridge(4) to know about the existence of VLAN interfaces and to deal with them accordingly as a special case, because Spanning Tree is specified differently in the case where VLANs are present. Therefore it is not unreasonable for if_bridge(4) to be looking at VLAN headers in the mbuf chain. As such I think the behaviour Andrew Thompson and I were discussing off list should be made the default: that is, the first 802.1q VLAN header is stripped off and turned into an M_VLANTAG before being passed to other consumers in the stack. The presence of M_VLANTAG makes it very easy to see that a frame was received with a VLAN header without involving vlan(4) and reduces the amount of 802.1q specific code across Layer 2 subsystems. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Mar 13 12:00:17 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5D1716A4E7; Tue, 13 Mar 2007 12:00:17 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 569FA13C489; Tue, 13 Mar 2007 12:00:17 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HR5fr-000Pbb-Jw; Tue, 13 Mar 2007 15:00:16 +0300 Date: Tue, 13 Mar 2007 15:00:05 +0300 From: Eygene Ryabinkin To: "Bruce M. Simpson" Message-ID: <20070313120005.GT58523@codelabs.ru> References: <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> <45F5BD36.1070205@inse.ru> <20070312214926.GK44732@comp.chem.msu.su> <20070313055029.GK58523@codelabs.ru> <45F68CD6.2030300@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <45F68CD6.2030300@FreeBSD.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: rik@FreeBSD.org, Roman Kurakin , andre@FreeBSD.org, Yar Tikhiy , glebius@FreeBSD.org, thompsa@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 12:00:17 -0000 Bruce, Tue, Mar 13, 2007 at 11:36:54AM +0000, Bruce M. Simpson wrote: > > In short: M_PROMISC exists to easily identify frames which were received > promiscuously, to prevent infinite recursion, and to simplify code which needs > to re-enter ether_input(). > > M_PROMISC is a flag introduced by NetBSD into their ethernet input path to deal > with the case where an entity in the network stack needs to receive frames > promiscuously, without necessarily passing those frames to the upper layers > e.g. IPv4. It is not documented; the code is the documentation in this > instance. > > It is cleared when an mbuf chain is passed to another entity which may consume > the frame in that mbuf chain, in case the entity re-enters ether_input() with > the same mbuf chain for local delivery (e.g. bridge, netgraph, vlan). Got the idea, thanks! > >I agree with you. That is why I patched if_bridge once again to enable > >the pfil hooks for the "physical" incoming interface. And there are > >two ways to solve the problem: > >- to give each VLAN interface the distinct MAC, as Bruce suggested, > > > I didn't suggest this. :-) OK, sorry. > >- to refuse the "logical" interfaces completely and to support only > >"physical" ones. It is what my very first (and very short) patch > >did. But this can break some existing firewall rulesets. And that > >should be discuissed -- we do not need the total breakage due to > >out changes. And you're right: the best way for this alternative is to > >leave the current behaviour as the compatibility sysctl that is turned > >off by default and move to the filtering on the "physical" interfaces > >by default. No problem, but skilled network people that are using > >FreeBSD as the bridge for VLANs should say if they are happy with it. > > > I think it is acceptable for if_bridge(4) to know about the existence of VLAN > interfaces and to deal with them accordingly as a special case, because > Spanning Tree is specified differently in the case where VLANs are present. > Therefore it is not unreasonable for if_bridge(4) to be looking at VLAN headers > in the mbuf chain. I see your point, but all if_bridge can do with the VLAN header is to identify the VLAN ID. But this will not help us in the case of multiple identical MAC addresses, when the "physical" input interface is not the L2 destination. Just because all we can do with the VLAN tag is to identify the physical incoming VLAN. But it is already passed to the bridge_input in the form of 'ifp'. Or I am missing some point here? > As such I think the behaviour Andrew Thompson and I were discussing off list > should be made the default: that is, the first 802.1q VLAN header is stripped > off and turned into an M_VLANTAG before being passed to other consumers in the > stack. So you want the if_vlan to mark the packet with the ETHERTYPE_VLAN (in-band VLAN tag) with M_VLANTAG? > The presence of M_VLANTAG makes it very easy to see that a frame was received > with a VLAN header without involving vlan(4) and reduces the amount of 802.1q > specific code across Layer 2 subsystems. Sure. But it seems to be unusable for our bug. Though maybe I am wrong. -- Eygene From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 09:57:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2E3716A400 for ; Wed, 14 Mar 2007 09:57:59 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id D2AFC13C45E for ; Wed, 14 Mar 2007 09:57:45 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2E9vT3w002885; Wed, 14 Mar 2007 12:57:29 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2E9vQS4002882; Wed, 14 Mar 2007 12:57:26 +0300 (MSK) (envelope-from yar) Date: Wed, 14 Mar 2007 12:57:26 +0300 From: Yar Tikhiy To: Luigi Rizzo Message-ID: <20070314095725.GA1766@comp.chem.msu.su> References: <20070310153534.GA35834@comp.chem.msu.su> <20070313004543.A54774@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070313004543.A54774@xorpc.icir.org> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: Who is to load dummynet.ko? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 09:57:59 -0000 On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote: > On Sat, Mar 10, 2007 at 06:35:34PM +0300, Yar Tikhiy wrote: > > Hi folks, > > > > Just noticed that neither ipfw(8) nor /etc/rc.d/ipfw cares to load > > dummynet.ko. It can result in a broken setup when one migrates > > from a custom monolithic kernel to GENERIC with modules, which is > > a nice way to reduce support headache today. > > > > There are at least two possible ways to deal with the issue. The > > easy way is to give the task of loading dummynet.ko to /etc/rc.d/ipfw. > > The problem with it is that the script cannot know in advance if > > dummynet is really used by the ipfw rules to be loaded. The decision > > whether to load the module is left to rc.conf(5) in this case. > > i think this is a reasonable option and the one to use for all ipfw > extensions (divert, dummynet, in-kernel nat and so on). Thank you for your reply! Loading dummynet via rc.d is really easy, I think I can add it. However, I'm afraid it won't be a real long-term solution -- please see below. > Making the load on demand would require a bit of additional code because > it depends on the actual rules being loaded, and the rules are not > parsed at load time. Plus, i believe that in a case like this > the decision of which modules to load should be a conscious one > taken upfront by the system administrator (i.e. end up in rc.conf > or loader.conf) rather than be the result of the actual ipfw > configuration. Well, I used to stick to this opinion, too, in the good old days. But today we are growing more and more modularity in our kernel, and it's a nice feature to have. With a lot of modules, the issue of double configuration appears: if I want feature FOO, I have to add its configuration AND not forget to load the respective module. It can be a pain as the number of such cases rockets up. Today at least mount, ifconfig, and netgraph provide for loading modules on demand, with the former two being system's core components. I've just taken a look at the ipfw userland utility code. It notices a "pipe" or "queue" keyword in its command line rather early, and it can be a good moment to check and load dummynet.ko. Ditto for divert. Or the inner function do_cmd() can load a missing module before issuing setsockopt(), which is even better as we won't load the module on a read access or if the command line contains a syntax error. do_cmd() can even load ipfw.ko itself so that people no longer have to type, e.g.: (kldload ipfw && ipfw add 65000 allow ip from any to any) > /dev/null 2>&1 insead of just: ipfw add 65000 allow ip from any to any if a need to load ipfw.ko for some experiments arise. > > The second way is to move the task of loading modules to ipfw(8). > > Then it could load ipfw.ko, divert.ko, and dummynet.ko on demand. > > cheers > luigi -- Yar From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 10:20:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00ADD16A404 for ; Wed, 14 Mar 2007 10:20:28 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id F3CE813C457 for ; Wed, 14 Mar 2007 10:20:25 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2EAKOR9003713 for ; Wed, 14 Mar 2007 13:20:24 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2EAKNlh003711 for freebsd-net@freebsd.org; Wed, 14 Mar 2007 13:20:23 +0300 (MSK) (envelope-from yar) Date: Wed, 14 Mar 2007 13:20:23 +0300 From: Yar Tikhiy To: freebsd-net@freebsd.org Message-ID: <20070314102023.GB1766@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: Generic ioctl and ether_ioctl don't agree X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 10:20:28 -0000 Hi folks, Quite a while ago I noticed that our ioctl handlers get the ioctl command via u_long, but ether_ioctl()'s command argument is int. This disarray dates back to 1998, when ioctl functions started to take u_long as the command, but ether_ioctl() was never fixed. Fortunately, our ioctl command coding still fits in 32 bits, or else we would've got problems on 64-bit arch'es already. I'd like to fix this long-standing bug some day after RELENG_7 is branched. Of course, this will break ABI to network modules on all 64-bit arch'es. BTW, the same applies to other L2 layers, such as firewire, which seems to have been cloned from if_ethersubr.c. Any objections or comments? Thanks! -- Yar From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 11:19:00 2007 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0A0416A406; Wed, 14 Mar 2007 11:19:00 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id B683713C458; Wed, 14 Mar 2007 11:19:00 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (glebius@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2EBJ0Fw024139; Wed, 14 Mar 2007 11:19:00 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2EBJ02B024135; Wed, 14 Mar 2007 11:19:00 GMT (envelope-from glebius) Date: Wed, 14 Mar 2007 11:19:00 GMT From: Gleb Smirnoff Message-Id: <200703141119.l2EBJ02B024135@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org Cc: Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 11:19:01 -0000 Synopsis: [net] [patch] ifconfig may not connect an interface to known network Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Wed Mar 14 11:18:24 UTC 2007 Responsible-Changed-Why: I'll work on this. http://www.freebsd.org/cgi/query-pr.cgi?pr=106722 From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 11:35:26 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30F0E16A405 for ; Wed, 14 Mar 2007 11:35:26 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 05BD913C46C for ; Wed, 14 Mar 2007 11:35:25 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l2EBZ6Zw076696; Wed, 14 Mar 2007 03:35:06 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l2EBZ6J8076695; Wed, 14 Mar 2007 04:35:06 -0700 (PDT) (envelope-from rizzo) Date: Wed, 14 Mar 2007 04:35:06 -0700 From: Luigi Rizzo To: Yar Tikhiy Message-ID: <20070314043506.A76618@xorpc.icir.org> References: <20070310153534.GA35834@comp.chem.msu.su> <20070313004543.A54774@xorpc.icir.org> <20070314095725.GA1766@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070314095725.GA1766@comp.chem.msu.su>; from yar@comp.chem.msu.su on Wed, Mar 14, 2007 at 12:57:26PM +0300 Cc: freebsd-net@freebsd.org Subject: Re: Who is to load dummynet.ko? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 11:35:26 -0000 On Wed, Mar 14, 2007 at 12:57:26PM +0300, Yar Tikhiy wrote: > On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote: ... > > Making the load on demand would require a bit of additional code because > > it depends on the actual rules being loaded, and the rules are not > > parsed at load time. Plus, i believe that in a case like this > > the decision of which modules to load should be a conscious one > > taken upfront by the system administrator (i.e. end up in rc.conf > > or loader.conf) rather than be the result of the actual ipfw > > configuration. > > Well, I used to stick to this opinion, too, in the good old days. > But today we are growing more and more modularity in our kernel, > and it's a nice feature to have. With a lot of modules, the issue > of double configuration appears: if I want feature FOO, I have to yes this is also try. > add its configuration AND not forget to load the respective module. > It can be a pain as the number of such cases rockets up. Today at > least mount, ifconfig, and netgraph provide for loading modules on > demand, with the former two being system's core components. > > I've just taken a look at the ipfw userland utility code. It notices > a "pipe" or "queue" keyword in its command line rather early, and > it can be a good moment to check and load dummynet.ko. Ditto for actually, i think it is the kernel itself (in the setsockopt handler, once it validates the rule) that should load the module, and not leave the task to the userland utility. Other modules already do this, e.g. iwi loads the firmware autonomously, and maybe even netgraph components do something similar. For dummynet and divert, this can be surely put in the setsockopt handler which is in ipfw.ko - if you need to autoload ipfw.ko, then i am not sure where to put the hooks (in the kernel) but i am pretty confident that there must be a good place. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 11:59:20 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC87216A402 for ; Wed, 14 Mar 2007 11:59:20 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.freebsd.org (Postfix) with ESMTP id 4695913C487 for ; Wed, 14 Mar 2007 11:59:19 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l2EBxGLu059039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Mar 2007 14:59:16 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id l2EBxGvv059038; Wed, 14 Mar 2007 14:59:16 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 14 Mar 2007 14:59:16 +0300 From: Gleb Smirnoff To: freebsd-net@FreeBSD.org Message-ID: <20070314115916.GB2713@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , freebsd-net@FreeBSD.org, Vladimir Ivanov , bug-followup@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: bug-followup@FreeBSD.org, Vladimir Ivanov Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 11:59:21 -0000 Just for the reference, here is a backtrace that shows how EEXIST is returned: rtrequest1(1,e6560aec,e6560ae0,e6560aec,30,...) at rtrequest1+0x658^M rtinit(c3e21500,1,1) at rtinit+0x193^M in_addprefix(c3e21500,1,e6560b68,0,1,...) at in_addprefix+0xa1^M in_ifinit(c3c4ec00,c3e21500,c3eb6e50,0) at in_ifinit+0x761^M in_control(c3f37bac,8040691a,c3eb6e40,c3c4ec00,c3e9b740) at in_control+0x93e^M ifioctl(c3f37bac,8040691a,c3eb6e40,c3e9b740,0,...) at ifioctl+0x1cf^M soo_ioctl(c3e5a828,8040691a,c3eb6e40,c414e000,c3e9b740) at soo_ioctl+0x2db^M kern_ioctl(c3e9b740,3,8040691a,c3eb6e40) at kern_ioctl+0x296^M ioctl(c3e9b740,e6560d00) at ioctl+0xf1^M syscall(e6560d38) at syscall+0x242^M Xint0x80_syscall() at Xint0x80_syscall+0x20^M The patch proposed vy Vladimir really looks like a hack. It covers only a case when old route was a gateway one. So, even with patch the following won't work: route add 10.0.0.0/24 -iface lo0 ifconfig IFACE 10.0.0.1/24 alias Also, I am afraid of the side effects, when patched kernel will substitute route in a case when it should return error. AFAIK, the problem needs a more generic approach. I see two approaches. 1) Introduce RTM_CHANGEADD, a command that will forcibly add route, deleting all conflicting ones. Use this command in in_addprefix(). 2) In rt_flags field we still have several extra bits. We can use them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX, where XXX is a routing protocol. When issuing RTM_ADD a route with a preferred source (e.g. CONNECTED vs STATIC) will override the old one. freebsd-net subscibers, what do you think? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 12:13:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 820F516A402; Wed, 14 Mar 2007 12:13:52 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from pinky.frank-behrens.de (pinky.frank-behrens.de [82.139.199.24]) by mx1.freebsd.org (Postfix) with ESMTP id E486413C469; Wed, 14 Mar 2007 12:13:51 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from [192.168.20.32] (sun.behrens [192.168.20.32]) by pinky.frank-behrens.de (8.13.8/8.13.8) with ESMTP id l2ECDntN087975; Wed, 14 Mar 2007 13:13:49 +0100 (CET) (envelope-from frank@pinky.sax.de) Message-Id: <200703141213.l2ECDntN087975@pinky.frank-behrens.de> From: "Frank Behrens" To: "Bruce M. Simpson" Date: Wed, 14 Mar 2007 13:12:59 +0100 MIME-Version: 1.0 Priority: normal In-reply-to: <45F15378.3020207@FreeBSD.org> References: <200703091036.l29AawwJ005466@pinky.frank-behrens.de> X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: freebsd-net@freebsd.org Subject: Re: tap(4) should go UP if opened X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 12:13:52 -0000 Bruce M. Simpson wrote on 9 Mar 2007 12:30: > However, we also support the creation of tap/tun instances by > non-super-users, so there is motivation for the change. Configuring a > tap interface to up by a non-superuser should only be permitted if the > interface itself was created by a non-superuser, and if > net.link.tap.user_open is set to 1. > > A more involved patch is needed to do this right for all cases -- we > should not do this by default. After thinking about the problem I agree with you and propose the following patch: --- sys/net/if_tap.c.orig Thu Mar 8 19:10:59 2007 +++ sys/net/if_tap.c Wed Mar 14 12:35:58 2007 @@ -501,6 +501,8 @@ s = splimp(); ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + if (tapuopen) + ifp->if_flags |= IFF_UP; splx(s); TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, minor(dev)); Rationale: For transmitting packets via tap(4) device (at least) two conditions have to met: 1. The control device must be opened by an process. 2. The ethernet interface must be UP. For 1. we allow non-root processes the access, when a) sysctl net.link.tap.user_open=1 AND b) /dev/tapx has sufficient permissions If we have no possibility to mark the interface as UP for the non-root process the net.link.tap.user_open=1 is useless, because we can not transmit any packets. With the patch the interface goes UP only, when the administrator allowed non-root user access. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 12:31:22 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63F2016A401 for ; Wed, 14 Mar 2007 12:31:22 +0000 (UTC) (envelope-from keith.arner@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id E75C213C465 for ; Wed, 14 Mar 2007 12:31:21 +0000 (UTC) (envelope-from keith.arner@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so182202nfc for ; Wed, 14 Mar 2007 05:31:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=tNvDCWClTOb+q6x5PIjMUHN4mvupcjnDaQ2PPhsA/9xye8nT2nlBdTDwJludmUnEoADjkr57ygum8JVHfJfCXK7GNGkWJzF8FONAE3arsmOPkp1jOQIYpJIJcb8PBCTlHq6BFhuszJcYOJNWs0c2EgWy+qsaKU9EIShfdVzenSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=l8WAvOgFmp/nL5kUjv5GCMeU431EqHlDnaJMmrecR3JLBJWXvCfeRCKabi6iWAzAky+mwYFBQmPbaI5bmImo67kNSpDOiIJMdPQ93RN416FwQUf5cMgdWYhMKC9qpJXDpBR9hSL11wiJNS0DKNfS+yR7l3qn0tNJlJyDc/LKb54= Received: by 10.78.164.9 with SMTP id m9mr1146827hue.1173875480629; Wed, 14 Mar 2007 05:31:20 -0700 (PDT) Received: by 10.82.121.1 with HTTP; Wed, 14 Mar 2007 05:31:20 -0700 (PDT) Message-ID: <8e552a500703140531l39f6fae5o518ee271b879eb1a@mail.gmail.com> Date: Wed, 14 Mar 2007 08:31:20 -0400 From: "Keith Arner" Sender: keith.arner@gmail.com To: "Robert Watson" In-Reply-To: <20070311073249.R20646@fledge.watson.org> MIME-Version: 1.0 References: <45C0CA5D.5090903@incunabulum.net> <45E6BEE0.2050307@FreeBSD.org> <45E6C22D.7060200@freebsd.org> <45E6D70C.10104@FreeBSD.org> <45EEB086.3050409@FreeBSD.org> <45F03269.7050705@FreeBSD.org> <45F08F1D.5080708@us.fujitsu.com> <20070310035135.B30274@fledge.watson.org> <8e552a500703102157p1845926au65bb3adaf81c01c0@mail.gmail.com> <20070311073249.R20646@fledge.watson.org> X-Google-Sender-Auth: bc3f232510bb6fcc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: netisr_direct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 12:31:22 -0000 On 3/11/07, Robert Watson wrote: > > > Yes -- right now the in-bound TCP path is essentially serialized because > of > the tcbinfo lock. The reason for this is that the tcbinfo lock doesn't > just > protect the inpcb chains during lookup, but also effectively acts as a > reference to prevent the inpcb from being freed during input processing. > There are several ways we could start to reduce contention on that lock: > So, why is the tcbinfo lock being used to protect the pcb from deletion? Why isn't the INP_LOCK on the pcb used, instead? Keith -- Well, I didn't find the Holy Grail, but I did find a rusty cup without too many holes in it... -- Jeff Semke From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 12:50:14 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89A4716A400 for ; Wed, 14 Mar 2007 12:50:14 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 61FE513C483 for ; Wed, 14 Mar 2007 12:50:14 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 0F07C1F7F4E; Wed, 14 Mar 2007 08:50:14 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Wed, 14 Mar 2007 08:50:14 -0400 X-Sasl-enc: xTP0CENA3KYZtHAhP5xZIPF8eSlWem4Xs9wRrPXFquns 1173876614 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id CF219BD3B; Wed, 14 Mar 2007 08:50:13 -0400 (EDT) Message-ID: <45F7EF84.5070700@FreeBSD.org> Date: Wed, 14 Mar 2007 12:50:12 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Yar Tikhiy References: <20070314102023.GB1766@comp.chem.msu.su> In-Reply-To: <20070314102023.GB1766@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Generic ioctl and ether_ioctl don't agree X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 12:50:14 -0000 Yar Tikhiy wrote: > Hi folks, > > Quite a while ago I noticed that our ioctl handlers get the ioctl > command via u_long, but ether_ioctl()'s command argument is int. > This disarray dates back to 1998, when ioctl functions started to > take u_long as the command, but ether_ioctl() was never fixed. > Fortunately, our ioctl command coding still fits in 32 bits, or > else we would've got problems on 64-bit arch'es already. I'd like > to fix this long-standing bug some day after RELENG_7 is branched. > Of course, this will break ABI to network modules on all 64-bit > arch'es. BTW, the same applies to other L2 layers, such as firewire, > which seems to have been cloned from if_ethersubr.c. > This is one of those annoying things which breaks compatibility with external modules. I'm not sure about this, though. I was getting sign extension warnings on amd64 last week when I was testing the IGMPv3 aware mtest(8). Perhaps if we're fixing these ABIs, we should commit to an explicit C99 type with known bit width, i.e. uint32_t. I would be much happier if we began using C99 types in the code. Just my 2c. BMS From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 12:50:46 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1B0116A400 for ; Wed, 14 Mar 2007 12:50:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8373813C448 for ; Wed, 14 Mar 2007 12:50:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id EADB746F32; Wed, 14 Mar 2007 07:50:45 -0500 (EST) Date: Wed, 14 Mar 2007 13:50:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Keith Arner In-Reply-To: <8e552a500703140531l39f6fae5o518ee271b879eb1a@mail.gmail.com> Message-ID: <20070314134013.P60010@fledge.watson.org> References: <45C0CA5D.5090903@incunabulum.net> <45E6BEE0.2050307@FreeBSD.org> <45E6C22D.7060200@freebsd.org> <45E6D70C.10104@FreeBSD.org> <45EEB086.3050409@FreeBSD.org> <45F03269.7050705@FreeBSD.org> <45F08F1D.5080708@us.fujitsu.com> <20070310035135.B30274@fledge.watson.org> <8e552a500703102157p1845926au65bb3adaf81c01c0@mail.gmail.com> <20070311073249.R20646@fledge.watson.org> <8e552a500703140531l39f6fae5o518ee271b879eb1a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: netisr_direct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 12:50:46 -0000 On Wed, 14 Mar 2007, Keith Arner wrote: > On 3/11/07, Robert Watson wrote: >> >> Yes -- right now the in-bound TCP path is essentially serialized because of >> the tcbinfo lock. The reason for this is that the tcbinfo lock doesn't >> just protect the inpcb chains during lookup, but also effectively acts as a >> reference to prevent the inpcb from being freed during input processing. >> There are several ways we could start to reduce contention on that lock: > > So, why is the tcbinfo lock being used to protect the pcb from deletion? Why > isn't the INP_LOCK on the pcb used, instead? The reasoning here is a little complex, and has to do with combining two uses of the tcbinfo lock. The tcbinfo lock is before the inpcb lock in the lock order, as you need to access the tcbinfo lists in order to acquire a reference to the inpcb. tcp_input() will always acquire a tcbinfo lock (whether one as today, or one of several in the future) in order to look up the inpcb. tcp_input() will then also acquire an inpcb lock to protect individual connection state. There are then two cases: simple cases, where we know we don't need to access the lists again, and then complex cases where we may need to access the list. A typical example of the former is a straight ACK in the fast path, which will modify per-connection state only, and a typical example of the latter is a RST where we will tear down connection, which may remove the inpcb from the global lists. In the former case, we do release the tcbinfo lock (in most cases) once we have decided that we won't need it; in the latter case we hold it because re-acquiring the lock would require dropping the inpcb lock for lock order reasons should the connection close. This is where moving to a reference count would help us: it would allow releasing both locks while maintaining a valid pointer to the inpcb, in turn letting us drop the tcbinfo lock and then re-acquire it later if we do hit a connection close case. This could use some refinement, and there are probably more cases we could be dropping the tcbinfo lock. BTW, in 7.x there is significantly less contention on the pcbinfo lock because it's no longer acquired in any of the common send and receive paths in TCP, whereas previously it was. This significantly lowers contention between the upper/lower halves of the kernel: that is, between a user thread performing send or receive on a TCP socket and netisr processing. In 6.x, the pcbinfo lock is used more extensively in order to prevent the inpcb from being freed. The change I've made in 7.x is to guarantee that so_pcb will always be valid for a properly referenced socket, keeping the inpcb around until the socket is freed in the case of a reset, rather than leaving the socket without the inpcb (and hence requiring a lock to keep so_pcb valid). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 13:09:29 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5303416A401 for ; Wed, 14 Mar 2007 13:09:29 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 13CB613C457 for ; Wed, 14 Mar 2007 13:09:29 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id B92DA1F88FF; Wed, 14 Mar 2007 09:09:28 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 14 Mar 2007 09:09:28 -0400 X-Sasl-enc: 8nRDUvxKMyDZBptSg+DT3NUkfKK99tGDNeyiUDC5oVEZ 1173877768 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 4C6DE1F8F3; Wed, 14 Mar 2007 09:09:27 -0400 (EDT) Message-ID: <45F7F405.4040607@FreeBSD.org> Date: Wed, 14 Mar 2007 13:09:25 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Frank Behrens References: <200703091036.l29AawwJ005466@pinky.frank-behrens.de> <200703141213.l2ECDntN087975@pinky.frank-behrens.de> In-Reply-To: <200703141213.l2ECDntN087975@pinky.frank-behrens.de> Content-Type: multipart/mixed; boundary="------------040501000203090403080306" Cc: freebsd-net@freebsd.org Subject: Re: tap(4) should go UP if opened X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 13:09:29 -0000 This is a multi-part message in MIME format. --------------040501000203090403080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Frank Behrens wrote: > If we have no possibility to mark the interface as UP for the non-root process the > net.link.tap.user_open=1 is useless, because we can not transmit any packets. With the > patch the interface goes UP only, when the administrator allowed non-root user access. > > The conditional in the second patch is a no-op as the open will be forbidden if the user did not have privilege to open the tap. Bringing the interface up by default potentially violates POLA, so this should not happen by default. Please try the attached patch, which puts this behaviour under a sysctl. Thanks, BMS --------------040501000203090403080306 Content-Type: text/x-patch; name="tapuponopen.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tapuponopen.diff" ==== //depot/user/bms/netdev/sys/net/if_tap.c#1 - /home/bms/p4/netdev/sys/net/if_tap.c ==== --- /tmp/tmp.58336.0 Wed Mar 14 13:06:09 2007 +++ /home/bms/p4/netdev/sys/net/if_tap.c Wed Mar 14 13:05:54 2007 @@ -150,7 +150,8 @@ */ static struct mtx tapmtx; static int tapdebug = 0; /* debug flag */ -static int tapuopen = 0; /* allow user open() */ +static int tapuopen = 0; /* allow user open() */ +static int tapuponopen = 0; /* IFF_UP on open() */ static int tapdclone = 1; /* enable devfs cloning */ static SLIST_HEAD(, tap_softc) taphead; /* first device */ static struct clonedevs *tapclones; @@ -164,6 +165,8 @@ "Ethernet tunnel software network interface"); SYSCTL_INT(_net_link_tap, OID_AUTO, user_open, CTLFLAG_RW, &tapuopen, 0, "Allow user to open /dev/tap (based on node permissions)"); +SYSCTL_INT(_net_link_tap, OID_AUTO, up_on_open, CTLFLAG_RW, &tapuponopen, 0, + "Bring interface up when /dev/tap is opened"); SYSCTL_INT(_net_link_tap, OID_AUTO, devfs_cloning, CTLFLAG_RW, &tapdclone, 0, "Enably legacy devfs interface creation"); SYSCTL_INT(_net_link_tap, OID_AUTO, debug, CTLFLAG_RW, &tapdebug, 0, ""); @@ -502,6 +505,8 @@ s = splimp(); ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + if (tapuponopen) + ifp->if_flags |= IFF_UP; splx(s); TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, minor(dev)); --------------040501000203090403080306-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 13:20:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78D7516A402 for ; Wed, 14 Mar 2007 13:20:51 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 50B4F13C46A for ; Wed, 14 Mar 2007 13:20:51 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id EB33F1F85C0; Wed, 14 Mar 2007 09:20:50 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 14 Mar 2007 09:20:50 -0400 X-Sasl-enc: jo3e4bg6httM8GzAb2vd3GoKY20FZZ4eL+IjfpkuOzXS 1173878450 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 52A3C1F7B9; Wed, 14 Mar 2007 09:20:50 -0400 (EDT) Message-ID: <45F7F6AF.1010308@FreeBSD.org> Date: Wed, 14 Mar 2007 13:20:47 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Aniruddha Bohra References: <45F55575.9040401@cs.rutgers.edu> In-Reply-To: <45F55575.9040401@cs.rutgers.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Removal of redundant entries from ifnet manpage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 13:20:51 -0000 Aniruddha Bohra wrote: > Hi, > The ifnet manpage contains entries for the following routines which do > not exist in the ifnet struct. committed, thanks! From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 13:29:43 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE4F416A409; Wed, 14 Mar 2007 13:29:43 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from pinky.frank-behrens.de (pinky.frank-behrens.de [82.139.199.24]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB2213C48C; Wed, 14 Mar 2007 13:29:43 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from [192.168.20.32] (sun.behrens [192.168.20.32]) by pinky.frank-behrens.de (8.13.8/8.13.8) with ESMTP id l2EDTfuJ089208; Wed, 14 Mar 2007 14:29:41 +0100 (CET) (envelope-from frank@pinky.sax.de) Message-Id: <200703141329.l2EDTfuJ089208@pinky.frank-behrens.de> From: "Frank Behrens" To: "Bruce M. Simpson" Date: Wed, 14 Mar 2007 14:29:48 +0100 MIME-Version: 1.0 Priority: normal In-reply-to: <45F7F405.4040607@FreeBSD.org> References: <200703141213.l2ECDntN087975@pinky.frank-behrens.de> X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: freebsd-net@FreeBSD.org Subject: Re: tap(4) should go UP if opened X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 13:29:44 -0000 Bruce, many thanks for your fast response. Bruce M. Simpson wrote on 14 Mar 2007 13:09: > The conditional in the second patch is a no-op as the open will be > forbidden if the user did not have privilege to open the tap. Bringing No. A process running with root rights can always open the tap. > the interface up by default potentially violates POLA, so this should > not happen by default. Ok, I see that the behaviour changes. I wonder who used the "tap user open" sysctl, when additional root rights are necessary to bring the interface UP? I can't imagine a setup where this could be used, somebody else? > Please try the attached patch, which puts this behaviour under a sysctl. Fine! This should work without problems. I agree with this solution, sounds good. I'll test it and report the result. Regards and thanks for your support, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 14:12:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38D0216A400 for ; Wed, 14 Mar 2007 14:12:22 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id ED2B213C455 for ; Wed, 14 Mar 2007 14:11:59 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2EEBl3G008810; Wed, 14 Mar 2007 17:11:47 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2EEBhWD008807; Wed, 14 Mar 2007 17:11:43 +0300 (MSK) (envelope-from yar) Date: Wed, 14 Mar 2007 17:11:43 +0300 From: Yar Tikhiy To: Luigi Rizzo Message-ID: <20070314141142.GB3830@comp.chem.msu.su> References: <20070310153534.GA35834@comp.chem.msu.su> <20070313004543.A54774@xorpc.icir.org> <20070314095725.GA1766@comp.chem.msu.su> <20070314043506.A76618@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070314043506.A76618@xorpc.icir.org> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: Who is to load dummynet.ko? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 14:12:22 -0000 On Wed, Mar 14, 2007 at 04:35:06AM -0700, Luigi Rizzo wrote: > On Wed, Mar 14, 2007 at 12:57:26PM +0300, Yar Tikhiy wrote: > > On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote: > ... > > > Making the load on demand would require a bit of additional code because > > > it depends on the actual rules being loaded, and the rules are not > > > parsed at load time. Plus, i believe that in a case like this > > > the decision of which modules to load should be a conscious one > > > taken upfront by the system administrator (i.e. end up in rc.conf > > > or loader.conf) rather than be the result of the actual ipfw > > > configuration. > > > > Well, I used to stick to this opinion, too, in the good old days. > > But today we are growing more and more modularity in our kernel, > > and it's a nice feature to have. With a lot of modules, the issue > > of double configuration appears: if I want feature FOO, I have to > > yes this is also try. > > > add its configuration AND not forget to load the respective module. > > It can be a pain as the number of such cases rockets up. Today at > > least mount, ifconfig, and netgraph provide for loading modules on > > demand, with the former two being system's core components. > > > > I've just taken a look at the ipfw userland utility code. It notices > > a "pipe" or "queue" keyword in its command line rather early, and > > it can be a good moment to check and load dummynet.ko. Ditto for > > actually, i think it is the kernel itself (in the setsockopt handler, > once it validates the rule) that should load the module, and not leave > the task to the userland utility. Other modules already do this, > e.g. iwi loads the firmware autonomously, and maybe even netgraph components > do something similar. > > For dummynet and divert, this can be surely put in the setsockopt > handler which is in ipfw.ko - if you need to autoload ipfw.ko, > then i am not sure where to put the hooks (in the kernel) but i am > pretty confident that there must be a good place. As our fortune file puts it, "If God is dead, who will save the Queen?" :-) We seem to have a sort of a chicken and egg problem here. Perhaps that's why most auto-loading is done from the userland. Of course, putting it in the kernel is better because it allows for different control tools unconcerned with the modules (imagining xipfw(8) here), but it has this shortcoming. Another funny point is that now it's impossible to unload a module auto-loaded by the kernel itself. I'm uncertain if it's an architectural limitation or "just in case". -- Yar From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 14:48:33 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2DFA16A404 for ; Wed, 14 Mar 2007 14:48:33 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id DBEAF13C465 for ; Wed, 14 Mar 2007 14:48:33 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l2EEmBpB079035; Wed, 14 Mar 2007 06:48:11 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l2EEmBcG079034; Wed, 14 Mar 2007 07:48:11 -0700 (PDT) (envelope-from rizzo) Date: Wed, 14 Mar 2007 07:48:11 -0700 From: Luigi Rizzo To: Yar Tikhiy Message-ID: <20070314074811.A78933@xorpc.icir.org> References: <20070310153534.GA35834@comp.chem.msu.su> <20070313004543.A54774@xorpc.icir.org> <20070314095725.GA1766@comp.chem.msu.su> <20070314043506.A76618@xorpc.icir.org> <20070314141142.GB3830@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20070314141142.GB3830@comp.chem.msu.su>; from yar@comp.chem.msu.su on Wed, Mar 14, 2007 at 05:11:43PM +0300 Cc: freebsd-net@freebsd.org Subject: Re: Who is to load dummynet.ko? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 14:48:34 -0000 On Wed, Mar 14, 2007 at 05:11:43PM +0300, Yar Tikhiy wrote: > On Wed, Mar 14, 2007 at 04:35:06AM -0700, Luigi Rizzo wrote: ... > > actually, i think it is the kernel itself (in the setsockopt handler, > > once it validates the rule) that should load the module, and not leave > > the task to the userland utility. Other modules already do this, > > e.g. iwi loads the firmware autonomously, and maybe even netgraph components > > do something similar. > > > > For dummynet and divert, this can be surely put in the setsockopt > > handler which is in ipfw.ko - if you need to autoload ipfw.ko, > > then i am not sure where to put the hooks (in the kernel) but i am > > pretty confident that there must be a good place. > > As our fortune file puts it, "If God is dead, who will save the > Queen?" :-) We seem to have a sort of a chicken and egg problem not really. IP_FW_GET (and other commands) are processed in sys/netinet/raw_ip.c::rip_ctloutput() so it's there that we can try and autoload the module (if ip_fw_ctl_ptr == NULL). I don't know if there are hooks to autoload a protocol stack, as some are not modules - no ipv4.ko, ipv6.ko, but there is arcnet.ko, but you could in principle do the same thing with protocols and anywhere there is a missing function, annotate it with the functions to autoload the module supplying it. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 15:02:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A5DB16A400 for ; Wed, 14 Mar 2007 15:02:12 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.freebsd.org (Postfix) with ESMTP id 385DC13C459 for ; Wed, 14 Mar 2007 15:02:12 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id l2EF1dL8057372; Wed, 14 Mar 2007 10:01:39 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id l2EF1cuZ057371; Wed, 14 Mar 2007 10:01:38 -0500 (CDT) (envelope-from brooks) Date: Wed, 14 Mar 2007 10:01:38 -0500 From: Brooks Davis To: Yar Tikhiy Message-ID: <20070314150138.GC56444@lor.one-eyed-alien.net> References: <20070314102023.GB1766@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WplhKdTI2c8ulnbP" Content-Disposition: inline In-Reply-To: <20070314102023.GB1766@comp.chem.msu.su> User-Agent: Mutt/1.5.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 14 Mar 2007 10:01:39 -0500 (CDT) Cc: freebsd-net@freebsd.org Subject: Re: Generic ioctl and ether_ioctl don't agree X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 15:02:12 -0000 --WplhKdTI2c8ulnbP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 14, 2007 at 01:20:23PM +0300, Yar Tikhiy wrote: > Hi folks, >=20 > Quite a while ago I noticed that our ioctl handlers get the ioctl > command via u_long, but ether_ioctl()'s command argument is int. > This disarray dates back to 1998, when ioctl functions started to > take u_long as the command, but ether_ioctl() was never fixed. > Fortunately, our ioctl command coding still fits in 32 bits, or > else we would've got problems on 64-bit arch'es already. I'd like > to fix this long-standing bug some day after RELENG_7 is branched. > Of course, this will break ABI to network modules on all 64-bit > arch'es. BTW, the same applies to other L2 layers, such as firewire, > which seems to have been cloned from if_ethersubr.c. >=20 > Any objections or comments? Thanks! Why wait? We're allowed to break module ABIs in current at any time and there's no chance modules built on RELENG_6 will work on RELENG_7 trees anyway. -- Brooks --WplhKdTI2c8ulnbP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF+A5SXY6L6fI4GtQRAllSAJ46pjNPXUmgW75ecpgONqRNdpBKHQCgqbBf cL6E8d7By1TIU8h3sfgyvzk= =sbzp -----END PGP SIGNATURE----- --WplhKdTI2c8ulnbP-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 15:39:00 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B48E16A401; Wed, 14 Mar 2007 15:39:00 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.freebsd.org (Postfix) with ESMTP id BB07C13C448; Wed, 14 Mar 2007 15:38:58 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id A907133CA7; Wed, 14 Mar 2007 17:17:45 +0200 (SAST) Date: Wed, 14 Mar 2007 17:17:45 +0200 From: John Hay To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20070314151745.GA45847@zibbi.meraka.csir.co.za> References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121073244.GA80811@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: "Bruce A. Mah" , freebsd-net@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 15:39:00 -0000 Hi Tatuya, Well after getting distracted for a while, I am back with this one. On Fri, Jan 26, 2007 at 03:13:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Sun, 21 Jan 2007 09:32:44 +0200, > >>>>> John Hay said: > > >> There's another workaround for people stuck in this situation and who > >> aren't in a position to try this diff. That is to manually install > >> the host route like this: > >> > >> # route add -host -inet6 aaaa:bbbb:cccc:dddd::2 -interface gif0 -nostatic -llinfo > >> > >> Comments? > > > Well it seems that even my stuff does not always work perfectly with that > > change (1.48.2.15), so maybe we should revert it and I will search for > > yet other ways to make FreeBSD's IPv6 code to actually work for our stuff. > > > My "stuff" is a wireless IPv6 only network running in adhoc mode with > > olsrd as the routing protocol. The problem is that all nodes on a subnet > > cannot "see" each other, so olsrd needs to add routes to a node through > > another node. Sometimes, just to complicate matters a little more, you > > would want to have more than one network card in a host, all with the same > > subnet address. (For instance on a high site, with sector antennas.) > > > The case that I found that still does not work reliably, is if olsrd add > > the route and route is not immediately used, then the nd code will time > > it out and remove it. > > I think I'm responsible for the troubles. I've been thinking about > how to meet all the requests, and concluded that it's more complicated > than I originally thought. > > I've come across an idea that may solve the problems, but I'll need > more time to implement and test it. > > At the moment, I suggest reverting the 1.48.2.16 change for those who > simply wanted a gif to work. > > Regarding the OLSRD stuff, I'd like to know more specific features > that are sought. For example, > > - what should happen if link-layer address resolution fails? Should > then entry be removed? Probably not according to your description > above, but what would you expect the entry to become in this case? > > - once the link-layer address is resolved for the entry, should it be > regarded as "permanent" without any ND state changes? For example, > should NUD be performed on the cache? If yes, what should happen if > NUD detects the neighbor is unreachable? Should the entry be > removed? Again, probably not, but then what should it become? > Keeping it with the same link-layer address? Keeping it with an > empty link-layer address? Others? What if the neighbor is acting > as a router (setting the router flag in NAs)? Should destination > caches using the now-unreachable router be removed as described in > the protocol spec? Or should the destination caches be intact? > > I have my own speculation on these points, but I'd like to know what > the actual user(s) of these features want before taking any action > based on the speculation. Maybe some background. Olsrd (http://www.olsr.org/) does not use link-local addresses. I think it might have made thinks simpler... Except if you kill it in a weird way, it should remove routes that it have added, so I guess we don't really need a timeout. I can think of 3 types of routes that olsr use: 1) A direct route. In a single interface, you actually would not need these because the standard FreeBSD/Kame IPv6 code would handle it. The problem come in when you have more than one interface (and in the same subnet). I think it would be great if I can just tell the kernel which interface to use and let it do all the normal IPv6 stuff to make comms work to that host, but do it on the specified interface. If it then timeout the low-level stuff because of comms problems, that is fine, as long as it remember which interface to use when it has to try again. Let me try a picture: An olsr router may have more than one wireless interface to cover different areas. In this example ath0 and ath1 are configured with the same IPv6 subnet, eg. fd12:3:4:5::/48 --------------------- | | | D | | | |ath0 ath1| --------------------- )-| |-( ) ( ) ( A B C Then the client might be somewhere between A and B and sometimes work through ath0 and sometimes through ath1. Olsrd must be able to tell the kernel which interface to use. And it must keep on using that interface until olsrd delete that route and add another one. 2) A host route through another host. In my above picture, C might be too far to reach D directly, so it will need to add a route through B to get to D and A. The signal might fluctuate a bit, so it might be that C can reach D directly sometimes, so it must be possible for olsrd to delete a type 1 route and add a type 2 and also the other way around. I guess what I am saying is that when olsrd removes a route and the kernel have added some of its own stuff to make it work, that has to be deleted too or at least not stand in the way when another route for the same destination is added. 3) A network route. These are what they call HNA routes. They are not a problem on FreeBSD because they are our "normal" kind, eg. "route add 3ffe::/16 1234:4567::89" If you have more questions, please ask. Thanks. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 16:00:17 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F9E616A403; Wed, 14 Mar 2007 16:00:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id F032013C468; Wed, 14 Mar 2007 16:00:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 92CE81F7D07; Wed, 14 Mar 2007 12:00:16 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 14 Mar 2007 12:00:16 -0400 X-Sasl-enc: P3lmKnhmgCuiLGgo3DThDT6s9LQ74SnRxaCBy8MJtFqP 1173888016 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id CF5A320E0B; Wed, 14 Mar 2007 12:00:14 -0400 (EDT) Message-ID: <45F81C0D.2000608@FreeBSD.org> Date: Wed, 14 Mar 2007 16:00:13 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Gleb Smirnoff , freebsd-net@FreeBSD.org, Vladimir Ivanov , bug-followup@FreeBSD.org References: <20070314115916.GB2713@cell.sick.ru> In-Reply-To: <20070314115916.GB2713@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 16:00:17 -0000 Gleb Smirnoff wrote: > AFAIK, the problem needs a more generic approach. I see two approaches. > > 1) Introduce RTM_CHANGEADD, a command that will forcibly add route, > deleting all conflicting ones. Use this command in in_addprefix(). > > 2) In rt_flags field we still have several extra bits. We can use > them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX, > where XXX is a routing protocol. When issuing RTM_ADD a route with > a preferred source (e.g. CONNECTED vs STATIC) will override the old > one. > > The proposed changes also constitute a hack. I understand that they are being proposed to address problems we currently have in the stack, i.e. that we do not support multipathing, though it is more than likely they will be blown away in future when the architecture changes (and it has to change). Approach 1 is largely irrelevant if multiple paths are introduced to the network stack; there is then no concept of a conflicting forwarding entry, only preference derived from the interface, entry flags, or the entry ('route') itself. Approach 2 has some merit to it, although the forwarding plane should not care where the forwarding entry came from unless it needs to (e.g. next-hop resolution). It seems reasonable that the forwarding plane should tag entries as being 'CONNECTED' i.e. derived from the address configuration of an interface. I believe many implementations out there do this, and multi-path does not change this. We already have the RTF_PROTO1 flag to determine if the forwarding entry ('route') came from a routing protocol in userland, so there should be no need to change the existing flags. The RTF_STATIC flag only has special meaning in that it means 'the user added this forwarding entry manually via the route(8) command'. We should preserve these semantics, though I believe we should start implementing forwarding preference in the radix trie. I think it seems acceptable and reasonable that we use a limited form of Approach 2 to clobber 'routes' being aded in the case described in the PR, until such time as the network stack is re-engineered to support multiple paths and forwarding preference. I also believe it is useful if we start to use more modern technical jargon to discuss 'routes' in the network stack, because we are actually discussing the behaviour of entries in a forwarding table. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 16:10:25 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C607916A401; Wed, 14 Mar 2007 16:10:25 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.freebsd.org (Postfix) with ESMTP id 2C76D13C455; Wed, 14 Mar 2007 16:10:24 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l2EGANfQ061629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Mar 2007 19:10:24 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id l2EGANh8061628; Wed, 14 Mar 2007 19:10:23 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 14 Mar 2007 19:10:23 +0300 From: Gleb Smirnoff To: "Bruce M. Simpson" Message-ID: <20070314161023.GF2713@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , "Bruce M. Simpson" , freebsd-net@FreeBSD.org, Vladimir Ivanov , bug-followup@FreeBSD.org References: <20070314115916.GB2713@cell.sick.ru> <45F81C0D.2000608@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <45F81C0D.2000608@FreeBSD.org> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org, Vladimir Ivanov Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 16:10:25 -0000 On Wed, Mar 14, 2007 at 04:00:13PM +0000, Bruce M. Simpson wrote: B> The proposed changes also constitute a hack. B> B> I understand that they are being proposed to address problems we B> currently have in the stack, i.e. that we do not support multipathing, B> though it is more than likely they will be blown away in future when the B> architecture changes (and it has to change). B> B> Approach 1 is largely irrelevant if multiple paths are introduced to the B> network stack; there is then no concept of a conflicting forwarding B> entry, only preference derived from the interface, entry flags, or the B> entry ('route') itself. B> B> Approach 2 has some merit to it, although the forwarding plane should B> not care where the forwarding entry came from unless it needs to (e.g. B> next-hop resolution). B> B> It seems reasonable that the forwarding plane should tag entries as B> being 'CONNECTED' i.e. derived from the address configuration of an B> interface. I believe many implementations out there do this, and B> multi-path does not change this. B> B> We already have the RTF_PROTO1 flag to determine if the forwarding entry B> ('route') came from a routing protocol in userland, so there should be B> no need to change the existing flags. B> B> The RTF_STATIC flag only has special meaning in that it means 'the user B> added this forwarding entry manually via the route(8) command'. We B> should preserve these semantics, though I believe we should start B> implementing forwarding preference in the radix trie. B> B> I think it seems acceptable and reasonable that we use a limited form of B> Approach 2 to clobber 'routes' being aded in the case described in the B> PR, until such time as the network stack is re-engineered to support B> multiple paths and forwarding preference. B> B> I also believe it is useful if we start to use more modern technical B> jargon to discuss 'routes' in the network stack, because we are actually B> discussing the behaviour of entries in a forwarding table. I was afraid that this would raise an argument on multipath routing. Let's temporary do not speak about multipath but just decide what is the correct way to remove conflicting routes when we are assigning an IP prefix to a local interface? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 18:20:54 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5501C16A402; Wed, 14 Mar 2007 18:20:54 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 226E713C468; Wed, 14 Mar 2007 18:20:54 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id AB6C61F8390; Wed, 14 Mar 2007 14:20:53 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Wed, 14 Mar 2007 14:20:53 -0400 X-Sasl-enc: 5B2iKsUaIv3aLjyQa9U07cbHTBDa3KNsy2mWUeRI4AZB 1173896453 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id A834216B5B; Wed, 14 Mar 2007 14:20:52 -0400 (EDT) Message-ID: <45F83D03.9020501@FreeBSD.org> Date: Wed, 14 Mar 2007 18:20:51 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Gleb Smirnoff , "Bruce M. Simpson" , freebsd-net@FreeBSD.org, Vladimir Ivanov , bug-followup@FreeBSD.org References: <20070314115916.GB2713@cell.sick.ru> <45F81C0D.2000608@FreeBSD.org> <20070314161023.GF2713@cell.sick.ru> In-Reply-To: <20070314161023.GF2713@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 18:20:54 -0000 Gleb Smirnoff wrote: > I was afraid that this would raise an argument on multipath routing. Let's > temporary do not speak about multipath but just decide what is the correct > way to remove conflicting routes when we are assigning an IP prefix to a > local interface? > My suggestion is to take the second approach you outlined but modify it slightly. That way, the conflict between the 'connected' FTE introduced by ifconfig'ing the interface and the pre-existing FTE for that network prefix, may be resolved in a manner which doesn't break current consumers of the routing code, and leaves the way open to do multipath later w/o problems. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 20:07:47 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F00416A404; Wed, 14 Mar 2007 20:07:47 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.freebsd.org (Postfix) with ESMTP id 17DAB13C489; Wed, 14 Mar 2007 20:07:47 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from citrin (unknown [81.19.65.167]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id 9CCAF12279E2; Wed, 14 Mar 2007 23:07:45 +0300 (MSK) Date: Wed, 14 Mar 2007 23:06:52 +0300 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.62.14) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <6110191101.20070314230652@citrin.ru> To: "Bruce M. Simpson" In-Reply-To: <45F81C0D.2000608@FreeBSD.org> References: <20070314115916.GB2713@cell.sick.ru> <45F81C0D.2000608@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re[2]: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 20:07:47 -0000 Wednesday, March 14, 2007, 7:00:13 PM, Bruce M. Simpson wrote: BMS> Gleb Smirnoff wrote: >> AFAIK, the problem needs a more generic approach. I see two approaches. >> >> 1) Introduce RTM_CHANGEADD, a command that will forcibly add route, >> deleting all conflicting ones. Use this command in in_addprefix(). >> >> 2) In rt_flags field we still have several extra bits. We can use >> them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX, >> where XXX is a routing protocol. When issuing RTM_ADD a route with >> a preferred source (e.g. CONNECTED vs STATIC) will override the old >> one. >> BMS> I understand that they are being proposed to address problems we BMS> currently have in the stack, i.e. that we do not support multipathing, BMS> though it is more than likely they will be blown away in future when the BMS> architecture changes (and it has to change). IMHO question is not related to multipathing. Kernel routes now don't contain administrative distance and it root of this problem. RTS_CONNECTED, RTS_STATIC is a hack adding some fixed AD values without increasing route size in memory. -- WBR, Anton Yuzhaninov From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 22:42:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B070316A404 for ; Wed, 14 Mar 2007 22:42:28 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.freebsd.org (Postfix) with ESMTP id 87B3C13C4B0 for ; Wed, 14 Mar 2007 22:42:28 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HRcAt-0002k6-Ix for freebsd-net@freebsd.org; Wed, 14 Mar 2007 15:42:27 -0700 Message-ID: <9484186.post@talk.nabble.com> Date: Wed, 14 Mar 2007 15:42:27 -0700 (PDT) From: rms_zaphod To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: tmskeren3@yahoo.com Subject: fbsd amd64 and fast_ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 22:42:28 -0000 OK, I have used these ken mods for my file server/nat/router/firewall servers for years. (kern ops then question) #Mt ****e options IPFIREWALL options IPDIVERT options IPFIREWALL_VERBOSE options IPSTEALTH options FAST_IPSEC #smbfs stuff options NETSMB options NETSMBCRYPTO options LIBMCHAIN options LIBICONV options SMBFS #end smbfs stuff device crypto With 6.2, with latest (3.13.07) cvsup -L 2 -h `(fastest_cvsup -q -c us )` /root/stable-supfile make buildworld etc...I STILL cannot get setkey nor racoon to function. I keep getting a pfkey error, and cannot establish a VPN tunnel. I can if I use: options IPSEC options IPSEC_ESP options IPSEC_DEBUG But giant mutex is enable...etc. However all was good up to 6.1. Is this broken in 6.2?? -- View this message in context: http://www.nabble.com/fbsd-amd64-and-fast_ipsec-tf3405028.html#a9484186 Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 01:15:12 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B182916A402 for ; Thu, 15 Mar 2007 01:15:12 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A231113C468 for ; Thu, 15 Mar 2007 01:15:12 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 829611A3C1A for ; Wed, 14 Mar 2007 18:15:12 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C33625132C; Wed, 14 Mar 2007 21:15:11 -0400 (EDT) Date: Wed, 14 Mar 2007 21:15:11 -0400 From: Kris Kennaway To: net@FreeBSD.org Message-ID: <20070315011511.GA55003@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: Scalability problem from route refcounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 01:15:12 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have recently started looking at database performance over gigabit ethernet, and there seems to be a bottleneck coming from the way route reference counting is implemented. On an 8-core system it looks like we spend a lot of time waiting for the rtentry mutex: max total wait_total count avg wait_avg cnt_hold cnt_lock name [...] 408 950496 1135994 301418 3 3 24876 55936 net/if_ethersubr.c:397 (sleep mutex:bge1) 974 968617 1515169 253772 3 5 14741 60581 dev/bge/if_bge.c:2949 (sleep mutex:bge1) 2415 18255976 1607511 253841 71 6 125174 3131 netinet/tcp_input.c:770 (sleep mutex:inp) 233 1850252 2080506 141817 13 14 0 126897 netinet/tcp_usrreq.c:756 (sleep mutex:inp) 384 6895050 2737492 299002 23 9 92100 73942 dev/bge/if_bge.c:3506 (sleep mutex:bge1) 626 5342286 2760193 301477 17 9 47616 54158 net/route.c:147 (sleep mutex:radix node head) 326 3562050 3381510 301477 11 11 133968 110104 net/route.c:197 (sleep mutex:rtentry) 146 947173 5173813 301477 3 17 44578 120961 net/route.c:1290 (sleep mutex:rtentry) 146 953718 5501119 301476 3 18 63285 121819 netinet/ip_output.c:610 (sleep mutex:rtentry) 50 4530645 7885304 1423098 3 5 642391 788230 kern/subr_turnstile.c:489 (spin mutex:turnstile chain) i.e. during a 30 second sample we spend a total of >14 seconds (on all cpus) waiting to acquire the rtentry mutex. This appears to be because (among other things), we increment and then decrement the route refcount for each packet we send, each of which requires acquiring the rtentry mutex for that route before adjusting the refcount. So multiplexing traffic for lots of connections over a single route is being partly rate-limited by those mutex operations. This is not the end of the story though, the bge driver is a serious bottleneck on its own (e.g. I nulled out the route locking since it is not relevant in my environment, at least for the purposes of this test, and that exposed bge as the next problem -- but other drivers may not be so bad). Kris --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF+J4fWry0BWjoQKURAnPuAJ97CLDA/ZlMYKyHUcMGVZWy+4zT4gCghEVM h1SsQilD6TKOAv5A6FUTPSU= =dzfz -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 01:45:21 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6506816A402 for ; Thu, 15 Mar 2007 01:45:21 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.freebsd.org (Postfix) with ESMTP id 270E313C45B for ; Thu, 15 Mar 2007 01:45:21 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so395816wxc for ; Wed, 14 Mar 2007 18:45:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pmCzNguzMqsNToDI10USYgJC2MKIJ0Lhcupv2Lsfhk1pIqA9fvVghdOack7GvqJPrbR0H2mnquaz5Wzb6/g3Um2A9TT4goYUV1bG12eeP819AgaJ93suLq9v3paN7C9WpF5SI9A/srrbROWX0sdr8JKuD0LsaXBG9jOjR2tC7Gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PnGtX7GuTXv7CY6MpqzQ8kL/DrOKYtUzIV4vsX06kQ0XkY3StG9x3fzE8ydpuWpkI0dIW9YltFbI8E9YfsU0GhAyshuUl55eBjvLXwrr4sb7UCF1CD7jKrE3FM3jUmGPoWKNLRiABzOvj5g54Sjj0adfUtepyCNIjSiBs2P45As= Received: by 10.90.118.12 with SMTP id q12mr26771agc.1173923120915; Wed, 14 Mar 2007 18:45:20 -0700 (PDT) Received: by 10.90.25.1 with HTTP; Wed, 14 Mar 2007 18:45:20 -0700 (PDT) Message-ID: Date: Wed, 14 Mar 2007 18:45:20 -0700 From: "Kip Macy" To: "Kris Kennaway" , net@freebsd.org In-Reply-To: <20070315011511.GA55003@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070315011511.GA55003@xor.obsecurity.org> Cc: Subject: Re: Scalability problem from route refcounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 01:45:21 -0000 Apologies in advance if you have already answered this question elsewhere - can you point me to a HOWTO for replicating the test in my local environment? -Kip On 3/14/07, Kris Kennaway wrote: > I have recently started looking at database performance over gigabit > ethernet, and there seems to be a bottleneck coming from the way route > reference counting is implemented. On an 8-core system it looks like > we spend a lot of time waiting for the rtentry mutex: > > max total wait_total count avg wait_avg cnt_hold > cnt_lock name > [...] > 408 950496 1135994 301418 3 3 24876 > 55936 net/if_ethersubr.c:397 (sleep mutex:bge1) > 974 968617 1515169 253772 3 5 14741 > 60581 dev/bge/if_bge.c:2949 (sleep mutex:bge1) > 2415 18255976 1607511 253841 71 6 125174 > 3131 netinet/tcp_input.c:770 (sleep mutex:inp) > 233 1850252 2080506 141817 13 14 0 > 126897 netinet/tcp_usrreq.c:756 (sleep mutex:inp) > 384 6895050 2737492 299002 23 9 92100 > 73942 dev/bge/if_bge.c:3506 (sleep mutex:bge1) > 626 5342286 2760193 301477 17 9 47616 > 54158 net/route.c:147 (sleep mutex:radix node head) > 326 3562050 3381510 301477 11 11 133968 > 110104 net/route.c:197 (sleep mutex:rtentry) > 146 947173 5173813 301477 3 17 44578 > 120961 net/route.c:1290 (sleep mutex:rtentry) > 146 953718 5501119 301476 3 18 63285 > 121819 netinet/ip_output.c:610 (sleep mutex:rtentry) > 50 4530645 7885304 1423098 3 5 642391 > 788230 kern/subr_turnstile.c:489 (spin mutex:turnstile chain) > > i.e. during a 30 second sample we spend a total of >14 seconds (on all > cpus) waiting to acquire the rtentry mutex. > > This appears to be because (among other things), we increment and then > decrement the route refcount for each packet we send, each of which > requires acquiring the rtentry mutex for that route before adjusting > the refcount. So multiplexing traffic for lots of connections over a > single route is being partly rate-limited by those mutex operations. > > This is not the end of the story though, the bge driver is a serious > bottleneck on its own (e.g. I nulled out the route locking since it is > not relevant in my environment, at least for the purposes of this > test, and that exposed bge as the next problem -- but other drivers > may not be so bad). > > Kris > > From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 02:13:51 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4992516A404 for ; Thu, 15 Mar 2007 02:13:51 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6CF13C44C for ; Thu, 15 Mar 2007 02:13:51 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 1BBFD1A3C1A; Wed, 14 Mar 2007 19:13:51 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 60757517C9; Wed, 14 Mar 2007 22:13:50 -0400 (EDT) Date: Wed, 14 Mar 2007 22:13:50 -0400 From: Kris Kennaway To: Kip Macy Message-ID: <20070315021349.GA55921@xor.obsecurity.org> References: <20070315011511.GA55003@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: net@freebsd.org, Kris Kennaway Subject: Re: Scalability problem from route refcounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 02:13:51 -0000 On Wed, Mar 14, 2007 at 06:45:20PM -0700, Kip Macy wrote: > Apologies in advance if you have already answered this question > elsewhere - can you point me to a HOWTO for replicating the test in my > local environment? Well it's not completely spelled out...but most of the steps are documented in http://people.freebsd.org/~kris/scaling/mysql.html and references therein. You'll probably want to use my kris-contention p4 branch to avoid the scaling bottlenecks we have identified and solved so far. Kris From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 08:15:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F93B16A404 for ; Thu, 15 Mar 2007 08:15:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4182213C45D for ; Thu, 15 Mar 2007 08:15:11 +0000 (UTC) (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 5212A1FFE9A; Thu, 15 Mar 2007 09:15:09 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 4CA841FFEA0; Thu, 15 Mar 2007 09:15:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 51646444885; Thu, 15 Mar 2007 08:14:59 +0000 (UTC) Date: Thu, 15 Mar 2007 08:14:59 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: rms_zaphod In-Reply-To: <9484186.post@talk.nabble.com> Message-ID: <20070315081034.H62476@maildrop.int.zabbadoz.net> References: <9484186.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-net@freebsd.org Subject: Re: fbsd amd64 and fast_ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 08:15:11 -0000 On Wed, 14 Mar 2007, rms_zaphod wrote: Hi , > OK, I have used these ken mods for my file server/nat/router/firewall servers > for years. (kern ops then question) > > options FAST_IPSEC > device crypto > > With 6.2, with latest (3.13.07) cvsup -L 2 -h `(fastest_cvsup -q -c us )` > /root/stable-supfile > > make buildworld etc...I STILL cannot get setkey nor racoon to function. I > keep getting a pfkey error, and cannot establish a VPN tunnel. I can if I > use: can you be more specific about which "racoon"? Which "setkey" and what errors when doing what? I'll be happy to fix more amd64/(fast)ipsec bugs but I need details so I can try to reproduce them. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 11:14:04 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE05816A400; Thu, 15 Mar 2007 11:14:04 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 0529E13C43E; Thu, 15 Mar 2007 11:14:03 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2FBE1Ps030670; Thu, 15 Mar 2007 14:14:01 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2FBE11w030669; Thu, 15 Mar 2007 14:14:01 +0300 (MSK) (envelope-from yar) Date: Thu, 15 Mar 2007 14:14:00 +0300 From: Yar Tikhiy To: "Bruce M. Simpson" Message-ID: <20070315111400.GC28354@comp.chem.msu.su> Mail-Followup-To: Yar Tikhiy , "Bruce M. Simpson" , freebsd-arch@FreeBSD.org References: <20070314102023.GB1766@comp.chem.msu.su> <45F7EF84.5070700@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45F7EF84.5070700@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Generic ioctl and ether_ioctl don't agree X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 11:14:04 -0000 On Wed, Mar 14, 2007 at 12:50:12PM +0000, Bruce M. Simpson wrote: > Yar Tikhiy wrote: > >Hi folks, > > > >Quite a while ago I noticed that our ioctl handlers get the ioctl > >command via u_long, but ether_ioctl()'s command argument is int. > >This disarray dates back to 1998, when ioctl functions started to > >take u_long as the command, but ether_ioctl() was never fixed. > >Fortunately, our ioctl command coding still fits in 32 bits, or > >else we would've got problems on 64-bit arch'es already. I'd like > >to fix this long-standing bug some day after RELENG_7 is branched. > >Of course, this will break ABI to network modules on all 64-bit > >arch'es. BTW, the same applies to other L2 layers, such as firewire, > >which seems to have been cloned from if_ethersubr.c. > > > This is one of those annoying things which breaks compatibility with > external modules. > > I'm not sure about this, though. I was getting sign extension warnings > on amd64 last week when I was testing the IGMPv3 aware mtest(8). Perhaps > if we're fixing these ABIs, we should commit to an explicit C99 type > with known bit width, i.e. uint32_t. > > I would be much happier if we began using C99 types in the code. This is a point to discuss in -arch as it's closely related to the generic ioctl interface. Let's move this thread to -arch. It's been a vague issue to me whether to use a fixed-width type or a basic type in particular kernel code. Of course, it's better to use a fixed-width type when it comes to network packets or hardware registers. OTOH, errno is int. But not all cases are that simple. Do we have a guideline for that? -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 11:15:14 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0862B16A405; Thu, 15 Mar 2007 11:15:14 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id DFD0413C46C; Thu, 15 Mar 2007 11:15:12 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2FBF40P030690; Thu, 15 Mar 2007 14:15:04 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2FBF4da030689; Thu, 15 Mar 2007 14:15:04 +0300 (MSK) (envelope-from yar) Date: Thu, 15 Mar 2007 14:15:03 +0300 From: Yar Tikhiy To: Brooks Davis Message-ID: <20070315111503.GD28354@comp.chem.msu.su> References: <20070314102023.GB1766@comp.chem.msu.su> <20070314150138.GC56444@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070314150138.GC56444@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: Generic ioctl and ether_ioctl don't agree X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 11:15:14 -0000 On Wed, Mar 14, 2007 at 10:01:38AM -0500, Brooks Davis wrote: > On Wed, Mar 14, 2007 at 01:20:23PM +0300, Yar Tikhiy wrote: > > Hi folks, > > > > Quite a while ago I noticed that our ioctl handlers get the ioctl > > command via u_long, but ether_ioctl()'s command argument is int. > > This disarray dates back to 1998, when ioctl functions started to > > take u_long as the command, but ether_ioctl() was never fixed. > > Fortunately, our ioctl command coding still fits in 32 bits, or > > else we would've got problems on 64-bit arch'es already. I'd like > > to fix this long-standing bug some day after RELENG_7 is branched. > > Of course, this will break ABI to network modules on all 64-bit > > arch'es. BTW, the same applies to other L2 layers, such as firewire, > > which seems to have been cloned from if_ethersubr.c. > > > > Any objections or comments? Thanks! > > Why wait? We're allowed to break module ABIs in current at any time and > there's no chance modules built on RELENG_6 will work on RELENG_7 > trees anyway. Perhaps I was over-conservative. :-) -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 16:23:20 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F2B316A401 for ; Thu, 15 Mar 2007 16:23:20 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id EA11B13C46E for ; Thu, 15 Mar 2007 16:23:19 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 60039 invoked from network); 15 Mar 2007 15:53:26 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Mar 2007 15:53:26 -0000 Message-ID: <45F972F4.8070106@freebsd.org> Date: Thu, 15 Mar 2007 17:23:16 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kris Kennaway References: <20070315011511.GA55003@xor.obsecurity.org> In-Reply-To: <20070315011511.GA55003@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qingli@freebsd.org, net@FreeBSD.org Subject: Re: Scalability problem from route refcounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 16:23:20 -0000 Kris Kennaway wrote: > I have recently started looking at database performance over gigabit > ethernet, and there seems to be a bottleneck coming from the way route > reference counting is implemented. On an 8-core system it looks like > we spend a lot of time waiting for the rtentry mutex: > > max total wait_total count avg wait_avg cnt_hold cnt_lock name > [...] > 408 950496 1135994 301418 3 3 24876 55936 net/if_ethersubr.c:397 (sleep mutex:bge1) > 974 968617 1515169 253772 3 5 14741 60581 dev/bge/if_bge.c:2949 (sleep mutex:bge1) > 2415 18255976 1607511 253841 71 6 125174 3131 netinet/tcp_input.c:770 (sleep mutex:inp) > 233 1850252 2080506 141817 13 14 0 126897 netinet/tcp_usrreq.c:756 (sleep mutex:inp) > 384 6895050 2737492 299002 23 9 92100 73942 dev/bge/if_bge.c:3506 (sleep mutex:bge1) > 626 5342286 2760193 301477 17 9 47616 54158 net/route.c:147 (sleep mutex:radix node head) > 326 3562050 3381510 301477 11 11 133968 110104 net/route.c:197 (sleep mutex:rtentry) > 146 947173 5173813 301477 3 17 44578 120961 net/route.c:1290 (sleep mutex:rtentry) > 146 953718 5501119 301476 3 18 63285 121819 netinet/ip_output.c:610 (sleep mutex:rtentry) > 50 4530645 7885304 1423098 3 5 642391 788230 kern/subr_turnstile.c:489 (spin mutex:turnstile chain) > > i.e. during a 30 second sample we spend a total of >14 seconds (on all > cpus) waiting to acquire the rtentry mutex. > > This appears to be because (among other things), we increment and then > decrement the route refcount for each packet we send, each of which > requires acquiring the rtentry mutex for that route before adjusting > the refcount. So multiplexing traffic for lots of connections over a > single route is being partly rate-limited by those mutex operations. The rtentry locking actually isn't that much of a problem in itself and rtalloc1() in net/route.c only gets the blame because this function aquires the lock for the routing table entry and returns a locked entry. It is the job of the callers to unlock it as soon as possible again. Here arpresolve() in netinet/if_ether.c is the offending function keeping the lock over an extended period causing the contention and long wait times. ARP is a horrible mess and I don't have a quick fix for this. There is some work in progress for quite some time to replace the current ARP code with something more adequate. That's not finished yet though. > This is not the end of the story though, the bge driver is a serious > bottleneck on its own (e.g. I nulled out the route locking since it is > not relevant in my environment, at least for the purposes of this > test, and that exposed bge as the next problem -- but other drivers > may not be so bad). -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 16:30:58 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FA2E16A402 for ; Thu, 15 Mar 2007 16:30:58 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B2A5A13C480 for ; Thu, 15 Mar 2007 16:30:57 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 60110 invoked from network); 15 Mar 2007 16:01:04 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Mar 2007 16:01:04 -0000 Message-ID: <45F974BE.5050404@freebsd.org> Date: Thu, 15 Mar 2007 17:30:54 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Gleb Smirnoff , "Bruce M. Simpson" , freebsd-net@FreeBSD.org, Vladimir Ivanov , bug-followup@FreeBSD.org References: <20070314115916.GB2713@cell.sick.ru> <45F81C0D.2000608@FreeBSD.org> <20070314161023.GF2713@cell.sick.ru> In-Reply-To: <20070314161023.GF2713@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 16:30:58 -0000 Gleb Smirnoff wrote: > > I was afraid that this would raise an argument on multipath routing. Let's > temporary do not speak about multipath but just decide what is the correct > way to remove conflicting routes when we are assigning an IP prefix to a > local interface? IMO when configuring a interface with an IP address and network it should kick out previous host and/or network routes matching it. Unless those are from locally configured interfaces, then it should reject the new attempt. The current behavior is a big problem when running routing daemons like OpenBGPD or OpenOSPFD. If you add a second router to a subnet and that router receives that subnet already via the routing protocol you can't configure the interface. For the routing daemon a RTM_CHANGE in the replacement case is fine. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 16:59:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 338E416A401 for ; Thu, 15 Mar 2007 16:59:42 +0000 (UTC) (envelope-from pusateri@bangj.com) Received: from jj.bangj.com (jj.bangj.com [24.106.203.82]) by mx1.freebsd.org (Postfix) with ESMTP id 0B38013C45B for ; Thu, 15 Mar 2007 16:59:41 +0000 (UTC) (envelope-from pusateri@bangj.com) Received: from jj.bangj.com (localhost.bangj.com [127.0.0.1]) by jj.bangj.com (Postfix) with ESMTP id 38462B8CA; Thu, 15 Mar 2007 12:37:37 -0400 (EDT) To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <68988.1173976657.1@jj.bangj.com> Date: Thu, 15 Mar 2007 12:37:37 -0400 From: Tom Pusateri Message-Id: <20070315163737.38462B8CA@jj.bangj.com> Cc: Tom Pusateri Subject: IPv6 bridge0 link-local address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 16:59:42 -0000 I've configured a bridge0 interface that bridges fxp0 and em0. I have a global IPv6 address configured on it and IPv6 works fine. # ifconfig bridge0 bridge0: flags=8043 mtu 1500 inet x.x.x.82 netmask 0xfffffff0 broadcast x.x.x.95 inet6 2001:4877:1777:1001::1 prefixlen 64 ether ac:de:48:49:71:91 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: fxp0 flags=3 member: em0 flags=3 I'm trying to run route6d and it aborts because there is no link local address on the bridge0 interface. I can't even tell route6d to ignore the interface because it won't get past initialization. Is anyone routing route6d over a bridge0 interface and if so, did you add a link local address manually (can you even do that) or some other trick? # route6d -d newif fxp0 found address fe80:1::202:a5ff:fe87:4012/64 index: 1, mtu: 1500, metric: 0 join fxp0 ff02::9 newif em0 found address fe80:2::20e:cff:fe9f:f40a/64 index: 2, mtu: 1500, metric: 0 join em0 ff02::9 newif fxp1 found address fe80:3::2d0:b7ff:fe3c:9dae/64 index: 3, mtu: 1500, metric: 0 join fxp1 ff02::9 found address 2001:4877:1713:1002::1/64 newif fxp2 found address fe80:4::2d0:b7ff:fe3f:42c0/64 index: 4, mtu: 1500, metric: 0 join fxp2 ff02::9 found address 2001:4877:1713:1003::1/64 newif lo0 found address ::1/128 found address fe80:6::1/64 index: 6, mtu: 1500, metric: 0 newif bridge0 found address 2001:4877:1713:1001::1/64 newif gif0 found address fe80:8::202:a5ff:fe87:4012/64 -- :: index: 8, mtu: 1280, metric: 0 join gif0 ff02::9 found address 2001:4877:1700:29::2/128 -- :: newif tun0 found address fe80:9::202:a5ff:fe87:4012/64 -- :: index: 9, mtu: 1500, metric: 0 join tun0 ff02::9 newif gif1 found address 2001:4877:1713:1011::1/64 -- :: found address fe80:b::202:a5ff:fe87:4012/64 -- :: index: 11, mtu: 1280, metric: 0 join gif1 ff02::9 No ifindex found at bridge0 (no link-local address?) Thanks, Tom From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 17:01:36 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2014F16A401 for ; Thu, 15 Mar 2007 17:01:36 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id 8600B13C468 for ; Thu, 15 Mar 2007 17:01:35 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu ([151.77.253.161]) (authenticated bits=128) by parrot.aev.net (8.14.0/8.13.8) with ESMTP id l2FH8LSD065121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Mar 2007 18:08:27 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.0/8.13.8) with ESMTP id l2FH1NLW064837 for ; Thu, 15 Mar 2007 18:01:23 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <45F97BE2.4010605@netfence.it> Date: Thu, 15 Mar 2007 18:01:22 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 212.31.247.179 Subject: CARP Question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 17:01:36 -0000 Hello. I've got two servers configured as follows: a) /etc/rc.conf: ifconfig_xl0="inet 192.168.0.2 netmask 255.255.255.0" ifconfig_fxp0="inet 192.168.101.4 netmask 255.255.255.0" cloned_interfaces="carp0 carp1 carp2 carp3" ifconfig_carp0="vhid 1 advskew 100 pass xxxx 192.168.101.10" ifconfig_carp1="vhid 2 pass yyyy 192.168.101.10" ifconfig_carp2="vhid 3 advskew 100 pass zzzz 192.168.0.4" ifconfig_carp3="vhid 4 pass wwww 192.168.0.4" /etc/sysctl.conf: net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 b) /etc/rc.conf: ifconfig_fxp0="inet 192.168.101.1 netmask 255.255.255.0" ifconfig_fxp1="inet 192.168.0.3 netmask 255.255.255.0" cloned_interfaces="carp0 carp1 carp2 carp3" ifconfig_carp0="vhid 1 pass xxxx 192.168.101.10" ifconfig_carp1="vhid 2 advskew 100 pass yyyy 192.168.101.10" ifconfig_carp2="vhid 3 pass zzzz 192.168.0.4" ifconfig_carp3="vhid 4 advskew 100 pass wwww 192.168.0.4" /etc/sysctl.conf: net.inet.carp.arpbalance=1 net.inet.carp.preempt=1 With this I would expect that, being both servers online, they should have two MASTER and two BACKUP carp interfaces each. Instead, one has all MASTERs and the other all BACKUPs. a) ifconfig carp0: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xffffff00 carp: BACKUP vhid 1 advbase 1 advskew 100 carp1: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xffffff00 carp: BACKUP vhid 2 advbase 1 advskew 0 carp2: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xffffff00 carp: BACKUP vhid 3 advbase 1 advskew 100 carp3: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xffffff00 carp: BACKUP vhid 4 advbase 1 advskew 0 b) ifconfig carp0: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xffffff00 carp: MASTER vhid 1 advbase 1 advskew 0 carp1: flags=49 mtu 1500 inet 192.168.101.10 netmask 0xffffff00 carp: MASTER vhid 2 advbase 1 advskew 100 carp2: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xffffff00 carp: MASTER vhid 3 advbase 1 advskew 0 carp3: flags=49 mtu 1500 inet 192.168.0.4 netmask 0xffffff00 carp: MASTER vhid 4 advbase 1 advskew 100 Why? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 18:37:13 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 516FD16A403 for ; Thu, 15 Mar 2007 18:37:13 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id 0304E13C458 for ; Thu, 15 Mar 2007 18:37:12 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so269778ana for ; Thu, 15 Mar 2007 11:37:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B40zBwUuer13yejksEoZFWNajm97TsrUOT58RCpKgEp76I3IPn1nAQNA9tMZzN//FH3k9gE6aXh2CCGEha3viiPdaH9tVbjI1FdkWdFpyNSLpk+EYEwECt/PruvThjBO5RRUuTPlQO5qzpr5Vg7wd8qc8dmD8myG2AurQMD/JH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i8hCDf9xETnJgtJq3zBCpB8Ri6aQ7C8yWldd0Z3SSx0ziavw47QqvoUPzAEEEo2GM7bFlIpdvCF9M/P1XxWI23segDjSjtsucXtOQ9E4RYCq5KSPdx8SvhzK0UEHpMbusflKKZZa5KyyKN671riRGulyiC4tPVX6u3FAJ/F6QEk= Received: by 10.100.107.2 with SMTP id f2mr725974anc.1173982257836; Thu, 15 Mar 2007 11:10:57 -0700 (PDT) Received: by 10.100.11.20 with HTTP; Thu, 15 Mar 2007 11:10:57 -0700 (PDT) Message-ID: Date: Thu, 15 Mar 2007 21:10:57 +0300 From: pluknet To: "Tom Pusateri" In-Reply-To: <20070315163737.38462B8CA@jj.bangj.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070315163737.38462B8CA@jj.bangj.com> Cc: freebsd-net@freebsd.org Subject: Re: IPv6 bridge0 link-local address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 18:37:13 -0000 On 15/03/07, Tom Pusateri wrote: > I've configured a bridge0 interface that bridges fxp0 and em0. > I have a global IPv6 address configured on it and IPv6 works fine. > > # ifconfig bridge0 > bridge0: flags=8043 mtu 1500 > inet x.x.x.82 netmask 0xfffffff0 broadcast x.x.x.95 > inet6 2001:4877:1777:1001::1 prefixlen 64 > ether ac:de:48:49:71:91 > priority 32768 hellotime 2 fwddelay 15 maxage 20 > member: fxp0 flags=3 > member: em0 flags=3 [snip] I don't know precisely what's about if_bridge. According to the rfc2373 (App.A) it should be similar to: fe80::aede:48ff:fe49:7191%bridge0 Hmm.. but if you try the `ifconfig bridge0 inet6 eui64` command, you''ll see: ifconfig: could not determine link local address wbr, pluknet. From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 18:45:35 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC67616A402 for ; Thu, 15 Mar 2007 18:45:35 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 3C05713C45A for ; Thu, 15 Mar 2007 18:45:35 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 744701B10F08 for ; Thu, 15 Mar 2007 19:45:34 +0100 (CET) Received: from [192.168.3.125] (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 6F8551B10F05 for ; Thu, 15 Mar 2007 19:45:34 +0100 (CET) Message-ID: <45F9944D.6070707@sun-fish.com> Date: Thu, 15 Mar 2007 20:45:33 +0200 From: Stefan Lambrev User-Agent: Thunderbird 1.5.0.10 (X11/20070307) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <45F97BE2.4010605@netfence.it> In-Reply-To: <45F97BE2.4010605@netfence.it> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Subject: Re: CARP Question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 18:45:35 -0000 Hi, Andrea Venturoli wrote: > Hello. > > I've got two servers configured as follows: > > a) > /etc/rc.conf: > ifconfig_xl0="inet 192.168.0.2 netmask 255.255.255.0" > ifconfig_fxp0="inet 192.168.101.4 netmask 255.255.255.0" > cloned_interfaces="carp0 carp1 carp2 carp3" > ifconfig_carp0="vhid 1 advskew 100 pass xxxx 192.168.101.10" > ifconfig_carp1="vhid 2 pass yyyy 192.168.101.10" > ifconfig_carp2="vhid 3 advskew 100 pass zzzz 192.168.0.4" > ifconfig_carp3="vhid 4 pass wwww 192.168.0.4" > > /etc/sysctl.conf: > net.inet.carp.arpbalance=1 > net.inet.carp.preempt=1 > > > > b) > /etc/rc.conf: > ifconfig_fxp0="inet 192.168.101.1 netmask 255.255.255.0" > ifconfig_fxp1="inet 192.168.0.3 netmask 255.255.255.0" > cloned_interfaces="carp0 carp1 carp2 carp3" > ifconfig_carp0="vhid 1 pass xxxx 192.168.101.10" > ifconfig_carp1="vhid 2 advskew 100 pass yyyy 192.168.101.10" > ifconfig_carp2="vhid 3 pass zzzz 192.168.0.4" > ifconfig_carp3="vhid 4 advskew 100 pass wwww 192.168.0.4" > > /etc/sysctl.conf: > net.inet.carp.arpbalance=1 > net.inet.carp.preempt=1 > > > > With this I would expect that, being both servers online, they should > have two MASTER and two BACKUP carp interfaces each. > Instead, one has all MASTERs and the other all BACKUPs. > > a) ifconfig > carp0: flags=49 mtu 1500 > inet 192.168.101.10 netmask 0xffffff00 > carp: BACKUP vhid 1 advbase 1 advskew 100 > carp1: flags=49 mtu 1500 > inet 192.168.101.10 netmask 0xffffff00 > carp: BACKUP vhid 2 advbase 1 advskew 0 > carp2: flags=49 mtu 1500 > inet 192.168.0.4 netmask 0xffffff00 > carp: BACKUP vhid 3 advbase 1 advskew 100 > carp3: flags=49 mtu 1500 > inet 192.168.0.4 netmask 0xffffff00 > carp: BACKUP vhid 4 advbase 1 advskew 0 > > b) ifconfig > carp0: flags=49 mtu 1500 > inet 192.168.101.10 netmask 0xffffff00 > carp: MASTER vhid 1 advbase 1 advskew 0 > carp1: flags=49 mtu 1500 > inet 192.168.101.10 netmask 0xffffff00 > carp: MASTER vhid 2 advbase 1 advskew 100 > carp2: flags=49 mtu 1500 > inet 192.168.0.4 netmask 0xffffff00 > carp: MASTER vhid 3 advbase 1 advskew 0 > carp3: flags=49 mtu 1500 > inet 192.168.0.4 netmask 0xffffff00 > carp: MASTER vhid 4 advbase 1 advskew 100 > > > Why? > man carp: net.inet.carp.preempt Allow virtual hosts to preempt each other. It is also used to failover carp interfaces as a group. When the option is enabled and one of the carp enabled physical interfaces goes down, advskew is changed to 240 on all carp inter- faces. See also the first example. Disabled by default. > > bye & Thanks > av. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 20:07:35 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B81116A522 for ; Thu, 15 Mar 2007 20:07:35 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id 282CB13C4B0 for ; Thu, 15 Mar 2007 20:07:34 +0000 (UTC) (envelope-from ml.diespammer@netfence.it) Received: from soth.ventu ([151.77.253.161]) (authenticated bits=128) by parrot.aev.net (8.14.0/8.13.8) with ESMTP id l2FKEL6F088664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Mar 2007 21:14:27 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Received: from [10.1.2.18] (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.0/8.13.8) with ESMTP id l2FK7LkA066558; Thu, 15 Mar 2007 21:07:21 +0100 (CET) (envelope-from ml.diespammer@netfence.it) Message-ID: <45F9A777.9090905@netfence.it> Date: Thu, 15 Mar 2007 21:07:19 +0100 From: Andrea Venturoli User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Stefan Lambrev References: <45F97BE2.4010605@netfence.it> <45F9944D.6070707@sun-fish.com> In-Reply-To: <45F9944D.6070707@sun-fish.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.61 on 212.31.247.179 Cc: freebsd-net@freebsd.org Subject: Re: CARP Question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 20:07:35 -0000 Stefan Lambrev wrote: > man carp: > > net.inet.carp.preempt Allow virtual hosts to preempt each other. It > is also used to failover carp interfaces as a > group. When the option is enabled and one of > the carp enabled physical interfaces goes > down, > advskew is changed to 240 on all carp inter- > faces. See also the first example. Disabled > by default. Yes, I had read that. Since this two boxes are, amidst other things, acting as routers, I do want the interface pair to go into master state all at once. However I had understood that, once the other box comes up again, the two interfaces which had switched should go back to backup state and be masters on the alive-again host. In other words, after one server solved its troubles, I should have the initial status again. How can I accomplish this? BTW, I used to have this working on 4.x using the now discontinued freevrrpd port. I can't believe this is not possible anymore now. bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 00:32:37 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62DBF16A416 for ; Fri, 16 Mar 2007 00:32:37 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC7B13C459 for ; Fri, 16 Mar 2007 00:32:37 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HS0N1-0001Yi-Jt for freebsd-net@freebsd.org; Thu, 15 Mar 2007 17:32:35 -0700 Message-ID: <9506441.post@talk.nabble.com> Date: Thu, 15 Mar 2007 17:32:35 -0700 (PDT) From: rms_zaphod To: freebsd-net@freebsd.org In-Reply-To: <20070315081034.H62476@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: tmskeren3@yahoo.com References: <9484186.post@talk.nabble.com> <20070315081034.H62476@maildrop.int.zabbadoz.net> Subject: Re: [PATCH] fbsd amd64 and fast_ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 00:32:37 -0000 Bjoern A. Zeeb wrote: > > On Wed, 14 Mar 2007, rms_zaphod wrote: > > Hi , > >> OK, I have used these ken mods for my file server/nat/router/firewall >> servers >> for years. (kern ops then question) >> >> options FAST_IPSEC >> device crypto >> >> With 6.2, with latest (3.13.07) cvsup -L 2 -h `(fastest_cvsup -q -c us )` >> /root/stable-supfile >> >> make buildworld etc...I STILL cannot get setkey nor racoon to function. I >> keep getting a pfkey error, and cannot establish a VPN tunnel. I can if I >> use: > > can you be more specific about which "racoon"? > Which "setkey" and what errors when doing what? > > I'll be happy to fix more amd64/(fast)ipsec bugs but I need details so > I can try to reproduce them. > > -- > Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT > > OK...I only have a few things...this is what I get as a response: > > testor# setkey -D > pfkey_open: Protocol not supported > testor# racoon > racoon: something error happened while pfkey initializing. > testor# > > That's all I can say. Today, I did do a full cvsup and world build on > 5.4, and I recieved the same error message. Perhaps an update in cv's is > the problem??? > > I'm using racoon from /usr/ports/security/ipsec-tools ---current ports > tree. > > I will do a build using 6.2 without a world rebuild and see what happens. > _______________________________________________ > 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" > > -- View this message in context: http://www.nabble.com/fbsd-amd64-and-fast_ipsec-tf3405028.html#a9506441 Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 09:45:29 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B04D16A403; Fri, 16 Mar 2007 09:45:29 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from pinky.frank-behrens.de (pinky.frank-behrens.de [82.139.199.24]) by mx1.freebsd.org (Postfix) with ESMTP id CAC7B13C46C; Fri, 16 Mar 2007 09:45:28 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from [192.168.20.32] (sun.behrens [192.168.20.32]) by pinky.frank-behrens.de (8.13.8/8.13.8) with ESMTP id l2G9jOYY048747; Fri, 16 Mar 2007 10:45:27 +0100 (CET) (envelope-from frank@pinky.sax.de) Message-Id: <200703160945.l2G9jOYY048747@pinky.frank-behrens.de> From: "Frank Behrens" To: "Bruce M. Simpson" Date: Fri, 16 Mar 2007 10:45:35 +0100 MIME-Version: 1.0 Priority: normal In-reply-to: <45F7F405.4040607@FreeBSD.org> References: <200703141213.l2ECDntN087975@pinky.frank-behrens.de> X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: freebsd-net@FreeBSD.org Subject: Re: tap(4) should go UP if opened X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 09:45:29 -0000 Bruce M. Simpson wrote on 14 Mar 2007 13:09: > Please try the attached patch, which puts this behaviour under a sysctl. It works well as expected. Many thanks! I created a PR http://www.freebsd.org/cgi/query-pr.cgi?pr=110383 with the hope the patch will be commited. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 10:01:03 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5268916A405 for ; Fri, 16 Mar 2007 10:01:03 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0C113C4B0 for ; Fri, 16 Mar 2007 10:01:03 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id C18271B10F0E for ; Fri, 16 Mar 2007 11:01:01 +0100 (CET) Received: from [192.168.3.125] (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 863DA1B10EB5 for ; Fri, 16 Mar 2007 11:01:01 +0100 (CET) Message-ID: <45FA6ADD.1090608@sun-fish.com> Date: Fri, 16 Mar 2007 12:01:01 +0200 From: Stefan Lambrev User-Agent: Thunderbird 1.5.0.10 (X11/20070307) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: Subject: if_bridge & pf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 10:01:03 -0000 Hello, I have 2 firewalls, and every of them have 2 bridged interfaces + STP , running FreeBSD 6.1-STABLE Unfortunately one of them is totally dead (hw problems) and I have to make new one, but I plan to use FreeBSD-6.2-STABLE. My question is are there any know compatibility issues between 6.1 and 6.2? I know that a lot of changes are committed to if_bridge and pf/pfsync, that's why I'm little unsure :) Sorry if this is not the proper mail list. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 11:55:59 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42C1016A552 for ; Fri, 16 Mar 2007 11:55:59 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.freebsd.org (Postfix) with ESMTP id F0AE813C448 for ; Fri, 16 Mar 2007 11:55:58 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from citrin (unknown [81.19.65.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id 0B3D512279E2; Fri, 16 Mar 2007 14:55:58 +0300 (MSK) Date: Fri, 16 Mar 2007 14:55:03 +0300 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.62.14) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <446293168.20070316145503@citrin.ru> To: Andre Oppermann In-Reply-To: <45F974BE.5050404@freebsd.org> References: <20070314115916.GB2713@cell.sick.ru> <45F81C0D.2000608@FreeBSD.org> <20070314161023.GF2713@cell.sick.ru> <45F974BE.5050404@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re[2]: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 11:55:59 -0000 Thursday, March 15, 2007, 7:30:54 PM, Andre Oppermann wrote: AO> IMO when configuring a interface with an IP address and network it should AO> kick out previous host and/or network routes matching it. Unless those AO> are from locally configured interfaces, then it should reject the new AO> attempt. New route should replace existing one only if it have administrative distance (in cisco terms) smaller than AD for existing route. Preference of network from locally configured interface is only particular case of this general principle. -- WBR, Anton Yuzhaninov From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 12:38:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E17716A402 for ; Fri, 16 Mar 2007 12:38:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5B013C459 for ; Fri, 16 Mar 2007 12:38:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.185.206] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1HSBhN0Rs3-0000mg; Fri, 16 Mar 2007 13:38:21 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Fri, 16 Mar 2007 13:38:12 +0100 User-Agent: KMail/1.9.5 References: <45FA6ADD.1090608@sun-fish.com> In-Reply-To: <45FA6ADD.1090608@sun-fish.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1346434.ELUrUNuatm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703161338.19240.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18CWj0DTXSXamwwyfCid6oGzzqygZ4hBYnr8g7 d3Hp7AwQar7d7iZmzS0mDpGuAR57KRo3AyGGwaKYFYiY+Eq8n8 XVOYxJeWWlEYhaySbwqCQ== Cc: Stefan Lambrev Subject: Re: if_bridge & pf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 12:38:28 -0000 --nextPart1346434.ELUrUNuatm Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 March 2007 11:01, Stefan Lambrev wrote: > I have 2 firewalls, and every of them have 2 bridged interfaces + STP , > running FreeBSD 6.1-STABLE > Unfortunately one of them is totally dead (hw problems) and I have to > make new one, but I plan to use > FreeBSD-6.2-STABLE. > > My question is are there any know compatibility issues between 6.1 and > 6.2? I know that > a lot of changes are committed to if_bridge and pf/pfsync, that's why > I'm little unsure :) Regarding pf there have not been any commits that should affect=20 compatibility. For if_bridge there have been some refinements regarding=20 the pfil hooks, but these should - if at all - only affect you in a=20 positive way. There is a extensive section "PACKET FILTERING" in the=20 if_bridge manpage which is a good read. > Sorry if this is not the proper mail list. This is indeed the right list. You might consider freebsd-pf@ if you have= =20 followup questions regarding pf. =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 --nextPart1346434.ELUrUNuatm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF+o+7XyyEoT62BG0RAp+YAJ4sDOKZg0cfniry6p1B4M8J4J+MDgCcCpNy vT0D3I1Hod3DXb8oxwqnDqw= =RFZb -----END PGP SIGNATURE----- --nextPart1346434.ELUrUNuatm-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 13:17:50 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0625B16A404 for ; Fri, 16 Mar 2007 13:17:50 +0000 (UTC) (envelope-from bohra@cs.rutgers.edu) Received: from mail.nec-labs.com (mail.nec-labs.com [138.15.200.209]) by mx1.freebsd.org (Postfix) with ESMTP id C129913C489 for ; Fri, 16 Mar 2007 13:17:49 +0000 (UTC) (envelope-from bohra@cs.rutgers.edu) Received: from mail.nec-labs.com (localhost.localdomain [127.0.0.1]) by mail.nec-labs.com (8.13.6/8.13.6) with ESMTP id l2GDHkqV027017 for ; Fri, 16 Mar 2007 09:17:46 -0400 Received: from mailer.nec-labs.com (mailer.nec-labs.com [138.15.108.3]) by mail.nec-labs.com (8.13.6/8.13.6) with ESMTP id l2GDHkhp027011 for ; Fri, 16 Mar 2007 09:17:46 -0400 Received: from [138.15.109.80] ([138.15.109.80] unverified) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Mar 2007 09:17:46 -0400 Message-ID: <45FA98DD.3080205@cs.rutgers.edu> Date: Fri, 16 Mar 2007 09:17:17 -0400 From: Aniruddha Bohra User-Agent: Thunderbird 1.5.0.9 (X11/20070217) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2007 13:17:46.0383 (UTC) FILETIME=[7CD7E9F0:01C767CD] Subject: ether_input question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 13:17:50 -0000 Hi, In two drivers, fxp and em, the assumptions about entering the ether_input routine are different. From em_rxeof: #ifdef DEVICE_POLLING EM_UNLOCK() (*ifp->if_input)() EM_UNLOCK() #else (*ifp->if_input)() #endif While in fxp: FXP_UNLOCK() (*ifp->if_input)() FXP_LOCK() My question is : Does ether_input() assume it is the only thread executing the code? If it is the case, what is the reason for dropping the lock in the DEVICE_POLLING case? Thanks Aniruddha From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 13:21:27 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7208F16A404 for ; Fri, 16 Mar 2007 13:21:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1CB4C13C44C for ; Fri, 16 Mar 2007 13:21:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 356864741F; Fri, 16 Mar 2007 08:21:25 -0500 (EST) Date: Fri, 16 Mar 2007 14:21:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Aniruddha Bohra In-Reply-To: <45FA98DD.3080205@cs.rutgers.edu> Message-ID: <20070316141836.J60288@fledge.watson.org> References: <45FA98DD.3080205@cs.rutgers.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: ether_input question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 13:21:27 -0000 On Fri, 16 Mar 2007, Aniruddha Bohra wrote: > In two drivers, fxp and em, the assumptions about entering the ether_input > routine are different. From em_rxeof: > > #ifdef DEVICE_POLLING > EM_UNLOCK() > (*ifp->if_input)() > EM_UNLOCK() > #else > (*ifp->if_input)() > #endif > > While in fxp: > > FXP_UNLOCK() > (*ifp->if_input)() > FXP_LOCK() > > My question is : Does ether_input() assume it is the only thread executing > the code? If it is the case, what is the reason for dropping the lock in the > DEVICE_POLLING case? I can't speak to the details of the above, but can speak generally on the issue of the link layer input path and locking. There is no assumption that the caller will provide serialization, and fully concurrent input from multiple threads is supported. The reason the drivers drop their locks is that the network stack frequently holds locks over calls to driver output routines. As a result, driver locks tend to follow network stack locks in the lock order--at least, for drivers that have a single lock covering both send and receive paths (quite common). As a result, the driver must drop the driver lock before calling into the stack to avoid a lock order reversal. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 14:11:30 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BB1E16A409; Fri, 16 Mar 2007 14:11:30 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id CD9D513C4B0; Fri, 16 Mar 2007 14:11:29 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 5EF671F9750; Fri, 16 Mar 2007 10:11:28 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Fri, 16 Mar 2007 10:11:28 -0400 X-Sasl-enc: +eu8BQOxAf62eTLYUuz3KIFLXSQdeK9k4z0p80ygecGJ 1174054289 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 72D5417819; Fri, 16 Mar 2007 10:11:28 -0400 (EDT) Message-ID: <45FAA58E.6000600@FreeBSD.org> Date: Fri, 16 Mar 2007 14:11:26 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Anton Yuzhaninov References: <20070314115916.GB2713@cell.sick.ru> <45F81C0D.2000608@FreeBSD.org> <20070314161023.GF2713@cell.sick.ru> <45F974BE.5050404@freebsd.org> <446293168.20070316145503@citrin.ru> In-Reply-To: <446293168.20070316145503@citrin.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Andre Oppermann Subject: Re: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 14:11:30 -0000 Anton Yuzhaninov wrote: > Thursday, March 15, 2007, 7:30:54 PM, Andre Oppermann wrote: > > AO> IMO when configuring a interface with an IP address and network it should > AO> kick out previous host and/or network routes matching it. Unless those > AO> are from locally configured interfaces, then it should reject the new > AO> attempt. > > New route should replace existing one only if it have administrative > distance (in cisco terms) smaller than AD for existing route. > > Preference of network from locally configured interface is only > particular case of this general principle. > We are obstructed by the current radix trie code only matching on destination and prefix. Adding 'administrative distance' to the FTE match is something which should seriously be considered. It is a stepping stone to equal cost multipath and would help in this situation. It does however considerably change the semantics of the existing routing socket and its consumers would need to be updated to reflect that fact. As I hinted at in my original response: it seems acceptable that ifconfig'ing an interface into the system should be able to clobber the overlapping routes in the meantime, but only until the architecture is fixed. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 14:13:54 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E152816A402; Fri, 16 Mar 2007 14:13:54 +0000 (UTC) (envelope-from bohra@nec-labs.com) Received: from mail.nec-labs.com (mail.nec-labs.com [138.15.200.209]) by mx1.freebsd.org (Postfix) with ESMTP id A587913C46E; Fri, 16 Mar 2007 14:13:54 +0000 (UTC) (envelope-from bohra@nec-labs.com) Received: from mail.nec-labs.com (localhost.localdomain [127.0.0.1]) by mail.nec-labs.com (8.13.6/8.13.6) with ESMTP id l2GDmS0K032016; Fri, 16 Mar 2007 09:48:28 -0400 Received: from mailer.nec-labs.com (mailer.nec-labs.com [138.15.108.3]) by mail.nec-labs.com (8.13.6/8.13.6) with ESMTP id l2GDmSa7032009; Fri, 16 Mar 2007 09:48:28 -0400 Received: from [138.15.109.80] ([138.15.109.80] unverified) by mailer.nec-labs.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Mar 2007 09:48:28 -0400 Message-ID: <45FAA00F.4070208@nec-labs.com> Date: Fri, 16 Mar 2007 09:47:59 -0400 From: Aniruddha Bohra User-Agent: Thunderbird 1.5.0.9 (X11/20070217) MIME-Version: 1.0 To: Robert Watson References: <45FA98DD.3080205@cs.rutgers.edu> <20070316141836.J60288@fledge.watson.org> In-Reply-To: <20070316141836.J60288@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2007 13:48:28.0382 (UTC) FILETIME=[C6C2A7E0:01C767D1] Cc: freebsd-net@FreeBSD.org Subject: Re: ether_input question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 14:13:55 -0000 Robert Watson wrote: > On Fri, 16 Mar 2007, Aniruddha Bohra wrote: >> My question is : Does ether_input() assume it is the only thread >> executing the code? If it is the case, what is the reason for >> dropping the lock in the DEVICE_POLLING case? > > I can't speak to the details of the above, but can speak generally on > the issue of the link layer input path and locking. There is no > assumption that the caller will provide serialization, and fully > concurrent input from multiple threads is supported. The reason the > drivers drop their locks is that the network stack frequently holds > locks over calls to driver output routines. As a result, driver locks > tend to follow network stack locks in the lock order--at least, for > drivers that have a single lock covering both send and receive paths > (quite common). As a result, the driver must drop the driver lock > before calling into the stack to avoid a lock order reversal. Thanks Robert, So, if I have a queue shared between ether_input() and another thread, I need to ensure mutual exclusion. In such scenarios, should spinlocks or default mutexes be used? The driver locks themselves are usually MTX_DEF, whereas in netgraph for example, (the scenario above), a spinlock is used. Is there a rule of thumb, for example, never use blocking locks in the network interrupt path? Thanks Aniruddha From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 15:55:40 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2D1616A401 for ; Fri, 16 Mar 2007 15:55:40 +0000 (UTC) (envelope-from s8827129@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 427A013C46E for ; Fri, 16 Mar 2007 15:55:39 +0000 (UTC) (envelope-from s8827129@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so718797ugh for ; Fri, 16 Mar 2007 08:55:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=itJC3OpNQ1nMX+08WyoYNr7SPnMu1iJ6U+Y09oyeZhRR1T88mdn0IzdFAyKBwI4xvk7LcJOFKiVYMDSdc7uH58EaMEqTmKtdv85EUAEBvrb4c8uHxlFfV++b9Mm8QdeWuiRWQY1cHcQIXpVoQ8cplup21jt33ANjxTKFGJVfyy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=aR2NDP5RW3chnfMoVYSFD78TWPBaYf3nIoASBPCSLlJg6yOvfwH6EVcu4i1Mzk6QI7Q5RotCDjmx6EK71ozDiF4RtT5jS/B+IcnJIok9bVYhoP36t+V5k+zlGt6t39orzwfbgjVMKxDTcxDtCgqkbKiQbjtFj4jRbq04KJoJTQw= Received: by 10.114.168.1 with SMTP id q1mr760484wae.1174058878848; Fri, 16 Mar 2007 08:27:58 -0700 (PDT) Received: by 10.115.90.17 with HTTP; Fri, 16 Mar 2007 08:27:58 -0700 (PDT) Message-ID: <6603c4f10703160827p141d1562p902dedcb4d269398@mail.gmail.com> Date: Fri, 16 Mar 2007 23:27:58 +0800 From: "speedo chen" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Why the IPFilter version on FreeBSD6.2 is former than the one on FreeBSD6.0 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 15:55:40 -0000 Hi all: Below links show that *IPFilter* has been updated from 3.4.35 to 4.1.18. On FreeBSD6.0 *IPFilter* has been updated from 4.1.8 to 4.1.13. On FreeBSD6.2 http://www.freebsd.org/releases/6.0R/relnotes-i386.html#CONTRIB http://www.freebsd.org/releases/6.2R/relnotes-i386.html#CONTRIB Could someone tell me why the version of IPFilter on FreeBSD6.2 is former than FreeBSD6.0 ? Thanks. Sincerely, Y.T. From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 16:16:20 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8618416A400 for ; Fri, 16 Mar 2007 16:16:20 +0000 (UTC) (envelope-from marion.beckera@quickemail.de) Received: from ns1.smart-weblications.de (ns1.smart-weblications.de [83.151.19.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2464D13C487 for ; Fri, 16 Mar 2007 16:16:19 +0000 (UTC) (envelope-from marion.beckera@quickemail.de) Received: from ts (mail.weber-stock.de [195.238.144.3] (may be forged)) (authenticated bits=0) by ns1.smart-weblications.de (8.13.4/8.13.8/Debian-2) with ESMTP id l2FKFJEn024154 for ; Thu, 15 Mar 2007 21:19:37 +0100 Message-Id: <200703152019.l2FKFJEn024154@ns1.smart-weblications.de> From: "Marion.Backera" To: freebsd-net@freebsd.org MIME-Version: 1.0 Date: Thu, 15 Mar 2007 21:19:47 +0100 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Herzlichen =?iso-8859-1?q?Gl=FCckwunsch=2C?= du hast einen Tag gewonnen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 16:16:20 -0000 Du bist ausgelost, du hast 1 Tag Dil do Sau gewonnen f=FCr 4,95 Euro http://dildosau.com/?pid=3D71366&hc=3D0&trial=3D1 [http://dildosau.com= /?pid=3D71366&hc=3D0&trial=3D1] From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 16:42:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD61516A400 for ; Fri, 16 Mar 2007 16:42:47 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6EF13C4B9 for ; Fri, 16 Mar 2007 16:42:47 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from booyah.home.comstyle.com (unknown [IPv6:2001:4830:122b:5:216:6fff:fe3e:6327]) (Authenticated sender: brad) by fubar.home.comstyle.com (Postfix) with ESMTP id BC17EA2C68 for ; Fri, 16 Mar 2007 12:24:19 -0400 (EDT) Date: Fri, 16 Mar 2007 12:24:16 -0400 From: Brad To: freebsd-net@freebsd.org Message-ID: <20070316122416.367e577f@booyah.home.comstyle.com> In-Reply-To: <6603c4f10703160827p141d1562p902dedcb4d269398@mail.gmail.com> References: <6603c4f10703160827p141d1562p902dedcb4d269398@mail.gmail.com> X-Mailer: Claws Mail 2.7.2 (GTK+ 2.8.20; i386-unknown-openbsd4.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Why the IPFilter version on FreeBSD6.2 is former than the one on FreeBSD6.0 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 16:42:47 -0000 On Fri, 16 Mar 2007 23:27:58 +0800 "speedo chen" wrote: > Hi all: > > Below links show that > > *IPFilter* has been updated from 3.4.35 to 4.1.18. On > FreeBSD6.0 *IPFilter* has been updated from 4.1.8 to 4.1.13. On > FreeBSD6.2 > > http://www.freebsd.org/releases/6.0R/relnotes-i386.html#CONTRIB > http://www.freebsd.org/releases/6.2R/relnotes-i386.html#CONTRIB > > > Could someone tell me why the version of IPFilter on FreeBSD6.2 is > former than FreeBSD6.0 ? > Thanks. The release notes for 6.0 has a typo in it. > Sincerely, > Y.T. From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 18:30:46 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 351D716A401; Fri, 16 Mar 2007 18:30:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id D776013C468; Fri, 16 Mar 2007 18:30:45 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l2GIUjsp001887; Fri, 16 Mar 2007 14:30:45 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-net@FreeBSD.org Date: Fri, 16 Mar 2007 14:30:40 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200703161430.42854.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2851/Fri Mar 16 12:11:20 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-stable@FreeBSD.org Subject: [PATCH] bge(4) patch for -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 18:30:46 -0000 I have made bge(4) patch for -STABLE (sorry, not suitable for RELENG_6_2): http://people.freebsd.org/~jkim/bge_releng6.diff I received few success reports but I need wider testing because changes are too big and there are two many BCM57xx variants out there. If it breaks anything, please let me know. Especially, I want to hear more about IPMI/ASF mode support, i.e., if it doesn't work but setting hw.bge.allow_asf=0 in /boot/loader.conf fixes the problem, definitely I want to know. Thanks, Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Fri Mar 16 20:30:28 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD14116A404 for ; Fri, 16 Mar 2007 20:30:28 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 634AF13C4BD for ; Fri, 16 Mar 2007 20:30:28 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id B62441CC58; Sat, 17 Mar 2007 09:30:26 +1300 (NZDT) Date: Sat, 17 Mar 2007 09:30:26 +1300 From: Andrew Thompson To: Stefan Lambrev Message-ID: <20070316203026.GA2312@heff.fud.org.nz> References: <45FA6ADD.1090608@sun-fish.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45FA6ADD.1090608@sun-fish.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@FreeBSD.org Subject: Re: if_bridge & pf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 20:30:28 -0000 On Fri, Mar 16, 2007 at 12:01:01PM +0200, Stefan Lambrev wrote: > Hello, > > I have 2 firewalls, and every of them have 2 bridged interfaces + STP , > running FreeBSD 6.1-STABLE > Unfortunately one of them is totally dead (hw problems) and I have to > make new one, but I plan to use > FreeBSD-6.2-STABLE. > > My question is are there any know compatibility issues between 6.1 and > 6.2? I know that > a lot of changes are committed to if_bridge and pf/pfsync, that's why > I'm little unsure :) For if_bridge there were over a dozen commits, half were new feaures and the other half bugfixes. I do not know of any compatibility issues. The main one for you to test would be the addition of RSTP which was a large overhaul of the existing code. The default protocol is still STP and should be no different for you. Andrew From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 07:03:17 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F90716A401 for ; Sat, 17 Mar 2007 07:03:17 +0000 (UTC) (envelope-from rajkumars@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id F021313C45B for ; Sat, 17 Mar 2007 07:03:16 +0000 (UTC) (envelope-from rajkumars@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so732493wxc for ; Sat, 17 Mar 2007 00:03:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ScC7u+9wgwc8XpmW2lkso/jGYN64oshJHzsNy+EUBqfafCohxsg+L5BXmkfcAPLrqypkE2LZ7ynFoiw9Fo7XXwrQ/639h6beOMM6SZlvHeQUDU8CBnN2y4aN8qvRjo+SnakngdsuF80PNxf6wbHJrqUnqrgzfwEO2LsHr0ZNWAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hps8T3HAV68hplYKp6A+97bkdoPJop251QzJO8LWlf4aHRrChHcvN38dWjZ337/KmYsXaubbj7annT7x3W+Y51+cdKC1Neg0WsLyu9sXH9NAk2eKjdIlFhFWgc4N9kRSxzINbm+sqLsrOsIeoIZYEKgSqmezXUjbrZoP+8WbDaM= Received: by 10.70.125.2 with SMTP id x2mr4610120wxc.1174113247476; Fri, 16 Mar 2007 23:34:07 -0700 (PDT) Received: by 10.70.69.8 with HTTP; Fri, 16 Mar 2007 23:34:07 -0700 (PDT) Message-ID: <64de5c8b0703162334y5ca29839vb4af5ac5f9e90480@mail.gmail.com> Date: Sat, 17 Mar 2007 12:04:07 +0530 From: "Rajkumar S" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: kernel panic when using safe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 07:03:17 -0000 Hi, I am trying to install SafeNet 1141 support in one of the freebsd boxes here. according to safe(4), I have to add "device safe" into my kernel config and compile to enable hardware crypto acceleration. But after I boot with safe module enabled I get a kernel panic. The last couple of lines in my boot message are safe0 mem 0xf6120000-0xf6121fff irq 5 at device 10.0 on pci0 safe0: cannot allocate DMA tag device_attach: safe0 attach returned 6 re0: port 0xb000-0xb0ff mem 0xf6120 re0: could not allocate dma tag Fatal trap 12: page fault while in kernel mode fault virtual address = 0x60 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0570ea5 stack pointer = 0x28:0xc0c20bd0 frame pointer = 0x28:0xc0c20be4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 12 panic: page fault Uptime: 1s To test this further, I commented the "device safe" line from the kernel config and this time the system booted up correctly. The diff of the messages up to the point of panic is --- embedded.txt 2007-03-16 15:59:52.528876360 +0530 +++ freebsd.dump 2007-03-16 15:58:18.852117392 +0530 @@ -3,7 +3,7 @@ The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. -FreeBSD 6.2-RELEASE-p3 #0: Fri Mar 16 08:57:36 UTC 2007 +FreeBSD 6.2-RELEASE-p3 #0: Thu Mar 15 11:46:30 UTC 2007 root@beastie.linuxense.com:/usr/obj.pfSense/usr/src/sys/pfSense_wrap.6 Timecounter "i8254" frequency 1193182 Hz quality 0 @@ -69,6 +69,24 @@ rlphy7: on miibus7 rlphy7: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl7: Ethernet address: 00:60:e0:04:29:e4 -pci0: at device 10.0 (no driver attached) +safe0 mem 0xf6120000-0xf6121fff irq 5 at device 10.0 on pci0 +safe0: cannot allocate DMA tag +device_attach: safe0 attach returned 6 re0: port 0xb000-0xb0ff mem 0xf6120 +re0: could not allocate dma tag + + +Fatal trap 12: page fault while in kernel mode +fault virtual address = 0x60 +fault code = supervisor read, page not present +instruction pointer = 0x20:0xc0570ea5 +stack pointer = 0x28:0xc0c20bd0 +frame pointer = 0x28:0xc0c20be4 +code segment = base 0x0, limit 0xfffff, type 0x1b + = DPL 0, pres 1, def32 1, gran 1 +processor eflags = interrupt enabled, resume, IOPL = 0 +current process = 0 (swapper) +trap number = 12 +panic: page fault +Uptime: 1s It's only 2 lines about could not allocate dma tag, I have searched for this error message, but nothing came up. Any help to get the safe(4) working will me very much appreciated. I can provide more information if required. The kernel config is at the end of the mail. I am using FreeBSD 6.2 and use the following supfile to update the kernel *default base=/var/db *default host=cvsup2.freebsd.org *default prefix=/usr *default release=cvs tag=RELENG_6_2 *default delete use-rel-suffix *default compress src-all Thanks for reading, raj -- machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident embedded # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. options COMPAT_FREEBSD5 options CPU_GEODE options CPU_SOEKRIS options CPU_ELAN #options CPU_ELAN_PPS #options CPU_ELAN_XTAL=32768000 #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID #device mlx # Mylex DAC960 family device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # IO devices for console device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Floating point support - do not disable. device npx # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device ppi # Parallel port interface device # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device lge # Level 1 LXT1001 gigabit Ethernet device nge # NatSemi DP83820 gigabit Ethernet device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Wireless NIC cards device wlan # 802.11 support device wlan_wep device wlan_ccmp device wlan_tkip device wlan_xauth device wlan_acl device ath device ath_rate_sample device ath_hal device an # Aironet 4500/4800 802.11 wireless NICs. device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. device wl # Older non 802.11 Wavelan wireless NIC. #device iwi # Intel PRO/Wireless 2200BG # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device ucom # Uncommented at the request of colin device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) # pfsense addons device wlan # 802.11 support device wlan_wep device wlan_ccmp device wlan_tkip device wlan_xauth device wlan_acl device ath device ath_rate_sample device ath_hal device an # Aironet 4500/4800 802.11 wireless NICs. device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. device wl # Older non 802.11 Wavelan wireless NIC. device tap device gre options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT device vlan options IPSTEALTH options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN options GEOM_UZIP options GEOM_LABEL options NETGRAPH #netgraph(4) system options NETGRAPH_BPF options NETGRAPH_ETHER options NETGRAPH_IFACE options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options NETGRAPH_RFC1490 options NETGRAPH_SOCKET options NETGRAPH_TTY options NETGRAPH_MPPC_ENCRYPTION #options NETGRAPH_UI #options NETGRAPH_VJC #options NETGRAPH_KSOCKET #options NETGRAPH_LMI #options NETGRAPH_ONE2MANY #options NETGRAPH_BRIDGE #options NETGRAPH_CISCO #options NETGRAPH_ECHO #options NETGRAPH_ASYNC #options NETGRAPH_FRAME_RELAY #options NETGRAPH_HOLE #options NETGRAPH_TEE device ubsa device ucom options FAST_IPSEC #device enc options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_PRIQ device pf device pflog device carp device pfsync device crypto # core crypto support device cryptodev # /dev/crypto for access to h/w device rndtest # FIPS 140-2 entropy tester device hifn # Hifn 7951, 7781, etc. options HIFN_DEBUG # enable debugging support: hw.hifn.debug options HIFN_RNDTEST # enable rndtest support device ubsec # Broadcom 5501, 5601, 58xx #device safe # SafeNet Support device if_bridge device speaker device hme options DEVICE_POLLING options ZERO_COPY_SOCKETS options HZ=100 device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet options TCP_SIGNATURE options PREEMPTION #options NO_ADAPTIVE_MUTEXES options ADAPTIVE_GIANT # Giant mutex is adaptive. # Lighttpd options ACCEPT_FILTER_HTTP # IPSEC filtering interface device enc From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 07:05:14 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 267EC16A405 for ; Sat, 17 Mar 2007 07:05:14 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id A92E313C465 for ; Sat, 17 Mar 2007 07:05:13 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 9850 invoked by uid 0); 17 Mar 2007 09:43:34 +0300 Received: from tarkhil.rostokino.net (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 17 Mar 2007 06:43:34 -0000 Message-ID: <45FB8CE5.7010100@webmail.sub.ru> Date: Sat, 17 Mar 2007 09:38:29 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Any success with Intel Wi-Fi on IBM Lenovo R60 and FreeBSD 6.x? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 07:05:14 -0000 Hello! Does anyone have any positive experience with Intel WiFi adapter on Lenovo R60 with FreeBSD 6.X? Native driver or ndis, does not matter. Alex. From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 11:26:38 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 130EC16A401 for ; Sat, 17 Mar 2007 11:26:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id BDA2413C44C for ; Sat, 17 Mar 2007 11:26:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 179F446D1B; Sat, 17 Mar 2007 06:26:37 -0500 (EST) Date: Sat, 17 Mar 2007 12:26:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Aniruddha Bohra In-Reply-To: <45FAA00F.4070208@nec-labs.com> Message-ID: <20070317121920.D7579@fledge.watson.org> References: <45FA98DD.3080205@cs.rutgers.edu> <20070316141836.J60288@fledge.watson.org> <45FAA00F.4070208@nec-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: ether_input question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 11:26:38 -0000 On Fri, 16 Mar 2007, Aniruddha Bohra wrote: > Robert Watson wrote: >> >> I can't speak to the details of the above, but can speak generally on the >> issue of the link layer input path and locking. There is no assumption >> that the caller will provide serialization, and fully concurrent input from >> multiple threads is supported. The reason the drivers drop their locks is >> that the network stack frequently holds locks over calls to driver output >> routines. As a result, driver locks tend to follow network stack locks in >> the lock order--at least, for drivers that have a single lock covering both >> send and receive paths (quite common). As a result, the driver must drop >> the driver lock before calling into the stack to avoid a lock order >> reversal. > > So, if I have a queue shared between ether_input() and another thread, I > need to ensure mutual exclusion. In such scenarios, should spinlocks or > default mutexes be used? I'm not sure I completely understand the scenario you are suggesting -- could you be specific? Normally, from the perspective of a device driver author, you simply drop your driver-specific locks and call ifp->if_input() to hand the mbuf chain up to the link layer. No locks need to be held around the call to the input routine. On the other hand, if you are modifying the link layer itself (i.e., hooking into it in one of a number of ways), this means that you must provide any synchronization necessary to make your code operate correctly in the presence of concurrency. Many instances of ether_input() may run at the same time on various CPUs -- typically one per input source, since they run in the ithread of the device driver. In general, you should use default mutexes in preference to spin mutexes unless you know your code will run the fast interrupt path (rather than the ithread path). Universally, the network stack assumes it will not run in the fast interrupt path, so unless you're doing something quite low level and special involving a device driver, default mutexes (or rwlocks if you need shared locking) are the right way to go. > The driver locks themselves are usually MTX_DEF, whereas in netgraph for > example, (the scenario above), a spinlock is used. Is there a rule of thumb, > for example, never use blocking locks in the network interrupt path? I am not sure why Netgraph uses spin locks -- it probably shouldn't be doing so. In the kernel we have several different notions of "sleeping", and unfortunately the terminology is not entirely clear. The best way I've found to explain it is using the term "bounded". Sleeping associated with mutexes and rwlocks is bounded sleeping, whereas sleeping associated with condition variables, wait channels, and sx locks is unbounded sleeping. This distinction is important because you don't want, for example, an interrupt thread performing an unbounded sleep waiting on something that may not happen for a very long (unbounded) period of time, such as waiting for keyboard input or disk I/O to return. If you run with INVARIANTS and WITNESS, a debugging kernel should warn you if you try to acquire the wrong type of lock in the wrong context. A locking(9) man page talking about some of the selection choices was recently added to 7-CURRENT, FYI. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 14:39:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78EAB16A402 for ; Sat, 17 Mar 2007 14:39:22 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ivy.southportcomputers.co.uk (ivy.southportcomputers.co.uk [82.195.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id D47CD13C459 for ; Sat, 17 Mar 2007 14:39:21 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ivy.southportcomputers.co.uk (localhost [127.0.0.1]) by ivy.southportcomputers.co.uk (8.14.0/8.13.4) with ESMTP id l2HEAdWx096737 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Mar 2007 14:10:39 GMT (envelope-from freebsd@southportcomputers.co.uk) Received: (from www@localhost) by ivy.southportcomputers.co.uk (8.14.0/8.13.6/Submit) id l2HEAX1v096736; Sat, 17 Mar 2007 14:10:33 GMT (envelope-from freebsd@southportcomputers.co.uk) X-Authentication-Warning: ivy.southportcomputers.co.uk: www set sender to freebsd@southportcomputers.co.uk using -f Received: from 84.92.207.22 (SquirrelMail authenticated user scomp) by mail.southportcomputers.co.uk with HTTP; Sat, 17 Mar 2007 14:10:33 -0000 (GMT) Message-ID: <55580.84.92.207.22.1174140633.squirrel@mail.southportcomputers.co.uk> Date: Sat, 17 Mar 2007 14:10:33 -0000 (GMT) From: "Colin Waring" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Troubleshooting aliases. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 14:39:22 -0000 Hi folks, Been running into brick walls since last night on this one. Situation is that our server has 6.1-RELEASE on it with four IP addresses. The section of rc.conf is this: ifconfig_em0="inet a.a.a.a netmask 255.255.255.0" ifconfig_em0_alias0="inet a.a.a.b netmask 255.255.255.255" ifconfig_em0_alias1="inet a.a.a.c netmask 255.255.255.255" ifconfig_em0_alias2="inet a.a.a.d netmask 255.255.255.255" For some reason, with no updates or changes both a.a.a.b and a.a.a.c have stopped working properly. a.a.a.a works fine, as does a.a.a.d. Unfortunately, the nameservers for the domains hosted on the server use a.a.a.b and a.a.a.c! So basically I can't figure out what's up as .d works fine..anyone able to help me with some suggestions of where to look for fixing .b and .c? From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 15:18:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2391A16A403 for ; Sat, 17 Mar 2007 15:18:10 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id C6E8C13C457 for ; Sat, 17 Mar 2007 15:18:08 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id CAA01286; Sun, 18 Mar 2007 02:17:54 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 18 Mar 2007 02:17:53 +1100 (EST) From: Ian Smith To: Colin Waring In-Reply-To: <55580.84.92.207.22.1174140633.squirrel@mail.southportcomputers.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Troubleshooting aliases. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 15:18:10 -0000 On Sat, 17 Mar 2007, Colin Waring wrote: > Hi folks, > Been running into brick walls since last night on this one. > Situation is that our server has 6.1-RELEASE on it with four IP addresses. > > The section of rc.conf is this: > > ifconfig_em0="inet a.a.a.a netmask 255.255.255.0" > ifconfig_em0_alias0="inet a.a.a.b netmask 255.255.255.255" > ifconfig_em0_alias1="inet a.a.a.c netmask 255.255.255.255" > ifconfig_em0_alias2="inet a.a.a.d netmask 255.255.255.255" > > For some reason, with no updates or changes both a.a.a.b and a.a.a.c have > stopped working properly. a.a.a.a works fine, as does a.a.a.d. Sorry if it should be obvious, but stopped working properly in what way? > Unfortunately, the nameservers for the domains hosted on the server use > a.a.a.b and a.a.a.c! > > So basically I can't figure out what's up as .d works fine..anyone able to > help me with some suggestions of where to look for fixing .b and .c? Works fine at doing what, by comparison? Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 15:19:22 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D09716A401 for ; Sat, 17 Mar 2007 15:19:22 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.embarqhsd.net [65.40.24.38]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5A213C4DB for ; Sat, 17 Mar 2007 15:19:21 +0000 (UTC) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.13.8/8.13.1) with ESMTP id l2HEwMe3027217; Sat, 17 Mar 2007 09:58:22 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.13.8/8.13.1/Submit) id l2HEwGoO027216; Sat, 17 Mar 2007 10:58:16 -0400 (EDT) (envelope-from bv) Date: Sat, 17 Mar 2007 10:58:16 -0400 From: Bill Vermillion To: Colin Waring Message-ID: <20070317145816.GA27192@wjv.com> References: <55580.84.92.207.22.1174140633.squirrel@mail.southportcomputers.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55580.84.92.207.22.1174140633.squirrel@mail.southportcomputers.co.uk> User-Agent: Mutt/1.4.2.2i Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bilver.wjv.com Cc: freebsd-net@freebsd.org Subject: Re: Troubleshooting aliases. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 15:19:22 -0000 Somewhere around Sat, Mar 17, 2007 at 14:10 , the world stopped and listened as Colin Waring graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: > Hi folks, > Been running into brick walls since last night on this one. > Situation is that our server has 6.1-RELEASE on it with four IP addresses. > > The section of rc.conf is this: > > ifconfig_em0="inet a.a.a.a netmask 255.255.255.0" > ifconfig_em0_alias0="inet a.a.a.b netmask 255.255.255.255" > ifconfig_em0_alias1="inet a.a.a.c netmask 255.255.255.255" > ifconfig_em0_alias2="inet a.a.a.d netmask 255.255.255.255" > For some reason, with no updates or changes both a.a.a.b and > a.a.a.c have stopped working properly. a.a.a.a works fine, as > does a.a.a.d. > > Unfortunately, the nameservers for the domains hosted on the > server use a.a.a.b and a.a.a.c! > So basically I can't figure out what's up as .d works fine..anyone able to > help me with some suggestions of where to look for fixing .b and .c? You showed up your rc.conf. What might be more helpful is the output of 'ifconfig'. Perhaps the aliases have been deleted. Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 15:30:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 018D016A401 for ; Sat, 17 Mar 2007 15:30:43 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ivy.southportcomputers.co.uk (ivy.southportcomputers.co.uk [82.195.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 8D90113C43E for ; Sat, 17 Mar 2007 15:30:42 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ivy.southportcomputers.co.uk (localhost [127.0.0.1]) by ivy.southportcomputers.co.uk (8.14.0/8.13.4) with ESMTP id l2HFUe5R097326 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Mar 2007 15:30:41 GMT (envelope-from freebsd@southportcomputers.co.uk) Received: (from www@localhost) by ivy.southportcomputers.co.uk (8.14.0/8.13.6/Submit) id l2HFUZkW097325; Sat, 17 Mar 2007 15:30:35 GMT (envelope-from freebsd@southportcomputers.co.uk) X-Authentication-Warning: ivy.southportcomputers.co.uk: www set sender to freebsd@southportcomputers.co.uk using -f Received: from 84.92.207.22 (SquirrelMail authenticated user scomp) by mail.southportcomputers.co.uk with HTTP; Sat, 17 Mar 2007 15:30:35 -0000 (GMT) Message-ID: <55974.84.92.207.22.1174145435.squirrel@mail.southportcomputers.co.uk> In-Reply-To: References: Date: Sat, 17 Mar 2007 15:30:35 -0000 (GMT) From: "Colin Waring" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Troubleshooting aliases. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 15:30:43 -0000 I'm sure I wrote out some more info than that but apparently not. I must be getting confused as I did a description somewhere else, sorry! Basically, .a and .d respond to pings and pass all traffic .b and .c respond to pings but don't appear to pass any other traffic. IPF is compiled but I've completely turned it off for testing None of the actual configuration has changed though so I wouldn't expect anything to show up in ifconfig any as it was all working like this previously.. em0: flags=8843 mtu 1500 options=b inet6 fe80::215:c5ff:fe5d:f7b7%em0 prefixlen 64 scopeid 0x1 inet a.a.a.a netmask 0xffffff00 broadcast a.a.a.255 inet a.a.a.b netmask 0xffffffff broadcast a.a.a.255 inet a.a.a.c netmask 0xffffffff broadcast a.a.a.255 inet a.a.a.d netmask 0xffffffff broadcast a.a.a.255 ether 00:15:c5:5d:f7:b7 media: Ethernet autoselect (100baseTX ) status: active Thanks Colin. From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 15:42:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0EDA16A405 for ; Sat, 17 Mar 2007 15:42:43 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 08CB613C507 for ; Sat, 17 Mar 2007 15:42:42 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.40.197] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1HSb3I4A1I-0006S9; Sat, 17 Mar 2007 16:42:41 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sat, 17 Mar 2007 16:42:29 +0100 User-Agent: KMail/1.9.5 References: <45FB8CE5.7010100@webmail.sub.ru> In-Reply-To: <45FB8CE5.7010100@webmail.sub.ru> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5131269.WtOS7Iyzm3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703171642.36019.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18lTCUQR02g9rko8nRJZrS78SJ+IPazol4C+eV PTPOXxbOoOm++OfxafycPOg2/1BFxwRqj+o9hIPtb5sz6ebmFq NCxnUD18VqyTg6Hi5bVSQ== Cc: freebsd-mobile@freebsd.org, Alex Povolotsky Subject: Re: Any success with Intel Wi-Fi on IBM Lenovo R60 and FreeBSD 6.x? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 15:42:43 -0000 --nextPart5131269.WtOS7Iyzm3 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 17 March 2007 07:38, Alex Povolotsky wrote: > Does anyone have any positive experience with Intel WiFi adapter on > Lenovo R60 with FreeBSD 6.X? That would be the 3945abg part, right? In that case you want the driver=20 from here: http://www.clearchain.com/wiki/Wpi > Native driver or ndis, does not matter. I have heard that ndis doesn't work for this one, but I wouldn't know. =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 --nextPart5131269.WtOS7Iyzm3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF/AxrXyyEoT62BG0RAt8oAJ9kZr0PtZRjZMKpmIIR/YuqHg6zaQCfYO3e HMVEDmJfbjeKYegT59mO3TI= =Ks1o -----END PGP SIGNATURE----- --nextPart5131269.WtOS7Iyzm3-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 16:36:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6ECB416A403 for ; Sat, 17 Mar 2007 16:36:54 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 9FC9113C45E for ; Sat, 17 Mar 2007 16:36:53 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 14258 invoked by uid 0); 17 Mar 2007 19:41:53 +0300 Received: from unknown (HELO ?85.192.19.9?) (tarkhil%sub.ru@85.192.19.9) by techno.sub.ru with SMTP; 17 Mar 2007 16:41:53 -0000 Message-ID: <45FC1920.90601@webmail.sub.ru> Date: Sat, 17 Mar 2007 19:36:48 +0300 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Max Laier References: <45FB8CE5.7010100@webmail.sub.ru> <200703171642.36019.max@love2party.net> In-Reply-To: <200703171642.36019.max@love2party.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Any success with Intel Wi-Fi on IBM Lenovo R60 and FreeBSD 6.x? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 16:36:54 -0000 Max Laier wrote: > On Saturday 17 March 2007 07:38, Alex Povolotsky wrote: > >> Does anyone have any positive experience with Intel WiFi adapter on >> Lenovo R60 with FreeBSD 6.X? >> > > That would be the 3945abg part, right? In that case you want the driver > from here: http://www.clearchain.com/wiki/Wpi > Already wrote to author - it recognize card, but attempt to ifconfig it up results in computer lockup > >> Native driver or ndis, does not matter. >> > > I have heard that ndis doesn't work for this one, but I wouldn't know. > > Yes, for me it did not work. Alex. From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 17:09:32 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2B8316A401 for ; Sat, 17 Mar 2007 17:09:32 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 8509A13C487 for ; Sat, 17 Mar 2007 17:09:31 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id EAA04205; Sun, 18 Mar 2007 04:09:23 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 18 Mar 2007 04:09:22 +1100 (EST) From: Ian Smith To: Colin Waring In-Reply-To: <55974.84.92.207.22.1174145435.squirrel@mail.southportcomputers.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Troubleshooting aliases. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 17:09:33 -0000 On Sat, 17 Mar 2007, Colin Waring wrote: > Basically, .a and .d respond to pings and pass all traffic > .b and .c respond to pings but don't appear to pass any other traffic. > > IPF is compiled but I've completely turned it off for testing If you run one tcpdump on lo0 and another on em0 and try 'other traffic' you should be able to see which packets are/n't getting out, or through. Other things maybe worth checking: # netstat -finet -rna # after pinging all your aliases # arp -an # check address (incl bcast) at MAC on interface # sockstat -4 # which addresses/ports are listening/connected > None of the actual configuration has changed though so I wouldn't expect > anything to show up in ifconfig any as it was all working like this > previously.. > > em0: flags=8843 mtu 1500 > options=b > inet6 fe80::215:c5ff:fe5d:f7b7%em0 prefixlen 64 scopeid 0x1 > inet a.a.a.a netmask 0xffffff00 broadcast a.a.a.255 > inet a.a.a.b netmask 0xffffffff broadcast a.a.a.255 > inet a.a.a.c netmask 0xffffffff broadcast a.a.a.255 > inet a.a.a.d netmask 0xffffffff broadcast a.a.a.255 > ether 00:15:c5:5d:f7:b7 > media: Ethernet autoselect (100baseTX ) > status: active Did you specify those broadcast addresses on b, c and d? Here I'd see a.a.a.b through a.a.a.d broadcast addresses for those having 0xffffffff netmasks (on 5.5-S) but don't know if that's relevant to your problem. Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 18:14:14 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2FD916A406 for ; Sat, 17 Mar 2007 18:14:14 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ivy.southportcomputers.co.uk (ivy.southportcomputers.co.uk [82.195.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 2D69B13C465 for ; Sat, 17 Mar 2007 18:14:13 +0000 (UTC) (envelope-from freebsd@southportcomputers.co.uk) Received: from ivy.southportcomputers.co.uk (localhost [127.0.0.1]) by ivy.southportcomputers.co.uk (8.14.0/8.13.4) with ESMTP id l2HIECHc099068 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Mar 2007 18:14:12 GMT (envelope-from freebsd@southportcomputers.co.uk) Received: (from www@localhost) by ivy.southportcomputers.co.uk (8.14.0/8.13.6/Submit) id l2HIE6De099067; Sat, 17 Mar 2007 18:14:06 GMT (envelope-from freebsd@southportcomputers.co.uk) X-Authentication-Warning: ivy.southportcomputers.co.uk: www set sender to freebsd@southportcomputers.co.uk using -f Received: from 84.92.113.93 (SquirrelMail authenticated user scomp) by mail.southportcomputers.co.uk with HTTP; Sat, 17 Mar 2007 18:14:06 -0000 (GMT) Message-ID: <49641.84.92.113.93.1174155246.squirrel@mail.southportcomputers.co.uk> In-Reply-To: References: Date: Sat, 17 Mar 2007 18:14:06 -0000 (GMT) From: "Colin Waring" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Troubleshooting aliases. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 18:14:14 -0000 Thanks to anyone who had a think about this one. It appears the cause is a bit simpler than thought. Quite simply, the hosting centre have apparantly allocated the IP addresses to someone else so whilst there is something responding, it isn't actually the right machine. Numpties. :) Regards, Colin. From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 18:43:38 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6CBF16A404 for ; Sat, 17 Mar 2007 18:43:38 +0000 (UTC) (envelope-from manuel.ochoa@yahoo.com) Received: from web58011.mail.re3.yahoo.com (web58011.mail.re3.yahoo.com [68.142.236.119]) by mx1.freebsd.org (Postfix) with SMTP id 611AF13C455 for ; Sat, 17 Mar 2007 18:43:38 +0000 (UTC) (envelope-from manuel.ochoa@yahoo.com) Received: (qmail 79431 invoked by uid 60001); 17 Mar 2007 18:16:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=jZ6c1nUO5v/GrblI6OmXiie94yrOwuK+hbYA1YlzgMI2j8FYrxTwj59hj05hCoCNW8vsI5on7pA4kbIxfYBrpo7Xk4ku34pJw9Rca/UJTI5uwpQ7qAuFlBGlT+/pO4rXDViYa0e7vVK3nG5lJz6xz22o5m9e1xg+zRxq45izMtE=; X-YMail-OSG: ZrsRtUoVM1mEeuCi1MY73byt92Bfa1YHxe2h9zqd5.EqlBdWNg0qWFKONKWi_dtaqj5Sor.PPEsmPtr3vRgfRnTTcgJonHKtxQYZJ_tv664fe3y69tNqN2ccROgDcF.6m2SrWNdXdTjCALPGG9Oq Received: from [64.183.197.194] by web58011.mail.re3.yahoo.com via HTTP; Sat, 17 Mar 2007 11:16:56 PDT X-Mailer: YahooMailRC/471 YahooMailWebService/0.6.132.8 Date: Sat, 17 Mar 2007 11:16:56 -0700 (PDT) From: manuel.ochoa@yahoo.com To: FreeBSD Net MIME-Version: 1.0 Message-ID: <826528.78192.qm@web58011.mail.re3.yahoo.com> X-Mailman-Approved-At: Sat, 17 Mar 2007 18:58:26 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Wireshark X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 18:43:38 -0000 Can someone please explain the difference between Wireshark and Wireshark-l= ite. I would like to install a packet sniffer on my FreeBSD box for CLI onl= y.=0AThanks,=0A=0AManuel Ochoa CCNP MCSA MCSE MCDBA=0AI will not fake my = way through life!=0A=0A=0A =0A_____________________________________________= _______________________________________=0AGet your own web address. =0AHav= e a HUGE year through Yahoo! Small Business.=0Ahttp://smallbusiness.yahoo.c= om/domains/?p=3DBESTDEAL From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 19:05:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C65016A403 for ; Sat, 17 Mar 2007 19:05:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id B77BA13C44B for ; Sat, 17 Mar 2007 19:05:24 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.40.197] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1HSeDJ0wxv-0005fA; Sat, 17 Mar 2007 20:05:13 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sat, 17 Mar 2007 20:05:06 +0100 User-Agent: KMail/1.9.5 References: <826528.78192.qm@web58011.mail.re3.yahoo.com> In-Reply-To: <826528.78192.qm@web58011.mail.re3.yahoo.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4050492.1Evy7u8IXb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703172005.12027.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/A5/HL/VJJy4Meq29OsCSJgc1Bz0tygOP8vkp SW7pmceCk34p2/Iw0MRLU/uyFlzaCTE9ZMjPdKmaznUgBdK/JN qgWDxsapDLKGWXV/B+UlA== Cc: manuel.ochoa@yahoo.com Subject: Re: Wireshark X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 19:05:25 -0000 --nextPart4050492.1Evy7u8IXb Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 17 March 2007 19:16, manuel.ochoa@yahoo.com wrote: > Can someone please explain the difference between Wireshark and > Wireshark-lite. I would like to install a packet sniffer on my FreeBSD > box for CLI only. Thanks, What's wrong with tcpdump(8)? Other than that building either the real or= =20 the -lite version with "WITHOUT_X11" defined will get you the=20 cli-version. "-lite" seems to just disable a couple of dissectors that=20 have a lot of external dependencies. =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 --nextPart4050492.1Evy7u8IXb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF/DvoXyyEoT62BG0RAiAiAJ9lgTdUgDoIISC8NAc6QTagvSDscgCffrSl MwKbJPs6WIfx224Ms8BHyFk= =5nAr -----END PGP SIGNATURE----- --nextPart4050492.1Evy7u8IXb-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 19:23:03 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23F6416A400; Sat, 17 Mar 2007 19:23:03 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C488513C45E; Sat, 17 Mar 2007 19:23:02 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HSeUW-000LPn-FE; Sat, 17 Mar 2007 22:23:01 +0300 Date: Sat, 17 Mar 2007 22:22:54 +0300 From: Eygene Ryabinkin To: Yar Tikhiy Message-ID: <20070317192254.GB82045@codelabs.ru> References: <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> <45F5BD36.1070205@inse.ru> <20070312214926.GK44732@comp.chem.msu.su> <20070313055029.GK58523@codelabs.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <20070313055029.GK58523@codelabs.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: rik@FreeBSD.org, Roman Kurakin , andre@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org, thompsa@FreeBSD.org, "Bruce M. Simpson" Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 19:23:03 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Good day. Tue, Mar 13, 2007 at 08:50:29AM +0300, Eygene Ryabinkin wrote: > Sure. And that is why all switches that can bear the IP on their > interfaces have distinct MACs for each interface or/and the only > one interface can have the IP. And that is why I am going to > add the paragraph to the if_bridge(4) describing the current situation > and giving advice on the setting IP for the bridge members and the > bridge itself. Will provide the patch in a day or two. OK, the patch to the if_bridge.4 is attached. It is rather lengthy, but I don't know how to make it clear with less amount of words. Comments are welcome. -- Eygene --wac7ysb48OaltWcw Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="if_bridge.4.diff" --- if_bridge.4.orig Sun Mar 4 15:37:22 2007 +++ if_bridge.4 Sat Mar 17 22:18:52 2007 @@ -219,9 +219,67 @@ so all packets are passed to the filter for processing. .Pp -Note that packets to and from the bridging host will be seen by the -filter on the interface with the appropriate address configured as well -as on the interface on which the packet arrives or departs. +The packets originating from the bridging host will be seen by +the filter on the interface that is looked up in the routing +table according to the packet destination address (not the MAC +address). +.Pp +The packets destined to the bridging host will be seen by the filter +on the interface with the MAC address equal to the packet's destination +MAC. Be prepated to the situation when some of the bridge members are sharing +the same MAC address (for example the +.Xr if_vlan 4 +interfaces: they are currenly sharing the +MAC address of the parent physical interface). It is not possible +to distinguish between these interfaces using their MAC address, +excluding the case when the packet's destination MAC address is +equal to the MAC address of the interface on which the packet was +entered to the system. In this case the filter will see the incoming +packet on this interface. In all other cases the interface seen +by the packet filter is almost randomly chosen from the list of +bridge members with the same MAC address. +.Pp +The previous paragraph is best illustrated with the following +pictures. Let the MAC address of the incoming packet's destination will be +.Nm nn:nn:nn:nn:nn:nn , +the interface on which packet entered the system is +.Nm vlanX +with the MAC address +.Nm xx:xx:xx:xx:xx:xx +and the bridge has more than one interface that are sharing the +same MAC address +.Nm yy:yy:yy:yy:yy:yy ; +we will call them +.Nm vlanY1 , +.Nm vlanY2 , +etc. Then if MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm xx:xx:xx:xx:xx:xx +then the filter will see the packet on the interface +.Nm vlanX +no matter if there are some other bridge members carrying the same +MAC address. But if the MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm yy:yy:yy:yy:yy:yy +then the interface that will be seen by the filter is some of the +.Nm vlanYn , +but it is not possible to know the name of the actual interface +without the knowledge of the system state and the +.Nm if_bridge +implementation details. +.Pp +This problem arises for any bridge members that are sharing the same +MAC address, not only to the +.Xr if_vlan 4 +ones: they we taken just as the example of such situation. So if one wants +the filter the locally destined packets based on their interface name, +he should be aware of this implication. Such situation will appear on the +filtering bridges that are doing IP-forwarding; in this case it is better +to assign the IP address only to the +.Nm if_bridge +interface and not to the bridge members. But your mileage may vary. .Sh EXAMPLES The following when placed in the file .Pa /etc/rc.conf --wac7ysb48OaltWcw-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 19:30:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E29216A401 for ; Sat, 17 Mar 2007 19:30:34 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6F713C43E for ; Sat, 17 Mar 2007 19:30:33 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so964554ugh for ; Sat, 17 Mar 2007 12:30:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=hZlBgDVFw9gk0oytMr0vXgD0YOq1P3qlSB5WhSz3njs5y+jH8pLOgw9FEWJfMIOr30PRZTvIaHwEIcRu0UPoGSjHSAsDM5CoVpVV4llIrJOzZJB8eDtiNdaw0JMSdMt4SVC9IbSIedx6Tqz9xobNjSDk1v2b4eKMmFbAnHvmY7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Wknr3J3p45XE/M90UXtn2Hz9lJSb317a6K+S/RXpnQMNOHgEIVkkNYY7hZZm0B0PHpLYlmtUrc9bxAQm9ohsCFpL1GDPa5ciCgMvMeJOME4i1OjMzMm6XN1TkpDhBuRikjalORenT5wu6BQXPbt/9b4JPbPeQP+Y4PqUHpUipx0= Received: by 10.65.222.11 with SMTP id z11mr1781967qbq.1174159831713; Sat, 17 Mar 2007 12:30:31 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Sat, 17 Mar 2007 12:30:31 -0700 (PDT) Message-ID: Date: Sat, 17 Mar 2007 22:30:31 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "manuel.ochoa@yahoo.com" In-Reply-To: <826528.78192.qm@web58011.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <826528.78192.qm@web58011.mail.re3.yahoo.com> X-Google-Sender-Auth: ba3c6b59f1b3ed6e Cc: FreeBSD Net Subject: Re: Wireshark X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 19:30:34 -0000 On 3/17/07, manuel.ochoa@yahoo.com wrote: > Can someone please explain the difference between Wireshark > and Wireshark-lite. I would like to install a packet sniffer > on my FreeBSD box for CLI only. lite = cli only From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 19:43:03 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E6DC16A402 for ; Sat, 17 Mar 2007 19:43:03 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 57C4713C44C for ; Sat, 17 Mar 2007 19:43:03 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 0402A1F84F4 for ; Sat, 17 Mar 2007 15:43:02 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Sat, 17 Mar 2007 15:43:02 -0400 X-Sasl-enc: RII7RimqyZZ18L8IEPQYCsG7LJLQJu+oDz4EYScXMdlI 1174160583 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 203432A8FC for ; Sat, 17 Mar 2007 15:43:02 -0400 (EDT) Message-ID: <45FC44C5.1090007@incunabulum.net> Date: Sat, 17 Mar 2007 19:43:01 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: IPv4, IPv6 and link-layer multicast refcounting in bms_netdev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 19:43:03 -0000 I have just committed reference counting for multicast structures in p4. Change list number is 116036. This should fix the problems with pfsync and carp since the scalability fixes for IPv4 multicast last September. A further cumulative fix for pfsync is present in this branch. Basic testing with the stock IPv4 and Ethernet code have been performed. Further testing would be much appreciated before the code is merged to HEAD. The refcounting has been implemented in a way so as not to break the 6.x ABI so that it may be merged to STABLE. It would be great to have feedback on how these patches may affect vlan(4) which is the only other consumer of the in_delmulti() KPI. My experience working on this suggests IFF_NEEDSGIANT is a real headache for dealing with ifnets which may potentially go away during the lifetime of the system. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 19:45:03 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0AD3C16A400 for ; Sat, 17 Mar 2007 19:45:03 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id D878813C45A for ; Sat, 17 Mar 2007 19:45:02 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 9AEB81F88B4 for ; Sat, 17 Mar 2007 15:45:01 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Sat, 17 Mar 2007 15:45:01 -0400 X-Sasl-enc: N9ArDqMdlCfidby6RcSqszvdWgkLPSsnBovVVvqSeSIL 1174160702 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id B88E2109F9 for ; Sat, 17 Mar 2007 15:45:02 -0400 (EDT) Message-ID: <45FC453D.9070504@incunabulum.net> Date: Sat, 17 Mar 2007 19:45:01 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: MFCing rev 1.96 of netinet/in.c for Zeroconf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 19:45:03 -0000 The change itself is very simple; http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=1.95&r2=1.96 This change is necessary before IPv4 address scope and source selection policy may be implemented. Does anyone see any potential problems with this? It is possible that there are people out there forwarding between LANs with 169.254.0.0/16 subnetted on different interfaces, though this is not RFC compliant behaviour, so I'd like to hear about that before I merge it. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 20:05:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6B6F16A402 for ; Sat, 17 Mar 2007 20:05:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id 49FD213C457 for ; Sat, 17 Mar 2007 20:05:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.40.197] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1HSf9a0dPd-0007YT; Sat, 17 Mar 2007 21:05:26 +0100 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Sat, 17 Mar 2007 21:05:18 +0100 User-Agent: KMail/1.9.5 References: <826528.78192.qm@web58011.mail.re3.yahoo.com> In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2563207.Mo3N9oYVhS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703172105.25345.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/kQ1KgeBWiX9chI9IRXH2+g6iF2O7hfZbkASC /nM+vg5zYdFyVC9rQ9/GbH4IZ9QZer0I1+1hwWqVDXDntvS/of 4ogJBJah5ixxOyo8/uS5Q== Cc: Andrew Pantyukhin , "manuel.ochoa@yahoo.com" Subject: Re: Wireshark X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 20:05:28 -0000 --nextPart2563207.Mo3N9oYVhS Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 17 March 2007 20:30, Andrew Pantyukhin wrote: > On 3/17/07, manuel.ochoa@yahoo.com wrote: > > Can someone please explain the difference between Wireshark > > and Wireshark-lite. I would like to install a packet sniffer > > on my FreeBSD box for CLI only. > > lite =3D cli only That's not correct. See my previous email. =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 --nextPart2563207.Mo3N9oYVhS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF/EoFXyyEoT62BG0RAlDCAJ0bj4qVGiPw/6A/knWY+MICrK7U0ACfb2kl qck7SOMPvD6E6WouBPT2VOc= =bMAA -----END PGP SIGNATURE----- --nextPart2563207.Mo3N9oYVhS-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 20:18:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7750016A402 for ; Sat, 17 Mar 2007 20:18:58 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.freebsd.org (Postfix) with ESMTP id 30D4013C489 for ; Sat, 17 Mar 2007 20:18:58 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so842336wxc for ; Sat, 17 Mar 2007 13:18:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=seVs+CoVHA8VScA2NZOFUwpB/bM+YRxTeeFFOrxGugHJN6vHvL6Hk74RG8zhRzXNIZ9TZV7K9ZZUKEOm8z7sripkZ+3a/EvhlRkdcHKFKVRLBMbUwdVVdsq3NVdENXd160oE5V5s++Ada9+yrRvw6E1ITSdz5UHEgp6GuRKg6O8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=hZqt3az45dX9xe978+Fm8bD+GSDGABcwfENw0gTP9CevIkDD3uPFC959VmuUjIJNzgz6+m0aShi/gO/QPdEXIRyrgXHbpEC/M4CaVljb8HUSr4Ji82K7vDN7TeyPAHJAy4J81OaOO8zlCmCGAqoiDW209Aj6CKk0vDNj7CRqVTU= Received: by 10.70.129.4 with SMTP id b4mr5602759wxd.1174162737323; Sat, 17 Mar 2007 13:18:57 -0700 (PDT) Received: by 10.114.201.2 with HTTP; Sat, 17 Mar 2007 13:18:57 -0700 (PDT) Message-ID: Date: Sat, 17 Mar 2007 23:18:57 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Max Laier" In-Reply-To: <200703172105.25345.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <826528.78192.qm@web58011.mail.re3.yahoo.com> <200703172105.25345.max@love2party.net> X-Google-Sender-Auth: aa24cacc97cf3162 Cc: freebsd-net@freebsd.org, "manuel.ochoa@yahoo.com" Subject: Re: Wireshark X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 20:18:58 -0000 On 3/17/07, Max Laier wrote: > On Saturday 17 March 2007 20:30, Andrew Pantyukhin wrote: > > On 3/17/07, manuel.ochoa@yahoo.com wrote: > > > Can someone please explain the difference between Wireshark > > > and Wireshark-lite. I would like to install a packet sniffer > > > on my FreeBSD box for CLI only. > > > > lite = cli only > > That's not correct. See my previous email. Yep, sorry. From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 22:11:55 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D48D616A400 for ; Sat, 17 Mar 2007 22:11:55 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from rock.polstra.com (rock.polstra.com [64.119.0.113]) by mx1.freebsd.org (Postfix) with ESMTP id B1FCC13C459 for ; Sat, 17 Mar 2007 22:11:55 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from [10.0.0.64] (adsl-sj-14-253.rockisland.net [64.119.14.253]) (authenticated bits=0) by rock.polstra.com (8.13.8/8.13.8) with ESMTP id l2HMBbQI068069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Mar 2007 15:11:39 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: <45FC6799.2030101@polstra.com> Date: Sat, 17 Mar 2007 15:11:37 -0700 From: John Polstra User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Aniruddha Bohra References: <45FA98DD.3080205@cs.rutgers.edu> In-Reply-To: <45FA98DD.3080205@cs.rutgers.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (rock.polstra.com [64.119.0.113]); Sat, 17 Mar 2007 15:11:39 -0700 (PDT) Cc: freebsd-net@freebsd.org Subject: Re: ether_input question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 22:11:55 -0000 Aniruddha Bohra wrote: > Hi, > In two drivers, fxp and em, the assumptions about entering the > ether_input routine are different. > From em_rxeof: > > #ifdef DEVICE_POLLING > EM_UNLOCK() > (*ifp->if_input)() > EM_UNLOCK() > #else > (*ifp->if_input)() > #endif > > While in fxp: > > FXP_UNLOCK() > (*ifp->if_input)() > FXP_LOCK() > > > My question is : > Does ether_input() assume it is the only thread executing the code? If > it is the case, what is the > reason for dropping the lock in the DEVICE_POLLING case? There is actually no difference between these cases. In the !DEVICE_POLLING case, the em driver does not hold its driver lock when it calls em_rxeof. The call is made from em_handle_rxtx, where you'll see that the driver has not acquired a lock when it calls em_rxeof. Thus, in all cases the if_input function is called without holding the driver lock. John From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 23:50:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4789016A402 for ; Sat, 17 Mar 2007 23:50:11 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with SMTP id EA11013C4CC for ; Sat, 17 Mar 2007 23:50:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 8101 invoked by uid 399); 17 Mar 2007 23:50:09 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 17 Mar 2007 23:50:09 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45FC7EAE.803@FreeBSD.org> Date: Sat, 17 Mar 2007 16:50:06 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Mark Andrews References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> In-Reply-To: <200703171210.l2HCAD63046801@drugs.dv.isc.org> Content-Type: multipart/mixed; boundary="------------090805060704060603060007" Cc: freebsd-net@freebsd.org, freebsd-rc@freebsd.org Subject: Re: rc.order wrong (ipfw) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 23:50:11 -0000 This is a multi-part message in MIME format. --------------090805060704060603060007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [ Re-locating this thread from -stable. ] Mark Andrews wrote: >> On Saturday 17 March 2007 03:58, Mark Andrews wrote: >> >>>>> nothing goes to this machine because by default everything is blocked >>>>> until >>>>> >>>>> you permit it >>>> You're absolutely correct, however your original post seems to have >>>> taken many of us by surprise, causing some of us (at least me!) to >>>> assume that you've changed the default method to allow. I'm obviously >>>> misunderstanding, so I apologise for that, but I hope you can see the >>>> reasoning behind my comments with what I knew at the time. :) >>> ipfw needs to be before networking or router discovery >>> fails for IPv6. >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/108589 >>> >> >> as default any network connection will fail so long as you do not permit it >> >> If rtsol fails or is called to early it is an rtsol problem and not an ipfw >> problem I guess >> >> named and ipfw before netif? > > ip6fw is before networking. ipfw is supposed to be taking > over from ip6fw. ipfw and ip6wf should be started at a > similar time. > > rtsol is approximately the equivalent to DHCP. The machine is > requesting a address from the network. It doesn't matter if > it is a router or a DHCP server that is suppling the address. > > DHCP only works because it bypasses the firefall. Mark, Currently the order (with some non-networking items removed) is: /etc/rc.d/ipfilter /etc/rc.d/ipnat /etc/rc.d/ipfs /etc/rc.d/sppp /etc/rc.d/auto_linklocal /etc/rc.d/pccard /etc/rc.d/netif /etc/rc.d/ip6addrctl /etc/rc.d/atm2 /etc/rc.d/pfsync /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/isdnd /etc/rc.d/ppp /etc/rc.d/routing /etc/rc.d/ip6fw /etc/rc.d/network_ipv6 /etc/rc.d/ipsec /etc/rc.d/ipfw /etc/rc.d/nsswitch /etc/rc.d/mroute6d /etc/rc.d/route6d /etc/rc.d/mrouted /etc/rc.d/routed /etc/rc.d/NETWORKING ipfilter starts very early in the "late" section of rcorder, it requires mountcritlocal (the default early_late_divider) and has a BEFORE: netif. Currently ip6fw actually starts after routing (and therefore after netif). Before we move it I think someone who knows more about how rtsol works than I do should comment. AFAICT, network_ipv6 is going to need routing up. If ip6fw's functionality is going to be subsumed into ipfw, then changing ipfw to run before netif now, and nuking ip6fw later is probably sufficient. If it's reasonable to conclude that we want all the firewalls to start before netif, I see two ways to accomplish that. One would be to have netif REQUIRE ipfilter, pf, and ipfw. In some ways I think this is cleaner, but netif already has a pretty long REQUIRE line. The other way would be to add a new FIREWALLS placeholder for the REQUIREs I'm suggesting above, and then have netif REQUIRE that. If on the other hand, there is some reason NOT to start all the firewalls before netif, then things get more complicated. :) The attached patch changes the rcorder to the following: /etc/rc.d/sppp /etc/rc.d/ipfw /etc/rc.d/pfsync /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/ipfilter /etc/rc.d/ipnat /etc/rc.d/ipfs /etc/rc.d/auto_linklocal /etc/rc.d/serial /etc/rc.d/netif /etc/rc.d/ip6addrctl /etc/rc.d/atm2 /etc/rc.d/isdnd /etc/rc.d/ppp /etc/rc.d/routing /etc/rc.d/ip6fw /etc/rc.d/network_ipv6 /etc/rc.d/ipsec /etc/rc.d/nsswitch /etc/rc.d/mroute6d /etc/rc.d/route6d /etc/rc.d/mrouted /etc/rc.d/routed /etc/rc.d/NETWORKING Thoughts? Doug -- This .signature sanitized for your protection --------------090805060704060603060007 Content-Type: text/plain; name="rc-firewalls.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc-firewalls.diff" Index: ip6fw =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.d/ip6fw,v retrieving revision 1.8 diff -u -r1.8 ip6fw --- ip6fw 31 Dec 2006 10:37:18 -0000 1.8 +++ ip6fw 17 Mar 2007 21:28:18 -0000 @@ -5,7 +5,6 @@ # PROVIDE: ip6fw # REQUIRE: routing -# BEFORE: network_ipv6 # KEYWORD: nojail . /etc/rc.subr Index: ipfilter =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.d/ipfilter,v retrieving revision 1.26 diff -u -r1.26 ipfilter --- ipfilter 31 Dec 2006 10:37:18 -0000 1.26 +++ ipfilter 17 Mar 2007 21:15:21 -0000 @@ -6,7 +6,6 @@ # PROVIDE: ipfilter # REQUIRE: root mountcritlocal -# BEFORE: netif # KEYWORD: nojail . /etc/rc.subr Index: ipfs =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.d/ipfs,v retrieving revision 1.6 diff -u -r1.6 ipfs --- ipfs 7 Oct 2004 13:55:26 -0000 1.6 +++ ipfs 17 Mar 2007 21:15:43 -0000 @@ -6,7 +6,6 @@ # PROVIDE: ipfs # REQUIRE: ipnat -# BEFORE: netif # KEYWORD: nojail shutdown . /etc/rc.subr Index: ipfw =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.d/ipfw,v retrieving revision 1.14 diff -u -r1.14 ipfw --- ipfw 31 Dec 2006 10:37:18 -0000 1.14 +++ ipfw 17 Mar 2007 21:31:21 -0000 @@ -4,8 +4,7 @@ # # PROVIDE: ipfw -# REQUIRE: ppp -# BEFORE: NETWORKING +# REQUIRE: root mountcritlocal # KEYWORD: nojail . /etc/rc.subr Index: ipnat =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.d/ipnat,v retrieving revision 1.15 diff -u -r1.15 ipnat --- ipnat 31 Dec 2006 10:37:18 -0000 1.15 +++ ipnat 17 Mar 2007 21:15:29 -0000 @@ -6,7 +6,6 @@ # PROVIDE: ipnat # REQUIRE: ipfilter -# BEFORE: DAEMON netif # KEYWORD: nojail . /etc/rc.subr Index: netif =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.d/netif,v retrieving revision 1.22 diff -u -r1.22 netif --- netif 9 Feb 2007 12:11:26 -0000 1.22 +++ netif 17 Mar 2007 23:04:21 -0000 @@ -26,7 +26,8 @@ # # PROVIDE: netif -# REQUIRE: atm1 ipfilter mountcritlocal serial sppp sysctl +# REQUIRE: atm1 mountcritlocal serial sppp sysctl +# REQUIRE: ipfilter ipfs pf ipfw # KEYWORD: nojail . /etc/rc.subr Index: network_ipv6 =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.d/network_ipv6,v retrieving revision 1.37 diff -u -r1.37 network_ipv6 --- network_ipv6 7 Oct 2004 13:55:26 -0000 1.37 +++ network_ipv6 17 Mar 2007 21:20:18 -0000 @@ -29,7 +29,7 @@ # # PROVIDE: network_ipv6 -# REQUIRE: routing +# REQUIRE: routing ip6fw # KEYWORD: nojail . /etc/rc.subr Index: pf =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.d/pf,v retrieving revision 1.14 diff -u -r1.14 pf --- pf 31 Dec 2006 10:37:18 -0000 1.14 +++ pf 17 Mar 2007 21:18:13 -0000 @@ -4,8 +4,7 @@ # # PROVIDE: pf -# REQUIRE: root mountcritlocal netif pflog pfsync -# BEFORE: routing +# REQUIRE: root mountcritlocal pflog pfsync # KEYWORD: nojail . /etc/rc.subr Index: pflog =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.d/pflog,v retrieving revision 1.10 diff -u -r1.10 pflog --- pflog 31 Dec 2006 10:37:18 -0000 1.10 +++ pflog 17 Mar 2007 21:18:21 -0000 @@ -4,7 +4,7 @@ # # PROVIDE: pflog -# REQUIRE: root mountcritlocal netif cleanvar +# REQUIRE: root mountcritlocal cleanvar # KEYWORD: nojail . /etc/rc.subr Index: pfsync =================================================================== RCS file: /usr/local/ncvs/src/etc/rc.d/pfsync,v retrieving revision 1.2 diff -u -r1.2 pfsync --- pfsync 31 Dec 2006 10:37:18 -0000 1.2 +++ pfsync 17 Mar 2007 21:18:33 -0000 @@ -4,7 +4,7 @@ # # PROVIDE: pfsync -# REQUIRE: root mountcritlocal netif +# REQUIRE: root mountcritlocal # KEYWORD: nojail . /etc/rc.subr --------------090805060704060603060007--