MT6000 custom build with LuCi and some optimization - kernel 6.6.x

[Wevik]

Hello
On the latest firmware version, I experience periodic failures of the 5GHz module (I have about 5 clients on it, but only one of them is active). How long did it take for the router to cope on its own and reboot the module? But today I had to turn off the power to get the module to work again.
In the logs I see this error:
phy0 L1 SER recovery start.

Unfortunately, after a reboot, the rest of the error is not visible (it looks like the log is cleared).
This problem is discussed here:

mt798x: Crash with `multicast_to_unicast_all` set

I'm just wondering if anyone knows anything about this problem and if there is a solution?
P.s.: Multi To Unicast - is OFF.

[SebTM]

Hey, did you have a chance to check if you could limit the root-fs size in your builds? (Accessing a data partiton on the 8 GB of eMMC on GL.iNET Flint 2 (GL-MT6000) - #6 by zhaojh329)

I really like the device but I find it kind of scary to have a random amount of data lost on upgrade as the rootfs is bigger then the ram?

I would like to see a limit of 512-768MB maybe? (not sure if that's the best)

[mcmas]

same here @pesa1234 , check log on tg.

[_FailSafe]

@pesa1234 I'm seeing the same issue with r2.6. Though the recovery seems to be occurring fine in my case. Here's a snippet from my kernel log:

[15373.119811] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000004
[15373.126709] mt798x-wmac 18000000.wifi:
[15373.126709] phy0 L1 SER recovery start.
[15373.135200] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000008
[15373.151325] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000010
[15373.158252] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000020
[15373.166614] mt798x-wmac 18000000.wifi:
[15373.166614] phy0 L1 SER recovery completed.
[36552.500745] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000004
[36552.507630] mt798x-wmac 18000000.wifi:
[36552.507630] phy0 L1 SER recovery start.
[36552.516050] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000008
[36552.532166] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000010
[36552.539088] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000020
[36552.547442] mt798x-wmac 18000000.wifi:
[36552.547442] phy0 L1 SER recovery completed.
[76257.743417] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000004
[76257.750297] mt798x-wmac 18000000.wifi:
[76257.750297] phy0 L1 SER recovery start.
[76257.758734] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000008
[76257.775041] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000010
[76257.781954] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000020
[76257.789710] mt798x-wmac 18000000.wifi:
[76257.789710] phy0 L1 SER recovery completed.
[76922.543059] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000004
[76922.549940] mt798x-wmac 18000000.wifi:
[76922.549940] phy0 L1 SER recovery start.
[76922.558364] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000008
[76922.570863] mt798x-wmac 18000000.wifi: Message 00005aed (seq 13) timeout
[76922.574416] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000010
[76922.584529] mt798x-wmac 18000000.wifi: phy0 SER recovery state: 0x00000020
[76922.790544] mt798x-wmac 18000000.wifi: send message 00005aed timeout, try again(1).
[76922.799322] mt798x-wmac 18000000.wifi:
[76922.799322] phy0 L1 SER recovery completed.

Can anyone still running r2.4 confirm that these same events are NOT occurring?

[mcmas]

Let's wait for him, I've already told him what problems I've been having since yesterday. surely he will do his usual magic and resolve in 10 min @pesa1234

[di_Niko]

I dont have them…

[_FailSafe]

On r2.4 or r2.6?

[nxhack]

Please check this value.

cat /sys/devices/virtual/net/br-lan/lower_phy0-ap0/brport/multicast_to_unicast

Normally this would be the value in /etc/config/wireless, but for some reason it seems to be '1'.

I explicitly set it to '0'.

echo 0 > /sys/devices/virtual/net/br-lan/lower_phy0-ap0/brport/multicast_to_unicast
echo 0 > /sys/devices/virtual/net/br-lan/lower_phy0-ap1/brport/multicast_to_unicast
echo 0 > /sys/devices/virtual/net/br-lan/lower_phy1-ap0/brport/multicast_to_unicast
echo 0 > /sys/devices/virtual/net/br-lan/lower_phy1-ap1/brport/multicast_to_unicast

[Wevik]

Yes, I know. I have it disabled. I wrote about this.

[di_Niko]

The latest published by pesa, not quite sure about build number..

[Gingernut]

As nxhack said, you need to set it manually as luci setting doesn't change this.

[Kyle94]

Having some strange issue..vht on 2g,ibf,and tut options disappears after sometime installing the build..Any fix?

[pesa1234]

Can you tell me if the issue is coming only in latest release?

@_FailSafe can you compile 2.7 branch and let me know if have same issue

[Kyle94]

Yes sir..issue is present on latest release
Edit:I received the router 2 days ago and I think the issue was present in previous release too,I could be wrong tho

[Wevik]

Thanks. So it turned out to change.
Hope this helps.

[pesa1234]

Dear. I'm out this weekend.
If you tell me which version are getting this error I will be more faster...

Precise and detailed feedback are appreciated...

Also all previous are affect means nothing.

If you have time to compile let me know if 2.7 is affected.

Thanks

[pesa1234]

Clear your browser cache.

[_FailSafe]

Hey @pesa1234, I'll compile r2.7 shortly and give it a test. If the issue still presents, I'll switch back to an r2.4 build to see if it is there. Will report back here with confirmation ASAP.

@nxhack

Normally this would be the value in /etc/config/wireless, but for some reason it seems to be '1'.

@nxhack This is really interesting. On my APs I am seeing the same, despite having 'Multi to Unicast' disabled from a UI perspective:

for val in $(ls /sys/devices/virtual/net/br-lan/lower_phy*/brport/multicast_to_unicast); do
    echo "$val = $(cat $val)"
done

/sys/devices/virtual/net/br-lan/lower_phy0-ap0/brport/multicast_to_unicast = 1
/sys/devices/virtual/net/br-lan/lower_phy0-ap1/brport/multicast_to_unicast = 1
/sys/devices/virtual/net/br-lan/lower_phy0-ap2/brport/multicast_to_unicast = 1
/sys/devices/virtual/net/br-lan/lower_phy1-ap0/brport/multicast_to_unicast = 1
/sys/devices/virtual/net/br-lan/lower_phy1-ap1/brport/multicast_to_unicast = 1

I find this particularly interesting because I had raised this issue in the mt76 repo some time back: https://github.com/openwrt/mt76/issues/866

But despite the values I am seeing (posted above), I am no longer seeing the mt76 driver crashes. I'm perplexed at the moment.

I was under the impression that setting "Multi to Unicast" via the UI would append multicast_to_unicast_all='1' to one's wireless config for the given SSID. That then gets parsed via hostapd. So is it possible that the bridge-level multicast_to_unicast value is separate and distinct from the enablement of multicast_to_unicast within the wireless stack?

[_FailSafe]

All:
If you're going to report an issue with a build, it really should go without saying that you need to 1) know what build you're on and 2) include that build number in your issue statements.

Pesa already alluded to this as well.

If you're not sure if you're on r2.4, r2.6, r2.7, etc.. then at least include the BUILD_ID with your post. This is the number you see on the OpenWrt login banner each time you SSH into your device. It can also be found via: cat /etc/os-release | grep BUILD_ID.

e.g.:

root@AP:~# cat /etc/os-release | grep BUILD_ID
BUILD_ID="r26906-9036108abb"

[EXREYFOX]

Can @pesa1234 add this package Qosify: new package for DSCP marking + cake to your build