Firmware release - 5.110.22.p14

[carrano]

New Features

1. Signature based WOL filter

(see details bellow)

2. Support for 32 multicast addresses.

Bug Fix

1. OLPC ticket 6805

http://dev.laptop.org/ticket/6805

Notes

1. Driver patch is required for signature based host wakeup feature.

2. ethtool command support is optional with the driver patch.

[carrano]

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

[carrano]

proposed patch (from Marvell)

[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.

Usage: These commands are implemented using iwpriv command in the driver.

SYNOPSIS

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

DESCRIPTION

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

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

2. "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.

3. "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]"

Packet_Type_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.SIGNATURE_MASK@LOCATION

SIGNATURE is the byte pattern to be matched in the

received packet at location LOCATION with mask SIGNATURE_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 SIGNATURE. SIGNATURE_MASK defines bits of the SIGNATURE 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 SIGNATURE size.

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

Examples:

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

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

0xC0A80101.FFFFFFFF@16"

If user needs to set WOL filter for ARP request received

from the host with ip address 192.168.0.1 in mesh mode

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

2. 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.

3. 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 mode.

[carrano]

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 169.254.4.180

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

3 - any arp request via eth0

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

4 - an arp request coming from 192.168.11.5

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

5 - both 2 and 4

6 - both 1 and 3

At all cases, the filter successfully waked the host.

[carrano]

This firmware is confirmed to fix #6805.

[carrano]

Dennis,

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

Thanks! Ricardo

[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.

[gnu]

(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).

[gnu]

(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.

[gregorio]

Milestone Never Assigned deleted

[dsaxena]

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.