On Tue, 2005-03-01 at 09:07, Alexandru Petrescu wrote:
> > I've seen: 1) device driver bugs. either they fail to program the
> > multicast filter or they try and get it wrong. A common multicast
> > filter is a bit vector with associated hash function. (if
> > filter[hash(dst)] is set, receive packet). If the driver miscomputes
> > the hash function, bits don't move.
>
> Thanks. It's not the case here. The current code simply says /*TODO*/.
That suggests to me that the hardware is capable but the driver author is busy.
> > 2) firmware bugs in 802.11 access points. (the vendor had a firmware
> > upgrade available fixing it by the time I noticed the problem).
>
> Ok, that's an option, I'll have to wait and see.
using ethernet broadcast for your own private testing seems perfectly
reasonable as a hackaround to let you exercise the rest of the system, but
asking for everyone else to implement that hackaround in their v6 stack
before you've exhausted your options with your vendor seems like going about
things in the wrong order..
On Tue, 2005-03-01 at 08:51, Jari Arkko wrote:
> Is there any way to determine how widespread this problem is?
> Personally, I have never seen it. But YMMV.
I've seen it a few times. I've actually also seen something far more horrific:
an RTOS network driver interface which (a) pushed ethertype filtering into
the driver, and (b) did not allow any way for the stack to request specific
ethertypes. If it wasn't ETHERTYPE_ARP or ETHERTYPE_IP, it went straight into
the bit bucket. No V6 for you!
I've seen no evidence the problem is hardware.
- Bill
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
