Opened 9 years ago

Closed 9 years ago

#6993 closed defect (fixed)

Firmware release - 5.110.22.p14

Reported by: carrano Owned by: dgilmore
Priority: normal Milestone:
Component: distro Version: Update.1
Keywords: wireless firmware Cc: javier@…, luisca@…, ashish, mbletsas, dsaxena
Blocked By: Blocking: #3732, #4616
Deployments affected: Action Needed: never set
Verified: no


New Features

  1. Signature based WOL filter

(see details bellow)

  1. Support for 32 multicast addresses.

Bug Fix

  1. OLPC ticket 6805


  1. Driver patch is required for signature based host wakeup feature.
  1. ethtool command support is optional with the driver patch.

Attachments (2)

usb8388-22p14.bin (120.8 KB) - added by carrano 9 years ago.
Libertas Firmware 22.p14 - md5sum: bb929f89374d10bd01b6e75e97833901 usb8388.bin
0002-Wol_Signature_Filter.patch (18.2 KB) - added by carrano 9 years ago.
proposed patch (from Marvell)

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by carrano

Libertas Firmware 22.p14 - md5sum: bb929f89374d10bd01b6e75e97833901 usb8388.bin

Changed 9 years ago by carrano

proposed patch (from Marvell)

comment:1 Changed 9 years ago by carrano

  • Cc javier@… luisca@… added

comment:2 Changed 9 years ago by carrano

Intructions on the filter (from the Marvell release notes):

This signature based WOL filter is independent of existing
{uni|multi|broadcast} (ethtool -s wol mshX ubm) filter.
This rule based filter can accommodate maximum 8 rules at a
given time. The rules can be ORed or/and ANDed with other
rules or can be used independently. These rules are defined
for 6 patterns which are all possible combinations of packet
type {uni|multi|broad}cast and mode of communication
(mesh or BSS).

The host_CMD_802_11_HOST_SLEEP_CFG command is overloaded to

configure the WOL filter.
Three commands i.e., set_wol_rule, get_wol_rule and
reset_wol_rule are supported.
The WOL filter has following restrictions.

  1. Two rules can not be defined for same pattern. i.e., same packet type {uni|multi|broad}cast and mode (mesh or BSS).
  2. Rules will be executed from left to right.
  3. Rule table can be reset, however, a single rule cannot be deleted, once defined.

These commands are implemented using iwpriv command in the


iwpriv {et|ms}hX <command> <option> <rule> [op] [rule] [op]...


command: Three commands to manage WOL Rules in the filter.

  1. "set_wol_rule" to set rules into the WOL filter

  1. "get_wol_rule" to get the currently stored rules.

Arguments to get_wol_rule are optional. If called
without any argument returns total available rule
slots in the WOL filter, which can be used to set
new rules.

  1. "reset_wol_rule" resets the all WOL filter rules No argument is required for reset_wol_command.

Option: consist of "Packet_Type_Option [Mesh_Mode_Option]"


{[uU]|[bB]|[mM]} for {uni|multi|broad}cast frames.

Mesh_Mode_Option (optional)

[mM] for Mesh
Missing for ad-hoc/infra frames.

Rule: RULE is defined as below.


SIGNATURE is the byte pattern to be matched in the

received packet at location LOCATION with mask
The size of SIGNATURE can be up to 4 byte. The received
packet is used to wake up the host, if it matches the
that should be used for matching the packet. LOCATION
defines the start byte position of SIGNATURE offset in
the _payload_ (after 802.11 header) of the received packet.

SIGNATURE and SIGNATURE_MASK are defined in network byte
order format. SIGNATURE should start with the 0X or 0x byte
pattern. SIGNATURE can be defined only for payload of
802.11 frame format. SIGNATURE offset has a limit of 2300
bytes which is maximum IEEE 802.11 payload size minus

Op: operator could be && (for AND) or
(for OR)


  1. How to the set the WOL rule. If user needs to wakeup the host on ARP request received from host with ip address in infra mode.

$iwpriv eth0 set_wol_rule "b 0x00000806.FFFFFFFF@04 && \


If user needs to set WOL filter for ARP request received

from the host with ip address in mesh mode

$iwpriv msh0 set_wol_rule "b m 0x50430806.FFFFFFFF@04 && 0xC0A80001.FFFFFFFF@1b"

  1. How to get the status of the rule If user needs the status of the set rule in the WOL filter.

$iwpriv eth0 get_wol_rule bm

This will return the status of the rule set for broadcast

mesh packet as per below format.

