Re: sent an invalid ICMP type 11, code 0 error to a broadcast: 0.0.0.0 on lo?

From: Michael Tokarev (mjt_at_tls.msk.ru)
Date: 07/07/05

  • Next message: Ingo Molnar: "Re: Realtime Preemption, 2.6.12, Beginners Guide?" 
    Date:	Thu, 07 Jul 2005 17:05:31 +0400
To: linux-os@analogic.com

    Richard B. Johnson wrote:
    []
    > If you ping an IP address on your computer, the traffic will go
    > through lo. However, I think that the IP address shown is
    > the result of an instrumentation error because it is impossible
    > to put, for instance your 192.168.1.1, through a 127.0.0.0 network,
    > the ONLY route through lo. This shows that 'local' traffic bypasses
    > the lo route filtering altogether. You can verify this by
    > deleting the lo route altogether, you can still ping the local
    > addresses.

    Hmm. I can't parse this. ;)
    Well, I can bring loopback down, but in this case I can't even
    ping my local IP addresses anymore, ping reports 'Invalid argument'
    error (there's only one route left after deleting lo on my test
    machine - 192.168.1.0/24).

    > Somebody else mentioned that lo was 'perfectly happy' to
    > carry whatever. The fact that something bogus appears on
    > lo can be a sign of a misconfiguration error, just as
    > the reserved 127.0.0.0 network must never appear on ethernet.

    I'm not denying it may be some misconfiguration. The problem
    is that I don't see what/where it is. All the stuff looks pretty
    normal.

    > In the case of 0.0.0.0 (a possible broadcast), there is
    > no "local" address that could cause a bypass via lo. Instead,
    > any such traffic should have been on the ethernet wire. This
    > shows the possible configuration error that I mentioned.

    Again, I don't understand what do you mean. The message
    in $subj says that something *on this box* sent that bogus
    ICMP packet, with source address on this same box. It may
    be a reply to bogus packet sent with src=0.0.0.0 somehow,
    or maybe not. Maybe the host is trying to reply to a packet
    sent to one of its local IPs -- eg, imagine I send packet
    with src=0.0.0.0 to another host to non-listening port
    (rp_filter should be activated in that case I think, but
    IF that packet comes from the interface where the default
    route goes, rp_filter may not trigger) - and kernel is trying
    to send an ICMP reply... back to 0.0.0.0...

    Even that does not explain everything still. My 'default route'
    interface - the one which goes to my ISP - I doubt it's possible
    from the ISP side to send a packet destined to 192.168.4.2 so
    that the packet will come to us - unless their routing is hosed.

    The problem is, I can't see what is causing this misconfiguration
    or whatever. I wasn't able to capture such a packet so far either --
    it never happened while tcpdump was running.

     Note the local IP address mentioned is different, I've
    seen 3 so far, all 3 are local on this box and are on 3
    different (ethernet) interfaces (but the ICMP always comes
    from lo).

    >
    >> 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    >
    > ^^^^^^^^^^^^^^^^
    >
    >> inet 127.0.0.1/8 scope host lo
    >
    >
    > This looks as though there is no netmask set. My configuration
    > shows:

    The netmask is perfect - it's 127.255.255.255. The thing you
    quoted is *ethernet* address, not IP address - and for loopback,
    it's ok to have that as all-zeros.

    > lo Link encap:Local Loopback
    > inet addr:127.0.0.1 Mask:255.0.0.0
    > inet6 addr: ::1/128 Scope:Host
    > UP LOOPBACK RUNNING MTU:16436 Metric:1
    >
    > This is a possible configuration error.

    Here's how ifconfig shows my interface:

    lo Link encap:Local Loopback
              inet addr:127.0.0.1 Mask:255.0.0.0
              UP LOOPBACK RUNNING MTU:16436 Metric:1

    The above output is from `ip addr'.

    /mjt
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Ingo Molnar: "Re: Realtime Preemption, 2.6.12, Beginners Guide?"

    Relevant Pages

    • Re: ipv4 regression in 2.6.31 ?
      ... interface eth1 on host B and let host A ping 192.168.2.1 you get no reply. ... Each incoming packet is tested against the FIB and if the interface ... Current recommended practice in RFC3704 is to enable strict mode ...
      (Linux-Kernel)
    • Re: dialup solution (as seconary connection / iptables )
      ... with no default route for the PPP interface if you want to ... ethx is the host's Ethernet interface. ... it's the dialup host. ... In both instances the packet should be sent, ...
      (comp.os.linux.networking)
    • Re: Forcing a particular IP address out to an interface
      ... > lo device regardless of what is in the route table. ... pretend that the ppp0 interface on the 'left' box has IP ... the packet somewhere along its route. ... packet to alter the destination address to 192.168.1.23 ...
      (comp.os.linux.networking)
    • Re: Win 2003
      ... ping the outside interface of the router ... Server is a member of the domain. ... IPv4 Route Table ... Interface List ...
      (microsoft.public.windows.server.general)
    • Re: how to interpret route command
      ... network interface configuration for *receiving* data packets. ... It deals with the IP addresses for network interfaces, ... So when we look at a route table, do not expect to see anything ... necessary to decide on a per packet basis which network gets ...
      (comp.os.linux.networking)