6

I'm using Scapy to replay some dumped packets in which I change the TTL value. I've been getting very odd results even with TTL=1.

When I run my test hours apart from each other, I can get from roughly 40% to 95% of packets replied to with an ICMP time-exceeded message. Then I can recursively replay unanswered packets and get each time more or less the same percentage of answered packets as before.

Why is that?

I've been sending packets with an interval of 0.1 seconds between each other. This should be ok, right? My timeout value is 10s, which should be very conservative.

What's wrong here?

Ricky Robinson
  • 21,798
  • 42
  • 129
  • 185

1 Answers1

5

What you're saying is essentially you can only test for so many unreachable hosts in a given span of time. One possible reason: many routers rate-limit ICMP messages.

It is much better to test for a ping success to a host before doing something else; this way you have positive confirmation of reachability. The downside is MS Windows blocks pings by default.

If you can't ping first, then you'll need to increase the time between your probes, or raise the ICMP unreachable rate on the router that is returning the ICMP messages.

EDIT:

Based on the comments, it looks like you're hitting a wall for scapy's ability to process traffic. I have improved throughput in the past by sending with scapy and spawning tcpdump in the background to receive traffic.

Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
  • ICMP rate-limiting was also my guess, but then today I tried to send everything again with an inter-packet interval of even 5 seconds, and I still didn't get a reply for at least 6-7 packets out of my 50 (small test). I'm using the `sr` function in Scapy. So I thought I'd pass it one packet at a time and then pause for 1 second. Well, this time *every* single packet gets answered. I guess it's a problem with the implementation of `sr`. – Ricky Robinson Jun 06 '12 at 14:50
  • 1
    I have seen similar issues with `scapy`, it's dog-slow for sending / receiving traffic; on one project I actually started using `tcpdump` as a background processes that wrote to a `.pcap` file and then parsed the file in `scapy` to see whether I got the correct response. – Mike Pennington Jun 06 '12 at 14:59
  • I see. Do you know any alternatives to scapy's `sr` function? I really just need to send packets with a modified TTL value and pair them up with the corresponding ICMP message. It looked /so/ simple in Scapy, but calling `sr` for each packet takes ages. – Ricky Robinson Jun 07 '12 at 11:51
  • In the end I tried with tcpdump to capture incoming icmp packets to also solve some other issues. Sending with scapy's `send` means, as opposed to what happens with `sr`, that no timestamp is added to the sent packets. Therefore I couldn't extract RTTs values. Do you know of a way to do this? – Ricky Robinson Aug 22 '12 at 17:36
  • Hi Mike, I'm looking at this issue again and actually ICMP rate-limiting should not affect the generation of `time-exceeded` messages, which is what I'm concerned with. It only limits ICMP `unreachable` messages. Therefore there must be something else interfering with the loss of such packets. Hmm... – Ricky Robinson Jan 08 '13 at 11:06
  • oh yeah, sure I did. :) It's just that this loss rate varies greatly depending on the router I target. That's why I thought at first that it might be related to ICMP rate limiting. I will look into this! – Ricky Robinson Jan 08 '13 at 11:51