search

Lanchon / openwrt-tr4400-v2

OpenWrt installation instructions for Arris TR4400 v2 / RAC2V1A
Other
4 stars 0 forks source link

Installation on devices with an active secondary OS slot #1

Closed uragit closed 1 year ago

uragit commented 1 year ago

Hi! (Hope this is the right place to raise this):

After the tricky business of opening the case, soldering tiny wires, getting a serial console...

I'm stuck installing openwrt on my RACV21A version Arris TR4400 v2. There's a whole bunch of differences flagged up by check-svn1418.sh (see below).

Does this mean there's a problem with check-svn1418.sh, or can I safely ignore the errors?

emmerson@mingo ~/openwrt_arris_racv21a/openwrt-tr4400-v2-main [9] ssh -l root 10.9.124.4 sh <check-svn1418.sh

This script checks the current state of your router in depth. If all checks pass, you are good to go on installing OpenWRT. The router USB port should be empty when running this script.

checking /proc/cmdline checking /etc/svn.info /etc/svn.info - differ: char 69, line 2

ERROR: /etc/svn.info

Path: . URL: svn://10.10.67.238:36901/svn/Router/TR4400v2/TR4400v2_0719/Source Repository Root: svn://10.10.67.238:36901/svn/Router/TR4400v2 Repository UUID: a6b6dc33-2ea1-44c0-8bf5-3169134277e6 Revision: 1782 Node Kind: directory Schedule: normal Last Changed Author: lucien Last Changed Rev: 1782 Last Changed Date: 2019-08-05 10:19:11 +0800 (Mon, 05 Aug 2019)

VERSION: Build from: PD1-build01 /home/rdrelease/TR4400v2/TR4400v2_0719_191108/Source by rdrelease DATE: Mon Nov 11 10:44:03 CST 2019 BOARD_ID: TR4400-CH

checking /etc/openwrt_release /etc/openwrt_release - differ: char 74, line 3

ERROR: /etc/openwrt_release

DISTRIB_ID="OpenWrt" DISTRIB_RELEASE="Bleeding Edge" DISTRIB_REVISION="r1602" DISTRIB_CODENAME="barrier_breaker" DISTRIB_TARGET="ipq806x/generic" DISTRIB_DESCRIPTION="OpenWrt Barrier Breaker r1602" DISTRIB_TAINTS="no-all busybox override"

checking /proc/version /proc/version - differ: char 24, line 1

ERROR: /proc/version

Linux version 3.14.43 (rdrelease@PD1-build01) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.01 r1602) ) #1 SMP PREEMPT Fri Nov 8 20:42:04 CST 2019

checking /proc/mtd /proc/mtd - differ: char 130, line 4

ERROR: /proc/mtd

dev: size erasesize name mtd0: 00040000 00020000 "0:SBL1" mtd1: 00140000 00020000 "0:MIBIB" mtd2: 00140000 00020000 "0:SBL2_1" mtd3: 00280000 00020000 "0:SBL3_1" mtd4: 00120000 00020000 "0:DDRCONFIG_1" mtd5: 00120000 00020000 "0:SSD" mtd6: 00280000 00020000 "0:TZ_1" mtd7: 00280000 00020000 "0:RPM_1" mtd8: 00500000 00020000 "0:APPSBL_1" mtd9: 00080000 00020000 "0:APPSBLENV" mtd10: 00140000 00020000 "0:ART" mtd11: 04000000 00020000 "rootfs_1" mtd12: 00060000 00020000 "0:BOOTCONFIG" mtd13: 00140000 00020000 "0:SBL2" mtd14: 00280000 00020000 "0:SBL3" mtd15: 00120000 00020000 "0:DDRCONFIG" mtd16: 00120000 00020000 "0:SSD_1" mtd17: 00280000 00020000 "0:TZ" mtd18: 00280000 00020000 "0:RPM" mtd19: 00060000 00020000 "0:BOOTCONFIG1" mtd20: 00500000 00020000 "0:APPSBL" mtd21: 04000000 00020000 "rootfs" mtd22: 00100000 00020000 "fw_env" mtd23: 00800000 00020000 "config" mtd24: 00200000 00020000 "PKI" mtd25: 00100000 00020000 "scfgmgr" mtd26: 00008000 00008000 "spi32766.0" mtd27: 003e0000 0001f000 "kernel" mtd28: 01e08000 0001f000 "ubi_rootfs" mtd29: 0001f000 0001f000 "rootfs_data" mtd30: 00744000 0001f000 "ubi_config"

