Qt network being unreliable establishing a connection

[Thomas Strehl]

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.

[Paweł Stołowski (stolowski)]

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.

[Lorn Potter (lorn-potter)]

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

[Lorn Potter (lorn-potter)]

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)]

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

[Ubuntu Foundations Team Bug Bot (crichton)]

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.]

[Paweł Stołowski (stolowski)]

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)]

@Lorn any update?

[Timo Jyrinki (timo-jyrinki)]

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)]

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)]

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)]

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)]

defer to pick up fix in qt 5.4

[Timo Jyrinki (timo-jyrinki)]

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.