On Fri, Apr 18, 2008 at 12:01 PM, Polychronis Ypodimatopoulos <<a href="mailto:ypod@mit.edu">ypod@mit.edu</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">David Woodhouse wrote:<br>
> On Fri, 2008-04-18 at 11:50 -0400, Polychronis Ypodimatopoulos wrote:<br>
><br>
>> what's possible? why not?<br>
>><br>
>> David Woodhouse wrote:<br>
>><br>
>>> On Fri, 2008-04-18 at 11:43 -0400, Polychronis Ypodimatopoulos wrote:<br>
>>><br>
>>><br>
>>>> Is it possible to associate shared activities with ethernet ports<br>
>>>> instead of whole multicast addresses? Then we would only need one single<br>
>>>> multicast address and do the filtering on the ethernet ports (eg IP is<br>
>>>> port 0x0800). At the very least, the multicast address is 6 bytes and<br>
>>>> the ethernet port is 2 bytes.<br>
>>>><br>
>>>><br>
>>> That's possible, yes -- although you won't get the device filtering it<br>
>>> for you then.<br>
>>><br>
>>><br>
>>><br>
><br>
> Error. Question upside down. Please don't top-post.<br>
><br>
> It's possible to do as you say -- to use different ports for different<br>
> activities (although I read 'UDP ports' where you actually said<br>
> 'ethernet ports' so perhaps I misunderstood).<br>
><br>
> The device firmware doesn't speak IPv6 or Legacy IP, however -- and we<br>
> wouldn't want it to, even if we trusted it. So it wouldn't filter for<br>
> only those ports you're interested in; it'll give you all packets for<br>
> that address.<br>
><br>
><br>
</div>You're not following: Ethernet ports are bytes 12-14 (2 bytes total) on<br>
_all_ ethernet frames. IP has nothing to do with this. Instead of<br>
looking at the first 6 bytes (destination mac) for a specific multicast<br>
address, the filter should be looking at bytes 12-14 for a specific<br>
ethernet port.<br>
<br>
Pol<br>
<div><div></div><div class="Wj3C7c"><br>
</div></div></blockquote><div><br>An ethernet frame may exist to the host, but what the firmware gets is the incoming 802.11 frame.<br>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.<br>
<br>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.<br>
<br>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.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
<br>
<br>
<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
</div></div></blockquote></div><br>