additional eeprom value - per forum post https://forum.openwrt.org/t/…

[ronasimi]

…archer-c50-v4-mac80211-looses-internet-access-after-20-away-from-router-but-maintains-connection/53575/49

[namidairo]

Does the vendor driver also do this or does it just... assume that the section is intact and skip a couple bytes before parsing?

Odd.

Either way, you might want to amend the commit name from additional eeprom value - per forum post... to something like mt7603: Allow eeprom sections starting with 7600 or something and add a brief description of why a couple lines down.

Ie.
git commit --amend
Then force push to your branch?

[dtrautmann]

Thanks, this is exactly what I did to fix the weak 2.4G signal on my devices.

[PsychoGame]

This fix is tested by me on actually 7 Archer C50 v4's. The patch does exactly what the committer said, fix the poor 2.4GHz signal on these routers. Without this patch signal on my clients is constantly dropped. 5GHz has a further range than 2.4GHz which shouldn't normally be the case.

[rotanid]

@nbd168 can you please consider this patch?

[ronasimi]

I finally got around to testing this myself. Works well, 2.4 GHz seems to be working as it should.

[Parabol1337]

can you please consider this patch?
i have 10 devices with this problem.... the fix works fine

[adschm]

@ronasimi Please also change the PR title to make this easier to find.
@nbd168 I also have this issue and would be happy if the fix was merged.

[ggbruno]

Just a note on the problem...
The problem is related to a wrong burn in eeprom of Archer C50v4. It did not burn the first byte of eeprom (thats why the 28 went as 00). Newer Archers C50v4 already fix that.
TPLink did not fix because the vendor driver have a "fallback" feature. If it cant recognize the eeprom, it uses an internal eeprom in the driver (which, for ArcherC50, is the same calibration as a "working" eeprom)...
The problem is that we can have this problem in the future... If TPLink burn the eeprom header wrongly again, the vendor driver will still be working... Maybe we can work on a more long term solution, like the fallback eeprom that the vendor driver have....

[adschm]

@ronasimi This patch lacks a Signed-off-by, so it actually cannot be merged in the current state. Apart from that, please wrap the lines in your commit message after 74 chars.

[namidairo]

There's a more style-compliant looking version of this on the linux-wireless mailing list at the moment, with a little bit of discussion as well.

https://patchwork.kernel.org/project/linux-wireless/patch/20201013142326.8361-1-mail@david-bauer.net/

[adschm]

There's a more style-compliant looking version of this on the linux-wireless mailing list at the moment, with a little bit of discussion as well.

https://patchwork.kernel.org/project/linux-wireless/patch/20201013142326.8361-1-mail@david-bauer.net/

Ah, perfect, so we will get it in mt76 anyway when it's merged there.

[adschm]

Merged in 9a1a0a4.

[Pilabol]

I installed openwrt (version 21.02.3 and 22.03.rc4), on Arche C50v4. For a while it worked great! However, after a while the 2.4ghz wifi disappeared and the connected equipment could no longer be found. I couldn't find a frequency or extado monent. It used to occur when data consumption increased (donwloado in pc, use of tv and cell phones at the same time). Can anyone help?

[rotanid]

@Pilabol maybe try rc3, i know of a bug in rc4 which maybe could also effect you

[Pilabol]

@rotanid there is a bug reporter here openwrt/openwrt#10074