Summary: | ASTERISK-23488: Logic error in callerid checksum processing | ||||
Reporter: | Russ Meyerriecks (rmeyerriecks) | Labels: | |||
Date Opened: | 2014-03-14 11:11:46 | Date Closed: | 2014-03-17 17:25:16 | ||
Priority: | Major | Regression? | No | ||
Status: | Closed/Complete | Components: | Core/CallerID | ||
Versions: | 1.8.15.1 | Frequency of Occurrence | Constant | ||
Related Issues: |
| ||||
Environment: | Attachments: | ( 0) checksum_fix_v2.patch ( 1) checksum_fix.patch | |||
Description: | In short, callerid will fail if the checksum is ever calculated to 0x00. A valid checksum lies in the range 0-255, a 16 bit value. We suddenly started seeing our CID tests in production fail fairly consistently. I believe this is due to the transmitted date field incrementing to the point where checksums were more often calculated close to the 0x00 value.
The following line in main/callerid.c which checks the received cid checksum (b) against the calculated checksum will overflow with a checksum of 0x00: if (b != (256 - (cid->cksum & 0xff))) { Even though cid->cksum is masked off, 0x100-0x00 is 0x100 which fails this check. A better way to do this is to add our calculated checksum to the transmitted 2's compliment checksum. if (b + (cid->cksum & 0xff)) { | ||||
Comments: | By: Russ Meyerriecks (rmeyerriecks) 2014-03-14 11:13:18.624-0500 Added a patch that fixes the issue. Patch applies cleanly to asterisk 1.8.15. By: Russ Meyerriecks (rmeyerriecks) 2014-03-17 13:29:06.445-0500 Updated patch to match reviewboard |