QNetworkAccessManager doesn't support roaming on Ubuntu

[Victor Tuson Palau]

scope images load fine in wifi, but not on hsdpa even when there is good connectivity and browsing works well. Results are return, but images do not load.

[Michael Zanetti (mzanetti)]

Confirming too.

Some observation: I noticed that when switching from WiFi to 3G, running apps fail to do any network traffic too until they are restarted.

Makes me believe this is an issue in QNetworkAccessManager's backend/platform integration code.

[Alexander Sack (asac)]

I had that on #2 krillin rtm proposed channel; also it felt it took almost a day on wifi to really recover from whatever state it cached during 3g usage. e.g. after 3g the wifi didnt cure it right away...

[Alexander Sack (asac)]

marked it critical because it was a very bad scope experience for me on first use after flashing since i was never on wifi...

[Michael Zanetti (mzanetti)]

Confirming that QNetworkAccessManager doesn't realize when the network connection comes up (or changes).

If a QNetworkAccessManager is constructed while the network is down, all get() calls will continue failing even when the network comes up.

Only QNetworkAccessManagers created while the network is working, will be functional.

[Antti Kaijanmäki (kaijanmaki)]

if the scopes are confined then we need to change the QPA plugin to use connectivity-service instead of NM to get the networking status changes.

[kevin gunn (kgunn72)]

probably like
connectivity-service <- platform-api <- qtubutntu

[Robin Burchell (viroteck)]

Sounds like a problem in the QtNetwork bearer plugin you're using. I'd guess that would be networkmanager (qtbase/src/plugins/bearer/networkmanager/), but I'm not sure if that's correct.

P.S. (re comment #6): Bearer plugins, while platform specific, are not related to QPA. QPA is strictly for graphical abstraction, as the network backend is not tied to the display system used (for instance, Sailfish uses ConnMan, even though many desktop Linuxes use NM).

[Michael Zanetti (mzanetti)]

>if the scopes are confined then we need to change the QPA plugin to use
> connectivity-service instead of NM to get the networking status changes.

Well, this doesn't only affect scopes. It also affects apps.

[Mathieu Trudel-Lapierre (cyphermox)]

Looks to me like QNetworkAccessManager doesn't support roaming, either because it was built without it being enabled or it's disabled because it's not detected as being supported; but I can see QNetworkConfigurationManager doesn't report roaming to be supported as per the QNetworkAccessManager documentation, and that seems to be why it fails to notice the connection states changed.

One way to counter this would be to make sure there is proper error checking when trying to retrieve data; it appears to me as it should be reasonably easy to notice, from the error returned and the fact that HTTP headers are empty, for example, that a request has failed.

The other option is to make it so that roaming is properly supported, and that may improve the behavior of QNetworkAccessManager.

I've written a small test program that shows the issue; see lp:~mathieu-tl/+junk/networktest.

[kevin gunn (kgunn72)]

@chicken - hope you don't mind me putting back to you, networking not exactly in our wheelhouse.

[kevin gunn (kgunn72)]

changing tag to 10/9, altho from the write above sounds like a longer term proposition

[Antti Kaijanmäki (kaijanmaki)]

Just ping me if you need anything added to the connectivity-service.
The security team has made it clear that they don't want to allow broad access to the NM D-Bus API for confined apps. So, the way we do this is by relaying any necessary information through the properly confined connectivity-service.

[Mathieu Trudel-Lapierre (cyphermox)]

I haven't been able to build qtbase with some extra debugging just yet, it fails to build (segfaults) in sbuild and/or in a PPA; I'm still waiting for the results of building on my phone. From there, I'll be able to move forward to figure out why QNetworkAccessManager doesn't seem to be using the NetworkManager bearer for network status.

[Lorn Potter (lorn-potter)]

Is the generic bearer plugin also being installed? What happens when that is removed?

[Lorn Potter (lorn-potter)]

I forgot to mention I noticed this weekend the NetworkManager plugin is not exactly working well. There is a MR fixing this
https://codereview.qt-project.org/#/c/96332/

[Lorn Potter (lorn-potter)]

Looked into the code, it appears that when they were porting the NM backend to qt5, they never hooked up anything to the StateChanged signal. ;/ (I originally wrote the NM backend, but was not on the team that ported it.)

[Mathieu Trudel-Lapierre (cyphermox)]

Great, thanks for looking into it. I'm not very familiar with Qt code, so I didn't get that far yet.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mathieu Trudel-Lapierre (cyphermox)]

Lorn, if you're working on this, could you please assign the bug to yourself for the qtbase-opensource-src task?

[Mathieu Trudel-Lapierre (cyphermox)]

Not sure if I reassigned this properly, but qtubuntu/platform-api probably should use connectivity-api if that's possible, to know whether they are online or not. Any other information might need to be added to the connectivity api.

[Lorn Potter (lorn-potter)]

I have no way to test this currently, but this change may also help.
The NM backend was missing some mobile connection functionality.

https://codereview.qt-project.org/#/c/96501/

[Lorn Potter (lorn-potter)]

So there are two things that effect this bug.

1) NetworkManager backend is not working with current NetworkManager on any platform.

    The previously mentioned patches fix this. Mostly API changes in NetworkManager from when I last worked on this bearer plugin.

2) Having the generic backend plugin installed alongside other bearer plugins breaks the proper functionality of the networkmanager backend.

    Not quite sure the proper way to deal with this, either by packaging the plugins separately, and only installing the networkmanager one, or by only building the networkmanager plugin. My feeling is to only build what is needed. But this would be tricky to upstream, as the Qt CI autotests probably rely on the generic plugin basic functionality.

The generic plugin knows nothing about ofono and works only on kernel network device nodes, and since I currently do not have a device to test this on, cannot say for sure if the cellular network even is available to QtBearer using generic plugin.

[Timo Jyrinki (timo-jyrinki)]

Hey, I noticed this bug on my bug filtering. Test build for the quoted patch pushed to:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-022/+packages - armhf build will take around 3h.

apt line on device: deb http://ppa.launchpad.net/ci-train-ppa-service/landing-022/ubuntu-rtm 14.09 main

[Timo Jyrinki (timo-jyrinki)]

It has built, I'm not sure how useful it is without a fix for 2). Maybe one could additionally remove /usr/lib/*/qt5/plugins/bearer/libqgenericbearer.so for testing?

For 2), we should generally not deviate from upstream as a rule and also because Ubuntu has other Qt 5 users like KDE. So we need to ship ~everything in any case, possibly just not installing it all.

The preferred way would be any upstream acceptable way for eg. runtime disabling of the generic backend (or the effect it causes).

The second possibility, if that testing method above removing the file is enough, would be to deviate from Debian and split the libqt5network5 package into four packages. Make it not require the generic plugin to be installed (Recommends: libqt5network5-plugin-generic/nm/connman from libqt5network5), and take care the generic plugin would not be included on the touch images.

[Lorn Potter (lorn-potter)]

Just pushed another revision to the first upstream change review. This fixes the plugin on a desktop using ethernet and/or wifi connections.

As for #2. I can make QtNetwork ignore the generic plugin when others are present and usable. It is a one line fix.
See https://bugreports.qt-project.org/browse/QTBUG-41866

[Timo Jyrinki (timo-jyrinki)]

PPA has now finished building updated 5.3.0+dfsg-2ubuntu10~utopic1~test2 package, please test!

It includes both updated Add-better-mobile-connections-to-QtBearer-NetworkMan.patch and one-liner patch as copy-pasted from QTBUG-41866.

[Lorn Potter (lorn-potter)]

Also needed is the update to the networkmanager API version patch.
https://codereview.qt-project.org/#/c/96332/

That patch is now targeted for 5.4, but it is needed for the networkmanager bearer plugin to work.

[Timo Jyrinki (timo-jyrinki)]

Added that one too. I needed to rebase it for 5.3.0, but it didn't seem too scary.

