576 bit times comes about because the frame will consist of 7 bytes of preamble, 1 start of frame delimiter byte, 42 ARP protocol bytes, 18 padding bytes, and 4 CRC bytes for a total of 72 bytes of 576 bits. If you attach an oscilloscope to the Ethernet cable, you will observe a waveform lasting 576 bit times (57.6us). The node that receives the ARP packet will show 60 bytes received (4 byte CRC is also something Wireshark cannot normally observe). The node that sends the ARP query or response will show 42 bytes sent in Wireshark. You can observe that all ARP packets are 64 bytes by running Wireshark on two PCs that are connected to the same network. Windows submits only 42 bytes to the NDIS driver, so that's all Wireshark gets to see. The reason for this is because the padding to 60 bytes + 4 byte CRC is done by the Ethernet hardware as the ARP packet is being transmitted. Wireshark tells you only 42 bytes are sent, but it is lying. I'm trying to figure out how to capture all frames (not just ARPs) containing an FCS set to 0x0000, to see how wide spread this issue is.No, all ARP packets on Ethernet are 64 bytes, not 42. Seems to me that any frame with an FCS of all zeros will be dropped by receiving hosts ('bad FCS'). custom hardware capable of line-rate capture). However, the trace I reference here was taken using a Fluke Optiview XG (one of its 'Network Ports', i.e. I saw this first by capturing using Wireshark loaded on a Windows VM. Casual inspection suggests that only Windows VMs are producing these odd ARPs. On one particular VLAN, ~300,000 ARP frames in an ~hour, of which ~1100 contained an all-zeros FCS. I'm intermittently seeing ARP frames (both requests and responses) equipped with an FCS set to all zeros.
0 kommentar(er)
