Looking for info and possibility of (future) support of TP-Link Omada er605 Router

I have not encounted this issue.
The MAC adress is detected and set on sysupgrade. See code below,

mtd_get_mac_uci_config_ubi() {
	local volumename="$1"

	. /lib/upgrade/nand.sh

	local ubidev=$(nand_attach_ubi $CI_UBIPART)
	local part=$(nand_find_volume $ubidev $volumename)

	cat "/dev/$part" | sed -n 's/^\s*option macaddr\s*'"'"'\?\([0-9A-F:]\+\)'"'"'\?/\1/Ip'
}

The only reason it would be random is if the partition the MAC address was on was overriden before running sysupgrade.

As I didnt use @chill1Penguin method of flashing recovery then OpenWRT I dont know if that is the cause or not. Maybe they can shed some light on it?

In the mean time you can just force OpenWRT to use the "correct" MAC.

Network -> Interfaces -> Devices -> eth0 -> Configure -> MAC address

Hi @Darbness thanks for the info,

The problem is not in eth0/eth1.... the MAC address problem is in the dsa device (in my case), the rest of devices always get the same MAC after rebooting/upgrading.

Can you check if your dsa device changes MAC after rebooting?

Thanks,

Yep, that changes after a reboot. I dont use VLANs so not much help here sorry.

Thanks @Darbness for the feedback!!!

In my case VLANs are working fine.

With the stock firmware, the MAC address is in the tddp UBI partition. The method I developed for flashing preserves this partition. If you overwrote the tddp partition or deleted it, then your MAC address will go to a random address.

As for the MAC address changing on the dsa switch, I can confirm that the address also changes to a random MAC for me, as well. To fix this by default, I suspect that a patch would have to be developed. I don’t have time to do so at the moment. Manually setting the MAC in LUCI seems to fix the changing MAC on the dsa switch.

2 Likes

If I touch anything in dsa device (via Luci), the network becomes unresponsive.
To make it work again, I have to edit network file and remove dsa device and reboot network.

Any updates on this? I have a v2, but I'm afraid to install and have no internet at all at home :frowning:

cheers

I have both the 605 (with OpenWRT installed - thank you @chill1Penguin for the super easy install script!) and 8511. With that said, given I want to get OpenWRT up on the latter device.

Some information regarding the ER8411 (the successor to the 605):

ubinfo
root@ER8411:/# ubinfo -a

UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:59
Present UBI devices:            ubi0

ubi0
Volumes count:                           19
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     2016 (255983616 bytes, 244.1 MiB)
Amount of available logical eraseblocks: 1001 (127102976 bytes, 121.2 MiB)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  40
Current maximum erase counter value:     2
Minimum input/output unit size:          2048 bytes
Character device major/minor:            241:0
Present volumes:                         0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        2 LEBs (253952 bytes, 248.0 KiB)
State:       OK
Name:        partition-table
Character device major/minor: 241:1

Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        2 LEBs (253952 bytes, 248.0 KiB)
State:       OK
Name:        support-list
Character device major/minor: 241:2

Volume ID:   2 (on ubi0)
Type:        static
Alignment:   1
Size:        67 LEBs (8507392 bytes, 8.1 MiB)
Data bytes:  4141997 bytes (3.9 MiB)
State:       OK
Name:        kernel
Character device major/minor: 241:3

Volume ID:   3 (on ubi0)
Type:        static
Alignment:   1
Size:        265 LEBs (33648640 bytes, 32.0 MiB)
Data bytes:  27918336 bytes (26.6 MiB)
State:       OK
Name:        rootfs
Character device major/minor: 241:4

Volume ID:   4 (on ubi0)
Type:        static
Alignment:   1
Size:        2 LEBs (253952 bytes, 248.0 KiB)
Data bytes:  131 bytes
State:       OK
Name:        firmware-info
Character device major/minor: 241:5

Volume ID:   5 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        83 LEBs (10539008 bytes, 10.0 MiB)
State:       OK
Name:        rootfs_data
Character device major/minor: 241:6

Volume ID:   6 (on ubi0)
Type:        static
Alignment:   1
Size:        67 LEBs (8507392 bytes, 8.1 MiB)
Data bytes:  4141511 bytes (3.9 MiB)
State:       OK
Name:        kernel.b
Character device major/minor: 241:7

Volume ID:   7 (on ubi0)
Type:        static
Alignment:   1
Size:        265 LEBs (33648640 bytes, 32.0 MiB)
Data bytes:  27918336 bytes (26.6 MiB)
State:       OK
Name:        rootfs.b
Character device major/minor: 241:8

Volume ID:   8 (on ubi0)
Type:        static
Alignment:   1
Size:        2 LEBs (253952 bytes, 248.0 KiB)
Data bytes:  131 bytes
State:       OK
Name:        firmware-info.b
Character device major/minor: 241:9

Volume ID:   9 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        83 LEBs (10539008 bytes, 10.0 MiB)
State:       OK
Name:        rootfs_data.b
Character device major/minor: 241:10

Volume ID:   10 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        17 LEBs (2158592 bytes, 2.0 MiB)
State:       OK
Name:        log
Character device major/minor: 241:11

Volume ID:   11 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        17 LEBs (2158592 bytes, 2.0 MiB)
State:       OK
Name:        log.b
Character device major/minor: 241:12

Volume ID:   12 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        3 LEBs (380928 bytes, 372.0 KiB)
State:       OK
Name:        extra-para
Character device major/minor: 241:13

Volume ID:   13 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        3 LEBs (380928 bytes, 372.0 KiB)
State:       OK
Name:        extra-para.b
Character device major/minor: 241:14

Volume ID:   14 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        2 LEBs (253952 bytes, 248.0 KiB)
State:       OK
Name:        device-info
Character device major/minor: 241:15

Volume ID:   15 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        2 LEBs (253952 bytes, 248.0 KiB)
State:       OK
Name:        device-info.b
Character device major/minor: 241:16

Volume ID:   16 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        2 LEBs (253952 bytes, 248.0 KiB)
State:       OK
Name:        tddp
Character device major/minor: 241:17

Volume ID:   17 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        2 LEBs (253952 bytes, 248.0 KiB)
State:       OK
Name:        tddp.b
Character device major/minor: 241:18

Volume ID:   18 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        83 LEBs (10539008 bytes, 10.0 MiB)
State:       OK
Name:        database

Currently trying to build an image for this (thankfully, it seems like ~8 MB is available for the kernel), and I'll update this as necessary. Seems like the same process would work given the similarity in TP-Link's firmware (both kernel and kernel.b exist as well, which confirms that the recovery partition is also present on this router).

Edit: Seems like a new target is needed for mvebu/cortexa72 (board is using a Marvell's CN913x series SOC).

The release of openwrt 23 is out.
But initramfs is bigger than 5,242,880 bytes.
Do I need to build openwrt with your config to get the right size of initramfs?
Are your patches still needed in the release?

You shouldn’t need to build a new initramfs image, as you should be able to use the initramfs image I built to flash the 23.05 release sysupgrade image.

I will rebuild a 23.05 release initramfs image and publish it in the GitHub repo when I have some time.

I have now updated the GitHub repo with the 23.05 release.

2 Likes

Thank you to everyone who has contributed to this effort!

I have one ER605 v2 running OpenWRT and am learning more about OpenWRT each day. I also have some "stock" ER605s that are running a IPSec site to site VPN which has been causing us some trouble. In an attempt to fix those issues upgraded to stock firmware 2.2.2 and this is where things go a little sideways.

With that upgrade the method to login to the "debug" console no longer works.

I have been able to determine that there has been a change to the file /etc/cli_extra_cmd.tree in the 2.2.2 firmware.

This file now includes the line, "___level":1, , for the debug command.

It does not appear that the /etc/init.d/dropbear file has been modified and the debug command does still prompt for a password, just does not accept the one generated. Downgrading the firmware to 2.1.2 the generated password will work on the same box.

Has anyone had any luck accessing debug mode with firmware 2.2.2? I am still trying to figure "anything" out on what might be causing this but not being super familiar with Linux it is a struggle.

Thank you
Pale

Why don't you flash stock version 2.1.2, and then OpenWRT?

I still want to know how/if I can flash a v1 ...

3 Likes

Klingon still learning OpenWRT and the VPN configuration in the stock firmware for the remaining devices is easier to deal with. Again might be my misunderstanding of the capabilities of OpenWRT, graphical IPSec setup.

Thank you
Pale

As far as I know, there is no graphical IPSec setup in OpenWRT.

I'm running firmware 2.2.2. on ER605 and the password generated using the method described by richh above doesn't work for ssh root login. Sounds like TP-LINK closed that "loophole" in the latest firmware release?

Question, I obtained an ER605 a while back and was wondering whether flashing via SSH is necessary or if it was possible to flash via the integrated web interface. As of 2.2.2 Build 20231017 Rel.68869, SSH access doesn't work via the HTML page on your GitHub repository.

Edit: Would bootting the ER605 in recovery mode, then flashing the initramfs image and then eventually booting the sysupgrade image also be a viable solution?

I followed @chill1Penguin instructions and managed to install OpenWrt on v2 with firmware 2.1.2.
Would it be possible to add the USB interface in a future release?

Yes, flashing via SSH is necessary. You can downgrade your stock firmware to 2.1.2 and then ssh should work.