Pre lbl-3.3 tcpdump (like the one in -current) mistakenly believes
that the small udp packet is actually a truncated one because of a
logic bug in print-udp.c (which probably produced correct results for
the wrong reasons on interfaces which padded ethernet packets to
ETHERMIN before the bpf_tap.)  Of course nowadays we have more
advanced hw that pads for us so the driver doesn't have to, and very
short packets get shoved down the bpf_tap pipe to bring these bugs to
light. But anyways:

Fix: 

tcpdump v3.3 from ftp.ee.lbl.gov fixes the problem.

Since we are a release behind, I have done nearly all of the work necessary 
to merge this into -current and created a kit which I have uploaded as

ftp://ftp.freebsd.org/pub/FreeBSD/incoming/tcpdump-to-lbl33-merge.tar.gz

MD5 (tcpdump-to-lbl33-merge.tar.gz) = 7fa45cf54d5ce868d21bfeaecde55b3e

The kit consists of a buildable reference tree that resulted from my local 
CVS merge (into a copy of the FreeBSD tree) of lbl-3.3 tcpdump, and a patch
kit to address merge conflicts (a couple of -Wall patches are included
separately.)

A complete narrative of length war and peace is included which explains
how this would be useful to someone really merging this into our tree.
Normally the corresponding release of libpcap would be merged at the
same time - I can do that, too, but would like some feedback on whether
or not this kind of submission is useful or appropriate.
How-To-Repeat: 
To see the bug, use netcat to query a udp time server, such as the one
that inetd can run, and monitor the transaction from the same machine
using tcpdump:

   nc -u -z -w 1 pahtoh time

   15:54:37.024031 [|udp]
   15:54:37.025030 pahtoh.cwu.edu.time > swash.cts.cwu.edu.1267: udp 4

Merged -current+lbl-3.3 correctly processes this:

   15:57:39.021435 swash.cts.cwu.edu.1271 > pahtoh.cwu.edu.time: udp 1
   15:57:39.022410 pahtoh.cwu.edu.time > swash.cts.cwu.edu.1271: udp 4