Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Thu, 2008-04-17 at 17:09 -0400, Michael Stone wrote: Ashish comments on #6869: Firmware release - 5.110.22.p9 as follows: Currently firmware 5.110.22.p8/9 does not support more than 8 multicast mac addresses. Is there a possibility that any given point of time there are more than 8 multicast address required? Is this going to be a problem for anyone? Theoretically we go into ALLMULTI mode (and filter on the host) when we exceed the size of the multicast list that the device can handle. There shouldn't be a hard limit on the number of multicast groups that userspace can join; it just gets less efficient. However, we believe that size to be 32 (MRVDRV_MAX_MULTICAST_LIST_SIZE in defs.h). -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, Apr 18, 2008 at 10:28 AM, David Woodhouse [EMAIL PROTECTED] wrote: On Thu, 2008-04-17 at 17:09 -0400, Michael Stone wrote: Ashish comments on #6869: Firmware release - 5.110.22.p9 as follows: Currently firmware 5.110.22.p8/9 does not support more than 8 multicast mac addresses. Is there a possibility that any given point of time there are more than 8 multicast address required? Is this going to be a problem for anyone? Theoretically we go into ALLMULTI mode (and filter on the host) when we exceed the size of the multicast list that the device can handle. There shouldn't be a hard limit on the number of multicast groups that userspace can join; it just gets less efficient. In this case, it seems a bad choice to compromise buffer space in exchange of an improbable scenario (sharing more than 4 activities over a simple mesh). However, we believe that size to be 32 (MRVDRV_MAX_MULTICAST_LIST_SIZE in defs.h). Mmm, if the driver says it is 32 and the firmware only allows for 8, we have a problem, don't we? ;-) -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 10:58 -0400, Ricardo Carrano wrote: Mmm, if the driver says it is 32 and the firmware only allows for 8, we have a problem, don't we? ;-) Indeed. Do we know which versions of firmware support which numbers of addresses? Remember, this driver handles lots of devices, some with non-mesh firmware. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
Is it possible to associate shared activities with ethernet ports instead of whole multicast addresses? Then we would only need one single multicast address and do the filtering on the ethernet ports (eg IP is port 0x0800). At the very least, the multicast address is 6 bytes and the ethernet port is 2 bytes. Pol David Woodhouse wrote: On Fri, 2008-04-18 at 10:58 -0400, Ricardo Carrano wrote: Mmm, if the driver says it is 32 and the firmware only allows for 8, we have a problem, don't we? ;-) Indeed. Do we know which versions of firmware support which numbers of addresses? Remember, this driver handles lots of devices, some with non-mesh firmware. -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
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 single multicast address and do the filtering on the ethernet ports (eg IP is 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. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
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 single multicast address and do the filtering on the ethernet ports (eg IP is 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. -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
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 single multicast address and do the filtering on the ethernet ports (eg IP is 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. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
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 single multicast address and do the filtering on the ethernet ports (eg IP is 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. Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
David Woodhouse wrote: On Fri, 2008-04-18 at 12:01 -0400, Polychronis Ypodimatopoulos wrote: 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. Ah, sorry. I read it as UDP ports. It would be hard to do this -- there's a defined mapping from IPv6 addresses to the multicast MAC addresses used, and high-level applications don't get to muck around with low-level details of the Ethernet frames. Dynamic mapping from a single 6-byte address to multiple 16-byte addresses? I'm curious how this works. I just hope you don't have to change your IPv6 address every now and then ;-) Salut is _no_ high-level application and it should _not_ be associating multicast addresses with activities. Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 12:08 -0400, Polychronis Ypodimatopoulos wrote: Dynamic mapping from a single 6-byte address to multiple 16-byte addresses? The other way round. Given an IPv6 multicast address, there exists a MAC address associated with that IPv6 address. When we join the multicast group, we tell the device that we want to receive packets addressed to that MAC address. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 12:01 -0400, Polychronis Ypodimatopoulos wrote: 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. Ah, sorry. I read it as UDP ports. It would be hard to do this -- there's a defined mapping from IPv6 addresses to the multicast MAC addresses used, and high-level applications don't get to muck around with low-level details of the Ethernet frames. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 12:01 -0400, Polychronis Ypodimatopoulos wrote: 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. Forgive my ignorance... you're not talking about the EtherType field, which is set to 0x800 to indicate IPv4 packets or 0x86dd for IPv6? It doesn't seem practical to use that for application-specific purposes. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, Apr 18, 2008 at 11:26 AM, David Woodhouse [EMAIL PROTECTED] wrote: On Fri, 2008-04-18 at 10:58 -0400, Ricardo Carrano wrote: Mmm, if the driver says it is 32 and the firmware only allows for 8, we have a problem, don't we? ;-) Indeed. Do we know which versions of firmware support which numbers of addresses? Remember, this driver handles lots of devices, some with non-mesh firmware. The multicast filter was implemented in 22p8 (with the limit of 8 since them). Is that what you're asking? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, 2008-04-18 at 14:19 -0400, Ricardo Carrano wrote: The multicast filter was implemented in 22p8 (with the limit of 8 since them). Is that what you're asking? Then the firmware was just ignoring the MAC list before then, and always implementing the ALLMULTI behaviour? -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
On Fri, Apr 18, 2008 at 12:01 PM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: 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 single multicast address and do the filtering on the ethernet ports (eg IP is 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. Pol 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@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Do we ever want to bind more than 8 multicast MAC addresses?
Ashish comments on #6869: Firmware release - 5.110.22.p9 as follows: Currently firmware 5.110.22.p8/9 does not support more than 8 multicast mac addresses. Is there a possibility that any given point of time there are more than 8 multicast address required? Is this going to be a problem for anyone? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
It seems a very relevant question. The way collaboration over salut works now (I ask the experts to confirm that), every application will demand a multicast mac address. And four are already taken (01:00:5e:00:00:fb, 01:00:5e:00:00:01, 33:33:00:00:00:01 and 33:33:ff:1:2:3, where 1..3 are the last three bytes of the XO's mac addr). I am assuming this has to be subtracted from the total of 8. So, this would pose a limit of 4 shared applications for a given XO over a simple mesh. Assuming this is correct, than some questions follow. - Is 4 a reasonable limit (is the XO capable of more in terms of processing and memory?) - Is this a hard limit? How hard is to increase this number and what is the compromise? On Thu, Apr 17, 2008 at 5:09 PM, Michael Stone [EMAIL PROTECTED] wrote: Ashish comments on #6869: Firmware release - 5.110.22.p9 as follows: Currently firmware 5.110.22.p8/9 does not support more than 8 multicast mac addresses. Is there a possibility that any given point of time there are more than 8 multicast address required? Is this going to be a problem for anyone? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ricardo Carrano wrote: | Assuming this is correct, than some questions follow. | - Is 4 a reasonable limit (is the XO capable of more in terms of processing | and memory?) The XO is definitely capable of more, especially for activities like Chat that require minimal CPU/RAM and are usually silent on the network. | - Is this a hard limit? How hard is to increase this number and what is the | compromise? I have an additional question: Could the firmware allow the driver to designate one or more of those slots as a trivial bitwise filter? This would allow the driver to subscribe to one or more ranges of multicast addresses. It would also provide graceful degradation if there are too many multicast addresses to fit: the surplus addresses can just be OR'd together into a filter. There will be some false positives that will have to be screened out by the driver, but perhaps not too many. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIB9GAUJT6e6HFtqQRAu8kAKCXPHKqWLm5Rk2pimt8+yg3sW/VKgCfTTjn eqzgVrWnAxfJ9wmOvkbMWzI= =h0XZ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
I have a feeling that the capability of participating in up to four activities over a simple mesh scenario (no school server present) seems good enough. But I may be wrong and we certainly don't have enough (if any) user input to validate this (or not). On Thu, Apr 17, 2008 at 6:38 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ricardo Carrano wrote: | Assuming this is correct, than some questions follow. | - Is 4 a reasonable limit (is the XO capable of more in terms of processing | and memory?) The XO is definitely capable of more, especially for activities like Chat that require minimal CPU/RAM and are usually silent on the network. | - Is this a hard limit? How hard is to increase this number and what is the | compromise? I have an additional question: Could the firmware allow the driver to designate one or more of those slots as a trivial bitwise filter? This would allow the driver to subscribe to one or more ranges of multicast addresses. It would also provide graceful degradation if there are too many multicast addresses to fit: the surplus addresses can just be OR'd together into a filter. There will be some false positives that will have to be screened out by the driver, but perhaps not too many. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIB9GAUJT6e6HFtqQRAu8kAKCXPHKqWLm5Rk2pimt8+yg3sW/VKgCfTTjn eqzgVrWnAxfJ9wmOvkbMWzI= =h0XZ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Do we ever want to bind more than 8 multicast MAC addresses?
Yes, this is a problem for us. We need to request that 16 be allocated. wad On Apr 17, 2008, at 5:09 PM, Michael Stone wrote: Ashish comments on #6869: Firmware release - 5.110.22.p9 as follows: Currently firmware 5.110.22.p8/9 does not support more than 8 multicast mac addresses. Is there a possibility that any given point of time there are more than 8 multicast address required? Is this going to be a problem for anyone? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
