I've been working on code nearly identical to yours in purpose
recently. I need to simulate a slower device (slower than 10Mbps) for
some research that I'm doing on how TCP reacts to window size
alterations in various network conditions. I actually got my code
working on Friday morning - probably right before you posted your
message.
Anyhow, I came across the same problem you had (ie: redirecting the
netif_rx call). I decided on a somewhat different solution... (which
doesn't require changes to any drivers)
netif_rx hands packets off to net_bh which distributes them to the
various handlers (ie: ip_rcv). What I do is I add a "struct
packet_type" which has the pointer to my handler function (using
dev_add_pack). I then need to remove the "ip_packet_type" struct
(ip_output.c) from the list of packet types. This could be done
easily enough using the dev_remove_pack call, if "ip_packet_type" was
not declared static [preferred solution]. But "ip_packet_type" is
static so I look through the list of handlers looking for the one with
"ip_rcv" and remove that (keeping a reference to it so that I can
restore it later) ["temporary" hack solution].
With this accomplished my handler gets all IP traffic (which is all
that I am concerned with). Packets are delayed as necessary and then
passed on through ip_rcv. This procedure can be easily extended for
non-IP traffic.
One could also accomplish the same thing by testing for
net_shaper_rx_hook and redirecting packets from within net_bh.
However, I like how the normal handlers are generalized and wouldn't
want to put in tests or calls for specific handlers.
On a related topic, another thing I've been working on is limiting
transmission rates as is done by the shaper. I've had some problems
with the shaper and I wanted code for controlling sending and
receiving to be integrated. My preferred solution for this is to
implement it as a queue discipline. My code for this is currently in
prototype state, though the idea does work.
Regards,
Michal Ostrowski
mostrows@styx.uwaterloo.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html