So, ~test3 pushed to the PPA. Let's see how the unit tests go (they are executed as part of the build) as upstream MP has some issue.

[Omer Akram (om26er)]

@Timo, did that change in the ppa fix the issue ?

[Timo Jyrinki (timo-jyrinki)]

@Omer: At the moment I'd need someone to test the PPA. I may be able to test it later today myself, but not next week where I don't have a HSDPA that I could reasonably use.

[Lorn Potter (lorn-potter)]

I now have a mako to test on.

As far as I can tell, those patches did not fix this. At leastnow the bearer backend is mostly working.

Tested with the soundcloud scope tutorial app :) and one I made testing QNAM/QNetworkConfiguration and friends.

I think the problem is the bearer backend does not find any usable configurations when connected to mobile data.

Will do more work on the bearer backend...

[Lorn Potter (lorn-potter)]

Forgot to mention, all these patches will go into upstream 5.4, but will also cleanly apply to 5.3

[Lorn Potter (lorn-potter)]

This patch https://codereview.qt-project.org/#/c/98115/
and bug bugreports.qt-project.org/browse/QTBUG-40234

will probably effect/fix this bug as well as those other previous fixes.

[Lorn Potter (lorn-potter)]

Unfortunately, QtBearer cannot be totally asynchronous, as QNAM is a synchronous API.

It does need optimization in regards to amount of blocking calls it does.

[Timo Jyrinki (timo-jyrinki)]

I've just pushed updated build ~test4, refreshing/rebasing from the 5.4 patches and adding Reset-QNAM-s-NetworkConfiguration-when-state-changes.patch. The patches included currently are:

disable-generic-plugin-when-others-available.patch
Add-better-mobile-connections-to-QtBearer-NetworkMan.patch
update-QtBearer-NetworkManager-backend-API.patch
Reset-QNAM-s-NetworkConfiguration-when-state-changes.patch

Please tell if eg any of the following not yet mentioned here would be needed to be added too (from codereview):

Fix bogus error report when disconnect/stop actually works
Do not add invalid configurations to bearermonitor
QtBearer corewlan add list of remembered networks

...although I understand there's still work to be done.

[Lorn Potter (lorn-potter)]

Here'a yet another one. Hopefully only small bug fixes are needed after this.
https://codereview.qt-project.org/#/c/98547/

This one makes mobile data detection really works and uses property cache instead of making blocking calls for every property call.

The 3 other reviews do not need to be included, two of them only effect mac os x, and the other is for the example app.

[Timo Jyrinki (timo-jyrinki)]

The last patch is big and seems to fail quite largely on top of 5.3.0 + the other patches. I haven't tried to look it hard yet to see how much work the rebasing would be, but if in the end we will want that patch to fix this bug, rebasing needs to be done for it too.

If interested, I've pushed a branch to https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src_530_networkmanagerfixes now. The first four patches have been rebased to apply, this last one fails as can be tried locally with:

apt install bzr-builddeb
apt-get build-dep qtbase-opensource-src
wget https://launchpad.net/ubuntu/+archive/primary/+files/qtbase-opensource-src_5.3.0%2Bdfsg.orig.tar.xz
bzr branch lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src_530_networkmanagerfixes
cd qtbase-opensource-src_530_networkmanagerfixes
bzr bd

Which produces the attached failure to apply.

[Timo Jyrinki (timo-jyrinki)]

I succeeded in rebasing the patch for 5.3.0, although with some level of uncertainty when doing that for example with QNetworkManagerEngine::deviceConnectionsChanged not existing in 5.3.0. It applies now and seems to build also successfully, although as of now the armhf build is still ongoing (at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-022).

When armhf has finished, it'd be worth testing. lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src_530_networkmanagerfixes is updated with the rebase.

[Timo Jyrinki (timo-jyrinki)]

To replicate my rebasing environment see http://pastebin.ubuntu.com/8819119/. I originally did quilt push -f on the last patch and then manually fixed the codebase until I had gone through all the rejected parts.

