netdev
[Top] [All Lists]

Re: IFF_NOARP & broadcasting [2]

To: kuznet@xxxxxxxxxxxxx
Subject: Re: IFF_NOARP & broadcasting [2]
From: Karlis Peisenieks <karlis@xxxxx>
Date: Thu, 25 Jul 2002 16:32:23 +0300
Cc: netdev@xxxxxxxxxxx
In-reply-to: <200207241652.UAA19057@xxxxxxxxxxxxx>; from kuznet@xxxxxxxxxxxxx on Wed, Jul 24, 2002 at 19:52:55 +0300
References: <20020724190421.A2449@karlis> <200207241652.UAA19057@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On 2002.07.24 19:52 kuznet@xxxxxxxxxxxxx wrote:

> No, it is surely not impossible. f.e.
> 
> ip neigh add 255.255.255.255 dev dummy0 lladdr ff:ff:ff:ff:ff:ff

Ok, but even in this case there is minor problem. And it lies in
net/ethernet/eth.c - eth_header.

neigh_resolve_output creates header cache with correct ll source and ll
destination as in neighbour, but uses dev->hard_header to build header for
first packet. And eth_header has code:

        if (dev->flags & (IFF_LOOPBACK|IFF_NOARP)) 
        {
                memset(eth->h_dest, 0, dev->addr_len);
                return(dev->hard_header_len);
        }

which explicitly sets ll destination to all 0s. For all next packets
hh_cache is used and they get correct ll address (as in neighbour).

Please comment on this patch :) :

--- eth.c.orig  Thu Jul 25 16:16:37 2002
+++ eth.c       Thu Jul 25 16:16:47 2002
@@ -100,7 +100,7 @@
         *      Anyway, the loopback-device should never use this
function... 
         */
 
-       if (dev->flags & (IFF_LOOPBACK|IFF_NOARP)) 
+       if (dev->flags & IFF_LOOPBACK) 
        {
                memset(eth->h_dest, 0, dev->addr_len);
                return(dev->hard_header_len);



Karlis


<Prev in Thread] Current Thread [Next in Thread>