Post your text output as actual text please, so it's searchable. Screenshots cannot be indexed by any search engine, you see.
No, you're on a DSA target. The software bridge is there (
br-lan). For now there's no LuCI counterpart yet, but you can manipulate it on the command line if needed.
Ok, but what are the VLAN tagging options then? I have 4 VLAN's to configure. And some LAN ports require tagging.
now we just need someone who knows how is to update the header creation
that area just got updated for what was the "sge" parsers http://lists.infradead.org/pipermail/openwrt-devel/2021-January/033482.html
you can edit one your self if you like
add "DIR-2660" text at address 0x40 hex
add "V1.00000" text at address 0x80 hex
add "A1" text at address 0x90 hex
change bytes 0x04 to 0x07 to 00
create crc32 for bytes 0x0 to 0x9F
place result in bytes 0x04 to 0x07
here are the before and after files
I don't know with of these is required but it's what i did for the test file
Ok, so that would be for factory images. What about SysUpgrade? Could I just flash a sysupgrade or would it also require new headers?
they all require new headers due to your boot loader now requiring them now
I have not done this but you should be able to extract the kernel image from a sysupgrade file
edit it the same & place it back into the archive "sysupgrade file"
Ok, I am starting to understand now. So just to make sure we are on the same page:
- The DIR-2660 A1 can still work without these modified headers
- The DIR-2660 A2 needs new headers and thus a new target in the OpenWRT builds?
For the latter we need some help? Would it make sense to contact the commit of the commit adding the A1 version (https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b5dd746cbb1aaf91f4b68e9f3eda97413550d904)
well it seems the later DIR-2660-A1's needs this as well
I think as some point they updated the boot loader
it would be better if this mod was added for all the devices
that is the one's built by SGE DIR-878,867,882,1960,2660 & others
it wasn't added due to it not being needed at the time
but it would help in future is someone writes the encrypt part
with would make them web flashable
you could contact them i think it would speed up everything
it would take me a long time to lean how & then another 6 mouths for the commit to got thought
there is a part where \tools\firmware-utils\src\uimage_padhdr.c
add's padding to the standard uboot header
"96 bytes of 00 in this case"
as this area is the part added maybe this is where the
DEVICE_MODEL & DEVICE_VARIANT
should be added
I started with creating an issue for this in the OpenWrt issue tracker: https://bugs.openwrt.org/index.php?do=details&task_id=3641
I really am not into OpenWrt enough to create a patch that solves right now. Hopefully somebody can assist?
In the mean time I am curious what would be the best way of manually modding the upgrade images until something working comes up?
I think the only option for the time being is to keep modifying the factory image
I'm going to play in the background
but someone who know what they are doing could do it in a few minutes
I can read the code ok but not so good at writing it
I tried to update the kernel image in the upgrade package, but after tar-ing the result, flashing it gives a warning that the format is incorrect.
you may just have to use the factory image
if you get the current snapshot you can get packages for a little while
or compile you own with repository
depends on what your plans for you device are
And then flash via the recovery?
yes that's how you use the factory image
The encryption was already figured out, see dlink-decrypt for details on how to decypt/encrypt stock firmware images. Also worth mentioning the recovery GUI from the bootloader only accepts unencrypted firmware images.
Also, the encrypted image must be signed with D-Link's private AES key in order to be accepted by the web GUI of the stock firmware and each device uses a different key. In other words, unless that private key leaks, no custom firmware will ever be accepted by the stock firmware, even through the SHRS format the router expects is already documented...
it depend on witch boatload your board got form the factory
my original dated Jul-19-2017 will only accept unencrypted ones
I have a later copy of one dated Jul-8-2018 that accepts both
I do be leave it accepts any of the boards encrypted versions of firmware as well 878 & 882
I even tested another clone the DIR-1935 firmware and saved the unencrypted version this way
original dlink firmware for the DIR-878 has the extra 96 bytes as
#define PRODUCT_LEN 64
#define VERSION_LEN 16
so 1st 64 bytes as device name "DIR-878"
then 16 bytes for software version number "V1.01B04"
then last 16 bytes for hardware version "A1"
so at the moment the blank 96 bytes are add to a default uboot header by
The bootloader on my DIR-882 (and on a DIR-867 I borrowed in the past) accepts only unencrypted files. Also, DIR-1760/1960/2660 uses NAND instead of NOR flash, it's probably not a good idea to mix the bootloaders...
the problem is that dlink seem to load the current boot loader version into each unit as it's going through production
& when we update the firmware it never updates the boot loader
but the capability's & check's of the boot loader are changing
I think is also why the DIR-2660 now need the extra header information
that the earlier one's didn't
I have the same experience as @Lucky1 where I need the additional header fields. My box also shows DIR-2660 A2 but the factory software still said DIR-2660 A1.