I am new to flashing openwrt to a remade router and not sure on where to look to get instructions as to how to flash this router/mesh system
is there any place i can go to get instructions on how to flash the dlink m32?
or can someone provide me with how to do it?
i have been using it on a pi and on x86_64 vm
Start scrolling back in this thread, don't even have to scroll very far...
Has anyone tried adding a USB port to the R32 router? It has a space on the board for a component with 9 pins, I assume it's a USB port. (Plus an electrolytic capacitor.)
If the hardware side supports it, will it need changes to the kernel?
Never thought about an USB port on this device. Is this the connector:
Maybe the device tree for this must be adpapted to support USB
Yes, that's the one.
Quite a few unpopulated components around it, many of which probably are needed for the USB port.
Does anyone else see the wifi LEDs both flicker when the 2.4 GHz network is transmitting a lot? On the R32 router.
Yes, same on my device. As soon as there is traffic on 2.4G (did a internet speed test), both LEDs start flickering.
Wen using 5GHz, LEDs are constant on all the time.
As far as I know the LEDs are directly connected to the wireless chips, no idea how to control them as intended. The LEDs also appear in the LuCI LED configuration but settings there don't result in changed LED behaviour.
How do I revert to OEM firmware?
Do I need a decrypted firmware? Anyone have one already decrypted?
Thanks.
Yes, you need a decrypted firmware for the recovery web interface. Do you know which OEM version you used before switching to OpenWrt? Depending on the version, you need the corresponding firmware to be able to install updates in future.
@RolandoMagico I saw your PR for the R32 in gluon, thanks for adding this device (I had even built an image for testing, but only then realized the wifi issue due to the recent switch to a later OpenWrt branch was still present 
)
However, I attempted to have another look at the LEDs for R32, as far as I recall we mostly reused the (remaining) GPIO pin definitions from M32, and apparently I was not able to find any direct SoC connection for the wifi LEDs back then... (also they flash at some point during the initialization of the mt76 chips on boot, so there definitely must be some connection to the wifi chips, but maybe there are indeed multiple connections?).
In any case, I just found a bug in a script that I had previously used to dump GPIO_IN registers low-level from mt7622 devices (which resulted in only GPIOs below 64 being detected correctly )
So, in conclusion: All I can say for now is that the 2.4G LED is somehow connected to GPIO 73 and 5G to GPIO 75, but maybe additional pinmux settings are required (I think the mt7622's built-in wifi LED control can also be muxed to output pins, so maybe this is why we see at least some LED control magically happen without any control from OpenWrt).
I need to get some sleep now, but will test building an image with
wlan_2g {
color = <LED_COLOR_ID_WHITE>;
function = LED_FUNCTION_WLAN_2GHZ;
gpios = <&pio 73 GPIO_ACTIVE_LOW>;
linux,default-trigger = "phy0tpt";
};
wlan_5g {
color = <LED_COLOR_ID_WHITE>;
function = LED_FUNCTION_WLAN_5GHZ;
gpios = <&pio 75 GPIO_ACTIVE_LOW>;
linux,default-trigger = "phy1tpt";
};
tomorrow to see if this is already sufficient.
(Feel free to try in the meantime, I will only be back home late in the evening 
)
Thanks for the hint. I thought I checked all pins but seems like I missed these.
Adding the entries to the DTS indeed allows controlling the wifi LEDs. Unfortunately 2.4GHz Wifi is not available (at least in LuCI) anymore. Maybe related to this log entry:
Tue Jan 14 15:02:13 2025 kern.err kernel: [ 9.248106] mt7622-wmac 18000000.wmac: Error applying setting, reverse things back
Reverting the changes results in 2.4 GHz wifi to come back. I'll check further the next days.
Fascinating, that error does not seem to come from the mt76 driver, but seems to be something generic in the kernel.
Honestly I'm not quite sure what exactly LED_FUNCTION_WLAN_2GHZ and the default-trigger for the phy are doing automagically, so I'm gonna try dropping those and just treat these pins as regular LEDs. For some devices, I had also seen phy0radio instead of throughput, maybe the tpt channel is not available for the built-in wifi or something... I just have too little experience with all these new devices 
(speaking of, my M60 has finally arrived )
// edit:
So this error occurs in https://elixir.bootlin.com/linux/v6.6.50/source/drivers/pinctrl/core.c#L1326, though the label does not let us know whether it was jumped to from the pinmux or pinconf functions located above 
// edit #2:
built with just basic LED settings, but I also see that pinmux error:
[ 9.332010] mt7622-pinctrl 10211000.pinctrl: pin SPIC1_CLK already requested by pinctrl_moore:585; cannot claim for 18000000.wmac
[ 9.343724] mt7622-pinctrl 10211000.pinctrl: pin-73 (18000000.wmac) status -22
[ 9.350964] mt7622-pinctrl 10211000.pinctrl: could not request pin 73 (SPIC1_CLK) from group antsel12 on device pinctrl_moore
[ 9.362361] mt7622-wmac 18000000.wmac: Error applying setting, reverse things back
So it seems the mediatek wifi driver(?) itself is trying to map that pin to something, apparently using the mediatek-proprietary pinctrl implementation in https://github.com/torvalds/linux/blob/master/drivers/pinctrl/mediatek/pinctrl-moore.c, which might explain why we see them flashing upon initialization of the wmac drive on boot. So maybe this just needs the correct pinmux setting, will try to check tomorrow It looks like the rabbit hole goes deeper there:
/* Just for backward compatible for these old pinctrl nodes without
* "gpio-ranges" property. Otherwise, called directly from a
* DeviceTree-supported pinctrl driver is DEPRECATED.
* Please see Section 2.1 of
* Documentation/devicetree/bindings/gpio/gpio.txt on how to
* bind pinctrl and gpio drivers via the "gpio-ranges" property.
*/
if (!of_property_present(hw->dev->of_node, "gpio-ranges")) {
// edit #3:
okay that seemed rather unrelated, but I have dropped antsel12 (for pin 73) and antsel14 (pin 75) from mt7622-dlink-eagle-pro-ai-ax3200-a1.dtsi pinmux settings for epa_elna_pins, as suggested by the error message(s), and both wifis are back. No idea what exactly those pins would do otherwise, and which of the others are actually unused for antenna selection as well (but how to find that out without accidentally (maybe just partially) breaking wifi?)