CC3220SF: Ping response

In general, the code looks ok.

if you are in an enterprise network, please make sure ping is enabled (try to ping 166.62.28.82 by another device (pone/laptop) connected to the same router). 

Can you provide an air sniffer log (e.g. wireshark)?

Hi,

Yes I try to ping the  "166.62.28.82" Ip which is fine. able to ping from the laptop.

Well I am not sure about the disable or enable the ping setting but I would say this issue started getting before 4 days, so far was good not event update the framework.

Hi,

Not possible with Wireshark option ? As I understood Wireshark capture the log only where it's open ? 

I don't know how to take it from the router. 

Could you suggest me what and all possibility to failed the ping if internet is available 

I'm not familiar with issue with the ping unless an external firewall disables it. Can you test it in another environment?

Air sniffer can work if you provide it the passphrase (see https://wiki.wireshark.org/HowToDecrypt802.11)

This should be the easiest way to understand the problem.

You can try to provide NWP log which may have some indication (only if the problem is the device). see chapter 20 in https://www.ti.com/lit/swru455.

Hi,

NWP log I can provide you.

I have an doubt regarding the wireshark air sniffer.

My device is connected with the router and my laptop also connected with the same network where device is connected. So My laptop would able to capture the wireshark log of the device or It will capture only the laptop network log (means whatever request is coming to laptop).

it depends on the interface you are using for monitoring. You should use the wi-fi interface to sniff the over-the-air traffic (note that not all the on-board wi-fi devices supports the promiscuous interface required for an air sniffer so it may not work with wireshark. there are wi-fi dongles that can work with it).

Meanwhile, please provide the NWP log so we can check if it is helpful.

Hi,

Thank you for the information, I found some interesting thing and observed some bug about the ping.

Let me explain. As you can see my code which I posted as reference. I was using the @sl_Htonl(); function to converting the IP address to the network ordered IP address. were IP been resolved through the @sl_NetAppDnsGetHostByName API. It was work well since long time. So that means I was able to get the Ping response from the above code. 

But Recently it's failed due some reasons that still we are not able to identify so I made some code changes, Instead of the @sl_Htonl I used @SL_IPV4_VAL macro for the IP conversation to the Network Ordered. which is worked fine. I was able to get the response. the moment I Passed @SL_IPV4_VAL converted IP address I received response. I don't know how this got work  now ?

Here I did some R&D on these two function. well @sl_Htonl function return the IP based on the endian, If the architecture is little ending it will return the IP address in reserved ordered form (means 3 to 0). otherwise IP address would same as you passed(means 0 to 3 ordered). 

and @SL_IPV4_VAL  Marco is only arrange the index to the 3 to 0 form. 

So I don't know how this conversion started getting disturb without changes of any framework or device. how would I predict that @SL_IPV4_VAL  Marco will work. ?

Very strange.

sl_Htonl converts a 32b integer (unsigned int) from host to network order. (Network order is big endian - so if the host is big endian nothing will be done and if the host is little endian then the endianness will get reversed).

SL_IPV4_VAL just creates a 32b integer (host order) from 4 unsigned char (8b) values. If you operate it on an array ie. SL_IPV4_VAL(a[0], a[1], a[2]. a[3]) - the result will actually be the opposite of the htonl, i.e. if you look at the result in the memory - it  will be reversed-order in case of big-endianess host and keep the original order in case of little-endianess host. Anyway it was not meant for endianess conversion. 

I don't understand how htonl suddenly stopped working.

I recommend, you print the ip address as an array before and after the call to htonl and see if it get changed.

BTW. what is your host endianess?   

Hi,

Please find the IP address format in various method.

I add the comment which was working fine and which one is worked now. Please find the comment in the conversation function.

 uint32_t ipLocal = 0;

    WMLogInfo(GEN_LOG, "IP address by sl_NetAppDnsGetHostByName() = %08lx", hostIp);

    ipLocal = sl_Htonl(hostIp);       //failed by this conversation. It was worked before.
    WMLogInfo(GEN_LOG, "IP address by sl_Htonl() = %08lx", ipLocal);

    ipLocal = SL_IPV4_VAL(((uint8_t*)&hostIp)[0],
                           ((uint8_t*)&hostIp)[1],
                           ((uint8_t*)&hostIp)[2],
                           ((uint8_t*)&hostIp)[3]); //this conversation failed too

    WMLogInfo(GEN_LOG, "IP address by SL_IPV4_VAL() from 0 to 3 = %08lx", ipLocal);

    ipLocal = SL_IPV4_VAL(((uint8_t*)&hostIp)[3],
                           ((uint8_t*)&hostIp)[2],
                           ((uint8_t*)&hostIp)[1],
                           ((uint8_t*)&hostIp)[0]);  //this conversation working now.

    WMLogInfo(GEN_LOG, "IP address by SL_IPV4_VAL() from 3 to 0 = %08lx", ipLocal);

log for above code.

GEN:IP address by sl_NetAppDnsGetHostByName() = a63e1c52 ("extra edited " a63e1c52 = 166.62.28.82)

GEN:IP address by sl_Htonl() = 521c3ea6 ("extra edited" 521c3ea6 = 82.28.62.166)
GEN:IP address by SL_IPV4_VAL() from 0 to 3 = 521c3ea6 ("extra edited " 521c3ea6 = 82.28.62.166) 
GEN:IP address by SL_IPV4_VAL() from 3 to 0 = a63e1c52 ("extra edited " a63e1c52 = 166.62.28.82)

so you are having a little-endian cpu and the it seems that the result from sl_NetAppDnsGetHostByName is already in network order (big-endian) - so you don't need to call SL_IPV4_VAL (which was not meant for conversion anyway as i tried to explain before).

Are you saying that it was working with sl_Htonl before?

I don't think it was changed recently but i'll double check. Have you updated the service pack?

Yes, @sl_NetAppDnsGetHostByName  Already in network order.

No I did not update the anything in device side. Device is located in other place.

Yes I was using the @sl_Htonl everywhere, so far it was fine. recently only we fetch this issue.

Hi,

It could be possible that If @sl_NetAppDnsGetHostByName reporting as little-endian base Ip format so our device will work though the sl_Htonl() because it will change the IP format to the big-endian format. 

The sl_NetAppPing expects to see the the address in 32b host order, not in network order.

Same as the sl_NetAppDnsGetHostByName . 

So you don't need to do any conversion.

(in host order if you try to connect to 166.62.28.82 (which is equal to a6.3e.1c.52), then 32b value should be printed (%ld) as a63e1c52).

Okay Noted

So, what we can conclude here ?? I feel that it will failed again at some point.

it looks like you don't need to do any conversion between the sl_NetAppDnsGetHostByName and sl_NetAppPing.

It if will fail, i guess we will need to check in what cases the sl_NetAppDnsGetHostByName (or somehow your application) is returning the ip address unexpectedly in an opposite (network) order.

Hi,

How can make sl_NetAppDnsGetHostByName to failed and return the Ip Address opposite.??

Can we archive something like that if sl_Htonl failed to get response, The application should try to send the Ping request with Host order

sl_NetAppDnsGetHostByName shouldn't fail and i'm not familiar with a similar issue.

What i was saying was just based on your reports - i'm not sure what happened (how it worked before). I believe it was an issue in the application.

Okay

But if there is problem in API call I think at first call of API should be failed not like after long period.

The way of calling the API as I shown before Yes i would agree if the problem being reported as developing time but this is in production phase that means we test this functionality over 100s time.