On Wednesday, November 4, 2020, 3:27:25 AM GMT+1, Alex Rousskov
wrote:
> https://bugs.squid-cache.org/show_bug.cgi?id=5084
Hi,
I added a comment to that bug report.
I cannot reproduce the problem anymore, at least not with the latest version of
Squid 5.
Thanks,
Vieri
On 10/18/20 6:07 PM, Vieri wrote:
> Please let me know if I should add something to the bug report
If you can retest with the triage patch attached to the bug report,
please do so an post new error messages produced by the patch (if any).
You can post them to the bug report (preferred) or here.
Hi Vieri,
I attached a patch to bug5084 which may help us to debug the issue:
https://bugs.squid-cache.org/attachment.cgi?id=3772
The patch is for squid-v5 and produces debug messages at debug level 1.
Regards,
Christos
On 17/10/20 11:36 μ.μ., Alex Rousskov wrote:
On 10/16/20 11:58 A
On 19/10/20 11:07 am, Vieri wrote:
>
> On Saturday, October 17, 2020, 10:36:47 PM GMT+2, Alex Rousskov wrote:
>
>> or due to some TLS error.
>> I filed bug #5084
>
> Hi again,
>
> Thanks for opening a bug report.
>
> I don't want to add anything there myself because I wouldn't want to confu
On Saturday, October 17, 2020, 10:36:47 PM GMT+2, Alex Rousskov
wrote:
> or due to some TLS error.
> I filed bug #5084
Hi again,
Thanks for opening a bug report.
I don't want to add anything there myself because I wouldn't want to confuse
whoever might take this issue into account, but I
On 10/16/20 11:58 AM, Vieri wrote:
> I pinpointed one particular request that's failing:
>
> 2020/10/16 16:56:37.250 kid1| 85,2| client_side_request.cc(745)
> clientAccessCheckDone: The request GET
> https://ed1lncb62601.webex.com/direct?type=websocket&dtype=binary&rand=1602860196950&uuidtag=G7
On 17/10/20 3:07 am, Vieri wrote:
> Hi,
>
> I think I found something in the cache.log I posted before.
>
> sendRequest: HTTP Server conn* local=PUB_IPv4_ADDR_3
> ...
> sendRequest: HTTP Server conn* local=PUB_IPv4_ADDR_2
>
> It seems that Squid sometimes connects to the remote HTTP server with
On Friday, October 16, 2020, 4:48:55 PM GMT+2, Alex Rousskov
wrote:
> tcp_outgoing_address.
OK, I fixed the "local" address issue, but I'm still seeing the same behavior.
I pinpointed one particular request that's failing:
2020/10/16 16:56:37.250 kid1| 85,2| client_side_request.cc(745)
cl
BTW how does Squid decide which IP address to use for "local" here below?
sendRequest: HTTP Server conn* local=
I tried specifying a bind address in http_port and https_port as well as
routing traffic from that address out through just one ppp interface, but that
doesn't seem to change the way
Hi,
I think I found something in the cache.log I posted before.
sendRequest: HTTP Server conn* local=PUB_IPv4_ADDR_3
...
sendRequest: HTTP Server conn* local=PUB_IPv4_ADDR_2
It seems that Squid sometimes connects to the remote HTTP server with either
one of the available addresses on the Squid
On 10/16/20 10:41 AM, Vieri wrote:
> BTW how does Squid decide which IP address to use for "local" here below?
>
> sendRequest: HTTP Server conn* local=
By default, Squid does not make that decision. The OS does it for Squid.
You can try to force Squid to bind to a specific source address for
out
On 10/16/20 3:35 AM, Vieri wrote:
> squid-5.0.4-20200825-rf4ade365f/src/cf.data.pre contains:
> Usage: http_upgrade_request_protocols allow|deny [!]acl ...
>
> The required "protocol" parameter is either an all-caps word OTHER or
> an
> explicit protocol name (e.g. "WebSo
On Thursday, October 15, 2020, 5:28:03 PM GMT+2, Alex Rousskov
wrote:
>> In other words, I do not need to be specific with
>> 'http_upgrade_request_protocols WebSocket allow all' unless I want
>> to, right?
>
> Just in case somebody else starts copy-pasting the above rule into their
> configu
On Tuesday, October 13, 2020, 6:14:18 PM GMT+2, Alex Rousskov
wrote:
> You should probably follow up with Gentoo folks responsible for this Squid
> customization.
Squid 5 now builds and installs perfectly on Gentoo Linux with a few custom
changes to the distro's package installation script.
On 10/15/20 10:08 AM, Vieri wrote:
> On Tuesday, October 13, 2020, 6:14:18 PM GMT+2, Alex Rousskov wrote:
>> You should probably follow up with Gentoo folks responsible for this Squid
>> customization.
> Squid 5 now builds and installs perfectly on Gentoo Linux with a few
> custom changes to th
On Tuesday, October 13, 2020, 3:55:56 PM GMT+2, Alex Rousskov
wrote:
> The beginning of the above log appears to show some unofficial bootstrapping
> steps.
Yes, I was looking into this today and I saw that the actual difference between
a manual build and a Gentoo Linux build is with the f
On 10/13/20 11:21 AM, Vieri wrote:
> I saw that the actual difference between a manual build and a Gentoo Linux
> build is with the following:
> 1) the build fails as mentioned earlier in this thread when running
> Gentoo-specific "configure" scripts. Bootstrapping makes no real
> difference.
>
On 10/12/20 7:35 PM, Vieri wrote:
> I'm compiling on a Gentoo Linux system the tarball taken from
> http://www.squid-cache.org/Versions/v5/squid-5.0.4.tar.gz.
> The build log (failed) is here (notice the call to make -j1):
> https://drive.google.com/file/d/1no0uV3Ti1ILZavAaiOyFIY9W0eLRv87q/view?
I'm compiling on a Gentoo Linux system the tarball taken from
http://www.squid-cache.org/Versions/v5/squid-5.0.4.tar.gz.
The build log (failed) is here (notice the call to make -j1):
https://drive.google.com/file/d/1no0uV3Ti1ILZavAaiOyFIY9W0eLRv87q/view?usp=sharing
If I build from git f4ade36 a
Just a quick test and question.
If I manually create the tests subdirs and run make then I get an error such as:
/bin/sh ../../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -Wall
-Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual -pipe
-D_REENTRANT -O2 -pipe -
On 10/11/20 11:03 AM, Vieri wrote:
> If I manually create the tests subdirs and run make then I get an error such
> as:
>
> /bin/sh ../../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -Wall
> -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Woverloaded-virtual
> -pipe -D_REENTRA
On 10/10/20 1:13 PM, Vieri wrote:
> I'm also getting this other file that can't be copied:
>
> cp ../../src/tests/stub_debug.cc tests/stub_debug.cc
> cp: cannot create regular file 'tests/stub_debug.cc': No such file or
> directory
> make[3]: *** [Makefile:1490: tests/stub_debug.cc] Error 1
>
>
On 11/10/20 6:13 am, Vieri wrote:
> I'm also getting this other file that can't be copied:
>
> cp ../../src/tests/stub_debug.cc tests/stub_debug.cc
> cp: cannot create regular file 'tests/stub_debug.cc': No such file or
> directory
> make[3]: *** [Makefile:1490: tests/stub_debug.cc] Error 1
>
>
I'm also getting this other file that can't be copied:
cp ../../src/tests/stub_debug.cc tests/stub_debug.cc
cp: cannot create regular file 'tests/stub_debug.cc': No such file or directory
make[3]: *** [Makefile:1490: tests/stub_debug.cc] Error 1
Tried "make" and "make -j1", but the error message
On Friday, October 9, 2020, 3:28:01 AM GMT+2, Amos Jeffries
wrote:
> I advise explicitly using -j1 for the workaround build.
Well, I'm running with -j1, but I'm still getting the same error message.
Here's a snippet of the build log:
make -j1
Making all in compat
make[1]: Entering director
> As a workaround, try sequential build ("make" instead of "make -j...")
I removed -j, but I'm still getting a similar error:
cp ../../src/tests/stub_fd.cc tests/stub_fd.cc
cp: cannot create regular file 'tests/stub_fd.cc': No such file or directory
make[3]: *** [Makefile:1402: tests/stub_fd.cc]
On 9/10/20 11:56 am, Vieri wrote:
>> As a workaround, try sequential build ("make" instead of "make -j...")
>
> I removed -j, but I'm still getting a similar error:
>
Not just similar. The same one.
FYI, some make do parallel by default. I advise explicitly using -j1 for
the workaround build. T
On 10/8/20 5:11 AM, Vieri wrote:
> OK, so I'm now trying to compile Squid 5 instead of backporting to V 4, but
> I'm getting this silly error:
> cp ../../src/tests/stub_fd.cc tests/stub_fd.cc
> cp: cannot create regular file 'tests/stub_fd.cc': No such file or directory
> make[3]: *** [Makefile:1
OK, so I'm now trying to compile Squid 5 instead of backporting to V 4, but I'm
getting this silly error:
cp ../../src/tests/stub_fd.cc tests/stub_fd.cc
cp: cannot create regular file 'tests/stub_fd.cc': No such file or directory
make[3]: *** [Makefile:1452: tests/stub_fd.cc] Error 1
I guess it
> To allow WebSocket tunnels, you need http_upgrade_request_protocols available
> since v5.0.4
Thanks for the info.
My distro does not include v. 5 yet as it's still beta, although I could try
compiling it.
Just a thought though. What would the easiest way be to allow websockets
through in v.
On 10/7/20 9:29 AM, Vieri wrote:
>> To allow WebSocket tunnels, you need http_upgrade_request_protocols
>> available since v5.0.4
> What would the easiest way be to allow websockets through in v. 4?
Backport (the essential parts of) v5 changes to v4.
> That is, for trusted domains, allow a dir
On 8/10/20 2:29 am, Vieri wrote:
>> To allow WebSocket tunnels, you need http_upgrade_request_protocols
>> available since v5.0.4
>
> Thanks for the info.
> My distro does not include v. 5 yet as it's still beta, although I could try
> compiling it.
>
> Just a thought though. What would the eas
Hi,
Using Google Chrome instead of Firefox gives me the same result:
Error during WebSocket handshake: Unexpected response code: 200
I'm not sure what to look for in cache.log.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists
On 10/7/20 4:08 AM, Vieri wrote:
> I'd like to allow websockets from specific domains through Squid in
> intercept sslbump mode.
> I am obviously not using on_unsupported_protocol properly.
WebSocket handshake looks like HTTP so on_unsupported_protocol is not
applicable to the WebSocket protocol
I also tried:
on_unsupported_protocol tunnel all
on Squid v. 4.13.
I don't see any denials in the access log.
The only thing I see regarding the URL I mentioned earlier is:
TCP_MISS/200 673 GET https://ed1lncb62202.webex.com/direct? -
ORIGINAL_DST/62.109.225.31 text/html
It is easy to reprodu
Hi,
I'd like to allow websockets from specific domains through Squid in intercept
sslbump mode.
One of the clients reports:
Firefox can’t establish a connection to the server at
wss://ed1lncb62202.webex.com/direct?type=websocket&dtype=binary&rand=1602057495268&uuidtag=C99EG7B6-G550-43CG-AD72-7E
36 matches
Mail list logo
