TP Link really a security risk?

Hardware Hub Networking
1

Are TPlink routers really that big of a risk? All routers as far as I know are made in china. So is it really a risk?

2

It’s hard to point at any one specific thing they do wrong, but statistically they are much more likely to be a security risk than any others.

Check out the latest list of router’s the three letter agencies are trying to unpwned:

There are a decent selection of routers made outside China. I’d be more worried about Chinese brands as opposed to them being made in China because of the 2017 national intelligence law.

3

I tend to think it matters less where something is manufactured and more where it is designed, and where the software is written.

Its much more difficult to hide hardware exploits as a contract manufacturer who delivers product to a western manufacturer who owns the design and the software than it is to sneak in exploits into an existing supply chain.

Personally I switched over to software router/firewall systems running on custom hardware over a decade ago. At first it was pfSense, but now I’m on OPNSense.

Not only are these much more powerful platforms, but they are also much less likely to have that kind of exploit in them.

5 Likes
4

Qwen was able to get a root telnet session launched on a fairly new, up to date wifi 7 router from tplink in under 30 minutes in a pentest I ran at home.

5 Likes
5

What is that?

6

a large language model

1 Like
7

Short answer: No, it’s not. Long answer: BS

The US policy is to encourage or coerce vendors to bring back manufacturing to the US. It’s in plain sight for anyone with a sense in politics.

A properly configured TP-Link is about as secure as other consumer routers. All based on pretty much the same software: either openwrt or an early version to forked WRT.

For popular TP-link models, high chance it’s already supported by vanilla OpenWrt. Though personally I would recommend against OpenWrt for WiFi performance/functionalities. Vendors’ firmware is usually better.

8

Amusingly, that can also mean other consumer routers are not that secure.

I do not appreciate using the good name of openwrt to endorse random vendor firmware of dubious quality.

While it is true the vendor sdks are usually based off an openwrt version, it is nearly always ancient. A bunch of stuff sold today is still based on openwrt 18.x (from 2018, eol in 2020).

How safe that is to use today relies squarely on the vendor updating things on their own.

9

Why are so many people on this forum falling for the orange man’s propaganda.

The main issues with tp-link had nothing to do with China, this is just the new distraction. TP-Link is one of the few brands that is a CNA. They actively identifiy and catalog software vulnerabilities across the board. The problem is they sat on a major known vulnerability in their own products without patching, while calling out others. They also use their higher rating and lower number of reported vulnerabilities as a selling point over other brands. Which has been equated to claiming you won a contest you were also a judge in. This was a big thing in the security space back in November. Then the FCC restriction on licenses happened, and the two I think get conflated sometimes. TP-Link is not dangerous for being Chinese, but possibly hypocritical the way they report their competitions vulnerabilities and cover their own.

I’ve also worked with regular Tp-Link and Tp-link Omada. Their seems to be a major separation in the company. The Omada teams sees themselves as a separate entity. Origirialy it was Tp-Link Business, then TP-Link Omada, Then Omada by Tp-Link. Now the Tp-Link font size is drastically reduced compared to the Omada name, to the point it’s almost not noticable. If marketing materials are anything to go by, soon it will just be Omada Networks (which is already their official reddit, the others are fan pages).

As far as AI finding a security vulnerabilities, look at what’s going on in the Linux world alone with AI. We are finding security vulnerabilities that have been there for decades that we couldn’t find before. No brand is safe if your targeted by someone with some spare time and a couple of GPUs or an Nvidia Spark.

If China is a concern we should be more concerned with new brands like WAVLINK being a 100% Chinese company, coming in out of nowhere with agressive marketing and review seeding. The worst software stack I have ever seen, phoning home constantly, but also the most insane range for an outdoor AP I had ever seen. Your average person doesn’t research security with those products, they care about performance and range. Also the FCC stuff really only effects big box in-store retailers. Lots of chinses switches, especially the budget multi gig, without a real FCC certification, all over Amazon. Amzon has a hard time policing scams and knock offs, they don’t care if a FCC sticker is genuine. So Amazon is already full of botnet products.

3 Likes
10

For professional access points yes, for any consumer device, as you already said:

Vanilla OpenWRT is the way to go IMHO, you will get better or the at least the same functionality and performance when the device is fully supported by OpenWRT, and you will have the latest security updates.

You can check here if you device is supported:

1 Like
11

TP Link in the US is bound by US law as they are a US based company.

12

I use Omada and TP Link throughout the entirety of my homelab. We also use them in my workplace, where we are responsible for private data covered under HIPPA and other federal protections. If they were a security risk, that wouldn’t be possible.

13

I am amazed at the white knighting happening in this thread just because “bad man can do no right”. While I don’t disagree that this was the wrong way to go about this, tp-link devices are a huge security threat and have been before this ban was even a twinkle in someones eye. I was avoiding too many specifics but maybe this will encourage people to look deeper at what is securing their edge.

Model: BE800, running current official tplink firmware with a fairly standard config. Only exotic thing is the enabled root telnet and some extra lock down I’ve done on the WAN side.

TP-Link Archer BE800 — Software Inventory & CVE Exposure

Target: 192.168.0.1 (hostname Archer_BE800)
Date of audit: 2026-05-19
Access method: unauthenticated telnet (TCP/23) — drops directly into a root shell
Auditor: read-only enumeration from the LAN side; no exploits run

0. Executive summary

The single most serious finding is independent of any CVE: TCP/23 on the LAN side is open and grants a root shell with no authentication. The banner explicitly states that setting a root password will disable telnet and enable SSH instead. Anyone with network reach to the LAN (wired, Wi‑Fi, or any device that’s been onboarded) has full control of the router. Fix this first.

Beyond that, the firmware ships a fleet of network daemons (ProFTPD, netatalk, Samba, MiniDLNA, strongSwan, OpenVPN, pppd, etc.) at versions ranging from “old” to “12-year-old.” The good news from the live enumeration: most of them are not currently listening. They sit on disk and only get started when the corresponding feature is enabled in the web UI. So the “what is actually exposed right now” list is short, but the “what becomes exposed the moment you toggle a feature” list is long and dangerous.

WAN-side filtering is correctly closed (default INPUT DROP, explicit drop for traffic destined to the LAN IP and management ports). Nothing critical appears reachable from the internet today.

1. System identification

Property Value
Hardware model TP-Link Archer BE800
Banner build tag r0-2cf9f544de (also visible as the OpenWrt revision)
OS OpenWrt 23.05-SNAPSHOT, target board_ipq95xx/generic (Qualcomm IPQ95xx)
Kernel Linux 5.4.213 #0 SMP PREEMPT Fri Mar 13 11:47:44 2026 aarch64
Toolchain GCC 12.3.0 (OpenWrt r0-8b28f05c3); rootfs built 2026-02-10
WAN IP 98.42.217.29/22 on eth1
LAN IP 192.168.0.1/24 on br-lan
IPv6 only ::1; no global v6 prefix delegated at audit time

2. What is actually listening (live state)

From netstat -tulpn, filtered to the network-reachable sockets:

Proto Bind Process Reachable from LAN? Reachable from WAN?
TCP 23 :::23 telnetd YES — passwordless root No (default INPUT DROP; LAN-only)
TCP 80 0.0.0.0:80, :::80 uhttpd (web UI) Yes No (explicit lan_remote_mgnt drop to WAN IP :80,443)
TCP 443 0.0.0.0:443, :::443 uhttpd Yes No (same)
TCP 53 / UDP 53 0.0.0.0, ::: dnsmasq Yes No
UDP 67 0.0.0.0 dnsmasq DHCP Yes (LAN bcast) No
TCP 1900 / UDP 1900 0.0.0.0 miniupnpd Yes (UPnP control) No
UDP 5351 192.168.0.1 miniupnpd (NAT-PMP) Yes No
UDP 20002 0.0.0.0 tdpServer (TP-Link TDDP) Yes No
UDP 43611 ::: conn-indicator Yes (v6 unused) No
TCP 20001 0.0.0.0:20001 dropbear No — INPUT -p tcp --dport 20001 -j REJECT --reject-with tcp-reset No
TCP 127.0.0.1:5453 localhost stubby (DoT) No (loopback) No
TCP 127.0.0.1:20002 localhost tmpServer No (loopback) No
TCP 127.0.0.1:20015 localhost easymesh-controller No (loopback) No
UDP 127.0.0.1:9900 localhost hostapd ctrl No (loopback) No
UDP 127.0.0.1:9902 localhost wpa_supplicant ctrl No (loopback) No

Kernel modules of note: wireguard, ksmbd, ovpn_dco_v2, vxlan, l2tp_core are loaded. ksmbd being loaded matters — even though there’s no SMB listener visible right now, the kernel SMB server’s attack surface is live in the kernel; if any share is enabled in the UI, kernel-level SMB CVEs immediately apply.

3. Software inventory

Component Installed version Release date Currency
BusyBox 1.36.1 May 2023 Old-but-supported
Linux kernel 5.4.213 Aug 2022 Old (5.4.y is LTS but missing 4+ years of backports)
OpenSSL 1.1.1t + 3.x Feb 2023 (1.1.1t) EOL (1.1.1 series since 2023-09)
Dropbear SSH 2019.78 Jul 2019 Old
Dnsmasq 2.83 Jan 2021 Old
hostapd / wpa_supplicant QCA-patched (banner suppressed; ~2.10 base) — QCA fork
ProFTPD 1.3.4b Sep 2012 Ancient
Netatalk afpd 3.1.8 2017 Very old
Samba (nmbd) 3.6.25 2014 Ancient
ksmbd-tools 3.4.8 2023 Recent
strongSwan U5.8.2 / K5.4.213 2019 Old
OpenVPN 2.6.6 Jun 2023 Old
pppd 2.4.3 2005 Ancient
accel-pptpd 0.8.5 (uses pppd above) — Old
xl2tpd 1.3.12 (uses pppd above) 2023 Recent
miniupnpd 2.2.2 Feb 2022 Old
minidlnad 1.1.2 2017 Very old
avahi-daemon 0.6.31 2014 Ancient
radvd 1.7 2008 Ancient
stubby 0.4.0 2018 Old
https-dns-proxy “1.0” — Old
curl / libcurl 7.79.1 Sep 2021 Old
Snort 2.9.17 2020 Snort 2 line EOL Jan 2024
Lua 5.1.4 2008 Ancient (LuCI standard)
zlib 1.2.7 2012 Ancient
tcpdump / libpcap 4.99.4 / 1.10.4 2022 / 2023 Recent
ethtool 6.3 2023 Recent
wireguard-tools 1.0.20210914 Sep 2021 Old
afpd (Netatalk) 3.1.8 2017 Very old

Bold = unusually stale relative to actively-maintained upstreams.

4. Findings (ranked by exposure × severity)

4.1 CRITICAL — actively exposed

F-01. Passwordless root telnet on the LAN

  • Surface: TCP/23 listening on :::23, dropped into root shell with no auth.
  • Reach: Anything on LAN, including the Wi‑Fi SSIDs the router itself serves.
  • CVE: N/A — this is a configuration condition, not a software bug.
  • Mitigation: Set a root password on the router (login as admin in the web UI; the banner says “Use ‘passwd’ to set your login password — this will disable telnet and enable SSH”). After that, only Dropbear listens, and Dropbear is still firewalled (TCP/20001 is explicitly REJECTed by iptables).

F-02. TP-Link tdpServer (TDDP) on UDP/20002

  • Surface: tdpServer listening on 0.0.0.0:20002. This is TP-Link’s proprietary “Device Debug Protocol” daemon.
  • CVE history of this same daemon on other TP-Link models — all unauth RCE / auth-bypass:
    • CVE-2020-10882 — slave_mac command-injection RCE on Archer A7 (root).
    • CVE-2020-10884 — hard-coded encryption key (Archer A7).
    • CVE-2023-27332 — stack buffer overflow in tdpServer logging on Archer AX21, unauth pre-auth RCE.
    • CVE-2026-0834 (2026) — TDDPv2 authentication bypass: pktLength=0 skips DES decryption and treats the post-header bytes as a valid decrypted command, allowing unauthenticated administrative command execution from the local network.
  • Applicability to BE800 specifically: the per-model CVEs above were filed against the Archer A7 / AX21, not the BE800. The 2026 TDDP-auth-bypass write-up is protocol-level and applies wherever TDDPv2 is parsed in this way. Treat UDP/20002 as a high-confidence LAN attack surface until firmware is confirmed patched against CVE-2026-0834.
  • Mitigation: if you don’t need TP-Link’s mobile-app management, kill tdpServer (/etc/init.d/tdpServer stop) and/or block UDP/20002 to the router. Firmware update from TP-Link is the canonical fix.

4.2 HIGH — exposed today, more limited impact

F-03. dnsmasq 2.83 on LAN (TCP/UDP 53, UDP 67)

  • Binary banner shows no-DNSSEC, so the KeyTrap family (CVE-2023-50387 / CVE-2023-50868) likely doesn’t apply.
  • Still in range for: CVE-2022-0934 (heap UAF in DHCPv6 client/server), CVE-2023-28450 (EDNS0 limit), and the residual DNSpooq fixes in 2.84+. LAN-only.
  • 2.83 also predates --max-cache-ttl / cache-poisoning hardening from 2.84–2.89.

F-04. miniupnpd 2.2.2 (UPnP on UDP/TCP 1900, NAT-PMP on UDP/5351)

  • A LAN device can ask the router to add WAN→LAN port forwards via MINIUPNPD chain in iptables. The chain is already wired up (-A zone_wan_forward -j MINIUPNPD).
  • Version-specific issues from 2.2.x: input-validation fixes in 2.3.0+. Lower severity than tdpServer.
  • Mitigation: disable UPnP in the router UI unless a specific app needs it.

F-05. Kernel ksmbd module loaded

  • ksmbd (266 KB) is in lsmod. No :445 listener at audit time, but the moment a user enables an SMB share in the UI, all in-tree ksmbd kernel CVEs against ≤ 5.4.213 become relevant — and there are many:
    • CVE-2023-32250 ksmbd race → UAF.
    • CVE-2023-38427 / -38428 / -38429 / -38430 / -38431 / -38432 — various OOB-read/write / UAF / NULL-deref reachable from the SMB session-setup phase.
    • CVE-2024-26811 — IPC payload-length validation flaw between ksmbd.mountd and the kernel.
    • CVE-2025-38561 — pre-auth race in Preauth_HashValue handling during SMB2 session setup, kernel RCE.
    • CVE-2026-23226 (2026) — UAF in the multichannel session channel-list under SMB3.
  • Mitigation: if you don’t share files via SMB, ensure that’s disabled in the UI (it appears to be — no listener) and consider unloading the module (rmmod ksmbd) on firmware that supports it.

4.3 HIGH — installed but not running today (would be on the moment a feature is enabled)

These daemons are on the filesystem but had no listener at audit time. They start when their respective feature is toggled in the web UI (“USB FTP server”, “Time Machine / AFP”, “Samba”, “Media server”, “OpenVPN server”, “IPsec VPN server”, “L2TP/PPTP server”, etc.).

F-06. ProFTPD 1.3.4b — would be on TCP/21 if FTP server enabled

  • CVE-2015-3306 mod_copy (SITE CPFR / SITE CPTO) unauthenticated arbitrary file copy → RCE. Public exploit, metasploit module exists.
  • CVE-2019-12815 related arbitrary file copy.
  • 1.3.4b predates fixes; everything ≤ 1.3.6 is affected.
  • The iptables ruleset has ftp_access and ftp_access_lan chains pre-wired to open TCP/21 when the feature is enabled — so this would be reachable, possibly even from the WAN depending on UI setting.
  • Don’t enable the FTP-server feature on this firmware.

F-07. Netatalk afpd 3.1.8 — would be on TCP/548 if Time Machine / AFP enabled

  • CVE-2018-1160 unauth OOB write in dsi_opensession → root RCE.
  • CVE-2022-23121 .. -23125 Pwn2Own RCE chain (same daemon, used against WD NAS).
  • 3.1.8 predates 3.1.12 (CVE-2018-1160 fix) and 3.1.13 (Pwn2Own fixes).
  • Don’t enable the Apple file-sharing / Time Machine feature.

