Problem with W5100 and W3100A MAC raw mode

Question

I am trying to use the W5100 and W3100A in MAC raw mode. (Yes, the W3100A is very old, but I am trying to implement a software fix for a problem the Wiznet modules have with missing ARP requests, and I am trying to fix some old equipment my customers have in the field). Anyway, I have found that neither the W5100 nor the W3100A give me the correct length of the raw ethernet frames. The W5100 seems to pad out all ethernet frames to a minimum length of 60 bytes with extra bytes of zeros. The W3100A seems to pad out all ethernet frames to a minimum length of 64 bytes, and the extra padding bytes are not all zero. For example, a received ARP request frame is 42 bytes long (as confirmed by a Wireshark capture). The W5100 gives me a frame of 60 bytes (the proper 42 bytes plus an extra 18 bytes of zeros. The W3100A gives me a frame of 64 bytes (the proper 42 bytes plus an extra 22 bytes of padding, which are not all zero. I am trying to use the open source LWIP software stack to implement TCP protocol. It seems to be working with the W5100, but not with the W3100A. I think the extra non-zero padding bytes are causing problems. So why doesn’t either chip give me the correct length for received ethernet frames that are short? I see no reason to pad them out to be longer. And it seems like the non-zero padding bytes are causing problems! So how can I figure out the correct length of the received ethernet frames in MAC raw mode?

Eugeny · Answer

microaide: Anyway, I have found that neither the W5100 nor the W3100A give me the correct length of the raw ethernet frames. You do not detail the source of frame/data size value. There’s received size register, and there’s 2-byte data size value in the RX buffer before the data. Which one you refer to? microaide: ARP request frame is 42 bytes long (as confirmed by a Wireshark capture). I am not sure, but this size could be the value of 42 is size of actual data, without padding. What frame on the wire does actually consist of? Edit: I can not believe there could be such a bug when “data size” identifier is different than size of raw data. I am looking to the Wirehark, and see that ARP request is 60 bytes with 10 bytes of zero padding (exactly 42 bytes of raw data), and ARP reply is 42 bytes, without any padding. However looking inside the packet, and into the ARP packet message format it clearly says that meaningful data is 28 bytes after the headers, and type of message is defined before this ARP data (at offset 0xC). Thus driver must know the predefined size of data (28 bytes) for the ARP protocol (0x0806) before it starts parsing the data, and any garbage after meaningful 28 bytes must simply be discarded. Edit 2: to confirm the bug you must take the Wireshark log on the last interface connected directly to the W5100/W3150 - for example, on the PC in bridge mode, and capture packet log on the interface this PC is directly connected to the WIZnet. It may happen that packets forwarded on the network may be modified (e.g. padded), thus the only way is to compare configuration and data of the packets actually being sent by the device onto the wire, and packets (configuration and data) received by the WIZnet chip.