mediatek-mt7622: Add support for D-Link EAGLE PRO AI R32 A1 #3332
Conversation
github-actions
bot
added
3. topic: docs
|
Radio LEDs are not working? |
Not as I would expect. 2.4G is on by default and it's flickering while there is traffic on 2.4GHz. 5G is off by default and there is also no change during traffic on 5GHz wifi. Update: also tried to get a defined behavior in OpenWrt using the LED settings, but also no success there. |
|
Sorry for the late reply - if the LEDs are not working, please add the broken flag and remove the device from the documentation. Everything else LGTM. |
RolandoMagico
force-pushed
the
D-Link_R32
branch
2 times, most recently
from
cc999d0 to
e5077a2
Compare
Done |
|
This is pretty much ready to be merged. This device is marked as broken so it won't be backported into the last stable release 2023.2.x. and main's next release is going to be based on OpenWrt 24.10 which was merged a few days ago. It's likely that the new OpenWrt release (candidate) broke some stuff so that will need fixing anyways so it's only in your interest for this to be tested. (issues that might affect other mt7622 devices as well) If you don't have the time to do the tests, then please tell us :) |
RolandoMagico
force-pushed
the
D-Link_R32
branch
from
e5077a2 to
af85c4a
Compare
|
@Djfe: I rebased and built the image. What I saw so far:
I'm not an expert in gluon. Do you know if is related to my build setup or it is a general issue? My build environment: Command I used: |
|
there were one or two issues fixed very recently I had the same issue you experienced with the netgear wax206. Thanks for confirming that more device than one are affected. I'll check on my WAX206 soon (with the fix above) |
|
the issues should be fixed by the latest 24.10 updates in gluon main, no? |
github-actions
bot
added
3. topic: docs
RolandoMagico
force-pushed
the
D-Link_R32
branch
from
5210883 to
067c509
Compare
github-actions
bot
removed
3. topic: docs
|
@rotanid: The problem was already gone when creating the PR for the M30. But I'll build and test to be sure. Update: Problem still exits :-( |
rotanid
added
the
2. status: blocked
|
@RolandoMagico the error 500? did you do a full clean build to be sure? |
|
@rotanid: Yes Same error as before. I did a clean build |
|
@RolandoMagico can you post the output of And play around with this lua snippet, to see what is wrong with the phyname: iwinfo = require 'iwinfo'
t = iwinfo.nl80211.phyname("radio0")
print(t) |
RolandoMagico
force-pushed
the
D-Link_R32
branch
from
067c509 to
947eea0
Compare
|
@maurerle: I did a rebase and checked that the problem still exists -> yes it does.
|
|
Output of
|
|
Code: iwinfo = require 'iwinfo'
t = iwinfo.nl80211.phyname("radio0")
print(t)Output: Code: iwinfo = require 'iwinfo'
t = iwinfo.nl80211.phyname("phy0")
print(t)Output: Code: iwinfo = require 'iwinfo'
t = iwinfo.nl80211.phyname("phy1")
print(t)Output: |
|
Weird, can you show |
Sure: Can it be related to openwrt/openwrt#14207? I tried already reverting the commit causing the issue but then I don't have any wireless settings in gluon instead (tabs for wifi configuration are not present anymore). |
|
So the root of the problem is that is On a Ubiquity Unifi 6 LR v3 - which also names the radios as Note that a
So I suspect something going wrong in Though it looks fine to access .phy if .path does not exist when getting the name from uci: I don't know what else could go wrong here |
|
@blocktrron do you have an idea based on the information and analysis already done? |
|
Not sure if it helps but that's what I also see in OpenWrt when running Left side is OpenWrt 23.05.5 where the wireless device names are shown correctly in LuCI, right side is from 24.10rc4 where "Generic Unkown" is shown. But after enabling wifi interfaces in LuCI in 24.10rc4, the |
This comment was marked as outdated.
This comment was marked as outdated.
RolandoMagico
force-pushed
the
D-Link_R32
branch
from
947eea0 to
929d93f
Compare
|
@Djfe : Now I'm running out of git and building skills. Also seems not be easy to cherry-pick openwrt/openwrt@2e03c7d in the OpenWrt 24.10 branch. Any tips how to build current OpenWrt main? |
|
Hi @RolandoMagico I would rather flash openwrt-snapshot and take a look at |
|
Thanks @maurerle The output after enabling wifi0 in LuCI: Same output with OpenWrt 24.10.0-rc4 r28211-d55754ce0d / LuCI openwrt-24.10 branch 24.357.59006~41cbd31 For comparision, the output of OpenWrt 23.05.5 r24106-10cc5fcd00 / LuCI openwrt-23.05 branch git-24.264.56413-c7a3562:
All tests were done with the recovery image from the OpenWrt firmware selector. |
|
so this proves it's not an Issue in Gluon, but was introduced in OpenWrt main some time after 23.05 was branched. |
If the output of
So there seems to be a relation between the issue I face here and openwrt/openwrt#14207 Would be great if anyone can confirm that the problem is also present on other MT7622 devices, to be sure it's not related to the M32 only. I also tried to revert the changes from openwrt/openwrt@b993a00 in the current OpenWrt main. But as mentioned already earlier, wifi doesn't work at all anymore. I assume that there have been multiple changes in the wifi scripts since, so it's hard for me to track down what else was changed and relies on the changes of openwrt/openwrt@b993a00 |
In Gluon right? So I think, that this is a Gluon-only issue and we should add an additional fallback in gluon/package/gluon-core/luasrc/usr/lib/lua/gluon/wireless.lua Lines 11 to 13 in c31c7d7 to get the wl0 name from something else as the upstream behavior changed, to only return if the wifi interface is up as well? I don't have an additional mt7622 device I can test on - though I am quite confident that this is the right spot and that this will apply to all devices which have wl0 instead of phy0. Related issue is #3020 which was fixed in #3223 (the aforementioned gluon commit). @neocturne - as you did the previous patch, maybe you have a good idea here? |
No, it’s an issue in OpenWrt: after reversing the changes from the mentioned commit in OpenWrt main, WiFi doesn’t work anymore. There is also no wireless menu in LuCI anymore |
|
oh okay, so #3408 will not fix it either..? Hm, sorry then - I don't quite know what to do further |
|
I'll have to check the iwinfo code again |
|
My assumption: As soon as openwrt/openwrt#14207 is fixed in OpenWrt, you won't have any issues in gluon. |
sysupgrade [-n],firstboot)(
lua -e 'print(require("platform_info").get_image_name())')(https://gluon.readthedocs.io/en/latest/dev/hardware.html#hardware-support-in-packages)
factory reset must be performed before checking the primary MAC address, as
the setting from the old version is not reset otherwise.
(https://gluon.readthedocs.io/en/latest/features/configmode.html)
is_outdoor_devicefunction inpackage/gluon-core/luasrc/usr/lib/lua/gluon/platform.luais_cellular_devicefunction inpackage/gluon-core/luasrc/usr/lib/lua/gluon/platform.luasetup_ncm_qmitopackage/gluon-core/luasrc/lib/gluon/upgrade/250-cellulardocs/user/supported_devices.rst