F-08. Samba 3.6.25 — would be on TCP/445 if SMB enabled

  • CVE-2017-7494 “SambaCry” — upload .so to a writable share, trigger via named pipe → RCE in smbd context. 3.6.25 is well before the 4.4.14 / 4.5.10 / 4.6.4 fixes.
  • Many additional Samba 3.6-era CVEs (CVE-2015-0240 unauth heap corruption, CVE-2017-2619 symlink race, CVE-2017-12150 NTLM auth issues, …).
  • Note that this firmware also has the in-tree kernel ksmbd and ksmbd-tools 3.4.8 — modern SMB serving may actually use ksmbd rather than this Samba 3.6 fossil. Either way, both are old surfaces.

F-09. pppd 2.4.3 — used by PPPoE, PPTP, L2TP

  • CVE-2020-8597 EAP stack overflow, CVSS 9.8, unauthenticated pre-handshake RCE. Affects 2.4.2–2.4.8.
  • Same binary is the back-end for pptpd (accel-pptpd 0.8.5) and xl2tpd (1.3.12), so the same RCE is reachable from any feature that brings up PPP.
  • Don’t enable PPTP or L2TP server features. PPPoE for ISP connection is client-side and lower risk but still vulnerable if the upstream is hostile.

F-10. strongSwan U5.8.2 — would be on UDP/500, 4500 if IPsec enabled

  • CVE-2021-41991 in-memory cert-cache integer overflow.
  • CVE-2021-41990 signature truncation.
  • CVE-2021-45079 EAP DoS / auth bypass.
  • CVE-2022-4967 auth bypass via crafted certificate.
  • CVE-2023-26463 libtls peer-cert validation flaw.
  • CVE-2023-41913 charon-tkm stack overflow.
  • All fixed by ≥ 5.9.10.
  • Don’t enable the IPsec VPN server feature.

F-11. OpenVPN 2.6.6

  • CVE-2023-46850 UAF, CVE-2023-46849 NULL-deref DoS. Fixed in 2.6.7.
  • Lower severity but still avoid running an OpenVPN server from this firmware.

F-12. MiniDLNA 1.1.2

  • CVE-2020-12695 “CallStranger” — UPnP SUBSCRIBE reflection/exfiltration. Pre-fix.
  • CVE-2022-26505 DNS-rebinding (Host-header not validated).
  • CVE-2020-28926 RCE via crafted HTTP chunked encoding signedness overflow.
  • Many further fixes in 1.3.x.

F-13. Avahi 0.6.31

F-14. radvd 1.7

  • 2008-vintage. CVEs in subsequent releases (CVE-2011-3601 .. 3604, CVE-2013-2548). v6 is barely active on this network (no global v6 today), so impact is limited unless v6 comes up.

4.4 MEDIUM — library-level, applies to multiple linkers

F-15. OpenSSL 1.1.1t (and 1.1.1 series end-of-life)

  • 1.1.1 series went EOL 2023-09-11. Every 1.1.1 CVE released after Feb 2023 is unpatched on this device for any binary linked against /usr/lib/libssl.so.1.1.1 / libcrypto.so.1.1.1:
    • CVE-2023-0464 X.509 policy DoS.
    • CVE-2023-0465 / CVE-2023-0466 (cert validation issues).
    • CVE-2023-2650 ASN.1 OBJECT IDENTIFIER DoS.
    • CVE-2023-3446 / -3817 DH-param DoS.
    • CVE-2023-5363 key/IV length mix-up (cipher confusion).
    • CVE-2024-0727 PKCS#12 NULL-deref.
  • An OpenSSL 3.x library is also present (libssl.so.3, libcrypto.so.3), so different binaries may be linked differently. Worth checking what each daemon resolves to (e.g. ldd /usr/sbin/openvpn).

F-16. curl 7.79.1 / libcurl 7.79.1

  • CVE-2023-38545 SOCKS5 hostname heap overflow (libcurl 7.69.0 – 8.3.0).
  • Long tail: CVE-2022-22576, -27774, -27776, -27782; CVE-2022-32205/06/07/08; CVE-2023-23914 / -23915 / -23916; CVE-2023-27533 / -27534 / -27535 / -27536; CVE-2023-46218; CVE-2024-2398.
  • Used by the router’s cloud-update / cloud-report code paths (cloud-https, cloud_download, …). Exploit reach depends on whether the router talks SOCKS5 anywhere (probably not), and on what URLs it follows.

F-17. zlib 1.2.7

  • CVE-2018-25032 memory corruption in deflate() when given attacker-controlled input.
  • CVE-2022-37434 heap-buffer-overflow in inflate() on a malformed gzip header.
  • Reach: anything that links libz (curl, OpenSSL, OpenVPN, miniupnpd, Dropbear, …). Hard to triage individually; just acknowledge that zlib 1.2.7 was published in 2012 and a lot has happened to libz since.

F-18. BusyBox 1.36.1

  • CVE-2022-48174 awk fix; older awk OOB-read issues.
  • Mostly a privilege-locality issue: triggers when something parses attacker-influenced input through awk, etc.

F-19. Lua 5.1.4

  • The LuCI web UI’s scripting layer. 2008 release with assorted bugs (CVE-2014-5461, etc.). Exploitation usually requires already being able to load Lua code, which is admin-only — so it’s not an entry-point bug, just a privilege-amplifier if you’ve otherwise reached the UI.

4.5 LOW / INFORMATIONAL

  • Dropbear 2019.78 — only relevant once telnet is disabled and SSH comes up. Has CVE-2020-36254 (scp filename mishandling) and assorted user-enumeration issues, but the binary isn’t reachable today (firewall rejects TCP/20001).
  • Snort 2.9.17 — Snort 2 line EOL Jan 2024. Not running. Cosmetic.
  • wireguard-tools 1.0.20210914 — no listener; wireguard kmod is loaded but no peer config visible.
  • stubby 0.4.0, https-dns-proxy “1.0” — bound to loopback only, used as upstream resolver for dnsmasq.

5. Firewall observations

  • INPUT default policy is DROP (good).
  • lan_remote_mgnt chain explicitly drops WAN→98.42.217.29:80,443.
  • zone_wan_br_protection drops WAN traffic destined for 192.168.0.1 (LAN IP).
  • INPUT chain explicitly rejects TCP/20001 (Dropbear) regardless of source — that’s the router author hedging against accidental exposure.
  • IPv6 firewall mirrors IPv4 with v6-specific allowances for DHCPv6 (UDP/546, 547) and ICMPv6.
  • MINIUPNPD chain is pre-wired into zone_wan_forward — any LAN host can punch WAN→LAN forwards via UPnP/NAT-PMP today.
  • NAT prerouting has empty placeholder chains for HTTPS / HTTP / VPN / FTP / VS / PT / DNS — those get populated when the corresponding UI feature is enabled (this is how F-06 through F-11 become reachable from the WAN).

6. Recommended actions, in order

  1. Set a root password now (web UI → System Tools / Administration → set admin password, then run passwd over telnet if you want to be sure). This disables telnet and enables SSH instead. Single biggest risk reduction available.
  2. Update the firmware from TP-Link’s portal. The OEM build is from Feb–Mar 2026; if there’s a newer one, take it. This is the only realistic path to fixing the kernel / library / daemon CVEs above — you cannot opkg upgrade because the package database is intentionally empty on this OEM build.
  3. Disable UPnP unless a specific app on the network needs it. Reduces F-04 and removes the LAN-controlled WAN forward capability.
  4. Block / disable tdpServer if you don’t use TP-Link’s mobile-app management:
    • iptables -I INPUT -p udp --dport 20002 -j DROP
    • or via init: /etc/init.d/tdpServer disable; /etc/init.d/tdpServer stop
  5. Do not enable the FTP server, Time Machine / AFP, Samba / SMB, OpenVPN server, IPsec VPN server, PPTP server, L2TP server, or media (DLNA) server features on this firmware version — each one stands up one of F-06 through F-12.
  6. Audit again after every firmware update — version numbers move, but the network-exposed-binary list is unlikely to shrink.

7. Audit methodology / commands run (read-only)

All run interactively over the open telnet shell. No writes, no configuration changes.

cat /etc/openwrt_release
cat /etc/openwrt_version
uname -a
cat /proc/version
busybox | head -3
ls /usr/sbin /usr/bin /sbin /bin
opkg list-installed                       # (empty — OEM strips the db)
ls /usr/lib/opkg/ /var/opkg-lists/
head -200 /usr/lib/opkg/status            # (empty)
# version probes
/usr/sbin/dropbear -V
/usr/sbin/dnsmasq -v
/usr/bin/openssl version -a
/usr/bin/curl --version
/usr/sbin/proftpd -v
/usr/sbin/avahi-daemon -V
/usr/sbin/openvpn --version
/usr/sbin/pppd --version
/usr/sbin/nmbd -V
/usr/sbin/ksmbd.mountd --version
/usr/sbin/tcpdump --version
/usr/sbin/miniupnpd --version
/usr/sbin/minidlnad -V
/usr/sbin/ipsec --version
/usr/sbin/afpd -V
/usr/sbin/radvd -v
/usr/sbin/stubby -V
/usr/bin/wg --version
/usr/sbin/xl2tpd -v
/usr/sbin/pptpd -v
/usr/bin/snort -V
/usr/bin/lua -v
strings /usr/lib/libz.so* | grep deflate
# live state
netstat -tulpn
lsmod | grep -E 'ksmbd|wireguard|nf_tables'
ip -4 addr; ip -6 addr
iptables-save
ip6tables-save

8. Sources

End of report.

6 Likes
14

I was trying to put my finger on the weird shift in sentiment I’ve seen lately and I think you just described it.

4 Likes
15

It not White knighting. There is a massive difference not with just with security but with the company’s culture when you’re talking omada versus regular TP-Link. The ones defending are talking how they pass all the security audits at their work are running omada. Omada is them attempting to compete with unify. That division has a completely different culture. Even the way they deal with influencers and reviews is totally different. Omada says “here’s an entire network stack for free we just want you to tell us what you think about it” Regular TP-link wants to pay for a sponsor spot where they dictate the talking points which is why I’ve never done a video for that side. Anything with the Archer name is the cheapest entry level products they push out and forget about. I dont recommend the Tp-Link Archer Walmart specials to anyone, but to lump Omada in with the same boat, or say it’s bevuse they are Chinese is totally misrempresenting the issue. TP-link archer is the for the Walmart clearenced isel, always had been. Most of the users here who run or ran Tp-Link in this forum it’s Omada stuff, which is why they have a different experience.

2 Likes
16

I appreciate you being forward in letting us know that you have taken paid sponsorships for tp-link.

17

I think both that custom report and the brand’s general security reputation clearly show that they’re subpar at best, maliciously dangerous at worst. Whether that’s just negligence/enshittification or corporate malfeasance, I don’t think we can say. So, putting some sort of moratorium on them makes sense from a consumer protection standpoint.

That said, framing it as a “these routers are bad cause they’re from chyna” is blatant xenophobic fervor. And especially given this admin’s reputation and previous/current behavior, we certainly know the decision was not made with any sort of “consumer protection” framing in mind.

We can hold two truths at the same time.

2 Likes
18

I just said in that post I haven’t. Never taking a paid sponsorship from anybody or I’d have $1,000 desk chair right now if I did that. Omada team has sent me products, no money. I’ve refused reviews for regular TP Link because that division is shady. I have monetization off of my channel because no matter how many subscribers I get I don’t ever want to make money off of YouTube. I have an IT business that’s made me six figures plus every year for the past 13 years out of a tiny little Amish cabin. I would need several million subscribers before it could compete with that income.

Omada is actually a sister company of tp-link which is why it’s now Omada by TP-Link and by 2027 is just going to be Omada networks and they’re not even going to be the same company.

2 Likes
19

That is not a paid sponsorship. Very different contractual obligations and compensation. Nobody is living off reselling free review gear on ebay

1 Like
20

Lol right? Hundreds of acres my Wi-Fi testijg ground is 1.2 square miles of wide hay fields. We own all of property outright. No mortgages and at the end of the year since I’m not a hay farmer, out neighbors who are, pay us for our lawn clippings. They cut everything for me, that covers the land taxes. Nothing a brand could offer me with sub 20,000 subscribers compares to what I make by the lunch everyday.

1 Like