21

Has anybody ever succeeded in using Scapy on a PlanetLab node (running Fedora 12)?

I am aware of the safe raw socket restrictions, but it seems that I can send packets through Scapy by just setting conf.L3socket=L3RawSocket. As for the reception of packets, I couldn't get Scapy to work, so I just use tcpdump.

TCP and ICMP seem to work:

  • ICMP echo-requests get an echo-reply back
  • ICMP echo-requests with a low TTL get a time-exceeded message back
  • TCP SYN packets get a TCP RST packet back
  • TCP packets with a low TTL get a time-exceeded message back

UDP doesn't:

  • UDP packets to a closed port trigger an ICMP port-unreachable message, but this message doesn't make it back to my sliver. Tcpdump only sees the UDP packet.
  • same thing for UDP packets expiring along their path.

Are there any additional parameters to set in order to receive these ICMP packets?

Ricky Robinson
  • 21,798
  • 42
  • 129
  • 185
  • Do you have root privileges on the node? – RyPeck Sep 25 '13 at 19:39
  • yes, I start python with `sudo python`, otherwise Scapy wouldn't be able to send anything at layer 3 – Ricky Robinson Sep 25 '13 at 19:43
  • Just to be clear - You want Scapy to receive and deal with the ICMP Packets? – RyPeck Sep 27 '13 at 18:34
  • No, I actually prefer collecting timestamps with `tcpdump`. The problem I am experiencing is that when I send UDP packets with scapy, ICMP messages associated to those packets do not make it back to my slice. This means that the mechanism that matches incoming packets to slices, at the node level, isn't able assign these ICMP packets to my UDP packets and deliver them to me. The surprising thing is that I can send TCP and ICMP and get all the associated replies, but with UDP it doesn't work. – Ricky Robinson Sep 28 '13 at 10:20

1 Answers1

1

Not sure if this will help but in my experience in order to receive packets in scapy, you have to use the sr or sr1 method:

sr1(IP(dst="192.168.1.8")/UDP(dport=60112))

Begin emission: ...Finished to send 1 packets. Received 4 packets, got 1 answers, remaining 0 packets

<IP  version=4L ihl=5L tos=0xc0 len=56 id=47804 flags= frag=0L ttl=64 proto=icmp chksum=0x6274 src=192.168.1.8 dst=192.168.1.2 options='' |<ICMP  type=dest-unreach code=3 chksum=0x59eb unused=0 |<IPerror  version=4L ihl=5L tos=0x0 len=28 id=1 flags= frag=0L ttl=64 proto=udp chksum=0x1dfc src=192.168.1.2 dst=192.168.1.8 options='' |<UDPerror  sport=domain dport=60112 len=8 chksum=0xb803 |>>>>

The sr() function is for sending packets and receiving answers. The function returns a couple of packet and answers, and the unanswered packets. The function sr1() is a variant that only return one packet that answered the packet (or the packet set) sent. -Source

Peter Party Bus
  • 2,326
  • 1
  • 14
  • 15
  • yeah yeah, I am well aware of `sr` in scapy. :) It just makes use of some layer-3 functions that are not directly available on PlanetLab. I might have to change some internal settings, but since for rtt measurements scapy's timestamping is not so accurate, I simply use tcpdump. – Ricky Robinson Oct 28 '13 at 14:14
  • Ah I see. I'm sorry I don't think that I am able to answer your question. Or maybe I don't understand the issue, but to my understanding ICMP responses don't directly map to UDP packets because UDP packets have no sequence numbers they are inherently unreliable. So when you say "ICMP messages associated with those packets" I'm not sure what you mean. Your knowledge may way surpass my understanding. – Peter Party Bus Oct 28 '13 at 18:35
  • ICMP messages associated to offending UDP messages. Simply put, a UDP packet (just like a TCP or ICMP packet) might a router to generate an ICMP error message. When it is a TCP packet that generates such error message, I receive it. When it's a UDP packet, I don't. – Ricky Robinson Oct 29 '13 at 14:05