Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-8687

When sending http requests from phones to remote servers, we frequently get QNetworkReply::HostNotFoundError errors back whereas the network is fine

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • P1: Critical
    • 4.7.0, 4.7.1
    • 4.6.2
    • Network

    Description

      Description:
      ----------------
      When sending http requests to remote servers, we frequently get QNetworkReply::HostNotFoundError errors back.
      (This behavior is only noticed on phones, not in the emulator. Also, it occurs using both WiFi and 3G)

      In order to investigate, we added calls to QHostInfo::fromName("<our server domain>") when receiving the HostNotFoundError error.
      Of course, the QHostInfo::fromName method also returned a "Host not found" error message.
      We also added calls to QHostInfo::fromName on other servers (google & apple) and these calls also failed, but not as consistently as the ones to our server domain.

      We then added a native symbian resolution after the QHostInfo::fromName call using the following code:

      _LIT(KHostName, "<our server domain>");
      TNameEntry entry;
      TInt err;
      User::LeaveIfError(err = res.GetByName(KHostName, entry));

      qDebug() << QString("GetByName returned %1").arg(err);

      // Get the IP address of the host
      TInetAddr hostAddr = entry().iAddr;

      TBuf<50> ipAddr;
      TInetAddr::Cast(hostAddr).Output(ipAddr);

      qDebug() << QString("Symbian : hostAddr = %1").arg(hostAddr.Address());
      qDebug() << QString("Symbian : hostAddr family = %1").arg(hostAddr.Family());
      QString tmp = QString::fromUtf16(ipAddr.Ptr(), ipAddr.Length());
      qDebug() << QString("Symbian answer is %1 (%2)").arg(tmp).arg(ipAddr.Length());

      The native symbian call always returns the correct IP address for our server, even when QHostInfo::fromName fails with the "host not found" message.

      When the QHostInfo::fromName succeeds, the symbian native call succeeds too and gives back a KAfInet reponse.
      When the QHostInfo::fromName fails, the symbian native call succeeds but gives back a KAfInet6 response.
      Moreover, in both cases, the string returned by 'TInetAddr::Cast(hostAddr).Output(ipAddr)' is in the IPV4 format : '209.85.229.104'.
      The integer value returned by 'hostAddr.Address' is also the same in both cases.
      We don't understand this behavior.

      We also recompiled the QHostInfo sources in order to understand what was causing the QHostInfo::fromName method to fail.
      It appears the call to getaddrinfo returns EAI_FAIL when QHostInfo::fromName fails.

      Our understanding of the problem:
      ----------------------------------------------
      When QHostInfo::fromName succeeds, if we make a DNS resolution using RHostResolver, we get an answer with an address family of KAfInet.
      However, when QHostInfo::fromName fails, if we make a DNS resolution using RHostResolver, we get an answer with an address family of KAfInet6, but it contains an IPV4 address.
      Is it possible that the Qt domain name resolver can't handle KAfInet6 responses that contain an IPV4 address ? Anyway, there seem to be a problem in the communication between OpenC and QT on the network resolution.

      We tryied to match the bug with other issues in DB without any success:
      ------------------------------------------------------------------------------------------------

      http://bugreports.qt.nokia.com/browse/QTBUG-8182
      It's not the same bug :

      • Our URL is correct and available (I can access it at the same time from any other phone, including another Nokia phone running the same Application since this bug is not always there),
      • And the phone has network connectivity available (I can browse using the same access point at the same time).
        Which excludes this bug.

      http://bugreports.qt.nokia.com/browse/QTBUG-8335?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
      http://discussion.forum.nokia.com/forum/showthread.php?p=705972&highlight=resolver#post705972
      I don't believe that this bug report corresponds to the problem we are facing.

      • We experience the problem in both 3G and WLAN. Bug report states "WLAN works fine".
      • Our problem comes and goes over time, but there is no need to restart the device for it to start working again. Simply waiting a bit can make the DNS resolution work again. Also, not all domain names are affected at the same time.

      New info:
      Quick reminder of the initial issue :
      Main issue was the Symbian OS producing an invalid IP v6 address at network switch (3G to WiFi or WiFi to 3G).
      The system was using as default the invalid IP v6 address and thus was unable to perform any connexion afterward from any Qt application.
      Only solution was to reboot the phone.

      Current Status :
      We managed to reproduce nearly the same bug on the new firmware target for PR 1.1 on both N8 and C7.
      The only difference is that the bug now only applies in WiFi.
      3G connexions are working fine, but as soon as you get an invalid IP v6 address, you cannot use WiFi in Qt applications anymore.

      History :
      This bug has been notified to Nokia before N8 launch. Further investigation were done and the root cause of bad IPv6 address discovered.
      At that time, two solutions were found (one OpenC based, and one Qt based).
      The patch was delayed to first PR.

      Test phones information :
      Release : PR1.1
      Sw version : 013.016
      Sw version date : 2011-01-27
      Custom version : 013.016.203.04
      Custom version date : 2011-01-31
      Language set: 013.016.01.01
      Product code 059D5S6

      N8 :
      Release : PR1.1
      Sw version : 013.016
      Sw version date : 2011-01-27
      Custom version : 013.016.00.01
      Custom version date : 2011-01-27
      Language set: 013.016.06.01
      Product code 0598984

      Log extracts :

      Test application : failure exemple
      [Qt Message] "Resolving www.google.com"
      [Qt Message] "Qt results:"
      [Qt Message] " fromName returned: 0"
      [Qt Message] "Result is D155:E568:0:0:0:0:0:0"
      [Qt Message] "Result is D155:E593:0:0:0:0:0:0"
      [Qt Message] "Result is D155:E563:0:0:0:0:0:0"
      [Qt Message] "Result is 209.85.229.104"
      [Qt Message] "Result is 209.85.229.147"
      [Qt Message] "Result is 209.85.229.99"
      [Qt Message] "Symbian results:"
      [Qt Message] " GetByName returned: 0"
      [Qt Message] " hostAddr = 3512067432"
      [Qt Message] " hostAddr family = 2054"
      [Qt Message] " result is 209.85.229.104"
      [Qt Message] "Trying QSslSocket connectToHost"
      [Qt Message] "Error connecting socket: error number = 5, error string: Socket operation timed out"

      Test application : success exemple
      [Qt Message] "Resolving www.google.com"
      [Qt Message] "Qt results:"
      [Qt Message] " fromName returned: 0"
      [Qt Message] "Result is 209.85.229.147"
      [Qt Message] "Result is 209.85.229.99"
      [Qt Message] "Result is 209.85.229.104"
      [Qt Message] "Symbian results:"
      [Qt Message] " GetByName returned: 0"
      [Qt Message] " hostAddr = 3512067432"
      [Qt Message] " hostAddr family = 2054"
      [Qt Message] " result is 209.85.229.104"
      [Qt Message] "Trying QSslSocket connectToHost"
      [Qt Message] "Socket successfully connected"

      Attachments

        1. HostResolver_non-working.zip
          12 kB
        2. HostResolver_working.zip
          12 kB
        3. QTBUG-8687_workaround.zip
          6 kB
        4. QTBUG-8687.zip
          717 kB
        5. QTBUG-8687-new.zip
          3 kB

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              kallneva kalle nevala
              gregoire_gueret Gregoire Gueret
              Votes:
              6 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes