SUMMARY: le0 giant packet received

From: CYBERMAN (mccalld@Sonoma.EDU)
Date: Wed Sep 22 1993 - 08:03:08 CDT


Enclosed are the responses which were considered valuable information
for this problems consideration.

Here is the origional problem:
The following message is seen on the Sun OW3 Console window--
What does it mean, and what should I do about it?
-
- le0: Receive: giant packet from 8:0:20:0:f:3c
- le0: Receive: STP in rmd cleared
- le0: Receive: giant packet from ff:ff:ff:ff:ff:ff
- le0: Receive: STP in rmd cleared

- The ethernet address varies.

- > TFM [ le(4s) ] says:
 le%d: Receive: STP in rmd cleared
- > The driver has received a packet that straddles
- > multiple receive buffers and therefore consumes
- > more than one of the LANCE chip's receive descrip-
- > tors. Provided that all stations on the Ethernet
- > are operating according to the Ethernet specifica-
- > tion, this error "should never happen," since the
- > driver allocates its receive buffers to be large
- > enough to hold packets of the largest permitted
- > size. Most likely, some other station on the net
- > is transmitting packets whose lengths exceed the
- > maximum permitted for Ethernet.
- >
- > The second message is a result of the first. A "rmd" is a Recieve
- > Message Descriptor. STP is the Start of Packet bit. The second
- > message means that the chip returned a buffer that didn't have the STP
- > bit set. The lance chip will automatically chain buffers together if
- > neccessary. It should never be necessary to chain buffers since the
- > driver always allocates 1588 byte buffers. The buffers were chained
- > because the frame coming in was over 1588 bytes so the chip started
- > stuffing data into the next buffer.
- >
- > What all of this really means is that the machine is seeing long
- > frames. Your network is broken. Might be a broken host, xcvr,
- > repeater, sun spots, or whatever. Break out the sniffers.
- > The general consensus is that the problem described above can have
- > (at least) three causes:

- 1) existance of more than one protocol on the same physical segment.
-
- If you run e.g. AppleTalk or decnet together with tcp/ip on the same
- network, this can cause problems.
-
- 2) a too long physical segment.
-
- If your network does not comply with the 802.3 standard, you can
- expect such problems.
-
- 3) a hardware problem, such as a defect bridge, router or ethernet-card.
-
- Such defects seem to be very hard to track down. The best you can
- do is to control the correct operation of each component by monitoring
- before and after it.
**********************************************************
Don't sweat it. The giant packet is a MAC (physical) level error.
"STP in rmd cleared" lets you know that the IP (network) layer
handled the media access protocol error.

Its been my experience that PC ethernet adapters are most often
responsible for ill-formed packets.
**********************************************************
I'm sorry I don't have an answer, but I would appreciate
a Summary. We get the same message on our network. Best
we can tell its coming from one of the PC's we have.
**********************************************************
I received this message many times many months ago. I finally found
(simply by powering off the equipment) that an X-terminal was producing
 packets with more than the maximum number of bytes permissible.
 So, it probably is a hardware problem with your Ethernet circuitry
(or transceiver?) on a computer somewhere.
**********************************************************
first, the messages indicate that your ethernet port is receiving
packets that are:
                   1. larger than the legal limit ( 1518 bytes )
                   2. sourced and destined to the broadcast address
                      ( FF:FF:FF:FF:FF:FF )

it indicates that something on the ethernet interface/network is
misbehaving. probably, something is sending "all ones" in a stream, a
stream that exceeds 1518 bytes (at least). something could be
jabbering or completely jamming your network.
IF THIS WAS A ONE TIME OCCURANCE, WATCH OUT FOR IT!! something is
probably beginning to die.

IF IT IS A REGULAR OCCURANCE, SOMETHING IS DEAD!!

things to look at (in basically this order):
                   1. does anything else on your network do anything
                      similar? is something really slow?
                      a. almost anything on the network could cause this
                      b. un-tranlsated/un-encapsulated token-ring or
                         fddi packets bleeding onto an ethernet can do
                         this.
                      c. an electrical malfunction in the interface
                         itself could cause this.
                   2. check your cabling
                   3. try another tranceiver
                   4. does it do this without a tranceiver/cable?

**********************************************************
This message means

        A packet bigger than the maximum ethernet size came through
        on le0 (max = 1518 bytes total). Obviously, a bogus
        packet. Possible causes:

            Noise in the "quiet space" between packets, making
            2 pkts look like 1, or too-small between-pkt gap: pkts
            have a minimum spacing between them. Jam two of them
            closer together than that, and have what looks like
            1 pkt.

            ENP or STP bits blown away: Start of Pkt or End of Pkt
            bits got munged. A non-Sun host not respecting
            ethernet packet size limit can send oversized packets
            and cause this problem.

If you are getting the ethernet address as ff:ff:ff:ff:ff:ff - this
has been evaluated as not a bug. The 4.1 le driver prints the bytes
in the ethernet source address field. In this case they happen to be
all 0xff. Giant packets are invalid and discarded, they cause a
performance hit if nothing else - depending on frequency.
**********************************************************
1. It would seem to me that "giant packet" means that your w/s is detecting
a packet which is larger than the legal 1218 byte Ethernet frame length.

2. The fact that the packet is being received from a broadcast address,
which is also illegal.
**********************************************************
They got more frequent, then stopped. They stopped
coincidentally with a Shiva FastPath (an older one,
maybe from before Shiva bought the FastPath product).

It seemed at the time that most boxes did not respond
to these malformed packets, but all of our Suns sure
complained.

It might be some other type of device's ethernet controller
as well. Good luck finding it. BTW, we found that the
malformed packets will not pass through a bridge, but will
through a repeater.
**********************************************************
Suggestions are to check the overall length of yuor cable, try
replacing any obviously bad looking sections of cable, check any recent
changes, any new taps installed, T connectors, terminators, etc. If
this doesn' t help then get a network sniffer to look for bad
impedances, etc, in the cable runs.
**********************************************************
On out site we had have thousands of messages like this. We had a closer
look to the network with sniffers. We couldn't find any sources for many
month (years).

But now we know !

When anybody turns on (or off) a elect. engine close to a SS we've giant
packets. So never clean the floor or change the cables on your SS.

We changed some cheap AUI-Cable. Now I've never seen these message anymore.
**********************************************************

We got a whole storm of these things and it turned out to be our 10BaseT
concentrator! After we power cycled the thing, all the giant packets (well,
99.99% of them) went away. it took us a long time to find this out. we were looking for more obvious things...
*********************
Thank you to all who replied and even to some of you who were a bit
touchy about my posting. I'll try to be a bit more thorough next time
and if I'm not too lazy, do some extensive research prior to posting.
cyberman
PS: sorry for the delay



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:16 CDT