After carefully reading three reference documents, and analyzing

the 802.3 frames generated by the DC21040 (which does automatic padding
of less-than-minimum frames) and the frames generated by the 'ed'
driver, I've found that there is indeed a bug in the size of "ETHER_MIN_LEN"
as reported by several people, John Hay being the most recent. The driver
was actually setting the length to 6+6+2+50 (64 bytes), which when adding
in the CRC (which is automatically appended to the frame and not included
in the length), the minimum frame is 4 bytes larger than it is supposed to
be. All of this is confirmed by tcpdump showing 50 bytes of data for
minimum frames from the 'ed' cards and 46 bytes from 'de' cards. This
analysis has also revealed that there is garbage in the un-filled in
portion at the end of the minimum frames from the 'ed' driver; I don't
plan to fix this.

1 files changed, 4 insertions, 4 deletions

diff --git a/sys/i386/isa/if_ed.c b/sys/i386/isa/if_ed.c
index 6898dfd..d4d29f8 100644
--- a/sys/i386/isa/if_ed.c
+++ b/sys/i386/isa/if_ed.c
@@ -13,7 +13,7 @@
  *   the SMC Elite Ultra (8216), the 3Com 3c503, the NE1000 and NE2000,
  *   and a variety of similar clones.
  *
- * $Id: if_ed.c,v 1.70 1995/05/04 07:56:23 davidg Exp $
+ * $Id: if_ed.c,v 1.71 1995/05/12 22:39:40 davidg Exp $
  */
 
 #include "ed.h"
@@ -169,8 +169,8 @@ static unsigned short ed_790_intr_mask[] = {
 	IRQ15
 };
 
-#define	ETHER_MIN_LEN	64
-#define ETHER_MAX_LEN	1518
+#define	ETHER_MIN_LEN	60
+#define ETHER_MAX_LEN	1514
 #define	ETHER_ADDR_LEN	6
 #define	ETHER_HDR_SIZE	14
 
@@ -1682,7 +1682,7 @@ ed_rint(unit)
 			ed_pio_readmem(sc, packet_ptr, (char *) &packet_hdr,
 				       sizeof(packet_hdr));
 		len = packet_hdr.count;
-		if (len > ETHER_MAX_LEN) {
+		if (len > ETHER_MAX_LEN+4) { /* len includes 4 byte header */
 			/*
 			 * Length is a wild value. There's a good chance that
 			 * this was caused by the NIC being old and buggy.