eth0 get_wol_rule: Total 2 Rules found for Broadcast Rule

Rule No Signature Sig Mask Location Rule Op

000 0X504386 0xffffffff 0x04 AND
001 0Xc0a801 0xffffffff 0x1b Not Available

$iwpriv eth0 get_wol_rule

eth0 get_wol_rule: Total available free rule slots are 4.

  1. How to reset the WOL filter

$iwpriv eth0 reset_wol_filter

This will reset the WOL filter. If user issues the

get_wol_rule without any argument at this time, command will
return 8 free rule slots.

$iwpriv eth0 get_wol_rule

eth0 get_wol_rule: Total available free rule slots are 8.

ethtool command compatibility
By default, if neither ethtool nor set_wol_rule is given, the XO will
wake up on only unicast packets (driver sends 'ethtool -s mshX u'
command after firmware download).

When only ethtool -s mshX wol < options > command is used the XO wakes
up according to the option specified in the command.

When iwpriv msh0 set_wol_rule ... command is given, the XO wakes up
according to the rule specified in the command.

When the patterns given in ethtool and the set_wol_rule are different,
XO will wake up on packets specified in the ethtool or on packets
specified by the set_rule command.

When the pattern given in ethtool and set_wol_rule is same (e.g., both
are set for unicast), then the rules are ANDed. The XO will first check
the ethtool rule first and if it is true will check the set_rule command.
When both the rules are true then only the XO will come out of the sleep

comment:3 Changed 9 years ago by carrano

  • Cc ashish mbletsas added

First quick test with the wol signature filter:

I set up a filter to wake on the receipt of:

1 - any arp requests via msh0 interface

iwpriv msh0 set_wol_rule "b m 0x50430806.FFFFFFFF@04"

2 - an arp request coming from

iwpriv msh0 set_wol_rule "b m 0x50430806.FFFFFFFF@04 && \

3 - any arp request via eth0

iwpriv eth0 set_wol_rule "b 0x00000806.FFFFFFFF@04"

4 - an arp request coming from

iwpriv eth0 set_wol_rule "b 0x00000806.FFFFFFFF@04 && \

5 - both 2 and 4

6 - both 1 and 3

At all cases, the filter successfully waked the host.

comment:4 Changed 9 years ago by carrano

This firmware is confirmed to fix #6805.

comment:5 Changed 9 years ago by carrano

  • Owner changed from carrano to dgilmore


Once the new kernel is built (as reported in #7014), this firmware is ready to go into joyride.


comment:6 Changed 9 years ago by dgilmore

Next build will have the new firmware.

Ricardo. can we get together to work out a way to release new firmware. it changes from release to release and this file is named incorrectly.

comment:7 Changed 9 years ago by gnu

  • Blocking 3732 added

(In #3732) The new firmware in #6993 adds the wake-on-signature feature that's mentioned in the comment above. This could be used by our driver, initscripts, and network manager to permit wake-on-incoming-ARP. I don't believe that we have all of that infrastructure set up to use the new feature, though.

Doing that would fix this "autosuspended laptop doesn't wake on incoming ARP packets" bug, once and for all.

I believe it's mostly a driver issue; whenever an IPv4 address is added to the interface, it needs to be added to the wake-on-signature table so that we'll wake when an ARP for that address comes in. (Note that we can have several IPv4 addresses at the same time on the same interface.) When an IPv4 address is removed, we'd remove the entry from the wake-on-signature table.

Then during suspend, the kernel would have to know whether we are doing an automatic suspend (for power management, invisibly to the user) or a manual suspend (because the user told us to turn off). A manual suspend should not wake when packets come in (any packets). An automatic suspend should wake when packets come in (any packets for us, including ARP, multicast that we're listening for, or unicast addressed to us).

comment:8 Changed 9 years ago by gnu

  • Blocking 4616 added

(In #4616) #6993 contains firmware improvements that fix the wake-on-multicast table. If they work, and the driver changes take advantage of them, and Ohm or the driver sets the right bits based on how we suspend, then system-level testing should be finally able to close this bug.

comment:9 Changed 9 years ago by gregorio

  • Milestone Never Assigned deleted

Milestone Never Assigned deleted

comment:10 Changed 9 years ago by dsaxena

  • Action Needed set to never set
  • Cc dsaxena added

comment:11 Changed 9 years ago by dsaxena

  • Resolution set to fixed
  • Status changed from new to closed

I've committed the kernel patches to add the wakeup filter rules so am closing this. We still need a version upstream but Javier and Marvell are working on this.

Note: See TracTickets for help on using tickets.