From owner-freebsd-net@FreeBSD.ORG Sat Mar 27 08:25:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B1D116A4CE for ; Sat, 27 Mar 2004 08:25:22 -0800 (PST) Received: from viviendaatualcance.com.mx (dsl-200-78-18-163.prod-infinitum.com.mx [200.78.18.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A3C843D39 for ; Sat, 27 Mar 2004 08:25:21 -0800 (PST) (envelope-from eculp@viviendaatualcance.com.mx) Received: from localhost (localhost [127.0.0.1]) (uid 80) by viviendaatualcance.com.mx with local; Sat, 27 Mar 2004 10:25:20 -0600 Received: from dsl-201-129-46-8.prod-infinitum.com.mx (dsl-201-129-46-8.prod-infinitum.com.mx [201.129.46.8]) by mail.viviendaatualcance.com.mx (Horde) with HTTP for ; Sat, 27 Mar 2004 10:25:20 -0600 Message-ID: <20040327102520.hr4k0c8og4880ws8@mail.viviendaatualcance.com.mx> Date: Sat, 27 Mar 2004 10:25:20 -0600 From: Edwin Culp To: freebsd-net@freebsd.org References: <200403271332.i2RDWtdF031292@spooky.eis.net.au> In-Reply-To: <200403271332.i2RDWtdF031292@spooky.eis.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-EnContacto.net: Edwin Culp celular Mexico 001 228 824 5542 WorldInternet.ORG X-WorldInternet.org: Edwin Culp Te mantiene, siempre, EnContacto. X-Mailman-Approved-At: Sun, 28 Mar 2004 05:13:21 -0800 Subject: Re: PCI ADSL card and PPPoA 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, 27 Mar 2004 16:25:22 -0000 Quoting User Ernie : > Firstly I have to warn you I am a Netgraph newbie,and despite looking for > hours, I have not found much of a tutorial on how it all fits together. > > I recently obtained a PCI ADSl modem card, Pulsar ADSL from Traverse > Technologies http://www.traverse.com.au > > They have some test FreeBSD drivers http://adsl4linux.no-ip.org/pulsar.html > that implement a bridge mode ADSL connection using netgraph modules: > > Id Refs Address Size Name > 1 8 0xc0400000 65ab28 kernel > 2 1 0xc0a5b000 7794 ng_atm.ko > 3 4 0xc0a63000 14abc netgraph.ko > 4 1 0xc0a78000 386c ng_eiface.ko > 5 2 0xc0a7c000 3030 atm_aal.ko > 6 1 0xc0a80000 440dc if_pls.ko > 7 1 0xc0ac5000 2d50 ng_atmllc.ko > > > This all seems to work fine, the modules load up and I get an ADSL sync > light on the ADSL PCI card. > > However I need to run PPPoE or PPPoA to connect to my ISP, > I tried user ppp and mpd but the both complained that the interface was not > ethernet. > > Is it possible to use some like ng_ppp and mpd to hook to this card so I > can establish a PPPoA session? If so can anyone suggest an mpd config? YMMV with this answer because o- I use a TelCo supplied adsl modem. o- I've never had a problem with pppoe It's always just worked. The only real difference in the configuration of ppp for dialup and ppp for pppoe, in my case is: set device PPPoE:fxp1 It runs on tun[0-9], BTW but you must assign it to a free ethernet interface. In my case it is fxp1 - em0 is internal and fxp0 is a different isp with a partial E-1 as an example. My complete configuration, with some information changed to protect the innocent with xxxx, follows: default: set log Phase tun command # set ifaddr 10.0.0.1/0 10.0.0.2/0 set ifaddr xxx.78.18.xxx xx8.235.145.xxx 255.255.255.255 0.0.0.0 telmex: set device PPPoE:fxp1 set authname xxxxxxxx set authkey xxxxx set dial set login add default HISADDR It starts from rc with the rc.conf entry # User ppp configuration. ppp_enable="YES" # Start user-ppp (or NO). ppp_mode="ddial" # Choice of "auto", "ddial", "direct" or "dedicated". # For details see man page for ppp(8). Default is auto. ppp_nat="YES" # Use PPP's internal network address translation or NO. ppp_profile="telmex" # Which profile to use from /etc/ppp/ppp.conf. ppp_user="xxxx" # Which user to run ppp as It runs as: # ps -ax|grep ppp 246 ?? Ss 1:47.42 /usr/sbin/ppp -quiet -ddial -nat telmex I suppose auto would work the same way as ddial but I just modified a dial-up configuration. Hope this gives you some idea. BTW, this is on current although I assume it doesn't change. ed From owner-freebsd-net@FreeBSD.ORG Sat Mar 27 09:38:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D03716A4CE for ; Sat, 27 Mar 2004 09:38:52 -0800 (PST) Received: from web60401.mail.yahoo.com (web60401.mail.yahoo.com [216.109.118.184]) by mx1.FreeBSD.org (Postfix) with SMTP id 1AC4E43D54 for ; Sat, 27 Mar 2004 09:38:52 -0800 (PST) (envelope-from js082130@yahoo.com) Message-ID: <20040327173851.66947.qmail@web60401.mail.yahoo.com> Received: from [203.131.172.228] by web60401.mail.yahoo.com via HTTP; Sat, 27 Mar 2004 09:38:51 PST Date: Sat, 27 Mar 2004 09:38:51 -0800 (PST) From: Jobert To: freebsd-net@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 28 Mar 2004 05:13:21 -0800 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: request 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, 27 Mar 2004 17:38:52 -0000 Hello Gud Day want to ask about imesh www.imesh.com do u provide this net application tnx --------------------------------- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 07:56:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BED716A4CE; Sun, 28 Mar 2004 07:56:44 -0800 (PST) Received: from meitner.wh.uni-dortmund.de (meitner.wh.uni-dortmund.de [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA28043D2F; Sun, 28 Mar 2004 07:56:43 -0800 (PST) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id D150D1676C8; Sun, 28 Mar 2004 17:56:42 +0200 (CEST) Received: from [192.168.8.4] (kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i2SFue5u046997 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 28 Mar 2004 17:56:42 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock Date: Sun, 28 Mar 2004 17:56:37 +0200 User-Agent: KMail/1.6.1 To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_4WvZAQsFB6JYd+F"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200403281756.40676.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new Subject: Fwd: Found a working Gigabit Ethernet TC902X driver for STABLE 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, 28 Mar 2004 15:56:44 -0000 --Boundary-02=_4WvZAQsFB6JYd+F Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46orwarding this to FreeBSD-net and FreeBSD-hackers, in case someone wants to adopt the code. =2D--------- Forwarded Message ---------- Subject: Found a working Gigabit Ethernet TC902X driver for STABLE Date: Sunday 28 March 2004 16:54 =46rom: Martin To: freebsd-stable@FreeBSD.org Hi, I got a new network adapter (Longshine 8039TX; take a look here: http://longshine.de/produkt/1000mbit/giga-eng.html). I have been looking for drivers for STABLE and found this post: http://www.atm.tut.fi/list-archive/freebsd-stable/msg08427.html It mentions a module (sources), which you can download here: http://www.icplus.com.tw/Data/driver/TC902X_FreeBSD.zip The chipset comes from the company: Tamarack Microelectronics Inc. in Taiwan. I installed it on my STABLE box and it seems to work fine. Can someone of the committers take a look at the sources? I think the license is OK (it seems to be a BSD-type license). I hope that you can confirm that it is safe to use this module. =46or those who want to try it, here some advice (it's really weird, so read it please): 1) unzip the file in an empty folder 2) extract the tar-ball 3) rename the Readme.txt to rio.tgz 4) extract rio.tgz 5) cp the Makefile from ./rio subdirectory to the directory with the module sources 6) create a soft-link "pci -> ." in the same directory 7) run make 8) done, the result is: if_rio.ko I've asked to add it to ports ealier, but noone answered to me. I have tested this driver for 3 weeks now and it works well for me on FreeBSD-4.9-STABLE. It does not compile on CURRENT. Martin _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" =2D------------------------------------------------------ =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --Boundary-02=_4WvZAQsFB6JYd+F Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAZvW4Xhc68WspdLARAlhfAKCdZfwn2dUdku0ycebd5rfZsnJ0+wCfaTUt sQgM+JSaUSDIfcS2ckNDtTY= =M49Y -----END PGP SIGNATURE----- --Boundary-02=_4WvZAQsFB6JYd+F-- From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 08:40:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7841116A4CE for ; Sun, 28 Mar 2004 08:40:20 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B61B43D1D for ; Sun, 28 Mar 2004 08:40:19 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i2SGeAJ12136; Sun, 28 Mar 2004 18:40:11 +0200 (MEST) Date: Sun, 28 Mar 2004 18:40:10 +0200 (CEST) From: Harti Brandt To: User Ernie In-Reply-To: <200403272055.i2RKts0M078063@spooky.eis.net.au> Message-ID: <20040328183854.P10175@beagle.fokus.fraunhofer.de> References: <200403272055.i2RKts0M078063@spooky.eis.net.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: PCI ADSL card and PPPoA 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, 28 Mar 2004 16:40:20 -0000 On Sun, 28 Mar 2004, User Ernie wrote: UE>> On Sat, Mar 27, 2004 at 11:32:55PM +1000, User Ernie wrote: UE>> > Is it possible to use some like ng_ppp and mpd to hook to this card so I UE>> > can establish a PPPoA session? If so can anyone suggest an mpd config? UE>> UE>> Far simpler; if it supports the NATM API, you should be able to run UE>> userland ppp to begin with over it. This is documented in the Handbook UE>> now. Whilst userland PPP is 'teh suck', for the purposes of verifying that UE>> your configuration is working, it's useful. UE>> UE>> BMS UE>> UE> UE>I looked in the handbook orgilginally, chapter 18.6 is where I learnt about UE>mpd. The userland PPP example for PPPoA seemed to use and externam USB UE>modem. Which section is the NATM example in? I think there is no. I tried to contact Brian Somers to get some hints about the ppp/netgraph interface, to write a corresponding section, but without luck. harti From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 10:16:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13A7416A4CE for ; Sun, 28 Mar 2004 10:16:36 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C8E943D55 for ; Sun, 28 Mar 2004 10:16:35 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 56DAE65218; Sun, 28 Mar 2004 19:16:33 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09299-04; Sun, 28 Mar 2004 19:16:32 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id C41A965216; Sun, 28 Mar 2004 19:16:30 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id B3B466108; Sun, 28 Mar 2004 19:16:29 +0100 (BST) Date: Sun, 28 Mar 2004 19:16:29 +0100 From: Bruce M Simpson To: User Ernie Message-ID: <20040328181629.GD94618@empiric.dek.spc.org> Mail-Followup-To: User Ernie , freebsd-net@freebsd.org References: <20040327181345.GD90316@empiric.dek.spc.org> <200403272055.i2RKts0M078063@spooky.eis.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403272055.i2RKts0M078063@spooky.eis.net.au> cc: freebsd-net@freebsd.org Subject: Re: PCI ADSL card and PPPoA 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, 28 Mar 2004 18:16:36 -0000 On Sun, Mar 28, 2004 at 06:55:54AM +1000, User Ernie wrote: > I looked in the handbook orgilginally, chapter 18.6 is where I learnt about > mpd. The userland PPP example for PPPoA seemed to use and externam USB > modem. Which section is the NATM example in? The USB modem in question *is* an NATM advice; the use of the PPPoA keyword in the device statement is NATM specific, not USB specific. This doesn't appear to be mentioned in the ppp(8) manpage which is perhaps a bug... BMS From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 13:39:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 522BE16A4CE for ; Sun, 28 Mar 2004 13:39:02 -0800 (PST) Received: from spooky.eis.net.au (spooky.eis.net.au [203.12.171.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7D7443D2D for ; Sun, 28 Mar 2004 13:39:01 -0800 (PST) (envelope-from ernie@spooky.eis.net.au) Received: (from ernie@localhost) by spooky.eis.net.au (8.12.11/8.12.10) id i2SLcwJg038453; Mon, 29 Mar 2004 07:38:58 +1000 (EST) (envelope-from ernie) From: User Ernie Message-Id: <200403282138.i2SLcwJg038453@spooky.eis.net.au> In-Reply-To: <20040328181629.GD94618@empiric.dek.spc.org> To: Bruce M Simpson Date: Mon, 29 Mar 2004 07:38:58 +1000 (EST) 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: PCI ADSL card and PPPoA 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, 28 Mar 2004 21:39:02 -0000 > On Sun, Mar 28, 2004 at 06:55:54AM +1000, User Ernie wrote: > > I looked in the handbook orgilginally, chapter 18.6 is where I learnt about > > mpd. The userland PPP example for PPPoA seemed to use and externam USB > > modem. Which section is the NATM example in? > > The USB modem in question *is* an NATM advice; the use of the PPPoA keyword > in the device statement is NATM specific, not USB specific. This doesn't > appear to be mentioned in the ppp(8) manpage which is perhaps a bug... > > BMS > _______________________________________________ > 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" > I found this sentence in /usr/src/usr.sbin/ppp/atm.c: "PPPoA:if:vpi.vci expected\n", p->name.full); That sort of gives me the syntax, I know my vpi and vci are 8 and 35, should I be setting the interface to ng0 or pls0 which is the real interface in ifconfig? When I try ng0 I get the following error: Mar 29 07:37:01 athlon ppp[55174]: Phase: Using interface: tun0 Mar 29 07:37:01 athlon ppp[55174]: Phase: deflink: Created in closed state Mar 29 07:37:01 athlon ppp[55175]: Phase: PPP Started (ddial mode). Mar 29 07:37:01 athlon ppp[55175]: Phase: bundle: Establish Mar 29 07:37:01 athlon ppp[55175]: Phase: deflink: closed -> opening Mar 29 07:37:01 athlon ppp[55175]: Phase: deflink: Connecting to ng0:8.35 Mar 29 07:37:01 athlon ppp[55175]: Warning: PPPoA:ng0:8.35: connect: Device not configured Mar 29 07:37:01 athlon ppp[55175]: Warning: deflink: Device (PPPoA:ng0:8.35) must begin with a '/', a '!' or contain at least one ':' Mar 29 07:37:01 athlon ppp[55175]: Phase: deflink: Enter pause (30) for redialing. Mar 29 07:37:31 athlon ppp[55175]: Phase: deflink: Connecting to ng0:8.35 Mar 29 07:37:31 athlon ppp[55175]: Warning: PPPoA:ng0:8.35: connect: Device not configured Mar 29 07:37:31 athlon ppp[55175]: Warning: deflink: Device (PPPoA:ng0:8.35) must begin with a '/', a '!' or contain at least one ':' Mar 29 07:37:31 athlon ppp[55175]: Phase: deflink: Enter pause (30) for redialing. I guess that means ppp is expecting another device or I have to configure the netgraph device beforhand. - Ernie. From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 13:57:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47AEC16A4CE; Sun, 28 Mar 2004 13:57:36 -0800 (PST) Received: from integer.pobox.com (integer.pobox.com [208.58.1.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11C2543D1F; Sun, 28 Mar 2004 13:57:36 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from colander (localhost [127.0.0.1]) by integer.pobox.com (Postfix) with ESMTP id 93E2773881; Sun, 28 Mar 2004 16:57:35 -0500 (EST) Received: from jester.pobox.com (jester.pobox.com [64.71.166.114]) by integer.pobox.com (Postfix) with ESMTP id 43FED7387B; Sun, 28 Mar 2004 16:57:35 -0500 (EST) Received: from vaio.linnet.org (unknown [80.44.130.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jester.pobox.com (Postfix) with ESMTP id 83A2D88; Sun, 28 Mar 2004 16:57:34 -0500 (EST) Received: from brian by vaio.linnet.org with local (Exim 4.30) id 1B7iHb-000ASl-Bm; Sun, 28 Mar 2004 22:57:31 +0100 Date: Sun, 28 Mar 2004 22:57:31 +0100 From: Brian Candler To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Message-ID: <20040328215731.GA40112@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: q@onthenet.com.au cc: wpaul@freebsd.org Subject: nVidia chipset - ethernet 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, 28 Mar 2004 21:57:36 -0000 I have installed FreeBSD-5.2.1 on my brand new Soltek EQ3702A machine, which has an nVidia chipset. I have got most of the on-board hardware to work: kldload snd_ich -- pcm kldload firewire \ to mount my ipod kldload sbp / but I don't seem to be able to get ethernet to work. A google shows that this is a long-standing issue: http://lists.freebsd.org/pipermail/freebsd-questions/2003-August/016739.html http://lists.freebsd.org/pipermail/freebsd-net/2003-July/001016.html but I don't see anything else posted since August last year. I did come across this driver against FreeBSD-5.1: http://www.onthenet.com.au/~q/nvnet/ [1] Anyone have any experience with it? It claims to be in the official ports tree under net/nvnet, but I don't find it there (not in the 5.2.1-RELEASE ports tree anyway). Well actually, I did find something here: http://www.freebsd.org/cgi/pds.cgi?ports/net/nvnet [2] Unfortunately the driver page [1] doesn't link to the Linux driver it requires, and the port at [2] links to a different version of nvnet than the one at [1]. If anyone has this working with FreeBSD-5.2.1 (and either an up-to-date port, or a pointer to the correct Linux module required), that would save me some random hacking. Incidentally, my machine has two VGA ports. If anyone knows how to get both of those working together with XFree86, that would be appreciated too! Cheers, Brian. From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 14:06:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F36816A4CF for ; Sun, 28 Mar 2004 14:06:25 -0800 (PST) Received: from mail.datazug.ch (mail201.datazug.ch [212.4.65.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D56F43D1D for ; Sun, 28 Mar 2004 14:06:24 -0800 (PST) (envelope-from ruettimac@mac.com) Received: from [192.168.0.10] [212.4.89.17] by mail.datazug.ch with ESMTP (SMTPD32-8.05) id AC5E14690166; Mon, 29 Mar 2004 00:06:22 +0200 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <257C203C-8104-11D8-9902-00039303AB38@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-net@freebsd.org From: =?ISO-8859-1?Q?Cyrill_R=FCttimann?= Date: Mon, 29 Mar 2004 00:06:21 +0200 X-Mailer: Apple Mail (2.613) Subject: IPSec troubles 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, 28 Mar 2004 22:06:25 -0000 Hello, I have troubles setting up an IPSec Host-to-Host connection between FreeBSD 5.2.1 and MacOS X 10.3.3: Network Setup: Cable-Modem-->FreeBSD Box, 192.168.0.1-->Apple Airport Station running in Bridge Mode-->MacOS X Box, 192.168.0.10 /etc/ipsec.conf (FreeBSD) spdadd 192.168.0.1/24 192.168.0.10/24 any -P out ipsec esp/transport/192.168.0.1-192.168.0.10/require; spdadd 192.168.0.10/24 192.168.0.1/24 any -P in ipsec esp/transport/192.168.0.10-192.168.0.1/require; /etc/ipsec.conf (MacOS X) spdadd 192.168.0.10/24 192.168.0.1/24 any -P out ipsec esp/transport/192.168.0.10-192.168.0.1/require; spdadd 192.168.0.1/24 192.168.0.10/24 any -P in ipsec esp/transport/192.168.0.1-192.168.0.10/require; /usr/local/etc/racoon/racoon.conf (FreeBSD) remote anonymous { #exchange_mode main,aggressive; exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; #my_identifier address; my_identifier user_fqdn "root@ruettimac.ch"; peers_identifier user_fqdn "root@ruettimac.ch"; #certificate_type x509 "mycert" "mypriv"; nonce_size 16; lifetime time 1 min; # sec,min,hour initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 30 sec; encryption_algorithm 3des ; authentication_algorithm hmac_sha1; compression_algorithm deflate ; } /etc/racoon/remote/anonymous.conf (MacOS X) remote anonymous { #exchange_mode main,aggressive; exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; #my_identifier address; my_identifier user_fqdn "root@ruettimac.ch"; peers_identifier user_fqdn "root@ruettimac.ch"; #certificate_type x509 "mycert" "mypriv"; nonce_size 16; lifetime time 1 min; # sec,min,hour initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 30 sec; encryption_algorithm 3des ; authentication_algorithm hmac_sha1; compression_algorithm deflate ; } /usr/local/etc/racoon/psk.txt (FreeBSD) 192.168.0.1 7HdopoY72bNmewP 192.168.0.10 7HdopoY72bNmewP /etc/racoon/psk.txt (MacOS X) 192.168.0.1 7HdopoY72bNmewP 192.168.0.10 7HdopoY72bNmewP Debug output (FreeBSD) Mar 28 22:55:54 protos racoon: DEBUG: algorithm.c:614:alg_oakley_dhdef(): hmac(modp1024) Mar 28 22:55:54 protos racoon: DEBUG: pfkey.c:2379:pk_checkalg(): compression algorithm can not be checked because sadb message doesn't support it. Mar 28 22:55:54 protos racoon: DEBUG: pfkey.c:197:pfkey_handler(): get pfkey X_SPDDUMP message Mar 28 22:55:54 protos racoon: DEBUG: pfkey.c:197:pfkey_handler(): get pfkey X_SPDDUMP message Mar 28 22:55:54 protos racoon: DEBUG: policy.c:184:cmpspidxstrict(): sub:0xbfbfec40: 192.168.0.1/24[0] 192.168.0.10/24[0] proto=any dir=out Mar 28 22:55:54 protos racoon: DEBUG: policy.c:185:cmpspidxstrict(): db :0x80a2c08: 192.168.0.10/24[0] 192.168.0.1/24[0] proto=any dir=in Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:221:isakmp_handler(): === Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:222:isakmp_handler(): 277 bytes message received from 192.168.0.10[500] Mar 28 22:57:11 protos racoon: DEBUG: plog.c:193:plogdump(): a8d6f8dc 8b9041c1 00000000 00000000 01100400 00000000 00000115 04000034 00000001 00000001 00000028 01010 001 00000020 01010000 800b0001 800c003c 80010005 80030001 80020002 80040002 0a000084 f23e0504 edb10453 8212421a f817e04d 148782fb 81436b89 f73240d1 a69d3662 5cbb7e5a cb234c8a 764c6357 87b6c7ee 6606ad2b daf088dc 27dfbac8 5c8ca5f5 20b7c274 4e6f22d7 a85e4237 36291558 2cc68a6e fc9f449c 9d9463e3 ebb1536b 068063f7 ac6f290e 6160f975 b059 aa6c dcccf25d ee5361aa d18ba202 b567ff46 05000014 d2b5d6de f4860836 93be994d 10fb9d3a 0d000019 03000000 726f6f74 40727565 7474696d 61632e63 68000000 144df379 28e9fc4f d1b32621 70d515c6 62 Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:2246:isakmp_printpacket(): begin. Mar 28 22:57:11 protos racoon: DEBUG: remoteconf.c:129:getrmconf(): anonymous configuration selected for 192.168.0.10[500]. Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:887:isakmp_ph1begin_r(): === Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1110:isakmp_parsewoh(): begin. Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1137:isakmp_parsewoh(): seen nptype=1(sa) Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1137:isakmp_parsewoh(): seen nptype=4(ke) Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1137:isakmp_parsewoh(): seen nptype=10(nonce) Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1137:isakmp_parsewoh(): seen nptype=5(id) Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1137:isakmp_parsewoh(): seen nptype=13(vid) Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1176:isakmp_parsewoh(): succeed. Mar 28 22:57:11 protos racoon: DEBUG: isakmp_agg.c:646:agg_r1recv(): received payload of type ke Mar 28 22:57:11 protos racoon: DEBUG: isakmp_agg.c:646:agg_r1recv(): received payload of type nonce Mar 28 22:57:11 protos racoon: DEBUG: isakmp_agg.c:646:agg_r1recv(): received payload of type id Mar 28 22:57:11 protos racoon: DEBUG: isakmp_agg.c:646:agg_r1recv(): received payload of type vid Mar 28 22:57:11 protos racoon: DEBUG: vendorid.c:137:check_vendorid(): received unknown Vendor ID Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1117:get_proppair(): total SA len=48 Mar 28 22:57:11 protos racoon: DEBUG: plog.c:193:plogdump(): 00000001 00000001 00000028 01010001 00000020 01010000 800b0001 800c003c 80010005 80030001 80020002 80040 002 Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1110:isakmp_parsewoh(): begin. Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1137:isakmp_parsewoh(): seen nptype=2(prop) Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1176:isakmp_parsewoh(): succeed. Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1170:get_proppair(): proposal #1 len=40 Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1110:isakmp_parsewoh(): begin. Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1137:isakmp_parsewoh(): seen nptype=3(trns) Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1176:isakmp_parsewoh(): succeed. Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1311:get_transform(): transform #1 len=32 Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1870:check_attr_isakmp(): type=Life Type, flag=0x8000, lorv=seconds Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1870:check_attr_isakmp(): type=Life Duration, flag=0x8000, lorv=60 Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1870:check_attr_isakmp(): type=Encryption Algorithm, flag=0x8000, lorv=3DES-CBC Mar 28 22:57:11 protos racoon: DEBUG: algorithm.c:386:alg_oakley_encdef(): encription(3des) Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1870:check_attr_isakmp(): type=Authentication Method, flag=0x8000, lorv=pre-shared key Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1870:check_attr_isakmp(): type=Hash Algorithm, flag=0x8000, lorv=SHA Mar 28 22:57:11 protos racoon: DEBUG: algorithm.c:256:alg_oakley_hashdef(): hash(sha1) Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1870:check_attr_isakmp(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group Mar 28 22:57:11 protos racoon: DEBUG: algorithm.c:614:alg_oakley_dhdef(): hmac(modp1024) Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1213:get_proppair(): pair 1: Mar 28 22:57:11 protos racoon: DEBUG: proposal.c:895:print_proppair0(): 0x80a8dc0: next=0x0 tnext=0x0 Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:1248:get_proppair(): proposal #1: 1 transform Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:322:get_ph1approvalx(): prop#=1, prot-id=ISAKMP, spi-size=0, #trns=1 Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:327:get_ph1approvalx(): trns#=1, trns-id=IKE Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:491:t2isakmpsa(): type=Life Type, flag=0x8000, lorv=seconds Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:491:t2isakmpsa(): type=Life Duration, flag=0x8000, lorv=60 Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:491:t2isakmpsa(): type=Encryption Algorithm, flag=0x8000, lorv=3DES-CBC Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:491:t2isakmpsa(): type=Authentication Method, flag=0x8000, lorv=pre-shared key Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:491:t2isakmpsa(): type=Hash Algorithm, flag=0x8000, lorv=SHA Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:491:t2isakmpsa(): type=Group Description, flag=0x8000, lorv=1024-bit MODP group Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:338:get_ph1approvalx(): Compared: DB:Peer Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:339:get_ph1approvalx(): (lifetime = 60:60) Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:341:get_ph1approvalx(): (lifebyte = 0:0) Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:343:get_ph1approvalx(): enctype = 3DES-CBC:3DES-CBC Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:348:get_ph1approvalx(): (encklen = 0:0) Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:350:get_ph1approvalx(): hashtype = SHA:SHA Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:355:get_ph1approvalx(): authmethod = pre-shared key:pre-shared key Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:360:get_ph1approvalx(): dh_group = 1024-bit MODP group:1024-bit MODP group Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:248:get_ph1approval(): an acceptable proposal found. Mar 28 22:57:11 protos racoon: DEBUG: algorithm.c:614:alg_oakley_dhdef(): hmac(modp1024) Mar 28 22:57:11 protos racoon: DEBUG: isakmp.c:1994:isakmp_newcookie(): new cookie: 0ad0e291b31fe9c0 Mar 28 22:57:11 protos racoon: DEBUG: ipsec_doi.c:3238:ipsecdoi_setid1(): use ID type of User_FQDN Mar 28 22:57:11 protos racoon: DEBUG: oakley.c:300:oakley_dh_generate(): compute DH's private. Mar 28 22:57:11 protos racoon: DEBUG: plog.c:193:plogdump(): 6753fee8 60c3a0f2 ae75b8f8 b01a3ebb 077d1c3d 32079cb0 a85027bc ce546f9a ba3f7f1d 3621cdc7 846570e1 5f9ea ef5 ece52b65 8c704ae1 01ae7444 7490a9bd 72d9c58c 0366a656 38261e4e fa4b56ce 10d8544a 8e86344d 32b78168 909a5847 c118c017 a17cd78a cbb543b7 98e1cb8e 5e8faed4 f28ddb5b 1783717e 244b075f Mar 28 22:57:11 protos racoon: DEBUG: oakley.c:302:oakley_dh_generate(): compute DH's public. Mar 28 22:57:11 protos racoon: DEBUG: plog.c:193:plogdump(): 188b2e30 9cf45135 c1dc28fb 44f75b0b 0d6511c2 2d615c1c 032790c7 3a154392 582a65cf 3535dabc cd858f07 11b1d 229 e9a49744 aa3a1935 c9bff6cc 2a060706 6af1b688 0ca5f0e4 c8085d7d de7a24db 7e70369f c913691a b4de01fe b98f3218 35480394 ac9ec110 33431e8c a6098b94 0d29ad67 7be9cd11 059569db 7523ea0d Mar 28 22:57:11 protos racoon: DEBUG: oakley.c:250:oakley_dh_compute(): compute DH's shared. Mar 28 22:57:11 protos racoon: DEBUG: plog.c:193:plogdump(): 3a7b7282 97f70a35 423f1b4b cd893507 23188260 bb366f00 02bd5d60 1f85d97f ab60ce35 e4d1a4e8 975daf7a 34ba3 393 4282dba6 e30885e8 c8459602 f0d9f8dc 72048742 295d0035 5611342c e51c20c0 17d2a64b 7c985bd4 c5424535 e9cb8e05 900484a4 2838807a b2656122 be5e1bb6 5b0e1003 e1087aa2 ab448b19 fb5bdf3b Mar 28 22:57:21 protos racoon: DEBUG: isakmp.c:221:isakmp_handler(): === Mar 28 22:57:21 protos racoon: DEBUG: isakmp.c:222:isakmp_handler(): 277 bytes message received from 192.168.0.10[500] Mar 28 22:57:21 protos racoon: DEBUG: plog.c:193:plogdump(): a8d6f8dc 8b9041c1 00000000 00000000 01100400 00000000 00000115 04000034 00000001 00000001 00000028 01010 001 00000020 01010000 800b0001 800c003c 80010005 80030001 80020002 80040002 0a000084 f23e0504 edb10453 8212421a f817e04d 148782fb 81436b89 f73240d1 a69d3662 5cbb7e5a cb234c8a 764c6357 87b6c7ee 6606ad2b daf088dc 27dfbac8 5c8ca5f5 20b7c274 4e6f22d7 a85e4237 36291558 2cc68a6e fc9f449c 9d9463e3 ebb1536b 068063f7 ac6f290e 6160f975 b059 aa6c dcccf25d ee5361aa d18ba202 b567ff46 05000014 d2b5d6de f4860836 93be994d 10fb9d3a 0d000019 03000000 726f6f74 40727565 7474696d 61632e63 68000000 144df379 28e9fc4f d1b32621 70d515c6 62 Debug output (MacOS X) Mar 28 23:05:24 localhost racoon: INFO: isakmp.c:2038:isakmp_chkph1there(): delete phase 2 handler. Mar 28 23:05:53 localhost racoon: ERROR: isakmp.c:1694:isakmp_ph1resend(): phase1 negotiation failed due to time up. 4445e17f3009917d:0000000000000000 Mar 28 23:06:13 localhost racoon: INFO: isakmp.c:1941:isakmp_post_acquire(): IPsec-SA request for 192.168.0.1 queued due to no phase1 found. Mar 28 23:06:13 localhost racoon: INFO: isakmp.c:994:isakmp_ph1begin_i(): initiate new phase 1 negotiation: 192.168.0.10[500]<=>192.168.0.1[500] Mar 28 23:06:13 localhost racoon: INFO: isakmp.c:999:isakmp_ph1begin_i(): begin Aggressive mode. Mar 28 23:06:44 localhost racoon: ERROR: isakmp.c:2033:isakmp_chkph1there(): phase2 negotiation failed due to time up waiting for phase1. ESP 192.168.0.1->192.168.0.1 0 Mar 28 23:06:44 localhost racoon: INFO: isakmp.c:2038:isakmp_chkph1there(): delete phase 2 handler. Something wrong with the setup? Maybe incompatible versions of racoon (tip found in a FreeBSD Mailinglist)? racoon-20040116a <-----> racoon-20040114 (Big Endian) Thanks for any help! Cyrill From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 15:31:33 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AF1416A4CE for ; Sun, 28 Mar 2004 15:31:33 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id E875743D2F for ; Sun, 28 Mar 2004 15:31:32 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 2A40665213; Mon, 29 Mar 2004 00:31:32 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12044-06; Mon, 29 Mar 2004 00:31:31 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 27E37651FA; Mon, 29 Mar 2004 00:31:31 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 13C5F6108; Mon, 29 Mar 2004 00:31:30 +0100 (BST) Date: Mon, 29 Mar 2004 00:31:30 +0100 From: Bruce M Simpson To: User Ernie Message-ID: <20040328233130.GG70173@empiric.dek.spc.org> Mail-Followup-To: User Ernie , freebsd-net@freebsd.org References: <20040328181629.GD94618@empiric.dek.spc.org> <200403282138.i2SLcwJg038453@spooky.eis.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403282138.i2SLcwJg038453@spooky.eis.net.au> cc: freebsd-net@freebsd.org Subject: Re: PCI ADSL card and PPPoA 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, 28 Mar 2004 23:31:33 -0000 On Mon, Mar 29, 2004 at 07:38:58AM +1000, User Ernie wrote: > I found this sentence in /usr/src/usr.sbin/ppp/atm.c: > > "PPPoA:if:vpi.vci expected\n", p->name.full); > > That sort of gives me the syntax, I know my vpi and vci are 8 and 35, should > I be setting the interface to ng0 or pls0 which is the real interface in > ifconfig? Yup. Try pls0. /usr/sbin/ppp's PPPoA syntax keyword expects a NATM device and vpi.vci tuple corresponding to the PVC where your ISP is using PPPoA encapsulation. it only supports AAL5 at this time. BMS From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 16:53:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEC4F16A4D1; Sun, 28 Mar 2004 16:53:47 -0800 (PST) Received: from mail-in.m-online.net (mail-in.m-online.net [62.245.150.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ACE843D41; Sun, 28 Mar 2004 16:53:47 -0800 (PST) (envelope-from h@schmalzbauer.de) Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144]) by svr8.m-online.net (Postfix) with ESMTP id 9246B4BC4F; Mon, 29 Mar 2004 02:53:45 +0200 (CEST) Received: from sam.flintsbach.schmalzbauer.de (ppp-82-135-1-225.mnet-online.de [82.135.1.225]) by mail.m-online.net (Postfix) with ESMTP id 5F7496A7B6; Mon, 29 Mar 2004 02:53:45 +0200 (CEST) Received: from cale.flintsbach.schmalzbauer.de (cale.flintsbach.schmalzbauer.de [172.21.1.251])i2T0rhxw043264; Mon, 29 Mar 2004 02:53:44 +0200 (CEST) (envelope-from h@schmalzbauer.de) From: Harald Schmalzbauer To: freebsd-questions@freebsd.org Date: Mon, 29 Mar 2004 02:53:38 +0200 User-Agent: KMail/1.6.1 References: <20040328215731.GA40112@uk.tiscali.com> In-Reply-To: <20040328215731.GA40112@uk.tiscali.com> X-Country: Germany X-Address: Munich, 80686 X-Phone2: +49 (0) 89 18947781 X-Phone1: +49 (0) 163 555 3237 X-Name: Harald Schmalzbauer X-Birthday: 06 Oktober 1972 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_XO3ZAwRaDgAWspf"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403290253.43487.h@schmalzbauer.de> cc: q@onthenet.com.au cc: freebsd-net@freebsd.org cc: wpaul@freebsd.org cc: Brian Candler Subject: Re: nVidia chipset - ethernet support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 00:53:47 -0000 --Boundary-02=_XO3ZAwRaDgAWspf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 28. M=E4rz 2004 23:57 schrieb Brian Candler: > I have installed FreeBSD-5.2.1 on my brand new Soltek EQ3702A machine, > which has an nVidia chipset. I have got most of the on-board hardware to > work: kldload snd_ich -- pcm > kldload firewire \ to mount my ipod > kldload sbp / > > but I don't seem to be able to get ethernet to work. A google shows that > this is a long-standing issue: > > http://lists.freebsd.org/pipermail/freebsd-questions/2003-August/016739.h= tm >l http://lists.freebsd.org/pipermail/freebsd-net/2003-July/001016.html > > but I don't see anything else posted since August last year. > > I did come across this driver against FreeBSD-5.1: > http://www.onthenet.com.au/~q/nvnet/ [1] > > Anyone have any experience with it? It claims to be in the official ports > tree under net/nvnet, but I don't find it there (not in the 5.2.1-RELEASE > ports tree anyway). Well actually, I did find something here: > http://www.freebsd.org/cgi/pds.cgi?ports/net/nvnet [2] I tried the nvnet driver from the ports some days ago with a nforce2 and it= =20 worked flawlessly. But you can also use the ProjectEvil ndis wrapper and use the WinXP driver. I also did this with great success some weeks ago. > > Unfortunately the driver page [1] doesn't link to the Linux driver it > requires, and the port at [2] links to a different version of nvnet than > the one at [1]. > > If anyone has this working with FreeBSD-5.2.1 (and either an up-to-date > port, or a pointer to the correct Linux module required), that would save > me some random hacking. > > Incidentally, my machine has two VGA ports. If anyone knows how to get bo= th > of those working together with XFree86, that would be appreciated too! You need the proprietary nvidia driver (from ports/x11/nvidia-driver). See = the=20 docs in the working directory of the port for more info, if you need a samp= le=20 dual-layout I can send you mine. Best regards, =2DHarry > > Cheers, > > Brian. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" --Boundary-02=_XO3ZAwRaDgAWspf Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAZ3OXBylq0S4AzzwRAk8RAJ0aKYtFkXQZPq1Z6CXu1/a33+96CQCeIHPz lrrC4FxzQwONXme7TEDma00= =zwhD -----END PGP SIGNATURE----- --Boundary-02=_XO3ZAwRaDgAWspf-- From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 19:18:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CC1916A4CE for ; Sun, 28 Mar 2004 19:18:25 -0800 (PST) Received: from trueband.net (director.trueband.net [216.163.120.8]) by mx1.FreeBSD.org (Postfix) with SMTP id 7F45443D2F for ; Sun, 28 Mar 2004 19:18:24 -0800 (PST) (envelope-from jhall@vandaliamo.net) Received: (qmail 25671 invoked by uid 1006); 29 Mar 2004 03:18:21 -0000 Received: from jhall@vandaliamo.net by rs0 by uid 1003 with qmail-scanner-1.16 (spamassassin: 2.44. Clear:SA:0(-4.9/100.0):. Processed in 0.761807 secs); 29 Mar 2004 03:18:21 -0000 X-Spam-Status: No, hits=-4.9 required=100.0 X-Spam-Level: Received: from unknown (HELO trueband.net) (127.0.0.1) by -v with SMTP; 29 Mar 2004 03:18:20 -0000 Received: (qmail 25565 invoked from network); 29 Mar 2004 03:18:18 -0000 Received: from unknown (HELO vandaliamo.net) (12.170.206.13) by -v with SMTP; 29 Mar 2004 03:18:18 -0000 Message-ID: <40679626.1040104@vandaliamo.net> Date: Sun, 28 Mar 2004 21:21:10 -0600 From: Jay Hall User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 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: RE: PPTP MTU 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, 29 Mar 2004 03:18:25 -0000 OK, I think I have an MTU negotiation problem. The server side sets an MTU of 1458 and the client side sets an MTU of 1456. Occassionally, the MTUs on the client and the server will be the same and then the connection comes up and runs like a champ as long as the MTU is 1456. Any other values, even if they are the same on the client and server end result in a connection that comes up and then drops. Both the client and the server contain the line set link mtu 1460 In order to use the PPTP connection, I connect to the Internet using a DSL connection. I have tried using both MPD and ppp to establish the Internet connection. And, while the Internet connection is always successful, the pptp connection is not. I am using an Intel 10/100/1000 NIC in the server on the client end. I am using a Westell 2100 DSL modem, in bridge mode, to establish the DSL connection. Is it possible that this is a hardware issue? Thanks for your help. Jay Date: Sat, 27 Mar 2004 08:08:34 -0600 From: Jay Hall Subject: PPTP mtu To: freebsd-net@freebsd.org Message-ID: <40658AE2.2080506@vandaliamo.net> Content-Type: text/plain; charset=us-ascii; format=flowed I am using mpd to establish a DSL connection and, once that connection is established, I am brining up a PPTP connection. However, I am having problems keeping the PPTP connection up. In the logs on the remote machine, I am seeing the following error message: Mar 27 00:22:52 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Nak #1 link 0 (Req-Sent) Mar 27 00:22:52 ST_CHARLES mpd: MPPC Mar 27 00:22:52 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:22:52 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #2 Mar 27 00:22:52 ST_CHARLES mpd: MPPC Mar 27 00:22:52 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:22:52 ST_CHARLES mpd: [vpn] error writing len 14 frame to bypass: No route to host Mar 27 00:22:54 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #56 link 0 (Req-Sent) Mar 27 00:22:54 ST_CHARLES mpd: MPPC Mar 27 00:22:54 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 27 00:22:54 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #56 Mar 27 00:22:54 ST_CHARLES mpd: MPPC Mar 27 00:22:54 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:22:54 ST_CHARLES mpd: [vpn] error writing len 14 frame to bypass: No route to host Mar 27 00:22:54 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #3 Mar 27 00:22:54 ST_CHARLES mpd: MPPC Mar 27 00:22:54 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:22:54 ST_CHARLES mpd: [vpn] error writing len 14 frame to bypass: No route to host Mar 27 00:22:56 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #57 link 0 (Req-Sent) Mar 27 00:22:56 ST_CHARLES mpd: MPPC Mar 27 00:22:56 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 27 00:22:56 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #57 Mar 27 00:22:56 ST_CHARLES mpd: MPPC Mar 27 00:22:56 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:22:56 ST_CHARLES mpd: [vpn] error writing len 14 frame to bypass: No route to host Mar 27 00:22:56 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #4 Mar 27 00:22:56 ST_CHARLES mpd: MPPC Mar 27 00:22:56 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:22:58 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #58 link 0 (Req-Sent) Mar 27 00:22:58 ST_CHARLES mpd: MPPC Mar 27 00:22:58 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 27 00:22:58 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #58 Mar 27 00:22:58 ST_CHARLES mpd: MPPC Mar 27 00:22:58 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:22:58 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #5 Mar 27 00:22:58 ST_CHARLES mpd: MPPC Mar 27 00:22:58 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:23:00 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #59 link 0 (Req-Sent) Mar 27 00:23:00 ST_CHARLES mpd: MPPC Mar 27 00:23:00 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 27 00:23:00 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #59 Mar 27 00:23:00 ST_CHARLES mpd: MPPC Mar 27 00:23:00 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:23:00 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #6 Mar 27 00:23:00 ST_CHARLES mpd: MPPC Mar 27 00:23:00 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:23:02 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #60 link 0 (Req-Sent) Mar 27 00:23:02 ST_CHARLES mpd: MPPC Mar 27 00:23:02 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 27 00:23:02 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #60 Mar 27 00:23:02 ST_CHARLES mpd: MPPC Mar 27 00:23:02 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:23:02 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #7 Mar 27 00:23:02 ST_CHARLES mpd: MPPC Mar 27 00:23:02 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:23:04 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #61 link 0 (Req-Sent) Mar 27 00:23:04 ST_CHARLES mpd: MPPC Mar 27 00:23:04 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 27 00:23:04 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #61 Mar 27 00:23:04 ST_CHARLES mpd: MPPC Mar 27 00:23:04 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:23:04 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #8 Mar 27 00:23:04 ST_CHARLES mpd: MPPC Mar 27 00:23:04 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:23:06 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #9 Mar 27 00:23:06 ST_CHARLES mpd: MPPC Mar 27 00:23:06 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #63 link 0 (Req-Sent) Mar 27 00:23:08 ST_CHARLES mpd: MPPC Mar 27 00:23:08 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: not converging Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: parameter negotiation failed Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: Close event Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: state change Req-Sent --> Closing Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: SendTerminateReq #10 Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: encryption required, but MPPE was not negotiated in both directions Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: failed to negotiate required encryption Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: Close event Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: state change Closing --> Closed Mar 27 00:23:08 ST_CHARLES mpd: [vpn] CCP: LayerFinish Mar 27 00:23:08 ST_CHARLES mpd: [vpn] IPCP: failed to negotiate required encryption Mar 27 00:23:08 ST_CHARLES mpd: [vpn] IPCP: LayerFinish Mar 27 00:23:08 ST_CHARLES mpd: [vpn] IPCP: LayerStart On the server I am seeing the following messages: [pptp1] CCP: parameter negotiation failed I think this might be an MTU problem. When the MTU is negotiated at 1456, the connection runs fine. However, at values higher or lower, the connection does not work, and will drop after a few seconds. I am using mpd-3.15 on both ends of the connection. Any suggestions would be greatly appreciated. Thank in advance for your assistance. Jay From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 22:31:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E76E216A4CE for ; Sun, 28 Mar 2004 22:31:24 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9315F43D31 for ; Sun, 28 Mar 2004 22:31:24 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-67-169-127-171.client.comcast.net[67.169.127.171]) by comcast.net (sccrmhc13) with ESMTP id <2004032906312301600hvrble>; Mon, 29 Mar 2004 06:31:23 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i2T6VM0m074583; Sun, 28 Mar 2004 22:31:22 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i2T6VHFP074582; Sun, 28 Mar 2004 22:31:17 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Sun, 28 Mar 2004 22:31:17 -0800 From: "Crist J. Clark" To: Lutz Petersen Message-ID: <20040329063117.GC73269@blossom.cjclark.org> References: <6686.1079661277@www27.gmx.net> <20040319193514.GB54073@blossom.cjclark.org> <406204AF.5050600@despammed.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406204AF.5050600@despammed.com> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org Subject: Re: BIND: Lookup of CNAME records 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: Mon, 29 Mar 2004 06:31:25 -0000 On Wed, Mar 24, 2004 at 10:59:11PM +0100, Lutz Petersen wrote: > Crist J. Clark wrote: > >How long does it take to do a reverse-lookup on the result of the > >previous lookups? The applications may be trying to resolve a PTR > >record for the final IP address they end up with. > > Reverse lookups work fine. But I do not think PTR lookups are an issue > in this case (see below). > > >You can try the following two tests and compare the difference, > > > > 1) Put the two external servers in resolv.conf, and run, > > > > # tcpdump -s512 port 53 > > > > And try your ftp or telnet. > > > > 2) Put 127.0.0.1 back into resolv.conf, clear the cache of the local > > BIND (not sure of a way to do that other than killing and > > restarting in 8.x.x), and run the same thing, > > > > # tcpdump -s512 port 53 > > > > And again try the ftp or telnet. > > I am enclosing the results of these two tests. For better readability I > have removed the time offset and replaced my IP number with "me", the > forwarder's IP with "fw". It looks like "fw" is messed up. Those responses don't carry any authority records. The queries for the root servers are returning "no error" with completely blank responses. > (1) > 00:00.000000 me.49235 > fw.domain: 1081+ AAAA? ftp.de.freebsd.org. (36) > 00:00.235195 fw.domain > me.49235: 1081 2/0/0 CNAME ftp4.de.freebsd.org., > CNAME ftp.leo.org. (77) (DF) > 00:00.235648 me.49236 > fw.domain: 1082+ A? ftp.de.freebsd.org. (36) > 00:00.850987 fw.domain > me.49236: 1082 3/0/0 CNAME ftp4.de.freebsd.org., > CNAME ftp.leo.org., A 131.159.72.23 (93) (DF) > > (2) > 00:00.000000 me.domain > fw.domain: 8207+ [1au] AAAA? ftp.de.freebsd.org. > (47) > 00:00.093818 fw.domain > me.domain: 8207 2/0/0 CNAME ftp4.de.freebsd.org., > CNAME ftp.leo.org. (77) (DF) > 00:00.094539 me.domain > fw.domain: 30226+ [1au] AAAA? ftp.leo.org. (40) > 00:00.183988 fw.domain > me.domain: 30226 0/0/0 (29) (DF) > 00:05.184504 me.domain > fw.domain: 52418+ [1au] AAAA? ftp.leo.org. (40) > 00:05.278765 fw.domain > me.domain: 52418 0/0/0 (29) (DF) > 00:15.278043 me.domain > fw.domain: 24089+ [1au] AAAA? ftp.leo.org. (40) > 00:15.377019 fw.domain > me.domain: 24089 0/0/0 (29) (DF) > 00:35.374320 me.domain > fw.domain: 31178+ [1au] AAAA? ftp.leo.org. (40) > 00:35.978176 fw.domain > me.domain: 31178 0/0/0 (29) (DF) > 01:15.970823 me.domain > fw.domain: 53751+ [1au] A? ftp.leo.org. (40) > 01:16.064579 fw.domain > me.domain: 53751 1/0/0 A 131.159.72.23 (45) (DF) > 01:16.065468 me.domain > fw.domain: 56474+ [1au] AAAA? J.ROOT-SERVERS.NET. > (47) > 01:16.065915 me.domain > fw.domain: 36905+ [1au] AAAA? K.ROOT-SERVERS.NET. > (47) > 01:16.066172 me.domain > fw.domain: 38356+ [1au] AAAA? L.ROOT-SERVERS.NET. > (47) > 01:16.066372 me.domain > fw.domain: 395+ [1au] AAAA? M.ROOT-SERVERS.NET. > (47) > 01:16.066572 me.domain > fw.domain: 54526+ [1au] AAAA? I.ROOT-SERVERS.NET. > (47) > 01:16.066771 me.domain > fw.domain: 61085+ [1au] AAAA? E.ROOT-SERVERS.NET. > (47) > 01:16.066986 me.domain > fw.domain: 38040+ [1au] AAAA? D.ROOT-SERVERS.NET. > (47) > 01:16.068062 me.domain > fw.domain: 35807+ [1au] AAAA? A.ROOT-SERVERS.NET. > (47) > 01:16.068664 me.domain > fw.domain: 27426+ [1au] AAAA? H.ROOT-SERVERS.NET. > (47) > 01:16.069117 me.domain > fw.domain: 39377+ [1au] AAAA? C.ROOT-SERVERS.NET. > (47) > 01:16.069552 me.domain > fw.domain: 11036+ [1au] AAAA? G.ROOT-SERVERS.NET. > (47) > 01:16.070036 me.domain > fw.domain: 34035+ [1au] AAAA? F.ROOT-SERVERS.NET. > (47) > 01:16.070476 me.domain > fw.domain: 33542+ [1au] AAAA? B.ROOT-SERVERS.NET. > (47) > 01:16.157385 fw.domain > me.domain: 56474 0/0/0 (36) (DF) > 01:16.160564 fw.domain > me.domain: 36905 0/0/0 (36) (DF) > 01:16.172424 fw.domain > me.domain: 38356 0/0/0 (36) (DF) > 01:16.176809 fw.domain > me.domain: 395 0/0/0 (36) (DF) > 01:16.188828 fw.domain > me.domain: 54526 0/0/0 (36) (DF) > 01:16.193810 fw.domain > me.domain: 61085 0/0/0 (36) (DF) > 01:16.202584 fw.domain > me.domain: 38040 0/0/0 (36) (DF) > 01:16.209829 fw.domain > me.domain: 35807 0/0/0 (36) (DF) > 01:16.217073 fw.domain > me.domain: 27426 0/0/0 (36) (DF) > 01:16.238637 fw.domain > me.domain: 39377 0/0/0 (36) (DF) > 01:16.240081 fw.domain > me.domain: 11036 0/0/0 (36) (DF) > 01:16.241823 fw.domain > me.domain: 34035 0/0/0 (36) (DF) > 01:16.246842 fw.domain > me.domain: 33542 0/0/0 (36) (DF) > > As I thought of an IPv6 problem, I compiled a new kernel with IPNET6. > That did not help at all, unfortunately. > > Any ideas? > _______________________________________________ > 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" -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 22:51:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF88816A4CE for ; Sun, 28 Mar 2004 22:51:58 -0800 (PST) Received: from smtp.octapharma.se (smtp.octapharma.se [195.198.168.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3DFC43D2F for ; Sun, 28 Mar 2004 22:51:57 -0800 (PST) (envelope-from Mikael.Gunnarsson@octapharma.se) Received: from sestosrv004p.ad.octapharma.se ([195.198.13.61] RDNS failed) by smtp.octapharma.se with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 08:55:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Mar 2004 08:51:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Looking for switch recommendations ... Thread-Index: AcQTTKm8g1cNoKLBSRCet8GAiF6tqACDAPrg From: "Gunnarsson, Mikael" To: "Marc G. Fournier" , X-OriginalArrivalTime: 29 Mar 2004 06:55:16.0343 (UTC) FILETIME=[CA983870:01C4155A] Subject: RE: Looking for switch recommendations ... 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, 29 Mar 2004 06:51:58 -0000 You don't mention if you need gigabit speeds on all ports, so I'll assu= me you don't. The HP ProCurve 2524 (or 2512 if you really only want 12= ports, but the price difference is minimal) is a very nice and stable sw= itch. We have about 95-100 2524 switches on the access level here, and I = am yet to experience a fault that originated in the actual switch. It has= 24 (or 12) 10/100 ports and two module slots for gigabit links. It's man= ageable via serial console, telnet, web or snmp (and rmon too, I think) a= nd has all the bells and whistles you expect from a manageble switch (ple= nty of monitoring, spanning tree, vlan support, etc..) They're rather = cheap nowadays, over here they go for 3500 SEK (approx. $450) .. It's one= of HP's big sellers, so they have dropped quite a lot in price lately. = Mvh Mikael Gunnarsson Octapharma AB / IT > -----Original M= essage----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freeb= sd-net@freebsd.org]On Behalf Of Marc G. Fournier > Sent: den 26 mars 200= 4 17:05 > To: freebsd-net@freebsd.org > Subject: Looking for switch rec= ommendations ... > > > > I'm looking at replacing my el'cheapo swi= tch with something > better that > will allow me to fix my issues with= the em/full-duplex problem ... > > I'm looking for ssomething managed= , as well as SNMP aware so > that I can > tie it into Zabbix for monit= oring ... something 8 or 12 port > preferred. > > Cisco, of course, = is always a big name ... but also expensive ... oen > recommendation is = the xl 1900, but I can't find any specs on her at > cisco's site, so dis= continued product? > > What about Netgear, which I have easy access to= ? Or Alcatel? > > models to stay away from? > > Thanks ... > > = ---- > Marc G. Fournier Hub.Org Networking Services (http://= www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy = ICQ: 7615664 _______________________________________________ freebs= d-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo= /freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@f= reebsd.org" This email and any files transmitted with it are confidentia= l and intended solely for the use of the individual or entity to whom the= y are addressed. If you have received this email in error please notify t= he system manager. This message contains confidential information and is = intended only for the individual named. If you are not the named addresse= e you should not disseminate, distribute or copy this e-mail. From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 23:18:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 058F316A4CE for ; Sun, 28 Mar 2004 23:18:54 -0800 (PST) Received: from mail.a-quadrat.at (mail.a-quadrat.at [81.223.141.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C25F43D54 for ; Sun, 28 Mar 2004 23:18:53 -0800 (PST) (envelope-from mbretter@a-quadrat.at) Received: from localhost (localhost.a-quadrat.at [127.0.0.1]) by files.a-quadrat.at (Postfix) with ESMTP id 84B775CBC2; Mon, 29 Mar 2004 09:18:51 +0200 (CEST) Received: from mail.a-quadrat.at ([127.0.0.1]) by localhost (files.a-quadrat.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44727-04; Mon, 29 Mar 2004 09:18:48 +0200 (CEST) Received: from BRUTUS.a-quadrat.at (brutus.a-quadrat.at [192.168.90.60]) by files.a-quadrat.at (Postfix) with ESMTP id F37485C853; Mon, 29 Mar 2004 09:18:47 +0200 (CEST) Date: Mon, 29 Mar 2004 09:18:46 +0200 (=?ISO-8859-15?Q?Westeurop=E4ische_Sommerzeit?=) From: Michael Bretterklieber To: Jay Hall In-Reply-To: <40679626.1040104@vandaliamo.net> Message-ID: References: <40679626.1040104@vandaliamo.net> X-X-Sender: mbretter@files.a-quadrat.at MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at a-quadrat.at cc: freebsd-net@freebsd.org Subject: RE: PPTP MTU 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, 29 Mar 2004 07:18:54 -0000 Hi, On Sun, 28 Mar 2004, Jay Hall wrote: > OK, I think I have an MTU negotiation problem. The server side sets an > MTU of 1458 and the client side sets an MTU of 1456. Occassionally, the > MTUs on the client and the server will be the same and then the > connection comes up and runs like a champ as long as the MTU is 1456. > Any other values, even if they are the same on the client and server end > result in a connection that comes up and then drops. > > Both the client and the server contain the line > > set link mtu 1460 > > Mar 27 00:22:52 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Nak #1 link 0 > (Req-Sent) > Mar 27 00:22:52 ST_CHARLES mpd: MPPC > Mar 27 00:22:52 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless > Mar 27 00:22:52 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #2 > Mar 27 00:22:52 ST_CHARLES mpd: MPPC > Mar 27 00:22:52 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless > Mar 27 00:22:52 ST_CHARLES mpd: [vpn] error writing len 14 frame to > bypass: No route to host there is a problem with the underlaying connection, could you please post the whole log, from the beginning of the connection. the value of 1456 is ok, because Mpd takes the ppp-header into account, wich has usually 4 bytes. bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 From owner-freebsd-net@FreeBSD.ORG Sun Mar 28 23:37:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 102FD16A4CE for ; Sun, 28 Mar 2004 23:37:08 -0800 (PST) Received: from lakecmmtao02.coxmail.com (lakecmmtao02.coxmail.com [68.99.120.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AD6043D1F for ; Sun, 28 Mar 2004 23:37:07 -0800 (PST) (envelope-from steve@freeslacker.net) Received: from freeslacker.net ([68.110.170.205]) by lakecmmtao02.coxmail.comESMTP <20040329073707.LVUC1450.lakecmmtao02.coxmail.com@freeslacker.net>; Mon, 29 Mar 2004 02:37:07 -0500 Message-ID: <4067D250.8070609@freeslacker.net> Date: Mon, 29 Mar 2004 00:37:52 -0700 From: Steven Stremciuc User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Looking for switch recommendations ... 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, 29 Mar 2004 07:37:08 -0000 Has anyone tested port mirroring on these switches (2524) and run into any problems? Many people seem to recommend these ProCurve switches here and so far they seem like a great buy (only one I saw that cheap that does 802.1x). I'm also looking for a managed switch (probably something off ebay) and would like to find something that does port mirroring nicely as I'd like to play with that in the future. I saw Dell's Powerconnect 3348 has some problems with port mirroring and am trying to avoid getting a switch where the feature is listed as supported but doesn't work as expected. Info about the 3348's problems: http://forums.us.dell.com/supportforums/board/message?board.id=pc_managed&message.id=1425 Steve Stremciuc Gunnarsson, Mikael wrote: >You don't mention if you need gigabit speeds on all ports, so I'll assume you don't. > >The HP ProCurve 2524 (or 2512 if you really only want 12 ports, but the price difference is minimal) is a very nice and stable switch. We have about 95-100 2524 switches on the access level here, and I am yet to experience a fault that originated in the actual switch. It has 24 (or 12) 10/100 ports and two module slots for gigabit links. It's manageable via serial console, telnet, web or snmp (and rmon too, I think) and has all the bells and whistles you expect from a manageble switch (plenty of monitoring, spanning tree, vlan support, etc..) > >They're rather cheap nowadays, over here they go for 3500 SEK (approx. $450) .. It's one of HP's big sellers, so they have dropped quite a lot in price lately. > > > >Mvh >Mikael Gunnarsson >Octapharma AB / IT > > > > > >>-----Original Message----- >>From: owner-freebsd-net@freebsd.org >>[mailto:owner-freebsd-net@freebsd.org]On Behalf Of Marc G. Fournier >>Sent: den 26 mars 2004 17:05 >>To: freebsd-net@freebsd.org >>Subject: Looking for switch recommendations ... >> >> >> >>I'm looking at replacing my el'cheapo switch with something >>better that >>will allow me to fix my issues with the em/full-duplex problem ... >> >>I'm looking for ssomething managed, as well as SNMP aware so >>that I can >>tie it into Zabbix for monitoring ... something 8 or 12 port >>preferred. >> >>Cisco, of course, is always a big name ... but also expensive ... oen >>recommendation is the xl 1900, but I can't find any specs on her at >>cisco's site, so discontinued product? >> >>What about Netgear, which I have easy access to? Or Alcatel? >> >>models to stay away from? >> >>Thanks ... >> >>---- >>Marc G. Fournier Hub.Org Networking Services >> >> >(http://www.hub.org) >Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 >_______________________________________________ >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" >This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 00:12:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BBA916A4CE for ; Mon, 29 Mar 2004 00:12:51 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E852F43D41 for ; Mon, 29 Mar 2004 00:12:49 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i2T8FjSs090714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Mar 2004 11:15:47 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2T8CODr070793; Mon, 29 Mar 2004 11:12:24 +0300 (EEST) (envelope-from ru) Date: Mon, 29 Mar 2004 11:12:24 +0300 From: Ruslan Ermilov To: "Jacob S. Barrett" Message-ID: <20040329081224.GC70021@ip.net.ua> References: <200403251118.40718.jbarrett@amduat.net> <20040327074205.GA32984@ip.net.ua> <200403270753.53476.jbarrett@amduat.net> <200403270848.37996.jbarrett@amduat.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i7F3eY7HS/tUJxUd" Content-Disposition: inline In-Reply-To: <200403270848.37996.jbarrett@amduat.net> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@FreeBSD.org Subject: Re: Disabling VLAN_HWTAGGING 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, 29 Mar 2004 08:12:51 -0000 --i7F3eY7HS/tUJxUd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 27, 2004 at 08:48:37AM -0800, Jacob S. Barrett wrote: > On Saturday 27 March 2004 07:53 am, Jacob S. Barrett wrote: > > Well with a new "correct" MAC that pings go back and forth just fine no= w.=20 > > I will back out all my changes and see if they still work with the hard= ware > > tagging/detagging enabled. >=20 > OK, with the hardware support re-enabled the frame now enters the driver.= It=20 > is detected as VLAN frame and sent to VLAN_INPUT_TAG. The frame is then= =20 > delivered via lower hook to the ng_vlan where it doesn't match the vlan t= ag=20 > so it goes out the nomatch hook. I guess with the VLAN tag stripped from= the=20 > frame that ng_vlan can't match it. Is this the expected behavior with=20 > ng_vlan? I can just comment out the VLAN stripping line in the driver if= it=20 > is the expected behavior. That isn't a big deal really. >=20 No, this is not of course expected. Can you add some debug printfs in the ng_vlan.c:ng_vlan_rcvdata() and see if it ever receives the VLAN tag, and if so, print its value (perhaps the tag is entered by a driver in a network byte order). > I haven't done a whole lot with the network interface drivers other than = a few=20 > minor fixes here and there, but would it be hard to add some sort of flag= to=20 > enable/disable the tag stripping via ifconfig? I was thinking that could= be=20 > down through a "linkx" flag right? If the driver got the say "link1" it= =20 > would down the interface, set clear the stripping config bits, and then r= e-up=20 > the interface. Or would this be better handled by a sysctl option? Does= =20 > that sound safe and do-able? >=20 Well, for IP/TCP/UDP checksumming, it's possible to switch the corresponding bit in the interface's enabled capabilities field. OTOH, switching VLAN stripping on/off requires reprogramming of the hardware. Generally, if the hardware supports IP/TCP/UDP checksumming and or VLAN tag removal/insertion, it's better to use it. We'd better find the root of the problem and fix it. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --i7F3eY7HS/tUJxUd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAZ9poUkv4P6juNwoRAoh/AJ9cjaW4Kw8N0rx0OaZOSl7z1cYNMACfQM7C VNQoigAaEV7HB4JWaR/PCuU= =E3Ey -----END PGP SIGNATURE----- --i7F3eY7HS/tUJxUd-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 01:07:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AE3216A4CE for ; Mon, 29 Mar 2004 01:07:48 -0800 (PST) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54DEA43D3F for ; Mon, 29 Mar 2004 01:07:47 -0800 (PST) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id i2T97kAP040549; Mon, 29 Mar 2004 12:07:46 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.12.9p2/8.12.9) id i2T96pV3003830; Mon, 29 Mar 2004 12:06:51 +0300 (EEST) (envelope-from netch) Date: Mon, 29 Mar 2004 12:06:51 +0300 From: Valentin Nechayev To: Max Khon Message-ID: <20040329090651.GA3788@iv.nn.kiev.ua> References: <20040324195934.GA76265@samodelkin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040324195934.GA76265@samodelkin.net> X-42: On Organization: Dark side of coredump cc: freebsd-net@freebsd.org Subject: Re: race condition in ipfw restart (please review the fix) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 09:07:48 -0000 Thu, Mar 25, 2004 at 01:59:34, fjoe (Max Khon) wrote about "race condition in ipfw restart (please review the fix)": MK> ipfw restart has race condition: there is "sleep 2" statement after MK> killall natd but if natd will not die in 2 seconds ipfw can't MK> start nat daemon (natd: Unable to bind divert socket.: Address already in use). Is there any reason to wait until natd finishes polite restart? I usually kill it with -KILL, result is the same. -netch- From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 01:18:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44EC116A4CE; Mon, 29 Mar 2004 01:18:36 -0800 (PST) Received: from boggle.pobox.com (boggle.pobox.com [208.58.1.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FF6C43D53; Mon, 29 Mar 2004 01:18:36 -0800 (PST) (envelope-from b.candler@pobox.com) Received: from colander (localhost [127.0.0.1]) by boggle.pobox.com (Postfix) with ESMTP id 4DE1D7F97D; Mon, 29 Mar 2004 04:18:34 -0500 (EST) Received: from jester.pobox.com (jester.pobox.com [64.71.166.114]) by boggle.pobox.com (Postfix) with ESMTP id A3FE87F95F; Mon, 29 Mar 2004 04:18:33 -0500 (EST) Received: from vaio.linnet.org (unknown [80.44.130.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jester.pobox.com (Postfix) with ESMTP id 80D4688; Mon, 29 Mar 2004 04:18:32 -0500 (EST) Received: from brian by vaio.linnet.org with local (Exim 4.30) id 1B7sub-000Aau-Ql; Mon, 29 Mar 2004 10:18:29 +0100 Date: Mon, 29 Mar 2004 10:18:29 +0100 From: Brian Candler To: Harald Schmalzbauer Message-ID: <20040329091829.GB40668@uk.tiscali.com> References: <20040328215731.GA40112@uk.tiscali.com> <200403290253.43487.h@schmalzbauer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403290253.43487.h@schmalzbauer.de> User-Agent: Mutt/1.4.1i cc: q@onthenet.com.au cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org cc: wpaul@freebsd.org Subject: Re: nVidia chipset - ethernet support? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 09:18:36 -0000 On Mon, Mar 29, 2004 at 02:53:38AM +0200, Harald Schmalzbauer wrote: > I tried the nvnet driver from the ports some days ago with a nforce2 and it > worked flawlessly. Many thanks, I have it working now. Summary for anyone else who needs to do this: - fetch nvnet.tar.gz from http://cvsweb.FreeBSD.org/ports/net/nvnet/nvnet.tar.gz?tarball=1 - unpack nvnet.tar.gz under /usr/ports/net - since the network interface is not working at this moment, I had to fetch the other files into /usr/ports/distfiles/ manually: http://www.onthenet.com.au/~q/nvnet/nvnet-src-20040108.tar.gz ftp://download.nvidia.com/XFree86/nforce/1.0-0261/NVIDIA_nforce-1.0-0261.tar.gz [this is a Microsoft FTP server, remember to set binary mode!] - cd /usr/ports/net/nvnet - in Makefile, change NVNETVERSION= 20040108 but leave NVVERSION=0261 (version 0269 is for AMD64 processors I am told) - append to 'distinfo' MD5 (nvnet-src-20040108.tar.gz) = 96730b413cb1f949f6cdadb6797740c2 SIZE (nvnet-src-20040108.tar.gz) = 17547 - make install - append to /boot/loader.conf if_nv_load="YES" Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 01:21:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A58516A4CE for ; Mon, 29 Mar 2004 01:21:08 -0800 (PST) Received: from ns.egotop.com (unknown [220.202.4.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id B34B243D1F for ; Mon, 29 Mar 2004 01:21:06 -0800 (PST) (envelope-from chenbo@egotop.com) Received: ( www.egotop.com qmail 12865 invoked from network); 29 Mar 2004 17:21:02 +0800 Received: from unknown (HELO RavProxy) (172.16.12.76) by 172.16.1.10 with SMTP; 29 Mar 2004 17:21:02 +0800 From: "chenbo" To: freebsd-net@freebsd.org X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Date: Mon, 29 Mar 2004 17:20:58 +0800 Message-Id: <20040329092106.B34B243D1F@mx1.FreeBSD.org> Subject: help:FreeBSD4.8+IP Filter: v3.4.32,and error:/kernel: in_cksum: out of data by 3 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, 29 Mar 2004 09:21:08 -0000 Hi: I have installed the FreeBSD4.8 and IP Filter3.4.32. The FreeBSD BOX is used to NAT. But , i always get the messages "in_cksum: out of data by 3" , And the IP Packets always are droped. How to resolve the problem? the message is: cat /var/log/messages Mar 8 17:13:49 nat /kernel: in_cksum: out of data by 2 Mar 8 17:14:19 nat last message repeated 4 times Mar 8 20:10:03 nat /kernel: in_cksum: out of data by 4 Mar 9 11:59:47 nat /kernel: in_cksum: out of data by 2 Mar 9 11:59:48 nat /kernel: in_cksum: out of data by 2 Mar 9 12:40:06 nat /kernel: in_cksum: out of data by 2 Mar 9 13:32:47 nat /kernel: in_cksum: out of data by 2 Mar 9 17:27:48 nat /kernel: in_cksum: out of data by 2 Mar 9 17:28:16 nat last message repeated 3 times Mar 9 17:37:19 nat /kernel: in_cksum: out of data by 3 Mar 9 18:04:03 nat /kernel: in_cksum: out of data by 1 Mar 9 19:35:19 nat /kernel: in_cksum: out of data by 2 Mar 9 19:35:23 nat last message repeated 2 times Mar 10 09:27:43 nat /kernel: in_cksum: out of data by 2 Mar 10 15:43:08 nat /kernel: in_cksum: out of data by 3 Mar 10 15:43:09 nat /kernel: in_cksum: out of data by 3 Mar 10 19:22:34 nat /kernel: in_cksum: out of data by 2 Mar 10 19:22:55 nat last message repeated 4 times Mar 12 19:30:00 nat /kernel: in_cksum: out of data by 3 Mar 12 20:48:29 nat /kernel: in_cksum: out of data by 3 Mar 13 13:56:40 nat /kernel: in_cksum: out of data by 3 Mar 13 15:45:40 nat /kernel: in_cksum: out of data by 1 Mar 13 16:25:45 nat /kernel: in_cksum: out of data by 3 Mar 13 16:25:53 nat /kernel: in_cksum: out of data by 3 Mar 13 18:28:38 nat /kernel: in_cksum: out of data by 2 Mar 13 18:42:54 nat /kernel: in_cksum: out of data by 3 Mar 13 18:42:57 nat last message repeated 2 times Mar 13 19:04:05 nat /kernel: in_cksum: out of data by 1 Mar 13 19:33:58 nat /kernel: in_cksum: out of data by 3 Mar 13 19:34:16 nat last message repeated 3 times Mar 15 16:06:10 nat /kernel: in_cksum: out of data by 1 Mar 15 16:06:37 nat last message repeated 4 times the system information is: nat# netstat -m 213/432/240000 mbufs in use (current/peak/max): 213 mbufs allocated to data 211/432/60000 mbuf clusters in use (current/peak/max) 972 Kbytes allocated to network (0 of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines nat# netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll fxp0 1500 xx:xx:xx:xx:xx:xx 3630613020 14 3601258558 0 0 fxp0 1500 xx.xx.xx.xx xx.xx.xx.xx 7201 - 1332493 - - xl0 1500 xx:xx:xx:xx:xx:xx 4036405001 1 3534131265 0 0 xl0 1500 xx.xx.xx.xx xx.xx.xx.xx 285499286 - 11105 - - xl0 1500 xx.xx.xx.xx xx.xx.xx.xx 4058 - 0 - - ppp0* 1500 0 0 0 0 0 lo0 16384 28 0 28 0 0 lo0 16384 127 127.0.0.1 0 - 0 - - nat# nat# vmstat 1 procs memory page disk faults cpu r b w avm fre flt re pi po fr sr ad0 in sy cs us sy id 0 0 0 27516 790040 1 0 0 0 1 0 0 746 14 6 0 17 83 0 0 0 27516 790036 5 0 0 0 0 0 0 19842 23 8 0 40 60 0 0 0 27516 790036 3 0 0 0 0 0 0 19614 23 8 0 46 54 0 0 0 27516 790036 3 0 0 0 0 0 3 20335 23 8 0 37 63 0 0 0 27516 790036 3 0 0 0 0 0 0 20996 23 8 0 49 51 0 0 0 27516 790036 3 0 0 0 0 0 1 19973 23 9 0 45 55 0 0 0 27516 790036 3 0 0 0 0 0 0 20990 23 8 0 42 58 0 0 0 27516 790036 3 0 0 0 0 0 0 20368 27 9 0 43 57 ^C nat# cat /boot/loader.conf userconfig_script_load="YES" hw.ata.wc="1" kern.ipc.nmbclusters="60000" nat# cat /etc/sysctl.conf vfs.vmiodirenable=1 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=8192 kern.ipc.maxsockets=16424 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.rfc1323=1 net.inet.tcp.delayed_ack=0 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=65535 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.inet.ipf.fr_tcpidletimeout=7200 net.inet.ipf.fr_tcpclosewait=120 net.inet.ipf.fr_tcplastack=120 net.inet.ipf.fr_tcptimeout=240 net.inet.ipf.fr_tcpclosed=60 net.inet.ipf.fr_tcphalfclosed=300 net.inet.ipf.fr_udptimeout=90 net.inet.ipf.fr_icmptimeout=35 net.link.ether.inet.log_arp_wrong_iface=0 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim_output=0 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=300 nat# ipnat -l |wc 31572 279674 2310903 Dec 31 19:40:59 nat /kernel: Copyright (c) 1992-2003 The FreeBSD Project. Dec 31 19:40:59 nat /kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Dec 31 19:40:59 nat /kernel: The Regents of the University of California. All rights reserved. Dec 31 19:40:59 nat /kernel: FreeBSD 4.8-RELEASE #1: Fri Sep 12 09:04:24 CST 2003 Dec 31 19:40:59 nat /kernel: Timecounter "i8254" frequency 1193182 Hz Dec 31 19:40:59 nat /kernel: Timecounter "TSC" frequency 2398856292 Hz Dec 31 19:40:59 nat /kernel: CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2398.86-MHz 686-class CPU) Dec 31 19:40:59 nat /kernel: Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Dec 31 19:40:59 nat /kernel: Features=0xbfebfbff Dec 31 19:40:59 nat /kernel: real memory = 1065353216 (1040384K bytes) Dec 31 19:40:59 nat /kernel: avail memory = 1033474048 (1009252K bytes) Dec 31 19:40:59 nat /kernel: Preloaded elf kernel "kernel" at 0xc02f0000. Dec 31 19:40:59 nat /kernel: Pentium Pro MTRR support enabled Dec 31 19:40:59 nat /kernel: IP Filter: v3.4.32 initialized. Default = pass all, Logging = enabled From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 05:38:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 673FC16A4CE for ; Mon, 29 Mar 2004 05:38:29 -0800 (PST) Received: from trueband.net (director.trueband.net [216.163.120.8]) by mx1.FreeBSD.org (Postfix) with SMTP id 7486D43D41 for ; Mon, 29 Mar 2004 05:38:28 -0800 (PST) (envelope-from jhall@vandaliamo.net) Received: (qmail 19203 invoked by uid 1006); 29 Mar 2004 13:38:25 -0000 Received: from jhall@vandaliamo.net by rs0 by uid 1003 with qmail-scanner-1.16 (spamassassin: 2.44. Clear:SA:0(-4.9/100.0):. Processed in 6.389173 secs); 29 Mar 2004 13:38:25 -0000 X-Spam-Status: No, hits=-4.9 required=100.0 X-Spam-Level: Received: from unknown (HELO trueband.net) (127.0.0.1) by -v with SMTP; 29 Mar 2004 13:38:19 -0000 Received: (qmail 18911 invoked from network); 29 Mar 2004 13:38:17 -0000 Received: from unknown (HELO vandaliamo.net) (12.170.206.13) by -v with SMTP; 29 Mar 2004 13:38:17 -0000 Message-ID: <40682776.5000104@vandaliamo.net> Date: Mon, 29 Mar 2004 07:41:10 -0600 From: Jay Hall User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Bretterklieber References: <40679626.1040104@vandaliamo.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: PPTP MTU 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, 29 Mar 2004 13:38:29 -0000 Here is a copy of the log file for the client. Mar 29 06:35:40 ST_CHARLES mpd: mpd: process 81252 terminated Mar 29 06:37:37 ST_CHARLES mpd: mpd: pid 81306, version 3.17 (root@ST_CHARLES.MNEA.ORG 10:34 26-Mar-2004) Mar 29 06:37:37 ST_CHARLES mpd: [vpn] ppp node is "mpd81306-vpn" Mar 29 06:37:37 ST_CHARLES mpd: mpd: local IP address for PPTP is 0.0.0.0 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] using interface ng1 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IFACE: Open event Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: Open event Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: state change Initial --> Starting Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: LayerStart Mar 29 06:37:37 ST_CHARLES mpd: [vpn] bundle: OPEN event in state CLOSED Mar 29 06:37:37 ST_CHARLES mpd: [vpn] opening link "vpn"... Mar 29 06:37:37 ST_CHARLES mpd: [vpn] link: OPEN event Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: Open event Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: state change Initial --> Starting Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: LayerStart Mar 29 06:37:37 ST_CHARLES mpd: [vpn] device: OPEN event in state DOWN Mar 29 06:37:37 ST_CHARLES mpd: pptp0: connecting to 199.223.158.225:1723 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] device is now in state OPENING Mar 29 06:37:37 ST_CHARLES mpd: pptp0: connected to 199.223.158.225:1723 Mar 29 06:37:37 ST_CHARLES mpd: pptp0: attached to connection with 199.223.158.225:1723 Mar 29 06:37:37 ST_CHARLES mpd: pptp0-0: outgoing call connected at 64000 bps Mar 29 06:37:37 ST_CHARLES mpd: [vpn] PPTP call successful Mar 29 06:37:37 ST_CHARLES mpd: [vpn] device: UP event in state OPENING Mar 29 06:37:37 ST_CHARLES mpd: [vpn] device is now in state UP Mar 29 06:37:37 ST_CHARLES mpd: [vpn] link: UP event Mar 29 06:37:37 ST_CHARLES mpd: [vpn] link: origination is local Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: Up event Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: state change Starting --> Req-Sent Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: phase shift DEAD --> ESTABLISH Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: SendConfigReq #1 Mar 29 06:37:37 ST_CHARLES mpd: ACFCOMP Mar 29 06:37:37 ST_CHARLES mpd: PROTOCOMP Mar 29 06:37:37 ST_CHARLES mpd: MRU 1500 Mar 29 06:37:37 ST_CHARLES mpd: MAGICNUM a618a2c0 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: rec'd Configure Request #13 link 0 (Req-Sent) Mar 29 06:37:37 ST_CHARLES mpd: ACFCOMP Mar 29 06:37:37 ST_CHARLES mpd: PROTOCOMP Mar 29 06:37:37 ST_CHARLES mpd: MRU 1500 Mar 29 06:37:37 ST_CHARLES mpd: MAGICNUM a2eb3f5e Mar 29 06:37:37 ST_CHARLES mpd: AUTHPROTO CHAP MSOFTv2 Mar 29 06:37:37 ST_CHARLES mpd: MP MRRU 1600 Mar 29 06:37:37 ST_CHARLES mpd: MP SHORTSEQ Mar 29 06:37:37 ST_CHARLES mpd: ENDPOINTDISC [802.1] 00 e0 b8 14 60 1f Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: SendConfigRej #13 Mar 29 06:37:37 ST_CHARLES mpd: MP MRRU 1600 Mar 29 06:37:37 ST_CHARLES mpd: MP SHORTSEQ Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: rec'd Configure Ack #1 link 0 (Req-Sent) Mar 29 06:37:37 ST_CHARLES mpd: ACFCOMP Mar 29 06:37:37 ST_CHARLES mpd: PROTOCOMP Mar 29 06:37:37 ST_CHARLES mpd: MRU 1500 Mar 29 06:37:37 ST_CHARLES mpd: MAGICNUM a618a2c0 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: state change Req-Sent --> Ack-Rcvd Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: rec'd Configure Request #14 link 0 (Ack-Rcvd) Mar 29 06:37:37 ST_CHARLES mpd: ACFCOMP Mar 29 06:37:37 ST_CHARLES mpd: PROTOCOMP Mar 29 06:37:37 ST_CHARLES mpd: MRU 1500 Mar 29 06:37:37 ST_CHARLES mpd: MAGICNUM a2eb3f5e Mar 29 06:37:37 ST_CHARLES mpd: AUTHPROTO CHAP MSOFTv2 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: SendConfigAck #14 Mar 29 06:37:37 ST_CHARLES mpd: ACFCOMP Mar 29 06:37:37 ST_CHARLES mpd: PROTOCOMP Mar 29 06:37:37 ST_CHARLES mpd: MRU 1500 Mar 29 06:37:37 ST_CHARLES mpd: MAGICNUM a2eb3f5e Mar 29 06:37:37 ST_CHARLES mpd: AUTHPROTO CHAP MSOFTv2 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: state change Ack-Rcvd --> Opened Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: phase shift ESTABLISH --> AUTHENTICATE Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: auth: peer wants CHAP, I want nothing Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: LayerUp Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CHAP: rec'd CHALLENGE #1 Mar 29 06:37:37 ST_CHARLES mpd: Name: "" Mar 29 06:37:37 ST_CHARLES mpd: Using authname "st.charles" Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CHAP: sending RESPONSE Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CHAP: rec'd SUCCESS #1 Mar 29 06:37:37 ST_CHARLES mpd: MESG: S=A77DDFF69B9B3D78EB6B9526BD0E88B0C77B71F8 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: authorization successful Mar 29 06:37:37 ST_CHARLES mpd: [vpn] LCP: phase shift AUTHENTICATE --> NETWORK Mar 29 06:37:37 ST_CHARLES mpd: [vpn] setting interface ng1 MTU to 1460 bytes Mar 29 06:37:37 ST_CHARLES mpd: [vpn] up: 1 link, total bandwidth 64000 bps Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: Up event Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: state change Starting --> Req-Sent Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: SendConfigReq #1 Mar 29 06:37:37 ST_CHARLES mpd: IPADDR 10.129.10.101 Mar 29 06:37:37 ST_CHARLES mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Open event Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: state change Initial --> Starting Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: LayerStart Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Up event Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: state change Starting --> Req-Sent Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #1 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are enabled -> yes Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Checking whether 56 bits are enabled -> no Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are enabled -> yes Mar 29 06:37:37 ST_CHARLES mpd: MPPC Mar 29 06:37:37 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: rec'd Configure Request #4 link 0 (Req-Sent) Mar 29 06:37:37 ST_CHARLES mpd: IPADDR 10.129.10.40 Mar 29 06:37:37 ST_CHARLES mpd: 10.129.10.40 is OK Mar 29 06:37:37 ST_CHARLES mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: SendConfigAck #4 Mar 29 06:37:37 ST_CHARLES mpd: IPADDR 10.129.10.40 Mar 29 06:37:37 ST_CHARLES mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: state change Req-Sent --> Ack-Sent Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #31 link 0 (Req-Sent) Mar 29 06:37:37 ST_CHARLES mpd: MPPC Mar 29 06:37:37 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are acceptable -> yes Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are acceptable -> yes Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #31 Mar 29 06:37:37 ST_CHARLES mpd: MPPC Mar 29 06:37:37 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: rec'd Configure Ack #1 link 0 (Ack-Sent) Mar 29 06:37:37 ST_CHARLES mpd: IPADDR 10.129.10.101 Mar 29 06:37:37 ST_CHARLES mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: state change Ack-Sent --> Opened Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: LayerUp Mar 29 06:37:37 ST_CHARLES mpd: 10.129.10.101 -> 10.129.10.40 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IFACE: Up event Mar 29 06:37:37 ST_CHARLES mpd: [vpn] setting interface ng1 MTU to 1458 bytes Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/ifconfig ng1 10.129.10.101 10.129.10.40 netmask 0xffffffff -link0 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.10.101 -iface lo0 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.10.0 10.129.10.40 -netmask 0xffffff00 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.30.0 10.129.10.40 -netmask 0xffffff00 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.40.0 10.129.10.40 -netmask 0xffffff00 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.50.0 10.129.10.40 -netmask 0xffffff00 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.60.0 10.129.10.40 -netmask 0xffffff00 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.70.0 10.129.10.40 -netmask 0xffffff00 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.128.10.0 10.129.10.40 -netmask 0xffffff00 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 192.0.0.0 10.129.10.40 -netmask 0xc0000000 Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 172.16.8.0 10.129.10.40 -netmask 0xfffff800 Mar 29 06:37:38 ST_CHARLES mpd: [vpn] exec: /etc/iface-up.sh ng1 inet 10.129.10.101 10.129.10.40 Mar 29 06:37:38 ST_CHARLES mpd: [vpn] IFACE: Up event Mar 29 06:37:38 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Nak #1 link 0 (Req-Sent) Mar 29 06:37:38 ST_CHARLES mpd: MPPC Mar 29 06:37:38 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:38 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #2 Mar 29 06:37:38 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are enabled -> no Mar 29 06:37:38 ST_CHARLES mpd: [vpn] CCP: Checking whether 56 bits are enabled -> no Mar 29 06:37:38 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are enabled -> yes Mar 29 06:37:38 ST_CHARLES mpd: MPPC Mar 29 06:37:38 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:38 ST_CHARLES mpd: [vpn] error writing len 14 frame to bypass: Resource deadlock avoided Mar 29 06:37:39 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #32 link 0 (Req-Sent) Mar 29 06:37:39 ST_CHARLES mpd: MPPC Mar 29 06:37:39 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 06:37:39 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are acceptable -> yes Mar 29 06:37:39 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are acceptable -> yes Mar 29 06:37:39 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #32 Mar 29 06:37:39 ST_CHARLES mpd: MPPC Mar 29 06:37:39 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:39 ST_CHARLES mpd: [vpn] error writing len 14 frame to bypass: Resource deadlock avoided Mar 29 06:37:40 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #3 Mar 29 06:37:40 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are enabled -> no Mar 29 06:37:40 ST_CHARLES mpd: [vpn] CCP: Checking whether 56 bits are enabled -> no Mar 29 06:37:40 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are enabled -> yes Mar 29 06:37:40 ST_CHARLES mpd: MPPC Mar 29 06:37:40 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:41 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #33 link 0 (Req-Sent) Mar 29 06:37:41 ST_CHARLES mpd: MPPC Mar 29 06:37:41 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 06:37:41 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are acceptable -> yes Mar 29 06:37:41 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are acceptable -> yes Mar 29 06:37:41 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #33 Mar 29 06:37:41 ST_CHARLES mpd: MPPC Mar 29 06:37:41 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:42 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #4 Mar 29 06:37:42 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are enabled -> no Mar 29 06:37:42 ST_CHARLES mpd: [vpn] CCP: Checking whether 56 bits are enabled -> no Mar 29 06:37:42 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are enabled -> yes Mar 29 06:37:42 ST_CHARLES mpd: MPPC Mar 29 06:37:42 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:43 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #34 link 0 (Req-Sent) Mar 29 06:37:43 ST_CHARLES mpd: MPPC Mar 29 06:37:43 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 06:37:43 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are acceptable -> yes Mar 29 06:37:43 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are acceptable -> yes Mar 29 06:37:43 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #34 Mar 29 06:37:43 ST_CHARLES mpd: MPPC Mar 29 06:37:43 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:44 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #5 Mar 29 06:37:44 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are enabled -> no Mar 29 06:37:44 ST_CHARLES mpd: [vpn] CCP: Checking whether 56 bits are enabled -> no Mar 29 06:37:44 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are enabled -> yes Mar 29 06:37:44 ST_CHARLES mpd: MPPC Mar 29 06:37:44 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:45 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #35 link 0 (Req-Sent) Mar 29 06:37:45 ST_CHARLES mpd: MPPC Mar 29 06:37:45 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 06:37:45 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are acceptable -> yes Mar 29 06:37:45 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are acceptable -> yes Mar 29 06:37:45 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #35 Mar 29 06:37:45 ST_CHARLES mpd: MPPC Mar 29 06:37:45 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:46 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #6 Mar 29 06:37:46 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are enabled -> no Mar 29 06:37:46 ST_CHARLES mpd: [vpn] CCP: Checking whether 56 bits are enabled -> no Mar 29 06:37:46 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are enabled -> yes Mar 29 06:37:46 ST_CHARLES mpd: MPPC Mar 29 06:37:46 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:48 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #36 link 0 (Req-Sent) Mar 29 06:37:48 ST_CHARLES mpd: MPPC Mar 29 06:37:48 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 06:37:48 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are acceptable -> yes Mar 29 06:37:48 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are acceptable -> yes Mar 29 06:37:48 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #36 Mar 29 06:37:48 ST_CHARLES mpd: MPPC Mar 29 06:37:48 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:48 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #7 Mar 29 06:37:48 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are enabled -> no Mar 29 06:37:48 ST_CHARLES mpd: [vpn] CCP: Checking whether 56 bits are enabled -> no Mar 29 06:37:48 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are enabled -> yes Mar 29 06:37:48 ST_CHARLES mpd: MPPC Mar 29 06:37:48 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:50 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #37 link 0 (Req-Sent) Mar 29 06:37:50 ST_CHARLES mpd: MPPC Mar 29 06:37:50 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 06:37:50 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are acceptable -> yes Mar 29 06:37:50 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are acceptable -> yes Mar 29 06:37:50 ST_CHARLES mpd: [vpn] CCP: SendConfigNak #37 Mar 29 06:37:50 ST_CHARLES mpd: MPPC Mar 29 06:37:50 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:50 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #8 Mar 29 06:37:50 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are enabled -> no Mar 29 06:37:50 ST_CHARLES mpd: [vpn] CCP: Checking whether 56 bits are enabled -> no Mar 29 06:37:50 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are enabled -> yes Mar 29 06:37:50 ST_CHARLES mpd: MPPC Mar 29 06:37:50 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:52 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #9 Mar 29 06:37:52 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are enabled -> no Mar 29 06:37:52 ST_CHARLES mpd: [vpn] CCP: Checking whether 56 bits are enabled -> no Mar 29 06:37:52 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are enabled -> yes Mar 29 06:37:52 ST_CHARLES mpd: MPPC Mar 29 06:37:52 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 06:37:54 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Request #39 link 0 (Req-Sent) Mar 29 06:37:54 ST_CHARLES mpd: MPPC Mar 29 06:37:54 ST_CHARLES mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 06:37:54 ST_CHARLES mpd: [vpn] CCP: Checking whether 40 bits are acceptable -> yes Mar 29 06:37:54 ST_CHARLES mpd: [vpn] CCP: Checking whether 128 bits are acceptable -> yes Mar 29 06:37:54 ST_CHARLES mpd: [vpn] CCP: not converging Mar 29 06:37:54 ST_CHARLES mpd: [vpn] CCP: parameter negotiation failed Mar 29 06:37:54 ST_CHARLES mpd: [vpn] CCP: Close event Mar 29 06:37:54 ST_CHARLES mpd: [vpn] CCP: state change Req-Sent --> Closing Mar 29 06:37:54 ST_CHARLES mpd: [vpn] CCP: SendTerminateReq #10 Mar 29 06:37:54 ST_CHARLES mpd: [vpn] CCP: state change Closing --> Closed Mar 29 06:37:54 ST_CHARLES mpd: [vpn] CCP: LayerFinish Mar 29 06:38:00 ST_CHARLES mpd: [vpn] LCP: rec'd Terminate Request #16 link 0 (Opened) Mar 29 06:38:00 ST_CHARLES mpd: [vpn] LCP: state change Opened --> Stopping Mar 29 06:38:00 ST_CHARLES mpd: [vpn] LCP: phase shift NETWORK --> TERMINATE Following is the mpd.conf file on the client side. ################################################################# # # MPD configuration file # # This file defines the configuration for mpd: what the # bundles are, what the links are in those bundles, how # the interface should be configured, various PPP parameters, # etc. It contains commands just as you would type them # in at the console. A blank line ends an entry. Lines # starting with a "#" are comments and get completely # ignored. # # $Id: mpd.conf.sample,v 1.9 2003/03/05 16:59:16 archie Exp $ # ################################################################# # # Default configuration is "myisp" default: # load PPPoE load vpn # # Mpd using PPTP for LAN to LAN VPN, always connected. # # Suppose you have a private Office LAN numbered 192.168.1.0/24 and another # remote private Office LAN numbered 192.168.2.0/24, and you wanted to route # between these two private networks using a PPTP VPN over the Internet. # # You run mpd on dual-homed machines on either end. Say the local machine # has internal address 192.168.1.1 and externally visible address 1.2.3.4, # and the remote machine has internal address 192.168.2.1 and externally # visible address 2.3.4.5. # # Note: mpd does not support the peer's "inside" IP address being the same # as its "outside" IP address. In the above example, this means that # 192.168.2.1 != 2.3.4.5. # # The "inside" IP addresses are configured by "set ipcp ranges ..." # (in mpd.conf) while the "outside" IP addreses are configured by # "set pptp self ..." and "set pptp peer ..." (in mpd.links). # # See also the 'vpn' link entry in mpd.links.sample. # vpn: new -i ng1 vpn vpn set iface disable proxy-arp set iface disable on-demand set iface up-script /etc/iface-up.sh set iface addrs 10.129.20.40 10.129.10.40 set iface idle 0 # set iface route default set iface route 10.129.10.0/24 set iface route 10.129.30.0/24 set iface route 10.129.40.0/24 set iface route 10.129.50.0/24 set iface route 10.129.60.0/24 set iface route 10.129.70.0/24 set iface route 10.128.10.0/24 set iface route 192.168.40.0/2 set iface route 172.16.8.0/21 set bundle disable multilink set bundle authname "XXXXXXXXXX" set bundle password "XXXXXXXXXX" set link yes acfcomp protocomp set link no pap set link disable chap set link mtu 1460 # set link mru 1492 # If remote machine is NT you need this.. # set link enable no-orig-auth set link keep-alive 10 75 set ipcp yes vjcomp set ipcp ranges 10.129.10.101/32 10.129.10.40/32 # # The five lines below enable Microsoft Point-to-Point encryption # (MPPE) using the ng_mppc(8) netgraph node type. # set bundle enable compression set bundle enable crypt-reqd set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless open # # PPPoE client example (see also mpd.links.sample entry "PPPoE") # PPPoE: new -i ng0 PPPoE PPPoE set iface disable proxy-arp set iface addrs 1.1.1.1 2.2.2.2 set iface up-script /etc/iface-up.sh set iface route default set iface disable on-demand set iface idle 0 set bundle disable multilink set bundle authname "XXXXXXX" set bundle password "XXXXXXX" set link no acfcomp protocomp set link disable pap chap set link accept chap set link mtu 1492 set ipcp yes vjcomp set ipcp ranges 0.0.0.0/0 0.0.0.0/0 open iface The log file from the server shows: Mar 29 07:28:04 MNEA-HQ mpd: mpd: PPTP connection from 69.29.37.57:2608 Mar 29 07:28:04 MNEA-HQ mpd: pptp1: attached to connection with 69.29.37.57:2608 Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] IFACE: Open event Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] IPCP: Open event Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] IPCP: state change Initial --> Starting Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] IPCP: LayerStart Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] IPCP: Open event Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] bundle: OPEN event in state CLOSED Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] opening link "pptp1"... Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] link: OPEN event Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: Open event Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: state change Initial --> Starting Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: LayerStart Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] device: OPEN event in state DOWN Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] attaching to peer's outgoing call Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] device is now in state OPENING Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] device: UP event in state OPENING Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] device is now in state UP Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] link: UP event Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] link: origination is remote Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: Up event Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: state change Starting --> Req-Sent Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: phase shift DEAD --> ESTABLISH Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: SendConfigReq #160 Mar 29 07:28:04 MNEA-HQ mpd: ACFCOMP Mar 29 07:28:04 MNEA-HQ mpd: PROTOCOMP Mar 29 07:28:04 MNEA-HQ mpd: MRU 1500 Mar 29 07:28:04 MNEA-HQ mpd: MAGICNUM a190cbac Mar 29 07:28:04 MNEA-HQ mpd: AUTHPROTO CHAP MSOFTv2 Mar 29 07:28:04 MNEA-HQ mpd: MP MRRU 1600 Mar 29 07:28:04 MNEA-HQ mpd: MP SHORTSEQ Mar 29 07:28:04 MNEA-HQ mpd: ENDPOINTDISC [802.1] 00 e0 b8 14 60 1f Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: rec'd Configure Request #1 link 0 (Req-Sent) Mar 29 07:28:04 MNEA-HQ mpd: ACFCOMP Mar 29 07:28:04 MNEA-HQ mpd: PROTOCOMP Mar 29 07:28:04 MNEA-HQ mpd: MRU 1500 Mar 29 07:28:04 MNEA-HQ mpd: MAGICNUM 98dacd74 Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: SendConfigAck #1 Mar 29 07:28:04 MNEA-HQ mpd: ACFCOMP Mar 29 07:28:04 MNEA-HQ mpd: PROTOCOMP Mar 29 07:28:04 MNEA-HQ mpd: MRU 1500 Mar 29 07:28:04 MNEA-HQ mpd: MAGICNUM 98dacd74 Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: state change Req-Sent --> Ack-Sent Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: rec'd Configure Reject #160 link 0 (Ack-Sent) Mar 29 07:28:04 MNEA-HQ mpd: MP MRRU 1600 Mar 29 07:28:04 MNEA-HQ mpd: MP SHORTSEQ Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: SendConfigReq #161 Mar 29 07:28:04 MNEA-HQ mpd: ACFCOMP Mar 29 07:28:04 MNEA-HQ mpd: PROTOCOMP Mar 29 07:28:04 MNEA-HQ mpd: MRU 1500 Mar 29 07:28:04 MNEA-HQ mpd: MAGICNUM a190cbac Mar 29 07:28:04 MNEA-HQ mpd: AUTHPROTO CHAP MSOFTv2 Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: rec'd Configure Ack #161 link 0 (Ack-Sent) Mar 29 07:28:04 MNEA-HQ mpd: ACFCOMP Mar 29 07:28:04 MNEA-HQ mpd: PROTOCOMP Mar 29 07:28:04 MNEA-HQ mpd: MRU 1500 Mar 29 07:28:04 MNEA-HQ mpd: MAGICNUM a190cbac Mar 29 07:28:04 MNEA-HQ mpd: AUTHPROTO CHAP MSOFTv2 Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: state change Ack-Sent --> Opened Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: phase shift ESTABLISH --> AUTHENTICATE Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: auth: peer wants nothing, I want CHAP Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] CHAP: sending CHALLENGE Mar 29 07:28:04 MNEA-HQ mpd: [pptp1] LCP: LayerUp Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CHAP: rec'd RESPONSE #1 Mar 29 07:28:05 MNEA-HQ mpd: Name: "st.charles" Mar 29 07:28:05 MNEA-HQ mpd: Peer name: "st.charles" Mar 29 07:28:05 MNEA-HQ mpd: Response is valid Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CHAP: sending SUCCESS Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] LCP: authorization successful Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] LCP: phase shift AUTHENTICATE --> NETWORK Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] setting interface ng1 MTU to 1460 bytes Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] up: 1 link, total bandwidth 64000 bps Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IPCP: Up event Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IPCP: state change Starting --> Req-Sent Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IPCP: SendConfigReq #54 Mar 29 07:28:05 MNEA-HQ mpd: IPADDR 10.129.10.40 Mar 29 07:28:05 MNEA-HQ mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: Open event Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: state change Initial --> Starting Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: LayerStart Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: Up event Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: state change Starting --> Req-Sent Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: SendConfigReq #133 Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are enabled -> yes Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: Checking whether 56 bits are enabled -> no Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are enabled -> yes Mar 29 07:28:05 MNEA-HQ mpd: MPPC Mar 29 07:28:05 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IPCP: rec'd Configure Request #1 link 0 (Req-Sent) Mar 29 07:28:05 MNEA-HQ mpd: IPADDR 10.129.10.101 Mar 29 07:28:05 MNEA-HQ mpd: 10.129.10.101 is OK Mar 29 07:28:05 MNEA-HQ mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IPCP: SendConfigAck #1 Mar 29 07:28:05 MNEA-HQ mpd: IPADDR 10.129.10.101 Mar 29 07:28:05 MNEA-HQ mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IPCP: state change Req-Sent --> Ack-Sent Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: rec'd Configure Request #1 link 0 (Req-Sent) Mar 29 07:28:05 MNEA-HQ mpd: MPPC Mar 29 07:28:05 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are acceptable -> yes Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are acceptable -> yes Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] CCP: SendConfigNak #1 Mar 29 07:28:05 MNEA-HQ mpd: MPPC Mar 29 07:28:05 MNEA-HQ mpd: 0x01000040: MPPE, 128 bit, stateless Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IPCP: rec'd Configure Ack #54 link 0 (Ack-Sent) Mar 29 07:28:05 MNEA-HQ mpd: IPADDR 10.129.10.40 Mar 29 07:28:05 MNEA-HQ mpd: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IPCP: state change Ack-Sent --> Opened Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IPCP: LayerUp Mar 29 07:28:05 MNEA-HQ mpd: 10.129.10.40 -> 10.129.10.101 Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IFACE: Up event Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] setting interface ng1 MTU to 1458 bytes Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] exec: /sbin/ifconfig ng1 10.129.10.40 10.129.10.101 netmask 0xffffffff -link0 Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] exec: /usr/sbin/arp -s 10.129.10.101 0:e0:b8:14:60:1f pub Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] exec: /sbin/route add 10.129.10.40 -iface lo0 Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] exec: /sbin/route add 10.129.20.0 10.129.10.101 -netmask 0xffffff00 Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] exec: /etc/iface-up.sh ng1 inet 10.129.10.40 10.129.10.101 st.charles Mar 29 07:28:05 MNEA-HQ mpd: [pptp1] IFACE: Up event Mar 29 07:28:07 MNEA-HQ mpd: [pptp1] CCP: SendConfigReq #134 Mar 29 07:28:07 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are enabled -> yes Mar 29 07:28:07 MNEA-HQ mpd: [pptp1] CCP: Checking whether 56 bits are enabled -> no Mar 29 07:28:07 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are enabled -> yes Mar 29 07:28:07 MNEA-HQ mpd: MPPC Mar 29 07:28:07 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:09 MNEA-HQ mpd: [pptp1] CCP: SendConfigReq #135 Mar 29 07:28:09 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are enabled -> yes Mar 29 07:28:09 MNEA-HQ mpd: [pptp1] CCP: Checking whether 56 bits are enabled -> no Mar 29 07:28:09 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are enabled -> yes Mar 29 07:28:09 MNEA-HQ mpd: MPPC Mar 29 07:28:09 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:11 MNEA-HQ mpd: [pptp1] CCP: SendConfigReq #136 Mar 29 07:28:11 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are enabled -> yes Mar 29 07:28:11 MNEA-HQ mpd: [pptp1] CCP: Checking whether 56 bits are enabled -> no Mar 29 07:28:11 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are enabled -> yes Mar 29 07:28:11 MNEA-HQ mpd: MPPC Mar 29 07:28:11 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:13 MNEA-HQ mpd: [pptp1] CCP: SendConfigReq #137 Mar 29 07:28:13 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are enabled -> yes Mar 29 07:28:13 MNEA-HQ mpd: [pptp1] CCP: Checking whether 56 bits are enabled -> no Mar 29 07:28:13 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are enabled -> yes Mar 29 07:28:13 MNEA-HQ mpd: MPPC Mar 29 07:28:13 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:15 MNEA-HQ mpd: [pptp1] CCP: SendConfigReq #138 Mar 29 07:28:15 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are enabled -> yes Mar 29 07:28:15 MNEA-HQ mpd: [pptp1] CCP: Checking whether 56 bits are enabled -> no Mar 29 07:28:15 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are enabled -> yes Mar 29 07:28:15 MNEA-HQ mpd: MPPC Mar 29 07:28:15 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:17 MNEA-HQ mpd: [pptp1] CCP: SendConfigReq #139 Mar 29 07:28:17 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are enabled -> yes Mar 29 07:28:17 MNEA-HQ mpd: [pptp1] CCP: Checking whether 56 bits are enabled -> no Mar 29 07:28:17 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are enabled -> yes Mar 29 07:28:17 MNEA-HQ mpd: MPPC Mar 29 07:28:17 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:19 MNEA-HQ mpd: [pptp1] CCP: SendConfigReq #140 Mar 29 07:28:19 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are enabled -> yes Mar 29 07:28:19 MNEA-HQ mpd: [pptp1] CCP: Checking whether 56 bits are enabled -> no Mar 29 07:28:19 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are enabled -> yes Mar 29 07:28:19 MNEA-HQ mpd: MPPC Mar 29 07:28:19 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:21 MNEA-HQ mpd: [pptp1] CCP: SendConfigReq #141 Mar 29 07:28:21 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are enabled -> yes Mar 29 07:28:21 MNEA-HQ mpd: [pptp1] CCP: Checking whether 56 bits are enabled -> no Mar 29 07:28:21 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are enabled -> yes Mar 29 07:28:21 MNEA-HQ mpd: MPPC Mar 29 07:28:21 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:23 MNEA-HQ mpd: [pptp1] CCP: SendConfigReq #142 Mar 29 07:28:23 MNEA-HQ mpd: [pptp1] CCP: Checking whether 40 bits are enabled -> yes Mar 29 07:28:23 MNEA-HQ mpd: [pptp1] CCP: Checking whether 56 bits are enabled -> no Mar 29 07:28:23 MNEA-HQ mpd: [pptp1] CCP: Checking whether 128 bits are enabled -> yes Mar 29 07:28:23 MNEA-HQ mpd: MPPC Mar 29 07:28:23 MNEA-HQ mpd: 0x01000060: MPPE, 40 bit, 128 bit, stateless Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: state change Req-Sent --> Stopped Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: LayerFinish Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: parameter negotiation failed Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: Close event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: state change Stopped --> Closed Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: encryption required, but MPPE was not negotiated in both directions Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: failed to negotiate required encryption Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: Close event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: LayerFinish Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IPCP: failed to negotiate required encryption Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IPCP: LayerFinish Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IPCP: LayerStart Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IPCP: state change Opened --> Starting Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IPCP: LayerDown Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IFACE: Down event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] exec: /sbin/route delete 10.129.20.0 10.129.10.101 -netmask 0xffffff00 Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] exec: /sbin/route delete 10.129.10.40 -iface lo0 Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] exec: /usr/sbin/arp -d 10.129.10.101 Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] exec: /sbin/ifconfig ng1 down delete -link0 Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: LayerFinish Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] bundle: CLOSE event in state OPENED Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] closing link "pptp1"... Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] bundle: OPEN event in state CLOSED Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] opening link "pptp1"... Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] link: CLOSE event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: Close event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: state change Opened --> Closing Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: phase shift NETWORK --> TERMINATE Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] setting interface ng1 MTU to 1500 bytes Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] up: 0 links, total bandwidth 9600 bps Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IPCP: Down event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: Down event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: state change Closed --> Initial Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] CCP: Close event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: SendTerminateReq #162 Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: LayerDown Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] link: OPEN event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: Open event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: state change Closing --> Stopping Mar 29 07:28:25 MNEA-HQ mpd: pptp1-0: call cleared by peer Mar 29 07:28:25 MNEA-HQ mpd: pptp1-0: killing channel Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] PPTP call terminated Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IFACE: Close event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IPCP: Close event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IPCP: state change Starting --> Initial Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IPCP: LayerFinish Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] IFACE: Close event Mar 29 07:28:25 MNEA-HQ mpd: pptp1: closing connection with 69.29.37.57:2608 Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] bundle: CLOSE event in state OPENED Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] closing link "pptp1"... Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] device: DOWN event in state UP Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] device is now in state DOWN Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] link: CLOSE event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: Close event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: state change Stopping --> Closing Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] link: DOWN event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: Down event Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: LayerFinish Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: state change Closing --> Initial Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] LCP: phase shift TERMINATE --> DEAD Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] device: CLOSE event in state DOWN Mar 29 07:28:25 MNEA-HQ mpd: [pptp1] device is now in state DOWN Mar 29 07:28:25 MNEA-HQ mpd: pptp1: killing connection with 69.29.37.57:2608 The configuration file from the server is as follows. default: load pptp0 load pptp1 pptp0: new -i ng0 pptp0 pptp0 set ipcp ranges 10.129.10.40/32 10.129.10.100/32 set iface route 10.128.10.0/24 set link disable chap set link mtu 1460 load client_standard pptp1: new -i ng1 pptp1 pptp1 set ipcp ranges 10.129.10.40/32 10.129.10.101/32 set iface route 10.129.20.0/24 set link disable chap set link mtu 1460 load client_standard client_standard: set iface up-script /etc/iface-up.sh set iface disable on-demand set iface enable proxy-arp # set iface idle 1800 # set link mtu 1458 set bundle enable multilink set bundle enable crypt-reqd set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 10.129.10.41 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless Thanks in advance for your assistance. Jay Michael Bretterklieber wrote: > Hi, > > On Sun, 28 Mar 2004, Jay Hall wrote: > >>OK, I think I have an MTU negotiation problem. The server side sets an >>MTU of 1458 and the client side sets an MTU of 1456. Occassionally, the >>MTUs on the client and the server will be the same and then the >>connection comes up and runs like a champ as long as the MTU is 1456. >>Any other values, even if they are the same on the client and server end >>result in a connection that comes up and then drops. >> >>Both the client and the server contain the line >> >>set link mtu 1460 >> >>Mar 27 00:22:52 ST_CHARLES mpd: [vpn] CCP: rec'd Configure Nak #1 link 0 >>(Req-Sent) >>Mar 27 00:22:52 ST_CHARLES mpd: MPPC >>Mar 27 00:22:52 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless >>Mar 27 00:22:52 ST_CHARLES mpd: [vpn] CCP: SendConfigReq #2 >>Mar 27 00:22:52 ST_CHARLES mpd: MPPC >>Mar 27 00:22:52 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless >>Mar 27 00:22:52 ST_CHARLES mpd: [vpn] error writing len 14 frame to >>bypass: No route to host > > > there is a problem with the underlaying connection, could you please post > the whole log, from the beginning of the connection. > > the value of 1456 is ok, because Mpd takes the ppp-header into account, > wich has usually 4 bytes. > > bye, > -- > ------------------------------- ---------------------------------- > Michael Bretterklieber - http://www.bretterklieber.com > A-Quadrat Automation GmbH - http://www.a-quadrat.at > Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 > ------------------------------- ---------------------------------- > "...the number of UNIX installations has grown to 10, with more > expected..." - Dennis Ritchie and Ken Thompson, June 1972 > > From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 09:36:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0279516A4CE; Mon, 29 Mar 2004 09:36:52 -0800 (PST) Received: from bes.amduat.net (bes.amduat.net [206.124.149.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8804643D48; Mon, 29 Mar 2004 09:36:51 -0800 (PST) (envelope-from jbarrett@amduat.net) Received: from osiris.amduat.net ([63.115.16.66]) (AUTH: LOGIN jbarrett, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by bes.amduat.net with esmtp; Mon, 29 Mar 2004 09:36:50 -0800 From: "Jacob S. Barrett" To: Ruslan Ermilov Date: Mon, 29 Mar 2004 09:36:49 -0800 User-Agent: KMail/1.6.1 References: <200403251118.40718.jbarrett@amduat.net> <200403270848.37996.jbarrett@amduat.net> <20040329081224.GC70021@ip.net.ua> In-Reply-To: <20040329081224.GC70021@ip.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403290936.49345.jbarrett@amduat.net> cc: freebsd-net@FreeBSD.org Subject: Re: Disabling VLAN_HWTAGGING 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, 29 Mar 2004 17:36:52 -0000 On Monday 29 March 2004 12:12 am, Ruslan Ermilov wrote: > No, this is not of course expected. Can you add some debug printfs > in the ng_vlan.c:ng_vlan_rcvdata() and see if it ever receives the > VLAN tag, and if so, print its value (perhaps the tag is entered by > a driver in a network byte order). Bingo... I will dig around in if_nge.c to figure out where to swap the bytes. > Well, for IP/TCP/UDP checksumming, it's possible to switch the > corresponding bit in the interface's enabled capabilities field. > OTOH, switching VLAN stripping on/off requires reprogramming of > the hardware. > > Generally, if the hardware supports IP/TCP/UDP checksumming and > or VLAN tag removal/insertion, it's better to use it. We'd > better find the root of the problem and fix it. ;) I agree, so now that we have found it I will try to fix it. Thanks for your help. -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 09:56:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B16BD16A4CE; Mon, 29 Mar 2004 09:56:15 -0800 (PST) Received: from mail.dti.supsi.ch (mail.die.supsi.ch [193.5.153.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50F0E43D1F; Mon, 29 Mar 2004 09:56:14 -0800 (PST) (envelope-from roberto.nunnari@supsi.ch) Received: from supsi.ch (pcm2027.dti.supsi.ch [193.5.152.27]) by mail.dti.supsi.ch (8.11.6/8.11.6) with ESMTP id i2THu7v08434; Mon, 29 Mar 2004 19:56:07 +0200 Message-ID: <406863B8.7010504@supsi.ch> Date: Mon, 29 Mar 2004 19:58:16 +0200 From: Roberto Nunnari User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jacob S. Barrett" References: <200403251118.40718.jbarrett@amduat.net> <200403270848.37996.jbarrett@amduat.net> <20040329081224.GC70021@ip.net.ua> <200403290936.49345.jbarrett@amduat.net> In-Reply-To: <200403290936.49345.jbarrett@amduat.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Disabling VLAN_HWTAGGING 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, 29 Mar 2004 17:56:15 -0000 Hello. Jacob S. Barrett wrote: > On Monday 29 March 2004 12:12 am, Ruslan Ermilov wrote: > >>No, this is not of course expected. Can you add some debug printfs >>in the ng_vlan.c:ng_vlan_rcvdata() and see if it ever receives the >>VLAN tag, and if so, print its value (perhaps the tag is entered by >>a driver in a network byte order). > > > Bingo... I will dig around in if_nge.c to figure out where to swap the bytes. > > >>Well, for IP/TCP/UDP checksumming, it's possible to switch the >>corresponding bit in the interface's enabled capabilities field. >>OTOH, switching VLAN stripping on/off requires reprogramming of >>the hardware. >> >>Generally, if the hardware supports IP/TCP/UDP checksumming and >>or VLAN tag removal/insertion, it's better to use it. We'd >>better find the root of the problem and fix it. ;) > > > I agree, so now that we have found it I will try to fix it. Thanks for your > help. > Do you believe this may also be the root cause of my fatal trap 12 I'm experiencing? see my posts with subject: Fatal trap in rt_msg2 Best regards. -- Roberto Nunnari -software engineer- mailto:roberto.nunnari@supsi.ch Scuola Universitaria Professionale della Svizzera Italiana Dipartimento Tecnologie Innovative http://www.dti.supsi.ch SUPSI-DTI Via Cantonale tel: +41-91-6108561 6928 Manno """ fax: +41-91-6108570 Switzerland (o o) =======================oOO==(_)==OOo======================== From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 10:22:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7069F16A4CE; Mon, 29 Mar 2004 10:22:27 -0800 (PST) Received: from sizone.org (mortar.sizone.org [65.126.154.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48D8243D1F; Mon, 29 Mar 2004 10:22:27 -0800 (PST) (envelope-from dgilbert@daveg.ca) Received: by sizone.org (Postfix, from userid 66) id 83D3E308A5; Mon, 29 Mar 2004 13:22:26 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 040DF1D2669; Mon, 29 Mar 2004 13:22:24 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16488.26976.314273.752771@canoe.dclg.ca> Date: Mon, 29 Mar 2004 13:22:24 -0500 To: "Jacob S. Barrett" In-Reply-To: <200403251650.35714.jbarrett@amduat.net> References: <200403251118.40718.jbarrett@amduat.net> <20040325234527.GC85417@ip.net.ua> <200403251650.35714.jbarrett@amduat.net> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid cc: freebsd-net@freebsd.org Subject: Re: Disabling VLAN_HWTAGGING 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, 29 Mar 2004 18:22:27 -0000 >>>>> "Jacob" == Jacob S Barrett writes: Jacob> On Thursday 25 March 2004 03:45 pm, you wrote: >> > Can you disable VLAN_HWTAGGING? >> >> Not without modifying if_nge.c, but it should be pretty trivial. Jacob> As trivial as setting chaning: ifp-> if_capabilities = IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING; Jacob> to: ifp-> if_capabilities = 0; Jacob> This didn't solve the problem completely though. On the remote Jacob> host I can now see tagged frames from the if_nge host, but the Jacob> reply frames from the if_em host or not visible at all on the Jacob> if_nge host (via tcpdump). Are you dumping all packets? We've found that you can dump a specific vlan on nge's, but you can't get good data by dumping the raw port itself. No matter how it's set, in both Linux and FreeBSD, many nge chipsets will not show vlan packets from the driver with a tcpdump. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 10:39:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84BD616A4CE for ; Mon, 29 Mar 2004 10:39:03 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FC9C43D2D for ; Mon, 29 Mar 2004 10:39:02 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i2TIgGAZ000824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Mar 2004 21:42:18 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2TIctEW074061; Mon, 29 Mar 2004 21:38:55 +0300 (EEST) (envelope-from ru) Date: Mon, 29 Mar 2004 21:38:54 +0300 From: Ruslan Ermilov To: David Gilbert Message-ID: <20040329183854.GC73842@ip.net.ua> References: <200403251118.40718.jbarrett@amduat.net> <20040325234527.GC85417@ip.net.ua> <200403251650.35714.jbarrett@amduat.net> <16488.26976.314273.752771@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jousvV0MzM2p6OtC" Content-Disposition: inline In-Reply-To: <16488.26976.314273.752771@canoe.dclg.ca> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@freebsd.org Subject: Re: Disabling VLAN_HWTAGGING 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, 29 Mar 2004 18:39:03 -0000 --jousvV0MzM2p6OtC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 29, 2004 at 01:22:24PM -0500, David Gilbert wrote: > >>>>> "Jacob" =3D=3D Jacob S Barrett writes: >=20 > Jacob> On Thursday 25 March 2004 03:45 pm, you wrote: > >> > Can you disable VLAN_HWTAGGING? > >>=20 > >> Not without modifying if_nge.c, but it should be pretty trivial. >=20 > Jacob> As trivial as setting chaning: > ifp-> if_capabilities =3D IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING; > Jacob> to: > ifp-> if_capabilities =3D 0; >=20 > Jacob> This didn't solve the problem completely though. On the remote > Jacob> host I can now see tagged frames from the if_nge host, but the > Jacob> reply frames from the if_em host or not visible at all on the > Jacob> if_nge host (via tcpdump). >=20 > Are you dumping all packets? We've found that you can dump a specific > vlan on nge's, but you can't get good data by dumping the raw port > itself. No matter how it's set, in both Linux and FreeBSD, many nge > chipsets will not show vlan packets from the driver with a tcpdump. >=20 Hmm, you can't probably see it because the hardware is configured to do VLAN tag insertion/removal, and stores VLAN data decoupled from the frame's mbuf chain. And BPF is very unlikely to reconstruct the ETHERTYPE_VLAN packet using this information... Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --jousvV0MzM2p6OtC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaG0+Ukv4P6juNwoRAvV/AJ41Nb0ekfQcASKwykLPO6RlEuabzACeKEnp KjP3bN5aRLuiXbQAFzz2Gkk= =k7o0 -----END PGP SIGNATURE----- --jousvV0MzM2p6OtC-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 11:01:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5067316A4CE for ; Mon, 29 Mar 2004 11:01:39 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3356543D2D for ; Mon, 29 Mar 2004 11:01:39 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i2TJ1dbv083785 for ; Mon, 29 Mar 2004 11:01:39 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2TJ1ca2083779 for freebsd-net@freebsd.org; Mon, 29 Mar 2004 11:01:38 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 29 Mar 2004 11:01:38 -0800 (PST) Message-Id: <200403291901.i2TJ1ca2083779@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 19:01:39 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 11:16:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 293F816A4CE for ; Mon, 29 Mar 2004 11:16:07 -0800 (PST) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 702E043D46 for ; Mon, 29 Mar 2004 11:16:06 -0800 (PST) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-216-100-132-94.dsl.snfc21.pacbell.net [216.100.132.94])i2TJFqGa142248; Mon, 29 Mar 2004 14:15:58 -0500 Message-ID: <4068757B.4000009@elischer.org> Date: Mon, 29 Mar 2004 11:14:03 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: David Gilbert References: <200403251118.40718.jbarrett@amduat.net> <20040325234527.GC85417@ip.net.ua> <200403251650.35714.jbarrett@amduat.net> <16488.26976.314273.752771@canoe.dclg.ca> In-Reply-To: <16488.26976.314273.752771@canoe.dclg.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Disabling VLAN_HWTAGGING 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, 29 Mar 2004 19:16:07 -0000 > itself. No matter how it's set, in both Linux and FreeBSD, many nge > chipsets will not show vlan packets from the driver with a tcpdump. netgraph interception? -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 12:03:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19B0516A4CE for ; Mon, 29 Mar 2004 12:03:19 -0800 (PST) Received: from sizone.org (mortar.sizone.org [65.126.154.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id D59BB43D1D for ; Mon, 29 Mar 2004 12:03:18 -0800 (PST) (envelope-from dgilbert@daveg.ca) Received: by sizone.org (Postfix, from userid 66) id 6D633308B0; Mon, 29 Mar 2004 15:03:18 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 1F6CA1D2664; Mon, 29 Mar 2004 15:03:17 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16488.33020.907107.289101@canoe.dclg.ca> Date: Mon, 29 Mar 2004 15:03:08 -0500 To: Julian Elischer In-Reply-To: <4068757B.4000009@elischer.org> References: <200403251118.40718.jbarrett@amduat.net> <20040325234527.GC85417@ip.net.ua> <200403251650.35714.jbarrett@amduat.net> <16488.26976.314273.752771@canoe.dclg.ca> <4068757B.4000009@elischer.org> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid cc: freebsd-net@freebsd.org cc: David Gilbert Subject: Re: Disabling VLAN_HWTAGGING 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, 29 Mar 2004 20:03:19 -0000 >>>>> "Julian" == Julian Elischer writes: >> itself. No matter how it's set, in both Linux and FreeBSD, many >> nge chipsets will not show vlan packets from the driver with a >> tcpdump. Julian> netgraph interception? I don't understand the question. If you have a vlan on nge0, and you tcpdump the vlan interface, you get what you expect. If you tcpdump the nge0 interface, you get all the packets from all the vlans without vlan tags to differentiate. The FreeBSD and Linux drivers share this behaviour. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 12:05:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D46B16A4CE for ; Mon, 29 Mar 2004 12:05:31 -0800 (PST) Received: from sizone.org (mortar.sizone.org [65.126.154.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7354043D1F for ; Mon, 29 Mar 2004 12:05:31 -0800 (PST) (envelope-from dgilbert@daveg.ca) Received: by sizone.org (Postfix, from userid 66) id 1801F308B0; Mon, 29 Mar 2004 15:05:31 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 07C901D2669; Mon, 29 Mar 2004 15:05:30 -0500 (EST) Resent-Message-ID: <16488.33161.497754.550154@canoe.dclg.ca> Resent-Date: Mon, 29 Mar 2004 15:05:29 -0500 Resent-To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16488.33132.640236.689635@canoe.dclg.ca> In-Reply-To: <20040329183854.GC73842@ip.net.ua> References: <200403251118.40718.jbarrett@amduat.net> <20040325234527.GC85417@ip.net.ua> <200403251650.35714.jbarrett@amduat.net> <16488.26976.314273.752771@canoe.dclg.ca> <20040329183854.GC73842@ip.net.ua> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid From: David Gilbert To: Ruslan Ermilov Date: Mon, 29 Mar 2004 15:05:00 -0500 Resent-From: dgilbert@daveg.ca (David Gilbert) Subject: Re: Disabling VLAN_HWTAGGING 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, 29 Mar 2004 20:05:31 -0000 >>>>> "Ruslan" == Ruslan Ermilov writes: Ruslan> Hmm, you can't probably see it because the hardware is Ruslan> configured to do VLAN tag insertion/removal, and stores VLAN Ruslan> data decoupled from the frame's mbuf chain. And BPF is very Ruslan> unlikely to reconstruct the ETHERTYPE_VLAN packet using this Ruslan> information... This may entirely be, but it makes debugging awfully hard. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 13:06:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34AFB16A4CE for ; Mon, 29 Mar 2004 13:06:03 -0800 (PST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AD4A43D48 for ; Mon, 29 Mar 2004 13:06:03 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <20040329210556015007p1m3e>; Mon, 29 Mar 2004 21:06:02 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA29792; Mon, 29 Mar 2004 13:14:48 -0800 (PST) Date: Mon, 29 Mar 2004 13:14:46 -0800 (PST) From: Julian Elischer To: David Gilbert In-Reply-To: <16488.33020.907107.289101@canoe.dclg.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Disabling VLAN_HWTAGGING 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, 29 Mar 2004 21:06:03 -0000 On Mon, 29 Mar 2004, David Gilbert wrote: > >>>>> "Julian" == Julian Elischer writes: > > >> itself. No matter how it's set, in both Linux and FreeBSD, many > >> nge chipsets will not show vlan packets from the driver with a > >> tcpdump. > > Julian> netgraph interception? > > I don't understand the question. If you have a vlan on nge0, and you > tcpdump the vlan interface, you get what you expect. If you tcpdump > the nge0 interface, you get all the packets from all the vlans without > vlan tags to differentiate. The FreeBSD and Linux drivers share this > behaviour. I was just pointing out that if tcpdump seems to not catch some things you can also try netgraph interception.. But apparently from what you say it's not needed. > > Dave. > > -- > ============================================================================ > |David Gilbert, Independent Contractor. | Two things can only be | > |Mail: dave@daveg.ca | equal if and only if they | > |http://daveg.ca | are precisely opposite. | > =========================================================GLO================ > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Mar 29 13:41:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77E1316A4CE for ; Mon, 29 Mar 2004 13:41:01 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 556F243D45 for ; Mon, 29 Mar 2004 13:41:01 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-67-169-127-171.client.comcast.net[67.169.127.171]) by comcast.net (rwcrmhc12) with ESMTP id <20040329214100014007cj2ae>; Mon, 29 Mar 2004 21:41:00 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i2TLex0m009062; Mon, 29 Mar 2004 13:40:59 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i2TLewMI009061; Mon, 29 Mar 2004 13:40:58 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Mon, 29 Mar 2004 13:40:58 -0800 From: "Crist J. Clark" To: Cyrill R?ttimann Message-ID: <20040329214057.GA8711@blossom.cjclark.org> References: <257C203C-8104-11D8-9902-00039303AB38@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <257C203C-8104-11D8-9902-00039303AB38@mac.com> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org Subject: Re: IPSec troubles 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: Mon, 29 Mar 2004 21:41:01 -0000 On Mon, Mar 29, 2004 at 12:06:21AM +0200, Cyrill R?ttimann wrote: > Hello, > > I have troubles setting up an IPSec Host-to-Host connection between > FreeBSD 5.2.1 and MacOS X 10.3.3: Last I knew, 5.2.1 still had broken IPsec. Specifically, the system tries to apply the IPsec policy to the IKE traffic giving us a chicken and egg problem. The Mac end timing out waiting to hear from the FreeBSD system is consistent with this. Run 'tcpdump -n port 500' on the FreeBSD system and watch for outgoing traffic, and have a look at 'netstat -sp ipsec' and see if the 'outbound packets with no SA available' count is increasing. The workaround was to not use IPSEC in the kernel, but FAST_IPSEC. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 00:09:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 562E616A4CE for ; Tue, 30 Mar 2004 00:09:35 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0EF843D41 for ; Tue, 30 Mar 2004 00:09:33 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i2U8CqDb010018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2004 11:12:53 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2U89SY5091910; Tue, 30 Mar 2004 11:09:28 +0300 (EEST) (envelope-from ru) Date: Tue, 30 Mar 2004 11:09:27 +0300 From: Ruslan Ermilov To: Julian Elischer Message-ID: <20040330080927.GB91501@ip.net.ua> References: <16488.33020.907107.289101@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@freebsd.org cc: David Gilbert Subject: Re: Disabling VLAN_HWTAGGING 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, 30 Mar 2004 08:09:35 -0000 --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 29, 2004 at 01:14:46PM -0800, Julian Elischer wrote: >=20 >=20 > On Mon, 29 Mar 2004, David Gilbert wrote: >=20 > > >>>>> "Julian" =3D=3D Julian Elischer writes: > >=20 > > >> itself. No matter how it's set, in both Linux and FreeBSD, many > > >> nge chipsets will not show vlan packets from the driver with a > > >> tcpdump. > >=20 > > Julian> netgraph interception? > >=20 > > I don't understand the question. If you have a vlan on nge0, and you > > tcpdump the vlan interface, you get what you expect. If you tcpdump > > the nge0 interface, you get all the packets from all the vlans without > > vlan tags to differentiate. The FreeBSD and Linux drivers share this > > behaviour. >=20 > I was just pointing out that if tcpdump seems to not catch some things > you can also try netgraph interception.. > But apparently from what you say it's not needed. >=20 This is more convoluted than it seems. In 4.x, if the interface supports VLAN stripping in firmware, the driver calls if_vlan.c:vlan_input_tag() which "fakes up" a normal VLAN header and passes it to BPF for inspection. OTOH, vlan_input_tag() also searches through the list of all vlan(4) interfaces attempting to find an interface with the matching VLAN tag, so ng_vlan(4) doesn't have a chance of working in RELENG_4 for NIC drivers that support stripping VLAN tags in firmware. In 5.x, drivers always call ether_input() which has proper hooks into Netgraph (so ng_vlan(4) always works), but it doesn't "fake up" the VLAN header as vlan_input_tag() does in RELENG_4, so you cannot see the original VLAN packet -- you see the VLAN-stripped packet on the parent interface (I will look into fixing it later)! In any case, you cannot see the "normal" VLAN packet with tcpdump(1) on originating host that does the VLAN insertion in firmware. (You need to set the IFF_LINK0 flag on the vlan(4) interface in RELENG_4 to tell it that the parent device supports VLAN insertion in firmware.) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaSs3Ukv4P6juNwoRAiXwAJ9glne98xMY/qdQ9lrqjDojOPVcdACcCy8u x7gK5ids5We1d4VjIq0cYhg= =htu0 -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 02:32:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E05316A4CE for ; Tue, 30 Mar 2004 02:32:56 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86CE043D49 for ; Tue, 30 Mar 2004 02:32:55 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i2UAaHWs012417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2004 13:36:18 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2UAWqV2092909; Tue, 30 Mar 2004 13:32:52 +0300 (EEST) (envelope-from ru) Date: Tue, 30 Mar 2004 13:32:51 +0300 From: Ruslan Ermilov To: "Jacob S. Barrett" Message-ID: <20040330103251.GA92824@ip.net.ua> References: <200403251118.40718.jbarrett@amduat.net> <200403270848.37996.jbarrett@amduat.net> <20040329081224.GC70021@ip.net.ua> <200403290936.49345.jbarrett@amduat.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <200403290936.49345.jbarrett@amduat.net> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@freebsd.org Subject: Re: Disabling VLAN_HWTAGGING 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, 30 Mar 2004 10:32:56 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 29, 2004 at 09:36:49AM -0800, Jacob S. Barrett wrote: > On Monday 29 March 2004 12:12 am, Ruslan Ermilov wrote: > > No, this is not of course expected. Can you add some debug printfs > > in the ng_vlan.c:ng_vlan_rcvdata() and see if it ever receives the > > VLAN tag, and if so, print its value (perhaps the tag is entered by > > a driver in a network byte order). >=20 > Bingo... I will dig around in if_nge.c to figure out where to swap the by= tes. >=20 > > Well, for IP/TCP/UDP checksumming, it's possible to switch the > > corresponding bit in the interface's enabled capabilities field. > > OTOH, switching VLAN stripping on/off requires reprogramming of > > the hardware. > > > > Generally, if the hardware supports IP/TCP/UDP checksumming and > > or VLAN tag removal/insertion, it's better to use it. We'd > > better find the root of the problem and fix it. ;) >=20 > I agree, so now that we have found it I will try to fix it. Thanks for y= our=20 > help. >=20 OK. After configuring our GigE switch to pass the VLAN packets unstripped, I've been able to reproduce this problem on 4.x too. So I've just committed a fix for this into HEAD, please test it: $FreeBSD: src/sys/dev/nge/if_nge.c,v 1.55 2004/03/30 10:24:52 ru Exp $ The DP8382[01] data sheets are not very specific about the issue, and most probably, the initial VLAN support has been tested between two nge(4) cards, so the problem didn't manifest itself until now. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaUzTUkv4P6juNwoRAswcAJ9HkcSi1IYQkb3NW25Z66rWehSB4wCePBMP jPqkpaMR+0PJmmxYzPPKFhM= =qiXi -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 03:30:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E84C416A4CF; Tue, 30 Mar 2004 03:30:09 -0800 (PST) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id B40A643D5A; Tue, 30 Mar 2004 03:30:09 -0800 (PST) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id D7A071FF931; Tue, 30 Mar 2004 13:30:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id DFDD41FF91D; Tue, 30 Mar 2004 13:30:06 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 6FEC5154E3; Tue, 30 Mar 2004 11:22:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 65618153AA; Tue, 30 Mar 2004 11:22:08 +0000 (UTC) Date: Tue, 30 Mar 2004 11:22:08 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: "Crist J. Clark" In-Reply-To: <20040329214057.GA8711@blossom.cjclark.org> Message-ID: References: <257C203C-8104-11D8-9902-00039303AB38@mac.com> <20040329214057.GA8711@blossom.cjclark.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-net@freebsd.org Subject: Re: IPSec troubles 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, 30 Mar 2004 11:30:10 -0000 On Mon, 29 Mar 2004, Crist J. Clark wrote: > > I have troubles setting up an IPSec Host-to-Host connection between > > FreeBSD 5.2.1 and MacOS X 10.3.3: > > Last I knew, 5.2.1 still had broken IPsec. Specifically, the system > tries to apply the IPsec policy to the IKE traffic giving us a chicken > and egg problem. you can "exclude" IKE traffic in the SPD manually. I am still unsure if this IS a bug. Would need to go through RFCs in detail. Just skipped through 2401 and what I have found is: In host systems, applications MAY be allowed to select what security processing is to be applied to the traffic they generate and consume. and The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. So if I get the problem right racoon is unable to tell the kernel that it's traffic should 'bypass' IPSec processing ? If this is the remaining problem apart from the yet known (where KAME people cannot find the time to review at the moment) I may look into this; have setup my wireless connection on a 5.2.1 notebook (being updated to HEAD soon) to use IPSec lately so I have a 'testbed' now. -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 03:58:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38E9216A4CE for ; Tue, 30 Mar 2004 03:58:54 -0800 (PST) Received: from mail.datazug.ch (mail201.datazug.ch [212.4.65.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D22743D55 for ; Tue, 30 Mar 2004 03:58:53 -0800 (PST) (envelope-from ruettimac@mac.com) Received: from [192.168.0.10] [212.4.89.37] by mail.datazug.ch with ESMTP (SMTPD32-8.05) id A0D823F901E4; Tue, 30 Mar 2004 13:58:16 +0200 In-Reply-To: References: <257C203C-8104-11D8-9902-00039303AB38@mac.com> <20040329214057.GA8711@blossom.cjclark.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87BC9FE1-8241-11D8-9782-00039303AB38@mac.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Cyrill_R=FCttimann?= Date: Tue, 30 Mar 2004 13:58:16 +0200 To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.613) cc: freebsd-net@freebsd.org Subject: Re: IPSec troubles 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, 30 Mar 2004 11:58:54 -0000 Hello, > If this is the remaining problem apart from the yet known (where KAME > people cannot find the time to review at the moment) I may look into > this; have setup my wireless connection on a 5.2.1 notebook (being > updated to HEAD soon) to use IPSec lately so I have a 'testbed' now. Please can you report if IPSec is working with current or the latest stable? With 5.2.1, you are lost completely. IPSec with kernel options do not work and if you enable FAST_IPSEC (which should work), you end up not able to compile the kernel. There was a patch mentioned to solve this, but for me it did not work. Regards, Cyrill From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 04:35:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE5FF16A4CE for ; Tue, 30 Mar 2004 04:35:06 -0800 (PST) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59FA943D1F for ; Tue, 30 Mar 2004 04:35:06 -0800 (PST) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id D50571FF931; Tue, 30 Mar 2004 14:35:04 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id D7B601FF91D; Tue, 30 Mar 2004 14:35:02 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 7E788154E3; Tue, 30 Mar 2004 12:33:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 73DE9153AA; Tue, 30 Mar 2004 12:33:08 +0000 (UTC) Date: Tue, 30 Mar 2004 12:33:08 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: =?ISO-8859-1?Q?Cyrill_R=FCttimann?= In-Reply-To: <87BC9FE1-8241-11D8-9782-00039303AB38@mac.com> Message-ID: References: <257C203C-8104-11D8-9902-00039303AB38@mac.com> <87BC9FE1-8241-11D8-9782-00039303AB38@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-net@freebsd.org Subject: Re: IPSec troubles 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, 30 Mar 2004 12:35:07 -0000 On Tue, 30 Mar 2004, Cyrill R=FCttimann wrote: Hi, > > If this is the remaining problem apart from the yet known (where KAME > > people cannot find the time to review at the moment) I may look into > > this; have setup my wireless connection on a 5.2.1 notebook (being > > updated to HEAD soon) to use IPSec lately so I have a 'testbed' now. > > Please can you report if IPSec is working with current or the latest > stable? > > With 5.2.1, you are lost completely. IPSec with kernel options do not > work and if you enable FAST_IPSEC (which should work), you end up not > able to compile the kernel. There was a patch mentioned to solve this, > but for me it did not work. I have been able to use IPSEC (do not know about FAST_IPSEC) with 5.2.1R miniinst installation on following setup: notebook(wi0) <---> AP(bridge) <----> (fxp2)router I am now on a 5.2.1R with a private kernel incooperated some of my IPSEC related patches from HEAD (not all) and it also works. What I had to do had been "excluding IKE traffic" by doing s.th. like this (router side config): spdadd ROUTER[500] NOTEBOOK[500] udp -P out none ; spdadd NOTEBOOK[500] ROUTER[500] udp -P in none ; This for sure is not the most nifty way to do but it works. --=20 Greetings Bjoern A. Zeeb=09=09=09=09bzeeb at Zabbadoz dot NeT 56 69 73 69 74=09=09=09=09http://www.zabbadoz.net/ From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 05:02:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC4EA16A4CF for ; Tue, 30 Mar 2004 05:02:41 -0800 (PST) Received: from cheer.mahoroba.org (flets19-094.kamome.or.jp [218.45.19.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FA1643D1D for ; Tue, 30 Mar 2004 05:02:41 -0800 (PST) (envelope-from ume@FreeBSD.org) Received: from localhost (IDENT:BAlfI/Ib+QqtmNbgT1Q6h5/Rsl8I//q1f773m3J7xlmaXhR0dIlR5zZIXfB53q3e@localhost [IPv6:::1]) (user=ume mech=CRAM-MD5 bits=0)i2UD375m092462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2004 22:03:10 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Tue, 30 Mar 2004 22:03:07 +0900 Message-ID: From: Hajimu UMEMOTO To: "Bjoern A. Zeeb" In-Reply-To: References: <257C203C-8104-11D8-9902-00039303AB38@mac.com> <87BC9FE1-8241-11D8-9782-00039303AB38@mac.com> User-Agent: xcite1.38> Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.9-RELEASE-p4 MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cheer.mahoroba.org cc: freebsd-net@freebsd.org cc: Cyrill =?ISO-8859-1?Q?R=FCttimann?= Subject: Re: IPSec troubles 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, 30 Mar 2004 13:02:42 -0000 Hi, >>>>> On Tue, 30 Mar 2004 12:33:08 +0000 (UTC) >>>>> "Bjoern A. Zeeb" said: bzeeb> What I had to do had been "excluding IKE traffic" by doing s.th. bzeeb> like this (router side config): bzeeb> spdadd ROUTER[500] NOTEBOOK[500] udp bzeeb> -P out none ; bzeeb> spdadd NOTEBOOK[500] ROUTER[500] udp bzeeb> -P in none ; bzeeb> This for sure is not the most nifty way to do but it works. The per socket security policy is broken under 5.2.1-RELEASE, and it was fixed in 5-CURRENT. Racoon uses it to exclude IKE packets from target of IPsec. So, the bzeeb's way should work for workaround. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 05:20:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89FDF16A4CF; Tue, 30 Mar 2004 05:20:09 -0800 (PST) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52FF543D2D; Tue, 30 Mar 2004 05:20:09 -0800 (PST) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 480101FF931; Tue, 30 Mar 2004 15:20:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 4BC991FF91D; Tue, 30 Mar 2004 15:20:06 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id A4F3B154E3; Tue, 30 Mar 2004 13:15:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9A98C153AA; Tue, 30 Mar 2004 13:15:34 +0000 (UTC) Date: Tue, 30 Mar 2004 13:15:34 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Hajimu UMEMOTO In-Reply-To: Message-ID: References: <257C203C-8104-11D8-9902-00039303AB38@mac.com> <87BC9FE1-8241-11D8-9782-00039303AB38@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-net@freebsd.org cc: =?ISO-8859-1?Q?Cyrill_R=FCttimann?= Subject: Re: IPSec troubles 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, 30 Mar 2004 13:20:09 -0000 On Tue, 30 Mar 2004, Hajimu UMEMOTO wrote: Hi, > >>>>> On Tue, 30 Mar 2004 12:33:08 +0000 (UTC) > >>>>> "Bjoern A. Zeeb" said: > > bzeeb> What I had to do had been "excluding IKE traffic" by doing s.th. > bzeeb> like this (router side config): > bzeeb> spdadd ROUTER[500] NOTEBOOK[500] udp > bzeeb> -P out none ; > bzeeb> spdadd NOTEBOOK[500] ROUTER[500] udp > bzeeb> -P in none ; > bzeeb> This for sure is not the most nifty way to do but it works. > > The per socket security policy is broken under 5.2.1-RELEASE, and it > was fixed in 5-CURRENT. Racoon uses it to exclude IKE packets from > target of IPsec. So, the bzeeb's way should work for workaround. just for the archives (and to let me sleep well again ;-) can you please point me to the commit in question ? Thanks. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 05:38:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA8B916A4CE for ; Tue, 30 Mar 2004 05:38:46 -0800 (PST) Received: from cheer.mahoroba.org (flets19-094.kamome.or.jp [218.45.19.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 328AD43D2D for ; Tue, 30 Mar 2004 05:38:46 -0800 (PST) (envelope-from ume@FreeBSD.org) Received: from localhost (IDENT:ELUdHFpsuAFWM3rD0JdjiDZV3aRzVq8xRhlZXi1L4wg41QyGOARjB6G4kcrRNPbP@localhost [IPv6:::1]) (user=ume mech=CRAM-MD5 bits=0)i2UDdJ5m001999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2004 22:39:19 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Tue, 30 Mar 2004 22:39:19 +0900 Message-ID: From: Hajimu UMEMOTO To: "Bjoern A. Zeeb" In-Reply-To: References: <257C203C-8104-11D8-9902-00039303AB38@mac.com> <87BC9FE1-8241-11D8-9782-00039303AB38@mac.com> User-Agent: xcite1.38> Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.9-RELEASE-p4 MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cheer.mahoroba.org cc: freebsd-net@freebsd.org cc: Cyrill =?ISO-8859-1?Q?R=FCttimann?= Subject: Re: IPSec troubles 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, 30 Mar 2004 13:38:46 -0000 Hi, >>>>> On Tue, 30 Mar 2004 13:15:34 +0000 (UTC) >>>>> "Bjoern A. Zeeb" said: bzeeb> just for the archives (and to let me sleep well again ;-) can you bzeeb> please point me to the commit in question ? Okay, the commits are: src/sys/netinet/ip_output.c 1.205 src/sys/netinet/raw_ip.c 1.125 src/sys/netinet/tcp_input.c 1.221 src/sys/netinet/tcp_output.c 1.85 src/sys/netinet/udp_usrreq.c 1.146 src/sys/netinet6/icmp6.c 1.51 src/sys/netinet6/ip6_output.c 1.76 src/sys/netinet6/ipsec.c 1.33 src/sys/netinet6/ipsec.h 1.15 src/sys/netinet6/ipsec6.h 1.8 src/sys/netinet6/nd6_nbr.c 1.24 src/sys/netinet6/raw_ip6.c 1.37 src/sys/netinet6/udp6_output.c 1.16 src/sys/netinet6/udp6_usrreq.c 1.41 Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 06:59:57 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3BAC16A4CE; Tue, 30 Mar 2004 06:59:57 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 057D243D48; Tue, 30 Mar 2004 06:59:57 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i2UF3Sxv018121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2004 18:03:29 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2UF02Rt094807; Tue, 30 Mar 2004 18:00:02 +0300 (EEST) (envelope-from ru) Date: Tue, 30 Mar 2004 18:00:02 +0300 From: Ruslan Ermilov To: Doug Ambrisko Message-ID: <20040330150001.GB94442@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@FreeBSD.org Subject: ste(4) NIC's RX ring head may get ahead of the driver [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: Tue, 30 Mar 2004 14:59:58 -0000 --qtZFehHsKgwS5rPz Content-Type: multipart/mixed; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Doug, I'm writing to you because you were the last who touched this driver seriously, but since it's been 1,5 years ago, I'm also Cc:ing the freebsd-net mailing list, as I'm not sure if you're still interested in this driver. To make the long story short, under a heavy RX load, the ste(4) NIC's RX ring head may get ahead of what driver thinks, bringing all sort of havoc like stuck traffic, disordered packets, etc. The NIC never gets out of this state, and the only workaround is to reset the chip, and so we did for some time (by adding the IFF_LINK2 handler to call the driver's watchdog function). A similar problem is known to exist with other NICs, such as dc(4) and xl(4), and their drivers have workarounds for this situation. We've adopted the approach used by dc(4) and xl(4), but instead of seeing if we need to re-synchronize the head _after_ receiving (like dc(4) and xl(4) drivers do), we do it at the beginning of ste_rxeof(). As statistics shows, the number of resyncs needed is smaller by a factor of 3 or more in this case, because often the RxDMAComplete interrupt is generated when RX ring is completely empty(!), and as NIC continues to do DMA and fill the RX ring while we're still servicing the RxDMAComplete interrupt, we did more resyncs than was actually necessary. Also, we were able to further reduce the number of resyncs by setting the RxDMAPollPeriod to a higher value. 320ns looked like an overkill here, and I'm not sure why you have chosen it in the first place, when adding polling support for RX in the driver. Also, we believe that this setting may be responsible for what you referred to as: > This card still has seemingly unfixable issues under heavy RX load in > which the card takes over the PCI bus. in the commit log for revision 1.33 of if_ste.c. Attached is the patch (for RELENG_4) we're currently using, and are quite happy with. If anyone is using ste(4) NICs and is experiencing similar problems, I'd be glad to hear the reports about this patch. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Content-Transfer-Encoding: quoted-printable Index: if_ste.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/ipnet/freebsd/src/sys/pci/if_ste.c,v retrieving revision 1.1.1.2 retrieving revision 1.7 diff -u -p -r1.1.1.2 -r1.7 --- if_ste.c 29 Mar 2004 11:47:42 -0000 1.1.1.2 +++ if_ste.c 29 Mar 2004 13:41:47 -0000 1.7 @@ -30,6 +30,7 @@ * THE POSSIBILITY OF SUCH DAMAGE. * * $FreeBSD: src/sys/pci/if_ste.c,v 1.14.2.10 2004/03/25 08:49:22 ru Exp $ + * $IPNet: ipnet/freebsd/src/sys/pci/if_ste.c,v 1.7 2004/03/29 13:41:47 ru= Exp $ */ =20 #include @@ -39,6 +40,7 @@ #include #include #include +#include =20 #include #include @@ -163,6 +165,10 @@ static driver_t ste_driver =3D { =20 static devclass_t ste_devclass; =20 +static int ste_rxresync; +SYSCTL_INT(_hw, OID_AUTO, ste_rxresync, CTLFLAG_RW, + &ste_rxresync, 0, ""); + DRIVER_MODULE(if_ste, pci, ste_driver, ste_devclass, 0, 0); DRIVER_MODULE(miibus, ste, miibus_driver, miibus_devclass, 0, 0); =20 @@ -691,6 +697,19 @@ static void ste_rxeof(sc) =20 ifp =3D &sc->arpcom.ac_if; =20 + if (sc->ste_cdata.ste_rx_head->ste_ptr->ste_status =3D=3D 0) { + cur_rx =3D sc->ste_cdata.ste_rx_head; + do { + cur_rx =3D cur_rx->ste_next; + /* If the ring is empty, just return. */ + if (cur_rx =3D=3D sc->ste_cdata.ste_rx_head) + return; + } while (cur_rx->ste_ptr->ste_status =3D=3D 0); + /* We've fallen behind the chip: catch it. */ + sc->ste_cdata.ste_rx_head =3D cur_rx; + ++ste_rxresync; + }; + while((rxstat =3D sc->ste_cdata.ste_rx_head->ste_ptr->ste_status) & STE_RXSTAT_DMADONE) { if ((STE_RX_LIST_CNT - count) < 3) { @@ -1255,7 +1274,7 @@ static void ste_init(xsc) } =20 /* Set RX polling interval */ - CSR_WRITE_1(sc, STE_RX_DMAPOLL_PERIOD, 1); + CSR_WRITE_1(sc, STE_RX_DMAPOLL_PERIOD, 64); =20 /* Init TX descriptors */ ste_init_tx_list(sc); --St7VIuEGZ6dlpu13-- --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaYtxUkv4P6juNwoRAsDmAKCFR+dRSyOaZdnQ6MiIdPSCqX8iTQCggTVX 0JOAvF0tSgTiR7yRGmZUHgc= =6VzZ -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 08:23:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F00016A4CE; Tue, 30 Mar 2004 08:23:05 -0800 (PST) Received: from www.ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3453243D1F; Tue, 30 Mar 2004 08:23:05 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.9p2/8.12.9) with ESMTP id i2UGN4Cf049371; Tue, 30 Mar 2004 08:23:04 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.9p2/8.12.9/Submit) id i2UGN4oD049370; Tue, 30 Mar 2004 08:23:04 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200403301623.i2UGN4oD049370@ambrisko.com> In-Reply-To: <20040330150001.GB94442@ip.net.ua> To: Ruslan Ermilov Date: Tue, 30 Mar 2004 08:23:04 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: net@FreeBSD.org Subject: Re: ste(4) NIC's RX ring head may get ahead of the driver [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: Tue, 30 Mar 2004 16:23:05 -0000 Ruslan Ermilov writes: | To make the long story short, under a heavy RX load, the ste(4) NIC's | RX ring head may get ahead of what driver thinks, bringing all sort | of havoc like stuck traffic, disordered packets, etc. The NIC never | gets out of this state, and the only workaround is to reset the chip, | and so we did for some time (by adding the IFF_LINK2 handler to call | the driver's watchdog function). We never experienced this in our testing or in production. We were using the 4 port card. Maybe this bug is on another variant of the chip. | We've adopted the approach used by dc(4) and xl(4), but instead of | seeing if we need to re-synchronize the head _after_ receiving (like | dc(4) and xl(4) drivers do), we do it at the beginning of ste_rxeof(). | As statistics shows, the number of resyncs needed is smaller by a | factor of 3 or more in this case, because often the RxDMAComplete | interrupt is generated when RX ring is completely empty(!), and as | NIC continues to do DMA and fill the RX ring while we're still | servicing the RxDMAComplete interrupt, we did more resyncs than was | actually necessary. Sounds good. | Also, we were able to further reduce the number of resyncs by setting | the RxDMAPollPeriod to a higher value. 320ns looked like an overkill | here, and I'm not sure why you have chosen it in the first place, | when adding polling support for RX in the driver. Also, we believe | that this setting may be responsible for what you referred to as: I'm not sure. | > This card still has seemingly unfixable issues under heavy RX load in | > which the card takes over the PCI bus. | | in the commit log for revision 1.33 of if_ste.c. | | Attached is the patch (for RELENG_4) we're currently using, and are | quite happy with. If anyone is using ste(4) NICs and is experiencing | similar problems, I'd be glad to hear the reports about this patch. Sounds good. However it won't fix the core problem that I reported. D-Link's solution was to EOL 4-port card because of this problem. You can see it in their Linux and Windows drivers. The easiest way to see it is to send traffic into all 4 ports of the 4 port card. You will see only one port have activity then it switch to another. It will not be multiplexing traffic. Another thing I found that would lead to a panic was that if you reset the chip while it is sending traffic into the card the reset will return but the card still takes RX packets and DMA's them into memory. Since it we have released the memory for the card it would then splat bits over something else. It was a while before I figure out this cause of panics :-( I don't see how your change will fix that. I no longer have access to the HW or the test environment I used since I've changed jobs. I have no objection to your change and it sounds good. I don't think it will solve the problem I saw. While you are in this driver can you convert it to Mike Silby's generic de-frager? To test it do some like: dd if=/kernel bs=1 | ssh "cat > /tmp/kernel" I original "stole" the code to do this from fxp(4) which was before Mike did the generic de-frager. Thanks, Doug A. From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 09:10:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D16516A4CF; Tue, 30 Mar 2004 09:10:11 -0800 (PST) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5B9E43D3F; Tue, 30 Mar 2004 09:10:10 -0800 (PST) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id C6FF91FF931; Tue, 30 Mar 2004 19:10:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id CDF461FF91D; Tue, 30 Mar 2004 19:10:06 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 1DC66154E3; Tue, 30 Mar 2004 17:01:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1AC75153AA; Tue, 30 Mar 2004 17:01:57 +0000 (UTC) Date: Tue, 30 Mar 2004 17:01:57 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Hajimu UMEMOTO In-Reply-To: Message-ID: References: <257C203C-8104-11D8-9902-00039303AB38@mac.com> <87BC9FE1-8241-11D8-9782-00039303AB38@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-net@freebsd.org cc: =?ISO-8859-1?Q?Cyrill_R=FCttimann?= Subject: Re: IPSec troubles 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, 30 Mar 2004 17:10:11 -0000 On Tue, 30 Mar 2004, Hajimu UMEMOTO wrote: > >>>>> On Tue, 30 Mar 2004 13:15:34 +0000 (UTC) > >>>>> "Bjoern A. Zeeb" said: > > bzeeb> just for the archives (and to let me sleep well again ;-) can you > bzeeb> please point me to the commit in question ? > > Okay, the commits are: ah I see, I had these included from your patch before; thus I did not really notice it. Working great on my router now. Looking forward for the buildworld and -kernel to finish for my notebook ... :-) Many thanks. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 10:34:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE47516A4CF for ; Tue, 30 Mar 2004 10:34:03 -0800 (PST) Received: from tx3.oucs.ox.ac.uk (tx3.oucs.ox.ac.uk [163.1.2.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id A27FF43D39 for ; Tue, 30 Mar 2004 10:34:03 -0800 (PST) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from scan3.oucs.ox.ac.uk ([163.1.2.166] helo=localhost) by tx3.oucs.ox.ac.uk with esmtp (Exim 4.24) id 1B8O3m-0002YC-PB for freebsd-net@freebsd.org; Tue, 30 Mar 2004 19:34:02 +0100 Received: from rx3.oucs.ox.ac.uk ([163.1.2.165]) by localhost (scan3.oucs.ox.ac.uk [163.1.2.166]) (amavisd-new, port 25) with ESMTP id 09387-10 for ; Tue, 30 Mar 2004 19:34:02 +0100 (BST) Received: from gateway.wadham.ox.ac.uk ([163.1.161.253]) by rx3.oucs.ox.ac.uk with smtp (Exim 4.24) id 1B8O3m-0002Y9-Bn for freebsd-net@freebsd.org; Tue, 30 Mar 2004 19:34:02 +0100 Received: (qmail 3723 invoked by uid 1004); 30 Mar 2004 18:34:02 -0000 Received: from colin.percival@wadham.ox.ac.uk by gateway by uid 71 with qmail-scanner-1.20 (clamscan: 0.67. sweep: 2.18/3.79. Clear:RC:1(163.1.161.131):. Processed in 0.018171 secs); 30 Mar 2004 18:34:02 -0000 Received: from dhcp1131.wadham.ox.ac.uk (HELO piii600.wadham.ox.ac.uk) (163.1.161.131) by gateway.wadham.ox.ac.uk with SMTP; 30 Mar 2004 18:34:02 -0000 Message-Id: <6.0.1.1.1.20040330193050.0316cdf0@imap.sfu.ca> X-Sender: cperciva@imap.sfu.ca (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 30 Mar 2004 19:33:55 +0100 To: freebsd-net@freebsd.org From: Colin Percival Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" cc: secteam@freebsd.org Subject: Another complaint about the tcp security fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 18:34:04 -0000 There's another PR accusing the TCP security fix of causing problems: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/64826 I can't see how there could be any connection here, but it's certainly suspicious that a 140-day stable box became unstable after applying the security fix. Could someone on -net look at this? Colin Percival From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 11:19:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E8E516A4CF; Tue, 30 Mar 2004 11:19:06 -0800 (PST) Received: from bes.amduat.net (bes.amduat.net [206.124.149.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D0B043D49; Tue, 30 Mar 2004 11:19:06 -0800 (PST) (envelope-from jbarrett@amduat.net) Received: from osiris.amduat.net ([63.115.16.66]) (AUTH: LOGIN jbarrett, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by bes.amduat.net with esmtp; Tue, 30 Mar 2004 11:19:05 -0800 From: "Jacob S. Barrett" To: Ruslan Ermilov Date: Tue, 30 Mar 2004 11:19:00 -0800 User-Agent: KMail/1.6.1 References: <200403251118.40718.jbarrett@amduat.net> <200403290936.49345.jbarrett@amduat.net> <20040330103251.GA92824@ip.net.ua> In-Reply-To: <20040330103251.GA92824@ip.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403301119.01357.jbarrett@amduat.net> cc: freebsd-net@freebsd.org Subject: Re: Disabling VLAN_HWTAGGING 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, 30 Mar 2004 19:19:06 -0000 Now what have I done wrong. I noticed this yesterday and I can't figure out what I have done wrong. VLAN tagged ARP requests coming into if_nge are not visible anymore (tcpdump). Non VLAN tagged ARP requests are visible. Debug statements are showing the frame doesn't make it into the driver. This is the request as it leaves the remote host. 11:04:53.588726 0:90:27:f4:58:1d ff:ff:ff:ff:ff:ff 8100 46: 802.1Q vlan#2 P0 arp who-has 10.2.0.1 tell 10.2.0.2 Strangely though, other broadcasts that are VLAN tagged get delivered to the driver. With your patch they now correctly show up on the ng_vlan interface too. This is the other broadcast as sent by remote host: 0:90:27:f4:58:1d ff:ff:ff:ff:ff:ff 8100 257: 802.1Q vlan#2 P0 10.2.0.2.138 > 10.2.0.255.138: NBT UDP PACKET(138) This is he above broadcast that was received by both if_nge and ng_vlan: 0:90:27:f4:58:1d ff:ff:ff:ff:ff:ff 0800 246: 10.2.0.2.138 > 10.2.0.255.138: NBT UDP PACKET(138) Any idea why the ARP packets would be filtered at the NIC? The same goes for ARP replies. I can ARP request from the if_nge machine, but the replies get dropped. -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 11:48:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55CF016A4CF for ; Tue, 30 Mar 2004 11:48:28 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CF3E43D31 for ; Tue, 30 Mar 2004 11:48:27 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i2UJpme9022854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2004 22:51:50 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2UJmLH7096934; Tue, 30 Mar 2004 22:48:21 +0300 (EEST) (envelope-from ru) Date: Tue, 30 Mar 2004 22:48:21 +0300 From: Ruslan Ermilov To: "Jacob S. Barrett" Message-ID: <20040330194821.GA96878@ip.net.ua> References: <200403251118.40718.jbarrett@amduat.net> <200403290936.49345.jbarrett@amduat.net> <20040330103251.GA92824@ip.net.ua> <200403301119.01357.jbarrett@amduat.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <200403301119.01357.jbarrett@amduat.net> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-net@freebsd.org Subject: Re: Disabling VLAN_HWTAGGING 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, 30 Mar 2004 19:48:28 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 30, 2004 at 11:19:00AM -0800, Jacob S. Barrett wrote: > Now what have I done wrong. I noticed this yesterday and I can't figure = out=20 > what I have done wrong. VLAN tagged ARP requests coming into if_nge are = not=20 > visible anymore (tcpdump). Non VLAN tagged ARP requests are visible. De= bug=20 > statements are showing the frame doesn't make it into the driver. >=20 Like I said in another email in this thread, if NIC is doing VLAN stripping in firmware, you won't be able to see the original VLAN packet with tcpdump(8) in 5.x. Instead, it will be shown an inner Ethernet packet on the physical ("parentdev") interface. This can be fixed. But neither 4.x nor 5.x will show you the virgin VLAN packet on output if the NIC does VLAN insertion in firmware. > This is the request as it leaves the remote host. > 11:04:53.588726 0:90:27:f4:58:1d ff:ff:ff:ff:ff:ff 8100 46: 802.1Q vlan#2= P0=20 > arp who-has 10.2.0.1 tell 10.2.0.2 >=20 > Strangely though, other broadcasts that are VLAN tagged get delivered to = the=20 > driver. With your patch they now correctly show up on the ng_vlan interfa= ce=20 > too. >=20 > This is the other broadcast as sent by remote host: > 0:90:27:f4:58:1d ff:ff:ff:ff:ff:ff 8100 257: 802.1Q vlan#2 P0 10.2.0.2.13= 8 >=20 > 10.2.0.255.138: NBT UDP PACKET(138) >=20 > This is he above broadcast that was received by both if_nge and ng_vlan: > 0:90:27:f4:58:1d ff:ff:ff:ff:ff:ff 0800 246: 10.2.0.2.138 > 10.2.0.255.13= 8:=20 > NBT UDP PACKET(138) >=20 > Any idea why the ARP packets would be filtered at the NIC? >=20 Hmm, this shouldn't happen. Perhaps you have a firewall configured to run at layer2 that rejects them? > The same goes for=20 > ARP replies. I can ARP request from the if_nge machine, but the replies = get=20 > dropped. >=20 If you set ARP entries manually, can you ping each other? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAac8FUkv4P6juNwoRAvzuAKCA3RHJ78vMqnKoSrr3DdyCtdJZ5QCfUSyq QVJY2kwTR2T29Yh3zj4Y9mw= =Gsfu -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 12:55:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5824116A4CF; Tue, 30 Mar 2004 12:55:09 -0800 (PST) Received: from bes.amduat.net (bes.amduat.net [206.124.149.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id D47BA43D2D; Tue, 30 Mar 2004 12:55:08 -0800 (PST) (envelope-from jbarrett@amduat.net) Received: from osiris.amduat.net ([63.115.16.66]) (AUTH: LOGIN jbarrett, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by bes.amduat.net with esmtp; Tue, 30 Mar 2004 12:55:07 -0800 From: "Jacob S. Barrett" To: Ruslan Ermilov Date: Tue, 30 Mar 2004 12:55:06 -0800 User-Agent: KMail/1.6.1 References: <200403251118.40718.jbarrett@amduat.net> <200403301119.01357.jbarrett@amduat.net> <20040330194821.GA96878@ip.net.ua> In-Reply-To: <20040330194821.GA96878@ip.net.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403301255.06689.jbarrett@amduat.net> cc: freebsd-net@freebsd.org Subject: Re: Disabling VLAN_HWTAGGING 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, 30 Mar 2004 20:55:09 -0000 On Tuesday 30 March 2004 11:48 am, Ruslan Ermilov wrote: > On Tue, Mar 30, 2004 at 11:19:00AM -0800, Jacob S. Barrett wrote: > > Now what have I done wrong. I noticed this yesterday and I can't figure > > out what I have done wrong. VLAN tagged ARP requests coming into if_nge > > are not visible anymore (tcpdump). Non VLAN tagged ARP requests are > > visible. Debug statements are showing the frame doesn't make it into the > > driver. > > Like I said in another email in this thread, if NIC is doing VLAN > stripping in firmware, you won't be able to see the original VLAN > packet with tcpdump(8) in 5.x. Instead, it will be shown an inner > Ethernet packet on the physical ("parentdev") interface. This can > be fixed. But neither 4.x nor 5.x will show you the virgin VLAN > packet on output if the NIC does VLAN insertion in firmware. Correct, I shouldn't be able to see them with tags, but they should show up in tcpdump without the tags just like all the other VLAN frames right? There shouldn't be anything special for ARP requests/replies at the hardware level right? > Hmm, this shouldn't happen. Perhaps you have a firewall configured > to run at layer2 that rejects them? No firewall at all. > > The same goes for > > ARP replies. I can ARP request from the if_nge machine, but the replies > > get dropped. > > If you set ARP entries manually, can you ping each other? Yes, if I manually enter the MACs the pings work great. -- Jacob S. Barrett jbarrett@amduat.net www.amduat.net "I don't suffer from insanity, I enjoy every minute of it." From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 14:05:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 453B216A4CF for ; Tue, 30 Mar 2004 14:05:49 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00ACC43D1F for ; Tue, 30 Mar 2004 14:05:49 -0800 (PST) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com (unknown [198.147.128.71]) by smtp-relay.omnis.com (Postfix) with ESMTP id 27B75100492; Tue, 30 Mar 2004 14:05:48 -0800 (PST) From: Wes Peters Organization: Softweyr.com To: Steven Stremciuc , freebsd-net@freebsd.org Date: Tue, 30 Mar 2004 14:06:05 -0800 User-Agent: KMail/1.5.4 References: <4067D250.8070609@freeslacker.net> In-Reply-To: <4067D250.8070609@freeslacker.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403301406.05470.wes@softweyr.com> Subject: Re: Looking for switch recommendations ... 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, 30 Mar 2004 22:05:49 -0000 On Sunday 28 March 2004 11:37 pm, Steven Stremciuc wrote: > Has anyone tested port mirroring on these switches (2524) and run into > any problems? Many people seem to recommend these ProCurve switches here > and so far they seem like a great buy (only one I saw that cheap that > does 802.1x). I'm also looking for a managed switch (probably something > off ebay) and would like to find something that does port mirroring > nicely as I'd like to play with that in the future. I saw Dell's > Powerconnect 3348 has some problems with port mirroring and am trying to > avoid getting a switch where the feature is listed as supported but > doesn't work as expected. > > Info about the 3348's problems: > http://forums.us.dell.com/supportforums/board/message?board.id=pc_managed >&message.id=1425 Every switch that does port mirroring probably has some problems related to port mirroring, because mirroring typically cannot be done in hardware. If nothing else, you can expect some degraded performance on the port(s) being mirrored and on the port doing the mirroring, because the packets have to be fondled by the CPU before they can be switched. Even with a really fast processor, this will increase the latency a bit. In a multi-slot switch like the ProCurve 4000M, you probably want to mirror to a port on the same switch blade. This certainly helped with the latency in the Xylan chassis. Smaller switches like the 2500 series are *probably* implemented as a slot-based architecture with all of the slots on one board, so it may be advantageous to have the mirror ports in the same group of 8. Without knowing the architecture more closely, it would be hard to say for sure. The guy who posted the message in the Dell forum you linked above sounds like he has no idea what he's doing. It's not possible to use a switch port mirroring function to monitor a switch without a strong knowlege of network configuration. The fact that he's getting only packets bearing the IP address of the other NIC in his XP box doesn't lend me to believe he has that knowlege. -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 14:41:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84E2216A4D5 for ; Tue, 30 Mar 2004 14:41:30 -0800 (PST) Received: from lakecmmtao01.coxmail.com (lakecmmtao01.coxmail.com [68.99.120.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAF7243D2D for ; Tue, 30 Mar 2004 14:41:29 -0800 (PST) (envelope-from steve@freeslacker.net) Received: from freeslacker.net ([68.110.170.205]) by lakecmmtao01.coxmail.comESMTP <20040330224129.XUKM13607.lakecmmtao01.coxmail.com@freeslacker.net> for ; Tue, 30 Mar 2004 17:41:29 -0500 Message-ID: <4069F7A3.3060202@freeslacker.net> Date: Tue, 30 Mar 2004 15:41:39 -0700 From: Steven Stremciuc User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4067D250.8070609@freeslacker.net> <200403301406.05470.wes@softweyr.com> In-Reply-To: <200403301406.05470.wes@softweyr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Looking for switch recommendations ... 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, 30 Mar 2004 22:41:32 -0000 Wes Peters wrote: >>Info about the 3348's problems: >>http://forums.us.dell.com/supportforums/board/message?board.id=pc_managed&message.id=1425 >> >>The guy who posted the message in the Dell forum you linked above sounds >>like he has no idea what he's doing. It's not possible to use a switch >>port mirroring function to monitor a switch without a strong knowlege of >>network configuration. The fact that he's getting only packets bearing the >>IP address of the other NIC in his XP box doesn't lend me to believe he has >>that knowlege. >> I was referring to the reply from the Moderator Randy (2nd post) and not the original poster you mention. The Moderator mentions "The switch's architecture has ports 1-24 and gigabit port 1 on 1 ASIC, while ports 25-48 and gigabit port 2 are on the other. Because of this architecture, you are unable to mirror between ASICs, e.g. port 1 to port 48." He also mentions a hardware chipset limitation that only affects the Dell 33xx series regarding mirroring of ports that are part of a 802.1Q VLAN. From owner-freebsd-net@FreeBSD.ORG Tue Mar 30 15:47:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDD0916A4CE for ; Tue, 30 Mar 2004 15:47:02 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CC0543D45 for ; Tue, 30 Mar 2004 15:47:02 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-67-169-127-171.client.comcast.net[67.169.127.171]) by comcast.net (sccrmhc11) with ESMTP id <2004033023465101100c9lt6e>; Tue, 30 Mar 2004 23:47:01 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i2UNkn0m045626; Tue, 30 Mar 2004 15:46:50 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i2UNkmT5045625; Tue, 30 Mar 2004 15:46:48 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Tue, 30 Mar 2004 15:46:48 -0800 From: "Crist J. Clark" To: "Bjoern A. Zeeb" Message-ID: <20040330234648.GA45024@blossom.cjclark.org> References: <257C203C-8104-11D8-9902-00039303AB38@mac.com> <20040329214057.GA8711@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org Subject: Re: IPSec troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2004 23:47:03 -0000 On Tue, Mar 30, 2004 at 11:22:08AM +0000, Bjoern A. Zeeb wrote: > On Mon, 29 Mar 2004, Crist J. Clark wrote: > > > > I have troubles setting up an IPSec Host-to-Host connection between > > > FreeBSD 5.2.1 and MacOS X 10.3.3: > > > > Last I knew, 5.2.1 still had broken IPsec. Specifically, the system > > tries to apply the IPsec policy to the IKE traffic giving us a chicken > > and egg problem. > > you can "exclude" IKE traffic in the SPD manually. I am still unsure > if this IS a bug. Would need to go through RFCs in detail. [snip RFC2401 quotes] I don't think we do. I mispoke... er, typed. IPsec _policy_ must be applied to every packet (or socket). However, IKE traffic should skip IPsec _processing,_ i.e. the IPsec policy should dictate the IKE traffic skip IPsec processing. > So if I get the problem right racoon is unable to tell the kernel > that it's traffic should 'bypass' IPSec processing ? Yes. Racoon can _no longer_ tell the kernel to bypass using KAME IPsec. This used to work. A working racoon binary stopped working as of a kernel upgrade between 5. and 5.. Racoon will still work fine with FAST_IPSEC. Racoon tells the kernel that the IKE socket should be 'bypassed' in IPsec processing in the racoon/sockmisc.c:setsockopt_bypass function. -- 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 Mar 31 00:32:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2948416A4CE for ; Wed, 31 Mar 2004 00:32:01 -0800 (PST) Received: from caliban.dreamscope.com (mail.dreamscope.com [69.55.225.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12ABA43D41 for ; Wed, 31 Mar 2004 00:32:01 -0800 (PST) (envelope-from chance@dreamscope.com) Received: from belial (caliban.dreamscope.com [69.55.225.46]) by caliban.dreamscope.com (Postfix) with ESMTP id 948604CA35; Wed, 31 Mar 2004 00:31:41 -0800 (PST) From: "Chance Whaley" To: "'Wes Peters'" , "'Steven Stremciuc'" , Date: Wed, 31 Mar 2004 01:32:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200403301406.05470.wes@softweyr.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQWozW4I6AqKl+QRYi5QX7mQ1wHoAAVoAhg Message-Id: <20040331083141.948604CA35@caliban.dreamscope.com> Subject: RE: Looking for switch recommendations ... 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, 31 Mar 2004 08:32:01 -0000 > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Wes Peters > Sent: Tuesday, March 30, 2004 3:06 PM > To: Steven Stremciuc; freebsd-net@freebsd.org > Subject: Re: Looking for switch recommendations ... > > > Every switch that does port mirroring probably has some > problems related to port mirroring, because mirroring > typically cannot be done in hardware. If nothing else, you > can expect some degraded performance on the port(s) being > mirrored and on the port doing the mirroring, because the > packets have to be fondled by the CPU before they can be > switched. Even with a really fast processor, this will > increase the latency a bit. This is an untrue statement. There are several switch vendors that pride themselves on their wire-speed mirroring capabilities - specifically their ability to do it in hardware. Foundry's BigIron and the like comes to mind as a highly reliable and fairly inexpensive (subjective) switch that is very capable of doing multi-port wirespeed mirroring at line rate. .chance From owner-freebsd-net@FreeBSD.ORG Wed Mar 31 00:59:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 361CC16A4CE for ; Wed, 31 Mar 2004 00:59:15 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D93743D55 for ; Wed, 31 Mar 2004 00:59:15 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i2V8xEgd009626; Wed, 31 Mar 2004 00:59:14 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i2V8xE71009625; Wed, 31 Mar 2004 00:59:14 -0800 (PST) (envelope-from rizzo) Date: Wed, 31 Mar 2004 00:59:14 -0800 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20040331005914.A6934@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: do we support non contiguous netmasks ? 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, 31 Mar 2004 08:59:15 -0000 Hi, i was wondering if anyone knows what kind of support we have in FreeBSD networking code, for non contiguous netmasks. While it is trivial to support them for interface addresses, managing them in the routing table is probably far from trivial and I believe also mostly useless... and anyways, i have no idea how our kernel code deals with them cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Mar 31 01:15:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8AC916A4CE for ; Wed, 31 Mar 2004 01:15:43 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3318B43D39 for ; Wed, 31 Mar 2004 01:15:43 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i2V9JHe0056518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2004 12:19:20 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i2V9FZL5000389; Wed, 31 Mar 2004 12:15:35 +0300 (EEST) (envelope-from ru) Date: Wed, 31 Mar 2004 12:15:34 +0300 From: Ruslan Ermilov To: Luigi Rizzo Message-ID: <20040331091534.GA359@ip.net.ua> References: <20040331005914.A6934@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <20040331005914.A6934@xorpc.icir.org> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org Subject: Re: do we support non contiguous netmasks ? 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, 31 Mar 2004 09:15:44 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 31, 2004 at 12:59:14AM -0800, Luigi Rizzo wrote: > Hi, > i was wondering if anyone knows what kind of support we have > in FreeBSD networking code, for non contiguous netmasks. > While it is trivial to support them for interface addresses, > managing them in the routing table is probably far from trivial > and I believe also mostly useless... and anyways, i have no > idea how our kernel code deals with them >=20 Yes, our generic routing code that uses PATRICIA trees supports non-contiguos netmasks (see net/radix.c) but its current version has been opmimized for contiguous netmasks. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAaow2Ukv4P6juNwoRAs2SAJwLTWN6Xq5fNPfTVRq+35jvNqLFoACfYrwt 003GwtXk/ureKnTJZBCm4ms= =ttKa -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 31 03:44:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2804416A4CE for ; Wed, 31 Mar 2004 03:44:27 -0800 (PST) Received: from moe.ilimit.es (38.Red-213-96-13.pooles.rima-tde.net [213.96.13.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA2D643D1D for ; Wed, 31 Mar 2004 03:44:25 -0800 (PST) (envelope-from d.ortiz@in.ilimit.es) Received: from dani.ilimit.lan ([192.168.1.57] helo=in.ilimit.es) by moe.ilimit.es with smtp (Exim 3.35 #1 (Debian)) id 1B8e8P-0007h0-00 for ; Wed, 31 Mar 2004 13:43:53 +0200 Received: by in.ilimit.es (sSMTP sendmail emulation); Wed, 31 Mar 2004 13:44:11 +0200 Date: Wed, 31 Mar 2004 13:44:11 +0200 From: Daniel Ortiz To: FreeBSD Networking Message-ID: <20040331114411.GB797@in.ilimit.es> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean Subject: About ET/BWMGR 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, 31 Mar 2004 11:44:27 -0000 --gatW/ieO32f1wygP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everybody, On my work we are evaluating the possibility of implementing the ET/BWMGR Bandwidth Shapper. The installation it's a little odd, and the documentation it's a piece of shit. That software should work on bridge mode (with a custom implementation of bridging) but on my server (an IBM x305s with 2 broadcom ethernets (bge)) doesn't work. Shapping works.=20 Anyone has any experience with this software? It's possible to use bridging combinated with dummynet? Can I use virtualhosts with dummynet? Thanks in advance. --=20 -- Use perl; http://taik0.piscue.com Daniel Ortiz d.ortiz@in.ilimit.es --gatW/ieO32f1wygP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAaq8LPprEQTARuLoRAnFmAJ97ySe1evowQ8MlercXbblolTVpRgCgtqmk maGIqGYkZNHCQ+YkcYu+t/k= =7wWk -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From owner-freebsd-net@FreeBSD.ORG Wed Mar 31 04:53:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CB0516A4CE for ; Wed, 31 Mar 2004 04:53:50 -0800 (PST) Received: from mail.a-quadrat.at (mail.a-quadrat.at [81.223.141.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F15D543D67 for ; Wed, 31 Mar 2004 04:53:49 -0800 (PST) (envelope-from mbretter@a-quadrat.at) Received: from localhost (localhost.a-quadrat.at [127.0.0.1]) by files.a-quadrat.at (Postfix) with ESMTP id 17F565C424; Wed, 31 Mar 2004 14:53:48 +0200 (CEST) Received: from mail.a-quadrat.at ([127.0.0.1]) by localhost (files.a-quadrat.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29853-08; Wed, 31 Mar 2004 14:53:37 +0200 (CEST) Received: from BRUTUS.a-quadrat.at (brutus.a-quadrat.at [192.168.90.60]) by files.a-quadrat.at (Postfix) with ESMTP id BCB7B5C2D4; Wed, 31 Mar 2004 14:53:37 +0200 (CEST) Date: Wed, 31 Mar 2004 14:53:35 +0200 (=?ISO-8859-15?Q?Westeurop=E4ische_Sommerzeit?=) From: Michael Bretterklieber To: Jay Hall In-Reply-To: <40682776.5000104@vandaliamo.net> Message-ID: References: <40679626.1040104@vandaliamo.net> <40682776.5000104@vandaliamo.net> X-X-Sender: mbretter@files.a-quadrat.at MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at a-quadrat.at cc: freebsd-net@freebsd.org Subject: Re: PPTP MTU 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, 31 Mar 2004 12:53:50 -0000 Hi, it looks everything is ok, until your routes were added. Could you try this without these routes? On Mon, 29 Mar 2004, Jay Hall wrote: > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: Up event > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: state change Starting --> > Req-Sent > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: SendConfigReq #1 > Mar 29 06:37:37 ST_CHARLES mpd: IPADDR 10.129.10.101 > Mar 29 06:37:37 ST_CHARLES mpd: COMPPROTO VJCOMP, 16 comp. channels, no > comp-cid > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Open event > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: state change Initial --> > Starting > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: LayerStart > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Up event ... > bytes > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/ifconfig ng1 > 10.129.10.101 10.129.10.40 netmask 0xffffffff -link0 > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add > 10.129.10.101 -iface lo0 > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.10.0 > 10.129.10.40 -netmask 0xffffff00 > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.30.0 > 10.129.10.40 -netmask 0xffffff00 > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.40.0 > 10.129.10.40 -netmask 0xffffff00 > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.50.0 > 10.129.10.40 -netmask 0xffffff00 > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.60.0 > 10.129.10.40 -netmask 0xffffff00 > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.70.0 > 10.129.10.40 -netmask 0xffffff00 > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.128.10.0 > 10.129.10.40 -netmask 0xffffff00 > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 192.0.0.0 > 10.129.10.40 -netmask 0xc0000000 > Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 172.16.8.0 > 10.129.10.40 -netmask 0xfffff800 > Mar 29 06:37:38 ST_CHARLES mpd: [vpn] exec: /etc/iface-up.sh ng1 inet > 10.129.10.101 10.129.10.40 ... > Mar 29 06:37:38 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless > Mar 29 06:37:38 ST_CHARLES mpd: [vpn] error writing len 14 frame to > bypass: Resource deadlock avoided bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 From owner-freebsd-net@FreeBSD.ORG Wed Mar 31 05:19:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E04916A4CE for ; Wed, 31 Mar 2004 05:19:58 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 545DB43D1F for ; Wed, 31 Mar 2004 05:19:57 -0800 (PST) (envelope-from jrh@it.uc3m.es) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5816519C34 for ; Wed, 31 Mar 2004 15:19:56 +0200 (CEST) Received: from localhost.invalid (unknown [163.117.140.30]) by smtp03.uc3m.es (Postfix) with ESMTP id 428CB19C19 for ; Wed, 31 Mar 2004 15:19:56 +0200 (CEST) From: Juan Rodriguez Hervella Organization: UC3M To: freebsd-net@freebsd.org Date: Wed, 31 Mar 2004 15:19:50 +0200 User-Agent: KMail/1.6 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200403311519.50763.jrh@it.uc3m.es> Subject: How to change the next hop ethernet address of a route using "route" command 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, 31 Mar 2004 13:19:58 -0000 Hello, I try to do this: route add 163.117.139.99/32 -iface tap0 route change 163.117.139.99/32 -link 00:bd:82:1c:96:00 And when I see the result with "netstat -rn", I get this: [snipped] 163.117.140.30/32 00:bd.82.1c.96.0 ULS 0 14 tap0 ^^^^^^^^^^^^^^ [snipped] Is this right ? why there are not the same number of colons ? Thanks -- ****** JFRH ****** "Deliver yesterday, code today, think tomorrow." From owner-freebsd-net@FreeBSD.ORG Wed Mar 31 12:54:08 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C16216A4CE for ; Wed, 31 Mar 2004 12:54:08 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id C16BA43D55 for ; Wed, 31 Mar 2004 12:54:07 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id 4605F5487E for ; Wed, 31 Mar 2004 14:54:07 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id F17E26D465; Wed, 31 Mar 2004 14:54:06 -0600 (CST) Date: Wed, 31 Mar 2004 14:54:06 -0600 From: "Jacques A. Vidrine" To: freebsd-net@freebsd.org Message-ID: <20040331205406.GD16803@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i Subject: Fwd: [IPv4 fragmentation --> The Rose Attack] 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, 31 Mar 2004 20:54:08 -0000 ----- Forwarded message from gandalf@digital.net ----- Date: Tue, 30 Mar 2004 22:18:05 -0600 From: gandalf@digital.net To: bugtraq@securityfocus.com Subject: IPv4 fragmentation --> The Rose Attack Message-ID: Greetings and Salutations: While this discussion pertains to IPv4, IPv6 also allows fragmentation and I suspect IPv6 will also be affected by this attack. I have created what I believe is a unique fragmented attack ("Rose Attack") that I would like to inform the community about. It seems to affect most IP devices. Since cell phones, IPSec & satellite use fragmented packets this attack is pertinent to the Internet of today. The attack is simple. Two parts of a fragmented packet are sent to the machine being attacked. The first fragment (payload 32 bytes long) is the initial offset zero fragment of a SYN packet. The final (second) fragment of the SYN packet is also 32 bytes in size, but is set to an offset of 64800 bytes into the datagram. During my testing, I alternated this two fragment pattern rotating between ICMP, TCP, UDP, ICMP, etc. All test fragments used the same source IP address and fragment ID. Since this attack does not require a response from the target system, the source IP address can be spoofed, thus hiding the attacker's true location. Also note the source and destination ports do not matter as the packet is never validated at the layer four level, it never gets past layer three. The devices accept the packets no matter what port is used. Of the machines I have had access to, this attack has caused any number of the following problems: 1) Causes the CPU to spike, thus exhausting processor resources. 2) Legitimate fragmented packets are dropped intermittently (unfragmented packets get through fine) 3) Legitimate fragmented packets are no longer accepted by the machine under attack (unfragmented packets get through fine) until the fragmentation time exceeded timers expire. 4) Devices like Cisco routers can have Buffer overflow, i.e. packets are dropped at high packet rates if there aren't enough buffers allocated. The following devices were tested and showed some or all of the above symptoms: 1) Microsoft Windows 2000 2) Mandrake Linux 9.2 2) Cisco 2621XM 3) PIX Firewall 4) Mac OS/X V10.2.8 (FreeBSD 5?) The following vendors have been notified of this condition prior to the release of this announcement: 1) Microsoft 2) Cisco (2621XM only) 3) Linux This can also be used in active fingerprinting as some OS's return a "Fragmentation Reassembly Time exceeded", some do not, some return the first fragments as assembly time exceeded, some return later packets. For the original discussion (excerpt from my larger SANS GCFW paper http://www.giac.org/practical/GCFW/William_Hollis_GCFW.pdf ) please see: http://gandalf.home.digital.net/Rose.rtf I have "cleaned up" the procedure since the original discussion. For the test procedure to test this attack using Windows computers and suggestions on how to mitigate this attack please see: http://gandalf.home.digital.net/TestProc.txt For the support files please see: http://gandalf.home.digital.net/nemITUrnd.xls http://gandalf.home.digital.net/Picmpdata.txt http://gandalf.home.digital.net/Ptcpdata.txt http://gandalf.home.digital.net/Pudpdata.txt You will need WinPCap (of course) WinPcap_3_0.exe http://www.packetfactory.net/projects/nemesis/ nemesis-1.4beta3.zip on website NetWox http://www.laurentconstantin.com/en/netw/netwox/ I used: netwox-5.11.0-bin_windows.tgz The suggested software solution to this attack is to: 1) Allocate X*64k buffers upon NIC card initialization. Assuming X=200 buffers this would equate to approximately 12 Mb 2) Flush fragmented buffers in a FIFO fashion. 3) Do not reassemble buffers until all have been received, then use the CPU to reassemble the buffers. I would like to thank Chris Brenton for his help / input on this attack. Your comments on this attack are appreciated. Ken --------------------------------------------------------------- Do not meddle in the affairs of wizards for they are subtle and quick to anger. Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC WWW Page - http://digital.net/~gandalf/ Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html Trolls crossposts - http://digital.net/~gandalf/trollfaq.html ----- End forwarded message ----- From owner-freebsd-net@FreeBSD.ORG Wed Mar 31 13:48:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D95116A4CE for ; Wed, 31 Mar 2004 13:48:50 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C2B343D1F for ; Wed, 31 Mar 2004 13:48:49 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 79682 invoked from network); 31 Mar 2004 21:48:48 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 31 Mar 2004 21:48:48 -0000 Message-ID: <406B3CC0.C277B933@freebsd.org> Date: Wed, 31 Mar 2004 23:48:48 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20040331205406.GD16803@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Fwd: [IPv4 fragmentation --> The Rose Attack] 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, 31 Mar 2004 21:48:50 -0000 We have the following sysctl's to withstand such an attack: net.inet.ip.maxfragpackets [800] net.inet.ip.maxfragsperpacket [16] Which limits such an attack to 800 packets overall and 16 fragments per packet. Of course, when the maxfragpackets limit is reached by malicous packets we are unable to process legitimate fragmented IP packets until the malicous ones start to time out. There is nothing else one can do to fight off such an attack. -- Andre "Jacques A. Vidrine" wrote: > > ----- Forwarded message from gandalf@digital.net ----- > > Date: Tue, 30 Mar 2004 22:18:05 -0600 > From: gandalf@digital.net > To: bugtraq@securityfocus.com > Subject: IPv4 fragmentation --> The Rose Attack > Message-ID: > > Greetings and Salutations: > > While this discussion pertains to IPv4, IPv6 also allows fragmentation and I > suspect IPv6 will also be affected by this attack. > > I have created what I believe is a unique fragmented attack ("Rose Attack") > that I would like to inform the community about. It seems to affect most IP > devices. Since cell phones, IPSec & satellite use fragmented packets this > attack is pertinent to the Internet of today. > > The attack is simple. Two parts of a fragmented packet are sent to the > machine being attacked. The first fragment (payload 32 bytes long) is the > initial offset zero fragment of a SYN packet. The final (second) fragment > of the SYN packet is also 32 bytes in size, but is set to an offset of 64800 > bytes into the datagram. > > During my testing, I alternated this two fragment pattern rotating between > ICMP, TCP, UDP, ICMP, etc. All test fragments used the same source IP > address and fragment ID. > > Since this attack does not require a response from the target system, > the source IP address can be spoofed, thus hiding the attacker's true > location. Also note the source and destination ports do not matter as the > packet is never validated at the layer four level, it never gets past layer > three. The devices accept the packets no matter what port is used. > > Of the machines I have had access to, this attack has caused any number of > the following problems: > 1) Causes the CPU to spike, thus exhausting processor resources. > 2) Legitimate fragmented packets are dropped intermittently (unfragmented > packets get through fine) > 3) Legitimate fragmented packets are no longer accepted by the machine under > attack (unfragmented packets get through fine) until the fragmentation time > exceeded timers expire. > 4) Devices like Cisco routers can have Buffer overflow, i.e. packets are > dropped at high packet rates if there aren't enough buffers allocated. > > The following devices were tested and showed some or all of the above > symptoms: > 1) Microsoft Windows 2000 > 2) Mandrake Linux 9.2 > 2) Cisco 2621XM > 3) PIX Firewall > 4) Mac OS/X V10.2.8 (FreeBSD 5?) > > The following vendors have been notified of this condition prior to the > release of this announcement: > 1) Microsoft > 2) Cisco (2621XM only) > 3) Linux > > This can also be used in active fingerprinting as some OS's return a > "Fragmentation Reassembly Time exceeded", some do not, some return the first > fragments as assembly time exceeded, some return later packets. > > For the original discussion (excerpt from my larger SANS GCFW paper > http://www.giac.org/practical/GCFW/William_Hollis_GCFW.pdf ) please see: > http://gandalf.home.digital.net/Rose.rtf > > I have "cleaned up" the procedure since the original discussion. For the > test procedure to test this attack using Windows computers and suggestions > on how to mitigate this attack please see: > http://gandalf.home.digital.net/TestProc.txt > > For the support files please see: > http://gandalf.home.digital.net/nemITUrnd.xls > http://gandalf.home.digital.net/Picmpdata.txt > http://gandalf.home.digital.net/Ptcpdata.txt > http://gandalf.home.digital.net/Pudpdata.txt > > You will need WinPCap (of course) > WinPcap_3_0.exe > > http://www.packetfactory.net/projects/nemesis/ > nemesis-1.4beta3.zip on website > > NetWox > http://www.laurentconstantin.com/en/netw/netwox/ > I used: > netwox-5.11.0-bin_windows.tgz > > The suggested software solution to this attack is to: > 1) Allocate X*64k buffers upon NIC card initialization. Assuming X=200 > buffers this would equate to approximately 12 Mb > 2) Flush fragmented buffers in a FIFO fashion. > 3) Do not reassemble buffers until all have been received, then use the CPU > to reassemble the buffers. > > I would like to thank Chris Brenton for his help / input on this attack. > > Your comments on this attack are appreciated. > > Ken > > --------------------------------------------------------------- > Do not meddle in the affairs of wizards for they are subtle and > quick to anger. > Ken Hollis - Gandalf The White - gandalf@digital.net - O- TINLC > WWW Page - http://digital.net/~gandalf/ > Trace E-Mail forgery - http://digital.net/~gandalf/spamfaq.html > Trolls crossposts - http://digital.net/~gandalf/trollfaq.html > > ----- End forwarded message ----- > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 31 16:09:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E9BE16A4CF for ; Wed, 31 Mar 2004 16:09:12 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id DCF1443D39 for ; Wed, 31 Mar 2004 16:09:11 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 64702 invoked from network); 1 Apr 2004 00:09:10 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 1 Apr 2004 00:09:10 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 31 Mar 2004 18:09:09 -0600 (CST) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <406B3CC0.C277B933@freebsd.org> Message-ID: <20040331180359.G4941@odysseus.silby.com> References: <20040331205406.GD16803@madman.celabo.org> <406B3CC0.C277B933@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Jacques A. Vidrine" cc: freebsd-net@freebsd.org Subject: Re: Fwd: [IPv4 fragmentation --> The Rose Attack] 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 Apr 2004 00:09:12 -0000 On Wed, 31 Mar 2004, Andre Oppermann wrote: > We have the following sysctl's to withstand such an attack: > > net.inet.ip.maxfragpackets [800] > net.inet.ip.maxfragsperpacket [16] > > Which limits such an attack to 800 packets overall and 16 fragments > per packet. > > Of course, when the maxfragpackets limit is reached by malicous > packets we are unable to process legitimate fragmented IP packets > until the malicous ones start to time out. There is nothing else > one can do to fight off such an attack. > > -- > Andre Actually, once the limit is reached, packets are forced out in FIFO order. However, if the attack is continuous and of a high data rate, then it is possible that legitimate packets will be forced out of the queue before they can be fully reassembled. NetBSD has adopted a slightly different approach to the problem, they track the total number of fragments, then do a random purge of reassembly queues whenever the fragment count hits a certain threshold. I suspect that under a high bandwidth fragmentation attack, both approaches would be overwhelmed. I'm not sure what's really new about this "Rose Attack", it shouldn't affect 4.8+ FreeBSD machines much at all. I'm actually puzzled that his attack does anything at all, you can eat up a lot more memory using fragrouter and some creative ipfw rules. :) Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu Apr 1 11:40:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87E2E16A4CE for ; Thu, 1 Apr 2004 11:40:42 -0800 (PST) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by mx1.FreeBSD.org (Postfix) with SMTP id 7126243D2F for ; Thu, 1 Apr 2004 11:40:41 -0800 (PST) (envelope-from akio@despammed.com) Received: (qmail 31551 invoked from network); 1 Apr 2004 19:40:32 -0000 Received: from r065048.stusta.swh.mhn.de (HELO despammed.com) (10.150.65.48) by mailhub.stusta.mhn.de with SMTP; 1 Apr 2004 19:40:32 -0000 Message-ID: <406C702A.3030600@despammed.com> Date: Thu, 01 Apr 2004 21:40:26 +0200 From: Lutz Petersen User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: freebsd-net@freebsd.org References: <6686.1079661277@www27.gmx.net> <20040319193514.GB54073@blossom.cjclark.org> <406204AF.5050600@despammed.com> <20040329063117.GC73269@blossom.cjclark.org> In-Reply-To: <20040329063117.GC73269@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: BIND: Lookup of CNAME records 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 Apr 2004 19:40:42 -0000 I have installed BIND 9 now, and everything works like a charm. Presumably BIND 8 simply doesn't handle AAAA lookups correctly. Crist J. Clark wrote: > It looks like "fw" is messed up. Those responses don't carry any > authority records. The queries for the root servers are returning "no > error" with completely blank responses. From owner-freebsd-net@FreeBSD.ORG Thu Apr 1 22:13:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1A3016A4CE for ; Thu, 1 Apr 2004 22:13:07 -0800 (PST) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3C3543D41 for ; Thu, 1 Apr 2004 22:13:05 -0800 (PST) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i326CtrD066389; Fri, 2 Apr 2004 14:13:00 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <406D0456.64512D98@kuzbass.ru> Date: Fri, 02 Apr 2004 14:12:38 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Andrey Alekseyev References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: stable@freebd.org cc: net@freebsd.org Subject: Re: nfs_getpages: error 70 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 Apr 2004 06:13:08 -0000 [moving to -net from -stable] Andrey Alekseyev wrote: > > > If you'd like, try this patch (it may help for NFSv3 and certain > > usage patterns) > > http://blackflag.ru/patches/open-retry-stale.diff > > In addition you may also try this one: > http://blackflag.ru/patches/nfs_subs.c.diff > > In turn, this patch won't help you to solve your problem with a > stale filehandle, though allows for more fine grained control > over NFS attribute cache (see sysctl's description inside the patch) > and can be used in combination with the reopen-if-stale patch. > > Forgot to mention - both patches are for the NFS client. I've applied both patches (and defined Z_NFS_EXTENSIONS). It does not help. How do I handle it? I've tried to increase vfs.nfs.access_cache_agemin to 120, it does not help too. The same sympthoms remain. Eugene From owner-freebsd-net@FreeBSD.ORG Thu Apr 1 22:27:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B02516A4CE for ; Thu, 1 Apr 2004 22:27:41 -0800 (PST) Received: from jimi.ru (unknown [195.14.58.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id C414B43D46 for ; Thu, 1 Apr 2004 22:27:39 -0800 (PST) (envelope-from uitm@blackflag.ru) Received: from [195.14.58.203] (account uitm@blackflag.ru) by jimi.ru (CommuniGate Pro WebUser 4.1.8) with HTTP id 893296; Fri, 02 Apr 2004 10:27:37 +0400 From: "Andrey Alekseyev" To: Eugene Grosbein X-Mailer: CommuniGate Pro WebUser Interface v.4.1.8 Date: Fri, 02 Apr 2004 10:27:37 +0400 Message-ID: In-Reply-To: <406D0456.64512D98@kuzbass.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit cc: stable@freebd.org cc: net@freebsd.org Subject: Re: nfs_getpages: error 70 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 Apr 2004 06:27:41 -0000 > I've applied both patches (and defined Z_NFS_EXTENSIONS). > It does not help. How do I handle it? Did you set open_retry_stale sysctl to 1? From owner-freebsd-net@FreeBSD.ORG Thu Apr 1 22:42:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3BAC16A4CE for ; Thu, 1 Apr 2004 22:42:24 -0800 (PST) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BA3E43D55 for ; Thu, 1 Apr 2004 22:42:23 -0800 (PST) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i326gH58071249; Fri, 2 Apr 2004 14:42:17 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <406D0B38.83E389A8@kuzbass.ru> Date: Fri, 02 Apr 2004 14:42:00 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Andrey Alekseyev References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: nfs_getpages: error 70 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 Apr 2004 06:42:25 -0000 Andrey Alekseyev wrote: > > > I've applied both patches (and defined Z_NFS_EXTENSIONS). > > It does not help. How do I handle it? > > Did you set open_retry_stale sysctl to 1? Ops, mea culpa. I'll try. Eugene From owner-freebsd-net@FreeBSD.ORG Thu Apr 1 10:51:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F0ED16A4CE for ; Thu, 1 Apr 2004 10:51:44 -0800 (PST) Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by mx1.FreeBSD.org (Postfix) with SMTP id 0911143D1D for ; Thu, 1 Apr 2004 10:51:44 -0800 (PST) (envelope-from eickeaf@yahoo.com.br) Received: from unknown (HELO eicke) (eickeaf@200.162.114.126 with login) by smtp018.mail.yahoo.com with SMTP; 1 Apr 2004 18:51:43 -0000 Message-ID: <005e01c41819$cd1faa30$0905a8c0@alellyxbr.com.br> From: "Eicke Felipe" To: "FreeBSD_Net" Date: Thu, 1 Apr 2004 15:47:33 -0300 MIME-Version: 1.0 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 X-Mailman-Approved-At: Fri, 02 Apr 2004 06:26:53 -0800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: MRTG no SNMP 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 Apr 2004 18:51:44 -0000 Hi folks, Is There a way to configure MRTG no SNMP? Thanks and Regards. Eicke. From owner-freebsd-net@FreeBSD.ORG Fri Apr 2 04:06:32 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75F2616A4CE; Fri, 2 Apr 2004 04:06:32 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E44C43D2F; Fri, 2 Apr 2004 04:06:27 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i32C9wnZ089044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Apr 2004 15:09:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i32C6JL2010594; Fri, 2 Apr 2004 15:06:19 +0300 (EEST) (envelope-from ru) Date: Fri, 2 Apr 2004 15:06:19 +0300 From: Ruslan Ermilov To: Bill Paul Message-ID: <20040402120619.GA10105@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FkmkrVfFsRoUs1wW" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@FreeBSD.org Subject: [PATCH] TX algorithms, missetting IFF_OACTIVE and if_timer 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 Apr 2004 12:06:32 -0000 --FkmkrVfFsRoUs1wW Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Gang, I've been wading through several network drivers recently, learning Bill Paul's code. Specifically, I examined the following drivers: ste(4), rl(4), dc(4), nge(4), and vr(4). They all use the consumer/producer approach for handling TX. if_start() works with the producer, and txeof() works with the consumer. The condition (consumer =3D=3D producer) is when the TX ring is empty. To differentiate the case of an empty ring from the full ring, some drivers (ste(4), dc(4), and nge(4)) have the threshold (6 for dc(4), 3 for ste(4), and 2 for nge(4)) to assert the gap between producer and consumer, thus not allow the producer to catch the consumer. (The vr(4) is hairier, and I will not discuss it in detail here.) First, could you please explain these magic numbers? Also, some drivers use indexes for consumer and producer, where they could use "next" pointers, which should be faster. I also think that using the gap between producer/consumer is suboptimal, but this gap is part of the existing algorithm. Attached is the patch for ste(4) that converts its producer and consumer to be pointers rather than indexes (like in vr(4), but slightly differently, only using two pointers), drops the tx_cnt and removes the gap. The condition of an empty ring becomes "the mbuf pointer of the consumer is NULL". The patch also fixes the resetting of IFF_OACTIVE and if_timer. Before, it was possible for IFF_OACTIVE to be reset even if we didn't free any mbufs in ste_txeof() (this is most apparent in the DEVICE_POLLING case, when we call ste_txeof() periodically), and if_timer could be reset to zero even if we have some more TX work to do later. Attached also the patch for nge(4) that fixes resetting of IFF_OACTIVE and if_itimer in nge_txeof(). Previously, the if_timer was always bogusly reset to 0, and we could reset IFF_OACTIVE when we didn't free any mbufs (again, this is most apparent with DEVICE_POLLING -- we break out the loop if NGE_OWNDESC(cur_tx) bit is set, meaning that the current descriptor wasn't yet DMA'ed, and still treated this as if we did some TX work, and reset IFF_OACTIVE). (I didn't convert it to replace indexes with the pointers for consumer and producer, although this is possible, and should probably be faster.) The rl(4) is buggier: the TX ring is only 4 elements, and the driver does not have a producer/consumer gap, so the producer can catch the consumer, which itself is normal. So rl_txeof() always loops through TX list, but doesn't detect a case when the TX list is empty, resulting in PR kern/64975, visible under DEVICE_POLLING. Also, when TX list is full, we could break out the loop without freeing any mbufs, and still resetting if_timer to zero (Luigi attempted to fix this in rev. 1.71, but the fix is incomplete). Attached is the patch that should fix both issues. The dc(4) driver looks the most correct dealing with IFF_OACTIVE and if_timer. As an aside, lot of drivers that support auto-padding still have useless xx_pad[XX_MIN_FRAMELEN] element in their xx_chain_data structure, namely, dc(4), ste(4), and tl(4) have it. I think these were copied from some template driver, is it safe to remove them? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ste.patch" Content-Transfer-Encoding: quoted-printable Index: sys/pci/if_ste.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/pci/if_ste.c,v retrieving revision 1.67 diff -u -r1.67 if_ste.c --- sys/pci/if_ste.c 1 Apr 2004 12:55:38 -0000 1.67 +++ sys/pci/if_ste.c 2 Apr 2004 08:13:26 -0000 @@ -893,35 +893,23 @@ ste_txeof(sc) struct ste_softc *sc; { - struct ste_chain *cur_tx =3D NULL; + struct ste_chain *cur_tx; struct ifnet *ifp; - int idx; =20 ifp =3D &sc->arpcom.ac_if; =20 - idx =3D sc->ste_cdata.ste_tx_cons; - while(idx !=3D sc->ste_cdata.ste_tx_prod) { - cur_tx =3D &sc->ste_cdata.ste_tx_chain[idx]; - + cur_tx =3D sc->ste_cdata.ste_tx_cons; + while (cur_tx->ste_mbuf !=3D NULL) { if (!(cur_tx->ste_ptr->ste_ctl & STE_TXCTL_DMADONE)) break; - - if (cur_tx->ste_mbuf !=3D NULL) { - m_freem(cur_tx->ste_mbuf); - cur_tx->ste_mbuf =3D NULL; - } - + m_freem(cur_tx->ste_mbuf); + cur_tx->ste_mbuf =3D NULL; ifp->if_opackets++; - - sc->ste_cdata.ste_tx_cnt--; - STE_INC(idx, STE_TX_LIST_CNT); - ifp->if_timer =3D 0; - } - - sc->ste_cdata.ste_tx_cons =3D idx; - - if (cur_tx !=3D NULL) ifp->if_flags &=3D ~IFF_OACTIVE; + cur_tx =3D cur_tx->ste_next; + } + sc->ste_cdata.ste_tx_cons =3D cur_tx; + ifp->if_timer =3D (cur_tx->ste_mbuf =3D=3D NULL) ? 0 : 5; =20 return; } @@ -1280,22 +1268,13 @@ cd->ste_tx_chain[i].ste_phys =3D vtophys(&ld->ste_tx_list[i]); if (i =3D=3D (STE_TX_LIST_CNT - 1)) cd->ste_tx_chain[i].ste_next =3D + cd->ste_tx_prod =3D cd->ste_tx_cons =3D &cd->ste_tx_chain[0]; else cd->ste_tx_chain[i].ste_next =3D &cd->ste_tx_chain[i + 1]; - if (i =3D=3D 0) - cd->ste_tx_chain[i].ste_prev =3D - &cd->ste_tx_chain[STE_TX_LIST_CNT - 1]; - else - cd->ste_tx_chain[i].ste_prev =3D - &cd->ste_tx_chain[i - 1]; } =20 - cd->ste_tx_prod =3D 0; - cd->ste_tx_cons =3D 0; - cd->ste_tx_cnt =3D 0; - return; } =20 @@ -1379,7 +1358,7 @@ STE_SETBIT4(sc, STE_DMACTL, STE_DMACTL_TXDMA_UNSTALL); STE_SETBIT4(sc, STE_DMACTL, STE_DMACTL_TXDMA_UNSTALL); ste_wait(sc); - sc->ste_tx_prev_idx=3D-1; + sc->ste_tx_prev =3D NULL; =20 /* Enable receiver and transmitter */ CSR_WRITE_2(sc, STE_MACCTL0, 0); @@ -1610,8 +1589,7 @@ { struct ste_softc *sc; struct mbuf *m_head =3D NULL; - struct ste_chain *cur_tx =3D NULL; - int idx; + struct ste_chain *cur_tx; =20 sc =3D ifp->if_softc; STE_LOCK(sc); @@ -1626,27 +1604,19 @@ return; } =20 - idx =3D sc->ste_cdata.ste_tx_prod; - - while(sc->ste_cdata.ste_tx_chain[idx].ste_mbuf =3D=3D NULL) { - - if ((STE_TX_LIST_CNT - sc->ste_cdata.ste_tx_cnt) < 3) { - ifp->if_flags |=3D IFF_OACTIVE; - break; - } + cur_tx =3D sc->ste_cdata.ste_tx_prod; + while (cur_tx->ste_mbuf =3D=3D NULL) { =20 IF_DEQUEUE(&ifp->if_snd, m_head); if (m_head =3D=3D NULL) break; =20 - cur_tx =3D &sc->ste_cdata.ste_tx_chain[idx]; - if (ste_encap(sc, cur_tx, m_head) !=3D 0) break; =20 cur_tx->ste_ptr->ste_next =3D 0; =20 - if(sc->ste_tx_prev_idx < 0){ + if (sc->ste_tx_prev =3D=3D NULL) { cur_tx->ste_ptr->ste_ctl =3D STE_TXCTL_DMAINTR | 1; /* Load address of the TX list */ STE_SETBIT4(sc, STE_DMACTL, STE_DMACTL_TXDMA_STALL); @@ -1662,12 +1632,11 @@ ste_wait(sc); }else{ cur_tx->ste_ptr->ste_ctl =3D STE_TXCTL_DMAINTR | 1; - sc->ste_cdata.ste_tx_chain[ - sc->ste_tx_prev_idx].ste_ptr->ste_next + sc->ste_tx_prev->ste_ptr->ste_next =3D cur_tx->ste_phys; } =20 - sc->ste_tx_prev_idx=3Didx; + sc->ste_tx_prev =3D cur_tx; =20 /* * If there's a BPF listener, bounce a copy of this frame @@ -1675,11 +1644,13 @@ */ BPF_MTAP(ifp, cur_tx->ste_mbuf); =20 - STE_INC(idx, STE_TX_LIST_CNT); - sc->ste_cdata.ste_tx_cnt++; ifp->if_timer =3D 5; - sc->ste_cdata.ste_tx_prod =3D idx; + cur_tx =3D cur_tx->ste_next; } + + if (cur_tx->ste_mbuf !=3D NULL) + ifp->if_flags |=3D IFF_OACTIVE; + sc->ste_cdata.ste_tx_prod =3D cur_tx; =20 STE_UNLOCK(sc); =20 Index: sys/pci/if_stereg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/pci/if_stereg.h,v retrieving revision 1.13 diff -u -r1.13 if_stereg.h --- sys/pci/if_stereg.h 31 Mar 2004 20:39:20 -0000 1.13 +++ sys/pci/if_stereg.h 2 Apr 2004 07:11:41 -0000 @@ -467,8 +467,6 @@ #define ETHER_ALIGN 2 #define STE_RX_LIST_CNT 64 #define STE_TX_LIST_CNT 64 -#define STE_INC(x, y) (x) =3D (x + 1) % y -#define STE_NEXT(x, y) (x + 1) % y =20 struct ste_type { u_int16_t ste_vid; @@ -486,7 +484,6 @@ struct ste_desc *ste_ptr; struct mbuf *ste_mbuf; struct ste_chain *ste_next; - struct ste_chain *ste_prev; u_int32_t ste_phys; }; =20 @@ -501,9 +498,8 @@ struct ste_chain ste_tx_chain[STE_TX_LIST_CNT]; struct ste_chain_onefrag *ste_rx_head; =20 - int ste_tx_prod; - int ste_tx_cons; - int ste_tx_cnt; + struct ste_chain *ste_tx_prod; + struct ste_chain *ste_tx_cons; }; =20 struct ste_softc { @@ -520,7 +516,7 @@ int ste_tx_thresh; u_int8_t ste_link; int ste_if_flags; - int ste_tx_prev_idx; + struct ste_chain *ste_tx_prev; struct ste_list_data *ste_ldata; struct ste_chain_data ste_cdata; struct callout_handle ste_stat_ch; --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nge.patch" Content-Transfer-Encoding: quoted-printable Index: sys/dev/nge/if_nge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/dev/nge/if_nge.c,v retrieving revision 1.55 diff -u -r1.55 if_nge.c --- sys/dev/nge/if_nge.c 30 Mar 2004 10:24:52 -0000 1.55 +++ sys/dev/nge/if_nge.c 2 Apr 2004 11:20:16 -0000 @@ -1418,9 +1418,6 @@ =20 ifp =3D &sc->arpcom.ac_if; =20 - /* Clear the timeout timer. */ - ifp->if_timer =3D 0; - /* * Go through our tx list and free mbufs for those * frames that have been transmitted. @@ -1457,13 +1454,14 @@ =20 sc->nge_cdata.nge_tx_cnt--; NGE_INC(idx, NGE_TX_LIST_CNT); - ifp->if_timer =3D 0; } =20 - sc->nge_cdata.nge_tx_cons =3D idx; - - if (cur_tx !=3D NULL) + if (idx !=3D sc->nge_cdata.nge_tx_cons) { + /* Some buffers have been freed. */ + sc->nge_cdata.nge_tx_cons =3D idx; ifp->if_flags &=3D ~IFF_OACTIVE; + } + ifp->if_timer =3D (idx =3D=3D sc->nge_cdata.nge_tx_prod) ? 0 : 5; =20 return; } --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rl.patch" Content-Transfer-Encoding: quoted-printable Index: sys/pci/if_rl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/pci/if_rl.c,v retrieving revision 1.133 diff -u -r1.133 if_rl.c --- sys/pci/if_rl.c 17 Mar 2004 17:50:53 -0000 1.133 +++ sys/pci/if_rl.c 2 Apr 2004 09:57:11 -0000 @@ -1359,6 +1359,8 @@ * frames that have been uploaded. */ do { + if (RL_LAST_TXMBUF(sc) =3D=3D NULL) + break; txstat =3D CSR_READ_4(sc, RL_LAST_TXSTAT(sc)); if (!(txstat & (RL_TXSTAT_TX_OK| RL_TXSTAT_TX_UNDERRUN|RL_TXSTAT_TXABRT))) @@ -1366,12 +1368,10 @@ =20 ifp->if_collisions +=3D (txstat & RL_TXSTAT_COLLCNT) >> 24; =20 - if (RL_LAST_TXMBUF(sc) !=3D NULL) { - bus_dmamap_unload(sc->rl_tag, RL_LAST_DMAMAP(sc)); - bus_dmamap_destroy(sc->rl_tag, RL_LAST_DMAMAP(sc)); - m_freem(RL_LAST_TXMBUF(sc)); - RL_LAST_TXMBUF(sc) =3D NULL; - } + bus_dmamap_unload(sc->rl_tag, RL_LAST_DMAMAP(sc)); + bus_dmamap_destroy(sc->rl_tag, RL_LAST_DMAMAP(sc)); + m_freem(RL_LAST_TXMBUF(sc)); + RL_LAST_TXMBUF(sc) =3D NULL; if (txstat & RL_TXSTAT_TX_OK) ifp->if_opackets++; else { @@ -1396,8 +1396,7 @@ ifp->if_flags &=3D ~IFF_OACTIVE; } while (sc->rl_cdata.last_tx !=3D sc->rl_cdata.cur_tx); =20 - ifp->if_timer =3D - (sc->rl_cdata.last_tx =3D=3D sc->rl_cdata.cur_tx) ? 0 : 5; + ifp->if_timer =3D (RL_LAST_TXMBUF(sc) =3D=3D NULL) ? 0 : 5; =20 return; } --PEIAKu/WMn1b1Hv9-- --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAbVc7Ukv4P6juNwoRAol6AJ9NqFPyJEs4QcZC8gcSC/xIfL927wCfWWRq Wvh/a/8UgfHjG/qMbNc4k+k= =6hAN -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 2 09:03:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id C227F16A4CF; Fri, 2 Apr 2004 09:03:02 -0800 (PST) In-Reply-To: <20040402120619.GA10105@ip.net.ua> from Ruslan Ermilov at "Apr 2, 2004 03:06:19 pm" To: ru@FreeBSD.org (Ruslan Ermilov) Date: Fri, 2 Apr 2004 09:03:02 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20040402170302.C227F16A4CF@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: net@FreeBSD.org Subject: Re: [PATCH] TX algorithms, missetting IFF_OACTIVE and if_timer 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 Apr 2004 17:03:02 -0000 > Gang, > > I've been wading through several network drivers recently, > learning Bill Paul's code. Specifically, I examined the > following drivers: ste(4), rl(4), dc(4), nge(4), and vr(4). > > They all use the consumer/producer approach for handling TX. > if_start() works with the producer, and txeof() works with > the consumer. The condition (consumer == producer) is when > the TX ring is empty. To differentiate the case of an empty > ring from the full ring, some drivers (ste(4), dc(4), and > nge(4)) have the threshold (6 for dc(4), 3 for ste(4), and > 2 for nge(4)) to assert the gap between producer and consumer, > thus not allow the producer to catch the consumer. (The > vr(4) is hairier, and I will not discuss it in detail here.) > > First, could you please explain these magic numbers? Not really, no. Very often, values were chosen because they worked (and in some cases, they weren't chosen by me). > Also, some drivers use indexes for consumer and producer, > where they could use "next" pointers, which should be faster. "Should" be faster? I'm not saying you're wrong, but can you prove that it's faster to use lists? I started out using linked lists for descriptors, but then I started to encounter chips that used producer/consumer indexes internally (like the Adaptec 'starfire' chip and the Tigon II). I decided that since I tended to allocate all of the descriptors in contiguous chunks anyway, it was simpler to just treat them as arrays and use index counters. > I also think that using the gap between producer/consumer is > suboptimal, but this gap is part of the existing algorithm. Nowhere is it written that you can't change the algorithm. :) Note that if you're looking for approval from me to check in these patches, don't bother: I will neither approve nor disapprove. The only way for me to know if your changes are correct is to test them, and I don't have the time or resources right now to do that. If you want to commit them, go ahead. It's your funeral. :) > As an aside, lot of drivers that support auto-padding > still have useless xx_pad[XX_MIN_FRAMELEN] element in > their xx_chain_data structure, namely, dc(4), ste(4), > and tl(4) have it. I think these were copied from > some template driver, is it safe to remove them? If nothing references them, sure. Note that there is no "template driver." I write new drivers by choosing an existing driver that most closely matches the design of the chip I need to support, run it through sed(1) to change its name, strip out all the device-dependent stuff specific to the old device and replace it with stuff for the new device. And then the stork comes, and it's a driver. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-net@FreeBSD.ORG Fri Apr 2 14:52:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 132D216A4CE for ; Fri, 2 Apr 2004 14:52:37 -0800 (PST) Received: from trueband.net (director.trueband.net [216.163.120.8]) by mx1.FreeBSD.org (Postfix) with SMTP id 1895843D2D for ; Fri, 2 Apr 2004 14:52:36 -0800 (PST) (envelope-from jhall@vandaliamo.net) Received: (qmail 1189 invoked by uid 1006); 2 Apr 2004 22:52:34 -0000 Received: from jhall@vandaliamo.net by rs0 by uid 1003 with qmail-scanner-1.16 (spamassassin: 2.44. Clear:SA:0(-4.9/100.0):. Processed in 1.55372 secs); 02 Apr 2004 22:52:34 -0000 X-Spam-Status: No, hits=-4.9 required=100.0 X-Spam-Level: Received: from unknown (HELO trueband.net) (127.0.0.1) by -v with SMTP; 2 Apr 2004 22:52:33 -0000 Received: (qmail 1112 invoked from network); 2 Apr 2004 22:52:32 -0000 Received: from unknown (HELO vandaliamo.net) (12.170.206.13) by -v with SMTP; 2 Apr 2004 22:52:32 -0000 Message-ID: <406DEF54.1020301@vandaliamo.net> Date: Fri, 02 Apr 2004 16:55:16 -0600 From: Jay Hall User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Bretterklieber References: <40679626.1040104@vandaliamo.net> <40682776.5000104@vandaliamo.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: PPTP MTU - SOLVED 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 Apr 2004 22:52:37 -0000 Yes, you are correct. I had mistyped a route and was trying to add 192.168.40.0/2 instead of 192.168.40.0/24. Thanks for your help. I think I had looked at that long enough that I would have never found the problem. Jay Michael Bretterklieber wrote: > Hi, > > it looks everything is ok, until your routes were added. Could you try > this without these routes? > > On Mon, 29 Mar 2004, Jay Hall wrote: > >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: Up event >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: state change Starting --> >>Req-Sent >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] IPCP: SendConfigReq #1 >>Mar 29 06:37:37 ST_CHARLES mpd: IPADDR 10.129.10.101 >>Mar 29 06:37:37 ST_CHARLES mpd: COMPPROTO VJCOMP, 16 comp. channels, no >>comp-cid >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Open event >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: state change Initial --> >>Starting >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: LayerStart >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] CCP: Up event > > ... > >>bytes >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/ifconfig ng1 >>10.129.10.101 10.129.10.40 netmask 0xffffffff -link0 >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add >>10.129.10.101 -iface lo0 >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.10.0 >>10.129.10.40 -netmask 0xffffff00 >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.30.0 >>10.129.10.40 -netmask 0xffffff00 >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.40.0 >>10.129.10.40 -netmask 0xffffff00 >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.50.0 >>10.129.10.40 -netmask 0xffffff00 >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.60.0 >>10.129.10.40 -netmask 0xffffff00 >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.129.70.0 >>10.129.10.40 -netmask 0xffffff00 >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 10.128.10.0 >>10.129.10.40 -netmask 0xffffff00 >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 192.0.0.0 >>10.129.10.40 -netmask 0xc0000000 >>Mar 29 06:37:37 ST_CHARLES mpd: [vpn] exec: /sbin/route add 172.16.8.0 >>10.129.10.40 -netmask 0xfffff800 >>Mar 29 06:37:38 ST_CHARLES mpd: [vpn] exec: /etc/iface-up.sh ng1 inet >>10.129.10.101 10.129.10.40 > > ... > >>Mar 29 06:37:38 ST_CHARLES mpd: 0x01000040: MPPE, 128 bit, stateless >>Mar 29 06:37:38 ST_CHARLES mpd: [vpn] error writing len 14 frame to >>bypass: Resource deadlock avoided > > > bye, > -- > ------------------------------- ---------------------------------- > Michael Bretterklieber - http://www.bretterklieber.com > A-Quadrat Automation GmbH - http://www.a-quadrat.at > Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 > ------------------------------- ---------------------------------- > "...the number of UNIX installations has grown to 10, with more > expected..." - Dennis Ritchie and Ken Thompson, June 1972 > > From owner-freebsd-net@FreeBSD.ORG Fri Apr 2 15:19:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA8D016A4CE for ; Fri, 2 Apr 2004 15:19:43 -0800 (PST) Received: from web60810.mail.yahoo.com (web60810.mail.yahoo.com [216.155.196.73]) by mx1.FreeBSD.org (Postfix) with SMTP id 3C3B943D39 for ; Fri, 2 Apr 2004 15:19:43 -0800 (PST) (envelope-from richard_bejtlich@yahoo.com) Message-ID: <20040402231942.30375.qmail@web60810.mail.yahoo.com> Received: from [208.235.153.34] by web60810.mail.yahoo.com via HTTP; Fri, 02 Apr 2004 15:19:42 PST Date: Fri, 2 Apr 2004 15:19:42 -0800 (PST) From: Richard Bejtlich To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: IPSec troubles 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 Apr 2004 23:19:43 -0000 Hello, This thread has been very helpful. I'm using FreeBSD 5.2.1 REL with kernels recompiled to support IPSEC. I've found the "trick" to exclude port 500 UDP packets allows ISAKMP traffic to be exchanged, e.g: spdadd 192.168.20.1[500] 192.168.21.1[500] udp -P out none; spdadd 192.168.21.1[500] 192.168.20.1[500] udp -P in none; Unfortunately, I cannot follow this ipsec.conf entry with something like this for 'any' protocol: spdadd 192.168.20.1 192.168.21.1 any -P out ipsec esp/tunnel/192.168.20.1-192.168.21.1/require; spdadd 192.168.21.1 192.168.20.1 any -P in ipsec esp/tunnel/192.168.21.1-192.168.20.1/require; If I try to ping 192.168.20.1 from 192.168.21.1, I get this error on 192.168.20.1 from racoon: 2004-04-02 18:10:43: ERROR: isakmp_quick.c:2064:get_proposal_r(): policy found, but no IPsec required: 192.168.20.1/32[0] 192.168.21.1/32[0] proto=any dir=out 2004-04-02 18:10:43: ERROR: isakmp_quick.c:1071:quick_r1recv(): failed to get proposal for responder. 2004-04-02 18:10:43: ERROR: isakmp.c:1061:isakmp_ph2begin_r(): failed to pre-process packet. No traffic is exchanged. I've found that replacing the 'any' entry in the ipsec.conf with new entries for 'icmp' and 'tcp' allow those protocols to be protected by IPSec, e.g. for tcp: spdadd 192.168.20.1 192.168.21.1 tcp -P out ipsec esp/tunnel/192.168.20.1-192.168.21.1/require; spdadd 192.168.21.1 192.168.20.1 tcp -P in ipsec esp/tunnel/192.168.21.1-192.168.20.1/require; Unfortunately, I can't add an entry for 'udp' as that appears to conflict with the udp entry for port 500. I tried 'ip' in place of 'any', but that didn't seem to encrypt any traffic at all. Is my only alternative to upgrade from 5.2.1 to CURRENT if I want everything to be protected by IPSec (besides ISAKMP)? Thank you, Richard http://www.taosecurity.com __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From owner-freebsd-net@FreeBSD.ORG Fri Apr 2 15:50:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B950016A4CE; Fri, 2 Apr 2004 15:50:03 -0800 (PST) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D42E143D1D; Fri, 2 Apr 2004 15:50:02 -0800 (PST) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i32NrYMS023919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Apr 2004 02:53:36 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i32NnrAH000794; Sat, 3 Apr 2004 02:49:53 +0300 (EEST) (envelope-from ru) Date: Sat, 3 Apr 2004 02:49:52 +0300 From: Ruslan Ermilov To: Bill Paul Message-ID: <20040402234952.GA743@ip.net.ua> References: <20040402120619.GA10105@ip.net.ua> <20040402170302.C227F16A4CF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20040402170302.C227F16A4CF@hub.freebsd.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@FreeBSD.ORG Subject: Re: [PATCH] TX algorithms, missetting IFF_OACTIVE and if_timer 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 Apr 2004 23:50:03 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 02, 2004 at 09:03:02AM -0800, Bill Paul wrote: [...] > > To differentiate the case of an empty > > ring from the full ring, some drivers (ste(4), dc(4), and > > nge(4)) have the threshold (6 for dc(4), 3 for ste(4), and > > 2 for nge(4)) to assert the gap between producer and consumer, > > thus not allow the producer to catch the consumer. (The > > vr(4) is hairier, and I will not discuss it in detail here.) > >=20 > > First, could you please explain these magic numbers? >=20 > Not really, no. Very often, values were chosen because they worked > (and in some cases, they weren't chosen by me). >=20 Hmm, well, at least I now know (learned the hard way) why the gap is ever necessary -- I will just silently join the crew who keep this secret, and don't tell it to anyone. ;) > > Also, some drivers use indexes for consumer and producer, > > where they could use "next" pointers, which should be faster. >=20 > "Should" be faster? I'm not saying you're wrong, but can you prove > that it's faster to use lists? I started out using linked lists > for descriptors, but then I started to encounter chips that used > producer/consumer indexes internally (like the Adaptec 'starfire' > chip and the Tigon II). I decided that since I tended to allocate > all of the descriptors in contiguous chunks anyway, it was simpler > to just treat them as arrays and use index counters. >=20 I experimented with ste(4) today -- except for getting 200 bytes less driver code when converting to use the precomputed pointers, I didn't notice any change in performance, so I threw my changes away. ;) > > I also think that using the gap between producer/consumer is > > suboptimal, but this gap is part of the existing algorithm. >=20 > Nowhere is it written that you can't change the algorithm. :) >=20 Now I know (I wish you'd tell me it) why the gap is necessary, but let's keep this secret. ;) > Note that if you're looking for approval from me to check in these > patches, don't bother: I will neither approve nor disapprove. The > only way for me to know if your changes are correct is to test them, > and I don't have the time or resources right now to do that. If you > want to commit them, go ahead. It's your funeral. :) >=20 Understood. This is some ancient code, and you have lot of modern stuff to play with. ;) Actually, I was just looking for your advise and your vision. [...] > And then the stork comes, and it's a driver. >=20 *LOL* Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAbfwgUkv4P6juNwoRAs7FAJ9fdEzzBnnK1LpQgZMOqoAisrMz4QCgiycJ /G59CWaywsXzgm3RyOoW1ro= =rOka -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 2 19:36:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE83A16A4CE for ; Fri, 2 Apr 2004 19:36:13 -0800 (PST) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23ABA43D55 for ; Fri, 2 Apr 2004 19:36:12 -0800 (PST) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.11/8.12.11) with ESMTP id i333a7nV000605; Sat, 3 Apr 2004 11:36:07 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i333a6S0000604; Sat, 3 Apr 2004 11:36:06 +0800 (KRAST) (envelope-from eugen) Date: Sat, 3 Apr 2004 11:36:06 +0800 From: Eugene Grosbein To: Eicke Felipe Message-ID: <20040403033606.GA571@grosbein.pp.ru> References: <005e01c41819$cd1faa30$0905a8c0@alellyxbr.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005e01c41819$cd1faa30$0905a8c0@alellyxbr.com.br> User-Agent: Mutt/1.4.1i cc: FreeBSD_Net Subject: Re: MRTG no SNMP 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 Apr 2004 03:36:13 -0000 On Thu, Apr 01, 2004 at 03:47:33PM -0300, Eicke Felipe wrote: > Is There a way to configure MRTG no SNMP? Yes. Just read its documentation. And this question isn't for this list. Eugene From owner-freebsd-net@FreeBSD.ORG Fri Apr 2 22:42:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF79A16A4CE for ; Fri, 2 Apr 2004 22:42:20 -0800 (PST) Received: from ctb-mesg6.saix.net (ctb-mesg6.saix.net [196.25.240.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2773A43D1F for ; Fri, 2 Apr 2004 22:42:20 -0800 (PST) (envelope-from karnaugh@karnaugh.za.net) Received: from karnaugh.za.net (ndn-ip-nas-1-p136.telkom-ipnet.co.za [155.239.192.136]) by ctb-mesg6.saix.net (Postfix) with ESMTP id 8D33E64D1; Sat, 3 Apr 2004 08:42:11 +0200 (SAST) Message-ID: <406E5CD1.4000805@karnaugh.za.net> Date: Sat, 03 Apr 2004 08:42:25 +0200 From: Colin Alston User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eugene Grosbein References: <005e01c41819$cd1faa30$0905a8c0@alellyxbr.com.br> <20040403033606.GA571@grosbein.pp.ru> In-Reply-To: <20040403033606.GA571@grosbein.pp.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD_Net cc: Eicke Felipe Subject: Re: MRTG no SNMP 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 Apr 2004 06:42:20 -0000 Eugene Grosbein wrote: > On Thu, Apr 01, 2004 at 03:47:33PM -0300, Eicke Felipe wrote: > > >>Is There a way to configure MRTG no SNMP? > > > Yes. Just read its documentation. And this question isn't for this list. > I disagree a bit, as this can be quite an interesting topic You can use ipfw counters and write a script to retrieve data for graphing, as with system load and memory etc, even disk space. Yes, details of doing the base scripting is in the MRTG documents ;) You can use sed/awk/grep to output the data correctly, or write a python/perl script that does it. Or see mrtg-tools. -- A tout le monde, a tous mes amis. Je vous aime. Je dois partir Ce sont les derniers mots que je parlerai jamais et elles me placeront libre. From owner-freebsd-net@FreeBSD.ORG Sat Apr 3 12:28:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3693F16A4CE for ; Sat, 3 Apr 2004 12:28:00 -0800 (PST) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.FreeBSD.org (Postfix) with SMTP id 102AB43D1D for ; Sat, 3 Apr 2004 12:27:59 -0800 (PST) (envelope-from ofsen@enderunix.org) Received: (qmail 72028 invoked by uid 89); 3 Apr 2004 20:28:00 -0000 Message-ID: <20040403202800.72025.qmail@istanbul.enderunix.org> From: Omer Faruk Sen To: freebsd-net@freebsd.org Date: Sat, 03 Apr 2004 23:27:59 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-9" Content-Transfer-Encoding: 7bit Subject: mpd and pptpclient 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 Apr 2004 20:28:00 -0000 I am trying to use pptpclient but on my mpd server when I try to send package (such as pinging mpd server) I get those errors on the mpd server. I have no idea why can that be... Any comments? ptp1] rec'd unexpected protocol 0x00b1 on link -1, rejecting [pptp1] rec'd proto 0xe21d on MP link! (ignoring) [pptp1] rec'd unexpected protocol 0xa0ab on link -1, rejecting [pptp1] rec'd unexpected protocol 0x0007 on link -1, rejecting [pptp1] rec'd unexpected protocol 0x00dd on link -1, rejecting [pptp1] rec'd unexpected protocol 0x0035 on link -1, rejecting [pptp1] rec'd unexpected protocol 0x0a8d on link -1, rejecting [pptp1] rec'd unexpected protocol 0x00b7 on link -1, rejecting [pptp1] rec'd unexpected protocol 0x56db on link -1, rejecting [pptp1] rec'd unexpected protocol 0x00df on link -1, rejecting [pptp1] rec'd unexpected protocol 0xba57 on link -1, rejecting [pptp1] rec'd unexpected protocol 0x004f on link -1, rejecting [pptp1] rec'd unexpected protocol 0x0081 on link -1, rejecting [pptp1] rec'd unexpected protocol CRYPT on link -1, rejecting [pptp1] rec'd unexpected protocol 0x009d on link -1, rejecting ----------------------- Omer Faruk Sen http://www.EnderUNIX.ORG Software Development Team @ Turkey http://www.Faruk.NET For Public key: http://www.enderunix.org/ofsen/ofsen.asc ******************************************************** From owner-freebsd-net@FreeBSD.ORG Sat Apr 3 12:38:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8EC016A4CE for ; Sat, 3 Apr 2004 12:38:25 -0800 (PST) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8147D43D41 for ; Sat, 3 Apr 2004 12:38:25 -0800 (PST) (envelope-from rneese@adelphia.net) Received: from 69-160-8-12.bflony.adelphia.net ([69.160.8.12]) by mta10.adelphia.netESMTP <20040403203824.KFJN20146.mta10.adelphia.net@69-160-8-12.bflony.adelphia.net> for ; Sat, 3 Apr 2004 15:38:24 -0500 From: Richard Neese To: freebsd-net@freebsd.org Date: Sat, 3 Apr 2004 15:38:20 -0500 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200404031538.21333.rneese@adelphia.net> Subject: Driver for ADMTek wireless 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 Apr 2004 20:38:25 -0000 I am hoping this is the right list to get help with a driver for the admtek adm8211 chipset wireless cardlinksys and dlink use this chip on a few of thier newer cards mine is a generic card WP2K. there is a driver in netbsd its called atw driver. I would like to see this driver ported to fbsd I am not a programmer but I have 20 of these cards. the d-link ver with the 2 geneic cards also. From owner-freebsd-net@FreeBSD.ORG Sat Apr 3 13:39:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBD1916A4CE for ; Sat, 3 Apr 2004 13:39:14 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB6EE43D49 for ; Sat, 3 Apr 2004 13:39:14 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i33LdDgd067474; Sat, 3 Apr 2004 13:39:13 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i33LdDjY067473; Sat, 3 Apr 2004 13:39:13 -0800 (PST) (envelope-from rizzo) Date: Sat, 3 Apr 2004 13:39:13 -0800 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20040403133913.A67287@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: removal of unused and redundant fields in 'struct ifnet' 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 Apr 2004 21:39:15 -0000 Hi, in -current, I am about to remove the following unused fields from 'struct ifnet', hope there are no objections: - int (*if_done) /* output complete routine */ - (struct ifnet *); /* (XXX not used; fake prototype) */ - int (*if_poll_recv) /* polled receive routine */ - (struct ifnet *, int *); - int (*if_poll_xmit) /* polled transmit routine */ - (struct ifnet *, int *); - void (*if_poll_intren) /* polled interrupt reenable routine */ - (struct ifnet *); - void (*if_poll_slowinput) /* input routine for slow devices */ - (struct ifnet *, struct mbuf *); - struct ifqueue *if_poll_slowq; /* input queue for slow devices */ On passing, i also note that the following fields are only used by IPv6, and they seem quite redundant (and space-consuming! AF_MAX is 36) struct ifprefixhead if_prefixhead; /* list of prefixes per if */ void *if_afdata[AF_MAX]; int if_afdata_initialized; struct mtx if_afdata_mtx; I suppose all of this could go into a 'struct inet6_data *', using the lock on the struct ifnet for the initial creation, and an additional lock inside the struct for specific ops. While this is not a change i plan to make soon, at some point in the future I would like to fix this too. comments ? cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Apr 3 17:52:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FA1216A4CE; Sat, 3 Apr 2004 17:52:21 -0800 (PST) Received: from catapult.dreamscape.com (catapult.dreamscape.com [206.64.128.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD7E943D5E; Sat, 3 Apr 2004 17:52:20 -0800 (PST) (envelope-from m.mcdonald@computer.org) Received: from mail2.dreamscape.com (mail2.dreamscape.com [206.64.128.18]) i341qJfJ026091; Sat, 3 Apr 2004 20:52:19 -0500 (EST) Received: from MICHAELIWZHLNY (pool-141-149-206-40.syr.east.verizon.net [141.149.206.40])i341qIwS028236; Sat, 3 Apr 2004 20:52:18 -0500 (EST) Message-ID: <002401c419e7$76692ac0$2f01a8c0@MICHAELIWZHLNY> From: "Michael McDonald" To: , , Date: Sat, 3 Apr 2004 20:52:02 -0500 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 Subject: Request for Cluster Recommendations X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Michael McDonald List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 01:52:21 -0000 I'm planning a small, experimental cluster running FreeBSD 5. Currently running 5.2 on a dual XEON box which I intend to use as my workstation/head node. I'm looking at gigabit ethernet for the interconnect and a backup 10/100 ethernet for "overhead" print server, internet traffic etc. as hubs are priced way cheap and NICs are standard equipment with most cpu boxes. The budget is about $5K for the "starter kit" to include 4 nodes, switch, cabling and ups. Could be stretched to $10K, but it's a big stretch. I'm looking for recommendations at any level: hardware: managed/unmanaged switch? specific brands/models? diskless nodes? network attached storage processor speed vs. memory capacity vs. comm. speed software: job submission/control node autoconfiguration light, efficient comm. protocols lam vs. mpich (currently using lam) literature citations/simulation reports Anyone know of a FreeBSD version of the 9grid project? ( http://www.9grid.net ) The project is beginning as coursework towards a master's degree. Hope to have it at a production level soon. Apologies to the smp list for not exacly being exactly on topic, but I hope you can weigh in on MPI related issues. Thanks, Mike McDonald