tomahawk-devs — Mailing list for tomahawk developers/contributors

[Tomahawk-devs] Traffic Generation Problems

[Steve S. <ss...@ll...>]

Hello,

We're having some problems with tomahawk correctly replaying our pcap 
file.  We have a pcap file with 9 packets in it, 6 in one direction, and 
3 replies in the other, so only 2 addresses total.  It's a very simple 
pcap we've been using for debugging.

The problem is that only the primary interface spews out any packets. 
It's not a hardware/OS issue, since any interface works, so long as it's 
specified by "-i" and not "-j".

In the SendPackets function, I've noticed that on/around line 1436 of 
tomahawk.c, we check the handler to see if it's in "attacker" mode, and 
if so, writes out to the primary interface.  I put printf statements in 
each conditional branch to demarcate when each was happening, and it 
appears that h->attacker is always set to 1, which means that the 2nd 
interface never gets to fire.

I see that in RecvPackets, there is code to "switch" modes, but it never 
seems to trigger.  Also, it seems that every packet in the trace has an 
attacker flag, but this is never referenced for updating, at least as 
far as I can tell.  I'm still working on understanding the code, but I 
was hoping someone else had run into this and may be able to shed some 
light on this - maybe we could work at rolling out a Tomahawk 1.1 :)

Any thoughts/fixes?  Thanks!

Steve Suppe

[Tomahawk-devs] Match failures due to ethernet trailers?

[cdb <cd...@ev...>]

Anyone notice a problem with spurious match failures on short packets due to
comparison of the ethernet trailer?  I was running test.pcap through a linux
VM in VMware running snort_inline.  The packets were running out eth0,
through the bridge, and arriving on eth1 but were not counted as having
arrived by tomahawk.  The received counter printed by tomahawk at the end of
the run was incremented, but the behavior of tomahawk was as if they never
arrived.

A little investigation showed that the failure was due to a failed match in
PacketEquals, with a difference at the very end of the data.  I added a
small hack to PacketEqual to write out b1 and b2 in pcap format to better
see the reason for the match failures.  In the PCAP, the packets are in
groups of two, representing the contents of b1 and b2 respectively.  Notice
the difference is in the trailer.  In the final memcmp, should the
comparison length be min(iph->tot_len, len)?  That patch works for me.  Is
the correct approach or something wrong with this test case?

[Tomahawk-devs] packet capture

[allan a. <im...@ya...>]

hello,

at this time, i have not figured out how to capture
packets from a live network. could someone please give
me some pointers. i'm using a linux system. i'm sort
of new to linux as well so please be gentle:)

thanks so much!