Re: libpcap and tc filters

[Adam Katz <adamkatz0 () gmail com>]

First of all, thanks for the quick reply.

Well, I am using Linux, sorry for not mentioning that explicitly. tc is the
built in linux utility for (among other things) traffic shaping... it's a
pretty useful piece of software. I use it to create three output queues on
eth0 with a scheduler that selects which of them to dequeue. I immediately
though of the explanation you gave me and imagined pcap might bypass some of
the stack but it doesn't seem that way as packets sent with pcap do show up
in those queues I created, they're only not classified correctly and end up
in the default queue.

If pcap was completely bypassing the stack, I imagine i would not have seen
the packets in the queue at all.


On Sun, Jun 5, 2011 at 5:15 AM, Aaron Turner <synfinatic () gmail com> wrote:

> 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.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.