Bug 1254016 - IPv4 fallback is not working when connecting to a dualstack host with non-functional IPv6 [NEEDINFO]
IPv4 fallback is not working when connecting to a dualstack host with non-fun...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: squid (Show other bugs)
7.1
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Luboš Uhliarik
Martin Frodl
: Patch
Depends On:
Blocks: 1295396
  Show dependency treegraph
 
Reported: 2015-08-16 14:26 EDT by Brian J. Murrell
Modified: 2016-11-03 17:15 EDT (History)
6 users (show)

See Also:
Fixed In Version: squid-3.5.10-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 17:15:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mfrodl: needinfo? (brian)


Attachments (Terms of Use)
backported patch (2.42 KB, patch)
2015-08-19 10:44 EDT, Brian J. Murrell
no flags Details | Diff

  None (edit)
Description Brian J. Murrell 2015-08-16 14:26:25 EDT
Description of problem:
Due to many bugs fixed since 3.3.8 I would like to encourage/request an update to the latest squid, to be included in RHEL.  In particular this bug:

http://www.squid-cache.org/Versions/v3/3.5/changesets/squid-3.5-13851.patch

affects me and I am going to have to roll my own 3.5.6 (at least, but since it's out, 3.5.7 likely) squid package.  It would just be nice to have a fully functional package come from the distro.  I suppose short of a squid update, at least including the above bugfix would be nice.

Version-Release number of selected component (if applicable):
3.3.8-12.el7_0

How reproducible:
100%

Steps to Reproduce:
1. Install and configure squid
2. Try to connect to a host that has both IPv4 and IPv6 addresses but non-functional IPv6
3. Watch as your connections to such hosts through the proxy fail.

Actual results:
Connections to broken IPv6 (but functional IPv4) break as the IPv4 fallback fails.

Expected results:
Connections should succeed.

Additional info:
Comment 2 Tomáš Hozza 2015-08-19 09:26:32 EDT
Lowering the severity to medium, as this bug does not fit the Urgent severity description.
Comment 4 Brian J. Murrell 2015-08-19 10:16:48 EDT
You don't think it's urgent that any website with a non-working IPv6 end-point cannot be reached through squid?

A non-working IPv4 endpoint would likely become very obvious to a website owner pretty quickly and get fixed pretty quickly but a non-working IPv6 endpoint might not (get noticed or even fixed quickly) with the low-penetration of IPv6 thus far, in addition to the assumption by the website owner that any hosts failing to reach the IPv6 endpoint will fallback to IPv4.

This bug in squid leaves those websites unreachable to users with IPv6 with who knows what kind of repair time the website owner might have given the above assumptions.

And yes, it's not lost on me that ultimately this is the fault of the broken website but that doesn't change the fact that the fallback that any non-squid using host will enjoy will not be enjoyed by a squid-proxied user.
Comment 5 Tomáš Hozza 2015-08-19 10:32:08 EDT
(In reply to Brian J. Murrell from comment #4)
> You don't think it's urgent that any website with a non-working IPv6
> end-point cannot be reached through squid?

I'm aware of the implications of this bug. I think the bug is important, but yes I don't think it is urgent.

Urgent stands for:
"catastrophic issues which severely impact the mission-critical operations of an organization. This may mean that the operational servers, development systems or customer applications are down or not functioning and no procedural workaround exists."

Also RHEL development works in a different way compared to Fedora. RHEL is aimed for stability and compatibility between releases. Therefore it is very unlikely we will update the package to the latest upstream version without thorough investigation of possible issues. However we may look at backporting the fix for the IPv4 fallback.
Comment 6 Brian J. Murrell 2015-08-19 10:43:46 EDT
(In reply to Tomas Hozza from comment #5)
> 
> Urgent stands for:
> "catastrophic issues which severely impact the mission-critical operations
> of an organization. This may mean that the operational servers, development
> systems or customer applications are down or not functioning and no
> procedural workaround exists."

OK.

> Also RHEL development works in a different way compared to Fedora. RHEL is
> aimed for stability and compatibility between releases. Therefore it is very
> unlikely we will update the package to the latest upstream version without
> thorough investigation of possible issues. However we may look at
> backporting the fix for the IPv4 fallback.

Indeed.  I am aware of this.  I think this ticket was trying to cover both.  That a patch backport (which I will attach) is needed in the short term but that updating to the latest for the next point release would be desirable since there are lots of other fixes in there.
Comment 7 Brian J. Murrell 2015-08-19 10:44:42 EDT
Created attachment 1064900 [details]
backported patch
Comment 8 Brian J. Murrell 2016-01-03 17:04:03 EST
Any activity/progress on this issue?
Comment 9 Tomáš Hozza 2016-01-04 03:53:11 EST
The bug is currently proposed for the next RHEL-7 minor update. However I can not make any promises that it will be included.
Comment 14 Brian J. Murrell 2016-07-02 14:44:45 EDT
errata-xmlrpc 2016-06-14 08:04:34 EDT
Status: MODIFIED → ON_QA

How long does it stay ON_QA before we see it in the regular repo?
Comment 15 Tomáš Hozza 2016-07-11 09:11:52 EDT
(In reply to Brian J. Murrell from comment #14)
> errata-xmlrpc 2016-06-14 08:04:34 EDT
> Status: MODIFIED → ON_QA
> 
> How long does it stay ON_QA before we see it in the regular repo?

Hello.

If the package passes testing, it should be available via regular means once RHEL-7.3 is GA. Unfortunately I can not provide you any exact date when this will be. Thank you for understanding.
Comment 16 Brian J. Murrell 2016-07-11 10:08:11 EDT
Ahhh.  I didn't realise this was being held until RHEL-7.3 was GA.

Thanks for the update!
Comment 19 Martin Frodl 2016-09-13 10:10:19 EDT
Hi Brian,

I have been trying to reproduce the original bug by following the steps you
mention in the description in order to verify the fix. I had little success so
far. Would you mind giving a more specific example how to reproduce it?

What I tried:
1) 3 machines, named 'client', 'proxy' and 'backend'; originally, all three had
   both IPv4 and IPv6 working
3) On 'backend', I disabled IPv6 as follows:

   # sysctl -w net.ipv6.conf.all.disable_ipv6=1
   # sysctl -w net.ipv6.conf.default.disable_ipv6=1

4) On 'proxy', I installed squid-3.3.8-26.el7 and started it with default
   configuration
5) On 'backend', I installed httpd-2.4.6-45.el7 and started it with default
   configuration
6) From 'client', I issued the following request:

   # curl -x proxy:3128 http://backend/testfile

The connection hanged for 1 minute (default value of connect_timeout) but
eventually, the requested file was correctly downloaded over IPv4.
Comment 21 Brian J. Murrell 2016-09-15 07:44:34 EDT
Hi Martin,

Your test looks valid to me and seems to indicate that the problem is fixed.

I, unfortunately don't have any example sites where I know ipv6 is broken, but ipv4 is working where I can test.  I also don't have the fixed RPM to test with.
Comment 23 errata-xmlrpc 2016-11-03 17:15:50 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2600.html

Note You need to log in before you can comment on or make changes to this bug.