Request for TP-Link RE220 v1 images (RE200 v3 clone) by someone with a toolchain

Yeah, I am puzzled. I don't know how to fix the image not pulling in the kmods necessary for the RE220v1. Please test the firmware for a few days to ensure your device works as expected. I hope we can find out where the problem lies.

@amteza, @Borromini, Thank you for working on this.

I think we can wrap this up. Testing passed*.
I reccomend the RE220v1 can be released as a supported device based on the images from Borromini.

*There were some stability and performance issues with the 5GHz radio, but on par with the currently supported RE220v2.

I installed the factory image fro Borromini's Sept 29 post on an unmodified stock RE220v1 (1.8). I hadn't looked at it earlier as I thought is was something being provided for @amteza.

It installed fine and testing was overall successful.

tyrekick: single port eth0 configured as uplink, output from tyrekick.sh -y -s -medium

root@OpenWrt:/tmp# cat /tmp/tk-2022-10-05-16-21-19/tk-TP-Link-RE220-v1-SNAPSHOT-
2022-10-05-16-21-19.csv
model,OUI,testID,result-v1
TP-Link-RE220-v1,74da88,inet-dns-000001,pass
TP-Link-RE220-v1,74da88,ntp-000001,pass
TP-Link-RE220-v1,74da88,uhttpd-000001,pass
TP-Link-RE220-v1,74da88,firewall-fw4-test-000001,pass
TP-Link-RE220-v1,74da88,opkg-unzip-000001,pass
TP-Link-RE220-v1,74da88,iperf3-000001,pass
TP-Link-RE220-v1,74da88,all-radio-on-000001,pass
TP-Link-RE220-v1,74da88,wireless-extra-options-radio0-2g-11-10-psk2,pass
TP-Link-RE220-v1,74da88,wireless-extra-options-radio1-5g-36-10-psk2+ccmp,pass
TP-Link-RE220-v1,74da88,radio0-2g-1-10-psk2,pass
TP-Link-RE220-v1,74da88,radio0-2g-1-10-sae,pass
TP-Link-RE220-v1,74da88,radio0-2g-1-10-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio0-2g-1-1-psk2,pass
TP-Link-RE220-v1,74da88,radio0-2g-1-1-sae,pass
TP-Link-RE220-v1,74da88,radio0-2g-1-1-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio0-2g-6-10-psk2,pass
TP-Link-RE220-v1,74da88,radio0-2g-6-10-sae,pass
TP-Link-RE220-v1,74da88,radio0-2g-6-10-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio0-2g-6-1-psk2,pass
TP-Link-RE220-v1,74da88,radio0-2g-6-1-sae,pass
TP-Link-RE220-v1,74da88,radio0-2g-6-1-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio0-2g-11-10-psk2,pass
TP-Link-RE220-v1,74da88,radio0-2g-11-10-sae,pass
TP-Link-RE220-v1,74da88,radio0-2g-11-10-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio0-2g-11-1-psk2,pass
TP-Link-RE220-v1,74da88,radio0-2g-11-1-sae,pass
TP-Link-RE220-v1,74da88,radio0-2g-11-1-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio1-5g-36-4-psk2,pass
TP-Link-RE220-v1,74da88,radio1-5g-36-4-sae,pass
TP-Link-RE220-v1,74da88,radio1-5g-36-4-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio1-5g-36-1-psk2,pass
TP-Link-RE220-v1,74da88,radio1-5g-36-1-sae,pass
TP-Link-RE220-v1,74da88,radio1-5g-36-1-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio1-5g-100-4-psk2,pass
TP-Link-RE220-v1,74da88,radio1-5g-100-4-sae,pass
TP-Link-RE220-v1,74da88,radio1-5g-100-4-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio1-5g-100-1-psk2,pass
TP-Link-RE220-v1,74da88,radio1-5g-100-1-sae,pass
TP-Link-RE220-v1,74da88,radio1-5g-100-1-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio1-5g-149-4-psk2,pass
TP-Link-RE220-v1,74da88,radio1-5g-149-4-sae,pass
TP-Link-RE220-v1,74da88,radio1-5g-149-4-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio1-5g-149-1-psk2,pass
TP-Link-RE220-v1,74da88,radio1-5g-149-1-sae,pass
TP-Link-RE220-v1,74da88,radio1-5g-149-1-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio1-5g-165-4-psk2,pass
TP-Link-RE220-v1,74da88,radio1-5g-165-4-sae,pass
TP-Link-RE220-v1,74da88,radio1-5g-165-4-sae-mixed,pass
TP-Link-RE220-v1,74da88,radio1-5g-165-1-psk2,pass
TP-Link-RE220-v1,74da88,radio1-5g-165-1-sae,pass
TP-Link-RE220-v1,74da88,radio1-5g-165-1-sae-mixed,pass
root@OpenWrt:/tmp#

