NETWORK ERROR

[sheldon123z]

Hi,
When I was testing freeRTOS for a small application, I encountered a NETWORK ERROR problem.
Because I am in China, so I am not sure if this issue is caused by the distance between me and amazon server is too far or some thing else. The area of my endpoint address is us-east-1. Actually, sometimes this problem does not exist at all, but sometimes the board cannot connect to my endpoint at all. Here is the error logs for running the shadow demo.

I (2090) WIFI: SYSTEM_EVENT_STA_CONNECTED
3 861 [IP-task] vDHCPProcess: offer c0a80105ip
I (8920) event: sta ip: 192.168.1.5, mask: 255.255.255.0, gw: 192.168.1.1
I (8920) WIFI: SYSTEM_EVENT_STA_GOT_IP
4 890 [IP-task] vDHCPProcess: offer c0a80105ip
5 891 [iot_thread] [INFO ][DEMO][8910] Successfully initialized the demo. Network type for the demo: 1
6 891 [iot_thread] [INFO ][MQTT][8910] MQTT library successfully initialized.
7 891 [iot_thread] [INFO ][Shadow][8910] Shadow library successfully initialized.
8 891 [iot_thread] [INFO ][DEMO][8910] Shadow Thing Name is esp32 (length 5).
9 1893 [iot_thread] [ERROR][NET][18930] Failed to resolve a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com.
10 1893 [iot_thread] [ERROR][MQTT][18930] Failed to establish new MQTT connection, error NETWORK ERROR.
11 1893 [iot_thread] [ERROR][DEMO][18930] MQTT CONNECT returned error NETWORK ERROR.
12 1893 [iot_thread] [INFO ][Shadow][18930] Shadow library cleanup done.
13 1893 [iot_thread] [INFO ][MQTT][18930] MQTT library cleanup done.
14 1893 [iot_thread] [ERROR][DEMO][18930] Error running demo.
15 1895 [iot_thread] [INFO ][INIT][18950] SDK cleanup done.

Any suggestions?

Regards,
Sheldon

[gordonwang0]

Hi Sheldon,

The following log message is reporting the error:

9 1893 [iot_thread] [ERROR][NET][18930] Failed to resolve a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com.

Can you verify the your network's DNS server is correctly configured? You can try running
nslookup a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com
on from a computer within the network to see if the hostname resolves correctly.

I get the following results, you should see something similar:

nslookup a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com

Non-authoritative answer:
Name:	a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com
Address: 3.217.158.67
Name:	a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com
Address: 54.173.67.16
Name:	a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com
Address: 54.236.143.226

[sheldon123z]

Hi,
Thank you for your reply, I have ran the code you provided and got the following result.

xiaodongs-MacBook-Pro-2:amazon-freertos xiaodongzheng$ nslookup a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com
Server:         202.96.134.133
Address:        202.96.134.133#53

Non-authoritative answer:
Name:   a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com
Address: 54.209.12.127
Name:   a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com
Address: 52.45.73.130
Name:   a1zwfs4sf2i9un-ats.iot.us-east-1.amazonaws.com
Address: 34.227.128.244


And actually, it turns out the demo sometimes runs successfully(maybe 1/10 chance), but most of the times are not. 

[htibosch]

And actually, it turns out the demo sometimes runs successfully
(maybe 1/10 chance), but most of the times are not.

It is not normal that the DNS lookup fails most of the time.
The DNS look-up is controlled by two macro's: ipconfigSOCK_DEFAULT_RECEIVE_BLOCK_TIME and ipconfigDNS_REQUEST_ATTEMPTS.
Can you check the actual values of these two macro's in your FreeRTOSIPConfig.h?
Can you also check the values of ipconfigUSE_DNS_CACHE and ipconfigDNS_CACHE_ENTRIES?

I would suggest these values:

#define ipconfigSOCK_DEFAULT_RECEIVE_BLOCK_TIME pdMS_TO_TICKS( 3000 )
#define ipconfigDNS_REQUEST_ATTEMPTS            3
#define ipconfigUSE_DNS_CACHE                   1
#define ipconfigDNS_CACHE_ENTRIES               20

Meaning: every look-up has a timeout of of 3 seconds, it should look-up 3 times. The results of DNS look-ups must be cached. The cache will contain at most 20 entries.

[sheldon123z]

Thank you very much, it was the issue that those parameters weren't set correctly. My problems have been solved and this issue is closed.

[boshueryi]

Hello Sheldon,
I met the same problem. Would you please tell me which parameters did you changed to solve this problem?
Thanke you !

Regards,
Zhenhui

[htibosch]

When doing a DNS lookup, there used to be a read-timeout of ipconfigSOCK_DEFAULT_RECEIVE_BLOCK_TIME.

However, by default, this macro is defined as:

#define ipconfigSOCK_DEFAULT_RECEIVE_BLOCK_TIME   portMAX_DELAY

Since a recent pull request, 2 new macros were introduced to configure the DNS handling:

#define ipconfigDNS_RECEIVE_BLOCK_TIME_TICKS   pdMS_TO_TICKS( 500u )
#define ipconfigDNS_SEND_BLOCK_TIME_TICKS      pdMS_TO_TICKS( 500u )

both with a default value of 0.5 seconds.

That is maybe short, and you might want to give them a value of 2 seconds (pdMS_TO_TICKS( 2000u )).