Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 3112] CDP Checksum Calculation Incorrect

Date: Fri, 12 Dec 2008 11:29:54 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3112





--- Comment #2 from Greg Neujahr <wireshark@xxxxxxxxxxxxxxxxxxxxx>  2008-12-12 11:29:53 PDT ---
(In reply to comment #1)
Yep. Noticed the code there, but haven't had a chance to trace through all the
optimizations that are present. It does seem to support odd-length
calculations, but I've yet to figure out exactly how it's managing that. I've
provided two C functions that provide checksumming for CDP below. One that
produces checksums that work with Wireshark, and one that produces checksums
that work with cisco equipment, but not with wireshark. They key bit of
difference seems to be in how the last byte is handled. If it is just added
into the sum as a regular byte say 0xAA, then it passes wireshark's test, but
it should be added in as a padded byte as 0xAA00. 

unsigned short real_cdp_checksum(const char *data, int length) {
        unsigned long sum = 0;
        const unsigned short *d = (const unsigned short *)data;

        while (length > 1) {
                sum += *d++;
                length -= 2;
        }
        if (length)
                sum += htons(*((unsigned char *)d));

        sum = (sum >> 16) + (sum & 0xffff);
        sum += (sum >> 16);
        return (unsigned short)~sum;
}

unsigned short wireshark_cdp_checksum(const char *data, int length) {
        unsigned long sum = 0;
        const unsigned short *d = (const unsigned short *)data;

        while (length > 1) {
                sum += *d++;
                length -= 2;
        }
        if (length)
                sum += *((unsigned char *)d);

        sum = (sum >> 16) + (sum & 0xffff);
        sum += (sum >> 16);
        return (unsigned short)~sum;
}

Having looked over that and glanced at the code a bit more, it would seem that
this case is handled by the mlen == -1 case at the bottom, but it's failing to
account for it for some reason. Perhaps over the weekend I'll get a spare
moment to break out my debugger and walk through the calculations. I'm sure it
has something to do with the endian-ness and the byte length. But could also be
byte boundry related too. 


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.