From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 07:20:06 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D56E37B401 for ; Sun, 27 Apr 2003 07:20:06 -0700 (PDT) Received: from hexagon.stack.nl (hexagon.stack.nl [131.155.140.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35B0143FBD for ; Sun, 27 Apr 2003 07:20:05 -0700 (PDT) (envelope-from marcolz@stack.nl) Received: by hexagon.stack.nl (Postfix, from userid 65534) id 0F8921C35; Sun, 27 Apr 2003 16:20:04 +0200 (CEST) Received: from toad.stack.nl (toad.stack.nl [2001:610:1108:5010::135]) by hexagon.stack.nl (Postfix) with ESMTP id 46ADF1C2B; Sun, 27 Apr 2003 16:19:58 +0200 (CEST) Received: by toad.stack.nl (Postfix, from userid 333) id 2D93293; Sun, 27 Apr 2003 16:19:58 +0200 (CEST) Date: Sun, 27 Apr 2003 16:19:58 +0200 From: Marc Olzheim To: soheil soheil Message-ID: <20030427141958.GA61415@stack.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD toad.stack.nl 4.8-STABLE FreeBSD 4.8-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: marcolz@stack.nl cc: freebsd-net@freebsd.org Subject: Re: arping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 14:20:06 -0000 On Fri, Apr 25, 2003 at 04:01:08PM +0000, soheil soheil wrote: > I get some files that uses libnet like arping > after make gcc .... -lnet xxx.c and after it takes somelink errors for > libnet init send write .... func. > What can make this happened ? You need /usr/ports/net/libnet http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/libnet/ as well... Zlo From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 10:56:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A495937B401 for ; Sun, 27 Apr 2003 10:56:36 -0700 (PDT) Received: from mail102.csoft.net (lilly.csoft.net [63.111.22.101]) by mx1.FreeBSD.org (Postfix) with SMTP id D404A43F75 for ; Sun, 27 Apr 2003 10:56:35 -0700 (PDT) (envelope-from mcc@fid4.com) Received: (qmail 13441 invoked from network); 27 Apr 2003 18:54:14 -0000 Received: from unknown (HELO fid4.com) (66.30.202.75) by mail102.csoft.net with SMTP; 27 Apr 2003 18:54:14 -0000 Sender: mcc@FreeBSD.ORG Message-ID: <3EAC1859.C865E135@fid4.com> Date: Sun, 27 Apr 2003 13:50:17 -0400 From: "Michael C. Cambria" X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Digium drivers & Asterisk VoIP PBX support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 17:56:37 -0000 Does anyone know if there is FreeBSD support for digium (www.digium.com) PCI cards, and a port for the Asterisk PBX (www.asterisk.org) software? The specific cards I'm interested in are: Single-Port FXO PCI card (X100P) Single-Port (upgradeable to 4) TDM400P The X100P lets an VoIP endpoint make a phone call to the local PSTN. The TDM400P lets an analog phone into the PC to call H.323 endpoints. Thanks, MikeC From owner-freebsd-net@FreeBSD.ORG Sun Apr 27 22:36:08 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 356C837B401 for ; Sun, 27 Apr 2003 22:36:08 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B218D43F3F for ; Sun, 27 Apr 2003 22:36:07 -0700 (PDT) (envelope-from freebsd@nbritton.org) Received: from dsc06-chc-il-3-18.rasserver.net ([209.109.242.18] helo=nbritton.org) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19A1J7-0002dt-00 for freebsd-net@freebsd.org; Sun, 27 Apr 2003 22:36:05 -0700 Message-ID: <3EACBE0D.9010106@nbritton.org> Date: Mon, 28 Apr 2003 00:37:17 -0500 From: Nikolas Britton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Compex Network Switches (DSR2216) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 05:36:08 -0000 Any one use Compex's network switches (or any of there products)...I'd like to get your feelings etc. about this company. from the looks of it I can get a 16-port 10/100 rackable *managed* switch from them for $88 bucks (newegg.com)...sounds to good to be true, Is it? /Nikolas From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 08:26:21 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E9F937B401 for ; Mon, 28 Apr 2003 08:26:21 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58BD543F93 for ; Mon, 28 Apr 2003 08:26:20 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.9/8.12.9) with SMTP id h3SFQR9S046645; Mon, 28 Apr 2003 11:26:34 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 28 Apr 2003 11:26:24 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Martin Blapp In-Reply-To: <20030418193305.S6156@cvs.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Implementing SO_BINDTODEVICE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 15:26:21 -0000 On Fri, 18 Apr 2003, Martin Blapp wrote: > How difficult would it be to implement SO_BINDTODEVICE on FreeBSD ? I > need the to make is possible to run more than one instance of dhclient > on one host with more than one NIC. > > We would need this to support removable devices properly. > > There is a tool called omshell which should be able to change variables > so the interface is added to the lists. Unfortunatly the documentation > is bad and I only found hooks to dhcpd. Hmm. My impression was that dhclient used solely BPF descriptors on FreeBSD to perform interface-specific DHCP client communications, and that SO_BINDTODEVICE was used only in the DHCP server? BPF requires you to specifically identify an interface to bind to, as it's an interface-layer communications primitive. Last time I tried, the only real issue in using dhclient on multiple interfaces was making sure that pid files didn't collide, but that was several years ago, things could easily have changed. What semantics does SO_BINDTODEVICE offer? Normally, IP sockets make IP address binding and routing decisions based on the process optionally specifying IP addresses for local binding, and based on the destination of a connection/transmission. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 14:42:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6CD137B401; Mon, 28 Apr 2003 14:42:48 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BFD843F3F; Mon, 28 Apr 2003 14:42:47 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3SLgiAf007951; Mon, 28 Apr 2003 23:42:45 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Mon, 28 Apr 2003 23:42:44 +0200 (CEST) From: Martin Blapp To: Robert Watson In-Reply-To: Message-ID: <20030428173053.E52034@cvs.imp.ch> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Implementing SO_BINDTODEVICE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 21:42:49 -0000 Hi, > Hmm. My impression was that dhclient used solely BPF descriptors on > FreeBSD to perform interface-specific DHCP client communications, and that > SO_BINDTODEVICE was used only in the DHCP server? BPF requires you to > specifically identify an interface to bind to, as it's an interface-layer > communications primitive. Hmm. I'll have to look at this again. > Last time I tried, the only real issue in using dhclient on multiple > interfaces was making sure that pid files didn't collide, but that was > several years ago, things could easily have changed. I guess one can work around with binding just to another port within dhclient. > What semantics does SO_BINDTODEVICE offer? Normally, IP sockets make IP > address binding and routing decisions based on the process optionally > specifying IP addresses for local binding, and based on the destination of > a connection/transmission. In the meantime I have found out that omsshell does provide the functionality to remove and add dhclient supported devices. What's missing is a uncomplicated access method via af_unix socket. I'm currently implementing this one. Then the way dhclient is used will change. You only call dhclient once at startup. For each device you add you call omshell which tells dhclient to poll for link activity. If you remove the card, omshell can be called again to invalidate the device. Martin From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 21:01:20 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64F0737B401 for ; Mon, 28 Apr 2003 21:01:20 -0700 (PDT) Received: from mail46.fg.online.no (mail46-s.fg.online.no [148.122.161.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAF9143FAF for ; Mon, 28 Apr 2003 21:01:16 -0700 (PDT) (envelope-from sartan@online.no) Received: from dellur (ti200720a080-1827.bb.online.no [80.213.143.35]) by mail46.fg.online.no (8.9.3p2/8.9.3) with SMTP id GAA20136 for ; Tue, 29 Apr 2003 06:01:15 +0200 (MEST) Message-ID: <014f01c30e04$0000b410$4d00a8c0@dellur> From: "Lasse Ulvund" To: Date: Tue, 29 Apr 2003 06:01:23 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Using vr - driver from 4.8 on 4.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 04:01:20 -0000 Hi.. I'm trying to utilize an onboard Via Rhine III chip in freebsd, using = the "vr" - driver, it works in 4.8, but not 4.7.. seems 4.7 only = supports Via Rhine I and II chips. Is there a way to get the onboard lan = working under 4.7 with the drivers from 4.8 ?. If so, how would I go = about doing that ?. The reason I need to run FreeBSD 4.7, is that this machine is using a = Highpoint RockedRaid 133-adapter, and highpoints latest driver will only = install under 4.7. The computer has no spare slots (1u-rack), so I can't install any = alternative NIC's. Regards, Lasse From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 21:05:19 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E45637B401 for ; Mon, 28 Apr 2003 21:05:19 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C6F6343FB1 for ; Mon, 28 Apr 2003 21:05:18 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 58585 invoked from network); 29 Apr 2003 04:05:17 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 29 Apr 2003 04:05:17 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 28 Apr 2003 23:04:58 -0500 (CDT) From: Mike Silbersack To: Lasse Ulvund In-Reply-To: <014f01c30e04$0000b410$4d00a8c0@dellur> Message-ID: <20030428230354.H10639@odysseus.silby.com> References: <014f01c30e04$0000b410$4d00a8c0@dellur> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Using vr - driver from 4.8 on 4.7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 04:05:19 -0000 Sure, just copy if_vr.c and if_vrreg.h from 4.8 over the copies in your 4.7 source tree, and recompile your kernel. That should work without problems. Mike "Silby" Silbersack On Tue, 29 Apr 2003, Lasse Ulvund wrote: > Hi.. > > I'm trying to utilize an onboard Via Rhine III chip in freebsd, using the "vr" - driver, it works in 4.8, but not 4.7.. seems 4.7 only supports Via Rhine I and II chips. Is there a way to get the onboard lan working under 4.7 with the drivers from 4.8 ?. If so, how would I go about doing that ?. > > The reason I need to run FreeBSD 4.7, is that this machine is using a Highpoint RockedRaid 133-adapter, and highpoints latest driver will only install under 4.7. > > The computer has no spare slots (1u-rack), so I can't install any alternative NIC's. > > Regards, > Lasse > _______________________________________________ > 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 Apr 28 21:30:06 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C7C137B401 for ; Mon, 28 Apr 2003 21:30:06 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F13743FBD for ; Mon, 28 Apr 2003 21:30:05 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA81675 for ; Mon, 28 Apr 2003 21:21:01 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h3T4L12r069314 for ; Mon, 28 Apr 2003 21:21:01 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3T4L1Ow069313 for freebsd-net@freebsd.org; Mon, 28 Apr 2003 21:21:01 -0700 (PDT) From: Archie Cobbs Message-Id: <200304290421.h3T4L1Ow069313@arch20m.dellroad.org> To: freebsd-net@freebsd.org Date: Mon, 28 Apr 2003 21:21:01 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: MPD now hosted on SourceForge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 04:30:06 -0000 FYI- For anyone interested in MPD, the project is now hosted on SourceForge with a mailing list, bug tracking, etc: http://sourceforge.net/projects/mpd This is part of a larger plot to eventually cede control of MPD to other folks who actually use it regularly, since I don't personally use it anymore. Cheers, -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 04:31:25 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2F7437B401 for ; Tue, 29 Apr 2003 04:31:25 -0700 (PDT) Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4007943FCB for ; Tue, 29 Apr 2003 04:31:24 -0700 (PDT) (envelope-from ericdahan@MEIway.com) Received: from VirusGate.MEIway.com (virus-gate.meiway.com [212.73.210.91]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id EB882EF430 for ; Tue, 29 Apr 2003 13:26:56 +0200 (CEST) Received: from localhost (localhost.meiway.com [127.0.0.1]) by VirusGate.MEIway.com (Postfix) with SMTP id 7EE9F5D009 for ; Tue, 29 Apr 2003 13:32:18 +0200 (CEST) Received: from ms1.meiway.com (ms1.meiway.com [212.73.210.73]) by VirusGate.MEIway.com (Postfix) with ESMTP id 0B3135D008 for ; Tue, 29 Apr 2003 13:32:18 +0200 (CEST) Received: from EDA_VAIO.meiway.com [193.252.44.38] by ms1.meiway.com with ESMTP (SMTPD32-6.06) id A77A907300CE; Tue, 29 Apr 2003 13:52:26 +0200 Message-Id: <5.2.0.9.0.20030429131254.04cb8cd8@ms1.meiway.com> X-Sender: ericdahan@meiway.com@ms1.meiway.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 29 Apr 2003 13:31:15 +0200 To: freebsd-net@freebsd.org From: Eric Dahan Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: MPD error : "error writing len 27 frame to bypass: No route to host" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 11:31:26 -0000 Hi all, I'm trying to establish a pptp tunnel with MPD box V 3.13 under FreeBSD=20 4.8-RC1 and Win XP Station. I'm getting "error writing len 27 frame to bypass: No route to host"= rejects. Any ideas what is actually going wrong? Thanks. FreeBSD 4.8-RC1 box: 81.80.x.y winXP Station : 193.252.x.y Private net behind FreeBsd Box : 192.168.x.0/24 Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 1542, version 3.13 (root@freebsd.org 11:25 19-Apr-2003) [pptp] ppp node is "mpd1542-pptp" mpd: local IP address for PPTP is 81.80.153.45 [pptp] using interface ng0 [pptp:pptp] mpd: PPTP connection from 193.252.44.38:23660 pptp0: attached to connection with 193.252.44.38:23660 [pptp] IFACE: Open event [pptp] IPCP: Open event [pptp] IPCP: state change Initial --> Starting [pptp] IPCP: LayerStart [pptp] IPCP: Open event [pptp] bundle: OPEN event in state CLOSED [pptp] opening link "pptp"... [pptp] link: OPEN event [pptp] LCP: Open event [pptp] LCP: state change Initial --> Starting [pptp] LCP: LayerStart [pptp] device: OPEN event in state DOWN [pptp] attaching to peer's outgoing call [pptp] device is now in state OPENING [pptp] device: UP event in state OPENING [pptp] device is now in state UP [pptp] link: UP event [pptp] link: origination is remote [pptp] LCP: Up event [pptp] LCP: state change Starting --> Req-Sent [pptp] LCP: phase shift DEAD --> ESTABLISH [pptp] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 21decf22 AUTHPROTO CHAP MSOFTv2 [pptp] error writing len 27 frame to bypass: No route to host pptp0-0: ignoring SetLinkInfo [pptp] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 21decf22 AUTHPROTO CHAP MSOFTv2 [pptp] error writing len 27 frame to bypass: No route to host [pptp] LCP: SendConfigReq #3 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 21decf22 AUTHPROTO CHAP MSOFTv2 [pptp] LCP: SendConfigReq #4 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 21decf22 AUTHPROTO CHAP MSOFTv2 [pptp] LCP: SendConfigReq #5 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 21decf22 AUTHPROTO CHAP MSOFTv2 mpd.conf default: load pptp pptp: new -i ng0 pptp pptp set iface disable on-demand set iface enable proxy-arp set iface route 192.168.35.0/24 set bundle disable multilink set bundle authname "Name" set bundle password "password" set bundle enable encryption set link yes acfcomp protocomp set link disable pap set link enable chap set link keep-alive 10 60 set ipcp enable vjcomp set ipcp ranges 81.80.x.y/32 192.168.x.200/32 set ipcp dns 193.252.19.3 set bundle enable compression set ccp enable mppc set ccp enable mpp-e40 set ccp enable mpp-e128 set ccp yes mpp-stateless set bundle enable crypt-reqd mpd.links. pptp: set link type pptp set pptp self 81.80.x.y set pptp enable incoming set pptp enable originate mpd.secrets. Name password Eric DAHAN. MEI 25 Avenue des Bretagnes 93230 ROMAINVILLE Tel : 01.41.71.06.06. Fax : 01.41.71.06.04. Centre de formation agr=E9e N=B011752906075 www.meiway.com=20 From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 12:37:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACD6C37B401 for ; Tue, 29 Apr 2003 12:37:34 -0700 (PDT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95EE643FBF for ; Tue, 29 Apr 2003 12:37:33 -0700 (PDT) (envelope-from fjoe@iclub.nsu.ru) Received: from mail by mx.nsu.ru with drweb-scanned (Exim 3.36 #1 (Debian)) id 19Aawo-0007rI-00 for ; Wed, 30 Apr 2003 02:39:26 +0700 Received: from iclub.nsu.ru ([193.124.215.97] ident=root) by mx.nsu.ru with esmtp (Exim 3.36 #1 (Debian)) id 19Aawb-0007mk-00 for ; Wed, 30 Apr 2003 02:39:13 +0700 Received: from iclub.nsu.ru (fjoe@localhost [127.0.0.1]) by iclub.nsu.ru (8.12.9/8.12.9) with ESMTP id h3TJagud022596 for ; Wed, 30 Apr 2003 02:36:42 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Received: (from fjoe@localhost) by iclub.nsu.ru (8.12.9/8.12.9/Submit) id h3TJaf2e022595 for freebsd-net@freebsd.org; Wed, 30 Apr 2003 02:36:42 +0700 (NSS) Date: Wed, 30 Apr 2003 02:36:41 +0700 From: Max Khon To: freebsd-net@freebsd.org Message-ID: <20030430023640.A22257@iclub.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Envelope-To: freebsd-net@freebsd.org X-Bogosity: No, tests=bogofilter, spamicity=0.000331, version=0.11.1.4 X-Spam-Status: No, hits=-6.8 required=5.0 tests=BOGOFILTER_TEST_PASS,UPPERCASE_25_50,USER_AGENT_MUTT version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Subject: IPDIVERT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 19:37:35 -0000 hi, there! I have a suggestion to build GENERIC and ipfw.ko with IPDIVERT by default or change IPDIVERT to NOIPDIVERT and build boot kernels with NOIPDIVERT. The main goal is to allow to use NAT with stock kernels and ipfw.ko. Comments? /fjoe From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 13:05:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF33537B401 for ; Tue, 29 Apr 2003 13:05:39 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3540C43FB1 for ; Tue, 29 Apr 2003 13:05:36 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h3TK5T62073673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2003 23:05:29 +0300 (EEST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h3TK5Toq073672; Tue, 29 Apr 2003 23:05:29 +0300 (EEST) (envelope-from ru) Date: Tue, 29 Apr 2003 23:05:29 +0300 From: Ruslan Ermilov To: Max Khon Message-ID: <20030429200529.GA71528@sunbay.com> References: <20030430023640.A22257@iclub.nsu.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <20030430023640.A22257@iclub.nsu.ru> User-Agent: Mutt/1.5.4i cc: freebsd-net@freebsd.org Subject: Re: IPDIVERT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 20:05:40 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 30, 2003 at 02:36:41AM +0700, Max Khon wrote: > hi, there! >=20 > I have a suggestion to build GENERIC and ipfw.ko with IPDIVERT by default > or change IPDIVERT to NOIPDIVERT and build boot kernels with NOIPDIVERT. > The main goal is to allow to use NAT with stock kernels and ipfw.ko. >=20 > Comments? >=20 Only if you succeed in making the ipdivert.ko module: IPDIVERT is not modularized currently, contrary to IPFIREWALL. What it means basically is that you will have to change lot of ``#ifdef IPDIVERT'' to ``if (IPDIVERT_LOADED)'', like with the IPFW_LOADED. I think this is worth doing. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+rtsJUkv4P6juNwoRAmC+AJ42iMrHhwJBqoz6YraMx2Bf2zKgcgCfTwnp RpChCLKjg3DTvlXeMcmXxuc= =NpE5 -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 13:14:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA13E37B401 for ; Tue, 29 Apr 2003 13:14:44 -0700 (PDT) Received: from cultdeadsheep.org (charon.cultdeadsheep.org [80.65.226.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49F8F43FA3 for ; Tue, 29 Apr 2003 13:14:42 -0700 (PDT) (envelope-from sheepkiller@cultdeadsheep.org) Received: (qmail 26468 invoked from network); 29 Apr 2003 20:14:39 -0000 Received: from unknown (HELO lucifer.cultdeadsheep.org) (192.168.0.2) by goofy.cultdeadsheep.org with SMTP; 29 Apr 2003 20:14:39 -0000 Date: Tue, 29 Apr 2003 22:15:54 +0200 From: Clement Laforet To: Max Khon Message-Id: <20030429221554.4eea1145.sheepkiller@cultdeadsheep.org> In-Reply-To: <20030430023640.A22257@iclub.nsu.ru> References: <20030430023640.A22257@iclub.nsu.ru> Organization: tH3 cUlt 0f tH3 d3@d sH33p X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386-portbld-freebsd4.8) X-Face: ._cVVRDn#-2((lnfi^P7CoD4htI$4+#G/G)!w|,}H5yK~%(3-C.JlEYbOjJGFwJkt*7N^%z jYeu[;}]}F"3}l5R'l"X0HbvT^D\Q&%deCo)MayY`);TO Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: IPDIVERT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 20:14:45 -0000 On Wed, 30 Apr 2003 02:36:41 +0700 Max Khon wrote: > hi, there! Hi, Max ! > I have a suggestion to build GENERIC and ipfw.ko with IPDIVERT by > default or change IPDIVERT to NOIPDIVERT and build boot kernels with > NOIPDIVERT. The main goal is to allow to use NAT with stock kernels > and ipfw.ko. > > Comments? yes, but I don't know if I'm right :p IPDIVERT isn't designed to be manageable by ipfw. I (mis)read the kernel IP source few day ago (I'm playing with libalias) and that's what I understood : IPDIVERT is a way to reinject IP packets into the IP stack. It seems to be a big workaround for users who wished NAT than a real solution. ipfw only add a flag "to be diverted" to packets. IPDIVERT is a big workaround, libalias is a very big workaround ;) Considering that NAT'ing using natd/libalias/divert is not very clean way of doing NAT, why should it be in the GENERIC kernel ? however, it sould be easy to build it as module. regards, clem From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 13:33:07 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BF5E37B401 for ; Tue, 29 Apr 2003 13:33:07 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF62C43F93 for ; Tue, 29 Apr 2003 13:33:04 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <2003042920330300300fo6hhe>; Tue, 29 Apr 2003 20:33:03 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA55373; Tue, 29 Apr 2003 13:33:03 -0700 (PDT) Date: Tue, 29 Apr 2003 13:33:02 -0700 (PDT) From: Julian Elischer To: Clement Laforet In-Reply-To: <20030429221554.4eea1145.sheepkiller@cultdeadsheep.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: IPDIVERT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 20:33:07 -0000 On Tue, 29 Apr 2003, Clement Laforet wrote: > On Wed, 30 Apr 2003 02:36:41 +0700 > Max Khon wrote: > > > hi, there! > Hi, Max ! > > > I have a suggestion to build GENERIC and ipfw.ko with IPDIVERT by > > default or change IPDIVERT to NOIPDIVERT and build boot kernels with > > NOIPDIVERT. The main goal is to allow to use NAT with stock kernels > > and ipfw.ko. > > > > Comments? IPDIVERT was written when it became clear that there were userland applications that wanted to 'fiddle' with packets in transit. It was written when one of the CSRG guys said that there was too much in the kernel already and that a way to do such fiddling outside the kernel might be useful. NAT is only just one such app. we also had code to do encryption for example. > > yes, but I don't know if I'm right :p > IPDIVERT isn't designed to be manageable by ipfw. > I (mis)read the kernel IP source few day ago (I'm playing with > libalias) and that's what I understood : > IPDIVERT is a way to reinject IP packets into the IP stack. It > seems to be a big workaround for users who wished NAT than a real > solution. ipfw only add a flag "to be diverted" to packets. > IPDIVERT is a big workaround, libalias is a very big workaround ;) > Considering that NAT'ing using natd/libalias/divert is not very clean > way of doing NAT, why should it be in the GENERIC kernel ? > > however, it sould be easy to build it as module. > > regards, > > clem > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 15:47:53 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C519837B401 for ; Tue, 29 Apr 2003 15:47:53 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CC3843F85 for ; Tue, 29 Apr 2003 15:47:53 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3TMlpVo044310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 29 Apr 2003 18:47:51 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3TMlpPU044307; Tue, 29 Apr 2003 18:47:51 -0400 (EDT) (envelope-from wollman) Date: Tue, 29 Apr 2003 18:47:51 -0400 (EDT) From: Garrett Wollman Message-Id: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> To: net@FreeBSD.org X-Spam-Score: -6 () PATCH_UNIFIED_DIFF X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) Subject: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 22:47:54 -0000 Here's a patch inspired by a recent Steve Bellovin paper. It also saves a bswap operation in the common case for non-TCP (non-PMTUD) traffic. Untested as yet, but I have great faith.... -GAWollman Index: ip_output.c =================================================================== RCS file: /home/cvs/src/sys/netinet/ip_output.c,v retrieving revision 1.187 diff -u -r1.187 ip_output.c --- ip_output.c 12 Apr 2003 06:11:46 -0000 1.187 +++ ip_output.c 29 Apr 2003 22:42:55 -0000 @@ -223,17 +223,29 @@ pkt_dst = args.next_hop ? args.next_hop->sin_addr : ip->ip_dst; /* - * Fill in IP header. + * Fill in IP header. If we are not allowing fragmentation, + * then the ip_id field is meaningless, so send it as zero + * to reduce information leakage. Otherwise, if we are not + * randomizing ip_id, then don't bother to convert it to network + * byte order -- it's just a nonce. Note that a 16-bit counter + * will wrap around in less than 10 seconds at 100 Mbit/s on a + * medium with MTU 1500. See Steven M. Bellovin, "A Technique + * for Counting NATted Hosts", Proc. IMW'02, available at + * . */ if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { ip->ip_v = IPVERSION; ip->ip_hl = hlen >> 2; ip->ip_off &= IP_DF; + if (ip->ip_off) + ip->ip_id = 0; + else { #ifdef RANDOM_IP_ID - ip->ip_id = ip_randomid(); + ip->ip_id = ip_randomid(); #else - ip->ip_id = htons(ip_id++); + ip->ip_id = ip_id++; #endif + } ipstat.ips_localout++; } else { hlen = ip->ip_hl << 2; From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 22:12:19 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5593E37B401 for ; Tue, 29 Apr 2003 22:12:19 -0700 (PDT) Received: from hotmail.com (f56.law15.hotmail.com [64.4.23.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00F3043F85 for ; Tue, 29 Apr 2003 22:12:19 -0700 (PDT) (envelope-from soheil_hh@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 29 Apr 2003 22:12:19 -0700 Received: from 194.225.40.59 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 30 Apr 2003 05:12:18 GMT X-Originating-IP: [194.225.40.59] X-Originating-Email: [soheil_hh@hotmail.com] From: "soheil soheil" To: freebsd-net@freebsd.org Date: Wed, 30 Apr 2003 05:12:18 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2003 05:12:19.0031 (UTC) FILETIME=[12A8B670:01C30ED7] Subject: Snoop TCP vs. Proxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 05:12:19 -0000 Hi there I can not get if Snoop TCP changes the ip_src address of any packets travel through , or in other words does it proxy the wireless host , (or it is not). if ( Snoop_TCP() == Proxy() ) { } else{ } Thanx _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-freebsd-net@FreeBSD.ORG Tue Apr 29 23:58:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B5D137B401 for ; Tue, 29 Apr 2003 23:58:48 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B2E2343F75 for ; Tue, 29 Apr 2003 23:58:47 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 95709 invoked from network); 30 Apr 2003 06:58:46 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 30 Apr 2003 06:58:46 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 30 Apr 2003 01:58:36 -0500 (CDT) From: Mike Silbersack To: Garrett Wollman In-Reply-To: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> Message-ID: <20030430015609.M514@odysseus.silby.com> References: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 06:58:48 -0000 Looks good to me, I've been contemplating doing just this for a while. It's too bad we don't have an inexpensive function we can use for the !DF case. I'd like to make the OpenBSD function the default for frag packets, but it seems just too heavyweight.. Mike "Silby" Silbersack On Tue, 29 Apr 2003, Garrett Wollman wrote: > Here's a patch inspired by a recent Steve Bellovin paper. It also > saves a bswap operation in the common case for non-TCP (non-PMTUD) > traffic. Untested as yet, but I have great faith.... > > -GAWollman > > > Index: ip_output.c > =================================================================== > RCS file: /home/cvs/src/sys/netinet/ip_output.c,v > retrieving revision 1.187 > diff -u -r1.187 ip_output.c > --- ip_output.c 12 Apr 2003 06:11:46 -0000 1.187 > +++ ip_output.c 29 Apr 2003 22:42:55 -0000 > @@ -223,17 +223,29 @@ > pkt_dst = args.next_hop ? args.next_hop->sin_addr : ip->ip_dst; > > /* > - * Fill in IP header. > + * Fill in IP header. If we are not allowing fragmentation, > + * then the ip_id field is meaningless, so send it as zero > + * to reduce information leakage. Otherwise, if we are not > + * randomizing ip_id, then don't bother to convert it to network > + * byte order -- it's just a nonce. Note that a 16-bit counter > + * will wrap around in less than 10 seconds at 100 Mbit/s on a > + * medium with MTU 1500. See Steven M. Bellovin, "A Technique > + * for Counting NATted Hosts", Proc. IMW'02, available at > + * . > */ > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { > ip->ip_v = IPVERSION; > ip->ip_hl = hlen >> 2; > ip->ip_off &= IP_DF; > + if (ip->ip_off) > + ip->ip_id = 0; > + else { > #ifdef RANDOM_IP_ID > - ip->ip_id = ip_randomid(); > + ip->ip_id = ip_randomid(); > #else > - ip->ip_id = htons(ip_id++); > + ip->ip_id = ip_id++; > #endif > + } > ipstat.ips_localout++; > } else { > hlen = ip->ip_hl << 2; > _______________________________________________ > 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 Apr 30 00:31:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5FD337B401; Wed, 30 Apr 2003 00:31:34 -0700 (PDT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA83143F85; Wed, 30 Apr 2003 00:31:33 -0700 (PDT) (envelope-from fjoe@iclub.nsu.ru) Received: from mail by mx.nsu.ru with drweb-scanned (Exim 3.36 #1 (Debian)) id 19Am64-0004zr-00; Wed, 30 Apr 2003 14:33:44 +0700 Received: from iclub.nsu.ru ([193.124.215.97] ident=root) by mx.nsu.ru with esmtp (Exim 3.36 #1 (Debian)) id 19Am5s-0004vW-00; Wed, 30 Apr 2003 14:33:32 +0700 Received: from iclub.nsu.ru (fjoe@localhost [127.0.0.1]) by iclub.nsu.ru (8.12.9/8.12.9) with ESMTP id h3U7VGud039720; Wed, 30 Apr 2003 14:31:16 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Received: (from fjoe@localhost) by iclub.nsu.ru (8.12.9/8.12.9/Submit) id h3U7VEBZ039719; Wed, 30 Apr 2003 14:31:15 +0700 (NSS) Date: Wed, 30 Apr 2003 14:31:14 +0700 From: Max Khon To: Ruslan Ermilov Message-ID: <20030430143114.A38982@iclub.nsu.ru> References: <20030430023640.A22257@iclub.nsu.ru> <20030429200529.GA71528@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030429200529.GA71528@sunbay.com>; from ru@freebsd.org on Tue, Apr 29, 2003 at 11:05:29PM +0300 X-Envelope-To: ru@freebsd.org, freebsd-net@freebsd.org X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.11.1.4 X-Spam-Status: No, hits=-34.6 required=5.0 tests=BOGOFILTER_TEST_PASS,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-net@freebsd.org Subject: Re: IPDIVERT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 07:31:35 -0000 hi, there! On Tue, Apr 29, 2003 at 11:05:29PM +0300, Ruslan Ermilov wrote: > > I have a suggestion to build GENERIC and ipfw.ko with IPDIVERT by default > > or change IPDIVERT to NOIPDIVERT and build boot kernels with NOIPDIVERT. > > The main goal is to allow to use NAT with stock kernels and ipfw.ko. > > > > Comments? > > > Only if you succeed in making the ipdivert.ko module: IPDIVERT is not > modularized currently, contrary to IPFIREWALL. What it means basically > is that you will have to change lot of ``#ifdef IPDIVERT'' to > ``if (IPDIVERT_LOADED)'', like with the IPFW_LOADED. I think this is > worth doing. AFAIK there is no possibility to add IPPROTO_DIVERT dynamically to inetsw[]. Some fields of 'struct ipq' are under #ifdef IPDIVERT as well. ipfw code under #ifdef IPDIVERT are just `case' labels and strings in printf's (like "ipdivert enabled"). In other words is it really worth splitting ipdivert into separate .ko module? Changing IPDIVERT to NOIPDIVERT will be cleaner in my opinion. /fjoe From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 00:42:47 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80C7D37B401; Wed, 30 Apr 2003 00:42:47 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E429943F3F; Wed, 30 Apr 2003 00:42:46 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h3U7gkBp098223; Wed, 30 Apr 2003 00:42:46 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h3U7gkhc098222; Wed, 30 Apr 2003 00:42:46 -0700 (PDT) (envelope-from rizzo) Date: Wed, 30 Apr 2003 00:42:45 -0700 From: Luigi Rizzo To: Max Khon Message-ID: <20030430004245.B95389@xorpc.icir.org> References: <20030430023640.A22257@iclub.nsu.ru> <20030429200529.GA71528@sunbay.com> <20030430143114.A38982@iclub.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030430143114.A38982@iclub.nsu.ru>; from fjoe@iclub.nsu.ru on Wed, Apr 30, 2003 at 02:31:14PM +0700 cc: freebsd-net@freebsd.org Subject: Re: IPDIVERT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 07:42:47 -0000 On Wed, Apr 30, 2003 at 02:31:14PM +0700, Max Khon wrote: > hi, there! ... > On Tue, Apr 29, 2003 at 11:05:29PM +0300, Ruslan Ermilov wrote: > > > I have a suggestion to build GENERIC and ipfw.ko with IPDIVERT by default > > > or change IPDIVERT to NOIPDIVERT and build boot kernels with NOIPDIVERT. > > > The main goal is to allow to use NAT with stock kernels and ipfw.ko. ... > AFAIK there is no possibility to add IPPROTO_DIVERT dynamically to > inetsw[]. Some fields of 'struct ipq' are under #ifdef IPDIVERT as well. > ipfw code under #ifdef IPDIVERT are just `case' labels and strings in printf's > (like "ipdivert enabled"). In other words is it really > worth splitting ipdivert into separate .ko module? Changing IPDIVERT to > NOIPDIVERT will be cleaner in my opinion. indeed, i believe we should make the main part of IPDIVERT processing (in ip_input.c, ip_output.c, ip_fw2.c and ip_var.h) non-optional (this would also allow a better realignment of fields in struct ipq) and only make the code in ip_divert.c a module cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56122 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 01:08:47 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96EF337B401 for ; Wed, 30 Apr 2003 01:08:47 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D18743FBF for ; Wed, 30 Apr 2003 01:08:43 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h3U88W62041520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2003 11:08:35 +0300 (EEST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h3U88WfW041515; Wed, 30 Apr 2003 11:08:32 +0300 (EEST) (envelope-from ru) Date: Wed, 30 Apr 2003 11:08:32 +0300 From: Ruslan Ermilov To: Luigi Rizzo Message-ID: <20030430080832.GB39766@sunbay.com> References: <20030430023640.A22257@iclub.nsu.ru> <20030429200529.GA71528@sunbay.com> <20030430143114.A38982@iclub.nsu.ru> <20030430004245.B95389@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UFHRwCdBEJvubb2X" Content-Disposition: inline In-Reply-To: <20030430004245.B95389@xorpc.icir.org> User-Agent: Mutt/1.5.4i cc: freebsd-net@freebsd.org Subject: Re: IPDIVERT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 08:08:47 -0000 --UFHRwCdBEJvubb2X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 30, 2003 at 12:42:45AM -0700, Luigi Rizzo wrote: > On Wed, Apr 30, 2003 at 02:31:14PM +0700, Max Khon wrote: > > hi, there! > ... > > On Tue, Apr 29, 2003 at 11:05:29PM +0300, Ruslan Ermilov wrote: > > > > I have a suggestion to build GENERIC and ipfw.ko with IPDIVERT by d= efault > > > > or change IPDIVERT to NOIPDIVERT and build boot kernels with NOIPDI= VERT. > > > > The main goal is to allow to use NAT with stock kernels and ipfw.ko. > ... > > AFAIK there is no possibility to add IPPROTO_DIVERT dynamically to > > inetsw[]. Some fields of 'struct ipq' are under #ifdef IPDIVERT as well. > > ipfw code under #ifdef IPDIVERT are just `case' labels and strings in p= rintf's > > (like "ipdivert enabled"). In other words is it really > > worth splitting ipdivert into separate .ko module? Changing IPDIVERT to > > NOIPDIVERT will be cleaner in my opinion. >=20 > indeed, i believe we should make the main part of IPDIVERT processing > (in ip_input.c, ip_output.c, ip_fw2.c and ip_var.h) non-optional > (this would also allow a better realignment of fields in struct ipq)=20 > and only make the code in ip_divert.c a module >=20 That's what I basically meant by "changing lot of ``#ifdef IPDIVERT'' to ``if (IPDIVERT_LOADED)''", too. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --UFHRwCdBEJvubb2X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+r4SAUkv4P6juNwoRAox2AJ9yKTveG3rl7nDLgVXtpA5zyd3akQCeOGEx unhRKpLdVs2/Ig1kSCBAEbs= =wV+p -----END PGP SIGNATURE----- --UFHRwCdBEJvubb2X-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 02:03:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E48837B401; Wed, 30 Apr 2003 02:03:00 -0700 (PDT) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECC2943F93; Wed, 30 Apr 2003 02:02:57 -0700 (PDT) (envelope-from fjoe@iclub.nsu.ru) Received: from mail by mx.nsu.ru with drweb-scanned (Exim 3.36 #1 (Debian)) id 19AnWN-0006eS-00; Wed, 30 Apr 2003 16:04:59 +0700 Received: from iclub.nsu.ru ([193.124.215.97] ident=root) by mx.nsu.ru with esmtp (Exim 3.36 #1 (Debian)) id 19AnW3-0006Jx-00; Wed, 30 Apr 2003 16:04:39 +0700 Received: from iclub.nsu.ru (fjoe@localhost [127.0.0.1]) by iclub.nsu.ru (8.12.9/8.12.9) with ESMTP id h3U92Oud042014; Wed, 30 Apr 2003 16:02:24 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Received: (from fjoe@localhost) by iclub.nsu.ru (8.12.9/8.12.9/Submit) id h3U92Nf1042008; Wed, 30 Apr 2003 16:02:23 +0700 (NSS) Date: Wed, 30 Apr 2003 16:02:23 +0700 From: Max Khon To: Luigi Rizzo Message-ID: <20030430160222.A41678@iclub.nsu.ru> References: <20030430023640.A22257@iclub.nsu.ru> <20030429200529.GA71528@sunbay.com> <20030430143114.A38982@iclub.nsu.ru> <20030430004245.B95389@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030430004245.B95389@xorpc.icir.org>; from rizzo@icir.org on Wed, Apr 30, 2003 at 12:42:45AM -0700 X-Envelope-To: rizzo@icir.org, ru@freebsd.org, freebsd-net@freebsd.org X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.11.1.4 X-Spam-Status: No, hits=-34.6 required=5.0 tests=BOGOFILTER_TEST_PASS,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-net@freebsd.org Subject: Re: IPDIVERT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 09:03:01 -0000 hi, there! On Wed, Apr 30, 2003 at 12:42:45AM -0700, Luigi Rizzo wrote: > > > > I have a suggestion to build GENERIC and ipfw.ko with IPDIVERT by default > > > > or change IPDIVERT to NOIPDIVERT and build boot kernels with NOIPDIVERT. > > > > The main goal is to allow to use NAT with stock kernels and ipfw.ko. > ... > > AFAIK there is no possibility to add IPPROTO_DIVERT dynamically to > > inetsw[]. Some fields of 'struct ipq' are under #ifdef IPDIVERT as well. > > ipfw code under #ifdef IPDIVERT are just `case' labels and strings in printf's > > (like "ipdivert enabled"). In other words is it really > > worth splitting ipdivert into separate .ko module? Changing IPDIVERT to > > NOIPDIVERT will be cleaner in my opinion. > > indeed, i believe we should make the main part of IPDIVERT processing > (in ip_input.c, ip_output.c, ip_fw2.c and ip_var.h) non-optional > (this would also allow a better realignment of fields in struct ipq) > and only make the code in ip_divert.c a module ok, how can I add IPPROTO_DIVERT dynamically? Is it ok to have dummy usrreqs there and to overwrite IPPROTO_DIVERT array element upon module load/unload? /fjoe From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 05:30:32 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9CEA37B401 for ; Wed, 30 Apr 2003 05:30:32 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06E4B43FEC for ; Wed, 30 Apr 2003 05:30:26 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h3UCUC62071891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2003 15:30:12 +0300 (EEST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h3UCU68I071876; Wed, 30 Apr 2003 15:30:06 +0300 (EEST) (envelope-from ru) Date: Wed, 30 Apr 2003 15:30:06 +0300 From: Ruslan Ermilov To: Garrett Wollman Message-ID: <20030430123006.GC68817@sunbay.com> References: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oj4kGyHlBMXGt3Le" Content-Disposition: inline In-Reply-To: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.5.4i cc: net@freebsd.org Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 12:30:33 -0000 --oj4kGyHlBMXGt3Le Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 29, 2003 at 06:47:51PM -0400, Garrett Wollman wrote: > Here's a patch inspired by a recent Steve Bellovin paper. It also > saves a bswap operation in the common case for non-TCP (non-PMTUD) > traffic. Untested as yet, but I have great faith.... >=20 Looks like a winner! > Index: ip_output.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/cvs/src/sys/netinet/ip_output.c,v > retrieving revision 1.187 > diff -u -r1.187 ip_output.c > --- ip_output.c 12 Apr 2003 06:11:46 -0000 1.187 > +++ ip_output.c 29 Apr 2003 22:42:55 -0000 > @@ -223,17 +223,29 @@ > pkt_dst =3D args.next_hop ? args.next_hop->sin_addr : ip->ip_dst; > =20 > /* > - * Fill in IP header. > + * Fill in IP header. If we are not allowing fragmentation, > + * then the ip_id field is meaningless, so send it as zero > + * to reduce information leakage. Otherwise, if we are not > + * randomizing ip_id, then don't bother to convert it to network > + * byte order -- it's just a nonce. Note that a 16-bit counter > + * will wrap around in less than 10 seconds at 100 Mbit/s on a > + * medium with MTU 1500. See Steven M. Bellovin, "A Technique > + * for Counting NATted Hosts", Proc. IMW'02, available at > + * . > */ > if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) =3D=3D 0) { > ip->ip_v =3D IPVERSION; > ip->ip_hl =3D hlen >> 2; > ip->ip_off &=3D IP_DF; > + if (ip->ip_off) > + ip->ip_id =3D 0; > + else { > #ifdef RANDOM_IP_ID > - ip->ip_id =3D ip_randomid(); > + ip->ip_id =3D ip_randomid(); > #else > - ip->ip_id =3D htons(ip_id++); > + ip->ip_id =3D ip_id++; > #endif > + } > ipstat.ips_localout++; > } else { > hlen =3D ip->ip_hl << 2; > _______________________________________________ > 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" --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --oj4kGyHlBMXGt3Le Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+r8HOUkv4P6juNwoRAtVRAJ0a/JotVPV5LvdWLfOyNePEUCjYdgCfc0eK l+2iexVR2wrSuUu7hvXbH9U= =L2F6 -----END PGP SIGNATURE----- --oj4kGyHlBMXGt3Le-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 09:56:51 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 435AC37B401 for ; Wed, 30 Apr 2003 09:56:51 -0700 (PDT) Received: from mgw1.MEIway.com (mgw1.meiway.com [212.73.210.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C60CC43FD7 for ; Wed, 30 Apr 2003 09:56:49 -0700 (PDT) (envelope-from ericdahan@MEIway.com) Received: from VirusGate.MEIway.com (virus-gate.meiway.com [212.73.210.91]) by mgw1.MEIway.com (Postfix Relay Hub) with ESMTP id 64EBCEF42C; Wed, 30 Apr 2003 18:52:10 +0200 (CEST) Received: from localhost (localhost.meiway.com [127.0.0.1]) by VirusGate.MEIway.com (Postfix) with SMTP id A862B5D00A; Wed, 30 Apr 2003 18:57:45 +0200 (CEST) Received: from ms1.meiway.com (ms1.meiway.com [212.73.210.73]) by VirusGate.MEIway.com (Postfix) with ESMTP id 42AC75D009; Wed, 30 Apr 2003 18:57:45 +0200 (CEST) Received: from EDA_VAIO.meiway.com [193.252.44.38] by ms1.meiway.com with ESMTP (SMTPD32-6.06) id A52211E800DE; Wed, 30 Apr 2003 19:17:22 +0200 Message-Id: <5.2.0.9.0.20030430184244.06919e80@ms1.meiway.com> X-Sender: ericdahan@meiway.com@ms1.meiway.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 30 Apr 2003 18:56:35 +0200 To: Alexandre Kardanev From: Eric Dahan In-Reply-To: References: <5.2.0.9.0.20030429131254.04cb8cd8@ms1.meiway.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org Subject: Re: MPD error : "error writing len 27 frame to bypass: No route to host" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 16:56:51 -0000 > >You forgot "set iface addr ..." command. It is REQUIRED for inbound calls. Ok When i modify the mdp.conf : default: load pptp pptp: new -i ng0 pptp pptp set iface disable on-demand set iface enable proxy-arp set iface addrs 2.2.2.2 192.168.1.1 set iface route 192.168.1.0/24 set bundle disable multilink set bundle authname "Name" set bundle password "Password" set bundle enable encryption set link yes acfcomp protocomp set link disable pap set link enable chap set link keep-alive 10 60 set ipcp enable vjcomp set ipcp ranges 2.2.2.2/32 192.168.1.1/32 set ipcp dns 193.252.19.3 set bundle enable compression set ccp enable mppc set ccp enable mpp-e40 set ccp enable mpp-e128 set ccp yes mpp-stateless set bundle enable crypt-reqd The error is the even in this case : (( Nota : The PPTP server is started on the firewall (ipf and ipnat loaded) that is connected to the Lan (192.168.1.0/24). Thank you for taking the time to help out. Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 3329, version 3.13 (root@freebsd.org 11:25 19-Apr-2003) [pptp] ppp node is "mpd3329-pptp" mpd: local IP address for PPTP is 2.2.2.2 [pptp] using interface ng0 [pptp:pptp] mpd: PPTP connection from 1.1.1.1:13013 pptp0: attached to connection with 1.1.1.1:13013 [pptp] IFACE: Open event [pptp] IPCP: Open event [pptp] IPCP: state change Initial --> Starting [pptp] IPCP: LayerStart [pptp] IPCP: Open event [pptp] bundle: OPEN event in state CLOSED [pptp] opening link "pptp"... [pptp] link: OPEN event [pptp] LCP: Open event [pptp] LCP: state change Initial --> Starting [pptp] LCP: LayerStart [pptp] device: OPEN event in state DOWN [pptp] attaching to peer's outgoing call [pptp] device is now in state OPENING [pptp] device: UP event in state OPENING [pptp] device is now in state UP [pptp] link: UP event [pptp] link: origination is remote [pptp] LCP: Up event [pptp] LCP: state change Starting --> Req-Sent [pptp] LCP: phase shift DEAD --> ESTABLISH [pptp] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 44f2b21f AUTHPROTO CHAP MSOFTv2 [pptp] error writing len 27 frame to bypass: No route to host pptp0-0: ignoring SetLinkInfo [pptp] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 44f2b21f AUTHPROTO CHAP MSOFTv2 [pptp] error writing len 27 frame to bypass: No route to host [pptp] LCP: SendConfigReq #3 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 44f2b21f AUTHPROTO CHAP MSOFTv2 ^Cmpd: caught fatal signal int mpd: fatal error, exiting [pptp] IPCP: Down event [pptp] IFACE: Close event [pptp] IPCP: Close event [pptp] IPCP: state change Starting --> Initial From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 12:35:38 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB6FF37B401 for ; Wed, 30 Apr 2003 12:35:38 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 063BB43F85 for ; Wed, 30 Apr 2003 12:35:38 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 32325 invoked from network); 30 Apr 2003 19:35:36 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 30 Apr 2003 19:35:36 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 30 Apr 2003 14:35:23 -0500 (CDT) From: Mike Silbersack To: freebsd-net@freebsd.org Message-ID: <20030430142532.F3741@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1764443641-1051731323=:3741" Subject: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 19:35:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1764443641-1051731323=:3741 Content-Type: TEXT/PLAIN; charset=US-ASCII I'd be interested in comments on the attached patch from anyone who's been doing work with network drivers & such. All it does is add a M_FREELIST flag which is set whenever a mbuf is freed. If m_free or m_freem find this flag to be set, they will panic, as this is a clear sign that the mbuf was freed twice. (All flags are cleared whenever a mbuf is taken off the freelist, so false M_FREELIST hits shouldn't occur.) The system isn't perfect, as it won't catch mbufs which are reallocated before their second free occurs. However, it does seem to do a good job in catching simple double-free errors, which previously caused corruption that lead to panics in codepaths totally unrelated to the original double-free. (One of my double-free tests without this code managed to cause a mutex-related panic, somehow!) I could probably make this code test for use-after-free by checksumming the entire mbuf when M_FREELIST is set and verifying that the checksum has not changed when the mbuf is reallocated, but I think this code is useful enough as it is. Comments? Thanks, Mike "Silby" Silbersack --0-1764443641-1051731323=:3741 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mbuf_double_free_detection.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20030430143523.B3741@odysseus.silby.com> Content-Description: Content-Disposition: attachment; filename="mbuf_double_free_detection.patch" ZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL2tlcm4vc3Vicl9tYnVmLmMg L3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9tYnVmLmMNCi0tLSAvdXNyL3NyYy9z eXMub2xkL2tlcm4vc3Vicl9tYnVmLmMJV2VkIEFwciAzMCAwMDowNTowMyAy MDAzDQorKysgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9tYnVmLmMJV2VkIEFw ciAzMCAxNDoyODozMSAyMDAzDQpAQCAtMTM4MCw2ICsxMzgwLDkgQEANCiAJ aW50IGNjaG51bTsNCiAJc2hvcnQgcGVyc2lzdCA9IDA7DQogDQorCWlmICht Yi0+bV9mbGFncyAmIE1fRlJFRUxJU1QpDQorCQlwYW5pYygibV9mcmVlIGRl dGVjdGVkIGEgbWJ1ZiBkb3VibGUtZnJlZSIpOw0KKwltYi0+bV9mbGFncyB8 PSBNX0ZSRUVMSVNUOw0KIAlpZiAoKG1iLT5tX2ZsYWdzICYgTV9QS1RIRFIp ICE9IDApDQogCQltX3RhZ19kZWxldGVfY2hhaW4obWIsIE5VTEwpOw0KIAlu YiA9IG1iLT5tX25leHQ7DQpAQCAtMTQyMiw2ICsxNDI1LDkgQEANCiAJc2hv cnQgcGVyc2lzdDsNCiANCiAJd2hpbGUgKG1iICE9IE5VTEwpIHsNCisJCWlm IChtYi0+bV9mbGFncyAmIE1fRlJFRUxJU1QpDQorCQkJcGFuaWMoIm1fZnJl ZW0gZGV0ZWN0ZWQgYSBtYnVmIGRvdWJsZS1mcmVlIik7DQorCQltYi0+bV9m bGFncyB8PSBNX0ZSRUVMSVNUOw0KIAkJaWYgKChtYi0+bV9mbGFncyAmIE1f UEtUSERSKSAhPSAwKQ0KIAkJCW1fdGFnX2RlbGV0ZV9jaGFpbihtYiwgTlVM TCk7DQogCQlwZXJzaXN0ID0gMDsNCmRpZmYgLXUgLXIgL3Vzci9zcmMvc3lz Lm9sZC9zeXMvbWJ1Zi5oIC91c3Ivc3JjL3N5cy9zeXMvbWJ1Zi5oDQotLS0g L3Vzci9zcmMvc3lzLm9sZC9zeXMvbWJ1Zi5oCVdlZCBBcHIgMzAgMDA6MDQ6 MDAgMjAwMw0KKysrIC91c3Ivc3JjL3N5cy9zeXMvbWJ1Zi5oCVdlZCBBcHIg MzAgMTI6NDk6NTIgMjAwMw0KQEAgLTE1Myw2ICsxNTMsNyBAQA0KICNkZWZp bmUJTV9QUk9UTzMJMHgwMDQwCS8qIHByb3RvY29sLXNwZWNpZmljICovDQog I2RlZmluZQlNX1BST1RPNAkweDAwODAJLyogcHJvdG9jb2wtc3BlY2lmaWMg Ki8NCiAjZGVmaW5lCU1fUFJPVE81CTB4MDEwMAkvKiBwcm90b2NvbC1zcGVj aWZpYyAqLw0KKyNkZWZpbmUgTV9GUkVFTElTVAkweDQwMDAJLyogbWJ1ZiBp cyBvbiB0aGUgZnJlZSBsaXN0ICovDQogDQogLyoNCiAgKiBtYnVmIHBrdGhk ciBmbGFncyAoYWxzbyBzdG9yZWQgaW4gbV9mbGFncykuDQo= --0-1764443641-1051731323=:3741-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 13:18:54 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1272F37B401 for ; Wed, 30 Apr 2003 13:18:54 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A66043F93 for ; Wed, 30 Apr 2003 13:18:53 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3UKIpVo055538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Apr 2003 16:18:52 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3UKIpcF055535; Wed, 30 Apr 2003 16:18:51 -0400 (EDT) (envelope-from wollman) Date: Wed, 30 Apr 2003 16:18:51 -0400 (EDT) From: Garrett Wollman Message-Id: <200304302018.h3UKIpcF055535@khavrinen.lcs.mit.edu> To: Mike Silbersack In-Reply-To: <20030430015609.M514@odysseus.silby.com> References: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> <20030430015609.M514@odysseus.silby.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 20:18:54 -0000 < said: > Looks good to me, I've been contemplating doing just this for a while. > It's too bad we don't have an inexpensive function we can use for the !DF > case. I'd like to make the OpenBSD function the default for frag packets, > but it seems just too heavyweight.. What we'd really like is cheap random sequences on Z/65536Z. It is fairly trivial to generate cheap non-random sequences on that group -- there's a whole family of trivial ones, but these are easy to analyze. Ultimately I don't think it's really worth that much effort, and the DF trick, since it's normally enabled for all TCP sessions, gives us 99% of the value at 0.1% of the cost. -GAWollman From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 14:35:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA18637B401 for ; Wed, 30 Apr 2003 14:35:39 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C636843F3F for ; Wed, 30 Apr 2003 14:35:38 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 77578 invoked from network); 30 Apr 2003 21:35:37 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 30 Apr 2003 21:35:37 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 30 Apr 2003 16:35:24 -0500 (CDT) From: Mike Silbersack To: Garrett Wollman In-Reply-To: <200304302018.h3UKIpcF055535@khavrinen.lcs.mit.edu> Message-ID: <20030430162628.A3741@odysseus.silby.com> References: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> <200304302018.h3UKIpcF055535@khavrinen.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 21:35:40 -0000 On Wed, 30 Apr 2003, Garrett Wollman wrote: > What we'd really like is cheap random sequences on Z/65536Z. It is > fairly trivial to generate cheap non-random sequences on that group -- > there's a whole family of trivial ones, but these are easy to analyze. > Ultimately I don't think it's really worth that much effort, and the > DF trick, since it's normally enabled for all TCP sessions, gives us > 99% of the value at 0.1% of the cost. > > -GAWollman I think that even a trivial pseudo-random sequence would be good to implement. With the standard ip_id++ sequence, you can precisely monitor the number of packets sent and also determine if two IPs are shared by the machine without any work. Any sort of psuedo-random sequence would at least require you to go through some work to determine any information. I have this nagging feeling that taking most TCP sessions out of the equation makes the obfuscation of the remaining ip_id'd packets more important, but I can't figure out why exactly. Do we set the DF flag on most UDP and ICMP packets? Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 14:42:38 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38AAC37B401 for ; Wed, 30 Apr 2003 14:42:38 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 587E343F3F for ; Wed, 30 Apr 2003 14:42:37 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3ULgZVo056436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Apr 2003 17:42:36 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3ULgZ0i056433; Wed, 30 Apr 2003 17:42:35 -0400 (EDT) (envelope-from wollman) Date: Wed, 30 Apr 2003 17:42:35 -0400 (EDT) From: Garrett Wollman Message-Id: <200304302142.h3ULgZ0i056433@khavrinen.lcs.mit.edu> To: Mike Silbersack In-Reply-To: <20030430162628.A3741@odysseus.silby.com> References: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> <20030430015609.M514@odysseus.silby.com> <200304302018.h3UKIpcF055535@khavrinen.lcs.mit.edu> <20030430162628.A3741@odysseus.silby.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 21:42:38 -0000 < said: > I think that even a trivial pseudo-random sequence would be good to > implement. With the standard ip_id++ sequence, you can precisely monitor > the number of packets sent and also determine if two IPs are shared by the > machine without any work. See Bellovin's paper for how to do it for any fixed increment without much work. The trouble is that we need sequences that are guaranteed not to repeat too fast -- and even then we'll still break on modern networks anyway, as I noted in my comment. Solaris apparently goes out of its way to create a different ip_id sequence for every combination of (which is allowed), but this still doesn't buy you much if your system is capable of performing NFSv2 transactions at 100 Mbit/s. > I have this nagging feeling that taking most TCP sessions out of the > equation makes the obfuscation of the remaining ip_id'd packets more > important, but I can't figure out why exactly. I feel rather the opposite. > Do we set the DF flag on most UDP and ICMP packets? ping(8) can set it, but the kernel is not able to do so, since it can't predict the MTU in advance of sending the ICMP. -GAWollman From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 15:20:38 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DBA737B401 for ; Wed, 30 Apr 2003 15:20:38 -0700 (PDT) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id B53F443FB1 for ; Wed, 30 Apr 2003 15:20:36 -0700 (PDT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 86149 invoked from network); 30 Apr 2003 22:39:04 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 30 Apr 2003 22:39:04 -0000 Received: (nullmailer pid 1573 invoked by uid 136); Wed, 30 Apr 2003 22:23:44 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <200304302142.h3ULgZ0i056433@khavrinen.lcs.mit.edu> To: Garrett Wollman Date: Thu, 1 May 2003 02:23:44 +0400 (MSD) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1051741424.259802.1572.nullmailer@cicuta.babolo.ru> cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 22:20:38 -0000 > < said: > > > I think that even a trivial pseudo-random sequence would be good to > > implement. With the standard ip_id++ sequence, you can precisely monitor > > the number of packets sent and also determine if two IPs are shared by the > > machine without any work. > > See Bellovin's paper for how to do it for any fixed increment without > much work. > > The trouble is that we need sequences that are guaranteed not to > repeat too fast -- and even then we'll still break on modern networks > anyway, as I noted in my comment. Why not to use 16 bit of 32 bit pseudorandom generator? > Solaris apparently goes out of its way to create a different ip_id > sequence for every combination of (which is allowed), > but this still doesn't buy you much if your system is capable of > performing NFSv2 transactions at 100 Mbit/s. > > > I have this nagging feeling that taking most TCP sessions out of the > > equation makes the obfuscation of the remaining ip_id'd packets more > > important, but I can't figure out why exactly. > > I feel rather the opposite. > > > Do we set the DF flag on most UDP and ICMP packets? > > ping(8) can set it, but the kernel is not able to do so, since it > can't predict the MTU in advance of sending the ICMP. From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 16:05:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30D6437B401 for ; Wed, 30 Apr 2003 16:05:44 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9144F43F75 for ; Wed, 30 Apr 2003 16:05:41 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by rwcrmhc53.attbi.com (rwcrmhc53) with ESMTP id <2003043023054105300f824ve>; Wed, 30 Apr 2003 23:05:41 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h3UN5eki004444; Wed, 30 Apr 2003 16:05:40 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h3UN5dHP004443; Wed, 30 Apr 2003 16:05:39 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Wed, 30 Apr 2003 16:05:39 -0700 From: "Crist J. Clark" To: "."@babolo.ru Message-ID: <20030430230539.GB3912@blossom.cjclark.org> References: <200304302142.h3ULgZ0i056433@khavrinen.lcs.mit.edu> <1051741424.259802.1572.nullmailer@cicuta.babolo.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1051741424.259802.1572.nullmailer@cicuta.babolo.ru> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: Garrett Wollman cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 23:05:44 -0000 On Thu, May 01, 2003 at 02:23:44AM +0400, "."@babolo.ru wrote: > > < said: [snip] > > The trouble is that we need sequences that are guaranteed not to > > repeat too fast -- and even then we'll still break on modern networks > > anyway, as I noted in my comment. > Why not to use 16 bit of 32 bit pseudorandom generator? Uhh... I might be missing a joke here, but the problem is that after you put 65536 packets onto the wire, the next one _must_ have a repeated IP ID (since there are only 65536 possible). Choosing a random IP ID only can make this problem worse. As many of the references perviously discussed or a very simple calculation on your own will show, with a perfect random generator, after about 300 packets, there is a 50-50 chance the next packet's IP ID will collide (good ol' "birthday paradox"). -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 16:17:15 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC9E537B401 for ; Wed, 30 Apr 2003 16:17:15 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 078E543F75 for ; Wed, 30 Apr 2003 16:17:15 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2003043023171400100nlg6he>; Wed, 30 Apr 2003 23:17:14 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h3UNHDki004476; Wed, 30 Apr 2003 16:17:13 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h3UNHC8o004475; Wed, 30 Apr 2003 16:17:12 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Wed, 30 Apr 2003 16:17:12 -0700 From: "Crist J. Clark" To: Garrett Wollman Message-ID: <20030430231712.GC3912@blossom.cjclark.org> References: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 23:17:16 -0000 On Tue, Apr 29, 2003 at 06:47:51PM -0400, Garrett Wollman wrote: [snip] > Index: ip_output.c > =================================================================== > RCS file: /home/cvs/src/sys/netinet/ip_output.c,v > retrieving revision 1.187 > diff -u -r1.187 ip_output.c > --- ip_output.c 12 Apr 2003 06:11:46 -0000 1.187 > +++ ip_output.c 29 Apr 2003 22:42:55 -0000 > @@ -223,17 +223,29 @@ > pkt_dst = args.next_hop ? args.next_hop->sin_addr : ip->ip_dst; > > /* > - * Fill in IP header. > + * Fill in IP header. If we are not allowing fragmentation, > + * then the ip_id field is meaningless, so send it as zero > + * to reduce information leakage. Otherwise, if we are not > + * randomizing ip_id, then don't bother to convert it to network > + * byte order -- it's just a nonce. Note that a 16-bit counter > + * will wrap around in less than 10 seconds at 100 Mbit/s on a > + * medium with MTU 1500. See Steven M. Bellovin, "A Technique > + * for Counting NATted Hosts", Proc. IMW'02, available at > + * . > */ [snip] > - ip->ip_id = htons(ip_id++); > + ip->ip_id = ip_id++; This is actually bad with respect to the spirit of the paper and the whole idea of information leakage. If I have two FreeBSD machines, one i386 and one sparc64, they now look different to someone sniffing the traffic. If I leave the htons(), all of my FreeBSD hosts look alike. There is less information content in the IP ID field. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 17:00:06 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D49A437B401 for ; Wed, 30 Apr 2003 17:00:06 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1084143F85 for ; Wed, 30 Apr 2003 17:00:06 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id QAA96366; Wed, 30 Apr 2003 16:51:47 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h3UNpk2r077258; Wed, 30 Apr 2003 16:51:46 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3UNpkBa077257; Wed, 30 Apr 2003 16:51:46 -0700 (PDT) From: Archie Cobbs Message-Id: <200304302351.h3UNpkBa077257@arch20m.dellroad.org> In-Reply-To: <20030430142532.F3741@odysseus.silby.com> To: Mike Silbersack Date: Wed, 30 Apr 2003 16:51:46 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@FreeBSD.ORG Subject: Re: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 00:00:07 -0000 Mike Silbersack wrote: > I'd be interested in comments on the attached patch from anyone who's been > doing work with network drivers & such. All it does is add a M_FREELIST > flag which is set whenever a mbuf is freed. If m_free or m_freem find > this flag to be set, they will panic, as this is a clear sign that the > mbuf was freed twice. (All flags are cleared whenever a mbuf is > taken off the freelist, so false M_FREELIST hits shouldn't occur.) Without reviewing the patch, I like the idea a whole lot. We added similar sanity checks at Vernier and they were very helpful. -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 17:55:07 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3569D37B401 for ; Wed, 30 Apr 2003 17:55:07 -0700 (PDT) Received: from postala.lbl.gov (postala.lbl.gov [128.3.41.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA86043FD7 for ; Wed, 30 Apr 2003 17:55:03 -0700 (PDT) (envelope-from brdraney@hawkfarm.lbl.gov) Received: from postala.lbl.gov (localhost [127.0.0.1]) by postala.lbl.gov (8.12.9/8.12.9) with ESMTP id h410t1gI025301 for ; Wed, 30 Apr 2003 17:55:01 -0700 (PDT) Received: from postal.lbl.gov (postal.lbl.gov [128.3.1.85]) by postala.lbl.gov (8.12.9/8.12.9) with ESMTP id h410t1Lw025297 for ; Wed, 30 Apr 2003 17:55:01 -0700 (PDT) Received: from hawkfarm.lbl.gov (hawkfarm.lbl.gov [128.3.1.84]) by postal.lbl.gov (8.8.7/8.8.7) with ESMTP id WAA28877 for ; Sun, 27 Apr 2003 22:24:01 -0700 (PDT) Message-Id: <200304280524.WAA28877@postal.lbl.gov> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-net@freebsd.org From: Brent Draney Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Apr 2003 17:54:58 -0700 Sender: brdraney@hawkfarm.lbl.gov Subject: Gigabit etherchanneling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Brent Draney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 00:55:07 -0000 Hi networking guru's, Has ne1 played with etherchanneling gigabit interfaces? I'm trying to figure out the current right way to do this. Is ng_fec the best place to start? Thanks in advance, Brent Draney NERSC Networking and Security From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 18:43:31 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1394237B401; Wed, 30 Apr 2003 18:43:31 -0700 (PDT) Received: from net2.dinoex.sub.org (net2.dinoex.de [212.184.201.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7AD043F3F; Wed, 30 Apr 2003 18:43:28 -0700 (PDT) (envelope-from pmc@citylink.dinoex.sub.org) Received: from net2.dinoex.sub.org (uucp@net2.dinoex.de [212.184.201.182]) by net2.dinoex.sub.org (8.12.9/8.12.9) with ESMTP id h411hKgx017127; Thu, 1 May 2003 03:43:22 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: net2.dinoex.sub.org: Host uucp@net2.dinoex.de [212.184.201.182] claimed to be net2.dinoex.sub.org Received: from citylink.dinoex.sub.org (uucp@localhost) h411hJYY017126; Thu, 1 May 2003 03:43:19 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from citylink.dinoex.sub.de by citylink.dinoex.sub.org (8.8.5/PMuch-B3b) with ESMTP id CAA05101; Thu, 1 May 2003 02:07:32 +0200 (CEST) Received: from gate.oper.dinoex.org (localhost [127.0.0.1]) h410Ei1i001544; Thu, 1 May 2003 02:14:45 +0200 (CEST) (envelope-from pmc@disp.oper.dinoex.org) Received: from disp.oper.dinoex.org (disp-e [192.168.98.5]) by gate.oper.dinoex.org (8.12.6/8.12.6) with ESMTP id h410DWAj001533; Thu, 1 May 2003 02:13:38 +0200 (CEST) (envelope-from pmc@disp.oper.dinoex.org) Received: (from pmc@localhost) by disp.oper.dinoex.org (8.11.6/8.11.6) id h410BQw20930; Thu, 1 May 2003 02:11:26 +0200 (CEST) (envelope-from pmc) From: Peter Much Message-Id: <200305010011.h410BQw20930@disp.oper.dinoex.org> To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Date: Thu, 1 May 2003 02:11:25 +0200 (CEST) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=DISPLAY Content-Transfer-Encoding: 8bit Subject: rsh crashes 4.7 kernel, help needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 01:43:31 -0000 Hi all, I am stuck with this one: My gateway machine, a 486dx66 running PPPoE/natd/ipfw on a 4.7.0-RELEASE installation, runs totally stable for weeks, except when moving large amounts of data out of the machine via rsh (my backup routines do that). Then, not too often, but repeatabe, kernel crashs do happens from rsh. It seems that the crashes do happen especially if the data flow is repeatedly interrupted for longer times -during tape movement etc.-, but that is only a supposition. The stack trace always shows the same functions, ending in m_copym(). While it may be true that there is no need to do full backups from a gateway machine, I am still unhappy about this effect, and would rather like to fix it. Therefore, I made room for crashdumps, built a debug-kernel, and activated INVARIANTS for m_copym(). Now the gdb shows the attached output. It does not seem to me that m_copym() should be called with 0 as the first parameter, but when looking into tcp_output(), I quit: this is too large and complicated for me to understand. The network card that would transfer the data, is the following one, and AFAIK there are no known issues with it: ed0 at port 0x300-0x31f iomem 0xd8000-0xdbfff irq 10 on isa0 ed0: address 00:00:c0:30:b7:2f, type WD8013EPC (16 bit) So my question is, what to do now. Input is very much appreciated. rgds, PMc ---------------------------------------------------------------- initial pcb at physical address 0x003b7b20 panicstr: m_copym, length > size of mbuf chain panic messages: --- panic: m_copym, length > size of mbuf chain syncing disks... 4 done Uptime: 3d17h17m38s dumping to dev #da/1, offset 480 dump 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 dumpsys () at ../../kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) bt full #0 dumpsys () at ../../kern/kern_shutdown.c:487 error = 0 #1 0xc01a56a7 in boot (howto=256) at ../../kern/kern_shutdown.c:316 howto = 256 #2 0xc01a5ae9 in panic (fmt=0xc032f6a0 "m_copym, length > size of mbuf chain") at ../../kern/kern_shutdown.c:595 fmt = 0xc032f6a0 "m_copym, length > size of mbuf chain" bootopt = 256 buf = "m_copym, length > size of mbuf chain", '\000' #3 0xc01c1b1d in m_copym (m=0x0, off0=1448, len=920, wait=1) at ../../kern/uipc_mbuf.c:806 n = (struct mbuf *) 0xc06a8c00 np = (struct mbuf **) 0xc06a8c00 off = 0 top = (struct mbuf *) 0xc06a8c00 copyhdr = 0 #4 0xc0221cd5 in tcp_output (tp=0xc471ee40) at ../../netinet/tcp_output.c:612 tp = (struct tcpcb *) 0xc471ee40 so = (struct socket *) 0xc46d0cc0 len = 1448 win = 57920 off = 1448 flags = 16 error = 0 m = (struct mbuf *) 0xc06ec400 ip = (struct ip *) 0x0 ip6 = (struct ip6_hdr *) 0x0 th = (struct tcphdr *) 0x5a8 opt = "\001\001\b\n\001éå\004\0026JS\000\000\000\000äýÍÄGd\034À0\rmÄ\000+lÀ\000UnÀ\020þÍÄ" ipoptlen = 1448 optlen = 12 hdrlen = 52 idle = 0 sendalot = 1 taop = (struct rmxp_tao *) 0x5a8 tao_noncached = {tao_cc = 1, tao_ccsent = 0, tao_mssopt = 32} isipv6 = 0 #5 0xc0226445 in tcp_usr_send (so=0xc46d0cc0, flags=0, m=0xc06c2b00, nam=0x0, control=0x0, p=0xc4c4f100) at ../../netinet/tcp_usrreq.c:578 m = (struct mbuf *) 0xc06c2b00 control = (struct mbuf *) 0x0 s = 6422528 error = 0 inp = (struct inpcb *) 0x0 tp = (struct tcpcb *) 0xc471ee40 isipv6 = 0 ostate = 4 #6 0xc01c4403 in sosend (so=0xc46d0cc0, addr=0x0, uio=0xc4cdfed4, top=0xc06c2b00, control=0x0, flags=0, p=0xc4c4f100) at ../../kern/uipc_socket.c:609 mp = (struct mbuf **) 0xc06c2b00 m = (struct mbuf *) 0xc06c2b00 space = 29880 len = 0 resid = 0 clen = -1066652928 error = -999486272 s = 0 dontroute = 0 mlen = 2048 atomic = 0 #7 0xc01b7a70 in soo_write (fp=0xc0c4cbc0, uio=0xc4cdfed4, cred=0xc0b87780, flags=0, p=0xc4c4f100) at ../../kern/sys_socket.c:81 fp = (struct file *) 0x0 uio = (struct uio *) 0x0 so = (struct socket *) 0x0 #8 0xc01b4701 in dofilewrite (p=0xc4c4f100, fp=0xc0c4cbc0, fd=3, buf=0xbfbff5bc, nbyte=1024, offset=-1, flags=0) at ../../sys/file.h:162 error = -993726208 fp = (struct file *) 0xc0c4cbc0 cred = (struct ucred *) 0x0 p = (struct proc *) 0xc4c4f100 fp = (struct file *) 0xc0c4cbc0 offset = 0 auio = {uio_iov = 0xc4cdfeac, uio_iovcnt = 1, uio_offset = 1023, uio_resid = 0, uio_segflg = UIO_USERSPACE, uio_rw = UIO_WRITE, uio_procp = 0xc4c4f100} aiov = {iov_base = 0xbfbff9bc "\b", iov_len = 0} cnt = 1024 error = -993726208 ktriov = {iov_base = 0xc4cdfed8 "\001", iov_len = 3224186978} ktruio = {uio_iov = 0x0, uio_iovcnt = 1, uio_offset = -4268021561307097088, uio_resid = 0, uio_segflg = 3217029564, uio_rw = UIO_READ, uio_procp = 0xc0951800} didktr = 0 #9 0xc01b45ba in write (p=0xc4c4f100, uap=0xc4cdff80) at ../../kern/sys_generic.c:329 p = (struct proc *) 0xc4c4f100 uap = (struct write_args *) 0xc4cdff80 fp = (struct file *) 0xc0c4cbc0 error = -993132672 #10 0xc02eaa99 in syscall2 (frame={tf_fs = -1078001617, tf_es = -993198033, tf_ds = -1078001617, tf_edi = -1077938756, tf_esi = 1024, tf_ebp = -1077937348, tf_isp = -993132588, tf_ebx = -1077937732, tf_edx = 3, tf_ecx = 3, tf_eax = 4, tf_trapno = 7, tf_err = 2, tf_eip = 672005944, tf_cs = 31, tf_eflags = 663, tf_esp = -1077938816, tf_ss = 47}) at ../../i386/i386/trap.c:1175 params = 0xbfbff584 "\003" i = 0 callp = (struct sysent *) 0xc038d7a0 p = (struct proc *) 0xc4c4f100 orig_tf_eflags = 663 sticks = 60359 error = 0 narg = 3 args = {3, -1077938756, 1024, 0, 0, 0, 0, 0} have_mplock = 1 code = 4 #11 0xc02de205 in Xint0x80_syscall () No symbol table info available. #12 0x8048f84 in ?? () No symbol table info available. #13 0x8048ae9 in ?? () No symbol table info available. From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 23:27:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA70837B401 for ; Wed, 30 Apr 2003 23:27:00 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAB2E43FB1 for ; Wed, 30 Apr 2003 23:26:59 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])h416Qwww028881; Thu, 1 May 2003 02:26:58 -0400 (EDT) Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.9/8.12.1/Submit) id h416Qwr9028880; Thu, 1 May 2003 02:26:58 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) X-Authentication-Warning: angelica.unixdaemons.com: bmilekic set sender to bmilekic@unixdaemons.com using -f Date: Thu, 1 May 2003 02:26:58 -0400 From: Bosko Milekic To: Mike Silbersack Message-ID: <20030501062658.GA26458@unixdaemons.com> References: <20030430142532.F3741@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030430142532.F3741@odysseus.silby.com> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 06:27:01 -0000 On Wed, Apr 30, 2003 at 02:35:23PM -0500, Mike Silbersack wrote: > > I'd be interested in comments on the attached patch from anyone who's been > doing work with network drivers & such. All it does is add a M_FREELIST > flag which is set whenever a mbuf is freed. If m_free or m_freem find > this flag to be set, they will panic, as this is a clear sign that the > mbuf was freed twice. (All flags are cleared whenever a mbuf is > taken off the freelist, so false M_FREELIST hits shouldn't occur.) > > The system isn't perfect, as it won't catch mbufs which are reallocated > before their second free occurs. However, it does seem to do a good job > in catching simple double-free errors, which previously caused corruption > that lead to panics in codepaths totally unrelated to the original > double-free. (One of my double-free tests without this code managed to > cause a mutex-related panic, somehow!) > > I could probably make this code test for use-after-free by checksumming > the entire mbuf when M_FREELIST is set and verifying that the checksum has > not changed when the mbuf is reallocated, but I think this code is useful > enough as it is. > > Comments? > > Thanks, This sounds like a good idea but there is a potential bogon if you enable it by default. There is a certain producer/consumer relationship with mbuf consumption in some cases and in which case you would have one thread allocating a bunch of mbufs, writing to them, etc., and another thread reclaiming the data, but not writing to it, and then freeing the mbufs. If I understand it correctly, your patch introduces a write-to-mbuf-data on free, which may force unnecessary slot invalidations... this may sound a little "cooked up," but there is certainly an effort to not write to the object being freed during free so as to not force unnecessary invalidations in the producer/consumer cases such as the one described. -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Thu May 1 04:12:13 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCE5837B401 for ; Thu, 1 May 2003 04:12:12 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C6B643FB1 for ; Thu, 1 May 2003 04:12:11 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h41BCBBp003861; Thu, 1 May 2003 04:12:11 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h41BCAFS003860; Thu, 1 May 2003 04:12:10 -0700 (PDT) (envelope-from rizzo) Date: Thu, 1 May 2003 04:12:10 -0700 From: Luigi Rizzo To: Mike Silbersack Message-ID: <20030501041210.A3514@xorpc.icir.org> References: <20030430142532.F3741@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030430142532.F3741@odysseus.silby.com>; from silby@silby.com on Wed, Apr 30, 2003 at 02:35:23PM -0500 cc: freebsd-net@freebsd.org Subject: Re: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 11:12:13 -0000 as Bosko noticed, it would be a good idea to make the change to subr_mbuf.c conditionally compiled under DIAGNOSTIC or INVARIANTS or the like. I was actually wondering if you have caught already any bug with this code enabled. [on a side note, it is a bit depressing to see the same code replicated twice, in m_free() and m_freem(). Couldn't one try to make m_freem() just call m_free() in a loop and save some code bloat ? I doubt the extra function call would harm performance too much.] cheers luigi On Wed, Apr 30, 2003 at 02:35:23PM -0500, Mike Silbersack wrote: > > I'd be interested in comments on the attached patch from anyone who's been > doing work with network drivers & such. All it does is add a M_FREELIST ... From owner-freebsd-net@FreeBSD.ORG Thu May 1 05:35:28 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C41B37B401 for ; Thu, 1 May 2003 05:35:28 -0700 (PDT) Received: from rms21.rommon.net (rms21.rommon.net [193.64.42.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF83F43F93 for ; Thu, 1 May 2003 05:35:26 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PHE (h93.vuokselantie10.fi [193.64.42.147]) by rms21.rommon.net (8.12.6p2/8.12.6) with SMTP id h41CZLiZ062165; Thu, 1 May 2003 15:35:22 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <003901c30fde$37f2a0f0$932a40c1@PHE> From: "Petri Helenius" To: "Luigi Rizzo" , "Mike Silbersack" References: <20030430142532.F3741@odysseus.silby.com> <20030501041210.A3514@xorpc.icir.org> Date: Thu, 1 May 2003 15:35:56 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-net@freebsd.org Subject: Re: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 12:35:28 -0000 > > [on a side note, it is a bit depressing to see the same > code replicated twice, in m_free() and m_freem(). Couldn't > one try to make m_freem() just call m_free() in a loop and > save some code bloat ? I doubt the extra function call > would harm performance too much.] > Allocating / freeing mbufs is quite expensive already so it probably does not make that huge a difference. However the direction should be to improve the perfomance. Pete From owner-freebsd-net@FreeBSD.ORG Thu May 1 07:52:24 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9D8437B401 for ; Thu, 1 May 2003 07:52:24 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CA9243F85 for ; Thu, 1 May 2003 07:52:24 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h41EqOBp034046; Thu, 1 May 2003 07:52:24 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h41EqNmU034045; Thu, 1 May 2003 07:52:23 -0700 (PDT) (envelope-from rizzo) Date: Thu, 1 May 2003 07:52:23 -0700 From: Luigi Rizzo To: Petri Helenius Message-ID: <20030501075222.A33903@xorpc.icir.org> References: <20030430142532.F3741@odysseus.silby.com> <20030501041210.A3514@xorpc.icir.org> <003901c30fde$37f2a0f0$932a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <003901c30fde$37f2a0f0$932a40c1@PHE>; from pete@he.iki.fi on Thu, May 01, 2003 at 03:35:56PM +0300 cc: freebsd-net@freebsd.org Subject: Re: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 14:52:25 -0000 On Thu, May 01, 2003 at 03:35:56PM +0300, Petri Helenius wrote: ... > Allocating / freeing mbufs is quite expensive already so it probably does not make > that huge a difference. However the direction should be to improve the perfomance. it is not clear at all that a function call is more expensive than replicating a relatively large chunk of code. In fact, i have had quite a few surprise in the past when making a function __inline and the code turning out slower than the original. cheers luigi > Pete > > _______________________________________________ > 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 Thu May 1 08:38:50 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEE5B37B401 for ; Thu, 1 May 2003 08:38:50 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 6B8FF43F75 for ; Thu, 1 May 2003 08:38:49 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 6285 invoked from network); 1 May 2003 15:38:48 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 1 May 2003 15:38:48 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 1 May 2003 10:38:31 -0500 (CDT) From: Mike Silbersack To: Luigi Rizzo In-Reply-To: <20030501041210.A3514@xorpc.icir.org> Message-ID: <20030501103520.S6445@odysseus.silby.com> References: <20030430142532.F3741@odysseus.silby.com> <20030501041210.A3514@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 15:38:51 -0000 On Thu, 1 May 2003, Luigi Rizzo wrote: > as Bosko noticed, it would be a good idea to make the change to subr_mbuf.c > conditionally compiled under DIAGNOSTIC or INVARIANTS or the like. Hsu already convinced me to put it under INVARIANTS in private mail. > I was actually wondering if you have caught already any bug > with this code enabled. Nope, not yet. I was just trying to figure out how mbuf free list corruption could occur, and a double-free seemed to be an obvious thing to try. Once I found how much it messed things up, I came up with this patch. > [on a side note, it is a bit depressing to see the same > code replicated twice, in m_free() and m_freem(). Couldn't > one try to make m_freem() just call m_free() in a loop and > save some code bloat ? I doubt the extra function call > would harm performance too much.] > > cheers > luigi Someone seems to have placed a SEP field around that paragraph, I'm having trouble reading it. :) Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu May 1 10:06:41 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92A7637B401 for ; Thu, 1 May 2003 10:06:41 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2A8243F93 for ; Thu, 1 May 2003 10:06:40 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])h41H6dww019090; Thu, 1 May 2003 13:06:39 -0400 (EDT) Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.9/8.12.1/Submit) id h41H6c9G019089; Thu, 1 May 2003 13:06:38 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) X-Authentication-Warning: angelica.unixdaemons.com: bmilekic set sender to bmilekic@unixdaemons.com using -f Date: Thu, 1 May 2003 13:06:38 -0400 From: Bosko Milekic To: Luigi Rizzo Message-ID: <20030501170638.GA17758@unixdaemons.com> References: <20030430142532.F3741@odysseus.silby.com> <20030501041210.A3514@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501041210.A3514@xorpc.icir.org> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 17:06:41 -0000 On Thu, May 01, 2003 at 04:12:10AM -0700, Luigi Rizzo wrote: > as Bosko noticed, it would be a good idea to make the change to subr_mbuf.c > conditionally compiled under DIAGNOSTIC or INVARIANTS or the like. > > I was actually wondering if you have caught already any bug > with this code enabled. > > [on a side note, it is a bit depressing to see the same > code replicated twice, in m_free() and m_freem(). Couldn't > one try to make m_freem() just call m_free() in a loop and > save some code bloat ? I doubt the extra function call > would harm performance too much.] > > cheers > luigi The reason it's done that way has to do with a bigger optimization than just the avoidance of the extra function call: the cache lock is held, as most as possible, across repeated calls to mb_free(). In order to implement this "as most as possible," to allow for virtually atomic frees in some cases, it was ripped out and done that way... if you can figure out a cleaner way, that would be cool, though. -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Thu May 1 11:36:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDE5A37B407 for ; Thu, 1 May 2003 11:36:40 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EA3043FB1 for ; Thu, 1 May 2003 11:36:40 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h41IadBp065797; Thu, 1 May 2003 11:36:39 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h41Iad4i065796; Thu, 1 May 2003 11:36:39 -0700 (PDT) (envelope-from rizzo) Date: Thu, 1 May 2003 11:36:39 -0700 From: Luigi Rizzo To: Bosko Milekic Message-ID: <20030501113639.B65552@xorpc.icir.org> References: <20030430142532.F3741@odysseus.silby.com> <20030501041210.A3514@xorpc.icir.org> <20030501170638.GA17758@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030501170638.GA17758@unixdaemons.com>; from bmilekic@unixdaemons.com on Thu, May 01, 2003 at 01:06:38PM -0400 cc: freebsd-net@freebsd.org Subject: Re: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 18:36:41 -0000 On Thu, May 01, 2003 at 01:06:38PM -0400, Bosko Milekic wrote: ... > The reason it's done that way has to do with a bigger optimization > than just the avoidance of the extra function call: the cache lock is > held, as most as possible, across repeated calls to mb_free(). In > order to implement this "as most as possible," to allow for virtually > atomic frees in some cases, it was ripped out and done that way... if > you can figure out a cleaner way, that would be cool, though. but according to the comment (and the code) that optimization is not there yet because of issues in some of the functions called in the body. Given that you have clearly documented what the plan is and what the issues are, i would suggest to revert m_freem() to use m_free() until those issues are solved. In addition to reducing the code size, this would also reduce the risk that the two pieces of code diverge by mistake. cheers luigi > -- > Bosko Milekic > bmilekic@unixdaemons.com > bmilekic@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 Thu May 1 12:17:37 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F211D37B401 for ; Thu, 1 May 2003 12:17:36 -0700 (PDT) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3295D43FBD for ; Thu, 1 May 2003 12:17:36 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: from angelica.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])h41JHYww058947; Thu, 1 May 2003 15:17:34 -0400 (EDT) Received: (from bmilekic@localhost) by angelica.unixdaemons.com (8.12.9/8.12.1/Submit) id h41JHXXp058946; Thu, 1 May 2003 15:17:33 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) X-Authentication-Warning: angelica.unixdaemons.com: bmilekic set sender to bmilekic@unixdaemons.com using -f Date: Thu, 1 May 2003 15:17:33 -0400 From: Bosko Milekic To: Luigi Rizzo Message-ID: <20030501191733.GA58454@unixdaemons.com> References: <20030430142532.F3741@odysseus.silby.com> <20030501041210.A3514@xorpc.icir.org> <20030501170638.GA17758@unixdaemons.com> <20030501113639.B65552@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030501113639.B65552@xorpc.icir.org> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: Review needed: Mbuf double-free detection patch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2003 19:17:37 -0000 On Thu, May 01, 2003 at 11:36:39AM -0700, Luigi Rizzo wrote: > On Thu, May 01, 2003 at 01:06:38PM -0400, Bosko Milekic wrote: > ... > > The reason it's done that way has to do with a bigger optimization > > than just the avoidance of the extra function call: the cache lock is > > held, as most as possible, across repeated calls to mb_free(). In > > order to implement this "as most as possible," to allow for virtually > > atomic frees in some cases, it was ripped out and done that way... if > > you can figure out a cleaner way, that would be cool, though. > > but according to the comment (and the code) that optimization > is not there yet because of issues in some of the functions > called in the body. Given that you have clearly documented what the > plan is and what the issues are, i would suggest to revert m_freem() > to use m_free() until those issues are solved. In addition to > reducing the code size, this would also reduce the risk that the > two pieces of code diverge by mistake. Well, I was going to actually complete the optimization for the cluster case (because cluster ref counts are no longer malloc'd), but now that there's a call to m_tag_destroy in the body, I don't know if it's possible at all. So what you're proposing makes sense. > cheers > luigi > > > -- > > Bosko Milekic > > bmilekic@unixdaemons.com > > bmilekic@FreeBSD.org -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Thu May 1 23:09:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03C6D37B401 for ; Thu, 1 May 2003 23:09:00 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5B74B43F75 for ; Thu, 1 May 2003 23:08:59 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 47824 invoked from network); 2 May 2003 06:08:57 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 2 May 2003 06:08:57 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 2 May 2003 01:08:45 -0500 (CDT) From: Mike Silbersack To: freebsd-net@freebsd.org Message-ID: <20030502010545.U610@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1806121823-1051855725=:610" Subject: More mbuf INVARIANTS code, comments needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 06:09:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1806121823-1051855725=:610 Content-Type: TEXT/PLAIN; charset=US-ASCII Now that I have the double-free code in (under INVARIANTS), I'm considering the attached patch as well; it fills the m_data, m_next, and m_nextpkt fields with non-NULL garbage in hopes that any uses after free will be immediately fatal. Does anyone see problems with this, and/or other simple checks that could be added cheaply? Thanks, Mike "Silby" Silbersack --0-1806121823-1051855725=:610 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mbuf_more_invariants.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20030502010845.J610@odysseus.silby.com> Content-Description: Content-Disposition: attachment; filename="mbuf_more_invariants.patch" ZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL2tlcm4vc3Vicl9tYnVmLmMg L3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9tYnVmLmMNCi0tLSAvdXNyL3NyYy9z eXMub2xkL2tlcm4vc3Vicl9tYnVmLmMJVGh1IE1heSAgMSAyMjo1NTowOSAy MDAzDQorKysgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9tYnVmLmMJRnJpIE1h eSAgMiAwMDo1MzowOCAyMDAzDQpAQCAtMTQwNCw2ICsxNDA0LDEyIEBADQog CQkJfQ0KIAkJfQ0KIAl9DQorI2lmZGVmIElOVkFSSUFOVFMNCisJLyogRmls bCB3aXRoIGp1bmsgZGF0YSB0byBwcm92b2tlIHBhbmljcyBmcm9tIGFjY2Vz c2VzIGFmdGVyIGZyZWUgKi8NCisJbWItPm1fZGF0YSA9ICh2b2lkICopIDB4 MTM3Ow0KKwltYi0+bV9uZXh0ID0gKHZvaWQgKikgMHgxMzg7DQorCW1iLT5t X25leHRwa3QgPSAodm9pZCAqKSAweDEzOTsNCisjZW5kaWYNCiAJbWJfZnJl ZSgmbWJfbGlzdF9tYnVmLCBtYiwgbWItPm1fdHlwZSwgcGVyc2lzdCwgJmNj aG51bSk7DQogCXJldHVybiAobmIpOw0KIH0NCkBAIC0xNDUzLDYgKzE0NTks MTIgQEANCiAJCQkJfQ0KIAkJCX0NCiAJCX0NCisjaWZkZWYgSU5WQVJJQU5U Uw0KKwkJLyogRmlsbCB3aXRoIGp1bmsgZGF0YSB0byBwcm92b2tlIHBhbmlj cyBmcm9tIGFjY2Vzc2VzIGFmdGVyIGZyZWUgKi8NCisJCW0tPm1fZGF0YSA9 ICh2b2lkICopIDB4MTM3Ow0KKwkJbS0+bV9uZXh0ID0gKHZvaWQgKikgMHgx Mzg7DQorCQltLT5tX25leHRwa3QgPSAodm9pZCAqKSAweDEzOTsNCisjZW5k aWYNCiAJCW1iX2ZyZWUoJm1iX2xpc3RfbWJ1ZiwgbSwgbS0+bV90eXBlLCBw ZXJzaXN0LCAmY2NobnVtKTsNCiAJfQ0KIH0NCg== --0-1806121823-1051855725=:610-- From owner-freebsd-net@FreeBSD.ORG Fri May 2 00:46:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1045E37B401 for ; Fri, 2 May 2003 00:46:30 -0700 (PDT) Received: from mercure.vincentjardin.net (AVelizy-102-1-3-212.abo.wanadoo.fr [217.128.244.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id B92D643FBD for ; Fri, 2 May 2003 00:46:28 -0700 (PDT) (envelope-from jardin@mercure.vincentjardin.net) Received: from mercure.vincentjardin.net (localhost.vincentjardin.net [127.0.0.1])h427kQlo000391; Fri, 2 May 2003 09:46:26 +0200 (CEST) (envelope-from jardin@mercure.vincentjardin.net) Received: by mercure.vincentjardin.net (8.12.6/8.12.6/Submit) id h427kKRX000390; Fri, 2 May 2003 09:46:20 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Mike Silbersack , freebsd-net@freebsd.org Date: Fri, 2 May 2003 09:46:20 +0200 User-Agent: KMail/1.4.3 References: <20030502010545.U610@odysseus.silby.com> In-Reply-To: <20030502010545.U610@odysseus.silby.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200305020946.20514.vjardin@wanadoo.fr> Subject: Re: More mbuf INVARIANTS code, comments needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 07:46:30 -0000 It is a good idea. I do not see any problems with your patch. An esthetic comment: I would prefer to see other trivial hexadecimal values like: - 0xd0 (as in "Duh", used by stdlib/malloc()) - or 0xdeadc0de (used by kern_malloc.c:#define WEIRD_ADDR 0xdeadc0de) - or 0xdead0137, 0xdead0138, 0xdead0139, ... According to me, these values are easier to analyse when you get a panic = or=20 when you dump the memory. Regards, Vincent On Friday 02 May 2003 08:08, Mike Silbersack wrote: > Now that I have the double-free code in (under INVARIANTS), I'm > considering the attached patch as well; it fills the m_data, m_next, an= d > m_nextpkt fields with non-NULL garbage in hopes that any uses after fre= e > will be immediately fatal. > > Does anyone see problems with this, and/or other simple checks that cou= ld > be added cheaply? > > Thanks, > > Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Fri May 2 11:06:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 519E737B401; Fri, 2 May 2003 11:06:57 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8287843FE0; Fri, 2 May 2003 11:06:56 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h42I6tVo074334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 May 2003 14:06:55 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h42I6tl4074331; Fri, 2 May 2003 14:06:55 -0400 (EDT) (envelope-from wollman) Date: Fri, 2 May 2003 14:06:55 -0400 (EDT) From: Garrett Wollman Message-Id: <200305021806.h42I6tl4074331@khavrinen.lcs.mit.edu> To: "Crist J. Clark" In-Reply-To: <20030430231712.GC3912@blossom.cjclark.org> References: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> <20030430231712.GC3912@blossom.cjclark.org> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: net@FreeBSD.org Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 18:06:57 -0000 < said: > This is actually bad with respect to the spirit of the paper and the > whole idea of information leakage. If I have two FreeBSD machines, one > i386 and one sparc64, they now look different to someone sniffing the > traffic. If I leave the htons(), all of my FreeBSD hosts look > alike. If you have two little-endian machines, one FreeBSD and one some other operating system which doesn't do the htons(), they now look different to someone sniffing the traffic. If you remove the htons(), all of your little-endian hosts look alike. -GAWollman From owner-freebsd-net@FreeBSD.ORG Fri May 2 11:08:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C7F637B401 for ; Fri, 2 May 2003 11:08:10 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2063443F75 for ; Fri, 2 May 2003 11:08:09 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h42I88Vo074352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 May 2003 14:08:08 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id h42I876c074349; Fri, 2 May 2003 14:08:07 -0400 (EDT) (envelope-from wollman) Date: Fri, 2 May 2003 14:08:07 -0400 (EDT) From: Garrett Wollman Message-Id: <200305021808.h42I876c074349@khavrinen.lcs.mit.edu> To: net@FreeBSD.org In-Reply-To: <20030430231712.GC3912@blossom.cjclark.org> References: <200304292247.h3TMlpPU044307@khavrinen.lcs.mit.edu> <20030430231712.GC3912@blossom.cjclark.org> X-Spam-Score: -9.9 () IN_REP_TO,REFERENCES X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) Subject: Re: Reducing ip_id information leakage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2003 18:08:10 -0000 I'm puzzling over some microbenchmark results right now to try to understand the performance implications. -GAWollman From owner-freebsd-net@FreeBSD.ORG Fri May 2 18:38:38 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4131637B401 for ; Fri, 2 May 2003 18:38:38 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 68F9E43FA3 for ; Fri, 2 May 2003 18:38:37 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 31361 invoked from network); 3 May 2003 01:38:36 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 3 May 2003 01:38:36 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 2 May 2003 20:38:20 -0500 (CDT) From: Mike Silbersack To: Vincent Jardin In-Reply-To: <200305020946.20514.vjardin@wanadoo.fr> Message-ID: <20030502203036.M4749@odysseus.silby.com> References: <20030502010545.U610@odysseus.silby.com> <200305020946.20514.vjardin@wanadoo.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: More mbuf INVARIANTS code, comments needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 01:38:38 -0000 On Fri, 2 May 2003, Vincent Jardin wrote: > It is a good idea. I do not see any problems with your patch. > > An esthetic comment: > I would prefer to see other trivial hexadecimal values like: > - 0xd0 (as in "Duh", used by stdlib/malloc()) > - or 0xdeadc0de (used by kern_malloc.c:#define WEIRD_ADDR 0xdeadc0de) > - or 0xdead0137, 0xdead0138, 0xdead0139, ... > > According to me, these values are easier to analyse when you get a panic or > when you dump the memory. > > Regards, > Vincent FWIW, I picked 0x137 through 0x139 because they all land within the first page of memory, which should be guaranteed to fault. I believe that 0xdeadbeef might be a valid address on large memory systems, thereby not causing the immediate failure I wanted. If anyone can think of symbolic values < 4096, I'm open to using them. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Fri May 2 21:06:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9E1437B401 for ; Fri, 2 May 2003 21:06:39 -0700 (PDT) Received: from chikage.wsyntax.com (66-214-183-33.la-cbi.charterpipeline.net [66.214.183.33]) by mx1.FreeBSD.org (Postfix) with SMTP id 2770C43FA3 for ; Fri, 2 May 2003 21:06:39 -0700 (PDT) (envelope-from raymond@chikage.wsyntax.com) Received: (qmail 39143 invoked by uid 83); 3 May 2003 04:06:38 -0000 Received: from mahoro.wsyntax.com (HELO chikage.wsyntax.com) (raymond@192.168.1.100) by chikage.wsyntax.com with SMTP; 3 May 2003 04:06:38 -0000 Message-ID: <3EB3404E.5030103@chikage.wsyntax.com> Date: Fri, 02 May 2003 21:06:38 -0700 From: Raymond Jimenez User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: IPv6 Neighbor Discovery Problem with dc(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 04:06:40 -0000 On my network, several machines are having trouble recognizing an icmp6 neighbor solicitation. This only happens to me when I use the dc driver, in combination with the ADMTek AN985 10/100BaseTX chipset. The machines are running a combination of 4.7 and -CURRENT. The network topology consists of 3 switches, 2 of Linksys make, and 1 of Gigafast make. The computers will not recognize each other even when on the same switch. Tcpdump on the sender of the packet shows that the other interface (should be) reciving the packets, but is sending out no reply. When two computers are using any other driver than dc(4), they can ping each other. However, when tcpdump is done on the system with dc, the other can ping it and send data packets back and forth. It continues working after tcpdump is stopped. I've searched, and found nothing. Is there something I should check? Thanks in advance. -- Below is the output of tcpdump -nlvvve ip6 (on the system that is ping6'ing the one with the dc(4) driver) [raymond@shirayuki raymond]$ sudo tcpdump -nlevvv ip6 | tee Password: tcpdump: listening on ep0 20:57:37.306117 0:60:97:93:af:d0 33:33:ff:1a:49:c8 86dd 86: 2001:470:1f00:256:260:97ff:fe93:afd0 > ff02::1:ff1a:49c8: icmp6: neighbor sol: who has 2001:470:1f00:256:203:6dff:fe1a:49c8(src lladdr: 00:60:97:93:af:d0) (len 32, hlim 255) 20:57:38.306194 0:60:97:93:af:d0 33:33:ff:1a:49:c8 86dd 86: 2001:470:1f00:256:260:97ff:fe93:afd0 > ff02::1:ff1a:49c8: icmp6: neighbor sol: who has 2001:470:1f00:256:203:6dff:fe1a:49c8(src lladdr: 00:60:97:93:af:d0) (len 32, hlim 255) 20:57:39.306283 0:60:97:93:af:d0 33:33:ff:1a:49:c8 86dd 86: 2001:470:1f00:256:260:97ff:fe93:afd0 > ff02::1:ff1a:49c8: icmp6: neighbor sol: who has 2001:470:1f00:256:203:6dff:fe1a:49c8(src lladdr: 00:60:97:93:af:d0) (len 32, hlim 255) 20:57:41.306427 0:60:97:93:af:d0 33:33:ff:1a:49:c8 86dd 86: 2001:470:1f00:256:260:97ff:fe93:afd0 > ff02::1:ff1a:49c8: icmp6: neighbor sol: who has 2001:470:1f00:256:203:6dff:fe1a:49c8(src lladdr: 00:60:97:93:af:d0) (len 32, hlim 255) 20:57:42.306501 0:60:97:93:af:d0 33:33:ff:1a:49:c8 86dd 86: 2001:470:1f00:256:260:97ff:fe93:afd0 > ff02::1:ff1a:49c8: icmp6: neighbor sol: who has 2001:470:1f00:256:203:6dff:fe1a:49c8(src lladdr: 00:60:97:93:af:d0) (len 32, hlim 255) 20:57:43.306572 0:60:97:93:af:d0 33:33:ff:1a:49:c8 86dd 86: 2001:470:1f00:256:260:97ff:fe93:afd0 > ff02::1:ff1a:49c8: icmp6: neighbor sol: who has 2001:470:1f00:256:203:6dff:fe1a:49c8(src lladdr: 00:60:97:93:af:d0) (len 32, hlim 255) 20:57:45.306743 0:60:97:93:af:d0 33:33:ff:1a:49:c8 86dd 86: 2001:470:1f00:256:260:97ff:fe93:afd0 > ff02::1:ff1a:49c8: icmp6: neighbor sol: who has 2001:470:1f00:256:203:6dff:fe1a:49c8(src lladdr: 00:60:97:93:af:d0) (len 32, hlim 255) 20:57:46.306801 0:60:97:93:af:d0 33:33:ff:1a:49:c8 86dd 86: 2001:470:1f00:256:260:97ff:fe93:afd0 > ff02::1:ff1a:49c8: icmp6: neighbor sol: who has 2001:470:1f00:256:203:6dff:fe1a:49c8(src lladdr: 00:60:97:93:af:d0) (len 32, hlim 255) ^C 47 packets received by filter 0 packets dropped by kernel [raymond@shirayuki raymond]$ ping6 sakura.wsyntax.com PING6(56=40+8+8 bytes) 2001:470:1f00:256:260:97ff:fe93:afd0 --> 2001:470:1f00:256:203:6dff:fe1a:49c8 ^C --- sakura.wsyntax.com ping6 statistics --- 56 packets transmitted, 0 packets received, 100% packet loss -- Raymond Jimenez http://chikage.wsyntax.com <> cyanoacry@rakka.irc.wsyntax.com From owner-freebsd-net@FreeBSD.ORG Sat May 3 06:47:38 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B03D37B401 for ; Sat, 3 May 2003 06:47:38 -0700 (PDT) Received: from mwinf0201.wanadoo.fr (smtp7.wanadoo.fr [193.252.22.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37BB443FBF for ; Sat, 3 May 2003 06:47:35 -0700 (PDT) (envelope-from vjardin@wanadoo.fr) Received: from venus.vincentjardin.net (AVelizy-102-1-3-52.abo.wanadoo.fr [217.128.244.52]) by mwinf0201.wanadoo.fr (SMTP Server) with ESMTP id 48A0F3000423 for ; Sat, 3 May 2003 15:47:33 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" From: Vincent Jardin To: net@freebsd.org Date: Sat, 3 May 2003 15:47:34 +0200 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200305031547.34668.vjardin@wanadoo.fr> Subject: Howto rename an interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 13:47:38 -0000 I would like to rename the network interfaces. More particularly, I would= like=20 to control the numbers in the name and to remove the constraints. For example, what are the issues about renaming my 'vr0' interface to eth= 1-3=20 or DSL-WAN that does not have a ifunit within its name ? I think about the following issues, what am I forgetting ? - update all the sockaddr_dl - many drivers, in fact all of them, log with %s%d, ifname, ifunit - (add a message on the routing socket) Regards, Vincent From owner-freebsd-net@FreeBSD.ORG Sat May 3 07:43:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31C0C37B401 for ; Sat, 3 May 2003 07:43:36 -0700 (PDT) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C88643FCB for ; Sat, 3 May 2003 07:43:35 -0700 (PDT) (envelope-from mike@sentex.net) Received: from house (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.12.9/8.12.6) with SMTP id h43EhaRK083879; Sat, 3 May 2003 10:43:36 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Vincent Jardin Date: Sat, 03 May 2003 10:43:38 -0400 Message-ID: <09l7bv4bp8vvngc0j85tgqob0u3b0vl7pr@4ax.com> References: <_MzYgD.A.O9P._h8s-@coal.sentex.ca> In-Reply-To: <_MzYgD.A.O9P._h8s-@coal.sentex.ca> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable cc: freebsd-net@freebsd.org Subject: Re: Howto rename an interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 14:43:36 -0000 It sounds a bit messy to maintain. Perhaps it would be easier to just write wrapper programs around those that you use if really need be. e.g.= a local copy of netstat,ifconfig and route and have those executed first in your path. =20 ---Mike On Sat, 3 May 2003 15:47:34 +0200, in sentex.lists.freebsd.net you wrote: >I would like to rename the network interfaces. More particularly, I = would like=20 >to control the numbers in the name and to remove the constraints. > >For example, what are the issues about renaming my 'vr0' interface to = eth1-3=20 >or DSL-WAN that does not have a ifunit within its name ? > >I think about the following issues, what am I forgetting ? > - update all the sockaddr_dl > - many drivers, in fact all of them, log with %s%d, ifname, ifunit > - (add a message on the routing socket) > >Regards, > Vincent >_______________________________________________ >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" Mike Tancsa (mike@sentex.net)=09 http://www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Sat May 3 10:38:58 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7FE037B401 for ; Sat, 3 May 2003 10:38:58 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8164043FB1 for ; Sat, 3 May 2003 10:38:57 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h43Hcrdt022827 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 3 May 2003 10:38:53 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h43HcrIn040717; Sat, 3 May 2003 10:38:53 -0700 (PDT) (envelope-from jdp) Date: Sat, 3 May 2003 10:38:53 -0700 (PDT) Message-Id: <200305031738.h43HcrIn040717@strings.polstra.com> To: net@freebsd.org From: John Polstra In-Reply-To: <3EB3404E.5030103@chikage.wsyntax.com> References: <3EB3404E.5030103@chikage.wsyntax.com> Organization: Polstra & Co., Seattle, WA cc: raymond@chikage.wsyntax.com Subject: Re: IPv6 Neighbor Discovery Problem with dc(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2003 17:38:59 -0000 In article <3EB3404E.5030103@chikage.wsyntax.com>, Raymond Jimenez wrote: > On my network, several machines are having trouble recognizing an icmp6 > neighbor solicitation. This only happens to me when I use the dc driver, > in combination with the ADMTek AN985 10/100BaseTX chipset. The machines > are running a combination of 4.7 and -CURRENT. The network topology > consists of 3 switches, 2 of Linksys make, and 1 of Gigafast make. The > computers will not recognize each other even when on the same switch. > Tcpdump on the sender of the packet shows that the other interface > (should be) reciving the packets, but is sending out no reply. When two > computers are using any other driver than dc(4), they can ping each > other. However, when tcpdump is done on the system with dc, the other > can ping it and send data packets back and forth. It continues working > after tcpdump is stopped. I've searched, and found nothing. > Is there something I should check? This sounds a lot like a multicast-related bug that may have been fixed just two days ago in -current. Here is the log message from "src/sys/pci/if_dc.c": revision 1.106 date: 2003/05/01 09:31:01; author: mbr; state: Exp; lines: +5 -1 Use only a 64bit hash filter table for ADM-Centaur cards like the Accton EN2242 and the ADMtek AN985 cards. PR: 32699 Submitted by: Jean-Luc Richier Reviewed by: phk MFC after: 2 weeks John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Two buttocks cannot avoid friction." -- Malawi saying From owner-freebsd-net@FreeBSD.ORG Sat May 3 23:43:52 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 227CF37B401 for ; Sat, 3 May 2003 23:43:52 -0700 (PDT) Received: from chikage.wsyntax.com (66-214-183-33.la-cbi.charterpipeline.net [66.214.183.33]) by mx1.FreeBSD.org (Postfix) with SMTP id 83CE243FA3 for ; Sat, 3 May 2003 23:43:51 -0700 (PDT) (envelope-from raymond@chikage.wsyntax.com) Received: (qmail 24073 invoked by uid 83); 4 May 2003 06:43:51 -0000 Received: from mahoro.wsyntax.com (HELO chikage.wsyntax.com) (raymond@192.168.1.100) by chikage.wsyntax.com with SMTP; 4 May 2003 06:43:51 -0000 Message-ID: <3EB4B6A6.4040908@chikage.wsyntax.com> Date: Sat, 03 May 2003 23:43:50 -0700 From: Raymond Jimenez User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org References: <3EB3404E.5030103@chikage.wsyntax.com> <200305031738.h43HcrIn040717@strings.polstra.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: IPv6 Neighbor Discovery Problem with dc(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2003 06:43:52 -0000 John Polstra wrote: > This sounds a lot like a multicast-related bug that may have been > fixed just two days ago in -current. Here is the log message from > "src/sys/pci/if_dc.c": > > revision 1.106 > date: 2003/05/01 09:31:01; author: mbr; state: Exp; lines: +5 -1 > Use only a 64bit hash filter table for ADM-Centaur cards like the > Accton EN2242 and the ADMtek AN985 cards. > > PR: 32699 > Submitted by: Jean-Luc Richier > Reviewed by: phk > MFC after: 2 weeks > > John Yeah, this fixed it. Thanks. -- Raymond Jimenez ("Cyanoacry") http://chikage.wsyntax.com <> cyanoacry@rakka.irc.wsyntax.com