Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:12857 comp.os.386bsd.bugs:2471 comp.os.386bsd.development:2527 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!cobra.uni.edu!kuhtzc1768 From: kuhtzc1768@cobra.uni.edu Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.bugs,comp.os.386bsd.development Subject: Re: FreeBSD IP problem? Message-ID: <1994Sep2.111218.31463@cobra.uni.edu> Date: 2 Sep 94 11:12:18 -0500 References: <33tee7INN7vr@scarecrow.mke.ab.com> Organization: University of Northern Iowa Lines: 41 Hi, (economically speaking: I assume that Livingston's terminal server has a bug :) > I have an interesting problem with the networking on my FreeBSD box. > It tickles a bug in my Livingston terminal server causing it to crash. > The problem seems to occur when there is garbage data in the ethernet > frame following the end of the IP packet. Our testing shows that this > is a problem with NetBSD, FreeBSD, and KA9Q... maybe other IP devices > as well, but those our the ones we have discovered. I am trying to Yes, and? Do we have to implement bugs in systems to hide other systems' bugs? Please, do not even think about doing something like that! Slaughter Livingston but not other OS who happen to be on the same network and tickles a bug in the Livingston. Btw: ANY system has to be able to handle a certain amount of garbage on the Ethernet. Read the standard documentation if you don't believe me. > get a patch from Livingston, but I would also like to patch my FreeBSD Ok, so, my assumption is true that it's a Livingston bug. :) > code (I have a feeling I can accomplish that much more quickly). Can That might be true. But what would be the consequences? Other boxes trying to fix one bug in *another* system with a bug in their *own* system? You can't be serious. We might not work with a 100% professional system, but does that release us from the obligation to at least *try* to work professionally? > anyone offer some help or advice? (i.e "look at such and such part of > the kernel code") Should I be focusing on the driver for my specific > network card? (3c509) What part of the kernel source code should I > be looking at? Such practice should be *extremely* discouraged. Please, think about what you're trying to do. Kind regards, Chris