Since I started using the vr(4) driver (i.e., when I switched my network to twisted pair cables), I've been experiencing very annoying crashes when running in promiscuous mode. This happened rarely at boot up, while dhclient(8) fetches its first lease. However, if you happen to use any other utility that puts the NIC in promiscuous mode, such as tcpdump(8) or bridge(4), the crashes happen almost 95% of the times.
Yesterday, I got up decided to fix this issue (mainly because I need to set up a bridge). Oh well, what a crazy decision. I spent the whole day tracking down the problem; it took so long because I didn't know anything about the kernel's networking code and because GNU gdb did strange things.
After dealing with the kernel core dump and reading a big amount of code, I started to understand what was going on. (I can say that I learned a lot during the process, although I am still missing many, many details.) And finally I isolated the problem.
For some reason, the card is producing zero-length packets with some unusual flags active. I guess these are raised to notify the driver about a special condition but, without the card specs (they used to be public, but now you have to fill in a form and wait for confirmation to get them), it is very difficult to know what's going on. FWIW, I looked at the Linux driver and they simply ignore these packets. Basically, they assume that if a packet does not have the first fragment nor the last fragment bits set, it's incorrect.
So I've done a patch that discards these packets, just as Linux does. You can find it in this thread (the first one is incorrect; the second one is almost correct, except the assertion). I'm waiting to do a bit more testing locally to later commit the patch.
However, I think I still haven't found the root of the problem. All this patch does is add some more sanity checks, but those zero-length packets shouldn't be generated at all (according to what I see in Linux when reproducing a similar scenario).
