From owner-freebsd-stable Fri Sep 26 14:34:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29375 for stable-outgoing; Fri, 26 Sep 1997 14:34:54 -0700 (PDT) Received: from usr08.primenet.com (tlambert@usr08.primenet.com [206.165.6.208]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29370; Fri, 26 Sep 1997 14:34:51 -0700 (PDT) Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA14622; Fri, 26 Sep 1997 14:34:01 -0700 (MST) From: Terry Lambert Message-Id: <199709262134.OAA14622@usr08.primenet.com> Subject: Re: 'fxp' driver/hardware lossage (was Re: Alexander B. Povol's mail) To: dg@root.com Date: Fri, 26 Sep 1997 21:34:01 +0000 (GMT) Cc: mike@smith.net.au, tarkhil@mgt.msk.ru, hackers@FreeBSD.ORG, stable@FreeBSD.ORG In-Reply-To: <199709261426.HAA25055@implode.root.com> from "David Greenman" at Sep 26, 97 07:26:27 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > One of these days I'll conjure up some sort of hack to fix the problem. > Intel recommends reprogramming the multicast filter (!) if no packets are > received for some number of seconds. This is difficult to implement in the > current design of the driver. Plus it leaves your butt hanging in the wind for several seconds on a *supposedly* 100Mbit card. Pretty frigging ugly. I guess the errata don't say what causes the bug (like a collision? That would explain the 100Mbit being more robust...), like the macrocell for the chip is actually mask programmed and the unused bit sets aren't specifically disallowed, or a header collision can't be dealt with because the header accumulation buffer isn't cleared, or something dumb like that? Do we know that the "cron ping soloution" actually works? If it does, can we set up a bogus gateway route to avoid getting a packet back for one sent to see if it's the packet out or the packet back that does it? I'm betting out at this point... If this works, then a timer set to bogusly send a packet to ourselves would not bother anyone else on the network who wasn't in promiscuous mode and running a network monitor, and it would be filterable there. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.