checking /proc/mounts /proc/mounts - differ: char 300, line 8

ERROR: /proc/mounts

rootfs / rootfs rw 0 0 mtd:ubi_rootfs /rom squashfs ro,relatime 0 0 proc /proc proc rw,noatime 0 0 sysfs /sys sysfs rw,noatime 0 0 tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0 tmpfs /tmp/root tmpfs rw,noatime,mode=755 0 0 overlayfs:/tmp/root / overlayfs rw,noatime,lowerdir=/,upperdir=/tmp/root 0 0 ubi1:ubi_config /config ubifs rw,relatime 0 0 tmpfs /dev tmpfs rw,relatime,size=512k,mode=755 0 0 devpts /dev/pts devpts rw,relatime,mode=600 0 0 debugfs /sys/kernel/debug debugfs rw,noatime 0 0 ramfs /home ramfs rw,relatime 0 0 ramfs /mnt ramfs rw,relatime 0 0 ramfs /etc ramfs rw,relatime 0 0

checking /proc/bus/pci/devices cmp: EOF on

ERROR: /proc/bus/pci/devices

/proc/bus/pci/devices

checking /etc/fw_env.config Warning: Bad CRC, using default environment checking fw_printenv fw_printenv - differ: char 2, line 1

ERROR: fw_printenv

bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm bootdelay=5 baudrate=115200

checking dmesg-ubi-attached dmesg-ubi-attached - differ: char 18, line 1

ERROR: dmesg-ubi-attached

UBI: attached mtd21 (name "rootfs", size 64 MiB) to ubi0 UBI: attached mtd23 (name "config", size 8 MiB) to ubi1

checking dmesg-ubifs-mounted checking ubi0_0-kernel ubi0_0-kernel - differ: char 1, line 1

ERROR: ubi0_0-kernel

1e7876636109535510dd7cee16386d36 /dev/ubi0_0

checking ubi0_1-ubi_rootfs ubi0_1-ubi_rootfs - differ: char 1, line 1

ERROR: ubi0_1-ubi_rootfs

edcd4e0e5732f18e81da7b33892fe784 /dev/ubi0_1

checking ubi0_2-rootfs_data

WARNING: Do not proceed installing OpenWrt if any errors were output! Save the output and seek help in the forums instead.

uragit commented 1 year ago

Good work. It may well help the next person who tries it.

In other news, I have somehow seized defeat from the jaws of victory here.

I reassembled the router, almost completely; just leaving the serial cables trailing out of the base and found that the router no longer boots!

(I don't think I did anything weird in the process and suspect the new problem was just coincidental with the reassembly.)

The boot process loops due to the watchdog, and some sort of unhappiness with memory errors:

Hit any key to stop autoboot: 5 4 3 2 1 0 DOWNLOAD MODE BIT CHECK INTO NORMAL MODE:ff ff Creating 1 MTD partitions on "nand0": 0x000006500000-0x000010000000 : "mtd=0" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 126976 bytes UBI: smallest flash I/O unit: 2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset: 4096 UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=0" UBI: MTD device size: 155 MiB UBI: number of good PEBs: 1240 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 3 UBI: available PEBs: 28 UBI: total number of reserved PEBs: 1212 UBI: number of PEBs reserved for bad PEB handling: 12 UBI: max/mean erase counter: 1/0 Read 0 bytes from volume kernel to 44000000 No size specified -> Using max size (3047424) Image Name: ARM OpenWrt Linux-5.10.146 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2973021 Bytes = 2.8 MiB Load Address: 42208000 Entry Point: 42208000 Verifying Checksum ... Bad Data CRC ERROR: can't get kernel image! do_bootm[630]need change boot This block is not bad block. Erasing at 0x5ea0000 -- 100% complete. [0x5ea0000] write done

Resetting with watch dog!

U-Boot 2012.07 [Barrier Breaker r1596,r1596] (Nov 08 2019 - 19:18:40) ... etc

It then repeats and loops, although alternates between describing the problem at: Erasing at 0x5340000 -- 100% complete. [0x5340000] write done And Erasing at 0x5ea0000 -- 100% complete. [0x5ea0000] write done

I can interrupt the process: bootipq seems to successfully boot the (ISP) original firmware run boot_recovery which boots the new openwrt firmware but in recovery mode.

I'm going to poke around a bit and then probably try just using the boot_recovery mode to reinstall the sysupgrade image and hope that it takes care of things. Unless you think that's a bad idea!

(I've added both the console logs to the webpage with the others.)

--

Martin

On Sat, Dec 03, 2022 at 05:13:32PM -0800, Lanchon wrote:

i added detection for your case during install: https://github.com/Lanchon/openwrt-tr4400-v2/commit/f1b99b5a8e4f178c64972767a9d8893a1a2b2181

-- Reply to this email directly or view it on GitHub: https://github.com/Lanchon/openwrt-tr4400-v2/issues/1#issuecomment-1336293277 You are receiving this because you were mentioned.

Message ID: @.***>

--

Martin

Martin Emmerson.

@.*** +1 408 245 6743

uragit commented 1 year ago

Agreed about the soldering! I'd figured that I'd just to a temporary hack job long enough to do a quick firmware upgrade and then just remove the extra wiring. Didn't turn out that way!

I added a bit of strain relief on the pads by threading the thin wirewrap wires though the header holes. Makes it a good bit less susceptible to damage due to wire movement.

If I come across another of these devices, I think I'll try to get some appropriate sot23 n-fets and some tiny 5K(maybe) resistors and try to populate the board. Might be tricky but I'd feel a good bit happier once it was all in place. If so, I'll do a write up.

--

Martin

On Sat, Dec 03, 2022 at 05:25:06PM -0800, Lanchon wrote:

hi and sorry for not having time to answer properly.

soldering this MOFO is a b*tch,

also, the pads to which you are soldering the wires WILL peel off and break! it's inevitable. i'd cut those wires short and solder them to the currently disconnected though-holes of the serial connector, even if you don't add a connector. at least forces on them will diminish and they might survive. you never know when you might need serial again.

good to know you are using a voltage divider network... :+1:

I've left the networked serial port connection up

thanks! not needed anymore. AFAICK, your device is exactly like mine, but with different OS versions and some NAND flash defects.

thanks for reporting! got to know more about this platform.

take care :)

-- Reply to this email directly or view it on GitHub: https://github.com/Lanchon/openwrt-tr4400-v2/issues/1#issuecomment-1336295115 You are receiving this because you were mentioned.

Message ID: @.***>

--

Martin

Martin Emmerson.

@.*** +1 408 245 6743

Lanchon commented 1 year ago

oh :((

first, be careful with those wires, those pins are probably very sensitive to ESD. these ports are not meant to be exposed and they are probably not hardened.

i'll look into your issue now...

Lanchon commented 1 year ago

bootipq

seems to successfully boot the (ISP) original firmware

don't!!! ever!!! the fw_env partition has been relocated so its configuration is all messed up. worse, it will overwrite random parts of the big unified 'ubi' partition that now contains the OS and possibly other stuff.

run boot_recovery

it's always safe to do that. the recovery is ram-only and never touches the flash unless you command it to.

Lanchon commented 1 year ago

UBI: number of bad PEBs: 0

strange, we know there are at least 2 bad PEBs. the bootloader implementation of UBI is not seeing them. but it should be read-only, so im not concerned much.

Verifying Checksum ... Bad Data CRC

corruption in the NAND. kernel is affected. a new bad PEB?

ERROR: can't get kernel image! do_bootm[630]need change boot This block is not bad block. Erasing at 0x5ea0000 -- 100% complete. [0x5ea0000] write done

what a PoS!!! they hacked the bootm command!!! it should fail CRC and simply continue executing the UBOOT script, which would automatically fall through to the recovery. but shitty qualcomm destroyed the bootm command, what a bunch of tards!

now they are "Erasing" the BOOTCONFIGs alternatively (thus switching the active OS copy) whatever "erasing" means. maybe touching the age field? who knows. it'd be nice take a new mtd-backup and look into the BOOTCONFIGs now.

[ 2.011466] 0x000005340000-0x0000053a0000 : "0:BOOTCONFIG" [ 2.066471] 0x000005ea0000-0x000005f00000 : "0:BOOTCONFIG1"

whatever they are doing, it is still booting so no big deal.

1) boot recovery 2) reflash squashfs 3) reboot 4) ssh into it, then ubinfo -a and post it 5) please use scp to copy /dev/mtdNN to your PC, for the two NN corresponding to BOOTCONFIGs and upload them

