NDK Compatibility

Hi Jason,

Are you using a static IP address or DHCP? Are you adding a DNS server IP manually or letting DHCP supply it? Or maybe easier, do you have a small sample application that shows this (please include .c and .tcf)?

Thanks,
Todd

Todd,

I am not the end customer but I am fairly confident that DHCP is used with the IP is supplied by DHCP.  Are you available for a phone call with the end customer.  My email address is jason.haedt@avnet.com if you prefer to discuss this offline.  I appreciate the support.  Basically what happens with the latest release of the NDK is that in order to construct the IP address we have to look in the argument where the IP normally is jump to a different pointer that is filllled in that argument and concatenate it wilth values from the original argument list.  This is much different than how we have done this in the past and I was curios if we could go through some discussions on retrieving the IP over DHCP and discuss where that value should be loaded.  Thanks.

Jason

Jason,

For now, could you have the customer supply a simple test case first. I'd like to reproduce the problem here first.

Todd

CHAR CaptelURL[URL_LEN+1];

static U8 CaptionDNSBuf[512];

HOSTENT *DNS_data;

DNS_data = (HOSTENT *)&CaptionDNSBuf[0];

memset(CaptionDNSBuf, NULL, sizeof(CaptionDNSBuf));

strcpy(CaptelURL, "www.hybridcaptel.com");

result = DNSGetHostByName(CaptelURL, CaptionDNSBuf, sizeof(CaptionDNSBuf));

if( result == 0 )

{

CaptelIPAddr = DNS_data->h_addr[0];

CaptionSocketError = CAPTION_SOCKET_OK;

Captions_Eth_State = SOCKET_SETUP;

}

The code above shows how it worked in the old NDK (V1.94).  Since moving to V2.20, the resolved IP address no longer lives in h_addr[0].  h_addr[0] now appears to contain a pointer to an area of memory where two U32 values reside.  If you cat those two values together, you magically get the correct IP address.  None of documention or header files says this is the way DNSGetHostByName() should work.  What gives?

This is what we must do for the V2.20 NDK.

U16 Temp[2];

Temp[0] = *(U16 *)(DNS_data->h_addr[0]);

Temp[1] = *(U16 *)(DNS_data->h_addr[0]+2);

 CaptelIPAddr = Temp[0] | Temp[1]<<16;

- Dean

Hi Dean,

Could you please post a simple .c and .cfg?

Thanks,
Todd

Ummm, I did post simple .c code in my previous response.  What more do you need?  All the variables used by DNSGetHostByName() are shown with their definitions.  Furthermore, each variable is loaded with values that cause our issue.  I've shown the code we use to extract the IP address for V1.94 and V2.20.

Either DNSGetHostByName() changed in how it behaives between V1.94 and V2.20  ..or..  we've somehow screwed up the integration of the NDK into our project.

- Dean

Dean,

Based on past experience, the issue may not be related to the perceived problem. Having a complete example (i.e a .c and .cfg so we can build the exact same example) generally helps much more than a code snippet. It avoids us from having to make assumptions (e.g. what is the value of URL_LEN or what is the stack size of the task you are using).

Todd  

Based on your logic, you would require our entire project.  How did we setup NC_SystemOpen(), what NDK configuration are we using (DHCP, etc), you'll need our .h files, etc.  We don't have time at the moment to make a small stand alone project, as we are rushing towards a SW deadline.

My question is pretty straight forward, how does DNSGetHostByName() return the IP address for NDK V2.20?  We are seeing a difference from V1.94, and it doesn't match the documentation or header files.

If DNSGetHostByName() is still suppose to return the list of IP addresses in the h_add[] array, then we can begin the investigation on how we screwed up integrating the NDK.  If it is simply a documentation error, then I'll ask for the new API docs so we can make sure our code is correct.

If it helps, for all our NDK tasks, the stack size is 8192 bytes.  URL_LEN = 60.

- Dean

Todd, we used the trick to include the #define for the IPv6 code, followed the instructions in F.2.5.4, and everything now seems fine.  Thanks for your help.

- Dean