Do we ever want to bind more than 8 multicast MAC addresses?
carrano at laptop.org
Fri Apr 18 14:41:34 EDT 2008
On Fri, Apr 18, 2008 at 12:01 PM, Polychronis Ypodimatopoulos <ypod at mit.edu>
> David Woodhouse wrote:
> > On Fri, 2008-04-18 at 11:50 -0400, Polychronis Ypodimatopoulos wrote:
> >> what's possible? why not?
> >> David Woodhouse wrote:
> >>> On Fri, 2008-04-18 at 11:43 -0400, Polychronis Ypodimatopoulos wrote:
> >>>> Is it possible to associate shared activities with ethernet ports
> >>>> instead of whole multicast addresses? Then we would only need one
> >>>> multicast address and do the filtering on the ethernet ports (eg IP
> >>>> port 0x0800). At the very least, the multicast address is 6 bytes and
> >>>> the ethernet port is 2 bytes.
> >>> That's possible, yes -- although you won't get the device filtering it
> >>> for you then.
> > Error. Question upside down. Please don't top-post.
> > It's possible to do as you say -- to use different ports for different
> > activities (although I read 'UDP ports' where you actually said
> > 'ethernet ports' so perhaps I misunderstood).
> > The device firmware doesn't speak IPv6 or Legacy IP, however -- and we
> > wouldn't want it to, even if we trusted it. So it wouldn't filter for
> > only those ports you're interested in; it'll give you all packets for
> > that address.
> You're not following: Ethernet ports are bytes 12-14 (2 bytes total) on
> _all_ ethernet frames. IP has nothing to do with this. Instead of
> looking at the first 6 bytes (destination mac) for a specific multicast
> address, the filter should be looking at bytes 12-14 for a specific
> ethernet port.
An ethernet frame may exist to the host, but what the firmware gets is the
incoming 802.11 frame.
Since the mac filter is used immediately after the blinding table filter,
there is not an easy way to get this information. It would involve looking
into the frame payload to find some bytes that are not in a fixed position.
At the application level though, it is possible to multiplex one single
multicast address with as many applications as you need, using an UDP port.
This involves reengineering the middleware but it is a scalable solution.
But sorry to insist that, if after the eighth address has been taken the
host will respond to *every* multicast frame, then in this unlikely
scenario, suspend would not be as effective and thatś it. I am afraid we are
creating an issue out of nothing, possibly complicating matters later.
> Devel mailing list
> Devel at lists.laptop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel