Cannot connect to remote desktop, vino eating cpu and not answering

[Swâmi Petaramesh]

* Impact
vino eats cpu and doesn't work correctly when the upnp option is enabled

* Test case
- log into an unity session
- open vino settings
- check the upnp box

-> the process shouldn't start using cpu, if you have a router with upnp autoconfiguration it should get its table updated

* Regression potential

the change is limited to the upnp configuration option

----------------------

Seen this on 2 machines both running vino 3.8.1-0ubuntu9, exact same symptoms :

- One machine running Ubuntu 16.04.1 xenial LTS (from which I report this)
- One machine running Mint 18 Sarah (based on Ubuntu 16.04, showing same behaviour)

On both machines, vino does not work or works very erratically :
- The Vino icon doesn't appear in the task bar at all, or eventually appears after 20 minutes or so...
- uPNP port opening is *NOT* registered by router
- Port 5900 seems open
- It is not possible to remotely connect to the machine (server not responding)
- It *may* (or may not) start working after vino has been running for an extended period of time...
- If it eventually starts working, then, well, it works, but that seldom happens.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: vino 3.8.1-0ubuntu9
ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
Uname: Linux 4.4.0-31-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Aug 6 17:04:17 2016
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-07-22 (15 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
SourcePackage: vino
UpgradeStatus: No upgrade log present (probably fresh install)

[Swâmi Petaramesh (swami-petaramesh)]

After some more analysis, I could confirm that the issue relates to uPNP. It never succeeds setting uPNP on my router/DSL box (an Orange "LiveBox"), but if I uncheck the uPNP checkbox, then vino opens up immediately and works... on the LAN.

As a side note, the uPNP issue does not relate to the router, as Skype or my son's games have no problem opening ports using uPNP on the same router box...

[Launchpad Janitor (janitor)]

This bug was fixed in the package vino - 3.8.1-0ubuntu11

---------------
vino (3.8.1-0ubuntu11) yakkety; urgency=medium

  * debian/control.in:
    - build-depends on libgnutls28-dev rather libgnutls-dev, the binary
      has been renamed in yakkery to follow Debian

 -- Sebastien Bacher <email address hidden> Wed, 10 Aug 2016 15:18:41 +0200

[Brian Murray (brian-murray)]

Hello Swâmi, or anyone else affected,

Accepted vino into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/vino/3.8.1-0ubuntu9.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Swâmi Petaramesh (swami-petaramesh)]

Hi there,

The fix works for me and solves the issues on both machines on which I had encountered it (an Ubuntu 16.04 and a Mint 18).

I cam confirm that uPNP now works properly, and I can connect to the remote desktops.

Thank you very much.

[Sebastien Bacher (seb128)]

Great, thanks for testing!

[Launchpad Janitor (janitor)]

This bug was fixed in the package vino - 3.8.1-0ubuntu9.1

---------------
vino (3.8.1-0ubuntu9.1) xenial; urgency=medium

  * debian/patches/05_use-system-miniupnpc.patch:
    - use correct arguments for upnp calls, fixes vino server eating
      cpu and not responding once the corresponding option is enabled
      (lp: #1610547)

 -- Sebastien Bacher <email address hidden> Wed, 10 Aug 2016 11:03:23 +0200

[Martin Pitt (pitti)]

The verification of the Stable Release Update for vino has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.