From owner-freebsd-net@FreeBSD.ORG Mon Jan 23 11:02:47 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 0BB3016A420 for ; Mon, 23 Jan 2006 11:02:47 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC29843D80 for ; Mon, 23 Jan 2006 11:02:35 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0NB2Xfe086323 for ; Mon, 23 Jan 2006 11:02:33 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0NB2WdR086316 for freebsd-net@freebsd.org; Mon, 23 Jan 2006 11:02:32 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 23 Jan 2006 11:02:32 GMT Message-Id: <200601231102.k0NB2WdR086316@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 Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 11:02:47 -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] [patch] NFS root configurations wit o [2005/11/03] kern/88450 net SYN+ACK reports strange size of window 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 23 19:27:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2849816A41F for ; Mon, 23 Jan 2006 19:27:11 +0000 (GMT) (envelope-from tiagocruz@b4br.net) Received: from vader.b4br.net (vader.b4br.net [200.152.202.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A34B43D46 for ; Mon, 23 Jan 2006 19:27:09 +0000 (GMT) (envelope-from tiagocruz@b4br.net) Received: from localhost (localhost.b4br.net [127.0.0.1]) by vader.b4br.net (Postfix) with ESMTP id 22E81181478 for ; Mon, 23 Jan 2006 17:21:57 -0200 (BRST) Received: from vader.b4br.net ([127.0.0.1]) by localhost (vader.b4br.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99602-08-3 for ; Mon, 23 Jan 2006 17:21:50 -0200 (BRST) Received: from tuxkiller.matter.b4br.net (yoda.b4br.net [200.152.202.10]) by vader.b4br.net (Postfix) with ESMTP id A366C181428 for ; Mon, 23 Jan 2006 17:21:41 -0200 (BRST) From: Tiago Cruz To: freebsd-net@freebsd.org Content-Type: text/plain Date: Mon, 23 Jan 2006 17:26:52 -0200 Message-Id: <1138044412.4224.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at b4br.net Subject: VPN when host is not gateway X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 19:27:11 -0000 Hello all! In the FreeBSD 6.0, I've tried put the OpenVPN and/ or IPSec in one non-gateway host, but I have some doubts to make this, I'll try explain: If I install the VPN in my gateway (192.168.0.1), the laptop client host (Windows XP) is able to ping my virtual server (10.8.0.1), my gateway (192.168.0.1) and all my LAN (192.168.0.0/22). If I install the VPN in my gateway backup (192.168.0.253, with CARP), the laptop client is able to ping my virtual server (10.8.0.1), my gateway (192.168.0.1) but NOT is able to ping my LAN (192.168.0.0/22). I think that is missing some route, and because this I go to get some tip... Very thanks, Brazilian Regards -- Tiago Cruz http://linuxrapido.org Linux User #282636 "The box said: Requires MS Windows or better, so I installed Linux" From owner-freebsd-net@FreeBSD.ORG Mon Jan 23 20:10:45 2006 Return-Path: X-Original-To: net@FreeBSD.org 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 1658616A488 for ; Mon, 23 Jan 2006 20:10:43 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFF4E43E28 for ; Mon, 23 Jan 2006 19:39:43 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id BE3331A3C20; Mon, 23 Jan 2006 11:39:43 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id DCC575122E; Mon, 23 Jan 2006 14:39:42 -0500 (EST) Date: Mon, 23 Jan 2006 14:39:42 -0500 From: Kris Kennaway To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20060123193942.GA44622@xor.obsecurity.org> References: <20060116004438.GA27901@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: net@FreeBSD.org, Kris Kennaway Subject: Re: Changing time causes ipv6 panics X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 20:10:48 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 19, 2006 at 02:30:35PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Sun, 15 Jan 2006 19:44:38 -0500,=20 > >>>>> Kris Kennaway said: >=20 > > I ran ntpdate on an amd64 system with ipv6 enabled and a skewed clock > > (ntpdate stepped it back by about an hour), and immediately got a > > use-after-free panic in ifaddr. When I rebooted with memguard enabled > > on this malloc type and retried, I got this panic upon changing the > > date forward, then back, then forward again (also note the garbage > > return data from ntpdate): >=20 > Which version of FreeBSD are you using? Up-to-date 7.0. I didn't try it with older versions. Kris --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD1TD+Wry0BWjoQKURAhy7AKCOdvr5CqisZlHx/whkGeqfQjqOJQCbBTv9 qmQoSpocgJdpNsEQ+O/IW9U= =unWk -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 23 20:29:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2FF9116A42C for ; Mon, 23 Jan 2006 20:29:08 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.zoneseven.net [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0057A43D49 for ; Mon, 23 Jan 2006 20:29:07 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tiago Cruz References: <1138044412.4224.21.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060123204939.A46D4DCAA42@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Mon, 23 Jan 2006 20:49:40 +0000 (GMT) Cc: freebsd-net@freebsd.org Subject: Re: VPN when host is not gateway X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 20:29:08 -0000 Tiago Cruz wrote: > If I install the VPN in my gateway (192.168.0.1), the laptop client host > (Windows XP) is able to ping my virtual server (10.8.0.1), my gateway > (192.168.0.1) and all my LAN (192.168.0.0/22). > > If I install the VPN in my gateway backup (192.168.0.253, with CARP), > the laptop client is able to ping my virtual server (10.8.0.1), my > gateway (192.168.0.1) but NOT is able to ping my LAN (192.168.0.0/22). > > I think that is missing some route, and because this I go to get some > tip... I'd use tcpdump on the various interfaces (tap devices, ethernet) on the machines in question to see exactly at which host is not forwarding the packets properly and where they're going. Cheers, Nate From owner-freebsd-net@FreeBSD.ORG Mon Jan 23 22:57:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 3B20116A422 for ; Mon, 23 Jan 2006 22:57:18 +0000 (GMT) (envelope-from gregorynou@altern.org) Received: from esemetz.metz.supelec.fr (esemetz.metz.supelec.fr [193.48.224.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43DCB43DE1 for ; Mon, 23 Jan 2006 22:24:58 +0000 (GMT) (envelope-from gregorynou@altern.org) Received: from smtp.metz.supelec.fr (smtp.metz.supelec.fr [193.48.224.205]) by esemetz.metz.supelec.fr (8.11.6/8.9.3) with ESMTP id k0NMOtY12814 for ; Mon, 23 Jan 2006 23:24:56 +0100 Received: from [193.48.225.2] (nou.rez-metz.supelec.fr [193.48.225.2]) by smtp.metz.supelec.fr (8.11.6/8.11.6) with ESMTP id k0NMEsB11846 for ; Mon, 23 Jan 2006 23:14:54 +0100 Message-ID: <43D557B0.2080306@altern.org> Date: Mon, 23 Jan 2006 23:24:48 +0100 From: Gregory Nou User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Question on VLAN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 22:57:18 -0000 Hi, What is the difference between if (m->m_flags & M_VLANTAG) and if (ether_type == ETHERTYPE_VLAN) ? I suppose that m->m_flags are set using ether_type at one point. Still, I was not able to find a location in the source where it would happen. The fact is, I do not understand the difference between these two things, nor do I understand why we need the code in if_ethersubr.c[691-717] Thanks a lot ! -- Gregory From owner-freebsd-net@FreeBSD.ORG Tue Jan 24 00:59:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 BE22B16A44F for ; Tue, 24 Jan 2006 00:59:48 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3E8B43D48 for ; Tue, 24 Jan 2006 00:59:47 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: by uproxy.gmail.com with SMTP id o2so130912uge for ; Mon, 23 Jan 2006 16:59:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TSA0zgDJsgKQav9sxXWv08kQbJZNUvYUUyP9dinIDZXQimtv6WGaej5GP32jIQm30bAfIpNkDLe1ItTUYfBBkCRa6XoRiNtOF8W2pszfhd8N86ppvx/fZiTJsYxb5TYayLm1djvwHM18C7YlLLUJ0iZ+rrGe+2ottXCQaAuDN5A= Received: by 10.66.252.18 with SMTP id z18mr323087ugh; Mon, 23 Jan 2006 16:59:46 -0800 (PST) Received: by 10.66.223.13 with HTTP; Mon, 23 Jan 2006 16:59:46 -0800 (PST) Message-ID: <8eea04080601231659o2a26d71dkc3287195b032934e@mail.gmail.com> Date: Mon, 23 Jan 2006 16:59:46 -0800 From: Jon Simola Sender: jsimola@gmail.com To: Gregory Nou In-Reply-To: <43D557B0.2080306@altern.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43D557B0.2080306@altern.org> Cc: freebsd-net@freebsd.org Subject: Re: Question on VLAN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 00:59:48 -0000 On 1/23/06, Gregory Nou wrote: > Hi, > > What is the difference between > if (m->m_flags & M_VLANTAG) > and > if (ether_type =3D=3D ETHERTYPE_VLAN) ? > > I suppose that m->m_flags are set using ether_type at one point. Still, > I was not able to find a location in the source where it would happen. You're right, the M_VLANTAG is a tag on an mbuf to show it's an 802.1q packet, and looks like it gets turned on in vlan_start() in if_vlan.c ETHERTYPE_VLAN is 0x8100 and is a constant in 802.1q packets as they appear on the wire (just after the src/dst MAC addresses, offset 0x18 IIRC). > The fact is, I do not understand the difference between these two > things, nor do I understand why we need the code in if_ethersubr.c[691-71= 7] If the interface does de/tagging at the hardware level the kernel gets the vlan bits already seperated, otherwise it has to figure it out by looking in the header for the presence of the ETHERTYPE_VLAN tag. Hope that helps you out. -- Jon Simola Systems Administrator ABC Communications From owner-freebsd-net@FreeBSD.ORG Tue Jan 24 10:19:08 2006 Return-Path: X-Original-To: net@freebsd.org 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 561E916A420 for ; Tue, 24 Jan 2006 10:19:08 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B94C43D45 for ; Tue, 24 Jan 2006 10:19:07 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 88115 invoked from network); 24 Jan 2006 10:19:26 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Jan 2006 10:19:26 -0000 Message-ID: <43D5FF19.7090903@freebsd.org> Date: Tue, 24 Jan 2006 11:19:05 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: current@freebsd.org, net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Marvell/SysKonnect YukonII source code available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 10:19:08 -0000 Marvell/SysKonnect made the source code to the YukonII chips available today under a BSD license: http://people.freebsd.org/~andre/mykbsd60x86-8.12.1.3-src.tgz I haven't tested the driver yet and I don't know if it available directly from the their website already. Many thanks to Gerald and Frank at SysKonnect for working with us and making this possible! -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jan 24 13:44:31 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 90F1B16A41F for ; Tue, 24 Jan 2006 13:44:31 +0000 (GMT) (envelope-from tiagocruz@b4br.net) Received: from vader.b4br.net (vader.b4br.net [200.152.202.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0150943D46 for ; Tue, 24 Jan 2006 13:44:30 +0000 (GMT) (envelope-from tiagocruz@b4br.net) Received: from localhost (localhost.b4br.net [127.0.0.1]) by vader.b4br.net (Postfix) with ESMTP id 2DF63181428; Tue, 24 Jan 2006 11:39:15 -0200 (BRST) Received: from vader.b4br.net ([127.0.0.1]) by localhost (vader.b4br.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32651-03; Tue, 24 Jan 2006 11:39:08 -0200 (BRST) Received: from tuxkiller.matter.b4br.net (yoda.b4br.net [200.152.202.10]) by vader.b4br.net (Postfix) with ESMTP id 73D97181420; Tue, 24 Jan 2006 11:39:08 -0200 (BRST) From: Tiago Cruz To: "freebsd-net@FreeBSD.org" In-Reply-To: <20060123204939.A46D4DCAA42@mail.npubs.com> References: <1138044412.4224.21.camel@localhost.localdomain> <20060123204939.A46D4DCAA42@mail.npubs.com> Content-Type: text/plain Date: Tue, 24 Jan 2006 11:44:21 -0200 Message-Id: <1138110261.6174.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at b4br.net Cc: nielsen@memberwebs.com Subject: Re: VPN when host is not gateway X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 13:44:31 -0000 On Mon, 2006-01-23 at 20:49 +0000, Nate Nielsen wrote: > I'd use tcpdump on the various interfaces (tap devices, ethernet) on the > machines in question to see exactly at which host is not forwarding the > packets properly and where they're going. Thank you Nielsen! I'm not expert in art of tcpdump, bu I see that: - OpenVPN in my gateway (192.168.0.1): 1-) client vpn -> [ping] -> 192.168.0.19 [ok] 2-) 192.168.0.19 -> [reply] -> cliente vpn [ok] - OpenVPN in my backup gateway (192.168.0.253) 1-) client vpn -> [ping] -> 192.168.0.19 [fail] 2-) no reply from 192.168.0.19 I think that this setup will works: 1-) client vpn -> [ping] -> 192.168.0.1 -> [ping] -> 192.168.0.19 2-) 192.168.0.19 -> [reply] -> 192.168.0.1 -> [reply] -> client vpn So, my questions is this: How I make this route? Many thanks! -- Tiago Cruz http://linuxrapido.org Linux User #282636 "The box said: Requires MS Windows or better, so I installed Linux" From owner-freebsd-net@FreeBSD.ORG Tue Jan 24 14:14:02 2006 Return-Path: X-Original-To: net@FreeBSD.org 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 E2E6216A41F; Tue, 24 Jan 2006 14:14:02 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id D949B43D53; Tue, 24 Jan 2006 14:13:55 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.4/8.13.4/NinthNine) with ESMTP id k0OEDs1Y007265; Tue, 24 Jan 2006 23:13:54 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Tue, 24 Jan 2006 23:13:53 +0900 From: Norikatsu Shigemura To: Andre Oppermann Message-Id: <20060124231353.c0554f76.nork@FreeBSD.org> In-Reply-To: <43D5FF19.7090903@freebsd.org> References: <43D5FF19.7090903@freebsd.org> X-Mailer: Sylpheed version 2.2.0beta5 (GTK+ 2.8.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [219.127.74.121]); Tue, 24 Jan 2006 23:13:54 +0900 (JST) Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: Marvell/SysKonnect YukonII source code available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 14:14:03 -0000 On Tue, 24 Jan 2006 11:19:05 +0100 Andre Oppermann wrote: > Marvell/SysKonnect made the source code to the YukonII chips available > today under a BSD license: > http://people.freebsd.org/~andre/mykbsd60x86-8.12.1.3-src.tgz > I haven't tested the driver yet and I don't know if it available directly > from the their website already. > Many thanks to Gerald and Frank at SysKonnect for working with us and > making this possible! Good works!! I confirmed it on 6.0R-p2, but I didn't test. # mkdir /usr/src/sys/dev/myk # cd /usr/src/sys/dev/myk # tar xvf mykbsd60x86-8.12.1.3-src.tgz # make clean all : # kldload ./if_myk.ko # dmesg : myk0: port 0xa800-0xa8ff mem 0xff720000-0xff723fff irq 17 at device 0.0 on pci4 myk0: Ethernet address: 00:13:20:b4:85:66 # ifconfig myk0 myk0: flags=8802 mtu 1500 options=2b ether 00:13:20:b4:85:66 media: Ethernet autoselect status: no carrier From owner-freebsd-net@FreeBSD.ORG Tue Jan 24 14:54:29 2006 Return-Path: X-Original-To: net@FreeBSD.org 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 F12D316A420; Tue, 24 Jan 2006 14:54:28 +0000 (GMT) (envelope-from uros.gruber@sir-mag.com) Received: from strippy.vizija.si (strippy.vizija.si [217.72.81.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 075A743D66; Tue, 24 Jan 2006 14:54:22 +0000 (GMT) (envelope-from uros.gruber@sir-mag.com) Received: from cartman.dev (BSN-95-243-216.dsl.siol.net [193.95.243.216]) by strippy.vizija.si (Postfix) with ESMTP id 9B8B4A6CF0; Tue, 24 Jan 2006 15:54:15 +0100 (CET) Received: from cartman.dev (localhost [127.0.0.1]) by cartman.dev (Postfix) with ESMTP id C9AE3D4C08; Tue, 24 Jan 2006 16:02:21 +0100 (CET) Received: from [10.0.2.1] (uros [10.0.2.1]) by cartman.dev (Postfix) with ESMTP id 9F7C0D4C10; Tue, 24 Jan 2006 16:02:21 +0100 (CET) Message-ID: <43D63F96.1050908@sir-mag.com> Date: Tue, 24 Jan 2006 15:54:14 +0100 From: =?windows-1252?Q?Uro=9A_Gruber?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Norikatsu Shigemura , Andre Oppermann References: <43D5FF19.7090903@freebsd.org> <20060124231353.c0554f76.nork@FreeBSD.org> In-Reply-To: <20060124231353.c0554f76.nork@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: amavisd-new at vizija.si Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: Marvell/SysKonnect YukonII source code available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 14:54:29 -0000 Norikatsu Shigemura wrote: > On Tue, 24 Jan 2006 11:19:05 +0100 > Andre Oppermann wrote: > >> Marvell/SysKonnect made the source code to the YukonII chips available >> today under a BSD license: >> http://people.freebsd.org/~andre/mykbsd60x86-8.12.1.3-src.tgz >> I haven't tested the driver yet and I don't know if it available directly >> from the their website already. >> Many thanks to Gerald and Frank at SysKonnect for working with us and >> making this possible! >> > > Good works!! I confirmed it on 6.0R-p2, but I didn't test. > > # mkdir /usr/src/sys/dev/myk > # cd /usr/src/sys/dev/myk > # tar xvf mykbsd60x86-8.12.1.3-src.tgz > # make clean all > : > # kldload ./if_myk.ko > # dmesg > : > myk0: port 0xa800-0xa8ff mem 0xff720000-0xff723fff irq 17 at device 0.0 on pci4 > myk0: Ethernet address: 00:13:20:b4:85:66 > # ifconfig myk0 > myk0: flags=8802 mtu 1500 > options=2b > ether 00:13:20:b4:85:66 > media: Ethernet autoselect > status: no carrier > 5.4-RELEASE-p8 I get this sky2.c: In function `Yk2IntServiceRoutine': sky2.c:1478: warning: dereferencing `void *' pointer sky2.c:1478: error: request for member `Arpcom' in something not a structure or union *** Error code 1 Stop in /usr/src/sys/dev/myk. regards Uros > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jan 24 17:29:07 2006 Return-Path: X-Original-To: net@FreeBSD.org 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 50EFD16A41F for ; Tue, 24 Jan 2006 17:29:07 +0000 (GMT) (envelope-from kris.gamutan@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1DB243D79 for ; Tue, 24 Jan 2006 17:28:59 +0000 (GMT) (envelope-from kris.gamutan@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so1177604wra for ; Tue, 24 Jan 2006 09:28:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=TguvRiXi8/0dvyjqNwG/T79EZlP5kFqsE1RTDDwMe4XJxAm7mg9iWY5ONCS/6NHWYr08/7FHY9/SWDjE5LpO+/T1YtCxTZMW56cxjGkObiAfp9tRJWWmEJwOiPoMAUQ6UaKPFFAQ3iCwrYSikBgUqXGRlGJ5pbt8HT6f3rlCpbw= Received: by 10.54.144.2 with SMTP id r2mr275307wrd; Tue, 24 Jan 2006 09:28:59 -0800 (PST) Received: by 10.54.120.20 with HTTP; Tue, 24 Jan 2006 09:28:59 -0800 (PST) Message-ID: Date: Tue, 24 Jan 2006 09:28:59 -0800 From: =?WINDOWS-1252?Q?Kr=EEs=99Emmanuel_Y=2E_Gamutan?= To: net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: i want to subscribe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 17:29:07 -0000 hi please subscribe me, i read about "Absolute Freebsd" book From owner-freebsd-net@FreeBSD.ORG Tue Jan 24 18:26:04 2006 Return-Path: X-Original-To: freebsd-net@hub.freebsd.org Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 922D316A41F; Tue, 24 Jan 2006 18:26:04 +0000 (GMT) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D58243D45; Tue, 24 Jan 2006 18:26:04 +0000 (GMT) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0OIQ4Ts092351; Tue, 24 Jan 2006 18:26:04 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0OIQ4Ws092347; Tue, 24 Jan 2006 18:26:04 GMT (envelope-from andre) Date: Tue, 24 Jan 2006 18:26:04 GMT From: Andre Oppermann Message-Id: <200601241826.k0OIQ4Ws092347@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org Cc: Subject: Re: kern/88450: SYN+ACK reports strange size of window X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 18:26:04 -0000 Synopsis: SYN+ACK reports strange size of window Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Jan 24 18:25:48 UTC 2006 Responsible-Changed-Why: take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=88450 From owner-freebsd-net@FreeBSD.ORG Tue Jan 24 19:24:55 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 BC25A16A420 for ; Tue, 24 Jan 2006 19:24:55 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFCDC43D45 for ; Tue, 24 Jan 2006 19:24:54 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k0OJOiNS091354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jan 2006 22:24:45 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k0OJOiVT091353; Tue, 24 Jan 2006 22:24:44 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 24 Jan 2006 22:24:43 +0300 From: Gleb Smirnoff To: Gregory Nou Message-ID: <20060124192443.GR83922@FreeBSD.org> Mail-Followup-To: Gleb Smirnoff , Gregory Nou , freebsd-net@freebsd.org References: <43D557B0.2080306@altern.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <43D557B0.2080306@altern.org> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org Subject: Re: Question on VLAN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 19:24:55 -0000 On Mon, Jan 23, 2006 at 11:24:48PM +0100, Gregory Nou wrote: G> What is the difference between G> if (m->m_flags & M_VLANTAG) G> and G> if (ether_type == ETHERTYPE_VLAN) ? G> G> I suppose that m->m_flags are set using ether_type at one point. Still, G> I was not able to find a location in the source where it would happen. G> G> The fact is, I do not understand the difference between these two G> things, nor do I understand why we need the code in if_ethersubr.c[691-717] Some drivers are capable to recognise VLAN frames. In this case mbuf has M_VLANTAG set on it, vlan tag is stored in mbuf tag, and mbuf contains untagged frame. For those drivers that aren't capable to handle VLAN frames, we need to look into frame and see the tag. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Jan 24 21:24:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2DD0516A431 for ; Tue, 24 Jan 2006 21:24:28 +0000 (GMT) (envelope-from hans@nieser.net) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52DFC43D55 for ; Tue, 24 Jan 2006 21:24:19 +0000 (GMT) (envelope-from hans@nieser.net) Received: from [192.168.1.10] (nieser.net [194.109.160.131]) by smtp-vbr12.xs4all.nl (8.13.3/8.13.3) with ESMTP id k0OLOFT9058187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Jan 2006 22:24:16 +0100 (CET) (envelope-from hans@nieser.net) Message-ID: <43D69B06.4060208@nieser.net> Date: Tue, 24 Jan 2006 22:24:22 +0100 From: Hans Nieser User-Agent: Mail/News 1.5 (X11/20060113) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------070206040002050406020406" X-Virus-Scanned: by XS4ALL Virus Scanner Subject: re0: 2 link states coalesced X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 21:24:28 -0000 This is a multi-part message in MIME format. --------------070206040002050406020406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi list, I have a problem with my RTL8169 Gigabit NIC built into my (apparently very uncommon) Clevo D41EV laptop. At boot, when netif tries to set up the interface, I get a lot of these messages: > re0: 2 link states coalesced > re0: link state changed to DOWN > re0: 2 link states coalesced > re0: link state changed to DOWN > re0: 2 link states coalesced > re0: link state changed to DOWN At some point the interface will go UP just at the right time (?) and gets configured by dhclient succesfully. Once that is done it seems to works fine, giving me 10-11 MiB/s throughput on a 100mbit link. At first I didn't consider it a real problem, but now that I am trying to take my laptop into daily use I am becoming increasingly annoyed by having to wait 3 to 6 minutes for the NIC to go 'UP' during the boot process. Here's how the NIC is identified in pciconf -lv: > re0@pci0:10:0: class=0x020000 card=0x08001558 chip=0x816910ec rev=0x10 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8169 Gigabit Ethernet Adapter' > class = network > subclass = ethernet This is all on a fresh installation of FreeBSD-6.0-RELEASE updated to p3. I have the full dmesg log and pciconf output attached (and mirrored at http://www.nieser.net/files/re-problem/ incase the attachments don't come through). Does anyone know what causes this, and possibly the solution? Should I file a PR for this? Please let me know if more information is needed. --------------070206040002050406020406 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RELEASE-p3 #1: Mon Jan 23 11:38:20 CET 2006 root@aphax-laptop.nieser.local:/usr/obj/usr/src/sys/APHAX-LAPTOP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.12-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400> Hyperthreading: 2 logical CPUs real memory = 534708224 (509 MB) avail memory = 513912832 (490 MB) ACPI APIC Table: MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 9 on acpi0 pci_link2: irq 0 on acpi0 pci_link3: irq 11 on acpi0 pci_link4: irq 11 on acpi0 pci_link5: irq 9 on acpi0 pci_link6: irq 9 on acpi0 pci_link7: irq 0 on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xe7ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 fwohci0: mem 0xe8000000-0xe8000fff irq 17 at device 2.3 on pci0 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:90:f5:00:00:14:d7:28 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1000-0x100f at device 2.5 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 2.6 (no driver attached) pcm0: port 0x1c00-0x1cff,0x1800-0x187f at device 2.7 on pci0 pcm0: [GIANT-LOCKED] pcm0: ohci0: mem 0xe8001000-0xe8001fff irq 20 at device 3.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xe8002000-0xe8002fff irq 21 at device 3.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xe8003000-0xe8003fff irq 22 at device 3.2 on pci0 ohci2: [GIANT-LOCKED] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xe8004000-0xe8004fff at device 3.3 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: SiS EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered ugen0: Generic USB Storage Device, rev 2.00/1.00, addr 2 re0: port 0x2000-0x20ff mem 0xe8005000-0xe80050ff irq 19 at device 10.0 on pci0 miibus0: on re0 rgephy0: on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto re0: Ethernet address: 00:90:f5:28:d7:14 cbb0: mem 0x80000000-0x80000fff irq 18 at device 12.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: port 0x2f8-0x2ff irq 3 drq 0 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xdc000-0xdffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen1: Z-Star Corp. PC Camera, rev 1.10/1.00, addr 2 ums0: Logitech Optical USB Mouse, rev 2.00/3.40, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 3000121856 Hz quality 800 Timecounters tick every 1.000 msec ral0: mem 0x88000000-0x88001fff irq 18 at device 0.0 on cardbus0 ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 ral0: Ethernet address: 00:11:50:15:ab:f8 ad0: 57231MB at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s2a re0: 2 link states coalesced re0: 2 link states coalesced re0: 2 link states coalesced re0: 2 link states coalesced re0: 2 link states coalesced re0: 2 link states coalesced re0: 2 link states coalesced re0: link state changed to DOWN re0: 2 link states coalesced re0: link state changed to DOWN re0: 2 link states coalesced re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP ral0: link state changed to UP ral0: link state changed to DOWN ral0: link state changed to UP --------------070206040002050406020406 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pciconf.txt" agp0@pci0:0:0: class=0x060000 card=0x04801558 chip=0x06481039 rev=0x51 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS648MX Host-to-PCI Bridge' class = bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00000000 chip=0x00031039 rev=0x00 hdr=0x01 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS648FX Virtual PCI to PCI Bridge (AGP)' class = bridge subclass = PCI-PCI isab0@pci0:2:0: class=0x060100 card=0x00000000 chip=0x00081039 rev=0x14 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS PCI to ISA Bridge (LPC Bridge)' class = bridge subclass = PCI-ISA fwohci0@pci0:2:3: class=0x0c0010 card=0x04801558 chip=0x70071039 rev=0x00 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS OHCI Compliant FireWire Controller' class = serial bus subclass = FireWire atapci0@pci0:2:5: class=0x01018a card=0x04801558 chip=0x55131039 rev=0x00 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5513 EIDE Controller (A,B step)' class = mass storage subclass = ATA none0@pci0:2:6: class=0x070300 card=0x42011558 chip=0x70131039 rev=0xa0 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS7013 sharp actius rd10 _ modem 56k' class = simple comms subclass = generic modem pcm0@pci0:2:7: class=0x040100 card=0x04801558 chip=0x70121039 rev=0xa0 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS7013 PCI Audio Accelerator' class = multimedia subclass = audio ohci0@pci0:3:0: class=0x0c0310 card=0x04801558 chip=0x70011039 rev=0x0f hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5597/8 Universal Serial Bus Controller' class = serial bus subclass = USB ohci1@pci0:3:1: class=0x0c0310 card=0x04801558 chip=0x70011039 rev=0x0f hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5597/8 Universal Serial Bus Controller' class = serial bus subclass = USB ohci2@pci0:3:2: class=0x0c0310 card=0x04801558 chip=0x70011039 rev=0x0f hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5597/8 Universal Serial Bus Controller' class = serial bus subclass = USB ehci0@pci0:3:3: class=0x0c0320 card=0x04801558 chip=0x70021039 rev=0x00 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS7002 USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB re0@pci0:10:0: class=0x020000 card=0x08001558 chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169 Gigabit Ethernet Adapter' class = network subclass = ethernet cbb0@pci0:12:0: class=0x060700 card=0x04801558 chip=0x14101524 rev=0x01 hdr=0x02 vendor = 'ENE Technology Inc' device = 'CB-1420 CardBus Controller' class = bridge subclass = PCI-CardBus none1@pci1:0:0: class=0x030000 card=0x05141558 chip=0x4e501002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Mobility Radeon 9700 (M10 NP) (RV350)' class = display subclass = VGA ral0@pci2:0:0: class=0x028000 card=0x701a1799 chip=0x02011814 rev=0x01 hdr=0x00 vendor = 'Ralink Technology, Corp' device = 'Ralink RT2500 802.11 CardBus Reference Card' class = network --------------070206040002050406020406-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 24 22:05:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 0335616A41F for ; Tue, 24 Jan 2006 22:05:37 +0000 (GMT) (envelope-from jpeg@thilelli.net) Received: from smtp.thilelli.net (smtp.thilelli.net [213.41.129.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E0FA43D5C for ; Tue, 24 Jan 2006 22:05:32 +0000 (GMT) (envelope-from jpeg@thilelli.net) Received: from localhost (localhost [127.0.0.1]) by bento.thilelli.net (Postfix) with ESMTP id 9FB045647E; Tue, 24 Jan 2006 23:05:30 +0100 (CET) Received: from bento.thilelli.net ([127.0.0.1]) by localhost (bento.thilelli.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 38518-05; Tue, 24 Jan 2006 23:05:29 +0100 (CET) Received: from webmail.thilelli.net (localhost [127.0.0.1]) by bento.thilelli.net (Postfix) with ESMTP id 0EDFC5647C; Tue, 24 Jan 2006 23:05:29 +0100 (CET) Received: from 192.168.1.12 (SquirrelMail authenticated user jgabel) by webmail.thilelli.net with HTTP; Tue, 24 Jan 2006 23:05:29 +0100 (CET) Message-ID: <62280.192.168.1.12.1138140329.squirrel@webmail.thilelli.net> In-Reply-To: <43D69B06.4060208@nieser.net> References: <43D69B06.4060208@nieser.net> Date: Tue, 24 Jan 2006 23:05:29 +0100 (CET) From: "Julien Gabel" To: "Hans Nieser" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at thilelli.net Cc: freebsd-net@freebsd.org Subject: Re: re0: 2 link states coalesced. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jpeg@thilelli.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2006 22:05:37 -0000 Hello Hans, > I have a problem with my RTL8169 Gigabit NIC built into my (apparently > very uncommon) Clevo D41EV laptop. At boot, when netif tries to set up the > interface, I get a lot of these messages: > > > re0: 2 link states coalesced > > re0: link state changed to DOWN > > re0: 2 link states coalesced > > re0: link state changed to DOWN > > re0: 2 link states coalesced > > re0: link state changed to DOWN > > At some point the interface will go UP just at the right time (?) and gets > configured by dhclient succesfully. Once that is done it seems to works > fine, giving me 10-11 MiB/s throughput on a 100mbit link. > > At first I didn't consider it a real problem, but now that I am trying to > take my laptop into daily use I am becoming increasingly annoyed by having > to wait 3 to 6 minutes for the NIC to go 'UP' during the boot process. > > Here's how the NIC is identified in pciconf -lv: > > > re0@pci0:10:0: class=0x020000 card=0x08001558 chip=0x816910ec rev=0x10 > > hdr=0x00 > > vendor = 'Realtek Semiconductor' > > device = 'RTL8169 Gigabit Ethernet Adapter' > > class = network > > subclass = ethernet > > This is all on a fresh installation of FreeBSD-6.0-RELEASE updated to p3. > I have the full dmesg log and pciconf output attached (and mirrored at > http://www.nieser.net/files/re-problem/ incase the attachments don't come > through). Does anyone know what causes this, and possibly the solution? > Should I file a PR for this? I filled one a year ago, for the very same problem (encountered for two years now). See Problem Report kern/80005 for more information. I think that another user (Emmanuel Duros) tried to speak with Realtek on that point, not sure if there is feedback on it though... Sorry not to have better news. -- -jpeg. From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 01:56:33 2006 Return-Path: X-Original-To: net@freebsd.org 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 1027B16A423 for ; Wed, 25 Jan 2006 01:56:33 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7573743D53 for ; Wed, 25 Jan 2006 01:56:31 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so1351767nzo for ; Tue, 24 Jan 2006 17:56:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=AcoHizTgZ8vP1vMGPvpXlcHqizYpeFxjfVkQYdKv/ykgSq6DfNu7ZS0UCXaout25YSM4xqV8VL55WbxzpD2LPdbyVHsNYahWSM8u0A9WR/lhhSpZyy0BTjeRYGl7EBNRo3KC5o1w8/ymPVvqGf5AOOMwduw9gROqIrZKgzKXPok= Received: by 10.37.20.29 with SMTP id x29mr153598nzi; Tue, 24 Jan 2006 17:56:30 -0800 (PST) Received: from michelle.rndsoft.co.kr ( [211.32.202.217]) by mx.gmail.com with ESMTP id 15sm70127nzp.2006.01.24.17.56.29; Tue, 24 Jan 2006 17:56:30 -0800 (PST) Received: from michelle.rndsoft.co.kr (localhost.rndsoft.co.kr [127.0.0.1]) by michelle.rndsoft.co.kr (8.13.5/8.13.5) with ESMTP id k0P1tB7R011703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2006 10:55:12 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.rndsoft.co.kr (8.13.5/8.13.5/Submit) id k0P1tBHG011702; Wed, 25 Jan 2006 10:55:11 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 25 Jan 2006 10:55:11 +0900 From: Pyun YongHyeon To: Andre Oppermann Message-ID: <20060125015511.GA11296@rndsoft.co.kr> References: <43D5FF19.7090903@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43D5FF19.7090903@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, net@freebsd.org Subject: Re: Marvell/SysKonnect YukonII source code available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 01:56:33 -0000 On Tue, Jan 24, 2006 at 11:19:05AM +0100, Andre Oppermann wrote: > Marvell/SysKonnect made the source code to the YukonII chips available > today under a BSD license: > > http://people.freebsd.org/~andre/mykbsd60x86-8.12.1.3-src.tgz > > I haven't tested the driver yet and I don't know if it available directly > from the their website already. > > Many thanks to Gerald and Frank at SysKonnect for working with us and > making this possible! > Yes, that's great news. Is there any chance to get a copy of data sheet for Yukon chips? I've tried hard to make Rx TCP/UDP checksum offload work but failed. ATM both Linux and OpenBSD use Rx IP checksum offload only but this driver enabled Rx checksum offload for TCP/UDP. So I guess there is somthing not listed in SK-NET Genesis data sheet. :-( Quick reading the source shows that this driver has the following issues. 1. Incomplete bus_dma(9) support. The driver uses BUS_SPACE_MAXADDR when it creates DMA tags which means its DMA supports any address without limitations. However, I'm sure Rx/Tx descriptors should reside in < 4GB. So the driver wouldn't work on systems with > 4GB memory. 2. Since the driver makes use of mbpool(9) it wouldn't work when bounce buffers are involved. In fact, I think the use of mbpool(9) is really bad as it lacks bus_dmamap_sync(9) operation. 3. Lack of ALTQ support. 4. The driver may not work on big-endian architectures. 5. The driver may not work on architectures with strict-alignment. Btw, new sk(4) is availabe at the following URL. Due to lack of documentation it doesn't support YukonII yet. http://people.freebsd.org/~yongari/sk/if_sk.c http://people.freebsd.org/~yongari/sk/if_skreg.h -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 02:23:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 9F8BF16A41F for ; Wed, 25 Jan 2006 02:23:16 +0000 (GMT) (envelope-from haisang@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0841143D64 for ; Wed, 25 Jan 2006 02:23:15 +0000 (GMT) (envelope-from haisang@gmail.com) Received: by xproxy.gmail.com with SMTP id h30so798wxd for ; Tue, 24 Jan 2006 18:23:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=JDAWzNKGX0hUsvWft9IjRBGiD4H73eUKxIfCwvzQmi7NSf+eK8booPsDuZe9K52mpxWG3l9n5TVYrjxddi4Iwc6BsL8oEO3xDj1BPGQjrtT95aF+fJCVpkDGeMDkQ0EFqabNFXG+oKnQU/rL/ZfRWvRWYS2b3LXsSkgq4D1Ryu4= Received: by 10.70.126.14 with SMTP id y14mr235171wxc; Tue, 24 Jan 2006 18:23:15 -0800 (PST) Received: by 10.70.126.15 with HTTP; Tue, 24 Jan 2006 18:23:15 -0800 (PST) Message-ID: Date: Tue, 24 Jan 2006 18:23:15 -0800 From: Haisang Wu To: freebsd-net@freebsd.org. MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Developing New Socket Option on 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 02:23:16 -0000 Hello, all, I am writing for help on my freebsd kernel hacking. I am working on 4.10, and intend to introduct a new socket option (say, SO_TAG_PAK) for my own kernel. When sending out a packet, if this option is set, the socket layer will produce a 20-byte tag, and finally this tag will be prepended before IP header (may be done in ip_output() ). This is somewhat like MPLS's shim layer, but this special packet with the tag will only be sent over a logical tunnel to another system. When receiving a packet, the IP layer will check whether the packet has this tag (through the first integer of the tag), and pass the tag up (to applications). For future possible extensions, I introduced a flag, so_tag_pak_flag, int= o "struct socket". I modified sosetopt() to set so->so_tag_pak_flag=3D0x1 wh= en (sopt->sopt_name =3D=3D SO_TAG_PAK). I will write a function so_tagpak( ) t= o generate the 20-byte tag. This tag will be kept in the kernel space, and later be prepended to the IP packet in function ip_output( ). I have a few questions below: At sending direction: 1. Should I allocate a separate mbuf for this tag inside so_tagpak( )? 2. The function so_tagpak( ) should be called in the socket layer so the socket can check the flag and produce the tag. Where should it be called? 3. In ip_output( ), can I prepend this tag (i.e., a separate mbuf) before the IP header? Could you give me some suggestions on how to do so? At receiving direction: 4. Can I detect the tag in ipintr( )? How will be the mbuf operation here? Thank you very much for your help! Haisang From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 02:39:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 CE51716A41F for ; Wed, 25 Jan 2006 02:39:37 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FBD843D46 for ; Wed, 25 Jan 2006 02:39:37 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 86D145DB9; Tue, 24 Jan 2006 21:39:36 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70875-06; Tue, 24 Jan 2006 21:39:34 -0500 (EST) Received: from [192.168.1.3] (pool-68-160-211-174.ny325.east.verizon.net [68.160.211.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 5D5355C44; Tue, 24 Jan 2006 21:39:33 -0500 (EST) Message-ID: <43D6E4E9.7010604@mac.com> Date: Tue, 24 Jan 2006 21:39:37 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Haisang Wu References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-net@freebsd.org Subject: Re: Developing New Socket Option on 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 02:39:37 -0000 Haisang Wu wrote: > I am writing for help on my freebsd kernel hacking. I am working on 4.10, > and intend to introduct a new socket option (say, SO_TAG_PAK) > for my own kernel. When sending out a packet, if this option is set, the > socket layer will produce a 20-byte tag, and finally this tag will be > prepended before IP header (may be done in ip_output() ). This is somewhat > like MPLS's shim layer, but this special packet with the tag will only be > sent over a logical tunnel to another system. When receiving a packet, the > IP layer will check whether the packet has this tag (through the > first integer of the tag), and pass the tag up (to applications). If you want to write your own protocol which wraps IP, OK, but there are easier ways of passing out-of-band data to the application layer. Consider either setting up a new IP-layer option, a new TCP-layer option, or just using TCP's urgent pointer to send OOB data. Twenty bytes would fit just fine inside the existing protocols, and you would be able to take advantage of hardware support for Rx and Tx checksums, etc, etc. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 03:04:59 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2F63C16A41F for ; Wed, 25 Jan 2006 03:04:59 +0000 (GMT) (envelope-from haisang@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BC6B43D46 for ; Wed, 25 Jan 2006 03:04:58 +0000 (GMT) (envelope-from haisang@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so6248wxc for ; Tue, 24 Jan 2006 19:04:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=E499BSpL3csGqFSbA+2QDCyljbh9LKRoNzVuS2LiQn595QV4ZHAMjgZMZxb7p+Cy6uaRA+2hqTWxzFxS8ZFLdlvZ40qLxENecOriO1I7QSSXxSBw2g8PXrJybeaPvfpRtO/N9CMud7jb1pYGRsEod3xu3tQ6X4QxfftzNfQzAVQ= Received: by 10.70.31.20 with SMTP id e20mr251654wxe; Tue, 24 Jan 2006 19:04:57 -0800 (PST) Received: by 10.70.126.15 with HTTP; Tue, 24 Jan 2006 19:04:57 -0800 (PST) Message-ID: Date: Tue, 24 Jan 2006 19:04:57 -0800 From: Haisang Wu To: Chuck Swiger In-Reply-To: <43D6E4E9.7010604@mac.com> MIME-Version: 1.0 References: <43D6E4E9.7010604@mac.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Developing New Socket Option on 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 03:04:59 -0000 Well, I may have some more socket options in the future for the application to fill segments of the 20-byte tag, and the tag may be extended to 40 or 64 bytes, when OOB information increases. How does IPSEC prepend the new header in tunnelling mode? Thanks. Haisang On 1/24/06, Chuck Swiger wrote: > > Haisang Wu wrote: > > I am writing for help on my freebsd kernel hacking. I am working on > 4.10, > > and intend to introduct a new socket option (say, SO_TAG_PAK) > > for my own kernel. When sending out a packet, if this option is set, th= e > > socket layer will produce a 20-byte tag, and finally this tag will be > > prepended before IP header (may be done in ip_output() ). This is > somewhat > > like MPLS's shim layer, but this special packet with the tag will only > be > > sent over a logical tunnel to another system. When receiving a packet, > the > > IP layer will check whether the packet has this tag (through the > > first integer of the tag), and pass the tag up (to applications). > > If you want to write your own protocol which wraps IP, OK, but there are > easier > ways of passing out-of-band data to the application layer. > > Consider either setting up a new IP-layer option, a new TCP-layer option, > or > just using TCP's urgent pointer to send OOB data. Twenty bytes would fit > just > fine inside the existing protocols, and you would be able to take > advantage of > hardware support for Rx and Tx checksums, etc, etc. > > -- > -Chuck > From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 06:54:46 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 4C3C016A41F for ; Wed, 25 Jan 2006 06:54:46 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 120BC43D46 for ; Wed, 25 Jan 2006 06:54:46 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.107]) by a50.ironport.com with ESMTP; 24 Jan 2006 22:54:45 -0800 Message-ID: <43D720B5.2020803@elischer.org> Date: Tue, 24 Jan 2006 22:54:45 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Haisang Wu References: <43D6E4E9.7010604@mac.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Developing New Socket Option on 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 06:54:46 -0000 Haisang Wu wrote: >Well, I may have some more socket options in the future for the application >to fill >segments of the 20-byte tag, and the tag may be extended to 40 or 64 bytes, >when >OOB information increases. > >How does IPSEC prepend the new header in tunnelling mode? Thanks. > >Haisang > > you COULD use netgraph to do this.. you would have an ng_iface node hooked to your own node that adds the header which could be hooked to an ng_ether interface as a type filter itself or using ng_etf as the ethertype filter. From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 08:03:57 2006 Return-Path: X-Original-To: net@freebsd.org 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 43E2016A41F for ; Wed, 25 Jan 2006 08:03:57 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9097743D53 for ; Wed, 25 Jan 2006 08:03:55 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 99740 invoked from network); 25 Jan 2006 08:04:04 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Jan 2006 08:04:04 -0000 Message-ID: <43D730EA.6070105@freebsd.org> Date: Wed, 25 Jan 2006 09:03:54 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: pyunyh@gmail.com References: <43D5FF19.7090903@freebsd.org> <20060125015511.GA11296@rndsoft.co.kr> In-Reply-To: <20060125015511.GA11296@rndsoft.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, net@freebsd.org Subject: Re: Marvell/SysKonnect YukonII source code available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 08:03:57 -0000 Pyun YongHyeon wrote: > On Tue, Jan 24, 2006 at 11:19:05AM +0100, Andre Oppermann wrote: > > Marvell/SysKonnect made the source code to the YukonII chips available > > today under a BSD license: > > > > http://people.freebsd.org/~andre/mykbsd60x86-8.12.1.3-src.tgz > > > > I haven't tested the driver yet and I don't know if it available directly > > from the their website already. > > > > Many thanks to Gerald and Frank at SysKonnect for working with us and > > making this possible! > > > Yes, that's great news. > > Is there any chance to get a copy of data sheet for Yukon chips? If you are willing and able to sign a NDA for the 'physical' docs I think so. Using the obtained knowledge in a driver is not longer a problem as pretty much all of the information is available in the BSD licensed OSS driver too. It's just a bit harder to digest w/o the documentation. Ie. now that the driver is OSS there are no more trade secrets in the chip. > I've tried hard to make Rx TCP/UDP checksum offload work but > failed. ATM both Linux and OpenBSD use Rx IP checksum offload only > but this driver enabled Rx checksum offload for TCP/UDP. So I guess > there is somthing not listed in SK-NET Genesis data sheet. :-( Likely. > Quick reading the source shows that this driver has the following > issues. > 1. Incomplete bus_dma(9) support. The driver uses BUS_SPACE_MAXADDR > when it creates DMA tags which means its DMA supports any address > without limitations. However, I'm sure Rx/Tx descriptors should > reside in < 4GB. So the driver wouldn't work on systems with > 4GB > memory. > 2. Since the driver makes use of mbpool(9) it wouldn't work when > bounce buffers are involved. In fact, I think the use of mbpool(9) > is really bad as it lacks bus_dmamap_sync(9) operation. > 3. Lack of ALTQ support. > 4. The driver may not work on big-endian architectures. > 5. The driver may not work on architectures with strict-alignment. Yes, they haven't spent all the time to get up-to-date with FreeBSD. It seems most of their time is spent on OSX and Solaris drivers for new wired and wireless chips. > Btw, new sk(4) is availabe at the following URL. Due to lack of > documentation it doesn't support YukonII yet. > http://people.freebsd.org/~yongari/sk/if_sk.c > http://people.freebsd.org/~yongari/sk/if_skreg.h What's the differences to our current sk(4)? -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 10:55:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 E407C16A424 for ; Wed, 25 Jan 2006 10:55:10 +0000 (GMT) (envelope-from h.nieser@xs4all.nl) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C2A743E73 for ; Wed, 25 Jan 2006 10:50:24 +0000 (GMT) (envelope-from h.nieser@xs4all.nl) Received: from [192.168.1.10] (nieser.net [194.109.160.131]) by smtp-vbr13.xs4all.nl (8.13.3/8.13.3) with ESMTP id k0PAnpiN048739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2006 11:49:51 +0100 (CET) (envelope-from h.nieser@xs4all.nl) Message-ID: <43D757CE.9060105@xs4all.nl> Date: Wed, 25 Jan 2006 11:49:50 +0100 From: Hans Nieser User-Agent: Mail/News 1.5 (X11/20060113) MIME-Version: 1.0 To: jpeg@thilelli.net, freebsd-net@freebsd.org References: <43D69B06.4060208@nieser.net> <62280.192.168.1.12.1138140329.squirrel@webmail.thilelli.net> In-Reply-To: <62280.192.168.1.12.1138140329.squirrel@webmail.thilelli.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Subject: Re: re0: 2 link states coalesced. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 10:55:11 -0000 Julien Gabel wrote: > Hello Hans, > >> I have a problem with my RTL8169 Gigabit NIC built into my (apparently >> very uncommon) Clevo D41EV laptop. At boot, when netif tries to set up the >> interface, I get a lot of these messages: >> >> > re0: 2 link states coalesced >> > re0: link state changed to DOWN >> > re0: 2 link states coalesced >> > re0: link state changed to DOWN >> > re0: 2 link states coalesced >> > re0: link state changed to DOWN > > I filled one a year ago, for the very same problem (encountered for two > years now). See Problem Report kern/80005 for more information. I think > that another user (Emmanuel Duros) tried to speak with Realtek on that > point, not sure if there is feedback on it though... > > Sorry not to have better news. > That's too bad, but thanks for letting me know From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 15:20:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A18F816A420 for ; Wed, 25 Jan 2006 15:20:34 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6713343D49 for ; Wed, 25 Jan 2006 15:20:34 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: by ion.gank.org (mail, from userid 1001) id EF60A2AAE5; Wed, 25 Jan 2006 09:20:33 -0600 (CST) Date: Wed, 25 Jan 2006 09:20:33 -0600 From: craig@olyun.gank.org To: freebsd-net@freebsd.org Message-ID: <20060125152032.GA40581@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Race condition in ip6_getpmtu? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 15:20:34 -0000 I seem to be running into a race condition in ip6_getpmtu. I've been having sporadic panics recently -- sometimes the machine will last a week, sometimes it'll panic twice in a day. The backtrace is always the same: (ddb and doadump frames removed) #9 0xc066548a in calltrap () at /compile/src/sys/i386/i386/exception.s:139 #10 0xc05d32f1 in ip6_getpmtu (ro_pmtu=0xc528a90c, ro=0xc528a90c, ifp=0xc4fea800, dst=0xe886b964, mtup=0x0, alwaysfragp=0xe886b8e4) at /compile/src/sys/netinet6/ip6_output.c:1415 #11 0xc05d2197 in ip6_output (m0=0xc528a90c, opt=0x0, ro=0xc528a90c, flags=4, im6o=0x0, ifpp=0x0, inp=0x0) at /compile/src/sys/netinet6/ip6_output.c:806 #12 0xc05c74d4 in in6_gif_output (ifp=0xc51ae400, family=-971248640, m=0xc5362900) at /compile/src/sys/netinet6/in6_gif.c:216 #13 0xc05900cb in gif_output (ifp=0xc51ae400, m=0xc52d4400, dst=0xc51b1a50, rt=0xc543e084) at /compile/src/sys/net/if_gif.c:435 #14 0xc05a75f0 in ip_output (m=0xc52d4400, opt=0xc51ae400, ro=0xe886baac, flags=0, imo=0x0, inp=0xc6189bf4) at /compile/src/sys/netinet/ip_output.c:776 #15 0xc05b1828 in tcp_output (tp=0xc6060c94) at /compile/src/sys/netinet/tcp_output.c:1080 #16 0xc05b99ca in tcp_usr_rcvd (so=0x0, flags=0) at /compile/src/sys/netinet/tcp_usrreq.c:600 #17 0xc055129b in soreceive (so=0xc61b3de8, psa=0x0, uio=0xe886bcb0, mp0=0x0, controlp=0x0, flagsp=0x0) at /compile/src/sys/kern/uipc_socket.c:1400 #18 0xc053c63f in soo_read (fp=0x0, uio=0x0, active_cred=0xc61c7e00, flags=0, td=0xc61bec00) at /compile/src/sys/kern/sys_socket.c:91 ... all the way back to read(), though sometimes it will be in write() (kgdb) up 10 #10 0xc05d32f1 in ip6_getpmtu (ro_pmtu=0xc528a90c, ro=0xc528a90c, ifp=0xc4fea800, dst=0xe886b964, mtup=0x0, alwaysfragp=0xe886b8e4) at /compile/src/sys/netinet6/ip6_output.c:1415 1415 mtu = ro_pmtu->ro_rt->rt_rmx.rmx_mtu; (kgdb) print ro_pmtu $1 = (struct route_in6 *) 0xc528a90c (kgdb) print ro_pmtu->ro_rt $2 = (struct rtentry *) 0x0 But... That line is in a block where ro_rt has already been checked to see if it's null. 1400 if (ro_pmtu->ro_rt) { ... 1412 if (mtu) 1413 mtu = min(mtu, ro_pmtu->ro_rt->rt_rmx.rmx_mtu); 1414 else 1415 mtu = ro_pmtu->ro_rt->rt_rmx.rmx_mtu; ... 1441 } else if (ifp) { So, somehow ro_pmto->ro_rt is being set to null between line 1400 and 1415. The only function call inside the block is tcp_hc_getmtu(), and that doesn't touch the routing table. My guess is that it's being preempted by another process and the cached neighbor entry is expiring. I don't see any locks protecting ro_pmtu, however I'm unfamiliar with how locking in the IP6 code works so there may be one higher up. The traffic in question is IPv4 traffic going out over an IPv6 gif tunnel. So far it always seems to happen when trying to send an encapsulated packet. Any IPv6 gurus know if that's a reasonable theory? Thanks, Craig --------- Addendum: While writing this message, it panic'd again. However this time it was in a delayed ACK transmission (still for the gif tunnel though). #10 0xc05d32f1 in ip6_getpmtu (ro_pmtu=0xc51ecc0c, ro=0xc51ecc0c, ifp=0xc4fea800, dst=0xe3938a2c, mtup=0x0, alwaysfragp=0xe39389ac) at /compile/src/sys/netinet6/ip6_output.c:1415 #11 0xc05d2197 in ip6_output (m0=0xc51ecc0c, opt=0x0, ro=0xc51ecc0c, flags=4, im6o=0x0, ifpp=0x0, inp=0x0) at /compile/src/sys/netinet6/ip6_output.c:806 #12 0xc05c74d4 in in6_gif_output (ifp=0xc51af400, family=-991434496, m=0xc53a9d00) at /compile/src/sys/netinet6/in6_gif.c:216 #13 0xc05900cb in gif_output (ifp=0xc51af400, m=0xc53ef900, dst=0xc51ad970, rt=0xc5439084) at /compile/src/sys/net/if_gif.c:435 #14 0xc05a75f0 in ip_output (m=0xc53ef900, opt=0xc51af400, ro=0xe3938b74, flags=0, imo=0x0, inp=0xc61484ec) at /compile/src/sys/netinet/ip_output.c:776 #15 0xc05b1828 in tcp_output (tp=0xc6cf3398) at /compile/src/sys/netinet/tcp_output.c:1080 #16 0xc05b71c2 in tcp_timer_delack (xtp=0xc6cf3398) at /compile/src/sys/netinet/tcp_timer.c:175 #17 0xc051cb83 in softclock (dummy=0x0) at /compile/src/sys/kern/kern_timeout.c:290 #18 0xc04f5e90 in ithread_loop (arg=0xc4ee5280) ... Exact same spot in ip6_getpmtu though. From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 15:24:17 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 4969F16A41F for ; Wed, 25 Jan 2006 15:24:17 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id C467743D48 for ; Wed, 25 Jan 2006 15:24:15 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id DADF778C21 for ; Wed, 25 Jan 2006 17:25:49 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45251-15 for ; Wed, 25 Jan 2006 17:25:49 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id 2DC7978C1D for ; Wed, 25 Jan 2006 17:25:49 +0200 (EET) Date: Wed, 25 Jan 2006 17:29:20 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.64.01 Christmas Edition) Professional X-Priority: 3 (Normal) Message-ID: <1249572348.20060125172920@osk.com.ua> To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Cc: Subject: gif interface listener problem? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 15:24:17 -0000 Hello, One of my servers still runs FreeBSD 4.11. It has two internet connections from two different providers. First of them is used for common internet access and the second is dedicated for a tunnel between offices. Lets mark IPs in this way rl0 - main interface rl1 - tunnel interface xxx.xxx.xxx.xxx - IP of main internet interface XXX.XXX.XXX.XXX - IP of gateway for main interface yyy.yyy.yyy.yyy - IP of tunnel interface YYY.YYY.YYY.YYY - IP of gateway for tunnel interface zzz.zzz.zzz.zzz - IP of endpoint for tunnel I have configured policy routing using ipfw in a such way (simplifyed): add fwd YYY.YYY.YYY.YYY all from yyy.yyy.yyy.yyy out xmit rl0 add fwd XXX.XXX.XXX.XXX all from xxx.xxx.xxx.xxx out xmit rl1 add allow ipencap from any to any via rl1 add allow all from any to any via gif0 ... gif tunnel is configured in a such way: gif0: flags=8051 mtu 1280 tunnel inet yyy.yyy.yyy.yyy --> zzz.zzz.zzz.zzz inet 192.168.200.1 --> 192.168.201.1 netmask 0xffffffff The default route is to XXX.XXX.XXX.XXX if a route zzz.zzz.zzz.zzz -> YYY.YYY.YYY.YYY is manually created, everything works fine. But in this case ALL traffic to host zzz.zzz.zzz.zzz is routed through rl1 interface and this is unacceptable as all of rl1 bandwidth is reserved for tunneling important interactive data. If there is no manual route we have (dumping rl1 interface): - all outgoing ipencap traffic goes well - all incoming traffic comes in rl1 but is lost (gif0 interface is empty) It seems that gif interface listens for ipencap on the interface that is on route to destination but not at its source (yyy.yyy.yyy.yyy in my case). How can I force gif to listen on correct interface? Maybe this is corrected in later versions of FreeBSD? Should I upgrade that box? -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 16:14:57 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 2469A16A41F for ; Wed, 25 Jan 2006 16:14:57 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id B620643D58 for ; Wed, 25 Jan 2006 16:14:50 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id AFA0E78C25 for ; Wed, 25 Jan 2006 18:16:24 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47235-04 for ; Wed, 25 Jan 2006 18:16:24 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id E70FD78C21 for ; Wed, 25 Jan 2006 18:16:23 +0200 (EET) Date: Wed, 25 Jan 2006 18:19:55 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.64.01 Christmas Edition) Professional X-Priority: 3 (Normal) Message-ID: <898692010.20060125181955@osk.com.ua> To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Cc: Subject: Policy routing and multipath routing needed (override routing table) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 16:14:57 -0000 Hello, Many people know how to engage policy routing using ipfw forward function. This can be successfully used on simple routers (not NAT gateways) and to make gateways with multiple internet connections provide services (such as DNS, mail etc) on all interfaces. But the difficulty comes when the box itself is the source of packets. For example when mail server sends mail to another server. In this case the source ip of packets is calculated using routing table based on the destination address. These packets can't be correctly routed using policy as in this case we should probably pass these packets through NAT that is not always acceptable and is difficult to perform using standart tools as forwarded packets are not injected into firewall to be diverted through NAT. The easiest way to show this need is a simple planning of interface load division between internet interfaces based on services (for ex. proxy, dns, mail, ftp etc). In this case simple routing table can not provide what we need. The second thing to be mentioned is known as multipath routing. It is a special situation of policy routing but is more easy to develope. It can solve some problems too. I have found a mentioning of developing these functions as "planned" by FreeBSD developers in march 2004 (http://kerneltrap.org/node/2593). The obvious solution of this problem lies in using of Cisco router but this is not good for medium-size business organization due to lack of funds (you know those bosses) as thas router costs like another routing machine ;) It would be great to hear from core team of their plans regarding this network stack changes. There is another problem. In my opinion it should be great to make one more attribute to routes in routing table indicating of their activity/inactivity. The source of this problem is that all static routes on reconfigured interface are deleted as ip changes. If this reconfiguration occurs we need to recreate these routes again. It would be great if they would persisted and for that time were "inactive". One of the solutions in this case would be a tool for monitoring interface state able to activate some script on state change. This would be great for failover for example. Please enlight me and tell if there is any. -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 16:39:15 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 8B68116A41F for ; Wed, 25 Jan 2006 16:39:15 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AC1143D68 for ; Wed, 25 Jan 2006 16:39:13 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id 2D4CB78C2B for ; Wed, 25 Jan 2006 18:40:53 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47447-02 for ; Wed, 25 Jan 2006 18:40:52 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id 88B7C78C29 for ; Wed, 25 Jan 2006 18:40:52 +0200 (EET) Date: Wed, 25 Jan 2006 18:44:24 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.64.01 Christmas Edition) Professional X-Priority: 3 (Normal) Message-ID: <831122596.20060125184424@osk.com.ua> To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Cc: Subject: Failover and load balancing using advanced NAT daemon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 16:39:15 -0000 Hello, I have an idea of implementation of this common task. Please tell me if there is some alternative or use my idea to implement advanced NAT daemon (this would be great). Maybe it would be good to upgrade standart natd daemon. The task: We have several interfaces connected to internet and all having static IPs and one (or more) interfaces to local network. We must provide NATed internet access to local network users load-balancing internet interfaces and providing failover. All session have to "remember" their outgoing interface as one session will break if packets start to come from different IPs. A way to perform this: - We need to monitor interface state (some simple like up/down) or more complex like periodic gateway ping for example. - We need to measure interface load - We need NAT that aliases outgoing connections to one of these interfaces - We need to route outgoing packets based on source IP assigned by NAT. This can be performed using ipfw forward mechanism. First three functions would be great to be implemented inside one daemon like standart natd. Packets should be diverted into it. This daemon can easily perform all of the tasks listed above as all of the packets are passed through it. Using it in a combination with policy-routing would be a powerful mechanism! -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 17:29:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A25C416A41F for ; Wed, 25 Jan 2006 17:29:37 +0000 (GMT) (envelope-from bsd@roamingsolutions.net) Received: from basillia.speedxs.net (basillia.speedxs.net [83.98.255.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5171443D72 for ; Wed, 25 Jan 2006 17:29:33 +0000 (GMT) (envelope-from bsd@roamingsolutions.net) Received: from ongers.net (ongers.speedxs.nl [83.98.237.210]) by basillia.speedxs.net (Postfix) with ESMTP id 17357B5B4; Wed, 25 Jan 2006 18:10:19 +0100 (CET) Received: from (165.146.241.117 [165.146.241.117]) by MailEnable Inbound Mail Agent with ESMTP; Wed, 25 Jan 2006 18:38:01 +0100 Message-ID: <43D7B602.7000501@roamingsolutions.net> Date: Wed, 25 Jan 2006 19:31:46 +0200 From: G Bryant User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD MailList References: <831122596.20060125184424@osk.com.ua> In-Reply-To: <831122596.20060125184424@osk.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0604-2, 2006/01/25), Outbound message X-Antivirus-Status: Clean Cc: FreeBSD Subject: Re: Failover and load balancing using advanced NAT daemon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 17:29:37 -0000 Hey there Oleg, I have done something similar with 2 internet interfaces, but I use very crude IPFW rules to "remember" sessions. I have a seperate natd running for each interface, but my setup includes mail, web and pptp servers on the LAN which complicates matters. I did not have load balancing but am using a ping script to monitor interfaces and re-route traffic using ipfw set's which get enabled and disabled. This ping script could be modified to calculate ping times and shift load by the same method - but that's _really_ rough. I am sure there are much more elegant ways of doing this though. Keep us posted! Graham Oleg Tarasov wrote: >Hello, > >I have an idea of implementation of this common task. Please tell me >if there is some alternative or use my idea to implement advanced NAT >daemon (this would be great). Maybe it would be good to upgrade >standart natd daemon. > >The task: >We have several interfaces connected to internet and all having static >IPs and one (or more) interfaces to local network. >We must provide NATed internet access to local network users >load-balancing internet interfaces and providing failover. All session >have to "remember" their outgoing interface as one session will break >if packets start to come from different IPs. > >A way to perform this: >- We need to monitor interface state (some simple like up/down) or more >complex like periodic gateway ping for example. >- We need to measure interface load >- We need NAT that aliases outgoing connections to one of these >interfaces >- We need to route outgoing packets based on source IP assigned by >NAT. This can be performed using ipfw forward mechanism. > >First three functions would be great to be implemented inside one >daemon like standart natd. Packets should be diverted into it. This >daemon can easily perform all of the tasks listed above as all of the >packets are passed through it. > >Using it in a combination with policy-routing would be a powerful >mechanism! > > > From owner-freebsd-net@FreeBSD.ORG Wed Jan 25 21:05:08 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 498B616A4B3 for ; Wed, 25 Jan 2006 21:05:05 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 998F4449B5 for ; Wed, 25 Jan 2006 20:33:33 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: by uproxy.gmail.com with SMTP id o2so12095uge for ; Wed, 25 Jan 2006 12:33:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z/Fj6PpRR3wMwwM1lucIyFHkFI5LNl+JXJfcvrkWRQaYHtCP799rtD/q3ooO9DfKYlDnGu8JvccewIXS7FBOL/rCep3lGG1YnXewMTT/17Gi9X94amwjtOSD8+MgXY3tjOFIRMfjv55C17E33VuneUE5SE0CHfNx/uqg7SVZ0Lw= Received: by 10.66.252.18 with SMTP id z18mr486057ugh; Wed, 25 Jan 2006 12:26:19 -0800 (PST) Received: by 10.66.223.13 with HTTP; Wed, 25 Jan 2006 12:26:19 -0800 (PST) Message-ID: <8eea04080601251226g752113e4qe815fbb5de7648fb@mail.gmail.com> Date: Wed, 25 Jan 2006 12:26:19 -0800 From: Jon Simola Sender: jsimola@gmail.com To: FreeBSD MailList In-Reply-To: <831122596.20060125184424@osk.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <831122596.20060125184424@osk.com.ua> Cc: freebsd-net@freebsd.org Subject: Re: Failover and load balancing using advanced NAT daemon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2006 21:05:09 -0000 On 1/25/06, Oleg Tarasov wrote: > First three functions would be great to be implemented inside one > daemon like standart natd. Packets should be diverted into it. This > daemon can easily perform all of the tasks listed above as all of the > packets are passed through it. > > Using it in a combination with policy-routing would be a powerful > mechanism! You may want to check out PF, the packet filter imported from OpenBSD. I have it running on some large routers doing NAT out multiple interfaces, load balancing and policy routing. Careful use of anchors and some scripting (or ifstated which might be in ports) can move traffic off failed links or respond to changing loads. I've done a lot with both ipfw and PF now, and I'm finding PF to be more flexible for my uses. -- Jon Simola Systems Administrator ABC Communications From owner-freebsd-net@FreeBSD.ORG Thu Jan 26 01:17:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 9B8F516A42B for ; Thu, 26 Jan 2006 01:17:11 +0000 (GMT) (envelope-from gregorynou@altern.org) Received: from esemetz.metz.supelec.fr (esemetz.metz.supelec.fr [193.48.224.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id D901043D45 for ; Thu, 26 Jan 2006 01:17:10 +0000 (GMT) (envelope-from gregorynou@altern.org) Received: from smtp.metz.supelec.fr (smtp.metz.supelec.fr [193.48.224.205]) by esemetz.metz.supelec.fr (8.11.6/8.9.3) with ESMTP id k0Q1H7Y10316 for ; Thu, 26 Jan 2006 02:17:07 +0100 Received: from [193.48.225.2] (nou.rez-metz.supelec.fr [193.48.225.2]) by smtp.metz.supelec.fr (8.11.6/8.11.6) with ESMTP id k0Q171B14644 for ; Thu, 26 Jan 2006 02:07:02 +0100 Message-ID: <43D8230A.2040808@altern.org> Date: Thu, 26 Jan 2006 02:16:58 +0100 From: Gregory Nou User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Question on IFF_PPROMISC (and IFF_PROMISC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 01:17:11 -0000 Hi, I found a (somewhat old) post from gnn@ on this topic there : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2004-09/0289.html I also think that it would be a good idea to do it (at least, it would be easier to understand, because IFF_PPROMISC is not that explicit). If nobody has already done it, I'll work on this. There is another point on which I would appreciate to know your opinion: referring to if.c[1269], I understand that if IFF_PPROMISC is set in ifp->if_flags, IFF_PROMISC should be set to (or we are in a transient situation). It appears that if_ethersubr.c[652] is working in this case. Isn't it a mistake ? Thanks a lot ! -- Gregory PS : Gleb, Jon, thanks for your answers on vlan. It helped a lot :) From owner-freebsd-net@FreeBSD.ORG Thu Jan 26 06:23:02 2006 Return-Path: X-Original-To: net@freebsd.org 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 C887A16A420; Thu, 26 Jan 2006 06:23:02 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from mail07.powweb.com (mail07.powweb.com [66.152.97.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86A2F43D45; Thu, 26 Jan 2006 06:23:02 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from vixen42.vulpes (24-119-122-41.cpe.cableone.net [24.119.122.41]) by mail07.powweb.com (Postfix) with ESMTP id 71FB114DC9B; Wed, 25 Jan 2006 22:23:01 -0800 (PST) Date: Thu, 26 Jan 2006 00:33:04 -0600 From: Vulpes Velox To: Andre Oppermann Message-ID: <20060126003304.5948e5c0@vixen42.vulpes> In-Reply-To: <43D5FF19.7090903@freebsd.org> References: <43D5FF19.7090903@freebsd.org> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, net@freebsd.org Subject: Re: Marvell/SysKonnect YukonII source code available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 06:23:03 -0000 On Tue, 24 Jan 2006 11:19:05 +0100 Andre Oppermann wrote: > Marvell/SysKonnect made the source code to the YukonII chips > available today under a BSD license: > > http://people.freebsd.org/~andre/mykbsd60x86-8.12.1.3-src.tgz > > I haven't tested the driver yet and I don't know if it available > directly from the their website already. > > Many thanks to Gerald and Frank at SysKonnect for working with us > and making this possible! Who would one send bug reports too? I have a 88E8053 in a laptop with a releng_6 install that is up to date as of saturday. The status of the connection does not change off of "no carrier". From owner-freebsd-net@FreeBSD.ORG Thu Jan 26 09:05:11 2006 Return-Path: X-Original-To: net@freebsd.org 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 177EA16A420; Thu, 26 Jan 2006 09:05:11 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93A0443D46; Thu, 26 Jan 2006 09:05:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 3F74D1FFDEC; Thu, 26 Jan 2006 10:05:08 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 793471FFDE6; Thu, 26 Jan 2006 10:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id BCDC844487E; Thu, 26 Jan 2006 09:03:47 +0000 (UTC) Date: Thu, 26 Jan 2006 09:03:47 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Vulpes Velox In-Reply-To: <20060126003304.5948e5c0@vixen42.vulpes> Message-ID: <20060126085338.T24703@maildrop.int.zabbadoz.net> References: <43D5FF19.7090903@freebsd.org> <20060126003304.5948e5c0@vixen42.vulpes> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: FreeBSD current mailing list , FreeBSD net mailing list Subject: Re: Marvell/SysKonnect YukonII source code available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 09:05:11 -0000 On Thu, 26 Jan 2006, Vulpes Velox wrote: > On Tue, 24 Jan 2006 11:19:05 +0100 > Andre Oppermann wrote: > >> Marvell/SysKonnect made the source code to the YukonII chips >> available today under a BSD license: ... >> >> I haven't tested the driver yet and I don't know if it available >> directly from the their website already. > > Who would one send bug reports too? well, that's a good question. > I have a 88E8053 in a laptop with a releng_6 install that is up to > date as of saturday. The status of the connection does not change off > of "no carrier". Yeah lucky you. I have manually updated it so it compiles on HEAD but loading it on amd64 makes the machine panic. Not that I'd have expected it to fully work asap;) I guess it would be best to wait until the driver is officially supported by the FreeBSD project (read once it is comitted). -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Thu Jan 26 10:24:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2625E16A420 for ; Thu, 26 Jan 2006 10:24:35 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D24943D46 for ; Thu, 26 Jan 2006 10:24:33 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id 33A7E78C2C; Thu, 26 Jan 2006 12:26:07 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51596-05; Thu, 26 Jan 2006 12:26:06 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id 77F4178C1C; Thu, 26 Jan 2006 12:26:06 +0200 (EET) Date: Thu, 26 Jan 2006 12:25:24 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.64.01 Christmas Edition) Professional X-Priority: 3 (Normal) Message-ID: <412777922.20060126122524@osk.com.ua> To: Jon Simola In-Reply-To: <8eea04080601251226g752113e4qe815fbb5de7648fb@mail.gmail.com> References: <831122596.20060125184424@osk.com.ua> <8eea04080601251226g752113e4qe815fbb5de7648fb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Cc: freebsd-net@freebsd.org Subject: Re: Failover and load balancing using advanced NAT daemon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 10:24:35 -0000 Hello, Jon Simola wrote: > You may want to check out PF, the packet filter imported from OpenBSD. > I have it running on some large routers doing NAT out multiple > interfaces, load balancing and policy routing. Careful use of anchors > and some scripting (or ifstated which might be in ports) can move > traffic off failed links or respond to changing loads. > I've done a lot with both ipfw and PF now, and I'm finding PF to be > more flexible for my uses. Thanks. I've looked through PF documentation and find it quite interesting to use in this tasks. In combination with ifstated much can be done. I'm sorry for my incompetence in this case. I have always used ipfw for packet processing and now find a mistake not looking through PF. As I can now say ipfw is faster and easier to configure, but PF contains more flexible mechanisms supporting aliasing address pools for NAT and stateful routing. The only visible problem I see is a lack of policy routing in FreeBSD routing system which is used to create session listener when packets origin is a router itself (like tunnels) and packets cant be passed through NAT to be routed to another interface different from that in routing table. -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua From owner-freebsd-net@FreeBSD.ORG Thu Jan 26 15:01:54 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 721F716A420 for ; Thu, 26 Jan 2006 15:01:54 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9489043D49 for ; Thu, 26 Jan 2006 15:01:53 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id EF6C878C2A for ; Thu, 26 Jan 2006 17:03:27 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52979-07 for ; Thu, 26 Jan 2006 17:03:27 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id 5A24D78C1D for ; Thu, 26 Jan 2006 17:03:27 +0200 (EET) Date: Thu, 26 Jan 2006 17:01:50 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.64.01 Christmas Edition) Professional X-Priority: 3 (Normal) Message-ID: <1623226562.20060126170150@osk.com.ua> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Subject: Named could not listen on UDP socket: permission denied X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 15:01:54 -0000 Hello, I run FreeBSD 6.0 and I have begun to recieve quite periodic error messages like these: Jan 25 19:45:50 central named[728]: could not listen on UDP socket: permission denied Jan 25 19:45:50 central named[728]: creating IPv4 interface ng0 failed; interface ignored ng0 is my main internet interface and is created on early boot (rcordered like ppp-user) by mpd. Certainly, I need DNS listening on this interface. The reason is that if mpd is restarted for some reason, interface ng0 is destroyed and created again while listener on this interface is destroyed too. Named is chrooted at this time and cannot re-bind listener on this interface. Only manual restart of named helps it bind to this interface. This is not deadly situation as if I manually restart mpd I will be able to restart named too... Running named under root user or out of chroot environment is not quite acceptable way... Please tell me if this problem has a solution other then above -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua From owner-freebsd-net@FreeBSD.ORG Thu Jan 26 16:10:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A1A7516A420 for ; Thu, 26 Jan 2006 16:10:23 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E19143D48 for ; Thu, 26 Jan 2006 16:10:21 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id 3E02078C2A for ; Thu, 26 Jan 2006 18:11:56 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53551-13 for ; Thu, 26 Jan 2006 18:11:54 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id 98A6678C30 for ; Thu, 26 Jan 2006 18:11:54 +0200 (EET) Date: Thu, 26 Jan 2006 18:10:18 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.64.01 Christmas Edition) Professional X-Priority: 3 (Normal) Message-ID: <83462512.20060126181018@osk.com.ua> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Subject: Duplicate SAD entries lead to ESP tunnel malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 16:10:23 -0000 Hello, I run FreeBSD 6.0 and installed latest ported version of ipsec-tools. A had to create two IPSEC tunnels to two different hosts. On one host runs FreeBSD too, on another host is located hardware router DI-804HV (D-Link). That router is supposed to support IPSEC tunnelling and seems to work fine. When IPSEC tunnel is established two SAD entries are created - one per direction. This is normal functioning. In my case sometimes there are two more created. Some connection problem occurs causing both sides to reestablish tunnel. Both sides report that tunnel is established successfully but no packets can pass through tunnel. Dumping SAD entries using setkey -D shows that there are two SAD entries for both address pairs. How can this happen anyway? Flushing SAD entries helps tunnel to return its functionality - after this tunnel is established successfully and works properly. ======================================================================= central# setkey -D 172.21.0.222 172.21.0.224 esp mode=tunnel spi=230854012(0x0dc28d7c) reqid=0(0x00000000) E: 3des-cbc dabdc3b8 ea8f9519 c755b2da 57d348f5 a319f839 555e5759 A: hmac-md5 8139183d b8c06aea 65ac6a72 4c93f714 seq=0x00003c46 replay=4 flags=0x00000000 state=mature created: Jan 26 17:58:29 2006 current: Jan 26 18:58:41 2006 diff: 3612(s) hard: 28800(s) soft: 23040(s) last: Jan 26 18:58:35 2006 hard: 0(s) soft: 0(s) current: 2689960(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 15430 hard: 0 soft: 0 sadb_seq=5 pid=5501 refcnt=2 172.21.0.224 172.21.0.222 esp mode=tunnel spi=192143459(0x0b73e063) reqid=0(0x00000000) E: 3des-cbc 5b75d9dc b2cba7c5 be08b863 e11e3c79 b993f636 d76b4437 A: hmac-md5 69759773 cfeb1fe1 e0dac25f 5360851e seq=0x000030fd replay=4 flags=0x00000000 state=mature created: Jan 26 17:58:29 2006 current: Jan 26 18:58:41 2006 diff: 3612(s) hard: 28800(s) soft: 23040(s) last: Jan 26 18:58:35 2006 hard: 0(s) soft: 0(s) current: 1781854(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 12541 hard: 0 soft: 0 sadb_seq=4 pid=5501 refcnt=1 172.21.0.222 172.21.0.225 esp mode=tunnel spi=1241514000(0x4a000010) reqid=0(0x00000000) E: 3des-cbc 71061694 cf98e926 fed56e44 ca6437fd d681a362 36342bd0 A: hmac-md5 8c62152f 272b19d5 dcda82db 4772d15c seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Jan 26 18:49:30 2006 current: Jan 26 18:58:41 2006 diff: 551(s) hard: 28800(s) soft: 23040(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=3 pid=5501 refcnt=1 172.21.0.222 172.21.0.225 esp mode=tunnel spi=1207959568(0x48000010) reqid=0(0x00000000) E: 3des-cbc 17aab273 2df4dca8 7871aa0c b3342a68 35221d02 bbbabbf6 A: hmac-md5 4f708fc1 1762371d 95e55918 1a167a31 seq=0x000000a7 replay=4 flags=0x00000000 state=mature created: Jan 26 17:58:03 2006 current: Jan 26 18:58:41 2006 diff: 3638(s) hard: 28800(s) soft: 23040(s) last: Jan 26 18:58:30 2006 hard: 0(s) soft: 0(s) current: 18656(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 167 hard: 0 soft: 0 sadb_seq=2 pid=5501 refcnt=2 172.21.0.225 172.21.0.222 esp mode=tunnel spi=220625554(0x0d267a92) reqid=0(0x00000000) E: 3des-cbc a446d441 856a0ed3 0f8d8ad8 065a6b27 da756609 98fa670e A: hmac-md5 7f14777f e5131500 8c345030 d90900d2 seq=0x00000003 replay=4 flags=0x00000000 state=mature created: Jan 26 18:49:30 2006 current: Jan 26 18:58:41 2006 diff: 551(s) hard: 28800(s) soft: 23040(s) last: Jan 26 18:49:56 2006 hard: 0(s) soft: 0(s) current: 144(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 3 hard: 0 soft: 0 sadb_seq=1 pid=5501 refcnt=1 172.21.0.225 172.21.0.222 esp mode=tunnel spi=90138890(0x055f690a) reqid=0(0x00000000) E: 3des-cbc 4f77a3d4 7d2e446c a0e54ee5 ed482e15 e6e4b75b d723803c A: hmac-md5 ebc9281a 780016ce 295ad45a 9d969b46 seq=0x0000009e replay=4 flags=0x00000000 state=mature created: Jan 26 17:58:03 2006 current: Jan 26 18:58:41 2006 diff: 3638(s) hard: 28800(s) soft: 23040(s) last: Jan 26 18:00:44 2006 hard: 0(s) soft: 0(s) current: 9480(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 158 hard: 0 soft: 0 sadb_seq=0 pid=5501 refcnt=1 ======================================================================= central# setkey -D -P 192.168.0.0/24[any] 192.168.82.0/24[any] any in ipsec esp/tunnel/172.21.0.224-172.21.0.222/require created: Jan 26 15:20:00 2006 lastused: Jan 26 18:59:06 2006 lifetime: 0(s) validtime: 0(s) spid=16390 seq=3 pid=5513 refcnt=1 192.168.1.0/24[any] 192.168.82.0/24[any] any in ipsec esp/tunnel/172.21.0.225-172.21.0.222/require created: Jan 26 15:20:00 2006 lastused: Jan 26 18:49:56 2006 lifetime: 0(s) validtime: 0(s) spid=16392 seq=2 pid=5513 refcnt=1 192.168.82.0/24[any] 192.168.0.0/24[any] any out ipsec esp/tunnel/172.21.0.222-172.21.0.224/require created: Jan 26 15:20:00 2006 lastused: Jan 26 18:59:06 2006 lifetime: 0(s) validtime: 0(s) spid=16389 seq=1 pid=5513 refcnt=1 192.168.82.0/24[any] 192.168.1.0/24[any] any out ipsec esp/tunnel/172.21.0.222-172.21.0.225/require created: Jan 26 15:20:00 2006 lastused: Jan 26 18:58:30 2006 lifetime: 0(s) validtime: 0(s) spid=16391 seq=0 pid=5513 refcnt=1 ======================================================================= /var/log/racoon.log Jan 26 17:41:39 central racoon: INFO: IPsec-SA established: ESP/Tunnel 172.21.0.225[0]->172.21.0.222[0] spi=120109393(0x 728b951) Jan 26 17:41:39 central racoon: INFO: IPsec-SA established: ESP/Tunnel 172.21.0.222[0]->172.21.0.225[0] spi=1157627920(0 x45000010) Jan 26 17:55:59 central racoon: INFO: purged IPsec-SA proto_id=ESP spi=1157627920. Jan 26 17:55:59 central racoon: INFO: purging ISAKMP-SA spi=d1637c3987692522:b339bd2ace610860. Jan 26 17:55:59 central racoon: INFO: keeping IPsec-SA spi=1090519056 - found valid ISAKMP-SA spi=f6907895966fed7d:f17fc ca46153f83f. Jan 26 17:55:59 central racoon: INFO: Unknown IPsec-SA spi=120109393, hmmmm? Jan 26 17:55:59 central racoon: INFO: purged IPsec-SA spi=120109393. Jan 26 17:55:59 central racoon: INFO: keeping IPsec-SA spi=85976071 - found valid ISAKMP-SA spi=f6907895966fed7d:f17fcca 46153f83f. Jan 26 17:55:59 central racoon: INFO: purged ISAKMP-SA spi=d1637c3987692522:b339bd2ace610860. Jan 26 17:56:00 central racoon: INFO: respond new phase 1 negotiation: 172.21.0.222[500]<=>172.21.0.225[500] Jan 26 17:56:00 central racoon: INFO: begin Identity Protection mode. Jan 26 17:56:00 central racoon: WARNING: SPI size isn't zero, but IKE proposal. Jan 26 17:56:00 central racoon: INFO: ISAKMP-SA deleted 172.21.0.222[500]-172.21.0.225[500] spi:d1637c3987692522:b339bd2 ace610860 Jan 26 17:56:00 central racoon: INFO: ISAKMP-SA established 172.21.0.222[500]-172.21.0.225[500] spi:34637a9c843982ca:b55 cb815ad6bd124 Jan 26 17:56:00 central racoon: INFO: respond new phase 2 negotiation: 172.21.0.222[0]<=>172.21.0.225[0] Jan 26 17:56:01 central racoon: INFO: IPsec-SA established: ESP/Tunnel 172.21.0.225[0]->172.21.0.222[0] spi=76313686(0x4 8c7456) Jan 26 17:56:01 central racoon: INFO: IPsec-SA established: ESP/Tunnel 172.21.0.222[0]->172.21.0.225[0] spi=1191182352(0 x47000010) Jan 26 17:58:03 central racoon: INFO: respond new phase 2 negotiation: 172.21.0.222[0]<=>172.21.0.225[0] Jan 26 17:58:03 central racoon: INFO: IPsec-SA established: ESP/Tunnel 172.21.0.225[0]->172.21.0.222[0] spi=90138890(0x5 5f690a) Jan 26 17:58:03 central racoon: INFO: IPsec-SA established: ESP/Tunnel 172.21.0.222[0]->172.21.0.225[0] spi=1207959568(0 x48000010) Jan 26 17:58:29 central racoon: INFO: respond new phase 2 negotiation: 172.21.0.222[0]<=>172.21.0.224[0] Jan 26 17:58:29 central racoon: INFO: IPsec-SA established: ESP/Tunnel 172.21.0.224[0]->172.21.0.222[0] spi=192143459(0x b73e063) Jan 26 17:58:29 central racoon: INFO: IPsec-SA established: ESP/Tunnel 172.21.0.222[0]->172.21.0.224[0] spi=230854012(0x dc28d7c) Jan 26 18:49:30 central racoon: INFO: respond new phase 1 negotiation: 172.21.0.222[500]<=>172.21.0.225[500] Jan 26 18:49:30 central racoon: INFO: begin Identity Protection mode. Jan 26 18:49:30 central racoon: WARNING: SPI size isn't zero, but IKE proposal. Jan 26 18:49:30 central racoon: INFO: ISAKMP-SA established 172.21.0.222[500]-172.21.0.225[500] spi:7a61b69ba520e1c9:a6b d1e28db6d3794 Jan 26 18:49:30 central racoon: INFO: respond new phase 2 negotiation: 172.21.0.222[0]<=>172.21.0.225[0] Jan 26 18:49:30 central racoon: INFO: IPsec-SA established: ESP/Tunnel 172.21.0.225[0]->172.21.0.222[0] spi=220625554(0x d267a92) Jan 26 18:49:30 central racoon: INFO: IPsec-SA established: ESP/Tunnel 172.21.0.222[0]->172.21.0.225[0] spi=1241514000(0 x4a000010) ======================================================================= /usr/local/etc/racoon/racoon.conf path include "/usr/local/etc/racoon" ; path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; path certificate "/usr/local/etc/cert" ; padding { maximum_length 20; # maximum padding length. randomize off; # enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } listen { isakmp 172.21.0.222 [500]; } timer { # These value can be changed per remote node. counter 5; # maximum trying count to send. interval 20 sec; # maximum interval to resend. persend 1; # the number of packets per a send. # timer for waiting to complete each phase. phase1 30 sec; phase2 15 sec; } remote 172.21.0.224 { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.21.0.222; peers_identifier address 172.21.0.224; nonce_size 16; lifetime time 86400 sec; # sec,min,hour initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key ; dh_group 1 ; } } remote 172.21.0.225 { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.21.0.222; peers_identifier address 172.21.0.225; nonce_size 16; lifetime time 86400 sec; # sec,min,hour initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key ; dh_group 1 ; } } sainfo anonymous { pfs_group 1; lifetime time 28800 sec; encryption_algorithm 3des ; authentication_algorithm hmac_md5; compression_algorithm deflate ; } ============================================================== /etc/ipsec.conf flush; spdflush; spdadd 192.168.82.0/24 192.168.0.0/24 any -P out ipsec esp/tunnel/172.21.0.222-172.21.0.224/require; spdadd 192.168.0.0/24 192.168.82.0/24 any -P in ipsec esp/tunnel/172.21.0.224-172.21.0.222/require; spdadd 192.168.82.0/24 192.168.1.0/24 any -P out ipsec esp/tunnel/172.21.0.222-172.21.0.225/require; spdadd 192.168.1.0/24 192.168.82.0/24 any -P in ipsec esp/tunnel/172.21.0.225-172.21.0.222/require; ============================================================== -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua From owner-freebsd-net@FreeBSD.ORG Thu Jan 26 19:51:37 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 5042816A420 for ; Thu, 26 Jan 2006 19:51:37 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id D929A43D49 for ; Thu, 26 Jan 2006 19:51:36 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 26 Jan 2006 11:51:36 -0800 Message-ID: <43D92848.2050005@elischer.org> Date: Thu, 26 Jan 2006 11:51:36 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD MailList References: <83462512.20060126181018@osk.com.ua> In-Reply-To: <83462512.20060126181018@osk.com.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Duplicate SAD entries lead to ESP tunnel malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 19:51:37 -0000 Oleg Tarasov wrote: >Hello, > >I run FreeBSD 6.0 and installed latest ported version of ipsec-tools. > >A had to create two IPSEC tunnels to two different hosts. On one host >runs FreeBSD too, on another host is located hardware router DI-804HV >(D-Link). That router is supposed to support IPSEC tunnelling and >seems to work fine. > >When IPSEC tunnel is established two SAD entries are created - one per >direction. This is normal functioning. > >In my case sometimes there are two more created. Some connection >problem occurs causing both sides to reestablish tunnel. Both sides >report that tunnel is established successfully but no packets can pass >through tunnel. Dumping SAD entries using > setkey -D >shows that there are two SAD entries for both address pairs. > >How can this happen anyway? > >Flushing SAD entries helps tunnel to return its functionality - after >this tunnel is established successfully and works properly. > > There is a sysctl that can help this behaviour but I forget which something to do with ipsec and oldSAD or newSAD or something.. >========== > > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 26 23:29:50 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 A2A7B16A420 for ; Thu, 26 Jan 2006 23:29:50 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.wsfamily.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FF4843D45 for ; Thu, 26 Jan 2006 23:29:50 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tiago Cruz References: <1138044412.4224.21.camel@localhost.localdomain> <20060123204939.A46D4DCAA42@mail.npubs.com> <1138110261.6174.27.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20060126235041.3981BDCA990@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Thu, 26 Jan 2006 23:50:43 +0000 (GMT) Cc: "freebsd-net@FreeBSD.org" Subject: Re: VPN when host is not gateway X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2006 23:29:50 -0000 Tiago Cruz wrote: > On Mon, 2006-01-23 at 20:49 +0000, Nate Nielsen wrote: > > >>I'd use tcpdump on the various interfaces (tap devices, ethernet) on the >>machines in question to see exactly at which host is not forwarding the >>packets properly and where they're going. > > > Thank you Nielsen! > I'm not expert in art of tcpdump, bu I see that: > > So, my questions is this: How I make this route? I guess either with the 'route' command or by running a routing protocol like RIP or OSPF. Cheers, Nate From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 02:05:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 D04B816A420 for ; Fri, 27 Jan 2006 02:05:29 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C47343D70 for ; Fri, 27 Jan 2006 02:05:29 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 330D12AA01; Thu, 26 Jan 2006 20:05:29 -0600 (CST) Date: Thu, 26 Jan 2006 20:05:28 -0600 From: Craig Boston To: freebsd-net@freebsd.org Message-ID: <20060127020528.GA18728@nowhere> References: <20060125152032.GA40581@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060125152032.GA40581@nowhere> User-Agent: Mutt/1.4.2.1i Subject: Re: Race condition in ip6_getpmtu (actually gif)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 02:05:29 -0000 On Wed, Jan 25, 2006 at 09:20:33AM -0600, craig@olyun.gank.org wrote: > I seem to be running into a race condition in ip6_getpmtu. I've been > having sporadic panics recently -- sometimes the machine will last a > week, sometimes it'll panic twice in a day. The backtrace is always the > same: > > -- snip -- After some more analysis I think this is a problem in in6_gif_output. It keeps a cached route in its softc. After ip6_output completes, if IFF_LINK0 is not set, the cached route is freed. This works fine so long as in6_gif_output is not reentered. My current theory is that a higher priority kernel thread is preempting while we're somewhere in ip6_getmtu. Say, an incoming IPv4 ICMP packet might cause the NIC driver to call ether_input from an ithread. Since IPv4 is marked NETISR_MPSAFE it will be dispatched from the ithread, filter all the way down to icmp_input, which decides that an ICMP reply needs to be sent a host across the tunnel. It goes to icmp_send, which passes it to ip_output. The destination is a gif interface, so into gif_output we go, and BAM! We just re-entered in6_gif_output while still in the ithread. When this happens, the route cached in the sc is still valid, so a new one is not allocated. After ip6_output completes, the route is freed and set to NULL. Later, context returns to the original thread, and ip6_getpmtu (called from ip6_output) has just had its route pulled out from under it... It's a longshot, but I think it is possible and that would certainly explain why it sometimes takes millions of packets to trigger. Attached is a quick hack to protect the cached route with a mutex. A better fix with less overhead would be to allocate the route in a local variable on the stack, and only copy it to the softc if route caching is enabled. I'll run for a couple weeks with the patch and file a PR if that fixes it. If I have time I'll also try to set up a test machine and attempt to detect if ip6_gif_output is indeed reentered, and if so how. I think this should only be a problem for gif when IPv4 is the inner protocol and IPv6 is the outer. Since IPv4 is MPSAFE and v6 is not, gif might sometimes inadvertently cause v6 code that hasn't been fully locked to be re-entered or otherwise called without GIANT held. There may be other problems that are less likely to occur... Craig From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 02:10:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 33E9716A420 for ; Fri, 27 Jan 2006 02:10:49 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECF3043D45 for ; Fri, 27 Jan 2006 02:10:48 +0000 (GMT) (envelope-from craig@olyun.gank.org) Received: by ion.gank.org (mail, from userid 1001) id C8D392ACCF; Thu, 26 Jan 2006 20:10:48 -0600 (CST) Date: Thu, 26 Jan 2006 20:10:48 -0600 From: Craig Boston To: freebsd-net@freebsd.org Message-ID: <20060127021048.GB18728@nowhere> References: <20060125152032.GA40581@nowhere> <20060127020528.GA18728@nowhere> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20060127020528.GA18728@nowhere> User-Agent: Mutt/1.4.2.1i Subject: Re: Race condition in ip6_getpmtu (actually gif)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 02:10:49 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 26, 2006 at 08:05:28PM -0600, Craig Boston wrote: > Attached is a quick hack... Whoops, patch _actually_ attached this time. --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gif6.patch" === net/if_gif.c ================================================================== --- net/if_gif.c (/vendor/sys) (revision 292) +++ net/if_gif.c (/gif6) (revision 292) @@ -154,6 +154,8 @@ return (ENOSPC); } + mtx_init(&sc->gif_ro_mtx, "gif_ro_mtx", NULL, MTX_DEF); + GIF2IFP(sc)->if_softc = sc; if_initname(GIF2IFP(sc), ifc->ifc_name, unit); @@ -227,6 +229,7 @@ mtx_lock(&gif_mtx); LIST_REMOVE(sc, gif_list); mtx_unlock(&gif_mtx); + mtx_destroy(&sc->gif_ro_mtx); gif_destroy(sc); } === net/if_gif.h ================================================================== --- net/if_gif.h (/vendor/sys) (revision 292) +++ net/if_gif.h (/gif6) (revision 292) @@ -65,6 +65,7 @@ struct route_in6 gifscr_ro6; /* xxx */ #endif } gifsc_gifscr; + struct mtx gif_ro_mtx; int gif_flags; const struct encaptab *encap_cookie4; const struct encaptab *encap_cookie6; === netinet6/in6_gif.c ================================================================== --- netinet6/in6_gif.c (/vendor/sys) (revision 292) +++ netinet6/in6_gif.c (/gif6) (revision 292) @@ -195,25 +195,30 @@ dst->sin6_family = sin6_dst->sin6_family; dst->sin6_len = sizeof(struct sockaddr_in6); dst->sin6_addr = sin6_dst->sin6_addr; + mtx_lock(&sc->gif_ro_mtx); if (sc->gif_ro6.ro_rt) { RTFREE(sc->gif_ro6.ro_rt); sc->gif_ro6.ro_rt = NULL; } + mtx_unlock(&sc->gif_ro_mtx); #if 0 GIF2IFP(sc)->if_mtu = GIF_MTU; #endif } + mtx_lock(&sc->gif_ro_mtx); if (sc->gif_ro6.ro_rt == NULL) { rtalloc((struct route *)&sc->gif_ro6); if (sc->gif_ro6.ro_rt == NULL) { m_freem(m); + mtx_unlock(&sc->gif_ro_mtx); return ENETUNREACH; } /* if it constitutes infinite encapsulation, punt. */ if (sc->gif_ro.ro_rt->rt_ifp == ifp) { m_freem(m); + mtx_unlock(&sc->gif_ro_mtx); return ENETUNREACH; /*XXX*/ } #if 0 @@ -238,6 +243,7 @@ RTFREE(sc->gif_ro6.ro_rt); sc->gif_ro6.ro_rt = NULL; } + mtx_unlock(&sc->gif_ro_mtx); return (error); } --Kj7319i9nmIyA2yE-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 08:45:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 5FE5016A420 for ; Fri, 27 Jan 2006 08:45:25 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from corwin.easynet.fr (smarthost171.mail.easynet.fr [212.180.1.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C9CB43D7E for ; Fri, 27 Jan 2006 08:45:14 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from easyconnect2121135-233.clients.easynet.fr ([212.11.35.233] helo=smtp.zeninc.net) by corwin.easynet.fr with esmtp (Exim 4.50) id 1F2PEG-0007yq-OI for freebsd-net@freebsd.org; Fri, 27 Jan 2006 09:45:13 +0100 Received: by smtp.zeninc.net (smtpd, from userid 1000) id 164B83F17; Fri, 27 Jan 2006 09:44:58 +0100 (CET) Date: Fri, 27 Jan 2006 09:44:58 +0100 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20060127084457.GA21360@zen.inc> References: <83462512.20060126181018@osk.com.ua> <43D92848.2050005@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43D92848.2050005@elischer.org> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Duplicate SAD entries lead to ESP tunnel malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 08:45:25 -0000 On Thu, Jan 26, 2006 at 11:51:36AM -0800, Julian Elischer wrote: > Oleg Tarasov wrote: > There is a sysctl that can help this behaviour but I forget which > > something to do with ipsec and oldSAD or newSAD or something.. net.key.prefered_oldsa, or net.key.preferred_oldsa (changed since 4.X). It is 1 by default, and it should be set to 0 to help better interoperability with lots of peers..... Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 09:36:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 E196E16A422 for ; Fri, 27 Jan 2006 09:36:52 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from gandalf.osk.com.ua (osk.com.ua [195.5.17.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B03B43D45 for ; Fri, 27 Jan 2006 09:36:51 +0000 (GMT) (envelope-from subscriber@osk.com.ua) Received: from localhost (localhost [127.0.0.1]) by gandalf.osk.com.ua (Postfix) with ESMTP id A22FF78C1F; Fri, 27 Jan 2006 11:38:22 +0200 (EET) Received: from gandalf.osk.com.ua ([127.0.0.1]) by localhost (gandalf.osk.com.ua [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60284-10; Fri, 27 Jan 2006 11:38:22 +0200 (EET) Received: from OLEG (unknown [192.168.82.111]) by gandalf.osk.com.ua (Postfix) with ESMTP id EE0A578C1D; Fri, 27 Jan 2006 11:38:21 +0200 (EET) Date: Fri, 27 Jan 2006 11:36:46 +0200 From: Oleg Tarasov X-Mailer: The Bat! (v3.64.01 Christmas Edition) Professional X-Priority: 3 (Normal) Message-ID: <603364524.20060127113646@osk.com.ua> To: VANHULLEBUS Yvan In-Reply-To: <20060127084457.GA21360@zen.inc> References: <83462512.20060126181018@osk.com.ua> <43D92848.2050005@elischer.org> <20060127084457.GA21360@zen.inc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at osk.com.ua Cc: freebsd-net@freebsd.org Subject: Re: Duplicate SAD entries lead to ESP tunnel malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD MailList List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 09:36:53 -0000 Hello, VANHULLEBUS Yvan wrote: > net.key.prefered_oldsa, or net.key.preferred_oldsa (changed since > 4.X). > It is 1 by default, and it should be set to 0 to help better > interoperability with lots of peers..... This seems quite like correct solution. I analyzed behavior of the interface and saw upcoming ping requests (obviously) AND outgoing ping echoes, but remote host didn't get them. Obviously incoming packets were decrypted using one of SAs (the new one) but outgoing packets were encrypted using old SA which is not present on remote host due to some problems (like forced reboot, connection problems etc). Normally in this case remote host must report of unknown spi, but rather it lacks this function or it just ignores these packets. As it is a hardware router I am unaware of its behavior. I will test this solution for some time but I am sure this will help. Thanx for really great help - all these troubles are on my production box and every minute of malfunction returns to me with #not good# words of my boss :/ -- Best regards, Oleg Tarasov mailto:subscriber@osk.com.ua From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 10:34:19 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 8522016A420 for ; Fri, 27 Jan 2006 10:34:19 +0000 (GMT) (envelope-from tiagocruz@b4br.net) Received: from vader.b4br.net (vader.b4br.net [200.152.202.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1289943D46 for ; Fri, 27 Jan 2006 10:34:18 +0000 (GMT) (envelope-from tiagocruz@b4br.net) Received: from localhost (localhost.b4br.net [127.0.0.1]) by vader.b4br.net (Postfix) with ESMTP id 4310E18142A; Fri, 27 Jan 2006 08:28:55 -0200 (BRST) Received: from vader.b4br.net ([127.0.0.1]) by localhost (vader.b4br.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82920-03; Fri, 27 Jan 2006 08:28:41 -0200 (BRST) Received: from tuxkiller.matter.b4br.net (yoda.b4br.net [200.152.202.10]) by vader.b4br.net (Postfix) with ESMTP id BBA53181429; Fri, 27 Jan 2006 08:28:41 -0200 (BRST) From: Tiago Cruz To: nielsen@memberwebs.com In-Reply-To: <20060126235041.3981BDCA990@mail.npubs.com> References: <1138044412.4224.21.camel@localhost.localdomain> <20060123204939.A46D4DCAA42@mail.npubs.com> <1138110261.6174.27.camel@localhost.localdomain> <20060126235041.3981BDCA990@mail.npubs.com> Content-Type: text/plain Date: Fri, 27 Jan 2006 08:34:04 -0200 Message-Id: <1138358044.9340.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at b4br.net Cc: "freebsd-net@FreeBSD.org" Subject: Re: VPN when host is not gateway X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 10:34:19 -0000 On Thu, 2006-01-26 at 23:50 +0000, Nate Nielsen wrote: > > So, my questions is this: How I make this route? > > I guess either with the 'route' command or by running a routing protocol > like RIP or OSPF. Thank you, but I can do this: I make this route at my FreeBSD gateway: cat /usr/local/etc/rc.d/routes.sh #!/usr/local/bin/bash route delete 10.8.0.0 &> /dev/null route add -net 10.8.0.0 -netmask 255.255.255.0 192.168.0.253 &>/dev/null And now all works very good :-) -- Tiago Cruz http://linuxrapido.org Linux User #282636 "The box said: Requires MS Windows or better, so I installed Linux" From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 13:00:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 60A8C16A420; Fri, 27 Jan 2006 13:00:53 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E855243D49; Fri, 27 Jan 2006 13:00:52 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id F1D49AD; Fri, 27 Jan 2006 08:01:13 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 849337B83; Fri, 27 Jan 2006 08:01:12 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2TDc-000Fh1-V9; Fri, 27 Jan 2006 13:00:49 +0000 Date: Fri, 27 Jan 2006 13:00:48 +0000 From: Brian Candler To: freebsd-net@freebsd.org Message-ID: <20060127130048.GA60219@uk.tiscali.com> References: <20060105110404.GA25737@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060105110404.GA25737@uk.tiscali.com> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: sl2tps, MRU, MTU, and MSS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 13:00:53 -0000 On Thu, Jan 05, 2006 at 11:04:04AM +0000, Brian Candler wrote: > I've done a bit more debugging on the MSS problem I'm having with sl2tps > running with IPSEC transport layer security. The client is Windows XP > out-of-the-box. > > Here's what happens: > > 1. PPP negotiates an MRU of 1400 > 2. However, ifconfig ng0 shows an MTU of 1376 (where does that come from?) > 3. When the client opens a TCP connection, it offers an MSS of 1360 ...and then fragmentation problems occur, because the remote server sends IP datagrams which are 1400 bytes with DF bit set, the ng0 interface with MTU 1376 rejects them, the generated ICMP messages are discarded by an intervening NAT gateway, and the TCP connection fails. > root@candlerb ~# ifconfig ng0 > ng0: flags=88d1 mtu 1376 > inet 172.17.0.216 --> 192.168.100.100 netmask 0xffffffff I've done some digging, and I've found the sources of this problem, but I don't know what the right fixes are. After PPP has negotiated an MRU of 1400, why does the ng0 interface get an MTU of 1376? There appear to be two reasons for this. (1) In libpdel, file ppp/ppp_link.c, the interface MRU is explicitly set to 20 less than the requested MRU: #define WINXP_PPTP_HACK(x) ((x) - 20) /* winxp pptp stupidity hack */ ... lconf->mru = MIN( WINXP_PPTP_HACK(link->lcp_req.mru[PPP_PEER]), ppp_channel_get_mtu(link->device)); My test client for L2TP over IPSEC does happen to be WINXP, but as far as I can see this hack is done unconditionally. (2a) In libpdel, file ppp/ppp_bundle.c, the interface MTU is taken from the PPP MRU, and then additionally 4 is subtracted if conf.mppe_40, conf.mppe_56 or conf.mppe_128 is set. if (bundle->conf.mppe_40 || bundle->conf.mppe_56 || bundle->conf.mppe_128) mtu -= 4; /* allow for mppe header */ Note that this happens even if MPPE has not been negotiated. (2b) in sl2tps, file sls_manager.c, conf->mppe_128 is set to 1 conf->mppe_128 = 1; conf->mppe_stateless = 1; Now, if I modify sl2tps to set conf->mppe_128 to 0, and I change the WINXP_PPTP_HACK macro to make it a no-op, my L2TP/IPSEC client connects, ng0 gets the correct MTU of 1400, and TCP traffic flows happily through the tunnel. So what's the correct fix? Well in case (2), I'd have thought that the MTU should not be reduced by 4 unless MPPE has actually been negotiated in CCP (option 18, see RFC 3078). For case (1), I don't know, because I don't know where the WINXP_PPTP_HACK macro comes from or under what circumstances it is required. All I can say is that WINXP using L2TP over IPSEC does *not* need this hack (and indeed, the hack breaks things). Perhaps it should only be used if PPTP is the underlying transport. I don't know if there's a straightforward way to detect when that's the case. Is there anyone here who knows the libpdel ppp code better and can suggest the right fixes? Thanks, Brian. From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 13:53:48 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 CDA9616A420 for ; Fri, 27 Jan 2006 13:53:48 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 781E443D45 for ; Fri, 27 Jan 2006 13:53:48 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 8512DEA; Fri, 27 Jan 2006 08:54:09 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 3551280BB; Fri, 27 Jan 2006 08:54:08 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2U2q-000FkS-M6; Fri, 27 Jan 2006 13:53:44 +0000 Date: Fri, 27 Jan 2006 13:53:44 +0000 From: Brian Candler To: Oleg Tarasov Message-ID: <20060127135344.GB60498@uk.tiscali.com> References: <1623226562.20060126170150@osk.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1623226562.20060126170150@osk.com.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Named could not listen on UDP socket: permission denied X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 13:53:48 -0000 On Thu, Jan 26, 2006 at 05:01:50PM +0200, Oleg Tarasov wrote: > I run FreeBSD 6.0 and I have begun to recieve quite periodic error messages like these: > > Jan 25 19:45:50 central named[728]: could not listen on UDP socket: permission denied > Jan 25 19:45:50 central named[728]: creating IPv4 interface ng0 failed; interface ignored > > ng0 is my main internet interface and is created on early boot > (rcordered like ppp-user) by mpd. Certainly, I need DNS listening on > this interface. > > The reason is that if mpd is restarted for some reason, interface ng0 > is destroyed and created again while listener on this interface is > destroyed too. Named is chrooted at this time and cannot re-bind > listener on this interface. Only manual restart of named helps it bind > to this interface. > > This is not deadly situation as if I manually restart mpd I will be > able to restart named too... > > Running named under root user or out of chroot environment is not > quite acceptable way... named needs to be root in order to bind to port 53. If ng0 has a fixed IP address, then you could configure an alias on lo0 with that address. Then, even though named cannot rebind to ng0, it will still answer queries to that address. If ng0 has a dynamic address, then I think your only solution is to run named as root within a chroot environment or jail(8) - or to write a script which is run when ng0 comes up, which kills and restarts bind. Does mpd have a hook to call a script on interface up? Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 14:39:19 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 33BB916A420 for ; Fri, 27 Jan 2006 14:39:19 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E50C044111 for ; Fri, 27 Jan 2006 14:39:18 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from [10.2.2.50] (24-158-230-170.dhcp.leds.al.charter.com [24.158.230.170]) by smtp-relay.omnis.com (Postfix) with ESMTP id 140C21880C3E; Fri, 27 Jan 2006 06:39:15 -0800 (PST) Message-ID: <43DA30AD.5040907@dellroad.org> Date: Fri, 27 Jan 2006 08:39:41 -0600 From: Archie Cobbs User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <20060105110404.GA25737@uk.tiscali.com> <20060127130048.GA60219@uk.tiscali.com> In-Reply-To: <20060127130048.GA60219@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: sl2tps, MRU, MTU, and MSS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 14:39:19 -0000 Brian Candler wrote: >> 1. PPP negotiates an MRU of 1400 >> 2. However, ifconfig ng0 shows an MTU of 1376 (where does that come from?) >> 3. When the client opens a TCP connection, it offers an MSS of 1360 > > ...and then fragmentation problems occur, because the remote server sends IP > datagrams which are 1400 bytes with DF bit set, the ng0 interface with MTU > 1376 rejects them, the generated ICMP messages are discarded by an > intervening NAT gateway, and the TCP connection fails. Sounds like the NAT gateway is the root cause of all this, no? While all the MTU logic in slt2ps is probably not optimal, in theory it shouldn't matter if it's not optimal because ICMP should be working. A router is supposed to be able to reduce the MTU if it needs to and things should continue to work. Instead of "fixing" sl2ps to work in your particular situation (and breaking it in other situations), is it possible to fix/replace the broken gateway instead? (Try a FreeBSD box instead :-) Some background as best as I can remember... The reduction of MTU to account for PPP protocol overhead (MPPE) is not controversial. Obviously if the hard MTU is (say) 1400 and you've got 4 bytes of MPPE overhead, then the interface MTU should be <= 1396. You're right that this shouldn't really happen unless MPPE is actually negotiated, but that's harder to do.. MPPE negotiation happens after link negotiation. To avoid this, disable MPPE if you can. The WinXP hack is something that at some time was deemed necessary to work around a bug in Windows XP. As I recall, it would advertise a MRU that was actually bigger than what it would really accept. Since there was no easy way to detect WinXP clients, we had to put in this workaround unconditionally. This may have only been a bug in pre-SP2 WinXP. It was (IIRC) when trying to do L2TP over IPSec, not PPTP. Hope this helps. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 16:26:27 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 3B87916A425 for ; Fri, 27 Jan 2006 16:26:27 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04D04441A8 for ; Fri, 27 Jan 2006 15:56:53 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id F1BB0D3; Fri, 27 Jan 2006 10:57:14 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 8A2898C59; Fri, 27 Jan 2006 10:57:13 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Vxx-000Fpj-Oc; Fri, 27 Jan 2006 15:56:49 +0000 Date: Fri, 27 Jan 2006 15:56:49 +0000 From: Brian Candler To: Archie Cobbs Message-ID: <20060127155649.GA60799@uk.tiscali.com> References: <20060105110404.GA25737@uk.tiscali.com> <20060127130048.GA60219@uk.tiscali.com> <43DA30AD.5040907@dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43DA30AD.5040907@dellroad.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: sl2tps, MRU, MTU, and MSS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 16:26:27 -0000 On Fri, Jan 27, 2006 at 08:39:41AM -0600, Archie Cobbs wrote: > Brian Candler wrote: > >>1. PPP negotiates an MRU of 1400 > >>2. However, ifconfig ng0 shows an MTU of 1376 (where does that come from?) > >>3. When the client opens a TCP connection, it offers an MSS of 1360 > > > >...and then fragmentation problems occur, because the remote server sends > >IP > >datagrams which are 1400 bytes with DF bit set, the ng0 interface with MTU > >1376 rejects them, the generated ICMP messages are discarded by an > >intervening NAT gateway, and the TCP connection fails. > > Sounds like the NAT gateway is the root cause of all this, no? > > While all the MTU logic in slt2ps is probably not optimal, in theory > it shouldn't matter if it's not optimal because ICMP should be working. > A router is supposed to be able to reduce the MTU if it needs to and > things should continue to work. > > Instead of "fixing" sl2ps to work in your particular situation (and > breaking it in other situations), is it possible to fix/replace the > broken gateway instead? (Try a FreeBSD box instead :-) It's a PIX. Perhaps I should draw out the test scenario properly just to make sure all is clear: fxp0 rl0 RFC1918 pub Win ------------ FreeBSD 6.0 -------//---------- firewall ---- Internet XP + ipsec-tools PIX + sl2tps <============> L2TP over IPSEC The FreeBSD box runs pf NAT, in order for the IP address given out from the sl2tps pool to be usable. The rl0 address is from private address space, as it hangs on an office network. The PIX firewall also runs NAT to give external connectivity. When I bring up the tunnel, LCP negotiates an MRU of 1400. The Windows box is happy with this, and therefore chooses a TCP MSS of 1360 for outbound connections. FreeBSD configures its ng0 interface with an MTU of 1376. Even if this is technically allowed, because path MTU discovery should take care of it, it's certainly suboptimal, since we *could* send datagrams with an MTU of 1400 over the negotiated tunnel. Although I understand your argument that the PIX is broken, there are also parts of the Internet which wrongly block ICMP fragmentation-needed messages. Unfortunately, fixing the whole Internet is outside of my power. However I'm happy to rely on the vast majority of the Internet supporting an MTU of 1500, and for the last hop to be lower than this since the originating socket will directly set the initial MSS to an appropriate value. > Some background as best as I can remember... > > The reduction of MTU to account for PPP protocol overhead (MPPE) is > not controversial. Obviously if the hard MTU is (say) 1400 and you've > got 4 bytes of MPPE overhead, then the interface MTU should be <= 1396. > > You're right that this shouldn't really happen unless MPPE is actually > negotiated, but that's harder to do.. MPPE negotiation happens after > link negotiation. To avoid this, disable MPPE if you can. OK. I already changed sl2tps not to allow MPPE. I guess an option in config.xml would be better. > The WinXP hack is something that at some time was deemed necessary to > work around a bug in Windows XP. As I recall, it would advertise a MRU > that was actually bigger than what it would really accept. Since there > was no easy way to detect WinXP clients, we had to put in this workaround > unconditionally. This may have only been a bug in pre-SP2 WinXP. It > was (IIRC) when trying to do L2TP over IPSec, not PPTP. To paraphrase your words: instead of "fixing" sl2tps to work in this particular situation, is it possible to fix/replace the broken WinXP box instead? :-) The WinXP box I'm using is running SP2, and doesn't seem to have the bug you describe. Since SP2 has been out for a long time, perhaps it would now be reasonable to drop this workaround, or to make it a compile-in option. In any case, I think pre-SP2 XP has other problems with IPSEC, so any serious XP user should be upgrading to SP2 anyway. Besides which, any PPP implementation which announces an MRU of X but then refuses to receive packets of size X is so totally broken that it defeats the object of PPP option negotiation in the first place. Cheers, and thanks for your quick response, Brian. From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 16:39:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 97B8E16A420 for ; Fri, 27 Jan 2006 16:39:10 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F35A43D6A for ; Fri, 27 Jan 2006 16:39:10 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from [10.3.2.11] (unknown [208.63.111.51]) by smtp-relay.omnis.com (Postfix) with ESMTP id 21269200690C; Fri, 27 Jan 2006 08:39:09 -0800 (PST) Message-ID: <43DA4CAC.3070906@dellroad.org> Date: Fri, 27 Jan 2006 10:39:08 -0600 From: Archie Cobbs User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <20060105110404.GA25737@uk.tiscali.com> <20060127130048.GA60219@uk.tiscali.com> <43DA30AD.5040907@dellroad.org> <20060127155649.GA60799@uk.tiscali.com> In-Reply-To: <20060127155649.GA60799@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: sl2tps, MRU, MTU, and MSS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 16:39:10 -0000 Brian Candler wrote: >>>> 1. PPP negotiates an MRU of 1400 >>>> 2. However, ifconfig ng0 shows an MTU of 1376 (where does that come from?) >>>> 3. When the client opens a TCP connection, it offers an MSS of 1360 >>> ...and then fragmentation problems occur, because the remote server sends >>> IP >>> datagrams which are 1400 bytes with DF bit set, the ng0 interface with MTU >>> 1376 rejects them, the generated ICMP messages are discarded by an >>> intervening NAT gateway, and the TCP connection fails. >> Sounds like the NAT gateway is the root cause of all this, no? >> >> While all the MTU logic in slt2ps is probably not optimal, in theory >> it shouldn't matter if it's not optimal because ICMP should be working. >> A router is supposed to be able to reduce the MTU if it needs to and >> things should continue to work. >> >> Instead of "fixing" sl2ps to work in your particular situation (and >> breaking it in other situations), is it possible to fix/replace the >> broken gateway instead? (Try a FreeBSD box instead :-) > > It's a PIX. Perhaps I should draw out the test scenario properly just to > make sure all is clear: > > > fxp0 rl0 RFC1918 pub > Win ------------ FreeBSD 6.0 -------//---------- firewall ---- Internet > XP + ipsec-tools PIX > + sl2tps > <============> > L2TP over > IPSEC > > The FreeBSD box runs pf NAT, in order for the IP address given out from the > sl2tps pool to be usable. The rl0 address is from private address space, as > it hangs on an office network. The PIX firewall also runs NAT to give > external connectivity. > > When I bring up the tunnel, LCP negotiates an MRU of 1400. The Windows box > is happy with this, and therefore chooses a TCP MSS of 1360 for outbound > connections. > > FreeBSD configures its ng0 interface with an MTU of 1376. Even if this is > technically allowed, because path MTU discovery should take care of it, it's > certainly suboptimal, since we *could* send datagrams with an MTU of 1400 > over the negotiated tunnel. First of all, let's be clear about terminology.. there are two different MRU's negoatiated in opposite directions and those negoations are done independently. The problem, which is basically "the FreeBSD->WinXP MTU is causing a PIX-bug-triggering MSS in the WinXP->FreeBSD direction" arises because: - WinXP sets its MSS (which applies to data flowing in the FreeBSD->WinXP direction) based on the MTU that it sees (which applies to the WinXP->FreeBSD direction). This is a heuristic "guess" made by the TCP stack, based on the assumption that the link is MTU-symmetrical. - This "guess" is wrong and because of path-MTU problems can't be corrected. In any case, in the FreeBSD -> WinXP direction, you say we could send 1400 byte packets out the ng0 interface, but this is not necessarily true. What is the MRU that the WinXP machine asked for? If it's 1400, then the ng0 interface must definitely be < 1400, because of PPP overhead (e.g., IPCP). The 1400 negiotiated by LCP applies to PPP frame payload, not IP size. Seems like the proper workaround would be to configure sl2tps to negotiate a smaller MRU (WinXP->FreeBSD direction) than 1400. There's no config knob for this but one could be added. Then WinXP would "guess" better. > The WinXP box I'm using is running SP2, and doesn't seem to have the bug you > describe. Since SP2 has been out for a long time, perhaps it would now be > reasonable to drop this workaround, or to make it a compile-in option. In > any case, I think pre-SP2 XP has other problems with IPSEC, so any serious > XP user should be upgrading to SP2 anyway. > > Besides which, any PPP implementation which announces an MRU of X but then > refuses to receive packets of size X is so totally broken that it defeats > the object of PPP option negotiation in the first place. You can remove that hack, but the hack is not the reason for the failure so to speak. It just happens to trigger the problem (which occurs elsewhere). The hack itself should probably be turned into a config knob too. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 16:54:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 9C13716A420 for ; Fri, 27 Jan 2006 16:54:29 +0000 (GMT) (envelope-from gkozyrev@ukr.net) Received: from computer.ukrsat.com (computer.ukrsat.com [212.35.160.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC68943DB7 for ; Fri, 27 Jan 2006 16:54:28 +0000 (GMT) (envelope-from gkozyrev@ukr.net) Received: from gleb.kozyrev.name (juli.slnet.kiev.ua [195.49.149.86]) by computer.ukrsat.com (8.12.8/8.12.8) with SMTP id k0RGckHu026993; Fri, 27 Jan 2006 18:39:01 +0200 Received: from Gleb ([127.0.0.1]) by Gleb (192.168.48.1) with smtp ; Fri, 27 Jan 2006 18:54:46 +0200 Message-ID: <000801c62362$5f0c5a10$0130a8c0@Gleb> From: "Gleb Kozyrev" To: "FreeBSD MailList" , References: <1623226562.20060126170150@osk.com.ua> Date: Fri, 27 Jan 2006 18:54:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" 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 FL-Build: Fidolook 2002 (SL) 6.0.2800.94 - 5/4/2005 11:39:16 Cc: Subject: Re: Named could not listen on UDP socket: permission denied X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 16:54:29 -0000 Oleg Tarasov wrote to on Thu, 26 Jan 2006 17:01:50 +0200: OT> I run FreeBSD 6.0 and I have begun to recieve quite periodic error OT> messages like these: OT> Jan 25 19:45:50 central named[728]: could not listen on UDP socket: permission denied OT> Jan 25 19:45:50 central named[728]: creating IPv4 interface ng0 failed; OT> interface ignored OT> ng0 is my main internet interface and is created on early boot OT> (rcordered like ppp-user) by mpd. Certainly, I need DNS listening on OT> this interface. OT> The reason is that if mpd is restarted for some reason, interface ng0 OT> is destroyed and created again while listener on this interface is OT> destroyed too. Named is chrooted at this time and cannot re-bind OT> listener on this interface. Only manual restart of named helps it bind OT> to this interface. OT> This is not deadly situation as if I manually restart mpd I will be OT> able to restart named too... OT> Running named under root user or out of chroot environment is not OT> quite acceptable way... OT> Please tell me if this problem has a solution other then above Maybe this can help you: -- With best regards, Gleb Kozyrev. From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 17:47:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 70D2116A494 for ; Fri, 27 Jan 2006 17:47:24 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 831FA43FA7 for ; Fri, 27 Jan 2006 17:15:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 0D29C1FFDEC; Fri, 27 Jan 2006 18:15:08 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 4651E1FFDE6; Fri, 27 Jan 2006 18:15:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id B81EC44487E; Fri, 27 Jan 2006 17:14:53 +0000 (UTC) Date: Fri, 27 Jan 2006 17:14:53 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Brian Candler In-Reply-To: <20060127155649.GA60799@uk.tiscali.com> Message-ID: <20060127171017.D24703@maildrop.int.zabbadoz.net> References: <20060105110404.GA25737@uk.tiscali.com> <20060127130048.GA60219@uk.tiscali.com> <43DA30AD.5040907@dellroad.org> <20060127155649.GA60799@uk.tiscali.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-net@freebsd.org Subject: Re: sl2tps, MRU, MTU, and MSS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 17:47:28 -0000 On Fri, 27 Jan 2006, Brian Candler wrote: > It's a PIX. Perhaps I should draw out the test scenario properly just to make sure to explicitly allow icmp messages needed. I think it was "PixOS" 4->5 when they changed defaults. See for exmaple [1] or several other dozens of similar docs also on cisco.com. May it help your problem or not ;) [1] http://www.elemental.net/~lf/templates/pix-config-template -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 18:20:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 3C7CF16A424 for ; Fri, 27 Jan 2006 18:20:06 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id C444343D6D for ; Fri, 27 Jan 2006 18:19:59 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 27 Jan 2006 10:19:59 -0800 Message-ID: <43DA644E.9090703@elischer.org> Date: Fri, 27 Jan 2006 10:19:58 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD MailList References: <83462512.20060126181018@osk.com.ua> <43D92848.2050005@elischer.org> <20060127084457.GA21360@zen.inc> <603364524.20060127113646@osk.com.ua> In-Reply-To: <603364524.20060127113646@osk.com.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: Duplicate SAD entries lead to ESP tunnel malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 18:20:06 -0000 Oleg Tarasov wrote: >Hello, > >VANHULLEBUS Yvan wrote: > > > >>net.key.prefered_oldsa, or net.key.preferred_oldsa (changed since >>4.X). >> >> > > > >>It is 1 by default, and it should be set to 0 to help better >>interoperability with lots of peers..... >> >> > >This seems quite like correct solution. I analyzed behavior of the >interface and saw upcoming ping requests (obviously) AND outgoing ping >echoes, but remote host didn't get them. Obviously incoming packets >were decrypted using one of SAs (the new one) but outgoing packets >were encrypted using old SA which is not present on remote host due to >some problems (like forced reboot, connection problems etc). > > yes let us know if that solves your problem.. remember you don't need to reboot to set it.. the result should be instantaneous. >Normally in this case remote host must report of unknown spi, but >rather it lacks this function or it just ignores these packets. As it >is a hardware router I am unaware of its behavior. > >I will test this solution for some time but I am sure this will help. > >Thanx for really great help - all these troubles are on my production >box and every minute of malfunction returns to me with #not good# >words of my boss :/ > > > From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 18:43:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 3C1E016A420 for ; Fri, 27 Jan 2006 18:43:03 +0000 (GMT) (envelope-from tiagocruz@b4br.net) Received: from vader.b4br.net (vader.b4br.net [200.152.202.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BA7643D75 for ; Fri, 27 Jan 2006 18:42:56 +0000 (GMT) (envelope-from tiagocruz@b4br.net) Received: from localhost (localhost.b4br.net [127.0.0.1]) by vader.b4br.net (Postfix) with ESMTP id 5D824181433 for ; Fri, 27 Jan 2006 16:37:32 -0200 (BRST) Received: from vader.b4br.net ([127.0.0.1]) by localhost (vader.b4br.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11435-04 for ; Fri, 27 Jan 2006 16:37:20 -0200 (BRST) Received: from tuxkiller.matter.b4br.net (yoda.b4br.net [200.152.202.10]) by vader.b4br.net (Postfix) with ESMTP id 82728181429 for ; Fri, 27 Jan 2006 16:37:20 -0200 (BRST) From: Tiago Cruz To: freebsd-net@freebsd.org Date: Fri, 27 Jan 2006 16:42:42 -0200 Message-Id: <1138387362.4742.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-Virus-Scanned: amavisd-new at b4br.net Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Network client is the same from server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 18:43:03 -0000 Hi guys, Have some way, like some "ninjitsu" :) to make the connection that one client that have the same network that us? Exemple: My corporate network: 192.168.0.0/22 My house network: 192.168.0.0.24 Result: VPN don't work, because we have a address conflict. Thanks so much! -- Tiago Cruz http://linuxrapido.org Linux User #282636 "The box said: Requires MS Windows or better, so I installed Linux" From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 18:54:36 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 C4CF216A420 for ; Fri, 27 Jan 2006 18:54:36 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4340243D55 for ; Fri, 27 Jan 2006 18:54:35 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 27 Jan 2006 10:54:35 -0800 Message-ID: <43DA6C6A.7050701@elischer.org> Date: Fri, 27 Jan 2006 10:54:34 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tiago Cruz References: <1138387362.4742.9.camel@localhost.localdomain> In-Reply-To: <1138387362.4742.9.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Network client is the same from server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 18:54:36 -0000 Tiago Cruz wrote: >Hi guys, > >Have some way, like some "ninjitsu" :) to make the connection that one >client that have the same network that us? Exemple: > >My corporate network: 192.168.0.0/22 >My house network: 192.168.0.0.24 > >Result: VPN don't work, because we have a address conflict. > >Thanks so much! > > you can use NATD to fix this but you will need to have "mapped" name for all teh machines on the other nets.. e,g on net 1 you will see the other net as being 192.168.128.x and on the other net you will see the first net as 192.168.128.x (or whatever you want) I have done it once but you will need to read the natd and libalias docs as it has been a long time since I did it. I also had a DNS spoofer that translated DNS requests between the two nets as needed. but That is long gone. (I have another one now but it is proprietary). From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 19:27:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 426BF16A420 for ; Fri, 27 Jan 2006 19:27:35 +0000 (GMT) (envelope-from tiagocruz@b4br.net) Received: from vader.b4br.net (vader.b4br.net [200.152.202.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id A330043D49 for ; Fri, 27 Jan 2006 19:27:34 +0000 (GMT) (envelope-from tiagocruz@b4br.net) Received: from localhost (localhost.b4br.net [127.0.0.1]) by vader.b4br.net (Postfix) with ESMTP id A71C2181439; Fri, 27 Jan 2006 17:22:10 -0200 (BRST) Received: from vader.b4br.net ([127.0.0.1]) by localhost (vader.b4br.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13685-05; Fri, 27 Jan 2006 17:21:59 -0200 (BRST) Received: from tuxkiller.matter.b4br.net (yoda.b4br.net [200.152.202.10]) by vader.b4br.net (Postfix) with ESMTP id 33F0C18142D; Fri, 27 Jan 2006 17:21:59 -0200 (BRST) From: Tiago Cruz To: Julian Elischer In-Reply-To: <43DA6C6A.7050701@elischer.org> References: <1138387362.4742.9.camel@localhost.localdomain> <43DA6C6A.7050701@elischer.org> Content-Type: text/plain Date: Fri, 27 Jan 2006 17:27:21 -0200 Message-Id: <1138390041.4742.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at b4br.net Cc: freebsd-net@freebsd.org Subject: Re: Network client is the same from server X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 19:27:35 -0000 On Fri, 2006-01-27 at 10:54 -0800, Julian Elischer wrote: > you can use NATD to fix this but you will need to have "mapped" name for > all teh machines on the other nets.. Wol, so is it possible?!?! I'm using FreeBSD 6.0 and OpenVPN 2.0.5-1. I'm not using ipfw, only PF. Is possible to do with pf? Thank you! Tiago Cruz From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 00:45:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 699B216A420 for ; Sat, 28 Jan 2006 00:45:10 +0000 (GMT) (envelope-from meno.abels@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id A277B43D48 for ; Sat, 28 Jan 2006 00:45:08 +0000 (GMT) (envelope-from meno.abels@gmail.com) Received: by xproxy.gmail.com with SMTP id t12so446931wxc for ; Fri, 27 Jan 2006 16:45:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Yi48FRZAqKrxvKaRl+ojHI8j7vXAU8LqCKJZ9ag5t/K3u0TKeCN8aYRA0xYRrkw1rvo2xwDnwqJUWFh2IA1miwT1+ZyrrFkJ2dSez6++kNbQEac2iOvWpgzDN3RPs/zNxVUNKquBw+z3SLG5WMb8h1qV1cJ9xqYmfwIE9YzIP7o= Received: by 10.11.98.44 with SMTP id v44mr50666cwb; Fri, 27 Jan 2006 16:45:07 -0800 (PST) Received: by 10.11.120.19 with HTTP; Fri, 27 Jan 2006 16:45:07 -0800 (PST) Message-ID: <344de2870601271645j5f9029a3l@mail.gmail.com> Date: Sat, 28 Jan 2006 01:45:07 +0100 From: Meno Abels To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: panic in sbdrop_locked X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 00:45:10 -0000 Hello, i have two boxes running currently freebsd-6.0-p3 i386 and they are panic around every 24 hour once a time. I just update to -p4 so i will see if it working better. I also didn't have the debug kernel ready so i can only provide this very weak infos: (kgdb) bt #0 0xc06e5b2c in doadump () #1 0xc06e60c0 in boot () #2 0xc06e6409 in panic () #3 0xc0731406 in sbdrop_locked () #4 0xc07b373e in tcp_input () #5 0xc07a93fe in ip_input () #6 0xc077a2b9 in netisr_processqueue () #7 0xc077a51f in swi_net () #8 0xc06cbfe8 in ithread_loop () #9 0xc06caebf in fork_exit () #10 0xc090fe1c in fork_trampoline () Is there any procedure to track this problem down other than have a debug kernel prepared what i done now-:) And have a very close look to the backtrace. I saw it happens sometimes in the development branches. BTW The network config is quite komplex on that both crashing boxes but very simliar. I also have around 100 other boxes running on the same hardware with the same os without problem but the network config is not that complex. re0: flags=3D8943 mtu 1500 options=3D8 inet 172.20.20.20 netmask 0xffffff00 broadcast 172.20.20.255 inet6 fe80::240:f4ff:fecb:9463%re0 prefixlen 64 scopeid 0x1 inet 172.20.20.97 netmask 0xffffffff broadcast 172.20.20.97 inet 172.20.20.89 netmask 0xffffffff broadcast 172.20.20.89 inet 172.20.20.60 netmask 0xffffffff broadcast 172.20.20.60 inet6 2001:XXX:XXX::3 prefixlen 64 ether 00:40:f4:cb:94:63 media: Ethernet autoselect (1000baseTX ) status: active re1: flags=3D8843 mtu 1500 options=3D8 inet 172.20.21.2 netmask 0xffffff00 broadcast 172.20.21.255 inet6 fe80::240:f4ff:febb:2124%re1 prefixlen 64 scopeid 0x2 ether 00:40:f4:bb:21:24 media: Ethernet autoselect (10baseT/UTP) status: active rl0: flags=3D8943 mtu 1500 options=3D8 inet YY.YY.YY.215 netmask 0xffffff00 broadcast YY.YY.YY.255 inet6 fe80::213:8fff:fe1f:6586%rl0 prefixlen 64 scopeid 0x3 ether 00:13:8f:1f:65:86 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=3D108851 mtu 1500 pfsync0: flags=3D41 mtu 1348 pfsync: syncdev: re1 maxupd: 128 pflog0: flags=3D41 mtu 33208 lo0: flags=3D8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 carp240: flags=3D41 mtu 1500 inet 172.20.20.240 netmask 0xffffff00 carp: MASTER vhid 11 advbase 1 advskew 110 carp241: flags=3D41 mtu 1500 inet 172.20.20.241 netmask 0xffffff00 carp: BACKUP vhid 12 advbase 1 advskew 140 carp255: flags=3D41 mtu 1500 inet 172.20.20.1 netmask 0xffffff00 carp: MASTER vhid 255 advbase 1 advskew 110 carp254: flags=3D1 mtu 1500 carp: INIT vhid 254 advbase 1 advskew 110 carp219: flags=3D41 mtu 1500 inet YY.YY.YY.219 netmask 0xffffff00 carp: MASTER vhid 16 advbase 1 advskew 100 carp220: flags=3D41 mtu 1500 inet YY.YY.YY.220 netmask 0xffffff00 carp: BACKUP vhid 17 advbase 1 advskew 130 carp20: flags=3D41 mtu 1500 inet YY.YY.YY.182 netmask 0xffffff00 carp: BACKUP vhid 21 advbase 1 advskew 130 carp21: flags=3D41 mtu 1500 inet YY.YY.YY.183 netmask 0xffffff00 carp: BACKUP vhid 22 advbase 1 advskew 130 carp196: flags=3D41 mtu 1500 inet YY.YY.YY.196 netmask 0xffffff00 carp: BACKUP vhid 196 advbase 1 advskew 130 carp197: flags=3D41 mtu 1500 inet YY.YY.YY.197 netmask 0xffffff00 carp: MASTER vhid 197 advbase 1 advskew 110 carp58: flags=3D41 mtu 1500 inet 172.20.20.58 netmask 0xffffff00 carp: BACKUP vhid 58 advbase 1 advskew 200 carp59: flags=3D41 mtu 1500 inet 172.20.20.59 netmask 0xffffff00 carp: BACKUP vhid 59 advbase 1 advskew 140 vlan0: flags=3D8943 mtu 150= 0 inet 172.20.22.2 netmask 0xffffff00 broadcast 172.20.22.255 inet6 fe80::240:f4ff:fecb:9463%vlan0 prefixlen 64 scopeid 0x14 ether 00:40:f4:cb:94:63 media: Ethernet autoselect (1000baseTX ) status: active vlan: 22 parent interface: re0 bridge0: flags=3D8041 mtu 1500 inet6 2001:XXX:XXX:2::3 prefixlen 64 ether ac:de:48:6c:e5:2d priority 32768 hellotime 2 fwddelay 15 maxage 20 member: vlan0 flags=3D3 gif0: flags=3D8051 mtu 1280 tunnel inet XX.YY.ZZ.219 --> 212.224.0.188 inet6 fe80::240:f4ff:fecb:9463%gif0 prefixlen 64 scopeid 0x16 inet6 2001:XXX:XXX:2bf::2 --> 2001:XXX:XXX:2bf::1 prefixlen 128 Cheers meno From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 10:45:00 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 C790016A420 for ; Sat, 28 Jan 2006 10:45:00 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43FFD43D46 for ; Sat, 28 Jan 2006 10:45:00 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 3E804BB; Sat, 28 Jan 2006 05:45:21 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id BB55988C5; Sat, 28 Jan 2006 05:45:19 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2nZf-000GdS-Ja; Sat, 28 Jan 2006 10:44:55 +0000 Date: Sat, 28 Jan 2006 10:44:55 +0000 From: Brian Candler To: Archie Cobbs Message-ID: <20060128104455.GA63806@uk.tiscali.com> References: <20060105110404.GA25737@uk.tiscali.com> <20060127130048.GA60219@uk.tiscali.com> <43DA30AD.5040907@dellroad.org> <20060127155649.GA60799@uk.tiscali.com> <43DA4CAC.3070906@dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43DA4CAC.3070906@dellroad.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: sl2tps, MRU, MTU, and MSS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 10:45:00 -0000 On Fri, Jan 27, 2006 at 10:39:08AM -0600, Archie Cobbs wrote: > First of all, let's be clear about terminology.. there are two different > MRU's negoatiated in opposite directions and those negoations are done > independently. The problem, which is basically "the FreeBSD->WinXP MTU > is causing a PIX-bug-triggering MSS in the WinXP->FreeBSD direction" > arises because: > > - WinXP sets its MSS (which applies to data flowing in the FreeBSD->WinXP > direction) based on the MTU that it sees (which applies to the > WinXP->FreeBSD direction). This is a heuristic "guess" made by the > TCP stack, based on the assumption that the link is MTU-symmetrical. > - This "guess" is wrong and because of path-MTU problems can't be > corrected. I have to admit that it's a long time since I used dial-up PPP, so I'm very rusty on all of this :-) I thought the L2TP link was symmetric in my test (i.e. both sides accepted 1400) but I don't have the logs to hand, so I'll have to check that when I'm next in the office. As an observation: when you ifconfig ng0, you can't set separate "transmit MTU" and "receive MTU". So I imagine that the configured MTU only applies to outbound datagrams, i.e. it means "don't transmit any datagram larger than this on this interface". If ng0 were to *receive* a datagram larger than the MTU I don't know for sure what would happen, but given that it was successfully received, I see no reason why the kernel should discard it. So the ng0 MTU should just match the requested MRU from the WinXP side, and all will be well in that direction. Equally, the WinXP interface MTU should match the MRU requested by FreeBSD. > In any case, in the FreeBSD -> WinXP direction, you say we could send 1400 > byte packets out the ng0 interface, but this is not necessarily true. What > is the MRU that the WinXP machine asked for? If it's 1400, then the ng0 > interface must definitely be < 1400, because of PPP overhead (e.g., IPCP). > The 1400 negiotiated by LCP applies to PPP frame payload, not IP size. I think you're mistaken; see here in RFC 1661 | 2. PPP Encapsulation | ... | +----------+-------------+---------+ | | Protocol | Information | Padding | | | 8/16 bits| * | * | | +----------+-------------+---------+ | ... | The maximum length for the Information field, including Padding, | but not including the Protocol field, is termed the Maximum | Receive Unit (MRU), which defaults to 1500 octets. By | negotiation, consenting PPP implementations may use other values | for the MRU. And explicitly in RFC 1332 (IPCP): | The maximum length of an IP packet transmitted over a PPP link is the | same as the maximum length of the Information field of a PPP data | link layer frame. So, a PPP MRU of 1400 lets you send an IP datagram of size 1400. Of course, IPCP is just a control protocol for negotiating IP options. There is no "IPCP overhead" when encapsulating an IP datagram, since the IPCP exchange has already finished. In any case, I didn't see anything in libpdel which tried to make allowance for a smaller IP MTU than the PPP MRU, except the WINXP_HACK > Seems like the proper workaround would be to configure sl2tps to negotiate > a smaller MRU (WinXP->FreeBSD direction) than 1400. There's no config > knob for this but one could be added. Then WinXP would "guess" better. Bear with me while I try to understand this. We have two independent channels, as you say. 1. For the flow of packets from FreeBSD to WinXP: WinXP <------------ FreeBSD <----------- rest of world 1a. WinXP asks for MRU of 1400 1b. FreeBSD accepts this 1c. FreeBSD configures the MTU in this direction as 1376, for its own reasons 2. For the flow of packets from WinXP to FreeBSD: WinXP ------------> FreeBSD -----------> rest of world 2a. FreeBSD asks for MRU of 1400 2b. WinXP accepts this 2c. I presume WinXP configures the MTU in this direction as 1400, although I don't know how to confirm this (i.e. ipconfig doesn't show the MTU) Now: when opening a TCP connection to the outside world, Windows proposes an MSS of (2c)-40, since there are 40 bytes of IP+TCP headers. So yes you're right, if FreeBSD is going to choose an MTU of 1376 in step 1c, then it could propose an MRU of 1376 in step 2a, so that Windows would choose an MSS of 1376-40. However I don't see how it could do this (easily), since it would have to wait until it has finished negotiating the MRU from WinXP (step 1a/1b) before it could even offer an MRU in the opposite direction (step 2a). This does seem to be a lot of hoops to jump through, when you could simply fix step 1c: if the WinXP machine says it can receive 1400-byte datagrams, then configure the interface to send it datagrams of up to 1400 bytes! > >Besides which, any PPP implementation which announces an MRU of X but then > >refuses to receive packets of size X is so totally broken that it defeats > >the object of PPP option negotiation in the first place. > > You can remove that hack, but the hack is not the reason for the failure > so to speak. It just happens to trigger the problem (which occurs > elsewhere). Hmm, maybe. If you follow the letter of the RFCs, then if an implementation says it will accept an MRU of X, then you are no under obligation to send it datagrams of size X. But it's rather pointless to get your IP stack to fragment (or reject) datagrams of size smaller than X. In this case, WinXP said it could accept datagrams of up to 1400, but FreeBSD has decided that any incoming datagram between 1377 and 1400 bytes needs to be fragmented or returned to sender, and this is pointless. As you say, it does trigger the path MTU problem elsewhere in the network, but even if path MTU were working correctly, it would result in a sub-optimal choice of MSS. (Aside: RFC 1661 section 6.1 says that if an implementation asks for an MRU of less than 1500, it MUST still be able to receive packets of size 1500. So we could legitimately ifconfig ng0 to 1500 for all MRU smaller than 1500!) > The hack itself should probably be turned into a config knob too. Well I think we agree there :-) Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 12:02:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A222616A420 for ; Sat, 28 Jan 2006 12:02:38 +0000 (GMT) (envelope-from steven@unix-solutions.be) Received: from DOZER.unix-solutions.be (dozer.unix-solutions.be [85.158.213.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FE0343D49 for ; Sat, 28 Jan 2006 12:02:11 +0000 (GMT) (envelope-from steven@unix-solutions.be) Received: from cloe ([81.165.218.56]) by unix-solutions.be with MailEnable ESMTP; Sat, 28 Jan 2006 13:01:54 +0100 Message-ID: <001501c62402$a1bd4c70$05000100@cloe> From: "Unix-Solutions - Steven" To: Date: Sat, 28 Jan 2006 13:01:53 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: multiple natd + ipfw, with 2 internal ip's X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 12:02:38 -0000 Hi you guy's, I have a little problem with my natd or ipfw configuration. Current situation: ISP1 =3D Telenet (Belgium) Speed: 20 mbit/s down & 1 mbit/s upload We get ip via dhcp ISP2 =3D Versatel (Belgium) Speed: 1 mbit/s down & 1 mbit/s upload We have a range with static ip's Versatel is our backup ISP because this line is very slow Currently we are running on telenet but we want to switch to versatel = when telenet is down. Config that works: TELENET --> ROUTER VERSATEL --> ROUTER ROUTER --> INTERNAL NETWORK RC.conf: # 84.195.224.254 --> gateway of telenet defaultrouter=3D"84.195.224.254"=20 hostname=3D"router.intranet.local" ifconfig_fxp0=3D"inet 192.168.2.254 netmask 255.255.255.0" # VERSATEL ifconfig_xl0=3D"inet 62.166.141.36 netmask 255.255.255.248" # TELENET=20 ifconfig_xl1=3D"DHCP" gateway_enable=3D"YES" firewall_enable=3D"YES" firewall_type=3D"OPEN" firewall_logging=3D"YES" firewall_script=3D"/etc/ipfw.rules" natd_enable=3D"YES" natd_interface=3D"xl1" natd_flags=3D"-f /etc/natd.conf" IPFW.rules: ipfw -f flush ipfw add 00001 divert natd ip from any to any via xl1 ipfw add 00002 divert natd ip from any to 62.166.141.32/29 via xl0 ipfw add 00004 allow ip from any to any via lo0 ipfw add 00005 deny ip from any to 127.0.0.0/8 ipfw add 00006 deny ip from 127.0.0.0/8 to any ipfw add 00007 allow ip from any to any Now I want to add 192.168.2.253 as alias on the FXP0 and when a PC on my internal network sets his gateway to 192.168.2.253 I want that this PC takes the versatel route. How is this possible ? I'm currently followed this manual =3D> = http://www.opennet.ru/base/net/freebsd_2x_natd.txt.html I translated it with babelfish =3D> = http://pub.beenske.be/docs/dual-natd+ipfw.txt Config files: RC.conf: # 84.195.224.254 --> gateway of telenet defaultrouter=3D"84.195.224.254"=20 hostname=3D"router.intranet.local" ifconfig_fxp0=3D"inet 192.168.2.254 netmask 255.255.255.0" ifconfig_fxp0_alias0=3D"inet 192.168.2.253 netmask 255.255.255.255" # VERSATEL ifconfig_xl0=3D"inet 62.166.141.36 netmask 255.255.255.248" # TELENET=20 ifconfig_xl1=3D"DHCP" gateway_enable=3D"YES" firewall_enable=3D"YES" firewall_type=3D"OPEN" firewall_logging=3D"YES" firewall_script=3D"/etc/ipfw.rules" natd_enable=3D"YES" natd_interface=3D"xl1" natd_flags=3D"-f /etc/natd.conf" natd2_enable=3D"YES" natd2_interface=3D"62.166.141.36" natd_flags=3D"-f /etc/natd2.conf" ipfw.rules: ipfw -f flush ipfw add 00001 divert natd ip from any to any via xl1 ipfw add 00002 divert natd ip from any to 62.166.141.32/29 via xl0 ipfw add 00003 divert 8669 ip from 192.168.2.253 to any via xl0 ipfw add 00004 allow ip from any to any via lo0 ipfw add 00005 deny ip from any to 127.0.0.0/8 ipfw add 00006 deny ip from 127.0.0.0/8 to any ipfw add 00007 allow ip from any to any natd.conf & natd2.conf: redirect_port tcp 192.168.2.30:3389 3389 (a windows pc that i want to = access over RDP) Can you please help me ? Greetz, Steven Bens CEO Unix-Solutions.be From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 13:12:28 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 0235A16A420 for ; Sat, 28 Jan 2006 13:12:28 +0000 (GMT) (envelope-from korio@korio.org) Received: from server.ma3x.net (server.ma3x.net [195.214.255.249]) by mx1.FreeBSD.org (Postfix) with SMTP id 195E343D45 for ; Sat, 28 Jan 2006 13:12:26 +0000 (GMT) (envelope-from korio@korio.org) Received: (qmail 1799 invoked by uid 1049); 28 Jan 2006 13:12:24 -0000 Received: from korio@korio.org by server by uid 0 with qmail-scanner-1.20 (AV Scan @ Club Ma3x Clear:RC:1(195.214.255.196):. Processed in 0.521065 secs); 28 Jan 2006 13:12:24 -0000 X-Qmail-Scanner-Mail-From: korio@korio.org via server X-Qmail-Scanner: 1.20 (Clear:RC:1(195.214.255.196):. Processed in 0.521065 secs) Received: from unknown (HELO ibiza.ma3x.net) (195.214.255.196) by 0 with SMTP; 28 Jan 2006 13:12:23 -0000 Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Iassen Anadoliev To: freebsd-net@freebsd.org Date: Sat, 28 Jan 2006 15:12:45 +0200 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-ibiza.ma3x.net-49834-1138453965-0001"; micalg=pgp-sha1; protocol="application/pgp-signature" Subject: Ftpd problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 13:12:28 -0000 This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. --=_mimegpg-ibiza.ma3x.net-49834-1138453965-0001 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello guys i hope this is the appropriate list so... I am running a ftp server and have some problems with large files. While syncing files over 4GB with rsync there is no problem: ls -lha -rw------- 1 support support 4.2G Nov 14 19:46 somefile.data But when i try to download the file it fails: ftp> get somefile.data local: somefile.data remote: somefile.data 229 Entering Extended Passive Mode (|||56293|) 150 Opening BINARY mode data connection for 'somefile.data' (4475322368 bytes). 4% |* | 172 MB 6.41 MB/s 10:38 ETA 226 Transfer finished due to premature end of file. 180355072 bytes received in 00:26 (6.41 MB/s) Both client and server are running FreeBSD 6.0-STABLE cvsuped 5 days ago. Googling doesn't help me and I am just wondering is there some hard limit like 4GB. While reading man ftpd(8) i couldn't find anything about such limit but the strange thing is that totalsize-downloadedsize = ~4GB. The second one is that size and get commands shows the filesize right.So any help will be appreciated... 10x in advance --=_mimegpg-ibiza.ma3x.net-49834-1138453965-0001 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBD223NVVkEomfaJm0RAhImAKC8YCdfaMsszR6FXiFU5DUjbVgjmgCfYZOD ooW6SulHWRSMHBHUweyQrt8= =BfLl -----END PGP SIGNATURE----- --=_mimegpg-ibiza.ma3x.net-49834-1138453965-0001-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 15:34:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 E4E4A16A422 for ; Sat, 28 Jan 2006 15:34:02 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FE1243D5A for ; Sat, 28 Jan 2006 15:34:00 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id A8ED35DAB; Sat, 28 Jan 2006 10:33:59 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95273-09; Sat, 28 Jan 2006 10:33:59 -0500 (EST) Received: from [192.168.1.3] (pool-68-160-211-174.ny325.east.verizon.net [68.160.211.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id C0ED55CA3; Sat, 28 Jan 2006 10:33:58 -0500 (EST) Message-ID: <43DB8EEA.6090006@mac.com> Date: Sat, 28 Jan 2006 10:34:02 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Iassen Anadoliev References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-net@freebsd.org Subject: Re: Ftpd problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 15:34:03 -0000 Iassen Anadoliev wrote: > Hello guys i hope this is the appropriate list so... > > I am running a ftp server and have some problems with large files. While > syncing files over 4GB with rsync there is no problem: > > ls -lha > -rw------- 1 support support 4.2G Nov 14 19:46 somefile.data > > But when i try to download the file it fails: It's entirely possible that either ftpd or your ftp client has a 4GB filesize limitation, yes. rsync is a good alternative for such large files, as you've already discovered. If you can identify more specificly which side is having the problem, it's probably worth filing a PR about it. Try using fetch or curl instead, to see whether another client does OK, or try using proftpd to test another FTP server. You might also find that publishing the files via HTTP/1.1 so that byte-surfing works better than using FTP. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 16:07:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 96B5816A420 for ; Sat, 28 Jan 2006 16:07:02 +0000 (GMT) (envelope-from korio@korio.org) Received: from server.ma3x.net (server.ma3x.net [195.214.255.249]) by mx1.FreeBSD.org (Postfix) with SMTP id 7874643D6B for ; Sat, 28 Jan 2006 16:07:01 +0000 (GMT) (envelope-from korio@korio.org) Received: (qmail 14391 invoked by uid 1049); 28 Jan 2006 16:06:59 -0000 Received: from korio@korio.org by server by uid 0 with qmail-scanner-1.20 (AV Scan @ Club Ma3x Clear:RC:1(195.214.255.196):. Processed in 0.577908 secs); 28 Jan 2006 16:06:59 -0000 X-Qmail-Scanner-Mail-From: korio@korio.org via server X-Qmail-Scanner: 1.20 (Clear:RC:1(195.214.255.196):. Processed in 0.577908 secs) Received: from unknown (HELO ibiza.ma3x.net) (195.214.255.196) by 0 with SMTP; 28 Jan 2006 16:06:57 -0000 References: <43DB8EEA.6090006@mac.com> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Iassen Anadoliev To: Chuck Swiger Date: Sat, 28 Jan 2006 18:07:19 +0200 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-ibiza.ma3x.net-50054-1138464439-0001"; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: freebsd-net@freebsd.org Subject: Re: Ftpd problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 16:07:02 -0000 This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. --=_mimegpg-ibiza.ma3x.net-50054-1138464439-0001 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Thanks for the fast response... Chuck Swiger writes: > Iassen Anadoliev wrote: >> Hello guys i hope this is the appropriate list so... >> >> I am running a ftp server and have some problems with large files. While >> syncing files over 4GB with rsync there is no problem: >> >> ls -lha >> -rw------- 1 support support 4.2G Nov 14 19:46 somefile.data >> >> But when i try to download the file it fails: > > It's entirely possible that either ftpd or your ftp client has a 4GB filesize > limitation, yes. rsync is a good alternative for such large files, as you've > already discovered. It seems to be a ftpd side problem... > > If you can identify more specificly which side is having the problem, it's > probably worth filing a PR about it. Try using fetch or curl instead, to see > whether another client does OK, or try using proftpd to test another FTP server. First i tried vsftpd. We have vsftpd running on linux servers and there is no such problems with them. On FreeBSD i got: 426 Failure writing network stream. and the same result. It works perfectly with ProFTPD without problems but i don't wanna use ftpd from ports when i have one in the base... > > You might also find that publishing the files via HTTP/1.1 so that byte-surfing > works better than using FTP. Yeah i know that but here it is impossible because we are using custom windows ftp client for download on our user pcs. > > -- > -Chuck WWell Iassen Anadoliev --=_mimegpg-ibiza.ma3x.net-50054-1138464439-0001 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBD25a3VVkEomfaJm0RAo7MAJ4wysiU+HpZKwpXN7iqO5o6z/cIvQCgyK9V JMV5PNmX7n5IQXJp9OFzkOk= =wJju -----END PGP SIGNATURE----- --=_mimegpg-ibiza.ma3x.net-50054-1138464439-0001-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 16:25:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 24AA116A420 for ; Sat, 28 Jan 2006 16:25:16 +0000 (GMT) (envelope-from korio@korio.org) Received: from server.ma3x.net (ns.ma3x.net [195.214.255.249]) by mx1.FreeBSD.org (Postfix) with SMTP id 37AB843D49 for ; Sat, 28 Jan 2006 16:25:14 +0000 (GMT) (envelope-from korio@korio.org) Received: (qmail 10030 invoked by uid 1049); 28 Jan 2006 16:25:13 -0000 Received: from korio@korio.org by server by uid 0 with qmail-scanner-1.20 (AV Scan @ Club Ma3x Clear:RC:1(195.214.255.196):. Processed in 0.639543 secs); 28 Jan 2006 16:25:13 -0000 X-Qmail-Scanner-Mail-From: korio@korio.org via server X-Qmail-Scanner: 1.20 (Clear:RC:1(195.214.255.196):. Processed in 0.639543 secs) Received: from unknown (HELO ibiza.ma3x.net) (195.214.255.196) by 0 with SMTP; 28 Jan 2006 16:25:12 -0000 References: <43DB8EEA.6090006@mac.com> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Iassen Anadoliev To: Chuck Swiger Date: Sat, 28 Jan 2006 18:25:34 +0200 Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=_mimegpg-ibiza.ma3x.net-50054-1138465534-0002"; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: freebsd-net@freebsd.org Subject: Re: Ftpd problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 16:25:16 -0000 This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. --=_mimegpg-ibiza.ma3x.net-50054-1138465534-0002 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Chuck Swiger writes: > Iassen Anadoliev wrote: >> Hello guys i hope this is the appropriate list so... >> >> I am running a ftp server and have some problems with large files. While >> syncing files over 4GB with rsync there is no problem: >> >> ls -lha >> -rw------- 1 support support 4.2G Nov 14 19:46 somefile.data >> >> But when i try to download the file it fails: > > If you can identify more specificly which side is having the problem, it's > probably worth filing a PR about it. Try using fetch or curl instead, to see > whether another client does OK, or try using proftpd to test another FTP server. Never sent PR before. So trying to find PR that already describe my problem I found this: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/89100 > -- > -Chuck WWell Iassen Anadoliev --=_mimegpg-ibiza.ma3x.net-50054-1138465534-0002 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBD25r+VVkEomfaJm0RAsB8AJ0SLUxeP5oN9zzPwI9fn9z41/yzVQCfWXMi PkZtnxEm5QgDAtnqeE9pw54= =BnLB -----END PGP SIGNATURE----- --=_mimegpg-ibiza.ma3x.net-50054-1138465534-0002-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 17:53:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 3F58716A420 for ; Sat, 28 Jan 2006 17:53:02 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACE4043D45 for ; Sat, 28 Jan 2006 17:53:01 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from [10.2.2.50] (24-158-230-170.dhcp.leds.al.charter.com [24.158.230.170]) by smtp-relay.omnis.com (Postfix) with ESMTP id 9E63B1407765; Sat, 28 Jan 2006 09:53:00 -0800 (PST) Message-ID: <43DBAF98.5010101@dellroad.org> Date: Sat, 28 Jan 2006 11:53:28 -0600 From: Archie Cobbs User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <20060105110404.GA25737@uk.tiscali.com> <20060127130048.GA60219@uk.tiscali.com> <43DA30AD.5040907@dellroad.org> <20060127155649.GA60799@uk.tiscali.com> <43DA4CAC.3070906@dellroad.org> <20060128104455.GA63806@uk.tiscali.com> In-Reply-To: <20060128104455.GA63806@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: sl2tps, MRU, MTU, and MSS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 17:53:02 -0000 Brian Candler wrote: > As an observation: when you ifconfig ng0, you can't set separate "transmit > MTU" and "receive MTU". So I imagine that the configured MTU only applies to > outbound datagrams, i.e. it means "don't transmit any datagram larger than > this on this interface". If ng0 were to *receive* a datagram larger than the > MTU I don't know for sure what would happen, but given that it was > successfully received, I see no reason why the kernel should discard it. Right.. the kernel will happily receive any size packet that shows up. >> In any case, in the FreeBSD -> WinXP direction, you say we could send 1400 >> byte packets out the ng0 interface, but this is not necessarily true. What >> is the MRU that the WinXP machine asked for? If it's 1400, then the ng0 >> interface must definitely be < 1400, because of PPP overhead (e.g., IPCP). >> The 1400 negiotiated by LCP applies to PPP frame payload, not IP size. > > I think you're mistaken; see here in RFC 1661 The PPP MTU and the IP interface MTU can be the same only as long as there is no intermediate protocol doing compression or encryption. Even VJ compression has overhead (I think). So this is not necessarily true in general. You're right though that if straight IPCP is being used then PPP MTU == IP MTU. > So yes you're right, if FreeBSD is going to choose an MTU of 1376 in step > 1c, then it could propose an MRU of 1376 in step 2a, so that Windows would > choose an MSS of 1376-40. > > However I don't see how it could do this (easily), since it would have to > wait until it has finished negotiating the MRU from WinXP (step 1a/1b) > before it could even offer an MRU in the opposite direction (step 2a). It actually wouldn't be hard.. we'd just send another Config-Request, forcing a renegotiation with the smaller value. Alternately, one could implement the "MSS hack" that is implemented in ppp(8) and mpd that does a transparent "fixup" of the MSS as it flys by. > This does seem to be a lot of hoops to jump through, when you could simply > fix step 1c: if the WinXP machine says it can receive 1400-byte datagrams, > then configure the interface to send it datagrams of up to 1400 bytes! Well, this didn't work at one time. It may now in a SP2 world... so then this boils down to which brokenness (WinXP or the PIX) do you label as the real problem and which do you label as the unfortunate circumstance that we should work around. Since there's no right answer, it should be left up to the user to (re)configure as needed. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 19:52:12 2006 Return-Path: X-Original-To: net@freebsd.org 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 C683C16A420 for ; Sat, 28 Jan 2006 19:52:12 +0000 (GMT) (envelope-from frank@deze.org) Received: from xs4all.deze.org (deze.xs4all.nl [80.126.117.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DB7F43D49 for ; Sat, 28 Jan 2006 19:52:11 +0000 (GMT) (envelope-from frank@deze.org) Received: from localhost (localhost [127.0.0.1]) by xs4all.deze.org (Postfix) with ESMTP id 5617E1142B for ; Sat, 28 Jan 2006 20:52:10 +0100 (CET) Received: from xs4all.deze.org ([127.0.0.1]) by localhost (drawbridge.deze.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01014-02 for ; Sat, 28 Jan 2006 20:52:06 +0100 (CET) Received: from [192.168.1.2] (corfu [192.168.1.2]) by xs4all.deze.org (Postfix) with ESMTP id C681E11429 for ; Sat, 28 Jan 2006 20:52:06 +0100 (CET) Message-ID: <43DBCB6B.7080504@deze.org> Date: Sat, 28 Jan 2006 20:52:11 +0100 From: Frank User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at deze.org Cc: Subject: Creating span port using netgraph X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 19:52:12 -0000 Hi, I'm trying to setup a "span" Interface for using with snort. Basically, the span interface should receive a copy of all IP packets seen on my real network interfaces, with the purpose that snort can snoop this interface. After reading the manuals, and searching the Internet I came up with the following script: #!/bin/sh # load ng_ether to get ethernet interfaces if ! kldstat -v | grep ng_ether > /dev/null 2>&1; then kldload ng_ether fi # create ngeth0 and bind xl0, xl1, xl2 and xl3 to it ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many lower one ngctl connect xl0: ngeth0:lower lower many0 ngctl connect xl1: ngeth0:lower lower many1 ngctl connect xl2: ngeth0:lower lower many2 ngctl connect xl3: ngeth0:lower lower many3 # bring up ngeth0 for sniffing duties ifconfig ngeth0 monitor up After I run this script, all network connections freeze and I lost all IP connectvity. If I tcpdup on any inteface (xl? or ngeth0) no traffic is visible. Maybe I'm overlooking the obvious, but I do not understand why it does not work.... Any help is appreciated! I'm using FreeBSD 6-STABLE. Regards, Frank