Hi Thanasis, thanks for taking the time. I appreciate your effort.
On Mar 2, 10:09 pm, Thanasis <[email protected]> wrote: > I still think that you are looking at the wrong direction. This has > something to do with the comm link. In that case I would expect that I either get randomly messed up messages, or at random times, or problems at regular intervals (after x characters, something like that). But what I observe is that the messages are _always_ bad when using _one_ originator, and _always_ good when using a different one. No matter how much I've done in the same terminal session before, no matter in which order I send the messages, always the same pattern. > > This PDU with the dozens of FFs at the end, is certainly *not* a bad > encoded PDU. I can see why you say that. However, look at what the terminal session shows. I sent off three SM with originator "Stefan Renz", each with more text appended to the content. Then, I sent the same content in the same order, but this time with originator "Renz Stefan". Here's what shows up: +CMGL: 2,1,,34 0891534875001040F30414D0537AD91C7683A465B71E0000013030414101400CC7F79B0C6ABFE5EEB4FB0C +CMGL: 3,1,,54 0891534875001040F30414D0537AD91C7683A465B71E00000130304141024023C7F79B0C6ABFE5EEB4FB0CA2BF41F977DD052ADACBF23C1D9D769F41EFF50F +CMGL: 4,1,,71 0891534875001040F30414D0537AD91C7683A465B71E00000130304172944036C7F79B0C6ABFE5EEB4FB0CA2BF41F977DD052ADACBF23C1D9D769F41EFF50FF444B3407474987E029DE5E5307DF30A01 +CMGL: 5,1,,163 0891534875001040F30414D0D2B25B0F0000000000000F30204420B2AF0F90A0CBE6B01B00000130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF +CMGL: 6,1,,163 0891534875001040F30414D0D2B25B0F0000000000000F30604420B2AF0F90A0CBE6B01B00000130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF +CMGL: 7,1,,163 0891534875001040F30414D0D2B25B0F0000000000000F30704420B2AF0F90A0CBE6B01B00000130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF So I rule out that I mis-use the bulk gateway, because in that case I would not be able to decode the first three messages. I also rule our that the message length has something to do with it, as I sent different content. I've also sent the messages to my mobile phone, where they come out right. > I understand that you are giving the CGMR command by hand (i.e > Hyperterminal?) and still get those FFs, right? Have you tried to play > with XON/XOFF or hardware handshake settings and see if it makes any > difference? Yes, I'm working off kermit on Linux, tried different settings, speeds, etc. Unfortunately, to no avail. So what I can rule out: * cause in smslib, as smslib is not at all involved (so I'm even more grateful for your help) * improper use of the bulk SMS gateway (see above) Leaves me with * serial communication is broken (what you suggest) * Pdu package is broken (apparently, but why?) * SIM card broken * provider broken * modem broken I'll need to get a different device, so I can rule out or prove the last three points. Oh, BTW, Nokia 6500c is not compatible with smslib as it doesn't support +CPMS and +CMGL, so I can't use my mobile phone to verify my issue :-( Thanks, bye Stefan > > On Mar 2, 10:14 pm, sgr <[email protected]> wrote: > > > Hi, > > > thanks for the hint. I tried as suggested, but it didn't change a bit. > > I think you're right with the buffer overflow: the TP-UDL (length of > > the message) comes _after_ the originator address, and as such is > > already garbled (does the mobile device look at that same field?). I > > guess that's why we see the FFs (and I've seen 00's as well in other > > garbled messages). Furthermore, the behavior is reliably reproducable > > -- regardless of which SM arrives first, the one with the "bad" > > originator string is always garbled. > > > I think I need to bite the bullet at decode the raw PDU string by hand > > to see where exactly things go awry. My bet is that the originator > > string is NOT encoded as expected, and looking at the comments in the > > PduParser, there seems to be some room for interpretation. > > > I'll keep you posted, but would still appreciate any hints... > > > Bye > > Stefan > > > On Mar 2, 8:30 pm, Thanasis <[email protected]> wrote: > > > > Hi, > > > > I've seen this sequence of FFs before, but had nothing to do with the > > > actual message. Those strange FFs are sign of a communication failure, > > > maybe a buffer overflow or something going wrong with the serial port > > > connecting the phone. > > > > Try to work with different baud rates. Start with 9600, test and > > > increase baud rate. I could bet that this has nothing to do with the > > > originator string. > > > > On Mar 2, 2:34 pm, sgr <[email protected]> wrote: > > > > > Hi, > > > > > I have trouble parsing a PDU message with an originator address other > > > > than an international phone number. Let me briefly explain the purpose > > > > and setup before I go into the message specifics. > > > > > I need to receive an SM sent by a business partner. They probably send > > > > the SM via a bulk SMS gateway, using an arbitrary string as the > > > > originator address. I also have access to a bulk SMS gateway, so I can > > > > approximate what the partner sends us. I receive the SM on a GSM-Modem > > > > (Siemens M20), using the smsserver component of smslib. I'm > > > > interpreting the received SM by implementing > > > > org.smslib.smsserver.interfaces.Interface#MessagesReceived. > > > > I've tested the implementation by sending an SMS to the modem from my > > > > mobile phone. Works like a charm. > > > > > However, things change when I receive messages from certain originator > > > > addresses of type D0, for example, "Renz Stefan". All PDU data > > > > following the originator address block seems to be garbled, looking at > > > > the resulting SmsDeliveryPdu object. I've seen TP-PIDs of 0x21 and > > > > 0x58, where 0x00 is expected. Also, the TP-SCTS is either way in the > > > > future, or in the past (by years). > > > > > Here's the raw PDU that I read from the modem (e.g. by issuing AT > > > > +CMGR=...): > > > > 0891534875001040F30414D0D2B25B0F0000000000000F30204420B2AF0F90A0CBE6B01B000 > > > > > > > > 00130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > > > > > > > > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > > > > > > > > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > > > > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF > > > > > Using a different originator, say, using now "Stefan Renz" instead of > > > > "Renz Stefan", works out well: the SMS is well parsable by the > > > > PduParser: > > > > here's the raw PDU String I copied from the terminal program: > > > > 0891534875001040F30414D0537AD91C7683A465B71E0000013020017560400CC7F79B0C6AB > > > > FE5EEB4FB0C > > > > > The only difference between the two are the originator address, and > > > > the time sent. Immediately striking is the fact that the garbled > > > > message is much longer and seems to be somewhat padded. > > > > > In order to play with those messages, I directly use > > > > org.ajwcc.pduUtils.gsm3040.PduParser#parse, passing in those raw PDU > > > > strings, and looking at the resulting Pdu objects. > > > > > Does anyone have an idea of where I go wrong, or what the problem may > > > > be? The whole issue looks rather strange to me, especially since the > > > > PDU data received on the modem already looks garbled. > > > > > Thanks in advance, > > > > Stefan -- You received this message because you are subscribed to the Google Groups "SMSLib User Group" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/smslib?hl=en.
