CC3200: unreliable discoverability via mDNS

Hey Carsten,

I've assigned this to one of our SW experts to support. Please allow a few days for response due to the weekend.

Hi,

What power policy are you using?

If you are using SL_NORMAL_POLICY, can you try SL_ALWAYS_ON_POLICY and test if the statistics improve?

Regards,

Shlomi

Thank you for the suggestion. We have added more devices for testing with the suggested policy modification (device 5-9).

Unfortunately, this does not seem to have influenced the statistics. Are there any other idea we can try?

----------------------------------------------
Benchmark MDNS
Scan 25 times in 26s
----------------------------------------------
device 2         48% (SL_NORMAL_POLICY)
device 3         48% (SL_NORMAL_POLICY)
device 4         48% (SL_NORMAL_POLICY)
device 5         52% (SL_ALWAYS_ON_POLICY)
device 6         52% (SL_ALWAYS_ON_POLICY)
device 7         48% (SL_ALWAYS_ON_POLICY)
device 8         48% (SL_ALWAYS_ON_POLICY)
device 9         44% (SL_ALWAYS_ON_POLICY)
mysimplelink  52% (SL_NORMAL_POLICY, mdns example)
rpi                   96%
----------------------------------------------

Hi,

Just wanted to make sure we are not missing any packets due to Wi-Fi going to sleep.

Can you elaborate what is the mDNS discovery procedure you are applying? e.g. does the device only transmits mDNS multicast frames and the mobile app should pick it? or are the devices also need to receive something (e.g. to "close the loop")?

Also, do you have an air sniffer that can shed more light?

what servicepack version are you using?

Shlomi

Our devices are all connected to the same access point, and so is the end device with the app. The app sends a normal multicast query and waits for the responses of the devices with the CC3200 to then successively connect to them. Due to the partial lack of response from individual devices, not all devices are reached in this way.

Sending several requests and collecting the answers makes it better in principle, but from our point of view this would be only a stopgap solution and it would be nicer to achieve reliable answers in the first place.

and the nature of these response from CC3200 devices is a multicast? what I am trying to understand is how the mechanism of finding these devices work, all multicast, unicast, other?

if you discover the devices, are you able to connect OK?

a detailed description of the procedure is highly appreciated.

I asked my colleague who did the experiments for details on how he did it, do the attached pictures help with this?

The CC3200s found in each case can be connected to the app without any problems.

Addendum to the service pack: some have an older service pack, but some are also up to date (to be able to compare the influence), just like the original LaunchXL (CC3100_CC3200_ServicePack_1.0.1.15-2.15.0.1).

Thanks for sharing.

So from my understanding, both requests and responses are over mDNS.

The question now is whether CC3200 experiences issues in receiving these messages or sending the responses.

