From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 02:44:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 222E037B401 for ; Sun, 20 Apr 2003 02:44:36 -0700 (PDT) Received: from mail1.psconsult.nl (mail1.psconsult.nl [213.222.19.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id B178B43F85 for ; Sun, 20 Apr 2003 02:44:34 -0700 (PDT) (envelope-from paul@pop3.psconsult.nl) Received: from pop3.psconsult.nl (ps227.psconsult.nl [213.222.19.227]) by mail1.psconsult.nl (8.12.6p2/8.12.6) with ESMTP id h3K9iWwU002909; Sun, 20 Apr 2003 11:44:32 +0200 (CEST) (envelope-from paul@pop3.psconsult.nl) Received: (from paul@localhost) by pop3.psconsult.nl (8.9.2/8.9.2) id LAA74152; Sun, 20 Apr 2003 11:44:31 +0200 (CEST) (envelope-from paul) Date: Sun, 20 Apr 2003 11:44:31 +0200 From: Paul Schenkeveld To: Jeremy Chadwick Message-ID: <20030420114431.A74015@psconsult.nl> References: <20030419064801.GA11635@parodius.com> <1050791079.007237.719.nullmailer@cicuta.babolo.ru> <20030419223913.GA51072@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20030419223913.GA51072@parodius.com>; from freebsd@jdc.parodius.com on Sat, Apr 19, 2003 at 03:39:13PM -0700 cc: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 09:44:36 -0000 Hi Jeremy, On Sat, Apr 19, 2003 at 03:39:13PM -0700, Jeremy Chadwick wrote: > I hadn't considered jails -- I can't believe I forgot about > them. An excellent idea. > > For now, I've moved both of my nameservers over to relying > entirely on the public IP network for transmission of > everything, and as expected, it works great. I might have > to try the jail method for the private network! I've had good results running separate named instances for internal and external zoned within jails for two or three years now. Reading the last few messages in this thread another possible solution came to mind. What about adding host routes for the public address to send all this traffic over your private network. This does not limit traffic to DNS, in fact all traffic between the two machines will be over your private link whether the private or the public address is used. Example External subnet, public addresses ---------------+--------------------------------+--------------- | | | p.q.r.a | p.q.r.b +----------------------------+ +----------------------------+ | | | | | route add -host \ | | route add -host \ | | p.q.r.b 10.0.0.y | | p.q.r.a 10.0.0.x | | | | | | | | | | | | | +----------------------------+ +----------------------------+ | 10.0.0.x | 10.0.0.y | | | | ---------------+--------------------------------+--------------- Internal subnet, private addresses It might be necessary to adjust your ipfw rules a bit but I seem to remember you allow all traffic over your private interface. Regards, Paul Schenkeveld, Consultant PSconsult ICT Dervices BV From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 14:17:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C53337B401 for ; Sun, 20 Apr 2003 14:17:34 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFE1643FBD for ; Sun, 20 Apr 2003 14:17:33 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.gorean.org (12-234-22-23.client.attbi.com[12.234.22.23]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <20030420211733053002ff7ke>; Sun, 20 Apr 2003 21:17:33 +0000 Date: Sun, 20 Apr 2003 14:17:33 -0700 (PDT) From: Doug Barton To: Jeremy Chadwick In-Reply-To: <20030418174956.GA71335@parodius.com> Message-ID: <20030420141329.U631@znfgre.tberna.bet> References: <20030418174956.GA71335@parodius.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 21:17:34 -0000 On Fri, 18 Apr 2003, Jeremy Chadwick wrote: > Greetings. I've spoken with numerous other administrators > about the phenomenon I'm about to post, and the only answer > I've gotten so far is "Your box is broken" (how quaint). I > have two web/nameservers, both which exhibit this behaviour. I suspect the actual answer you got was that you're trying to do way too much stuff with the same two machines, which is correct; although clearly not what you wanted to hear. At minimum, based on your description of the problem, if you want named to behave differently for inside and outside traffic, you need two named instances on each box, with appropriate listen-on directives in each named.conf. I would highly recommend this approach if you're currently running both recursive and authoritative functions on the same named, which by your description I strongly suspect you are. Good luck, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 18:30:12 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF1D637B407 for ; Sun, 20 Apr 2003 18:30:12 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A930B43FB1 for ; Sun, 20 Apr 2003 18:30:06 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA18347; Sun, 20 Apr 2003 18:25:06 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h3L1P52r035042; Sun, 20 Apr 2003 18:25:05 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3L1P5me035041; Sun, 20 Apr 2003 18:25:05 -0700 (PDT) From: Archie Cobbs Message-Id: <200304210125.h3L1P5me035041@arch20m.dellroad.org> In-Reply-To: <5.2.1.1.2.20030415070820.04610eb0@194.184.65.4> To: Gianmarco Giovannelli Date: Sun, 20 Apr 2003 18:25:04 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: net@FreeBSD.ORG Subject: Re: mpd: PPTP call failed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 01:30:13 -0000 Gianmarco Giovannelli wrote: > bind: Can't assign requested address ... > vpn: > set link type pptp > set pptp enable originate incoming outcall > set pptp self 81.75.144.245 ^^^^^^^^^^^^^ Most likely your mpd box doesn't own that IP address. -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 21:11:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E74B237B401 for ; Sun, 20 Apr 2003 21:11:39 -0700 (PDT) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74B3443FE0 for ; Sun, 20 Apr 2003 21:11:39 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 62BD142D26; Sun, 20 Apr 2003 21:11:36 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Brett Glass , Bill Fumerola Date: Sun, 20 Apr 2003 21:11:36 -0700 User-Agent: KMail/1.5 References: <4.3.2.7.2.20030417122205.02aed700@localhost> <4.3.2.7.2.20030417135027.02b1c910@localhost> In-Reply-To: <4.3.2.7.2.20030417135027.02b1c910@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304202111.36197.wes@softweyr.com> cc: freebsd-net@freebsd.org Subject: Re: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 04:11:40 -0000 On Thursday 17 April 2003 12:52, Brett Glass wrote: > At 01:26 PM 4/17/2003, Bill Fumerola wrote: > >> I don't understand. Why is /24 more "natural" than /16? > > > >because that address is in class C space, not class B. read rfc791. > > As I understand it, that portion of RFC791 was obsolete decades ago. > (Even if it weren't, you should be able to subdivide the > address space.) Your understanding is correct, Microsoft's isn't. No surprise there, on either side. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 21:18:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C46E437B401 for ; Sun, 20 Apr 2003 21:18:30 -0700 (PDT) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 121DE43FCB for ; Sun, 20 Apr 2003 21:18:30 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 98CC242E3D; Sun, 20 Apr 2003 21:18:28 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Brett Glass , Chris Luke Date: Sun, 20 Apr 2003 21:18:28 -0700 User-Agent: KMail/1.5 References: <4.3.2.7.2.20030418111623.02819bd0@localhost> <4.3.2.7.2.20030418163428.02bf6480@localhost> In-Reply-To: <4.3.2.7.2.20030418163428.02bf6480@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304202118.28427.wes@softweyr.com> cc: freebsd-net@freebsd.org Subject: Re: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 04:18:31 -0000 On Friday 18 April 2003 15:41, Brett Glass wrote: > At 04:22 PM 4/18/2003, Chris Luke wrote: > >Tunnels are point-to-point connections. Each end of the link > >has an address, even if inherited from another interface, > >and these addresses are either known in advance, or exchanged or > >negotiated by a higher-level protocol, such as the negotiation > >stuff in PPP. Thus the address of the far end is known, and is > >entered as a route into the forwarding table. > > Even assuming that you don't need ARP (and SOMEONE has to do > ARP if you're going to get to other addresses on the LAN you're > tunneling into), The "other end" does the ARP. Your packets reach the "other end" because that's where your route pointed them. The same effect works on your local LAN gatewayed to the internet every day. For instance, when I send mail to you, none of my hosts know the MAC address for mail.lariat.org becuase that address is not on the local network. My workstation looks up the address 63.229.157.2 in the routing table and matches on the default route: default 204.68.178.1 UGSc 2 0 dc0 My workstation *does* know how to ARP for 204.68.178.1: frankenrouter.softweyr.com (204.68.178.1) at 00:09:5b:37:a1:e2 on dc0 [ethernet] So it sends the packet there, and frankenrouter sends it through a point to point interface (the cable modem) to a router at san.rr.com, and so on. Eventually it gets to the router upstream of mail.lariat.org, which presumably does ARP for the address of your mailserver. > there are many applications that do need > to send out a broadcast. HP JetDirect and LapLink are two which > I know these folks to be using. The broadcast address should > be the correct one for the LAN into which you're tunneling, or > these products won't work. Since by definition your PPTP client is on the same network as the JetDirect, the PPTP server at the other end had better forward the broadcast (and multicast) packets through the tunnel, right? -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 21:27:54 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 190CF37B401 for ; Sun, 20 Apr 2003 21:27:54 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35F1D43FDF for ; Sun, 20 Apr 2003 21:27:53 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id WAA27137; Sun, 20 Apr 2003 22:27:32 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030420222403.02bde840@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 20 Apr 2003 22:27:29 -0600 To: Wes Peters , Chris Luke From: Brett Glass In-Reply-To: <200304202118.28427.wes@softweyr.com> References: <4.3.2.7.2.20030418163428.02bf6480@localhost> <4.3.2.7.2.20030418111623.02819bd0@localhost> <4.3.2.7.2.20030418163428.02bf6480@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" cc: freebsd-net@freebsd.org Subject: Re: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 04:27:54 -0000 At 10:18 PM 4/20/2003, Wes Peters wrote: >Since by definition your PPTP client is on the same network as the >JetDirect, the PPTP server at the other end had better forward the >broadcast (and multicast) packets through the tunnel, right? I'd hope so! But since Microsoft gets the subnet mask wrong, it also gets the broadcast address wrong. I'm changing their LAN to a /24 so that their reality conforms to Microsoft's imagination. --Brett From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 22:45:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F04A37B401; Sun, 20 Apr 2003 22:45:10 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82D5643FE3; Sun, 20 Apr 2003 22:45:07 -0700 (PDT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (kost [213.184.65.82])h3L5j3Af044591; Mon, 21 Apr 2003 13:45:04 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Message-ID: <3EA383E4.B9069203@grosbein.pp.ru> Date: Mon, 21 Apr 2003 13:38:44 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: security@freebsd.org Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: ipfw1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 05:45:10 -0000 Hi! May somebody look at http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/51132 ? It looks like ipfw1 has serious bug in the ruleset processing. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 23:20:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC15537B401 for ; Sun, 20 Apr 2003 23:20:48 -0700 (PDT) Received: from Draculina.otdel-1.org (draculina.otdel-1.org [195.230.89.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id B151943FAF for ; Sun, 20 Apr 2003 23:20:47 -0700 (PDT) (envelope-from nms@Draculina.otdel-1.org) Received: from Draculina.otdel-1.org (localhost [127.0.0.1]) by Draculina.otdel-1.org (8.12.6/8.12.6) with ESMTP id h3L6KbSH044654; Mon, 21 Apr 2003 10:20:37 +0400 (MSD) (envelope-from nms@Draculina.otdel-1.org) Received: (from nms@localhost) by Draculina.otdel-1.org (8.12.6/8.12.6/Submit) id h3L6KZrp044653; Mon, 21 Apr 2003 10:20:35 +0400 (MSD) Date: Mon, 21 Apr 2003 10:20:35 +0400 From: Nikolai SAOUKH To: Archie Cobbs Message-ID: <20030421062035.GA44592@otdel1.org> Mail-Followup-To: Archie Cobbs , Gianmarco Giovannelli , net@FreeBSD.ORG References: <5.2.1.1.2.20030415070820.04610eb0@194.184.65.4> <200304210125.h3L1P5me035041@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304210125.h3L1P5me035041@arch20m.dellroad.org> User-Agent: Mutt/1.5.4i cc: Gianmarco Giovannelli cc: net@FreeBSD.ORG Subject: Re: mpd: PPTP call failed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 06:20:49 -0000 | > bind: Can't assign requested address | ... | > vpn: | > set link type pptp | > set pptp enable originate incoming outcall | > set pptp self 81.75.144.245 | ^^^^^^^^^^^^^ | Most likely your mpd box doesn't own that IP address. No, ther order of lines is significant (undocumented feature of mpd). Try this set link type pptp set pptp self 81.75.144.245 set pptp enable originate incoming outcall From owner-freebsd-net@FreeBSD.ORG Sun Apr 20 23:58:28 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 586FB37B401 for ; Sun, 20 Apr 2003 23:58:28 -0700 (PDT) Received: from cecov.masternet.it (cecov.masternet.it [194.184.65.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4F6843F3F for ; Sun, 20 Apr 2003 23:58:26 -0700 (PDT) (envelope-from gmarco@scotty.masternet.it) Received: from usul.scotty.masternet.it (freebsd.giovannelli.com [194.184.65.139]) by cecov.masternet.it (8.12.9/8.12.9) with ESMTP id h3L6xJNO084011; Mon, 21 Apr 2003 08:59:19 +0200 (CEST) (envelope-from gmarco@scotty.masternet.it) Message-Id: <5.2.1.1.2.20030421085241.0275c600@194.184.65.7> X-Sender: gmarco@194.184.65.7 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 21 Apr 2003 08:59:58 +0200 To: Archie Cobbs From: Gianmarco Giovannelli In-Reply-To: <200304210125.h3L1P5me035041@arch20m.dellroad.org> References: <5.2.1.1.2.20030415070820.04610eb0@194.184.65.4> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: net@freebsd.org Subject: Re: mpd: PPTP call failed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 06:58:28 -0000 At 20/04/2003, you wrote: >Gianmarco Giovannelli wrote: > > bind: Can't assign requested address > >... > > > vpn: > > set link type pptp > > set pptp enable originate incoming outcall > > set pptp self 81.75.144.245 > ^^^^^^^^^^^^^ > >Most likely your mpd box doesn't own that IP address. Infact it doesn't ... it is owns by the Zyxel 645R (the wan side) which does a complete nat/pat to the inner FreeBSD box (that has IP 10.0.1.1 and the router's ethernet is 10.0.1.254). But if I can't use this address which one I should use ? The FreeBSD box has/knows only private IPs . Perhaps it is the idea behind this configuration which is wrong but I thought it could work, also because it seems to work in an other situation with only a side with a router that does the complete nat (the other side use ppp and a bridge 645M, so the wan IP address is on the tun0 device of the box). Any ideas ? Anyone else which has tried a setup like this ? Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.gufi.org/~gmarco From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 00:21:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88D3437B401 for ; Mon, 21 Apr 2003 00:21:48 -0700 (PDT) Received: from cecov.masternet.it (cecov.masternet.it [194.184.65.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D8C843FE0 for ; Mon, 21 Apr 2003 00:21:47 -0700 (PDT) (envelope-from gmarco@scotty.masternet.it) Received: from usul.scotty.masternet.it (freebsd.giovannelli.com [194.184.65.139]) by cecov.masternet.it (8.12.9/8.12.9) with ESMTP id h3L7MkNO084070; Mon, 21 Apr 2003 09:22:47 +0200 (CEST) (envelope-from gmarco@scotty.masternet.it) Message-Id: <5.2.1.1.2.20030421090010.02141e98@194.184.65.7> X-Sender: gmarco@194.184.65.7 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 21 Apr 2003 09:23:26 +0200 To: Nikolai SAOUKH From: Gianmarco Giovannelli In-Reply-To: <20030421062035.GA44592@otdel1.org> References: <200304210125.h3L1P5me035041@arch20m.dellroad.org> <5.2.1.1.2.20030415070820.04610eb0@194.184.65.4> <200304210125.h3L1P5me035041@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: net@freebsd.org Subject: Re: mpd: PPTP call failed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 07:21:48 -0000 At 21/04/2003, you wrote: >| > bind: Can't assign requested address >| ... >| > vpn: >| > set link type pptp >| > set pptp enable originate incoming outcall >| > set pptp self 81.75.144.245 >| ^^^^^^^^^^^^^ >| Most likely your mpd box doesn't own that IP address. > >No, ther order of lines is significant (undocumented feature of mpd). Try this > > set link type pptp > set pptp self 81.75.144.245 > set pptp enable originate incoming outcall Uhm .. that is interesting... :-) Infact in the other situation I have : vpn: set link type pptp set pptp self 194.184.65.165 set pptp peer 194.184.65.138 set pptp enable originate incoming outcall But also changing the order of the line I get the same error. Is it possible ? Thanks ... Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.gufi.org/~gmarco From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 06:43:05 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4257437B401; Mon, 21 Apr 2003 06:43:05 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3A1543FA3; Mon, 21 Apr 2003 06:43:04 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h3LDh4Bp098281; Mon, 21 Apr 2003 06:43:04 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h3LDh26f098277; Mon, 21 Apr 2003 06:43:02 -0700 (PDT) (envelope-from rizzo) Date: Mon, 21 Apr 2003 06:43:02 -0700 From: Luigi Rizzo To: Eugene Grosbein Message-ID: <20030421064302.A98117@xorpc.icir.org> References: <3EA383E4.B9069203@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3EA383E4.B9069203@grosbein.pp.ru>; from eugen@grosbein.pp.ru on Mon, Apr 21, 2003 at 01:38:44PM +0800 cc: net@freebsd.org cc: security@freebsd.org Subject: Re: ipfw1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 13:43:05 -0000 indeed, it looks like there is/has never been support in RELENG_4's ip_fw.c for "not me" -- the section of code below should change like this (untested -- check the polarity of the test): if (f->fw_flg & IP_FW_F_SME) { INADDR_TO_IFP(src_ip, tif); - if (tif == NULL) + if ((tif == NULL) ^ ((f->fw_flg & IP_FW_F_INVSRC) != 0)) continue; } if (f->fw_flg & IP_FW_F_DME) { INADDR_TO_IFP(dst_ip, tif); - if (tif == NULL) + if ((tif == NULL) ^ ((f->fw_flg & IP_FW_F_INVDST) != 0)) continue; } ipfw2 does support this. On Mon, Apr 21, 2003 at 01:38:44PM +0800, Eugene Grosbein wrote: > Hi! > > May somebody look at http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/51132 ? > It looks like ipfw1 has serious bug in the ruleset processing. on a side note, i would have been more specific and said "ipfw1 has a serious bug in processing "not me" rules. Granted, your way of stating the problem attracted my attention for this time, but next time i might well think "ok it might be something minor..." :) cheers luigi > Eugene Grosbein > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 08:31:13 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31F7E37B401 for ; Mon, 21 Apr 2003 08:31:13 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74DC443FDD for ; Mon, 21 Apr 2003 08:31:12 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id IAA22757; Mon, 21 Apr 2003 08:19:39 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h3LFJc2r037126; Mon, 21 Apr 2003 08:19:39 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3LFJcBK037125; Mon, 21 Apr 2003 08:19:38 -0700 (PDT) From: Archie Cobbs Message-Id: <200304211519.h3LFJcBK037125@arch20m.dellroad.org> In-Reply-To: <20030421062035.GA44592@otdel1.org> To: Nikolai SAOUKH Date: Mon, 21 Apr 2003 08:19:38 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: mpd: PPTP call failed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 15:31:13 -0000 Nikolai SAOUKH wrote: > | > set link type pptp > | > set pptp enable originate incoming outcall > | > set pptp self 81.75.144.245 > | ^^^^^^^^^^^^^ > | Most likely your mpd box doesn't own that IP address. > > No, ther order of lines is significant (undocumented feature of mpd). Try this > > set link type pptp > set pptp self 81.75.144.245 > set pptp enable originate incoming outcall The order shouldn't matter -- if it does that's a bug (not a feature :-) What exactly happens when it doesn't work? -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 08:31:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AA9B37B401 for ; Mon, 21 Apr 2003 08:31:16 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6D7643FE9 for ; Mon, 21 Apr 2003 08:31:15 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id IAA22766; Mon, 21 Apr 2003 08:20:51 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.8/8.12.8) with ESMTP id h3LFKo2r037142; Mon, 21 Apr 2003 08:20:50 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.8/8.12.8/Submit) id h3LFKosg037141; Mon, 21 Apr 2003 08:20:50 -0700 (PDT) From: Archie Cobbs Message-Id: <200304211520.h3LFKosg037141@arch20m.dellroad.org> In-Reply-To: <5.2.1.1.2.20030421085241.0275c600@194.184.65.7> To: Gianmarco Giovannelli Date: Mon, 21 Apr 2003 08:20:50 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: net@freebsd.org Subject: Re: mpd: PPTP call failed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 15:31:16 -0000 Gianmarco Giovannelli wrote: > > > bind: Can't assign requested address > > > > > vpn: > > > set link type pptp > > > set pptp enable originate incoming outcall > > > set pptp self 81.75.144.245 > > ^^^^^^^^^^^^^ > > > >Most likely your mpd box doesn't own that IP address. > > Infact it doesn't ... it is owns by the Zyxel 645R (the wan side) which > does a complete nat/pat to the inner FreeBSD box (that has IP 10.0.1.1 and > the router's ethernet is 10.0.1.254). > > But if I can't use this address which one I should use ? The FreeBSD box > has/knows only private IPs . You have to use an IP owned by the mpd box. Whether it will work or not through NAT depends on exactly what you're trying to do (and your NAT equipment). Give it a try... -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 08:55:14 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C03ED37B401; Mon, 21 Apr 2003 08:55:14 -0700 (PDT) Received: from grosbein.pp.ru (D00015.dialonly.kemerovo.su [213.184.66.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAB2F43FB1; Mon, 21 Apr 2003 08:55:08 -0700 (PDT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (smmsp@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.9/8.12.7) with ESMTP id h3LFsX7Y001886; Mon, 21 Apr 2003 23:54:42 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.9/8.12.9/Submit) id h3LFqDoX001852; Mon, 21 Apr 2003 23:52:13 +0800 (KRAST) Date: Mon, 21 Apr 2003 23:52:13 +0800 From: Eugene Grosbein To: Luigi Rizzo Message-ID: <20030421235213.B1818@grosbein.pp.ru> References: <3EA383E4.B9069203@grosbein.pp.ru> <20030421064302.A98117@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030421064302.A98117@xorpc.icir.org>; from rizzo@icir.org on Mon, Apr 21, 2003 at 06:43:02AM -0700 cc: net@freebsd.org cc: security@freebsd.org Subject: Re: ipfw1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 15:55:15 -0000 On Mon, Apr 21, 2003 at 06:43:02AM -0700, Luigi Rizzo wrote: > > May somebody look at http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/51132 ? > > It looks like ipfw1 has serious bug in the ruleset processing. > > on a side note, i would have been more specific and said "ipfw1 has > a serious bug in processing "not me" rules. > Granted, your way of stating the problem attracted my attention for > this time, but next time i might well think "ok it might be something > minor..." :) Ok, I've got it. However, I try to never bother people in this way when a problem is minor. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 09:31:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14DC237B401 for ; Mon, 21 Apr 2003 09:31:35 -0700 (PDT) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id 1364243FDD for ; Mon, 21 Apr 2003 09:31:34 -0700 (PDT) (envelope-from darcy@wavefire.com) Received: (qmail 8451 invoked from network); 21 Apr 2003 17:03:15 -0000 Received: from dbitech.wavefire.com (HELO dbitech) (darcy@64.141.15.253) by radius.wavefire.com with SMTP; 21 Apr 2003 17:03:15 -0000 Content-Type: text/plain; charset="us-ascii" From: Darcy Buskermolen Organization: Wavefire Technologies Corp. To: freebsd-net@freebsd.org Date: Mon, 21 Apr 2003 09:31:27 -0700 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200304210931.27836.darcy@wavefire.com> Subject: Netgraph one2many X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 16:31:36 -0000 I'm trying to implement a one2many setup however I'm getting the followin= g=20 errorm msg: bash-2.0$ ngctl mkpeer xl1: one2many upper one ngctl: send msg: No such file or directory bash-2.0$ --=20 Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 10:09:38 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC1C137B401; Mon, 21 Apr 2003 10:09:38 -0700 (PDT) Received: from pyroxene.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A36CF43FDF; Mon, 21 Apr 2003 10:09:37 -0700 (PDT) (envelope-from damian@sentex.net) Received: from pegmatite.sentex.ca (pegmatite.sentex.ca [192.168.42.92]) by pyroxene.sentex.ca (8.12.9/8.12.8) with ESMTP id h3LH9H8C006596; Mon, 21 Apr 2003 13:09:17 -0400 (EDT) (envelope-from damian@sentex.net) Received: by pegmatite.sentex.ca (Postfix, from userid 1001) id 2AE31170EC; Mon, 21 Apr 2003 13:09:17 -0400 (EDT) Date: Mon, 21 Apr 2003 13:09:17 -0400 From: Damian Gerow To: "Crist J. Clark" Message-ID: <20030421170916.GI2173@sentex.net> References: <20030415223713.GB648@sentex.net> <00d001c303dc$191c2830$0b01a8c0@Beastie> <20030416190520.GJ648@sentex.net> <20030418223822.GC39466@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030418223822.GC39466@blossom.cjclark.org> X-Operating-System: FreeBSD 5.0-CURRENT on a i386 X-GPG-Key: https://ssl3.sentex.ca/~damian/damian.asc X-GPG-Key-Id: 0xB841F142 X-GPG-Fingerprint: C7C1 E1D1 EC06 7C86 AF7C 57E6 173D 9CF6 B841 F142 User-Agent: Mutt/1.5.3i X-Virus-Scanned: By Sentex Communications (lava/20020517) cc: net@freebsd.org Subject: Re: IPSec tunnel setup problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 17:09:39 -0000 Thus spake Crist J. Clark (crist.clark@attbi.com) [21/04/03 11:47]: > > I've done it. I see continual re-tries for Phase I, nothing for Phase II. > > Here's what I see: > > > > tcpdump: > > 14:31:33.613674 pyroxene.sentex.ca.isakmp > asylum.afflictions.org.isakmp: isakmp: phase 1 I agg: [|sa] > > 14:31:53.428132 pyroxene.sentex.ca.isakmp > asylum.afflictions.org.isakmp: isakmp: phase 1 I agg: [|sa] > > Well, one weird thing is that pyroxene must be behind some kind of NAT > device, Nope. Pyroxene /is/ the NAT device. As is asylum. > > initiating: > [snip] > > 43:09.033625 64.7.134.90:500 -> 199.212.134.18:500: isakmp 1.0 msgid 00000000: phase 1 I agg: > ^^^ > > sa: doi=ipsec situation=identity > > p: #1 protoid=isakmp transform=1 > > t: #1 id=iketype=lifetype value=sectype=lifeduration value=0e10type=enc value=blowfishtype=keylen value=0080type=auth value=presharedtype=hash value=sha1type=group desc value=0005)))) > > ke: key len=192) > > nonce: n len=16) > > id: idtype=IPv4 protoid=udp port=500 len=4 64.7.134.90) > ^^^ > > receiving: > [snip] > > 40:07.915101 64.7.134.90:41889 -> 199.212.134.18:500: isakmp 1.0 msgid 00000000: phase 1 I agg: > ^^^^^ > > (sa: doi=ipsec situation=identity > > (p: #1 protoid=isakmp transform=1 > > (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=blowfish)(type=keylen value=0080)(type=auth value=preshared)(type=hash value=sha1)(type=group desc value=0005)))) > > (ke: key len=192) > > (nonce: n len=16) > > (id: idtype=IPv4 protoid=udp port=500 len=4 64.7.134.90) > ^^^ > > > 2003-04-16 14:40:07: DEBUG: remoteconf.c:134:getrmconf(): no remote configuration found. > > 2003-04-16 14:40:07: ERROR: isakmp.c:851:isakmp_ph1begin_r(): couldn't find configuration. > > I'm not 100% as to whether that is a deal-breaker or not. Hrmm? That's definitely odd... I'll have to check that out, to find out what's going on. Thanks for pointing it out. > This doesn't explain why initiating in the other direction doesn't > work. But what kind of devices are in between these two hosts? What is > doing NAT? The two hosts are, as pointed out above. . It might be some portmap statements in ipnat, I'll double-check, and try again. From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 10:36:02 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F11C437B401 for ; Mon, 21 Apr 2003 10:36:01 -0700 (PDT) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4C1A43FE0 for ; Mon, 21 Apr 2003 10:36:00 -0700 (PDT) (envelope-from chris@unixpages.org) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) by haakonia.hitnet.rwth-aachen.de (Postfix) with ESMTP id 1AC9CA91E; Mon, 21 Apr 2003 19:36:00 +0200 (CEST) Received: by gondor.middleearth (Postfix, from userid 1001) id 1350846A4; Mon, 21 Apr 2003 19:35:58 +0200 (CEST) Date: Mon, 21 Apr 2003 19:35:58 +0200 From: Christian Brueffer To: Darcy Buskermolen Message-ID: <20030421173558.GB17943@unixpages.org> References: <200304210931.27836.darcy@wavefire.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: <200304210931.27836.darcy@wavefire.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.0-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D cc: freebsd-net@freebsd.org Subject: Re: Netgraph one2many X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 17:36:02 -0000 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 21, 2003 at 09:31:27AM -0700, Darcy Buskermolen wrote: > I'm trying to implement a one2many setup however I'm getting the followin= g=20 > errorm msg: >=20 > bash-2.0$ ngctl mkpeer xl1: one2many upper one > ngctl: send msg: No such file or directory > bash-2.0$ >=20 Have you loaded the ng_ether and ng_one2many modules? - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+pCv+bHYXjKDtmC0RArohAKCBAvFAAd7+RnIK/AQh7VJKJySBSACggV9R RsekcYUoAlfO6AU9bAVu2no= =R2Yt -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 11:50:01 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8126537B401 for ; Mon, 21 Apr 2003 11:50:01 -0700 (PDT) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id 8D2E943FA3 for ; Mon, 21 Apr 2003 11:50:00 -0700 (PDT) (envelope-from darcy@wavefire.com) Received: (qmail 12987 invoked from network); 21 Apr 2003 19:21:43 -0000 Received: from dbitech.wavefire.com (HELO dbitech) (darcy@64.141.15.253) by radius.wavefire.com with SMTP; 21 Apr 2003 19:21:43 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Darcy Buskermolen Organization: Wavefire Technologies Corp. To: Christian Brueffer Date: Mon, 21 Apr 2003 11:49:54 -0700 User-Agent: KMail/1.4.3 References: <200304210931.27836.darcy@wavefire.com> <20030421173558.GB17943@unixpages.org> In-Reply-To: <20030421173558.GB17943@unixpages.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200304211149.54495.darcy@wavefire.com> cc: freebsd-net@freebsd.org Subject: Re: Netgraph one2many X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 18:50:01 -0000 On Monday 21 April 2003 10:35, Christian Brueffer wrote: > On Mon, Apr 21, 2003 at 09:31:27AM -0700, Darcy Buskermolen wrote: > > I'm trying to implement a one2many setup however I'm getting the > > following errorm msg: > > > > bash-2.0$ ngctl mkpeer xl1: one2many upper one > > ngctl: send msg: No such file or directory > > bash-2.0$ > > Have you loaded the ng_ether and ng_one2many modules? > > - Christian Thanks, I was missing the ng_ether. In playing around with this I came u= p=20 with an idea that might be a viable way to solve a customers problem that= =20 they are having with their VPN. Their ADSL provider, in an effort to=20 discurage using their non business accounts for server type purposes have= =20 imposed a per connection bandwith limit of 128Kbit. This makes the VPN=20 somewhat slow for his purposes. I've used netgraph and ksock to create=20 tunnels for routing of IPX information etc. this has made me wonder if it= 's=20 possible to bind a bunch of these ksocks together to create a one2many ov= er 7=20 tunnels, to allow the VPN to use the full bandwith? How probabel does th= is=20 sound for implementing in the following mannor? #create interface for connection 1 ngctl mkpeer tee dummy left2right ngctl name dummy tee1 ngctl mkpeer tee1: ksocket left inet/dgram/udp ngctl name tee1:left ksock1 #create interface for connection 2 ngctl mkpeer tee dummy left2right ngctl name dummy tee2 ngctl mkpeer tee2: ksocket left inet/dgram/udp ngctl name tee2:left ksock2 # bind connection1 ngctl msg ksock1: bind inet/${LOCAL_IP}:4096 ngctl msg ksock1: connect inet/${REMOTE_IP}:4096 #bind connection2 ngctl msg ksock2: bind inet/${LOCAL_IP}:4097 ngctl msg ksock2: connect inet/${REMOTE_IP}:4097 #bind to the existing VPN on gif0 ngctl mkpeer gif0: one2many upper one ngctl connect tee1: gif0:upper lower many1 ngctl connect tee2: gif0:upper lower many2 ngctl msg gif0:upper setconfig "{xmitAlg=3D1 failAlg=3D1 enabledLinks =3D= [ 1 1 ]=20 }" --=20 Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 13:46:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 399DB37B401 for ; Mon, 21 Apr 2003 13:46:26 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89A3243FAF for ; Mon, 21 Apr 2003 13:46:25 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc03.attbi.com (sccrmhc03) with ESMTP id <20030421204624003008rkgne>; Mon, 21 Apr 2003 20:46:24 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA86270; Mon, 21 Apr 2003 13:46:22 -0700 (PDT) Date: Mon, 21 Apr 2003 13:46:19 -0700 (PDT) From: Julian Elischer To: Darcy Buskermolen In-Reply-To: <200304210931.27836.darcy@wavefire.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Netgraph one2many X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 20:46:26 -0000 do you have the ng_ether module loaded? On Mon, 21 Apr 2003, Darcy Buskermolen wrote: > I'm trying to implement a one2many setup however I'm getting the following > errorm msg: > > bash-2.0$ ngctl mkpeer xl1: one2many upper one > ngctl: send msg: No such file or directory > bash-2.0$ > > > -- > Darcy Buskermolen > Wavefire Technologies Corp. > ph: 250.717.0200 > fx: 250.763.1759 > http://www.wavefire.com > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Apr 21 16:03:41 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC1B837B401 for ; Mon, 21 Apr 2003 16:03:40 -0700 (PDT) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id A59CC43F93 for ; Mon, 21 Apr 2003 16:03:39 -0700 (PDT) (envelope-from chris@unixpages.org) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) by haakonia.hitnet.rwth-aachen.de (Postfix) with ESMTP id 66852A91E; Tue, 22 Apr 2003 01:03:38 +0200 (CEST) Received: by gondor.middleearth (Postfix, from userid 1001) id 5440646A4; Tue, 22 Apr 2003 01:03:37 +0200 (CEST) Date: Tue, 22 Apr 2003 01:03:36 +0200 From: Christian Brueffer To: Darcy Buskermolen Message-ID: <20030421230336.GC17943@unixpages.org> References: <200304210931.27836.darcy@wavefire.com> <20030421173558.GB17943@unixpages.org> <200304211149.54495.darcy@wavefire.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+xNpyl7Qekk2NvDX" Content-Disposition: inline In-Reply-To: <200304211149.54495.darcy@wavefire.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.0-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D cc: freebsd-net@freebsd.org Subject: Re: Netgraph one2many X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 23:03:41 -0000 --+xNpyl7Qekk2NvDX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 21, 2003 at 11:49:54AM -0700, Darcy Buskermolen wrote: > On Monday 21 April 2003 10:35, Christian Brueffer wrote: > > On Mon, Apr 21, 2003 at 09:31:27AM -0700, Darcy Buskermolen wrote: > > > I'm trying to implement a one2many setup however I'm getting the > > > following errorm msg: > > > > > > bash-2.0$ ngctl mkpeer xl1: one2many upper one > > > ngctl: send msg: No such file or directory > > > bash-2.0$ > > > > Have you loaded the ng_ether and ng_one2many modules? > > > > - Christian >=20 > Thanks, I was missing the ng_ether. In playing around with this I came u= p=20 > with an idea that might be a viable way to solve a customers problem that= =20 > they are having with their VPN. Their ADSL provider, in an effort to=20 > discurage using their non business accounts for server type purposes have= =20 > imposed a per connection bandwith limit of 128Kbit. This makes the VPN=20 > somewhat slow for his purposes. I've used netgraph and ksock to create= =20 > tunnels for routing of IPX information etc. this has made me wonder if it= 's=20 > possible to bind a bunch of these ksocks together to create a one2many ov= er 7=20 > tunnels, to allow the VPN to use the full bandwith? How probabel does th= is=20 > sound for implementing in the following mannor? >=20 > #create interface for connection 1 > ngctl mkpeer tee dummy left2right > ngctl name dummy tee1 > ngctl mkpeer tee1: ksocket left inet/dgram/udp > ngctl name tee1:left ksock1 >=20 > #create interface for connection 2 > ngctl mkpeer tee dummy left2right > ngctl name dummy tee2 > ngctl mkpeer tee2: ksocket left inet/dgram/udp > ngctl name tee2:left ksock2 >=20 > # bind connection1 > ngctl msg ksock1: bind inet/${LOCAL_IP}:4096 > ngctl msg ksock1: connect inet/${REMOTE_IP}:4096 >=20 > #bind connection2 > ngctl msg ksock2: bind inet/${LOCAL_IP}:4097 > ngctl msg ksock2: connect inet/${REMOTE_IP}:4097 >=20 > #bind to the existing VPN on gif0 > ngctl mkpeer gif0: one2many upper one > ngctl connect tee1: gif0:upper lower many1 > ngctl connect tee2: gif0:upper lower many2 > ngctl msg gif0:upper setconfig "{xmitAlg=3D1 failAlg=3D1 enabledLinks = =3D[ 1 1 ]=20 > }" >=20 Sorry, can't answer that one. I have never used one2many in production environments. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --+xNpyl7Qekk2NvDX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+pHjIbHYXjKDtmC0RAp4zAKDIS5wnksSUQVzgCjhnwycUQYw7IwCeLJ+D 60B61W/uYklg5mdv4D2wy2g= =Bigu -----END PGP SIGNATURE----- --+xNpyl7Qekk2NvDX-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 01:13:06 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BBCC37B401 for ; Tue, 22 Apr 2003 01:13:05 -0700 (PDT) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68BF143F93 for ; Tue, 22 Apr 2003 01:13:03 -0700 (PDT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by smtp.atlantis.dp.ua (8.12.6p2/8.12.6) with ESMTP id h3M8CusH070469 for ; Tue, 22 Apr 2003 11:12:56 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Tue, 22 Apr 2003 11:12:56 +0300 (EEST) From: Dmitry Pryanishnikov To: freebsd-net@freebsd.org In-Reply-To: <20030421064302.A98117@xorpc.icir.org.lucky.freebsd.net> Message-ID: <20030422110553.R30692-100000@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: ipfw1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 08:13:06 -0000 Hello! On Mon, 21 Apr 2003, Luigi Rizzo wrote: > indeed, it looks like there is/has never been support in RELENG_4's ip_fw.c > for "not me" -- the section of code below should change like this > (untested -- check the polarity of the test): > > if (f->fw_flg & IP_FW_F_SME) { > INADDR_TO_IFP(src_ip, tif); > - if (tif == NULL) > + if ((tif == NULL) ^ ((f->fw_flg & IP_FW_F_INVSRC) != 0)) > continue; > } > if (f->fw_flg & IP_FW_F_DME) { > INADDR_TO_IFP(dst_ip, tif); > - if (tif == NULL) > + if ((tif == NULL) ^ ((f->fw_flg & IP_FW_F_INVDST) != 0)) > continue; > } > Or, maybe, it would be better to just MFC your fix for this problem in 1.186 like in the following (patch against 1.131.2.39, minimal testing has been done): --- ip_fw.c.orig Mon Jan 20 04:23:07 2003 +++ ip_fw.c Tue Apr 22 10:16:20 2003 @@ -1250,24 +1250,22 @@ if ((f->fw_flg & IP_FW_F_FRAG) && offset == 0 ) continue; + /* If src-addr doesn't match, not this rule. */ if (f->fw_flg & IP_FW_F_SME) { INADDR_TO_IFP(src_ip, tif); - if (tif == NULL) - continue; - } - if (f->fw_flg & IP_FW_F_DME) { - INADDR_TO_IFP(dst_ip, tif); - if (tif == NULL) - continue; - } - /* If src-addr doesn't match, not this rule. */ - if (((f->fw_flg & IP_FW_F_INVSRC) != 0) ^ ((src_ip.s_addr - & f->fw_smsk.s_addr) != f->fw_src.s_addr)) + } else + (int)tif = f->fw_src.s_addr == + (src_ip.s_addr & f->fw_smsk.s_addr); + if ( ((f->fw_flg & IP_FW_F_INVSRC) != 0) ^ (tif == NULL) ) continue; /* If dest-addr doesn't match, not this rule. */ - if (((f->fw_flg & IP_FW_F_INVDST) != 0) ^ ((dst_ip.s_addr - & f->fw_dmsk.s_addr) != f->fw_dst.s_addr)) + if (f->fw_flg & IP_FW_F_DME) { + INADDR_TO_IFP(dst_ip, tif); + } else + (int)tif = f->fw_dst.s_addr == + (dst_ip.s_addr & f->fw_dmsk.s_addr); + if (((f->fw_flg & IP_FW_F_INVDST) != 0) ^ (tif == NULL) ) continue; /* Interface check */ Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 01:35:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E671737B401 for ; Tue, 22 Apr 2003 01:35:35 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8120543F75 for ; Tue, 22 Apr 2003 01:35:34 -0700 (PDT) (envelope-from langd@informatik.tu-muenchen.de) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5]) by mailout.informatik.tu-muenchen.de (Postfix) with ESMTP id BDA3F617C; Tue, 22 Apr 2003 10:35:33 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.42.129]) by mailrelay1.informatik.tu-muenchen.de (Postfix) with ESMTP id A3681794D; Tue, 22 Apr 2003 10:35:33 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id 2F7E613B5D; Tue, 22 Apr 2003 10:35:33 +0200 (CEST) Date: Tue, 22 Apr 2003 10:35:32 +0200 From: Daniel Lang To: Martin Stiemerling Message-ID: <20030422083532.GB49848@atrbg11.informatik.tu-muenchen.de> References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9E6D34.5020100@ccrle.nec.de> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i cc: freebsd-net@freebsd.org Subject: Re: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 08:35:36 -0000 Hi Folks, I've investigated further and come to the conclusion, that the ipfilter on my box does no longer keep the state all. It doesn't work any more for both TCP und UDP. I tried to initiate a ssh connection to a host, that is not explicitly permitted, and I can see that its replies are blocked by ipfilter: [..] Apr 22 10:11:22 atleo3 ipmon[60]: 10:11:21.773527 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN Apr 22 10:11:28 atleo3 ipmon[60]: 10:11:27.973741 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN Apr 22 10:11:29 atleo3 ipmon[60]: 10:11:29.593264 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 44 -AS IN Apr 22 10:11:40 atleo3 ipmon[60]: 10:11:40.174349 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN Apr 22 10:11:56 atleo3 ipmon[60]: 10:11:56.593091 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 44 -AS IN Apr 22 10:12:04 atleo3 ipmon[60]: 10:12:04.374875 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN [..] Maybe the ruleset processing order has changed? Here are relevant rules, as used in the kernel. I use ipfstat -oi to show you my rules: [..] pass out quick on lo0 from any to any pass out quick proto icmp from any to any pass out quick proto tcp/udp from any to any keep state keep frags block in from any to any pass in quick on lo0 from any to any pass in quick from 131.159.72.12/32 to any block in quick proto tcp from any to any with short block in log level local7.notice from any to any block in log level local7.notice proto tcp from any to any ^^^^^^^^^^^^^^^^^^^ This is the rule, that blocks the packet according to the log (@7). [..] block return-rst in log level local7.notice quick proto tcp from any to any port = 1080 block return-rst in log level local7.notice quick proto tcp from any to any port = 3128 block return-rst in log level local7.notice quick proto tcp from any to any port = 8080 block in proto udp from any to any pass in quick proto icmp from any to any block in quick from any to 224.0.0.0/8 [ rules with special host exceptions omitted ] Maybe there is now a special keyword required to make a states overrule blocking rules? If I display current state in 'top' mode, and try to initiate a connection, the state does not get added! Only states of connections, that can be established due to explicitly allowed rules seem to get added. So that seems to be the problem, that somehow a connection is only added to the state tables, once it is established? That would explain why it breaks now, but I'm not sure, if I'm just doing something wrong? Any explanations appreciated. Best regards, Daniel -- IRCnet: Mr-Spock - "I hear that, if you play the WindowsXP CD backwards, you get a Satanic message!" - "That's nothing. If you play it forward, it installs WindowsXP!" Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 02:18:42 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6A1C37B401 for ; Tue, 22 Apr 2003 02:18:42 -0700 (PDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3795243FCB for ; Tue, 22 Apr 2003 02:18:41 -0700 (PDT) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h3M9IVVI039321; Tue, 22 Apr 2003 11:18:32 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 24FB290A27; Tue, 22 Apr 2003 11:13:23 +0200 (CEST) Message-ID: <3EA508EB.5020906@ccrle.nec.de> Date: Tue, 22 Apr 2003 11:18:35 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Lang References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> <20030422083532.GB49848@atrbg11.informatik.tu-muenchen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 09:18:43 -0000 Hi Daniel, the stuff below looks ok so far, i.e. it should work. Perhaps you can check with 'ipfstat -hio' (it shows the hit counts per rule) where the intial TCP packet from your host 131.159.72.12 is matched against a rule, especially this rule: > pass in quick from 131.159.72.12/32 to any If this doesn't help try to replace the state rule with this and check whether this rule has been hit at all. > pass out quick proto tcp/udp from any to any keep state keep frags NEW > pass out quick proto tcp from any to any flags S keep state keep frags IP Filter has neither changed rule processing nor a new keyword. Cheers Martin Daniel Lang wrote: > Hi Folks, > > I've investigated further and come to the conclusion, that > the ipfilter on my box does no longer keep the state all. > It doesn't work any more for both TCP und UDP. > > I tried to initiate a ssh connection to a host, that is > not explicitly permitted, and I can see that its replies > are blocked by ipfilter: > [..] > Apr 22 10:11:22 atleo3 ipmon[60]: 10:11:21.773527 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > Apr 22 10:11:28 atleo3 ipmon[60]: 10:11:27.973741 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > Apr 22 10:11:29 atleo3 ipmon[60]: 10:11:29.593264 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 44 -AS IN > Apr 22 10:11:40 atleo3 ipmon[60]: 10:11:40.174349 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > Apr 22 10:11:56 atleo3 ipmon[60]: 10:11:56.593091 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 44 -AS IN > Apr 22 10:12:04 atleo3 ipmon[60]: 10:12:04.374875 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > [..] > > Maybe the ruleset processing order has changed? Here are relevant > rules, as used in the kernel. I use ipfstat -oi to show you my rules: > [..] > > pass out quick on lo0 from any to any > pass out quick proto icmp from any to any > pass out quick proto tcp/udp from any to any keep state keep frags > > block in from any to any > pass in quick on lo0 from any to any > pass in quick from 131.159.72.12/32 to any > block in quick proto tcp from any to any with short > block in log level local7.notice from any to any > block in log level local7.notice proto tcp from any to any > ^^^^^^^^^^^^^^^^^^^ > This is the rule, that blocks the packet according to the log (@7). > [..] > block return-rst in log level local7.notice quick proto tcp from any to any port = 1080 > block return-rst in log level local7.notice quick proto tcp from any to any port = 3128 > block return-rst in log level local7.notice quick proto tcp from any to any port = 8080 > block in proto udp from any to any > pass in quick proto icmp from any to any > block in quick from any to 224.0.0.0/8 > [ rules with special host exceptions omitted ] > > Maybe there is now a special keyword required to make a states > overrule blocking rules? > > If I display current state in 'top' mode, and try to initiate a > connection, the state does not get added! Only states of connections, > that can be established due to explicitly allowed rules seem to get added. > > So that seems to be the problem, that somehow a connection is only > added to the state tables, once it is established? That would > explain why it breaks now, but I'm not sure, if I'm just doing something > wrong? > > Any explanations appreciated. > > Best regards, > Daniel -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 02:34:24 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41B9937B401 for ; Tue, 22 Apr 2003 02:34:24 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67F9643F75 for ; Tue, 22 Apr 2003 02:34:23 -0700 (PDT) (envelope-from langd@informatik.tu-muenchen.de) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5]) by mailout.informatik.tu-muenchen.de (Postfix) with ESMTP id BCF4462F4; Tue, 22 Apr 2003 11:34:22 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.42.129]) by mailrelay1.informatik.tu-muenchen.de (Postfix) with ESMTP id AF10A7943; Tue, 22 Apr 2003 11:34:22 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id 81D6513B5D; Tue, 22 Apr 2003 11:34:22 +0200 (CEST) Date: Tue, 22 Apr 2003 11:34:22 +0200 From: Daniel Lang To: Martin Stiemerling Message-ID: <20030422093422.GE49848@atrbg11.informatik.tu-muenchen.de> References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> <20030422083532.GB49848@atrbg11.informatik.tu-muenchen.de> <3EA508EB.5020906@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA508EB.5020906@ccrle.nec.de> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i cc: freebsd-net@freebsd.org Subject: Re: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 09:34:24 -0000 Hi Martin, thanks for your quick reply, Martin Stiemerling wrote on Tue, Apr 22, 2003 at 11:18:35AM +0200: [..] > the stuff below looks ok so far, i.e. it should work. > Perhaps you can check with 'ipfstat -hio' (it shows the hit counts per > rule) where the intial TCP packet from your host 131.159.72.12 is > matched against a rule, especially this rule: > > pass in quick from 131.159.72.12/32 to any No this rule is not hit, but I did not expect it. This rule just exists if the host connects to itself but not using the loopback address. The initial packet from my ssh test will of course be an _outgoing_ packet and therefore is not expect to hit an 'in' rule. However, ... > If this doesn't help try to replace the state rule with this and check > whether this rule has been hit at all. > > pass out quick proto tcp/udp from any to any keep state keep frags This rule is hit quite often. > NEW > pass out quick proto tcp from any to any flags S keep state keep frags Ok. I will try to change this rule and see, if it helps. YES. If I put this rule in front of the rule above, I immediately get a connection. What does that mean? The original rule of mine should be more general, i.e. include the situation with the SYN flag set. But it doesn't? Using this rule is a better workaround than to allow all hosts explicitly, but it still doesn't help me with UDP I guess. > IP Filter has neither changed rule processing nor a new keyword. Thanks. I was going to say "it worked before" and "I did not change anything else", but from my long experience with (l)users, this is _always_ a lie. ;-)) Best regards, Daniel -- IRCnet: Mr-Spock - Truth lies in the eye of the beholder - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 04:43:50 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD3E137B401 for ; Tue, 22 Apr 2003 04:43:50 -0700 (PDT) Received: from Draculina.otdel-1.org (draculina.otdel-1.org [195.230.89.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4C6E43FB1 for ; Tue, 22 Apr 2003 04:43:49 -0700 (PDT) (envelope-from nms@Draculina.otdel-1.org) Received: from Draculina.otdel-1.org (localhost [127.0.0.1]) by Draculina.otdel-1.org (8.12.6/8.12.6) with ESMTP id h3MBhfOA004580; Tue, 22 Apr 2003 15:43:41 +0400 (MSD) (envelope-from nms@Draculina.otdel-1.org) Received: (from nms@localhost) by Draculina.otdel-1.org (8.12.6/8.12.6/Submit) id h3MBheAF004579; Tue, 22 Apr 2003 15:43:40 +0400 (MSD) Date: Tue, 22 Apr 2003 15:43:40 +0400 From: Nikolai SAOUKH To: Archie Cobbs Message-ID: <20030422114340.GA4545@otdel1.org> Mail-Followup-To: Archie Cobbs , freebsd-net@freebsd.org References: <20030421062035.GA44592@otdel1.org> <200304211519.h3LFJcBK037125@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304211519.h3LFJcBK037125@arch20m.dellroad.org> User-Agent: Mutt/1.5.4i cc: freebsd-net@freebsd.org Subject: Re: mpd: PPTP call failed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 11:43:51 -0000 | > | > set link type pptp | > | > set pptp enable originate incoming outcall | > | > set pptp self 81.75.144.245 | > | ^^^^^^^^^^^^^ | > | Most likely your mpd box doesn't own that IP address. | > No, ther order of lines is significant (undocumented feature of mpd). Try this | > set link type pptp | > set pptp self 81.75.144.245 | > set pptp enable originate incoming outcall | The order shouldn't matter -- if it does that's a bug (not a feature :-) | What exactly happens when it doesn't work? When 'set pptp self ...' is not a second line, then mpd ignore it and binds to all interfaces. In my case, at least. From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 06:11:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 472E937B401 for ; Tue, 22 Apr 2003 06:11:36 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0E5E43F93 for ; Tue, 22 Apr 2003 06:11:34 -0700 (PDT) (envelope-from langd@informatik.tu-muenchen.de) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5]) by mailout.informatik.tu-muenchen.de (Postfix) with ESMTP id 436876156; Tue, 22 Apr 2003 15:11:34 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.42.129]) by mailrelay1.informatik.tu-muenchen.de (Postfix) with ESMTP id 3597F7943; Tue, 22 Apr 2003 15:11:34 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id D83ED13B5D; Tue, 22 Apr 2003 15:11:33 +0200 (CEST) Date: Tue, 22 Apr 2003 15:11:33 +0200 From: Daniel Lang To: Martin Stiemerling Message-ID: <20030422131133.GI49848@atrbg11.informatik.tu-muenchen.de> References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> <20030422083532.GB49848@atrbg11.informatik.tu-muenchen.de> <3EA508EB.5020906@ccrle.nec.de> <20030422093422.GE49848@atrbg11.informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030422093422.GE49848@atrbg11.informatik.tu-muenchen.de> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i cc: freebsd-net@freebsd.org Subject: Re: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 13:11:36 -0000 Hi Again, Daniel Lang wrote on Tue, Apr 22, 2003 at 11:34:22AM +0200: [..] > > NEW > pass out quick proto tcp from any to any flags S keep state keep frags > Ok. I will try to change this rule and see, if it helps. > YES. If I put this rule in front of the rule above, I immediately > get a connection. > > What does that mean? The original rule of mine should be more general, > i.e. include the situation with the SYN flag set. But it doesn't? > > Using this rule is a better workaround than to allow all hosts > explicitly, but it still doesn't help me with UDP I guess. Updated situation. It ceased working! I just checked again without changing everything and the rule still in place. But it no longer works, the packets are again blocked, as I can see in ipfilters log. Now I get the impression, that there is maybe a limit for the state tables for each "keep state" rule, and if that is hit, no more states can be added. I'll make a few tests... Ok, I've added another such rule, similar but with a specific source ip instead of any, to get it added. It worked for a few times, then suddenly the packets are beeing blocked again, just after a few hits. Heres the ipfstat -hoi output: [..] 48 pass out quick proto tcp from 131.159.72.12/32 to any flags S/FSRPAU keep state keep frags 2706 pass out quick proto tcp from any to any flags S/FSRPAU keep state keep frags 1789457 pass out quick proto tcp/udp from any to any keep state keep frags [..] Other things I could find out: If the ruleset has changed and is reloaded (ipf -Fa -f /file/with/rules) it works again for a while. Even without the "flags S" rule but with the original tcp/udp rule. Flushing the state stable (small): ipf -Fs did help, but not always. I've issued this a couple of times, and suddenly it worked again. Flushing all states: ipf -FS helped a lot. It works much longer than just flushing incomplete states. However, ipfstat -s always shows: [..] 0 no memory [..] So it's not like the states don't get added because of that.... Well, a crontab entry with ipf -FS every hour would not be a very clean solution. Any more hints, how to debug this further appreciated. Thanks, Daniel -- IRCnet: Mr-Spock - Work is for people, who don't surf - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 06:21:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AC0E37B401 for ; Tue, 22 Apr 2003 06:21:36 -0700 (PDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A900C43F3F for ; Tue, 22 Apr 2003 06:21:34 -0700 (PDT) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h3MDLXVI052088; Tue, 22 Apr 2003 15:21:33 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2978B89678; Tue, 22 Apr 2003 15:16:23 +0200 (CEST) Message-ID: <3EA541DE.1080706@ccrle.nec.de> Date: Tue, 22 Apr 2003 15:21:34 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Lang References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> <20030422083532.GB49848@atrbg11.informatik.tu-muenchen.de> <3EA508EB.5020906@ccrle.nec.de> <20030422093422.GE49848@atrbg11.informatik.tu-muenchen.de> <20030422131133.GI49848@atrbg11.informatik.tu-muenchen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 13:21:36 -0000 [...] > Flushing the state stable (small): ipf -Fs > did help, but not always. I've issued this a couple > of times, and suddenly it worked again. Ah, ok, So you are running out of state table entries... > > Flushing all states: ipf -FS helped a lot. It works much longer > than just flushing incomplete states. > However, ipfstat -s always shows: > [..] > 0 no memory > [..] That's OK, i.e. no out of memory problems within IP Filter. Would be nice to see the "State table bucket statistics" output from the end of ipfstat -s. Here are the limits for states compiled into IP FIlter (taken from ip_state.h): #ifndef IPSTATE_SIZE # define IPSTATE_SIZE 5737 #endif #ifndef IPSTATE_MAX # define IPSTATE_MAX 4013 /* Maximum number of states held */ #endif Martin From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 07:03:14 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 337E337B401 for ; Tue, 22 Apr 2003 07:03:14 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E21F44001 for ; Tue, 22 Apr 2003 07:03:10 -0700 (PDT) (envelope-from langd@informatik.tu-muenchen.de) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5]) by mailout.informatik.tu-muenchen.de (Postfix) with ESMTP id 660B66208; Tue, 22 Apr 2003 16:03:09 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.42.129]) by mailrelay1.informatik.tu-muenchen.de (Postfix) with ESMTP id 497197943; Tue, 22 Apr 2003 16:03:09 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id CB7D413B5D; Tue, 22 Apr 2003 16:03:08 +0200 (CEST) Date: Tue, 22 Apr 2003 16:03:08 +0200 From: Daniel Lang To: Martin Stiemerling Message-ID: <20030422140308.GK49848@atrbg11.informatik.tu-muenchen.de> References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> <20030422083532.GB49848@atrbg11.informatik.tu-muenchen.de> <3EA508EB.5020906@ccrle.nec.de> <20030422093422.GE49848@atrbg11.informatik.tu-muenchen.de> <20030422131133.GI49848@atrbg11.informatik.tu-muenchen.de> <3EA541DE.1080706@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA541DE.1080706@ccrle.nec.de> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i cc: freebsd-net@freebsd.org Subject: Re: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 14:03:14 -0000 Hi Martin, Martin Stiemerling wrote on Tue, Apr 22, 2003 at 03:21:34PM +0200: [..] > Ah, ok, So you are running out of state table entries... Oh well. Thats a statement I can use. :) [..] > That's OK, i.e. no out of memory problems within IP Filter. > > Would be nice to see the "State table bucket statistics" output from the > end of ipfstat -s. The buckets and active states kept changing, around 1500-4000+. I talked to our netadmin, who told me, that this could be the problem. In my ruleset I seems to carry _lots_ of unnecessary state information around. I changed this to keep state only for outgoing connection and flags S/SA set. I will see, how it behaves. Thanks a lot so far. Daniel -- IRCnet: Mr-Spock - Agartim billiard bumba m'abdul in papejim twista - rumba rock n rolla. Leik'ab mai. Spirzon Heroin se'osit gaula. - - Marijuana esit gaula. Haschisch. Opis. - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 07:29:14 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A24E937B401 for ; Tue, 22 Apr 2003 07:29:14 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECF1E43FA3 for ; Tue, 22 Apr 2003 07:29:13 -0700 (PDT) (envelope-from ddolson@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Apr 2003 10:29:13 -0400 Message-ID: From: Dave Dolson To: freebsd-net@freebsd.org Date: Tue, 22 Apr 2003 10:29:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: em net (optical GigE) driver hangs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 14:29:14 -0000 Has anyone experienced em interface hangs after approx several days of heavy operation? We are using a system which is mostly RELENG_4_7, using multiple optical em GigE devices. The symptom is that the interface stops transmitting or receiving, reporting drops on output (no tx descriptors) and input errors (MPC stat-->no receive descriptors). It turns out that all but 64 transmit descriptors are in use. The driver is waiting for the "done" flag to be set so it can clean the descriptors. The device is also in the OACTIVE state at this time. After the interface is brought down (or unplugged), the em watchdog timer goes off 5s later. We are trying to figure out two things: 1. why did the driver lock up? 2. why didn't the watchdog timer go off earlier? I think we would be happy to solve #2 given the rarity of the event. Is the RELENG_4 version likely to fix the problem? Any help or similar reports would be appreciated. Thanks, David Dolson (ddolson@sandvine.com, www.sandvine.com) From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 09:54:07 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F279337B401 for ; Tue, 22 Apr 2003 09:54:06 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2D6743FBD for ; Tue, 22 Apr 2003 09:54:05 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3MGrwXB027200 for ; Tue, 22 Apr 2003 09:54:02 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304221654.h3MGrwXB027200@gw.catspoiler.org> Date: Tue, 22 Apr 2003 09:53:58 -0700 (PDT) From: Don Lewis To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Subject: IP fragmentation disagreement between current and stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 16:54:07 -0000 It looks like I've stumbled across an IP fragmentation bug in either 5.0-current or 4.8-stable that afflicts certain packet sizes. If I ping from the 4.8-stable machine to the 5.0-current machine # ping -c 1 -s 3176 192.168.101.3 I observe the following using tcpdump on the 5.0-current machine: 09:27:47.457860 192.168.101.2 > 192.168.101.3: icmp: echo request (frag 47248:1480@0+) (ttl 64, len 1500) 4500 05dc b890 2000 4001 513a c0a8 6502 c0a8 6503 0800 3479 9953 0000 836d a53e 9dff 0600 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 09:27:47.457957 192.168.101.2 > 192.168.101.3: icmp (frag 47248:1480@1480+) (ttl 64, len 1500) 4500 05dc b890 20b9 4001 5081 c0a8 6502 c0a8 6503 c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd 09:27:47.457976 192.168.101.2 > 192.168.101.3: icmp (frag 47248:224@2960) (ttl 64, len 244) 4500 00f4 b890 0172 4001 74b0 c0a8 6502 c0a8 6503 8889 8a8b 8c8d 8e8f 9091 9293 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 c4c5 09:27:47.458040 192.168.101.3 > 192.168.101.2: icmp: echo reply (frag 16298:1480@0+) (ttl 64, len 1500) 4500 05dc 3faa 2000 4001 ca20 c0a8 6503 c0a8 6502 0000 3c79 9953 0000 836d a53e 9dff 0600 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 09:27:47.458046 192.168.101.3 > 192.168.101.2: icmp (frag 16298:1480@1480+) (ttl 64, len 1500) 4500 05dc 3faa 20b9 4001 c967 c0a8 6503 c0a8 6502 c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd 09:27:47.458050 192.168.101.3 > 192.168.101.2: icmp (frag 16298:224@2960) (ttl 64, len 244) 4500 00f4 3faa 0172 4001 ed96 c0a8 6503 c0a8 6502 8889 8a8b 8c8d 8e8f 9091 9293 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 c4c5 The -current machine is seenig the echo request and is sending a response. If I observe the same traffic on the -stable machine, I see: 09:27:47.458727 192.168.101.2 > 192.168.101.3: icmp: echo request (frag 47248:1480@0+) (ttl 64, len 1500) 4500 05dc b890 2000 4001 513a c0a8 6502 c0a8 6503 0800 3479 9953 0000 836d a53e 9dff 0600 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 09:27:47.458743 192.168.101.2 > 192.168.101.3: icmp (frag 47248:1480@1480+) (ttl 64, len 1500) 4500 05dc b890 20b9 4001 5081 c0a8 6502 c0a8 6503 c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd 09:27:47.458758 192.168.101.2 > 192.168.101.3: icmp (frag 47248:224@2960) (ttl 64, len 244) 4500 00f4 b890 0172 4001 74b0 c0a8 6502 c0a8 6503 8889 8a8b 8c8d 8e8f 9091 9293 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 c4c5 09:27:47.459525 192.168.101.3 > 192.168.101.2: icmp: echo reply (frag 16298:1480@0+) (ttl 64, len 1500) 4500 05dc 3faa 2000 4001 ca20 c0a8 6503 c0a8 6502 0000 3c79 9953 0000 836d a53e 9dff 0600 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 09:27:47.459641 192.168.101.3 > 192.168.101.2: icmp (frag 16298:1480@1480+) (ttl 64, len 1500) 4500 05dc 3faa 20b9 4001 c967 c0a8 6503 c0a8 6502 c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd 09:27:47.459657 truncated-ip - 2 bytes missing! 192.168.101.3 > 192.168.101.2: icmp (frag 16298:224@2960) (ttl 64, len 244) 4500 00f4 3faa 0172 4001 ed96 c0a8 6503 c0a8 6502 8889 8a8b 8c8d 8e8f 9091 9293 9495 9697 9899 9a9b 9c9d 9e9f a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf b0b1 b2b3 b4b5 b6b7 b8b9 babb bcbd bebf c0c1 c2c3 c4c5 For some reason, the stable machine doesn't like the last fragment, and the IP stack and the ping command don't see the response. If I ping from -current to -stable, the -stable machine doesn't like the last fragment of the echo request and doesn't send a response. If I increase the packet size by any multiple of 1480 bytes (which results in the same final fragment size), I see the same symptoms. Interestingly, I don't see any problems if I decrease the packet size by 1480 bytes to 1696, everything works just fine. Viewed from -current: 09:51:31.518033 192.168.101.2 > 192.168.101.3: icmp: echo request (frag 57049:1480@0+) (ttl 64, len 1500) 4500 05dc ded9 2000 4001 2af1 c0a8 6502 c0a8 6503 0800 c081 ef53 0000 1373 a53e 49f1 0700 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 09:51:31.518064 192.168.101.2 > 192.168.101.3: icmp (frag 57049:224@1480) (ttl 64, len 244) 4500 00f4 ded9 00b9 4001 4f20 c0a8 6502 c0a8 6503 c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd 09:51:31.518136 192.168.101.3 > 192.168.101.2: icmp: echo reply (frag 40560:1480@0+) (ttl 64, len 1500) 4500 05dc 9e70 2000 4001 6b5a c0a8 6503 c0a8 6502 0000 c881 ef53 0000 1373 a53e 49f1 0700 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 09:51:31.518141 192.168.101.3 > 192.168.101.2: icmp (frag 40560:224@1480) (ttl 64, len 244) 4500 00f4 9e70 00b9 4001 8f89 c0a8 6503 c0a8 6502 c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd Viewed from -stable: 09:51:31.520577 192.168.101.2 > 192.168.101.3: icmp: echo request (frag 57049:1480@0+) (ttl 64, len 1500) 4500 05dc ded9 2000 4001 2af1 c0a8 6502 c0a8 6503 0800 c081 ef53 0000 1373 a53e 49f1 0700 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 09:51:31.520592 192.168.101.2 > 192.168.101.3: icmp (frag 57049:224@1480) (ttl 64, len 244) 4500 00f4 ded9 00b9 4001 4f20 c0a8 6502 c0a8 6503 c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd 09:51:31.521293 192.168.101.3 > 192.168.101.2: icmp: echo reply (frag 40560:1480@0+) (ttl 64, len 1500) 4500 05dc 9e70 2000 4001 6b5a c0a8 6503 c0a8 6502 0000 c881 ef53 0000 1373 a53e 49f1 0700 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 09:51:31.521310 192.168.101.3 > 192.168.101.2: icmp (frag 40560:224@1480) (ttl 64, len 244) 4500 00f4 9e70 00b9 4001 8f89 c0a8 6503 c0a8 6502 c0c1 c2c3 c4c5 c6c7 c8c9 cacb cccd cecf d0d1 d2d3 d4d5 d6d7 d8d9 dadb dcdd dedf e0e1 e2e3 e4e5 e6e7 e8e9 eaeb eced eeef f0f1 f2f3 f4f5 f6f7 f8f9 fafb fcfd From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 10:12:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA19937B401 for ; Tue, 22 Apr 2003 10:12:36 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4301C43FAF for ; Tue, 22 Apr 2003 10:12:36 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3MHCTXB027263 for ; Tue, 22 Apr 2003 10:12:33 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304221712.h3MHCTXB027263@gw.catspoiler.org> Date: Tue, 22 Apr 2003 10:12:29 -0700 (PDT) From: Don Lewis To: freebsd-net@FreeBSD.org In-Reply-To: <200304221654.h3MGrwXB027200@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Subject: Re: IP fragmentation disagreement between current and stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 17:12:37 -0000 On 22 Apr, To: freebsd-net@freebsd.org wrote: > # ping -c 1 -s 3176 192.168.101.3 > If I increase the packet size by any multiple of 1480 bytes (which > results in the same final fragment size), I see the same symptoms. > Interestingly, I don't see any problems if I decrease the packet size by > 1480 bytes to 1696, everything works just fine. I explored the vicinity of 3176 and found that 3174 works, 3175 through 3177 don't work, and 3178 works. I'm smelling a packet length calculation error. In the case of a 3176 byte ping, the final fragment will contain 222 bytes of data. With a 14 byte Ethernet header and a 20 byte IP header, that just fits into one 256 byte mbuf. I wonder if there is a divide by 4 to calculate the number of words, and the remainder is being discarded instead of being rounded up? And why does this problem only occur if there are three or more fragments? Could this be a driver problem instead of a problem in the stack itself? Both ends are fxp cards. From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 10:22:27 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AFFE37B401; Tue, 22 Apr 2003 10:22:27 -0700 (PDT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A757443F75; Tue, 22 Apr 2003 10:22:25 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay.macomnet.ru (8.11.6/8.11.6) with ESMTP id h3MHMOR3932529; Tue, 22 Apr 2003 21:22:24 +0400 (MSD) Date: Tue, 22 Apr 2003 21:22:24 +0400 (MSD) From: Maxim Konovalov To: Don Lewis In-Reply-To: <200304221712.h3MHCTXB027263@gw.catspoiler.org> Message-ID: <20030422211839.D75980@news1.macomnet.ru> References: <200304221712.h3MHCTXB027263@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: IP fragmentation disagreement between current and stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 17:22:27 -0000 On 10:12-0700, Apr 22, 2003, Don Lewis wrote: > On 22 Apr, To: freebsd-net@freebsd.org wrote: > > > # ping -c 1 -s 3176 192.168.101.3 > > > If I increase the packet size by any multiple of 1480 bytes (which > > results in the same final fragment size), I see the same symptoms. > > Interestingly, I don't see any problems if I decrease the packet size by > > 1480 bytes to 1696, everything works just fine. > > I explored the vicinity of 3176 and found that 3174 works, 3175 through > 3177 don't work, and 3178 works. I'm smelling a packet length > calculation error. In the case of a 3176 byte ping, the final fragment > will contain 222 bytes of data. With a 14 byte Ethernet header and a 20 > byte IP header, that just fits into one 256 byte mbuf. I wonder if > there is a divide by 4 to calculate the number of words, and the > remainder is being discarded instead of being rounded up? And why does > this problem only occur if there are three or more fragments? > > Could this be a driver problem instead of a problem in the stack itself? > Both ends are fxp cards. can't reproduce with ref5.freebsd.org: stable# ping -c 1 -s 3176 ref5.freebsd.org PING ref5.freebsd.org (216.136.204.102): 3176 data bytes 3184 bytes from 216.136.204.102: icmp_seq=0 ttl=46 time=194.385 ms ref5$ netstat -s -p ip | grep frag 7496159 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 38994 output datagrams fragmented 231719 fragments created 0 datagrams that can't be fragmented ref5$ netstat -s -p ip | grep frag 7496162 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 38995 output datagrams fragmented 231722 fragments created 0 datagrams that can't be fragmented It got three fragments, defragmented them, sent icmp echo reply in three fragments. -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 10:49:18 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BB3937B401 for ; Tue, 22 Apr 2003 10:49:18 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0942C43FAF for ; Tue, 22 Apr 2003 10:49:17 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 87774 invoked from network); 22 Apr 2003 17:49:16 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 22 Apr 2003 17:49:16 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 22 Apr 2003 00:45:17 -0500 (CDT) From: Mike Silbersack To: Don Lewis In-Reply-To: <200304221712.h3MHCTXB027263@gw.catspoiler.org> Message-ID: <20030422004104.Q523@odysseus.silby.com> References: <200304221712.h3MHCTXB027263@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@FreeBSD.org Subject: Re: IP fragmentation disagreement between current and stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 17:49:18 -0000 On Tue, 22 Apr 2003, Don Lewis wrote: > will contain 222 bytes of data. With a 14 byte Ethernet header and a 20 > byte IP header, that just fits into one 256 byte mbuf. I wonder if > there is a divide by 4 to calculate the number of words, and the > > Could this be a driver problem instead of a problem in the stack itself? > Both ends are fxp cards. A similar problem was found with Via Rhine chips, where having multiple packets exactly fill up the internal FIFO seemed to cause those packets to be dropped. Naturally, this only cropped up with fragmented ping packets of certain lengths. We never bothered patching it because, well, no clear solution presented itself, and it wouldn't occur in normal usage. (Actually, changing from store and forward back to smaller DMA sizes might have fixed it, I'm not sure.) So, I would not rule out the possibility of a driver / chipset bug. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 13:12:08 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7276237B401 for ; Tue, 22 Apr 2003 13:12:08 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3996143FDF for ; Tue, 22 Apr 2003 13:12:07 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h3MKC5dt059043 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Apr 2003 13:12:06 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h3MKC5OZ009213; Tue, 22 Apr 2003 13:12:05 -0700 (PDT) (envelope-from jdp) Date: Tue, 22 Apr 2003 13:12:05 -0700 (PDT) Message-Id: <200304222012.h3MKC5OZ009213@strings.polstra.com> To: net@freebsd.org From: John Polstra In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Subject: Re: em net (optical GigE) driver hangs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 20:12:08 -0000 In article , Dave Dolson wrote: > > Has anyone experienced em interface hangs after approx several days of heavy > operation? > > We are using a system which is mostly RELENG_4_7, using multiple optical em > GigE devices. > > The symptom is that the interface stops transmitting or receiving, reporting > drops on output (no tx descriptors) and input errors (MPC stat-->no receive > descriptors). > > It turns out that all but 64 transmit descriptors are in use. The driver is > waiting for the "done" flag to be set so it can clean the descriptors. > The device is also in the OACTIVE state at this time. > > After the interface is brought down (or unplugged), the em watchdog timer > goes off 5s later. > > We are trying to figure out two things: > 1. why did the driver lock up? > 2. why didn't the watchdog timer go off earlier? > > I think we would be happy to solve #2 given the rarity of the event. > Is the RELENG_4 version likely to fix the problem? I think the RELENG_4 version is likely to eliminate the problem. See the comment near the define of EM_RDTR in if_em.h (in the RELENG_4 version of that file, of course). John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 14:47:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 287D037B401 for ; Tue, 22 Apr 2003 14:47:44 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BE4E43FBF for ; Tue, 22 Apr 2003 14:47:43 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Apr 2003 17:47:41 -0400 Message-ID: From: Don Bowman To: 'John Polstra' , net@freebsd.org Date: Tue, 22 Apr 2003 17:47:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: em net (optical GigE) driver hangs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 21:47:44 -0000 From: John Polstra [mailto:jdp@polstra.com] > Sent: April 22, 2003 16:12 > To: net@freebsd.org > Subject: Re: em net (optical GigE) driver hangs? > > > In article > , > Dave Dolson wrote: > > > > Has anyone experienced em interface hangs after approx > several days of heavy > > operation? > > > > We are using a system which is mostly RELENG_4_7, using > multiple optical em > > GigE devices. > > > > The symptom is that the interface stops transmitting or > receiving, reporting > > drops on output (no tx descriptors) and input errors (MPC > stat-->no receive > > descriptors). > > > > It turns out that all but 64 transmit descriptors are in > use. The driver is > > waiting for the "done" flag to be set so it can clean the > descriptors. > > The device is also in the OACTIVE state at this time. > > > > After the interface is brought down (or unplugged), the em > watchdog timer > > goes off 5s later. > > > > We are trying to figure out two things: > > 1. why did the driver lock up? > > 2. why didn't the watchdog timer go off earlier? > > > > I think we would be happy to solve #2 given the rarity of the event. > > Is the RELENG_4 version likely to fix the problem? > > I think the RELENG_4 version is likely to eliminate the problem. See > the comment near the define of EM_RDTR in if_em.h (in the RELENG_4 > version of that file, of course). We saw that, but we are using DEVICE_POLLING, so assumed it was not the issue. We think instead its another problem, which is also solved in the RELENG_4 driver, in that em_poll() calls em_start() if device is running and there are pkts on the queue. em_start() re-arms the timer, holding off the wdog forever. --don From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 15:13:11 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E698637B401 for ; Tue, 22 Apr 2003 15:13:11 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD26543F85 for ; Tue, 22 Apr 2003 15:13:10 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3MMD2XB027887; Tue, 22 Apr 2003 15:13:07 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304222213.h3MMD2XB027887@gw.catspoiler.org> Date: Tue, 22 Apr 2003 15:13:02 -0700 (PDT) From: Don Lewis To: silby@silby.com In-Reply-To: <20030422004104.Q523@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-net@FreeBSD.org Subject: Re: IP fragmentation disagreement between current and stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 22:13:12 -0000 On 22 Apr, Mike Silbersack wrote: > > On Tue, 22 Apr 2003, Don Lewis wrote: > >> will contain 222 bytes of data. With a 14 byte Ethernet header and a 20 >> byte IP header, that just fits into one 256 byte mbuf. I wonder if >> there is a divide by 4 to calculate the number of words, and the >> >> Could this be a driver problem instead of a problem in the stack itself? >> Both ends are fxp cards. > > A similar problem was found with Via Rhine chips, where having multiple > packets exactly fill up the internal FIFO seemed to cause those packets to > be dropped. Naturally, this only cropped up with fragmented ping packets > of certain lengths. We never bothered patching it because, well, no clear > solution presented itself, and it wouldn't occur in normal usage. > (Actually, changing from store and forward back to smaller DMA sizes might > have fixed it, I'm not sure.) > > So, I would not rule out the possibility of a driver / chipset bug. That looks like the most likely problem. I swapped in an ancient de card on the -current box, and now it works. The fxp card that is is causing problems is a fairly recent Pro/100S desktop card that has an IBM OEM part number. I bought two of these cards from the same source over a period of several months, and both have another oddity. Neither one is probed by either the BIOS or the OS after a power-on cold boot. Not even the Intel diagnostic .exe program sees them. Hitting reset during the boot sequence or doing a reboot from the OS seems to reset something that allows the cards to work. I had to swap out the other card from the system that it was in and replace it with an older fxp that I had on hand because that system needed to be able to boot unattended after a power failure. I try the other card to see if it exhibits the same packet size problem. I'll also try a different flavor fxp, but that'll take some doing since the only remaining spare is on an older Asus motherboard that is on box running -stable. From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 15:27:52 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 913D137B401 for ; Tue, 22 Apr 2003 15:27:52 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89D7943F75 for ; Tue, 22 Apr 2003 15:27:51 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h3MMRndt059654 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Apr 2003 15:27:49 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h3MMRm5E009574; Tue, 22 Apr 2003 15:27:48 -0700 (PDT) (envelope-from jdp) Date: Tue, 22 Apr 2003 15:27:48 -0700 (PDT) Message-Id: <200304222227.h3MMRm5E009574@strings.polstra.com> To: net@freebsd.org From: John Polstra In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Subject: Re: em net (optical GigE) driver hangs? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 22:27:52 -0000 In article , Don Bowman wrote: > From: John Polstra [mailto:jdp@polstra.com] > > I think the RELENG_4 version is likely to eliminate the problem. See > > the comment near the define of EM_RDTR in if_em.h (in the RELENG_4 > > version of that file, of course). > > We saw that, but we are using DEVICE_POLLING, so assumed it was not > the issue. Assuming the RDTR-related hangs are caused by a chip bug, I think they would happen if the RDTR register was set to a nonzero value, whether or not you were using interrupts in the device driver. > We think instead its another problem, which is also solved in the > RELENG_4 driver, in that em_poll() calls em_start() if device is > running and there are pkts on the queue. em_start() re-arms the > timer, holding off the wdog forever. That may well be true. But the non-firing of the watchdog timer is a separate problem from the occurrence of the hangs in the first place. In other words, if everything were working perfectly you wouldn't need the watchdog timer at all. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 20:50:50 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85F1B37B401 for ; Tue, 22 Apr 2003 20:50:50 -0700 (PDT) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF0D943FDD for ; Tue, 22 Apr 2003 20:50:46 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id CFE1843212; Tue, 22 Apr 2003 20:50:44 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Brett Glass , Chris Luke Date: Sun, 20 Apr 2003 23:33:15 -0700 User-Agent: KMail/1.5 References: <4.3.2.7.2.20030418163428.02bf6480@localhost> <4.3.2.7.2.20030420222403.02bde840@localhost> In-Reply-To: <4.3.2.7.2.20030420222403.02bde840@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304202333.15451.wes@softweyr.com> cc: freebsd-net@freebsd.org Subject: Re: Userland PPP/PPTP tunneling problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 03:50:51 -0000 On Sunday 20 April 2003 21:27, Brett Glass wrote: > At 10:18 PM 4/20/2003, Wes Peters wrote: > >Since by definition your PPTP client is on the same network as the > >JetDirect, the PPTP server at the other end had better forward the > >broadcast (and multicast) packets through the tunnel, right? > > I'd hope so! But since Microsoft gets the subnet mask wrong, it > also gets the broadcast address wrong. I'm changing their > LAN to a /24 so that their reality conforms to Microsoft's > imagination. That *should* work. As you note, TCP/IP networking with Microsoft is a crapshoot; they seem to be unencumbered by understanding how things are supposed to work. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 22:52:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 839C537B401 for ; Tue, 22 Apr 2003 22:52:26 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5D0B43F75 for ; Tue, 22 Apr 2003 22:52:25 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3N5qHXB028433; Tue, 22 Apr 2003 22:52:21 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304230552.h3N5qHXB028433@gw.catspoiler.org> Date: Tue, 22 Apr 2003 22:52:17 -0700 (PDT) From: Don Lewis To: silby@silby.com In-Reply-To: <20030422004104.Q523@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-net@FreeBSD.org Subject: Re: IP fragmentation disagreement between current and stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 05:52:26 -0000 On 22 Apr, Mike Silbersack wrote: > > On Tue, 22 Apr 2003, Don Lewis wrote: > >> will contain 222 bytes of data. With a 14 byte Ethernet header and a 20 >> byte IP header, that just fits into one 256 byte mbuf. I wonder if >> there is a divide by 4 to calculate the number of words, and the >> >> Could this be a driver problem instead of a problem in the stack itself? >> Both ends are fxp cards. > > A similar problem was found with Via Rhine chips, where having multiple > packets exactly fill up the internal FIFO seemed to cause those packets to > be dropped. Naturally, this only cropped up with fragmented ping packets > of certain lengths. We never bothered patching it because, well, no clear > solution presented itself, and it wouldn't occur in normal usage. > (Actually, changing from store and forward back to smaller DMA sizes might > have fixed it, I'm not sure.) > > So, I would not rule out the possibility of a driver / chipset bug. It's starting to smell like a bug in the -current fxp driver. The de card I tried works ok. The other fxp card I tried with the same part number fails. I'd forgotten that I had a Red Hat 7.3 partition on this box, so I reinstalled the fxp card and booted Red Hat and I was able to ping the box, but that isn't quite as interesting as I had hoped because Linux sends out the fragments in the reverse order. I also moved the fxp card to a 4.8-stable box and it worked fine there too. The only things I haven't tried are the D-Link card I stumbled across, and I haven't tried booting current on one of my older machines that has an fxp port on the motherboard. The fact that tcpdump on the -current box doesn't show the problem also makes me think that the problem isn't in the IP stack. From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 00:10:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFAF737B401; Wed, 23 Apr 2003 00:10:57 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CDB443FBF; Wed, 23 Apr 2003 00:10:57 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3N7AmXB028560; Wed, 23 Apr 2003 00:10:52 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304230710.h3N7AmXB028560@gw.catspoiler.org> Date: Wed, 23 Apr 2003 00:10:48 -0700 (PDT) From: Don Lewis To: silby@silby.com, wpaul@FreeBSD.org In-Reply-To: <200304230552.h3N5qHXB028433@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-net@FreeBSD.org Subject: fxp/82550 bug (was Re: IP fragmentation disagreement between current and stable) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 07:10:58 -0000 > It's starting to smell like a bug in the -current fxp driver. I did some digging in the fxp driver, and now I think it's a chip bug that is being triggered by the -current fxp driver, which attempts to use some more advanced features of the 82550. I found this suspicious comment in the code: /* * XXX The 82550 chip appears to have trouble * dealing with IP header checksums in very small * datagrams, namely fragments from 1 to 3 bytes * in size. For example, say you want to transmit * a UDP packet of 1473 bytes. The packet will be * fragmented over two IP datagrams, the latter * containing only one byte of data. The 82550 will * botch the header checksum on the 1-byte fragment. * As long as the datagram contains 4 or more bytes * of data, you're ok. * * The following code attempts to work around this * problem: if the datagram is less than 38 bytes * in size (14 bytes ether header, 20 bytes IP header, * plus 4 bytes of data), we punt and compute the IP * header checksum by hand. This workaround doesn't * work very well, however, since it can be fooled * by things like VLAN tags and IP options that make * the header sizes/offsets vary. */ The code it mentions is inside a #ifdef block that is not enabled. I think the problem is worse than mentioned above. I attempted to totally disable hardware checksumming with some surgery to the code (because the fxp driver doesn't appear to support the ifconfig run time knobs for this), but even with hardware checksumming disabled, the final fragment was still bad. Once I totally disabled the special transmit features for the 82550 with the following patch so that the driver used the transmit code for the older chips, I was able to successfully send large fragmented pings with the troublesome sizes. diff -u -r1.173 if_fxp.c --- if_fxp.c 16 Apr 2003 09:16:55 -0000 1.173 +++ if_fxp.c 23 Apr 2003 06:45:39 -0000 @@ -573,7 +573,11 @@ * Be careful to do this only on the right devices. */ +#if 0 if (sc->revision == FXP_REV_82550 || sc->revision == FXP_REV_82550_C) { +#else + if (0) { +#endif sc->rfa_size = sizeof (struct fxp_rfa); sc->tx_cmd = FXP_CB_COMMAND_IPCBXMIT; sc->flags |= FXP_FLAG_EXT_RFA; From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 02:25:15 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 640A837B401 for ; Wed, 23 Apr 2003 02:25:15 -0700 (PDT) Received: from possum.icir.org (possum.icir.org [192.150.187.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA6F243F93 for ; Wed, 23 Apr 2003 02:25:14 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.8p1/8.12.3) with ESMTP id h3N9PBmC024921; Wed, 23 Apr 2003 02:25:11 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200304230925.h3N9PBmC024921@possum.icir.org> To: freebsd-net@freebsd.org Date: Wed, 23 Apr 2003 02:25:11 -0700 From: Pavlin Radoslavov cc: pavlin@icir.org cc: suz@crl.hitachi.co.jp Subject: Request for review and commit of PIM patches X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 09:25:15 -0000 All, For quite some time I have been maintaining the IPv4 PIM kernel patches for *BSD, and I'd like to request for their inclusion in FreeBSD-current (and hopefully in the forthcoming 5.2 release). At high level, the patches include the following: 1. Basic PIM kernel support (similar to the support that has been already added to other UN*X flavors, including IPv6 from KAME, though the other implementations were based on an early version of those patches :)) Disabled by default. To enable it, the new "options PIM" must be added to the kernel configuration file (in addition to MROUTING): options MROUTING # Multicast routing options PIM # Protocol Independent Multicast 2. Few bug fixes to the existing multicast code. 3. Added support for advanced multicast API setup/configuration and extensibility. 4. Added support for kernel-level PIM Register encapsulation. 5. Implemented a mechanism for "multicast bandwidth monitoring and upcalls". 6. Pulled-out the IP fragmentation code from ip_output() into a new function ip_fragment(). This is basically same change that was done back in November 2002, but later was reversed-back due to its non-urgency at the time: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c?rev=1.171&content-type=text/x-cvsweb-markup The motivation for the additional changes on top of the basic PIM support is because of various limitations of the basic support. All those additional changes are completely backward compatible (both at the API and the binary level), so the new features will be used only if the user-level program explicitly tries to enable them. The patches against FreeBSD-current as of April 23, 2003 are available from: http://www.icir.org/pavlin/.private/pim/pim_freebsd_current_20030423.tar.gz The details about the changes are described in the README file. The README contains also installation information. Please let me know if you have any questions. Thank you, Pavlin Radoslavov Part of this work has been supported by the XORP project at ICSI http://www.xorp.org/ Acknowledgments: - Ahmed Helmy (USC) for the original PIM patches. - George Edmond Eddy (Rusty) (then at ISI) for various code modifications. - Hitoshi Asaeda (WIDE Project) for various modifications and porting to other *BSD flavors. - Andrew Adams (NextHop) for various suggestions and feedbacks. - Chris Brown (NextHop) for various feedbacks and for the co-design of the advanced multicast API setup/configuration. - Luigi Rizzo (U. of Pisa and ICSI) for the code audition back in November 2002. - All users who were brave enough to try those patches when they were still evolving. From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 02:17:08 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35BAD37B401; Wed, 23 Apr 2003 02:17:08 -0700 (PDT) Received: from haakonia.hitnet.rwth-aachen.de (haakonia.hitnet.RWTH-Aachen.DE [137.226.181.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1104B43FBF; Wed, 23 Apr 2003 02:16:42 -0700 (PDT) (envelope-from chris@unixpages.org) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) by haakonia.hitnet.rwth-aachen.de (Postfix) with ESMTP id C6313C1DC; Wed, 23 Apr 2003 11:16:20 +0200 (CEST) Received: by gondor.middleearth (Postfix, from userid 1001) id E44C446A4; Wed, 23 Apr 2003 11:16:19 +0200 (CEST) Date: Wed, 23 Apr 2003 11:16:19 +0200 From: Christian Brueffer To: current@freebsd.org Message-ID: <20030423091619.GA26749@unixpages.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.0-CURRENT X-PGP-Key: http://people.freebsd.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D X-Mailman-Approved-At: Wed, 23 Apr 2003 05:09:37 -0700 Subject: New PF on FreeBSD snapshot available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 09:17:08 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm sending this on behalf of Pyun YongHyeon (he can't send messages to the lists himself for some reason). --------------- PF on FreeBSD 5.X URL: http://pf4freebsd.love2party.net/index.html Contact: Pyun YongHyeon Contact: Max Laier We are very pleased to announce that a new release is available for download at http://pf4freebsd.love2party.net/pf_freebsd_0.61.tar.gz. Since the first release of PF at the end of March 2003, PF has undergone several major updates such as -current and ALTQ support. We also have removed bugs in IPv6, module handling and table support code. We believe the current version 0.61 is very close to production use. PF on FreeBSD provides nearly the same features as OpenBSD PF does, except some minor differences. (Probably we can mimic this missing behaviour if kernel sources could be modified.) Now, users on FreeBSD can choose the most appropriate filtering software with regard to his/her taste or policy among PF, ipfw and ipfilter. For those who are not familiar with PF, PF supports the following features over ipfw. . built-in variable expansion . built-in NAT and preventing NAT detection . table (a kind of very large blocks of address) support . packet normalization . state modulation . powerful state tracking . automatic rule optimization . queueing with ALTQ . load balancing with multiple routes PF on FreeBSD supports FreeBSD 5 and -current systems. Because ALTQ on FreeBSD is still experimental at this time, PF's ALTQ support is somewhat limited to a small set of network drivers. With ALTQ enabled PF, you can get amazing performance with "prioritizing empty acks" on ADSL connections. Due to ALTQ network driver lacking support network interfaces such as ppp or netgraph nodes at this time, this can only be achieved on a system which uses a transparent xDSL connection. (A system that uses transparent xDSL is not aware of the existence of xDSL. So this system does not use ppp or mpd at all. This system uses a static IP address and configures its network as if the connection comes from normal T1/E1 lines. I don't know any other countries which support this kind of service except Korea.) If FreeBSD merges code from ALTQ, PF would be the most preferrable packet filter. PF on FreeBSD can be configured not to use ALTQ too. -------------- - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+plnjbHYXjKDtmC0RAv59AKCL6pG2/wMjFrDmC7nfbmJPvi/WwgCg1PyP XHAEyrmP9g2ZfyhdFC9rDZQ= =wKaV -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 14:17:22 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id D81BF37B401; Wed, 23 Apr 2003 14:17:22 -0700 (PDT) In-Reply-To: <200304230710.h3N7AmXB028560@gw.catspoiler.org> from Don Lewis at "Apr 23, 2003 00:10:48 am" To: truckman@FreeBSD.org (Don Lewis) Date: Wed, 23 Apr 2003 14:17:22 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20030423211722.D81BF37B401@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: freebsd-net@FreeBSD.org Subject: Re: fxp/82550 bug (was Re: IP fragmentation disagreement between current and stable) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 21:17:23 -0000 > > > It's starting to smell like a bug in the -current fxp driver. Or a bug in the current rev of the fxp chip. For the record, it helps to actually identify the chip you have, either by looking at the output of pciconf -l, or by looking at the chip and making a note of the part number. (I can understand why some people don't bother to do this: Intel uses a special silkscreening process that makes their part numbers nearly invisible.) > I did some digging in the fxp driver, and now I think it's a chip bug > that is being triggered by the -current fxp driver, which attempts to > use some more advanced features of the 82550. I found this suspicious > comment in the code: > > /* > * XXX The 82550 chip appears to have trouble > * dealing with IP header checksums in very small > * datagrams, namely fragments from 1 to 3 bytes > * in size. For example, say you want to transmit > * a UDP packet of 1473 bytes. The packet will be > * fragmented over two IP datagrams, the latter > * containing only one byte of data. The 82550 will > * botch the header checksum on the 1-byte fragment. > * As long as the datagram contains 4 or more bytes > * of data, you're ok. I my tests, I didn't observe any problems with larger fragments, only with the one case outlined in this comment. I think I may have mis-identified the actual bug here. I never noticed any "XX bytes missing!" messages from tcpdump when I stumbled across this problem, but I think that was because, with my test, even though I was sending out only 1 byte of data, I was still generating a 64-byte ethernet frame (64 bytes is the minimum frame size). So all I noticed was that the IP header checksum was flagged as bad by the receiving system. > * The following code attempts to work around this > * problem: if the datagram is less than 38 bytes > * in size (14 bytes ether header, 20 bytes IP header, > * plus 4 bytes of data), we punt and compute the IP > * header checksum by hand. This workaround doesn't > * work very well, however, since it can be fooled > * by things like VLAN tags and IP options that make > * the header sizes/offsets vary. > */ > > The code it mentions is inside a #ifdef block that is not enabled. It's not enabled because, as the comment says, I didn't think it was such a great idea. I also didn't fully understand the cause or nature of the failure, so I chose to switch off the TX IP checksumming entirely and leave the code/comment there so people could understand my rationale (or lack thereoff :). > I think the problem is worse than mentioned above. I attempted to > totally disable hardware checksumming with some surgery to the code > (because the fxp driver doesn't appear to support the ifconfig run time > knobs for this), but even with hardware checksumming disabled, the final > fragment was still bad. On transmit, you have to map all the buffers that comprise a packet into an array of pointer/length pairs. I *think* the chip computes the total frame length by adding up these buffer sizes. It's possible one of them is getting stomped in certain circumstances. On the other hand, if we're setting them correctly and the chip is getting them wrong, then... uh... I'm not quite sure what to do. In any case, I need to check into this a bit more. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "If stupidity were a handicap, you'd have the best parking spot." ============================================================================= From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 14:36:05 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9126C37B401; Wed, 23 Apr 2003 14:36:05 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C25A243FB1; Wed, 23 Apr 2003 14:36:04 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (scratch.catspoiler.org [192.168.101.3]) by gw.catspoiler.org (8.12.6/8.12.6) with ESMTP id h3NLZqXB030386; Wed, 23 Apr 2003 14:35:56 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200304232135.h3NLZqXB030386@gw.catspoiler.org> Date: Wed, 23 Apr 2003 14:35:52 -0700 (PDT) From: Don Lewis To: wpaul@FreeBSD.org In-Reply-To: <20030423211722.D81BF37B401@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-net@FreeBSD.org Subject: Re: fxp/82550 bug (was Re: IP fragmentation disagreement between current and stable) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 21:36:05 -0000 On 23 Apr, Bill Paul wrote: >> >> > It's starting to smell like a bug in the -current fxp driver. > > Or a bug in the current rev of the fxp chip. > > For the record, it helps to actually identify the chip you have, > either by looking at the output of pciconf -l, or by looking at the > chip and making a note of the part number. (I can understand why > some people don't bother to do this: Intel uses a special silkscreening > process that makes their part numbers nearly invisible.) fxp0@pci0:10:0: class=0x020000 card=0x00508086 chip=0x12298086 rev=0x0d hdr=0x00 82550GY L107SA39 > I my tests, I didn't observe any problems with larger fragments, > only with the one case outlined in this comment. I think I may have > mis-identified the actual bug here. I never noticed any "XX bytes > missing!" messages from tcpdump when I stumbled across this problem, > but I think that was because, with my test, even though I was sending > out only 1 byte of data, I was still generating a 64-byte ethernet > frame (64 bytes is the minimum frame size). So all I noticed was > that the IP header checksum was flagged as bad by the receiving > system. In case you haven't seen the entire thread, the problem only seems to occur if the packet is split across three or more fragments. Ping -s 3175 through 3177 break, as well as those sizes plus N*1480. I wish knew why these cards aren't visible to the BIOS or the OS after a power-on cold boot. It's pretty annoying to have to have to either hit the reset button or long on the console and reboot the OS. I haven't seen any other mention of this problem on the net. At least this isn't a bug in the fxp driver ... From owner-freebsd-net@FreeBSD.ORG Wed Apr 23 16:13:21 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A01737B401; Wed, 23 Apr 2003 16:13:21 -0700 (PDT) Received: from volatile.chemikals.org (cae88-48-006.sc.rr.com [24.88.48.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB8D743F3F; Wed, 23 Apr 2003 16:13:19 -0700 (PDT) (envelope-from morganw@chemikals.org) Received: from localhost (morganw@localhost [127.0.0.1]) h3NNDIcx008762; Wed, 23 Apr 2003 19:13:18 -0400 (EDT) (envelope-from morganw@chemikals.org) Date: Wed, 23 Apr 2003 19:13:18 -0400 (EDT) From: Wesley Morgan To: Bill Paul In-Reply-To: <20030423211722.D81BF37B401@hub.freebsd.org> Message-ID: <20030423191015.J5477@volatile.chemikals.org> References: <20030423211722.D81BF37B401@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: Don Lewis Subject: Re: fxp/82550 bug (was Re: IP fragmentation disagreement between current and stable) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2003 23:13:21 -0000 On Wed, 23 Apr 2003, Bill Paul wrote: > Or a bug in the current rev of the fxp chip. > > For the record, it helps to actually identify the chip you have, > either by looking at the output of pciconf -l, or by looking at the > chip and making a note of the part number. (I can understand why > some people don't bother to do this: Intel uses a special silkscreening > process that makes their part numbers nearly invisible.) There are a lot of people out there with intel cards. How about ... Make a patch to print some debug info, and a little utility to tickle the bug. We can report back our chipset versions and build some data on this problem rather. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From owner-freebsd-net@FreeBSD.ORG Thu Apr 24 05:58:59 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFAF837B447 for ; Thu, 24 Apr 2003 05:58:59 -0700 (PDT) Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by mx1.FreeBSD.org (Postfix) with SMTP id CD88A43FEA for ; Thu, 24 Apr 2003 05:58:04 -0700 (PDT) (envelope-from NateBSD@yahoo.it) Received: from ppp-204-152.24-151.libero.it (HELO FreeLSD) (natebsd@151.24.152.204 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 24 Apr 2003 12:57:52 -0000 Date: Thu, 24 Apr 2003 14:54:36 +0200 From: Alex To: freebsd-net@freebsd.org Message-Id: <20030424145436.672fae04.NateBSD@yahoo.it> X-Mailer: Sylpheed version 0.8.10claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: RealTek RTL8139 + Acer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: NateBSD@libero.it List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2003 12:59:00 -0000 Hello, I have a big problem with my laptop end its ethernet card. The laptop is a Acer Aspire 1601LC, the card, according to WinXP system information, is a RealTek RTL8139/810x Family NIC Fast Ethernet (the card is on pci0:7:0). I'm using FreeBSD 5.0-RELEASE and the card is not found. I try to recompile the kernel many times with different conf but without success. I past below my kernel configuration, dmesg & pciconf output. Thanks in advance. KERNCONF ______________________ machine i386 cpu I686_CPU ident LapBSD maxusers 0 options CPU_ENABLE_SSE options INET #InterNETworking options INET6 #IPv6 communications protocols options RANDOM_IP_ID options TCP_DROP_SYNFIN options ZERO_COPY_SOCKETS options UFS_ACL options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options MSDOSFS #MSDOS Filesystem options LIBICONV options LIBMCHAIN options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options SMBFS options NETSMB # SMB/CIFS requester options NETSMBCRYPTO # encrypted pasword support for SMB options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options VESA options SC_PIXEL_MODE options VGA_WIDTH90 options XSERVER # support for X server on a vt console options PPP_BSDCOMP options PPP_DEFLATE device isa device eisa device pci device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # SCSI peripherals device scbus # SCSI bus (required) device ch # SCSI media changers device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device atapicam # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Floating point support - do not disable. device npx device pmtimer # PCCARD (PCMCIA) support # Pcmcia and cardbus bridge support device cbb # cardbus (yenta) bridge device pcic # ExCA ISA and PCI bridges device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports #device sio # 8250, 16[45]50 based serial ports # Parallel port device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device device pty # Pseudo ttys # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device rl device pcm device radeondrm device random # Entropy device device loop # Network loopback device ether # Ethernet support device ppp # Kernel PPP device tun # Packet tunnel. device gif # IPv6 and IPv4 tunneling device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ums # Mouse _______________________ dmesg _______________________ Copyright (c) 1992-2003 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 5.0-RELEASE #8: Sat Apr 19 21:48:30 CEST 2003 toor@LapBSD:/usr/obj/usr/src/sys/LapBSD Preloaded elf kernel "/boot/kernel/kernel" at 0xc04f9000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04f90a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2390306360 Hz CPU: Pentium 4 (2390.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xffffffffbfebfbff> real memory = 266272768 (253 MB) avail memory = 253284352 (241 MB) Initializing GEOMetry subsystem netsmb_dev: loaded Pentium Pro MTRR support enabled VESA: v2.0, 65536k memory, flags:0x1, mode table:0xc0422882 (1000022) VESA: ATI MOBILITY RADEON 9000 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 Using $PIR table, 8 entries at 0xc00fdf40 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe8000000-0xebffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 pci0: at device 2.3 (no driver attached) atapci0: port 0x2000-0x200f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 2.6 (no driver attached) pcm0: port 0x1c80-0x1cff,0x1400-0x14ff irq 11 at device 2.7 on pci0 ohci0: mem 0xec001000-0xec001fff irq 11 at device 3.0 on pci0 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 0xec002000-0xec002fff irq 11 at device 3.1 on pci0 usb1: OHCI version 1.0, legacy support 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 0xec003000-0xec003fff irq 11 at device 3.2 on pci0 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 pci0: at device 3.3 (no driver attached) cbb0: irq 11 at device 9.0 on pci0 cardbus0: on cbb0 cbb1: irq 11 at device 9.1 on pci0 cardbus1: on cbb1 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 acpi_ec0: port 0x66,0x62 on acpi0 orm0: