enjoy 
hopefully this will be fixed by the time you are back!
OK, I re-installed an old snapshot that I downloaded on Oct 12 and everything works again. The working snapshot is r27730-3d7040b7d6.
Luckily, I had a left-over copy on my laptop 
The latest snapshot from today (Oct 17 11:47:59) still does not work. Only phy2 (the 5 GHz radio) is initialised, but not phy0 or phy1.
It seems to me that under /sys/devices/platform/soc/11280000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0 are all files as in the "working" case, but I can't see any ieee80211/phy* dirs.
I hope this helps...
Hi,
if you look at the output of dmesg, you will find that one firmware file is missing in current snapshots:
[ 11.775001] mt7915e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240823172725a
[ 11.775001]
[ 11.877200] mt7915e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240823172741
[ 11.957618] mt7915e 0000:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20240823172837
[ 12.121544] mt7915e 0000:01:00.0: eeprom load fail, use default bin
[ 12.127923] mt7915e 0000:01:00.0: Direct firmware load for mediatek/mt7916_eeprom.bin failed with error -2
[ 12.137564] mt7915e 0000:01:00.0: Falling back to sysfs fallback for: mediatek/mt7916_eeprom.bin
[ 12.186005] mt7915e: probe of 0000:01:00.0 failed with error -12
Workaround: You can manually copy the file mt7916_eeprom.bin from an older/working snapshot or from MediaTek's OpenWrt feed website into the directory /lib/firmware/mediatek of a current snapshot.
I have still not figured out which commit (to openwrt or mt76) caused the regression.
I have still not figured out which commit (to openwrt or mt76) caused the regression.
Now I have. With commit 3e6de5d77a8b8cda1e02250179d964b840c203fa (“mediatek: use NVMEM framework on all Adtran devices”), first used in snapshot r27776, compiled and submitted for mediatek/filogic in r27777 at Tue Oct 15 2024 20:35:58 GMT+0000, mt7916_eeprom.bin extraction from emmc was dropped from script /target/linux/mediatek/filogic/base-files/etc/hotplug.d/firmware/11-mt76-caldata.
.
3 Likes
Thanks to dangowrt, the wifi degration was fixed very fast. 2024/10/18 snaphot build for mediatek/filogic already contains the fix. (edited, see #154)
1 Like
@goldwrt actually... not.
I tried the snapshot from Fri Oct 18 17:42:44 2024, the one with sha256sum = dbca794e0ee337c6165fb2eab4595b3daf41298112d595fc5fe47acb4e5c2e99, and the issue with the eeprom is still there.
Have you tried the same snapshot?
1 Like
Sorry, sorry, very sorry. You are right. 2024/10/18 snaphot build does not contain the fix.
Have you tried the same snapshot?
I thought I did. I have two sysupgrade files r27797 with nearly the same time stamp in different folders here. After downloading and testing the current snapshot again, it seems that I have inadvertently picked the hastily self-generated file that contains the fix again when I tried to upgrade to the current snapshot a few hours ago. I should have checked the changes tab on the buildbot website before posting.
The only good news is that the fix really works and that the next snapshot for mediatek/filogic will contain the fix.
Have I mentioned that I am very sorry?
Hi,
the new snapshot build does contain the fix now. It is the only change in r27798.
1 Like
Not sure if I am facing the same issues as everyone else. I am on the latest stable (supposedly), but it is anything but...
The good: Previously mentioned boot problems solved (great idea on the zero-fill, and good-looks to whoever figured out the WPS+RESET to delay bootloader) and I learned that I am not as bas at soldering as I thought!
Bad news... it's almost too buggy to use.
- LuCi is poorly integrated when it comes to radio configuration. I have no idea why, but if I set up a radio and then change something about it, I end up having to reload the default settings and start all over, or the radios will just not come up. I checked the radio config file, and they look uncorrupted, so I have no idea where this is coming from. Sometimes it will come back from a reboot looking like there are various hidden APs, each 20Mhz wide, rather than the non-hidden ESSID at the aggregate of those 20Mhz slices that I had.
- 6Ghz radio is extremely misconfigured. It can't be configured in LuCi, US does not work as the CC (following another's advice, I used JP, but I think that may be limiting my max power output, and only selecting CH.1.
- I don't see ant way to trigger DFS/AFS and/or Dopplar PCS channels? I see some available to select, but without DFS/AFS scanning abilities, technically they are illegal to operate on (not the end of the world as 6Ghz is still pretty open, but still).
- BUG: When I set the country code on the 5Ghz radio to 00 (world) and select a frequency other than CH.36, it shows (in LuCi) as the channel frequency being in the 6.1xx Ghz range. *I suspect that 2 and 4 are related).
- 2.4Ghz devices seem to work fine. When it comes to 5Ghz devices, authentication (sae-mixed) fails ten to twenty times before succeeding.
- When I try to switch a device between 5Ghz and 6Ghz, the router has some fatal error, crashes and reboots. While authentication on 5Ghz can take a lot of time and have a lot of failures, it usually succeeds, but attempting to change a device from 6 to 5 or vice versa, always instantly crashes the router.
- The DNS resolver is painfully slow (I am sure that I can fix that).
- It seems like the DHCP server is also being flaky. Some clients only get Autoconfigured V6 leases, some get Autoconfigured Global and the local DHCPv6 IANA private addresses, but no v4, and some only get v4. I thin kit's taking too long to respond. My LG TV can't get a global scope autoconfigured address, but I think that is due to its limitations.
AND FINALLY, MOST IMPORTANTLY, WHERE ARE MY SYSLOGS AND MEMDUMPS? I have looked everywhere... the only thing I can think of is that the fatal error causing the crash is causing complete kernel panic and nothing is getting written. The LuCi system logs clear after the chashes. Can I configure periodic memdumps in any way?
Thanks!
Some confirmatory, some contradictory observations:
BUG: When I set the country code on the 5Ghz radio to 00 (world) and select a frequency other than CH.36, it shows (in LuCi) as the channel frequency being in the 6.1xx Ghz range. *I suspect that 2 and 4 are related).
This bug also showed up on command line level with other country settings and with (2024/09) OpenWrt snapshot versions. I seem to remember that it was reproducible by setting 5 GHz channels to F_0 index values (50 instead of 52), but I cannot reproduce that any longer.
2.4Ghz devices seem to work fine. When it comes to 5Ghz devices, authentication (sae-mixed) fails ten to twenty times before succeeding.
This does not necessarily have to be a mistake on OpenWrt's part. I made the will-it-stand-up-to-Apple test and noticed that iPhones (with different iOS versions) could not connect to Predator-W6's 5 GHz wifi with “sae-mixed” enabled, whereas MacBooks (with macOS 12 to 14) had no difficulties to connect to the same wifi. Setting encryption to psk2+aes was a workaround (not really improving security).
When I try to switch a device between 5Ghz and 6Ghz, the router has some fatal error, crashes and reboots. While authentication on 5Ghz can take a lot of time and have a lot of failures, it usually succeeds, but attempting to change a device from 6 to 5 or vice versa, always instantly crashes the router.
Maybe that is a known problem that was solved. Please install a snapshot version. You can downgrade to 23.05.5 any time if you want in case the crashes continue.
AND FINALLY, MOST IMPORTANTLY, WHERE ARE MY SYSLOGS AND MEMDUMPS?
Your logs went to to RAM ring buffer, right?
Thanks for the quick reply and all the info! I was able to get 5Ghz working. Upon looking at the logs, the radio was refusing to come up on any channel above 48 because for some reason it was drawing an exception from the regulatory database, reporting the channels as being in the radar frequency range (which require DFS). Actually, they technically are. However, I was able to get it to stick to an 80Mhz channel with the carrier on 64 by setting the country code to US, setting the bandwidth to 20Mhz, selecting channel 64, and then setting the bandwidth back to 80Mhz. I might try setting the country code to India or the Philippines, as they both allow full 5Ghz spectrum without DFS. Then I'll know if it's a regulatory thing or something else.
As for the crashing issue, it seemed to be the the dhcpd hanging. I updatted and that issue seems resolved.
Finally, disabling dissociation on low ACK seemed to help with authentication.
I have installed stable (23.05.05) and snapshot versions, but I always have the kernel panic when a system disconnects from the 5 Ghz radio. Does someone has a link to a version of a snapshot where the patch from bmork is applied?
Yesterday I even compiled my own snapshot. But honestly I don't understand the build system: what do I have to do that it is not using the mt76-sources from 2024-04-03? Where do the modules in the sysupgrade image come from (date 2024-09-23)? Maybe I should not have skipped "kernel_menuconfig"... So my build shows the same problem. 
Hi Dirk,
is “the patch from bmork” commit 7d7eea4? Linux kernel version v6.6.54 contains this patch (see line 1506 in file drivers/net/wireless/mediatek/mt76/mac80211.c) to fix the bug that was introduced in version v6.6.48, and the fix is part of OpenWrt's snapshots (PKG_SOURCE_DATE:=2024-10-11.1 in package/kernel/mt76/Makefile) since July, 2024. OpenWrt stable version v25.05.5 still uses PKG_SOURCE_DATE:=2024-04-03.
If you follow all steps to setup und use the OpenWrt build system you can apply patches (i.e. to file package/kernel/mt76/Makefile) or create packages to modify the source code and build particular images. But if the crashes you talked about occurred while using a current OpenWrt sysupgrade snapshot image, then this probably will not help.
It is working now! It seems that I never installed a snapshot at all, because all the time I had a 5.x version of the kernel (thanks for this hint).
No problems so far! Even 160 MHz works on 6GHz and 5GHz. 
Question regarding W6d, what is current status of OpenWRT?
If you flash using serial now is it persistant?
Is it buggy?
OpenWrt installation is the same for all W6/W6e/W6d/W6m variants (using the uart0 serial connection after soldering a pin header or using pogo pins and your third hand – setting u-boot environment parameters correctly and/or overwriting kernel partitions before rebooting is important).
If you do not omit an installation step, installation will be “persistant”.
Current OpenWrt snapshorts run very stable, OpenWrt stable version 23.05.x crashes on wifi disconnects (see above).
I took some time, installed OpenWrt's build system, and learnt as much as I could. Recently, I submitted OpenWrt pull requests #16860 and #16861, which will improve software support for Acer Predator Connect W6/W6d and Acer Connect Vero W6m (based largely on @fer's PR #16410 and on many comments in this forum).
If you want to control Predator's the bright “mood LED area” like the six RGB antenna status LEDs from user space, or control Vero's RGB LED using the mainline linux driver, or use at tailor-made LuCI pages for your W6/W6d/W6m router, you can do so now if you are familiar with installing and using OpenWrt's build system. Please leave comments and approving reviews regarding pull requests #16860 and #16861 so that both can be merged into OpenWrt's mainline code.
With the I2C bus of W6* enabled (which is not the only, but an important improvement), I2C hardware other than the KTD2061 (in W6 and W6d at address 0x68) or the KTD2026 (in W6m at address 0x30) can be connected to the JST GH connector on the router board and controlled from userspace or via driver (if available and compiled).
2 Likes
Oh, cool, I had the driver for this from the GPL sources, but have been busy with actual work.
Hey there, could you clarify as I didn’t understand from this thread, is W6E still going to work with OpenWrt if I upgrade the stock firmware now, before I attempt to install OpenWrt?
I’m just not in a position to make a serial connection atm, but would rather have this router already work, before I’ll be able to install OpenWrt.
There is yet another (new) variant called W6x, anyone know if it is the same and current OpenWRT can be flashed?