|
From: Ludwig N. <l-...@us...> - 2006-11-04 12:34:34
|
Pierre Smolarek wrote: > Ludwig Nussel wrote: > > The -interval and -retry options influence how long qstat spends on > > a server. Individual protocols may misbehave though. > > > > > My actual command for my scanner is: > > /qstat/qstat -cfg /qstat/qstat.cfg -P -R -progress -sendinterval 0 > -retry 1 -maxsim 100 -timeout 600 -u -tsw -f qstat.list -raw,game ,, > > Relying on retry and interval (which has a default of 0.5s) isn't enough > it seems. That probably means some protocol misbehaves and clogs the queue with servers that don't time out. The protocol needs to be identified and fixed. > >> more /tmp/list > >> bf2142s 192.168.1.103:29900 > >> hl1 192.168.0.101:27015 > >> sf2 192.168.1.50:20100 > >> cod 192.168.0.2:28960 > >> mhss 192.168.101.47:12300 > >> mhbs 192.168.2.10:12203 > >> css 192.168.2.100:27015 > >> css 192.168.0.102:8080 > >> swb 192.168.2.2:3658 > >> fear 192.168.0.4:27888 > >> hlo 192.168.1.110:2302 > >> > > > > All private addresses with unoffical protocols. I can't reproduce > > with that list. > > > > > This is an example list of servers that will all timeout for the sake of > the later examples demonstrating the timeout functionality on a per scan > basis In this case the attached patch helps. I'll commit it after the 2.11 release. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |