Suspend vs Network Traffic - blockers

[Javier Cardona]

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)

Regarding upstream acceptability, this is what linville said about this:

<cozy-me> linville, I'm working on supporting signature based wake-on-wlan
<cozy-me> linville, that is, the host can send frame signatures to the
wireless device which will wake up the host when matched.
<cozy-me> I'm trying to avoid another iwpriv storm, but I don't know
of any other device that can do something like this.  What would be a
good user interface for this capability?
<linville> is it at all similar to the wol stuff in ethtool?  is this
just for libertas?
<cozy-me> it extends it.
<cozy-me> ie. with ethtool you can only say "wake me up on
unicast|broadcast|mcast" traffic.
<cozy-me> the signature allows more fine grained control.
<cozy-me> And yes, this is just for libertas.
<linville> is it something that could live in debugfs for a while?
<cozy-me> it could, yes, but this is something that userspace apps
would probably want to use.  One example is a VoIP app that requests that
the host is awakened when a particular frame is received.
<linville> johill had mentioned having something similar to iwpriv for
cfg80211, but I haven't seen it yet
<linville> if you need it soon, I suppose iwpriv might be acceptable
<linville> what things need to be set?  can you change the signatures?
<linville> I guess I would need to see a patch -- you know that people
will oppose new WE ioctls
<cozy-me>  a rule is SIGNATURE.SIGNATURE_MASK at LOCATION [&&
SIGNATURE.SIGNATURE_MASK at LOCATION]
<cozy-me> the device can accept up to 8 rules, that are ORed
<cozy-me> LOCATION=OFFSET
<linville> weird
<linville> I guess it sounds like something iwpriv might suit
<cozy-me> linville, ok, I'll submit a patch shortly

Cheers,

Javier

-- 
Javier Cardona
cozybit Inc.