[Lorn Potter (lorn-potter)]

@kgunn72 I think we certainly have moved on to a different bug. Originally, QNAM was not considering mobile data connection at all, because the QtBearer was only using generic plug (which does not know the difference between mobile data and other network interfaces and is not really usable anyway). The NetworkManager backend was also not working as it should.

@mathieu-tl I just noticed in comment #10, you mention roaming (as does the bug subject). Roaming in QConfiguration means 'connection migration' where connections are migrated seamlessly to and from wlan/mobile (kind of like what mobile does moving from tower to tower), i.e. a streaming media would continue uninterrupted moving from wlan to mobile data. I believe it has been supported only on Symbian which did the connection migrations at the platform level .

QNAM should now at least switch the configuration it uses when the default route changes to one that is usable, which is about the closest we can get to connection 'roaming' at this point. Previously a client would have to tear down and create a new QNAM. Now, a QNAM get request should succeed regardless when the QNAM was made.

[Lorn Potter (lorn-potter)]

syslog with networkmanager debug.
Starts with being connected. double spaced when it reached disconnection, and ends with reconnection.

[Lorn Potter (lorn-potter)]

As for the original comment. If I delete the cache and reboot, icons/images do not show up like normal if I start up with 3g connection.

Looking at the syslog, I noticed the disconnection always starts with the line:

NetworkManager[1439]: <debug> [1415764765.680476] [nm-modem.c:533] nm_modem_check_connection_compatible(): in nm_modem_check_connection_compatible

[Lorn Potter (lorn-potter)]

weird. I just downloaded/installed the package again, and I can no longer see that disconnect/reconnect loop.

[Timo Jyrinki (timo-jyrinki)]

@Lorn: Did you have wifi turned on with a known network when you booted?

I've seen the same that Pat saw: if you boot with wifi on, then turn wifi off, 3G stays on and doesn't have the reconnect cycle. However, if you boot so that wifi was disabled before starting the reboot, the 3G keeps reconnecting even if you enable wifi, disable it again etc.

It becomes even more complicated (at least for me) if you try forgetting the known wifi networks (via wifi settings). My idea was to start with wifi powered on but no known network, to test how's the 3G in that case. I thought it was my mako or SIM card acting up earlier, but I've now noticed the pattern that I lose the SIM PIN dialog if I forget the old wifi networks, which means I can't test this case since I don't get GSM functionality. Does it work on krillin, forget the wifi networks and reboot?

Yesterday I asked Antti (Wellark) to try to decipher what's happening, but I didn't hear from him yet whether he got results. He was working on dbus listening / log parsing to try to find out what's calling the reconnects.

[Lorn Potter (lorn-potter)]

Well, I did delete the contents of ~/.cache and reboot. But now I do not have the apps grid.

[Timo Jyrinki (timo-jyrinki)]

.cache/unity8-dash should be enough to remove, after which one can go to Video scope and pull down to refresh to test whether download works.

My mako PIN dialog problem is bug #1376250 (happens on mako only) and can be workarounded via system settings -> security. The wifi being simply powered on is not the key - if not connected to a wifi network, 3G keeps reconnecting. The only way for a stable 3G connection with the PPA is to have wifi connecting to a network on boot, after which the wifi can be disabled to use 3G only with the original bug fixed.

Driver being the problem was suggested, but since this happens on both mako and krillin it's not likely.

[Lorn Potter (lorn-potter)]

According to dbus-monitor, the mode interface keeps failing:

signal sender=:1.8 -> dest=(null destination) serial=1635 path=/org/freedesktop/NetworkManager/Devices/1; interface=org.freedesktop.NetworkManager.Device; member=StateChanged
   uint32 120
   uint32 40
   uint32 0
signal sender=:1.8 -> dest=(null destination) serial=1636 path=/org/freedesktop/NetworkManager/Devices/1; interface=org.freedesktop.NetworkManager.Device.Modem; member=PropertiesChanged
   array [
      dict entry(
         string "State"
         variant uint32 120
      )
      dict entry(
         string "StateReason"
         variant struct {
               uint32 120
               uint32 0
            }
      )
   ]

