FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

12729 questions

15121 answers

24266 comments

47324 members

0 votes
114 views 2 comments
by
I have a monitoring system that automatically sends a SMS when an event occurs. I can also query the system remotely by sending a SMS with a keyword and the system sends a SMS containing a report.

The system is composed of a STM32 arduino-like board with a W5200 ethernet interface board.

The interface is connected to an ethernet port of the RUTxxx.

The commands used are sms_total, sms_read, sms_delete and sms_send.

The first three commands work on both RUTxxx. But the sms_send does not send the SMS on the RUT900.

I have analyzed the ethernet traffic using Wireshark, and the frame that carries the sms_send command is the following:

0000   00 1e 42 13 a9 51 de ad be ef fe bb 08 00 45 00   ..B..Q........E.

0010   00 d3 00 40 40 00 80 06 56 43 c0 a8 11 50 c0 a8   ...@@...VC...P..

0020   11 01 04 6c 00 50 6e 2c e5 a4 d0 ff 1a c6 50 18   ...l.Pn,......P.

0030   08 00 d3 63 00 00 47 45 54 20 2f 2f 63 67 69 2d   ...c..GET //cgi-

0040   62 69 6e 2f 73 6d 73 5f 73 65 6e 64 3f 75 73 65   bin/sms_send?use

0050   72 6e 61 6d 65 3d 48 79 62 72 69 64 65 26 70 61   rname=Hybride&pa

0060   73 73 77 6f 72 64 3d 30 30 30 30 30 30 30 30 30   ssword=000000000

0070   30 26 6e 75 6d 62 65 72 3d 30 30 30 30 30 30 30  0&number=0000000

0080   37 37 37 26 74 65 78 74 3d 51 75 61 69 25 32 30   000&text=Quai%20

0090   61 62 73 65 6e 74 25 32 43 25 32 30 32 33 30 56   absent%2C%20230V

00a0   25 32 30 6f 6b 25 32 43 25 32 30 32 34 56 25 32   %20ok%2C%2024V%2

00b0   30 6f 6b 25 32 43 25 32 30 62 61 74 74 65 72 69   0ok%2C%20batteri

00c0   65 25 33 44 38 34 25 32 35 25 32 43 25 32 30 6f   e%3D84%25%2C%20o

00d0   6b 25 32 45 20 48 54 54 50 2f 31 2e 31 0d 0a 0d   k%2E HTTP/1.1...

00e0   0a   

No SMS is sent. (the password and phone number have been changed in this text from their actual values)                                        .

As a further test, I have copied the payload from this frame, and pasted it in the data field of the windows application Packet Sender. When captured, the frame sent by packet sender reads as follows:

0000   00 1e 42 13 a9 51 74 d0 2b 15 9f 79 08 00 45 00   ..B..Qt.+..y..E.

0010   00 d3 b4 ba 40 00 80 06 00 00 c0 a8 11 83 c0 a8   ....@...........

0020   11 01 e8 40 00 50 9e 3b b1 3f 3a 94 23 7a 50 18   ...@.P.;.?:.#zP.

0030   01 00 a4 9a 00 00 47 45 54 20 2f 2f 63 67 69 2d   ......GET //cgi-

0040   62 69 6e 2f 73 6d 73 5f 73 65 6e 64 3f 75 73 65   bin/sms_send?use

0050   72 6e 61 6d 65 3d 48 79 62 72 69 64 65 26 70 61   rname=Hybride&pa

0060   73 73 77 6f 72 64 3d 30 30 30 30 30 30 30 30 30   ssword=000000000

0070   30 26 6e 75 6d 62 65 72 3d 30 30 30 30 30 30 30   0&number=0000000

0080   30 30 30 26 74 65 78 74 3d 51 75 61 69 25 32 30   000&text=Quai%20

0090   61 62 73 65 6e 74 25 32 43 25 32 30 32 33 30 56   absent%2C%20230V

00a0   25 32 30 6f 6b 25 32 43 25 32 30 32 34 56 25 32   %20ok%2C%2024V%2

00b0   30 6f 6b 25 32 43 25 32 30 62 61 74 74 65 72 69   0ok%2C%20batteri

00c0   65 25 33 44 38 34 25 32 35 25 32 43 25 32 30 6f   e%3D84%25%2C%20o

00d0   6b 25 32 45 20 48 54 54 50 2f 31 2e 31 0d 0a 0d   k%2E HTTP/1.1...

00e0   0a                                                .

This frames DOES make the RUT900 send the SMS!

Only the first 53 bytes differ, as they are the frame header.

The ip address of the STM32 board is 192.168.17.80, and that of the PC that runs both Wireshark and Packet Sender is 192.168.17.131.

Another difference I see in the Wireshark record, is that in the cases that the command work, the next frame is an ACK frame, and the RUT900 sends a frame back containing "ok".

But when the sending fails, the next frame returned by the RUT900 is a TCP fin, ack frame, and no other frame is returned. i have no idea why this occurs.

Why would the RUT900 refuse this frame when it comes from the ip address 192.168.17.80, and accept it from ip address 192.168.17.131?

1 Answer

0 votes
by
Hello,

Could you start by providing the firmware version your device is using and the URL requests?

Best regards,

Žygimantas
by
The firmware version is 06.05.3.

What do you mean by URL requests? I do not type requests in the URL bar of a browser. Instead, the board I programmed sends TCP requests. The request that fails contains the following payload:

GET //cgi-bin/sms_send?username=Hybride&password=xxxxxxxxxx&number=xxxxxxxxxx&text=Quai%20absent%2C%20230V%20ok%2C%2024V%20ok%2C%20batterie%3D84%25%2C%20ok%2E HTTP/1.1\r\n\r\n

where \r is the CR character (0x0d) and \n is the LF character (0x0A).

 I paste here the ethernet traffic captured using WireShark. (I have overwritten the phone number and password wth "x").

192 0.004 192.168.17.80 192.168.17.1 HTTP 225 GET //cgi-bin/sms_send?username=Hybride&password=xxxxxxxxxx&number=xxxxxxxxxx&text=Quai%20absent%2C%20230V%20ok%2C%2024V%20ok%2C%20batterie%3D84%25%2C%20ok%2E HTTP/1.1

193 0.000 192.168.17.1 192.168.17.80 TCP 60 80 → 1128 [ACK] Seq=1 Ack=172 Win=30016 Len=0

194 0.007 192.168.17.80 192.168.17.1 TCP 60 1128 → 80 [FIN, ACK] Seq=172 Ack=1 Win=2048 Len=0

195 0.000 192.168.17.1 192.168.17.80 TCP 60 80 → 1128 [FIN, ACK] Seq=1 Ack=173 Win=30016 Len=0

196 0.000 192.168.17.80 192.168.17.1 TCP 60 1128 → 80 [ACK] Seq=173 Ack=2 Win=2048 Len=0

This sequence does not send the sms. As you can see, there is also a network problem since the RUT900 did not send the "ok" response.

However, if I paste into the "send sms" tab of the RUT900 webui the text "Quai absent, 230V ok, 24V ok, batterie=84%, ok.", the SMS is correctly sent and I receive it on my phone.
by
I found the cause of the problem.

When I send a command to the modem, I open a TCP connection, then I send the command, then I close the TCP connection. So far so good, the RUT500 behaves properly.

The RUT900, on the contrary, does not send the SMS because the TCP connection was closed at once. I have added a 3 second delay after the command is sent and before I close the connection, and then the RUT900 does send the SMS.

Is not that a bug? Why should the state of the TCP connection have an influence on the sending of a SMS which has nothing to do with ethernet and TCP/IP?