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.
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).
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).
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:
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.
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.
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).
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.
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.
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.
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.
Without any info of your clients RSSI -52, -66, -74, -92, -68, -56 looks better then RSSI -68, -92,- 96, -62
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.