[Lorn Potter (lorn-potter)]

modem interface...

Is there anyway to edit comments?

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

I have monitored calls to ofono DBus connection manager interfaces following comment #7 in

https://bugs.launchpad.net/ubuntu/+source/telepathy-ofono/+bug/1226739

The command was:

# dbus-monitor --system "interface=org.ofono.ConnectionManager" "interface=org.ofono.ConnectionContext"

I have attached the output. What I see is that a process with unique name ":1.8" is activating/deactivating periodically the cellular data context.

# dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID string:":1.8"

showed the PID of NetworkManager.

The output of /usr/share/ofono/scripts/monitor-ofono is:

...
{ConnectionContext} [/ril_0/context1] Settings = {}
{ConnectionContext} [/ril_0/context1] Active = False
{ConnectionContext} [/ril_0/context1] Settings = { Interface = ccmni0, Gateway = 10.79.188.18, DomainNameServers = 212.166.210.82 212.73.32.67, Netmask = 255.255.255.0, Method = static, Address = 10.79.188.18 }
{ConnectionContext} [/ril_0/context1] Active = True
{ConnectionContext} [/ril_0/context1] Settings = {}
{ConnectionContext} [/ril_0/context1] Active = False
{ConnectionContext} [/ril_0/context1] Settings = { Interface = ccmni0, Gateway = 10.143.31.135, DomainNameServers = 212.166.210.82 212.73.32.67, Netmask = 255.255.255.0, Method = static, Address = 10.143.31.135 }
...

ofono is just told to activate/deactivate the context, no spurious disconnections happen.

HTH

[Lorn Potter (lorn-potter)]

When I use dbus-monitor on NetworkManager, I get this:

signal sender=:1.8 -> dest=(null destination) serial=2845 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChanged
   uint32 20
signal sender=:1.8 -> dest=(null destination) serial=2852 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChanged
   uint32 40

