[Dnsmasq-discuss] [PATCH] TCP client timeout setting

Petr Menšík pemensik at redhat.com
Thu Jun 8 20:11:10 UTC 2023


This relies on default settings of tcp tuning values set in system.

I like the change in 50adf82199c362da6c542f1d22be2eeab7481211 adding 
timeout variable check.

But using SO_SNDTIMEO would allow setting it in time units, regardless 
default tcp values. And should be supported also on BSD and in general 
more portable variant. Do you have a reason to use only linux-specific 
variant? 2 tries seems too little if 6 is the default. I wish we had 
some value to tell system just retry (a bit) faster than usual. Haven't 
found that. I would use 3-4 to overcome short connection break at least. 
20-30 seconds should be better default value.

I think the final fix would be making connections non-blocking and in 
parallel, accepting first reply which arrives. This is just small tuning 
to be not so terrible. It has to be sooner than alarm kills the TCP 
client, at least 3 servers should be tried before that happens. I think 
previous default allowed just one, so my changed server report over pipe 
did not happen.

I am also not sure we should log every truncated packet without some 
limit. I think it might lead to denial of service attack. Just stats 
counter should be incremented, which can be watched by polling. Number 
of accepted TCP connections is not counted if I see well. As is not 
number of truncated messages. Would be useful for the service monitoring.

On 26. 05. 23 18:53, Simon Kelley wrote:
>
> Setting TCP_SYNCNT to 2 limits the delay for a non responsive address 
> to about 8 seconds, which is mouch more sensible.
>
> Simon.
>
-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB




More information about the Dnsmasq-discuss mailing list