The experiment with ALWAYS_ON power policy should improve the RX side (which obviously we didn't see much of improvement). On TX side, there are no actual "time slots" where it is supposed to transmit and whenever there is a packets to transmit, it should be good.

The only way to have a deeper look into it is by having an air sniffer (the one here seems like an ethernet capture). Do you have this capability?

Also, maybe we can make some benefit from NWP log capture. The procedure is described in some of the past posts like this one https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1063445/cc3200-enterprise-network-connection-issue/3935222#3935222

Regards,

Shlomi

Also if it is possible to get a code snippet of the procedure, that is best.

Just wanted to understand if you are using mDNS as advertiser, discovery or both.

Are you suing the sl_NetAppDnsGetHostByService()/sl_NetAppGetServiceList(), sl_NetAppMDNSRegisterService(), both?

Shlomi

We only use the discovery with sl_NetAppMDNSRegisterService(), here's the corresponding function:

long ConfigureMDNS (signed char *service_name, signed char *service_description, int port, char enable)
{
   long iretvalmDNS;
   //Registering for the mDNS service.
    char dev_domain[65]="xyz.";


    memcpy(&dev_domain[strlen("xyz.")],(const char*)service_name,strlen((const char*)service_name));

    iretvalmDNS = sl_NetAppMDNSUnRegisterService((const _i8*)dev_domain,\
                    (unsigned char)strlen((const char*)dev_domain));
    if (enable)
    {
      iretvalmDNS = sl_NetAppMDNSRegisterService((const _i8*)dev_domain,\
                    (unsigned char)strlen(dev_domain),\
                    service_description,\
                    (unsigned char)strlen((const char*)service_description),
                    gl_DeviceInfo.service_port, 2000, 1); // SERVICE_PORT,2000,1);
    }

    return iretvalmDNS;
}

Initially, we simply used a service browser app to display the devices found in the network.
When the devices respond, they usually do so very quickly (<300 ms), but in other cases they are not displayed even after a long wait.

I will have a look at the NWP log capture functionality, I've already noticed that we used that pin in our hardware design for other purposes.

Since the behavior of the Launchpad is similar to our devices, I have tested the network logging on this device first, attached the resulting log file, is this the correct format?

3000.capture.zip

Hi,

yes, this is OK. However, not much can be seen in regards to mDNS and why it fails.

To summarize, seems like at some point the mDNS frames are not seen by the probing device. Can you tell for how long you are collecting the statistics?

What I am trying to understand is whether the CC3200 device simply stops advertising as it supposed and thus you are not seeing it anymore.

In short, can you add the following GET command to fetch the mDNS advertising parameters and report the output?

{
    SlNetAppServiceAdvertiseTimingParameters_t mdnsStruct;
	_u8 optionLen = sizeof(mdnsStruct);
	
	sl_NetAppGet(SL_NETAPP_MDNS_ID, SL_NETAPP_MDNS_TIMING_PARAMS_OPT, &optionLen, (_u8 *)&mdnsStruct);
	
	UART_PRINT("MDNS parameters: t %d, p %d, k %d, RetransInterval %d, Maxinterval %d, max_time %d\n\r", mdnsStruct.t, mdnsStruct.p, mdnsStruct.k, mdnsStruct.RetransInterval, mdnsStruct.Maxinterval, mdnsStruct.max_time);
}

Shlomi

Do I need to make additional changes elsewhere? Is simply running the code enough or should the part be repeated regularly?

I just tested on an old version and since then some definitions were changed.

You can see it all under the netapp.h header file.

• use SL_NET_APP_MDNS_ID insead of SL_NETAPP_MDNS_ID
• use NETAPP_SET_GET_MDNS_TIMING_PARAMS_OPT instead of SL_NETAPP_MDNS_TIMING_PARAMS_OPT
• Not sure why it fails on the last two. The API is:
  • _i32 sl_NetAppGet(const _u8 AppId,const  _u8 Option,_u8 *pOptionLen, _u8 *pOptionValue);

can you double check that you have this API @netapp.h?

Shlomi

That helped, here ist the struct content from the debugger:

Thank you for this sufggestion! We've tried the modified parameters and it has become worse rather than better. The service "_uart._tcp.local" registered by us is found worse, the also existing service "_http._tcp.local" of the CC3200 seems to be found better in direct comparison. Does this have separate parameters and where is it configured?

No, these parameters apply to both, built-in and new services just the same.

Are you seeing major differences?

do you have a wireless sniffer in which we can actually see the mDNS frames?

We ran the statistics program again, the services with "_http._tcp.local" are reproducibly found better than those with "_uart._tcp.local" for the same devices. Also a simple Android app to list the services (e.g. Service Browser) comes to the same conclusion. Is there an explanation for different behavior of the two services?

Does the parameter "RetransInterval", if selected >0, cause the advertising process to be executed several times in the interval (unit seconds?)?

Hi,

Actually, both the internal one and the user registered one should appear on the same mDNS advertisement so it is not clear why you see different statistics.

Regarding the "RetransInterval", it denotes the number of ticks to wait before sending out repeated announcement message (which in the new case is 3).

Shlomi

By assigning unique service names xyz1._uart._tcp.local to the devices, we managed to find the uart services comparably well as the original http services. However, this did not fix the original problem, so we have adjusted our search strategy. We now search for a shorter time, but several times in a row each time after a waiting period and aggregate the found devices. This way, after a few runs, all devices are found quite reliably. However, if there are further suggestions to change the cause, we will be happy to try that. Anyway, thanks for the support already.