| Err 066 |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through April 12, 2010 ⬆ |
◄ ► |
| Author | Message | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 7 Registered: 10-2009 |
I am receiving err 066 while sending SMS from a SIM to a short code. 2010-01-18 13:43:29,76mobilenet,SMSReceive,41080176,+15332727771,47707863.req,Text,Text=id: 47707861 sub:001 dlvrd:000 submit date:1001181338 done date:1001181338 stat:REJECTD err:066 text:>¤PFAL,Alarm.Clear 2010-01-18 13:43:37,76mobilenet,SMSReceive,41080176,+15332727771,47707864.req,Text,Text=id: 47707862 sub:001 dlvrd:000 submit date:1001181338 done date:1001181339 stat:REJECTD err:066 text:>¤PFAL,Sys.Device. Please advice. Regards Adnan | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 8 Registered: 10-2009 |
Can some one please guide me what err 066 means? Is there a problem at teh cusotmers end who has a SC in his application or there is a problem at our SMSC end? Please advice. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1673 Registered: 08-2008 |
Hi, Are you saying that the outbound SMSC connection is a GSM modem with a SIM card? These error numbers tend to be SMSC specific. However ... if you are sending out via a GSM modem, they should be somewhat consistent. When creating the non-delivery report in this situation, NowSMS inserts the TP-Status value (from GSM/3GPP TS 03.40) as the "err:" value in decimal format. This particular value is defined as a permanent error with the description "Connection rejected by SME". I interpret this as meaning that the receiver (short code application) is actively rejecting the message. What if you take the SIM card out of the modem and put it into a phone ... are you able to send to that short code using the SIM in a phone? Assuming that you can't, I'd suggest talking to your short code provider. -- Des NowSMS Support | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 9 Registered: 10-2009 |
I am using an unlock cell phone as well as device in the field with a US SIM but still unable to send SMS to a SC. SC can send SMS easily to SIM but unable to receive any. You mentioned that this message is due to SC application rejecting the message, it means at the customer end, his application is rejecting it. Please note that this log is from our SMPP GW to the customer's SC app. Please calrify if we need to escalate this to the customer. Thanks Adnan | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1674 Registered: 08-2008 |
Hi Adnan, I need more of an explanation of the overall message flow in order to provide more advice. I assume that you are trying to send a message to a short code from either a phone or modem, and it is failing. If this is the case, it could be a problem at the customer end ... but it is more likely a problem with how the short code is provisioned. You should check with the short code provider. -- Des NowSMS Support | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 10 Registered: 10-2009 |
Yes, you are right. I am trying to send a message to a short code from either a phone or modem, and it is failing. We are the SC provider to the customers. But we are receiving this error on our SMSC GW while trying to send SMS to the SC. So, should I ask customer to verify at his end? | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 11 Registered: 10-2009 |
Do we need to modify any thing at our end? Please also note that there are number of other customers that are working abs fine with inbound SMS to their SC. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1675 Registered: 08-2008 |
That helps provide some clarity. But I still do not have a good picture of the overall message flow within your system. The error message above looks like you are trying to send a message to 41080176 via an outbound SMSC connection, and the SMSC connection is rejecting it. I would assume that there is an SMSOUT-yyyymmdd.LOG entry that also records this ... what does it say? However, if you are the short code provider, normally the message should get routed to a customer application, not an outbound SMSC connection. (There are different ways that you could set this up ... it is possible for a customer application to be an outbound SMSC connection, but this would be unusual.) So the next thing I would need to know is how you are expecting to route the message to the customer application? Is the customer application a 2-way HTTP command? Or is it an SMPP client that connects in to your system? Or some other type of configuration? I'm going to take a guess that the customer application is an SMPP client. In the "SMS Users" account definition, do you have 41080176 defined in the "Recipient address(es) to route to this user" field? If not, then your system does not know to route this short code to that user account. I'm making an educated guess here ... but I could be way off. One of the strong points of NowSMS is that there are a lot of different ways that customers can configure it to accomplish different tasks. So I may be making a wrong guess about how you have NowSMS configured. If something doesn't sound right in my explanation above, please explain more about how a message should flow through your system to the customer application. And let me know what you see regarding any of these messages in the SMSIN-yyyymmdd.LOG and SMSOUT-yyyymmdd.LOG files. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1676 Registered: 08-2008 |
Probably. Look closely at all of the configuration settings that you have setup for other customers. My guess is that this "Recipient address(es) to route to this user" is not set correctly for this customer. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 12 Registered: 10-2009 |
Customer's application is a SMPP client. In our system, we define a range like 410801XX which accepts all coming in the range. So, I don't think that some thing is missing here. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 13 Registered: 10-2009 |
is there any number I can reach at you? Can we place a conference call with me, you & our NE personal to further elaborate this issue? can you please provide your direct number? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1677 Registered: 08-2008 |
Ok ... but please understand that I need more details to provide any further advice or assistance. The customer's application is an SMPP client. This would mean that you have an account defined for them under "SMS Users" in NowSMS. What exactly do you have specified in the "Recipient address(es) to route to this user" field? (410801XX would not work as "X" is not considered a wildcard character ... "?" or "*" should be used. "?" matches exactly one character. "*" matches 0 or more characters.) When a message is sent to the short code, do any records get generated in SMSOUT-yyyymmdd.LOG and/or SMSIN-yyyymmdd.LOG? What do they say? -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1678 Registered: 08-2008 |
I prefer to see things like log files excerpts and screen shot images to telephone conversations. The problem is that conversations tend to gloss over important details. If you are confused by the questions that I am asking above ... then please just e-mail your SMSOUT-yyyymmdd.LOG, SMSIN-yyyymmdd.LOG and SMSGW.INI files to nowsms@nowsms.com. Put "Attention: Des" in the subject line. Basically, I need to see exactly what is specified in the "Recipient address(es) to route to this user" field for the account associated with this customer. I also need to see the IN and OUT log records that show the messages being processed. It's after hours here, so I am going to be off-line for a few hours, but will check again later to see if you have sent any additional detail. If you do send any details via e-mail, please post a follow-up here so that I can look for the e-mail in case it is not routed to me automatically. -- Des NowSMS Support | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 14 Registered: 10-2009 |
I can see my SMS to teh SC in SMSOUT: 2010-01-19 11:00:12,5044BFAF.req,,41080176,OK -- LocalUser:cingular,SubmitUser=SMPP - 209.183.52.48:8010;Sender=+15004238644;Text="Reply from kore" Another record: 2010-01-19 11:34:35,5044C3C4.req,10.191.2.31,+15004238644,OK -- SMPP - 209.183.52.48:8010,SubmitUser=cingular;Sender=41080176;SMSCMsgId=45C98EE4;Text=" Test@" Please advice. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 15 Registered: 10-2009 |
I have sent an email to you with the attached files. Please elaborate. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1679 Registered: 08-2008 |
You should probably send me today's logs. I don't see any problem with 41080176 in yesterday's logs. Whenever a message is sent to 41080176 (I see several test messages), the message gets queued to the "SMS Users" account named "cingular". So if there is an SMPP receiver or transceiver connected for that account, it should receive the message. Perhaps something different is happening today, but that is what was happening yesterday. I do notice some error 066 references yesterday, associated with other short codes, and I will elaborate on that after I study the log further. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 16 Registered: 10-2009 |
Please refer to the below: 2010-01-19 11:00:12,5044BFAF.req,,41080176,OK -- LocalUser:cingular,SubmitUser=SMPP - 209.183.52.48:8010;Sender=+15004238644;Text="Reply from kore" It is the message I have sent to 41080176 using my US SIM but it never reached to teh destination. Please analyze the logs why 41080176 not receiving any SMS. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1680 Registered: 08-2008 |
Regarding the error 066. Now that I can see that your outbound SMSC is SMPP based, I can explain that 066 is the error code that your provider is using to reject some messages that are being sent. The SMSOUT log contains the following additional detail description for this error "ERROR: ESME Receiver Reject Message Error Code - ESME_RX_R_APPN" 66 is the decimal value for the ESME_RX_R_APPN error. This is an error code that your provider is generating when you attempt to send some messages to them. Let me give you several examples from your SMSOUT-20100119.LOG file so that you can understand. At 00:58:09, user account cingular tried to send a message out from short code 41080163 to +1500462xxxx (I blanked out the last four digits but you can refer to your log file for details). Your SMPP provider rejected this message with error code ESME_RX_R_APPN. Because a delivery receipt was requested, a non-delivery notification is sent back to that short code indicating error 066. The same thing happens again at 00:58:42, with a message being sent by the short code to the same recipient. At 10:03:41, short code 41080132 encounters a similar situation. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 17 Registered: 10-2009 |
There are not much we can analyze for todays logs as we didn't test much today. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1681 Registered: 08-2008 |
From our logs, what I can see is that the message is received and routed to the "cingular" account. Lots of other short codes seem to also be routed to this "cingular" account. For example, at 11:00:10 (2 seconds prior), a message is received for short code 41080115 and also routed to the "cingular" account. From my perspective, it looks like NowSMS is routing messages to this "cingular" account. I don't know what happens next because at that point the message has left NowSMS and has been picked up by another SMPP client. In any event ... the "err:066" seems to be unrelated to any of this. I'd suggest you check the software that is connecting to NowSMS under the this "cingular" account. It appears to be receiving messages for multiple short codes, and from what I can see in these logs, messages for 41080176 are getting routed there ... but once the message leaves NowSMS, we don't know what the other system does with it. -- Des NowSMS Support | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 18 Registered: 10-2009 |
Are you confirming that the messages for 41080176 are leaving our NowSMS to the custmer's application? Obviously we don't know what the customer is doing with it. But we need to make sure that the problem doesn't lie at our end. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1682 Registered: 08-2008 |
I don't know enough about your overall system. What I can tell you is that the message is leaving that NowSMS server via the "cingular" user account. I don't know if this "cingular" account is the end point at which your customer connects, or if it is an intermediate point connecting to some other software within your company. When I look at your logs, I see many short codes being delivered to this "cingular" account. This short code is not being handled any differently. I just don't have visibility to what is on the other side of that "cingular" account. It may be at your customer site, or it may be some other software within your company. All I can know is that the message is being routed from NowSMS to the "cingular" account, along with messages for quite a few other short codes. What happens at that point is under the control of a different system. -- Des NowSMS Support | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 19 Registered: 10-2009 |
Yes, Cingular account is the end point at our end for all the customers. Does it mean now that the problem is at cusotmers end as we are are delivering it to them from this account? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1683 Registered: 08-2008 |
All customers connect using this same account? That doesn't compute for me. Do you have multiple customers connecting to this NowSMS server using the same cingular account name? That will not work. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 20 Registered: 10-2009 |
You can see in the logs that many short codes being delivered to this "cingular" account. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 21 Registered: 10-2009 |
what is the difference in SMSOUT & SMSIN log files? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1684 Registered: 08-2008 |
The cingular account should be receiving multiple short codes including the problem short code. Do all of those codes plus the problem one belong to one customer? If so, they must be having some problem on their end in processing this one code. I would suggest having them use Wireshark on their end in order to verify that the problem short code messages are being presented to their system. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 22 Registered: 10-2009 |
NO, all the SC coming to this account belong to different customers & none of them is facing any issue except this SC. All the customers are directly connected to this account so it seems as if their SC is not receiving any inbound SMS. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1690 Registered: 08-2008 |
That is my point. If all of the customers are directly connected to this single account, any of the customers could be receiving any of the messages. From the NowSMS perspective, it sees this as a single account. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 23 Registered: 10-2009 |
But each customer has its independent SC so that any incoming SMS will go directly to their respective SC. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1693 Registered: 08-2008 |
How is that supposed to happen? Let me emphasize my point ... from a NowSMS perspective, using examples from your log. Messages for 41080176 and 41080115 (and many other numbers) are all routed to the "cingular" account. Whatever customer is connected to this "cingular" account can receive any of these messages. NowSMS sees them as all belonging to the same account. What I think is happening is that you have some other software component in your overall system. That component connects to NowSMS using the "cingular" account. And that software component receives messages for all of these short codes, and dispatches the messages to different customers depending on the short code. On the NowSMS server that you are talking about here ... all of these short codes are being routed to a single customer account. | |||
| Robert Trabue New member Username: Rtrabue Post Number: 1 Registered: 01-2010 |
Hello. We are the customer. I ran across this thread trying to figure out things on our end. What kind of information do you need from us? We would really like to get this to work. A couple of key points here: We are using an SMPP client that we developed in-house, so it is not a commercial product. The software uses a TcpClient object for socket communications. It binds successfully as a transceiver, in accordance with the SMPP 3.4 spec. SMS submitted to us via a deliver_sm packet from another short code on the account Muhammad is using do reach us, but SMS from a SIM provided by his company never do. Our submit_sm packets also go out properly. We've checked out all of our network settings and don't see a problem with them. There should be no obstructions to packets from the SMPP server. We were thinking of setting up a computer outside of our firewall to rule this out completely. Our internet carrier is not directly affiliated with AT&T/Cingular, so we don't think the failure in routing the SMS packets is on our side. I can provide additional information as needed. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1694 Registered: 08-2008 |
Hi Robert, Thank you for entering the discussion. Here is what I would suggest. Download Wireshark (http://www.wireshark.org), and use it to capture packets between this NowSMS server and your SMPP client. Verify that you are indeed not receiving these messages. If you are, indeed, not receiving these messages, then I am still suspicious about something that was mentioned above. If there are multiple customers connecting using this same "cingular" account name, then these messages could be sent to any one of the connections that is bound as a receiver or transceiver. In fact, I take it that you are physically separated from Adnan. Let me ask you this ... is the user account name that you use to bind to the system "cingular"? I am suspicious that you are binding to a different server, because all of the logs that I have seen show messages for multiple customer short codes going into a single customer account. -- Des NowSMS Support | |||
| Robert Trabue New member Username: Rtrabue Post Number: 2 Registered: 01-2010 |
I'll download Wireshark and make sure its use is cleared with our network admin. If it is, I'll see what it can tell us. Muhammad and I work for different companies in different countries, so we are separated. Essentially, his company is a wireless carrier, and we are a customer. Our account name for connecting to their SMPP server is not "cingular". Cingular is the former name of the wireless division of AT&T, one of Muhammad's company's wireless carrier partners. A lot of their hardware, such as cellular towers, and a lot of their software systems still bear the Cingular name after AT&T bought them out. I don't work for or with AT&T, so I don't know exactly where the "cingular" name is coming up. It could easily be an APN, a server network, a cellular tower, or a router interfacing with the land line network. Muhammad would know more about this than I would. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 24 Registered: 10-2009 |
Cingular is just an account name we use in our NowSMS server. It has nothing to do with it external world like AT&T. We provide independent credentials to each SMPP user to connect with us. Robert also has an individual credentials which he used to connect to our SMPP GW. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1695 Registered: 08-2008 |
Robert, Thanks for the confirmation that you are not logging in with an account named "cingular". This confirms to me that nearly all of the above discussion is looking for a problem in the wrong place. The NowSMS server that all of this discussion has been about ... is queuing up messages for these short codes and delivering them to an account named "cingular". If you are not the one logging in as "cingular", then some other entity is connecting to this NowSMS server as "cingular". That entity extracts the messages for your short code and some how routes them to you. Maybe it's another NowSMS server that is doing this ... or maybe it is some other piece of software. Muhammad ... I think you're looking in the wrong place. This NowSMS server appears to be processing the message correctly ... but we don't know what happens after the "cingular" account logs in and collects the message. That appears some other entity in your network that sits between NowSMS and your customer. -- Des NowSMS Support | |||
| Robert Trabue New member Username: Rtrabue Post Number: 3 Registered: 01-2010 |
If that is the case, do I need to troubleshoot further with Wireshark? | |||
| Robert Trabue New member Username: Rtrabue Post Number: 4 Registered: 01-2010 |
If that is the case, do I need to continue troubleshooting with Wireshark? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1696 Registered: 08-2008 |
Hi Robert, I would still suggest using Wireshark to confirm that the problem is not somehow in your receiver software. (I can't tell you how many times we've been down this path and there has been a problem in the receiver software. I don't suspect it to be the case here, but best to use Wireshark to rule it out as a potential issue.) I have no operational access or control over this system, so keep in mind that I am only speculating based upon limited knowledge of the operational environment. My suspicion is that there is a secondary system, to which you are connecting, and that secondary system is not provisioned properly with your additional short code. All of the discussion here (and log files that have been sent to me) has been focused on a primary system ... and from what I can see, this primary system seems to functioning properly. Whatever is going wrong seems to be happening in between this system and your point of connection. -- Des NowSMS Support | |||
| Robert Trabue New member Username: Rtrabue Post Number: 5 Registered: 01-2010 |
Well, it very well may be a problem with the client program. Are there certain socket option settings I should be using when I create the TcpClient object to make sure we can rule that out? The code for setting up the socket looks like this: Dim oLOption As New LingerOption(True, 10) Dim oSocket As Socket . . . '---Create local IP address oLocalIP = IPAddress.Parse(szLocalIP) '---Create local IPEndPoint oLocalEndPoint = New IPEndPoint(oLocalIP, iLocalPort) '---Create TCPClient object with local IP address and port oSocket = New Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp) oSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, True) oSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.DontLinger, False) oSocket.LingerState = oLOption oSocket.ExclusiveAddressUse = False oSocket.NoDelay = True oSocket.Bind(oLocalEndPoint) oTCPClient = New TcpClient() oTCPClient.Client = oSocket The program then connect to their URL and port for the SMPP bind system, and it gets started with the bind_transceiver operations. Of course, it works for everything except receiving an SMS from on of their SIMs. An SMS from one of their short codes comes right through. I got clearance to use Wireshark from our network admin, so I am going to set that up. | |||
| Muhammad Adnan farooq New member Username: Adnan Post Number: 25 Registered: 10-2009 |
Ok Robert. Please let us know the result. | |||
| Robert Trabue New member Username: Rtrabue Post Number: 6 Registered: 01-2010 |
We tried to set up a laptop outside our network, but without a spare gateway, this wasn't possible. I installed Wireshark on our server and let it run for 6 minutes. All the while, I had a wireless device spitting out an SMS every 10 seconds to our short code. We got nothing. I did notice that Wireshark was complaining about packets from our service having an invalid checksum of 0x0000. I believe the firewall recalculates the checksum when they pass through because they are reaching the NowSMS server. This is cut and paste of the text file where I saved the capture of the traffic to and from our SMPP bind client service: No. Time Source Destination Protocol Info 1 0.000000 192.168.100.4 205.200.236.237 TCP 11015 > ridgeway2 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Frame 1 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 2 0.074145 205.200.236.237 192.168.100.4 TCP ridgeway2 > 11015 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1380 Frame 2 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: Cisco_db:24:f8 (00:16:9d:db:24:f8), Dst: Supermic_2e:cc:92 (00:30:48:2e:cc:92) Internet Protocol, Src: 205.200.236.237 (205.200.236.237), Dst: 192.168.100.4 (192.168.100.4) Transmission Control Protocol, Src Port: ridgeway2 (2777), Dst Port: 11015 (11015), Seq: 0, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 3 0.074169 192.168.100.4 205.200.236.237 TCP 11015 > ridgeway2 [ACK] Seq=1 Ack=1 Win=65535 Len=0 Frame 3 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 1, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 4 1.005971 192.168.100.4 205.200.236.237 SMPP SMPP Bind_transceiver Frame 4 (96 bytes on wire, 96 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 1, Ack: 1, Len: 42 Short Message Peer to Peer, Command: Bind_transceiver, Seq: 2075841367, Len: 42 No. Time Source Destination Protocol Info 5 1.080669 205.200.236.237 192.168.100.4 SMPP SMPP Bind_transceiver - resp: "Ok" Frame 5 (82 bytes on wire, 82 bytes captured) Ethernet II, Src: Cisco_db:24:f8 (00:16:9d:db:24:f8), Dst: Supermic_2e:cc:92 (00:30:48:2e:cc:92) Internet Protocol, Src: 205.200.236.237 (205.200.236.237), Dst: 192.168.100.4 (192.168.100.4) Transmission Control Protocol, Src Port: ridgeway2 (2777), Dst Port: 11015 (11015), Seq: 1, Ack: 43, Len: 28 Short Message Peer to Peer, Command: Bind_transceiver - resp, Status: "Ok", Seq: 2075841367, Len: 28 No. Time Source Destination Protocol Info 6 1.280628 192.168.100.4 205.200.236.237 TCP 11015 > ridgeway2 [ACK] Seq=43 Ack=29 Win=65507 Len=0 Frame 6 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 43, Ack: 29, Len: 0 No. Time Source Destination Protocol Info 7 1.999410 192.168.100.4 205.200.236.237 SMPP SMPP Bind_transceiver Frame 7 (96 bytes on wire, 96 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 43, Ack: 29, Len: 42 Short Message Peer to Peer, Command: Bind_transceiver, Seq: 2075841368, Len: 42 No. Time Source Destination Protocol Info 8 2.073989 205.200.236.237 192.168.100.4 SMPP SMPP Generic_nack: "Invalid command ID" Frame 8 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Cisco_db:24:f8 (00:16:9d:db:24:f8), Dst: Supermic_2e:cc:92 (00:30:48:2e:cc:92) Internet Protocol, Src: 205.200.236.237 (205.200.236.237), Dst: 192.168.100.4 (192.168.100.4) Transmission Control Protocol, Src Port: ridgeway2 (2777), Dst Port: 11015 (11015), Seq: 29, Ack: 85, Len: 16 Short Message Peer to Peer, Command: Generic_nack, Status: "Invalid command ID", Seq: 2075841368, Len: 16 No. Time Source Destination Protocol Info 9 2.264920 192.168.100.4 205.200.236.237 TCP 11015 > ridgeway2 [ACK] Seq=85 Ack=45 Win=65491 Len=0 Frame 9 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 85, Ack: 45, Len: 0 No. Time Source Destination Protocol Info 10 61.014958 192.168.100.4 205.200.236.237 SMPP SMPP Enquire_link Frame 10 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 85, Ack: 45, Len: 16 Short Message Peer to Peer, Command: Enquire_link, Seq: 2075841369, Len: 16 No. Time Source Destination Protocol Info 11 61.089019 205.200.236.237 192.168.100.4 SMPP SMPP Enquire_link - resp: "Ok" Frame 11 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Cisco_db:24:f8 (00:16:9d:db:24:f8), Dst: Supermic_2e:cc:92 (00:30:48:2e:cc:92) Internet Protocol, Src: 205.200.236.237 (205.200.236.237), Dst: 192.168.100.4 (192.168.100.4) Transmission Control Protocol, Src Port: ridgeway2 (2777), Dst Port: 11015 (11015), Seq: 45, Ack: 101, Len: 16 Short Message Peer to Peer, Command: Enquire_link - resp, Status: "Ok", Seq: 2075841369, Len: 16 No. Time Source Destination Protocol Info 12 61.214991 192.168.100.4 205.200.236.237 TCP 11015 > ridgeway2 [ACK] Seq=101 Ack=61 Win=65475 Len=0 Frame 12 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 101, Ack: 61, Len: 0 No. Time Source Destination Protocol Info 13 120.024187 192.168.100.4 205.200.236.237 SMPP SMPP Enquire_link Frame 13 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 101, Ack: 61, Len: 16 Short Message Peer to Peer, Command: Enquire_link, Seq: 2075841370, Len: 16 No. Time Source Destination Protocol Info 14 120.098421 205.200.236.237 192.168.100.4 SMPP SMPP Enquire_link - resp: "Ok" Frame 14 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Cisco_db:24:f8 (00:16:9d:db:24:f8), Dst: Supermic_2e:cc:92 (00:30:48:2e:cc:92) Internet Protocol, Src: 205.200.236.237 (205.200.236.237), Dst: 192.168.100.4 (192.168.100.4) Transmission Control Protocol, Src Port: ridgeway2 (2777), Dst Port: 11015 (11015), Seq: 61, Ack: 117, Len: 16 Short Message Peer to Peer, Command: Enquire_link - resp, Status: "Ok", Seq: 2075841370, Len: 16 No. Time Source Destination Protocol Info 15 120.274023 192.168.100.4 205.200.236.237 TCP 11015 > ridgeway2 [ACK] Seq=117 Ack=77 Win=65459 Len=0 Frame 15 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 117, Ack: 77, Len: 0 No. Time Source Destination Protocol Info 16 180.020934 192.168.100.4 205.200.236.237 SMPP SMPP Enquire_link Frame 16 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 117, Ack: 77, Len: 16 Short Message Peer to Peer, Command: Enquire_link, Seq: 2075841371, Len: 16 No. Time Source Destination Protocol Info 17 180.094750 205.200.236.237 192.168.100.4 SMPP SMPP Enquire_link - resp: "Ok" Frame 17 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Cisco_db:24:f8 (00:16:9d:db:24:f8), Dst: Supermic_2e:cc:92 (00:30:48:2e:cc:92) Internet Protocol, Src: 205.200.236.237 (205.200.236.237), Dst: 192.168.100.4 (192.168.100.4) Transmission Control Protocol, Src Port: ridgeway2 (2777), Dst Port: 11015 (11015), Seq: 77, Ack: 133, Len: 16 Short Message Peer to Peer, Command: Enquire_link - resp, Status: "Ok", Seq: 2075841371, Len: 16 No. Time Source Destination Protocol Info 18 180.208419 192.168.100.4 205.200.236.237 TCP 11015 > ridgeway2 [ACK] Seq=133 Ack=93 Win=65443 Len=0 Frame 18 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 133, Ack: 93, Len: 0 No. Time Source Destination Protocol Info 19 240.017615 192.168.100.4 205.200.236.237 SMPP SMPP Enquire_link Frame 19 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 133, Ack: 93, Len: 16 Short Message Peer to Peer, Command: Enquire_link, Seq: 2075841372, Len: 16 No. Time Source Destination Protocol Info 20 240.094715 205.200.236.237 192.168.100.4 SMPP SMPP Enquire_link - resp: "Ok" Frame 20 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Cisco_db:24:f8 (00:16:9d:db:24:f8), Dst: Supermic_2e:cc:92 (00:30:48:2e:cc:92) Internet Protocol, Src: 205.200.236.237 (205.200.236.237), Dst: 192.168.100.4 (192.168.100.4) Transmission Control Protocol, Src Port: ridgeway2 (2777), Dst Port: 11015 (11015), Seq: 93, Ack: 149, Len: 16 Short Message Peer to Peer, Command: Enquire_link - resp, Status: "Ok", Seq: 2075841372, Len: 16 No. Time Source Destination Protocol Info 21 240.251884 192.168.100.4 205.200.236.237 TCP 11015 > ridgeway2 [ACK] Seq=149 Ack=109 Win=65427 Len=0 Frame 21 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 149, Ack: 109, Len: 0 No. Time Source Destination Protocol Info 22 300.014357 192.168.100.4 205.200.236.237 SMPP SMPP Enquire_link Frame 22 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 149, Ack: 109, Len: 16 Short Message Peer to Peer, Command: Enquire_link, Seq: 2075841373, Len: 16 No. Time Source Destination Protocol Info 23 300.088037 205.200.236.237 192.168.100.4 SMPP SMPP Enquire_link - resp: "Ok" Frame 23 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Cisco_db:24:f8 (00:16:9d:db:24:f8), Dst: Supermic_2e:cc:92 (00:30:48:2e:cc:92) Internet Protocol, Src: 205.200.236.237 (205.200.236.237), Dst: 192.168.100.4 (192.168.100.4) Transmission Control Protocol, Src Port: ridgeway2 (2777), Dst Port: 11015 (11015), Seq: 109, Ack: 165, Len: 16 Short Message Peer to Peer, Command: Enquire_link - resp, Status: "Ok", Seq: 2075841373, Len: 16 No. Time Source Destination Protocol Info 24 300.295411 192.168.100.4 205.200.236.237 TCP 11015 > ridgeway2 [ACK] Seq=165 Ack=125 Win=65411 Len=0 Frame 24 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 165, Ack: 125, Len: 0 No. Time Source Destination Protocol Info 25 360.042108 192.168.100.4 205.200.236.237 SMPP SMPP Enquire_link Frame 25 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 165, Ack: 125, Len: 16 Short Message Peer to Peer, Command: Enquire_link, Seq: 2075841374, Len: 16 No. Time Source Destination Protocol Info 26 360.116273 205.200.236.237 192.168.100.4 SMPP SMPP Enquire_link - resp: "Ok" Frame 26 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: Cisco_db:24:f8 (00:16:9d:db:24:f8), Dst: Supermic_2e:cc:92 (00:30:48:2e:cc:92) Internet Protocol, Src: 205.200.236.237 (205.200.236.237), Dst: 192.168.100.4 (192.168.100.4) Transmission Control Protocol, Src Port: ridgeway2 (2777), Dst Port: 11015 (11015), Seq: 125, Ack: 181, Len: 16 Short Message Peer to Peer, Command: Enquire_link - resp, Status: "Ok", Seq: 2075841374, Len: 16 No. Time Source Destination Protocol Info 27 360.120239 192.168.100.4 205.200.236.237 TCP 11015 > ridgeway2 [ACK] Seq=181 Ack=141 Win=65395 Len=0 Frame 27 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Supermic_2e:cc:92 (00:30:48:2e:cc:92), Dst: Cisco_db:24:f8 (00:16:9d:db:24:f8) Internet Protocol, Src: 192.168.100.4 (192.168.100.4), Dst: 205.200.236.237 (205.200.236.237) Transmission Control Protocol, Src Port: 11015 (11015), Dst Port: ridgeway2 (2777), Seq: 181, Ack: 141, Len: 0 | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1697 Registered: 08-2008 |
Yes, invalid checksums are normal because of firewalls/NAT routers. I've never seen a Wireshark trace that doesn't report them, regardless of what's being traced. I think Muhammad needs to look at the server to which you are connecting for possible answers. To troubleshoot this any further, we need to know what happens when the message leaves the NowSMS server discussed thus far in this thread. The message is leaving this NowSMS server, and is being picked up by some other entity that is using an account named "cingular". We need to know what happens next. Is it another NowSMS server to which you are connecting? Or is it some other piece of software? So far we don't know. All we know is that the NowSMS server being discussed in this thread is routing your messages for pick up by an SMPP client that logs in using the account name "cingular". We know that your SMPP client is not logging in with the account name "cingular", so we know that there is some other system between this NowSMS server and your SMPP client. Whatever is happening wrong with the messages is happening there. So I'm not sure what other support I can offer here. The logs that I've seen indicate that the NowSMS server in question is doing what it is supposed to do. I guess there is one other thing I can suggest to you Robert ... which might help ... Look at the binary data in the 'SMPP Bind_transceiver - resp: "Ok"' ... does the text "NowSMS" appear? If it does, then your client is connecting to a NowSMS server ... it is just a different one than Muhammad is looking at. In this case, he should look for the NowSMS server on which your user account is defined ... and make sure that your short code is defined in the "Recipient address(es) to route to this user" field for your account. If NowSMS does not appear in the 'Bind_transceiver - resp', then you're connected to some other system that is acting as an intermediary. In either case ... with this information you can give Muhammad an idea of where to look, because the server that he seems to be looking at thus far seems to be the wrong one. He might need to look at a different NowSMS server, or they might have some other piece of middleware that needs to be provisioned with this additional short code. -- Des NowSMS Support | |||
| Robert Trabue New member Username: Rtrabue Post Number: 7 Registered: 01-2010 |
Yes, the text "NowSMS" does appear in that 'SMPP Bind_transceiver - resp: "Ok"' (a.k.a. bind_transceiver_resp) packet. I am also able to extract that text as the name of the SMSC, along with SMPP version 3400 (3.4), from the bind_transceiver_resp packet when I parse it with my client. Ok, so it sounds like the problem is not with our SMPP client software or our network, so we can rule those two factors out. Agreed? Without access, familiarity, or training with Muhammad's network, there is nothing else I can do from my side. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1698 Registered: 08-2008 |
Hi Robert, I don't think there's anything wrong on your end. The only thing I see that is unusual is that you are trying to bind a second time after you have already successfully bound (you see the "generic nack" response to the second bind attempt). However, that won't cause any operational problems. Unfortunately, at this point, there's nothing that I can do to help. All of the diagnostic and configuration information that I have received in this thread comes from a different NowSMS server than the one you are connecting to. I'd wager that the solution is simple ... and it's the solution that I've already suggested three or four times in this thread already. You are logging in to a NowSMS server with a specific account name. The configuration of that account has a setting titled "Recipient address(es) to route to this user". All short codes that are routed to your account need to be listed here ... otherwise the message doesn't get routed to you. This configuration setting can have a comma delimited list of numbers (no spaces). And a number in the list can have a wildcard ... "*" to match 0 or more numbers or "?" to match a single number. I've suggested looking at this setting multiple times. But it is necessary to look at the correct server. Unfortunately, I have no operational control or access to this server. -- Des NowSMS Support | |||
