682

Turn on packet steering problem solved

1 Like
683

Thanks, It worked

1 Like
684

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.

685

PR is ready to be merged: https://github.com/openwrt/openwrt/pull/14051/

1 Like
686

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
687

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
__

688

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
689

Thank You for quick update, thats worked great (I guess I need to read up on openwrt a bit more :slight_smile: Thanks again

1 Like
690

So what changes did you make? Are you using a BDF file from the OEM firmware?

691

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
692

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.

693

Using pre-caldata only is not a valid solution to the problem.

694

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.)

695

You can try my latest build and see if WiFi is working properly:

696

Does the latest build bring any changes for MX4200v2 wifi?

697

Firstly great work to all.

@lytr

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

698

No, just updated with main branch.

1 Like
699

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
700

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.....

701

Previously, functions were added that can modify pre-caldata: https://github.com/openwrt/openwrt/pull/14512/commits/869925aabe81b3009afbe6e7efd0e0025c3d5437