Ok, so trying with a different device shows different results -- I was
able to successfully receive the faulting SM on a mobile phone, and
read them out with AT+CMGL=0.
Next: I'll fetch the modem (it's installed at a hosting provider) to
check if it's the modem that's failing, or the SIM card.
Thanks for your help.
Bye
Stefan
On Mar 3, 9:07 pm, Thanasis <[email protected]> wrote:
> Yeah, I guess its better to find another phone or modem to test with
> as well.
>
> On Mar 3, 4:16 pm, sgr <[email protected]> wrote:
>
> > 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
> > 0891534875001040F30414D0537AD91C7683A465B71E0000013030414101400CC7F79B0C6AB
> > FE5EEB4FB0C
> > +CMGL: 3,1,,54
> > 0891534875001040F30414D0537AD91C7683A465B71E00000130304141024023C7F79B0C6AB
> > FE5EEB4FB0CA2BF41F977DD052ADACBF23C1D9D769F41EFF50F
> > +CMGL: 4,1,,71
> > 0891534875001040F30414D0537AD91C7683A465B71E00000130304172944036C7F79B0C6AB
> > FE5EEB4FB0CA2BF41F977DD052ADACBF23C1D9D769F41EFF50FF444B3407474987E029DE5E5
> > 307DF30A01
> > +CMGL: 5,1,,163
> > 0891534875001040F30414D0D2B25B0F0000000000000F30204420B2AF0F90A0CBE6B01B000
> > 00130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > +CMGL: 6,1,,163
> > 0891534875001040F30414D0D2B25B0F0000000000000F30604420B2AF0F90A0CBE6B01B000
> > 00130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > +CMGL: 7,1,,163
> > 0891534875001040F30414D0D2B25B0F0000000000000F30704420B2AF0F90A0CBE6B01B000
> > 00130FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> > FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
>
> > 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.
