SMPPDEBUG shows - WaitForResponseSMPP: Invalid Packet

Author

Message

Ian Mac
New member
Username: Imcgraw

Post Number: 1
Registered: 01-2006

Posted on Thursday, January 26, 2006 - 05:06 pm:

Hi,

I am working on an smpp server application that is to support NowSMS.

The SMPPDEBUG is show a lot of "WaitForResponseSMPP: Invalid Packet" messages. However the debug granularity isn't detailed enough to say why it's invalid.

Maybe it's a timeout?

16:50:57:860 (0000012C) 192.168.1.120 <-: 43 byte packet
16:50:57:860 (0000012C) 192.168.1.120 <-: 00 00 00 2B 80 00 00 04 00 00 00 00 00 00 00 03 +
16:50:57:860 (0000012C) 192.168.1.120 <-: 45 41 42 43 33 31 34 31 34 31 34 35 32 31 32 36 EABC314141452126
16:50:57:860 (0000012C) 192.168.1.120 <-: 35 32 35 34 35 36 32 35 35 33 00 5254562553
16:50:57:860 (0000012C) 192.168.1.120 --: WaitForResponseSMPP: Invalid Packet
16:50:57:876 (0000012C) 192.168.1.120 <-: 16 byte packet
16:50:57:876 (0000012C) 192.168.1.120 <-: 00 00 00 10 80 00 00 15 00 00 00 00 00 00 00 04
16:50:57:876 (0000012C) 192.168.1.120 --: WaitForResponseSMPP: Invalid Packet
16:50:57:876 (0000012C) 192.168.1.120 <-: 16 byte packet
16:50:57:876 (0000012C) 192.168.1.120 <-: 00 00 00 10 80 00 00 15 00 00 00 00 00 00 00 05
16:50:57:876 (0000012C) 192.168.1.120 --: WaitForResponseSMPP: Invalid Packet
16:50:57:876 (0000012C) 192.168.1.120 <-: 16 byte packet
16:50:57:876 (0000012C) 192.168.1.120 <-: 00 00 00 10 80 00 00 15 00 00 00 00 00 00 00 06
16:50:57:876 (0000012C) 192.168.1.120 --: WaitForResponseSMPP: Invalid Packet
16:50:57:876 (0000012C) 192.168.1.120 <-: 16 byte packet
16:50:57:891 (0000012C) 192.168.1.120 <-: 00 00 00 10 80 00 00 15 00 00 00 00 00 00 00 07
16:50:57:891 (0000012C) 192.168.1.120 --: WaitForResponseSMPP: Invalid Packet
16:50:57:891 (0000012C) 192.168.1.120 <-: 16 byte packet
16:50:57:891 (0000012C) 192.168.1.120 <-: 00 00 00 10 80 00 00 15 00 00 00 00 00 00 00 08
16:50:57:891 (0000012C) 192.168.1.120 --: WaitForResponseSMPP: Invalid Packet

Ian Mac
New member
Username: Imcgraw

Post Number: 2
Registered: 01-2006

Posted on Thursday, January 26, 2006 - 05:09 pm:

....sorry forgot to say the debug shows the ENQUIRE_LINK_RESP messages our app is sending back and it looks like there is a problem with the format od these messages. But quite what I'm not sure.

Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5446
Registered: 10-2002

Posted on Thursday, January 26, 2006 - 06:33 pm:

Hi Ian,

The first thing that I would suggest is trying the NowSMS patch at http://www.nowsms.com/download/latestpatch.zip. (This is a patch for v5.51, so if you don't have v5.51, first you need to update, which you can do by downloading the latest trial version from our web site.) I say that because there were some timing problems that we had with a few SMPP client applications. (The problem would occur most often if the application sent the request over multiple TCP packets instead of as a single packet.)

But I'd be surprised if that is what is happening here, because in that case, I believe we'd actually see timeout errors.

I'd like to see a more complete log ...

One thing I don't understand ... You're sending ENQUIRE_LINK_RESP, but is it in response to an ENQUIRE_LINK?

I think I'd need a more complete log of the entire session in order to get a better feel for the logic of what is occurring.

-bn

Ian Mac
New member
Username: Imcgraw

Post Number: 3
Registered: 01-2006

Posted on Friday, January 27, 2006 - 09:20 am:

Hi bn,

Thanks for your help. I have upgraded using the patch. The main gateway config app now shows the version as v5.51k.

I have attached the log showing the bind, submit and unbind operations. Looks like the same problem with the Enquire Link though.

Thanks, Ian.

SMPP Log
SMPPDEBUG.LOG (3.9 k)

Ian Mac
New member
Username: Imcgraw

Post Number: 4
Registered: 01-2006

Posted on Friday, January 27, 2006 - 10:35 am:

Am looking at this with Ethereal - there appear to be old RESPONSE messages being sent from our end to NowSMS.

Thanks for looking at this but it definitely looks like our end doing the wrong thing.

Best regards, Ian.