> In non-broadcast multiple-access networks (NBMA) such as Classical IP
> over ATM (CLIP), neither broadcast nor multicast have any useful
> semantics. Right now, I catch this in neigh_table->constructor and
> return -EINVAL.
> Is this the right approach ?
Yes, it is right. In theory.
> Or should I return success, accept the
> bogus neighbour entry (could this upset the neighbour cache ?), and
> blackhole the entire mess afterwards via neigh->ops and
> neigh->output ?
And this is always right.
> (Background: some applications seem to insist on sending broadcast
> or multicast even on interfaces that have neither IFF_BROADCAST nor
> IFF_MULTICAST set.
They are right. These flags do not mean, that such packets are
indeliverable. It is pure advise, and applications taking them
seriously are buggy as rule. Actually, even CLIP could have some
"broadcast router" on subnet without any modifications to protocol.
> According to people who have such applications,
> the current approach makes the stack believe that there is a memory
> shortage, and shrink the neighbour cache, which is undesirable.
It is news for me. Honestly. They almost do not lie,
only neighbour cache is happy, it is IP tries to help it
shrinking routing cache aggressively. It is bug.
> Furthermore, the offending packets get killed before they show up
> on tcpdump, which makes it harder to debug the "network" problem.)
8) Werner, do this in the way, convenient for you.
I would prefer to see only _real_ packets with tcpdump.
Tcpdump is supposed to tap device yet, rather than bogus
packets wandering inside the stack. But taking into account
bug, described above, you simply have no choice but to follow
your preferred way. 8)8)