We recently tracked down an annoying issue with DNS reliability when we updated our firmware to wiced SDK v6.1.
Our firmware uses ThreadX and NetX and our hardware is an STM32F4xx and the 4343W module.
The issue originally presented as DNS working reliably at some of our labs and not working reliably or at all at other office sites.
Eventually we traced this to a bug that appears in DNS for v6.1 and is still there in the 6.2.x releases.
Specifically, with the 6.1 update, the endian order of dns server addresses extracted and saved from DHCP responses changed inside WICED/network/NetX/WICED/wiced_network.c::wiced_ip_up() from host order to network order. But the consumer of the DNS addresses inside libraries/protocols/DNS/dns.c::dns_client_hostname_lookup() did not change. So those addressesno longer matched the order expected from wiced_udp_send (used to query the DNS servers). So all queries to DNS servers specified by the DHCP payload were failing.
Why did DNS sort-of work at some sites? Because the bug was partially masked by wiced code that was arbitrarily adding a hard-coded 184.108.40.206 (the google public dns a server) to the list of DNS servers. BUT that fix only worked if the DHCP payload had not already filled the list. So if you connected to an AP that only supplied one DNS address, that DNS server would fail, but the hardcoded google address would work.
It's trivial to reproduce this failure for any wiced 6.1 or 6.2 that uses DNS (including their example apps and snips) by simply commenting out that 220.127.116.11 hardcode inside WICED/network/NetX/WICED/wiced_network.c::wiced_ip_up(). Here are those lines.
/* Add Google DNS server (18.104.22.168) */
memset( dns_ip_string, 8, 4 );
SET_IPV4_ADDRESS( address, nx_dhcp_user_option_convert( dns_ip_string ) );
dns_client_add_server_address( address );
@Cypress can someone please confirm and add this to your bug tracking for the next release?