Re: flooding an embedded device with isic and tcpreplay causing different results

[Andres Riancho <andres.riancho () gmail com>]

wlet,

On Wed, Mar 25, 2009 at 9:37 AM, wlet <wlet () gmx net> wrote:
> Hi everybody,
>
> I'm trying to force a reload of an embedded SOHO router/NAT Gateway.
> This is what I've done so far:
> I flodded the device with isic and captured the packet flow. About 60s
> later the device rebooted (obviosly because of a memory overload). I
> stopped the packet capture, rebooted the SOHO and fired the pcap with
> tcpdump again to the SOHO.
> This behavior is reproducible - I did that scenario alt least 5 times.
>
> So, now I wondering why the tcpreplay attack don't f*** up the SOHO.
> I've 2 theories:
> 1. The tcpdump isn't complete because of "dropped by kernel" packets -
> and these are the packets which are forcing the reload
> 2. tcpreplays performance is weaker than that of isic - this causes less
> networkload and that is not enough to grill SOHOs mem.
>
> these are the statistics of isic:
> root@machine:/root# isic -s rand -d 192.168.1.1 -r 1337 -F 100 -I -V
>
> ..
> ..
>  284000 @ 5109.4 pkts/sec and 3321.4 k/s
>
> ^C
>
> Caught signal 2
>
> Used random seed 1337
>
> Wrote 284003 packets in 69.00s @ 4116.05 pkts/s
>
> and these are the captured packets from tcpdump:
> root@machine:/root# tcpdump -i eth0 -n -s0 -w /root/crash.pcap
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
> 65535 bytes
> ^C
> 268004 packets captured
>
> 283995 packets received by filter
>
> 15991 packets dropped by kernel
>
> there is the output of tcpreplay (replaying the captured *.pcap)
> root@machine:/root# tcpreplay -i eth0 crash.pcap
> sending out eth0
>
>
> processing file: crash.pcap
>
>
> Actual: 268004 packets (180061091 bytes) sent in 74.45 seconds
>
>
> Rated: 2418422.2 bps, 18.45 Mbps/sec, 3599.59 pps
>
>
>
>
>
> Statistics for network device: eth0
>
>
>        Attempted packets:         268004
>
>
>        Successful packets:        268004
>
>
>        Failed packets:            0
>
>
>        Retried packets (ENOBUFS): 0
>
>
>        Retried packets (EAGAIN):  0
>
>
>
> As you can see at the statistic of tcpreplay and isic, that tcpreplay
> sends out about 500pkt/s less than isic.
>
> Do you have an idea why my SOHO do not break down while pounding it with
>  tcpreplay?

In my experience, tcpdump won't just "miss packets"; so I'm thinking
that isic may be lying: the tool might thing that it sent a packet,
and the packet never actually left the interface.

If I were you, I would connect "machine", SOHO, and a new "machine-2"
to a hub, and capture the traffic at both "machine" and "machine-2".
After that, you could perform a pcap diff, to check whats really going
on. If that fails, try removing the -s0, and check if tcpdump gets all
the packets... that could prove that tcpdump is "failing at high
speeds", which is really unlikely.

Cheers,
> cu
>
> wlet
>
> ------------------------------------------------------------------------
> This list is sponsored by: InfoSec Institute
>
> Tired of using other people's tools? Why not learn how to write your own exploits? InfoSec Institute's Advanced 
> Ethical Hacking class teaches you how to write stack and heap buffer overflow exploits for Windows and Linux. Gain 
> your Certified Expert Penetration Tester (CEPT) cert as well.
>
> http://www.infosecinstitute.com/courses/advanced_ethical_hacking_training.html
> ------------------------------------------------------------------------



-- 
Andrés Riancho
http://www.bonsai-sec.com/
http://w3af.sourceforge.net/

------------------------------------------------------------------------
This list is sponsored by: InfoSec Institute

Tired of using other people's tools? Why not learn how to write your own exploits? InfoSec Institute's Advanced Ethical 
Hacking class teaches you how to write stack and heap buffer overflow exploits for Windows and Linux. Gain your 
Certified Expert Penetration Tester (CEPT) cert as well.

http://www.infosecinstitute.com/courses/advanced_ethical_hacking_training.html
------------------------------------------------------------------------