Turn on packet steering problem solved
1 Like
Thanks, It worked
1 Like
I started the topic about the MX5300 a while ago. Does the firmware work on that device too?
I started it once because the lack of vlan on the default firmware.
going to read this threat, was away for a while on this topic.
PR is ready to be merged: https://github.com/openwrt/openwrt/pull/14051/
1 Like
So it appears that hardware is not locked to 17dBm after-all.
After a some 'fiddling about', trial and error. Phy2 is now working @25dbm (channel 100/5500mhz1) using stock OpenWrt snapshot:
ifindex 15
wdev 0x200000004
addr xx:xx:xx:xx
ssid ProBeerenGiraffe
type AP
wiphy 2
channel 100 (5500 MHz), width: 80 MHz, center1: 5530 MHz
txpower 25.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 139 0 0 0 0 23738 130
I did not alter regdb's or anything like that:
phy#2 (self-managed)
country GB: DFS-ETSI
I fairly new and flashed my MX4200 using this link https://openwrt.org/toh/linksys/mx4200_v1_and_v2#tab__oem_firmware
After doing this I can only SSH into the device, I cant access via web 192.168.1.1 like before, prior to installing openwrt (I can only SSH as root and see screen below any idea what I am doing wrong, should the gui be working or do i need to install it)
__
OpenWrt SNAPSHOT, r25077-d274867c21
__
Do you have internet on the newly flashed device?
If the router can access the internet then you can run the following commands via SSH
opkg update && opkg install luci-ssl && service uhttpd restart
This should install and start the webinterface, you want to use.
1 Like
Thank You for quick update, thats worked great (I guess I need to read up on openwrt a bit more 
Thanks again
1 Like
So what changes did you make? Are you using a BDF file from the OEM firmware?
I am using @lytr build on my MX4200v2. I could see the phy2 having txpower of 27dbm on channel 104:
phy2-ap0 ESSID: "Test5G-Phy2"
Access Point: XX:XX:XX:XX:XX:XX
Mode: Master Channel: 104 (5.520 GHz) HT Mode: HE80
Center Channel 1: 106 2: unknown
Tx-Power: 27 dBm Link Quality: 48/70
Signal: -62 dBm Noise: -108 dBm
Bit Rate: 1080.6 MBit/s
Encryption: WPA2 PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11ac/ax/n
Hardware: embedded [Qualcomm Atheros IPQ8074]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy2
Everything needed is contained withing recent/current 'official' snapshots from OpenWrt.
However a step-by-step approach and some patience, is necessary.
Preface/prerequisite:
I already had the workaround in place (this made Phy-0 and Phy-1) usable.
Further endeavors, getting Phy-2 working:
-- Set "GB United Kingdom" as Country-code:
What I noticed was that Phy2 would crash when anything other than GB (Great Britain) was set as the reg-domain. (otherwise the log pointed to a invalid reg-domain).
-- Channel Selection messed up:
Next what I encountered is that for Phy-2, anything above CH-44 would result in the radio being configured to use 6Ghz. Which obviously the radio can't do
Thus the log showed 'invalid channel selection'.
-- Using Conservative settings:
With the above in mind, I set Phy-2 to CH44 / 40mhz-Wide (just to be safe) . Again, with reg-domain set to GB for all radio's, and then restarted Phy2.
--cac_time=600s:
Log now showed that Phy-2 was performing DFS_CAC. Now, normally this takes 60seconds, but log showed it would take 10-minutes, I decided to wait.
About 10 Minutes Later Phy-2 was up and broadcasting SSID but signal was really weak.
Workaround-part-2:
Workaround was needed once more:
Recognizing the issue (Phy-2 TX-signal being really weak as the one mentioned on the Buffalo's Wikipage) I performed the workaround once-more, taking into account the changes I made the first time around:
mv /lib/firmware/ath11k/IPQ8074/hw2.0/cal-abh-c000000.wifi.bin /lib/firmware/ath11k/IPQ8074/hw2.0/_IGNORE_cal-ahb-c000000.wifi.bin
. /lib/functions/caldata.sh
FIRMWARE=ath11k/IPQ8074/hw2.0/board.bin caldata_extract "0:art" 0x1000 0x20000
reboot
After rebooting Phy-2 is perfectly usable.
The issue with channel selection (Phy2 being instructed to transmit at 6Ghz when - for instance- selecting channel 64) is gone. Selecting Channel 100 now results in radio actually working at 5500Mhz.
Furthermore the Phy2 will broadcast at a reasonable and usable 25dBm
Observations:
--So it seems that you need to get Phy2 in (basic/minimal) working order. That's a hard prerequisite; you have to get it working on a minimal (conservative) level in terms of settings.
--In short: the mechanisms involving firmware/data/drive loading seem a bit quirky; as seen (in this case) Phy2 needs to be in a (minimal) working state in order to feed it the factory calibration data.
-- Although this workaround extracts pre-caldata a the second time and rebooting is a necessity to make the device fully functional. The pre-caldata is not any different.
-- Thus(again) it seems that the (pre-)caldata when fed in to the BDF can only be of use if The Phy already is in a minimal working state.
-- Time for DFS_CAC may take 10 minutes , this is before you have applied 'Workaround-part2'; be patient wait for Phy2 to be enabled.
-- GB region means the MX4200 adheres to DFS-ETSI standards (at least after 'workaround-part-2' it does).
-- Have Patience and look at OpenWrt's log.
Using pre-caldata only is not a valid solution to the problem.
Everything on my MX4200 is working perfectly now, all the issues seen before are resolved.
If you don't think it is a valid solution, thats perfectly okay.
'Valid' or not, the method of applying the workaround in steps resolves the problems seen before.
Furthermore it enables WiFi to be used to it's full potential (within limits set by ETSI offcourse) so not limited to 17dBm.
I'm not going to argue this 'valid' or not discussion any further. Thanks.
--
(Should devs need further info on this, so that the MX4200 works out of the box i'm more than happy to help.)
You can try my latest build and see if WiFi is working properly:
Does the latest build bring any changes for MX4200v2 wifi?
Firstly great work to all.
If I download the two .bin from your repo (for v1)
- openwrt-qualcommax-ipq807x-linksys_mx4200v1-squashfs-factory.bin
- openwrt-qualcommax-ipq807x-linksys_mx4200v1-squashfs-sysupgrade.bin
Can I just update the version I have already installed using the same process see link below and them be uptodate (sorry newbee here )
https://openwrt.org/toh/linksys/mx4200_v1_and_v2#tab__oem_firmware 4
I wasn't sure what the file below was for if I also need to install it or not
openwrt-qualcommax-ipq807x-linksys_mx4200v1-initramfs-uImage.itb
No, just updated with main branch.
1 Like
If you have OEM firmware use openwrt-qualcommax-ipq807x-linksys_mx4200v1-squashfs-factory.bin image.
For upgrade from OpenWrt use openwrt-qualcommax-ipq807x-linksys_mx4200v1-squashfs-sysupgrade.bin.
Initramfs image openwrt-qualcommax-ipq807x-linksys_mx4200v1-initramfs-uImage.itb is used to run OpenWrt from RAM.
1 Like
I did, it functions identically to a Snapshot with the workaround/fix I shared earlier.
Actually I'm a bit surprised that you opinionated my findings and the workaround/fix as being 'invalid'.
I mean you actually used my findings / the workaround and included it in this commit you made on GitHub 3-days ago. In order to make your firmware-releases for the device function better.
So @lytr I'll just go ahead and thank myself then, on behalf of you, i guess.....
Previously, functions were added that can modify pre-caldata: https://github.com/openwrt/openwrt/pull/14512/commits/869925aabe81b3009afbe6e7efd0e0025c3d5437