Weak signal on a rt305x travel router

I installed OpenWrt 18.06.8 on this rt305x 1t1r TEW-714tru. For basic stuiff it's working fine except for the coverage: even sitting 3m appart in the same room gives me frequent disconnections unless I uncheck "Disassociate On Low Acknowledgement". For reference, here is the signal strenght the device is seeing:

Funny thing, even though the datasheet states 20dBm max power, selecting USA domain allows me to set 30dBm. And as a matter of fact, leaving Tx power to "auto" supposedly forces that level. Even with that setting, the received power on the Clients varies between -90db and -50db around the home.
Before starting jumping across different OpenWrt versions, or going back to stock firmware, I would like to know which driver version is this currently running, and which OpenWrt version uses a newer and older driver.
Or is possible to apply some other tweaks to try to measure a difference?

All four of those clients are in the same room? The one at -60 is a good signal but the others are being received very weakly.

Concerns about txpower seem misdirected because is definitely transmitting better than it is receiving. This looks like hardware failure in the receiver. The definitive test for hardware failure is to go back to stock firmware.

1 Like

While in the same room the coverage is average (around -60dBm), but a single brick wall in-between turns the reception (from the viewpoint of the Clients) into a lousy -87dBm or "unavailable". The Clients are laptops, PCs, and smartphones. The behaviour is similar for all.

I have also tried switching Channels, but I don't see big difference on that.

I am increasing the txpower on the router to get at least "two bars" on the receivers in order to avoid them dropping the connection.

Before returning to stock firmware I wonder if there's a way to know which OpenWrt version uses which rt5350 wireless driver, so I can try that before returning to stock. (My main reason for using OpenWrt is to run some scripts with remote loging).


Those look like decent connection speeds for 802.11b and 802.11g connections

1 Like

And because OpenWrt was not straightforward for this device, what would be the best approach to return to stock firmware for it? In order to have OpenWrt running, I had to -F all the sysupgrades. Shall I force the sysupgrade to flash the stock .bin? or by tftp? In some pages I read it's needed to strip some Bytes from the header first, whereas in others read it's not needed anymore.

From the viewpoint of the router, seems the downlinks could have a decent G rate, but the uplinks just the basic B rates. From the viewpoint of the clients not in the same room, the reception is marginal, and suffer frequent disconnections.

But even though a link is a two-way connection, if the clients sense too low rx_power it will drop the connection (regardless the UL could theorically still be feasible).

Any reason you are not forcing 802.11n only?

Hmmm. Now you mention it, I re-disabled "allow legacy 801.11b rates" on LuCI, but on the "General" tab LuCI offers me set "Legacy" or "N" mode. Of course I selected "N"
but to be sure, I checked via CLI, and found something weird:

config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'platform/10180000.wmac'
option htmode 'HT20'
option country 'US'
option log_level '4'
option txpower '20'
option channel '1'
option legacy_rates '0'

So I set it to "11n" via uci, commit, and now I look this:

Which for moments improves a little. I'll keep watching for stability and rates.

It's possible that your router use not MAIN antenna but AUX. rf5350 support software antenna switching but current driver always use MAIN. I can build test firmware if you ready to try.

1 Like

Oh, that could explain this!

If you have the time for build an image, please do so, thanks. I'm open to try whatever version (from LEDE 17.01.1 onwards) you think it's best for this single-port 8/32 device. Main config mods I've done: disable IPv6 and PPP, WAN->eth0.1, LAN->wlan0, disable disassociate on low ACK, disable legacy rates, set 11n mode, and some sripts. That leaves free ~4/6. I haven't messed with the USB port yet.

BTW: I don't know why I've allways have to force the sysupgrade. I also don't know the best approach for eventually returning to stock in this case (force, tftp, hexedit and mtd, others) for what @mk24 suggested.


This will explain why you don't see 11n

Changed 3 years ago by jow

  • Resolution set to not_a_bug
  • Status changed from new to closed

Expected, config changed. 11g / 11a selects the band, htmode NOHT disables 11n, htmode HT20 / htmode HT40 enables 11n

So I agree with the other guys: the upstream developers are not making our lifes easy with the naming/settings. But LuCI developers could help: For instance, why only having "N" and "Legacy" as choices; and what "Legacy" mode means then? b? so why not having a proper menu with b, g, n settings? (and translate that to 11g NOHT, 11g w/ HT20/HT40, and whatever the b option should be configured as).

Openwrt 19.07.2 for tew-714tru with patched rt2800lib.ko (antenna diversity) here:

Added LuCI package. AP mode with SSD "OpenWrt" w/o password activated by default. Pls test it.
EDIT. Patch included.

What other choices are you seeking?

No, legacy covered infrared and was interoperable...while B maxed to 54 Mbps.

Can you explain the material difference between G and N devices in context of post-legacy/post-B/post-G WiFi chips???

Maybe I'm lost here...

Also, running newer devices in B-mode today shouldn't be done on a shared channel and maybe considered illegal interference in some configurations and Nations if you intentionally set a device to do so.

EDIT: Oh, BTW, the setting you refer to is actually here, not where you noted:


The b rates use DSSS modulation which will "splatter" outside the 20 MHz or 4 channels normally occupied by a g or n signal. This box should be unchecked in nearly every installation except when:

  • b-only devices must be connected
  • very long range / weak signal links

When "legacy rates" are allowed all beacons are sent at 1 Mbps. This wastes air time and also encourages clients to connect from a longer distance than they should. If beacons are sent at 6 Mbps they are less detectable at excessive range.

1 Like

Oh, boy. So "Legacy mode" means 802.11, and "N mode" embraces 802.11b, 802.11g, and 802.11n (and I guess there should be the option for 802.11a and 802.11ac for devices that support those).

I suppose you meant 11Mbps for b, which was enhanced to 54Mbps for standard G.

IMHO "Legacy mode" shouldn't be an option nowadays, as I don't recall having seen an IR router, and I doubt such devices could be flashed to OpenWrt.

Please don't get me wrong: I don't want to argue with you guys, neither I want to flame the project. On the contrary, I appreciate what you're doing for the community, and I'm particularly liking this forum so far. I'm a networking person, not a software person, and I'm used to call the things like I've read at other places. And I don't recall the standards by heart, but I recall MIMO and OFDM as highlights of N opposed to G. Therefore for devices other than 1T1R like mine, setting G should modify some "antenna chain" (as how dd-wrt names that) as well as other parameters.

Maybe one of the documents of The World Congress on Engineering 2011
(http://www.iaeng.org/publication/WCE2011/WCE2011_pp1741-1744.pdf) can shed I light on this:

802.11n standard could be configured to operate in three modes; Legacy mode, Mixed mode and Greenfield mode. The Legacy mode allows a Wireless N router to work in a network of entirely legacy clients, i.e. 802.11a/b/g without any 802.11n clients as part of the network. The Mixed mode is used for networks with an 802.11n router and a mixed environment of 802.11n clients as well as legacy 802.11a/b/g clients. Greenfield mode is used for networks with only 802.1n clients connecting 802.11n routers. The highest performance is achieved with the Greenfield mode. Network performance is reduced slightly with the other modes due to compatibility issues that let 802.11n work with a protective mode.

So what I was trying to point-out on my previous posts is what I've seen on Stock firmware and other third-party firmware projects: to be able to carefully set the wireless mode in order to handle cases like my OP wireless issues.

Again, thank you all for your support so far. And @123serge123: Thanks for the build (already downloaded). I'm pretty busy now. I'll try in a few days and let you know.

Agree. And that's I was testing how allowing/disallowing that could improve my network.

Interesting. I didn't know that.

For what I'm seeing, I think my router is working better with b dissabled.

I upgraded to @123serge123's build. Configuring this traveler router on 19.07.2 from scratch was trickier than with 17.06.8. It's running now: with the default packages, the (cli) free RAM is 3MB, and as before, the default tx_power still matches the maximum allowed for each regulatory domain.

With the same settings as before, I don't see a big difference from the router viewpoint:

(being the last Client 1 yard appart).
Although I notice the measurements from the Clients looks better.
Now I wonder: was the patch or the version upgrade? Maybe I will have to try the unpatched version.
The other test would it be to return to the OEM firmware, but I still wonder whether sysupgrade -F stock wouild it be the right way to do it.

I'll keep looking for speed and stability.

Without any info of your clients RSSI -52, -66, -74, -92, -68, -56 looks better then RSSI -68, -92,- 96, -62 :slight_smile:
It was more clear if you compare RSSI for the same clients before and after installation the patched version.

So at least tx path becomes better without doubts. And the unpatched version data will be helpful. It's enough to force install kmod-rt2800lib from 19.07.2 openwrt repo.