-1

as we know the FCS is an end part of the Ethernet packet frame structure, and by checking the FCS part we can find that an error happened in data transfer or not. I have a question about FCS checking in ETHERNET II or DIX packet these frames don't have a packet length in their frame structure, what should I do if I faced with a packet that the correct FCS exists in a middle of data. for example, the packet have 512 byte's length at the byte 128 I see the correct FCS till byte 128 but actually some bytes are remaining, the worst case is at the end of the correct length I see the FCS error, besides the packet length is not mentioned in the frame structure what should i do ? I see this problem in Jumbo frame (802.3) Ethernet II and DIX

Amir Hamidi
  • 1
  • 2

1 Answers1

0

The FCS is always at the end of the frame. Since, as you've pointed out, there's no frame size indication for the most popular frame types, putting the FCS anywhere else in the frame destroys its structure.

Even if you're using jumbo frames the FCS is always at the very end.

Depending on where the frames originated, how it was generated or captured (as a bitstream?) it might be possible to have some garbage at the end. This you'll need to detect and remove yourself as the generator/capture process was faulty.

With an IP packet inside the frame and its Total Length field you'll have some indication on where the user data (SDU) stops and the FCS might start. Still, there's guessing involved.

Zac67
  • 2,761
  • 1
  • 10
  • 21
  • Actually my question is what we should I do if randomly or accidently 4 sequence byte's in ETHERNET data is equal to the CRC32 of the data that captured till now.( i roll a part as a receiver) – Amir Hamidi Jun 11 '18 at 19:28
  • A switch or NIC doesn't stop receiving a frame if the current FCS residue simply happens to match by chance. The frame ends when transmission stops (end of carrier or end-of-data symbol), then the FCS is checked. – Zac67 Jun 11 '18 at 19:41
  • I captured ETHERNET data as a bitstream. as we can see in IEEE frame structure standard [link](https://en.wikipedia.org/wiki/Ethernet_frame) only FCS shows the ending of packet. there is no problem to capturing data. my question is about how can i understood the matching crc32 in the Ethernet packet is actually end of the packet or not this matching occure by chance. – Amir Hamidi Jun 11 '18 at 19:59
  • That is your misconception: any data matching the current FCS by chance does not mark the end-of-frame. It's the other way around: the end-of-frame is signalled by the Reconciliation Sublayer (RS) and then the last four bytes before that are interpreted as the FCS. Check e.g. IEEE 802.3 Clause 22.2. – Zac67 Jun 12 '18 at 10:56
  • did you mean the data in IFG had a meaning at the end of the packet? I only have a one clock signal and the raw ethernet data before PCS layer. – Amir Hamidi Jun 12 '18 at 12:24
  • I can't tell you what you captured. If this was the IPG it didn't have a meaning (the IPG can't be decoded either). – Zac67 Jun 12 '18 at 17:00
  • Thank you @Zac67, I found something like K word in 8b/10b data in 1 Gig ethernet and EOP data with word 0x87 in 64/66b data in 10 G ethernet that exist in IPG but we can eliminate IPG in 10 G Ethernet. my question has changed to how can find EOP in 10 G Ethernet without IPG, – Amir Hamidi Jun 14 '18 at 07:19
  • Still, the end-of-packet symbol is only visible in the line code (below PCS). When the line bitstream is decoded in PCS, the information is removed from the stream. Instead, EOF is signaled from PCS to RS, and from RS to MAC. – Zac67 Jun 14 '18 at 11:04