On 11/19/18 6:06 PM, Paul Hoffman wrote:
I am creating a testbed for DNS resolvers to test how they pick
authoritative servers based on differences in return times of messages.
The basic design is:
resolver -> router/ -> servers
under mangler
test
The mangling I want in the router would add different amounts of delay
based on the address of the target server.
Based on the earlier message, I think I can see a way forwards with
iptables and tc, and possibly with just tc. I'll experiment with those
and come back here if I need more. Thanks in advance!
You could queue the packet(s) to a userspace using NFQUEUE and then have
your external program sit on them for the desired time before submitting
them back for continued processing.
That would also give you a means to set knobs and switches on your
behaviors that are outside of netfilter's normal purvue.
A program that checks now-vs-packet-time and approves those packets
after the minimum delay shouldn't be to difficult to write.
Since the traffic depth for that use-case is pretty shallow (not a lot
of packets expected to be stuck in the approval queue for too long) you
probably won't hit the queue limit and get into packet dropping territory.
Arbitrary delays on the main logic path are probably not a thing that
would ever be added as it would back up the whole packet queue for all
the other packets as well and otherwise risk un-loved packet reordering.
More simply, REDIRECT all the various packets to a local socket where a
priviliged relay daemon would read them header-and-all as a RAW packet,
then reassert that packet header-and-all after a fixed delay. Look at
how dhcprelay works for a related example.
But putting a delay in the actual filter path isn't probably attractive
to the general public.
