mt76x2u: multicast stops working in IBSS

[eSoares]

Hello, I'm putting "mt76x2u" in the title because this was where I saw the behaviour, not sure if happens in more places. I'm using an Netgear A6210 (0846:9053) and setting it in IBSS mode and adding a default route for multicast traffic to the device. Then I start sending multicast traffic with iperf (v2):

iperf -u -c 224.224.2.5 -b 37M -t 3500 -i 1 Confirm it is working by running monitor mode in another interface and checking the packets getting received.

After a few minutes later (sometimes in the first 20 seconds, sometimes almost a minute later) of continues multicast traffic the transmission stops on the iperf, only resuming if I send a ping to the same multicast address.

Other wireless interfaces don't have the issue (tested with an ath9k).

This was tested with kernel 5.4.0-52-generic, but also in an raspberry pi with kernel 5.9.1-v7+ the same test causes a crash in mt76x02_mac_work (dmesg attached). dmesg_crash.log

[LorenzoBianconi]

Hello,

I'm putting "mt76x2u" in the title because this was where I saw the behaviour, not sure if happens in more places. I'm using an Netgear A6210 (0846:9053) and setting it in IBSS mode and adding a default route for multicast traffic to the device. Then I start sending multicast traffic with iperf (v2):

iperf -u -c 224.224.2.5 -b 37M -t 3500 -i 1 Confirm it is working by running monitor mode in another interface and checking the packets getting received.

Can you please confirm the system tries to resolve the L3 address using ARP? If so, I think the behaviour is expected since you are saturating the channel (IIUC you are sending L2 broadcast packets that are sent at low rate) and the neighbor subsystem is not able to resolve the IP address.

Regards, Lorenzo

After a few minutes later (sometimes in the first 20 seconds, sometimes almost a minute later) of continues multicast traffic the transmission stops on the iperf, only resuming if I send a ping to the same multicast address.

Other wireless interfaces don't have the issue (tested with an ath9k).

This was tested with kernel 5.4.0-52-generic, but also in an raspberry pi with kernel 5.9.1-v7+ the same test causes a crash in mt76x02_mac_work (dmesg attached). dmesg_crash.log https://github.com/openwrt/mt76/files/5477677/dmesg_crash.log

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/470, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOA2CJCYZC3OVXOYUHSGS3SN4FKVANCNFSM4TH4L3UA .

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[eSoares]

Multicast does not perform ARP, since already knows what is the MAC address to send the data. I don't see it as saturated, and even if i set the multicast rate (via mcast_rate) to an high value (let's say 48Mbps) and send traffic bellow that rate (36Mbps), it still happens.

In an ath9k interface, does not have such behaviour. Also, if I send a ping packet after the tx blocks, the TX will unblock and resume for a bit.

[LorenzoBianconi]

Multicast does not perform ARP, since already knows what is the MAC address to send the data. I don't see it as saturated, and even if i set the multicast rate (via mcast_rate) to an high value (let's say 48Mbps) and send traffic bellow that rate (36Mbps), it still happens.

In an ath9k interface, does not have such behaviour. Also, if I send a ping packet after the tx blocks, the TX will unblock and resume for a bit.

If you run the device in AP mode, does the issue occur? what about sta mode?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[eSoares]

Just tested and the issue does not seem to occur in AP, STA or Mesh. Looks to be only in IBSS mode. Even tried adjusting mcast_rate in mesh mode and did not cause any issue.

Lorenzo Bianconi notifications@github.com escreveu no dia segunda, 2/11/2020 à(s) 23:33:

Multicast does not perform ARP, since already knows what is the MAC address to send the data. I don't see it as saturated, and even if i set the multicast rate (via mcast_rate) to an high value (let's say 48Mbps) and send traffic bellow that rate (36Mbps), it still happens.

In an ath9k interface, does not have such behaviour. Also, if I send a ping packet after the tx blocks, the TX will unblock and resume for a bit.

If you run the device in AP mode, does the issue occur? what about sta mode?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/470#issuecomment-720785497, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOGVGEDTLDQHFOV3S6YVNDSN46T7ANCNFSM4TH4L3UA .

[LorenzoBianconi]

Just tested and the issue does not seem to occur in AP, STA or Mesh. Looks

to be only in IBSS mode. Even tried adjusting mcast_rate in mesh mode and did not cause any issue.

forgot to ask if you are running w or w/o encryption. If so, can you please try to disable it?

Eduardo Soares https://esoares.xyz

Lorenzo Bianconi notifications@github.com escreveu no dia segunda, 2/11/2020 à(s) 23:33:

Multicast does not perform ARP, since already knows what is the MAC address to send the data. I don't see it as saturated, and even if i set the multicast rate (via mcast_rate) to an high value (let's say 48Mbps) and send traffic bellow that rate (36Mbps), it still happens.

In an ath9k interface, does not have such behaviour. Also, if I send a ping packet after the tx blocks, the TX will unblock and resume for a bit.

If you run the device in AP mode, does the issue occur? what about sta mode?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/470#issuecomment-720785497, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAOGVGEDTLDQHFOV3S6YVNDSN46T7ANCNFSM4TH4L3UA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/470#issuecomment-721291819, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOA2CKILPVFDXCJNP37GJLSOBBHRANCNFSM4TH4L3UA .

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[eSoares]

Without encryption in every scenario that I mentioned.

Lorenzo Bianconi notifications@github.com escreveu no dia terça, 3/11/2020 à(s) 18:10:

Just tested and the issue does not seem to occur in AP, STA or Mesh. Looks

to be only in IBSS mode. Even tried adjusting mcast_rate in mesh mode and did not cause any issue.

forgot to ask if you are running w or w/o encryption. If so, can you please try to disable it?

Eduardo Soares https://esoares.xyz

Lorenzo Bianconi notifications@github.com escreveu no dia segunda, 2/11/2020 à(s) 23:33:

Multicast does not perform ARP, since already knows what is the MAC address to send the data. I don't see it as saturated, and even if i set the multicast rate (via mcast_rate) to an high value (let's say 48Mbps) and send traffic bellow that rate (36Mbps), it still happens.

In an ath9k interface, does not have such behaviour. Also, if I send a ping packet after the tx blocks, the TX will unblock and resume for a bit.

If you run the device in AP mode, does the issue occur? what about sta mode?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/470#issuecomment-720785497, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AAOGVGEDTLDQHFOV3S6YVNDSN46T7ANCNFSM4TH4L3UA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/470#issuecomment-721291819, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAOA2CKILPVFDXCJNP37GJLSOBBHRANCNFSM4TH4L3UA

.

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/470#issuecomment-721293107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOGVGDEM7JEAF3PQQUX3SDSOBBRFANCNFSM4TH4L3UA .

[LorenzoBianconi]

@eSoares I just tried using my last mt76 tree and it works fine for me (multicast traffic does not hang after 600s). Can you please confirm the issue occurs even using that codebase?

[eSoares]

Hello @LorenzoBianconi , I just tried it and I was unable to place the device in IBSS or Mesh mode. In both cases returning command failed: Operation not supported (-95) (monitor or managed mode worked). With the built in modules of the kernel IBSS and mesh also worked.

[LorenzoBianconi]

@eSoares I have just retried with my mt76 tree and a 76x2u device (0846:9053 NetGear, Inc. A6210) and it works as expected. I am able to connect to another (ath9k) vif in ibss mode (unencrypted connection) and the multicast traffic does not stop after 600s. I added the ath9k device as default next-hop for multicast traffic (ip route add default via <IP>). What fw are you running? Can you please share a reproducer I can test?

[julianocss]

Hi @LorenzoBianconi.

It´s possible to test your mt76 tree before you update mt76 repo? I would like to help, but I don't know how to compile from your repo using Openwrt Build System.

Juliano

[eSoares]

@LorenzoBianconi sorry, maybe it was a mistake in my side.

I'm trying to test it in a Ubuntu 20.04, installed kernel version 4.18.0-041800rc8-generic (from https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18-rc8/ ) and checkout the repository, and compiled from the directory drivers/net/wireless/mediatek/mt76 with the command make -C /lib/modules/4.18.0-041800rc8-generic/build M=$(pwd) modules.

The end result is just two kernel modules mt76.ko and mt76x2e.ko shouldn't be more?

I also tried to compile them for the latest kernel I have installed (5.4.0-58-generic) and was unable with an undefined error:

ERROR: "__sw_hweight8" [/storage/linux-drivers-tests/wireless-drivers-next/drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:94: __modpost] Error 1
make: *** [Makefile:1670: modules] Error 2
make: Leaving directory '/usr/src/linux-headers-5.4.0-58-generic'

Can you point me out on who to test it? Thanks in advance,

[LorenzoBianconi]

@eSoares @julianocss can you please try mt76-devel branch in my mt76 tree? (out of tree module)

[eSoares]

@LorenzoBianconi I tried it.

Under my desktop in kernel 5.4.0-58-generic gives the following error:

make: Entering directory '/usr/src/linux-headers-5.4.0-58-generic'
  CC [M]  /storage/linux-drivers-tests/mt76/mt7603/init.o
