Bug 196741
| Summary: | iwlwifi: unsolicited multicast traffic still dropped when adapter set to allmulti - WIFILNX-1330 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | regwz |
| Component: | network-wireless | Assignee: | DO NOT USE - assign "network-wireless-intel" component instead (linuxwifi) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | luca |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 4.12.8 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | potential fix | ||
We'll try to reproduce this and debug it. Okay, it seems that we just haven't implemented ALLMULTI in the iwlwifi driver. I'll come up with a patch for it soon. Created attachment 258173 [details]
potential fix
Please try this patch. It should solve the problem with ALLMULTI.
It does indeed work (kernel 4.12.10-1-ARCH with the patch applied). I tested the patch using the original reproduction steps. I also tested that the filter is active again after the ALLMULTI flag is toggled off. While testing the patch in Wireshark, I realized that I should be seeing multicast packets when the interface is set to promiscuous mode (and the allmulticast mode is off). But I didn't see any. I guess the difference is that the promiscuous mode should also turn off the optional broadcast filter (CONFIG_IWLWIFI_BCAST_FILTERING) and the unicast filter (if there is any). Should I file another bug report for that? Again, thanks for reporting and testing! The patch is on its way to the mainline. About promiscuous mode, yes, please file it as a separate bug report and I'll check what we can do about it. Patch merged in our internal tree. It will go upstream soon after the merge window closes. |
Only frames with link-layer address that is on the list shown by `ip -0 maddress show dev wlp4s0` are received. The wireless device is set to ALLMULTI mode by: `ip link set dev wlp4s0 allmulticast on` Steps to reproduce: 1. connect a wireless client to a wireless AP 2. open Wireshark on the client to monitor icmpv6 traffic 3. execute on the client: `ip link set dev wlp4s0 allmulticast on` 4. execute on the AP: ping ff02::1 ... RECEIVED by the client (the link-layer address 33:33:00:00:00:01 is on the list) 5. execute on the AP: ping ff02::1:ffab:cdef ... NOT RECEIVED by the client (the link-layer address 33:33:ff:ab:cd:ef is not on the list) 6. apply workaround 7. go to step 5; the packets are now received by the client Expected result: The client should receive packets from ff02::1:ffab:cdef because, even though the address is not in the multicast address list, the adapter is in ALLMULTI mode. The workaround for me was to add more than MAX_MCAST_FILTERING_ADDRESSES (256) using the script below (assuming there is at least one multicast address already present): #!/bin/bash for i in {0..255} do hex=$(printf '%02x' $i) ip maddress add 33:33:ff:00:00:$hex dev wlp4s0 done The use case for this feature is a IPv6 neighbor discovery proxy using ndppd (NDP Proxy Daemon). device info: Intel(R) Dual Band Wireless AC 3160, REV=0x164 driver: iwlwifi version: 4.12.8-2-ARCH firmware-version: 17.459231.0 expansion-rom-version: bus-info: 0000:04:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no