[226] in linux-net channel archive
Packet-length patch to lance.c in 1.2.5?
daemon@ATHENA.MIT.EDU (Dave Platt)
Tue Apr 25 17:14:48 1995
From: dplatt@3do.com (Dave Platt)
Date: Tue, 25 Apr 1995 11:22:14 PDT
To: linux-net@vger.rutgers.edu
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:
--- v1.2.4/linux/drivers/net/lance.c Fri Jan 20 11:34:39 1995
+++ linux/drivers/net/lance.c Sun Apr 9 10:38:29 1995
@@ -913,7 +913,7 @@
lp->rx_ring[entry].base &= 0x03ffffff;
} else {
/* Malloc up new buffer, compatible with net-2e. */
- short pkt_len = lp->rx_ring[entry].msg_length;
+ short pkt_len = (lp->rx_ring[entry].msg_length & 0xfff)-
4;
struct sk_buff *skb;
skb = alloc_skb(pkt_len, GFP_ATOMIC);
Can anyone explain to me why this was done? 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.
If the intent is to remove a higher-level (e.g. UDP) checksum from the
end of the packet, then this seems like the WRONG way to go about doing
so. Not all Ethernet protocols end their packet with a four-byte
checksum, and those that do may be intolerant of having the checksum
dropped on the floor by the network device. I'm told that this patch
has the effect of disabling CAP and other software which depends on the
ability to send and receive "raw" Ethernet packets.
Can anybody give a good justification for this change? If not, I believe
that it should probably be backed out for 1.2.7.
--
Dave Platt dplatt@3do.com
USNAIL: The 3DO Company, Systems Software group
600 Galveston Drive
Redwood City, CA 94063
