CC3351: Customized packet filter cannot be implemented with WOLAN pattern

Hey Zhang,

Thanks for the feedback here, I have assigned this post to one of our experts to support/monitor this.

Hello,

Thanks for sharing this. Have you confirmed the same on a sniffer capture as well? And what do you mean by the frame with or without indices?

Hi Sabeeh Khan1 
The meaning is that network packet frames with indexes 1, 2, 3, and 4 can wake up the system, while the frame with index 0 cannot wake up the system

Hi Jihu,

I apologize as I'm not familiar, but how are you setting the packet offset? Are you using the 'iw' command or something custom? Can you provide an example of the command and example on how to generate wakeup packet?

Hi Sabeeh,

      In our previous project case, we use custom command from wifi chipset vendor to implement this requirement.

      Case 1, Broadcom, wl command:

        You can find more details from the following attachment.

        80211-TI305-R_Broadcom WLAN Client Utility Command Set.pdf

        Case 2, AIC, wifi_test command:

Hi Jihu,

Instead of using offset, can we fill in the entire buffer that is supported in iw? We should support up to 81 bytes in the entire message filter.

Even without using offset, I don't believe `iw` supports this feature, because the custom filter pattern isn't restricted to a specific position; rather, it starts from a specific position within the network packet, and the system will be woken up whenever this pattern appears anywhere after that specific position.

Hi Jihu,

Yes I agree it starts from a specific position, but with the iw tool you are able to set multiple patterns. So I was suggesting to use multiple patterns with the determined offset.

And just to be clear, is this a packet filter for the WOWLAN usecase, or is this a packet filter for ALL packets even while awake?

Taking the following network packet as an example:
pattern: 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F

How many times do you think the patterns should be set? 
Could you please give me an example on how to set multiple patterns with iw tool?  

Besides, we should not be limited to 81 bytes in the entire message filter. The system should be waken up whenever this pattern appears anywhere from offset to the end of the entire message

It is just for WOWLAN usecase. 

Hi Sabeeh Khan1 ,

According to our requirement, the supported maximum length of the pattern should be >= 32 bytes.

Hi Xing SU 

Just to clarify, the maximum length of the pattern is <= 32 bytes (less than or equal to 32 bytes), correct? In previous message >= was written.

Hi Sabeeh Khan1 ,

My apologies for the confusion.
I mean the longest pattern will be 32 bytes in our use cases. Therefore the supported pattern length in TI's driver should be >= 32 bytes to meet our need. For example, if the maximum pattern length in the driver were 40 bytes (>= 32) , that would perfectly meet our needs.

Hello,

Thank you for confirming. So the maximum pattern for a packet will be 32 bytes, then what would be the shortest? I assume the pattern should be of variable length, correct?

Hi Sabeeh Khan1 ,

Thanks for asking. Yes, in our case, the shortest pattern is 4 bytes.

Unlocking the thread.

Hi Jihu SI  Xing SU 

A few questions about this feature. Is the packet filter offset supposed to be defined from the beginning of the header or the payload? Do you know if we need to search for the pattern only in the payload, or in the header too? If only in the payload - should the offset be taken from the payload start or from the beginning of the header?

Hi Sabeeh Khan1 ,

Sorry for the late response.

The offset should be taken from the beginning of the header. And the search range should cover both the header and the payload.

Hi Sabeeh Khan1 
I have verified this feature with the latest TI WiFi driver: cc33xx_linux_package_1_0_2_13.run
The system can be waken up properly by tcp or udp packages when custom filter is set.

But there are still some issues in this process.
The first issue is that the wlan0 interface will crash when reading /sys/class/net/wlan0/device/wowlan_mode to check whether the current mode is ENABLED at the begining of setting custom filter. This is occasional. Please refer to the following picture to get more log info and work flow.

If I remove the step to check if wowlan_made is enabled, the above problem will not occur.

The second issue is about offset.
According to the email from you:

• Pattern Offset: Starting byte position in payload (0 = first payload byte)
  
  

The pattern offset is relative to the payload position, when I set the custom filter to 31:32:34:34:35:36 with the following command:

         echo "31:32:33:34:35:36" > /sys/class/net/wlan0/device/wowlan_pattern_search


The system can be waken up by udp or tcp package with data (0x31, 0x32, 0x33, 0x34, 0x35, 0x36). In this case, the offset is 0.

But when i set the offset > 0 with above same filter and the send the same tcp or udp message, the system can also be waken up.
for example:
   echo "10+31:32:33:34:35:36" > /sys/class/net/wlan0/device/wowlan_pattern_search

I think this is not right. I think the system can only be waken up when the offset is set to 0.

