Re: Message "in_cksum_skip: out of data by ...."

On Sun, Oct 7, 2012 at 10:43 AM, David Wolfskill <david_at_catwhisker.org> wrote:
> On Sun, Oct 07, 2012 at 10:03:04AM -0700, Garrett Cooper wrote:
>> ...
>>     Maybe these revisions had something to do with it... (r241245 is
>> more likely)?
>>
>> ------------------------------------------------------------------------
>> r241245 | glebius | 2012-10-06 03:02:11 -0700 (Sat, 06 Oct 2012) | 19 lines
>>
>>   A step in resolving mess with byte ordering for AF_INET. After this change:
>> ...
>> ------------------------------------------------------------------------
>> r241244 | glebius | 2012-10-06 00:06:57 -0700 (Sat, 06 Oct 2012) | 5 lines
>>
>>   The pfil(9) layer guarantees us presence of the protocol header,
>> so remove extra check, that is always false.
>> ...
>
>>     Did you rebuild all of your modules, and (for David) are you
>> running any firmware blobs with your wireless NIC?
>
> Yes; when I update, my changes from the process in src/UPDATING
> generally augment what's there (e.g., to clear /usr/include &
> /usr/share/man before the make installworld).
>
> And the NIC that's in use (at home -- and most other places) on the
> laptop is iwn(4), so yes, there is a firmware blob:
>
>  4    1 0xc138a000 54e38    iwn5000fw.ko
>
> (Well, that particular line is from kldstat when it's running stable/9;
> I just checked the head slice, and the blob had been rebuilt (based on
> mtime), and has contents different from the contents in stable/9:
>
> g1-227(9.1-P)[3] md5 /{,S4/}boot/kernel/iwn5000fw.ko
> MD5 (/boot/kernel/iwn5000fw.ko) = 8f98e8f28c70fe801c73aec4f717973f
> MD5 (/S4/boot/kernel/iwn5000fw.ko) = a0150e03bfd307595ab37b0924252844
> g1-227(9.1-P)[4] ls -lT !$
> ls -lT /{,S4/}boot/kernel/iwn5000fw.ko
> -r-xr-xr-x  1 root  wheel  345868 Oct  7 07:48:46 2012 /S4/boot/kernel/iwn5000fw.ko
> -r-xr-xr-x  1 root  wheel  344416 Oct  7 04:51:11 2012 /boot/kernel/iwn5000fw.ko
> g1-227(9.1-P)[5]
>
> FWIW.)
>
> As noted, the message does not appear to be associated with (other)
> unwanted behavior, so I wouldn't consider this of earth-shattering
> importance.  It just seemed rather odd, and I got to wondering if
> the developer who committed the change had intended this result.
> And if said result was actually of use to anyone.  :-}

    Given that the issue is present on both your machine and
Michael's, it's unlikely that it's firmware related (unless re(4) is
doing something hacktacularly awesome!), but I just wanted to gather
all the facts before something's brought up to glebius_at_, if the issue
is indeed one of the two commits (or both) mentioned above.
    Could you guys please try reverting one or both of the commits to
see if the issue goes away?
Thanks!
-Garrett