From owner-freebsd-net@FreeBSD.ORG Sun Mar 18 00:28: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 971CD16A401 for ; Sun, 18 Mar 2007 00:28:04 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 54C1813C45A for ; Sun, 18 Mar 2007 00:28:04 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so874411wxc for ; Sat, 17 Mar 2007 17:28:03 -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=R4hrNtM2knCUtbdbd8PH8VvuZN9mMPFOGn7fZDfewZegAy92/la/FEjoVYFySp9TdcsaxflrONDpErrd7QrjymKjqUXkAiFdXP84HYgR+9DeCrFU4c4qg6YLcA/4w+78T/J9OWuIXJKnlP2PgFs1SLcIaPzzP63UpqGydKNz/tw= 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=Xm7aQkq07O8QlsBqdPN13fwPjSrZ3Kj89lZzNEZKpqaNMJUTbYoxdyvAPF7zaCHIF+Y1HZ1cd50AeYJl6qbBv/KFi7Ql9UQBil8ow28lLsuJUQ8nUb/+l/xfM3OKhMXR5mW01WlEGnGw0JOW1JzO2gagKF0urePUynJd+RJJMjM= Received: by 10.90.33.16 with SMTP id g16mr3025708agg.1174177683727; Sat, 17 Mar 2007 17:28:03 -0700 (PDT) Received: by 10.90.25.1 with HTTP; Sat, 17 Mar 2007 17:28:03 -0700 (PDT) Message-ID: Date: Sat, 17 Mar 2007 17:28:03 -0700 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20070316141836.J60288@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45FA98DD.3080205@cs.rutgers.edu> <20070316141836.J60288@fledge.watson.org> Cc: freebsd-net@freebsd.org, Aniruddha Bohra 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: Sun, 18 Mar 2007 00:28:04 -0000 > 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. Just to further clarify the corollary to this statement - drivers that separately lock their softc, tx, and rx queues don't need to drop the lock across if_input as there is no possibility of lock order reversal between the input and the output path. -Kip From owner-freebsd-net@FreeBSD.ORG Sun Mar 18 01:31:48 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 0191416A400 for ; Sun, 18 Mar 2007 01:31:48 +0000 (UTC) (envelope-from kian.mohageri@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8BBDC13C455 for ; Sun, 18 Mar 2007 01:31:47 +0000 (UTC) (envelope-from kian.mohageri@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so1006036ugh for ; Sat, 17 Mar 2007 18:31:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jHDTobsw7KCjnUj2tHIPFBcvECWUSGa7/5+fzSGx9AKmGQBSDpTAdzoKPkSFKGjSfaZeuvK/rsFgub4OksclHQ/1cUaPE8/uBbHqAW13U/p/nI/wSW8UHTMu4KExlqGtiFTLGl5S2zAndrywpyWnR/xivzwjLEVGgyOXtmyG5oQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ZApIbLyshT+Gc1azcPHBptwytD1sPDzIEF6fcBrH7NCh7F72Ecw7n7XGijA7T1Mu87PHTP2ztxYDnk4fvGmlDy9wg7ZfWLPlBjbJ3TqrvW4R4nUt3RtmjDrbhUvLCHgbXic0JDhvF/ziAcOoPTxxC0odKiNrYTL3ZLQkSRk0aNo= Received: by 10.65.137.5 with SMTP id p5mr4723729qbn.1174180065798; Sat, 17 Mar 2007 18:07:45 -0700 (PDT) Received: from ?10.0.1.8? ( [65.102.150.189]) by mx.google.com with ESMTP id 23sm5308672nzn.2007.03.17.18.07.43; Sat, 17 Mar 2007 18:07:44 -0700 (PDT) Message-ID: <45FC90CE.3020605@gmail.com> Date: Sat, 17 Mar 2007 18:07:26 -0700 From: Kian Mohageri User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Doug Barton References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> In-Reply-To: <45FC7EAE.803@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Andrews , 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: Sun, 18 Mar 2007 01:31:48 -0000 Doug Barton wrote: > > 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. :) > > I definitely think that firewalls should be started as early as possible, for obvious reasons. I can't speak for ipfw, but removing the REQUIRE: netif for pf might break some setups where the ruleset references a cloned interface that netif creates. Correct me if I'm wrong? Loading a minimal ruleset initially (as OpenBSD and NetBSD do) would solve that problem, at least for pf. The idea has been discussed a few times before but I didn't see it go anywhere. http://lists.freebsd.org/pipermail/freebsd-pf/2007-February/003041.html I'd love to see the rcorder for the firewalls get worked out! :) Kian From owner-freebsd-net@FreeBSD.ORG Sun Mar 18 05:17: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 BFBE416A400 for ; Sun, 18 Mar 2007 05:17: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 78F7613C43E for ; Sun, 18 Mar 2007 05:17: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 1HSnla-000MTV-2L; Sun, 18 Mar 2007 08:17:14 +0300 Date: Sun, 18 Mar 2007 08:17:09 +0300 From: Eygene Ryabinkin To: Julian Elischer Message-ID: <20070318051709.GE82045@codelabs.ru> References: <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> <20070317192254.GB82045@codelabs.ru> <45FCC115.1020408@elischer.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <45FCC115.1020408@elischer.org> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-net@freebsd.org, rik@inse.ru 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: Sun, 18 Mar 2007 05:17:17 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Julian, good day. > >+.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 > > prepated to ? > prepared for? ??? You're right, thanks for spotting the error. The corrected patch is attached. -- Eygene --Fba/0zbH8Xs+Fj9o 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 Sun Mar 18 08:13:53 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 prepared for 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 --Fba/0zbH8Xs+Fj9o-- From owner-freebsd-net@FreeBSD.ORG Sun Mar 18 10:23: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 9A09616A402 for ; Sun, 18 Mar 2007 10:23:32 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2D72413C448 for ; Sun, 18 Mar 2007 10:23:31 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l2I9WgsK003500 for ; Sun, 18 Mar 2007 10:32:42 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l2I9WgkY030189 for ; Sun, 18 Mar 2007 10:32:42 +0100 Received: (from localhost) by curry.mchp.siemens.de (8.13.8/8.13.8) id l2I9WgUG045250; Date: Sun, 18 Mar 2007 10:32:41 +0100 From: Andre Albsmeier To: freebsd-net@freebsd.org Message-ID: <20070318093241.GA1657@curry.mchp.siemens.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Andre.Albsmeier@siemens.com Subject: 6.2-STABLE: enc0 sees only outgoing packets in 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: Sun, 18 Mar 2007 10:23:32 -0000 (This is FreeBSD 6.2-STABLE as of yesterday using pf and FAST_IPSEC.) Yesterday I started to play around with enc0 in pf. I hoped I could now control IPSEC traffic in the standard way with pf rules but it seems that only outgoing packets hit enc0. I added a pass quick log on enc0 all on top of all pf rules. When sending a single ping packet to the remote side everything works but the only thing I see is Mar 18 10:20:11 gate pflogd: @0 pass out enc0 ICMP 192.168.164.81 -> 10.0.1.32 8 (echo) (192.168.164.81 is my local gif0 address and 10.0.1.32 the remote). However, when running a tcpdump on enc0 we see the answer as well: listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 1550 bytes 10:20:11.475041 (authentic,confidential): SPI 0x50521518: IP A.B.C.D > E.F.G.H: IP 192.168.164.81 > 10.0.1.32: ICMP echo request, id 3631, seq 0, length 64 (ipip-proto-4) 10:20:11.560430 (authentic,confidential): SPI 0x0cf2344e: IP E.F.G.H > A.B.C.D: IP 10.0.1.32 > 192.168.164.81: ICMP echo reply, id 3631, seq 0, length 64 (ipip-proto-4) (A.B.C.D is my local gif0 tunnel endpoint and E.F.G.H the remote). Just to make things clear: IPSEC works (as it did for years), I'm just not able to control the incoming packets with enc0 in pf. Any ideas? Thanks, -Andre From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 00:13: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 1741116A404 for ; Mon, 19 Mar 2007 00:13:59 +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 C09C413C44C for ; Mon, 19 Mar 2007 00:13:58 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 16264 invoked by uid 399); 19 Mar 2007 00:13:58 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 19 Mar 2007 00:13:58 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45FDD5C3.1070305@FreeBSD.org> Date: Sun, 18 Mar 2007 17:13:55 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Kian Mohageri References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> <45FC90CE.3020605@gmail.com> In-Reply-To: <45FC90CE.3020605@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Andrews , 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: Mon, 19 Mar 2007 00:13:59 -0000 Kian Mohageri wrote: > I can't speak for ipfw, but removing the > REQUIRE: netif for pf might break some setups where the ruleset > references a cloned interface that netif creates. Correct me if I'm wrong? > > Loading a minimal ruleset initially (as OpenBSD and NetBSD do) would > solve that problem, at least for pf. The idea has been discussed a few > times before but I didn't see it go anywhere. That's because no one who uses pf (and therefore cares sufficiently about the issue) has stepped up to do the work. Q.E.D. I don't know pf from a hole in the ground, and I'm not going to develop and commit a fundamentally different way of doing things for it that I can't test, and therefore will have no confidence that it's been done correctly. That said, if the issues of needing to resolve hostnames and set up rules for cloned interfaces are a universal problem (and it seems that they are) then perhaps rather than customizing a solution for pf it might be worthwhile to have a more generic "firewalls_late" script that performs the appropriate actions regardless of what firewalls are enabled. That way we could add just one rc.d script, and using the new functionality would be opt-in. Off the top of my head I envision something like: if [ checkyesno $firewall_enable -a -n "$firewall_rules_late" ]; then # do stuff specific to ipfw fi if [ checkyesno $ipfilter_enable -a -n "$ipfilter_rules_late" ]; then ... Comments? That's something that I would feel comfortable developing and committing, since it would be opt-in, and others more knowledgeable than I could jump in and run with it for a while before we considered MFC'ing it (if doing that would be appropriate at all, and I'm not sure that it would be). OTOH, perhaps if we just move everything (and therefore break things in the manner you described) it will motivate someone to do the work. :) Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 00:58: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 6E53C16A408 for ; Mon, 19 Mar 2007 00:58:19 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.freebsd.org (Postfix) with ESMTP id 0E12713C484 for ; Mon, 19 Mar 2007 00:58:18 +0000 (UTC) (envelope-from ghelmer@palisadesys.com) Received: from [192.168.0.100] (71-214-233-15.desm.qwest.net [71.214.233.15]) (authenticated bits=0) by magellan.palisadesys.com (8.13.8/8.13.8) with ESMTP id l2J0lvKR082180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Mar 2007 19:47:59 -0500 (CDT) (envelope-from ghelmer@palisadesys.com) Message-ID: <45FDDDC0.70102@palisadesys.com> Date: Sun, 18 Mar 2007 19:48:00 -0500 From: Guy Helmer User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Max Laier References: <826528.78192.qm@web58011.mail.re3.yahoo.com> <200703172005.12027.max@love2party.net> In-Reply-To: <200703172005.12027.max@love2party.net> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (magellan.palisadesys.com [192.188.162.211]); Sun, 18 Mar 2007 19:48:00 -0500 (CDT) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-3.688, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, HTML_40_50 0.50, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.21) X-Palisade-MailScanner-From: ghelmer@palisadesys.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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: Mon, 19 Mar 2007 00:58:19 -0000 Max Laier wrote: > 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 > the -lite version with "WITHOUT_X11" defined will get you the > cli-version. "-lite" seems to just disable a couple of dissectors that > have a lot of external dependencies. > > I like the tshark-lite port myself to get the protocol decoders in CLI (text) mode... Guy -- Guy Helmer, Ph.D. Chief System Architect Palisade Systems, Inc. From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 02:17: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 1E7E916A400 for ; Mon, 19 Mar 2007 02:17:08 +0000 (UTC) (envelope-from kian.mohageri@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 C143613C46A for ; Mon, 19 Mar 2007 02:17:07 +0000 (UTC) (envelope-from kian.mohageri@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1076102wxc for ; Sun, 18 Mar 2007 19:17:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=svjNtEdiOgDNyGEfO50+dcTNSX6OMlwwhD9LMzOXJ2OJrEoYebB5mRDmxD9Jz+va2ZBe7ykjCeyyTABgZXaBjMBozxSKEvAukaS1JvnFN5U5wv0n5R7WoUJuJmhHt5CtVLAXf06U+Is0PhRgL+vvPi4Q0ARbDJPa+XUwt3/X550= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GAK4XKU6FquMYkZQYYhqG007oqBUKymnw4r0wQditRkWJhEP8hvlpcHYBw549jD9rZLIgpte0dzUGOIHjjRPIffLDi0SIG83/0T5mJyRwjbAft5Zz2WWgDtHu/7SCfa2v3Q0GWf/+yJ8N0exJMCWwXGJPUNabx5NUmRRQilIB5A= Received: by 10.70.66.18 with SMTP id o18mr7609735wxa.1174270627007; Sun, 18 Mar 2007 19:17:07 -0700 (PDT) Received: from ?10.1.1.53? ( [71.227.220.29]) by mx.google.com with ESMTP id h20sm8008088wxd.2007.03.18.19.17.04; Sun, 18 Mar 2007 19:17:05 -0700 (PDT) Message-ID: <45FDF284.3040008@gmail.com> Date: Sun, 18 Mar 2007 19:16:36 -0700 From: Kian Mohageri User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Doug Barton References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> <45FC90CE.3020605@gmail.com> <45FDD5C3.1070305@FreeBSD.org> In-Reply-To: <45FDD5C3.1070305@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Andrews , 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: Mon, 19 Mar 2007 02:17:08 -0000 Doug Barton wrote: > That said, if the issues of needing to resolve hostnames and set up > rules for cloned interfaces are a universal problem (and it seems that > they are) then perhaps rather than customizing a solution for pf it > might be worthwhile to have a more generic "firewalls_late" script that > performs the appropriate actions regardless of what firewalls are > enabled. That way we could add just one rc.d script, and using the new > functionality would be opt-in. Off the top of my head I envision > something like: > > if [ checkyesno $firewall_enable -a -n "$firewall_rules_late" ]; then > # do stuff specific to ipfw > fi > if [ checkyesno $ipfilter_enable -a -n "$ipfilter_rules_late" ]; then > ... I agree VERY MUCH with this sort of approach. It would be a much cleaner solution than completely separate handling of all of these different problems. I'm trying to get an idea of what all of the major problems with the current order are, and these are the ones I'm aware of: - ipfw blocks by default (names unresolvable, rtsol breaks) - ipf/pf pass by default (services are unprotected) I think a firewall_boot script (similar to what you've proposed) could potentially solve all of these problems. If the user chose to enable it, it would do something like this: - load modules for pf/ipfw/ipf (whichever are enabled in rc.conf) - load firewall-specific minimal rulesets for enabled firewall(s) It would start BEFORE routing/netif, protecting services, but it would allow things like rtsol and name resolution to work. To elaborate a bit on your ideas, firewall_boot might do something like this: ... if [ checkyesno $firewall_enable -a -f $firewall_boot_script ]; # load ipfw and minimal ruleset if [ checkyesno $pf_enable -a -f $pf_boot_rules ]; # pf and minimal ruleset if [ checkyesno $ipfilter_enable -a -f $ipfilter_boot_rules ]; # ipfilter and minimal ruleset ... The tiny default boot rulesets would be in /etc/defaults/ and of course the user could override the location if they wanted to use their own early ruleset. The actual firewall scripts could then come up after the network, so cloned interfaces have been created, names can be resolved, etc. and the real rulesets should load without any problems. Does that sound reasonable? -Kian From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 04:39: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 14B0316A401 for ; Mon, 19 Mar 2007 04:39:08 +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 C169E13C480 for ; Mon, 19 Mar 2007 04:39:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 30862 invoked by uid 399); 19 Mar 2007 04:39:05 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 19 Mar 2007 04:39:05 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45FE13E5.9060902@FreeBSD.org> Date: Sun, 18 Mar 2007 21:39:01 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Kian Mohageri References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> <45FC90CE.3020605@gmail.com> <45FDD5C3.1070305@FreeBSD.org> <45FDF284.3040008@gmail.com> In-Reply-To: <45FDF284.3040008@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Andrews , 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: Mon, 19 Mar 2007 04:39:08 -0000 Kian Mohageri wrote: > I agree VERY MUCH with this sort of approach. It would be a much > cleaner solution than completely separate handling of all of these > different problems. I'm trying to get an idea of what all of the major > problems with the current order are, and these are the ones I'm aware of: > > - ipfw blocks by default (names unresolvable, rtsol breaks) > - ipf/pf pass by default (services are unprotected) > > I think a firewall_boot script (similar to what you've proposed) could > potentially solve all of these problems. I'm glad that you like the idea in principal, however I'm sorry to say that I don't see eye to eye with your suggestion of modifying the early behavior instead of the late behavior. I believe (for whatever that's worth) that firewalls (and firewall rules) _should_ be loaded prior to the interfaces coming up. If someone wants to have dynamic rules, rules that rely on name resolution, or rules for non-physical (e.g., cloned) interfaces, that's fine, but IMO those are the exception, not the rule. Furthermore (and I'm betraying a prejudice here) I think that firewall rules that rely on name resolution are absolutely nuts, and I say that with many years of experience as a professional DNS and system administrator. Therefore I believe strongly that the default behavior should be changed to load all firewalls (and rules) before netif, and that those who want to do firewall-related things that require netif or routing to be up should be the ones who have to opt in to the new script. That said, I think you and I have expressed our opinions pretty clearly on these points, so I'd suggest that we let someone else have a turn. Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 06:44:49 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 0FF9616A403 for ; Mon, 19 Mar 2007 06:44:49 +0000 (UTC) (envelope-from mmakonnen@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by mx1.freebsd.org (Postfix) with ESMTP id ABA1513C4C5 for ; Mon, 19 Mar 2007 06:44:48 +0000 (UTC) (envelope-from mmakonnen@gmail.com) Received: by wr-out-0506.google.com with SMTP id 36so1258693wra for ; Sun, 18 Mar 2007 23:44:48 -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=aE1CQHrRQhaalMYpJLGf+qxeCug3QNsAP47OYghl30jzt9ssrsXjYJhOUP7LPelyNdG1aJRCcAmZaj90TzoAUaw5dS4G5/+GUn/FgNWLaFmgLGIjnSM0+ql7xQ/eRYC+rYVW+UOiOdsHiVItEuEv20avrA3f5VMm0HzcaUOXaPY= 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=pE2DpvW82QrADYJVxcFPmjMYbUnckL3f8ED100199D90ocfvarbgEZ+0t3HGRise2OMFraMrMnHAjnwPAVuRUcqphFG+NvIDIvJlDY4WtP2qiy2Uxv+7/kCltH6K8+lQyzhmaO+ftTnhqgIx8p+8bmAAsrX74PO3M0FFYoe3Zq8= Received: by 10.65.151.6 with SMTP id d6mr6999503qbo.1174285116779; Sun, 18 Mar 2007 23:18:36 -0700 (PDT) Received: by 10.114.106.15 with HTTP; Sun, 18 Mar 2007 23:18:36 -0700 (PDT) Message-ID: <584bfc3f0703182318v31f8f5d0lee04af618809b3ef@mail.gmail.com> Date: Mon, 19 Mar 2007 09:18:36 +0300 From: "Mike Telahun Makonnen" To: "Doug Barton" In-Reply-To: <45FE13E5.9060902@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> <45FC90CE.3020605@gmail.com> <45FDD5C3.1070305@FreeBSD.org> <45FDF284.3040008@gmail.com> <45FE13E5.9060902@FreeBSD.org> 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: Mon, 19 Mar 2007 06:44:49 -0000 Hi guys, Long time no see :P I don't have anything to say directly about this issue (other than that I'm leaning towards Doug's reasoning on this) but I'm working on a patch to integrate IPv6 handling into rc.d/netif, which might indirectly have a bearing on this discussion. I'm currently testing the patch. I'll post it to the list as soon as I'm fairly certain it doesn't break anything too much. In my patch, IPv6 is configured in rc.d/netif right after IPv4. In general terms it goes something like this: o General net configuration (cloning, renaming, etc) o General pre-IPv6 configuration o Get list of all interfaces o For each interface: - Configure IPv4 - Configure IPv6 - Static configuration - rtsol - aliases o General post-IPv6 configuration I think that up until now the separation of general interface configuration and IPv6 configuration has complicated the ordering of routing and firewall scripts. Hopefully, the patch will remove some of those complications. I'll get back to you with the patch in the next couple of days. Cheers, Mike. On 3/19/07, Doug Barton wrote: > Kian Mohageri wrote: > > > I agree VERY MUCH with this sort of approach. It would be a much > > cleaner solution than completely separate handling of all of these > > different problems. I'm trying to get an idea of what all of the major > > problems with the current order are, and these are the ones I'm aware of: > > > > - ipfw blocks by default (names unresolvable, rtsol breaks) > > - ipf/pf pass by default (services are unprotected) > > > > I think a firewall_boot script (similar to what you've proposed) could > > potentially solve all of these problems. > > I'm glad that you like the idea in principal, however I'm sorry to say > that I don't see eye to eye with your suggestion of modifying the > early behavior instead of the late behavior. > > I believe (for whatever that's worth) that firewalls (and firewall > rules) _should_ be loaded prior to the interfaces coming up. If > someone wants to have dynamic rules, rules that rely on name > resolution, or rules for non-physical (e.g., cloned) interfaces, > that's fine, but IMO those are the exception, not the rule. > Furthermore (and I'm betraying a prejudice here) I think that firewall > rules that rely on name resolution are absolutely nuts, and I say that > with many years of experience as a professional DNS and system > administrator. > > Therefore I believe strongly that the default behavior should be > changed to load all firewalls (and rules) before netif, and that those > who want to do firewall-related things that require netif or routing > to be up should be the ones who have to opt in to the new script. That > said, I think you and I have expressed our opinions pretty clearly on > these points, so I'd suggest that we let someone else have a turn. > > Doug > > -- > > This .signature sanitized for your protection > _______________________________________________ > freebsd-rc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-rc > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 07:20: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 D5B1416A406 for ; Mon, 19 Mar 2007 07:20:21 +0000 (UTC) (envelope-from kian.mohageri@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE6013C4CC for ; Mon, 19 Mar 2007 07:20:21 +0000 (UTC) (envelope-from kian.mohageri@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1120237wxc for ; Mon, 19 Mar 2007 00:20: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:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qabMT7H9+zRsAaCoAJJ4IcBjVHX87lXaP09r0Z21A45+7fchFfn5eyBPPOf4Mew6oZpXVI4R96Kukjbd2wJoX2nXpJlESCmy6y4fhiEg/cyPuGdXEQBLQ0Hg88Be3iu/WddKVI3J5JvSXGYe1f+yXZBleCInvWLfMG8YKuNSKkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=XP4vEPkxk/51fD4U1oc0NObok3qd4mwvi12sG8Kcb7LnHv1F00aj7dsnEW1k6ds2tw+akon9qk6PqCCkmfPlxU586kWBw+HLkIlApZmB8TvZUNW3X8USEJE8nHeoAvaGWjeHPBgEnMEBG40o/EeXoPhA4MiMTfMe4qZprN6ZSTE= Received: by 10.70.69.2 with SMTP id r2mr7948107wxa.1174288820856; Mon, 19 Mar 2007 00:20:20 -0700 (PDT) Received: from ?10.1.1.53? ( [71.227.220.29]) by mx.google.com with ESMTP id h17sm8380779wxd.2007.03.19.00.20.19; Mon, 19 Mar 2007 00:20:19 -0700 (PDT) Message-ID: <45FE39AE.4070407@gmail.com> Date: Mon, 19 Mar 2007 00:20:14 -0700 From: Kian Mohageri User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Doug Barton References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> <45FC90CE.3020605@gmail.com> <45FDD5C3.1070305@FreeBSD.org> <45FDF284.3040008@gmail.com> <45FE13E5.9060902@FreeBSD.org> In-Reply-To: <45FE13E5.9060902@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Andrews , 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: Mon, 19 Mar 2007 07:20:21 -0000 Doug Barton wrote: > I believe (for whatever that's worth) that firewalls (and firewall > rules) _should_ be loaded prior to the interfaces coming up. If someone > wants to have dynamic rules, rules that rely on name resolution, or > rules for non-physical (e.g., cloned) interfaces, that's fine, but IMO > those are the exception, not the rule. Furthermore (and I'm betraying a > prejudice here) I think that firewall rules that rely on name resolution > are absolutely nuts, and I say that with many years of experience as a > professional DNS and system administrator. > Agreed. FQDNs in a ruleset is a pretty stupid idea. I guess I also agree with the reasoning that changing the common case as little as possible is good. > Therefore I believe strongly that the default behavior should be changed > to load all firewalls (and rules) before netif, and that those who want > to do firewall-related things that require netif or routing to be up > should be the ones who have to opt in to the new script. That said, I > think you and I have expressed our opinions pretty clearly on these > points, so I'd suggest that we let someone else have a turn. After re-reading your original idea, I think I understand a little better what you mean to do. For clarification, are you proposing that the [early] firewall scripts do nothing if firewall_late_enable=YES, and then have all firewalling taken care of later in the boot process (i.e. post-networking) by firewall_late? I think I might have misunderstood your original proposal:) -Kian From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 08:45: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 F293216A401; Mon, 19 Mar 2007 08:45:18 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from mx.isc.org (mx.isc.org [204.152.184.167]) by mx1.freebsd.org (Postfix) with ESMTP id D7D1513C457; Mon, 19 Mar 2007 08:45:18 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id B86AF11401C; Mon, 19 Mar 2007 07:55:54 +0000 (UTC) (envelope-from Mark_Andrews@isc.org) Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (verified OK)) by farside.isc.org (Postfix) with ESMTP id 2293FE60D9; Mon, 19 Mar 2007 07:55:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.8/8.13.8) with ESMTP id l2J7tnIB001548; Mon, 19 Mar 2007 18:55:50 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200703190755.l2J7tnIB001548@drugs.dv.isc.org> To: Doug Barton From: Mark Andrews In-reply-to: Your message of "Sun, 18 Mar 2007 21:39:01 PDT." <45FE13E5.9060902@FreeBSD.org> Date: Mon, 19 Mar 2007 18:55:49 +1100 Sender: Mark_Andrews@isc.org Cc: freebsd-net@FreeBSD.org, Kian Mohageri , 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: Mon, 19 Mar 2007 08:45:19 -0000 > Therefore I believe strongly that the default behavior should be > changed to load all firewalls (and rules) before netif, and that those > who want to do firewall-related things that require netif or routing > to be up should be the ones who have to opt in to the new script. That > said, I think you and I have expressed our opinions pretty clearly on > these points, so I'd suggest that we let someone else have a turn. > > Doug I concur with Doug. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 11:08: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 E0ED216A40E for ; Mon, 19 Mar 2007 11:08:33 +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 CE22F13C45E for ; Mon, 19 Mar 2007 11:08:33 +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 l2JB8Xrl055521 for ; Mon, 19 Mar 2007 11:08:33 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2JB8WW4055515 for freebsd-net@FreeBSD.org; Mon, 19 Mar 2007 11:08:32 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Mar 2007 11:08:32 GMT Message-Id: <200703191108.l2JB8WW4055515@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, 19 Mar 2007 11:08:34 -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/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 6 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 19 11:40: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 E246116A405 for ; Mon, 19 Mar 2007 11:40:33 +0000 (UTC) (envelope-from manuel.ochoa@yahoo.com) Received: from web58004.mail.re3.yahoo.com (web58004.mail.re3.yahoo.com [68.142.236.112]) by mx1.freebsd.org (Postfix) with SMTP id 91ECA13C48C for ; Mon, 19 Mar 2007 11:40:33 +0000 (UTC) (envelope-from manuel.ochoa@yahoo.com) Received: (qmail 1988 invoked by uid 60001); 19 Mar 2007 11:40:33 -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=04BudxCeJ7/rMGuHlAlPm7zRO5UHrsawnMnurUVGANaC26GafCmxCBpp8t7Fa5lRSXfIyXXwR5+oxhrGSOxFOxJ3SVVtI0YZF70fHWEYwOcX3VgEa8L0I9qiDfrgIIQMk0fZ3gqqOFroHUbzp+piuKsu32XD4dKmxPrGJE/HJRM=; X-YMail-OSG: XCowDRwVM1lEtL1cm9HjDh65VGkxcfhl5X3zUczujweTeIY.4e9doKlqTAYHkiPkuFnCkwwQ4lk_fZHgIuHK7flaSQ_6y_w9qQYMrIMndEheH6I2utmuIEUud0VK4SN1euR2tpjGGeuxhd7Qu8oSsWxJpw-- Received: from [131.107.0.102] by web58004.mail.re3.yahoo.com via HTTP; Mon, 19 Mar 2007 04:40:32 PDT X-Mailer: YahooMailRC/471 YahooMailWebService/0.6.132.8 Date: Mon, 19 Mar 2007 04:40:32 -0700 (PDT) From: manuel.ochoa@yahoo.com To: Max Laier , freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <983439.189.qm@web58004.mail.re3.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: 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: Mon, 19 Mar 2007 11:40:34 -0000 Max, correct me if I'm wrong but tcpdump will only give you the headers, is= that correct? This is fine most of the time but sometimes I need to captur= e full frames.=0A=0AThanks =0AManuel Ochoa CCNP MCSA MCSE MCDBA=0A=0A=0A= =0A=0A----- Original Message ----=0AFrom: Max Laier =0A= To: freebsd-net@freebsd.org=0ACc: manuel.ochoa@yahoo.com=0ASent: Saturday, = March 17, 2007 2:05:06 PM=0ASubject: Re: Wireshark=0A=0A=0AOn Saturday 17 M= arch 2007 19:16, manuel.ochoa@yahoo.com wrote:=0A> Can someone please expla= in the difference between Wireshark and=0A> Wireshark-lite. I would like to= install a packet sniffer on my FreeBSD=0A> box for CLI only. Thanks,=0A=0A= What's wrong with tcpdump(8)? Other than that building either the real or = =0Athe -lite version with "WITHOUT_X11" defined will get you the =0Acli-ver= sion. "-lite" seems to just disable a couple of dissectors that =0Ahave a = lot of external dependencies.=0A=0A-- =0A/"\ Best regards, = | mlaier@freebsd.org=0A\ / Max Laier | ICQ = #67774661=0AX http://pf4freebsd.love2party.net/ | mlaier@EFnet=0A/ \ AS= CII Ribbon Campaign | Against HTML Mail and News=0A=0A=0A =0A_= ___________________________________________________________________________= ________=0AExpecting? Get great news right away with email Auto-Check. =0AT= ry the Yahoo! Mail Beta.=0Ahttp://advision.webevents.yahoo.com/mailbeta/new= mail_tools.html From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 12:55: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 3847816A400 for ; Mon, 19 Mar 2007 12:55:04 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by mx1.freebsd.org (Postfix) with ESMTP id 7FDD713C46E for ; Mon, 19 Mar 2007 12:55:03 +0000 (UTC) (envelope-from shteryana@gmail.com) Received: by wr-out-0506.google.com with SMTP id 36so1355923wra for ; Mon, 19 Mar 2007 05:55:02 -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=eCf5MP7xp1LPl9bPx9oATVqel5db9bLyF2shL+yVF3HCQ50Fgq32e+0HJhd8aD65KyYndlmqpNsolTVPZOaF9X4v+8diJ4bRo3YxjZl/AyiknDCng+NjU5tDPJohC/IF9eMTzWNJXQQ8iWLcikmWcscIeYau/WNJPikD8s9iF9w= 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=q1+9aRqIUuq4z+Vl5dArXBYom4hr64mUBZ61ecTiXd6DhyocZHv6PmMnfYD64u4Vg7msJ1ezk6xKY6gFNbeqaUpvLBbLbJqDjc/pNvtg5wam+Dipr9QoNLZSD8rpklUtiTqtuARdFBqw8rUapvUjxCuST8w3OWOGWU+Eg8HPNtU= Received: by 10.90.92.7 with SMTP id p7mr3796881agb.1174307150505; Mon, 19 Mar 2007 05:25:50 -0700 (PDT) Received: by 10.114.56.18 with HTTP; Mon, 19 Mar 2007 05:25:49 -0700 (PDT) Message-ID: <61b573980703190525s30f22648od0ecdecd01879d0c@mail.gmail.com> Date: Mon, 19 Mar 2007 14:25:49 +0200 From: "Shteryana Shopova" To: "manuel.ochoa@yahoo.com" In-Reply-To: <983439.189.qm@web58004.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: <983439.189.qm@web58004.mail.re3.yahoo.com> Cc: Max Laier , freebsd-net@freebsd.org 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: Mon, 19 Mar 2007 12:55:04 -0000 On 3/19/07, manuel.ochoa@yahoo.com wrote: > Max, correct me if I'm wrong but tcpdump will only give you the headers, is that correct? This is fine most of the time but sometimes I need to capture full frames. Nope - that's not correct - #tcpdump -s 0 will capture full frames. Shteryana > > Thanks > Manuel Ochoa CCNP MCSA MCSE MCDBA > > > > > ----- Original Message ---- > From: Max Laier > To: freebsd-net@freebsd.org > Cc: manuel.ochoa@yahoo.com > Sent: Saturday, March 17, 2007 2:05:06 PM > Subject: Re: Wireshark > > > 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 > the -lite version with "WITHOUT_X11" defined will get you the > cli-version. "-lite" seems to just disable a couple of dissectors that > have a lot of external dependencies. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > > > ____________________________________________________________________________________ > Expecting? Get great news right away with email Auto-Check. > Try the Yahoo! Mail Beta. > http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html > _______________________________________________ > 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 19 14:28:56 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 4262216A403 for ; Mon, 19 Mar 2007 14:28:56 +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 1EBEE13C45A for ; Mon, 19 Mar 2007 14:28:56 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 01F15208F33 for ; Mon, 19 Mar 2007 10:28:53 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Mon, 19 Mar 2007 10:28:53 -0400 X-Sasl-enc: pTw941kUq9XDvSfuS6fwPSfmAma5rieBuiTm7mDdIdIM 1174314534 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 304462459E for ; Mon, 19 Mar 2007 10:28:54 -0400 (EDT) Message-ID: <45FE9E24.8010201@incunabulum.net> Date: Mon, 19 Mar 2007 14:28:52 +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: Interface index hack in IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 14:28:56 -0000 Hi, I plan to get rid of the ugly little ip_multicast_if() hack in the IP stack.= Before I do, is anyone actually using this? RFC 3678 specifies a protocol independent API for socket group memberships which allow joins on interfaces referenced by index. This is intended to support IGMPv3 and MLDv2. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 16:03:13 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 DBB0F16A401 for ; Mon, 19 Mar 2007 16:03:13 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 1671313C45D for ; Mon, 19 Mar 2007 16:03:12 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l2JFSbIJ004426; Mon, 19 Mar 2007 22:28:37 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l2JFSbnT004425; Mon, 19 Mar 2007 22:28:37 +0700 (KRAT) (envelope-from eugen) Date: Mon, 19 Mar 2007 22:28:37 +0700 From: Eugene Grosbein To: Bruce M Simpson Message-ID: <20070319152837.GA3984@svzserv.kemerovo.su> References: <45FE9E24.8010201@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45FE9E24.8010201@incunabulum.net> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: Interface index hack in IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 16:03:14 -0000 On Mon, Mar 19, 2007 at 02:28:52PM +0000, Bruce M Simpson wrote: > I plan to get rid of the ugly little ip_multicast_if() hack in the IP > stack.= > Before I do, is anyone actually using this? > > RFC 3678 specifies a protocol independent API for socket group > memberships which allow joins on interfaces referenced by index. This is > intended to support IGMPv3 and MLDv2. I recall that routed and ripd used to utilize something similar long time ago. I'm not sure if they have switched to another API. Eugene From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 16:44: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 E96A816A401; Mon, 19 Mar 2007 16:44:20 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.freebsd.org (Postfix) with ESMTP id AF60213C4C5; Mon, 19 Mar 2007 16:44:20 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.ticketswitch.com) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1HTKjC-0005Dn-Ud; Mon, 19 Mar 2007 16:28:58 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HTKjC-000GQc-No; Mon, 19 Mar 2007 16:28:58 +0000 To: freebsd-net@FreeBSD.org, jkim@FreeBSD.org In-Reply-To: <200703161430.42854.jkim@FreeBSD.org> Message-Id: From: Pete French Date: Mon, 19 Mar 2007 16:28:58 +0000 Cc: freebsd-stable@FreeBSD.org Subject: Re: [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: Mon, 19 Mar 2007 16:44:21 -0000 > I have made bge(4) patch for -STABLE (sorry, not suitable for > RELENG_6_2): What dates stable is this relative to ? I am trying to apply your patch to a cvsup of stable pulled on the day/time you sent your email, but parts of it are failing for me unfortunately. I would like to test this as I have a nmuber of bge interfaces running on some systems. -pete. From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 16:51:32 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 CA1B616A400 for ; Mon, 19 Mar 2007 16:51:32 +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 A540E13C465 for ; Mon, 19 Mar 2007 16:51:32 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 6867E209089; Mon, 19 Mar 2007 12:51:30 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Mon, 19 Mar 2007 12:51:30 -0400 X-Sasl-enc: OkX56kx3dS23KsKYk7jbPbanRHpSnjJhgCjZUZGQH30N 1174323092 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 DED2123F73; Mon, 19 Mar 2007 12:51:31 -0400 (EDT) Message-ID: <45FEBF91.2000709@incunabulum.net> Date: Mon, 19 Mar 2007 16:51:29 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Eugene Grosbein References: <45FE9E24.8010201@incunabulum.net> <20070319152837.GA3984@svzserv.kemerovo.su> In-Reply-To: <20070319152837.GA3984@svzserv.kemerovo.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Interface index hack in IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 16:51:32 -0000 Eugene Grosbein wrote: > > I recall that routed and ripd used to utilize something similar > long time ago. I'm not sure if they have switched to another API. > You're right -- this would break routed on point-to-point interfaces. They didn't, unless it was updated at the upstream, i.e. rhyolite.com. This means that the RFC1724 hack can't be safely deprecated without breaking this use case, until routed is updated to use the RFC 3678 protocol-independent ASM API. Linux uses a slightly different technique to work-around this; ip_mreq is expanded to ip_mreqn internally, and the interface index is explicitly passed around in the kernel. The blocker in the FreeBSD case which prevents us simply adopting this is the source interface selection logic in ip_output(). Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 17:03: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 56FAA16A400 for ; Mon, 19 Mar 2007 17:03:50 +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 E4B4F13C4CE for ; Mon, 19 Mar 2007 17:03:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 30780 invoked by uid 399); 19 Mar 2007 17:03:44 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 19 Mar 2007 17:03:44 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45FEC26E.40504@FreeBSD.org> Date: Mon, 19 Mar 2007 10:03:42 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0b2 (X11/20070116) MIME-Version: 1.0 To: Kian Mohageri References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> <45FC90CE.3020605@gmail.com> <45FDD5C3.1070305@FreeBSD.org> <45FDF284.3040008@gmail.com> <45FE13E5.9060902@FreeBSD.org> <45FE39AE.4070407@gmail.com> In-Reply-To: <45FE39AE.4070407@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Andrews , 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: Mon, 19 Mar 2007 17:03:50 -0000 Kian Mohageri wrote: > After re-reading your original idea, I think I understand a little > better what you mean to do. For clarification, are you proposing that > the [early] firewall scripts do nothing if firewall_late_enable=YES, and > then have all firewalling taken care of later in the boot process (i.e. > post-networking) by firewall_late? > > I think I might have misunderstood your original proposal:) I think so too. :) To be clear, what I'm suggesting is that we move ipfw and pf to a spot in the rcorder that is ahead of netif, along with ipfilter which is already there. I am not suggesting that we change their functionality, just the ordering. As a completely separate thing (although they could be done at the same time) I am suggesting _adding_ a new script for "late" firewall rules (where "late" is defined as after netif) so that people who want to do firewall-related things that require netif (like cloned interfaces, FQDN rules, etc.) will have a standard way to accomplish that. Thanks for the opportunity to clarify, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 17:38: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 378BB16A400 for ; Mon, 19 Mar 2007 17:38:29 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.freebsd.org (Postfix) with ESMTP id 150A313C4B8 for ; Mon, 19 Mar 2007 17:38:29 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2007 10:38:29 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2JHcSPO028940; Mon, 19 Mar 2007 10:38:28 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2JHcSZf009174; Mon, 19 Mar 2007 17:38:28 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 10:38:12 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 10:38:12 -0700 Message-ID: <45FECB41.3070601@cisco.com> Date: Mon, 19 Mar 2007 13:41:21 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Shteryana Shopova References: <983439.189.qm@web58004.mail.re3.yahoo.com> <61b573980703190525s30f22648od0ecdecd01879d0c@mail.gmail.com> In-Reply-To: <61b573980703190525s30f22648od0ecdecd01879d0c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 17:38:12.0389 (UTC) FILETIME=[5DE87550:01C76A4D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=726; t=1174325908; x=1175189908; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Wireshark |Sender:=20; bh=511U2slll7Q9MBe1+2nn165wR3fDtgC71ATSLYtSCto=; b=JdFQoYEFrzR/EH6c7fBlCPeKhKiQJUNltsLkges+yXHIPIgAu9cWPP472dbDdRa4/Qw91YQ6 4cN+wCsx9+KYEWJkjD/z9Ol9wgwmGwQvnccpqJsXvFGCuor7BJcBorMo; Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); Cc: Max Laier , "manuel.ochoa@yahoo.com" , freebsd-net@freebsd.org 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: Mon, 19 Mar 2007 17:38:29 -0000 Shteryana Shopova wrote: > On 3/19/07, manuel.ochoa@yahoo.com wrote: >> Max, correct me if I'm wrong but tcpdump will only give you the >> headers, is that correct? This is fine most of the time but sometimes >> I need to capture full frames. > > Nope - that's not correct - > > #tcpdump -s 0 > > will capture full frames. But nothing IMO beats wireshark for being able to go in and analyze a dump .. searching on various condition's fields etc.. It does not matter to me generally how its collected wireshark/tcpdump -s 0.. But to analyze it.. give me wireshark any day :-D R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 17:53: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 B356516A400; Mon, 19 Mar 2007 17:53:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7A19D13C483; Mon, 19 Mar 2007 17:53:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id l2JHreww082252; Mon, 19 Mar 2007 13:53:40 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id l2JHreQ3061174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2007 13:53:40 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200703191753.l2JHreQ3061174@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Mar 2007 13:51:48 -0400 To: Pete French , freebsd-net@freebsd.org, jkim@freebsd.org From: Mike Tancsa In-Reply-To: References: <200703161430.42854.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on clamscanner3 X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: [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: Mon, 19 Mar 2007 17:53:41 -0000 At 12:28 PM 3/19/2007, Pete French wrote: > > I have made bge(4) patch for -STABLE (sorry, not suitable for > > RELENG_6_2): > >What dates stable is this relative to ? I am trying to apply your >patch to a cvsup of stable pulled on the day/time you sent your email, >but parts of it are failing for me unfortunately. I would like to test this >as I have a nmuber of bge interfaces running on some systems. Mine applied cleanly to sources from last Friday. So far so good for me in that I have not yet seen the watchdog timeout (previously once every 4 days or so) but its too early to tell. Still, I have not seen any regressions with it yet since installing it last Saturday. This is a fairly busy recursive DNS server ---Mike From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 18:08: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 93C6A16A407; Mon, 19 Mar 2007 18:08:25 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.freebsd.org (Postfix) with ESMTP id 2CEC313C487; Mon, 19 Mar 2007 18:08:24 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.ticketswitch.com) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1HTMHP-0006Af-PS; Mon, 19 Mar 2007 18:08:23 +0000 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1HTMHP-000HZU-H9; Mon, 19 Mar 2007 18:08:23 +0000 To: freebsd-net@freebsd.org, jkim@freebsd.org, mike@sentex.net In-Reply-To: <200703191753.l2JHreQ3061174@lava.sentex.ca> Message-Id: From: Pete French Date: Mon, 19 Mar 2007 18:08:23 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: [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: Mon, 19 Mar 2007 18:08:25 -0000 > Mine applied cleanly to sources from last Friday. O.K., that works (now I have the correct date in my supfile). Will give it a shot... -pete. From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 18:52: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 61B4316A403 for ; Mon, 19 Mar 2007 18:52:35 +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 3C67E13C4AD for ; Mon, 19 Mar 2007 18:52:35 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 21F8B2085C4 for ; Mon, 19 Mar 2007 14:52:33 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 19 Mar 2007 14:52:33 -0400 X-Sasl-enc: tzdHKm2PAHJ83Ujtqi1V9srIOupnG9HB/2QIc4CcLOks 1174330354 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 D397B17E70 for ; Mon, 19 Mar 2007 14:52:34 -0400 (EDT) Message-ID: <45FEDBF0.4050105@incunabulum.net> Date: Mon, 19 Mar 2007 18:52:32 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PATCH] Multicast refcounting in network stack X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 18:52:35 -0000 Hi, A patch against -CURRENT is now available: http://people.freebsd.org/~bms/dump/multi_refcounting.diff This is a fairly sweeping architectural change which should resolve memory leaks and potential panics with the network stack as a whole, to better support interface detach at runtime. I'd like to check it in as soon as possible as it fixes the root cause of the problems we have had with carp and pfsync in our stack. NetBSD has implemented refcounting like this for some time now, so it does not suffer from the same problems. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 19:11: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 9ADEF16A402 for ; Mon, 19 Mar 2007 19:11: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 3734F13C4BF for ; Mon, 19 Mar 2007 19:11:57 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 88492 invoked from network); 19 Mar 2007 18:41:19 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Mar 2007 18:41:19 -0000 Message-ID: <45FEE07C.4060501@freebsd.org> Date: Mon, 19 Mar 2007 20:11:56 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bruce M Simpson References: <45FEDBF0.4050105@incunabulum.net> In-Reply-To: <45FEDBF0.4050105@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Multicast refcounting in network stack X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 19:11:58 -0000 Bruce M Simpson wrote: > Hi, > > A patch against -CURRENT is now available: > http://people.freebsd.org/~bms/dump/multi_refcounting.diff > > This is a fairly sweeping architectural change which should resolve > memory leaks and potential panics with the network stack as a whole, to > better support interface detach at runtime. > > I'd like to check it in as soon as possible as it fixes the root cause > of the problems we have had with carp and pfsync in our stack. NetBSD > has implemented refcounting like this for some time now, so it does not > suffer from the same problems. Patch looks good. :-) -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 19:54:57 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 7ACB016A401 for ; Mon, 19 Mar 2007 19:54:57 +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 008EC13C4B0 for ; Mon, 19 Mar 2007 19:54:56 +0000 (UTC) (envelope-from keith.arner@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so15092nfc for ; Mon, 19 Mar 2007 12:54:55 -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=maczwp+mYlo+i3+A7y4R2JL9Q0QedrY5Nt+HhOmPuubg5kpqrnNjFSpruZDJrMCCW6YiPtgRy/cOylvTJlm/k6wXea0L61PXvBFGAOCc/dkZVkRvlczFyyWawmn8EnJPJffVOZvG0mRX0ekiA9UmNr/1oJtDDxW9dLuxxCfq6NQ= 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=kmN2dvgZZ7bpcB6BacZ3lrRYP/NGgPyr4y42w6t5NK5YLIRF0AdkmvZjFAw4whnJOUERDLUOtmWetOXXDI4OqcCFa+BciUtVlnKCDNbjgMWiS4+PWjT2KlWXm72MCOljJXUghxkrmNfBkbdqgbMH+A8CjVAPOjAPfqcr5hEO7Hc= Received: by 10.82.167.5 with SMTP id p5mr10720797bue.1174334095496; Mon, 19 Mar 2007 12:54:55 -0700 (PDT) Received: by 10.82.121.1 with HTTP; Mon, 19 Mar 2007 12:54:55 -0700 (PDT) Message-ID: <8e552a500703191254qba4e194y810eb99a9f07bed8@mail.gmail.com> Date: Mon, 19 Mar 2007 15:54:55 -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: 9702e7818bd07833 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: Mon, 19 Mar 2007 19:54:57 -0000 On 3/11/07, Robert Watson wrote: > > > There are several ways we could start to reduce contention on that lock: > > (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've been thinking about this approach, and it does sound like the simplest to implement of the three proposed. However, the special case of the listen socket seems like it would complicate matters. It seems to me, however, that the complication of the listen socket could be simplified if the listen sockets were maintained in a separate pcb list from the rest of the TCP sockets (the fully connected sockets). If the two types of sockets were thus separated, the code would acquire the lock on the bucket in the connect hash, and search the connect hash; if there was a miss, acquire the lock on the listen list and then search the listen list. The lock on the listen list should follow the locks on the connect buckets in the locking order. The connection bucket should be locked first, as delivery of data would be the common case. To create a new connection in the tcp_input path, both the connect bucket and the listen list would need to be locked (connect bucket as a new entry would be added to the list, and listen list as the accept socket would be protected from going away). Keith From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 20:06:01 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 07C6E16A400 for ; Mon, 19 Mar 2007 20:06:01 +0000 (UTC) (envelope-from unixero@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 8FABB13C4BD for ; Mon, 19 Mar 2007 20:06:00 +0000 (UTC) (envelope-from unixero@gmail.com) Received: by nf-out-0910.google.com with SMTP id k27so19175nfc for ; Mon, 19 Mar 2007 13:05:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=IC9L50srjW37nVBKM1ktY6d/58kgNRjWrGZgKw7soreInHveF491brfvQyFWtXM25iHWaiIGdMWrdDv/V7i6oR5yLryBSY4s+qlNd4JBOEBloem9hkLqer4KHhzIFYLeNpPER+N+LEl0V6XM8QKvuQr8xi5bW+uVCTuQrrLMaaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=dkWHqHpgzueDlZ3yKd71poyXD/vEzMmzrO7r0lX+q7RuwznBknhmkkjZNsbcX5axNB709MsJW1s/s/NN1654Uy1pJ1u1y7+KEEPuS90x1Lzw8+aqunegltdPxw765axJG01Rp7wZuS3EpkhzRGRRLD4NyQMuU9FPf/QgKGXt+vY= Received: by 10.78.160.2 with SMTP id i2mr2616874hue.1174333026111; Mon, 19 Mar 2007 12:37:06 -0700 (PDT) Received: from debian ( [87.5.215.184]) by mx.google.com with ESMTP id k23sm57084nfc.2007.03.19.12.37.04; Mon, 19 Mar 2007 12:37:05 -0700 (PDT) Date: Mon, 19 Mar 2007 20:37:09 +0100 From: Ignacio Rey To: freebsd-net@freebsd.org Message-ID: <20070319203709.1272a470@debian> X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: networking code and splx() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 20:06:01 -0000 Hello everyone, I'm studying a bit the FreeBSD networking code. I've read "TCP/IP illustrated vol 2" by G. R. Wright and W. R. Stevens, which describes code in 4.4BSD-lite. Now I'm taking a look at FreeBSD 6.2 release. Some things are different, many others kept the same. What I'm confused about is that in 4.4BSD there are many calls to the splx() family of functions, and I didn't see any of them in the networking code in FreeBSD. However the 'grep' program showed me that they are used in other parts of the kernel. The question is: Have calls to these functions been wrapped? or are they simply not used in this context? Thanks in advance, Ignacio From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 20:12:48 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 3122516A403; Mon, 19 Mar 2007 20:12:48 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.freebsd.org (Postfix) with ESMTP id 015BB13C457; Mon, 19 Mar 2007 20:12:47 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id D2981DA82; Mon, 19 Mar 2007 16:12:46 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 635A161C8A; Mon, 19 Mar 2007 15:12:52 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17918.61124.353668.804988@canoe.dclg.ca> Date: Mon, 19 Mar 2007 15:12:52 -0500 To: Doug Barton In-Reply-To: <45FE13E5.9060902@FreeBSD.org> References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> <45FC90CE.3020605@gmail.com> <45FDD5C3.1070305@FreeBSD.org> <45FDF284.3040008@gmail.com> <45FE13E5.9060902@FreeBSD.org> X-Mailer: VM 7.17 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid Cc: freebsd-net@freebsd.org, Mark Andrews , Kian Mohageri , 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: Mon, 19 Mar 2007 20:12:48 -0000 >>>>> "Doug" == Doug Barton writes: Doug> Kian Mohageri wrote: >> I agree VERY MUCH with this sort of approach. It would be a much >> cleaner solution than completely separate handling of all of these >> different problems. I'm trying to get an idea of what all of the >> major problems with the current order are, and these are the ones >> I'm aware of: >> >> - ipfw blocks by default (names unresolvable, rtsol breaks) - >> ipf/pf pass by default (services are unprotected) >> >> I think a firewall_boot script (similar to what you've proposed) >> could potentially solve all of these problems. Doug> exception, not the rule. Furthermore (and I'm betraying a Doug> prejudice here) I think that firewall rules that rely on name Doug> resolution are absolutely nuts, and I say that with many years Doug> of experience as a professional DNS and system administrator. I think you're misreading the above. The poster is saying that because ipfw's default behaviour is block, loading it at the wrong time can break other startup items because they require name resolution or the sending of packets (rtsol). Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 20:23:18 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 5EF5E16A404 for ; Mon, 19 Mar 2007 20:23:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outD.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4E2AE13C4E3 for ; Mon, 19 Mar 2007 20:23:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 19 Mar 2007 12:55:31 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id B6277125AE4; Mon, 19 Mar 2007 13:23:17 -0700 (PDT) Message-ID: <45FEF135.2050203@elischer.org> Date: Mon, 19 Mar 2007 13:23:17 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ignacio Rey References: <20070319203709.1272a470@debian> In-Reply-To: <20070319203709.1272a470@debian> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: networking code and splx() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 20:23:18 -0000 Ignacio Rey wrote: > Hello everyone, > > I'm studying a bit the FreeBSD networking code. > > I've read "TCP/IP illustrated vol 2" by G. R. Wright and W. R. Stevens, > which describes code in 4.4BSD-lite. > > Now I'm taking a look at FreeBSD 6.2 release. Some things are different, > many others kept the same. What I'm confused about is that in 4.4BSD > there are many calls to the splx() family of functions, and I didn't see > any of them in the networking code in FreeBSD. However the 'grep' program > showed me that they are used in other parts of the kernel. There was a major change in the way that synchronization was done bewteen FreeBSD 4.x and FreeBSD 5.X. The changes were to support real multiprocessor operation and were extensive. The 'spl" method of operation was only able to protect operation on a single CPU. You should probably get a copy of "The design of the FreeBSD (um 5.2 I think) Operating System by Kirk McKusick and George Neville-Neil. It goes into some of the changes. (many changes have happenned since then too). the New locking largely depends on Mutexes. > > > The question is: Have calls to these functions been wrapped? or are they > simply not used in this context? > > > Thanks in advance, > > Ignacio > _______________________________________________ > 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 19 22:14: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 9923516A400 for ; Mon, 19 Mar 2007 22:14:37 +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 737C013C458 for ; Mon, 19 Mar 2007 22:14:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id D7C6B208C6A; Mon, 19 Mar 2007 18:14:33 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 19 Mar 2007 18:14:33 -0400 X-Sasl-enc: DrBevcq+KU5qH2fFLbyMrEBtAjqUUMHGghA4zPONHjfs 1174342475 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 53BAD181D3; Mon, 19 Mar 2007 18:14:35 -0400 (EDT) Message-ID: <45FF0B49.9060008@FreeBSD.org> Date: Mon, 19 Mar 2007 22:14:33 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Ignacio Rey References: <20070319203709.1272a470@debian> In-Reply-To: <20070319203709.1272a470@debian> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: networking code and splx() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 22:14:37 -0000 Ignacio Rey wrote: > ... > The question is: Have calls to these functions been wrapped? or are they > simply not used in this context? > splx() and friends have been no-ops since FreeBSD 5.x was branched. Synchronization is now done using other mechanisms such as mutexes and spin locks. See the new man page locking(9) in -CURRENT. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 22:21: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 9508B16A402 for ; Mon, 19 Mar 2007 22:21:04 +0000 (UTC) (envelope-from kml@patheticgeek.net) Received: from patheticgeek.net (dsl092-035-004.lax1.dsl.speakeasy.net [66.92.35.4]) by mx1.freebsd.org (Postfix) with SMTP id 4739A13C458 for ; Mon, 19 Mar 2007 22:21:04 +0000 (UTC) (envelope-from kml@patheticgeek.net) Received: (qmail 21716 invoked from network); 19 Mar 2007 21:53:25 -0000 Received: from dsl092-035-004.lax1.dsl.speakeasy.net (HELO yakko.patheticgeek.net) (66.92.35.4) by dsl092-035-004.lax1.dsl.speakeasy.net with SMTP; 19 Mar 2007 21:53:25 -0000 Date: Mon, 19 Mar 2007 14:54:22 -0700 From: Kevin Lahey To: freebsd-net@freebsd.org Message-ID: <20070319145422.39bfddcd@yakko.patheticgeek.net> In-Reply-To: <994cd1cf0703052105y375679a4t482f4e35988f9daf@mail.gmail.com> References: <994cd1cf0703050842r5e54daa6y5fe6af3083e15cd@mail.gmail.com> <45EC6E88.3080101@tomjudge.com> <20070305115615.W38684@orthanc.ca> <994cd1cf0703052105y375679a4t482f4e35988f9daf@mail.gmail.com> X-Mailer: Sylpheed-Claws 2.5.5 (GTK+ 2.10.6; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: PMTU Discovery support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 22:21:04 -0000 On Tue, 6 Mar 2007 10:35:42 +0530 "aditya kiran" wrote: > RFC 1191 says to increase the PMTU at some itnerval (15 minutes default) 10 minutes. > next time a packet is sent, this will be used... and if PMTU is really > increased, > no ICMP error will be recieved. that shows an increase in the PMTU. I'm > trying to > understand if this mechanism is there in freebsd. any on this is appreicated It looks to me as though FreeBSD stores per-host MTU data in the hostcache, which gets purged after five minutes of inactivity. If that's actually how it works, then, yes, FreeBSD should indeed periodically probe for larger PMTUs. Of course, the real test is to set up a few hosts and see what happens, rather than speculating based on a quick perusal of the code. :-) Kevin kml@patheticgeek.net From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 00:22:01 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 4F66916A405 for ; Tue, 20 Mar 2007 00:22:01 +0000 (UTC) (envelope-from kml@patheticgeek.net) Received: from patheticgeek.net (dsl092-035-004.lax1.dsl.speakeasy.net [66.92.35.4]) by mx1.freebsd.org (Postfix) with SMTP id F3A9B13C459 for ; Tue, 20 Mar 2007 00:22:00 +0000 (UTC) (envelope-from kml@patheticgeek.net) Received: (qmail 9 invoked from network); 20 Mar 2007 00:21:02 -0000 Received: from dsl092-035-004.lax1.dsl.speakeasy.net (HELO yakko.patheticgeek.net) (66.92.35.4) by dsl092-035-004.lax1.dsl.speakeasy.net with SMTP; 20 Mar 2007 00:21:02 -0000 Date: Mon, 19 Mar 2007 17:21:56 -0700 From: Kevin Lahey To: freebsd-net@freebsd.org Message-ID: <20070319172156.68cba0a9@yakko.patheticgeek.net> In-Reply-To: <20070319145422.39bfddcd@yakko.patheticgeek.net> References: <994cd1cf0703050842r5e54daa6y5fe6af3083e15cd@mail.gmail.com> <45EC6E88.3080101@tomjudge.com> <20070305115615.W38684@orthanc.ca> <994cd1cf0703052105y375679a4t482f4e35988f9daf@mail.gmail.com> <20070319145422.39bfddcd@yakko.patheticgeek.net> X-Mailer: Sylpheed-Claws 2.5.5 (GTK+ 2.10.6; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: PMTU Discovery support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 00:22:01 -0000 On Mon, 19 Mar 2007 14:54:22 -0700 Kevin Lahey wrote: > Of course, the real test is to set up a few hosts and see what > happens, rather than speculating based on a quick perusal of the > code. :-) After my slap-dash read of the current FreeBSD code, I was a little concerned that I'd missed something. As penance, I set up a quick experiment with four hosts connected in a line, A <-> B <-> C <-> D, set the MTU on the links from B to C to 512, and ran ttcp from A to D. PMTUD worked correctly. Then I suspended the ttcp process, went away for an hour, and resumed it. Watching tcpdump, it appears that 512 octet packets continued to be sent, with no attempt at probing. That would seem to be a bug. The boxes were running FreeBSD-6.1, but I can't really vouch for the particular kernel configuration. It could well be that the problem is with the loose nut behind the wheel, rather than with FreeBSD. :-) Kevin kml@patheticgeek.net From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 01:47: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 50D1716A404 for ; Tue, 20 Mar 2007 01:47: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 25E6713C43E for ; Tue, 20 Mar 2007 01:47:30 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 0D8AA208E13; Mon, 19 Mar 2007 21:47:28 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 19 Mar 2007 21:47:28 -0400 X-Sasl-enc: f57RLV2QVRxes1ZpAwIKb7+k9sSZ8EMJ7wj0VoHt3HTE 1174355250 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 B7C291AB5F; Mon, 19 Mar 2007 21:47:29 -0400 (EDT) Message-ID: <45FF3D2F.3040000@FreeBSD.org> Date: Tue, 20 Mar 2007 01:47:27 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Kevin Lahey References: <994cd1cf0703050842r5e54daa6y5fe6af3083e15cd@mail.gmail.com> <45EC6E88.3080101@tomjudge.com> <20070305115615.W38684@orthanc.ca> <994cd1cf0703052105y375679a4t482f4e35988f9daf@mail.gmail.com> <20070319145422.39bfddcd@yakko.patheticgeek.net> <20070319172156.68cba0a9@yakko.patheticgeek.net> In-Reply-To: <20070319172156.68cba0a9@yakko.patheticgeek.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: PMTU Discovery support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 01:47:30 -0000 Kevin Lahey wrote: > > The boxes were running FreeBSD-6.1, but I can't really vouch for the > particular kernel configuration. It could well be that the problem is > with the loose nut behind the wheel, rather than with FreeBSD. :-) > I believe PMTU measurements may only be relied upon for active TCP connections, but it's been a while since I read this code. It would be useful if non-TCP drivers such as gre(4) could be extended to perform PMTU discovery and auto-tune their MTU based on this, as manually setting the MTU is a bit random and can result in horrible fragmentation when going across the big-I Internet. I imagine doing this would require changes to the icmp input path and a bit of abstraction. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 01:48:02 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 982EF16A406; Tue, 20 Mar 2007 01:48:02 +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 6B6B713C4C8; Tue, 20 Mar 2007 01:48: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 71DE82047DC; Mon, 19 Mar 2007 21:48:00 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 19 Mar 2007 21:48:00 -0400 X-Sasl-enc: fgaynYZyAXXZjd1hueGns38cfeZO7xEkJ1KpeqXGew3q 1174355282 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 38C761AB61; Mon, 19 Mar 2007 21:48:02 -0400 (EDT) Message-ID: <45FF3D50.3050604@incunabulum.net> Date: Tue, 20 Mar 2007 01:48:00 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Andre Oppermann References: <45FEDBF0.4050105@incunabulum.net> <45FEE07C.4060501@freebsd.org> In-Reply-To: <45FEE07C.4060501@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [PATCH] Multicast refcounting in network stack X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 01:48:02 -0000 Andre Oppermann wrote: >> http://people.freebsd.org/~bms/dump/multi_refcounting.diff > Patch looks good. :-) Committed, with some changes. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 03:22:53 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 3AD8F16A401 for ; Tue, 20 Mar 2007 03:22:53 +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 49C9813C44B for ; Tue, 20 Mar 2007 03:22:51 +0000 (UTC) (envelope-from ale@seudns.net) Received: (qmail 50227 invoked from network); 20 Mar 2007 03:23:28 -0000 Received: from unknown (HELO ?192.168.100.20?) (192.168.100.20) by 0 with SMTP; 20 Mar 2007 03:23:27 -0000 Received-SPF: none (192.168.99.3: domain of ale@seudns.net does not designate permitted sender hosts) Message-ID: <45FF538F.1050405@seudns.net> Date: Tue, 20 Mar 2007 00:22:55 -0300 From: Alexandre Biancalana User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ifstated 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, 20 Mar 2007 03:22:53 -0000 Hi list, First, excuse-me by the off-topic message, I asked this on -questions but I don't have any answer. I'm trying to setup ifstated to check two links and if some go down, do some actions like change pf rules and machine's route. My doubt is about the execution order/repetition of the states body of ifstated.conf, in all configs that I tried just the last check is executed always, follow and example: ifstated.conf: ============================== loglevel debug ping1 = '( "ping -q -c 1 -t 3 www.site1.com > /dev/null" every 10 ) ' ping2 = '( "ping -q -c 1 -t 3 www.site2.com > /dev/null" every 10 ) ' state one { if ! ( $ping1 && $ping2 ) { set-state two } } state two { init { run "logger -p console.notice -t ifstated 'Restarting network !'" } if ( $ping && $ping2 ) { set-state one } } ============================== # ifstated -dv ping1 = "( "ping -q -c 1 -t 3 www.site1.com > /dev/null" every 10 ) " ping2 = "( "ping -q -c 1 -t 3 www.site2.com > /dev/null" every 10 ) " ifstated: initial state: one ifstated: changing state to one ifstated: running ping -q -c 1 -t 3 www.site1.com > /dev/null ifstated: running ping -q -c 1 -t 3 www.site2.com > /dev/null ifstated: started ifstated: changing state to two ifstated: running ping -q -c 1 -t 3 www.site1.com > /dev/null ifstated: running ping -q -c 1 -t 3 www.site2.com > /dev/null ifstated: running ping -q -c 1 -t 3 www.site2.com > /dev/null ifstated: running ping -q -c 1 -t 3 www.site2.com > /dev/null As you can see, after change state ifstated execute only the *last* check command of the statement (ping2) forever.... This is the expected behavior ? I'm running 6-STABLE + ifstated-20050505 (instaled via /usr/ports/net/ifstated) Thanks for any help. Alexandre From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 07:31: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 446DD16A405 for ; Tue, 20 Mar 2007 07:31:54 +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 9D34213C4BF for ; Tue, 20 Mar 2007 07:31:53 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id C2FD133C94; Tue, 20 Mar 2007 09:31:50 +0200 (SAST) Date: Tue, 20 Mar 2007 09:31:50 +0200 From: John Hay To: "Bruce M. Simpson" Message-ID: <20070320073150.GA19859@zibbi.meraka.csir.co.za> References: <20070319203709.1272a470@debian> <45FF0B49.9060008@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45FF0B49.9060008@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: networking code and splx() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 07:31:54 -0000 On Mon, Mar 19, 2007 at 10:14:33PM +0000, Bruce M. Simpson wrote: > Ignacio Rey wrote: > >... > >The question is: Have calls to these functions been wrapped? or are they > >simply not used in this context? > > > splx() and friends have been no-ops since FreeBSD 5.x was branched. > Synchronization is now done using other mechanisms such as mutexes and > spin locks. See the new man page locking(9) in -CURRENT. It does not seem to get installed: Doing a grep for locking in /usr/src/share/man/man9/Makefile produce nothing. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 07:41:01 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 DDBB816A403; Tue, 20 Mar 2007 07:41:01 +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 994B613C457; Tue, 20 Mar 2007 07:41:01 +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 1HTYxk-0001Vf-0g; Tue, 20 Mar 2007 10:40:56 +0300 Date: Tue, 20 Mar 2007 10:40:51 +0300 From: Eygene Ryabinkin To: John Hay Message-ID: <20070320074051.GH96806@codelabs.ru> References: <20070319203709.1272a470@debian> <45FF0B49.9060008@FreeBSD.org> <20070320073150.GA19859@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070320073150.GA19859@zibbi.meraka.csir.co.za> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.6 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_05 Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: networking code and splx() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 07:41:01 -0000 John, good day. Tue, Mar 20, 2007 at 09:31:50AM +0200, John Hay wrote: > > > > > splx() and friends have been no-ops since FreeBSD 5.x was branched. > > Synchronization is now done using other mechanisms such as mutexes and > > spin locks. See the new man page locking(9) in -CURRENT. > > It does not seem to get installed: The locking.9 is not the part of the current build as the comment of the initial commit of that file says. > Doing a grep for locking in /usr/src/share/man/man9/Makefile produce > nothing. But if you're running -CURRENT, then you can view the page from the sources (assuming that you have the system sources in /usr/src/): $ groff -Tascii -mandoc /usr/src/share/man/man9/locking.9 | less Our you can download the locking.9 from http://www.freebsd.org/cgi/cvsweb.cgi/src/share/man/man9/locking.9 -- Eygene From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 08:30: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 C035316A402 for ; Tue, 20 Mar 2007 08:30:27 +0000 (UTC) (envelope-from hostmaster@Infra-Service.ca) Received: from server.Infra-service.ca (loghost.infra-service.ca [204.138.67.1]) by mx1.freebsd.org (Postfix) with ESMTP id 94D7C13C45D for ; Tue, 20 Mar 2007 08:30:27 +0000 (UTC) (envelope-from hostmaster@Infra-Service.ca) Received: from localhost by mail.infra-service.ca via sendmail with STDIO (/R:bind_hosts/T:inet_zone_bind_smtp/dest:remote) id (1081 bytes from ident using UNIX) for ; Tue, 20 Mar 2007 04:19:55 -0400 (EDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #2; built 2006-May-8) Message-Id: From: Infraservice hostmaster To: freebsd-net@freebsd.org Date: Tue, 20 Mar 2007 04:19:55 -0400 (EDT) X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: "em" driver shuts down interface when "ifconfig media 100baseTX" is invoked X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 08:30:27 -0000 FreeBSD cg-gw 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #10: Tue Jan 16 01:40:27 EST 2007 root@taint:/usr/obj/usr/src/sys/FW-YQ i386 I did: "ifconfig em2 media 100baseTX mediaopt full-duplex" ifconfig em2 now reports: ... media: Ethernet 100baseTX (autoselect) status: no carrier "ifconfig em2 media 100baseTX" also does this We tried it on 2 different 100baseTX interfaces with the same result "ifconfig em2 media autonegotiate" brings the interface back up It doesn't seem to happen on another interface which autonegotiates 10baseT half-duplex, however This seems to indicate there might be a driver problem since the 2 interfaces connect to very different kinds of equipment Any suggestions? From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 12:00: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 9975016A413; Tue, 20 Mar 2007 12:00:46 +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 1997113C4C2; Tue, 20 Mar 2007 12:00:45 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 7A31F33CAE; Tue, 20 Mar 2007 14:00:43 +0200 (SAST) Date: Tue, 20 Mar 2007 14:00:43 +0200 From: John Hay To: Eygene Ryabinkin Message-ID: <20070320120043.GA32312@zibbi.meraka.csir.co.za> References: <20070319203709.1272a470@debian> <45FF0B49.9060008@FreeBSD.org> <20070320073150.GA19859@zibbi.meraka.csir.co.za> <20070320074051.GH96806@codelabs.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070320074051.GH96806@codelabs.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: networking code and splx() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 12:00:46 -0000 On Tue, Mar 20, 2007 at 10:40:51AM +0300, Eygene Ryabinkin wrote: > John, good day. > > Tue, Mar 20, 2007 at 09:31:50AM +0200, John Hay wrote: > > > > > > > splx() and friends have been no-ops since FreeBSD 5.x was branched. > > > Synchronization is now done using other mechanisms such as mutexes and > > > spin locks. See the new man page locking(9) in -CURRENT. > > > > It does not seem to get installed: > > The locking.9 is not the part of the current build as the comment > of the initial commit of that file says. But if we start to refer people to it, surely it is time to install it? It is like the Biblical example of lighting a candle and then putting a bucket over it... Pretty much pointless. > > Doing a grep for locking in /usr/src/share/man/man9/Makefile produce > > nothing. > > But if you're running -CURRENT, then you can view the page from > the sources (assuming that you have the system sources in /usr/src/): > $ groff -Tascii -mandoc /usr/src/share/man/man9/locking.9 | less > > Our you can download the locking.9 from > http://www.freebsd.org/cgi/cvsweb.cgi/src/share/man/man9/locking.9 Yes, but you must know what you are looking for. The nice unix tools, man -k and apropos, is not your friend anymore. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 15:45: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 3244C16A404 for ; Tue, 20 Mar 2007 15:45:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 1C49F13C4C1 for ; Tue, 20 Mar 2007 15:45:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 20 Mar 2007 08:17:59 -0700 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 6DA2C125B2B; Tue, 20 Mar 2007 08:45:52 -0700 (PDT) Message-ID: <460001B0.8040203@elischer.org> Date: Tue, 20 Mar 2007 08:45:52 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: John Hay References: <20070319203709.1272a470@debian> <45FF0B49.9060008@FreeBSD.org> <20070320073150.GA19859@zibbi.meraka.csir.co.za> <20070320074051.GH96806@codelabs.ru> <20070320120043.GA32312@zibbi.meraka.csir.co.za> In-Reply-To: <20070320120043.GA32312@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: networking code and splx() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 15:45:54 -0000 John Hay wrote: > On Tue, Mar 20, 2007 at 10:40:51AM +0300, Eygene Ryabinkin wrote: >> John, good day. >> >> Tue, Mar 20, 2007 at 09:31:50AM +0200, John Hay wrote: >>>>> >>>> splx() and friends have been no-ops since FreeBSD 5.x was branched. >>>> Synchronization is now done using other mechanisms such as mutexes and >>>> spin locks. See the new man page locking(9) in -CURRENT. >>> It does not seem to get installed: >> The locking.9 is not the part of the current build as the comment >> of the initial commit of that file says. > > But if we start to refer people to it, surely it is time to install it? > It is like the Biblical example of lighting a candle and then putting > a bucket over it... Pretty much pointless. since no locking gurus have given it a "blessing of correctness" yet I have not put it into the build as it may be wildly inaccurate. As soon as I have been told that it is correct I'll attach it.. It's only been there for a few days.. > >>> Doing a grep for locking in /usr/src/share/man/man9/Makefile produce >>> nothing. >> But if you're running -CURRENT, then you can view the page from >> the sources (assuming that you have the system sources in /usr/src/): >> $ groff -Tascii -mandoc /usr/src/share/man/man9/locking.9 | less >> >> Our you can download the locking.9 from >> http://www.freebsd.org/cgi/cvsweb.cgi/src/share/man/man9/locking.9 > > Yes, but you must know what you are looking for. The nice unix tools, > man -k and apropos, is not your friend anymore. > > John From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 20:05: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 25B8216A408 for ; Tue, 20 Mar 2007 20:05:29 +0000 (UTC) (envelope-from kml@patheticgeek.net) Received: from patheticgeek.net (dsl092-035-004.lax1.dsl.speakeasy.net [66.92.35.4]) by mx1.freebsd.org (Postfix) with SMTP id C6F7613C4C3 for ; Tue, 20 Mar 2007 20:05:28 +0000 (UTC) (envelope-from kml@patheticgeek.net) Received: (qmail 11740 invoked from network); 20 Mar 2007 20:04:29 -0000 Received: from dsl092-035-004.lax1.dsl.speakeasy.net (HELO yakko.patheticgeek.net) (66.92.35.4) by dsl092-035-004.lax1.dsl.speakeasy.net with SMTP; 20 Mar 2007 20:04:29 -0000 Date: Tue, 20 Mar 2007 13:05:25 -0700 From: Kevin Lahey To: "Bruce M. Simpson" Message-ID: <20070320130525.01caad3d@yakko.patheticgeek.net> In-Reply-To: <45FF3D2F.3040000@FreeBSD.org> References: <994cd1cf0703050842r5e54daa6y5fe6af3083e15cd@mail.gmail.com> <45EC6E88.3080101@tomjudge.com> <20070305115615.W38684@orthanc.ca> <994cd1cf0703052105y375679a4t482f4e35988f9daf@mail.gmail.com> <20070319145422.39bfddcd@yakko.patheticgeek.net> <20070319172156.68cba0a9@yakko.patheticgeek.net> <45FF3D2F.3040000@FreeBSD.org> X-Mailer: Sylpheed-Claws 2.5.5 (GTK+ 2.10.6; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: PMTU Discovery support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 20:05:29 -0000 On Tue, 20 Mar 2007 01:47:27 +0000 "Bruce M. Simpson" wrote: > I believe PMTU measurements may only be relied upon for active TCP > connections, but it's been a while since I read this code. I think, according to RFC1191, that the probing should happen on any given connection after 10 minutes. Otherwise, a single ICMP message could permanently reduce the MTU of a connection for good. I believe that FreeBSD and others did it that way 10 years ago, when I did a survey of available PMTUD implementations. I wonder if all applicable TCP connections ought to be notified when the hostcache MTU is updated and when a hostcache entry with an MTU set is deleted? (For that matter, can an entry ever be deleted while outstanding connections are going to that host?) Kevin kml@patheticgeek.net From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 22:43: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 75EDF16A405 for ; Tue, 20 Mar 2007 22:43:14 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id F27D413C448 for ; Tue, 20 Mar 2007 22:43:13 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from [192.168.98.246] ([192.168.44.2]) by mail1.cil.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 23:31:06 +0100 Message-ID: <460060A8.1080109@ide.resurscentrum.se> Date: Tue, 20 Mar 2007 23:31:04 +0100 From: Jon Otterholm User-Agent: Thunderbird 1.5.0.9 (X11/20070131) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2007 22:31:06.0891 (UTC) FILETIME=[738A65B0:01C76B3F] Subject: ICMP-floods X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 22:43:14 -0000 Hi. I have some strange netproblems where my FreeBSD-routers sends icmp-redirects/time-exceeds to my surveillance machine. Basically I have a admin-net where all routers and switches are connected. On this net I have a nagios-machine for surveillance (running FreeBSD). Sometimes when my Nagios sends icmp-echo-replies to equipment on my admin-net my FreeBSD-routers replies with a icmp-redirect (even though the echo-reply is not destined for the routers). This wouldn't be a problem if the routers would just send a single icmp-redirect, the problem is that they (sometimes more than one) send out about 15000 of them in reply to a single echo. All FreeBSD-machines are 6.2-RELEASE When setting net.inet.ip.redirect=0 on my routers, the icmp-redirects disappear, but instead I get a large amount of ICMP-time-exceed from my routers. The following is a output from tcpdump on my surveillance-machine: 23:03:54.024417 IP 192.168.1.54 > 192.168.1.59: ICMP echo request, id 122, seq 0, length 64 23:03:54.024716 IP 192.168.1.54 > 192.168.1.59: ICMP echo request, id 122, seq 0, length 64 23:03:54.024768 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.024925 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.025433 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.025653 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.025818 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.025967 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.026118 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.026372 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.026708 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.027085 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.027362 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.027746 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.028105 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.028467 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.028832 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.029202 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.029567 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 23:03:54.029929 IP 192.168.1.59 > 192.168.1.54: ICMP echo reply, id 122, seq 0, length 64 and here 192.168.1.59 replies with the same id for about 3300 lines, after that comes: 23:03:54.251379 IP 192.168.1.68 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251394 IP 192.168.1.56 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251398 IP 192.168.1.67 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251401 IP 192.168.1.56 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251417 IP 192.168.1.68 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251421 IP 192.168.1.68 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251426 IP 192.168.1.56 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251441 IP 192.168.1.56 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251445 IP 192.168.1.67 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251460 IP 192.168.1.68 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251465 IP 192.168.1.56 > 192.168.1.54: ICMP time exceeded in-transit, length 36 23:03:54.251468 IP 192.168.1.68 > 192.168.1.54: ICMP time exceeded in-transit, length 36 for about 3300 lines. This is my routers answering. 192.168.41.54 is a HP420 WLAN-AP. I get the same behavior from other equipment on my admin-lan including FreeBSD-machines. If someone could give me a hint to where to start debugging I would be grateful. //Jon From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 22:48: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 E392216A402 for ; Tue, 20 Mar 2007 22:48:00 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id CD3F713C483 for ; Tue, 20 Mar 2007 22:48:00 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out4.apple.com (8.13.8/8.13.8) with ESMTP id l2KMm09A004931; Tue, 20 Mar 2007 15:48:00 -0700 (PDT) Received: from relay8.apple.com (unknown [127.0.0.1]) by relay8.apple.com (Symantec Mail Security) with ESMTP id 77232404FD; Tue, 20 Mar 2007 15:48:00 -0700 (PDT) X-AuditID: 11807126-b0f3abb000004946-de-460064a07d0a Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay8.apple.com (Apple SCV relay) with ESMTP id 68407404F2; Tue, 20 Mar 2007 15:48:00 -0700 (PDT) In-Reply-To: <460060A8.1080109@ide.resurscentrum.se> References: <460060A8.1080109@ide.resurscentrum.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65531A6A-7178-48A1-97D0-9DCB4F72E315@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 20 Mar 2007 15:47:59 -0700 To: Jon Otterholm X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-net@freebsd.org Subject: Re: ICMP-floods X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 22:48:01 -0000 On Mar 20, 2007, at 3:31 PM, Jon Otterholm wrote: > Basically I have a admin-net where all routers and switches are > connected. On this net I have a nagios-machine for surveillance > (running > FreeBSD). Sometimes when my Nagios sends icmp-echo-replies to > equipment > on my admin-net my FreeBSD-routers replies with a icmp-redirect (even > though the echo-reply is not destined for the routers). This > wouldn't be > a problem if the routers would just send a single icmp-redirect, the > problem is that they (sometimes more than one) send out about > 15000 of > them in reply to a single echo. > > All FreeBSD-machines are 6.2-RELEASE > > When setting net.inet.ip.redirect=0 on my routers, the icmp-redirects > disappear, but instead I get a large amount of ICMP-time-exceed > from my > routers. The information you've provided strongly suggests either problems with the netmasks being used, or a routing loop, or some combination of both. ICMP time-exceeded messages happen when the packets have been shuffled around, decrementing the TTL at each hop, until it reaches zero. ICMP redirects happen when a machine sends traffic to a router where the router knows that the sending machine can reach the intended destination more directly via some other path. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 23:09: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 8F12716A402 for ; Tue, 20 Mar 2007 23:09:11 +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 6846F13C45D for ; Tue, 20 Mar 2007 23:09:11 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id E8A00209A8C; Tue, 20 Mar 2007 19:09:08 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Tue, 20 Mar 2007 19:09:08 -0400 X-Sasl-enc: /2fmfriXpw8IfU/K16ZcB+873gS5EGHQPneKfgkjAZyt 1174432151 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 D8FDC2B9C0; Tue, 20 Mar 2007 19:09:10 -0400 (EDT) Message-ID: <46006994.5020008@FreeBSD.org> Date: Tue, 20 Mar 2007 23:09:08 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Jon Otterholm References: <460060A8.1080109@ide.resurscentrum.se> In-Reply-To: <460060A8.1080109@ide.resurscentrum.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ICMP-floods X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 23:09:11 -0000 I have a patch attached to http://wiki.freebsd.org/Networking to rate-limit ICMP which is generated by the forwarding path. It would be useful to find out if this offers symptomatic relief in this situation, although as Chuck points out, it is most likely being caused by a routing loop. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 23:53:15 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 8B85316A409 for ; Tue, 20 Mar 2007 23:53:15 +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 1AD2113C4D1 for ; Tue, 20 Mar 2007 23:53:14 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 8E1DD209C36 for ; Tue, 20 Mar 2007 19:53:12 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Tue, 20 Mar 2007 19:53:12 -0400 X-Sasl-enc: zKBM5X7r3Iuk4QKeSgJSLrmO0ajgkpp+sFagMGZZiHxn 1174434794 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 AC28810E92 for ; Tue, 20 Mar 2007 19:53:14 -0400 (EDT) Message-ID: <460073E8.2080803@incunabulum.net> Date: Tue, 20 Mar 2007 23:53:12 +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: Proposal: Merge RFC3678 multicast APIs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 23:53:15 -0000 Hi, I propose that we merge the RFC3678 advanced multicast APIs. Doing so gets us closer to IGMPv3 and SSM. I would greatly appreciate suggestions about how to deal with the include header issue below. I have already started merging the basic definitions into p4 branch bms_netdev. Background: * RFC3678 specifies user and kernel APIs for any-source and specific-source multicast for IPv4, IPv6, and protocol-independent use. * this includes struct ip_mreq_source and friends * SIOCSIPMSFILTER and SIOCGMSFILTER are historical and may be ignored. Impact: * It requires that struct sockaddr_storage is visible to . * This change breaks the following files in the kernel: in4_cksum.c inet_ntoa.c ip_ecn.c in6_cksum.c in_cksum.c slcompress.c ...which do not include where this structure is defined. Benefit: * We get the SSM API. We don't support IGMPv3 or SSM yet, but this is part of the work. * Better to do this now and incrementally; the IGMPv3 implementations out there for FreeBSD have been published as patch sets which are now bitrotting. * This lets us eliminate the ugly RFC1724 hack from the IPv4 stack, which is used to specify an outgoing IPv4 multicast interface by passing a 24-bit interface index in the host portion of a 0.0.0.0/8 address. * This behaviour is not portable; Microsoft Windows Vista uses the full 32-bit wide interface index space in both its IPv4 and IPv6 stack. No snickering from the gallery please -- Dave Thaler has done excellent work bringing the MS stack closer to IETF standards. * routed uses this; it can be patched to not do so; the RFC3678 API for this is to use the generic MCAST_JOIN_GROUP socket option which accepts an interface index as an argument in struct group_req. * Linux defines a struct ip_mreqn as a workaround for applications using the pre RFC3678 API. Inside the kernel it maps IFA to IFP when handling IP_ADD_MEMBERSHIP, thus avoiding the 0.0.0.0/8 hack. See ip(4) in HEAD for the polite rendering of my rant about doing IGMP correctly and its implications for addressing in the IPv4 stack (short: you need an IP address for it to work properly, and source address selection, or IPv6, is looking like a really good idea in a wireless/manet/mobile/ad-hoc world). Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 02:59: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 3D0CD16A405 for ; Wed, 21 Mar 2007 02:59:08 +0000 (UTC) (envelope-from linuxinfoplus@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id B540013C4C7 for ; Wed, 21 Mar 2007 02:59:07 +0000 (UTC) (envelope-from linuxinfoplus@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so112386ugh for ; Tue, 20 Mar 2007 19:59:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=AOqsBWRVqgqXGlSNBUMrdlcIxzbBRIAsVpStOXje97wYDZBuGKySQrAG9b0kTIXEC/Wo+Axh3NAJxKFxPe22DxxKT2euImJ3tRfu1HRBLKycBnAfKrV1uYjKGMI/PoaI5Go/RoK46zkRkho0/l44a8DR2MtLSU9qSaGEJFt1glg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=Xja+nJl3P51CjJ4bSttEFBa1nmoZKPLknu2yzVKz3uNuXmWmv7NXtWEEW1rvGhfCNwU391tAc1von9xiBpC7TbYJRLPPNoPSpPYUQONqsWggojSB52zeqtYNDjFd+b5LyhzLMnKLyp86Z+g+Xlcj2K1zdL97JNnKqS8VHF5LbP0= Received: by 10.65.233.16 with SMTP id k16mr615241qbr.1174444446427; Tue, 20 Mar 2007 19:34:06 -0700 (PDT) Received: from ?192.168.3.211? ( [210.13.108.117]) by mx.google.com with ESMTP id 12sm7455432nzn.2007.03.20.19.34.03; Tue, 20 Mar 2007 19:34:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20070320120018.A6B7D16A5B3@hub.freebsd.org> References: <20070320120018.A6B7D16A5B3@hub.freebsd.org> Content-Type: text/plain; charset=GB2312; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: rhinux Date: Wed, 21 Mar 2007 10:33:59 +0800 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.752.2) Subject: Re: freebsd-net Digest, Vol 207, Issue 2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 02:59:08 -0000 =D4=DA 2007-3-20=A3=AC=CF=C2=CE=E78:00=A3=ACfreebsd-net-request@freebsd.or= g =D0=B4=B5=C0=A3=BA > Send freebsd-net mailing list submissions to > freebsd-net@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-net > or, via email, send a message with subject or body 'help' to > freebsd-net-request@freebsd.org > > You can reach the person managing the list at > freebsd-net-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-net digest..." > > > Today's Topics: > > 1. Re: Wireshark (Shteryana Shopova) > 2. Interface index hack in IP_ADD_MEMBERSHIP (Bruce M Simpson) > 3. Re: Interface index hack in IP_ADD_MEMBERSHIP (Eugene Grosbein) > 4. Re: [PATCH] bge(4) patch for -STABLE (Pete French) > 5. Re: Interface index hack in IP_ADD_MEMBERSHIP (Bruce M Simpson) > 6. Re: rc.order wrong (ipfw) (Doug Barton) > 7. Re: Wireshark (Randall Stewart) > 8. Re: [PATCH] bge(4) patch for -STABLE (Mike Tancsa) > 9. Re: [PATCH] bge(4) patch for -STABLE (Pete French) > 10. [PATCH] Multicast refcounting in network stack (Bruce M Simpson) > 11. Re: [PATCH] Multicast refcounting in network stack > (Andre Oppermann) > 12. Re: netisr_direct (Keith Arner) > 13. networking code and splx() (Ignacio Rey) > 14. Re: rc.order wrong (ipfw) (David Gilbert) > 15. Re: networking code and splx() (Julian Elischer) > 16. Re: networking code and splx() (Bruce M. Simpson) > 17. Re: PMTU Discovery support (Kevin Lahey) > 18. Re: PMTU Discovery support (Kevin Lahey) > 19. Re: PMTU Discovery support (Bruce M. Simpson) > 20. Re: [PATCH] Multicast refcounting in network stack > (Bruce M Simpson) > 21. ifstated behavior (Alexandre Biancalana) > 22. Re: networking code and splx() (John Hay) > 23. Re: networking code and splx() (Eygene Ryabinkin) > 24. "em" driver shuts down interface when "ifconfig media > 100baseTX" is invoked (Infraservice hostmaster) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 19 Mar 2007 14:25:49 +0200 > From: "Shteryana Shopova" > Subject: Re: Wireshark > To: "manuel.ochoa@yahoo.com" > Cc: Max Laier , freebsd-net@freebsd.org > Message-ID: > <61b573980703190525s30f22648od0ecdecd01879d0c@mail.gmail.com> > Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed > > On 3/19/07, manuel.ochoa@yahoo.com wrote: >> Max, correct me if I'm wrong but tcpdump will only give you the =20 >> headers, is that correct? This is fine most of the time but =20 >> sometimes I need to capture full frames. > > Nope - that's not correct - > > #tcpdump -s 0 > > will capture full frames. > > Shteryana > >> >> Thanks >> Manuel Ochoa CCNP MCSA MCSE MCDBA >> >> >> >> >> ----- Original Message ---- >> From: Max Laier >> To: freebsd-net@freebsd.org >> Cc: manuel.ochoa@yahoo.com >> Sent: Saturday, March 17, 2007 2:05:06 PM >> Subject: Re: Wireshark >> >> >> 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 =20 >>> FreeBSD >>> box for CLI only. Thanks, >> >> What's wrong with tcpdump(8)? Other than that building either the =20= >> real or >> the -lite version with "WITHOUT_X11" defined will get you the >> cli-version. "-lite" seems to just disable a couple of dissectors =20= >> that >> have a lot of external dependencies. >> >> -- >> /"\ Best regards, | mlaier@freebsd.org >> \ / Max Laier | ICQ #67774661 >> X http://pf4freebsd.love2party.net/ | mlaier@EFnet >> / \ ASCII Ribbon Campaign | Against HTML Mail and News >> >> >> >> _____________________________________________________________________=20= >> _______________ >> Expecting? Get great news right away with email Auto-Check. >> Try the Yahoo! Mail Beta. >> http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-=20 >> unsubscribe@freebsd.org" >> > > > ------------------------------ > > Message: 2 > Date: Mon, 19 Mar 2007 14:28:52 +0000 > From: Bruce M Simpson > Subject: Interface index hack in IP_ADD_MEMBERSHIP > To: net@FreeBSD.org > Message-ID: <45FE9E24.8010201@incunabulum.net> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Hi, > > I plan to get rid of the ugly little ip_multicast_if() hack in the IP > stack.=3D > Before I do, is anyone actually using this? > > RFC 3678 specifies a protocol independent API for socket group > memberships which allow joins on interfaces referenced by index. =20 > This is > intended to support IGMPv3 and MLDv2. > > Regards, > BMS > > > > > ------------------------------ > > Message: 3 > Date: Mon, 19 Mar 2007 22:28:37 +0700 > From: Eugene Grosbein > Subject: Re: Interface index hack in IP_ADD_MEMBERSHIP > To: Bruce M Simpson > Cc: net@freebsd.org > Message-ID: <20070319152837.GA3984@svzserv.kemerovo.su> > Content-Type: text/plain; charset=3Dus-ascii > > On Mon, Mar 19, 2007 at 02:28:52PM +0000, Bruce M Simpson wrote: > >> I plan to get rid of the ugly little ip_multicast_if() hack in the IP >> stack.=3D >> Before I do, is anyone actually using this? >> >> RFC 3678 specifies a protocol independent API for socket group >> memberships which allow joins on interfaces referenced by index. =20 >> This is >> intended to support IGMPv3 and MLDv2. > > I recall that routed and ripd used to utilize something similar > long time ago. I'm not sure if they have switched to another API. > > Eugene > > > ------------------------------ > > Message: 4 > Date: Mon, 19 Mar 2007 16:28:58 +0000 > From: Pete French > Subject: Re: [PATCH] bge(4) patch for -STABLE > To: freebsd-net@FreeBSD.org, jkim@FreeBSD.org > Cc: freebsd-stable@FreeBSD.org > Message-ID: > >> I have made bge(4) patch for -STABLE (sorry, not suitable for >> RELENG_6_2): > > What dates stable is this relative to ? I am trying to apply your > patch to a cvsup of stable pulled on the day/time you sent your email, > but parts of it are failing for me unfortunately. I would like to =20 > test this > as I have a nmuber of bge interfaces running on some systems. > > -pete. > > > ------------------------------ > > Message: 5 > Date: Mon, 19 Mar 2007 16:51:29 +0000 > From: Bruce M Simpson > Subject: Re: Interface index hack in IP_ADD_MEMBERSHIP > To: Eugene Grosbein > Cc: net@freebsd.org > Message-ID: <45FEBF91.2000709@incunabulum.net> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Eugene Grosbein wrote: >> >> I recall that routed and ripd used to utilize something similar >> long time ago. I'm not sure if they have switched to another API. >> > You're right -- this would break routed on point-to-point interfaces. > > They didn't, unless it was updated at the upstream, i.e. rhyolite.com. > > This means that the RFC1724 hack can't be safely deprecated without > breaking this use case, until routed is updated to use the RFC 3678 > protocol-independent ASM API. > > Linux uses a slightly different technique to work-around this; ip_mreq > is expanded to ip_mreqn internally, and the interface index is > explicitly passed around in the kernel. > > The blocker in the FreeBSD case which prevents us simply adopting this > is the source interface selection logic in ip_output(). > > Regards, > BMS > > > ------------------------------ > > Message: 6 > Date: Mon, 19 Mar 2007 10:03:42 -0700 > From: Doug Barton > Subject: Re: rc.order wrong (ipfw) > To: Kian Mohageri > Cc: freebsd-net@freebsd.org, Mark Andrews , > freebsd-rc@freebsd.org > Message-ID: <45FEC26E.40504@FreeBSD.org> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Kian Mohageri wrote: > >> After re-reading your original idea, I think I understand a little >> better what you mean to do. For clarification, are you proposing =20 >> that >> the [early] firewall scripts do nothing if =20 >> firewall_late_enable=3DYES, and >> then have all firewalling taken care of later in the boot process =20 >> (i.e. >> post-networking) by firewall_late? >> >> I think I might have misunderstood your original proposal:) > > I think so too. :) To be clear, what I'm suggesting is that we move > ipfw and pf to a spot in the rcorder that is ahead of netif, along > with ipfilter which is already there. I am not suggesting that we > change their functionality, just the ordering. As a completely > separate thing (although they could be done at the same time) I am > suggesting _adding_ a new script for "late" firewall rules (where > "late" is defined as after netif) so that people who want to do > firewall-related things that require netif (like cloned interfaces, > FQDN rules, etc.) will have a standard way to accomplish that. > > Thanks for the opportunity to clarify, > > Doug > > --=20 > > This .signature sanitized for your protection > > > > ------------------------------ > > Message: 7 > Date: Mon, 19 Mar 2007 13:41:21 -0400 > From: Randall Stewart > Subject: Re: Wireshark > To: Shteryana Shopova > Cc: Max Laier , "manuel.ochoa@yahoo.com" > , freebsd-net@freebsd.org > Message-ID: <45FECB41.3070601@cisco.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Shteryana Shopova wrote: >> On 3/19/07, manuel.ochoa@yahoo.com wrote: >>> Max, correct me if I'm wrong but tcpdump will only give you the >>> headers, is that correct? This is fine most of the time but =20 >>> sometimes >>> I need to capture full frames. >> >> Nope - that's not correct - >> >> #tcpdump -s 0 >> >> will capture full frames. > > But nothing IMO beats wireshark for being able > to go in and analyze a dump .. searching on various > condition's fields etc.. > > It does not matter to me generally how its collected > wireshark/tcpdump -s 0.. > > But to analyze it.. give me wireshark any day :-D > > R > > > --=20 > Randall Stewart > NSSTG - Cisco Systems Inc. > 803-345-0369 803-317-4952 (cell) > > > ------------------------------ > > Message: 8 > Date: Mon, 19 Mar 2007 13:51:48 -0400 > From: Mike Tancsa > Subject: Re: [PATCH] bge(4) patch for -STABLE > To: Pete French , > freebsd-net@freebsd.org, jkim@freebsd.org > Cc: freebsd-stable@freebsd.org > Message-ID: <200703191753.l2JHreQ3061174@lava.sentex.ca> > Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed > > At 12:28 PM 3/19/2007, Pete French wrote: >>> I have made bge(4) patch for -STABLE (sorry, not suitable for >>> RELENG_6_2): >> >> What dates stable is this relative to ? I am trying to apply your >> patch to a cvsup of stable pulled on the day/time you sent your =20 >> email, >> but parts of it are failing for me unfortunately. I would like to =20 >> test this >> as I have a nmuber of bge interfaces running on some systems. > > Mine applied cleanly to sources from last Friday. So far so good for > me in that I have not yet seen the watchdog timeout (previously once > every 4 days or so) but its too early to tell. Still, I have not > seen any regressions with it yet since installing it last > Saturday. This is a fairly busy recursive DNS server > > ---Mike > > > > ------------------------------ > > Message: 9 > Date: Mon, 19 Mar 2007 18:08:23 +0000 > From: Pete French > Subject: Re: [PATCH] bge(4) patch for -STABLE > To: freebsd-net@freebsd.org, jkim@freebsd.org, mike@sentex.net > Cc: freebsd-stable@freebsd.org > Message-ID: > >> Mine applied cleanly to sources from last Friday. > > O.K., that works (now I have the correct date in my supfile). Will > give it a shot... > > -pete. > > > ------------------------------ > > Message: 10 > Date: Mon, 19 Mar 2007 18:52:32 +0000 > From: Bruce M Simpson > Subject: [PATCH] Multicast refcounting in network stack > To: freebsd-net@freebsd.org > Message-ID: <45FEDBF0.4050105@incunabulum.net> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Hi, > > A patch against -CURRENT is now available: > http://people.freebsd.org/~bms/dump/multi_refcounting.diff > > This is a fairly sweeping architectural change which should resolve > memory leaks and potential panics with the network stack as a =20 > whole, to > better support interface detach at runtime. > > I'd like to check it in as soon as possible as it fixes the root cause > of the problems we have had with carp and pfsync in our stack. NetBSD > has implemented refcounting like this for some time now, so it does =20= > not > suffer from the same problems. > > Regards, > BMS > > > ------------------------------ > > Message: 11 > Date: Mon, 19 Mar 2007 20:11:56 +0100 > From: Andre Oppermann > Subject: Re: [PATCH] Multicast refcounting in network stack > To: Bruce M Simpson > Cc: freebsd-net@freebsd.org > Message-ID: <45FEE07C.4060501@freebsd.org> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Bruce M Simpson wrote: >> Hi, >> >> A patch against -CURRENT is now available: >> http://people.freebsd.org/~bms/dump/multi_refcounting.diff >> >> This is a fairly sweeping architectural change which should resolve >> memory leaks and potential panics with the network stack as a =20 >> whole, to >> better support interface detach at runtime. >> >> I'd like to check it in as soon as possible as it fixes the root =20 >> cause >> of the problems we have had with carp and pfsync in our stack. NetBSD >> has implemented refcounting like this for some time now, so it =20 >> does not >> suffer from the same problems. > > Patch looks good. :-) > > --=20 > Andre > > > > ------------------------------ > > Message: 12 > Date: Mon, 19 Mar 2007 15:54:55 -0400 > From: "Keith Arner" > Subject: Re: netisr_direct > To: "Robert Watson" > Cc: net@freebsd.org > Message-ID: > <8e552a500703191254qba4e194y810eb99a9f07bed8@mail.gmail.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > On 3/11/07, Robert Watson wrote: >> >> >> There are several ways we could start to reduce contention on that =20= >> lock: >> >> (3) Move towards greater granularity of locking for the tcbinfo: =20 >> instead >> of >> a single mutex, move to more than one locks, so that different >> connections >> processed simultaneously are likely to involve different =20 >> locks. For >> listen sockets, we would have to have a special case, such as a >> single >> lock to serialize simultaneous lock acquisitions of multiple =20 >> chain >> locks >> (for example). >> > > I've been thinking about this approach, and it does sound like the =20 > simplest > to > implement of the three proposed. However, the special case of the =20 > listen > socket > seems like it would complicate matters. > > It seems to me, however, that the complication of the listen socket =20= > could be > simplified > if the listen sockets were maintained in a separate pcb list from =20 > the rest > of the TCP > sockets (the fully connected sockets). If the two types of sockets =20= > were > thus separated, > the code would acquire the lock on the bucket in the connect hash, and > search the connect > hash; if there was a miss, acquire the lock on the listen list and =20 > then > search the listen list. > > The lock on the listen list should follow the locks on the connect =20 > buckets > in the locking > order. The connection bucket should be locked first, as delivery =20 > of data > would be > the common case. To create a new connection in the tcp_input path, =20= > both the > connect > bucket and the listen list would need to be locked (connect bucket =20 > as a new > entry would > be added to the list, and listen list as the accept socket would be > protected from going away). > > Keith > > > ------------------------------ > > Message: 13 > Date: Mon, 19 Mar 2007 20:37:09 +0100 > From: Ignacio Rey > Subject: networking code and splx() > To: freebsd-net@freebsd.org > Message-ID: <20070319203709.1272a470@debian> > Content-Type: text/plain; charset=3DUS-ASCII > > Hello everyone, > > I'm studying a bit the FreeBSD networking code. > > I've read "TCP/IP illustrated vol 2" by G. R. Wright and W. R. =20 > Stevens, > which describes code in 4.4BSD-lite. > > Now I'm taking a look at FreeBSD 6.2 release. Some things are =20 > different, > many others kept the same. What I'm confused about is that in 4.4BSD > there are many calls to the splx() family of functions, and I =20 > didn't see > any of them in the networking code in FreeBSD. However the 'grep' =20 > program > showed me that they are used in other parts of the kernel. > > > The question is: Have calls to these functions been wrapped? or are =20= > they > simply not used in this context? > > > Thanks in advance, > > Ignacio > > > ------------------------------ > > Message: 14 > Date: Mon, 19 Mar 2007 15:12:52 -0500 > From: David Gilbert > Subject: Re: rc.order wrong (ipfw) > To: Doug Barton > Cc: freebsd-net@freebsd.org, Mark Andrews , = Kian > Mohageri , freebsd-rc@freebsd.org > Message-ID: <17918.61124.353668.804988@canoe.dclg.ca> > Content-Type: text/plain; charset=3Dus-ascii > >>>>>> "Doug" =3D=3D Doug Barton writes: > > Doug> Kian Mohageri wrote: >>> I agree VERY MUCH with this sort of approach. It would be a much >>> cleaner solution than completely separate handling of all of these >>> different problems. I'm trying to get an idea of what all of the >>> major problems with the current order are, and these are the ones >>> I'm aware of: >>> >>> - ipfw blocks by default (names unresolvable, rtsol breaks) - >>> ipf/pf pass by default (services are unprotected) >>> >>> I think a firewall_boot script (similar to what you've proposed) >>> could potentially solve all of these problems. > > Doug> exception, not the rule. Furthermore (and I'm betraying a > Doug> prejudice here) I think that firewall rules that rely on name > Doug> resolution are absolutely nuts, and I say that with many years > Doug> of experience as a professional DNS and system administrator. > > I think you're misreading the above. The poster is saying that > because ipfw's default behaviour is block, loading it at the wrong > time can break other startup items because they require name > resolution or the sending of packets (rtsol). > > Dave. > > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > =3D=3D=3D=3D=3D=3D > |David Gilbert, Independent Contractor. | Two things can =20 > be | > |Mail: dave@daveg.ca | equal if and only =20 > if they | > |http://daveg.ca | are precisely =20 > opposite. | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3DGLO=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > =3D=3D=3D=3D=3D=3D > > > ------------------------------ > > Message: 15 > Date: Mon, 19 Mar 2007 13:23:17 -0700 > From: Julian Elischer > Subject: Re: networking code and splx() > To: Ignacio Rey > Cc: freebsd-net@freebsd.org > Message-ID: <45FEF135.2050203@elischer.org> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Ignacio Rey wrote: >> Hello everyone, >> >> I'm studying a bit the FreeBSD networking code. >> >> I've read "TCP/IP illustrated vol 2" by G. R. Wright and W. R. =20 >> Stevens, >> which describes code in 4.4BSD-lite. >> >> Now I'm taking a look at FreeBSD 6.2 release. Some things are =20 >> different, >> many others kept the same. What I'm confused about is that in 4.4BSD >> there are many calls to the splx() family of functions, and I =20 >> didn't see >> any of them in the networking code in FreeBSD. However the 'grep' =20 >> program >> showed me that they are used in other parts of the kernel. > > There was a major change in the way that synchronization was done =20 > bewteen FreeBSD 4.x > and FreeBSD 5.X. > The changes were to support real multiprocessor operation and were =20 > extensive. > The 'spl" method of operation was only able to protect operation on =20= > a single CPU. > > You should probably get a copy of "The design of the FreeBSD (um =20 > 5.2 I think) > Operating System by Kirk McKusick and George Neville-Neil. > It goes into some of the changes. (many changes have happenned =20 > since then too). > the New locking largely depends on Mutexes. > >> >> >> The question is: Have calls to these functions been wrapped? or =20 >> are they >> simply not used in this context? >> >> >> Thanks in advance, >> >> Ignacio >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-=20 >> unsubscribe@freebsd.org" > > > > ------------------------------ > > Message: 16 > Date: Mon, 19 Mar 2007 22:14:33 +0000 > From: "Bruce M. Simpson" > Subject: Re: networking code and splx() > To: Ignacio Rey > Cc: freebsd-net@freebsd.org > Message-ID: <45FF0B49.9060008@FreeBSD.org> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Ignacio Rey wrote: >> ... >> The question is: Have calls to these functions been wrapped? or =20 >> are they >> simply not used in this context? >> > splx() and friends have been no-ops since FreeBSD 5.x was branched. > Synchronization is now done using other mechanisms such as mutexes and > spin locks. See the new man page locking(9) in -CURRENT. > > Regards, > BMS > > > ------------------------------ > > Message: 17 > Date: Mon, 19 Mar 2007 14:54:22 -0700 > From: Kevin Lahey > Subject: Re: PMTU Discovery support > To: freebsd-net@freebsd.org > Message-ID: <20070319145422.39bfddcd@yakko.patheticgeek.net> > Content-Type: text/plain; charset=3DUS-ASCII > > On Tue, 6 Mar 2007 10:35:42 +0530 > "aditya kiran" wrote: > >> RFC 1191 says to increase the PMTU at some itnerval (15 minutes =20 >> default) > > 10 minutes. > >> next time a packet is sent, this will be used... and if PMTU is =20 >> really >> increased, >> no ICMP error will be recieved. that shows an increase in the =20 >> PMTU. I'm >> trying to >> understand if this mechanism is there in freebsd. any on this is =20 >> appreicated > > It looks to me as though FreeBSD stores per-host MTU data in the > hostcache, which gets purged after five minutes of inactivity. If > that's actually how it works, then, yes, FreeBSD should indeed > periodically probe for larger PMTUs. > > Of course, the real test is to set up a few hosts and see what > happens, rather than speculating based on a quick perusal of the > code. :-) > > Kevin > kml@patheticgeek.net > > > ------------------------------ > > Message: 18 > Date: Mon, 19 Mar 2007 17:21:56 -0700 > From: Kevin Lahey > Subject: Re: PMTU Discovery support > To: freebsd-net@freebsd.org > Message-ID: <20070319172156.68cba0a9@yakko.patheticgeek.net> > Content-Type: text/plain; charset=3DUS-ASCII > > On Mon, 19 Mar 2007 14:54:22 -0700 > Kevin Lahey wrote: > >> Of course, the real test is to set up a few hosts and see what >> happens, rather than speculating based on a quick perusal of the >> code. :-) > > After my slap-dash read of the current FreeBSD code, I was a little > concerned that I'd missed something. As penance, I set up a quick > experiment with four hosts connected in a line, A <-> B <-> C <-> D, > set the MTU on the links from B to C to 512, and ran ttcp from A to D. > PMTUD worked correctly. Then I suspended the ttcp process, went away > for an hour, and resumed it. Watching tcpdump, it appears that 512 > octet packets continued to be sent, with no attempt at probing. > > That would seem to be a bug. > > The boxes were running FreeBSD-6.1, but I can't really vouch for the > particular kernel configuration. It could well be that the problem is > with the loose nut behind the wheel, rather than with FreeBSD. :-) > > Kevin > kml@patheticgeek.net > > > ------------------------------ > > Message: 19 > Date: Tue, 20 Mar 2007 01:47:27 +0000 > From: "Bruce M. Simpson" > Subject: Re: PMTU Discovery support > To: Kevin Lahey > Cc: freebsd-net@freebsd.org > Message-ID: <45FF3D2F.3040000@FreeBSD.org> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Kevin Lahey wrote: >> >> The boxes were running FreeBSD-6.1, but I can't really vouch for the >> particular kernel configuration. It could well be that the =20 >> problem is >> with the loose nut behind the wheel, rather than with FreeBSD. :-) >> > > I believe PMTU measurements may only be relied upon for active TCP > connections, but it's been a while since I read this code. > > It would be useful if non-TCP drivers such as gre(4) could be extended > to perform PMTU discovery and auto-tune their MTU based on this, as > manually setting the MTU is a bit random and can result in horrible > fragmentation when going across the big-I Internet. > > I imagine doing this would require changes to the icmp input path =20 > and a > bit of abstraction. > > Regards, > BMS > > > ------------------------------ > > Message: 20 > Date: Tue, 20 Mar 2007 01:48:00 +0000 > From: Bruce M Simpson > Subject: Re: [PATCH] Multicast refcounting in network stack > To: Andre Oppermann > Cc: freebsd-net@freebsd.org > Message-ID: <45FF3D50.3050604@incunabulum.net> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Andre Oppermann wrote: >>> http://people.freebsd.org/~bms/dump/multi_refcounting.diff >> Patch looks good. :-) > Committed, with some changes. > > Regards, > BMS > > > ------------------------------ > > Message: 21 > Date: Tue, 20 Mar 2007 00:22:55 -0300 > From: Alexandre Biancalana > Subject: ifstated behavior > To: freebsd-net@freebsd.org > Message-ID: <45FF538F.1050405@seudns.net> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Hi list, > > First, excuse-me by the off-topic message, I asked this on -=20 > questions > but I don't have any answer. > > I'm trying to setup ifstated to check two links and if some go down, > do some actions like change pf rules and machine's route. > > My doubt is about the execution order/repetition of the states =20 > body of > ifstated.conf, in all configs that I tried just the last check is > executed always, follow and example: > > ifstated.conf: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > loglevel debug > > ping1 =3D '( "ping -q -c 1 -t 3 www.site1.com > > /dev/null" every 10 ) ' > ping2 =3D '( "ping -q -c 1 -t 3 www.site2.com > > /dev/null" every 10 ) ' > > state one { > if ! ( $ping1 && $ping2 ) { > set-state two > } > } > > state two { > > init { > run "logger -p console.notice -t ifstated 'Restarting > network !'" > } > > if ( $ping && $ping2 ) { > set-state one > } > } > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > # ifstated -dv > ping1 =3D "( "ping -q -c 1 -t 3 www.site1.com > > /dev/null" every 10 ) " > ping2 =3D "( "ping -q -c 1 -t 3 www.site2.com > > /dev/null" every 10 ) " > ifstated: initial state: one > ifstated: changing state to one > ifstated: running ping -q -c 1 -t 3 www.site1.com www.site1.com> >> /dev/null > ifstated: running ping -q -c 1 -t 3 www.site2.com www.site2.com> >> /dev/null > ifstated: started > ifstated: changing state to two > ifstated: running ping -q -c 1 -t 3 www.site1.com www.site1.com> >> /dev/null > ifstated: running ping -q -c 1 -t 3 www.site2.com www.site2.com> >> /dev/null > ifstated: running ping -q -c 1 -t 3 www.site2.com www.site2.com> >> /dev/null > ifstated: running ping -q -c 1 -t 3 www.site2.com www.site2.com> >> /dev/null > > > As you can see, after change state ifstated execute only the *last* > check command of the statement (ping2) forever.... > > This is the expected behavior ? > > I'm running 6-STABLE + ifstated-20050505 (instaled via > /usr/ports/net/ifstated) > > Thanks for any help. > > Alexandre > > > ------------------------------ > > Message: 22 > Date: Tue, 20 Mar 2007 09:31:50 +0200 > From: John Hay > Subject: Re: networking code and splx() > To: "Bruce M. Simpson" > Cc: freebsd-net@freebsd.org > Message-ID: <20070320073150.GA19859@zibbi.meraka.csir.co.za> > Content-Type: text/plain; charset=3Dus-ascii > > On Mon, Mar 19, 2007 at 10:14:33PM +0000, Bruce M. Simpson wrote: >> Ignacio Rey wrote: >>> ... >>> The question is: Have calls to these functions been wrapped? or =20 >>> are they >>> simply not used in this context? >>> >> splx() and friends have been no-ops since FreeBSD 5.x was branched. >> Synchronization is now done using other mechanisms such as mutexes =20= >> and >> spin locks. See the new man page locking(9) in -CURRENT. > > It does not seem to get installed: > > Doing a grep for locking in /usr/src/share/man/man9/Makefile produce > nothing. > > John > --=20 > John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org > > > ------------------------------ > > Message: 23 > Date: Tue, 20 Mar 2007 10:40:51 +0300 > From: Eygene Ryabinkin > Subject: Re: networking code and splx() > To: John Hay > Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" > Message-ID: <20070320074051.GH96806@codelabs.ru> > Content-Type: text/plain; charset=3Dkoi8-r > > John, good day. > > Tue, Mar 20, 2007 at 09:31:50AM +0200, John Hay wrote: >>>> >>> splx() and friends have been no-ops since FreeBSD 5.x was branched. >>> Synchronization is now done using other mechanisms such as =20 >>> mutexes and >>> spin locks. See the new man page locking(9) in -CURRENT. >> >> It does not seem to get installed: > > The locking.9 is not the part of the current build as the comment > of the initial commit of that file says. > >> Doing a grep for locking in /usr/src/share/man/man9/Makefile produce >> nothing. > > But if you're running -CURRENT, then you can view the page from > the sources (assuming that you have the system sources in /usr/src/): > $ groff -Tascii -mandoc /usr/src/share/man/man9/locking.9 | less > > Our you can download the locking.9 from > http://www.freebsd.org/cgi/cvsweb.cgi/src/share/man/man9/locking.9 > --=20 > Eygene > > > ------------------------------ > > Message: 24 > Date: Tue, 20 Mar 2007 04:19:55 -0400 (EDT) > From: Infraservice hostmaster > Subject: "em" driver shuts down interface when "ifconfig media > 100baseTX" is invoked > To: freebsd-net@freebsd.org > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii > > > FreeBSD cg-gw 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #10: Tue Jan 16 =20= > 01:40:27 EST 2007 root@taint:/usr/obj/usr/src/sys/FW-YQ i386 > > > I did: > "ifconfig em2 media 100baseTX mediaopt full-duplex" > > ifconfig em2 now reports: > ... > media: Ethernet 100baseTX (autoselect) > status: no carrier > > "ifconfig em2 media 100baseTX" also does this > > > We tried it on 2 different 100baseTX interfaces with the same result > > "ifconfig em2 media autonegotiate" brings the interface back up > > > It doesn't seem to happen on another interface which autonegotiates > 10baseT half-duplex, however > > > This seems to indicate there might be a driver problem since > the 2 interfaces connect to very different kinds of equipment > > > Any suggestions? > > > > ------------------------------ > > _______________________________________________ > 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" > > End of freebsd-net Digest, Vol 207, Issue 2 > ******************************************* From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 03:52:02 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 F023616A409; Wed, 21 Mar 2007 03:52:02 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA0413C44B; Wed, 21 Mar 2007 03:52:02 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2L3dd9H021191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Mar 2007 05:39:45 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2L3dJGF010989; Wed, 21 Mar 2007 05:39:31 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2L3dIU4010979; Wed, 21 Mar 2007 05:39:18 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Wed, 21 Mar 2007 05:39:18 +0200 From: Giorgos Keramidas To: John Hay Message-ID: <20070321033918.GA8576@kobe.laptop> References: <20070319203709.1272a470@debian> <45FF0B49.9060008@FreeBSD.org> <20070320073150.GA19859@zibbi.meraka.csir.co.za> <20070320074051.GH96806@codelabs.ru> <20070320120043.GA32312@zibbi.meraka.csir.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070320120043.GA32312@zibbi.meraka.csir.co.za> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.51, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.69, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: networking code and splx() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 03:52:03 -0000 On 2007-03-20 14:00, John Hay wrote: > On Tue, Mar 20, 2007 at 10:40:51AM +0300, Eygene Ryabinkin wrote: > > > Doing a grep for locking in /usr/src/share/man/man9/Makefile > > > produce nothing. > > > > But if you're running -CURRENT, then you can view the page from the > > sources (assuming that you have the system sources in /usr/src/): > > $ groff -Tascii -mandoc /usr/src/share/man/man9/locking.9 | less > > > > Our you can download the locking.9 from > > http://www.freebsd.org/cgi/cvsweb.cgi/src/share/man/man9/locking.9 > > Yes, but you must know what you are looking for. The nice unix tools, > man -k and apropos, is not your friend anymore. But they will be again, once the manpage is "connected to the build" :) Since the manpage is pending review, it's actually a very good thing that it is already part of the source tree, but it doesn't "sneak into" normal buildworld/installworld builds. This way we get the best of both worlds: we can read it before it actually goes live, *and* we keep the install tree clean from files which may go away of even be replaced before they reach their final version :) From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 04:18: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 864C216A40A for ; Wed, 21 Mar 2007 04:18:41 +0000 (UTC) (envelope-from smw2010@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 1DF0D13C468 for ; Wed, 21 Mar 2007 04:18:40 +0000 (UTC) (envelope-from smw2010@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so140836ugh for ; Tue, 20 Mar 2007 21:18:40 -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=b1RNzmfRyaoSQmjThprmYxp+b1JMU4S9XMxqZ1TyQguIjNNxYWlhO6l+MdpPdYBgx5ctiaxLAlQiC66EJKgzrlepqAyeq7ADcn5Z2vjnx7lZr5wwoI2gNKDsu/n932N1My8w5CNEBRKX3L7KIlJFR7SrHNzs5fENn3KpU9DzEZQ= 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=Rz3hegNjKGZgFeKyNIZ7A244ZybK5GYneY0IY+wlzB9KYhHXx0WzftAlDHNDrf2C3VRaq6E9Lw27/kh2AgAFr6q4Ih4BpLH0EBWoLqfj0hzBWLWN12bDBgyolFHNkzxKcfX8vP4iMojEtQcWCH1w7Hfp6vkXy3ce1gYxuJ3dnG0= Received: by 10.114.27.20 with SMTP id a20mr21471waa.1174450719151; Tue, 20 Mar 2007 21:18:39 -0700 (PDT) Received: by 10.114.254.5 with HTTP; Tue, 20 Mar 2007 21:18:39 -0700 (PDT) Message-ID: Date: Wed, 21 Mar 2007 15:18:39 +1100 From: "Sam Wun" 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: MPLS implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 04:18:41 -0000 Hi, Is there any MPLS implementation for FreeBSD? I found a port ayame mpls for netbsd, but the last implementation was dated back to 2003, seems very old. Thanks S From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 09:05: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 7A78B16A407 for ; Wed, 21 Mar 2007 09:05:24 +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 52C4213C46C for ; Wed, 21 Mar 2007 09:05:24 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id E0D7720A017; Wed, 21 Mar 2007 05:05:17 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Wed, 21 Mar 2007 05:05:17 -0400 X-Sasl-enc: Rtss3CMemqTzEgtD67iEBLqqLv0p+NHkKEXtrCI+qslA 1174467916 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 22A38331AA; Wed, 21 Mar 2007 05:05:16 -0400 (EDT) Message-ID: <4600F54A.10501@FreeBSD.org> Date: Wed, 21 Mar 2007 09:05:14 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: Sam Wun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: MPLS implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 09:05:24 -0000 Sam Wun wrote: > Hi, > > Is there any MPLS implementation for FreeBSD? > I found a port ayame mpls for netbsd, but the last implementation was > dated > back to 2003, seems very old. There is NISTswitch, but it is most likely very bit-rotted by now. I would suggest helping Anihudda Bodhra out on the Click port as it would be a great starting point for prototyping MPLS due to how Click will most likely attach to the kernel forwarding paths. The key to success with MPLS is to learn from the layer 2 forwarding stuff in if_bridge; to integrate cleanly with the Ethernet code; to use ALTQ for the token bucket filter and traffic classification policies; and to not break the regular forwarding path. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 09:07:00 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 B5E7516A402 for ; Wed, 21 Mar 2007 09:07:00 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 8CA2C13C483 for ; Wed, 21 Mar 2007 09:07:00 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l2L94GE0086282; Wed, 21 Mar 2007 02:05:17 -0700 (PDT) Date: Wed, 21 Mar 2007 18:04:15 +0900 Message-ID: From: gnn@freebsd.org To: Bruce M Simpson In-Reply-To: <460073E8.2080803@incunabulum.net> References: <460073E8.2080803@incunabulum.net> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: net@freebsd.org Subject: Re: Proposal: Merge RFC3678 multicast APIs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 09:07:00 -0000 At Tue, 20 Mar 2007 23:53:12 +0000, Bruce M Simpson wrote: > > Hi, > > I propose that we merge the RFC3678 advanced multicast APIs. Doing so > gets us closer to IGMPv3 and SSM. I would greatly appreciate suggestions > about how to deal with the include header issue below. > If you're up for it I think it's a good idea. I didn't see any downsides, but I figure given what it breaks it can't go into 6 easily. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 09:26:32 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 67DD616A401 for ; Wed, 21 Mar 2007 09:26:32 +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 8D40613C4E1 for ; Wed, 21 Mar 2007 09:26:28 +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 l2L9Q9l2062537; Wed, 21 Mar 2007 12:26:09 +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 l2L9Q6sj062534; Wed, 21 Mar 2007 12:26:06 +0300 (MSK) (envelope-from yar) Date: Wed, 21 Mar 2007 12:26:05 +0300 From: Yar Tikhiy To: Bruce M Simpson Message-ID: <20070321092605.GB41715@comp.chem.msu.su> References: <45FE9E24.8010201@incunabulum.net> <20070319152837.GA3984@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070319152837.GA3984@svzserv.kemerovo.su> User-Agent: Mutt/1.5.9i Cc: Eugene Grosbein , net@freebsd.org Subject: Re: Interface index hack in IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 09:26:32 -0000 On Mon, Mar 19, 2007 at 10:28:37PM +0700, Eugene Grosbein wrote: > On Mon, Mar 19, 2007 at 02:28:52PM +0000, Bruce M Simpson wrote: > > > I plan to get rid of the ugly little ip_multicast_if() hack in the IP > > stack.= > > Before I do, is anyone actually using this? > > > > RFC 3678 specifies a protocol independent API for socket group > > memberships which allow joins on interfaces referenced by index. This is > > intended to support IGMPv3 and MLDv2. > > I recall that routed and ripd used to utilize something similar > long time ago. I'm not sure if they have switched to another API. Quagga still uses it, too, if its configure script detects FreeBSD or NetBSD. I'm afraid it was me who submitted the patch to the Quagga folks when I'd found that Quagga's ospfd couldn't handle unnumbered P2P interfaces in FreeBSD because their local IPs weren't unique. Unfortunately, Quagga doesn't seem to use the protocol independent part of the RFC 3678 API yet. -- Yar From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 20:19:39 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 8CDD116A46C for ; Wed, 21 Mar 2007 20:19:39 +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 D47CB13C4C9 for ; Wed, 21 Mar 2007 20:19:38 +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 l2LKJbqm083859 for ; Wed, 21 Mar 2007 23:19: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 l2LKJaiH083858 for net@freebsd.org; Wed, 21 Mar 2007 23:19:36 +0300 (MSK) (envelope-from yar) Date: Wed, 21 Mar 2007 23:19:36 +0300 From: Yar Tikhiy To: net@freebsd.org Message-ID: <20070321201936.GN41715@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: A dummy Ethernet driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 20:19:39 -0000 Hi folks, We have disc(4) for testing and benchmarking. However, it's a loopback driver, so such things as vlan or bridge cannot attach to it. I needed a similar dummy interface mimicing Ethernet and failed to find a ready solution. I tried ng_eiface+ng_hole, but it just couldn't keep up with gigabit rates. So I knocked up a new dummy driver, edsc(4): Ethernet discard interface. I'd like to commit it if there are no objections. Then it could also serve as the bones of an Ethernet driver for those who study kernel internals or want to write a new driver. -- Yar From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 20:23: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 5D3A516A4E5 for ; Wed, 21 Mar 2007 20:23:21 +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 4A82813C4C9 for ; Wed, 21 Mar 2007 20:23:21 +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 l2LKN6t6001976; Wed, 21 Mar 2007 12:23: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 l2LKN6PY001975; Wed, 21 Mar 2007 13:23:06 -0700 (PDT) (envelope-from rizzo) Date: Wed, 21 Mar 2007 13:23:06 -0700 From: Luigi Rizzo To: Yar Tikhiy Message-ID: <20070321132306.A1936@xorpc.icir.org> References: <20070321201936.GN41715@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: <20070321201936.GN41715@comp.chem.msu.su>; from yar@comp.chem.msu.su on Wed, Mar 21, 2007 at 11:19:36PM +0300 Cc: net@freebsd.org Subject: Re: A dummy Ethernet driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 20:23:21 -0000 On Wed, Mar 21, 2007 at 11:19:36PM +0300, Yar Tikhiy wrote: > Hi folks, > > We have disc(4) for testing and benchmarking. However, it's a > loopback driver, so such things as vlan or bridge cannot attach to > it. I needed a similar dummy interface mimicing Ethernet and failed > to find a ready solution. I tried ng_eiface+ng_hole, but it just > couldn't keep up with gigabit rates. So I knocked up a new dummy > driver, edsc(4): Ethernet discard interface. I'd like to commit it > if there are no objections. Then it could also serve as the bones > of an Ethernet driver for those who study kernel internals or want > to write a new driver. seems like a good idea. cheers luigi > -- > Yar > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 21:08: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 1B76E16A478 for ; Wed, 21 Mar 2007 21:08:12 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 0369813C484 for ; Wed, 21 Mar 2007 21:08:09 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from [192.168.98.246] ([192.168.44.2]) by mail1.cil.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 22:08:08 +0100 Message-ID: <46019EB6.6010209@ide.resurscentrum.se> Date: Wed, 21 Mar 2007 22:08:06 +0100 From: Jon Otterholm User-Agent: Thunderbird 1.5.0.9 (X11/20070131) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <460060A8.1080109@ide.resurscentrum.se> <65531A6A-7178-48A1-97D0-9DCB4F72E315@mac.com> <4600689C.3080306@ide.resurscentrum.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2007 21:08:08.0067 (UTC) FILETIME=[0657E530:01C76BFD] Subject: Re: ICMP-floods X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 21:08:12 -0000 Chuck Swiger wrote: > On Mar 20, 2007, at 4:05 PM, Jon Otterholm wrote: >>>> When setting net.inet.ip.redirect=0 on my routers, the icmp-redirects >>>> disappear, but instead I get a large amount of ICMP-time-exceed >>>> from my >>>> routers. >>> >>> The information you've provided strongly suggests either problems >>> with the netmasks being used, or a routing loop, or some combination >>> of both. >> I have checked netmasks and they are all on the same network. There >> should not be any routing involved in the communication between these >> hosts. > > OK. Care to show a "tcpdump -ntv icmp" illustrating the problem...? :-) Nope :-) I dug a little deeper into this. It seems like my problems are far more extensive than I first expected. I did not mention earlier that all if's are vlan-based sub-intefaces. It seems that if I move admin-if's on my routers to a different physical if than the one with the default route, all weird time-exeed/redir are gone and all traffic on my Nagios-machine are OK. It seems allmost as if my routers can not hold apart inbound traffic destined to different sub-if's on one physical if. Can this be it? I have checked my topology from all around now and I can not find any routing loops. For example: Router1 has it's default route connected to em0.10. With admin-net on em0.20 I get my icmp-floods. Moving admin-net to em1.20 makes the icmp-floods go away. A possible bug in if_vlan? //Jon From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 22:46: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 2D4F216A414 for ; Wed, 21 Mar 2007 22:46:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0B813C48A for ; Wed, 21 Mar 2007 22:46:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 21 Mar 2007 15:04:46 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id CF031125AE4; Wed, 21 Mar 2007 15:32:49 -0700 (PDT) Message-ID: <4601B28B.7090204@elischer.org> Date: Wed, 21 Mar 2007 15:32:43 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Luigi Rizzo References: <20070321201936.GN41715@comp.chem.msu.su> <20070321132306.A1936@xorpc.icir.org> In-Reply-To: <20070321132306.A1936@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yar Tikhiy , net@freebsd.org Subject: Re: A dummy Ethernet driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 22:46:46 -0000 Luigi Rizzo wrote: > On Wed, Mar 21, 2007 at 11:19:36PM +0300, Yar Tikhiy wrote: >> Hi folks, >> >> We have disc(4) for testing and benchmarking. However, it's a >> loopback driver, so such things as vlan or bridge cannot attach to >> it. I needed a similar dummy interface mimicing Ethernet and failed >> to find a ready solution. I tried ng_eiface+ng_hole, but it just >> couldn't keep up with gigabit rates. So I knocked up a new dummy >> driver, edsc(4): Ethernet discard interface. I'd like to commit it >> if there are no objections. Then it could also serve as the bones >> of an Ethernet driver for those who study kernel internals or want >> to write a new driver. > > seems like a good idea. > I think the question I have is why eiface couldn't cope..? I think it should have so I'll look at it.. > cheers > luigi > >> -- >> Yar >> _______________________________________________ >> 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" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 23:12: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 B650716A46D; Wed, 21 Mar 2007 23:12:17 +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 7B74B13C4C8; Wed, 21 Mar 2007 23:12:15 +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 l2LNCENU083108; Wed, 21 Mar 2007 19:12:14 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Wed, 21 Mar 2007 19:12:09 -0400 User-Agent: KMail/1.6.2 References: <200703161430.42854.jkim@FreeBSD.org> In-Reply-To: <200703161430.42854.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200703211912.12391.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2894/Wed Mar 21 18:42:45 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-net@FreeBSD.org Subject: Re: [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: Wed, 21 Mar 2007 23:12:17 -0000 On Friday 16 March 2007 02:30 pm, Jung-uk Kim wrote: > 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. It is committed now but ASF mode is disabled by default because at least two people reported breakage. http://docs.freebsd.org/cgi/mid.cgi?200703212253.l2LMrM9M041854 Thanks for your help! Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 03:53:36 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 A861416A46D for ; Thu, 22 Mar 2007 03:53:36 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 9682D13C43E for ; Thu, 22 Mar 2007 03:53:36 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l2M3r2Mw049094; Wed, 21 Mar 2007 20:53:03 -0700 (PDT) Date: Thu, 22 Mar 2007 11:41:21 +0900 Message-ID: From: gnn@freebsd.org To: Yar Tikhiy In-Reply-To: <20070321201936.GN41715@comp.chem.msu.su> References: <20070321201936.GN41715@comp.chem.msu.su> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.0.95 (i386-apple-darwin8.8.2) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: net@freebsd.org Subject: Re: A dummy Ethernet driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2007 03:53:36 -0000 At Wed, 21 Mar 2007 23:19:36 +0300, Yar Tikhiy wrote: > > Hi folks, > > We have disc(4) for testing and benchmarking. However, it's a > loopback driver, so such things as vlan or bridge cannot attach to > it. I needed a similar dummy interface mimicing Ethernet and failed > to find a ready solution. I tried ng_eiface+ng_hole, but it just > couldn't keep up with gigabit rates. So I knocked up a new dummy > driver, edsc(4): Ethernet discard interface. I'd like to commit it > if there are no objections. Then it could also serve as the bones > of an Ethernet driver for those who study kernel internals or want > to write a new driver. > Works for me and it ought to be able to be the "documentation" interface as well. As in we try to document the (pick expletive) out of it. Best, George From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 15:39:48 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 8D79416A40A for ; Thu, 22 Mar 2007 15:39:48 +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 97E8E13C4CC for ; Thu, 22 Mar 2007 15:39: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 l2MFdW0N006722; Thu, 22 Mar 2007 18:39:32 +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 l2MFdRtj006721; Thu, 22 Mar 2007 18:39:27 +0300 (MSK) (envelope-from yar) Date: Thu, 22 Mar 2007 18:39:26 +0300 From: Yar Tikhiy To: Julian Elischer Message-ID: <20070322153926.GY41715@comp.chem.msu.su> References: <20070321201936.GN41715@comp.chem.msu.su> <20070321132306.A1936@xorpc.icir.org> <4601B28B.7090204@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4601B28B.7090204@elischer.org> User-Agent: Mutt/1.5.9i Cc: Luigi Rizzo , net@freebsd.org Subject: Re: A dummy Ethernet driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2007 15:39:48 -0000 On Wed, Mar 21, 2007 at 03:32:43PM -0700, Julian Elischer wrote: > Luigi Rizzo wrote: > >On Wed, Mar 21, 2007 at 11:19:36PM +0300, Yar Tikhiy wrote: > >>Hi folks, > >> > >>We have disc(4) for testing and benchmarking. However, it's a > >>loopback driver, so such things as vlan or bridge cannot attach to > >>it. I needed a similar dummy interface mimicing Ethernet and failed > >>to find a ready solution. I tried ng_eiface+ng_hole, but it just > >>couldn't keep up with gigabit rates. So I knocked up a new dummy > >>driver, edsc(4): Ethernet discard interface. I'd like to commit it > >>if there are no objections. Then it could also serve as the bones > >>of an Ethernet driver for those who study kernel internals or want > >>to write a new driver. > > > >seems like a good idea. > > > > I think the question I have is why eiface couldn't cope..? > I think it should have so I'll look at it.. I believe that it can't keep pace because the packet isn't passed straight from if_start() to Netgraph due to some reservations about locking. A callback is used intead, which may introduce a delay. -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 16:25: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 8A74516A402 for ; Thu, 22 Mar 2007 16:25:09 +0000 (UTC) (envelope-from df@bsd.it) Received: from virtual.bsd.it (virtual.bsd.it [69.55.228.157]) by mx1.freebsd.org (Postfix) with SMTP id 3DC2213C4B7 for ; Thu, 22 Mar 2007 16:25:09 +0000 (UTC) (envelope-from df@bsd.it) Received: (qmail 18841 invoked from network); 22 Mar 2007 15:58:26 -0000 Received: from unknown (HELO virtual.bsd.it) (69.55.228.157) by 0 with SMTP; 22 Mar 2007 15:58:26 -0000 From: Ed To: freebsd-net@freebsd.org Date: Thu, 22 Mar 2007 17:02:30 +0100 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200703221702.30505.df@bsd.it> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: re0 panic on FreeBSD 6.2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: df@bsd.it List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2007 16:25:09 -0000 Hello, I have just installed 6.2 on a new laptop. I tried FreeSBIE too. The short version of the story is that as soon as I touch ifconfig to set the gigabit ethernet card (recognized as re0) the system panics... It happens always. Same error, same addresses, everything seems 100% repeatable here. Browsing the changelog of the driver I saw that there could already be a fix available (Revision 1.46.2.24), but there have been too many changes to the driver since 6.2 release to use a diff from RELENG_6 version. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c?only_with_tag=RELENG_6 Is there any plan to backport this fix to RELENG_6_2? I am ready to test a patch, if you can fix this problem. Thanks. From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 18:41: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 253C216A401 for ; Thu, 22 Mar 2007 18:41:32 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 81FA013C4B8 for ; Thu, 22 Mar 2007 18:41:31 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l2MIfTek003209; Fri, 23 Mar 2007 05:41:29 +1100 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l2MIfS3Y003208; Fri, 23 Mar 2007 05:41:28 +1100 (EST) (envelope-from peter) Date: Fri, 23 Mar 2007 05:41:28 +1100 From: Peter Jeremy To: Jon Otterholm Message-ID: <20070322184128.GI847@turion.vk2pj.dyndns.org> References: <460060A8.1080109@ide.resurscentrum.se> <65531A6A-7178-48A1-97D0-9DCB4F72E315@mac.com> <4600689C.3080306@ide.resurscentrum.se> <46019EB6.6010209@ide.resurscentrum.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <46019EB6.6010209@ide.resurscentrum.se> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org Subject: Re: ICMP-floods 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, 22 Mar 2007 18:41:32 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2007-Mar-21 22:08:06 +0100, Jon Otterholm wrote: >I did not mention earlier that all if's are vlan-based sub-intefaces. It >seems that if I move admin-if's on my routers to a different physical if >than the one with the default route, all weird time-exeed/redir are gone >and all traffic on my Nagios-machine are OK. > >It seems allmost as if my routers can not hold apart inbound traffic >destined to different sub-if's on one physical if. Can this be it? I have a old switch at work that understands that IP traffic should be kept in VLANs but other traffic (eg DECnet) gets flooded across all VLANs. It got removed from the network very rapidly once the resulting problems were traced to it. That said, your problem sounds more like a switch/router configuration problem than a bug. Most managed switches default to a mode where they try to automatically just work - ie ports automatically enable or disable STP and switch between untagged and trunk mode depending on the management packets they see on that port. If you don't have a homogenous switch network, it's worth noting that some switch vendors use non-standard MAC addresses for switch management - these packets won't be recognized as management packets by other vendors' switches and can result in two switches that are not physically connected deciding that they _are_ connected and making topology decisions on that basis. I suggest you work through and manually configure all your switches to do what you want whilst disabling most or all of the auto-detection functionality. >A possible bug in if_vlan? I haven't bumped into any if_vlan bugs. There used to be some VLAN related bugs in the bridge code but these were very noisy so it would be immediately obvious if you hit them (the VLAN tag wasn't part of the MAC table hash so having the same MAC in different VLANs triggered error messages). -- Peter Jeremy --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGAs3Y/opHv/APuIcRApWKAKCB8FVt/pPN1tIXRYvFCbcgLzldvgCfa4yd n0rJQJLSE4wfS7BEXw9tGU0= =oo5N -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 21:02: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 6172216A402 for ; Thu, 22 Mar 2007 21:02:52 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id DE58B13C45D for ; Thu, 22 Mar 2007 21:02:51 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from [192.168.98.246] ([192.168.44.2]) by mail1.cil.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 22:02:50 +0100 Message-ID: <4602EEFA.5020907@ide.resurscentrum.se> Date: Thu, 22 Mar 2007 22:02:50 +0100 From: Jon Otterholm User-Agent: Thunderbird 1.5.0.9 (X11/20070131) MIME-Version: 1.0 To: Peter Jeremy References: <460060A8.1080109@ide.resurscentrum.se> <65531A6A-7178-48A1-97D0-9DCB4F72E315@mac.com> <4600689C.3080306@ide.resurscentrum.se> <46019EB6.6010209@ide.resurscentrum.se> <20070322184128.GI847@turion.vk2pj.dyndns.org> In-Reply-To: <20070322184128.GI847@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2007 21:02:50.0150 (UTC) FILETIME=[73435C60:01C76CC5] Cc: freebsd-net@freebsd.org Subject: Re: ICMP-floods 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, 22 Mar 2007 21:02:52 -0000 Peter Jeremy wrote: > On 2007-Mar-21 22:08:06 +0100, Jon Otterholm wrote: > >> I did not mention earlier that all if's are vlan-based sub-intefaces. It >> seems that if I move admin-if's on my routers to a different physical if >> than the one with the default route, all weird time-exeed/redir are gone >> and all traffic on my Nagios-machine are OK. >> >> It seems allmost as if my routers can not hold apart inbound traffic >> destined to different sub-if's on one physical if. Can this be it? >> > > I have a old switch at work that understands that IP traffic should be > kept in VLANs but other traffic (eg DECnet) gets flooded across all > VLANs. It got removed from the network very rapidly once the > resulting problems were traced to it. > From what I have seen my problem only concerns ICMP-traffic. > That said, your problem sounds more like a switch/router configuration > problem than a bug. Most managed switches default to a mode where > they try to automatically just work - ie ports automatically enable or > disable STP and switch between untagged and trunk mode depending on > the management packets they see on that port. If you don't have a > homogenous switch network, it's worth noting that some switch vendors > use non-standard MAC addresses for switch management - these packets > won't be recognized as management packets by other vendors' switches > and can result in two switches that are not physically connected > deciding that they _are_ connected and making topology decisions on > that basis. > Interesting. My switch-network is homogeneous D-link and it would not be the first time we find bugs in their products if that is the case. But I'm still not convinced it is related to my switches, my switches are working on L2, ICMP is L4. I'm just wondering why my problem goes away when moving my admin-vlan to another nic-port connected to the same switch. Cisco-routers connected to the same switch do not react to this as my FreeBSD-routers do. //Jon From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 21:36:57 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 D0DF616A400 for ; Thu, 22 Mar 2007 21:36:57 +0000 (UTC) (envelope-from volker@thalreit.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 676B213C4F5 for ; Thu, 22 Mar 2007 21:36:57 +0000 (UTC) (envelope-from volker@thalreit.de) Received: from [89.48.108.161] (helo=thalreit.de) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1HUUlM2IaP-00035v; Thu, 22 Mar 2007 22:24:00 +0100 Received: from localhost ([127.0.0.1] helo=ikarus.thalreit) by thalreit.de with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HUUlW-0008q4-KC for freebsd-net@freebsd.org; Thu, 22 Mar 2007 22:24:10 +0100 Received: (from volker@localhost) by ikarus.thalreit (8.13.6/8.13.6/Submit) id l2MLOAgJ033979 for freebsd-net@freebsd.org; Thu, 22 Mar 2007 22:24:10 +0100 (CET) (envelope-from volker) Date: Thu, 22 Mar 2007 22:24:09 +0100 From: Volker Jahns To: freebsd-net@freebsd.org Message-ID: <20070322212409.GA33837@ikarus.thalreit> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Provags-ID: V01U2FsdGVkX1/u0Ue4GZyPKQ+70oTdvwymoYlxahQEBq07Vsg gGJZA5GL99edBYm3ZGKHOBsLX/7czsAa5HAIrhl7VkPblEtTkI sNGE14G3HlPdWsu/U/JhQ== Subject: rpcinfo Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2007 21:36:57 -0000 Running rpcbind on a FreeBSD 6.1 testsystem has horrible effects, when - rpcbind is started at system boottime by the rc.conf directive rpcbind_enable="YES" - rpcinfo -p localhost is run ( this command then hangs until the system has died) The top output shows high load and 'many' rpcbind processes which have been started. -- last pid: 48637; load averages: 3.99, 3.24, 3.23 up 0+07:47:18 16:02:42 1832 processes:3 running, 195 sleeping, 1633 waiting, 1 lock CPU states: 5.2% user, 0.0% nice, 26.8% system, 4.3% interrupt, 63.7% idle Mem: 121M Active, 20M Inact, 88M Wired, 4688K Cache, 34M Buf, 1004K Free Swap: 470M Total, 244M Used, 226M Free, 51% Inuse, 22M In, 26M Out PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 317 root 1 128 0 1440K 424K RUN 44:17 7.37% rpcbind 37057 root 1 96 0 6524K 3468K RUN 0:20 0.06% top 296 root 1 96 0 1300K 0K WAIT 1:06 0.00% 437 root 1 96 0 3408K 0K WAIT 0:00 0.00% 538 root 1 96 0 6092K 0K WAIT 0:00 0.00% 447 root 1 8 0 1312K 0K WAIT 0:00 0.00% 441 smmsp 1 20 0 3300K 0K pause 0:00 0.00% 383 root 1 96 0 1212K 0K WAIT 0:00 0.00% 541 root 1 20 0 3996K 0K pause 0:00 0.00% 99806 root 1 4 0 1468K 0K WAIT 0:00 0.00% 38770 root 1 4 0 1464K 0K WAIT 0:00 0.00% 20459 root 1 4 0 1468K 0K WAIT 0:00 0.00% 21924 root 1 4 0 1440K 0K WAIT 0:00 0.00% 426 root 1 96 0 3356K 0K select 0:00 0.00% 49102 root 1 4 0 1468K 0K WAIT 0:00 0.00% 10715 root 1 4 0 1468K 648K kqread 0:00 0.00% rpcbind 49102 root 1 4 0 1468K 0K WAIT 0:00 0.00% 45921 root 1 4 0 1464K 0K WAIT 0:00 0.00% 45947 root 1 4 0 1464K 0K WAIT 0:00 0.00% -- The output of some well-known commands w/ the system in this state is puzzling me: -- orion# dmesg No more processes. -- -- ssh orion -l root ssh_exchange_identification: Connection closed by remote host -- Moreover, system log worries me: -- Mar 8 08:20:26 orion kernel: kern.maxfiles limit exceeded by uid 0, please see tuning(7). Mar 8 08:20:26 orion kernel: kern.maxfiles limit exceeded by uid 0, please see tuning(7). Mar 8 08:20:26 orion syslogd: /dev/console: Too many open files in system: Too many open files in system Mar 8 07:20:25 orion rpcbind: warning: /etc/hosts.allow, line 23: cannot open / etc/hosts.allow: Too many open files in system -- Running rpcinfo -p from a remote system can be used to benchmark this FreeBSD system. sockstat shows the TCP connects to rpcbind from the remote system and everything is fine. If rpcbind is _not_ started at boottime, but from the commandline once the system is up, rpcinfo -p localhost works as expected. I want to run NIS on the system, so rpcbind must run in reliable manner. Any help is much appreciated. -- Volker Jahns, volker@thalreit.de From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 06:54: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 C288316A401 for ; Fri, 23 Mar 2007 06:54:27 +0000 (UTC) (envelope-from zhuyan@staff.sina.com.cn) Received: from staff-jes1.sina.com.cn (staff-jes1.sina.com.cn [219.142.118.230]) by mx1.freebsd.org (Postfix) with ESMTP id 8596013C4BB; Fri, 23 Mar 2007 06:54:27 +0000 (UTC) (envelope-from zhuyan@staff.sina.com.cn) Received: from 3sclient2 ([10.218.30.162]) by staff-jes1.sina.com.cn (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTPA id <0JFC00JQFDQOUA70@staff-jes1.sina.com.cn>; Fri, 23 Mar 2007 13:54:24 +0800 (CST) Date: Fri, 23 Mar 2007 13:54:22 +0800 From: =?gb2312?B?1uzR0g==?= To: freebsd-net@freebsd.org, freebsd-bug@freebsd.org Message-id: <008f01c76d0f$b4b709e0$1e251da0$@sina.com.cn> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcdtD7G3XQZi9bciQAy7hj67dVvrNQ== x-cr-hashedpuzzle: A/2z CDO9 EyQO EzqY G/yK HH/+ Hx5d IscI KE7G MaVE MgJe NKll PQM0 PypR Qyfp Rbj3; 2; ZgByAGUAZQBiAHMAZAAtAGIAdQBnAEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnADsAZgByAGUAZQBiAHMAZAAtAG4AZQB0AEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {82980992-6D7F-4E8E-9393-9AD0797C84FA}; egBoAHUAeQBhAG4AQABzAHQAYQBmAGYALgBzAGkAbgBhAC4AYwBvAG0ALgBjAG4A; Fri, 23 Mar 2007 05:54:17 GMT;VABoAGUAIAB3AGkAMAAgACcAcwAgAGIAdQBnAA== x-cr-puzzleid: {82980992-6D7F-4E8E-9393-9AD0797C84FA} X-Mailman-Approved-At: Fri, 23 Mar 2007 11:34:47 +0000 Cc: Subject: The wi0 's bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2007 06:54:27 -0000 Hi Everybody, There is a bug in wi0, when I ifconfig scan the IP from DHCP, my wi0 will be panic... This bug is in all FreeBSD 6.x RELEASE, is there anybody know it? From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 15:00: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 2109B16A401 for ; Fri, 23 Mar 2007 15:00:24 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 6361713C4D0 for ; Fri, 23 Mar 2007 15:00:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 6FCADEB9848; Fri, 23 Mar 2007 23:00:20 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id DIC7R6flYYZu; Fri, 23 Mar 2007 23:00:08 +0800 (CST) Received: from [192.168.1.32] (unknown [61.51.105.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id AC34EEB9847; Fri, 23 Mar 2007 23:00:08 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:x-enigmail-version:content-type; b=U7mNvuH+EJWJnkHg5o+offMqBRDjLu5ASrZ7eUUNtGeypwolbadoH7D8imwDtWbKm Em66lrn6hBoQzFK8Zw2UA== Message-ID: <4603EB70.6060705@delphij.net> Date: Fri, 23 Mar 2007 23:00:00 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: =?UTF-8?B?5pyx5bKp?= References: <008f01c76d0f$b4b709e0$1e251da0$@sina.com.cn> In-Reply-To: <008f01c76d0f$b4b709e0$1e251da0$@sina.com.cn> X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig45BB9EEC53CF54251ABE6E19" Cc: freebsd-net@freebsd.org, freebsd-bug@freebsd.org Subject: Re: The wi0 's bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2007 15:00:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45BB9EEC53CF54251ABE6E19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E6=9C=B1=E5=B2=A9 wrote: > Hi Everybody,=20 > There is a bug in wi0, when I ifconfig scan the IP from DHCP, my wi0 wi= ll be > panic... > This bug is in all FreeBSD 6.x RELEASE, is there anybody know it? Is it possible to obtain a backtrace? Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig45BB9EEC53CF54251ABE6E19 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGA+twOfuToMruuMARCiQ6AJwI3E0M9mGxj1COm+FzhLsTJlBWtwCdHCtX zk8UMvhaLjcrI83gIyGno20= =G3m6 -----END PGP SIGNATURE----- --------------enig45BB9EEC53CF54251ABE6E19-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 18:44:13 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 1E84516A406; Fri, 23 Mar 2007 18:44:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id EB4BE13C4E7; Fri, 23 Mar 2007 18:44:12 +0000 (UTC) (envelope-from linimon@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 l2NIiCEZ089546; Fri, 23 Mar 2007 18:44:12 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2NIiCsa089542; Fri, 23 Mar 2007 18:44:12 GMT (envelope-from linimon) Date: Fri, 23 Mar 2007 18:44:12 GMT From: Mark Linimon Message-Id: <200703231844.l2NIiCsa089542@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Cc: Subject: Re: kern/110720: [net] [patch] support for interface descriptions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2007 18:44:13 -0000 Synopsis: [net] [patch] support for interface descriptions Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Mar 23 18:44:02 UTC 2007 Responsible-Changed-Why: Over to mailing list for evaluation. http://www.freebsd.org/cgi/query-pr.cgi?pr=110720 From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 09:49: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 0ABED16A401; Sat, 24 Mar 2007 09:49:33 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id 9960113C455; Sat, 24 Mar 2007 09:49:32 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Mar 2007 10:37:27 +0100 Date: Sat, 24 Mar 2007 10:37:24 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: freebsd-bugs@FreeBSD.org In-Reply-To: <200703231844.l2NIiCsa089542@freefall.freebsd.org> Message-ID: <20070324102948.Q58113@knop-beagle.kn.op.dlr.de> References: <200703231844.l2NIiCsa089542@freefall.freebsd.org> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 Mar 2007 09:37:27.0231 (UTC) FILETIME=[08EB64F0:01C76DF8] Cc: freebsd-net@FreeBSD.org Subject: Re: kern/110720: [net] [patch] support for interface descriptions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2007 09:49:33 -0000 Nice feature, although it would be nice to align the maximum length with IF-MIB::ifDescr (255 byte + \0). Also I suppose that the field more naturally fits into struct if_data (see net/if.h) given the comment for that struct: /* * Structure describing information about an interface * which may be of interest to management entities. */ harti From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 10:40: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 40F7816A403 for ; Sat, 24 Mar 2007 10:40:43 +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 A87D013C45E for ; Sat, 24 Mar 2007 10:40:42 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 74534 invoked from network); 24 Mar 2007 10:09:11 -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 ; 24 Mar 2007 10:09:11 -0000 Message-ID: <4604FDD4.2080805@freebsd.org> Date: Sat, 24 Mar 2007 11:30:44 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Harti Brandt References: <200703231844.l2NIiCsa089542@freefall.freebsd.org> <20070324102948.Q58113@knop-beagle.kn.op.dlr.de> In-Reply-To: <20070324102948.Q58113@knop-beagle.kn.op.dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/110720: [net] [patch] support for interface descriptions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2007 10:40:43 -0000 Harti Brandt wrote: > Nice feature, although it would be nice to align the maximum length with > IF-MIB::ifDescr (255 byte + \0). Also I suppose that the field more > naturally fits into struct if_data (see net/if.h) given the comment for > that struct: > > /* > * Structure describing information about an interface > * which may be of interest to management entities. > */ The string array should most likely not be part of struct ifnet as that would bloat it quite a bit. If it is in there it should be at the end of the struct to avoid cache line busting effects. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 12:54: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 54D1416A485; Sat, 24 Mar 2007 12:54:06 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id A49FB13C4BE; Sat, 24 Mar 2007 12:54:05 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l2OCbtfW024212; Sat, 24 Mar 2007 19:37:55 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l2OCbtdq024211; Sat, 24 Mar 2007 19:37:55 +0700 (KRAT) (envelope-from eugen) Date: Sat, 24 Mar 2007 19:37:55 +0700 From: Eugene Grosbein To: Andre Oppermann Message-ID: <20070324123754.GA80483@svzserv.kemerovo.su> References: <200703231844.l2NIiCsa089542@freefall.freebsd.org> <20070324102948.Q58113@knop-beagle.kn.op.dlr.de> <4604FDD4.2080805@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4604FDD4.2080805@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org, Harti Brandt Subject: Re: kern/110720: [net] [patch] support for interface descriptions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2007 12:54:06 -0000 On Sat, Mar 24, 2007 at 11:30:44AM +0100, Andre Oppermann wrote: > Harti Brandt wrote: > >Nice feature, although it would be nice to align the maximum length with > >IF-MIB::ifDescr (255 byte + \0). Also I suppose that the field more > >naturally fits into struct if_data (see net/if.h) given the comment for > >that struct: > > > >/* > > * Structure describing information about an interface > > * which may be of interest to management entities. > > */ > > The string array should most likely not be part of struct ifnet as that > would bloat it quite a bit. If it is in there it should be at the end > of the struct to avoid cache line busting effects. Also vote for this. And is it possible to make it a pointer instead of array? The bloat would be minimal for system with tons of interfaces, think about large pptp or pppoe server or similar that never would utilize arrays. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 17:38: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 4A43216A401; Sat, 24 Mar 2007 17:38:04 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id D6C8C13C468; Sat, 24 Mar 2007 17:38:03 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Mar 2007 18:38:02 +0100 Date: Sat, 24 Mar 2007 18:37:59 +0100 (CET) From: Hartmut Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: Eugene Grosbein In-Reply-To: <20070324123754.GA80483@svzserv.kemerovo.su> Message-ID: <20070324182901.I59406@knop-beagle.kn.op.dlr.de> References: <200703231844.l2NIiCsa089542@freefall.freebsd.org> <20070324102948.Q58113@knop-beagle.kn.op.dlr.de> <4604FDD4.2080805@freebsd.org> <20070324123754.GA80483@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 Mar 2007 17:38:02.0041 (UTC) FILETIME=[2BCE3A90:01C76E3B] Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org, Andre Oppermann Subject: Re: kern/110720: [net] [patch] support for interface descriptions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2007 17:38:04 -0000 On Sat, 24 Mar 2007, Eugene Grosbein wrote: EG>On Sat, Mar 24, 2007 at 11:30:44AM +0100, Andre Oppermann wrote: EG> EG>> Harti Brandt wrote: EG>> >Nice feature, although it would be nice to align the maximum length with EG>> >IF-MIB::ifDescr (255 byte + \0). Also I suppose that the field more EG>> >naturally fits into struct if_data (see net/if.h) given the comment for EG>> >that struct: EG>> > EG>> >/* EG>> > * Structure describing information about an interface EG>> > * which may be of interest to management entities. EG>> > */ EG>> EG>> The string array should most likely not be part of struct ifnet as that EG>> would bloat it quite a bit. If it is in there it should be at the end EG>> of the struct to avoid cache line busting effects. EG> EG>Also vote for this. And is it possible to make it a pointer instead EG>of array? The bloat would be minimal for system with tons of interfaces, EG>think about large pptp or pppoe server or similar that never would EG>utilize arrays. That makes sense. If it is a pointer it should not live in struct ifdata which can be retrieved via sysctl(). As for access to this field perhaps it makes more sense to use the sysctl net.link.generic.ifdata subtree. We have already IFDATA_DRIVERNAME there which returns a string. Could be IFDATA_DESCRIPTION (4). This would probably be more in line with the management nature of the data. Just a thought... Would be slightly easier for the SNMP daemon to use... harti