>> Not nice for NBMA ... :-(
It would be good if an application could determine quickly if multicast
or broadcast may actually work. If it comes back after trying for five
minutes with a complaint about lack of connectivity or such, this isn't
> ATMARP is not obliged even to know about this.
Except for the ATMARP server. Also, the clients need to allow sending
of packets to such addresses, which they may or may not do. (They
probably also need to disambiguate 255.255.255.255 broadcasts,
because the ATMARP server couldn't tell which LIS they are for.)
> Actually, many NBMA media did exactly this, because life
> without broadcasts is sort of... mmm... not easy.
Life with ATM is supposed to be hard ;-)
> Stop. But who did say:
>> Furthermore, the offending packets get killed before they show up
>> on tcpdump, which makes it harder to debug the "network" problem.)
Oops, there I was relaying a user comment ;-)
> No, I suggest to fix that bug. By the way, we will be able to get rid of
> that annoyning wrong "neighbour table overflow" for loopback.
First try: does my (completely untested) patch at
look reasonable ?
/ Werner Almesberger, ICA, EPFL, CH werner.almesberger@xxxxxxxxxxx /