How to: Debug modems from kannel logs

Continue reading below only if you’re interested in how to decode the hex strings and other info in the kannel bearerbox.log:These are the errors that keep showing up repeatedly:2012-06-29 01:19:42 [1567] [6] DEBUG: AT2[usb0-modem]: TP-Validity-Period: 24.0 hours
2012-06-29 01:19:42 [1567] [6] DEBUG: AT2[usb0-modem]: –> AT+CMGS=153^M
2012-06-29 01:19:42 [1567] [6] DEBUG: AT2[usb0-modem]: <– >
2012-06-29 01:19:42 [1567] [6] DEBUG: AT2[usb0-modem]: send command status: 1
2012-06-29 01:19:42 [1567] [6] DEBUG: AT2[usb0-modem]: –>
001100099120729100F00008A78C0E020E2D0E420E170E290E040E480E300E230E300E1A0E1A0E440E
210E480E400E020E490E320E430E080E020E490E2D0E040E270E320E210E020E2D0E070E170E480E3
20E1900200E150E490E2D0E070E010E320E230E040E270E320E210E0A0E480E270E220E400E2B0E25
0E370E2D0E420E170E23003000380039002D0038003100310031003600390038
2012-06-29 01:19:42 [1567] [6] DEBUG: AT2[usb0-modem]: –> ^Z
2012-06-29 01:19:45 [1567] [6] DEBUG: AT2[usb0-modem]: <– >
2012-06-29 01:19:45 [1567] [6] DEBUG: AT2[usb0-modem]: <– ERROR
2012-06-29 01:19:45 [1567] [6] ERROR: AT2[usb0-modem]: Generic error: ERROR
2012-06-29 01:19:45 [1567] [6] DEBUG: AT2[usb0-modem]: send command status: -1
It looks like what it’s doing is it keeps all failed SMS’s in its queue for a certain period of time, and keeps trying to resend SMS’s in its queue which in turn keep failing. Here’s some useful info:
–> AT+CMGS=153^M
This is the command to tell it to send a message. The 153 is supposed to be the number of bytes in the string (although I count 154 bytes). What follows is the hex string containing the number, the mesage, and other info, and then it sends a –> ^Z to denote the end of the message.
To extract the phone number from the hex string (this wasn’t online anywhere but I was able to figure this out by reconciling it with the message log):
Starting with the 6th byte, extract all bytes until you reach 00. From the example above, this gets us: 20729100F0. Next, the nibbles in each byte appear to be in litte-endian format, so reverse them. This gets: 022719000F. Finally, the F digit is just filler for phone numbers with an odd number of digits (so when there’s an even number of digits it’s not there), and the final number is 022719000 (the “Top-Up Origin” contact).
After the phone number, there seems to be two bytes of info and then the rest of the hex string is the actual message to send (the above one is in unicode).
Share
Tags
Similar Articles
Another day, another Zero Day: What all Digital Development organizations should take away from recent IT security news
Even if you don’t work as a software developer, you probably heard about recent, high profile security issues that had IT Admins and developers frantically patching servers over the holidays and again more recently. Dimagi's CTO shares what these recent issues mean for Digital Development organizations.
Technology
January 28, 2022
Join the fight to support critical open source infrastructure
Open Source tools are a critical piece of global infrastructure, and need champions for long term investment
Technology
March 17, 2020
Two big lessons that Iowa and Geneva can teach us about technology in digital development
Last week brought two high profile technology failures into the global spotlight. Although these two mishaps may seem quite different at first glance, they both highlight challenges that are inherent in providing software in the public sector (regardless of locale) and illustrate cautionary lessons worth discussing for practitioners in Digital Development. The Iowa Caucus Debacle
Technology
February 7, 2020