Hi,
I'm trying to use ip_queue (and the QUEUE target) to delay packets.
In a small test program, "ipdelay", I limit the rate of packets
being NF_ACCEPT:ed. This works fine until I enable (by inserting
the iptable_nat module) NAT. Then the kernel starts loosing
packets in streams/connections in which the first packet has
arrived but not yet has left the kernel. For example, if I send 10
UDP-packets with 100 ms in-packet time, and configure my ipdelay
program to sleep 500 ms between each ip_set_verdict(/../ NF_ACCEPT /../);
the first packet will get through, but packet number two to six
will be lost. Seven to ten gets through.
Because all connections are being tracked (not only those being NATed),
you get this behaviour for all connections.
What you can see is that for the first packet, and the packets 2-6
in my example, you get a new "conntrack" entity. resolve_normal_ct()
only seems to scan confirmed connections. Packets which arrived before
the first packet has been confirmed will be dropped when they come to
__ip_conntrack_confirm().
On the conceptual level, I don't really understand why it works this
way. Can this behaviour be considered to be a bug?
Regards,
Mattias