Lanchon commented 1 year ago

BTW, NAND flash should (almost) never develop defects once data is written. defects happen during erase and write and they are remapped by UBI. this is very strange.

running bootipq can cause this corruption, but i doubt you did that before the issue showed up.

uragit commented 1 year ago

(Correct, I didn't run 'bootipq' until I had to interrupt the looping bad-memory problem.)

1) boot recovery Done 2) reflash squashfs Done 3) reboot Done 4) ssh into it, then ubinfo -a and post it

@.***:~# ubinfo -a UBI version: 1 Count of UBI devices: 1 UBI control device major/minor: 10:62 Present UBI devices: ubi0

ubi0 Volumes count: 3 Logical eraseblock size: 126976 bytes, 124.0 KiB Total amount of logical eraseblocks: 1240 (157450240 bytes, 150.1 MiB) Amount of available logical eraseblocks: 0 (0 bytes) Maximum count of volumes 128 Count of bad physical eraseblocks: 0 Count of reserved physical eraseblocks: 40 Current maximum erase counter value: 3 Minimum input/output unit size: 2048 bytes Character device major/minor: 246:0 Present volumes: 0, 1, 2

Volume ID: 0 (on ubi0) Type: dynamic Alignment: 1 Size: 24 LEBs (3047424 bytes, 2.9 MiB) State: OK Name: kernel Character device major/minor: 246:1

Volume ID: 1 (on ubi0) Type: dynamic Alignment: 1 Size: 37 LEBs (4698112 bytes, 4.4 MiB) State: OK Name: rootfs Character device major/minor: 246:2

Volume ID: 2 (on ubi0) Type: dynamic Alignment: 1 Size: 1135 LEBs (144117760 bytes, 137.4 MiB) State: OK Name: rootfs_data Character device major/minor: 246:3 @.***:~#

5) please use scp to copy /dev/mtdNN to your PC, for the two NN corresponding to BOOTCONFIGs and upload them

Doing next...

--

Martin

On Sat, Dec 03, 2022 at 06:39:37PM -0800, Lanchon wrote:

UBI: number of bad PEBs: 0

strange, we know there are at least 2 bad PEBs. the bootloader implementation of UBI is not seeing them. but it should be read-only, so im not concerned much.

Verifying Checksum ... Bad Data CRC

corruption in the NAND. kernel is affected. a new bad PEB?

ERROR: can't get kernel image! do_bootm[630]need change boot This block is not bad block. Erasing at 0x5ea0000 -- 100% complete. [0x5ea0000] write done

what a PoS!!! they hacked the bootm command!!! it should fail CRC and simply continue executing the UBOOT script, which would automatically fall through to the recovery. but shitty qualcomm destroyed the bootm command, what a bunch of tards!

now they are "Erasing" the BOOTCONFIGs alternatively (thus switching the active OS copy) whatever "erasing" means. maybe touching the age field? who knows. it'd be nice take a new mtd-backup and look into the BOOTCONFIGs now.

[ 2.011466] 0x000005340000-0x0000053a0000 : "0:BOOTCONFIG" [ 2.066471] 0x000005ea0000-0x000005f00000 : "0:BOOTCONFIG1"

whatever they are doing, it is still booting so no big deal.

1) boot recovery 2) reflash squashfs 3) reboot 4) ssh into it, then ubinfo -a and post it 5) please use scp to copy /dev/mtdNN to your PC, for the two NN corresponding to BOOTCONFIGs and upload them

-- Reply to this email directly or view it on GitHub: https://github.com/Lanchon/openwrt-tr4400-v2/issues/1#issuecomment-1336306190 You are receiving this because you were mentioned.

Message ID: @.***>

--

Martin

Martin Emmerson.

@.*** +1 408 245 6743

uragit commented 1 year ago

5) please use scp to copy /dev/mtdNN to your PC, for the two NN corresponding to BOOTCONFIGs and upload them

scp didn't work for me but dd seemed to get the job done:

@. ~/openwrt_arris_racv21a/openwrt-tr4400-v2-main [17] ssh @. 'dd if=/dev/mtd12' > mtd12.bootconfig 768+0 records in 768+0 records out @. ~/openwrt_arris_racv21a/openwrt-tr4400-v2-main [18] ssh @. 'dd if=/dev/mtd19' > mtd19.bootconfig1 768+0 records in 768+0 records out @.*** ~/openwrt_arris_racv21a/openwrt-tr4400-v2-main [19]

Uploaded to web server: mtd12.bootconfig mtd19.bootconfig1

On Sat, Dec 03, 2022 at 06:39:37PM -0800, Lanchon wrote:

UBI: number of bad PEBs: 0

strange, we know there are at least 2 bad PEBs. the bootloader implementation of UBI is not seeing them. but it should be read-only, so im not concerned much.

Verifying Checksum ... Bad Data CRC

corruption in the NAND. kernel is affected. a new bad PEB?

ERROR: can't get kernel image! do_bootm[630]need change boot This block is not bad block. Erasing at 0x5ea0000 -- 100% complete. [0x5ea0000] write done

what a PoS!!! they hacked the bootm command!!! it should fail CRC and simply continue executing the UBOOT script, which would automatically fall through to the recovery. but shitty qualcomm destroyed the bootm command, what a bunch of tards!

now they are "Erasing" the BOOTCONFIGs alternatively (thus switching the active OS copy) whatever "erasing" means. maybe touching the age field? who knows. it'd be nice take a new mtd-backup and look into the BOOTCONFIGs now.

[ 2.011466] 0x000005340000-0x0000053a0000 : "0:BOOTCONFIG" [ 2.066471] 0x000005ea0000-0x000005f00000 : "0:BOOTCONFIG1"

whatever they are doing, it is still booting so no big deal.

1) boot recovery 2) reflash squashfs 3) reboot 4) ssh into it, then ubinfo -a and post it 5) please use scp to copy /dev/mtdNN to your PC, for the two NN corresponding to BOOTCONFIGs and upload them

-- Reply to this email directly or view it on GitHub: https://github.com/Lanchon/openwrt-tr4400-v2/issues/1#issuecomment-1336306190 You are receiving this because you were mentioned.

Message ID: @.***>

--

Martin

Martin Emmerson.

@.*** +1 408 245 6743

uragit commented 1 year ago

Seems to be up and stable. I've tried some reboots and a bunch of power cycles to see if it starts giving trouble again, but it seems to boot just fine each time.

I hadn't realized how much this router kicks ass until I compared the specs to my existing fleet of Netgear WNDR3800 routers. (They're perfectly fine, but the Arris TR4400 has a lot more ram/flash. Nice. I just need to make sure I don't brick it. I'll certainly keep an eye out for any more that people may be throwing away (should be a crime to throw out such nice hardware, or perhaps to make such nice hardware and then deliberately cripple it with dodgy/locked firmware).

The overlap of people who happen to have one of these routers spare, and are openwrt-proficient, with sufficient soldering can-do, may be fairly small. Which is a shame because it's a nice device.

Your electronics-fu is probably stronger than mine. Do you have a SOT23 mosfet in mind if anybody wants to try populating the board? And what's the pitch on those resistors needed, like 0.5mm x 1.0mm?

Yet again, I'm super happy for all the help getting this up and running, again (after I was worried it might end up bricked yet again!). I'm no expert yet but I've certainly gained more of an understanding in the process.

On Sat, Dec 03, 2022 at 06:44:32PM -0800, Lanchon wrote:

BTW, NAND flash should (almost) never develop defects once data is written. defects happen during erase and write and they are remapped by UBI. this is very strange.

running bootipq can cause this corruption, but i doubt you did that before the issue showed up.

-- Reply to this email directly or view it on GitHub: https://github.com/Lanchon/openwrt-tr4400-v2/issues/1#issuecomment-1336306668 You are receiving this because you were mentioned.

Message ID: @.***>

