Archer C50 v4 Mac80211 Loses Internet Access after 20'+ Away from Router But Maintains Connection

Issue: Wireless device can connect to 2.4G Radio and access internet when next to the router. Once i start walking away within the same room, speed degrades drastically (15mb down to 2mb). I walk a step or 2 further and no internet but connection stays. At this distance, i'll manually disconnect from the router on my device, then try to reconnect but my device thinks i have the wrong password.

The symptoms happen with multiple routers at different physical location as i have the same router model and same firmware version installed in multiple locations in the city.

Device: TP-Link Archer C50 v4 (Canadian HW version).
Firmware : 19.0.7 stable release.

Wireless Config:
I've intentionally left encryption set to "none" for both radio's for quick testing.

onfig wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/10300000.wmac'
option htmode 'HT20'
option legacy_rates '0'
option country 'CA'

config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'none'

config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11a'
option path 'pci0000:00/0000:00:00.0/0000:01:00.0'
option htmode 'VHT80'
option channel '112'
option legacy_rates '0'
option country 'CA'

config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'none'

I'm exhausted from trying different wifi settings and research, learning and more research.

EDIT : I changed radio0 "hwmode" from 11g to 11n and it appears to have resolved my problems. Will have to do some more speeds test to ensure it wasn't a fluke.

EDIT 2 : I can consistently get positive results with the 11g to 11n change.

EDIT 3 : 11n value was just a fluke as it isn't a valid value to use. " possible values are 11b , 11g , and 11a".

1 Like

fwiw, I note you are using country code CA. Could it possibly be related to the hostapd 2.9 bug which was recently fixed after 19.07.0 was released?

Have you tried the latest development snapshot (no LuCI) ?
https://downloads.openwrt.org/snapshots/targets/ramips/mt76x8/openwrt-ramips-mt76x8-tplink_archer-c50-v4-squashfs-sysupgrade.bin

I don't own a C50 v4 any more. A very early 19.07 snapshot (inc. LuCI) I last used can be found below if you wish to try it. It predates the hostapd 2.9 bug.

openwrt-19.07-snapshot-r10269-5100629e32-ramips-mt76x8-tplink_c50-v4-squashfs-sysupgrade.bin

https://www.dropbox.com/sh/2j6v8b8gjafcal2/AABcCZ56zQ4nxXu15fMTHhODa?dl=0
Download the zip and look in the 'original-sysupgrade.bin' folder.

Same Problem with C50 v4 EU version. 5GHz works, 2.4 only at very close range.

Changing the channel width to 40MhZ seems to fix the issue. You may have to force 40MhZ channelwidth until someone finds the root cause of this.
`
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'platform/10300000.wmac'
option country 'DE'
option channel '8'
option log_level '0'
option legacy_rates '0'
option htmode 'HT40'
option noscan '1'

config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option disassoc_low_ack '0'
option ssid 'XXXXXX'
option encryption 'psk2'
option log_level '0'
option dtim_period '1'
option short_preamble '0'
option key '********'
option skip_inactivity_poll '1'
option wmm '0'
`

As in can't figure out how to edit my original post, EDIT 2 should read "I can't consistently get positive results with the 11g to 11n change.".

Hi bill888,

Hostapd 2.9 bug you say...? I haven't ventured down that rabbit hole yet and would be a good idea to keep the link handy for future troubleshooting. I'll try and change country code to a USA to see it its isolated to just CA.

I can't recall if i tried the latest development snapshot or not during my whirlwind of troubleshooting. I have tried the oldest 19.07 snapshot i have, which is r10532, but the one you linked to is even older, which i great as its provide me another avenue to go down.

Silver lining...i'm forced to get familiar troubleshooting tools rather just being an end-user of a product.

You wouldn't happen to have the imagebuilder file for r10269 too would you? If so, can you also upload to dropbox and provide link. I'm buiding images with packages.

Thanks for the lead bill888.

Thanks for the suggestion sgrefen, i'm sure i tried forcing it to 40Mhz but it may have been mixed with other setting changes.

To edit a previously created post, look at the bottom of the post where you see 'Reply' button on right hand side. To the left, click on the pencil symbol to edit the post.

Sorry, I don't have any other files other than 19.07 r10269 snapshot I downloaded at the time.

For unknown reason, the pencil does not show up for my original post as its does for a reply within the thread.

Using latest 19.07 snapshot (r12126) and default settings aside from Country Code CA has no positive results.
Same setting as above with Force 40Mhz setting as 1 does not produce any positive results.

