3

I'm writing a simple UDP chat server in Python 2.7 on Linux 2.6.38.

How can ICMP error messages be read that a host(client) receives when it sends UDP segments to say, an unreachable server?

I tried

sockFd.setsockopt( socket.IPPROTO_IP, socket.IP_RECVERR, 1 )

But socket.IP_RECVERR isn't defined in socket module.

I tried using a timeout on sockFd.recvfrom and doing sendto a second time but that didn't help. Is there an API to read the ICMP errors received by the host?

crk
  • 617
  • 1
  • 8
  • 12

2 Answers2

2

The question is a bit old but I'll answer it since I've faced the same problem.

The constant IP_RECVERR is defined in the "IN" module, so the next statement should do the job:

import socket
import IN
sockFd.setsockopt( socket.IPPROTO_IP, IN.IP_RECVERR, 1 )
Oleg Andriyanov
  • 5,069
  • 1
  • 22
  • 36
-2

The ICMP errors are basically useless. If you receive an error, that doesn't assure that the other end didn't receive the packet. If you don't receive an error, that doesn't ensure that the other end did receive the packet. So there is almost no reason to ever bother doing this.

If you tell us more about why you think you need to do this, we can tell you what you should do instead.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • +1. Also, not all hosts will send an ICMP. NATs and Firewalls may drop packets silently as well. – selbie Feb 23 '13 at 04:45
  • I've setup iptables on the server such that it sends back ICMP host unreachable message for any UDP message it receives. So, I was trying to verify this behavior on the client side. – crk Feb 23 '13 at 09:46
  • 1
    That didn't answer the original question. How do you cope with the lack of `socket.IP_RECVERR`? – Ricky Robinson Nov 05 '13 at 16:55
  • @RickyRobinson You don't need them -- they would be useless if you got them. Why do you think you do? – David Schwartz Nov 07 '13 at 01:16
  • Sure sure, but what if I really wanted to receive such messages? For example, traceroute, when using UDP probes, triggers an ICMP port-unreachable message at the destination. – Ricky Robinson Nov 07 '13 at 09:14
  • 1
    @RickyRobinson That's way outside the scope of this question. But in that case, you have a raw socket open anyway, so you can listen for raw ICMP errors. – David Schwartz Nov 07 '13 at 16:22
  • @DavidSchwartz You don't have to use raw socket to trace route using UDP probes. This is how linux traceroute utility works by default. – Oleg Andriyanov Dec 16 '15 at 10:21
  • @DavidSchwartz: this is necessary to stop battering the other side (and the Internet) with pointless packets when the other side is explicitly saying they don't accept them. And/or it is necessary to tell user something better than "hey, it doesn't go through, but I have no idea why" (and giving the best possible explanation is a Really Good error reporting practice). Overall, ICMP is there for a reason - and usually for a Damn Good Reason. – No-Bugs Hare Oct 14 '16 at 10:14
  • @No-BugsHare It's not necessary. You have to stop battering the other side with pointless packets even if the other side doesn't explicitly say it won't accept them. If you need the ICMP errors to do the right thing, you're already failing. – David Schwartz Oct 14 '16 at 15:46
  • @DavidSchwartz Sure, but with ICMP I will stop doing it earlier. Regardless of ICMP, we need to have some kind of retransmits - and for a handshake we need to have at least 5-10 of them to be somewhat sure that the problem is persistent rather than transient; however, with ICMP handled I have a good chance to skip all the retries and stop battering the Internet after the first one (and tell my user about it earlier too - which can improve user experience etc.). In addition, as I've said - there is also error reporting, which is a Big Thing for anybody using our programs. – No-Bugs Hare Oct 15 '16 at 08:22
  • @No-BugsHare It's generally considered a mistake to stop earlier on the basis of ICMP because there's generally no way you can confirm that the source of the ICMP datagram is actually on the path. Best practice is to ignore ICMP errors. You could use it to provide a better error message if you independently decide to generate an error message for other reasons, but that's about it. – David Schwartz Oct 15 '16 at 19:32
  • @DavidSchwartz DoS via an ICMP spoof? Could happen, but for vast majority of applications out there the attack doesn't make much sense (somebody attacking my Skype with a rogue ICMP packet getting through all the ingress/egress filters just to break my Skype call? Extremely unlikely, not to mention that it will be merely equivalent to TCP RST attack). So while I agree that there are apps where it can be an issue - I don't see it as universal (by far). And as you've already agreed - there is error reporting, so we already agreed that there is a good reason to get those ICMPs ;-). – No-Bugs Hare Oct 18 '16 at 05:40