[Bug 807259] Re: MetaRelease.download() Issue after Captive Portal

Wed Jul 19 16:15:31 UTC 2017

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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to update-manager in Ubuntu.
https://bugs.launchpad.net/bugs/807259

Title:
  MetaRelease.download() Issue after Captive Portal

Status in update-manager package in Ubuntu:
  Triaged

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 at marshall:~$ export DEBUG_UPDATE_MANAGER=1
  david at marshall:~$ do-release-upgrade 
  Checking for a new ubuntu release
  MetaRelease.__init__() useDevel=False useProposed=False
  /etc/update-manager/meta-release: http://changelogs.ubuntu.com/meta-release 
  /etc/update-manager/meta-release: http://changelogs.ubuntu.com/meta-release-lts 
  /etc/update-manager/meta-release: -development 
  /etc/update-manager/meta-release: -proposed 
  metarelease-uri: http://changelogs.ubuntu.com/meta-release
  MetaRelease.download()
  result of meta-release download: 'HTTP Error 304: Not Modified'
  reading file '/home/david/.cache/update-manager-core/meta-release'
  have self.metarelease_information
  MetaRelease.parse()
  current dist name: 'maverick'
  current dist not found in meta-release file

  No new release found
  david at 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 at marshall:~$ cat ~/.cache/update-manager-core/meta-release
  <html>
  <!--
  <?xml version="1.0" encoding="UTF-8"?>
    <WISPAccessGatewayParam
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://192.168.10.1/xml/WISPAccessGatewayParam.xsd">
      <Redirect>
  	<AccessProcedure>1.0</AccessProcedure>
  	<AccessLocation></AccessLocation>
  	<LocationName></LocationName>
  	<LoginURL>http://192.168.10.1/login?target=xml</LoginURL>
  	<MessageType>100</MessageType>
  	<ResponseCode>0</ResponseCode>
      </Redirect>
    </WISPAccessGatewayParam>
  -->
  <head>
  <title>...</title>
  <meta http-equiv="refresh" content="0; url=http://192.168.10.1/login?dst=http%3A%2F%2Fchangelogs.ubuntu.com%2Fmeta-release">
  <meta http-equiv="pragma" content="no-cache">
  <meta http-equiv="expires" content="-1">
  </head>
  <body>
  </body>
  </html>

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

  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 self.download(), the following is added:
        req.add_header("If-Modified-Since", time.asctime(time.gmtime(lastmodified)))

  The meta-release file on the changelog.ubuntu.com 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 2.6.35.13
  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)
  ProcEnviron:
   LC_TIME=en_DK.utf8
   PATH=(custom, user)
   LANG=en_US.utf8
   SHELL=/bin/bash
  SourcePackage: update-manager

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/807259/+subscriptions