Next up, trying bills888 19.07 rrc10269 snapshot.

bills888 19.07 rc10269 snapshot did not fix it either.

Thanks for testing. Does the problem affect more than one 2.4 GHz wifi device? (eg. phone, laptop etc)

It may be a good idea for you to raise a bug report if more than one device is affected.
https://bugs.openwrt.org/

I have the same problem and it affects multiple devices. I manged to improve it a bit by setting "Advanced Settings" > "Distance Optimization" to 15 under the connection settings, greater values didn't improve it any more.
The signal range was not a problem before flashing OpenWRT, but since the LAN and WAN ports are not working I'm now better off than before.

Did OP open a bug report already?

The issue isn’t isolated to a single device in my experience (android and iOS phone + laptop)

I’ve yet to properly submit a bug report. Feel free to submit one ahead of me. Please reply with a link if you do and I’ll do the same (if one hasn’t been submitted)

I can confirm that I am seeing the same symptoms on my Archer C50 v4.1 EU. If I place it 5 metres away from the laptop in the same room, I can't really connect to it any more on 2.4GHz. Changing the channel to 40MHz does seem to improve things, and I can now connect from the next room through one wall - but it is still not working at full power.

I have another TP-Link TL-WR841N with OpenWRT in the same position - and the 841N is showing 94% signal, while the C50 is showing only 72% signal - so something is definitely not working properly. On top of that, the C50 is the more modern device, with better hardware - so it should have even better signal than the 841N.

The C50 is on the 19.07.0 sysupgrade image.

Bug 2781 report created.

I am also seeing something like this, however I am hesitant to join the pool of people reporting this issue, as I'm using a C50 v5 US router. (I just got one of those, opened it up, messed around with the console a bit, concluded that it is virtually identical as a v4, went ahead and flashed a v5 header+bootloader with a v4 OpenWRT image - works great except 2.4GHz)

However, my findings diverge a bit. I can get a signal on most of my devices, although not great. My main problem (and I had to revert to stock because of this) is that I have a bunch of ESP8266-based IoT stuff that literally does not want to connect to the 2.4G radio at all, even close up. Those devices operate poorly even with the stock firmware.

I'm just thinking that this Wi-Fi chipset is problematic and there's no way out. I've gone as far as getting a hold of one of the original v4 port images which is probably 1.5 years old, but still exhibits weird performance issues.

I read things like "try the newest version", however, if this is a new issue does anyone have any clue as to when this started, or has it just been like this forever?

Your problem with the V5 might be related. Take a look at the bug report, the problem might be with the driver mt76.

Oh, I am sure it is as it is the same hardware as far as i can tell (except for the PCB itself), I've seen the report and I'm following some issues directly at the mt76 development repository, however I'd like to try to pinpoint a report from someone that indicates when this all started

I opened a bug report on the kernel mail list: https://bugzilla.kernel.org/show_bug.cgi?id=206363
It really seems that it's a driver issue. The sotck firmware uses 2.6.36 but I don't know if it is the vanilla version or if it has patches.

All help is welcome. Everyone feel free to try to compile and test other kernel versions.

Forgot to meantion:
It would be great if someone with a JTAGed router or with experience in debricking could help test a possible kernel patch and/or other kernel versions. This is my first time using Open Wrt.

If you download the stock firmware source code, under the directory mtk_ApSoC_4320/linux-2.6.36.x/drivers/net/wireless/MT7612/mcu/bin/ there is a bunch of binary firmware files for which there seems to be no source. My guess is that putting one of those under /lib/firmware on the router might solve the problem. Specifically, the MT7610.bin, mt7612_patch_e1_hdr.bin and mt7612_patch_e1_hdr_0417.bin, perhaps changing the names a bit to match the files already present.

I think the firmware/eeprom might be the source of the problem because this recent kernel patch to a driver of the same family says that setting it through the eeprom might not be enough and that one might need to use firmware resources.

Unfortunately the ethernet ports on my router are fried, thus why I'm using Open Wrt. If it bricks I have no way of recovering it.
Could anyone please attempt that and see if it fixes the problem? Those firmwares are for 2.6.36 and we are dealing with 4.14.162 here, so it's a long shot.

I do realize I might be asking you to run proprietary software, but it is for debugging purposes.

===============================================================

I can't post new replies so I will just append stuff here.

I just noticed that on LuCI radio1 (5GHz) is reported as MediaTek MT76x2E 802.11nacwhile radio0(2.4GHz) is Generic 802.11bgn. Anyone has any thoughts on this?