Re: [squid-users] New Squid prefers IPv4
Spam detection software, running on the system "master.squid-cache.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello, I'm using Squid 3.5.24 (indluded in Synology DSM 6) and I've an issue with time acl. All works fine except some websites like myhordes.de. Once the user connected to this kind of website, the time acl [...] Content analysis details: (5.5 points, 5.0 required) pts rule name description -- -- 3.6 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL [82.64.172.59 listed in zen.spamhaus.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.7 SPF_NEUTRALSPF: sender does not match SPF record (neutral) -0.0 T_SCC_BODY_TEXT_LINE No description available. 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -0.0 NICE_REPLY_A Looks like a legit reply (A) --- Begin Message --- Hello, I'm using Squid 3.5.24 (indluded in Synology DSM 6) and I've an issue with time acl. All works fine except some websites like myhordes.de. Once the user connected to this kind of website, the time acl has no effect while the page is not reloaded. All datas send and received by javascript continue going thru the proxy server without any filter. Thx a lot for any idea. Regards, Speedy --- End Message --- ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] New Squid prefers IPv4
On 2024-02-05 11:32, Rob van der Putten wrote: On 05/02/2024 17:16, Dieter Bloms wrote: On Mon, Feb 05, Rob van der Putten wrote: After upgrading Squid from 3 to 5 the percentage of IPv6 reduced from 61% to less then 1%. Any ideas? yes, since squid5 the happy eyeball algorithm as described in rfc 8305 is used. If your ipv4 connectivity is better than ipv6 than ipv4 is used. I'm not quite sure how this is established. See RFC 8305 for the general approach, search squid.conf.documented for "Happy Eyeballs" to find relevant configuration directives, and see the following Squid commit message for a subset of Squid implementation caveats: https://github.com/squid-cache/squid/commit/5562295321debdf33b59f772bce846bf6dd33c26 Antony is correct that ICMP is pretty much irrelevant here. A brief algorithm description in Antony's response is easy to misinterpret, but it can be used as a rough approximation of what is actually going on. AFAICT, we do not have a good understanding of how the implemented algorithm actually behaves in various deployment environments. If you believe your IPv6 connectivity is better than your IPv4 connectivity, you may want to investigate why your Squid favors IPv4. HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] New Squid prefers IPv4
On Monday 05 February 2024 at 17:32:51, Rob van der Putten wrote: > Hi there > > On 05/02/2024 17:16, Dieter Bloms wrote: > > On Mon, Feb 05, Rob van der Putten wrote: > >> After upgrading Squid from 3 to 5 the percentage of IPv6 reduced from > >> 61% to less then 1%. > >> Any ideas? > > > > yes, since squid5 the happy eyeball algorithm as described in rfc 8305 > > is used. > > If your ipv4 connectivity is better than ipv6 than ipv4 is used. > > I'm not quite sure how this is established. It prefers IPv4 even when > the IPv6 ping is slightly smaller. I believe ping (ICMP) timings are irrelevant. The client (squid in this case) does a DNS lookup for the hostname's A and records, then makes two simultaneous HTTP connections to the server (one IPv4, on IPv6) and whichever one responds first *by HTTP* is then regarded as being the best way to route traffic thereafter. So, if you want to understand how this is doing what it is, I suggest you perform a packet capture of HTTP traffic and look at the requests and the response timings. Antony. -- I want to build a machine that will be proud of me. - Danny Hillis, creator of The Connection Machine Please reply to the list; please *don't* CC me. ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] New Squid prefers IPv4
Hi there On 05/02/2024 17:16, Dieter Bloms wrote: On Mon, Feb 05, Rob van der Putten wrote: After upgrading Squid from 3 to 5 the percentage of IPv6 reduced from 61% to less then 1%. Any ideas? yes, since squid5 the happy eyeball algorithm as described in rfc 8305 is used. If your ipv4 connectivity is better than ipv6 than ipv4 is used. I'm not quite sure how this is established. It prefers IPv4 even when the IPv6 ping is slightly smaller. Regards, Rob ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] New Squid prefers IPv4
Hello Rob, On Mon, Feb 05, Rob van der Putten wrote: > After upgrading Squid from 3 to 5 the percentage of IPv6 reduced from 61% to > less then 1%. > Any ideas? yes, since squid5 the happy eyeball algorithm as described in rfc 8305 is used. If your ipv4 connectivity is better than ipv6 than ipv4 is used. -- Regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
[squid-users] New Squid prefers IPv4
Hi there After upgrading Squid from 3 to 5 the percentage of IPv6 reduced from 61% to less then 1%. Any ideas? Regards, Rob ___ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] external icap issue with squid 5 and higher
Hello Alex, Thank you so much for your time and this detailed analysis. We will get back to the Forcepoint editor and ask for a correction. Best regards, Yvain PAYEN Pôle Opérations & Technologies Equipe Infrastructure système T. +33 (0)5 57 57 01 85 (Poste 1185) M. +33 (0)7 87 30 34 01 Absent tous les mercredi Tessi France Immeuble Cassiopée 1-3 avenue des Satellites 33185 Le Haillan Pensez à l'environnement avant d'imprimer cet e-mail. -Message d'origine- De : Alex Rousskov Envoyé : samedi 3 février 2024 04:32 À : Yvain PAYEN ; squid-users@lists.squid-cache.org Objet : Re: [squid-users] external icap issue with squid 5 and higher ⚠ FR : Ce message provient de l'extérieur de l'organisation. N'ouvrez pas de liens ou de pièces jointes à moins que vous ne sachiez que le contenu est fiable. ⚠ On 2024-02-02 17:36, Yvain PAYEN wrote: > I just sent you a Onedrive link to 2 pcap files, one for http request > and one for https request. Thank you. The ICAP service you are using is sending a malformed ICAP response to Squid. That ICAP response promises that there will be no HTTP body in the encapsulated HTTP message: Encapsulated: res-hdr=0, null-body=524 ... but the service does send a body after HTTP headers. That HTTP body contains an HTML resource explaining that the CONNECT message was blocked and redirecting the user to blockpage.cgi, but that content does not really matter here. What matters is that there are some bytes after the encapsulated HTTP header. There should be no such bytes (or the ICAP Encapsulated header should have res-body=184 instead of null-body=524). The null-body offset in the ICAP Encapsulated header is wrong. It should be 184 bytes (i.e. the size of the encapsulated HTTP response header), not 524 bytes. FWIW, 524 is the sum of the encapsulated HTTP response header (184 bytes) and the encapsulated HTTP response body (340 bytes). It sounds like the ICAP service thinks that it is encapsulating an HTTP response header, but it is actually encapsulating the whole HTTP response. Since this is an ICAP framing error(s), Squid rejects the whole transaction and bypasses the ICAP service (as configured). To fix this, fix the ICAP service configuration (or code). It is also possible to modify Squid code to ignore these errors, but I do not recommend that, and a hard-coded or rigid tolerance code like that should not be accepted by the Squid Project for the official inclusion. The ICAP response in the "http request" capture does not have this problem. It contains an encapsulated HTTP 302 Moved header without any encapsulated HTTP body. That encapsulation matches the ICAP Encapsulated header. HTH, Alex. > -Message d'origine- > De : Alex Rousskov > Envoyé : vendredi 2 février 2024 18:45 À : Yvain PAYEN > ; squid-users@lists.squid-cache.org Objet : Re: > [squid-users] external icap issue with squid 5 and higher > > ⚠ FR : Ce message provient de l'extérieur de l'organisation. N'ouvrez > pas de liens ou de pièces jointes à moins que vous ne sachiez que le > contenu est fiable. ⚠ > > > > On 2024-02-02 12:04, Yvain PAYEN wrote: > >> We don't use ssl_bump, icap service only analyze HTTP CONNECT >> requests > > Great, that simplifies things a lot. > > >> Adaptation::Icap::Xaction::noteCommRead threw exception: > check >> failed: readBuf.isEmpty()> exception location: ModXact.cc(1219) > stopParsing > > It looks like Squid found some leftovers after the ICAP response that Squid > (thought it) had fully parsed. I do not yet know whether that ICAP response > was malformed or Squid is buggy. > > Can you share raw ICAP response bytes (preferrably in libpcap or similar raw > packet capture format) collected by tcpdump, wireshark, or a similar tool? > You can obfuscate/convert that ICAP response to text as needed, but if those > extra bytes get lost in those conversions, then we would not be able to tell > what those bytes are (e.g., they may contain whitespace characters that get > easily lost). > > > Thank you, > > Alex. > > >>2024/02/02 17:40:41.943 kid1| 93,3| ModXact.cc(679) callException: >> bypassing 0x558f358fdae0*2 exception: check failed: readBuf.isEmpty() >>exception location: ModXact.cc(1219) stopParsing [FD >> 17;rp(1)S(2)YG/Rw job17] >>2024/02/02 17:40:41.943 kid1| 93,7| ModXact.cc(720) disableBypass: >> will never start bypass because already started to bypass >>2024/02/02 17:40:41.943 kid1| 93,5| Xaction.cc(127) disableRepeats: >> Adaptation::Icap::ModXact still cannot be repeated because preparing to echo >> content [FD17;rp(1)S(2)G/Rw job17] >>2024/02/02 17:40:41.943 kid1| 93,7| ModXact.cc(724) disableBypass: >> not protecting group bypass because preparing to echo content >>2024/02/02 17:40:41.943 kid1| 93,3| Xaction.cc(564) setOutcome: >> WARNING: resetting outcome: from ICAP_SAT to ICAP_ECHO >>2024/02/02 17:40:41.943 kid1| 93,7|
