Re: libpcap and tc filters

[Aaron Turner <synfinatic () gmail com>]

On Sat, Jun 4, 2011 at 2:38 PM, Adam Katz <adamkatz0 () gmail com> wrote:
> Hi, all!
>
> I'm trying to use tc to shape traffic sent using libpcap (actually
> tcpreplay, which is based on libpcap). I'm doing this for a research
> project.
>
> i have a simple prio scheduler with a default band 2:
>
> tc qdisc add dev eth0 root handle 1: prio priomap 2 2 2 2 2 2 2 2 2 2 2 2 2
> 2 2 2
>
> with two filters attached to it:
>
> tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 80
> 0xffff flowid 1:1
> tc filter add dev eth0 protocol ip parent 1: prio 2 u32 match ip dport 443
> 0xffff flowid 1:2
>
> (don't mind the port numbers, they're here just for the example)
>
> When sending actual traffic, the filters work and I see the appropriate
> traffic entering the right class. BUT when replaying captured traffic (with
> the appropriate port numbers)  over eth0 using tcpreplay, all packets end up
> in the default band 2 as if the filters simply refuse to work.

No idea what "tc" is or what platform you're using (guessing Linux by
the "eth0"), but in my experience, sending traffic via
tcpreplay/libpcap is done in a way which avoids all processing by the
sending host's IP stack.  For example, tcpreplay skips outbound
firewall rules and traffic sent is never "seen" by the sending host,
even if the destination MAC/IP is for that host.

Again, this is platform dependent, but from what I've seen on most, if
not all platforms that people use tcpreplay on it's true.


-- 
Aaron Turner
http://synfin.net/         Twitter: @synfinatic
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin
"carpe diem quam minimum credula postero"
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.