I did have a few issues. Some of these could be environmental with crowded wifi space.
A 5GHz uplink might take 10min or more to connect even on non DFS channel.
Performance issues on 5GHz
A ubus call hostapd error
MAC errors

The 5GHz radio had performance issues.
The 6MBit/s problem was also noticed on RE220v2.

rx bit rate 6MBit/s while tx is 72 MBit/s

#note this is from an RE220v2, but RE220v1 was same
root@OpenWrt:~# iw dev wlan1 station dump
Station redacted  (on wlan1)
        inactive time:  10 ms
        rx bytes:       743327
        rx packets:     3758
        tx bytes:       1323996
        tx packets:     3500
        tx retries:     947
        tx failed:      34
        rx drop misc:   0
        signal:         -23 [-23] dBm
        signal avg:     -32 [-32] dBm
        tx bitrate:     72.2 MBit/s MCS 7 short GI
        tx duration:    401427 us
        rx bitrate:     6.0 MBit/s
        rx duration:    1084239 us
        airtime weight: 256
        expected throughput:    34.148Mbps
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        DTIM period:    2
        beacon interval:100
        short preamble: yes
        short slot time:yes
        connected time: 228 seconds
        associated at [boottime]:       954.707s
        associated at:  1665003159481 ms
        current time:   1665003387034 ms

ubus hostapd error

Wed Oct  5 19:02:28 2022 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan1 wasn't started
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783): Command failed: ubus call hostapd config_add {"iface":"wlan1", "config":"/var/run/hostapd-phy1.conf"} (Invalid argument)
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783): Usage: ubus [<options>] <command> [arguments...]
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783): Options:
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  -s <socket>:             Set the unix domain socket to connect to
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  -t <timeout>:            Set the timeout (in seconds) for a command to complete
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  -S:                      Use simplified output (for scripts)
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  -v:                      More verbose output
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  -m <type>:               (for monitor): include a specific message type
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):                   (can be used more than once)
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  -M <r|t>         (for monitor): only capture received or transmitted traffic
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783): Commands:
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  - list [<path>]                  List objects
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  - call <path> <method> [<message>]       Call an object method
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  - subscribe <path> [<path>...]   Subscribe to object(s) notifications
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  - listen [<path>...]                     Listen for events
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  - send <type> [<message>]                Send an event
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  - wait_for <object> [<object>...]        Wait for multiple objects to appear on ubus
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):  - monitor                                Monitor ubus traffic
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783):
Wed Oct  5 19:02:28 2022 daemon.notice netifd: radio1 (6783): Device setup failed: HOSTAPD_START_FAILED
Wed Oct  5 19:02:28 2022 daemon.notice netifd: Wireless device 'radio1' set retry=0
Wed Oct  5 19:02:28 2022 daemon.crit netifd: Wireless device 'radio1' setup failed, retry=0
Wed Oct  5 19:02:29 2022 daemon.notice netifd: Wireless device 'radio1' is now down

Mac errors, pretty common for mt76 devices

Sat Sep  3 03:11:33 2022 kern.err kernel: [  970.763184] mt76x0e 0000:01:00.0: MAC error detected
Sat Sep  3 03:11:39 2022 kern.err kernel: [  977.243207] mt76x0e 0000:01:00.0: MAC error detected
Sat Sep  3 03:11:46 2022 kern.err kernel: [  983.423212] mt76x0e 0000:01:00.0: MAC error detected

OEM RE220v1 bootlog prior to install.

# serial boot log from TP-LINK RE220v1  (1.8)
#  Firware Version: 1.1.0 Build 20190616 Rel. 75592(8583)  

cid reg:00010102, cid:1[04020C0E][04020D08]
DDR Calibration DQS reg = 00008988

DDR Calibration MEMCTRL reg = 0E120003

U-Boot 1.1.3 (Jun 16 2019 - 20:09:21)

Board: Ralink APSoC DRAM:  64 MB
relocate_code Pointer at: 83fb8000
Use New Uboot
Use New Uboot patch lock_dcache addiu $12, 0x1000
flash manufacture id: 20, device id 70 17
Warning: un-recognized chip ID, please update bootloader!
*** Warning - bad CRC, using default environment

============================================
Ralink UBoot Version: 5.0.0.0
--------------------------------------------
ASIC 7628_MP (Port5<->None)
DRAM component: 512 Mbits DDR, width 16
DRAM bus: 16 bit
Total memory: 64 MBytes
Flash component: SPI Flash
Date:Jun 16 2019  Time:20:09:21
============================================
icache: sets:512, ways:4, linesz:32 ,total:65536
dcache: sets:256, ways:4, linesz:32 ,total:32768

 ##### The CPU freq = 580 MHZ ####
 estimate memory size =64 Mbytes
RESET MT7628 PHY!!!!!!

Please choose the operation:
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.
default: 3

You choosed 3
                                                                                                                                                    0

3: System Boot system code via Flash.
gpioMode1 Reg: 0x571504c4
gpioMode2 Reg: 0x5550555
tplink_turn_off_led
## Booting image at bc020000 ...
text base: 80000000
entry point: 8000c150
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 8000c150) ...
## Giving linux memsize in MB, 64

Starting kernel ...

LINUX started...

 THIS IS ASIC
Linux version 2.6.36 (jenkins@Sohoiipf) (gcc version 4.6.3 (Buildroot 2012.11.1) ) #1 Sun Jun 16 20:14:47 CST 2019

 The CPU feqenuce set to 580 MHz
CPU revision is: 00019655 (MIPS 24Kc)
Software DMA cache coherency
Determined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
Zone PFN ranges:
  Normal   0x00000000 -> 0x00004000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00004000
On node 0 totalpages: 16384
free_area_init_node: node 0, pgdat 80247150, node_mem_map 81000000
  Normal zone: 128 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 16256 pages, LIFO batch:3
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: console=ttyS1,57600n8 root=/dev/mtdblock3 init=/sbin/init earlyprintk debug
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Primary instruction cache 64kB, VIPT, , 4-waylinesize 32 bytes.
Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32 bytes
Writing ErrCtl register=00019538
Readback ErrCtl register=00019538
Memory: 62304k/65536k available (1903k kernel code, 3232k reserved, 433k data, 128k init, 0k highmem)
Hierarchical RCU implementation.
        RCU-based detection of stalled CPUs is disabled.
        Verbose stalled-CPUs detection is disabled.
NR_IRQS:128
console [ttyS1] enabled
Calibrating delay loop... 386.04 BogoMIPS (lpj=772096)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
NET: Registered protocol family 16
RALINK_GPIOMODE = 571504c4
RALINK_GPIOMODE = 571404c4
***** Xtal 40MHz *****
start PCIe register access
RALINK_RSTCTRL = 2400000
RALINK_CLKCFG1 = fdbfffc0