/storage/linux-drivers-tests/mt76/mt7603/init.c: In function 'mt7603_register_device':
/storage/linux-drivers-tests/mt76/mt7603/init.c:536:2: error: implicit declaration of function 'tasklet_setup' [-Werror=implicit-function-declaration]
  536 |  tasklet_setup(&dev->mt76.pre_tbtt_tasklet, mt7603_pre_tbtt_tasklet);
      |  ^~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [scripts/Makefile.build:275: /storage/linux-drivers-tests/mt76/mt7603/init.o] Error 1
make[1]: *** [scripts/Makefile.build:522: /storage/linux-drivers-tests/mt76/mt7603] Error 2
make: *** [Makefile:1757: /storage/linux-drivers-tests/mt76] Error 2
make: Leaving directory '/usr/src/linux-headers-5.4.0-58-generic'

Under my RPI with kernel 5.4.79-v7l+:

make: Entering directory '/usr/src/linux-headers-5.4.79-v7l+'
  CC [M]  /home/pi/linux-driver/mt76/mt76x0/usb.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x0/usb_mcu.o
  LD [M]  /home/pi/linux-driver/mt76/mt76x0/mt76x0u.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x0/init.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x0/main.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x0/eeprom.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x0/phy.o
  LD [M]  /home/pi/linux-driver/mt76/mt76x0/mt76x0-common.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/eeprom.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/mac.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/init.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/phy.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/mcu.o
  LD [M]  /home/pi/linux-driver/mt76/mt76x2/mt76x2-common.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/usb.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/usb_init.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/usb_main.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/usb_mac.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/usb_mcu.o
  CC [M]  /home/pi/linux-driver/mt76/mt76x2/usb_phy.o
  LD [M]  /home/pi/linux-driver/mt76/mt76x2/mt76x2u.o
  AR      /home/pi/linux-driver/mt76/built-in.a
  CC [M]  /home/pi/linux-driver/mt76/mmio.o
  CC [M]  /home/pi/linux-driver/mt76/util.o
  CC [M]  /home/pi/linux-driver/mt76/trace.o
  CC [M]  /home/pi/linux-driver/mt76/dma.o
  CC [M]  /home/pi/linux-driver/mt76/mac80211.o
/home/pi/linux-driver/mt76/mac80211.c: In function 'mt76_phy_init':
/home/pi/linux-driver/mt76/mac80211.c:286:31: error: 'NL80211_EXT_FEATURE_AQL' undeclared (first use in this function); did you mean 'NL80211_EXT_FEATURE_TXQS'?
  wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_AQL);
                               ^~~~~~~~~~~~~~~~~~~~~~~
                               NL80211_EXT_FEATURE_TXQS
/home/pi/linux-driver/mt76/mac80211.c:286:31: note: each undeclared identifier is reported only once for each function it appears in
/home/pi/linux-driver/mt76/mac80211.c: In function 'mt76_airtime_report':
/home/pi/linux-driver/mt76/mac80211.c:763:12: error: implicit declaration of function 'ieee80211_calc_rx_airtime'; did you mean 'ieee80211_check_tim'? [-Werror=implicit-function-declaration]
  airtime = ieee80211_calc_rx_airtime(dev->hw, &info, len);
            ^~~~~~~~~~~~~~~~~~~~~~~~~
            ieee80211_check_tim
cc1: all warnings being treated as errors
make[1]: *** [scripts/Makefile.build:266: /home/pi/linux-driver/mt76/mac80211.o] Error 1
make: *** [Makefile:1732: /home/pi/linux-driver/mt76] Error 2
make: Leaving directory '/usr/src/linux-headers-5.4.79-v7l+'

I'm not well versed in kernel development to solve this. If you can point me in anyway to be able to compile and run it I will try.

[LorenzoBianconi]

On Fri, Dec 18, 2020 at 6:43 PM eSoares notifications@github.com wrote:

@LorenzoBianconi https://github.com/LorenzoBianconi I tried it.

Under my desktop in kernel 5.4.0-58-generic gives the following error:

make: Entering directory '/usr/src/linux-headers-5.4.0-58-generic' CC [M] /storage/linux-drivers-tests/mt76/mt7603/init.o /storage/linux-drivers-tests/mt76/mt7603/init.c: In function 'mt7603_register_device': /storage/linux-drivers-tests/mt76/mt7603/init.c:536:2: error: implicit declaration of function 'tasklet_setup' [-Werror=implicit-function-declaration] 536 | tasklet_setup(&dev->mt76.pre_tbtt_tasklet, mt7603_pre_tbtt_tasklet);

you need to update your kernel

  |  ^~~~~~~~~~~~~

cc1: all warnings being treated as errors make[2]: [scripts/Makefile.build:275: /storage/linux-drivers-tests/mt76/mt7603/init.o] Error 1 make[1]: [scripts/Makefile.build:522: /storage/linux-drivers-tests/mt76/mt7603] Error 2 make: *** [Makefile:1757: /storage/linux-drivers-tests/mt76] Error 2 make: Leaving directory '/usr/src/linux-headers-5.4.0-58-generic'

Under my RPI with kernel 5.4.79-v7l+:

make: Entering directory '/usr/src/linux-headers-5.4.79-v7l+' CC [M] /home/pi/linux-driver/mt76/mt76x0/usb.o CC [M] /home/pi/linux-driver/mt76/mt76x0/usb_mcu.o LD [M] /home/pi/linux-driver/mt76/mt76x0/mt76x0u.o CC [M] /home/pi/linux-driver/mt76/mt76x0/init.o CC [M] /home/pi/linux-driver/mt76/mt76x0/main.o CC [M] /home/pi/linux-driver/mt76/mt76x0/eeprom.o CC [M] /home/pi/linux-driver/mt76/mt76x0/phy.o LD [M] /home/pi/linux-driver/mt76/mt76x0/mt76x0-common.o CC [M] /home/pi/linux-driver/mt76/mt76x2/eeprom.o CC [M] /home/pi/linux-driver/mt76/mt76x2/mac.o CC [M] /home/pi/linux-driver/mt76/mt76x2/init.o CC [M] /home/pi/linux-driver/mt76/mt76x2/phy.o CC [M] /home/pi/linux-driver/mt76/mt76x2/mcu.o LD [M] /home/pi/linux-driver/mt76/mt76x2/mt76x2-common.o CC [M] /home/pi/linux-driver/mt76/mt76x2/usb.o CC [M] /home/pi/linux-driver/mt76/mt76x2/usb_init.o CC [M] /home/pi/linux-driver/mt76/mt76x2/usb_main.o CC [M] /home/pi/linux-driver/mt76/mt76x2/usb_mac.o CC [M] /home/pi/linux-driver/mt76/mt76x2/usb_mcu.o CC [M] /home/pi/linux-driver/mt76/mt76x2/usb_phy.o LD [M] /home/pi/linux-driver/mt76/mt76x2/mt76x2u.o AR /home/pi/linux-driver/mt76/built-in.a CC [M] /home/pi/linux-driver/mt76/mmio.o CC [M] /home/pi/linux-driver/mt76/util.o CC [M] /home/pi/linux-driver/mt76/trace.o CC [M] /home/pi/linux-driver/mt76/dma.o CC [M] /home/pi/linux-driver/mt76/mac80211.o /home/pi/linux-driver/mt76/mac80211.c: In function 'mt76_phy_init': /home/pi/linux-driver/mt76/mac80211.c:286:31: error: 'NL80211_EXT_FEATURE_AQL' undeclared (first use in this function); did you mean 'NL80211_EXT_FEATURE_TXQS'? wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_AQL); ^~~~~~~ NL80211_EXT_FEATURE_TXQS

you need to update mac80211 source code I would suggest you to use OpenWrt

Regards, Lorenzo

/home/pi/linux-driver/mt76/mac80211.c:286:31: note: each undeclared identifier is reported only once for each function it appears in /home/pi/linux-driver/mt76/mac80211.c: In function 'mt76_airtime_report': /home/pi/linux-driver/mt76/mac80211.c:763:12: error: implicit declaration of function 'ieee80211_calc_rx_airtime'; did you mean 'ieee80211_check_tim'? [-Werror=implicit-function-declaration] airtime = ieee80211_calc_rx_airtime(dev->hw, &info, len); ^~~~~~~~~ ieee80211_check_tim cc1: all warnings being treated as errors make[1]: [scripts/Makefile.build:266: /home/pi/linux-driver/mt76/mac80211.o] Error 1 make: [Makefile:1732: /home/pi/linux-driver/mt76] Error 2 make: Leaving directory '/usr/src/linux-headers-5.4.79-v7l+'

I'm not well versed in kernel development to solve this. If you can point me in anyway to be able to compile and run it I will try.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openwrt/mt76/issues/470#issuecomment-748225465, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOA2CPVX3H5XP7ECJPMRW3SVOIC3ANCNFSM4TH4L3UA .

-- UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep

[julianocss]

Hi @LorenzoBianconi

I compiled the driver using the link you sent, everything is working fine.

Thank you. Juliano