Search squid archive

Re: [EXTERN] Re: getsockopt failures, although direct access to intercept ports is blocked

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Amos,

thank you so much for your reply. I was starting to suspect that the cause was located somewhere outside Squid or its config.

Is this happening at times of unusually high client connections through the NAT?
 Is eCAP processing blocking the Squid worker for all those seconds?

I was only able to reproduce the issue by provoking multiple long-running ecap transactions by curl-ing a certain .deb file. In my little test setup, there was not much of other client traffic (only one client with an open browser). The eCAP Adapter uses poll to wait for the response of a virus scanner on a unix domain socket, so yes, I assume this blocks the worker. I will probably have to look into Async operation with regard to this issue.

That part is likely to be the issue recently worked around by

Thanks for the patch, I will definitely try it, this will already go a long way to help mitigate the problem.

Kind regards,
Andreas

Zitat von Amos Jeffries <squid3@xxxxxxxxxxxxx>:

On 24/02/22 12:05, Andreas Weigel wrote:
Hi everyone,

I had the following issue with Squid in Transparent Mode (and SSL Interception in mode splice). It is working as expected, however after multiple long-running (talking about several seconds) anti-virus ecap-Processes have finished, I *sometimes* get the following in the log:

2022/02/23 14:56:40.668 kid1| 5,2| src/comm/TcpAcceptor.cc(224) doAccept: New connection on FD 21 2022/02/23 14:56:40.668 kid1| 5,2| src/comm/TcpAcceptor.cc(312) acceptNext: connection on local=[::]:2412 remote=[::] FD 21 flags=41 2022/02/23 14:56:40.668 kid1| 89,5| src/ip/Intercept.cc(405) Lookup: address BEGIN: me/client= 192.168.180.1:2412, destination/me= 192.168.180.10:48582 2022/02/23 14:56:40.668 kid1| ERROR: NF getsockopt(ORIGINAL_DST) failed on local=192.168.180.1:2412 remote=192.168.180.10:48582 FD 37 flags=33: (2) No such file or directory 2022/02/23 14:56:40.669 kid1| 89,9| src/ip/Intercept.cc(151) NetfilterInterception: address: local=192.168.180.1:2412 remote=192.168.180.10:48582 FD 37 flags=33 2022/02/23 14:56:40.669 kid1| ERROR: NAT/TPROXY lookup failed to locate original IPs on local=192.168.180.1:2412 remote=192.168.180.10:48582 FD 37 flags=33


These can happen if the NAT table entries expire or otherwise get dropped by conntrack between the client initiating TCP SYN and Squid accept(2) receiving the connection.

Your config looks good to me and the lack of regularity indicates the issue is likely this type of transient state situation. Is this happening at times of unusually high client connections through the NAT?
 Is eCAP processing blocking the Squid worker for all those seconds?


2022/02/23 14:56:40.669 kid1| 5,5| src/comm/TcpAcceptor.cc(287) acceptOne: non-recoverable error: FD 21, [::] [ job2] handler Subscription: 0x55edac3d08d0*1

Sometimes, this only appears on on of the two interception ports, sometimes on both. After that, the squid worker does not poll the intercept listen port any longer, i.e. stops working.

That part is likely to be the issue recently worked around by <http://www.squid-cache.org/Versions/v6/changesets/squid-6-9fd3e68c3d0dfd6035db98ce142cf425be6c5fc1.patch>


Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users



_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux