NSAPI DNS queries failing for some websites

[sarahmarshy]

Description

• Type: Bug
• Related issue: Fails to connect with K64F and ESP8266 mbed-os-example-client#205
• Priority: Major

---

Bug

Target
K64F

Toolchain:
GCC_ARM|ARM|IAR

meed-os sha:
88a4baa Merge pull request #3902 from mazimkhan/master

Steps to reproduce
Run this simple program:

#include "mbed.h"
#include "TCPSocket.h"
#include "ESP8266Interface.h"

ESP8266Interface wifi(MBED_CONF_APP_WIFI_TX, MBED_CONF_APP_WIFI_RX);

int main()
{
    printf("WiFi example\r\n\r\n");

    printf("\r\nConnecting...\r\n");
    int ret = wifi.connect(MBED_CONF_APP_WIFI_SSID, MBED_CONF_APP_WIFI_PASSWORD, NSAPI_SECURITY_WPA_WPA2);
    if (ret != 0) {
        printf("\r\nConnection error\r\n");
        return -1;
    }

    printf("Success\r\n\r\n");

    TCPSocket socket;

    socket.open(&wifi);
    ret = socket.connect("www.arm.com", 80);
    printf("%d\r\n", ret);

    wifi.disconnect();

    printf("\r\nDone\r\n");
}

Get this output:

WiFi example


Connecting...
Success

-3009

Done

-3009 indicates connection to address failed. Looking deeper, it fails at the DNS resolution step.

However, if you try to connect to google.com, you get this output:

WiFi example


Connecting...
Success

0

Done

This seems to also be affecting mbed-client behavior - ARMmbed/mbed-os-example-client#205.

[sarahmarshy]

arm.com on Dig - https://toolbox.googleapps.com/apps/dig/#A/www.arm.com
Appears to have a CNAME

google.com on Dig - https://toolbox.googleapps.com/apps/dig/#A/www.google.com
No CNAME

github.com also does not work, and it also appears to have a CNAME - https://toolbox.googleapps.com/apps/dig/#A/www.github.com

Not sure if related

[0xc0170]

cc @geky

[kegilbert]

Poking around a bit the issue is coming from https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/nsapi_dns.cpp#L131

Rcode from the flags segment of the DNS response packet is 0x01, which is a DNS format error. Saw the same response when testing with the sniffer network on wireshark (although I actually did not see this error initially when using it, only on the IoT lab WIFI). Got the same error code though in this issue after testing the following day.

After I started getting the error code on both networks I tested using my phone's mobile hotspot and it worked again (no error codes when running with both 'www.arm.com' and 'arm.com'). I haven't looked further into the DNS protocol aspect yet but could be related which network you're testing on.

[geky]

After more investigation it looks like this was just a result of sending a full packet (instead of sized based on the query size) and some DNS servers using the packet size instead of the count encoded in the packet.

@kjbracey-arm as a pr up that should fix this: #4274

@sarahmarshy If you get a chance, can you confirm #4274 fixes this issue with your setup?

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-365