Hi all,

while looking at the vr(4) errors I mentioned yesterday, I got curious
about a message being shown by dhclient:

ip length x disagrees with bytes received y
(replace x with the correct length and y=x+4; I don't remember the
exact numbers).

The thing is that the vr(4) driver, as well as _many_ others, sets the
M_HASFCS flag in each packet it receives.  This is correct, because all
packets include the CRC in them, which has to be removed later on.

The problem is that bpf does not care about that flag, so it takes the
length in the packet and does not subtract the checksum.  Thus you get
the message described above.

OTOH, ether_input does trim the CRC when M_HASFCS is set (I guess that
other _input functions do it as well; haven't checked).  So I think the
problem only affects bpf.

(As a test, I dropped the line setting that flag in vr(4) and replaced
it with one that manually removes ETHER_CRC_LEN from the packet length,
which effectively removed the warning message).

I don't know how this can be fixed, because bpf cannot know how many
bytes to remove.

Should M_HASFCS be nuked (as a developer suggested) and instead remove
the correct amount of bytes from each driver?

Thanks,

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/