*************** MT7628 PCIe RC mode *************
PCIE0 enabled
Port 0 N_FTS = 1b105000
init_rt2880pci done
bio: create slab <bio-0> at 0
pci 0000:00:00.0: reg 10: [mem 0x00000000-0x7fffffff]
pci 0000:00:00.0: reg 14: [mem 0x00000000-0x0000ffff]
pci 0000:00:00.0: supports D1
pci 0000:00:00.0: PME# supported from D0 D1 D3hot
pci 0000:00:00.0: PME# disabled
pci 0000:01:00.0: reg 10: [mem 0x00000000-0x000fffff]
pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
pci 0000:01:00.0: PME# disabled
pci 0000:01:00.1: reg 10: [mem 0x00000000-0x000fffff]
pci 0000:01:00.1: supports D1
pci 0000:01:00.1: PME# supported from D0 D1 D3hot D3cold
pci 0000:01:00.1: PME# disabled
pci 0000:00:00.0: BAR 0: can't assign mem (size 0x80000000)
pci 0000:00:00.0: BAR 8: assigned [mem 0x20000000-0x201fffff]
pci 0000:00:00.0: BAR 1: assigned [mem 0x20200000-0x2020ffff]
pci 0000:00:00.0: BAR 1: set to [mem 0x20200000-0x2020ffff] (PCI address [0x20200000-0x2020ffff]
pci 0000:01:00.0: BAR 0: assigned [mem 0x20000000-0x200fffff]
pci 0000:01:00.0: BAR 0: set to [mem 0x20000000-0x200fffff] (PCI address [0x20000000-0x200fffff]
pci 0000:01:00.1: BAR 0: assigned [mem 0x20100000-0x201fffff]
pci 0000:01:00.1: BAR 0: set to [mem 0x20100000-0x201fffff] (PCI address [0x20100000-0x201fffff]
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0:   bridge window [io  disabled]
pci 0000:00:00.0:   bridge window [mem 0x20000000-0x201fffff]
pci 0000:00:00.0:   bridge window [mem pref disabled]
PCI: Setting latency timer of device 0000:00:00.0 to 64
BAR0 at slot 0 = 0
bus=0x0, slot = 0x0
bus=0x1, slot = 0x0
bus=0x1, slot = 0x0
Switching to clocksource MIPS
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
PCI: CLS 80 bytes, default 32
squashfs: version 4.0 (2009/01/31) Phillip Lougher
msgmni has been set to 121
io scheduler noop registered (default)
Ralink gpio driver initialized
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x10000d00 (irq = 21) is a 16550A
serial8250: ttyS1 at MMIO 0x10000c00 (irq = 20) is a 16550A
flash manufacture id: 20, device id 70 17
Warning: un-recognized chip ID, please update SPI driver!
N25Q064A13ESE40F(20 ba171000) (8192 Kbytes)
mtd .name = raspi, .size = 0x00800000 (8M) .erasesize = 0x00010000 (64K) .numeraseregions = 0
Creating 5 MTD partitions on "raspi":
0x000000000000-0x000000800000 : "ALL"
0x000000000000-0x000000020000 : "fs-uboot"
0x000000020000-0x000000100000 : "os-image"
0x000000100000-0x0000007c0000 : "file-system"
0x0000007f0000-0x000000800000 : "radio"
TCP cubic registered
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
Freeing unused kernel memory: 128k freed
procd: Console is alive
procd: - preinit -
mounting /dev/root
procd: - early -
procd: - ubus -
procd: - init -
Please press Enter to activate this console.
GMAC1_MAC_ADRH -- : 0x0000000c
GMAC1_MAC_ADRL -- : 0x4328807b
Ralink APSoC Ethernet Driver Initilization. v3.1  256 rx/tx descriptors allocated, mtu = 1500!
GMAC1_MAC_ADRH -- : 0x0000000c
GMAC1_MAC_ADRL -- : 0x432880e7
PROC INIT OK!
liblog: module license 'unspecified' taints kernel.
Disabling lock debugging due to kernel taint
bridge: Successed to create netlink socket
reloadprofile() begin
reloadprofile() end
reloadconfig() begin
get_upgrade_level() begin
============> upgrade_level = 1
get_upgrade_level() end
get_upgrade_level() begin
============> upgrade_level = 1
get_upgrade_level() end
!!!!===> not do resetandmergeconfig .....
reloadconfig() end
user has set country
device is not production models, do nothing!!!
loadRepeaterProductInfo() end
[GPIOD][gpio_create_ibus_thread:34]create ibus thread successfully

Raeth v3.1 (Tasklet)

phy_tx_ring = 0x02e2d000, tx_ring = 0xa2e2d000

phy_rx_ring0 = 0x02e2e000, rx_ring0 = 0xa2e2e000
Gpio Mode Value: 571404c4
Gpio Mode Value: 571404c4
GMAC1_MAC_ADRH -- : 0x000074da
GMAC1_MAC_ADRL -- : 0x88933b99
RT305x_ESW: Link Status Changed
device eth2 entered promiscuous mode
br-lan: port 1(eth2) entering forwarding state
br-lan: port 1(eth2) entering forwarding state
tz isGMT+08:00
[smartip_create_ibus_thread 40] create ibus thread successfully
[smartip_start_process 761] smartipd start udhcpd...........
[onemesh_get_mesh_enable 939] Parse JSON failed!
@@@@@@@@ap follow sta ...
wifid[mtk_init_platform:5996]: mtk init platform start.
[smartip_receive_event 64] smartipd received action: 2
[smartip_receive_event 112] in ibus action wifi: set prelink_status to FALSE

MT7628-->

=== pAd = c0608000, size = 2402560 ===

<-- RTMPAllocTxRxRingMemory, Status=0, ErrorValue=0x
<-- RTMPAllocAdapterBlock, Status=0
MT7628-->RtmpChipOpsHook(492): Not support for HIF_MT yet!
MT7628-->mt7628_init()-->
MT7628-->mt7628_init(FW(8a00), HW(8a01), CHIPID(7628))
MT7628-->e2.bin mt7628_init(1135)::(2), pChipCap->fw_len(64736)
MT7628-->mt_bcn_buf_init(218): Not support for HIF_MT yet!
MT7628--><--mt7628_init()
table: 0x42dba8
on
off
MT7610-->rt2860_init_module-277)register rtpci
PCI: Setting latency timer of device 0000:01:00.0 to 64
MT7610-->RTMPAllocAdapterBlock-226)

=== pAd = c0e82000, size = 1709104 ===

<-- RTMPAllocTxRxRingMemory, Status=0
<-- RTMPAllocAdapterBlock, Status=0
MT7610-->RTMP_COM_IoctlHandle-939)pAd->CSRBaseAddress =0xc0d80000, csr_addr=0xc0d80000!
MT7610-->RTMPInitPCIeDevice-1250)device_id =0x7650
MT7610-->MT76x0_WLAN_ChipOnOff-3621)==>MT76x0_WLAN_ChipOnOff(): OnOff:1, pAd->WlanFunCtrl:0x0, Reg-WlanFunCtrl=0xff000002
MT7610-->MT76x0_WLAN_ChipOnOff-3675)MACVersion = 0x76502000
!!!!!!!!!!!!!!!!!!!cloud_brd start!!!!!
!!!!!!!!!!!!!!!!!!cloud-client start!!!
[cloud_cli.c]: main()->cloud client start.
MT7628-->TX_BCN DESC a1cba000 size = 320
MT7628-->RX[0] DESC a1cbe000 size = 4096
MT7628-->RX[1] DESC a1cbf000 size = 1024
MT7628-->AndesSendCmdMsg: Could not send in band command due to diable fRTMP_ADAPTER_MCU_SEND_IN_BAND_CMD
MT7628-->Smart Carrier Sense = 1
MT7628-->RTMPSetSingleSKUParameters - the country region is 5.
MT7628-->RTMPSetSingleSKUParameters - country code is US .
MT7628-->RTMPSetSingleSKUParameters - the country DFSType is 1.
MT7628-->Loading SKU file: /etc_ro/Wireless/RT2860/SingleSKU_2G_FCC.dat
MT7628-->load fw image from fw_header_image
MT7628-->AndesMTLoadFwMethod1(2182)::pChipCap->fw_len(64736)
MT7628-->FW Version:1MT7628-->
MT7628-->FW [https://forum.openwrt.org/t/request-for-tp-link-re220-v1-images-re200-v3-clone-by-someone-with-a-toolchain/138275/15](https://forum.openwrt.org/t/request-for-tp-link-re220-v1-images-re200-v3-clone-by-someone-with-a-toolchain/138275/15)Build Date:20170411104110MT7628-->
MT7628-->CmdAddressLenReq:(ret = 0)
truncated

Thanks, @jedboy. @Borromini, would you mind preparing the PR? It looks like your kmods are being included, not like in my firmware images. I don't know the reason, and I lack the time lately to investigate further.

I meant to mention that. Borromini's master images had the radio1 in the wireless config. And also the opkg update worked.

2 Likes

Do you get a valid MAC address though? The addresses should match with the ones the OEM firmware provides.

Edit: if you're noticing any differences with regards to LEDs etc (I won't be going through the whole other topic) then please share them here so we can look at splitting the DTS if necessary. The idea - as with anything else, like MAC addresses, is to match the OEM behaviour wherever possible.

MAC Address looks good.
eth0 address matches label on device
wlan0 is same except last octet incremented
wlan1 is same except last octet incremented from wlan0

For the leds, mostly good. Some improvement possible.
I think the fundamental problem is we are using dtsi from RE200v1 and at some point they changed from having 2 red leds, to only one.

  1. Is the model name supposed to be in dir name?
    I have not seen that before.
RE220 v2
root@OpenWrt:~# ls -al /sys/devices/platform/leds/leds
drwxr-xr-x   10 root     root             0 Jan  1  1970 .
drwxr-xr-x    3 root     root             0 Jan  1  1970 ..
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:lan
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:power
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wifi
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wifi2g
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wifi5g
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wps
drwxr-xr-x    2 root     root             0 Jan  1  1970 red:wifi2g
drwxr-xr-x    2 root     root             0 Jan  1  1970 red:wifi5g

RE220 v1
root@OpenWrt:/tmp# ls -al /sys/devices/platform/leds/leds
drwxr-xr-x   10 root     root             0 Jan  1  1970 .
drwxr-xr-x    3 root     root             0 Jan  1  1970 ..
drwxr-xr-x    2 root     root             0 Jan  1  1970 re220-v1:green:lan
drwxr-xr-x    2 root     root             0 Jan  1  1970 re220-v1:green:power
drwxr-xr-x    2 root     root             0 Jan  1  1970 re220-v1:green:wifi
drwxr-xr-x    2 root     root             0 Jan  1  1970 re220-v1:green:wifi2g
drwxr-xr-x    2 root     root             0 Jan  1  1970 re220-v1:green:wifi5g
drwxr-xr-x    2 root     root             0 Jan  1  1970 re220-v1:green:wps
drwxr-xr-x    2 root     root             0 Jan  1  1970 re220-v1:red:wifi2g
drwxr-xr-x    2 root     root             0 Jan  1  1970 re220-v1:red:wifi5g
  1. green:power needs a different name?
    Or, maybe not defined as an led at all.
    The OEM firmware has a night time mode that allows toggling all the leds off at a certain time.
    That is what this 'pin' appears to do. Set it to zero all lights go off. Set it to 255 all lights return to their previous state be it on or off.

