On Tue, Mar 31, 2015 at 1:42 AM, Matt Thomas <[email protected]> wrote: > >> On Mar 30, 2015, at 8:26 AM, Christoph Badura <[email protected]> wrote: >> >> On Sun, Mar 29, 2015 at 01:30:43PM +0000, Ryota Ozaki wrote: >>> Module Name: src >>> Committed By: ozaki-r >>> Date: Sun Mar 29 13:30:43 UTC 2015 >>> >>> Modified Files: >>> src/sys/net: if_vlan.c >>> >>> Log Message: >>> Correct frame padding length >>> >>> vlan pads a frame with zeros up to 68 bytes >>> (ETHER_MIN_LEN + ETHER_VLAN_ENCAP_LEN). It expects >>> that even if the frame is untagged, it keeps 64 bytes >>> at least. However, it lacks concern about CRC >>> (4 bytes). So a sending frame can be 72 (68 + 4) bytes. >> >> I don't get it. ETHER_MIN_LEN includes the 4 bytes for the CRC of a >> minimum sized packet. Therefore ETHER_MIN_LEN + ETHER_VLAN_ENCAP_LEN is >> the right size, isn't it? > > No, it has 4 bytes too many because the 4 bytes for CRC still needs to be > added by the hardware. > >> BTW, what do you mean by "it lacks concern about CRC"? > > It lacks compensating for the fact the CRC has been stripped by the time vlan > gets the packet.
# matt@ explained well than me... Note that the issue was found by some strict packet capture software (not by me, so I don't know what it is); typical OSes don't complain the extra padding, so we didn't notice the issue until recently. ozaki-r
