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?)
First and foremost, I want to express a thank you for contributing your efforts to run OpenWRT on DLink routers! I have successfully used your images for multiple M30 and M32 routers.
It appears that the M30 has a slightly larger partition size and it comes with similar decryption methods for firmware for going back to stock if needed. I think it would be a lot more beneficial to have the Kernel1 and Kernel2 merged and place the decryption instructions for flashing back to stock in the wiki, similar to how M30 has it.
Is this possible? I think for those who are using this to run a simple tailscale tunnel and need to update tailscale, could benefit from the extra space very much.
Hi,
You want to merge both kernel partitions for M32 and R32?
It’s possible in general, I already tested it for these devices.
Open questions:
hi, is it possible to revert to oem firmware (1.11) hotfix version with a cp2102 usb? i did a flash with 23.05.5 thru the dlink recovery page. i wasn't able to backup anything because i did not have a UART device yet. i tried to decrypt using the c file in ubuntu but i get errors about sha512 because openssl no longer includes it. currently running 24.10.0
Reverting to OEM is possible with the recovery web interface with a decrypted OEM image. Do you use M32 or R32?
its m32 model
Indeed!
I think the wiki page should reflect changes with the new partition layouts by default, otherwise the second partition is not doing much other than taking up space. Perhaps we have two versions built for people not sure on committing to OpenWRT yet? Something named M32-OEM Partition Layout and M32-OpenWRT Layout? Doing so allows the user to choose what they want to do ultimately. In the wiki page, we would put something like BREAKING CHANGES disclaimers or whatnot.
I ran into issues when upgrading from 23.05 to 24.10 on the M32. I assume that the M32 flipped to the second partition and I don't think there is a readily made M32 version to flip between the partitions, similar to what M30 already has. Would the merging of the partition layout solve this problem?
I am happy and willing to update the wiki pages explaining changes... and it should be quite similar to the decrypt process on M30... correct? If so, it should be a close copy-paste job on the reverting firmware end of things. With the dual partition layout thing, is it possible for you to create a UBI switch file for M32 and R32 users to switch back when updating?
Thanks! Happy to discuss further and see what I can do to help!