Today i've tried to update my DGN3500 to the latest OpenWRT release, i've always used OpenWRT since 14 and never had an issue, on the same router, but today the update broke it
After i've uploaded the Update Image as usual, the router rebooted and entered in a bootloop kind of state
The only thing i've had the chane to do has been rebooting and activating flashing green-red led and tried all the proceudre here described without luck
In particular, i've tried the debrick one but despite my best effort, i couldn't debrick it, i cannot access the green-orange led status because it just continue to bootloop
Can someone help me or found himself in the same situation? I really love this router and would be a pity to just throw it away
Thanks in advance for your help!
Ok guys, i've unbricked it
i installed a new 22.03 but it bricked it again
then i unbricked it once again and then installed 21.02.03, works like a charm so i guess there is something that doesn't work in the new release, anyway to report it?
I believe Lantiq (which is the architecture your device's SoC is using) is on DSA now. Which means you cannot keep network settings when upgrading from anything prior to 22.03. I suppose right after unbricking it, you tried to install 22.03? Or did you unbrick by installing 21.02, then sysupgrading to 22.03 again? If so, you should try that again while wiping settings (or at least
/etc/config/network). If that does not help, you should look at connecting serial to see what the boot log spits out.
The first time i kept network setting when upgrading to 22.03, and it brick
Second time i directly installed 22.03 and still it brick
Third time i've installed 21.02.03 and it worked
I've never used the sysupgrade image, except the first time
I hope this helps
You'll need serial to make sure what exactly is going wrong. Might be the bootloader doesn't like the kernel size, with the bump from 5.4 to 5.10. Common issue.
Well i think i will keep the old version, i'm not that good to understand why it doesn't work
I understand, but I don't think your device is that popular - so it will really help to keep support going if you'd be able to connect serial and see what's going on. In the short run you'll be fine of course, but at some point 21.02 will stop being supported.
I don't even have the equipment, is there a simple guide to follow eventually?
The wiki page has instructions on how to connect a serial cable, you'll need a USB to TTL serial adapter like this e.g.. Thing to keep in mind is NOT to connect the voltage pin (so skip the 3.3V pin), but connect all the others - ground (GND), transmit & receive (TX/RX).
i'm new in the forun: please forgive me if i do something wrong!
i use OPENWrt on my DGN3500 for few years and recently i tryed to upgrade from 18.06 to 22.03 but happened the same issue You describe. I'm not able to debrick it: i already tryed DG834 tool but the MAC ADDR is not recognized and also serial recovery doesn't work: (it say "bad image"). please, how did you debrick it?
Thank you in advance!
Here's the steps, it took me a while to figre it out
- Start the router with the reset button pressed, until it flashes green-red
- Install Virtualbox, restart your pc to install bridge adapter, and then install a copy of Windows XP 32 Bit
- Into windows XP install "Microsoft Loopback Device", that's because DG384 tool it's bugged and will not allow you to select the correct adapter until it senses another another LAN adapter
- Connect the router directly to your PC using port 1
- Select the correct adapter this time, the one which is connected to your router
- Check that into the Netgear DG384 folder there is the OEM firmware you want to upload, it must be in the same directory of the executable
- The software should allow you to select your router device and start the firmware upload, it will take about 15 minutes
- It will start a check, and will fail at 95%, don't worry, poweroff the router and power it on again, now you have the OEM firmware again and you can flash the old 21.02.03 that will work
Thank you for your help, but unfortunately i already tryed with a real winxp pc, and it didn't work. Now i tryed also with virtualbox, as yuo suggested, but the results is always the same: utility doesn't find the MAC ADDR.
I found a WINXP SP2 iso but also with this one the result is the same.
I spyed with wireshark the communication on the ethernet card used and i can see virtual pc and DGN3500 exchange each other packets with 0x8888 protocol, when utility is running, but probabbly it isn't enought.
I'm very close to surrender me and declare the router lost!
Any other suggest will be very appreciate!
I' m be able ti debrick my dgn3500. I report the procedure used: maybe It can help somebody else...
You must have a serial adapter connected to the DGN3500 serial port. Connect your PC to the lan port and set a static ip 192.168.1.X to the PC Ethernet adapter.
• download a stock firmware
• reset the router and interrupt the countdown on serial monitor, to step into u-boot
• type “web”: now you can navigate to http://192.168.1.1/ and upload your stock firmware
If the wrong PID error occurs, probably you have the wrong firmware: PID YP5723 means World Wide version and PID YP5726 means North America version.
I Discovery that my router Is a NA versione. Maybe for thia reason the serial/tftp procedure returned a bad image errore: i used a wrong firmware.
I have a DGN3500 World Wide (as confirmed by the PID YP5723), and I have the same issue with the 22.03 release. I also tested the new 22.03.1 and the issue is still present.
It has something to do with the Lzma decompression which fails.
Image Name: MIPS OpenWrt Linux-5.10.146
Created: 2022-10-07 23:34:56 UTC
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 2486218 Bytes = 2.4 MB
Load Address: 80002000
Entry Point: 80002000
Verifying Checksum ... OK
Uncompressing Kernel Image ... ERROR: LzmaDecode.c, 561
Decoding error = 1
LZMA ERROR 1 - must RESET board to recover
I found this issue on the forum https://forum.archive.openwrt.org/viewtopic.php?id=57291; in which they states that some had a similar issue and it was related to the size of the dictionary used to compress the data. Could this be similar?
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.