state 20 is NM_DEVICE_STATE_UNAVAILABLE (The device cannot be used (carrier off, rfkill, etc)

and 40 is "prepare", which is autoconnect starting to reconnect.

[Lorn Potter (lorn-potter)]

Ok, I think I see the light now. This is an odd one.

There seems to be two connection settings (within networkmanager) for the same connection context (even in mako), one being the nm settings configuration that is actually connected (settings/2), and the other that is not flagged as active (settings/0) (both with different UUID). It is this non-active configuration that SmartScopes is holding on to and trying to connect to, which then causes nm to disconnect the other configuration.

I can work around this by faking that the Settings/0 is flagged as Active in QtBearer when there is a connection context somewhere with the same context id that is actually active.

[Lorn Potter (lorn-potter)]

This fixes that last reconnection issue. There might be a better way, but with this, the connection is stable again.

https://codereview.qt-project.org/#/c/99818/

But the question remains why NetworkManager has more than one configuration for a context....

[Timo Jyrinki (timo-jyrinki)]

Sounds good!

For some reason, with that patch an unrelated unit test starts failing on both i386 and amd64 (armhf still building):
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-022/+sourcepub/4570340/+listing-archive-extra

"QFATAL : tst_QXmlStream::crashInUTF16Codec() Received signal 11
FAIL! : tst_QXmlStream::crashInUTF16Codec() Received a fatal error."

The delta between the previous build and this is:
https://launchpadlibrarian.net/190339928/qtbase-opensource-src_5.3.0%2Bdfsg-2ubuntu10~utopic1~test8_5.3.0%2Bdfsg-2ubuntu10~utopic1~test9.diff.gz

It's especially weird since the rtm-14.09 should not have much any other changes to cause such thing.

I'll try a few more builds to try to understand where the problem is coming from, even though it will be slow.

[Timo Jyrinki (timo-jyrinki)]

So a few builds later:

Without the patch, success:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-022/+build/6569022/+files/buildlog_ubuntu-rtm-14.09-amd64.qtbase-opensource-src_5.3.0%2Bdfsg-2ubuntu10%7Eutopic1%7Etest10_UPLOADING.txt.gz

With the patch again, fail:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-022/+build/6569183/+files/buildlog_ubuntu-rtm-14.09-amd64.qtbase-opensource-src_5.3.0%2Bdfsg-2ubuntu10%7Eutopic1%7Etest11_FAILEDTOBUILD.txt.gz

Any ideas what could cause the unit test to reliably fail with the patch added, given that the patch only touches bearer code and the failure is in tst_QXmlStream?

There is the option to start disabling additional unit tests, but QA probably would not accept that without understanding the cause for failure.

[Timo Jyrinki (timo-jyrinki)]

armhf build also failed in the same test:
https://launchpadlibrarian.net/190360081/buildlog_ubuntu-rtm-14.09-armhf.qtbase-opensource-src_5.3.0%2Bdfsg-2ubuntu10~utopic1~test11_FAILEDTOBUILD.txt.gz

[Timo Jyrinki (timo-jyrinki)]

The test actually does use network so it might need to get fixed. I've pushed a new build disabling that single test, to see if there are more failures.

[Mathieu Trudel-Lapierre (cyphermox)]

As far as I know there is nothing left to do on platform-api or NM, and the issues have already been closed in other bugs; let's just keep the qtbase task so it's clear where we're at.

[Lorn Potter (lorn-potter)]

When I run that test on the phone, it does not crash and passes.

[Lorn Potter (lorn-potter)]

Updated upstream. https://codereview.qt-project.org/#/c/99818/

[Timo Jyrinki (timo-jyrinki)]

I can confirm that the Saturday build with Lorn's newest patch, version ubuntu10~utopic1~test14, has the 3G connection staying alive.

Unit tests in qtbase however started failing so the build was done with temporarily disabling those. My next build will be with the patch version 4 from upstream, and will be versioned ubuntu10~vrtm~1. If unit tests still fail, I will build a ~vrtm~2 with the latest patch (some found issues fixed) but unit tests still disabled so that it can still be tested.

[Timo Jyrinki (timo-jyrinki)]

rtm-022 is again ready to test with the latest patch revision and the package versions ending in ~vrtm~2. I'll use a separate silo for further test builds but 022 is the one to test.

[Łukasz Zemczak (sil2100)]

As discussed, I suppose we should have QA starting testing of the packages with the unit tests temporarily disabled while the tests are still being fixed, but wait with the release until we have a clear understanding of why those are failing.

[Timo Jyrinki (timo-jyrinki)]

Upstream patch set 6 improves tests again (fail instead of crash) but no full pass: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-009/+sourcepub/4574822/+listing-archive-extra ("FAIL! : tst_QNetworkConfiguration::comparison() 'configs.count()' returned FALSE. ())

Patch set 6 is now uploaded to rtm-022 with tests disabled again as ubuntu10~vrtm~4, armhf build can be upgraded to in around 3.5h or a little less.

[Timo Jyrinki (timo-jyrinki)]

== PPA to be tested ==
vrtm~4 ready, ie upstream patch set 6 with unit tests just disabled.

== reproducing the original bug / test case==
https://wiki.ubuntu.com/Process/Merges/TestPlans/Qt#Testing_networking_code_in_Qt_Base updated with best information so far, but feel free to update with more accurate test case for example.

om26er/rvr are now reporting not able to reproduce the original issue on image #161 (krillin) anymore. Although it's sometimes hard to test because the test case is not crystal clear either. Suspicion that this network-manager landing might have fixed the symptom: https://lists.canonical.com/archives/rtm-14.09-changes/2014-November/000814.html

== this bug's description ==
This bug describes the symptom, but it would be nice to have more accurate description of the problem being solved with the fixed network manager Qt code.

== unit tests ==
Regarding unit tests, likewise because network-manager isn't installed on the builders also the following test fails (tested by skipping over the previous comparison one):
QDEBUG : tst_QNetworkConfigurationManager::allConfigurations() All configurations: 0
FAIL! : tst_QNetworkConfigurationManager::allConfigurations() 'all' returned FALSE. ()

Another test build with network-manager in build dependencies (so that it's installed during building) shows that it alone does not make the unit tests pass: https://launchpadlibrarian.net/190552078/buildlog_ubuntu-rtm-14.09-amd64.qtbase-opensource-src_5.3.0%2Bdfsg-2ubuntu10~vrtm~4%2Btest2_FAILEDTOBUILD.txt.gz

[kevin gunn (kgunn72)]

@failling unit tests - per lorn on irc,
tests are written in that they assume the generic plugin is loaded
& those are never going to pass since they need a valid configuration based on the generic plugin
FAIL! : tst_QNetworkConfiguration::comparison() 'configs.count()' returned FALSE. ()
but our patch set explicitly blocks the generic plugin if the networkmanager plugin is found
so it may be safe to selectively disable tests depending on a valid config.

[Lorn Potter (lorn-potter)]

Here's a patch to skip some of the tests that are failing due to no valid configurations on the test machines.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "skip failing network tests" 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.]

[Timo Jyrinki (timo-jyrinki)]

Patch set 7 from upstream together with the skipped tests in Lorn's path plus two more skipped tests yielded a pass on unit tests. I copied this vrtm~5 to the 022 silo from the testing PPA.

Current QA testing would imply the earlier Network Manager fix was a sufficient solution for now, so this Qt backend fix would not be rushed in anymore. The silo can be landed later to rtm, or to vivid targetting OTA update.

[Pat McGowan (pat-mcgowan)]

Removed from topblocker list

[Lorn Potter (lorn-potter)]

Has that network-manager fix hit ubuntu-rtm/devel yet? Because without these qtbearer/qnam patches, I'm still seeing images loading issues.

The problem is not manually disabling the AP, but when moving (roaming) from one to another, i.e. moving from wlan coverage to 3g coverage, or from 3g to wlan

If you set up a Wlan AP, connect the phone to it, and then pull the power plug on it so that AP disappears (or walk outside), the 3g connection will become default, but the old non patched QNAM is still holding on to the now non invalid wlan configuration. Refreshing to scopes will result in nothing being downloaded. The generic plugin does not know when something is actually connected or just the interface is 'up'. It does not generate the needed signals for QNAM to continue functioning without tearing down the QNAM object.

Even worse, if you bootup with 3g connected, walk into wlan coverage, the QNAM get() request will be going through the still connected 3g connection.

The tests mentioned at https://wiki.ubuntu.com/Process/Merges/TestPlans/Qt#Testing_networking_code_in_Qt_base do not cover "roaming" from one connected technology to another.

[Lorn Potter (lorn-potter)]

I did more testing of the generic plugin, and it's not as bad as I thought, in that it does signal when interfaces become the default route.

But my comment still stands that without these patches (in the least, the patch to QNAM itself is especially needed) the defaultConfiguration internal to QNAM will not switch, which _will_ cause people to wonder why their mobile data is being used while the indicator shows that they are connected to wifi, and _will_ cause people to use up their expensive mobile data.

I question the removal of this from TOPBLOCKER's and rtm.

QtBearer is not just about starting and stopping the connections, QNAM uses it internally for every get() request.

[Oliver Grawert (ogra)]

it is tagged ota-1, so it will land, just not in one of the next two promoted images, which just delays it by two weeks

[kevin gunn (kgunn72)]

@lorn - per ogra's comment, it's still a top-blocker in spirit (folks were using the title for some reporting visibility)

[Launchpad Janitor (janitor)]

This bug was fixed in the package qtbase-opensource-src - 5.3.2+dfsg-4ubuntu5

---------------
qtbase-opensource-src (5.3.2+dfsg-4ubuntu5) vivid; urgency=medium

  * Rename qt5-qmake-cross-armhf to qt5-qmake-arm-linux-gnueabihf
 -- Zoltan Balogh <email address hidden> Thu, 20 Nov 2014 10:33:16 +0000

[Timo Jyrinki (timo-jyrinki)]

So this was also included in the fixing upload:

  * Pick up the Qt 5.4 network-manager bearer fixes (LP: #1357321)
    - debian/patches/disable-generic-plugin-when-others-available.patch
      + not merged upstream, would need better runtime detection mechanism
    - debian/patches/update-QtBearer-NetworkManager-backend-API.patch
    - debian/patches/Reset-QNAM-s-NetworkConfiguration-when-state-changes.patch
    - debian/patches/Use-a-property-cache-to-cut-down-on-blocking-calls.patch
      + refreshed to match the Qt 5.4 networkmanger bearer directory code
        exactly. earlier patches made simpler via this.
    - debian/patches/Support-dual-sim-in-QtBearer-s-networkmanager-backen.patch
    - debian/patches/QtBearer-networkmanager-make-sure-to-set-flag-Active.patch
      + upstream patch set 7

These are now in vivid, but not yet in rtm. The rtm silo is waiting for QA Sign-off to be included in ota1.

[Lorn Potter (lorn-potter)]

Start InternetCheckercmd with wifi enabled, with the known wifi router unpowered or out of range, while connected to mobile data. (will not work like this when manually enabling/disabling wifi)

It will return something like this:

phablet@ubuntu-phablet:~$ InternetCheckercmd/InternetCheckercmd
(Checker::Checker:14) - configuration "ccmni0" QFlags(0x2|0x4|0x8)
(Checker::createGetRequest:30) - Initiate HTTP GET Request
(Checker::finishedSlot:35) - configuration "ccmni0" QFlags(0x2|0x4|0x8)
(Checker::finishedSlot:39) - "HTTP GET Reply Code: 0 and Name: Unknown error"

(reply code 0 means success)

With the InternetCheckercmd still running, either walk into range of a known/configured wifi, or power on the wifi router that is known and configured, so the phone will auto connect to it.

Wait for the wifi indicator to show there is a wifi connection. Notice that the get request is still going through the mobile data connection, instead of the wifi connection.

This means anything keeping a QNAM instance and using it to do random get requests will be using expensive mobile data instead of cheaper wifi, even though wifi is connected.

Try this again with the patched QNAM and QtBearer plugin, and it will change the configuration which it uses for the get request.

[Launchpad Janitor (janitor)]

This bug was fixed in the package qtbase-opensource-src - 5.3.0+dfsg-2ubuntu10~vrtm~5

---------------
qtbase-opensource-src (5.3.0+dfsg-2ubuntu10~vrtm~5) 14.09; urgency=medium

  * Pick up the Qt 5.4 network-manager bearer fixes (LP: #1357321)
    - debian/patches/Add-better-mobile-connections-to-QtBearer-NetworkMan.patch
    - debian/patches/disable-generic-plugin-when-others-available.patch
    - debian/patches/update-QtBearer-NetworkManager-backend-API.patch
    - debian/patches/Reset-QNAM-s-NetworkConfiguration-when-state-changes.patch
    - debian/patches/Use-a-property-cache-to-cut-down-on-blocking-calls.patch
    - debian/patches/Make-QtBearer-networkmanager-backend-respond-to-wire.patch
    - debian/patches/Support-dual-sim-in-QtBearer-s-networkmanager-backen.patch
    - debian/patches/make-qtbearer-networkmanager-defaultConfiguration-mo.patch
    - debian/patches/QtBearer-networkmanager-make-sure-to-set-flag-Active.patch
      + upstream patch set 7
  * debian/patches/enable-tests: Disable tests that assume generic plugin
    instead of the network-manager plugin
 -- Timo Jyrinki <email address hidden> Thu, 09 Oct 2014 15:43:33 +0000

[Pat McGowan (pat-mcgowan)]

documenting the landing

[Yuan-Chen Cheng (ycheng-twn)]

mark as fix release since no activity for long.