Changing it could be a problem if the current name is only thing causing it to get set to 255. If it is not set, none of the leds turn on.
echo 0 > /sys/devices/platform/leds/leds/re220-v1:green:power/brightness
echo 255 > /sys/devices/platform/leds/leds/re220-v1:green:power/brightness

  1. red:wifi2g should renamed to green:power
    (only if existing green:power is changed to something else)
    Toggling red:wifi2g toggles the green power led on the device (one above the WPS).
    echo 255 > /sys/devices/platform/leds/leds/re220-v1:red:wifi2g/brightness

Note that with OpenWRT firmware the power led on device is off during normal operation the expected behavior is that it should be on.

  1. red:wifi5g should be renamed to red:wifi
    When set, you get a red light in the same place as green:wifi as opposed to the specific green:wifi2g and green:wifi5g locations.

I suspect that regarding #2, #3 and #4 that the RE200v3 has the same incorrect behavior. Maybe someone can test it.

The green:wifi and the red led(s) are used for extender placement and probably don't have a use with stock OpenWRT functionality.

The green:wifi2g and green:wifi5g work properly as is. They are off if corresponding radio is disabled and blinking if it is not.

See Current User Guide for led descriptions.

The RE200v1 user guide shows both 5G and 2.4G locations having separate red lights whereas the current user guide shows the red light moving to the 'Wireless Signal' (aka green:wifi) location. In other words, old version had 2 red leds. Newer version only has one red led.

