wifi struggling on some devices about glibc_ddwrt

[i3roly]

i looked at what part of the code that error came from, and it's a rather mundane function that applies generally to the AP support:

https://github.com/hanwckf/rt-n56u/blob/d515edd9a6f9194f80c1b1edf8fa46f668e14cbb/trunk/proprietary/rt_wifi/rtpci/5.0.5.1/mt7615/embedded/common/bcn.c#L1825

it's possible that your thermostat is screwing up the beacon stuff but i'm not sure. sounds like you'd have to remove it from the network to eliminate that possibility.

i'm going to upload a new build in a little bit here with a slightly newer ramcode that the developer (For an unexplained reason) reverted:

hanwckf/rt-n56u@cbadfe5#diff-2d58ba5a1f6de327b80fd0bed8e310b2cad104f046c06d60289294a2e2405306

maybe it will fix things, maybe not. it sounds like the issue is at the 'lower level'.

i am not sure if openwrt works because i am unable to interpret your comment as to having tried it or not, but i suspect if it is present on openwrt then it has something to do with the firmware.

either way i don't think i can do much about this because i don't use a smart thermostat, and i have changed very little (if anything) that would have caused this to come up.

the fact you didn't see it for 3 days and then it started happening tells me it is something at the lower level.

sorry i couldn't be of more help

[markolonius]

update. I got rid of the thermostat, didn't make a difference. figured out it was only the 2.5Ghz causing the problem (ra0). I disabled it and the error I had in the logs went away. re-enabled it and disabled TurboQAM (QAM256) support, Short GI,
U-APSD (Automatic Power Save) that were enabled for some reason and haven't had the problem yet. Time will tell. Thanks.

[i3roly]

256qam, uapsd, and shortgi are enabled by default.

maybe i'll disable them by default in the future, but surprised either of those would be causing the problem.

i doubt it was any of those if you're on 143. it will probably be back in a few days again just like last time, and i suspect the only reason it's not back yet is due to the ramcode change.

[markolonius]

You are right. problem is already back. With vengeance too even more this time.

I'm actually still suspicious that my hardware is failing. If it were ramcode change this wouldn't have happened suddenly after being on one of your builds for solid 1-2 years without issue.

I saw https://github.com/Nossiac/mtk-openwrt-feeds/issues/26 with similar errors except for 5G instead of 2.4G like mine.

Also, googling around saw https://www.right.com.cn/forum/thread-986195-1-1.html and with translate it looks like its CPU that's dying maybe. They say CPU 'change' on the form from google translation so no idea.

Someone here https://github.com/openwrt/mt76/issues/110 had same error, but later said they fixed it without telling how or any info. so that's lame and not helpful.

think i'm going to give up and buy a new router.
thanks for your help.

[i3roly]

it's possible, but hardware failures are very rare.
i personally haven't seen that error.

have either of you managed to try 146 and see if the issue regarding the interface name is fixed?

[i3roly]

@markolonius it's possible that maybe the antenna cables or something are loose. if it was a CPU failing or hardware failure i think both rai0 and ra0 would report this issue.

i have no issues on 2.4ghz which suggests to me that it's possibly something to do with a loose cable or something. it could be dying, yes, but that's so rare. i've abused my router pretty badly (rewrote nand with firmware thousands of times) and it is still kicking.

it has to be something related to your region and stuff. have you tried a different region setting?

[i3roly]

@markolonius i looked at the code again and it's possible the next build i am going to upload (in a little bit) could fix your issue.

while i haven't esxperienced this problem, i did note a slight issue with one naming for the calibrated bin files.

i don't know if this will make a difference. you can try the build that's gonna be up in 20 or so minutes to see if it will alleviate the issue, but it may not.

either way i thought i'd let you know

[markolonius]

New build still has the issue when I just do upgrade. I tried factory-to-ddwrt your newest build from factory d-link firmware, however couldn't get it to boot properly and couldn't get an IP.
I just opened her up and the cables are secure and board looks clean.
Not sure where to change the region? I could give it a try.
This makes it hard since you can't reproduce the error. Thanks for the efforts.

[i3roly]

what country are you from?

use the nvram "region" variable.

the available regions are "EU" "DE" "RU" "AP" (KR) "JP" "GB"/"IE"/"IM" "CA" "US"

is your country missing? i am thinking since this is only caused on one band it's possible you're trying to use a radar region that is prohibited or something.

have you tried to use a common 2.4 ghz channel like 1/6/11 instead of autochannel? these are some things worth trying.

maybe i'll add an option to the webgui for regulatory domain but since i don't have the full country list implemented, it may be tedious.

[markolonius]

Im in "US".

This problem happens across the board on d-link factory, openwrt, and dd-wrt. Not really sure if region would cause this. I'll be able to give it a try tomorrow evening. I'll try common channels as well.

[i3roly]

then it probably is the board, sorry to hear that.

hopefully you can find an 882 for cheap ;) or a 2640 or 3040.

i think the 3040 is my personal masterpiece, but i didn't need three bands.

edit: i'd be dying without usb3 storage tbh. i don't know how you do it