netdev - Re: libpcap and tc filters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA0qwj7cH8Ah69fBMkXpGkwG77TH_ZqMhKwj-Cc8Vc=F5c9SSw@mail.gmail.com>
Date:	Mon, 4 Jul 2011 15:37:17 +0300
From:	Adam Katz <adamkatz0@...il.com>
To:	jhs@...atatu.com
Cc:	netdev@...r.kernel.org
Subject: Re: libpcap and tc filters

here's a more concrete example:

An example configuration:

	sudo tc qdisc add dev eth1 root handle 1: prio priomap 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2
	sudo tc qdisc add dev eth1 parent 1:1 handle 10: pfifo 	
	sudo tc qdisc add dev eth1 parent 1:2 handle 20: pfifo
	sudo tc qdisc add dev eth1 parent 1:3 handle 30: pfifo

	sudo tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip
dport 22 0xffff flowid 1:1
	sudo tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip
sport 22 0xffff flowid 1:1
	sudo tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip
dport 80 0xffff flowid 1:2
	sudo tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip
sport 80 0xffff flowid 1:2

I then used scp to copy a small file between computers while capturing
with wireshark:

http://dl.dropbox.com/u/3237005/port22example.pcap

and later I replayed the same capture using tcpreplay.
When using scp, the packets once again ended up where they should be
(1:1 in this configuration). With tcpreplay they ended up in the
default 1:3

On Mon, Jul 4, 2011 at 3:06 PM, jamal <hadi@...erus.ca> wrote:
> On Mon, 2011-07-04 at 15:00 +0300, Adam Katz wrote:
>> Ok, I just tried this:
>>
>> I've opened www.example.com using a browser while capturing with
>> wireshark. TC placed all port 80 packets into the 1:1 as required. I
>> then physically plugged the nic to a different socket, one that isn't
>> connected to the internet (i did this so I wont get any server
>> responses to the packets i'm sending) and then I replayed the capture
>> of me opening www.example.com
>>
>> The second time, none of the packets ended up in 1:1 - they all went
>> to the default class despite being the EXACT same traffic.
>>
>
> Please post a small sample of the tcpdumps and the tc rules you used.
>
> cheers,
> jamal
>
>



On Mon, Jul 4, 2011 at 3:01 PM, Adam Katz <adamkatz0@...il.com> wrote:
> Ok, I just tried this:
>
> I've opened www.example.com using a browser while capturing with
> wireshark. TC placed all port 80 packets into the 1:1 as required. I
> then physically plugged the nic to a different socket, one that isn't
> connected to the internet (i did this so I wont get any server
> responses to the packets i'm sending) and then I replayed the capture
> of me opening www.example.com
>
> The second time, none of the packets ended up in 1:1 - they all went
> to the default class despite being the EXACT same traffic.
>
> On Mon, Jul 4, 2011 at 2:11 PM, jamal <hadi@...erus.ca> wrote:
>>
>> Capture tcpdump for both scenario that works and one
>> that doesnt.
>> Make sure the filters match your failing scenario.
>>
>> cheers,
>> jamal
>>
>> On Mon, 2011-07-04 at 10:38 +0300, Adam Katz wrote:
>>> Hi Everyone
>>>
>>> I'm sorry for littering the mailing list with this question, but no
>>> other place could help me..
>>>
>>> I'm attempting to use tc to shape traffic sent using libpcap, I'm
>>> doing this for a research project. I have a classful scheduler with
>>> several classes, to this scheduler I attach a few filters based on
>>> destination tcp ports.
>>>
>>> My problem is this: When sending packets using a normal userland
>>> socket, the filters work and I see the appropriate traffic entering
>>> the right class. BUT when sending packets with libpcap, all packets
>>> end up in the scheduler's default band as if the filters simply refuse
>>> to work.
>>>
>>> Can anyone suggest a solution?
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@...r.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html