[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ethmac] magic number, compatibility problem?!



Correct, I did not know the original poster's situation, so I left all
options open.  If the data contained within the frame is IP data, you would
probably not forward it.

However, there are many other situations in which you may forward a frame
which contains a CRC error.  For example, if you were transmitting
specialized data within your frames (non-IP data) that was protected by an
error correction scheme (like Reed-Solomon) instead of just an error
detection scheme (like IP), you may still be able to correct and extract
your data with confidence despite the frame CRC error.  It just depends on
the situation.

Obviously, a network such as this would not be running across the internet
and would have specialized applications.

I hope this clears up what I was thinking.

Regards,
Kevin


-----Original Message-----
From: owner-ethmac@opencores.org [mailto:owner-ethmac@opencores.org]On
Behalf Of Illan Glasner
Sent: Sunday, February 10, 2002 3:10 PM
To: ethmac@opencores.org
Subject: RE: [ethmac] magic number, compatibility problem?!




   Hi,

      Usualy the only case you will forward a packet that have bad crc is
for debug porpuse as otherwise since you can;t tell what went wrong the
result might be quite harmfull.

have a nice day

   Illan


-----Original Message-----
From: Kevin Kay [mailto:kevin.kay@espipd.com]
Sent: Saturday, February 09, 2002 6:47 AM
To: ethmac@opencores.org
Subject: RE: [ethmac] magic number, compatibility problem?!


The magic number is a result of the CRC algorithm used.  It really doesn't
directly come from the 802.3 specification (rather, it comes about
indirectly).  The 802.3 spec. calls for the use of a specific CRC-32
algorithm and specifies the polynomial (which is obviously specified as the
FCS for the frame).  An indirect consequence of this CRC specification is
the magic number which is related to this polynomial.  Thus, since all 802.3
MACs will/should be using the same CRC polynomial, they will all essentially
be using the same magic number.

The magic number is simply a pattern that will result when an error-free
incoming frame (*including the FCS*) is pushed through the CRC generator.  A
correct incoming frame with the correct FCS will always generate this magic
number when pushed through this CRC algorithm.  The magic number approach
makes it much easier for checking for a correct frame since you don't have
to compare to each individual FCS for each frame.  You simply push the
incoming frame and the FCS through the CRC generator and then look for the
magic number.  If it's there, you're good to go, if not, then you either
drop the packet due to CRC error, pass the packet on with the error, or
assume the data is OK and pass it on with a new and correct CRC.  I can't
say which would be right for your situation, and some of the above decisions
are probably better than others.

Hope this helps.

Kevin

-----Original Message-----
From: owner-ethmac@opencores.org [mailto:owner-ethmac@opencores.org]On
Behalf Of jcwh@sina.com
Sent: Saturday, February 09, 2002 2:26 AM
To: ethmac@opencores.org
Subject: [ethmac] magic number, compatibility problem?!


the magic number is really interesting,

but the 802.3 doesn't mentioned this queer "magic number".

Will this result a compatibility problem with other ethernet controller?
--
To unsubscribe from ethmac mailing list please visit
http://www.opencores.org/mailinglists.shtml

--
To unsubscribe from ethmac mailing list please visit
http://www.opencores.org/mailinglists.shtml
--
To unsubscribe from ethmac mailing list please visit
http://www.opencores.org/mailinglists.shtml

--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml