[227] in linux-net channel archive
Re: Packet-length patch to lance.c in 1.2.5?
daemon@ATHENA.MIT.EDU (Russell Nelson)
Wed Apr 26 03:17:37 1995
Date: Wed, 26 Apr 95 00:51 EST
From: nelson@crynwr.com (Russell Nelson)
To: dplatt@3do.com
CC: linux-net@vger.rutgers.edu
In-reply-to: <9504251822.AA29574@rhett.3do.com> (dplatt@3do.com)
From: dplatt@3do.com (Dave Platt)
Date: Tue, 25 Apr 1995 11:22:14 PDT
In version 1.2.5, the net/lance.c driver was patched in a way which
appears to strip off the last four bytes of each packet received:
Can anyone explain to me why this was done?
My suggestion. I had a bug in Red.FS, a proprietary file sharing
protocol, which runs over raw Ethernet. I was working backward from
the length of the packet, which for the LANCE was four bytes too big.
So my appended checksums weren't were I thought they were.
I'm told that this was done to "avoid allocating the checksum", but
I don't really understand the intent. The Ethernet FCS is already
being removed from the end of the packet by the Lance driver,
thanks to the automatic pad/FCS stripping feature which is being
enabled during chip startup.
Maybe the FCS is stripped by code in *your* changes in 1.2.6, but in
the 1.2.1 version, it's still there.
Can anybody give a good justification for this change? If not, I believe
that it should probably be backed out for 1.2.7.
Sounds to me like a case of conflicting patches. My intent was that
the FCS not be delivered, and if your patches fix that, great!
--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St. | +1 315 268 1925 (9201 FAX) | What is thee doing about it?
Potsdam, NY 13676 | Help Phil Zimmerman! http://www.netresponse.com/zldf
