Issue after Captive Portal

Bug #807259 reported by David R. Hedges on 2011-07-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Status tracked in Eoan

Bug Description

I attempted to perform a release update today from maverick to natty. Both update-manager -c and do-release-update indicated that no newer releases were available.

After some investigation, I discovered the following was the culprit:
david@marshall:~$ export DEBUG_UPDATE_MANAGER=1
david@marshall:~$ do-release-upgrade
Checking for a new ubuntu release
MetaRelease.__init__() useDevel=False useProposed=False
/etc/update-manager/meta-release: -development
/etc/update-manager/meta-release: -proposed
result of meta-release download: 'HTTP Error 304: Not Modified'
reading file '/home/david/.cache/update-manager-core/meta-release'
have self.metarelease_information
current dist name: 'maverick'
current dist not found in meta-release file

No new release found
david@marshall:~$ ls -l ~/.cache/update-manager-core/meta-release
-rw-r--r-- 1 david david 780 2011-06-30 18:14 /home/david/.cache/update-manager-core/meta-release
david@marshall:~$ cat ~/.cache/update-manager-core/meta-release
<?xml version="1.0" encoding="UTF-8"?>
<meta http-equiv="refresh" content="0; url=">
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="expires" content="-1">


As you can likely tell, I was behind a captive portal on 2011-06-30. Update manager [automatically] attempted to retrieve the meta-release file at that time, and--even though it likely had a valid file before--grabbed the captive portal page, because it was newer. Now when update-manager-core calls, the following is added:
      req.add_header("If-Modified-Since", time.asctime(time.gmtime(lastmodified)))

The meta-release file on the server hasn't been changed since I used the captive portal (and likely only changes when a new release cycle begins), so the server returns HTTP 304 (not modified), and the client relies on the cached copy on disk (which is bogus). Neither MetaReleaseCore::download() nor MetaReleaseCore::parse() really care that the file on disk is obviously not the right format, with ::parse() simply returning false to nothing (unchecked return value in ::download()).

Given the small size of meta-release (6.7k), it hardly seems worth the effort of adding complexity necessary to avoid potentially re-downloading this data occasionally, but I suppose it's your prerogative. One workaround while still achieving this goal might be to check the server date is newer *OR* filesize does not match with a HEAD request prior to GET (and without If-Modified-Since), though this still leaves the window open for the corner case of a captive portal page exactly the same size as the meta-release file.

Additionally, if ::parse() returns false, it may be worthwhile to delete the .cache version of the meta-release file (and try to download it one more time?) (and tell the user something more useful than "no update available"?).

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: update-manager-core 1:0.142.23
ProcVersionSignature: Ubuntu 2.6.35-30.54-generic
Uname: Linux 2.6.35-30-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Thu Jul 7 16:40:27 2011
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
 PATH=(custom, user)
SourcePackage: update-manager

David R. Hedges (p14nd4) wrote :

Thanks for reporting this bug and for the detailed report, and sorry for having taken some time to get a response. The bug seems confirmed according to the data you provide.

affects: update-manager-core (Ubuntu) → update-manager (Ubuntu)
Changed in update-manager (Ubuntu):
status: New → Confirmed
Changed in update-manager (Ubuntu):
importance: Undecided → Medium
Changed in update-manager (Ubuntu):
status: Confirmed → Triaged

meta-release really doesn't change often; so caching behind captive portals is a real issue.

NM can already differentiate between a captive portal and the real internet (provided the feature is enabled and configured, but we're working on that too). Update-manager probably should be a little more careful about exactly what state we track and consider to be online, rather than taking any NM_STATE_CONNECTED_* as valid; some of these may mean we're behind a captive portal and in that case should be ignored... but this needs careful validation to account for local enterprise mirrors too.

Upgrading to "High"; captive portals are pretty common, and we want to be proactive about how we deal with those, given users doing upgrades, especially since we should soon have captive portal detection enabled.

Changed in update-manager (Ubuntu):
importance: Medium → High
tags: added: rls-cc-incoming
tags: added: rls-ee-incoming
removed: rls-cc-incoming
tags: removed: rls-ee-incoming
tags: added: id-5ce6d6855257155f211b5d3f
Julian Andres Klode (juliank) wrote :

This has been fixed in bionic with bug 1744318

Changed in update-manager (Ubuntu Eoan):
status: Triaged → Fix Released
Julian Andres Klode (juliank) wrote :

It now fails with:
result of meta-release download: '<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for ''. (_ssl.c:1056)>'
Failed to connect to Check your Internet connection or proxy settings
NO self.metarelease_information
No new release found.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers