Its been awhile since I could try to simulate a good use case.
In short its peeling an onion and just exposed a whole bunch of
bad factors. There are other issues in these gateways. They do a
lot of stuff that has no customer tuning or even visibility.
This confounds any honest testing. If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If you want to experiment with strategies, and your C is OK, it should
be quite easy to do. Look at allocate_rfd() in src/forward.c. That has
two bits of code, the first makes a new random socket, and if that
fails (kernel resource issues, or maximum
On 22/04/15 03:49, Eric Luehrsen wrote:
I would like to propose that DNSMASQ move the port every 6-60
seconds random per port# and also DNSMASQ move client ports when so
many requests have processed (max-concurrent reused or %10 of cache
or random again?). This will keep its profile on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/04/15 03:49, Eric Luehrsen wrote:
A while ago, DNSMASQ changed to roaming client ports to prevent
from being a sitting duck for [various response] attacks. Each new
request forward is assigned a new client return port. This is a
good.
A while ago, DNSMASQ changed to roaming client ports to prevent from being a
sitting duck for [various response] attacks. Each new request forward is
assigned a new client return port. This is a good. Further, the minimum port in
the selection of ports can be pushed away from extended low-range
