[245] in linux-net channel archive

home help back first fref pref prev next nref lref last post

Re: Packet-length patch to lance.c in 1.2.5?

daemon@ATHENA.MIT.EDU (Russell Nelson)
Fri Apr 28 01:13:28 1995

Date: Thu, 27 Apr 95 23:44 EST
From: nelson@crynwr.com (Russell Nelson)
To: dplatt@3do.com
CC: linux-net@vger.rutgers.edu
In-reply-to: <9504271820.AA25053@rhett.3do.com> (dplatt@3do.com)

   Date: Thu, 27 Apr 95 11:20:21 PDT
   From: dplatt@3do.com (Dave Platt)

   "Note that if the Automatic Pad Stripping feature is enabled, the FCS
    [for padded frames] will be verified against the value computed for the
    incoming bit stream including pad characters, but the FCS value [for a
    padded frame] will not be passed to the host."

Yeah, I've ran into this before also -- Ethernet hardware that knows
about the IEEE 802.3 frame length field, and believes it.  Caveat
programmer: if you put out a frame with the field at offset 0xe set to
something less than 0x600, you'd better set it to the length of the
frame!  Otherwise some other device out there might truncate the frame
to the length you specified...

   Approach [2] leads to simpler code, and it's more consistent - all of
   the FCS stripping would be done in the same way, for all Lance chips
   and all packet lengths.  The only possible disadvantage I can see to
   it, is that when short (padded) packets are received, the code would
   end up having to allocate a skbuff which is large enough for the padded
   packet.  This is probably a non-issue:  the extra space is only a few
   tens of bytes, and I can't imagine that any sane network code would try
   to figure out the length of the received packet by looking at the size
   of the skbuff.

Um, ah, er, that's how I found out about this problem -- by working
backwards from the length of the packet as reported by the Ethernet
controller.  Maybe that's not such a good idea...

   I'll try this out and letcha know.  Russ, could you try this and make sure
   it doesn't break your own protocol?

Yes, I tried it, and it works fine.

-- 
-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

home help back first fref pref prev next nref lref last post