FreeRTOS_gethostbyname max delay

Kernel
1

friesen wrote on Wednesday, October 17, 2018:

What is the maximum block time caused by gethostbyname? I was under the impression that this is defined by ipconfigSOCK_DEFAULT_RECEIVE_BLOCK_TIME however I am getting blocks at least twice this time. The blocks happen when the network is down, but I would like some idea how to estimate or reduce this time.

2

heinbali01 wrote on Wednesday, October 17, 2018:

Before I getting into those details, have you considered using FreeRTOS_gethostbyname_a()?

It will be available if you define ipconfigDNS_USE_CALLBACKS as 1.

It allows you to find an IP-address without waiting for it. You will receive an application call-back

3

friesen wrote on Wednesday, October 17, 2018:

Callbacks and state machines don’t play very well together in this case.

4

friesen wrote on Wednesday, October 17, 2018:

Looking at the code for byname_a, it would appear to fall through to prvGetHostByName anyway, so how does this avoid blocking?

5

heinbali01 wrote on Thursday, October 18, 2018:

I was under the impression that this is defined by
ipconfigSOCK_DEFAULT_RECEIVE_BLOCK_TIME
however I am getting blocks at least twice this time

The DNS requests are sent repeatedly, up to ipconfigDNS_REQUEST_ATTEMPTS times.
Have you defined this macro? It defaults to:

/* The maximum number of times a DNS request should be
sent out if a response is not received, before giving up. */
#ifndef ipconfigDNS_REQUEST_ATTEMPTS
	#define ipconfigDNS_REQUEST_ATTEMPTS		5
#endif

Looking at the code for byname_a, it would appear to fall through to
prvGetHostByName anyway, so how does this avoid blocking?

prvGetHostByName() will be called in a non-blocking way because the parameter xReadTimeOut_ms has been set to zero.

If you are using the latest FreeRTOS+TCP from github, unfortunately, FreeRTOS_gethostbyname_a() will not work properly.

I repaired it in my own branch on Github

Please use FreeRTOS_DNS.c and FreeRTOS_UDP_IP.c.

The idea of the call-back is as follows:

Send out a DNS request. Do not wait for an answer. When the DNS reply comes in, call the registered call-back routine.

6

friesen wrote on Thursday, October 18, 2018:

Thank you for that clarification, I’ll give this a try.

7

friesen wrote on Thursday, October 18, 2018:

How exactly is pvSearchID used internally?

This doesn’t have any examples, so it would appear that this is just some pointer, it isn’t actively checking the value in any way, is this right?

8

friesen wrote on Thursday, October 18, 2018:

Also, I am getting an exception when I call FreeRTOS_gethostbyname_cancel(&somevar) at vListInsertEnd.

Another problem, why isn’t dhcpDNS_SERVER_OPTIONS_CODE in the ucDHCPRequestOptions on line 907? It seems that this should rather be defined in the headers as an option.

9

heinbali01 wrote on Friday, October 19, 2018:

How exactly is pvSearchID used internally?

It is a pointer which has only meaning to the application, for instance a pointer to an object.

Also, I am getting an exception when I call FreeRTOS_gethostbyname_cancel(&somevar) at vListInsertEnd.

FreeRTOS_gethostbyname_cancel() calls vDNSCheckCallBack(), which will call uxListRemove().
You’re saying that you see an exception occurring in vListInsertEnd(). I don’t see how it can get there?

why isn’t dhcpDNS_SERVER_OPTIONS_CODE in the ucDHCPRequestOptions[]
on line 907?
It seems that this should rather be defined in the headers as an option.

The DNS server option is already included in ucDHCPDiscoverOptions[].
Would you like to make this configurable?

10

friesen wrote on Friday, October 19, 2018:

I won’t claim to completely understand how the list is implemented, but the stackpointer location at the crash crash pointed me to this being caused somehow by my use of either FreeRTOS_gethostbyname_a or FreeRTOS_gethostbyname_cancel. I figured it had something to do with calling these with a parameter rather than letting it time out, and the list getting removed twice perhaps.

I’ll do some more digging here on the DHCP, I should have started a different thread for that. I am having trouble getting dns settings through dhcp from a sonicwall tz105.

11

friesen wrote on Monday, October 22, 2018:

This is happening in FreeRTOS_gethostbyname_a -> vDNSSetCallBack at vListInsertEnd

I’m a bit unclear what I am doing wrong. I am calling it like

FreeRTOS_gethostbyname_a(urlstart, DNS_Callback, &hostaddr, 25000);
12

heinbali01 wrote on Tuesday, October 23, 2018:

Erik, could it be that you’re calling FreeRTOS_gethostbyname_a() before the network it up?
I mean, before vIPNetworkUpCalls() is called?
If so, the list that gathers the call-backs has not been initialised by vDNSInitialise() yet.

13

friesen wrote on Tuesday, October 23, 2018:

Its likely. Is there any way this could get patched though?

14

heinbali01 wrote on Tuesday, October 23, 2018:

Yes, I wouldn’t mind if vDNSInitialise() get called much earlier ( in FreeRTOS_IPInit() ) and only once.
I will propose this change.