Suspend vs Network Traffic - blockers

[Ricardo Carrano]

Hi Javier,

On Tue, Aug 12, 2008 at 3:19 PM, Javier Cardona <javier at cozybit.com> wrote:
> Deepak,
>
> On Tue, Aug 12, 2008 at 10:38 AM, Deepak Saxena <dsaxena at laptop.org> wrote:
>>> There are at least two mechanisms that need to be in place for both
>>> things to be able to operate together without causing major issues:
>>>
>>> 1 - The multicast address populating on the firmware, that is needed
>>> for collaboration to work:  http://dev.laptop.org/ticket/6818
>>
>> So it doesn't look like Javier's patch actually went into one of our official
>> branches (stable/testing/master). I'm also not sure we need it b/c testing
>> and stable have the following commit that came in 6 days after Javier's patch
>> on trac and it seems to deal with the same issue:
>>
>> commit c16eba59c2183f9d4952eca4d720982cfbe8e031
>> Author: David Woodhouse <dwmw2 at infradead.org>
>> Date:   Mon May 19 18:47:52 2008 +0100
>>
>>    libertas: fix multicast handling on eth and msh interfaces
>
> You are correct.  The patch that I sent is unnecessary, as David
> Woodhouse rewrote it in a much better way.
> I tested his implementation and it passed all our test cases.  So you
> can ignore my patch.
> (In case anyone needs them, our tests for this are here:
> http://dev.laptop.org/~javier/misc/olpc-mcast-stable-tests.tar.gz)
>
>>> 2 - The signature based filter, that is needed for ARP to work
>>> (keeping in mind that no ARP, no unicast traffic, nothing):
>>> http://dev.laptop.org/ticket/6993#comment:2
>>
>> This patch applies cleanly and if we need this for 8.2 mesh to work properly,
>> I'm OK pushing it in (depending on how our discussion on change control ends
>> up) but would like to see us vet this upstream for the future. Instead of
>> iwpriv, we could theoretically extend the ethtool interface to support
>> this if we think more HW in the future will support this sort of filtering.
>> Javier, can you work on push to upstream? Have we already tried and been
>> NACKed?
>
> We are waiting for Marvell for an updated firmware that implements a
> simpler API to configure wake-on-wlan signatures.  The proposed API
> was really hard to use and would require additional changes to support
> IPv6.  Before pushing this upstream we wanted to have a cleaner
> driver/fw interface.
>
> Marvell will implement the new wow-signature API with the next
> firmware release (22p18)

Though I agree now, as I agreed in the past, that the filter is not
easy to use, I would say that it was a mechanism already in place
(and the filter would not be used by an end user anyway). If I recall
correctly, the filter was compatible with IPv6, it was just terribly
inneficient in doing so.

It seeems to me that this old filter method (let's call it old) is the
only available option to do it fast. Do you guys believe we'll be able
to test a new firmware and driver and push it to a build fast?

Cheers!
Ricardo