Re: Some persistent error messages in linux

JLarmour@origin-at.co.uk writes:

>At 10:49 04/11/96 +0100, hhoff@modern-video.de wrote:
>>some time ago you posted on squid-users about squid generating lots
>>of repeating error messages on Linux. I have the same problem on
>>a Linux 2.x machine and was wondering if you've gotten any hints
>>on this..
>
>N.B. I'm putting this on the list.
>I've now investigated it a little, and I know why it happens now, whenever
>source_ping is defined in squid.conf, squid sends a test packet to the
>source on udp port 7 (echo). However some sites presumably have acl'ed
>routers/filtering that instead return an icmp port unreachable message, so
>squid complains.
>
>I thought I had a cunning plan of using the icmp error in other ways, but I
>made a bad logical flaw. Not enough coffee...
>
>Would it be possible for ICMP port unreachables to be dropped if it is not
>from a neighbor/sibling? Also when this happens, a single ICMP port
>unreachable causes two separate errors, so perhaps one of them should have
>its log level toned down, probably the "icpHandleUdp error_receiving" one.
>
>I'm not sure (and in fact doubt) if this also explains the "comm_udp_recv:
>recvfrom failure: Operation not supported on transport endpoint" messages,
>so if anyone knows where this does come from, could they post why?

This seems to me to be a "quirk" with Linux. I have not seen any
other OS generate read(2) errors from ICMP messages.

I recently added this hack which prevents the messages from being printed,
but doesn't prevent them from actually happening:

icpHandleUdp()
    ...
    if (len < 0) {
#ifdef _SQUID_LINUX_
        /* Some Linux systems seem to set the FD for reading and then
         * return ECONNREFUSED when sendto() fails and generates an ICMP
         * port unreachable message. */
        if (errno != ECONNREFUSED)
#endif
            debug(12, 1, "icpHandleUdp: FD %d recvfrom: %s\n",
                sock, xstrerror());
        return;
    }

Duane W.
Received on Tue Nov 05 1996 - 10:00:37 MST