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

[Andreas Weigel]

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 at treenet.co.nz>:

> 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users