Buttons worked great.
Followed the button test web page. The reset button short press would reboot. The reset button 10s would do a factor reset. The WPS button generated a WPS event.

1 Like

Confirmed. On rev200 v3, I get:

root@OpenWrt:~# ls -al /sys/devices/platform/leds/leds/
drwxr-xr-x   10 root     root             0 Jan  1  1970 .
drwxr-xr-x    3 root     root             0 Jan  1  1970 ..
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:lan
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:power
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wifi
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wifi2g
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wifi5g
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wps
drwxr-xr-x    2 root     root             0 Jan  1  1970 red:wifi2g
drwxr-xr-x    2 root     root             0 Jan  1  1970 red:wifi5g

#2
echo 0   > /sys/devices/platform/leds/leds/green:power/brightness               # turns LEDs off
echo 255 > /sys/devices/platform/leds/leds/green:power/brightness               # turns LEDs on
#3
echo 0   > /sys/devices/platform/leds/leds/red\:wifi2g/brightness               # turns power led (green) off
echo 255 > /sys/devices/platform/leds/leds/red\:wifi2g/brightness               # turns power led (green) on
#4
echo 0   > /sys/devices/platform/leds/leds/red\:wifi5g/brightness               # green light on wifi symbol ?
echo 255 > /sys/devices/platform/leds/leds/red\:wifi5g/brightness               # red light on wifi symbol

Thanks for testing. Does turning off green:wifi also work?

#wifi light off
echo 0   > /sys/devices/platform/leds/leds/green:wifi/brightness
echo 0   > /sys/devices/platform/leds/leds/red:wifi5g/brightness

#wifi light green
echo 255   > /sys/devices/platform/leds/leds/green:wifi/brightness
echo 0   > /sys/devices/platform/leds/leds/red:wifi5g/brightness

#wifi light red
echo 0   > /sys/devices/platform/leds/leds/green:wifi/brightness
echo 255   > /sys/devices/platform/leds/leds/red:wifi5g/brightness

#wifi light kinda orange
echo 255   > /sys/devices/platform/leds/leds/green:wifi/brightness
echo 255   > /sys/devices/platform/leds/leds/red:wifi5g/brightness

@borromini
I can live with the leds as is. Your call, if you want to implement dts changes.

Proposed RE220v1 .dts file
rename re200-v3 dts content to re220-v1 then prepend the = re200.dtsi content
then update led definitions per earlier post

I'm hesitant to change green:power as it might leave all leds off. I see led_power is referenced in a few aliases, so not sure ramifications of changing it.
In fact if night-mode is implemented in hardware, maybe it is why all lights are off during the U-boot failsafe phase.