--

Martin

Martin Emmerson.

@.*** +1 408 245 6743

Lanchon commented 1 year ago

im with firends now.

Do you have a SOT23 mosfet in mind

nope the key issue is low-threshold. it needs to work on 1.8V signals. look for an existing 1.8V serial circuit on some other router? the circuit is bound to be the same.

Lanchon commented 1 year ago

Uploaded to web server:

thanks!

just checked those. indeed, "erasing" is codeword for increasing the age field of the inactive bootconfig to make it active on next boot.

no impact for you, as bootipq is not invoked, so the same system is always booted.

regarding the failure, its a hardware malfunction :( hope it doesnt happen again.

later!

Lanchon commented 1 year ago

i got a favor ask

BUT ONLY IF YOU HAVE THE SERIAL PORT STILL CONNECTED otherwise i'll find another way

i want to write some instructions for a different router with the same UBOOT i need to set boot variables from UBOOT but the variable values have to include characters such as " (a quote) and im not sure how to quote in UBOOT, and i cant write instructions if im unsure

boot and interrupt UBOOT, set a test variable:

set testvar 'echo "hello         world" || this_shouldnt_be_ran'
run testvar

dont worry, variables are not persisted unless you issue a saveenv

thank you!!

uragit commented 1 year ago

(Good morning!)

No problem at all. Results below. More complete log (although it probably doesn't really contain anything extra that you need) is on the webserver in console.log6.testvar

Let me know if you need more. I can also put the network/serial login back in place if you want to do some poking. Indeed it was still in place but keeps breaking because I'm doing a bunch of reconfiguring of the router it relies on, to fix the ancient ssh protocol problem you'd pointed out. (But I'm having some strange openvpn/firewall issue so I keep having to break networking with restarts.)

--

Hit any key to stop autoboot: 5 4 0 (IPQ) # (IPQ) # (IPQ) # (IPQ) # set testvar 'echo "hello world" || this_shouldnt_be_ran' (IPQ) # run testvar hello world (IPQ) # printenv baudrate=115200 boot_custom=test -n "$boot_pre" && run boot_pre; run boot_main; run boot_recovery; run boot_tftp boot_extra_recovery=set mtdids nand0=nand0 && set mtdparts @.(mtd_extra) && ubi part mtd_extra && ubi read 0x44000000 recovery && bootm boot_main=set mtdids nand0=nand0 && set mtdparts @.(mtd_ubi) && ubi part mtd_ubi && ubi read 0x44000000 kernel && bootm boot_recovery=run boot_ubi_recovery; run boot_extra_recovery boot_stock=bootipq boot_tftp=test -n "$ipaddr" || set ipaddr 192.168.1.1; test -n "$serverip" || set serverip 192.168.1.2; tftpboot recovery.bin && bootm boot_ubi_recovery=set mtdids nand0=nand0 && set mtdparts @.***(mtd_ubi) && ubi part mtd_ubi && ubi read 0x44000000 recovery && bootm bootcmd=run boot_custom bootdelay=5 ethact=eth0 machid=1260 stderr=serial stdin=serial stdout=serial testvar=echo "hello world" || this_shouldnt_be_ran

Environment size: 987/262140 bytes (IPQ) #

On Sun, Dec 04, 2022 at 04:02:59AM -0800, Lanchon wrote:

i got a favor ask

BUT ONLY IF YOU HAVE THE SERIAL PORT STILL CONNECTED otherwise i'll find another way

i want to write some instructions for a different router with the same UBOOT i need to set boot variables from UBOOT but the variable values have to include characters such as " (a quote) and im not sure how to quote in UBOOT, and i cant write instructions if im unsure

boot and interrupt UBOOT, set a test variable:

set testvar 'echo "hello         world" || this_shouldnt_be_ran'
run testvar

dont worry, variables are not persisted unless you issue a saveenv

thank you!!

-- Reply to this email directly or view it on GitHub: https://github.com/Lanchon/openwrt-tr4400-v2/issues/1#issuecomment-1336394911 You are receiving this because you were mentioned.

Message ID: @.***>

--

Martin

Martin Emmerson.

@.*** +1 408 245 6743

Lanchon commented 1 year ago

thank you so much!!!! :)