no. I'm talking only about changing the filters so they'll see ALL the
traffic, not changing the source code.

anyway, it failed on yet another ubuntu 10.04 machine but worked on a
newer ubuntu 11.04 (2.6.38-8) and of course on the fedora box
mentioned earlier.

My guess is that something was fixed very recently in the kernel...
the ubuntu 10.04 box uses 2.6.32-32

But we should see what the netdev guys say about this, this is exactly
their area of expertise (Jamal from the netdev mailing list was the
one who pinpointed the problem when I asked there).


On Tue, Jul 5, 2011 at 8:00 PM, Aaron Turner <synfina...@gmail.com> wrote:
> Just so I'm clear- you're saying using ETH_P_IP works with tc on FC15
> but not ubuntu 10.04?
>
> Thanks
>
> On Tue, Jul 5, 2011 at 9:58 AM, Adam Katz <adamka...@gmail.com> wrote:
>> well, that'll have to wait.
>> Currently i've wasted more time than I had on this issue because the
>> suggested fix doesn't seem to be working on my ubuntu 10.04 box. I can
>> however confirm it works on a fedora core 15 machine, maybe because of
>> a newer kernel (2.6.32-32 vs 2.6.38.6-26.rc1)
>>
>> On Tue, Jul 5, 2011 at 7:24 PM, Aaron Turner <synfina...@gmail.com> wrote:
>>> On Tue, Jul 5, 2011 at 6:26 AM, Adam Katz <adamka...@gmail.com> wrote:
>>>> I've asked on netdev and thanks to Jamal, I now have a solution. You
>>>> can see the answer here:
>>>> http://marc.info/?l=linux-netdev&m=130987003108156
>>>>
>>>> but just in case (and to help future googlers of this issue) i'll
>>>> summarize the problem and solution here:
>>>>
>>>> tcpreplay opens its sending socket using the "ETH_P_ALL" option. This
>>>> means that tc filters that apply only to ip packets are skipped:
>>>>
>>>> sudo tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip
>>>> dport 22 0xffff flowid 1:1
>>>>
>>>> but if the rule is changed to scan all traffic:
>>>>
>>>> sudo tc filter add dev eth0 protocol all parent 1: prio 1 u32 match ip
>>>> dport 22 0xffff flowid 1:1
>>>>
>>>> it should work, but it will slow down the filter.
>>>>
>>>> A somewhat cleaner (and more long-term) solution is to provide a user
>>>> level option in tcpreplay to open its socket using ETH_P_IP. This will
>>>> limit the socket to send only ip traffic but will allow such rules to
>>>> work.
>>>>
>>>> On that note, I think that my trouble with tc can also apply to
>>>> problems people have been having with iptables with tcpreplay/libpcap
>>>> injected traffic.
>>>
>>> Interesting!
>>>
>>> You could try editing src/common/sendpacket.c sendpacket_open_pf()
>>> around line 658 and change it to ETH_P_IP.  I'd be curious to hear if
>>> that actually fixes this problem.  If so, then maybe I can make that
>>> an option in a future version.
>>>
>>>
>>> --
>>> 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"
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> Tcpreplay-users mailing list
>>> Tcpreplay-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
>>> Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
>>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Tcpreplay-users mailing list
>> Tcpreplay-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
>> Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
>>
>
>
>
> --
> 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"
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Tcpreplay-users mailing list
> Tcpreplay-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
> Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
>

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Tcpreplay-users mailing list
Tcpreplay-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcpreplay-users
Support Information: http://tcpreplay.synfin.net/trac/wiki/Support

Reply via email to