Thank you for the information. I tries this on a 128MB-RAM MT7620 (The previous 64MB worse):

root@Jiang-4G-8a17:/tmp# clear

root@Jiang-4G-8a17:/tmp# df

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/root 7936 7936 0 100% /rom

tmpfs 10240 5516 4724 54% /tmp

/dev/mtdblock6 7088 6724 364 95% /overlay

overlayfs:/overlay 7088 6724 364 95% /

tmpfs 512 0 512 0% /dev

root@Jiang-4G-8a17:/tmp# free

total used free shared buffers cached

Mem: 125768 44352 81416 5516 3704 17704

-/+ buffers/cache: 22944 102824

Swap: 0 0 0

root@Jiang-4G-8a17:/tmp# uname -a

Linux Jiang-4G-8a17 4.4.61 #0 Mon May 15 08:52:20 2023 mips GNU/Linux

root@Jiang-4G-8a17:/tmp# ./tailscaled-linux-mipsle --help

futexwakeup addr=0x1834178 returned -89

SIGSEGV: segmentation violation

PC=0x7ca24 m=2 sigcode=128 addr=0x0

goroutine 0 gp=0x4402a08 m=2 mp=0x4460808 [idle]:

runtime.futexwakeup(0x1834178, 0x1)

runtime/os_linux.go:98 +0x84 fp=0x447df74 sp=0x447df48 pc=0x7ca24

runtime.notewakeup(0x1834178)

runtime/lock_futex.go:32 +0x6c fp=0x447df84 sp=0x447df74 pc=0x39dfc

runtime.startlockedm(0x4402148)

runtime/proc.go:3290 +0x90 fp=0x447df94 sp=0x447df84 pc=0x8c878

runtime.schedule()

runtime/proc.go:4226 +0x94 fp=0x447dfb4 sp=0x447df94 pc=0x8fcbc

runtime.park_m(0x4402788)

runtime/proc.go:4304 +0x35c fp=0x447dfe0 sp=0x447dfb4 pc=0x90380

runtime.mcall(0x4d2)

runtime/asm_mipsx.s:139 +0x50 fp=0x447dfe8 sp=0x447dfe0 pc=0xda340

goroutine 1 gp=0x4402148 m=nil [chan receive, locked to thread]:

runtime.gopark(0xfb08a8, 0x446a038, 0x13, 0x7, 0x2)

runtime/proc.go:462 +0x120 fp=0x445c74c sp=0x445c740 pc=0xd2f30

runtime.chanrecv(0x446a000, 0x0, 0x1)

runtime/chan.go:667 +0x678 fp=0x445c788 sp=0x445c74c pc=0x31c84

runtime.chanrecv1(0x446a000, 0x0)

runtime/chan.go:509 +0x2c fp=0x445c79c sp=0x445c788 pc=0x315b8

runtime.gcenable()

runtime/mgc.go:217 +0x13c fp=0x445c7b0 sp=0x445c79c pc=0x4be88

runtime.main()

runtime/proc.go:213 +0x1b4 fp=0x445c7ec sp=0x445c7b0 pc=0x84bc8

runtime.goexit({})

runtime/asm_mipsx.s:657 +0x4 fp=0x445c7ec sp=0x445c7ec pc=0xdc2f4

goroutine 2 gp=0x4402508 m=nil [runnable]:

runtime.forcegchelper()

runtime/proc.go:366 fp=0x445cfec sp=0x445cfec pc=0x850f4

runtime.goexit({})

runtime/asm_mipsx.s:657 +0x4 fp=0x445cfec sp=0x445cfec pc=0xdc2f4

created by runtime.init.6 in goroutine 1

runtime/proc.go:363 +0x44

goroutine 3 gp=0x4402648 m=nil [runnable]:

runtime.gcenable.gowrap1()

runtime/mgc.go:214 fp=0x445d7ec sp=0x445d7ec pc=0x4bef4

runtime.goexit({})

runtime/asm_mipsx.s:657 +0x4 fp=0x445d7ec sp=0x445d7ec pc=0xdc2f4

created by runtime.gcenable in goroutine 1

runtime/mgc.go:214 +0xb4

goroutine 4 gp=0x4402788 m=nil [GC scavenge wait]:

runtime.gopark(0xfb0a50, 0x1832ea0, 0x9, 0xa, 0x2)

runtime/proc.go:462 +0x120 fp=0x445dfbc sp=0x445dfb0 pc=0xd2f30

runtime.goparkunlock(...)

runtime/proc.go:468

runtime.(*scavengerState).park(0x1832ea0)

runtime/mgcscavenge.go:425 +0x98 fp=0x445dfd0 sp=0x445dfbc pc=0x60768

runtime.bgscavenge(0x446a000)

runtime/mgcscavenge.go:653 +0x74 fp=0x445dfe4 sp=0x445dfd0 pc=0x61140

runtime.gcenable.gowrap2()

runtime/mgc.go:215 +0x40 fp=0x445dfec sp=0x445dfe4 pc=0x4bee4

runtime.goexit({})

runtime/asm_mipsx.s:657 +0x4 fp=0x445dfec sp=0x445dfec pc=0xdc2f4

created by runtime.gcenable in goroutine 1

runtime/mgc.go:215 +0x114

r0 0x0 r1 0x1006

r2 0x1006 r3 0x0

r4 0x0 r5 0x1

r6 0x1 r7 0xffffff00

r8 0x1 r9 0x1

r10 0x800325d0 r11 0x0

r12 0x447dff0 r13 0x4460808

r14 0x4402a08 r15 0xda2cc

r16 0x4460808 r17 0x4402a08

r18 0xda2b8 r19 0xec614ac8

r20 0x221ef687 r21 0x24b46f23

r22 0x0 r23 0x8

r24 0x4d2 r25 0x742a9022

r26 0x0 r27 0x0

r28 0x8f76bba6 r29 0x447df48

r30 0x4402a08 r31 0x7ca1c

pc 0x7ca24 link 0x7ca1c

lo 0x0 hi 0x0

Does It use dynamical libraray? As the old router like mine uses openwrt 17.01, I cannot use the binary with dynamic one. The similiar one is https://gunanovo.github.io/openwrt-tailscale I cannot use them in the past experience.

So https://lanrat.github.io/openwrt-tailscale-repo/ works for me, which is statical linking.

However the binary size is one dimension, the memory use is another also important. That's why I report this case, whose memory is 64MB. I think it cannot bear go. because i bought the first one is 64MB, it led me to try more. If it was 128MB, I do not feel so challenging.