It won't be reverted...
There's some work being done for hardware controlled LEDs but I don't understand much of it, either way, it's not there yet.
1 Like
Yes, I assume that's been the case for most of the devices supported by OpenWrt, as that's how they work on OEM firmware likely.
I'm not sure how that relates to obliterating/removing the ability/feature of custom configuring LEDs in OpenWrt - not simply just the ability to set "on" and "off".
So if this is a feature of 23.05.0 - I think that information definitely needs to be added to the Release Notes.
The commit explains itself.
Those LEDs are controlled by the switch.
If you take control of them by software, they will not function properly (as explained, hardware offloaded frames will be missed since you don't see those in software). Downside of that change is that you can't turn them off either.
Also only 3? devices were caught by the change,
zbt-wg1608-16m, wax202, and e7350.
1 Like
It is OK that I add your paragraph to the comments?
I understand your paragraph - I didn't understand anything written in the commit. That's why I want to add yours. If you have a GitHub account, can your paragraph to that?
(If I understand correctly - the issue resolved is "lights won't flash for offloaded frames".)
Does that also mean orange won't work, or changes the behavior??? 
I tried to change to orange and nothing seemed to happen, I'll have to setup a test device to recreate.
@lleachii I don't mean to be crude, but it sounds like you have a unique (low) power requirement
just rip your LEDs off
this is WAY too much talk about an intentional change
If those orange LEDs are also controlled by the removed switch gpio controller (and they seem to be) those LEDs will not function.. guess that can be fixed.
1 Like
Good idea, but I also:
- need to have them set to certain scripts to turn them orange
- have them set to certain scripts to turn off
- heartbeat
- set to a different network device (software)
- set to only on link on
- and it was kinda cool to do the flash interval setting
and in combinations - i.e. to signal something from script, etc.
Basically:
BTW, this is for other devices too.
The switch to DSA for ipq40xx which is mentioned as "highlight" is more a lowlight as it'll break roaming completely and cause all sorts of issues (see https://github.com/openwrt/openwrt/issues/11650). I've reverted the switch to DSA for now and it's working absolutely great.
I'm not sure if the broken images are still broken and will cause soft-bricks or if that's been fixed in the meantime but to me it looks like this is going to be the most broken release ever unless lot's of effort is put into fixing many things 
1 Like
2) OpenWrt support for this device will end after 2019.
19.07 will be the last official build for 4/32 devices. After 19.07, no further OpenWrt images will be built for 4/32 devices. See OpenWrt on 4/32 devices what you can do now.
The last official build was 19.07. The device was just not yet removed from automated builds. You could still build 23.05 images by yourself if you got the exception of the rule of an 16/64 MB model.
I would instead accept that this device is now end of life and upgrade to newer hardware. MT7620N SoC with its 580 MHz single MIPS core is a design from 2013. 10 years old. 22.03 old stable life cycle will be enough time to upgrade.
So I upgraded again. Orange does work, albeit the behavior is extremely different.
- Green blinks over/after orange no matter the configuration
- Orange being set to "Always on" successfully stops the green light (perhaps helpful in some use cases)
Lastly, the change in power seems negligible (less than 0.1 Ampere - I think I was recalling the power measurement logs of other, older devices), so the WAX202 seems OK.
Thanks for your inputs @znevna and @mpratt14
I think making a note of this behavior in the Release Note documentation is sufficient TBH.
Also assembling a list of affected devices and chip types would be good too for the Release Notes.
It seems that's been accomplished!
Thank you, I'm grateful!
EDIT:
I noticed WAN can still be controlled, if the ports were repurposed etc., would that port suffer from the same issue as LAN 1-3 (i.e. flashing for offloaded packets won't work)?
2 observations/issues thus far:
- DHCP settings for interfaces don't display, here's an example for LAN (which indeed has a DHCP config)
Pressing the button produces a box:
Save error
An error occurred while saving the form:RPC call to uci/add failed with ubus code 9: Unspecified error
at ClassConstructor.handleCallReply (https://192.168.1.1/luci-static/resources/rpc.js?v=git-23.118.79121-6fb185f:15:3)
- IPv6 addresses are not assigned to clients in LANs
- Although IPv6 traffic initiating from the router (e.g. WG tunnels with IPv6 endpoint addresses) works
I agree that 8/64 devices is not future proof choice but
its not the exception, 8/64 version is still actively being sold, yet marketed under different name.
If openwrt support for 8/64 mb devices comes to an end, why it is so only for specific devices and not for the rest even with exact same hardware?
Is this
DEFAULT := n
single line of code worth the discussion and time required to build image manually?
I think you might be missing a luci package, I don't have that issue.
Look again at the list of luci packages I added, this list is taken from the default build manifest pf 23.05 RC, so these are the default packages of luci.
I suspect you need luci-mod-network
@lleachii I'm not following that closely but it looks like, as expected, that the software netdev trigger is a little bit slower than the hardware driven trigger.
and yeah, 0.5 W sounds about right for LEDs, but if you're really crazy about conserving power then removing them is definitely the way to go, GPIOs are not perfect switches, there is commonly some leakage current even when off. (in a very dark room you might be able to even see it)
1 Like
12 V * 0.1 A == 1.2 Watts
Not sure where .5 came from. But as I noted, the cheesy screen on the charge control didn't even register much of a change.
The lights are OK.
I had to revert back to 22.03.5 for another issue now (the IPv6).
It seems they got rid of the software trigger altogether.
The typical green/red/yellow 8mm LEDs are rated for 10 mA, so 0.01 A; with more exotic ones ranging from 5 mA to 25 mA (rgb LEDs might rate higher).
1 Like
I just used the default build on the downloads site, and now IPv6 also works.
So, the Firmware Selector is missing some other things.
Can we make a list of packages missing from the Firmware Selector, that are present in the default build?
This is much different than using the Firmware Selector with 22.03.5.
The firmware selector does not have luci packages by default on custom builds, it didn't have luci on custom builds in 22.03 either afaik.
- IPv6 is not LuCI...I don't understand
- Yes, but adding
luci-sslorluclwas all that was needed, there's many solved threads of people offering that solution - but as we see, it's gonna cause a problem in 23.05.0.
Are you able to assist?
I'm really trying to get this list together before others have issues too.
well, then what changed was the dependencies on those packages then.
I never followed that route of just adding luci and luci-ssl.
I suggest you use the list I posted, as I said it's taken from the manifest of the default build. I hope that helps.