Tcp message and udp message is as follows:




 

Hi Sabeeh Khan1 ,

As we talked, please confirm that when we mention the header and payload, we are referring exclusively to the IP protocol layer.

Hi Jihu SI 

Thank you for this detailed review. We will take a look at these items.

For the crash that occurs when you are reading 'wowlan_mode', could you please collect and provide the FW logs? In the SDK, there should be a logger file, so please make sure to collect the FW logs using the logger.bin provided in the SDK.

Hi Sabeeh Khan1 
How to use the logger.bin to collect the FW logs?

First install the simplelink wifi toolbox from here: SIMPLELINK-WIFI-TOOLBOX Application software & framework | TI.com

Then, click on 'Logger' tool. 

From the first drop down, select 'Custome Parser', where you can then upload the logger.bin file.

Hi Jihu SI 

I want to make sure we're aligned on the starting byte position calculation requirements before proceeding. Let me explain what's currently implemented and confirm your expectations.

Our current implementation skips the MAC header and LLC header, then starts the search from the IP header.

offset = 0 → First byte of IP header (IP version)

offset = 9 → IP protocol field (TCP/UDP/ICMP)

offset = 12 → Source IP address

offset = 16 → Destination IP address

Regarding the offset issue:

Our implementation searches from the given offset forward through the rest of the packet.

offset = 0: Searches the entire IP payload (starting from IP header byte 0)

offset = 10: Searches from byte 10 onwards

In their TCP/UDP test packets, where is the pattern 31:32:33:34:35:36 located?

If their pattern is at offset 28 (typical UDP payload start), then both offset=0 and offset=10 will find it (because 28 > 10).

We need to verify the expected behavior: Should the offset parameter:

Option A: Match the pattern ONLY at the exact fixed offset position

Option B: Search for the pattern starting from the offset onwards (current implementation)?

Could you please clarify which behavior you expect?

Hi Sabeeh Khan1 

First of all,

Regarding the offset. I expect we should start the search from the Ethernet Header instead of IP header when offset is 0.

That means we should not skip the MAC header and LLC header.

Secondly,

Regarding the expected behavior about the offset parameter.

We expect the option B: Search for the pattern starting from the offset onwards.

Last but not least.

For UDP test packets, the pattern (31:32:33:34:35:36) is at offset 28(if search from IP header). The system can also be waken up when the offset is set to 42 or 29 with the same UDP message above.


The filter is as follows:

Active filters: 1/5

[0] offset=42: 31:32:33:34:35:36

Or

Active filters: 1/5

[0] offset=29: 31:32:33:34:35:36

Hi Jihu SI 

We believe there are other wakeup sources occurring. Could you please collect linux driver logs, sniffer, and FW logs so that we may observe the whole system?

Hi Sabeeh,

     I had reproduce the issus and capture some logs you mentioned. Please find the log files from here: https://drive.google.com/drive/folders/1Acj5Q1NoivZJ-jN9M24mme8FePeP6KE5?usp=sharing

     The following is my test steps:

     1. connect wifi ap: AUSU_2.4G_LIN

     2. execute the command:  echo 1 > /sys/class/net/wlan0/device/wowlan_mode

     3. execute the command: echo 1 > /sys/class/net/wlan0/device/wowlan_pattern_clear && echo "42+74:02:e1:20:ec:64" > /sys/class/net/wlan0/device/wowlan_pattern_search

     4. execute the command: echo mem > /sys/power/stat , to suspend sysmtem

     5. Send UDP packet to the device via my phone, and then the device waked up immediately.

     6. Repeat step 4 and step 5 several times.

     7. execute the command: echo 1 > /sys/class/net/wlan0/device/wowlan_pattern_clear && echo "29+74:02:e1:20:ec:64" > /sys/class/net/wlan0/device/wowlan_pattern_search

     8. Repeat step 4 and step 5 several times.

Hello Xianglong,

Sorry for the delay.

I believe there is an error during the FW log collection. The correct logger.bin seems to not have been used while collecting the FW logs. Please make sure you are selecting the 'custom parser' option in the Toolbox and then loading the "logger.bin" from the cc33xx SDK we provided to you.

Additionally, the sniffer log is encrypted. Can you please test on an AP that is using an OPEN network so that we can review the data of the packets inside?

Let me try to understand this correctly. '74:02:e1:20:ec:64' seems to be the MAC address of the phone. Is it your expectation that when using '29+74:02:e1:20:ec:64', the device should NOT wake up? 

Hello Sabeeh,

    Sorry about the wrong logs. I had captured the logs again. Please find the log files from here: https://drive.google.com/drive/folders/1s2JxiorHSvxaIjpAi2--cG_7Fir5ob4W?usp=drive_link

    1. I collected the FW logs with loading the "logger.bin" from the cc33xx SDK "cc33xx_linux_package_1_0_2_13.run".

    2. Because there isn't a tool allows connect to an open network, so it still connected to an encrypted network. But sniffer captured all authentication data packet, so it can decrypt all packet, and I had confirmed that there aren't any encrypted packet again. I think it is sufficient for analysis.

    3. '74:02:e1:20:ec:64' is the MAC address of CC3351. And I made a mistake with previous test, and I correct the commands with '31:32:33:34:35:36', it means we expect to wake up the host with the data '31:32:33:34:35:36' which is '123456' in string.

     The following is my test steps:

     1. connect wifi ap: AUSU_2.4G_LIN

     2. execute the command:  echo 1 > /sys/class/net/wlan0/device/wowlan_mode

     3. execute the command: echo 1 > /sys/class/net/wlan0/device/wowlan_pattern_clear && echo "42+31:32:33:34:35:36" > /sys/class/net/wlan0/device/wowlan_pattern_search

     4. execute the command: echo mem > /sys/power/stat , to suspend sysmtem

     5. Send UDP packet to the device via my phone, and then the device waked up immediately.

     6. Repeat step 4 and step 5 for a total of 5 times.

     7. execute the command: echo 1 > /sys/class/net/wlan0/device/wowlan_pattern_clear && echo "29+31:32:33:34:35:36" > /sys/class/net/wlan0/device/wowlan_pattern_search

     8. Repeat step 4 and step 5 for a total of 5 times.

     9. execute the command: echo 1 > /sys/class/net/wlan0/device/wowlan_pattern_clear && echo "31:32:33:34:35:36" > /sys/class/net/wlan0/device/wowlan_pattern_search

     10. Repeat step 4 and step 5 for a total of 5 times.

Thanks for providing the logs. I am reviewing them now with the team.

Before running the 'echo 1 > .../wowlan_mode' command, can you try executing the 'iw phy0 wowlan enable' command? I don't need logs for this, I'm just wondering if there is an issue with the command order.

Hi Sabeeh,

     I had tested again with executing the 'iw phy0 wowlan enable' command before 'echo 1 > .../wowlan_mode' command, it exists the same issue.

     BTW, with your EVB platform, do you reproduce this issue?

No, we don't reproduce this issue on our side. We still believe there may be other packets causing the wakeup.

I am providing a debug firmware with updated logger.bin file inside. Can you please re-collect the same sniffer capture and LOGGER pin logs using the below? This will help us pinpoint exactly which frame is causing the MPU to wakeup.

 wowlan_dbg_FW.zip

Hi Sabeeh,

     I had re-collected the logs with the new debug firmware and logger.bin. Please find the logs file from HERE: https://drive.google.com/drive/folders/11jszjiKv0-bVh_tUlRRsBUYw2rvRKL4h?usp=drive_link

     The test steps are the same as before.

Hi Xianglong,

We have created another debug FW where now more packets are offloaded to the firmware, so it should help to stop the host from waking so often. If you could please collect all the logs exactly as before again with the new logger.bin attached here.wowlan_debug_FW_2.zip

hi sabeeh，

First packet filter test:

echo 1 > /sys/class/net/wlan0/device/wowlan_pattern_clear && echo "42+31:32:33:34:35:36" > /sys/class/net/wlan0/device/wowlan_pattern_search && echo mem > /sys/power/state

Second packet filter test:

echo 1 > /sys/class/net/wlan0/device/wowlan_pattern_clear && echo "29+31:32:33:34:35:36" > /sys/class/net/wlan0/device/wowlan_pattern_search && echo mem > /sys/power/state

Third packet filter test:

echo 1 > /sys/class/net/wlan0/device/wowlan_pattern_clear && echo "31:32:33:34:35:36" > /sys/class/net/wlan0/device/wowlan_pattern_search && echo mem > /sys/power/state

drive.google.com/.../1-M47iisw2l647JYGGWQapYhWXSyrUxyM

In addition, the system can also be waken-up by ping messages when these three rules are set

Thank you Yinzhe, Jihu,

I have requested access to the drive link. It would be helpful also if you can upload the zip file of all files as well.

Hi Sabeeh，

sorry about that，I've modified the permissions for the link.

Hi Yinzhe,

Thank you, I have access now and will share the logs with the team.

Hi Sabeeh,

     We use this app named 'Network Kit' on my iphone while reproducing this issus. The parameters as following:

    I hope it can help you reproduce this issue.

In addition to the customized packet filter set above, we didn't set any other packet filters.