From owner-freebsd-net@FreeBSD.ORG Sun Jan 4 08:41:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74C9316A4CE; Sun, 4 Jan 2004 08:41:12 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE69C43D62; Sun, 4 Jan 2004 08:41:07 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i04Gf5jl029717; Sun, 4 Jan 2004 17:41:05 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: current@freebsd.org, net@freebsd.org From: Poul-Henning Kamp Date: Sun, 04 Jan 2004 17:41:05 +0100 Message-ID: <29716.1073234465@critter.freebsd.dk> Subject: REVIEW & TEST: libalias megapatch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2004 16:41:12 -0000 http://phk.freebsd.dk/patch/libalias.patch This patch makes it possible to have multiple packet aliasing instances in a single process. Redefine a new API based on s/PacketAlias/LibAlias/g Add new "instance" argument to all functions in the new API. Put all global variables in the instance structure. Implement old API in terms of the new API. No functional change. No functions removed so there is no need for shlib version bump, only an updating entry and a __FreeBSD_version bump. The intent is to subsequently add a "multilink" facility to natd(8) for people with two xDSL lines to different providers etc. For this we need to run one packet-aliasing engine per line, and in order to not totally toast throughput, this should not result in more context switches then we are used to. (ie: not kern/usr/kern/usr/kern for the second line, but just kern/usr/kern as always). This patch makes it possible for programs like natd to run multiple packet-aliasing engines, this was not previously possible because of the widespread use of global variables in libalias. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-net@FreeBSD.ORG Sun Jan 4 12:35:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4049F16A4CE for ; Sun, 4 Jan 2004 12:35:29 -0800 (PST) Received: from ganymede.hub.org (u46n208.hfx.eastlink.ca [24.222.46.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36D2443D58 for ; Sun, 4 Jan 2004 12:35:23 -0800 (PST) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id ED1AC36494; Sun, 4 Jan 2004 16:31:41 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id EC4B234455 for ; Sun, 4 Jan 2004 16:31:41 -0400 (AST) Date: Sun, 4 Jan 2004 16:31:41 -0400 (AST) From: "Marc G. Fournier" To: freebsd-net@freebsd.org Message-ID: <20040104162220.S28998@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Odd behaviour on em0 device in -stable ... I think ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2004 20:35:29 -0000 I'm having some odd behaviour with one of my servers ... it is the only one of 4 that I have that has an em device, and, from what I can tell, the problem doesn't exist on any of the other 3 ... The problem is that I want to move an IP from one of the other servers (all with fxp interfaces) over to the 4th, with the em device ... I -alias the IP from the fxp device, and alias it over to the em device, and I can no longer access it remotely ... If I alias it onto any of hte other two fxp based servers, it works fine. If I ping from the old server, on the same network, it pings fine ... its only remote pings that don't work ... and all other IPs currently on the em server are pingable too, so its not like I have ICMP blocked at any one point ... All 4 servers are plug'd into a Linksys 10/100 Switch, which is then plug'd into a Cisco Switch ... If I add an unused IP to the em device, it is pingable ... its as if somewhere isn't seeing the routing change from the old fxp based server over to the new em based one, but if I put it onto a different fxp based server, it works ... Trying to do a 'ping -S ns.uunet.ca' doesn't work either, but using an existing, pingable IP, does ... netmask is set identical to all the other IPs on the machine, and arp -a shows the IP as 'permanent' ... I'm not sure what to look at ... the only 'odd man out' here is the em device itself, but by the fact that I can add an unassigned IP to it, I'm not hitting a limit on # of aliased IPs (currently only 21) ... and I've tried with another assigned IP (unalias from fxp device, move it to em device) and it too becomes unpingable, but works fine if I move it to another fxp device on a different server ... Am I missing something obvious here? Thanks ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-net@FreeBSD.ORG Sun Jan 4 15:12:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CDDA16A4CE for ; Sun, 4 Jan 2004 15:12:59 -0800 (PST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01EA443D55 for ; Sun, 4 Jan 2004 15:12:53 -0800 (PST) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.10/8.12.10) with ESMTP id i04NCqcW071677; Sun, 4 Jan 2004 18:12:52 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.10/8.12.10/Submit) id i04NCqj5071676; Sun, 4 Jan 2004 18:12:52 -0500 (EST) (envelope-from barney) Date: Sun, 4 Jan 2004 18:12:52 -0500 From: Barney Wolff To: "Marc G. Fournier" Message-ID: <20040104231252.GA71628@pit.databus.com> References: <20040104162220.S28998@ganymede.hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040104162220.S28998@ganymede.hub.org> User-Agent: Mutt/1.5.5.1i X-Scanned-By: MIMEDefang 2.39 cc: freebsd-net@freebsd.org Subject: Re: Odd behaviour on em0 device in -stable ... I think ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2004 23:12:59 -0000 On Sun, Jan 04, 2004 at 04:31:41PM -0400, Marc G. Fournier wrote: > > The problem is that I want to move an IP from one of the other servers > (all with fxp interfaces) over to the 4th, with the em device ... I -alias > the IP from the fxp device, and alias it over to the em device, and I can > no longer access it remotely ... > > If I alias it onto any of hte other two fxp based servers, it works fine. Something, either the switch or the router, has a stale arp table entry. It's a little curious that this ever works, without resetting whatever it is. Perhaps the fxp's manage to send a gratuitous arp when taking on a new alias. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Sun Jan 4 16:08:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0925C16A4CE for ; Sun, 4 Jan 2004 16:08:17 -0800 (PST) Received: from ganymede.hub.org (u46n208.hfx.eastlink.ca [24.222.46.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE4A543D2D for ; Sun, 4 Jan 2004 16:08:15 -0800 (PST) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 1625F352C8; Sun, 4 Jan 2004 20:04:35 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 0D4F13474E; Sun, 4 Jan 2004 20:04:35 -0400 (AST) Date: Sun, 4 Jan 2004 20:04:34 -0400 (AST) From: "Marc G. Fournier" To: Barney Wolff In-Reply-To: <20040104231252.GA71628@pit.databus.com> Message-ID: <20040104200204.V28998@ganymede.hub.org> References: <20040104162220.S28998@ganymede.hub.org> <20040104231252.GA71628@pit.databus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Odd behaviour on em0 device in -stable ... I think ... 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, 05 Jan 2004 00:08:17 -0000 On Sun, 4 Jan 2004, Barney Wolff wrote: > On Sun, Jan 04, 2004 at 04:31:41PM -0400, Marc G. Fournier wrote: > > > > The problem is that I want to move an IP from one of the other servers > > (all with fxp interfaces) over to the 4th, with the em device ... I -alias > > the IP from the fxp device, and alias it over to the em device, and I can > > no longer access it remotely ... > > > > If I alias it onto any of hte other two fxp based servers, it works fine. > > Something, either the switch or the router, has a stale arp table entry. > It's a little curious that this ever works, without resetting whatever > it is. Perhaps the fxp's manage to send a gratuitous arp when taking > on a new alias. re: gratuitous arp ... I was wondering if the nics do anything like this, but, shouldn't be 'ping -S ' not "force" something? Like, I could see remote pings not being able to find their way, but sourcing one of the IP in question to go out, I would have thought it would have found its way ... Would the arp thing be nic based, or does the OS itself do it? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-net@FreeBSD.ORG Sun Jan 4 23:25:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 701C616A4CE for ; Sun, 4 Jan 2004 23:25:44 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2D4243D58 for ; Sun, 4 Jan 2004 23:25:20 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i057PIZv049938; Sun, 4 Jan 2004 23:25:18 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i057PGHZ049937; Sun, 4 Jan 2004 23:25:16 -0800 (PST) (envelope-from rizzo) Date: Sun, 4 Jan 2004 23:25:15 -0800 From: Luigi Rizzo To: "Marc G. Fournier" Message-ID: <20040104232515.A49878@xorpc.icir.org> References: <20040104162220.S28998@ganymede.hub.org> <20040104231252.GA71628@pit.databus.com> <20040104200204.V28998@ganymede.hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040104200204.V28998@ganymede.hub.org>; from scrappy@hub.org on Sun, Jan 04, 2004 at 08:04:34PM -0400 cc: Barney Wolff cc: freebsd-net@freebsd.org Subject: Re: Odd behaviour on em0 device in -stable ... I think ... 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, 05 Jan 2004 07:25:44 -0000 i am partly lost on the details of your specific question, but the symptoms do seem to suggest a stale ARP entry, which must be in the router (if the switch had a stale entry in its MAC forwarding table, you would have problems even with local pings, not only remote ones). It is the OS that generates a gratuitous ARP every time you assign an IP address (or alias) to a card, though i am not sure if it sends one for each address assigned to the card, or just one for the newly configured address -- the latter would not solve your problem. cheers luigi On Sun, Jan 04, 2004 at 08:04:34PM -0400, Marc G. Fournier wrote: > On Sun, 4 Jan 2004, Barney Wolff wrote: > > > On Sun, Jan 04, 2004 at 04:31:41PM -0400, Marc G. Fournier wrote: > > > > > > The problem is that I want to move an IP from one of the other servers > > > (all with fxp interfaces) over to the 4th, with the em device ... I -alias > > > the IP from the fxp device, and alias it over to the em device, and I can > > > no longer access it remotely ... > > > > > > If I alias it onto any of hte other two fxp based servers, it works fine. > > > > Something, either the switch or the router, has a stale arp table entry. > > It's a little curious that this ever works, without resetting whatever > > it is. Perhaps the fxp's manage to send a gratuitous arp when taking > > on a new alias. > > re: gratuitous arp ... I was wondering if the nics do anything like this, > but, shouldn't be 'ping -S ' not "force" something? > Like, I could see remote pings not being able to find their way, but > sourcing one of the IP in question to go out, I would have thought it > would have found its way ... > > Would the arp thing be nic based, or does the OS itself do it? > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 02:43:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17C7516A4CE for ; Mon, 5 Jan 2004 02:43:58 -0800 (PST) Received: from deliver.epitech.net (deliver.epitech.net [163.5.0.25]) by mx1.FreeBSD.org (Postfix) with SMTP id 4985643D1F for ; Mon, 5 Jan 2004 02:43:56 -0800 (PST) (envelope-from le-hen_j@epita.fr) Received: from epita.fr ([10.42.1.60]) by deliver.epitech.net (SAVSMTP 3.1.2.35) with SMTP id M2004010511424021295 ; Mon, 05 Jan 2004 11:42:40 +0100 Received: from carpediem (carpediem.epita.fr [10.42.42.5]) by epita.fr id i05Ahr827550 Mon, 5 Jan 2004 11:43:53 +0100 (CET) Date: Mon, 5 Jan 2004 11:43:51 +0100 From: Jeremie LE HEN To: "."@babolo.ru Message-ID: <20040105104351.GA2112@carpediem.epita.fr> References: <1073068183.380806.13522.nullmailer@cicuta.babolo.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1073068183.380806.13522.nullmailer@cicuta.babolo.ru> User-Agent: Mutt/1.4i cc: Stephane Raimbault cc: net@freebsd.org Subject: Re: VLAN MTU problem in 4.9 ? 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, 05 Jan 2004 10:43:58 -0000 > I know now, that xl interface can't pass 1504 frames > and most 1G interfaces can > don't know about another 100M interfaces Intel EtherExpress Pro/100 also supports it. I don't know if << Jumbo Frames >> are supported under FreeBSD with this network adapter, but it is under Linux with the driver developped by Intel (named "e100"). The old driver (named "eepro100") does not originally support Jumbo frames, but a minor modification can enable it. See http://www.softlab.ntua.gr/~afornaro/downloads/vlan-eepro.patch for more informations. Regards, -- Jeremie LE HEN aka TtZ/TataZ jeremie.le-hen@epita.fr ttz@epita.fr Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 02:48:13 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FACD16A4CE for ; Mon, 5 Jan 2004 02:48:13 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5046143D1F for ; Mon, 5 Jan 2004 02:48:11 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 64009 invoked from network); 5 Jan 2004 10:48:10 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 5 Jan 2004 10:48:10 -0000 Message-ID: <3FF940DD.19D6E577@pipeline.ch> Date: Mon, 05 Jan 2004 11:47:57 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeremie LE HEN References: <20040105104351.GA2112@carpediem.epita.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: "."@babolo.ru cc: Stephane Raimbault cc: net@freebsd.org Subject: Re: VLAN MTU problem in 4.9 ? 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, 05 Jan 2004 10:48:13 -0000 Jeremie LE HEN wrote: > > > I know now, that xl interface can't pass 1504 frames > > and most 1G interfaces can > > don't know about another 100M interfaces > > Intel EtherExpress Pro/100 also supports it. I don't know if << Jumbo > Frames >> are supported under FreeBSD with this network adapter, but it > is under Linux with the driver developped by Intel (named "e100"). The > old driver (named "eepro100") does not originally support Jumbo frames, > but a minor modification can enable it. > See http://www.softlab.ntua.gr/~afornaro/downloads/vlan-eepro.patch for > more informations. Be careful not to mix the term jumbo frames with the 4-byte addition for VLANs. Jumbo frames are frames which are something like 9000 bytes. To answer your question; the Intel Etherexpress Pro/100 as it is supported by the fxp driver accepts and sends the 4-byte VLAN enhanced ethernet frames. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 11:03:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9713916A4D1 for ; Mon, 5 Jan 2004 11:03:03 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3FD443D60 for ; Mon, 5 Jan 2004 11:01:39 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i05J1dFR016092 for ; Mon, 5 Jan 2004 11:01:39 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i05J1cLr016086 for freebsd-net@freebsd.org; Mon, 5 Jan 2004 11:01:38 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 5 Jan 2004 11:01:38 -0800 (PST) Message-Id: <200401051901.i05J1cLr016086@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2004 19:03:03 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 11:40:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36EEF16A4CE for ; Mon, 5 Jan 2004 11:40:22 -0800 (PST) Received: from ganymede.hub.org (u46n208.hfx.eastlink.ca [24.222.46.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F2F843D31 for ; Mon, 5 Jan 2004 11:40:21 -0800 (PST) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 5F41135E1F; Mon, 5 Jan 2004 15:36:43 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 4DF0D35C83; Mon, 5 Jan 2004 15:36:43 -0400 (AST) Date: Mon, 5 Jan 2004 15:36:43 -0400 (AST) From: "Marc G. Fournier" To: Luigi Rizzo In-Reply-To: <20040104232515.A49878@xorpc.icir.org> Message-ID: <20040105153544.W28998@ganymede.hub.org> References: <20040104162220.S28998@ganymede.hub.org> <20040104231252.GA71628@pit.databus.com> <20040104232515.A49878@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Barney Wolff cc: freebsd-net@freebsd.org Subject: Re: Odd behaviour on em0 device in -stable ... I think ... 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, 05 Jan 2004 19:40:22 -0000 On Sun, 4 Jan 2004, Luigi Rizzo wrote: > i am partly lost on the details of your specific question, but > the symptoms do seem to suggest a stale ARP entry, which must be > in the router (if the switch had a stale entry in its MAC forwarding > table, you would have problems even with local pings, not only > remote ones). > > It is the OS that generates a gratuitous ARP every time you assign > an IP address (or alias) to a card, though i am not sure if it > sends one for each address assigned to the card, or just one for the > newly configured address -- the latter would not solve your problem. One of the odd things I'm finding with the em0 device, over the fxp0 device on the other machines, is that if/when I do alias (or -alias), the network hangs for a couple of seconds, and the following gets generated in /var/log/messages: Jan 4 16:09:17 neptune /kernel: em0: Link is up 100 Mbps Full Duplex as if it brought the device down, and then back up again ... is that normal? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 11:55:05 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE6E116A4CE for ; Mon, 5 Jan 2004 11:55:05 -0800 (PST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B66343D2D for ; Mon, 5 Jan 2004 11:55:04 -0800 (PST) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.10/8.12.10) with ESMTP id i05Jt1cW087507; Mon, 5 Jan 2004 14:55:01 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.10/8.12.10/Submit) id i05Jt1Wj087506; Mon, 5 Jan 2004 14:55:01 -0500 (EST) (envelope-from barney) Date: Mon, 5 Jan 2004 14:55:01 -0500 From: Barney Wolff To: "Marc G. Fournier" Message-ID: <20040105195501.GA87471@pit.databus.com> References: <20040104162220.S28998@ganymede.hub.org> <20040104231252.GA71628@pit.databus.com> <20040104200204.V28998@ganymede.hub.org> <20040104232515.A49878@xorpc.icir.org> <20040105153544.W28998@ganymede.hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040105153544.W28998@ganymede.hub.org> User-Agent: Mutt/1.5.5.1i X-Scanned-By: MIMEDefang 2.39 cc: Barney Wolff cc: Luigi Rizzo cc: freebsd-net@freebsd.org Subject: Re: Odd behaviour on em0 device in -stable ... I think ... 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, 05 Jan 2004 19:55:06 -0000 On Mon, Jan 05, 2004 at 03:36:43PM -0400, Marc G. Fournier wrote: > > One of the odd things I'm finding with the em0 device, over the fxp0 > device on the other machines, is that if/when I do alias (or -alias), the > network hangs for a couple of seconds, and the following gets generated in > /var/log/messages: > > Jan 4 16:09:17 neptune /kernel: em0: Link is up 100 Mbps Full Duplex > > as if it brought the device down, and then back up again ... is that > normal? If by "normal" you meant do other people see the same, the answer is yes. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 15:33:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 923D316A4CE for ; Mon, 5 Jan 2004 15:33:55 -0800 (PST) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id C76B943D31 for ; Mon, 5 Jan 2004 15:33:43 -0800 (PST) (envelope-from alex@big.endian.de) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HR100BOTIS64Q@ms-dienst.rz.rwth-aachen.de> for freebsd-net@freebsd.org; Tue, 06 Jan 2004 00:33:42 +0100 (MET) Received: from relay.RWTH-Aachen.DE ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Tue, 06 Jan 2004 00:33:41 +0100 (MET) Received: from dustpuppy.kawo2.rwth-aachen.de (dustpuppy.kawo2.RWTH-Aachen.DE [134.130.180.5])i05NXfsU008514 for ; Tue, 06 Jan 2004 00:33:41 +0100 (MET) Received: from localhost (localhost [127.0.0.1])for ; Mon, 05 Jan 2004 17:42:17 +0100 (CET) Received: from fump.kawo2.rwth-aachen.de (fump.kawo2.rwth-aachen.de [134.130.181.148])409BB1FC0AB; Mon, 05 Jan 2004 17:42:17 +0100 (CET) Received: from fump.kawo2.rwth-aachen.defump.kawo2.rwth-aachen.de (8.12.10/8.12.10) with ESMTP id i05GgGK5012585; Mon, 05 Jan 2004 17:42:16 +0100 Received: (from alex@localhost) by fump.kawo2.rwth-aachen.de (8.12.10/8.12.10/Submit) id i05GgGHr012584; Mon, 05 Jan 2004 17:42:16 +0100 (CET envelope-from alex) Date: Mon, 05 Jan 2004 17:42:16 +0100 From: Alexander Langer In-reply-to: <05bc01c3c48f$d47cec30$02c0a8c0@gnbuero.qhintra.net> To: Markus Oestreicher Message-id: <20040105164216.GD9148@fump.kawo2.rwth-aachen.de> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.5.1i X-PGP-Fingerprint: 7EC1 5B98 4554 2A63 9079 2B2F 9A94 CD6F 7F14 EFA4 X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. X-Spam-Checker-Version: SpamAssassin 2.60-kawo2_dustpuppy_0.3 (1.212-2003-09-23-exp) on dustpuppy.kawo2.rwth-aachen.de X-Spam-Report: * -0.0 BAYES_44 BODY: Bayesian spam probability is 44 to 50% * [score: 0.4436] X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_44 autolearn=no version=2.60-kawo2_dustpuppy_0.3 X-Spam-Level: X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.16; AVE: 6.23.0.2; VDF: 6.23.0.25; host: dustpuppy.kawo2.rwth-aachen.de) References: <05bc01c3c48f$d47cec30$02c0a8c0@gnbuero.qhintra.net> cc: freebsd-net@freebsd.org Subject: Re: Polling CPU usage 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, 05 Jan 2004 23:33:55 -0000 Also sprach Markus Oestreicher (m.oe@x-trader.de): > Is there a way to get the real processor usage including > the time spent on polling? What machine do you use? When bridging approx. 25 MB/s (so 200 MBit/s; 1 MB of traffic roughly estimates to 1500 packets here) on a Duron 700 with ~2800 ipfw rules in polling mode, we have ~15.0 system load, so it might be your load is actually in fact so low ;) I once did a timed buildworld when the system was saturated like this, and compared to an almost idle CPU (in the night with < 100 kb/s) the build only took 5% longer or so. Alex From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 16:38:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CFEB16A4CE for ; Mon, 5 Jan 2004 16:38:08 -0800 (PST) Received: from mail.valuehost.co.uk (mail.valuehost.co.uk [62.25.99.6]) by mx1.FreeBSD.org (Postfix) with SMTP id B5E4F43D1F for ; Mon, 5 Jan 2004 16:38:06 -0800 (PST) (envelope-from bjorn@eikeland.info) Received: (qmail 59843 invoked by uid 89); 6 Jan 2004 00:37:50 +0000 Received: from unknown (HELO beer) (bjorn@eikeland.info@80.202.108.191) by mail.valuehost.co.uk with SMTP; 6 Jan 2004 00:37:50 +0000 Date: Tue, 06 Jan 2004 01:38:03 +0100 To: freebsd-net@freebsd.org From: Bjorn Eikeland Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera7.21/Win32 M2 build 3218 Subject: 5.1r Bridge with one ip - no access from non-ip side 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, 06 Jan 2004 00:38:09 -0000 Hi I've set up a bridge between the lan in my flat an my isp's adsl modem/nat router to shape traffic and also provide some services to both the lan and 'wan' side. current setup: router --- (xl0) bridge (fxp0) --- switch w/ clients 10.0.0.1 no-ip dhcp dhcp (10.0.0.2, 10.0.0.20-10.0.0.30) The bridge works for the clients and from the router to the clients. The fxp0 interface is configured by dhcp via the bridge, and later given a alias of 10.0.0.10 (just to have a fixed ip when switching between xl0 and fxp0 getting a ip assigned to it) so the fxp0 side is listening to the router when being configured, but not later. If I clear the arp entries (arp -da) and flush the routes (route flush) and ping the 10.0.0.1 router the arp entry is restored and a route is also put back. beerserver# arp 10.0.0.1 ? (10.0.0.1) at 00:00:c5:98:21:0c on fxp0 [ethernet] beerserver# netstat -rn Destination Gateway Flags Refs Use Netif Expire 10/24 link#2 UC 2 0 fxp0 10.0.0.1 00:00:c5:98:21:0c UHLW 0 2 fxp0 1186 10.0.0.2 00:a0:c9:f1:4e:6d UHLW 1 56 fxp0 1181 127.0.0.1 127.0.0.1 UH 0 0 lo0 Router pinging "bridge" (10.0.0.10): Tcpdump shows the packet arriving on xl0: 00:10:18.628986 10.0.0.1 > 10.0.0.10: icmp: echo request But it shows this on fxp0: 00:12:45.645646 arp who-has 10.0.0.10 tell 10.0.0.1 "Bridge" pinging router (10.0.0.1) Tcpdump shows packet leaving fxp0: 00:19:49.621531 10.0.0.10 > 10.0.0.1: icmp: echo request Tcpdump show reply comming back on xl0: 00:21:30.836404 10.0.0.10 > 10.0.0.1: icmp: echo request 00:21:30.836817 10.0.0.1 > 10.0.0.10: icmp: echo reply Just in case its a problem with the alias, I've tried only assigning 10.0.0.10 to fxp0, same result. The bridge is compiled into the kernel as I read the module had problems with this, but compiling it into the kernel did not solve my problem. (I've checked the module isnt loaded) Any suggestions? (Please ask if you need more info/configs) - Bjorn From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 17:23:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1869A16A4CE for ; Mon, 5 Jan 2004 17:23:38 -0800 (PST) Received: from swin.edu.au (c3p0.cc.swin.edu.au [136.186.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 560F843D31 for ; Mon, 5 Jan 2004 17:23:36 -0800 (PST) (envelope-from pvandenbergen@swin.edu.au) Received: from pvdbergen.caia.swin.edu.au (pvdbergen.caia.swin.edu.au [136.186.229.26]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id MAA800778; Tue, 6 Jan 2004 12:23:34 +1100 (EST) From: paul van den bergen To: freebsd-net@freebsd.org Date: Tue, 6 Jan 2004 12:16:47 +1100 User-Agent: KMail/1.5 Cc: freebsd-net@freebsd.org References: <200312151656.44591.pvandenbergen@swin.edu.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401061216.47187.pvandenbergen@swin.edu.au> Subject: Re: wireless monitoring of APs??? 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, 06 Jan 2004 01:23:38 -0000 On Mon, 15 Dec 2003 05:03 pm, Randy Bush wrote: > most APs have snmp sorry for the delayed response, I've been away :-) as usual, answers raise more questions... and another hole in my knowledge.... snmp = simple network management protocol, I presume, and allows network state data to be transported across the network. So how does this help me use the AP to monitor the network? as far as I can see I would need... 1) hardware/software on the AP to monitor the traffic and convert it to suitable snmp format packets and transmit on the wire. 2) software somewhere else that the AP can talk to that can interperete the snmp signals... I can imagine APs would have a variety of snmp capabilities, so this would essentially be model-specific. How about snmp information display programs for FreeBSD? -- Dr Paul van den Bergen Centre for Advanced Internet Architectures caia.swin.edu.au pvandenbergen@swin.edu.au IM:bulwynkl2002 "And some run up hill and down dale, knapping the chucky stones to pieces wi' hammers, like so many road makers run daft. They say it is to see how the world was made." Sir Walter Scott, St. Ronan's Well 1824 From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 19:40:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 033BF16A4CE for ; Mon, 5 Jan 2004 19:40:56 -0800 (PST) Received: from ganymede.hub.org (u46n208.hfx.eastlink.ca [24.222.46.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1655943D48 for ; Mon, 5 Jan 2004 19:40:55 -0800 (PST) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 7892B3536A; Mon, 5 Jan 2004 23:37:18 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 5C407347DD; Mon, 5 Jan 2004 23:37:18 -0400 (AST) Date: Mon, 5 Jan 2004 23:37:18 -0400 (AST) From: "Marc G. Fournier" To: Sreekanth In-Reply-To: <000001c3d3c6$d546d400$ae28a8c0@SREELAPTOP> Message-ID: <20040105233630.U28998@ganymede.hub.org> References: <000001c3d3c6$d546d400$ae28a8c0@SREELAPTOP> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: 'Barney Wolff' cc: 'Luigi Rizzo' cc: freebsd-net@freebsd.org Subject: RE: Odd behaviour on em0 device in -stable ... I think ... 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, 06 Jan 2004 03:40:56 -0000 On Mon, 5 Jan 2004, Sreekanth wrote: > The "Link is up" message can be explained by the fact the device is > reset everytime an alias is added or removed.Network hanging is > explained by the spanning tree protocol working(It prevents the port > from going into Forward state for around 20 seconds) is there a reason why the em driver does this, and the fxp doesn't? or, at least, why the em driver takes longer? it only appears to be the server with em devices that does it ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 19:43:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7FC816A4CE for ; Mon, 5 Jan 2004 19:43:26 -0800 (PST) Received: from ganymede.hub.org (u46n208.hfx.eastlink.ca [24.222.46.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id A07BE43D1F for ; Mon, 5 Jan 2004 19:43:25 -0800 (PST) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 486453536A; Mon, 5 Jan 2004 23:39:49 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 2D7F3347DD; Mon, 5 Jan 2004 23:39:49 -0400 (AST) Date: Mon, 5 Jan 2004 23:39:49 -0400 (AST) From: "Marc G. Fournier" To: Luigi Rizzo In-Reply-To: <20040104232515.A49878@xorpc.icir.org> Message-ID: <20040105233749.E28998@ganymede.hub.org> References: <20040104162220.S28998@ganymede.hub.org> <20040104231252.GA71628@pit.databus.com> <20040104232515.A49878@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Barney Wolff cc: freebsd-net@freebsd.org Subject: Re: Odd behaviour on em0 device in -stable ... I think ... 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, 06 Jan 2004 03:43:26 -0000 On Sun, 4 Jan 2004, Luigi Rizzo wrote: > It is the OS that generates a gratuitous ARP every time you assign an IP > address (or alias) to a card, though i am not sure if it sends one for > each address assigned to the card, or just one for the newly configured > address -- the latter would not solve your problem. Is there a way of doing this manually? man arp doesn't seem to indicate any way using that ... One thing I should note is that it *used* to do this ... the server has been up for 84 days now, but when first booted, I could add/remove pre-aliased IPs without this problem ... is there anything that maybe I should be checking before a reboot that may indicate an underlying problem? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 20:13:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 516DD16A4CE for ; Mon, 5 Jan 2004 20:13:31 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25B6743D1F for ; Mon, 5 Jan 2004 20:13:30 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id E341C654E1; Tue, 6 Jan 2004 04:13:28 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 80507-05; Tue, 6 Jan 2004 04:13:28 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id C3E60652FE; Tue, 6 Jan 2004 04:13:27 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 9BF35B7; Tue, 6 Jan 2004 04:13:26 +0000 (GMT) Date: Tue, 6 Jan 2004 04:13:26 +0000 From: Bruce M Simpson To: paul van den bergen Message-ID: <20040106041326.GB2084@saboteur.dek.spc.org> Mail-Followup-To: paul van den bergen , freebsd-net@freebsd.org References: <200312151656.44591.pvandenbergen@swin.edu.au> <200401061216.47187.pvandenbergen@swin.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401061216.47187.pvandenbergen@swin.edu.au> cc: freebsd-net@freebsd.org Subject: Re: wireless monitoring of APs??? 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, 06 Jan 2004 04:13:31 -0000 On Tue, Jan 06, 2004 at 12:16:47PM +1100, paul van den bergen wrote: > How about snmp information display programs for FreeBSD? I'm working on something like this. What exactly do you want to measure or monitor? BMS From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 20:36:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE65716A4CE for ; Mon, 5 Jan 2004 20:36:28 -0800 (PST) Received: from swin.edu.au (c3p0.cc.swin.edu.au [136.186.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id E21AB43D31 for ; Mon, 5 Jan 2004 20:36:26 -0800 (PST) (envelope-from pvandenbergen@swin.edu.au) Received: from pvdbergen.caia.swin.edu.au (pvdbergen.caia.swin.edu.au [136.186.229.26]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id PAA823473; Tue, 6 Jan 2004 15:35:40 +1100 (EST) From: paul van den bergen To: Bruce M Simpson Date: Tue, 6 Jan 2004 15:35:40 +1100 User-Agent: KMail/1.5 References: <200312151656.44591.pvandenbergen@swin.edu.au> <200401061216.47187.pvandenbergen@swin.edu.au> <20040106041326.GB2084@saboteur.dek.spc.org> In-Reply-To: <20040106041326.GB2084@saboteur.dek.spc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401061535.40356.pvandenbergen@swin.edu.au> cc: freebsd-net@freebsd.org Subject: Re: wireless monitoring of APs??? 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, 06 Jan 2004 04:36:28 -0000 On Tue, 6 Jan 2004 03:13 pm, you wrote: > On Tue, Jan 06, 2004 at 12:16:47PM +1100, paul van den bergen wrote: > > How about snmp information display programs for FreeBSD? > > I'm working on something like this. What exactly do you want to measure > or monitor? Ah! yes... see, now there is the rub ;-) I suppose it depends on your purpose. as a fuilly featured (IP) network tool you'd probably want some low level stats on the traffic. for a AP/wireless tool - well, what kismet or bsdairtools gives you. It would also depend on what the AP can gie you. If you can do accumulated statistics like moving averages of interpacket (frame?) arrival times, error rate, queue or buffer size, (being an indication of delay/saturation?), retransmittion delay, packet size... per traffic stream ;-0 OK ok, if one could just see what other devices were out there it would be a good start I suppose. -- Dr Paul van den Bergen Centre for Advanced Internet Architectures caia.swin.edu.au pvandenbergen@swin.edu.au IM:bulwynkl2002 "And some run up hill and down dale, knapping the chucky stones to pieces wi' hammers, like so many road makers run daft. They say it is to see how the world was made." Sir Walter Scott, St. Ronan's Well 1824 From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 20:41:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4601816A4CE for ; Mon, 5 Jan 2004 20:41:31 -0800 (PST) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA45443D1F for ; Mon, 5 Jan 2004 20:41:29 -0800 (PST) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (jc99mvjx@news1.macomnet.ru [195.128.64.14]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i064fRtn31451285; Tue, 6 Jan 2004 07:41:27 +0300 (MSK) Date: Tue, 6 Jan 2004 07:41:26 +0300 (MSK) From: Maxim Konovalov To: Bjorn Eikeland In-Reply-To: Message-ID: <20040106074051.O60614@news1.macomnet.ru> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: 5.1r Bridge with one ip - no access from non-ip side 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, 06 Jan 2004 04:41:31 -0000 Try sysctl net.inet.ip.check_interface=0. -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 20:49:09 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6C7616A4CE for ; Mon, 5 Jan 2004 20:49:09 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 919C343D55 for ; Mon, 5 Jan 2004 20:49:07 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id DBD3E654B1; Tue, 6 Jan 2004 04:49:05 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 80846-04; Tue, 6 Jan 2004 04:49:05 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id D817B654A9; Tue, 6 Jan 2004 04:49:04 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 67D02B7; Tue, 6 Jan 2004 04:49:03 +0000 (GMT) Date: Tue, 6 Jan 2004 04:49:03 +0000 From: Bruce M Simpson To: paul van den bergen Message-ID: <20040106044903.GC2084@saboteur.dek.spc.org> Mail-Followup-To: paul van den bergen , freebsd-net@freebsd.org References: <200312151656.44591.pvandenbergen@swin.edu.au> <200401061216.47187.pvandenbergen@swin.edu.au> <20040106041326.GB2084@saboteur.dek.spc.org> <200401061535.40356.pvandenbergen@swin.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401061535.40356.pvandenbergen@swin.edu.au> cc: freebsd-net@freebsd.org Subject: Re: wireless monitoring of APs??? 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, 06 Jan 2004 04:49:09 -0000 On Tue, Jan 06, 2004 at 03:35:40PM +1100, paul van den bergen wrote: > OK ok, if one could just see what other devices were out there it would be a > good start I suppose. I suggest you have a look at the WirelessLeiden and IEEE 802.11 MIBs. Some weeks ago I reviewed these for applicability to FreeBSD. My findings can be found here:- http://people.freebsd.org/~bms/dump/ieee-mib-freebsd-applicability.txt http://people.freebsd.org/~bms/dump/leiden-mib-freebsd-applicability.txt I haven't released my trafd/snmp code yet as it's unfinished. Many of the statistics you mention could be computed within the net80211 framework with some changes, although they sound more suited to the needs of network performance research within an academic context as opposed to the needs of Joe User, which has been my focus at this time. Some further work could be done in the area of presentation. Currently I use Cricket and rrdtool to produce time series graphs with a 4-minute average. Real-time monitoring and visualization tools are highly desirable. BMS From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 20:50:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47CDD16A4D0 for ; Mon, 5 Jan 2004 20:50:14 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D35B43D46 for ; Mon, 5 Jan 2004 20:50:12 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 69221 invoked from network); 6 Jan 2004 05:05:37 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 6 Jan 2004 05:05:37 -0000 Received: (nullmailer pid 32147 invoked by uid 136); Tue, 06 Jan 2004 04:50:08 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <3FF940DD.19D6E577@pipeline.ch> To: Andre Oppermann Date: Tue, 6 Jan 2004 07:50:08 +0300 (MSK) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1073364608.901196.32146.nullmailer@cicuta.babolo.ru> cc: "."@babolo.ru cc: Stephane Raimbault cc: net@freebsd.org Subject: Re: VLAN MTU problem in 4.9 ? 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, 06 Jan 2004 04:50:14 -0000 > To answer your question; the Intel Etherexpress Pro/100 as it is > supported by the fxp driver accepts and sends the 4-byte VLAN enhanced > ethernet frames. Do you know does dc driver accepts and sends the 4-byte VLAN enhanced ethernet frames? I have not this ethernet now to test but can change some of my xl's for dc in near future. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 00:02:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5725216A4CE for ; Tue, 6 Jan 2004 00:02:41 -0800 (PST) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D350D43D2F for ; Tue, 6 Jan 2004 00:02:39 -0800 (PST) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (9btc0i6c@news1.macomnet.ru [195.128.64.14]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i0682btn31583971; Tue, 6 Jan 2004 11:02:38 +0300 (MSK) Date: Tue, 6 Jan 2004 11:02:37 +0300 (MSK) From: Maxim Konovalov To: Bjorn Eikeland In-Reply-To: Message-ID: <20040106110122.T65251@news1.macomnet.ru> References: <20040106074051.O60614@news1.macomnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: 5.1r Bridge with one ip - no access from non-ip side - WORKS 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, 06 Jan 2004 08:02:41 -0000 On Tue, 6 Jan 2004, 06:33+0100, Bjorn Eikeland wrote: > P? Tue, 6 Jan 2004 07:41:26 +0300 (MSK), skrev Maxim Konovalov > : > > > Try sysctl net.inet.ip.check_interface=0. > > > > Well that did the trick! > Thank you very much! We really have to document that knob somewhere in bridge.4. -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 01:23:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C737F16A4CE for ; Tue, 6 Jan 2004 01:23:25 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0E6E43D48 for ; Tue, 6 Jan 2004 01:23:23 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id UAA05046; Tue, 6 Jan 2004 20:23:02 +1100 Date: Tue, 6 Jan 2004 20:23:01 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Alexander Langer In-Reply-To: <20040105164216.GD9148@fump.kawo2.rwth-aachen.de> Message-ID: <20040106200131.H3026@gamplex.bde.org> References: <05bc01c3c48f$d47cec30$02c0a8c0@gnbuero.qhintra.net> <20040105164216.GD9148@fump.kawo2.rwth-aachen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Polling CPU usage 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, 06 Jan 2004 09:23:25 -0000 On Mon, 5 Jan 2004, Alexander Langer wrote: > Also sprach Markus Oestreicher (m.oe@x-trader.de): > > > Is there a way to get the real processor usage including > > the time spent on polling? 1. No. 2. Use kernel profiling (preferably high resolution kernel profiling). Measurement will affect the usage significantly but it should be possible to get a good idea of the usage provided it is small. 3. Record timestamps on entry and exit in the profiling routines and analyze them. This is what high resolution kernel profiling does, except it records timestamps in _all_ routines and this costs more. 4. Use -current and put all the polling routines in low priority threads if they are not already (poll_idle already is, and it may be the most important one here -- in RELENG_4, the time spent doing work in the idle loop is counted as purely idle time and is indistinguishable from time spent doing nothing in the idle loop). This will also record timestamps on entry and exit to the profiling routines, but in a very inefficient way. > What machine do you use? > When bridging approx. 25 MB/s (so 200 MBit/s; 1 MB of traffic roughly > estimates to 1500 packets here) on a Duron 700 with ~2800 ipfw rules > in polling mode, we have ~15.0 system load, so it might be your load > is actually in fact so low ;) real/user/sys times don't give the overhead here, since most of it may be in "idle" time. > I once did a timed buildworld when the system was saturated like this, > and compared to an almost idle CPU (in the night with < 100 kb/s) the > build only took 5% longer or so. This is another way, but it will affect the usage a lot unless buildworld is your main application. buildworld should have no idle time on a perfectly tuned machine (with very fast disks), so polling should rarely occur in idle time. It will have to compete with buildworld and might end up not getting done, so all the network traffic might be handled at interrupt time. Bruce From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 02:07:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E17416A4D0 for ; Tue, 6 Jan 2004 02:07:23 -0800 (PST) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8A6243D45 for ; Tue, 6 Jan 2004 02:07:19 -0800 (PST) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i06A7HAB046422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Jan 2004 13:07:18 +0300 (MSK) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i06A7HlX046421 for net@freebsd.org; Tue, 6 Jan 2004 13:07:17 +0300 (MSK) Resent-From: Gleb Smirnoff Resent-Date: Tue, 6 Jan 2004 13:07:17 +0300 Resent-Message-ID: <20040106100717.GB46379@cell.sick.ru> Resent-To: net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B066516A4CE for ; Tue, 6 Jan 2004 02:05:20 -0800 (PST) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11CC743D2D for ; Tue, 6 Jan 2004 02:05:19 -0800 (PST) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i06A5GAB046405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Jan 2004 13:05:17 +0300 (MSK) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i06A5Gdn046404 for freeebsd-net@freebsd.org; Tue, 6 Jan 2004 13:05:16 +0300 (MSK) Date: Tue, 6 Jan 2004 13:05:15 +0300 From: Gleb Smirnoff To: freeebsd-net@freebsd.org Message-ID: <20040106100515.GA46379@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: splnet() and time slowing 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, 06 Jan 2004 10:07:23 -0000 I have a relatively loaded router with permanent load of ~ 200Kb/s. Its system time is a bit slowed down: Jan 6 10:45:30 gw-f ntpd[274]: time reset 4.212716 s Jan 6 11:00:52 gw-f ntpd[274]: time reset 3.682535 s Jan 6 11:15:50 gw-f ntpd[274]: time reset 2.881445 s Jan 6 11:32:42 gw-f ntpd[274]: time reset 3.130731 s Jan 6 11:49:26 gw-f ntpd[274]: time reset 2.999978 s It has some netgraph nodes with permanent traffic flow thru them. When I insert another node (which is considered to cause even more CPU load ), time I slowed down even more: Jan 6 12:04:39 gw-f ntpd[274]: time reset 16.165271 s Jan 6 12:20:20 gw-f ntpd[274]: time reset 27.880482 s Jan 6 12:37:30 gw-f ntpd[274]: time reset 30.759668 s Jan 6 12:53:19 gw-f ntpd[274]: time reset 27.591937 s Does this mean that spending much time at splnet() causes system clock to slow? Or may be the problem hides somwhere else? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 02:36:58 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BABD116A4CE for ; Tue, 6 Jan 2004 02:36:58 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DBF043D46 for ; Tue, 6 Jan 2004 02:36:57 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 35547 invoked from network); 6 Jan 2004 10:36:55 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for <.@babolo.ru>; 6 Jan 2004 10:36:55 -0000 Message-ID: <3FFA8FC7.D98BA8CE@freebsd.org> Date: Tue, 06 Jan 2004 11:36:55 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "."@babolo.ru References: <1073364608.901196.32146.nullmailer@cicuta.babolo.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: VLAN MTU problem in 4.9 ? 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, 06 Jan 2004 10:36:58 -0000 .@babolo.ru wrote: > > > To answer your question; the Intel Etherexpress Pro/100 as it is > > supported by the fxp driver accepts and sends the 4-byte VLAN enhanced > > ethernet frames. > > Do you know does dc driver accepts and sends the 4-byte VLAN enhanced > ethernet frames? The dc driver supports it. > I have not this ethernet now to test but can change > some of my xl's for dc in near future. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 13:20:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61F1716A4CE for ; Tue, 6 Jan 2004 13:20:26 -0800 (PST) Received: from mail.callcds.com (ip-66-129-110-166.name-host.com [66.129.110.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E86843D54 for ; Tue, 6 Jan 2004 13:20:24 -0800 (PST) (envelope-from tomt@callcds.com) Received: (qmail 7446 invoked from network); 6 Jan 2004 16:20:25 -0500 Received: from unknown (HELO mail.callcds.com) (127.0.0.1) by localhost.dns1.american-data.net with SMTP; 6 Jan 2004 16:20:25 -0500 Received: from 12.217.87.137 (SquirrelMail authenticated user tomt@callcds.com) by mail.callcds.com with HTTP; Tue, 6 Jan 2004 16:20:25 -0500 (EST) Message-ID: <38738.12.217.87.137.1073424025.squirrel@mail.callcds.com> Date: Tue, 6 Jan 2004 16:20:25 -0500 (EST) From: tomt@callcds.com To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: IPENCAP 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: Tue, 06 Jan 2004 21:20:26 -0000 The problem I have 5 buildings that are connected via point-to-point wireless. The cost of dedicated lines within this town were so high that wireless was an excellent option. The wireless is in place and working however we are going back to secure the wireless cloud so that it cannot be used by unauthorized people. The internet connection for all buildings is located at Building A so all machines need to route across the wireless to the internet. The solution 5 PCs running FreeBSD 5.1-Release using 2 network cards apiece and running IP-ENCAP between nodes with the tunnel being encrypted with IPSEC. Routing on each gateway that sends its traffic to the headend at Building A I have all this working except for this problem The PROBLEM Certain websites are not accessible sears.com msnbc.com microsoft.com drudgereport.com Other websites will work normally freebsd.org slashdot.org ebay.com What seems to be the problem Each of the websites that I listed have round-robin DNS enabled and have multiple A records for the website What I have done Recompile kernel back to GENERIC with options IPSEC options IPSEC_ESP options IPFIREWALL Disable IPSEC rc.conf ipsec_enable="NO" Open IPFW rules wide open firewall_enable="YES" firewall_type="OPEN" Summary I have slimed this configuration back to 2 machines(Building A and Building B) Building A External IP: 192.168.0.3/27 Internal IP: 10.114.252.1/22 Building B External IP: 192.168.0.6/27 Internal IP: 10.114.96.1/20 Removed IPSEC tunneling between machines now IP-ENCAP is the only thing that travels between machines. Opened the ruleset on both machines IPFW installation to OPEN Does anyone have any suggestions? Thanks Tom From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 14:04:31 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F37A916A4CE for ; Tue, 6 Jan 2004 14:04:30 -0800 (PST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ADEB43D2F for ; Tue, 6 Jan 2004 14:04:29 -0800 (PST) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.10/8.12.10) with ESMTP id i06M4PcW010169; Tue, 6 Jan 2004 17:04:26 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.10/8.12.10/Submit) id i06M3VGE010160; Tue, 6 Jan 2004 17:03:31 -0500 (EST) (envelope-from barney) Date: Tue, 6 Jan 2004 17:03:31 -0500 From: Barney Wolff To: tomt@callcds.com Message-ID: <20040106220331.GA10061@pit.databus.com> References: <38738.12.217.87.137.1073424025.squirrel@mail.callcds.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38738.12.217.87.137.1073424025.squirrel@mail.callcds.com> User-Agent: Mutt/1.5.5.1i X-Scanned-By: MIMEDefang 2.39 cc: freebsd-net@freebsd.org Subject: Re: IPENCAP 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: Tue, 06 Jan 2004 22:04:31 -0000 On Tue, Jan 06, 2004 at 04:20:25PM -0500, tomt@callcds.com wrote: > The problem > I have 5 buildings that are connected via point-to-point wireless. The > cost of dedicated lines within this town were so high that wireless was an > excellent option. The wireless is in place and working however we are > going back to secure the wireless cloud so that it cannot be used by > unauthorized people. The internet connection for all buildings is located > at Building A so all machines need to route across the wireless to the > internet. > > The solution > 5 PCs running FreeBSD 5.1-Release using 2 network cards apiece and running > IP-ENCAP between nodes with the tunnel being encrypted with IPSEC. > Routing on each gateway that sends its traffic to the headend at Building A > > I have all this working except for this problem > The PROBLEM > Certain websites are not accessible > sears.com > msnbc.com > microsoft.com > drudgereport.com > > Other websites will work normally > freebsd.org > slashdot.org > ebay.com > > What seems to be the problem > Each of the websites that I listed have round-robin DNS enabled and have > multiple A records for the website I'd suspect MTU issues rather than multiple A records. Try setting the MTU of the link to the Internet to 1400. If that works you can fine tune it. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 15:03:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA05E16A4CE for ; Tue, 6 Jan 2004 15:03:47 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6D8C43D46 for ; Tue, 6 Jan 2004 15:03:46 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id C1BB35C7D2; Tue, 6 Jan 2004 15:03:46 -0800 (PST) Date: Tue, 6 Jan 2004 15:03:46 -0800 From: Bill Fumerola To: Barney Wolff Message-ID: <20040106230346.GD40147@elvis.mu.org> References: <38738.12.217.87.137.1073424025.squirrel@mail.callcds.com> <20040106220331.GA10061@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040106220331.GA10061@pit.databus.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.9-MUORG-20031210 i386 cc: freebsd-net@freebsd.org cc: tomt@callcds.com Subject: Re: IPENCAP 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: Tue, 06 Jan 2004 23:03:47 -0000 On Tue, Jan 06, 2004 at 05:03:31PM -0500, Barney Wolff wrote: > I'd suspect MTU issues rather than multiple A records. Try setting the > MTU of the link to the Internet to 1400. If that works you can fine > tune it. i mailed the original author privately, but for the archive this is the most likely reason. msn/microsoft blocks icmp wholesale from their site and yahoo^Wfreebsd.org has no such filter. this would break pmtud. none of this belonged on -net, though... -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 15:30:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE27B16A579 for ; Tue, 6 Jan 2004 15:30:34 -0800 (PST) Received: from mailgw.servicefactory.se (mailgw.servicefactory.se [192.71.33.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD69743D64 for ; Tue, 6 Jan 2004 15:30:22 -0800 (PST) (envelope-from xfree@bulow.mine.nu) Received: from ark.servicefactory.se (ark.servicefactory.se [192.71.33.5]) i06NUKw22159 for ; Wed, 7 Jan 2004 00:30:20 +0100 (CET) Received: from bulow.mine.nu (ark.servicefactory.se [192.71.33.5]) by ark.servicefactory.se (8.12.9/8.12.6) with ESMTP id i06NTNmP000243 for ; Wed, 7 Jan 2004 00:29:23 +0100 (CET) (envelope-from xfree@bulow.mine.nu) Message-ID: <3FFB450A.6070403@bulow.mine.nu> Date: Wed, 07 Jan 2004 00:30:18 +0100 From: Jonas Bulow User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20031218 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: netgraph and kqueue together - socket 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: Tue, 06 Jan 2004 23:30:34 -0000 Hi, I'm trying to use netgraph and kqueue together and ran into some problems. I hope someone can enligthen me what I'm missing. I register EVFILT_READ and EVFILT_WRITE on a netgraph-socket connected to a netgraph echo-node. The EVFILT_WRITE-filter returns immediately from the kevent call saying there is 20480 bytes remaining in the write buffer (in the event data field). Then I write 20480 using NgSendData. NgSendData encounters an error: "No buffer space available". When I write fewer but smaller chunks of data, say ~3000 bytes, the next call to kevent returns the same amount of remaining space in the write buffer. The kqueue event data field never change from 20480 for the EVFILT_WRITE-filter. Now I understand that there are some overhead in the NgSendData. It's not just my data that are written through the socket. The addressing data adds some data when NgSendData calls sendto. Right? But, how do I calculate the true amount of remaining buffer space available for me when I call NgSendData? And, why does kevent EVFILT_WRITE always say 20480 on repeated calls to kevent on a netgraph-socket, even if I have successfully written some data between the calls to kevent? The netgraph-node the programming is talking to is a echo-node set up with: #ngctl mkpeer echo dummy foo Regards, Jonas From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 15:51:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 018BB16A4CE for ; Tue, 6 Jan 2004 15:51:34 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4377543D54 for ; Tue, 6 Jan 2004 15:50:42 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc11) with ESMTP id <2004010623503701100nep1de>; Tue, 6 Jan 2004 23:50:41 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA09581; Tue, 6 Jan 2004 15:50:35 -0800 (PST) Date: Tue, 6 Jan 2004 15:50:33 -0800 (PST) From: Julian Elischer To: Jonas Bulow In-Reply-To: <3FFB450A.6070403@bulow.mine.nu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: netgraph and kqueue together - socket 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: Tue, 06 Jan 2004 23:51:34 -0000 On Wed, 7 Jan 2004, Jonas Bulow wrote: > Hi, > > I'm trying to use netgraph and kqueue together and ran into some > problems. I hope someone can enligthen me what I'm missing. I'm not sure that anyone has ever looked at netgraph and kqueue as a pair. > > I register EVFILT_READ and EVFILT_WRITE on a netgraph-socket connected > to a netgraph echo-node. The EVFILT_WRITE-filter returns immediately > from the kevent call saying there is 20480 bytes remaining in the write > buffer (in the event data field). Then I write 20480 using NgSendData. > NgSendData encounters an error: "No buffer space available". WHat does it mean "write buffer"? The netgraph socket will pass th edat adirectly to whatever is connected. There is no buffer. The echo node in turn passes it back to the socket node (though there maybe a lock.. not sure) so eventually the data will be put in the receive buffer, so for this case the receive buffer is the send buffer but the socket can not know this.. > > When I write fewer but smaller chunks of data, say ~3000 bytes, the next > call to kevent returns the same amount of remaining space in the write > buffer. The kqueue event data field never change from 20480 for the > EVFILT_WRITE-filter. No it is returning some default value.. I doubt it is related in any way to much of importance. tell me, does a write of 20479 bytes work? > > Now I understand that there are some overhead in the NgSendData. It's > not just my data that are written through the socket. The addressing > data adds some data when NgSendData calls sendto. Right? > nope. that is out of band data.. I don't count that.. (I don't count anything really.). > But, how do I calculate the true amount of remaining buffer space > available for me when I call NgSendData? you can't.. there is no transmit buffer.. that is a reponsibility of the node that eventually decides to queue the data (maybe never). > > And, why does kevent EVFILT_WRITE always say 20480 on repeated calls to > kevent on a netgraph-socket, even if I have successfully written some > data between the calls to kevent? probably some default value. > > The netgraph-node the programming is talking to is a echo-node set up with: > > #ngctl mkpeer echo dummy foo > I suggest 'following' the data in the source code... starting in ng_socket.c start at: http://snapshots.jp.freebsd.org/tour/current/kernel/S/3328.html#338 for -current and: http://snapshots.jp.freebsd.org/tour/releng4/kernel/S/2566.html#182 for -stable. > Regards, > Jonas > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jan 6 23:05:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E72A116A4CE for ; Tue, 6 Jan 2004 23:05:45 -0800 (PST) Received: from mailgw.servicefactory.se (mailgw.servicefactory.se [192.71.33.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BE5B43D53 for ; Tue, 6 Jan 2004 23:05:43 -0800 (PST) (envelope-from xfree@bulow.mine.nu) Received: from ark.servicefactory.se (ark.servicefactory.se [192.71.33.5]) i0775fw26225; Wed, 7 Jan 2004 08:05:41 +0100 (CET) Received: from bulow.mine.nu (ark.servicefactory.se [192.71.33.5]) by ark.servicefactory.se (8.12.9/8.12.6) with ESMTP id i0774hmP015185; Wed, 7 Jan 2004 08:04:43 +0100 (CET) (envelope-from xfree@bulow.mine.nu) Message-ID: <3FFBAFB9.5060708@bulow.mine.nu> Date: Wed, 07 Jan 2004 08:05:29 +0100 From: Jonas Bulow User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20031218 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: netgraph and kqueue together - socket 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: Wed, 07 Jan 2004 07:05:46 -0000 Hi, Julian Elischer wrote: >On Wed, 7 Jan 2004, Jonas Bulow wrote: > > > >>Hi, >> >>I'm trying to use netgraph and kqueue together and ran into some >>problems. I hope someone can enligthen me what I'm missing. >> >> > >I'm not sure that anyone has ever looked at netgraph and kqueue as a >pair. > > > > > >>I register EVFILT_READ and EVFILT_WRITE on a netgraph-socket connected >>to a netgraph echo-node. The EVFILT_WRITE-filter returns immediately >>from the kevent call saying there is 20480 bytes remaining in the write >>buffer (in the event data field). Then I write 20480 using NgSendData. >>NgSendData encounters an error: "No buffer space available". >> >> > > > >WHat does it mean "write buffer"? > > I guess it is struct sockbuf sn_snd in struckt socket. >The netgraph socket will pass th edat adirectly to whatever is >connected. There is no buffer. >The echo node in turn passes it back to the socket node (though there >maybe a lock.. not sure) so eventually the data will be put in the >receive buffer, so for this case the receive buffer is the send buffer >but the socket can not know this.. > > > > > > > >>When I write fewer but smaller chunks of data, say ~3000 bytes, the next >>call to kevent returns the same amount of remaining space in the write >>buffer. The kqueue event data field never change from 20480 for the >>EVFILT_WRITE-filter. >> >> > >No it is returning some default value.. >I doubt it is related in any way to much of importance. > > > >tell me, does a write of 20479 bytes work? > > No, but 20473 works. The next call to kevent returns the constans 20480 again and the following NgSendData fails with the error above. > > > >>Now I understand that there are some overhead in the NgSendData. It's >>not just my data that are written through the socket. The addressing >>data adds some data when NgSendData calls sendto. Right? >> >> >> > >nope. >that is out of band data.. I don't count that.. (I don't count anything >really.). > > > > >>But, how do I calculate the true amount of remaining buffer space >>available for me when I call NgSendData? >> >> > >you can't.. there is no transmit buffer.. that is a reponsibility of the >node that eventually decides to queue the data (maybe never). > > > >>And, why does kevent EVFILT_WRITE always say 20480 on repeated calls to >>kevent on a netgraph-socket, even if I have successfully written some >>data between the calls to kevent? >> >> > >probably some default value. > > It seems to get it's value in kern/uipc_socket.c:filt_sowrite: ( -stable) kn->kn_data = sbspace(&so->so_snd); > > > >>The netgraph-node the programming is talking to is a echo-node set up with: >> >>#ngctl mkpeer echo dummy foo >> >> >> > >I suggest 'following' the data in the source code... > >starting in ng_socket.c >start at: > http://snapshots.jp.freebsd.org/tour/current/kernel/S/3328.html#338 >for -current and: > http://snapshots.jp.freebsd.org/tour/releng4/kernel/S/2566.html#182 >for -stable. > > Ok, I will do that. Isn't it kern/uipc_socket .c in sosend who is responsible for returning ENOBUFS in the first place when using the sendto that NgSendData uses? /j > > > > > >>Regards, >> Jonas >>_______________________________________________ >>freebsd-net@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-net >>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> > > > From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 04:23:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03EAA16A4CE for ; Wed, 7 Jan 2004 04:23:37 -0800 (PST) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B6C943D2D for ; Wed, 7 Jan 2004 04:23:32 -0800 (PST) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.2) with SMTP id XAA07244; Wed, 7 Jan 2004 23:23:13 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 7 Jan 2004 23:23:12 +1100 (EST) From: Ian Smith To: Maxim Konovalov In-Reply-To: <20040106110122.T65251@news1.macomnet.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Bjorn Eikeland cc: net@freebsd.org Subject: Re: 5.1r Bridge with one ip - no access from non-ip side - WORKS 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, 07 Jan 2004 12:23:37 -0000 On Tue, 6 Jan 2004, Maxim Konovalov wrote: > On Tue, 6 Jan 2004, 06:33+0100, Bjorn Eikeland wrote: > > > P? Tue, 6 Jan 2004 07:41:26 +0300 (MSK), skrev Maxim Konovalov > > : > > > > > Try sysctl net.inet.ip.check_interface=0. > > > > > > > Well that did the trick! > > Thank you very much! > > We really have to document that knob somewhere in bridge.4. I thought this might affect my problem with a very similar setup that I reported in some detail the other day, re the bridge not seeing (or not taking notice of, at least) rwho UDP 113 packets to the subnet broadcast address on the non-IP interface from hosts 'outside', but on checking, that knob was already set to 0 by default (4.8-RELEASE + BRIDGE kernel). Setting this to 1 did indeed kill connectivity (ping) on the unnumbered interface. I wonder why your system would default to 1 on that knob? In chasing this I've tried fiddling with several knobs, most recently net.link.ether.inet.proxyall=1 (guesswork!), and have tried creating an extra arp entry for the MAC address of the non-IP outside interface (pub and pub only) but these always get stored with the MAC of the inside interface, ie that with the IP assigned, despite specifying the other. I'm not sure if our problem is to do with arp at all, or with processing broadcast packets received on the non-IP interface, or what. I can live with rwho/ruptime only half-working on this box (ie for 'inside' boxes), but I do wonder whether protocols other than rwho using UDP broadcasts (such as ..?) might have the same problem? Anyway, the consequence is that the bridge box is the only one that won't report on rwho/ruptime for the (single) box on the unnumbered (outside) interface. Guess I could bring it up to -STABLE if anyone knows of bridge changes? Chees, Ian From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 06:39:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE49516A4CE for ; Wed, 7 Jan 2004 06:39:53 -0800 (PST) Received: from deliver.epitech.net (deliver.epitech.net [163.5.0.25]) by mx1.FreeBSD.org (Postfix) with SMTP id E388C43D48 for ; Wed, 7 Jan 2004 06:39:51 -0800 (PST) (envelope-from le-hen_j@epita.fr) Received: from epita.fr ([10.42.1.60]) by deliver.epitech.net (SAVSMTP 3.1.2.35) with SMTP id M2004010715383318901 ; Wed, 07 Jan 2004 15:38:33 +0100 Received: from carpediem (carpediem.epita.fr [10.42.42.5]) by epita.fr id i07EdmI11248 Wed, 7 Jan 2004 15:39:48 +0100 (CET) Date: Wed, 7 Jan 2004 15:39:48 +0100 From: jeremie le-hen To: "Jukka A. Ukkonen" , freebsd-net@freebsd.org Message-ID: <20040107143948.GA10051@carpediem.epita.fr> References: <200312031823.hB3INa5j013485@cs78135006.pp.htv.fi> <20031203184153.GC56046@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031203184153.GC56046@saboteur.dek.spc.org> User-Agent: Mutt/1.4i Subject: Re: Driver for D-Link DWL-G520+ ?? 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, 07 Jan 2004 14:39:53 -0000 > On Wed, Dec 03, 2003 at 08:23:36PM +0200, Jukka A. Ukkonen wrote: > > Is there anyone writing a driver for a D-Link DWL-G520+ card > > (apparently prism54)? > > I know a chap (local to me) working on such a thing:- http://wlan.kewl.org/ I have the same PCI wireless card. It seems that buying a D-Link card is a kind of lottery : depending on a few numbers near the barcode, you may have either some chipset or another from a different manufacturer... Since I'm not a lucky guy, I didn't get the one working with the ath(4) driver (Atheros), but instead I got the one which seems to have a Texas Intrument chipset which is not officially supported by FreeBSD yet. I tried the driver acx(4) driver from the given URL, but it doesn't work. The module is successfully loaded but no device is probed. Before I bring back my card to the shop, does anyone succeed in using using this card (with this chipset of course) ? Thanks in advance, -- Jeremie LE HEN aka TtZ/TataZ jeremie.le-hen@epita.fr ttz@epita.fr Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 07:07:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08FCC16A4CE for ; Wed, 7 Jan 2004 07:07:54 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C6F043D2F for ; Wed, 7 Jan 2004 07:07:52 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 164956548D; Wed, 7 Jan 2004 15:07:50 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 99505-01; Wed, 7 Jan 2004 15:07:49 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id C99DB652EC; Wed, 7 Jan 2004 15:07:46 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 87A7426; Wed, 7 Jan 2004 15:07:45 +0000 (GMT) Date: Wed, 7 Jan 2004 15:07:45 +0000 From: Bruce M Simpson To: jeremie le-hen Message-ID: <20040107150745.GB9601@saboteur.dek.spc.org> Mail-Followup-To: jeremie le-hen , "Jukka A. Ukkonen" , freebsd-net@freebsd.org References: <200312031823.hB3INa5j013485@cs78135006.pp.htv.fi> <20031203184153.GC56046@saboteur.dek.spc.org> <20040107143948.GA10051@carpediem.epita.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040107143948.GA10051@carpediem.epita.fr> cc: "Jukka A. Ukkonen" cc: freebsd-net@freebsd.org Subject: Re: Driver for D-Link DWL-G520+ ?? 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, 07 Jan 2004 15:07:54 -0000 On Wed, Jan 07, 2004 at 03:39:48PM +0100, jeremie le-hen wrote: > Since I'm not a lucky guy, I didn't get the one working with the ath(4) > driver (Atheros), but instead I got the one which seems to have a > Texas Intrument chipset which is not officially supported by FreeBSD > yet. I tried the driver acx(4) driver from the given URL, but it > doesn't work. The module is successfully loaded but no device is > probed. Before I bring back my card to the shop, does anyone succeed > in using using this card (with this chipset of course) ? I was able to associate to local APs and use normal IP services with Darron's latest snapshot, which I've been discussing with Warner about importing into FreeBSD proper with some changes. BMS From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 07:29:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCBA516A4CE for ; Wed, 7 Jan 2004 07:29:20 -0800 (PST) Received: from diaspar.rdsnet.ro (diaspar.rdsnet.ro [213.157.165.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 135C043D54 for ; Wed, 7 Jan 2004 07:29:19 -0800 (PST) (envelope-from dudu@diaspar.rdsnet.ro) Received: (qmail 53433 invoked by uid 89); 7 Jan 2004 15:29:25 -0000 Received: from unknown (HELO diaspar.rdsnet.ro) (dudu@diaspar.rdsnet.ro@213.157.165.224) by 0 with AES256-SHA encrypted SMTP; 7 Jan 2004 15:29:25 -0000 Date: Wed, 7 Jan 2004 17:29:24 +0200 From: Vlad Galu To: freebsd-net@freebsd.org Message-Id: <20040107172924.609eeed2.dudu@diaspar.rdsnet.ro> X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Wed__7_Jan_2004_17_29_24_+0200_zD8HOR+vsC+twjBm" Subject: IP stack peculiarity 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, 07 Jan 2004 15:29:21 -0000 --Signature=_Wed__7_Jan_2004_17_29_24_+0200_zD8HOR+vsC+twjBm Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi guys. I have the following setup: one FreeBSD box with a public IP, routed by a Linux machine which has the default route on another ISP than the one my FreeBSD box's IP belongs to. Shortly said, I have different up/downstream channels. The problem appears when during a TCP connection the FreeBSD machine. The 3-way handshake works smoothly, but soon the connection stalls. I tcpdump-ed it on both streams(upwards and downwards) and I see nothing but ACK's, some of them with the PUSH bit set (this is common for webservers). There's no retransmission. The packets just stop being sent from my FreeBSD machine. Eventually, the connection times out. Has anyone encountered this type of situation before ? I could paste some tcpdump output if necessary, but I thought to ask first. I only have one interface, so reverse patch checking issues don't have place here. Thanks in advance for any help. ---- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. --Signature=_Wed__7_Jan_2004_17_29_24_+0200_zD8HOR+vsC+twjBm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQE//CXUP5WtpVOrzpcRAlGDAJ9Tp/MsBsp6rJenI3TY7fmliTabfwCgktkS RUxUKYQA2LXWYKMFdUpEC2s= =Wbsw -----END PGP SIGNATURE----- --Signature=_Wed__7_Jan_2004_17_29_24_+0200_zD8HOR+vsC+twjBm-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 11:48:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8423716A4CE for ; Wed, 7 Jan 2004 11:48:35 -0800 (PST) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7D0043D49 for ; Wed, 7 Jan 2004 11:48:33 -0800 (PST) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i07JmTAB051472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2004 22:48:29 +0300 (MSK) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i07JmTWI051471; Wed, 7 Jan 2004 22:48:29 +0300 (MSK) Date: Wed, 7 Jan 2004 22:48:28 +0300 From: Gleb Smirnoff To: Vlad Galu Message-ID: <20040107194828.GB51373@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Vlad Galu , freebsd-net@freebsd.org References: <20040107172924.609eeed2.dudu@diaspar.rdsnet.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040107172924.609eeed2.dudu@diaspar.rdsnet.ro> User-Agent: Mutt/1.5.4i cc: freebsd-net@freebsd.org Subject: Re: IP stack peculiarity 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, 07 Jan 2004 19:48:35 -0000 On Wed, Jan 07, 2004 at 05:29:24PM +0200, Vlad Galu wrote: V> The problem appears when during a TCP connection the FreeBSD machine. V> The 3-way handshake works smoothly, but soon the connection stalls. I V> tcpdump-ed it on both streams(upwards and downwards) and I see nothing V> but ACK's, some of them with the PUSH bit set (this is common for V> webservers). There's no retransmission. The packets just stop being sent V> from my FreeBSD machine. Eventually, the connection times out. Can you provide tcpdump output on this host, and tcpdump on remote host in the Internet, the one you are connecting to? Analyzing this two dumps will help a lot. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 12:15:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3C1216A4CE for ; Wed, 7 Jan 2004 12:15:47 -0800 (PST) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2BDC43D39 for ; Wed, 7 Jan 2004 12:15:46 -0800 (PST) (envelope-from adam.mclaurin@gmx.net) Received: from 146-115-126-186.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com ([146.115.126.186] helo=jake) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.35 #4) id 1AeK5h-0006u4-00 for freebsd-net@freebsd.org; Wed, 07 Jan 2004 15:15:45 -0500 Date: Wed, 7 Jan 2004 15:15:44 -0500 From: Adam McLaurin To: freebsd-net@freebsd.org Message-Id: <20040107151544.6bbab003.adam.mclaurin@gmx.net> Organization: X-Mailer: Sylpheed version 0.9.5-gtk2-20030906 (GTK+ 2.2.4; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Intermittent problems with LAN transfer speeds 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, 07 Jan 2004 20:15:47 -0000 Since I first installed FreeBSD 2 years ago, I have intermittent problems with my LAN transfer speeds. It doesn't happen often, but when it does, I've not found any solution other than rebooting the server. My network configuration looks like this: cable modem --> freebsd 5.1-R --> dlink switch --> win2k workstation I normally get appx 10MB/s between my two machines. However, occasionally I'll fire up a transfer and only get 50-200KB/s, which is really awful. I've tried rebooting the Win2k machine, disconnecting the ethernet cables, even power cycling the switch; nothing helps. The only thing that seems to help is rebooting the server, which I really hate to do. I originally had a 3Com card serving the internal network, then I switched to a Linksys, and now I've got an Intel in there. All 3 have given me the exact same intermittent problems. I've seen this on FreeBSD 4.7, 4.8, 4.9, 5.0, and 5.1. There is no one else on the LAN but me, so it's not a matter of some goof misbehaving himself. I'm really baffled here. Here's the output of ifconfig: -$ ifconfig fxp0: flags=8843 mtu 1500 options=3 inet 192.168.56.2 netmask 0xffffff00 broadcast 192.168.56.255 ether 00:02:b3:a8:1d:19 media: Ethernet 100baseTX status: active dc0: flags=8843 mtu 1500 inet 146.115.***.*** netmask 0xffffff00 broadcast 255.255.255.255 ether 00:04:5a:7b:a7:d0 media: Ethernet autoselect (100baseTX ) status: active lp0: flags=8810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 Both the gateway's NIC and the workstations NIC are manually set to 100Mbit full-duplex. Anyone have any ideas? I'm running ipf+ipnat, if it matters. Thanks. -- Adam McLaurin P.S. Please CC your reply to me; I'm not currently subscribed to this list. From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 12:23:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 468B216A4CE for ; Wed, 7 Jan 2004 12:23:36 -0800 (PST) Received: from starburst.demon.co.uk (adsl-02-230.abel.net.uk [193.109.51.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DD6B43D2D for ; Wed, 7 Jan 2004 12:23:33 -0800 (PST) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id UAA18922 for freebsd-net@freebsd.org; Wed, 7 Jan 2004 20:23:48 GMT From: Richard Wendland Message-Id: <200401072023.UAA18922@starburst.demon.co.uk> To: freebsd-net@freebsd.org Date: Wed, 7 Jan 2004 20:23:47 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: kern/60889 - zero IP id change issues in 5.2RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rw@codeburst.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2004 20:23:36 -0000 I've been asked (for freebsd-bugs) to open a discussion about PR kern/60889 on freebsd-net, to decide if a recent change to IP should be reversed before 5.2-RELEASE (scheduled this month) to give more time for some serious issues and risks my PR has raised to be considered and tested. My proposal is to revert to 5.1 behaviour for now. The recent change is to emit a zero fragmentation id when DF is set, with the objective of improving privacy from external id sequence observation, an issue raised by Steve Bellovin's paper in IMW'02. I've identified 4 problems with this change: 1) Even with path_mtu_discovery set, for some reason TCP emits FIN-ACK without DF. This causes two problems for this change: a) Currently the change doesn't really meet its objective for TCP, it just means FIN-ACK must be observed. b) Because now just one id is consumed per TCP connection on the FIN-ACK, for most/many systems id becomes a close approximate count of the number of TCP connections it has made, which external observers can see, not possible before this change. To me this seems more of a privacy issue for all FreeBSD users than the NAT issue in Steve Bellovin's paper this change seeks to solve. 2) Linux made exactly this change some time ago, around Linux 2.4.4, but was forced to back-out the change because (I think) of practical connectivity issues related to the comment in include/net/ip.h ip_select_ident() where it now implements an incrementing ip_id for DF: /* This is only to work around buggy Windows95/2000 * VJ compression implementations. If the ID field * does not change, they drop every other packet in * a TCP stream using header compression. */ I'm not aware that anyone checked that this buggy Windows95/2000 VJ compression problem is no longer an issue in practice. I doubt that the large web hosters who use FreeBSD would be best-pleased if they ran into this for even just a few users - especially as there is no config option to disable this change. 3) This change causes ip_id for non-DF to be output in native byte order in ip_output.c. Unfortunately ip_id is still output in Network Byte Order in ip_mroute.c and raw_ip.c, so this change risks little-endian machines emitting the same fragmentation id at about the same time from these different modules, rather than the usual 64k cycle; creating a small but real risk of re-assembly errors. [This isn't in my PR, I've only just noticed it.] I also have a suspicion that some middle-boxes (like HTTP load-balancers) may clear DF without setting a fresh IP id - clearing DF would save them the bother of routing ICMP fragmentation needed back to the source server. If this is so this is another problem this change could show up which may cause re-assembly errors. I know the bug is elsewhere, but it would still become a practical problem for some FreeBSD users. So before going with this change I think four things need to be done: 1) TCP changed so FIN-ACK goes out with DF if path_mtu_discovery set. 2) Tests with Windows95/2000 TCP VJ compression (RFC1144) run. 3) ip_id should be emitted in the same byte order everywhere. 4) The change made a config option, so sites can disable it should they run into problems, just as RANDOM_IP_ID is an option. This all seems too much to do for 5.2-RELEASE, and as I think the problems and risks sufficiently serious, I propose reversing the change until this can be done. We need a quick decision on this to get it into 5.2-RELEASE. The PR has some more detail and tcpdump output demonstrating the issue: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60889 The change to be reversed can be seen at: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c#rev1.189 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1=1.188&r2=1.189 NB If anyone can easily run tests with Windows95/2000 TCP VJ compression that would be great (using tcpdump to see if there is abnormal retransmission). NB2 If anyone knows why FIN-ACK goes out without DF that would be helpful. I've quickly looked at the source, and I can't see why. It's emitted as TCP moves from FIN_WAIT_n state to TIME_WAIT probably at line 3091 of tcp_input.c with a call to tcp_output(). tcp_output() always appears to set IP_DF at line 998 of tcp_output.c, if path_mtu_discovery is enabled. A puzzle. Thanks to Boris Staeblow and Tim Rylance for highlighting this change and helping me diagnose the issues. Richard -- Richard Wendland richard@wendland.org.uk From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 12:36:07 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F62016A4CE for ; Wed, 7 Jan 2004 12:36:07 -0800 (PST) Received: from wbm4.pair.net (wbm4.pair.net [209.68.3.85]) by mx1.FreeBSD.org (Postfix) with SMTP id B157043D46 for ; Wed, 7 Jan 2004 12:36:04 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 50219 invoked by uid 65534); 7 Jan 2004 20:36:03 -0000 Received: from 158.6.15.27 ([158.6.15.27]) (SquirrelMail authenticated user silby@silby.com) by webmail.pair.com with HTTP; Wed, 7 Jan 2004 15:36:03 -0500 (EST) Message-ID: <54100.158.6.15.27.1073507763.squirrel@webmail.pair.com> Date: Wed, 7 Jan 2004 15:36:03 -0500 (EST) From: To: X-pair-Authenticated: 158.6.15.27 In-Reply-To: <200401072023.UAA18922@starburst.demon.co.uk> References: <200401072023.UAA18922@starburst.demon.co.uk> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: richard@starburst.demon.co.uk Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 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, 07 Jan 2004 20:36:07 -0000 Good analysis, I don't believe that any of us had heard of these issues. Rolling it back for 5.2-release makes sense to me, but I think we should leave it alone in -current and work through the problems. I'm out of town without a way to commit, so it'd be best if some other developer can talk to re@ and make this happen. Mike "Silby" Silbersack > I've been asked (for freebsd-bugs) to open a discussion about PR > kern/60889 on freebsd-net, to decide if a recent change to IP should be > reversed before 5.2-RELEASE (scheduled this month) to give more time for > some serious issues and risks my PR has raised to be considered and > tested. My proposal is to revert to 5.1 behaviour for now. > > The recent change is to emit a zero fragmentation id when DF is set, > with the objective of improving privacy from external id sequence > observation, an issue raised by Steve Bellovin's paper in IMW'02. > > I've identified 4 problems with this change: > > 1) Even with path_mtu_discovery set, for some reason TCP emits FIN-ACK > without DF. This causes two problems for this change: > > a) Currently the change doesn't really meet its objective for TCP, > it just means FIN-ACK must be observed. > > b) Because now just one id is consumed per TCP connection on the > FIN-ACK, for most/many systems id becomes a close approximate > count of the number of TCP connections it has made, which external > observers can see, not possible before this change. To me this > seems more of a privacy issue for all FreeBSD users than the NAT > issue in Steve Bellovin's paper this change seeks to solve. > > 2) Linux made exactly this change some time ago, around Linux 2.4.4, > but was forced to back-out the change because (I think) of practical > connectivity issues related to the comment in include/net/ip.h > ip_select_ident() where it now implements an incrementing ip_id for > DF: > > /* This is only to work around buggy Windows95/2000 > * VJ compression implementations. If the ID field > * does not change, they drop every other packet in > * a TCP stream using header compression. > */ > > I'm not aware that anyone checked that this buggy Windows95/2000 VJ > compression problem is no longer an issue in practice. I doubt that > the large web hosters who use FreeBSD would be best-pleased if they > ran into this for even just a few users - especially as there is no > config option to disable this change. > > 3) This change causes ip_id for non-DF to be output in native > byte order in ip_output.c. Unfortunately ip_id is still output in > Network Byte Order in ip_mroute.c and raw_ip.c, so this change risks > little-endian machines emitting the same fragmentation id at about > the same time from these different modules, rather than the usual 64k > cycle; creating a small but real risk of re-assembly errors. [This > isn't in my PR, I've only just noticed it.] > > I also have a suspicion that some middle-boxes (like HTTP > load-balancers) may clear DF without setting a fresh IP id - clearing DF > would save them the bother of routing ICMP fragmentation needed back to > the source server. If this is so this is another problem this change > could show up which may cause re-assembly errors. I know the bug is > elsewhere, but it would still become a practical problem for some > FreeBSD users. > > So before going with this change I think four things need to be done: > > 1) TCP changed so FIN-ACK goes out with DF if path_mtu_discovery set. > > 2) Tests with Windows95/2000 TCP VJ compression (RFC1144) run. > > 3) ip_id should be emitted in the same byte order everywhere. > > 4) The change made a config option, so sites can disable it should > they run into problems, just as RANDOM_IP_ID is an option. > > This all seems too much to do for 5.2-RELEASE, and as I think the > problems and risks sufficiently serious, I propose reversing the change > until this can be done. We need a quick decision on this to get it into > 5.2-RELEASE. > > The PR has some more detail and tcpdump output demonstrating the > issue: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60889 > > The change to be reversed can be seen at: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c#rev1.189 > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1=1.188&r2=1.189 > > NB If anyone can easily run tests with Windows95/2000 TCP VJ compression > that would be great (using tcpdump to see if there is abnormal > retransmission). > > NB2 If anyone knows why FIN-ACK goes out without DF that would be > helpful. I've quickly looked at the source, and I can't see why. It's > emitted as TCP moves from FIN_WAIT_n state to TIME_WAIT probably at line > 3091 of tcp_input.c with a call to tcp_output(). tcp_output() always > appears to set IP_DF at line 998 of tcp_output.c, if path_mtu_discovery > is enabled. A puzzle. > > Thanks to Boris Staeblow and Tim Rylance > for highlighting this change and helping me > diagnose the issues. > > Richard > -- > Richard Wendland richard@wendland.org.uk > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 14:48:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58DF316A4CE for ; Wed, 7 Jan 2004 14:48:35 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03A1643D55 for ; Wed, 7 Jan 2004 14:48:32 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 13351 invoked from network); 7 Jan 2004 22:48:30 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 7 Jan 2004 22:48:30 -0000 Message-ID: <3FFC8CBE.13B527A3@freebsd.org> Date: Wed, 07 Jan 2004 23:48:30 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rw@codeburst.co.uk References: <200401072023.UAA18922@starburst.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 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, 07 Jan 2004 22:48:35 -0000 Richard, I've attached a patch that fixes the problem with FIN/ACK and one more case which got it wrong. I also fixed the host byte order problem in ip_output.c for the normal ip_id incrementor. Some comments and questions: 1. Do you think it is neccessary to do a htons() on the randomized ip_id too? I'd say yes if there is a case where it has to monotonically increase afterwards. Does it? 2. I have a Win2k machine but have check out how I can get tcp header compression to work with my Cisco AS5300 (if it doesn't do that by default). Will I see the problem when I do a download from a FreeBSD 5.2RC2 machine or do I have to use the Windoze as router sending packets upwards?` 3. There are indeed devices clearing the DF bit. For example Cisco is recommending this in it's trouble shooting section for broadband access via DSL/L2TP where the MTU is lower than 1500 because of the tunnelling overhead. Make a route-map to unset the DF bit and apply it to the incoming interface. If these questions are answered I can prepare the final patch and commit it pending review and re@ approval. -- Andre (Note: tabs converted to whitespace because of c&p) Index: ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.203 diff -u -p -r1.203 ip_output.c --- ip_output.c 20 Nov 2003 20:07:38 -0000 1.203 +++ ip_output.c 7 Jan 2004 22:43:54 -0000 @@ -246,7 +246,7 @@ ip_output(struct mbuf *m0, struct mbuf * #ifdef RANDOM_IP_ID ip->ip_id = ip_randomid(); #else - ip->ip_id = ip_id++; + ip->ip_id = htons(ip_id++); #endif } else { ip->ip_off = IP_DF; Index: tcp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.172 diff -u -p -r1.172 tcp_subr.c --- tcp_subr.c 6 Jan 2004 23:29:46 -0000 1.172 +++ tcp_subr.c 7 Jan 2004 22:43:55 -0000 @@ -459,6 +459,8 @@ tcp_respond(tp, ipgen, th, m, ack, seq, tlen += sizeof (struct tcpiphdr); ip->ip_len = tlen; ip->ip_ttl = ip_defttl; + if (path_mtu_discovery) + ip->ip_off |= IP_DF; } m->m_len = tlen; m->m_pkthdr.len = tlen; @@ -1733,6 +1735,8 @@ tcp_twrespond(struct tcptw *tw, struct s m->m_pkthdr.csum_flags = CSUM_TCP; m->m_pkthdr.csum_data = offsetof(struct tcphdr, th_sum); ip->ip_len = m->m_pkthdr.len; + if (path_mtu_discovery) + ip->ip_off |= IP_DF; error = ip_output(m, inp->inp_options, NULL, (tw->tw_so_options & SO_DONTROUTE), NULL, inp); } Richard Wendland wrote: > > I've been asked (for freebsd-bugs) to open a discussion about PR > kern/60889 on freebsd-net, to decide if a recent change to IP should be > reversed before 5.2-RELEASE (scheduled this month) to give more time > for some serious issues and risks my PR has raised to be considered > and tested. My proposal is to revert to 5.1 behaviour for now. > > The recent change is to emit a zero fragmentation id when DF is set, with > the objective of improving privacy from external id sequence observation, > an issue raised by Steve Bellovin's paper in IMW'02. > > I've identified 4 problems with this change: > > 1) Even with path_mtu_discovery set, for some reason TCP emits FIN-ACK > without DF. This causes two problems for this change: > > a) Currently the change doesn't really meet its objective for TCP, > it just means FIN-ACK must be observed. > > b) Because now just one id is consumed per TCP connection on the > FIN-ACK, for most/many systems id becomes a close approximate > count of the number of TCP connections it has made, which external > observers can see, not possible before this change. To me this > seems more of a privacy issue for all FreeBSD users than the NAT > issue in Steve Bellovin's paper this change seeks to solve. > > 2) Linux made exactly this change some time ago, around Linux 2.4.4, > but was forced to back-out the change because (I think) of practical > connectivity issues related to the comment in include/net/ip.h > ip_select_ident() where it now implements an incrementing ip_id for DF: > > /* This is only to work around buggy Windows95/2000 > * VJ compression implementations. If the ID field > * does not change, they drop every other packet in > * a TCP stream using header compression. > */ > > I'm not aware that anyone checked that this buggy Windows95/2000 VJ > compression problem is no longer an issue in practice. I doubt that > the large web hosters who use FreeBSD would be best-pleased if they > ran into this for even just a few users - especially as there is no > config option to disable this change. > > 3) This change causes ip_id for non-DF to be output in native > byte order in ip_output.c. Unfortunately ip_id is still output in > Network Byte Order in ip_mroute.c and raw_ip.c, so this change risks > little-endian machines emitting the same fragmentation id at about > the same time from these different modules, rather than the usual > 64k cycle; creating a small but real risk of re-assembly errors. > [This isn't in my PR, I've only just noticed it.] > > I also have a suspicion that some middle-boxes (like HTTP load-balancers) > may clear DF without setting a fresh IP id - clearing DF would save them > the bother of routing ICMP fragmentation needed back to the source server. > If this is so this is another problem this change could show up which > may cause re-assembly errors. I know the bug is elsewhere, but it would > still become a practical problem for some FreeBSD users. > > So before going with this change I think four things need to be done: > > 1) TCP changed so FIN-ACK goes out with DF if path_mtu_discovery set. > > 2) Tests with Windows95/2000 TCP VJ compression (RFC1144) run. > > 3) ip_id should be emitted in the same byte order everywhere. > > 4) The change made a config option, so sites can disable it should > they run into problems, just as RANDOM_IP_ID is an option. > > This all seems too much to do for 5.2-RELEASE, and as I think the problems > and risks sufficiently serious, I propose reversing the change until this > can be done. We need a quick decision on this to get it into 5.2-RELEASE. > > The PR has some more detail and tcpdump output demonstrating the > issue: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60889 > > The change to be reversed can be seen at: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c#rev1.189 > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1=1.188&r2=1.189 > > NB If anyone can easily run tests with Windows95/2000 TCP VJ compression that > would be great (using tcpdump to see if there is abnormal retransmission). > > NB2 If anyone knows why FIN-ACK goes out without DF that would be helpful. > I've quickly looked at the source, and I can't see why. It's emitted > as TCP moves from FIN_WAIT_n state to TIME_WAIT probably at line 3091 of > tcp_input.c with a call to tcp_output(). tcp_output() always appears to > set IP_DF at line 998 of tcp_output.c, if path_mtu_discovery is enabled. > A puzzle. > > Thanks to Boris Staeblow and Tim Rylance > for highlighting this change and helping me > diagnose the issues. > > Richard > -- > Richard Wendland richard@wendland.org.uk > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 14:56:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9E6A16A4CE; Wed, 7 Jan 2004 14:56:15 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id B933743D55; Wed, 7 Jan 2004 14:56:14 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost.nic.fr [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i07MuDDa066943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Wed, 7 Jan 2004 17:56:13 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i07MuCnH066940; Wed, 7 Jan 2004 17:56:12 -0500 (EST) (envelope-from wollman) Date: Wed, 7 Jan 2004 17:56:12 -0500 (EST) From: Garrett Wollman Message-Id: <200401072256.i07MuCnH066940@khavrinen.lcs.mit.edu> To: Andre Oppermann In-Reply-To: <3FFC8CBE.13B527A3@freebsd.org> References: <200401072023.UAA18922@starburst.demon.co.uk> <3FFC8CBE.13B527A3@freebsd.org> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@FreeBSD.ORG Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 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, 07 Jan 2004 22:56:16 -0000 < said: > 1. Do you think it is neccessary to do a htons() on the randomized > ip_id too? I'd say yes if there is a case where it has to > monotonically increase afterwards. Does it? IP IDs are nonces. The only requirement is that they not be reused for a packet to the same destination IP address before reassembly has timed out. In practice, this is impossible to guarantee, so the usual practice is to try to ensure a complete cycle (of 16-bit numbers). The order doesn't matter. I prefer not byte-swapping the address, but with a modern processor that overhead can probably be pipelined out anyway. -GAWollman From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 16:18:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C921516A4CE; Wed, 7 Jan 2004 16:18:35 -0800 (PST) Received: from starburst.demon.co.uk (adsl-02-230.abel.net.uk [193.109.51.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id C48B443D4C; Wed, 7 Jan 2004 16:18:31 -0800 (PST) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id AAA19786; Thu, 8 Jan 2004 00:18:48 GMT From: Richard Wendland Message-Id: <200401080018.AAA19786@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Date: Thu, 8 Jan 2004 00:18:47 +0000 (GMT) In-Reply-To: <3FFC8CBE.13B527A3@freebsd.org> from "Andre Oppermann" at Jan 07, 2004 11:48:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rw@codeburst.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 00:18:36 -0000 > I've attached a patch that fixes the problem with FIN/ACK and one more > case which got it wrong. Well done! I couldn't track that down. > 1. Do you think it is necessary to do a htons() on the randomized > ip_id too? I'd say yes if there is a case where it has to > monotonically increase afterwards. Does it? No need for monotonic increase, it's a nonce and can cycle in any order. The only need is to be consistent in all the places ip_id is emitted. Maximising the cycle is a strong consideration (64K for the old-fashioned incrementing ip_id), and in my view a powerful argument against using randomized ip_id. Without htons() a remote observer may be able to detect if the system is little-endian or not (in practice today i386 or not); you certainly can for an incrementing ip_id. There is a security argument for not disclosing that (so remote attacker has to try more methods), but I don't think that's a strong argument for the randomized ip_id. My inclination would be to stick with tradition, htons() for incrementing ip_id, natural byte order for randomized ip_id. But other views are perfectly reasonable. > 2. I have a Win2k machine but have check out how I can get tcp header > compression to work with my Cisco AS5300 (if it doesn't do that by > default). Will I see the problem when I do a download from a FreeBSD > 5.2RC2 machine or do I have to use the Windoze as router sending > packets upwards?` All I know is from that comment in Linux, and that they backed-out their zero when DF change. I suspect Windows VJ compression is easiest to get going with PPP dial-up access to the Internet (default I'd guess). So a dial-up Windows system talking to any 5.2RC2 machine on the internet might well be the easiest way to test this, with tcpdump on the 5.2RC2 machine to check for excessive retransmission. You'd just make TCP connections from Windows to 5.2RC2 - web browsing with IE would be a simple way to do that. The other consideration is to not use RFC1323 (or any TCP options) on the connection, as TCP options defeat VJ compression. If Windows makes the active open I don't think Windows will negotiate RFC1323, but to be sure maybe set net.inet.tcp.rfc1323=0 on the 5.2RC2 machine. > 3. There are indeed devices clearing the DF bit. For example Cisco > is recommending this in it's trouble shooting section for broadband > access via DSL/L2TP where the MTU is lower than 1500 because of the > tunnelling overhead. Make a route-map to unset the DF bit and apply > it to the incoming interface. If that's clearing DF without setting a fresh IP id, then zero ip_ids when DF is set should certainly not be emitted by FreeBSD, as it will lead to re-assembly errors with middle-boxen like this. Actually setting a fresh IP id is problematic for middle-boxen and I'd be amazed if they did this. Properly you'd have to try to avoid treading on the genuine ip_id sequence, which is pretty hard - you need to maintain a lot of flow state like a NAT box would. If you have firm documentary evidence of this we should let the IETF TSVWG (or the soon to be split off TCP Maintenance WG) know about this to try to get this recorded in an RFC. I think the proper RFC view would be clearing DF in middle-boxen is wrong; but practical reality probably dictates here. I can do that if you like. Richard -- Richard Wendland richard@wendland.org.uk From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 18:02:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 518D116A4CE; Wed, 7 Jan 2004 18:02:01 -0800 (PST) Received: from starburst.demon.co.uk (adsl-02-230.abel.net.uk [193.109.51.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28FC943D2F; Wed, 7 Jan 2004 18:01:52 -0800 (PST) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id CAA20485; Thu, 8 Jan 2004 02:02:09 GMT From: Richard Wendland Message-Id: <200401080202.CAA20485@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Date: Thu, 8 Jan 2004 02:02:08 +0000 (GMT) In-Reply-To: <3FFC97A1.4F397CC3@freebsd.org> from "Andre Oppermann" at Jan 08, 2004 12:34:57 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: rw@codeburst.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 02:02:01 -0000 > 4. After reading the pf.conf man page from OpenBSD (where it talks about > scrubbing IP packets) I don't think it's a good idea to set the ip_id > to zero in the DF case. It seems to cause various kinds of problems > when for some reason DF is removed along the path (which it shouldn't > but whatever). I think it is clearly better to put a ip_id into every > packet no matter what. Yes, I think we're both now agreed that zero ip_id for DF is a bad idea because of what middle-boxes might do to DF. > Although the ip_randomid() function doesn't > look really cheap to run... but then security comes at a cost. > > 5. Random ip_id is already a kernel option but it is *not* enabled by > default in 5.2RC2 GENERIC or -current. I don't think random ip_id should be enabled by default. The reduction in ip_id cycle from 64k is a real re-assembly risk on modern high-speed networks. Random ip_id brings debatable benefits. There was a good discussion about this on tech-net@NetBSD.org last November, where they rejected random ip_id as default. One issue is that they (claim to have) discovered the OpenBSD random ip_id code has a 12k cycle rather than the advertised 30k: http://mail-index.netbsd.org/tech-net/2003/11/26/0005.html http://mail-index.netbsd.org/tech-net/2003/11/27/0007.html The other is a consideration of what the maximum safe data transfer rate is for a given ip_id cycle. You want long ip_id cycle times for non-DF gigabit networking, like NFS. I buy into these arguments by Robert Elz and Jonathan Stone: http://mail-index.netbsd.org/tech-net/2003/11/26/0013.html http://mail-index.netbsd.org/tech-net/2003/11/26/0015.html though a good contrary view is: http://mail-index.netbsd.org/tech-net/2003/11/26/0021.html It's important to remember that if fragmentation takes place, and a fragment is lost, the other fragment(s) will wait for quite some time in a re-assembly buffer (maybe up to 63 seconds). While they are waiting they are at quite some risk of being joined onto a fragment from the next ip_id cycle if a lot of packets are flowing: http://mail-index.netbsd.org/tech-net/2003/11/26/0022.html http://mail-index.netbsd.org/tech-net/2003/11/26/0023.html Remember a 64k cycle is consumed by 64MB of transfer if average datagram size is 1024 bytes. Thats not a lot on a gigabit network. The better solution in my opinion is to do similar to Solaris, have per-destination ip_id counters (or at least a hash of destination IP to one of N ip_id counters). You typically get longer cycle times and improved privacy, with a method that is faster than random ip_id. > On the other hand the code > *does* zero the ip_id when DF is set in any case which is troublesome > as we just found out. Yes. Richard -- Richard Wendland richard@wendland.org.uk From owner-freebsd-net@FreeBSD.ORG Wed Jan 7 19:03:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4992C16A4CE for ; Wed, 7 Jan 2004 19:03:28 -0800 (PST) Received: from smtp106.mail.sc5.yahoo.com (smtp106.mail.sc5.yahoo.com [66.163.169.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4868243D49 for ; Wed, 7 Jan 2004 19:03:27 -0800 (PST) (envelope-from q_dolan@yahoo.com.au) Received: from unknown (HELO ?192.168.100.140?) (q?dolan@203.144.21.67 with plain) by smtp106.mail.sc5.yahoo.com with SMTP; 8 Jan 2004 03:03:26 -0000 From: Q To: Adam McLaurin In-Reply-To: <20040107151544.6bbab003.adam.mclaurin@gmx.net> References: <20040107151544.6bbab003.adam.mclaurin@gmx.net> Content-Type: text/plain Message-Id: <1073530943.77647.90.camel@boxster.onthenet.com.au> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 08 Jan 2004 13:02:23 +1000 Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Intermittent problems with LAN transfer speeds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 03:03:28 -0000 The first thing you should try is setting the ethernet card to use autosense. This enables the autosense pulse to be sent to the switch, without this some passive/unmanaged switches can get very confused and switch speeds and duplex at seemingly random intervals for a while before eventually sorting themselves out again. You should only ever set speed & duplex manually if you can set it at BOTH ends. The easiest way to identify this as the problem is to do a 'netstat -i' and check for collisions. If everything on that LAN segment is full duplex all the time, there should be none. You will most likely have to wait for the problem to occur again before the collisions appear. Seeya...Q On Thu, 2004-01-08 at 06:15, Adam McLaurin wrote: > Since I first installed FreeBSD 2 years ago, I have intermittent > problems with my LAN transfer speeds. It doesn't happen often, but when > it does, I've not found any solution other than rebooting the server. > > My network configuration looks like this: > cable modem --> freebsd 5.1-R --> dlink switch --> win2k workstation > > I normally get appx 10MB/s between my two machines. However, > occasionally I'll fire up a transfer and only get 50-200KB/s, which is > really awful. ... > Both the gateway's NIC and the workstations NIC are manually set to > 100Mbit full-duplex. From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 03:27:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F4DF16A4CE; Thu, 8 Jan 2004 03:27:53 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A02D43D3F; Thu, 8 Jan 2004 03:27:52 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i08BRh7E019581; Thu, 8 Jan 2004 03:27:47 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200401081127.i08BRh7E019581@gw.catspoiler.org> Date: Thu, 8 Jan 2004 03:27:43 -0800 (PST) From: Don Lewis To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: sam@FreeBSD.org cc: itojun@FreeBSD.org Subject: panic in in6_ifdetach() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 11:27:53 -0000 I was testing one of Warner's patches on my laptop and found that it paniced during boot. The trigger was that fxp0 couldn't gets its irq configured in fxp_attach(), so it called ether_ifdetach(), which eventually ended up calling in6_ifdetach(), which blew up at the line of code marked below: /* remove route to link-local allnodes multicast (ff02::1) */ bzero(&sin6, sizeof(sin6)); sin6.sin6_len = sizeof(struct sockaddr_in6); sin6.sin6_family = AF_INET6; sin6.sin6_addr = in6addr_linklocal_allnodes; sin6.sin6_addr.s6_addr16[1] = htons(ifp->if_index); /* XXX grab lock first to avoid LOR */ ---> RADIX_NODE_HEAD_LOCK(rt_tables[AF_INET6]); rt = rtalloc1((struct sockaddr *)&sin6, 0, 0UL); if (rt) { if (rt->rt_ifp == ifp) rtexpunge(rt); RTFREE_LOCKED(rt); } RADIX_NODE_HEAD_UNLOCK(rt_tables[AF_INET6]); The problem is that during boot time the hardware is getting attached well before route_init() is called, which is what initializes rt_tables[]. It looks like the allnodes multicast address is not configured for the interface until it is given an IPv6 address, so there should be no need to remove the route until that has happened. Any suggestions for a non-kludgey way to fix this? From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 03:47:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7821E16A4CE for ; Thu, 8 Jan 2004 03:47:26 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D61343D46 for ; Thu, 8 Jan 2004 03:47:24 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 2064 invoked from network); 8 Jan 2004 11:47:23 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 8 Jan 2004 11:47:23 -0000 Message-ID: <3FFD434B.A634FC8B@freebsd.org> Date: Thu, 08 Jan 2004 12:47:23 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rw@codeburst.co.uk References: <200401080018.AAA19786@starburst.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 11:47:26 -0000 Richard Wendland wrote: > > > I've attached a patch that fixes the problem with FIN/ACK and one more > > case which got it wrong. > > Well done! I couldn't track that down. > > > 1. Do you think it is necessary to do a htons() on the randomized > > ip_id too? I'd say yes if there is a case where it has to > > monotonically increase afterwards. Does it? > > No need for monotonic increase, it's a nonce and can cycle in any order. Ok. I wasn't sure. > The only need is to be consistent in all the places ip_id is emitted. > Maximising the cycle is a strong consideration (64K for the old-fashioned > incrementing ip_id), and in my view a powerful argument against using > randomized ip_id. Agreed that we need to maximize the cycle. > Without htons() a remote observer may be able to detect if the system > is little-endian or not (in practice today i386 or not); you certainly > can for an incrementing ip_id. There is a security argument for not > disclosing that (so remote attacker has to try more methods), but I > don't think that's a strong argument for the randomized ip_id. Na, there are so many ways to detect the OS/architecture this doesn't matter. > My inclination would be to stick with tradition, htons() for incrementing > ip_id, natural byte order for randomized ip_id. But other views are > perfectly reasonable. I've done it this way to be consistent in all places. > > 2. I have a Win2k machine but have check out how I can get tcp header > > compression to work with my Cisco AS5300 (if it doesn't do that by > > default). Will I see the problem when I do a download from a FreeBSD > > 5.2RC2 machine or do I have to use the Windoze as router sending > > packets upwards?` > > All I know is from that comment in Linux, and that they backed-out their > zero when DF change. > > I suspect Windows VJ compression is easiest to get going with PPP > dial-up access to the Internet (default I'd guess). So a dial-up Windows > system talking to any 5.2RC2 machine on the internet might well be the > easiest way to test this, with tcpdump on the 5.2RC2 machine to check > for excessive retransmission. You'd just make TCP connections from > Windows to 5.2RC2 - web browsing with IE would be a simple way to do that. > > The other consideration is to not use RFC1323 (or any TCP options) > on the connection, as TCP options defeat VJ compression. If Windows > makes the active open I don't think Windows will negotiate RFC1323, > but to be sure maybe set net.inet.tcp.rfc1323=0 on the 5.2RC2 machine. Ok, will try to do that. > > 3. There are indeed devices clearing the DF bit. For example Cisco > > is recommending this in it's trouble shooting section for broadband > > access via DSL/L2TP where the MTU is lower than 1500 because of the > > tunnelling overhead. Make a route-map to unset the DF bit and apply > > it to the incoming interface. > > If that's clearing DF without setting a fresh IP id, then zero ip_ids > when DF is set should certainly not be emitted by FreeBSD, as it will > lead to re-assembly errors with middle-boxen like this. > > Actually setting a fresh IP id is problematic for middle-boxen and I'd be > amazed if they did this. Properly you'd have to try to avoid treading on > the genuine ip_id sequence, which is pretty hard - you need to maintain > a lot of flow state like a NAT box would. > > If you have firm documentary evidence of this we should let the IETF TSVWG > (or the soon to be split off TCP Maintenance WG) know about this to try > to get this recorded in an RFC. I think the proper RFC view would be > clearing DF in middle-boxen is wrong; but practical reality probably > dictates here. I can do that if you like. I fairly certain that the Cisco route-map hack is not setting a new ip_id. The OpenBSD pf.conf man page explicitly mentions that stateful connection tracking is required for clearing DF. So I'd say go ahead and raise this issue in IETF TSVWG. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 03:55:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D817E16A4D0 for ; Thu, 8 Jan 2004 03:55:34 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id B18CB43D5A for ; Thu, 8 Jan 2004 03:55:32 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 3817 invoked from network); 8 Jan 2004 11:55:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 8 Jan 2004 11:55:31 -0000 Message-ID: <3FFD4533.A35B6CD0@freebsd.org> Date: Thu, 08 Jan 2004 12:55:31 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rw@codeburst.co.uk References: <200401080202.CAA20485@starburst.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 11:55:35 -0000 Richard Wendland wrote: > > 5. Random ip_id is already a kernel option but it is *not* enabled by > > default in 5.2RC2 GENERIC or -current. > > I don't think random ip_id should be enabled by default. The reduction > in ip_id cycle from 64k is a real re-assembly risk on modern high-speed > networks. Random ip_id brings debatable benefits. There was a good > discussion about this on tech-net@NetBSD.org last November, where they > rejected random ip_id as default. Ok. > One issue is that they (claim to have) discovered the OpenBSD random > ip_id code has a 12k cycle rather than the advertised 30k: > > http://mail-index.netbsd.org/tech-net/2003/11/26/0005.html > http://mail-index.netbsd.org/tech-net/2003/11/27/0007.html > > The other is a consideration of what the maximum safe data transfer rate > is for a given ip_id cycle. You want long ip_id cycle times for non-DF > gigabit networking, like NFS. I buy into these arguments by Robert Elz > and Jonathan Stone: > > http://mail-index.netbsd.org/tech-net/2003/11/26/0013.html > http://mail-index.netbsd.org/tech-net/2003/11/26/0015.html > > though a good contrary view is: > > http://mail-index.netbsd.org/tech-net/2003/11/26/0021.html Haven't read all of that yet. > It's important to remember that if fragmentation takes place, and a > fragment is lost, the other fragment(s) will wait for quite some time in > a re-assembly buffer (maybe up to 63 seconds). While they are waiting > they are at quite some risk of being joined onto a fragment from the > next ip_id cycle if a lot of packets are flowing: > > http://mail-index.netbsd.org/tech-net/2003/11/26/0022.html > http://mail-index.netbsd.org/tech-net/2003/11/26/0023.html > > Remember a 64k cycle is consumed by 64MB of transfer if average datagram > size is 1024 bytes. Thats not a lot on a gigabit network. > > The better solution in my opinion is to do similar to Solaris, have > per-destination ip_id counters (or at least a hash of destination IP > to one of N ip_id counters). You typically get longer cycle times and > improved privacy, with a method that is faster than random ip_id. I have an idea how to something like this in an efficient manner. Have a global incrementing ip_id counter and a small fixed size hash table. The hash is computed from faddr/fport (see tcp_hostcache for a good hash function). The hash table contains seeds in every bucket which are refreshed periodically (every second or ten or whatever). For an outgoing packet you take the global ip_id counter, increment it by one, take the result and XOR it with the seed in the apropriate bucket. The chance of collisions is very low and you get the full 64k cycle (globally). Or you can do it the other way around and have a counter in every bucket and a global seed. Need to think about which is actually better. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 08:59:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0595116A4CE for ; Thu, 8 Jan 2004 08:59:42 -0800 (PST) Received: from wbm1.pair.net (wbm1.pair.net [209.68.3.41]) by mx1.FreeBSD.org (Postfix) with SMTP id 3A1B743D54 for ; Thu, 8 Jan 2004 08:59:10 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 51488 invoked by uid 65534); 8 Jan 2004 16:59:09 -0000 Received: from 158.6.15.27 ([158.6.15.27]) (SquirrelMail authenticated user silby@silby.com) by webmail.pair.com with HTTP; Thu, 8 Jan 2004 11:59:09 -0500 (EST) Message-ID: <60755.158.6.15.27.1073581149.squirrel@webmail.pair.com> Date: Thu, 8 Jan 2004 11:59:09 -0500 (EST) From: To: X-pair-Authenticated: 158.6.15.27 In-Reply-To: <3FFD4533.A35B6CD0@freebsd.org> References: <200401080202.CAA20485@starburst.demon.co.uk> <3FFD4533.A35B6CD0@freebsd.org> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: rw@codeburst.co.uk Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 16:59:42 -0000 > Richard Wendland wrote: > Haven't read all of that yet. >> It's important to remember that if fragmentation takes place, and a >> fragment is lost, the other fragment(s) will wait for quite some time >> in a re-assembly buffer (maybe up to 63 seconds). While they are >> waiting they are at quite some risk of being joined onto a fragment >> from the next ip_id cycle if a lot of packets are flowing: IMO, that's not really a "risk" anymore than packet loss is a risk. If two different IP packets are joined together, the subsequent TCP / UDP checksum will be incorrect, and the packet will be dropped. This is equivalent to a packet being dropped by the network; if we can't handle a few lost packets, then we have a big problem. Now, on to likelihood. Since IP IDs are per (IP source, dest) pair, let's consider two computers talking together, and assume that all packets are fragmented. If all packets are received in order, then we could actually get away with using the same ID over and over; each packet would be removed from the reassmebly queue when the final fragment arrived, and the next packet would create a new reassembly queue when its first fragment arrives. Assuming that some packet reordering occurs, but no packet loss, we're still in good shape, and can get away with only as many IP IDs as we have packets in flight. Even if we have slight packet loss, there should still be very few problems, as a collision in the 2^16 space will be unlikely if we have only a few incompletely reassembled packets hanging around. Of course, you can make the argument that if we have frequent packet loss, collisions become a common occurance. I agree... however, if you have frequent packet loss, TCP will backoff to a lower transmission rate, add delays, etc, which will help mitigate the problem. And if you have an app which keeps sending UDP packets at crazy rates which causes fragment loss and the resulting collisions, well, your performance will already be so bad that I doubt the additional few packets dropped due to collisions will matter one bit. So, to sum up my position on IP ID collisions: they cause no more problems than random packet loss would, and hence are not something we need to worry about much at all. Now, on to what we should do... > I have an idea how to something like this in an efficient manner. > Have a global incrementing ip_id counter and a small fixed size > hash table. The hash is computed from faddr/fport (see tcp_hostcache > for a good hash function). The hash table contains seeds in every > bucket which are refreshed periodically (every second or ten or > whatever). For an outgoing packet you take the global ip_id counter, > increment it by one, take the result and XOR it with the seed in > the apropriate bucket. The chance of collisions is very low and > you get the full 64k cycle (globally). Or you can do it the other way > around and have a counter in every bucket and a global seed. > Need to think about which is actually better. > > -- > Andre Could you just use the tcp host cache for this purpose? The simplest solution I can think of is to use the host cache to provide seperate IP ID sequences for hosts in the cache, and to use arc4random for all other hosts. This could result in a few collisions under certain situations, but I think that is an acceptable risk. If that requires extra host cache lookups, we could use the host cache provided sequence space for TCP packets only (one sequence space for all TCP sessions, of course), and arc4random for UDP / etc. I had considered some sort of hash table type system as you propose above, I came to the conclusion that it wouldn't be that much faster than arc4random and would provide much less randomness. Oh, I also wanted to reinforce a point Richard had made in his post on the problems with our id = 0 change: randomization becomes _more_ important as we move away from a global counter. If we use the tcp host cache to provide individual sequence spaces for TCP connections, we need to make sure that we address all the other packets, or we will be increasing the amount of information we're revealing. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 09:51:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A284016A504 for ; Thu, 8 Jan 2004 09:51:46 -0800 (PST) Received: from mutare.noc.clara.net (mutare.noc.clara.net [195.8.70.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C54043D6D for ; Thu, 8 Jan 2004 09:51:10 -0800 (PST) (envelope-from ollie@mutare.noc.clara.net) Received: from ollie by mutare.noc.clara.net with local (Exim 4.24) id 1AeeJJ-000IoN-Cd for freebsd-net@freebsd.org; Thu, 08 Jan 2004 17:51:09 +0000 Date: Thu, 8 Jan 2004 17:51:09 +0000 From: Ollie Cook To: freebsd-net@freebsd.org Message-ID: <20040108175109.GE70042@mutare.noc.clara.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.9-STABLE i386 X-NCC-RegID: uk.claranet Sender: Ollie Cook X-Envelope-To: freebsd-net@freebsd.org X-Clara-Scan: content scanned according to recipient preferences Subject: NFS server not responding / alive again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 17:51:46 -0000 Good evening, I am seeking some advice on some errors I am seeing in the logs of the machines in a mail cluster I am responsible for. The errors do not seem to be causing any operational impact, but equally, I'm inclined to investigate the source of the warnings in any case. The log messages in question are of the form: Jan 8 17:04:51 metis /kernel: nfs server 192.168.1.1:/vol/vol1/claramail: not responding Jan 8 17:04:53 metis /kernel: nfs server 192.168.1.1:/vol/vol1/claramail: is alive again These messages are logged fairly frequently, with a new pair appearing every few seconds or so. The mail cluster consists of ten i386 hosts running a variety of FreeBSD versions from 4.5-STABLE to 4.9-STABLE. The NFS server is a Network Appliance F825 filer running Data ONTAP 6.4.1. The remote volume is just shy of 1TB large. Four of the hosts run message delivery software and perform mostly writes to the remotely mounted volume. The remaining six run POP or webmail software and perform mostly reads from the volume. Seven of the hosts are on the same local LAN and mount the volume as NFSv3 over UDP. The remaining three hosts are in a remote datacentre and mount the volume over TCP. All but two of the hosts log these error conditions. These two hosts are two of the local ones which mount the volume by UDP. The four delivery hosts each do up to 250 NFS operations per second (avg 120) while the POP hosts each do up to 750 NFS operations per second (avg 500). The total number of NFS operations the file handles is up to 7000 per second (avg 3500). As far as I can tell there is no correlation between the type of NFS activity, the OS revisions on the individual hosts, the number of NFS operations per client or the NFS transport and the appearance of these log lines in /var/log/messages. If this were a NFS server performance issue, I'd expect it to affect all the NFS clients, but this isn't the case. We also run a second, similar but smaller cluster, with the same architecture and software but fewer hosts for another vISP, which doesn't exhibit this problem. There are two delivery hosts and two POP/webmail hosts. They generate a maximum of around 1200 NFS operations all together. Other posts I have seen on this subject have suggested to check for local network problems, exhausted mbufs etc., but I don't believe this to be the cause. From one client (one of the TCP ones): ollie@mese:[ollie] (1) # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll fxp0 1500 00:50:8b:e0:5b:85 1427046704 0 1406319153 1 0 fxp0 1500 192.168.1/24 mese 1236173208 - 1406332198 - - fxp0 1500 pop1.mail/32 pop1.mail 188200155 - 58 - - fxp1* 1500 00:50:8b:e0:5b:3e 0 0 0 0 0 lo0 16384 3589 0 3589 0 0 lo0 16384 your-net localhost 1129 - 1129 - - ollie@mese:[ollie] (2) # netstat -m 544/1632/34816 mbufs in use (current/peak/max): 439 mbufs allocated to data 105 mbufs allocated to packet headers 370/878/8704 mbuf clusters in use (current/peak/max) 2164 Kbytes allocated to network (8% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines The network interfaces on the clients and servers all operate at Fast Ethernet speeds in full-duplex, and none is close to being saturated. The NetApp filer does about 25Mbit/s at peak. Should these log lines concern me or am I worrying unnecessarily? Has anyone else experienced any similar behaviour between FreeBSD clients and NetApp filers? I am at a loss for how to further investigate this NFS issue, and would be glad to receive any advice in that direction. Yours, Ollie -- Oliver Cook Systems Administrator, Claranet UK ollie@uk.clara.net 020 7903 3065 From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 10:18:57 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCEE916A4CE for ; Thu, 8 Jan 2004 10:18:57 -0800 (PST) Received: from mutare.noc.clara.net (mutare.noc.clara.net [195.8.70.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id B112D43D3F for ; Thu, 8 Jan 2004 10:18:56 -0800 (PST) (envelope-from ollie@mutare.noc.clara.net) Received: from ollie by mutare.noc.clara.net with local (Exim 4.24) id 1AeekC-000J0p-45; Thu, 08 Jan 2004 18:18:56 +0000 Date: Thu, 8 Jan 2004 18:18:56 +0000 From: Ollie Cook To: Steve Francis Message-ID: <20040108181856.GF70042@mutare.noc.clara.net> References: <20040108175109.GE70042@mutare.noc.clara.net> <3FFD9E0C.3030305@expertcity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFD9E0C.3030305@expertcity.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.9-STABLE i386 X-NCC-RegID: uk.claranet Sender: Ollie Cook cc: freebsd-net@freebsd.org Subject: Re: NFS server not responding / alive again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 18:18:58 -0000 On Thu, Jan 08, 2004 at 10:14:36AM -0800, Steve Francis wrote: > Look at the dumbtimer mount option in mount_nfs Hi Steve, Sorry. I should have mentioned that they are already mounted with that option: 192.168.1.1:/vol/vol1/claramail /clara nfs rw,dumbtimer 0 0 in the UDP case and 192.168.1.1:/vol/vol1/claramail /clara nfs rw,dumbtimer,tcp 0 0 for TCP. Yours, Ollie -- Oliver Cook Systems Administrator, Claranet UK ollie@uk.clara.net 020 7903 3065 From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 13:24:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5395616A4CE for ; Thu, 8 Jan 2004 13:24:19 -0800 (PST) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3699A43D48 for ; Thu, 8 Jan 2004 13:24:17 -0800 (PST) (envelope-from adam.mclaurin@gmx.net) Received: from 146-115-126-186.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com ([146.115.126.186] helo=jake) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.35 #4) id 1AehdY-0006fo-00; Thu, 08 Jan 2004 16:24:16 -0500 Date: Thu, 8 Jan 2004 16:24:16 -0500 From: Adam McLaurin To: q_dolan@yahoo.com.au, freebsd-net@freebsd.org Message-Id: <20040108162416.13c13a53.adam.mclaurin@gmx.net> In-Reply-To: <1073530943.77647.90.camel@boxster.onthenet.com.au> References: <20040107151544.6bbab003.adam.mclaurin@gmx.net> <1073530943.77647.90.camel@boxster.onthenet.com.au> Organization: X-Mailer: Sylpheed version 0.9.5-gtk2-20030906 (GTK+ 2.2.4; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Intermittent problems with LAN transfer speeds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 21:24:19 -0000 On Thu, 08 Jan 2004 13:02:23 +1000 Q wrote: > The first thing you should try is setting the ethernet card to use > autosense. This enables the autosense pulse to be sent to the switch, > without this some passive/unmanaged switches can get very confused and > switch speeds and duplex at seemingly random intervals for a while > before eventually sorting themselves out again. You should only ever > set > speed & duplex manually if you can set it at BOTH ends. > > The easiest way to identify this as the problem is to do a 'netstat > -i' > and check for collisions. If everything on that LAN segment is full > duplex all the time, there should be none. You will most likely have > to > wait for the problem to occur again before the collisions appear. A few things .. First, both speed & duplex are set manualyl at both ends. In fact, I did this more than a year ago as a recommendation to solve this particular problem we're discussing now. In other words, the problem existed before I manually set speed/duplex, and afterwards. Second, the problem doesn't ever sort itself out. If I don't reboot the server, the problem continues indefinitely. Last, here is the output of netstat and ifconfig: http://www.tranceambient.com:8000/public/netstat.output.txt Note: The parts marked with 'x' are indicating my internet IP address, which I am futilely trying to mask. Thanks. -- Adam From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 18:48:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 262A216A4CE for ; Thu, 8 Jan 2004 18:48:03 -0800 (PST) Received: from mercury.ccmr.cornell.edu (mercury.ccmr.cornell.edu [128.84.231.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 921E343D1F for ; Thu, 8 Jan 2004 18:48:01 -0800 (PST) (envelope-from mitch@ccmr.cornell.edu) Received: from saruman.ccmr.cornell.edu (saruman.ccmr.cornell.edu [128.84.249.196])i092m03R002732; Thu, 8 Jan 2004 21:48:00 -0500 Received: from localhost (mitch@localhost)i092lx4w029954; Thu, 8 Jan 2004 21:48:00 -0500 X-Authentication-Warning: saruman.ccmr.cornell.edu: mitch owned process doing -bs Date: Thu, 8 Jan 2004 21:47:59 -0500 (EST) From: Mitch Collinsworth To: Adam McLaurin In-Reply-To: <20040108162416.13c13a53.adam.mclaurin@gmx.net> Message-ID: References: <20040107151544.6bbab003.adam.mclaurin@gmx.net> <1073530943.77647.90.camel@boxster.onthenet.com.au> <20040108162416.13c13a53.adam.mclaurin@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: q_dolan@yahoo.com.au Subject: Re: Intermittent problems with LAN transfer speeds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 02:48:03 -0000 On Thu, 8 Jan 2004, Adam McLaurin wrote: > First, both speed & duplex are set manualyl at both ends. In fact, I did > this more than a year ago as a recommendation to solve this particular > problem we're discussing now. In other words, the problem existed before > I manually set speed/duplex, and afterwards. When you say "both ends" do you mean computer and network switch? Or do you mean computer A and computer B? Is the switch managed or unmanaged? You can't set full duplex on an unmanaged switch, it is always in auto. If you have an unmanaged switch you MUST set the computers to auto or to half. Setting them to full will most definitely cause problems. The auto-negotiation specification says a port set to auto must choose half if the other end is not set to auto. This is an extremely common misunderstanding. -Mitch From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 06:43:02 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E86016A4CE for ; Fri, 9 Jan 2004 06:43:02 -0800 (PST) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC0D943D53 for ; Fri, 9 Jan 2004 06:43:00 -0800 (PST) (envelope-from adam.mclaurin@gmx.net) Received: from 146-115-126-186.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com ([146.115.126.186] helo=jake) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.35 #4) id 1Aexql-0001rN-00; Fri, 09 Jan 2004 09:42:59 -0500 Date: Fri, 9 Jan 2004 09:42:59 -0500 From: Adam McLaurin To: mitch@ccmr.cornell.edu, freebsd-net@freebsd.org Message-Id: <20040109094259.000c4353.adam.mclaurin@gmx.net> In-Reply-To: References: <20040107151544.6bbab003.adam.mclaurin@gmx.net> <1073530943.77647.90.camel@boxster.onthenet.com.au> <20040108162416.13c13a53.adam.mclaurin@gmx.net> Organization: X-Mailer: Sylpheed version 0.9.5-gtk2-20030906 (GTK+ 2.2.4; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Intermittent problems with LAN transfer speeds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 14:43:02 -0000 On Thu, 8 Jan 2004 21:47:59 -0500 (EST) Mitch Collinsworth wrote: > When you say "both ends" do you mean computer and network switch? Or > do you mean computer A and computer B? Is the switch managed or > unmanaged? You can't set full duplex on an unmanaged switch, it is > always in auto. If you have an unmanaged switch you MUST set the > computers to auto or to half. Setting them to full will most > definitely cause problems. The auto-negotiation specification says > a port set to auto must choose half if the other end is not set to > auto. This is an extremely common misunderstanding. The switch is completely unmanaged, so by 'both ends' I mean the gateway and the workstation behind the switch. I have both computers back to auto and reboot. The problem is gone (for now), but keep in mind it also would have been fixed had I not changed anything in my settings. The true test will be to see if the problem happens again in coming weeks .. Thanks for all the info, I appreciate it. -- Adam From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 07:09:39 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAB9816A4CE for ; Fri, 9 Jan 2004 07:09:39 -0800 (PST) Received: from ganymede.hub.org (u46n208.hfx.eastlink.ca [24.222.46.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15FE343D41 for ; Fri, 9 Jan 2004 07:09:37 -0800 (PST) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id CE7683808B; Fri, 9 Jan 2004 11:06:12 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id CDA41378E5 for ; Fri, 9 Jan 2004 11:06:12 -0400 (AST) Date: Fri, 9 Jan 2004 11:06:12 -0400 (AST) From: "Marc G. Fournier" To: freebsd-net@freebsd.org In-Reply-To: <20040104162220.S28998@ganymede.hub.org> Message-ID: <20040109110204.G32294@ganymede.hub.org> References: <20040104162220.S28998@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Odd behaviour on em0 device in -stable ... I think ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 15:09:40 -0000 Just a quick follow up note on this ... this morning, we upgraded the server in question to latest stable, and rebooted, to see if that would clear up the problem ... The problem persisted, but, based on comments about auto-negotiation made in this thread, I figured I'd see if maybe 'forcing' to 'media 100baseTX mediaopt full-duplex' would make any difference, and it appears to ... I can now move IPs back and forth from server to server, including this one, without any apparently problems ... So, problem with aliasing/unaliasing code where autoselect is enabled, maybe? On Sun, 4 Jan 2004, Marc G. Fournier wrote: > > I'm having some odd behaviour with one of my servers ... it is the only > one of 4 that I have that has an em device, and, from what I can tell, the > problem doesn't exist on any of the other 3 ... > > The problem is that I want to move an IP from one of the other servers > (all with fxp interfaces) over to the 4th, with the em device ... I -alias > the IP from the fxp device, and alias it over to the em device, and I can > no longer access it remotely ... > > If I alias it onto any of hte other two fxp based servers, it works fine. > > If I ping from the old server, on the same network, it pings fine ... its > only remote pings that don't work ... and all other IPs currently on the > em server are pingable too, so its not like I have ICMP blocked at any one > point ... > > All 4 servers are plug'd into a Linksys 10/100 Switch, which is then > plug'd into a Cisco Switch ... > > If I add an unused IP to the em device, it is pingable ... its as if > somewhere isn't seeing the routing change from the old fxp based server > over to the new em based one, but if I put it onto a different fxp based > server, it works ... > > Trying to do a 'ping -S ns.uunet.ca' doesn't work either, but using > an existing, pingable IP, does ... netmask is set identical to all the > other IPs on the machine, and arp -a shows the IP as 'permanent' ... > > I'm not sure what to look at ... the only 'odd man out' here is the em > device itself, but by the fact that I can add an unassigned IP to it, I'm > not hitting a limit on # of aliased IPs (currently only 21) ... and I've > tried with another assigned IP (unalias from fxp device, move it to em > device) and it too becomes unpingable, but works fine if I move it to > another fxp device on a different server ... > > Am I missing something obvious here? > > Thanks ... > > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 09:17:40 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AD6F16A4CE for ; Fri, 9 Jan 2004 09:17:40 -0800 (PST) Received: from web60804.mail.yahoo.com (web60804.mail.yahoo.com [216.155.196.67]) by mx1.FreeBSD.org (Postfix) with SMTP id E4AA843D49 for ; Fri, 9 Jan 2004 09:17:20 -0800 (PST) (envelope-from richard_bejtlich@yahoo.com) Message-ID: <20040109171717.33976.qmail@web60804.mail.yahoo.com> Received: from [68.84.6.72] by web60804.mail.yahoo.com via HTTP; Fri, 09 Jan 2004 09:17:16 PST Date: Fri, 9 Jan 2004 09:17:16 -0800 (PST) From: Richard Bejtlich To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Paper on device polling and packet capture performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 17:17:40 -0000 Hello, I was wondering if anyone read the paper by Luca Deri (of Ntop fame) on "Improving Passive Packet Capture: Beyond Device Polling": http://luca.ntop.org/Ring.pdf Luca makes some astounding claims regarding packet capture performance, with FreeBSD performing very well when device polling is enabled. A wrote a short and probably naive synopsis for my Blog: http://taosecurity.blogspot.com/2004_01_01_taosecurity_archive.html#107358025105922521 Does anyone care to comment on the paper? (I asked Luca and he agreed to this post.) Thank you, Richard Bejtlich http://www.taosecurity.com __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 09:29:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D80F916A4CE; Fri, 9 Jan 2004 09:29:51 -0800 (PST) Received: from TheWorld.com (pcls3.std.com [192.74.137.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0689C43D4C; Fri, 9 Jan 2004 09:29:50 -0800 (PST) (envelope-from kwc@shell.TheWorld.com) Received: from shell.TheWorld.com (pip1-5.std.com [192.74.137.185]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id i09HQuJi012526; Fri, 9 Jan 2004 12:29:42 -0500 Received: (from kwc@localhost) by shell.TheWorld.com (8.9.3/8.9.3) id MAA3017414; Fri, 9 Jan 2004 12:11:48 -0500 (EST) Date: Fri, 9 Jan 2004 12:11:48 -0500 (EST) From: Kenneth W Cochran Message-Id: <200401091711.MAA3017414@shell.TheWorld.com> To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: (revised) 4.0-stable & Linksys WRT54G won't talk w/each other X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 17:29:52 -0000 Hello: I'm having problems getting a FreeBSD machine and a Linksys WRT54G talking with each other. Interfaces: dc0 - "public" to outside Internet dc1 - internal 192.168.0.1/24, connects to a hub dc2 - internal 192.168.1.100/24, connects to a switched LAN port on the router dc3 - currently unused OS: FreeBSD 4.9-STABLE as of 10 December 2003 firewall: ipfw2 Running natd between dc0 & dc1 (& that works fine) dc0 gets its IP address, etc., via DHCP/dhclient. dc1 is configured statically & machines connected on that subnet work fine. dc2 should get its ip address, etc. from a Linksys WRT54G, but won't; syslog says "address in use," so I configured it "manually" with ifconfig, to 192.168.1.100/24. Problems/questions: dc2 has a Linksys WRT54G on it, & thus far, that box refuses to talk (not even icmp) with the fbsd machine, even if I set its ip-address & that of dc2 manually. (The Linksys defaults to running a dhcp server & its factory-supplied ip-address is 192.168.1.1 & it "tries" to setup the first interface talking to it to be 192.168.1.100). The router works fine when connecting another machine (running Windows 2000) to it. As examples: $ ping -c3 192.168.0.2 ## this is a Windows2000 box on the dc1 network PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=0.391 ms 64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.177 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.232 ms --- 192.168.0.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.177/0.267/0.391/0.091 ms localhost# tcpdump -lni dc1 ## tcpdump while running the above ping tcpdump: listening on dc1 10:15:39.882162 arp who-has 192.168.0.2 tell 192.168.0.1 10:15:39.882305 arp reply 192.168.0.2 is-at 0:90:27:84:42:f 10:15:39.882318 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:39.882492 192.168.0.2 > 192.168.0.1: icmp: echo reply 10:15:40.883394 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:40.883511 192.168.0.2 > 192.168.0.1: icmp: echo reply 10:15:41.893417 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:41.893584 192.168.0.2 > 192.168.0.1: icmp: echo reply $ ping -c3 192.168.1.1 ## ip address of the router on dc2 PING 192.168.1.1 (192.168.1.1): 56 data bytes --- 192.168.1.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss localhost# tcpdump -lni dc2 ## tcpdump while running the above ping tcpdump: listening on dc2 10:17:18.123385 arp who-has 192.168.1.1 tell 192.168.1.100 10:17:19.124588 arp who-has 192.168.1.1 tell 192.168.1.100 10:17:20.134583 arp who-has 192.168.1.1 tell 192.168.1.100 Any ideas on getting this thing to work? It seems to work fine when connected to a Windows2000 machine. Yes, I've tried other interfaces & cables, etc, so I'm confident the hardware is fine. :) Idea(s) on further troubleshooting/fixing this? FAQs/documentation pointers are quite welcome. :) Thanks, -kc From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 09:30:16 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C5B316A541; Fri, 9 Jan 2004 09:30:16 -0800 (PST) Received: from TheWorld.com (pcls3.std.com [192.74.137.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CD6343D3F; Fri, 9 Jan 2004 09:30:13 -0800 (PST) (envelope-from kwc@shell.TheWorld.com) Received: from shell.TheWorld.com (pip1-5.std.com [192.74.137.185]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id i09HQuJk012526; Fri, 9 Jan 2004 12:29:42 -0500 Received: (from kwc@localhost) by shell.TheWorld.com (8.9.3/8.9.3) id MAA15061483; Fri, 9 Jan 2004 12:15:11 -0500 (EST) Date: Fri, 9 Jan 2004 12:15:11 -0500 (EST) From: Kenneth W Cochran Message-Id: <200401091715.MAA15061483@shell.TheWorld.com> To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: (revised) 4.*9*-stable & Linksys WRT54G won't talk w/each other X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 17:30:16 -0000 oops, mistype, that should've been 4.9-stable instead of 4.0... stupidfingers... Hello: I'm having problems getting a FreeBSD machine and a Linksys WRT54G talking with each other. Interfaces: dc0 - "public" to outside Internet dc1 - internal 192.168.0.1/24, connects to a hub dc2 - internal 192.168.1.100/24, connects to a switched LAN port on the router dc3 - currently unused OS: FreeBSD 4.9-STABLE as of 10 December 2003 firewall: ipfw2 Running natd between dc0 & dc1 (& that works fine) dc0 gets its IP address, etc., via DHCP/dhclient. dc1 is configured statically & machines connected on that subnet work fine. dc2 should get its ip address, etc. from a Linksys WRT54G, but won't; syslog says "address in use," so I configured it "manually" with ifconfig, to 192.168.1.100/24. Problems/questions: dc2 has a Linksys WRT54G on it, & thus far, that box refuses to talk (not even icmp) with the fbsd machine, even if I set its ip-address & that of dc2 manually. (The Linksys defaults to running a dhcp server & its factory-supplied ip-address is 192.168.1.1 & it "tries" to setup the first interface talking to it to be 192.168.1.100). The router works fine when connecting another machine (running Windows 2000) to it. As examples: $ ping -c3 192.168.0.2 ## this is a Windows2000 box on the dc1 network PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=0.391 ms 64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.177 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.232 ms --- 192.168.0.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.177/0.267/0.391/0.091 ms localhost# tcpdump -lni dc1 ## tcpdump while running the above ping tcpdump: listening on dc1 10:15:39.882162 arp who-has 192.168.0.2 tell 192.168.0.1 10:15:39.882305 arp reply 192.168.0.2 is-at 0:90:27:84:42:f 10:15:39.882318 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:39.882492 192.168.0.2 > 192.168.0.1: icmp: echo reply 10:15:40.883394 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:40.883511 192.168.0.2 > 192.168.0.1: icmp: echo reply 10:15:41.893417 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:41.893584 192.168.0.2 > 192.168.0.1: icmp: echo reply $ ping -c3 192.168.1.1 ## ip address of the router on dc2 PING 192.168.1.1 (192.168.1.1): 56 data bytes --- 192.168.1.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss localhost# tcpdump -lni dc2 ## tcpdump while running the above ping tcpdump: listening on dc2 10:17:18.123385 arp who-has 192.168.1.1 tell 192.168.1.100 10:17:19.124588 arp who-has 192.168.1.1 tell 192.168.1.100 10:17:20.134583 arp who-has 192.168.1.1 tell 192.168.1.100 Any ideas on getting this thing to work? It seems to work fine when connected to a Windows2000 machine. Yes, I've tried other interfaces & cables, etc, so I'm confident the hardware is fine. :) Idea(s) on further troubleshooting/fixing this? FAQs/documentation pointers are quite welcome. :) Thanks, -kc From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 09:44:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7517B16A4D0 for ; Fri, 9 Jan 2004 09:44:17 -0800 (PST) Received: from mx01.bos.ma.towardex.com (a65-124-16-8.svc.towardex.com [65.124.16.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7214E43D6B for ; Fri, 9 Jan 2004 09:44:01 -0800 (PST) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 34F292F906; Fri, 9 Jan 2004 12:44:10 -0500 (EST) Date: Fri, 9 Jan 2004 12:44:10 -0500 From: haesu@towardex.com To: freebsd-net@freebsd.org Message-ID: <20040109174410.GA7749@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Windows 2000 <-> FreeBSD IPsec 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: Fri, 09 Jan 2004 17:44:17 -0000 Hi, I am trying to setup an IPSEC transport between a Windows 2000 box and a FreeBSD server for a customer... Both systems are on live public IP's and packets are not filtered by any intermediate systems or firewalls/routers in between. I have the following setup: Windows 2000 box: 1.1.1.2 FreeBSD Server: 2.2.2.3 (The actual IP's have been changed to above to protect the innocent..) I have racoon setup on the FreeBSD server with following configuration[1] And I have Windows configured correctly (verified many times after Googling and looking at various howto docs...) as well. I will provide more info about how its setup on Windows if anyone wants specific detail. But basically its set using the howto from http://asherah.dyndns.org/~josh/ipsec-howto.txt But when I try to have Windows box ping 2.2.2.3 (going over ipsec that is), I get the following error in the freebsd server running racoon[2]. If anyone can assist with this, I would really appreciate it. I've been scratching my head for a day trying to figure out what's going on.. Thanks! -J !<-------- [1] Racoon Configuration below ---------> path include "/usr/local/etc/racoon" ; path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; # "log" specifies logging level. It is followed by either "notify", "debug" # or "debug2". #log debug; # "padding" defines some parameter of padding. You should not touch these. padding { maximum_length 20; # maximum padding length. randomize off; # enable randomize length. strict_check off; # enable strict check. exclusive_tail off; # extract last one octet. } # if no listen directive is specified, racoon will listen to all # available interface addresses. listen { isakmp 1.1.1.2 [500]; } # Specification of default various timer. timer { # These value can be changed per remote node. counter 5; # maximum trying count to send. interval 20 sec; # maximum interval to resend. persend 1; # the number of packets per a send. # timer for waiting to complete each phase. phase1 15 sec; phase2 30 sec; } remote anonymous { #exchange_mode aggressive,main; doi ipsec_doi; exchange_mode main,aggressive; nonce_size 32; situation identity_only; lifetime time 1 min; # sec,min,hour initial_contact on; support_mip6 on; passive on; proposal_check claim; # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 36000 sec; encryption_algorithm 3des,des,cast128,blowfish ; authentication_algorithm hmac_sha1,hmac_md5; compression_algorithm deflate ; } !<--- End of [1]---> !<-------- [2] Racoon Debug/Error msgs below ---------> # racoon -v -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2004-01-08 15:26:03: INFO: main.c:172:main(): @(#)package version freebsd-20030826a 2004-01-08 15:26:03: INFO: main.c:174:main(): @(#)internal version 20001216 sakane@kame.net 2004-01-08 15:26:03: INFO: main.c:175:main(): @(#)This product linked OpenSSL 0.9.7c 30 Sep 2003 (http://www.openssl.org/) 2004-01-08 15:26:03: WARNING: cftoken.l:514:yywarn(): racoon.conf:49: "support_mip6" it is obsoleted. use "support_proxy". 2004-01-08 15:26:03: INFO: isakmp.c:1358:isakmp_open(): 1.1.1.2[500] used as isakmp port (fd=5) 2004-01-08 15:26:17: INFO: isakmp.c:894:isakmp_ph1begin_r(): respond new phase 1 negotiation: 1.1.1.2[500]<=>2.2.2.3[500] 2004-01-08 15:26:17: INFO: isakmp.c:899:isakmp_ph1begin_r(): begin Identity Protection mode. 2004-01-08 15:26:17: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: MS NT5 ISAKMPOAKLEY 2004-01-08 15:26:17: ERROR: ipsec_doi.c:1318:get_transform(): Only a single transform payload is allowed during phase 1 processing. 2004-01-08 15:26:18: NOTIFY: isakmp.c:255:isakmp_handler(): the packet is retransmitted by 2.2.2.3[500]. 2004-01-08 15:26:20: NOTIFY: isakmp.c:255:isakmp_handler(): the packet is retransmitted by 2.2.2.3[500]. 2004-01-08 15:26:24: NOTIFY: isakmp.c:255:isakmp_handler(): the packet is retransmitted by 2.2.2.3[500]. From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 09:56:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCB2316A4CE; Fri, 9 Jan 2004 09:56:16 -0800 (PST) Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B3D743D41; Fri, 9 Jan 2004 09:56:13 -0800 (PST) (envelope-from anthonyv@brainlink.com) Received: from [24.185.193.147] (HELO superior.local.non-standard.net) by brainlink.com (CommuniGate Pro SMTP 4.1.5) with ESMTP id 26387984; Fri, 09 Jan 2004 12:56:12 -0500 Date: Fri, 9 Jan 2004 12:56:20 -0500 (EST) From: Anthony Volodkin X-X-Sender: anthonyv@superior.local.non-standard.net To: Kenneth W Cochran In-Reply-To: <200401091711.MAA3017414@shell.TheWorld.com> Message-ID: <20040109125221.X14535-100000@superior.local.non-standard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: (revised) 4.0-stable & Linksys WRT54G won't talk w/each other X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 17:56:17 -0000 Hey, Apparently the WRT54G is having some arp issues. I'd check the following: - install latest firmware - install Ethereal on the windows machine and watch the traffic exchange when you would ping/access the WRT54G. It is important that this is done right after boot so that the Windows machine does not have the MAC of WRT54G cached. It'd be interesting to compare the arp requests from the FreeBSD machine to ones from the Win2k one, if that seems at all different. - Finally, I assumed that the cable that you are using to connect the freebsd box to WRT54G is just as good as the one you use with the Windows machine. -Anthony On Fri, 9 Jan 2004, Kenneth W Cochran wrote: > Hello: > > I'm having problems getting a FreeBSD machine and a Linksys > WRT54G talking with each other. > > Interfaces: > dc0 - "public" to outside Internet > dc1 - internal 192.168.0.1/24, connects to a hub > dc2 - internal 192.168.1.100/24, connects to a switched LAN port on the router > dc3 - currently unused > > OS: FreeBSD 4.9-STABLE as of 10 December 2003 > firewall: ipfw2 > Running natd between dc0 & dc1 (& that works fine) > > dc0 gets its IP address, etc., via DHCP/dhclient. > dc1 is configured statically & machines connected on that subnet work fine. > dc2 should get its ip address, etc. from a Linksys WRT54G, > but won't; syslog says "address in use," so I configured it "manually" > with ifconfig, to 192.168.1.100/24. > > Problems/questions: > > dc2 has a Linksys WRT54G on it, & thus far, that box refuses > to talk (not even icmp) with the fbsd machine, even if I set > its ip-address & that of dc2 manually. (The Linksys > defaults to running a dhcp server & its factory-supplied > ip-address is 192.168.1.1 & it "tries" to setup the first > interface talking to it to be 192.168.1.100). The router > works fine when connecting another machine (running Windows > 2000) to it. > > As examples: > $ ping -c3 192.168.0.2 ## this is a Windows2000 box on the dc1 network > PING 192.168.0.2 (192.168.0.2): 56 data bytes > 64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=0.391 ms > 64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.177 ms > 64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.232 ms > > --- 192.168.0.2 ping statistics --- > 3 packets transmitted, 3 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.177/0.267/0.391/0.091 ms > > localhost# tcpdump -lni dc1 ## tcpdump while running the above ping > tcpdump: listening on dc1 > 10:15:39.882162 arp who-has 192.168.0.2 tell 192.168.0.1 > 10:15:39.882305 arp reply 192.168.0.2 is-at 0:90:27:84:42:f > 10:15:39.882318 192.168.0.1 > 192.168.0.2: icmp: echo request > 10:15:39.882492 192.168.0.2 > 192.168.0.1: icmp: echo reply > 10:15:40.883394 192.168.0.1 > 192.168.0.2: icmp: echo request > 10:15:40.883511 192.168.0.2 > 192.168.0.1: icmp: echo reply > 10:15:41.893417 192.168.0.1 > 192.168.0.2: icmp: echo request > 10:15:41.893584 192.168.0.2 > 192.168.0.1: icmp: echo reply > > $ ping -c3 192.168.1.1 ## ip address of the router on dc2 > PING 192.168.1.1 (192.168.1.1): 56 data bytes > > --- 192.168.1.1 ping statistics --- > 3 packets transmitted, 0 packets received, 100% packet loss > > localhost# tcpdump -lni dc2 ## tcpdump while running the above ping > tcpdump: listening on dc2 > 10:17:18.123385 arp who-has 192.168.1.1 tell 192.168.1.100 > 10:17:19.124588 arp who-has 192.168.1.1 tell 192.168.1.100 > 10:17:20.134583 arp who-has 192.168.1.1 tell 192.168.1.100 > > Any ideas on getting this thing to work? It seems to work > fine when connected to a Windows2000 machine. > Yes, I've tried other interfaces & cables, etc, so I'm > confident the hardware is fine. :) > > Idea(s) on further troubleshooting/fixing this? > > FAQs/documentation pointers are quite welcome. :) > > Thanks, > > -kc > _______________________________________________ > 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 Fri Jan 9 12:10:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A26516A4CE; Fri, 9 Jan 2004 12:10:44 -0800 (PST) Received: from TheWorld.com (pcls4-e.std.com [192.74.137.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1828C43D1F; Fri, 9 Jan 2004 12:10:42 -0800 (PST) (envelope-from kwc@shell.TheWorld.com) Received: from shell.TheWorld.com (pip1-5.std.com [192.74.137.185]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id i09KAclt032223; Fri, 9 Jan 2004 15:10:38 -0500 Received: (from kwc@localhost) by shell.TheWorld.com (8.9.3/8.9.3) id PAA15144305; Fri, 9 Jan 2004 15:10:32 -0500 (EST) Date: Fri, 9 Jan 2004 15:10:32 -0500 (EST) From: Kenneth W Cochran Message-Id: <200401092010.PAA15144305@shell.TheWorld.com> To: Anthony Volodkin cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: (revised) 4.*9*-stable & Linksys WRT54G won't talk w/each other X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 20:10:44 -0000 >Date: Fri, 9 Jan 2004 12:56:20 -0500 (EST) >From: Anthony Volodkin >To: Kenneth W Cochran >cc: freebsd-net@freebsd.org, >Subject: Re: (revised) 4.0-stable & Linksys WRT54G won't talk w/each other > >Hey, > >Apparently the WRT54G is having some arp issues. I'd check the following: > >- install latest firmware Have avoided that so far b/c I wanted to be able to do that from FreeBSD, e.g. with tftp... But I might just go ahead & do that via Windows. {shrug} >- install Ethereal on the windows machine and watch the traffic exchange >when you would ping/access the WRT54G. It is important that this is done >right after boot so that the Windows machine does not have the MAC of >WRT54G cached. It'd be interesting to compare the arp requests from the >FreeBSD machine to ones from the Win2k one, if that seems at all >different. Have thought about that too, especially since trying to tcpdump dc2 with the Windows box connected to the Linksys resulted in nothing (the "inside" part of the Linksys is a switch). >- Finally, I assumed that the cable that you are using to connect the >freebsd box to WRT54G is just as good as the one you use with the Windows >machine. Yup, cables & interfaces are all good; 1st thing I checked. >-Anthony -kc >On Fri, 9 Jan 2004, Kenneth W Cochran wrote: > >> Hello: >> >> I'm having problems getting a FreeBSD machine and a Linksys >> WRT54G talking with each other. >> >> Interfaces: >> dc0 - "public" to outside Internet >> dc1 - internal 192.168.0.1/24, connects to a hub >> dc2 - internal 192.168.1.100/24, connects to a switched LAN port on the router >> dc3 - currently unused >> >> OS: FreeBSD 4.9-STABLE as of 10 December 2003 >> firewall: ipfw2 >> Running natd between dc0 & dc1 (& that works fine) >> >> dc0 gets its IP address, etc., via DHCP/dhclient. >> dc1 is configured statically & machines connected on that subnet work fine. >> dc2 should get its ip address, etc. from a Linksys WRT54G, >> but won't; syslog says "address in use," so I configured it "manually" >> with ifconfig, to 192.168.1.100/24. >> >> Problems/questions: >> >> dc2 has a Linksys WRT54G on it, & thus far, that box refuses >> to talk (not even icmp) with the fbsd machine, even if I set >> its ip-address & that of dc2 manually. (The Linksys >> defaults to running a dhcp server & its factory-supplied >> ip-address is 192.168.1.1 & it "tries" to setup the first >> interface talking to it to be 192.168.1.100). The router >> works fine when connecting another machine (running Windows >> 2000) to it. >> >> As examples: >> $ ping -c3 192.168.0.2 ## this is a Windows2000 box on the dc1 network >> PING 192.168.0.2 (192.168.0.2): 56 data bytes >> 64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=0.391 ms >> 64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.177 ms >> 64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.232 ms >> >> --- 192.168.0.2 ping statistics --- >> 3 packets transmitted, 3 packets received, 0% packet loss >> round-trip min/avg/max/stddev = 0.177/0.267/0.391/0.091 ms >> >> localhost# tcpdump -lni dc1 ## tcpdump while running the above ping >> tcpdump: listening on dc1 >> 10:15:39.882162 arp who-has 192.168.0.2 tell 192.168.0.1 >> 10:15:39.882305 arp reply 192.168.0.2 is-at 0:90:27:84:42:f >> 10:15:39.882318 192.168.0.1 > 192.168.0.2: icmp: echo request >> 10:15:39.882492 192.168.0.2 > 192.168.0.1: icmp: echo reply >> 10:15:40.883394 192.168.0.1 > 192.168.0.2: icmp: echo request >> 10:15:40.883511 192.168.0.2 > 192.168.0.1: icmp: echo reply >> 10:15:41.893417 192.168.0.1 > 192.168.0.2: icmp: echo request >> 10:15:41.893584 192.168.0.2 > 192.168.0.1: icmp: echo reply >> >> $ ping -c3 192.168.1.1 ## ip address of the router on dc2 >> PING 192.168.1.1 (192.168.1.1): 56 data bytes >> >> --- 192.168.1.1 ping statistics --- >> 3 packets transmitted, 0 packets received, 100% packet loss >> >> localhost# tcpdump -lni dc2 ## tcpdump while running the above ping >> tcpdump: listening on dc2 >> 10:17:18.123385 arp who-has 192.168.1.1 tell 192.168.1.100 >> 10:17:19.124588 arp who-has 192.168.1.1 tell 192.168.1.100 >> 10:17:20.134583 arp who-has 192.168.1.1 tell 192.168.1.100 >> >> Any ideas on getting this thing to work? It seems to work >> fine when connected to a Windows2000 machine. >> Yes, I've tried other interfaces & cables, etc, so I'm >> confident the hardware is fine. :) >> >> Idea(s) on further troubleshooting/fixing this? >> >> FAQs/documentation pointers are quite welcome. :) >> >> Thanks, >> >> -kc From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 13:28:48 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1CDA16A4CE for ; Fri, 9 Jan 2004 13:28:48 -0800 (PST) Received: from web21508.mail.yahoo.com (web21508.mail.yahoo.com [66.163.169.19]) by mx1.FreeBSD.org (Postfix) with SMTP id 3E60743D48 for ; Fri, 9 Jan 2004 13:28:48 -0800 (PST) (envelope-from afshinbsdbox@yahoo.com) Message-ID: <20040109212848.95871.qmail@web21508.mail.yahoo.com> Received: from [213.185.114.26] by web21508.mail.yahoo.com via HTTP; Fri, 09 Jan 2004 13:28:48 PST Date: Fri, 9 Jan 2004 13:28:48 -0800 (PST) From: afshin To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Wireless Repeater X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 21:28:48 -0000 Dear Friends, How Can I make a wireless repeater BOX ? I just want to extend my network range, So beside the Antenna I think the Repeater is a good choice. What is especiall in wireless repeater ? Cheers, AFShin __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 13:48:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A6AF16A4CE for ; Fri, 9 Jan 2004 13:48:28 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62AD743D1D for ; Fri, 9 Jan 2004 13:48:25 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 62044 invoked from network); 9 Jan 2004 22:04:07 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 9 Jan 2004 22:04:07 -0000 Received: (nullmailer pid 1070 invoked by uid 136); Fri, 09 Jan 2004 21:48:26 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20040108162416.13c13a53.adam.mclaurin@gmx.net> To: Adam McLaurin Date: Sat, 10 Jan 2004 00:48:26 +0300 (MSK) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1073684906.433504.1069.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org cc: q_dolan@yahoo.com.au Subject: Re: Intermittent problems with LAN transfer speeds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 21:48:28 -0000 > On Thu, 08 Jan 2004 13:02:23 +1000 > Q wrote: > > > The first thing you should try is setting the ethernet card to use > > autosense. This enables the autosense pulse to be sent to the switch, > > without this some passive/unmanaged switches can get very confused and > > switch speeds and duplex at seemingly random intervals for a while > > before eventually sorting themselves out again. You should only ever > > set > > speed & duplex manually if you can set it at BOTH ends. > > > > The easiest way to identify this as the problem is to do a 'netstat > > -i' > > and check for collisions. If everything on that LAN segment is full > > duplex all the time, there should be none. You will most likely have > > to > > wait for the problem to occur again before the collisions appear. > > A few things .. > > First, both speed & duplex are set manualyl at both ends. In fact, I did > this more than a year ago as a recommendation to solve this particular > problem we're discussing now. In other words, the problem existed before > I manually set speed/duplex, and afterwards. > > Second, the problem doesn't ever sort itself out. If I don't reboot the > server, the problem continues indefinitely. Does ifconfig xx down; ifconfig xx up helps? Can be packet loss triggered by a lot of small packets on this interface? From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 13:52:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48D5A16A4CE for ; Fri, 9 Jan 2004 13:52:25 -0800 (PST) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 862D443D7F for ; Fri, 9 Jan 2004 13:51:45 -0800 (PST) (envelope-from ghelmer@palisadesys.com) Received: from mira (mira.palisadesys.com [192.188.162.116]) (authenticated bits=0)i09LphIU087014 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 9 Jan 2004 15:51:43 -0600 (CST) (envelope-from ghelmer@palisadesys.com) From: "Guy Helmer" To: "Richard Bejtlich" , Date: Fri, 9 Jan 2004 15:51:43 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040109171717.33976.qmail@web60804.mail.yahoo.com> Importance: Normal X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on magellan.palisadesys.com Subject: RE: Paper on device polling and packet capture performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 21:52:25 -0000 Richard Bejtlich wrote on January 09, 2004 11:17 AM > I was wondering if anyone read the paper by Luca Deri > (of Ntop fame) on "Improving Passive Packet Capture: > Beyond Device Polling": > > http://luca.ntop.org/Ring.pdf > > Luca makes some astounding claims regarding packet > capture performance, with FreeBSD performing very well > when device polling is enabled. Looks interesting. I would hope the packet loss with FreeBSD and polling could be eliminated by tweaking the HZ and kern_frac/user_frac parameters, unless the machine is just too slow to handle the load. However, I think tying directly into the network drivers isn't as general an approach as is working at a little higher level in the system. The network device drivers have been modified in the past to perform special functions (e.g., polling) but it is more useful and less bug-prone to push general functions into the system at other levels (e.g., bridging, which used to have hooks into each network device driver). I want to look at memory-mapped access to the BPF device. This would preserve the existing network device drivers while reducing mbuf copies, context switches/user-kernel transitions, and latency. Performance ought to be comparable to Luca's approach, and this would also preserve bpf filtering capability. (If someone else has already done this, I'd love to know where to find the code!) > A wrote a short and probably naive synopsis for my > Blog: > > http://taosecurity.blogspot.com/2004_01_01_taosecurity_archive.htm > l#107358025105922521 > > Does anyone care to comment on the paper? (I asked > Luca and he agreed to this post.) > > Thank you, > > Richard Bejtlich > http://www.taosecurity.com Thanks for bringing this to my attention! Guy Helmer From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 18:47:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E465916A4CE for ; Fri, 9 Jan 2004 18:47:30 -0800 (PST) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7A9E43D55 for ; Fri, 9 Jan 2004 18:47:29 -0800 (PST) (envelope-from adam.mclaurin@gmx.net) Received: from 146-115-126-186.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com ([146.115.126.186] helo=jake) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.35 #4) id 1Af99s-00004p-00; Fri, 09 Jan 2004 21:47:28 -0500 Date: Fri, 9 Jan 2004 21:47:28 -0500 From: Adam McLaurin To: "."@babolo.ru, freebsd-net@freebsd.org Message-Id: <20040109214728.646bedcc.adam.mclaurin@gmx.net> In-Reply-To: <1073684906.433504.1069.nullmailer@cicuta.babolo.ru> References: <20040108162416.13c13a53.adam.mclaurin@gmx.net> <1073684906.433504.1069.nullmailer@cicuta.babolo.ru> Organization: X-Mailer: Sylpheed version 0.9.5-gtk2-20030906 (GTK+ 2.2.4; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Intermittent problems with LAN transfer speeds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 02:47:31 -0000 On Sat, 10 Jan 2004 00:48:26 +0300 (MSK) .@babolo.ru wrote: > Does > ifconfig xx down; ifconfig xx up > helps? Tried that many many times; no effect. > Can be packet loss triggered by a lot of small > packets on this interface? Not that I've noticed. Any suggestions on how to test this effectively? -- Adam From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 22:11:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A31216A4CE for ; Fri, 9 Jan 2004 22:11:04 -0800 (PST) Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFF8C43D31 for ; Fri, 9 Jan 2004 22:11:01 -0800 (PST) (envelope-from j.telford@sympatico.ca) Received: from johnny2k ([64.229.245.213]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20040110061100.IMKY23150.tomts13-srv.bellnexxia.net@johnny2k>; Sat, 10 Jan 2004 01:11:00 -0500 Message-ID: <003a01c3d742$789b4180$0a00a8c0@johnny2k> From: "John" To: "Adam McLaurin" , References: <20040107151544.6bbab003.adam.mclaurin@gmx.net> Date: Sat, 10 Jan 2004 01:24:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Subject: Re: Intermittent problems with LAN transfer speeds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 06:11:04 -0000 Long - Adam wrote: > Any suggestions on how to test this effectively? SInce this is very intermittant and to the point where you have to reboot my first suggestion: Run top and check for a memory leak from a process. I had this once where apache would slowly use up the memory then all the swap space until after a month the box was thrashing and a restart of apache (or box) was required. In top the more 'Free' on the Mem and the Swap lines the better. Let top run and/or check daily. I also recently discovered that 'screen' when installed using pkg_add is a CPU pig but runs fine when installed from ports. I've had my share of mis-matched switches - usually on the more expensive brands that can't seem to handle auto-negotiate very well (but for the $$$ they should :) and usually on a co-lo's gear or some peering point down the ISP so I had to go out of my way to prove the problem was on their side. The first tests I run are to ping with a large packet size to emulate file transfers and not Internet browsing, this is a common problem I had with ISP techs - They would say "Oh it pings fine, 0% loss" then I have to try and get them to use large packets because file transfers, ftp's are not the same as browsing. Network Testing: I'll assume neither box is under heavy load prior to testing. 192.168.0.10 = W2K box, so from the BSD: ping -i 0.01 -D -p ff -s1472 -c 1000 192.168.0.10 man ping for the option's but a quick rundown: -i 0.01 = interval between in secs. -D - don't fragment the packets -p ff = fill the packets with data. -s 1472 = the size of each packet , if you get a "ping: sendto: Message too long" then reduce this number by 5's. This (1472) was as high as I could go on my LAN. Their is some overhead to the 1500 so you won't get that. If you have to reduce this by a lot to get proper output that would be strange. -c 1000 = number of pings (side bar - I dropped in at a remote site and turned on the console and found I'd left a regular ping running to the next hop. I hadn't visited the site or rebooted the box in 6 months -doh- so I use the '-c' flag now in case I get sidetracked) Now try ping -f -D -p ff -s1472 -c 250000 192.168.0.10 Replace '-i 0.01' with '-f' to do a flood ping, BTW only do this on your own network never public, else you may get visit from your ISP. Bump up the count to -c 250000 or more. For reference my results: ping -f -D -p ff -s1472 -c 250000 192.168.0.10 PATTERN: 0xff PING 192.168.0.10 (192.168.0.10): 1472 data bytes ........... --- 192.168.0.10 ping statistics --- 250000 packets transmitted, 249994 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.610/0.785/54.674/0.264 ms If you get 100% Packet Loss then your firewall is in the way. If you get any other packet loss (well I dropped a few on the flood ping but not enough to bump the %) then it could be hardware on any of the 3 devices or some kind of load on 1 of them. On mismatched duplexes I 've seen between 10-25% packet loss. Another symptom is (on a synchronous link) would be regular speed ftp transfers in one direction and very slow in the other direction. Some Inexpensive hardware checks: Put in a crossover cable between the 2 systems thus eliminating the switch and retest. Borrow another NIC and re-test in both boxes. Probably won't help and only if you are comfortable doing it - enter the BIOS on each box and change the settings for IRQ's and see if you can get the NIC's on separate IRQ #'s - try to keep the video IRQ off the NIC's On my BSD servers I also always do this plus disable the USB, printer and serial ports if not in use. Could it be hard disk errors/retry's on either box ? If the room is quiet you might be able to hear it - check the logs. Software tools for the BSD side. Install the port (or package) 'trafshow' and then have it running on consoles for each card. trafshow -nifxp0 trafshow -nidc0 When you get the slowdowns you can see if something other than your transfer is going on. Check to see if someone is bashing on your public connection, but for 2 years probably not :) Take the public NIC down during these slowdowns to see what happens. Good luck let us know how you make out. Regards, JT Adam's History: > Since I first installed FreeBSD 2 years ago, I have intermittent > problems with my LAN transfer speeds. It doesn't happen often, but when > it does, I've not found any solution other than rebooting the server. > > My network configuration looks like this: > cable modem --> freebsd 5.1-R --> dlink switch --> win2k workstation > > I normally get appx 10MB/s between my two machines. However, > occasionally I'll fire up a transfer and only get 50-200KB/s, which is > really awful. > > I've tried rebooting the Win2k machine, disconnecting the ethernet > cables, even power cycling the switch; nothing helps. > > The only thing that seems to help is rebooting the server, which I > really hate to do. > Here's the output of ifconfig: > -$ ifconfig > fxp0: flags=8843 mtu 1500 > options=3 > inet 192.168.56.2 netmask 0xffffff00 broadcast 192.168.56.255 > ether 00:02:b3:a8:1d:19 > media: Ethernet 100baseTX > status: active > dc0: flags=8843 mtu 1500 > inet 146.115.***.*** netmask 0xffffff00 broadcast > 255.255.255.255 ether 00:04:5a:7b:a7:d0 > media: Ethernet autoselect (100baseTX ) > status: active From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 05:51:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EB8416A4CE for ; Sat, 10 Jan 2004 05:51:22 -0800 (PST) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DA5643D31 for ; Sat, 10 Jan 2004 05:51:20 -0800 (PST) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 12907 invoked from network); 10 Jan 2004 14:07:05 -0000 Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160) by ints.mail.pike.ru with SMTP; 10 Jan 2004 14:07:05 -0000 Received: (nullmailer pid 10392 invoked by uid 136); Sat, 10 Jan 2004 13:51:23 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20040109214728.646bedcc.adam.mclaurin@gmx.net> To: Adam McLaurin Date: Sat, 10 Jan 2004 16:51:23 +0300 (MSK) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1073742683.946126.10391.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org Subject: Re: Intermittent problems with LAN transfer speeds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 13:51:22 -0000 > On Sat, 10 Jan 2004 00:48:26 +0300 (MSK) > .@babolo.ru wrote: > > Does > > ifconfig xx down; ifconfig xx up > > helps? > Tried that many many times; no effect. > > > Can be packet loss triggered by a lot of small > > packets on this interface? > Not that I've noticed. Any suggestions on how to test this effectively? I have router with some ste interfaces, simple try to ping /23 at once effectively shuts perfomanse forever, down/up restores. From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 06:11:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4642C16A4CE; Sat, 10 Jan 2004 06:11:14 -0800 (PST) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8FEC43D2D; Sat, 10 Jan 2004 06:11:11 -0800 (PST) (envelope-from zec@tel.fer.hr) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id AC95C9B64A; Sat, 10 Jan 2004 15:11:09 +0100 (CET) Received: from marko-tp.zavod.tel.fer.hr (marko-tp.zavod.tel.fer.hr [161.53.19.14]) by xaqua.tel.fer.hr (Postfix) with ESMTP id BC9C19B647; Sat, 10 Jan 2004 15:11:05 +0100 (CET) From: Marko Zec To: Lorenzo Vicisano , freebsd-mobile@freebsd.org Date: Sat, 10 Jan 2004 15:11:04 +0100 User-Agent: KMail/1.5.4 References: <20040109184349.A12711@cisco.com> In-Reply-To: <20040109184349.A12711@cisco.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_4fAAAunGWPP68/U" Message-Id: <200401101511.04672.zec@tel.fer.hr> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL autolearn=no version=2.61 X-Sanitizer: Advosys mail filter cc: freebsd-net@freebsd.org Subject: Re: prism 2.5 timeout in wi_cmd 0x010b X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 14:11:14 -0000 --Boundary-00=_4fAAAunGWPP68/U Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Lorenzo, can you try the attached patch, it does seem to help on my ThinkPad X30, which has an internal mini-PCI Prism2.5 card with the same firmware. Cheers, Marko On Saturday 10 January 2004 03:43, Lorenzo Vicisano wrote: > Hi, > > This is the context: > > - Stable as of Jan 9 (FreeBSD 4.9-STABLE #14: Fri Jan 9 15:04:16 > PST 2004) The problem was present since Dec 22.. at least. > > - Linksys PCI WMP11/Prism: > > wi0: mem 0xf8a02000-0xf8a02fff irq 5 at device > 11.0 on pci2 wi0: 802.11 address: 00:06:25:09:a7:8f > wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) > wi0: Intersil Firmware: Primary 1.01.00, Station 1.04.02 > > acting as a client. The AP is a DLink 614+ (I've tried various > versions of the firmware). > > - High volume of transmitted traffic (ftp-ed a few MBs within the > WLAN). Either towards the AP or towards other clients (E.g. > AN350). > > And this is the symptom: > > wi0: timeout in wi_cmd 0x010b; event status 0x0000 > wi0: xmit failed > > after this the NIC is dead. > Sometimes the box freezes for a few seconds, sometimes it doesn't. > Most of the times the NIC doesn't resume unless it brought up/down > (ifconfig down/up). > > More messages (after the NIC stops working): > > wi0: watchdog timeout > wi0: timeout in wi_cmd 0x0002; event status 0x0000 > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: init failed > wi0: watchdog timeout > > Complete log attached. I'm able to reproduce this consistently ;( > I can do some debugging and provide more info, if needed. > > thanks, > Lorenzo --Boundary-00=_4fAAAunGWPP68/U Content-Type: text/x-diff; charset="iso-8859-2"; name="wi.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="wi.diff" --- if_wi.c.orig Wed Jan 7 15:55:18 2004 +++ if_wi.c Wed Jan 7 16:38:37 2004 @@ -1016,9 +1016,11 @@ wi_cmd(sc, cmd, val0, val1, val2) * set in the event status register. */ s = CSR_READ_2(sc, WI_EVENT_STAT); + DELAY(1); if (s & WI_EV_CMD) { /* Ack the event and read result code. */ s = CSR_READ_2(sc, WI_STATUS); + DELAY(1); CSR_WRITE_2(sc, WI_EVENT_ACK, WI_EV_CMD); #ifdef foo if ((s & WI_CMD_CODE_MASK) != (cmd & WI_CMD_CODE_MASK)) --Boundary-00=_4fAAAunGWPP68/U-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 08:39:42 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2F0B16A4CE; Sat, 10 Jan 2004 08:39:42 -0800 (PST) Received: from mail.mcmilleon.com (12-221-223-132.client.insightBB.com [12.221.223.132]) by mx1.FreeBSD.org (Postfix) with SMTP id EAEA443D1F; Sat, 10 Jan 2004 08:39:37 -0800 (PST) (envelope-from kwc@TheWorld.com) Received: from sccigwc01.asp.att.net ([63.240.76.150]) by sccigwc01.asp.att.netESMTP <20040109173101.YGX3446.sccigwc01.asp.att.net@sccigwc01.asp.att.net> for ; Fri, 9 Jan 2004 17:31:01 +0000 Received: from mail2.dnsvr.com ([216.40.250.39]) by sccigwc01.asp.att.net (sccigwc01) with ESMTP id <20040109173100ig1003sd62e>; Fri, 9 Jan 2004 17:31:00 +0000 Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by mail2.dnsvr.com (Postfix) with ESMTP id 7A03DA5DF6 for ; Fri, 9 Jan 2004 12:31:00 -0500 (EST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 1DD9B56C95; Fri, 9 Jan 2004 09:30:32 -0800 (PST) (envelope-from owner-freebsd-questions@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9C12B16A549; Fri, 9 Jan 2004 09:30:16 -0800 (PST) Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D80F916A4CE; Fri, 9 Jan 2004 09:29:51 -0800 (PST) Received: from TheWorld.com (pcls3.std.com [192.74.137.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0689C43D4C; Fri, 9 Jan 2004 09:29:50 -0800 (PST) (envelope-from kwc@shell.TheWorld.com) Received: from shell.TheWorld.com (pip1-5.std.com [192.74.137.185]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id i09HQuJi012526; Fri, 9 Jan 2004 12:29:42 -0500 Received: (from kwc@localhost) by shell.TheWorld.com (8.9.3/8.9.3) id MAA3017414; Fri, 9 Jan 2004 12:11:48 -0500 (EST) Date: Fri, 9 Jan 2004 12:11:48 -0500 (EST) From: Kenneth W Cochran Message-Id: <25054444.1073684105958.JavaMail.root@mail.mcmilleon.com> To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-questions@freebsd.org Errors-To: owner-freebsd-questions@freebsd.org X-fetched-from: insightbb Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Subject: (revised) 4.0-stable & Linksys WRT54G won't talk w/each other X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 16:39:42 -0000 Hello: I'm having problems getting a FreeBSD machine and a Linksys WRT54G talking with each other. Interfaces: dc0 - "public" to outside Internet dc1 - internal 192.168.0.1/24, connects to a hub dc2 - internal 192.168.1.100/24, connects to a switched LAN port on the router dc3 - currently unused OS: FreeBSD 4.9-STABLE as of 10 December 2003 firewall: ipfw2 Running natd between dc0 & dc1 (& that works fine) dc0 gets its IP address, etc., via DHCP/dhclient. dc1 is configured statically & machines connected on that subnet work fine. dc2 should get its ip address, etc. from a Linksys WRT54G, but won't; syslog says "address in use," so I configured it "manually" with ifconfig, to 192.168.1.100/24. Problems/questions: dc2 has a Linksys WRT54G on it, & thus far, that box refuses to talk (not even icmp) with the fbsd machine, even if I set its ip-address & that of dc2 manually. (The Linksys defaults to running a dhcp server & its factory-supplied ip-address is 192.168.1.1 & it "tries" to setup the first interface talking to it to be 192.168.1.100). The router works fine when connecting another machine (running Windows 2000) to it. As examples: $ ping -c3 192.168.0.2 ## this is a Windows2000 box on the dc1 network PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=0.391 ms 64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.177 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.232 ms --- 192.168.0.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.177/0.267/0.391/0.091 ms localhost# tcpdump -lni dc1 ## tcpdump while running the above ping tcpdump: listening on dc1 10:15:39.882162 arp who-has 192.168.0.2 tell 192.168.0.1 10:15:39.882305 arp reply 192.168.0.2 is-at 0:90:27:84:42:f 10:15:39.882318 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:39.882492 192.168.0.2 > 192.168.0.1: icmp: echo reply 10:15:40.883394 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:40.883511 192.168.0.2 > 192.168.0.1: icmp: echo reply 10:15:41.893417 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:41.893584 192.168.0.2 > 192.168.0.1: icmp: echo reply $ ping -c3 192.168.1.1 ## ip address of the router on dc2 PING 192.168.1.1 (192.168.1.1): 56 data bytes --- 192.168.1.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss localhost# tcpdump -lni dc2 ## tcpdump while running the above ping tcpdump: listening on dc2 10:17:18.123385 arp who-has 192.168.1.1 tell 192.168.1.100 10:17:19.124588 arp who-has 192.168.1.1 tell 192.168.1.100 10:17:20.134583 arp who-has 192.168.1.1 tell 192.168.1.100 Any ideas on getting this thing to work? It seems to work fine when connected to a Windows2000 machine. Yes, I've tried other interfaces & cables, etc, so I'm confident the hardware is fine. :) Idea(s) on further troubleshooting/fixing this? FAQs/documentation pointers are quite welcome. :) Thanks, -kc _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 08:43:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 335F416A4CE; Sat, 10 Jan 2004 08:43:11 -0800 (PST) Received: from mail.mcmilleon.com (12-221-223-132.client.insightBB.com [12.221.223.132]) by mx1.FreeBSD.org (Postfix) with SMTP id 2767843D3F; Sat, 10 Jan 2004 08:43:06 -0800 (PST) (envelope-from kwc@TheWorld.com) Received: from sccigwc02.asp.att.net ([127.0.0.1]) by sccigwc02.asp.att.net ESMTP <20040109201229.VMOL20059.sccigwc02.asp.att.net@sccigwc02.asp.att.net> for ; Fri, 9 Jan 2004 20:12:29 +0000 Received: from mail2.dnsvr.com ([216.40.250.39]) by sccigwc02.asp.att.net (sccigwc02) with ESMTP id <20040109201146ig200kcm3qe>; Fri, 9 Jan 2004 20:11:46 +0000 Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by mail2.dnsvr.com (Postfix) with ESMTP id 7ECA1A5812 for ; Fri, 9 Jan 2004 15:11:44 -0500 (EST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id AF73E56A29; Fri, 9 Jan 2004 12:11:21 -0800 (PST) (envelope-from owner-freebsd-questions@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E3DC416A4F0; Fri, 9 Jan 2004 12:11:19 -0800 (PST) Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A26516A4CE; Fri, 9 Jan 2004 12:10:44 -0800 (PST) Received: from TheWorld.com (pcls4-e.std.com [192.74.137.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1828C43D1F; Fri, 9 Jan 2004 12:10:42 -0800 (PST) (envelope-from kwc@shell.TheWorld.com) Received: from shell.TheWorld.com (pip1-5.std.com [192.74.137.185]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id i09KAclt032223; Fri, 9 Jan 2004 15:10:38 -0500 Received: (from kwc@localhost) by shell.TheWorld.com (8.9.3/8.9.3) id PAA15144305; Fri, 9 Jan 2004 15:10:32 -0500 (EST) Date: Fri, 9 Jan 2004 15:10:32 -0500 (EST) From: Kenneth W Cochran Message-Id: <10943145.1073684114560.JavaMail.root@mail.mcmilleon.com> To: Anthony Volodkin X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-questions@freebsd.org Errors-To: owner-freebsd-questions@freebsd.org X-fetched-from: insightbb Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: (revised) 4.*9*-stable & Linksys WRT54G won't talk w/each other X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 16:43:11 -0000 >Date: Fri, 9 Jan 2004 12:56:20 -0500 (EST) >From: Anthony Volodkin >To: Kenneth W Cochran >cc: freebsd-net@freebsd.org, >Subject: Re: (revised) 4.0-stable & Linksys WRT54G won't talk w/each other > >Hey, > >Apparently the WRT54G is having some arp issues. I'd check the following: > >- install latest firmware Have avoided that so far b/c I wanted to be able to do that from FreeBSD, e.g. with tftp... But I might just go ahead & do that via Windows. {shrug} >- install Ethereal on the windows machine and watch the traffic exchange >when you would ping/access the WRT54G. It is important that this is done >right after boot so that the Windows machine does not have the MAC of >WRT54G cached. It'd be interesting to compare the arp requests from the >FreeBSD machine to ones from the Win2k one, if that seems at all >different. Have thought about that too, especially since trying to tcpdump dc2 with the Windows box connected to the Linksys resulted in nothing (the "inside" part of the Linksys is a switch). >- Finally, I assumed that the cable that you are using to connect the >freebsd box to WRT54G is just as good as the one you use with the Windows >machine. Yup, cables & interfaces are all good; 1st thing I checked. >-Anthony -kc >On Fri, 9 Jan 2004, Kenneth W Cochran wrote: > >> Hello: >> >> I'm having problems getting a FreeBSD machine and a Linksys >> WRT54G talking with each other. >> >> Interfaces: >> dc0 - "public" to outside Internet >> dc1 - internal 192.168.0.1/24, connects to a hub >> dc2 - internal 192.168.1.100/24, connects to a switched LAN port on the router >> dc3 - currently unused >> >> OS: FreeBSD 4.9-STABLE as of 10 December 2003 >> firewall: ipfw2 >> Running natd between dc0 & dc1 (& that works fine) >> >> dc0 gets its IP address, etc., via DHCP/dhclient. >> dc1 is configured statically & machines connected on that subnet work fine. >> dc2 should get its ip address, etc. from a Linksys WRT54G, >> but won't; syslog says "address in use," so I configured it "manually" >> with ifconfig, to 192.168.1.100/24. >> >> Problems/questions: >> >> dc2 has a Linksys WRT54G on it, & thus far, that box refuses >> to talk (not even icmp) with the fbsd machine, even if I set >> its ip-address & that of dc2 manually. (The Linksys >> defaults to running a dhcp server & its factory-supplied >> ip-address is 192.168.1.1 & it "tries" to setup the first >> interface talking to it to be 192.168.1.100). The router >> works fine when connecting another machine (running Windows >> 2000) to it. >> >> As examples: >> $ ping -c3 192.168.0.2 ## this is a Windows2000 box on the dc1 network >> PING 192.168.0.2 (192.168.0.2): 56 data bytes >> 64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=0.391 ms >> 64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.177 ms >> 64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.232 ms >> >> --- 192.168.0.2 ping statistics --- >> 3 packets transmitted, 3 packets received, 0% packet loss >> round-trip min/avg/max/stddev = 0.177/0.267/0.391/0.091 ms >> >> localhost# tcpdump -lni dc1 ## tcpdump while running the above ping >> tcpdump: listening on dc1 >> 10:15:39.882162 arp who-has 192.168.0.2 tell 192.168.0.1 >> 10:15:39.882305 arp reply 192.168.0.2 is-at 0:90:27:84:42:f >> 10:15:39.882318 192.168.0.1 > 192.168.0.2: icmp: echo request >> 10:15:39.882492 192.168.0.2 > 192.168.0.1: icmp: echo reply >> 10:15:40.883394 192.168.0.1 > 192.168.0.2: icmp: echo request >> 10:15:40.883511 192.168.0.2 > 192.168.0.1: icmp: echo reply >> 10:15:41.893417 192.168.0.1 > 192.168.0.2: icmp: echo request >> 10:15:41.893584 192.168.0.2 > 192.168.0.1: icmp: echo reply >> >> $ ping -c3 192.168.1.1 ## ip address of the router on dc2 >> PING 192.168.1.1 (192.168.1.1): 56 data bytes >> >> --- 192.168.1.1 ping statistics --- >> 3 packets transmitted, 0 packets received, 100% packet loss >> >> localhost# tcpdump -lni dc2 ## tcpdump while running the above ping >> tcpdump: listening on dc2 >> 10:17:18.123385 arp who-has 192.168.1.1 tell 192.168.1.100 >> 10:17:19.124588 arp who-has 192.168.1.1 tell 192.168.1.100 >> 10:17:20.134583 arp who-has 192.168.1.1 tell 192.168.1.100 >> >> Any ideas on getting this thing to work? It seems to work >> fine when connected to a Windows2000 machine. >> Yes, I've tried other interfaces & cables, etc, so I'm >> confident the hardware is fine. :) >> >> Idea(s) on further troubleshooting/fixing this? >> >> FAQs/documentation pointers are quite welcome. :) >> >> Thanks, >> >> -kc _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 08:46:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66A8716A4CE; Sat, 10 Jan 2004 08:46:41 -0800 (PST) Received: from mail.mcmilleon.com (12-221-223-132.client.insightBB.com [12.221.223.132]) by mx1.FreeBSD.org (Postfix) with SMTP id 6C7D243D4C; Sat, 10 Jan 2004 08:46:28 -0800 (PST) (envelope-from kwc@TheWorld.com) Received: from sccigwc01.asp.att.net ([63.240.76.150]) by sccigwc01.asp.att.netESMTP <20040109173132.YRA3446.sccigwc01.asp.att.net@sccigwc01.asp.att.net> for ; Fri, 9 Jan 2004 17:31:32 +0000 Received: from mail2.dnsvr.com ([216.40.250.39]) by sccigwc01.asp.att.net (sccigwc01) with ESMTP id <20040109173130ig1003t36he>; Fri, 9 Jan 2004 17:31:30 +0000 Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by mail2.dnsvr.com (Postfix) with ESMTP id 1976FA5D85 for ; Fri, 9 Jan 2004 12:31:30 -0500 (EST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 9E5A156EA7; Fri, 9 Jan 2004 09:30:48 -0800 (PST) (envelope-from owner-freebsd-questions@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 558BD16A50D; Fri, 9 Jan 2004 09:30:40 -0800 (PST) Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C5B316A541; Fri, 9 Jan 2004 09:30:16 -0800 (PST) Received: from TheWorld.com (pcls3.std.com [192.74.137.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CD6343D3F; Fri, 9 Jan 2004 09:30:13 -0800 (PST) (envelope-from kwc@shell.TheWorld.com) Received: from shell.TheWorld.com (pip1-5.std.com [192.74.137.185]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id i09HQuJk012526; Fri, 9 Jan 2004 12:29:42 -0500 Received: (from kwc@localhost) by shell.TheWorld.com (8.9.3/8.9.3) id MAA15061483; Fri, 9 Jan 2004 12:15:11 -0500 (EST) Date: Fri, 9 Jan 2004 12:15:11 -0500 (EST) From: Kenneth W Cochran Message-Id: <4500574.1073684107622.JavaMail.root@mail.mcmilleon.com> To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-questions@freebsd.org Errors-To: owner-freebsd-questions@freebsd.org X-fetched-from: insightbb Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Subject: (revised) 4.*9*-stable & Linksys WRT54G won't talk w/each other X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 16:46:41 -0000 oops, mistype, that should've been 4.9-stable instead of 4.0... stupidfingers... Hello: I'm having problems getting a FreeBSD machine and a Linksys WRT54G talking with each other. Interfaces: dc0 - "public" to outside Internet dc1 - internal 192.168.0.1/24, connects to a hub dc2 - internal 192.168.1.100/24, connects to a switched LAN port on the router dc3 - currently unused OS: FreeBSD 4.9-STABLE as of 10 December 2003 firewall: ipfw2 Running natd between dc0 & dc1 (& that works fine) dc0 gets its IP address, etc., via DHCP/dhclient. dc1 is configured statically & machines connected on that subnet work fine. dc2 should get its ip address, etc. from a Linksys WRT54G, but won't; syslog says "address in use," so I configured it "manually" with ifconfig, to 192.168.1.100/24. Problems/questions: dc2 has a Linksys WRT54G on it, & thus far, that box refuses to talk (not even icmp) with the fbsd machine, even if I set its ip-address & that of dc2 manually. (The Linksys defaults to running a dhcp server & its factory-supplied ip-address is 192.168.1.1 & it "tries" to setup the first interface talking to it to be 192.168.1.100). The router works fine when connecting another machine (running Windows 2000) to it. As examples: $ ping -c3 192.168.0.2 ## this is a Windows2000 box on the dc1 network PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=0.391 ms 64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.177 ms 64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.232 ms --- 192.168.0.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.177/0.267/0.391/0.091 ms localhost# tcpdump -lni dc1 ## tcpdump while running the above ping tcpdump: listening on dc1 10:15:39.882162 arp who-has 192.168.0.2 tell 192.168.0.1 10:15:39.882305 arp reply 192.168.0.2 is-at 0:90:27:84:42:f 10:15:39.882318 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:39.882492 192.168.0.2 > 192.168.0.1: icmp: echo reply 10:15:40.883394 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:40.883511 192.168.0.2 > 192.168.0.1: icmp: echo reply 10:15:41.893417 192.168.0.1 > 192.168.0.2: icmp: echo request 10:15:41.893584 192.168.0.2 > 192.168.0.1: icmp: echo reply $ ping -c3 192.168.1.1 ## ip address of the router on dc2 PING 192.168.1.1 (192.168.1.1): 56 data bytes --- 192.168.1.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss localhost# tcpdump -lni dc2 ## tcpdump while running the above ping tcpdump: listening on dc2 10:17:18.123385 arp who-has 192.168.1.1 tell 192.168.1.100 10:17:19.124588 arp who-has 192.168.1.1 tell 192.168.1.100 10:17:20.134583 arp who-has 192.168.1.1 tell 192.168.1.100 Any ideas on getting this thing to work? It seems to work fine when connected to a Windows2000 machine. Yes, I've tried other interfaces & cables, etc, so I'm confident the hardware is fine. :) Idea(s) on further troubleshooting/fixing this? FAQs/documentation pointers are quite welcome. :) Thanks, -kc _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 08:52:46 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 350DD16A4CE; Sat, 10 Jan 2004 08:52:46 -0800 (PST) Received: from mail.mcmilleon.com (12-221-223-132.client.insightBB.com [12.221.223.132]) by mx1.FreeBSD.org (Postfix) with SMTP id A936543D39; Sat, 10 Jan 2004 08:52:41 -0800 (PST) (envelope-from anthonyv@brainlink.com) Received: from sccimhc01.asp.att.net ([127.0.0.1]) by sccimhc01.asp.att.net ESMTP <20040109175710.RCLD12088.sccimhc01.asp.att.net@sccimhc01.asp.att.net> for ; Fri, 9 Jan 2004 17:57:10 +0000 Received: from mail2.dnsvr.com ([216.40.250.39]) by sccimhc01.asp.att.net (sccimhc01) with ESMTP id <20040109175709im100cil5ne>; Fri, 9 Jan 2004 17:57:09 +0000 Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by mail2.dnsvr.com (Postfix) with ESMTP id 2999E9178C for ; Fri, 9 Jan 2004 12:57:05 -0500 (EST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 7D26856D98; Fri, 9 Jan 2004 09:56:43 -0800 (PST) (envelope-from owner-freebsd-questions@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1DF6216A4E4; Fri, 9 Jan 2004 09:56:42 -0800 (PST) Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCB2316A4CE; Fri, 9 Jan 2004 09:56:16 -0800 (PST) Received: from brainlink.com (mail.brainlink.com [66.228.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B3D743D41; Fri, 9 Jan 2004 09:56:13 -0800 (PST) (envelope-from anthonyv@brainlink.com) Received: from [24.185.193.147] (HELO superior.local.non-standard.net) by brainlink.com (CommuniGate Pro SMTP 4.1.5) with ESMTP id 26387984; Fri, 09 Jan 2004 12:56:12 -0500 Date: Fri, 9 Jan 2004 12:56:20 -0500 (EST) From: Anthony Volodkin X-X-Sender: anthonyv@superior.local.non-standard.net To: Kenneth W Cochran In-Reply-To: <200401091711.MAA3017414@shell.TheWorld.com> Message-ID: <18326726.1073684108018.JavaMail.root@mail.mcmilleon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-questions@freebsd.org Errors-To: owner-freebsd-questions@freebsd.org X-fetched-from: insightbb Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: (revised) 4.0-stable & Linksys WRT54G won't talk w/each other X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 16:52:46 -0000 Hey, Apparently the WRT54G is having some arp issues. I'd check the following: - install latest firmware - install Ethereal on the windows machine and watch the traffic exchange when you would ping/access the WRT54G. It is important that this is done right after boot so that the Windows machine does not have the MAC of WRT54G cached. It'd be interesting to compare the arp requests from the FreeBSD machine to ones from the Win2k one, if that seems at all different. - Finally, I assumed that the cable that you are using to connect the freebsd box to WRT54G is just as good as the one you use with the Windows machine. -Anthony On Fri, 9 Jan 2004, Kenneth W Cochran wrote: > Hello: > > I'm having problems getting a FreeBSD machine and a Linksys > WRT54G talking with each other. > > Interfaces: > dc0 - "public" to outside Internet > dc1 - internal 192.168.0.1/24, connects to a hub > dc2 - internal 192.168.1.100/24, connects to a switched LAN port on the router > dc3 - currently unused > > OS: FreeBSD 4.9-STABLE as of 10 December 2003 > firewall: ipfw2 > Running natd between dc0 & dc1 (& that works fine) > > dc0 gets its IP address, etc., via DHCP/dhclient. > dc1 is configured statically & machines connected on that subnet work fine. > dc2 should get its ip address, etc. from a Linksys WRT54G, > but won't; syslog says "address in use," so I configured it "manually" > with ifconfig, to 192.168.1.100/24. > > Problems/questions: > > dc2 has a Linksys WRT54G on it, & thus far, that box refuses > to talk (not even icmp) with the fbsd machine, even if I set > its ip-address & that of dc2 manually. (The Linksys > defaults to running a dhcp server & its factory-supplied > ip-address is 192.168.1.1 & it "tries" to setup the first > interface talking to it to be 192.168.1.100). The router > works fine when connecting another machine (running Windows > 2000) to it. > > As examples: > $ ping -c3 192.168.0.2 ## this is a Windows2000 box on the dc1 network > PING 192.168.0.2 (192.168.0.2): 56 data bytes > 64 bytes from 192.168.0.2: icmp_seq=0 ttl=128 time=0.391 ms > 64 bytes from 192.168.0.2: icmp_seq=1 ttl=128 time=0.177 ms > 64 bytes from 192.168.0.2: icmp_seq=2 ttl=128 time=0.232 ms > > --- 192.168.0.2 ping statistics --- > 3 packets transmitted, 3 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.177/0.267/0.391/0.091 ms > > localhost# tcpdump -lni dc1 ## tcpdump while running the above ping > tcpdump: listening on dc1 > 10:15:39.882162 arp who-has 192.168.0.2 tell 192.168.0.1 > 10:15:39.882305 arp reply 192.168.0.2 is-at 0:90:27:84:42:f > 10:15:39.882318 192.168.0.1 > 192.168.0.2: icmp: echo request > 10:15:39.882492 192.168.0.2 > 192.168.0.1: icmp: echo reply > 10:15:40.883394 192.168.0.1 > 192.168.0.2: icmp: echo request > 10:15:40.883511 192.168.0.2 > 192.168.0.1: icmp: echo reply > 10:15:41.893417 192.168.0.1 > 192.168.0.2: icmp: echo request > 10:15:41.893584 192.168.0.2 > 192.168.0.1: icmp: echo reply > > $ ping -c3 192.168.1.1 ## ip address of the router on dc2 > PING 192.168.1.1 (192.168.1.1): 56 data bytes > > --- 192.168.1.1 ping statistics --- > 3 packets transmitted, 0 packets received, 100% packet loss > > localhost# tcpdump -lni dc2 ## tcpdump while running the above ping > tcpdump: listening on dc2 > 10:17:18.123385 arp who-has 192.168.1.1 tell 192.168.1.100 > 10:17:19.124588 arp who-has 192.168.1.1 tell 192.168.1.100 > 10:17:20.134583 arp who-has 192.168.1.1 tell 192.168.1.100 > > Any ideas on getting this thing to work? It seems to work > fine when connected to a Windows2000 machine. > Yes, I've tried other interfaces & cables, etc, so I'm > confident the hardware is fine. :) > > Idea(s) on further troubleshooting/fixing this? > > FAQs/documentation pointers are quite welcome. :) > > Thanks, > > -kc > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 09:47:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 943FE16A4D2; Sat, 10 Jan 2004 09:47:06 -0800 (PST) Received: from sizone.org (mortar.sizone.org [65.126.154.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D0A743D48; Sat, 10 Jan 2004 09:47:05 -0800 (PST) (envelope-from dgilbert@daveg.ca) Received: by sizone.org (Postfix, from userid 66) id CAE63307BD; Sat, 10 Jan 2004 12:47:04 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id 6A7941D1F65; Sat, 10 Jan 2004 12:35:46 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16384.14322.83258.940369@canoe.dclg.ca> Date: Sat, 10 Jan 2004 12:35:46 -0500 To: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid Subject: off-by-one error in ip_fragment, recently. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 17:47:06 -0000 I just updated a machine that uses GRE to -CURRENT. Upon rebooting, the debugger stopped at the following: "panic: m_copym, offset > size of mbuf chain" panic() m_copym() ip_fragment() ip_output() gre_output() ip_output() udp_output() upd_send() sosend() kern_sendit() sendit() sendto() syscall() xint0x80_syscall() ... now I'm not sure that the error is perfectly technically off-by-one, but its something similar. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 10:09:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5081216A4CE for ; Sat, 10 Jan 2004 10:09:30 -0800 (PST) Received: from Greenmantis.net (130-94-162-101-dsl.hevanet.com [130.94.162.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 832F643D3F for ; Sat, 10 Jan 2004 10:09:25 -0800 (PST) (envelope-from aburke@nullplusone.com) Received: from thebe ([199.26.172.103]) by Greenmantis.net (8.12.10/8.12.10) with SMTP id i0A6Leq7043235; Fri, 9 Jan 2004 22:21:43 -0800 (PST) (envelope-from aburke@nullplusone.com) From: "Aaron Burke" To: "afshin" , Date: Sat, 10 Jan 2004 10:08:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20031230200830.59615.qmail@web21506.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: RE: 3NIC+ 2NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 18:09:30 -0000 > I have 3 Nics lets name them NIC1-NIC2-NIC3 > NIC1 --> Internal Network /24 > NIC2 --> OutSide World (A) > NIC2 --> OutSide World (B) I have a similar situation (I think). I also have two seperate connections to the internet. fxp0: 11.22.33.44 gateway 11.22.33.1 fxp1: 66.77.88.99 gateway 66.77.88.1 fxp2: 192.168.0.1/24 > > I want to NAT NIC1/25 on NIC2 and NIC1(128)/25 on > NIC3. Are you saying that you want certain packets to leave through NIC1, and others to leave through NIC2? If this is the case, I dont have a solution. However, if you have two connections in case one goes down, then read on. > But the FreeBSD 4.8 Doesn't fo it on both interfaces > it does just on the one that the default gateway (of > the 4.8 with 3 NIICs)refers to. > I Have Entered: > # natd -interface NIC2 > # natd-interface NIC3 (This Gives Error) > and Using "ipnat" I am guesing that you want to create a semi-redundant connection to the internet. For those occations when one of the interfaces goes down. The problem with doing all of this in /etc/rc.conf is that the other rc files only expect one interface to be the default. There are several things that need to be considdered for this to work. And the bad news is that when one of the interfaces goes down, I still have to manually change the default gateway. The good news is that its all the work that has to be done. > > Any comments is appreciated so much > Regards, My comments are my solution, which works great, except that I still have to manually change the default route to get it to work. Please let me know if I am off track here. Step 1: Comment out the lines in /etc/rc.conf that control natd. I have created a script placed in /usr/local/etc/rc.d/fxp0-natd.sh and /usr/local/etc/rc.d/fxp1-natd.sh . Step 2: I edited /etc/services and added the following line. (I am unsure if this was needed, but I added it just to be safe) natd2 8669/divert # Network Address Translation Step 3: I created the following files that actually start up natd on each internet connected interface. Notice that one uses 8668 (natd) and one uses 8669 (natd2) (This may get destroyed by an email client, so I have attached them both. Just to be safe) # /usr/local/etc/rc.d/fxp0-natd.sh with execute bit set #!/bin/sh if [ $# -eq 0 -o x$1 = xstart ]; then /sbin/natd -p natd -s -u -f /etc/natd.conf -n fxp0 && echo -n ' natd started on fxp0 (Cable)' cp /var/run/natd.pid /var/run/natd.fxp0.pid fi if [ x$1 = xstop ]; then if [ -f /var/run/natd.fxp0.pid ]; then kill `cat /var/run/natd.fxp0.pid` else # oh well # killall natd (dont want to do this) fi fi # /usr/local/etc/rc.d/fxp1-natd.sh with execute bit set #!/bin/sh if [ $# -eq 0 -o x$1 = xstart ]; then /sbin/natd -p natd2 -s -u -f /etc/natd.conf -n fxp1 && echo -n ' natd started on fxp1 (DSL)' cp /var/run/natd.pid /var/run/natd.fxp1.pid fi if [ x$1 = xstop ]; then if [ -f /var/run/natd.fxp1.pid ]; then kill `cat /var/run/natd.fxp1.pid` else # oh well # killall natd (dont want to do this) fi fi Step 4: Now I need to tell my firewall that I am running natd on each interface. I am using ipfw. ipfw add divert 8668 ip from any to any via fxp0 ipfw add divert 8669 ip from any to any via fxp1 Step 5: FreeBSD will still send out icmp packets out the default gateway. I wanted to avoid this for two reasons. One of my ISP's blocks icmp messages for clients that dont belong on its network. And second because I want packets that come in one interface to leave on the same one. The next two rules use the following format. # default gateway from your ip address ipfw add fwd 66.77.88.1 ip from 66.77.88.99 to any via fxp0 ipfw add fwd 11.22.33.1 ip from 11.22.33.44 to any via fxp1. Notice that the via interface is using the ethernet interface of the other card. This means that if Cable (fxp0) is the default gateway, and a packet came in through the DSL interface (fxp1), send it to that host via fxp1 instead of out the default gateway attached to fxp0. Listing the opposite rule works to my advantage when I am using DSL as my default gateway. That way Cable modem (fxp0) packets still leave on fxp0. > > AFShin (AAS) > > "FreeBSD is the Best Performance OS Ever Made!" FreeBSD has some major uses. I think its a great networking OS. But its not really a great desktop OS. But those people have several choices available to them. (Windows, MacOS, Linux, etc.) aburke@nullplusone.com From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 15:15:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E24E16A4D0 for ; Sat, 10 Jan 2004 15:15:20 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB9FF43D3F for ; Sat, 10 Jan 2004 15:15:17 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 47577 invoked from network); 10 Jan 2004 23:15:16 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Jan 2004 23:15:16 -0000 Message-ID: <40008783.330FAFF4@freebsd.org> Date: Sun, 11 Jan 2004 00:15:15 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Gilbert References: <16384.14322.83258.940369@canoe.dclg.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: off-by-one error in ip_fragment, recently. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 23:15:20 -0000 David Gilbert wrote: > > I just updated a machine that uses GRE to -CURRENT. Upon rebooting, > the debugger stopped at the following: > > "panic: m_copym, offset > size of mbuf chain" There are two possible ways this can happen: The function m_copym was called with off == 0, or off == m->m_len. Neither is supposed to happen (obviously) so the bug must be in ip_fragment. Lets have a look at that next... > panic() > m_copym() > ip_fragment() > ip_output() > gre_output() > ip_output() > udp_output() > upd_send() > sosend() > kern_sendit() > sendit() > sendto() > syscall() > xint0x80_syscall() > > ... now I'm not sure that the error is perfectly technically > off-by-one, but its something similar. Is this panic reproduceable? What kind of traffic was going on at that time? Or was it right away when you started using the GRE tunnel? Could you please open a PR with this information too? It helps keeping track of the progress. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 15:33:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92D0216A4CE for ; Sat, 10 Jan 2004 15:33:20 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BC8343D5C for ; Sat, 10 Jan 2004 15:33:08 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 48735 invoked from network); 10 Jan 2004 23:33:07 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Jan 2004 23:33:07 -0000 Message-ID: <40008BB3.B35CC892@freebsd.org> Date: Sun, 11 Jan 2004 00:33:07 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Gilbert , freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <16384.14322.83258.940369@canoe.dclg.ca> <40008783.330FAFF4@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: off-by-one error in ip_fragment, recently. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 23:33:20 -0000 Andre Oppermann wrote: > > David Gilbert wrote: > > > > I just updated a machine that uses GRE to -CURRENT. Upon rebooting, > > the debugger stopped at the following: > > > > "panic: m_copym, offset > size of mbuf chain" > > There are two possible ways this can happen: The function m_copym > was called with off == 0, or off == m->m_len. Neither is supposed > to happen (obviously) so the bug must be in ip_fragment. Lets have > a look at that next... > > > panic() > > m_copym() > > ip_fragment() > > ip_output() > > gre_output() > > ip_output() > > udp_output() > > upd_send() > > sosend() > > kern_sendit() > > sendit() > > sendto() > > syscall() > > xint0x80_syscall() > > > > ... now I'm not sure that the error is perfectly technically > > off-by-one, but its something similar. > > Is this panic reproduceable? What kind of traffic was going on > at that time? Or was it right away when you started using the > GRE tunnel? Ok, I should read the email again instead of the code. You said it happens on booting. I'm not in the office and my test boxen are there. I don't want to panic it from home. On Monday I'll look at it in more detail. Having a full backtrace will help alot since the ip_fragment code is not that easy to step through. > Could you please open a PR with this information too? It helps > keeping track of the progress. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 15:51:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F67F16A4D1 for ; Sat, 10 Jan 2004 15:51:55 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id C44A443D98 for ; Sat, 10 Jan 2004 15:50:46 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 49634 invoked from network); 10 Jan 2004 23:50:37 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Jan 2004 23:50:37 -0000 Message-ID: <40008FCD.90525A33@freebsd.org> Date: Sun, 11 Jan 2004 00:50:37 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Gilbert , freebsd-net@freebsd.org, freebsd-current@freebsd.org References: <16384.14322.83258.940369@canoe.dclg.ca> <40008783.330FAFF4@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: off-by-one error in ip_fragment, recently. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 23:51:55 -0000 Andre Oppermann wrote: > > David Gilbert wrote: > > > > I just updated a machine that uses GRE to -CURRENT. Upon rebooting, > > the debugger stopped at the following: > > > > "panic: m_copym, offset > size of mbuf chain" > > There are two possible ways this can happen: The function m_copym > was called with off == 0, or off == m->m_len. Neither is supposed > to happen (obviously) so the bug must be in ip_fragment. Lets have > a look at that next... There seems to be a bug in m_copym() anyway, but it's not the one you trip over because we are getting into the while loop again. However if off == m_len it would not break and trash *m for a panic a few lines later. -- Andre Index: uipc_mbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.124 diff -u -p -r1.124 uipc_mbuf.c --- uipc_mbuf.c 25 Dec 2003 01:17:27 -0000 1.124 +++ uipc_mbuf.c 10 Jan 2004 23:47:36 -0000 @@ -199,7 +199,7 @@ m_copym(struct mbuf *m, int off0, int le copyhdr = 1; while (off > 0) { KASSERT(m != NULL, ("m_copym, offset > size of mbuf chain")); - if (off < m->m_len) + if (off <= m->m_len) break; off -= m->m_len; m = m->m_next; From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 16:34:29 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C45B16A4CE; Sat, 10 Jan 2004 16:34:29 -0800 (PST) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FF1743D58; Sat, 10 Jan 2004 16:34:28 -0800 (PST) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Sat, 10 Jan 2004 16:34:27 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id E0EF55D08; Sat, 10 Jan 2004 16:34:26 -0800 (PST) To: Marko Zec In-Reply-To: Message from Marko Zec of "Sat, 10 Jan 2004 15:11:04 +0100." <200401101511.04672.zec@tel.fer.hr> Date: Sat, 10 Jan 2004 16:34:26 -0800 From: "Kevin Oberman" Message-Id: <20040111003426.E0EF55D08@ptavv.es.net> cc: freebsd-net@freebsd.org cc: Lorenzo Vicisano cc: freebsd-mobile@freebsd.org Subject: Re: prism 2.5 timeout in wi_cmd 0x010b 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, 11 Jan 2004 00:34:29 -0000 > From: Marko Zec > Date: Sat, 10 Jan 2004 15:11:04 +0100 > Sender: owner-freebsd-mobile@freebsd.org > > > --Boundary-00=_4fAAAunGWPP68/U > Content-Type: text/plain; > charset="iso-8859-2" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Hi Lorenzo, > > can you try the attached patch, it does seem to help on my ThinkPad X30, > which has an internal mini-PCI Prism2.5 card with the same firmware. Marko, I just started re-building my kernel with this patch. I have previously reported this under CURRENT and hope that this might fix the problem. It has also been reported by several others under slightly different circumstances. I'll report what I see. It's pretty easy to test...just copy a multi-megabyte file from my laptop to my workstation over the wireless. I'll be interested to hear if Warner has any comments on this. Thanks! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 17:31:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEEEB16A4CE; Sat, 10 Jan 2004 17:31:44 -0800 (PST) Received: from mail.tel.fer.hr (zg01-167.dialin.iskon.hr [213.191.129.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5F5C43D53; Sat, 10 Jan 2004 17:31:40 -0800 (PST) (envelope-from zec@tel.fer.hr) Received: from 192.168.200.114 (marko@dhcp14.katoda.net [192.168.200.114]) by mail.tel.fer.hr (8.12.6/8.12.6) with ESMTP id i0B1TIi3011981; Sun, 11 Jan 2004 02:29:41 +0100 (CET) (envelope-from zec@tel.fer.hr) From: Marko Zec To: "Kevin Oberman" Date: Sun, 11 Jan 2004 02:29:46 +0100 User-Agent: KMail/1.5.4 References: <20040111003426.E0EF55D08@ptavv.es.net> In-Reply-To: <20040111003426.E0EF55D08@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401110229.46446.zec@tel.fer.hr> cc: freebsd-net@freebsd.org cc: Lorenzo Vicisano cc: freebsd-mobile@freebsd.org Subject: Re: prism 2.5 timeout in wi_cmd 0x010b 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, 11 Jan 2004 01:31:44 -0000 On Sunday 11 January 2004 01:34, Kevin Oberman wrote: > > Marko, > > I just started re-building my kernel with this patch. I have > previously reported this under CURRENT and hope that this might fix > the problem. It has also been reported by several others under > slightly different circumstances. I'll report what I see. It's pretty > easy to test...just copy a multi-megabyte file from my laptop to my > workstation over the wireless. > Whoops... it seems that my hack doesn't fix the problem of outgoing traffic hosing the wi interface - next time I'll do more testing before making a post. However, without this patch my wi would lock up every now and than out of the blue, regardless whether it was associated to an AP or it was disconnected, and regardless whether there was any traffic flowing through it or not. The same card (Prism 2.5 mini-PCI) used to play nicely with 4.8-R, and works quite well with M$ also. There must be something rotten in the recent wi driver... Cheers, Marko From owner-freebsd-net@FreeBSD.ORG Sat Jan 10 17:59:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96C6C16A4CE; Sat, 10 Jan 2004 17:59:55 -0800 (PST) Received: from sizone.org (mortar.sizone.org [65.126.154.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5425A43D1D; Sat, 10 Jan 2004 17:59:54 -0800 (PST) (envelope-from dgilbert@daveg.ca) Received: by sizone.org (Postfix, from userid 66) id AC82E307CA; Sat, 10 Jan 2004 20:59:53 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id E4B1E1D1F65; Sat, 10 Jan 2004 20:59:51 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16384.44567.797902.985587@canoe.dclg.ca> Date: Sat, 10 Jan 2004 20:59:51 -0500 To: Andre Oppermann In-Reply-To: <40008783.330FAFF4@freebsd.org> References: <16384.14322.83258.940369@canoe.dclg.ca> <40008783.330FAFF4@freebsd.org> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: David Gilbert Subject: Re: off-by-one error in ip_fragment, recently. 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, 11 Jan 2004 01:59:55 -0000 >>>>> "Andre" == Andre Oppermann writes: Andre> There are two possible ways this can happen: The function Andre> m_copym was called with off == 0, or off == m->m_len. Neither Andre> is supposed to happen (obviously) so the bug must be in Andre> ip_fragment. Lets have a look at that next... I got there pretty quickly, too. Andre> Is this panic reproduceable? What kind of traffic was going on Andre> at that time? Or was it right away when you started using the Andre> GRE tunnel? It happens during the boot. I'm working on clearing off a drive so that I can get a crash dump with symbols. I have the following in rc.conf: cloned_interfaces="gre0" ifconfig_dc0="DHCP" ifconfig_wi0="inet x.y.z.105/29 media autoselect mode 11b mediaopt hostap ssid DaveG.ca channel 11" ifconfig_gre0="inet x.y.z.114 x.y.z.113 netmask 255.255.255.252 tunnel a.b.27.151 x.y.z.17" ifconfig_sis0="inet x.y.z.81/28" static_routes="tunnel default" route_tunnel="x.y.z.17/32 a.b.24.1" route_default="default x.y.z.113" dhcp picks up a.b.27.151 from my cable provider relatively dependably. So wi0 and sis0 are internal networks and dc0 is the external interface. gre0 runs over dc0. The crash happens after a few of the daemons start. It's a UDP send that's large enough to fragment. It could be a large dns packet or ntp. Not sure exactly. Andre> Could you please open a PR with this information too? It helps Andre> keeping track of the progress. I'll be opening the PR tomorrow once I have a crash dump and a better trace. This configuration is working in a kernel from 5.1-CURRENT built in october. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================