WIZnet Developer Forum

Missing Responses intermittently when used with 3G Router

Hi,

I am using the W7500S2E-R1 module and configured as TCP client in DHCP mode.

W7500S2E-R1 is connected to a Desktop using Serial Interface and the other end (Ethernet) is connected to 3G Router (transfers data via cellular network using SIM card). The Desktop is running teraterm to input data & display incoming data on screen and is configured correctly. (Default settings - Baud Rate: 115,200, data size: 8, Parity: None, stop bit: 1 and Flow control: None).

I sent a HTTP request from teraterm and get HTTP response from Wiznet module. But, in some instances it fails to receive HTTP response back from Wiznet module. The very next HTTP request will get a HTTP response successfully. I have attached both the teraterm & the relevant Wireshark logs. When checking the Wireshark log, I found that the HTTP response actually reaches the LAN interface but not the serial interface. Deeper analysis shows that any response that comes after the 0.8 secs from HTTP request sent time , is ignored by wiznet module and doesn’t get passed to serial interface. Instead, the wiznet module assumes the socket is lost and send another SYN packet to server. Below is one of the sample for no-response,

At no 89, HTTP request (port no: 5006) is been made; after 3 re-transmission of data, finally the response reached the LAN interface at 93; soon after a SYN packet is sent to the server with new port number 5007. Meanwhile, the response doesn’t get reached to serial interface, which is evident in the teraterm log I attached (at the same time 2021-02-16 15:02:50). Same instance happened in last request at 2021-02-16 15:05:39. Is there any internal response timeout that causing this issue. However I have disabled the available wiznet timers (Inactivity Time, Keep Alive Time - set to zero).

Can anyone help how to recover?

Thanks in advance.

Note: teraterm and Wireshark logs are edited to hide confidential infos. This problem never exists with LAN or 4G router.
logs.zip (4.3 KB)

Are there any symptoms even if I set the Inactivity Time to 2000?
And set a value to keepalive in this module and keep the connection from being disconnected.
It may be a network problem, so it would be nice to test it.

Hi Irina,

Thanks for replying.

I made another set of testing with modifying the Inactivity & Keepalive timer. Still the problem exists. We have even done outdoor testing with full signal coverage. Didn’t help either.
Attached logs for your review. Please help.

Testcases done:

  1. InactiveTimer - 0 (disabled) KeepAliveTimer - 0 (disabled)
  2. InactiveTimer - 60000 ms (max value) KeepAliveTimer - 0 (disabled)
  3. InactiveTimer - 60000 ms (max value) KeepAliveTimer - 250, unit: 5s (max value)
    log-2.zip (43.9 KB)

Note: Failed connections are highlighted in attached teraterm logs

Hi Praveena,

I’ve tried to test W7500S2E-R1 with a setting similar to your situation:

Sending an HTTP request (GET / HTTP/1.1) to the IP address shown in your wireshark record
by send packet from PC through serial port repeatedly every 0.8s.

The result of the test was :both receiving and sending packet of the module worked fine. Serial on my PC received all packet from the IP address.

Serial setting:

  • Baud Rate: 115,200
  • data size: 8
  • Parity: None
  • stop bit: 1
  • Flow control: None

Module network setting:

  • Firmware version: 2.4 (which can be downloaded from wizse.com)
  • InactiveTimer - 0 (disabled)
  • KeepAliveTimer - 0 (disabled)

If I didnt get you wrong, what you meant was that your wiznet module had “cool-down” time of 0.8s, no data would be received during the cd?
And there was no port shifting during my test. I assume there was no disconnection throughout my test.

It would help if you could provide more detail about your situation, for example what data you sent to the address, so that I can have another test much more closer to your situation

It is also suggested to check the setting and performance of your 3G module/connection due to the fact that in some cases 3G connection could be slower than serial communication with baud rate 115200, or the performance of the website to see if any misbehavior happened.

Attached is the wireshark record of my test

800ms problem of W7500s2eR1.zip (16.1 KB)

Hi,

We can’t share IP or URL details in forum. I simply explain the issue here.

W7500S2E-R1 is connected to a Desktop using Serial Interface and the other end (Ethernet) is connected to 3G Router (transfers data via cellular network using SIM card). The Desktop is running teraterm to input data & display incoming data on screen and is configured correctly. (Default settings - Baud Rate: 115,200, data size: 8, Parity: None, stop bit: 1 and Flow control: None).

I am sending a HTTP request to a server using serial port (PC serial settings - Baud Rate: 115,200, data size: 8, Parity: None, stop bit: 1 and Flow control: None). I was expecting a HTTP response back to serial port. But I am not getting the response back. When seeing the wireshark log I found, the response actually reaching the LAN interface but not to the serial interface (in teraterm). Observing few failure instances, (I am not sure though, it’s a guess) I found that the response time in Wiznet (roughly 0.8 secs) may causing a timeout and the response is lost. Because, Wiznet does 3 re-transmission of HTTP request; if the ACK or either response reaches LAN after the 3 re-transmission, ideally after ~0.8 secs, will be ignored by wiznet and a new connection is started by sending SYN packet to the server with new port number.

We have tried with different server IPs. Also tried with 38400 baudrate. We get the same result.

Can you able to simulate a simple server, send a HTTP request and delay both the ACK & response by 1 sec and see the result? 3G connection could be slower, but we want to see how wiznet would handle this.

Hi Pravaana,

Since ACK packets is to confirm whether the connection is fine, and normally it should be sent within 0.2s after receiving data, it should be sent ASAP once one end receives a packet. And it is independent from the reply packet of the server.

Since the port changed, losing the packet from you PC through serial made sense.

We are able to alter the buffer time for disconnection for you if necessary. However, checking your the performance/transmission speed of your 3Grouter beforehand is suggested as the time for ack packet is not often seen.

You are welcomed to send us your problem through email if you need further support and are worry about privacy.

Hi,

Thank you so much you came forward to help.

Can you please provide a new software with configurable response time (buffer time for disconnection in your term) for TCP commands with an AT command so that even if there is any delay in serial port or router the connection won’t be affected. Please make the response time to be bit enlarged like 0 to 60 secs.

Hi Pravaana,

I understand your concern. However I am afraid we cannot provide such a software to you.

After double-checked the protocol document RFC1122(RFC 1122 - Requirements for Internet Hosts - Communication Layers), we found that normally a TCP delayed acknowledgment should not be longer than 500ms:

4.2.3.2 When to Send an ACK Segment

A TCP SHOULD implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment.

The wiznet module already has a buffer upon the standard delayed ACK. It is suggested checking the performance of your 3Grouter or server since other unknown problems would be arisen along with the abnormal delayed ACKs and replies.

Or I personally reckon you could alter the code on your PC side to compromise with the late ACKs and replies if you want to keep the performance the way it performs.

Copyright © 2017 WIZnet Co., Ltd. All Rights Reserved.