Description of problem: When outgoing packets are filtered with icmp-admin-prohibited, glibc reports wrongly "No route to host". Correct report should be something like "Unreachable - admin prohibited filter" or something like that. Telling the user that there is no route to a host that is clearly routable and available, may give network administrators that do not know this bug headache and sleep trouble. Version-Release number of selected component (if applicable): glibc-2.5-34. Also reproducable on all tested Linux distributions, including for example rhel4 and a few Fedora, Debian and Ubuntu versions, so this is an upstream bug. How reproducible: Always Steps to Reproduce: 1. Filter outgoing packages with icmp-admin-prohibited, for example, on a Linux router, like this: iptables -A SOMECHAIN -s 192.168.42.42 -d www.redhat.com -j REJECT \ --reject-with icmp-admin-prohibited 2. Test, for example with telnet # telnet www.redhat.com 80 Trying 88.221.36.112... telnet: connect to address 88.221.36.112: No route to host tcpdump shows that the message "No route to host" is bogus. # tcpdump -i eth0 -n host www.redhat.com or icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 11:19:52.447684 IP 192.168.42.42.41959 > 88.221.36.112.http: S 821776623:821776623(0) win 5840 <mss 1460,sackOK,timestamp 1732359844 0,nop,wscale 6> 11:19:52.447856 IP 192.168.42.1 > 192.168.42.42: ICMP host 88.221.36.112 unreachable - admin prohibited filter, length 68 3. Compair with ping that does not use glibc in the same way $ ping -c1 www.redhat.com PING e86.b.akamaiedge.net (88.221.36.112) 56(84) bytes of data. From some.router.tld.net (192.168.42.1) icmp_seq=1 Packet filtered Actual results: glibc reports "No route to host". Expected results: glibc should report a correct error message, like "Unreachable - admin prohibited filter" or similar, see the ping example. Additional info: * Somebody reported the same bug in Debian, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421375
The kernel doesn't provide more detailed information. The connect calls fails with EHOSTUNREACH which traditionally results in the error message "No route to host". There is nothing that can be done.