DIR-1935 Supported?

I have DIR-1935 A1 running stock firmware V1.02 (confirmed in webui, not just basing this off the sticker), and aspire to be an OpenWRT user.

What's needed for me to:

  1. Get OpenWRT running on this
  2. If #1 is successful, contribute PRs and any required documentation to make the DIR-1935 better supported/documented?

I have a 3.3V FTDI FT232RL serial adapter and an RPI1 Model B if I need to do anything with the serial header, but will need some direction.

In the event that it helps, please see below.


  • SOC: MT7621? Based on this and that thread.
  • 5GHz radio(s) is/are MT7615 based on the threads from the previous bullet.
  • Flash size appears to be 16MB based on that thread and seeing a "winbond 25Q128JVFQ 1832" package on the PCB of my unit
    • Package seems to be SOIC-16-300mil based on its shape and multimeter measurements
    • Reviewing the Winbond website suggests that this is a 128Mb (i.e. 16MB) flash chip similar to the W25Q128FV and/or W25Q128JV. I can't tell much difference between these two chips from the first few sections of their datasheets, other than one being slower than the other.
  • USB Ports:
    • 1 front 3.0 port
    • PCB appears to have unpopulated pads for a rear USB 2.0 like the DIR-882 A1 (and others?)
  • Internal serial header appears to be the same as the DIR-882 A1 (and others?)

Bottom label:

Flash chip:

Top of PCB:

Bottom of PCB:

The general instructions are on the Wiki: https://openwrt.org/docs/guide-developer/add.new.device

What's missing are probably the first steps:

  • Get access to the boot loader via serial console
  • Check if there is an option to load an image from a TFTP server and boot it from RAM (very important)
  • Build a basic initramfs image and boot it from via TFTP
  • Fix things in the initramfs image and only as the last step try to make it persistent, i.e. flash it.
1 Like

sure sounds like a dir-878/882 A1 clone
connect you serial header capture the output as it's booting & keep it
compare it to the dir-882-a1's it's there on it's page
you want to make sure it's flash memory partition layout is the same
if it is the same you should be able to load it's initramfs image into ram only
via the "1: Load system code to SDRAM via TFTP." boot loader option
this should allow you to backup the untouched flash as it is now via saving all the MTD'S

1 Like

I soldered a header but am not able to get any signs of life from a serial connection from the router.

I'm using this command in linux:

screen /dev/ttyUSB0 57600,-parenb,-cstobp,cs8

/dev/ttyUSB0 is my USB to UART adapter (FTDI FT232 Serial UART). The jumper is set for 3.3V (as opposed to 5V). I've tried reversing RX and TX in case my adapter's labeling is funny and still get no output (garbled or not, I get nothing at all). When I disconnect RX and TX from the router and short them on the USB adapter, whatever characters I type appear on screen as if I'm in a text editor. I have GND on the router connected to GND on the USB adapter.

When first attempting this I had VCC connected between the router and adapter. After stopping this, both the VCC pins read ~3.3V to their respective GNDs, but I may have zapped something on the router. The router still boots and presents a wifi network fine though.

What have I missed and/or bungled?

Thank you

Edit: Should a loopback test using screen produce exactly one character per keypress, just like a text editor? This is what I'm getting, but youtube videos of other loopback tests suggest I should be getting 2x my inputs either on a per-key basis (e.g. HHEELLLLOO) or after hitting enter (e.g. HELLO HELLO). I wonder if my USB adapter's RX pin is a dud. I've never used this adapter before.

I'm a windows user for context so I can't comment on what to use in linux
but if you are looping back it sounds ok
only if you have local echo you will get 2x show up. The outgoing & the returning data
yes better not to connect +3v just gnd tx & rx for most usb adapters
if you just get routers tx & your rx & gnd then you should see the data just after power on
you need the other rx-tx connecting to interact tho
I just use putty for serial data

Check the voltages on the Rx and tx pins on the router, see if there’s anything there at all.

If not, follow the traces back and see what’s missing. Some vendors kill the uart with resistors or jumpers.

I tried putty and also only have my inputs show up 1:1 (e.g. HELLO, not HHEELLLLOO) with the same USB serial adapter when I bridge the RX and TX pins. Is this expected behaviour?

Throughout the bootup process the voltage between the TX and GND pins of the router is 0V (+/-0.003V). There is no continuity between these pins (no beep in continuity mode, resistance too high for my meter to measure).

The only other devices I have that could read are Arduino Nano clones, but I don't have a sketch for that handy.

Thank you

Edit: I've decrypted and extracted the stock firmware for a DIR-1935 and DIR-882 A1. I'm poking around to see if I can figure out the flash layout there. Any pointers?

Still no luck on serial but fortunately, the exploit detailed here is unpatched on the firmware version on my DIR-1935, and the python3 script worked for me. I now have access via telnet.

The flash layout appears to match the DIR-882 A1 OEM layout. I base this on the output of cat /proc/mtd, where the "name" of each partition matches, and the "size" matches when you convert the size values in /proc/mtd to decimal then convert to kB.

I copied each of the mtd partitions (/dev/mtdX, X=0..6) with dd onto a usb stick. Are their contents of interest?

What's next?

Thank you

I believe with putty you will only see what's being receive "no local echo" off the top of my head

you do really want the flash backup and it be correct
the factory calibration data is custom to your device you want to back this up just in case
also it the easiest way to get decrypted firmware that will upload via the recover interface

but really you still need serial access to debug the loading process
would be good to test with the initramfs to find out what works & not

but you can with more risk just flash to the device

anyway you could try the dir-882 firmware it depend on if it requires the header
some do some don't

but then duplicate the DIR-882-A1 in openwrt with new correct model number
and by changing the model number will generate the header with the new model number
that I think will be required for flashing

and from then it just checking & finding what need changing

are there 2x MT7615Nx4 radios or do you have a DCDB setup where it's split x2 for 2.4G & 2x for 5G ?

How do I back up the flash and verify that the backup is correct? I'll do another dd backup of /dev/mtd0..6 on a different USB stick and compare the results to the first.

I'm out of ideas with the serial connection, I don't think I can get it going:

  • Based on a video doing the same test, putty with default settings gives you 1:1 when you do a loopback test. This indicates that my USB adapter works.
  • When I measure TX - GND voltage on the USB adapter, I get ~3.3V and it drops when I transmit. When I do the same on the router's TX - GND, I get ~0V.
  • I don't see any unpopulated pads or anything on the PCB like on some TP-Link boards. The TX trace seems to go straight into the SOC's EMI shield and none of the caps on the other side have continuity to the TX pin.

How do I check the radios?

To ensure the header thing isn't an issue, should I build a new OpenWRT image (using the DIR-882 A1 as a starting point)? Could you link me to directions on how to do that?

How do you suggest I flash it? As far as I can tell I can flash OpenWRT with:

  • D-Link Recovery GUI
  • mtd_write -r -w write /tmp/firmware.img Kernel #(where /tmp/firmware.img is the firmware image)

Thanks again, I appreciate your patience

as I don't use the method you used to backup the mtd's "do get all of them"
you should be able to look at the firmware one in a hex editor & see the same type of header
that the Openwrt factory image has
while here look for the model number in the header and see it's it matches the real one

you do get a lot of information from the boot logs radios would be one of the things to look for
tho it's labelled as AC1900 so I'm thinking the same as the DIR-878's tho it's really ac2300

you can check your voltage range input of your serial but it seems like v3.3 but if it's only 5v it may not see the data at a lower level

anyway find your self a 10K resister & pull up the serial adapters RX worth a try & 10K won't break anything

you can look at the factory partition the 1st few bytes are the radio's model eg 15,76 for 7615 at 0 & 8000 HEX

as for flashing I would try the current DIR-882-A1 V23 factory image it has luci in it
you will find out quickly if it requires the correct model number in the header or not

tho this would be backed up by watching the serial port & looking for errors as it tries

found this old thread as well

here is the DIR-882-A1 factory file with the header manually changed to 1935

My dump of mtd5 has "DIR-1935" in the first 80 characters, and when viewed in a hex editor the model starts at the same place as the latest openwrt factory image for the DIR-882.

I tried a 9k pullup resistor and the TX pin on the router does pull up to ~3.3V, but it doesn't vary and I don't get any data in putty. I removed the USB adapter and changed the jumper to 5V mode and the TX-GND voltage went from ~3.3V to ~5V, so I think the jumper was set correctly in 3.3V mode.

My dump of mtd3 has 15,76,a0 at address 0 and 8000.

I couldn't access your link, but I tried flashing the DIR-882 A1's factory image (same filename as yours) after changing the DIR-882 to DIR-1935 and the D-link recovery gui rejected it (Update failed!). However, the unmodified DIR-882 worked and now it's running openwrt.

Both 2.4Ghz and 5Ghz networks work (used different SSIDs to confirm), however the range on the 5GHz one is really bad (about 50ft, up a staircase). At a location immediately before it drops, ping is still <10 ms and iperf3 speed is >150 Mbit/s on my laptop (intel dual-band wifi card). Any suggestions to improve range? I will try another power adapter for the router (the one I have for it is sketch), different channels, and different antenna orientations.

Now that it's running openwrt more or less correctly, what can I do to improve the state of documentation and build availability for the DIR-1935?

ok sounds like the recovery interface is not requiring the matching model number :slight_smile:

I think there was something about then not putting the MAC addresses in the radio calibration data
& it was showing bad mac addresses not sure it changes anything radio tho
but it did need fixing for later DIR-878's

but really entry's need to be made for the DIR-1935 same as for the DIR-878/882 etc
and a pull request genarated

not sure much can change for the radio's
I can't imagine the radio config have been swapped compared to the other ones

ether there is something wrong with you adapter or you have broken you serial interface
as in the other thread someone was able to use it find on the same model

other then changing channels I'm not sure what you can do for the radio's
just getting away from other interfering devices

not sure if you know how to build it your self but can start at the link below

I tried troubleshooting the wireless range again and after leaving the DIR-1935 running with the channel on auto for awhile the 5GHz band range improved and throughput was good. My guess is that the issue was interference with my nearby wifi AP. I haven't done thorough testing but will start using it instead of my regular AP for awhile and see if it behaves. Edit: Both the DIR-1935 and my regular AP are on the same 5GHz channel. Could just be interference and not a radio issue.

I reviewed the PR that added support for the D-Link DIR-867 A1 and DIR-882 A1. I added equivalent files/sections for the DIR-1935 A1 based on this PR. Following the high-level directions here, I made squashfs files for the DIR-882 A1 and DIR-1935 A1.

The checksums of the DIR-882 A1 squashfs-factory and squashfs-sysupgrade bin files do not match the latest equivalents linked here. Does that indicate a problem? If not, what's the next step? If it's firmware flashing, is it safer to use the D-Link Recovery GUI to flash the squashfs-factory file, or using LuCi to flash the squashfs-sysupgrade file? I never got serial access working so I don't want to brick a seemingly working device.

Thank you

Hi kewiha
even the change in the model number will change checksums
you should have a copy of the factory firmware
you should prune some of the blank ff's off the end tho
if you look in with a hex editor you will see where
I usually round it off & cut it XX000 address
after this you will be able to recover back to that version via the
recovery console
this is also the same place I recommend you flash the factory openwrt file

so in the end was there any changes from the DIR-882-A1 ?
are the leds still green ?
are the WIFI MAC address correct ?

The only difference I noticed from the DIR-882 A1 were related to LEDs. DIR-882 A1 has two USB activity LEDs that are not present on the DIR-1935 (visually identical to this picture of the DIR-867 A1). How I addressed this is below:

  • For the dts file I started with target/linux/ramips/dts/mt7621_dlink_dir-882-a1.dts but removed the &leds section, consistent with target/linux/ramips/dts/mt7621_dlink_dir-867-a1.dts
  • In target/linux/ramips/image/mt7621.mk I removed "kmod-usb-ledtrig-usbport" in DEVICE_PACKAGES

I'll try flashing the squashfs-factory file I made using the D-Link Recovery GUI. The squashfs-factory file I made does not appear to need the FF's at the end of the file trimmed, just like the squashfs-factory file for the DIR-882 A1 from the openwrt website. Hopefully this will work as expected and I won't have to try to reflash the OEM firmware to recover. I'll report back on the LEDs and MAC address afterwards.

it's the old factory firmware "D-Link OEM" that needs the extra padding removed
the kernel partition you saved
you need this to go back to D-Links OEM firmware

the picture shows the LED's as green are they still green ?
green is what's listed in the 8xx include file
if you can just use that it saves a lot of work
it seems weird that there is no usb led tho oh well

I built and flashed a build of v22.03.2 for the DIR-1935 A1 via DLink recovery gui and at first glance it seems to be behaving the same as when it had the DIR-882 A1 file on it.

LEDs are still green and behave as expected.

MAC addresses seem unchanged from the DIR-882 A1 firmware, and a MAC address lookup tool say they correspond to D-Link.

What testing should I do to confirm that everything is working properly?