Qt network being unreliable establishing a connection

Bug #1413269 reported by Thomas Strehl on 2015-01-21
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Unassigned
qtbase-opensource-src (Ubuntu)
Undecided
Unassigned
qtbase-opensource-src (Ubuntu RTM)
Undecided
Unassigned

Bug Description

Qt network manager is unreliable as it sometimes reports the device being not online when in fact it is. This manifest in bugs like bug #1409995 or some scopes querying online resources just being empty.

Thomas Strehl (strehl-t) on 2015-01-21
description: updated
description: updated
description: updated
Paweł Stołowski (stolowski) wrote :

Bug #1409995 affected our smartscopesproxy service, which starts with user session (keeps running in the background) and handles network requests by creating QNetworkAccessManager instance with every new request. So, in theory, since QNAM was re-created for every request, it should not be affected by temporary network issue and should recover with another request, assuming network becomes available. What we observed however was a permanent failure: if the problem occurred after reboot, no network requests were passing through anymore. QNetworkAccessManager / QNetworkReply signals wouldn't report any progress or error and were just stuck.

While reproducing that bug (which wasn't hard - it would happen every 2-3 reboots of the phone) I found out that it couldn't be reproduced if I just killed smartscopesproxy process and let upstart respawn it - I tried killing it around 20 times in a row, and every time it was serving network request correctly. That suggests the problem may have something to do with startup sequence.

Changed in canonical-devices-system-image:
milestone: none → ww05-2015
status: New → Confirmed
Lorn Potter (lorn-potter) wrote :

Could you try to restart NetworkManager? Does that have the same effect as restarting smartscopeproxy?

Lorn Potter (lorn-potter) wrote :

Briefly looked into this, and something odd is going on in the networkmanager QtBearer backend.

The wifi connection is first reported in the Defined state, and then gets Undefined for some reason when it should be updated to Active state.
Need to dig further.

Lorn Potter (lorn-potter) wrote :

Patch attached that fixes wonky configuration state and also fixes isOnline for me.
I will test and upstream this more tomorrow.

The attachment "fix-ubuntu-bearer.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Paweł Stołowski (stolowski) wrote :

Hi Lorn, re your question from comment #2 (sorry it took so long, I had to revert to some older phone image to verify that): restarting network manager service doesn't help. Also, when the problem happens, other apps (such as browser) work fine, so it's rather an issue with the state of Qt network stack of particular app instance.

Pat McGowan (pat-mcgowan) wrote :

@Lorn any update?

Changed in canonical-devices-system-image:
status: Confirmed → In Progress
milestone: ww05-2015 → ww07-2015
importance: Undecided → High
JACQUELINE (ijdisabest) on 2015-01-30
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Changed in canonical-devices-system-image:
status: Fix Committed → Confirmed
Timo Jyrinki (timo-jyrinki) wrote :

Whatever the cause, please test the builds on vivid:

ppa:ci-train-ppa-service/landing-001
( 5.3.2+dfsg-4ubuntu10 )

and rtm:

ppa:ci-train-ppa-service/landing-006
( 5.3.0+dfsg-2ubuntu11~rtm )

to see if Lorn's patch fixes the issue or not. The patch needed small rebasing to apply cleanly.

Paweł Stołowski (stolowski) wrote :

Unfortunately the patched version of Qt from landing-001 didn't help with our issue with smartscopesproxy (I've tested on an older image #73 on mako; it's important to test on an old image because we've recently switched to netcpp in smartscopesproxy to avoid these networking issues).

Timo Jyrinki (timo-jyrinki) wrote :

If it's something that is not NM backend specific but Qt networking in general, it would be an useful data point if Qt 5.4.0 works similarly or not, see https://wiki.ubuntu.com/Touch/QtTesting. If it would work better, we'd know there's something between 5.3 and 5.4 fixing the issue, in qtbase.

Paweł Stołowski (stolowski) wrote :

I re-tested with Qt 5.4.0 (from the ppa) and a custom build of unity-scopes-api (with switch-to-netcpp branch reverted) and I couldn't reproduce the networking issues of smartscopesproxy anymore. It looks like Qt 5.4.0 did fix that particular instance of the qt networking issue for us.

I cannot comment on the other issue that Thomas mentioned in this bug report - there is no clear scenario for reproducing seldom failures where shell plugin thinks that network is not available (because it's told so be Qt's network access manager) and passes network=false flag down to scopes with search.

Pat McGowan (pat-mcgowan) wrote :

defer to pick up fix in qt 5.4

Changed in canonical-devices-system-image:
milestone: ww07-2015 → ww11-2015
Timo Jyrinki (timo-jyrinki) wrote :

Marking as Fix Released as Qt 5.4.0 is now in vivid. rtm will get it when a vivid snapshot is made into new rtm.

Changed in qtbase-opensource-src (Ubuntu):
status: New → Fix Released
Changed in canonical-devices-system-image:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers