scapy sr1 ICMP response

2
votes

What I do:

  1. Use scapy to send/receive a UDP-Datagram from a server (192.168.1.2)
  2. The server replies with a UDP-Datagram to the source port of the received UDP-Datagram

This works fine, however, the client always sends a ICMP "Destination unreachable (Port unreachable))" after the datagram was successfully received. Scapy command run on the client:

pkt = IP(dst='192.168.1.2')/UDP(sport=49000, dport=50991)/Raw(udp_command_bytes)
rec = sr1(pkt)

I have a POXIS based application using sockets that does the same thing and there is no ICMP response sent. What is the problem with the above scapy command? Shouldn't it listen on port 49000 for the response?

1
networkingudpportscapy
Hi ! What do you mean by “the client sends a ICMP... destination unreachable”: do you see this in the logs or is it an extra packet seen through tcpdump/wireshark ? Do you see an answer packet after the sr1? (rev not none) – Cukic0d
Hi. I get an answer packet after sr1. and yes, the extra ICMP packet is seen on wireshark. I don't really understand why, but I am pretty sure that it has to do with the listening port on the host sending the UDP-Datagram beeing closed to soon or something.? – user3482407
You could try setting it to low-level mode, using Ether()/IP().... then sendp() instead of send() – Cukic0d
I tried that already, still the same result. I also tried different ports... – user3482407

1 Answers

2
votes

Scapy is not meant to 'listen' on the UDP port but rather 'sniff/spy' on it (cf. https://scapy.readthedocs.io/en/latest/introduction.html#scapy-decodes-it-does-not-interpret)

This means that the running TCP/IP stack is not aware that scapy is also receiving the packets, therefore, if it does not see a consumer, depending on your stack configuration (cf. https://serverfault.com/questions/522709/disable-icmp-unreachable-replies), it can decide to send an indication that the UDP packet did not reach a consumer (your extra ICMP message containing the UDP port unreachable indication).

As a workaround, you can simply open a shell and do:

netcat -lkfu 49000

This will ensure that your system has a consumer for this port and you can still use scapy to handle all the incoming traffic.