gpio 43 becomes green:powerx   (was red:wifi2g)
gpio 40 becomes red:wifi       (was red:wifi5g)

Could additionally try this:

gpio 44 becomes green:nightmode   (was green:power)
gpio 43 becomes green:power       (was red:wifi2g)

I can test any builds you want to try.

I have been keeping an eye on this thread with a lot of interest. I have a RE220 v1 and would like to jump over to using openwrt instead of stock tp-link fw.

Some questions if I may:
1 - Would using the GPL link on TP-Link's website help? It is an openwrt version: https://static.tp-link.com/resources/gpl/re220v1_gplcode.tar.bz2
2 - Do you need another tester? I am happy to help test this out, building is beyond my skills right now.
3 - For more experienced builders/users - How long does it normally take from working model to being listed in the openwrt supported hardware tables?

I apologize in advance for the noob questions. Thanks.

@Borromini will you be able to prepare the PR? It seems @amteza never had the build working 100%

  1. Good stuff. I don't think it is needed at this point.
  2. It would be great to have someone else test the RE220-v1
    I'll repeat my comment from the other RE220-V1 thread.
    Like other devices in this family (RE220v2, RE200) the 5GHz radio is not perfect. If you are happy with stock firmware, you may want to stick with it.

If you are relying on the device, you may not want to use it for testing.

I have not tried reverting back to OEM firmware.

If you want to be fully informed check out the thread on the RE200
The RE200 TOH is also useful.

If you do want to test, you can try the factory image from Borromini's Sept 29 post.

Note that a couple of vulnerabilities have been identified recently that are not in the experimental build.

  1. I'll leave that to the experienced builders.

@jedboy, I can prepare a build that works, but compilation will build the kernel modules in. I don't think it's the way to go; I'm not sure PR will be accepted in that case. Do you want me to try anyways?

I think following the standard way would be best.

1 Like

I will, but with a baby girl and a few pressing personal projects, it will take some time. I haven't abandoned this.

1 Like

No worries. Thanks.

yes it does.

@Borromini Would it be possible to include switch aware VLAN in the PR as well ?
I posted this a while back :

But also am not familiar with PR process.

Please advise.

Sorry for delayed response.

Thanks for the information.

I was able to flash my RE220 to the linked fw, but I had to downgrade to v.190616 because with more recent fw version from TP-link would produce an error about invalid fw.

Overall, I was able to get RE220 to work, however the lights would not light up but that is not a big issue for me.

Since this is a test device for me, I made several different configurations and everything was working as far as I could tell.

Then I ran into trouble. I decided to attempt to upload the same openwork firmware and things were going along nicely until I had a power outage. Sooooo... now I have a pretty white brick.

I am going to try to revive it so I am getting that together.

I wish you guys well.

Sorry for the wait guys, got some time to take another peek, so here we go.

Well from what I can tell this is already in the code?

        tplink,re200-v2|\
        tplink,re200-v3|\
        tplink,re200-v4|\
        tplink,re220-v1|\
        tplink,re220-v2|\
        tplink,re305-v1|\
        tplink,re305-v3|\
        tplink,tl-wr802n-v4|\
        tplink,tl-wa801nd-v5|\
        widora,neo-16m|\
        widora,neo-32m)
                ucidef_add_switch "switch0"
                ucidef_add_switch_attr "switch0" "enable" "false"
                ucidef_set_interface_lan "eth0"
                ;;

Good catch, it shouldn't be.

Is it an actual LED that is visible on the device or is this just a GPIO that turns all LEDs off?

I have changed the other LEDs like you asked:

  • Green power LED to GPIO 43 (was red WiFi 2G LED)
  • Green night light to GPIO 44 (if it's not a LED I will remove it)
  • Red WiFi 5G LED to a band agnostic red WiFI LED.

Let me know about the night light GPIO, then I can adapt the DTS and build a new image for everyone to test.