OpenWrt Forum Archive

Topic: D-Link DWR 921 support

The content of this topic has been archived between 8 Apr 2018 and 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi comdek,
thanks for your help (I get the info I need).
But this problem releted to the phy0: rt2800_init_eeprom appears really strange.

Can you please post the complete bootlog of your last working fw?

Bye the way, according to the oem bootlog the modem should support a qmi interface.
Try also to experiment with the qmi_wwan kernel module.

You can compile it as module and load it with opkg.
In this way you don't need to recompile every time the whole image.

Bye.

Fidodido,

There is the working code (dwr921 branch of git)

R▒[    0.337915] spi spi0.0: force spi mode3
[    0.346076] m25p80 spi0.0: w25q128 (16384 Kbytes)
[    0.355532] 4 ofpart partitions found on MTD device spi0.0
[    0.366465] Creating 4 MTD partitions on "spi0.0":
[    0.376021] 0x000000000000-0x000000030000 : "u-boot"
[    0.387723] 0x000000030000-0x000000040000 : "u-boot-env"
[    0.400136] 0x000000040000-0x000000050000 : "factory"
[    0.412042] 0x000000050000-0x000001000000 : "firmware"
[    1.745428] 2 uimage-fw partitions found on MTD device firmware
[    1.757264] 0x000000050000-0x00000018573b : "kernel"
[    1.768746] 0x00000018573b-0x000001000000 : "rootfs"
[    1.780463] mtd: device 5 (rootfs) set to be root filesystem
[    1.791937] 1 squashfs-split partitions found on MTD device rootfs
[    1.804281] 0x0000009a1000-0x000001000000 : "rootfs_data"
[    1.820060] mtk_soc_eth 10100000.ethernet: loaded mt7620 driver
[    1.832728] mtk_soc_eth 10100000.ethernet eth0: mediatek frame engine at 0xb0100000, irq 5
[    1.849764] rt2880_wdt 10000120.watchdog: Initialized
[    1.861385] NET: Registered protocol family 10
[    1.874638] NET: Registered protocol family 17
[    1.883651] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[    1.908803] 8021q: 802.1Q VLAN Support v1.8
[    1.932246] VFS: Mounted root (squashfs filesystem) readonly on device 31:5.
[    1.947148] Freeing unused kernel memory: 144K (803ac000 - 803d0000)
[    4.173429] init: Console is alive
[    4.180532] init: - watchdog -
[    6.668195] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[    6.806081] usbcore: registered new interface driver usbfs
[    6.817201] usbcore: registered new interface driver hub
[    6.827917] usbcore: registered new device driver usb
[    6.843618] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    6.857729] ohci-platform: OHCI generic platform driver
[    6.878450] phy phy-usbphy.0: remote usb device wakeup disabled
[    6.890257] phy phy-usbphy.0: UTMI 16bit 30MHz
[    6.899142] ohci-platform 101c1000.ohci: Generic Platform OHCI controller
[    6.912706] ohci-platform 101c1000.ohci: new USB bus registered, assigned bus number 1
[    6.928602] ohci-platform 101c1000.ohci: irq 26, io mem 0x101c1000
[    6.965069] hub 1-0:1.0: USB hub found
[    6.972958] hub 1-0:1.0: 1 port detected
[    6.983491] uhci_hcd: USB Universal Host Controller Interface driver
[    6.997980] ohci-pci: OHCI PCI platform driver
[    7.010686] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[    7.029277] init: - preinit -
[    7.999030] usb 1-1: new full-speed USB device number 2 using ohci-platform
[    8.878877] 8021q: adding VLAN 0 to HW filter on device eth0
[    8.949834] random: procd: uninitialized urandom read (4 bytes read, 15 bits of entropy available)
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[   10.733204] jffs2: notice: (338) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[   10.766881] mount_root: switching to jffs2 overlay
[   10.812364] urandom-seed: Seeding with /etc/urandom.seed
[   10.954699] procd: - early -
[   10.963704] procd: - watchdog -
[   11.683995] procd: - ubus -
[   11.789917] random: ubusd: uninitialized urandom read (4 bytes read, 22 bits of entropy available)
[   12.024727] random: ubusd: uninitialized urandom read (4 bytes read, 22 bits of entropy available)
[   12.043135] random: ubusd: uninitialized urandom read (4 bytes read, 22 bits of entropy available)
[   12.061171] random: ubusd: uninitialized urandom read (4 bytes read, 22 bits of entropy available)
[   12.084001] random: ubusd: uninitialized urandom read (4 bytes read, 22 bits of entropy available)
[   12.102017] random: ubusd: uninitialized urandom read (4 bytes read, 22 bits of entropy available)
[   12.120121] random: ubusd: uninitialized urandom read (4 bytes read, 22 bits of entropy available)
[   12.139145] random: ubusd: uninitialized urandom read (4 bytes read, 22 bits of entropy available)
[   12.157496] procd: - init -
Please press Enter to activate this console.
[   12.603196] kmodloader: loading kernel modules from /etc/modules.d/*
[   12.731442] ipip: IPv4 over IPv4 tunneling driver
[   12.769513] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   12.867757] Netfilter messages via NETLINK v0.30.
[   12.880498] ip_set: protocol 6
[   12.923721] Loading modules backported from Linux version wt-2017-01-31-0-ge882dff19e7f
[   12.939711] Backport generated by backports.git backports-20160324-13-g24da7d3c
[   13.146163] u32 classifier
[   13.151555]     input device check on
[   13.158902]     Actions configured
[   13.168583] Mirror/redirect action on
[   13.228981] usbcore: registered new interface driver cdc_wdm
[   13.262921] ip_tables: (C) 2000-2006 Netfilter Core Team
[   13.318378] nf_conntrack version 0.5.0 (951 buckets, 3804 max)
[   13.399626] usbcore: registered new interface driver usbserial
[   13.411445] usbcore: registered new interface driver usbserial_generic
[   13.424612] usbserial: USB Serial support registered for generic
[   13.445369] wireguard: WireGuard 0.0.20170726 loaded. See www.wireguard.com for information.
[   13.462257] wireguard: Copyright (C) 2015-2017 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[   13.524759] xt_time: kernel timezone is -0000
[   13.545928] PPP generic driver version 2.4.2
[   13.557479] NET: Registered protocol family 24
[   13.569492] usbcore: registered new interface driver qmi_wwan
[   13.603195] rt2800_wmac 10180000.wmac: loaded eeprom from mtd device "factory"
[   13.617675] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected
[   13.633125] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 7620 detected
[   13.757193] usbcore: registered new interface driver sierra
[   13.768483] usbserial: USB Serial support registered for Sierra USB modem
[   13.785675] usbcore: registered new interface driver sierra_net
[   13.804413] usbcore: registered new interface driver option
[   13.815717] usbserial: USB Serial support registered for GSM modem (1-port)
[   13.866066] usbcore: registered new interface driver qcserial
[   13.877701] usbserial: USB Serial support registered for Qualcomm USB modem
[   13.939678] kmodloader: done loading kernel modules from /etc/modules.d/*
[   14.921246] random: jshn: uninitialized urandom read (4 bytes read, 27 bits of entropy available)
[   25.759355] 8021q: adding VLAN 0 to HW filter on device eth0
[   25.877966] device eth0.1 entered promiscuous mode
[   25.887583] device eth0 entered promiscuous mode
[   25.944520] br-lan: port 1(eth0.1) entered forwarding state
[   25.955718] br-lan: port 1(eth0.1) entered forwarding state
[   27.953516] br-lan: port 1(eth0.1) entered forwarding state

fidodido,


The problem is in the time of loading wifi configs, the partition "factory" is not configured in dwr921 dts.

branch dwr921_uboot

[   12.236132] rt2800_wmac 10180000.wmac: loaded eeprom from mtd device "config"
[   12.250439] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected
[   12.265890] ieee80211 phy0: rt2800_init_eeprom: Error - Invalid RF chipset 0x0000 detected
[   12.282370] ieee80211 phy0: rt2x00lib_probe_dev: Error - Failed to allocate device

branch dwr-921

[   13.603195] rt2800_wmac 10180000.wmac: loaded eeprom from mtd device "factory"
[   13.617675] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected
[   13.633125] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 7620 detected

(Last edited by comdek on 7 Aug 2017, 15:23)

I think that the problem is related to the different definition of the eeprom partition:

not working:
[   12.236132] rt2800_wmac 10180000.wmac: loaded eeprom from mtd device "config"

working:
[   13.603195] rt2800_wmac 10180000.wmac: loaded eeprom from mtd device "factory"

Why are you redefining the partition table?

[    0.376021] 0x000000000000-0x000000030000 : "u-boot"
[    0.387723] 0x000000030000-0x000000040000 : "u-boot-env"
[    0.400136] 0x000000040000-0x000000050000 : "factory"
[    0.412042] 0x000000050000-0x000001000000 : "firmware"

for sure this table doesn't work on DWR-921-C1.

Bye.

Dear all it seems that the LEDE core developers do not like the way how we propose to install the fw and derfore they will not integrate the support for this board.

The best way to install the fw is to generate a factory image using the stock bootloader to apply the lede image.
Such image require a proper format. The oem binboy tool is able to generate this file.
Unfortunately there are no source code for the binboy tool and the LEDE system do not accept binary tool integrated in the toolchain.
You can check and contribute to the discussion here:
https://github.com/lede-project/source/pull/1279

Therefore the only solution is emulate the binboy process.

After some investigation and analysis this are my preliminary results:
The binboy tool concatenate the kernel (lzma compressed) and the rootfs file appending a proper header on the top.

The header is composed 0x88 byte long and the first 0x50 byte are used by the bootloader (to analyze/verify the fw file ?), the other 0x38 are stored in the flash with some modification.

Here an example:

the firmware for jboot:

xxd -g1 -l0x100 DWR-921_RevC_Firmware3.01b07.bin 
00000000: 44 4c 4b 36 45 32 34 31 34 30 30 31 00 00 33 b9  DLK6E2414001..3.
00000010: 00 00 00 00 00 00 00 00 00 00 01 00 74 77 bd 08  ............tw..
00000020: 00 00 01 00 00 00 17 00 00 00 01 00 4c de 13 00  ............L...
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000040: 42 48 02 00 00 00 04 04 00 00 00 00 24 6e 46 e6  BH..........$nF.
00000050: ff 04 24 2b 74 77 bd 08 3c de 13 00 38 b8 1d ba  ..$+tw..<...8...
00000060: 24 21 03 02 00 00 00 80 14 de 13 00 7c 61 6e 69  $!..........|ani
00000070: 00 00 00 80 00 00 18 bc 00 a0 75 00 10 5a e6 1a  ..........u..Z..
00000080: fb 8d 6b e6 28 00 00 00 5d 00 00 00 02 64 27 3a  ..k.(...]....d':    <- Start compressed LZMA data @0x88
00000090: 00 00 00 00 00 00 00 6f fd ff ff a3 b7 ff 47 3e  .......o......G>

The flash image compared with the 2nd header section (starting from 0x50):

flash                                                 bootloader input file (from 0x50)
04 04 24 2b 2c 25 9f 08 01 df 13 00 38 cf be f4       ff 04 24 2b 74 77 bd 08 3c de 13 00 38 b8 1d ba
24 21 03 02 00 00 00 80 d9 de 13 00 2c 81 bc a8       24 21 03 02 00 00 00 80 14 de 13 00 7c 61 6e 69
00 00 00 80 00 00 18 bc 00 80 70 00 18 42 df 85       00 00 00 80 00 00 18 bc 00 a0 75 00 10 5a e6 1a
6e f3 c3 e9 28 00 00 00 5d 00 00 00 02 64 27 3a       fb 8d 6b e6 28 00 00 00 5d 00 00 00 02 64 27 3a

If someone can contribute, can generate the fw for the  binboy tool in this way:

after cloning my dwr921_binboy branch from the https://github.com/fid0did0/source.git repository, and generate the relevant image, go in a dedicated directory:
cd <IMAGE_DIR>

copy the binboy tool from the GPL distribution provided by dlink and generate the image file in this way:

cp <LEDE_DIR>/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/dwr-921-kernel.bin .
mv dwr-921-kernel.bin zImage.lzma

cp <LEDE_DIR>/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/root.squashfs .
mv root.squashfs squashfs.o

./binboy-static @linux
./binboy-static @rootfs
./binboy-static @mydlink
./binboy-static @all

If you find some important element share them here.

Bye.

Fidodido,

Is not it easier to write a script to write the uboot using mtd_debug, doing a Jboot backup before? So it would be possible to return the router to the factory if want.

I already managed to make the 4G connection work in IPv4. I did it directly with the uqmi command. By luci it creates an interface qmi-wwan0, but does not find that name.
https://thumb.ibb.co/ij5KPv/3.png


The problem it the 4G is limited at 800kb/s max. In stock firmware I get 2.0~3.7mb/s speed.

(Last edited by comdek on 8 Aug 2017, 02:17)

IPv4/IPv6 are working, after a several tests with uqmi:

uqmi -d /dev/cdc-wdm0 --set-data-format 802.3
uqmi -d /dev/cdc-wdm0 --wda-set-data-format 802.3
uqmi -d /dev/cdc-wdm0 --sync
uqmi -d /dev/cdc-wdm0 --get-client-id wds
uqmi -d /dev/cdc-wdm0 --set-client-id wds,1 --start-network --ip-family ipv4
uqmi -d /dev/cdc-wdm1 --get-client-id wds
uqmi -d /dev/cdc-wdm1 --set-client-id wds,2 --start-network --ip-family ipv6

root@LEDE:~#
root@LEDE:~# uqmi -d /dev/cdc-wdm0 --get-current-settings
{
        "pdp-type": "ipv4-or-ipv6",
        "ip-family": "ipv4",
        "mtu": 1500,
        "ipv4": {
                "ip": "100.115.224.158",
                "dns1": "200.204.135.200",
                "dns2": "200.204.135.202",
                "gateway": "100.115.224.157",
                "subnet": "255.255.255.252"
        },
        "ipv6": {

        },
        "domain-names": {

        }
}
root@LEDE:~# uqmi -d /dev/cdc-wdm1 --get-current-settings
{
        "pdp-type": "ipv4-or-ipv6",
        "ip-family": "ipv6",
        "mtu": 1500,
        "ipv4": {

        },
        "ipv6": {
                "ip": "2804:18:43:6d12:ec:82b8:ae6:dc9e",
                "ip-prefix-length": 64,
                "gateway": "2804:18:43:6d12:e072:352:f096:218",
                "gw-prefix-length": 64,
                "dns1": "2001:12e0:0:1025:a080::7",
                "dns2": "2001:12e0:0:1025:a080::9"
        },
        "domain-names": {

        }
}
root@LEDE:~#

/etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd4b:0e6f:8c6f::/48'

config interface 'lan'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.0.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option _orig_ifname 'eth0.1 radio0.network1'
        option _orig_bridge 'true'
        option ifname 'eth0'

config device 'wan_dev'
        option name 'eth0.2'
        option macaddr '00:0c:43:76:20:71'

config device 'lan_dev'
        option name 'eth0.1'
        option macaddr '00:0c:43:76:20:70'

config interface 'wwan0'
        option proto 'qmi'
        option device '/dev/cdc-wdm0'
        option apn 'zap.vivo.com.br'
        option pincode '1234'
        option username 'vivo'
        option password 'vivo'
        option auth 'pap'

config interface 'wwan0_ipv4'
        option proto 'dhcp'
        option ifname 'wwan0'

config interface 'wwan0_ipv6'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option _orig_ifname 'wwan0'
        option _orig_bridge 'false'
        option ifname 'wwan1'

(Last edited by comdek on 8 Aug 2017, 03:46)

Does the LEDE images generated by binboy work if you flash them over stock firmware? If they do; all that is needed is to re-create the binboy code in a FOSS utility. since it's so small the disassembly should be easy (enough) to understand

Redfoxmoon,
you are right this is the right way to proceed.
I will open a page describing what I realized about the jboot and binboy.
In this way, with the contribution of everybody, it will be possible to integrate the FOSS binboy in the LEDE system.

By the way, currently is not a final decision that the PR will be rejected.
But I'm also agree that replacing the bootloader is not the best way to support the device in LEDE.

Bye.

Will this router ever be supported? Looking to buy one and install Open RWT. Rich

As stated in the previous posts one pull request able to support the router is pending, but due to the not simple installation procedure (bootloader replacement), it is not sure that the PR will be accepted.

The best way to support the Pull Request is to decode the stock firmware headers and replicate it in the owrt system.

After my summer break  I will publish my investigation about, in this way all the people able to contribute can proactively accelerate the finalization.

bye.

Dear All,
as promised I update the https://wiki.openwrt.org/inbox/d-link/d … e_cracking with all the informations I collected about the jboot stock bootloader embedded in the dwr-921.

Unfortunately I cannot dedicate more time in the next future, therefore I cannot proceed with the investigation.
For sure I can support interested people through this forum to identify the relevant lacking info about the file format and consequently prepare the factory and the sysupgrade image for the lede/owrt system.

I dont know if that can help
i found that on dlink page :


dlink-gpl.s3.amazonaws.com/GPL1500246/DWR-921C1_GPL_V3.00b07_20150724.tar.bz2

fidodido wrote:

Dear All,
as promised I update the <link> with all the informations I collected about the jboot stock bootloader embedded in the dwr-921.

I find how jboot calculate data in 0x0C and 0x0E:

00000000: 04 04 24 2b    magic
00000004: 74 77 bd 08    Timestamp : (UTC_TIME-0x35016f00)/4
00000008: 3c de 13 00    size(kernel.bin)+0x28
0000000c: 38 b8         jboot_checksum(start value: 0, start address: 0x00000010, length: size(kernel.bin)+0x28) -> jboot_checksum description below
0000000e: 1d ba         jboot_checksum(start value: 0, start address: 0x00000000, length: 0x0c) -> jboot_checksum description below
00000010: 24 21 03 02    magic ?
00000014: 00 00 00 80    kernel ram load address ?
00000018: 14 de 13 00    size(kernel.bin)
0000001c: 7c 61 6e 69    crc32(kernel.bin)
00000020: 00 00 00 80    kernel ram load address ?
00000024: 00 00 18 bc     root.squashfs flash load address
00000028: 00 a0 75 00     size(root.squashfs)
0000002c: 10 5a e6 1a    crc32(root.squashfs)
00000030: fb 8d 6b e6    ??? crc of the previous 7/8 words
00000034: 28 00 00 00     magic
00000038: 5d 00 00 00     <- 0x38 kernel (in lzma format) start
0000003c: 02 64 27 3a

What is jboot_checksum? It make sum of 16-bit data. If counter is above 0xFFFF, is added extra "1". See c code:

uint16_t checksum(uint16_t start_val, uint16_t *data, int size)
{
  uint32_t counter;
  uint16_t  *ptr;
 
  counter = start_val;
  ptr = data;
  while ( size > 1 )
  {
    counter += *ptr;
    ++ptr;
    while ( counter >> 16 )
      counter = (uint16_t) counter + (counter >> 16);
    size -= 2;
  }
  if ( size > 0 )
    counter += *(uint8_t *)ptr;
  while ( counter >> 16 )
    counter = (uint16_t) counter + (counter >> 16);
  return counter;
}

I add info here:
ht*tps://wiki.openwrt.org/inbox/d-link/dwr-921_image_cracking (I can't add link).

The last unknown is 0x30.

I made firmware builder for jboot devices.

It can be find at:
ht*ps://github.com/CHKDSK88/openwrt-1/commit/7ae534482e44f6efd85a2b6c8eaacb3d32473b06

Could somebody test it with DWR-921 or another jboot device?

Well done chkdsk,
I will check your investigation on the dwr 921 and dwr 512 as soon as I can (not very soon) and I will report here the results.
But your observation confirm some previously analysis I did, so they are very promising.

Therefore now we only need to identify the word at 0x00000030.

Bye.

fidodido wrote:

Well done chkdsk,
I will check your investigation on the dwr 921 and dwr 512 as soon as I can (not very soon) and I will report here the results.

Thank You. I'am glad to You want help.


fidodido wrote:

Therefore now we only need to identify the word at 0x00000030.

Bye.

0x30 is known too. It is crc32 of all header. I updated the wiki article couple days ago.

Durring last time, I create the image builder and jImage parser:
ht*ps://github.com/openwrt/openwrt/pull/712 -> image builder
ht*ps://github.com/openwrt/openwrt/pull/717 -> jImage parser in kernel
That can be used like in my DWR-116 PR:
ht*ps://github.com/openwrt/openwrt/pull/675

If You don't have much time, I can try create images for DWR-512 and 921, but I don't have devices for tests.

Dear chkdsk,
with pleasure I can confirm that I generated a booting linux image using your dlink image tools for the dwr-921.
The generated image can be installed using the jboot or the standard stock firmware from dlink.
In this way we can install openwrt on this router without replacing the bootloader and it is also possible restore the factory firmware.

Currently I'm able to boot completely the distribution with the relevant the rootfs.
I will publish the pull request to support the router as soon as I will fix and verify the small issue concerning the configuration (eth switch, wirless, gpio and led).

Thanks.
Bye and stay tuned.

fidodido wrote:

Dear chkdsk,
with pleasure I can confirm that I generated a booting linux image using your dlink image tools for the dwr-921.
The generated image can be installed using the jboot or the standard stock firmware from dlink.
In this way we can install openwrt on this router without replacing the bootloader and it is also possible restore the factory firmware.

Currently I'm able to boot completely the distribution with the relevant the rootfs.
I will publish the pull request to support the router as soon as I will fix and verify the small issue concerning the configuration (eth switch, wirless, gpio and led).

Thanks.
Bye and stay tuned.

That's great news! I can't wait for Your PR.

My support for DWR-116 and mkdlinkfw is still waiting for approval.

Hi chkdsk,
I'm struggling with the wan port on this device and I suspect that there is a bug in the driver.
Because you tested the DWR-116 based on the MT7620n you should have the same behaviour.

Can you confirm that you successfully tested the wan port with your image?

In positive case, wich kernel are you using and what is the base commit you use to test your image?

Second question:
after some installation I realize that I cannot use anymore the jboot recovery image web page and I need to use the curl according to your advice.
Do you know why there is this problem?

Thanks,
Bye.

fidodido wrote:

Hi chkdsk,

Hi fidodido,

fidodido wrote:

I'm struggling with the wan port on this device and I suspect that there is a bug in the driver.
Because you tested the DWR-116 based on the MT7620n you should have the same behaviour.

Can you confirm that you successfully tested the wan port with your image?

I had the same problem. Jboot disable WAN port by default. I have to make a patch.

In positive case, wich kernel are you using and what is the base commit you use to test your image?

I made a patch:
https://github.com/openwrt/openwrt/pull … 0f5012d6d6

fidodido wrote:

Second question:
after some installation I realize that I cannot use anymore the jboot recovery image web page and I need to use the curl according to your advice.
Do you know why there is this problem?

That's a good question. I have to use curl but i have no idea why.
After revert to stock, works webgui normally?


Thanks for replay.

(Last edited by chkdsk on 27 Feb 2018, 20:42)

fidodido wrote:

after some installation I realize that I cannot use anymore the jboot recovery image web page and I need to use the curl according to your advice.
Do you know why there is this problem?


My JBOOT recovery web page problems are gone after I disabled the 3rd party antivirus / firewall on my Windows workstation.

I think this is OS and/or browser incompatibility.

@fidodido

Could You upload a full memory dump C1? My C3 is a brick and I look for bootloader and config partition.

Here you can find the bootloader and config.
https://filebin.ca/3vAMRgKhTvH0

With this you can update the oem fw from dlink.
I cannot give you the full image because I have only one with some certificate that I cannot share.

Bye.

The discussion might have continued from here.