On Sat, Jun 4, 2011 at 2:38 PM, Adam Katz <[email protected]> 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.
