US could ban TP-Link routers over hacking fears: report
nypost.com
nypost.com
By provenance, I mean where it's designed, where it's manufactured, who has brand oversight of it, who controls the firmware, who runs the IoT phoning-home servers, etc.
(I don't have high security requirements for home, but I pay attention to such things out of curiosity.)
It's still Chinese hardware, but it's warrantied by Protectcli and you have control over the bits you can change.
My first move out of the consumer "junk" was Ubiquiti EdgeRouters but their software quality declined a few years back, and my models got no more updates, then my main router died. My overkill i3 6-port Protectcli box has been running great ever since; first with pfSense now OPNSense; I'll only replace it when it dies or I want 10GbE routing.
They've mostly been solid, and aren't too expensive. I did replace the one in the hall (on the ceiling) outside my living room recently though, upgrading it from an AP-AC-Pro to an U6-Pro and the range is significantly worse on the same WiFi spec, making the living room TV basically unusable for streaming, despite being flawless on the older AP.
I'm going to try the newer U7 Pros and if that doesn't work out, I'll start looking at alternatives, but I suspect anything acceptable will be more expensive. I run ethernet almost everywhere so WiFi is just for our mobiles/laptops/tablets/IoT, but the TV in the living room currently has no easy way to get cables to so that AP is critical.
I'm coming to the realization that mixed 2.4 ghz/5ghz access points aren't a great idea. If I wanted consistent 5 ghz coverage, I'd need a lot more access points, but I'd want to turn the 2.4ghz radios off on most of them because 2.4ghz goes too far.
The hardware is relatively inexpensive and seems to be rather stable, the company is based in Latvia, and the manufacturing (or at least the board-stuffing and injection-molding) seems to primarily be done in Europe. Some of their stuff is pretty flexible about what kinds of PoE is can work with.
All of the Mikrotik stuff I'm aware of runs their Linux-based RouterOS. This means they all get the same user interface -- the same for a "switch," for an "access point," and for a "router."
I like that this blurs the lines between different device classes. For instance, my access points have two Ethernet ports on them, and two radios. I can use them as simple access points, or as routers, or as switches... or all of this at the same time. Whatever I want to do with them is fine: It's just a highly-configurable device with n hardware interfaces available on it.
I could replace the separate switch and OpenWRT router that I have on a shelf in the basement with a singular Mikrotik switch that did both jobs if I wanted to. (I probably would not, and it probably would never make sense to do so, but their software allows me to do as many nonsensical things as I choose. That's a good thing.)
For me, wanting as much open source in the stack as possible, it gives me peace of mind, but it really depends on the individual.
All I can really suggest, is to take a look at the Coreboot site[0] and see if it sounds like something you'd want.
If you're concerned about provenance (or even if you're not), I suggest using a general purpose device and rolling your own ala pfSense[0]/OPNSense[1], etc, or just use one of the BSDs or Linux and use native tools or one of the many router/firewall distros[2]
[2] https://en.wikipedia.org/wiki/List_of_router_and_firewall_di...
Regarding pfSense and OPNsense, I recently built and used a nice OPNsense box, including IPS, but decided to go back to OpenWrt for home use, because OpenWrt actually worked a bit better for the things I needed.
I might use pfSense (or maybe OPNsense) router for a startup office of more than several people, though (until we can cost-justify a dedicated IT infra&support specialist). With OpenWrt on the WiFi APs.
Assuming you mean NUCs[0] and not NICs, I'm sure you're correct. That said, there are many other fanless miniPCs which are both less expensive and, as such, much less likely to be counterfeited.
>Regarding pfSense and OPNsense, I recently built and used a nice OPNsense box, including IPS, but decided to go back to OpenWrt for home use, because OpenWrt actually worked a bit better for the things I needed.
A fair point. The device I use as a router/firewall came pre-installed with OPNSense, which I immediately wiped and replaced with a vanilla Linux install and customised it to my own taste.
I mentioned OPN/pfSense not because I use them, but because they offer a fairly complete solution without having strong networking knowledge. Rolling your own is, IMNSHO, definitely superior to those, as well as to OpenWRT.
As for WiFi, I restrict my APs to just bridging to my wired network and have implemented strong egress filtering to control outbound access.
>I might use pfSense (or maybe OPNsense) router for a startup office of more than several people, though (until we can cost-justify a dedicated IT infra&support specialist). With OpenWrt on the WiFi APs.
That's not a bad idea at all. Although you might also consider one or more of the other distros/packages in the Wikipedia link[1] I included in my previous comment. Good luck!
[0] https://en.wikipedia.org/wiki/Next_Unit_of_Computing
[1] https://en.wikipedia.org/wiki/List_of_router_and_firewall_di...
(I used industrial NUC PCs as part of factory stations for a startup a few years ago, and they were nice. I looked into NUCs for home routers/firewalls, but I didn't like their NIC options.)
My misunderstanding. Apologies.
I use something similar to this[0] device, which has 4X2.5Gb ethernet ports and no WiFi (which was my preference) interface.
As such, no additional NICs were required, even with a dual ISP configuration.
[0] https://www.amazon.com/gp/product/B09J4H9ZXY?ie=UTF8&th=1
Many of their NUC-sized computers have dual physical LAN ports.
https://www.servethehome.com/identifying-risky-counterfeit-i...
(I’m looking at my stack right now and looking to upgrade)
The only thing is they're definitely not designed for regular consumers, you at least need familiarity with Linux networking.
Mikrotik has had quickset (a single page configuration for home use) for 8+ years, Android Home app for 3+ years
port forwarding? ofcourse how else can the kid have a minecraft server with friends
dynamic dns? then the friends don't need to search "what's my ip" every time
parental controls? to schedule how much time they can play minecraft...
I like Mikrotik but for anyone trying to go beyond the barebones default firewall/router/ap on the quickset page you need to be prepared to learn. i.e. To make a DHCP reservation, you go through the menus until you click IP, then you realise you don't click on DHCP client to set up a DHCP client you go into DHCP server and try to give a device a reservation which requires the step of making it static first then seperately setting it's IP.
The complaint basically boils down to: they have all the options there and available and the least common task is just as easy to do as the 2nd most common (after initial basic setup), and if a task touches multiple parts of the config you need to touch each of those parts. Great for someone who knows what they're doing but for a home user it would be great to have more quickset pages for the 2nd to 10th most common tasks (as intagible as that list is).
Ubiquity gear is structured the same way: It, too, absolutely runs Linux, and it uses a custom userland.
One of these userlands is friendlier than the other, but they're both still Linux.
It's a tale as old as the hills, or at least as old as the OG Linksys WRT54G -- which was my own first foray into owning dedicated routing hardware ~20 years ago (which was -- guess what -- Linux with a custom userland). (Previous to that, I used Linux with the userland of my choosing on my desktop PC.)
From that point I found the CLI to be relatively discoverable as a way to configure the devices.
I like RouterOS well enough, though.
I tell people to jump into Ubiquiti's (ui.com) ecosystem which is much more accessible for power users who occasionally wrestle with concepts like wireless, VLANs, subnets, and traffic rules.
So I installed openwrt. They're actually pretty well supported by openwrt (except for the newer 10g switches)
You mean an RFC1918 for etherboot? I have a "few" of these devices and this simply doesn't make any sense in any context.
I've since wiped the firmware/license keys so no idea.
Since APU2 schematics are open, rebooting PC Engines as a US company could be initiated by US leadership requesting AMD to restart production of the AMD GX-412TC SoC, until AMD can ship a Ryzen Embedded alternative with comparable power efficiency. The lack of a replacement SoC forced the end of APU2 and PC Engines.
National policy tools are not limited to banning negative examples, they can also encourage scaling of positive existence proofs.
Arguably the most important area of "provenance" is who controls the software ("firmware"). (Perhaps the hardware owner should control the software, e.g., compile and install OpenWRT.) The report on which this submission appears to be based mentions "command injection" as the vulnerability being exploited.
https://www.cyfirma.com/research/comprehensive-analysis-of-c...
https://www.microsoft.com/en-us/security/blog/2024/10/31/chi...
I still don't understand why because it's not fully installed.
I thought this was just a DC generator plugged into a DC-to-AC converter (an "inverter") and nature did its thing to autobalance the flow of electricity. I'm excited to find out what the app does and why these panels need a WiFi password.
And FWIW to anyone in power who happens to read this, I was plenty radicalized by my own experiences and those of my friends under capitalism. China didn't do shit.
It could be a GIRD or acid reflux condition. Civil discussions online shouldn't cause vomiting. You should probably see a doctor about that.
No. Do both. Why would we wait to fix one problem when we have two problems?
This just seems like distracting from the router issue, and taking the discussion off-topic.
But they are nice and cheap OpenWRT platforms. Ban the software instead? ;D
I bought a pair of TP-Link units specifically because OpenWRT ran well on them. If I had to get something more expensive, I might not decide to keep a cold spare.
The newer generations of TP links are a different beast entirely. Doubt you can even set it up local only let alone openwrt it
Nope. Any device that has a wired Ethernet port and an antenna cannot be just a layer 2 device; WiFi is not just a wireless Ethernet. Also, any device that you can ping by IP address and configure over the network rather than over a serial cable is operating above layer 2 for at least the control plane.
WiFi in fact goes to great lengths to behave as wireless Ethernet, putting all its complexity on layers below carrying Ethernet frames.
Set aside the theory and look at how any of the real devices are implemented. These devices are all running Linux, and that Linux OS is managing a minimum of two separate NICs with the full software networking stack. They incorporate all of the software complexity of a full-blown router, and none of the simplicity and security/privacy advantages of an unmanaged Ethernet switch which is a purely L2 device. There's no separation of control plane and data plane; no hardware-accelerated forwarding between Ethernet and WiFi to allow packets to skip a trip through the CPU cores. In fact, it is often the case that the only meaningful difference between a consumer WiFi router and a WiFi extender is that the latter omits the Ethernet switch chip and consequently only has one or two Ethernet ports rather than 5+ ports. Presuming that a WiFi extender is less likely to be nefarious than a WiFi router by analogy to a layer 2 unmanaged Ethernet switch (with at most kilobytes of RAM and likely only an 8-bit or 16-bit microcontroller for a processor core) is entirely wrong.
I know Ubiquity is a choice, but the reason I chose Omada over Ubiquity is that I can host the Omada controller locally and not be forced to use a cloud product.
Any system so heavily reliant on a single point of failure with such difficulty to replace is a no go for me. Never in half a decade have I seen such a problem whilst rolling out mikrotik hardware.
> Any system so heavily reliant on a single point of failure with such difficulty to replace is a no go for me.
Not to shill for Ubiquiti here, but none of that sounds like a problem with UniFi or the idea of centrally-managed APs.
UniFi APs don't stop working if the UniFi server fails. You can't make configuration changes, but you can SSH into the AP, reset it, and associate it with another UniFi server.
I advocate certain clients towards centrally managed systems, but for most of these clients who aren't interested in a regular checkup or business agreement with an IT provider I generally put them on un-managed setups with at least 2x USB devices with copies of config on-site and a printout of what the setup and network layout is. This is in-case I'm not here the next time they need work done or in case I do come back and don't want to spend a day deciphering their setup again. All cloud services are disable, no external log-in from outside of the site allowed. I leave the main modem/ISP connected router ideally up to the ISP they are getting internet services from and build everything downstream from that. Auto-update set to on. I've got multiple p2p and p2mp wireless networks at properties all around the region that haven't had a tech on-site for 4+ years and they won't until something breaks or the protocol their operating on gets too slow for user requirements which I would expect is another 4+ years at least because mikrotik wifi is rock solid when its setup manually and correctly.
Security is less of a worry. I mean honestly if your willing to drive out to the middle of nowhere to war-drive and crack the passwords and get into their network...hell you probably deserve to get some internet and check ya emails for the effort you've put in. They'll probably see your vehicle while your doing it and invite you in for a cuppa and give you the password anyways.
Mikrotik could easily be setup with weak passwords and management exposed, as can Cisco/Aruba/Ruckus/insert favorite vendor here.
If you want to access your controller(s) on the go then just setup a VPN on UniFi. Turn on your VPN, manage from the unifi app, and then turn the VPN off if needed.
"TP-Link also offers a $5-per-month or $36-per-year plan for Security+ network protection and IoT security. If you don’t pay, you still get some basic functionality such as the ability to block websites and to manually toggle internet access on your kids’ devices, but advanced settings, automatic timed internet control, most protection, and reporting are disabled after the one-month free trial. That said, the Archer AX3000 Pro will continue to provide solid Wi-Fi connectivity even if you don’t sign up for the added plans."
This report is a great example of why it's a bad deal to trade away security for a lower price. Wirecutter should have been leading the way in pointing this out, instead of just steering people to the cheapest fast thing, YOLO style (anyone can make that kind of recommendation).
https://www.nytimes.com/wirecutter/reviews/best-wi-fi-router...
For home office switches, if we required PoE 1G + 10G ports - the nearest option sold by US companies is 2x the price of TP-Link. There are no competitively priced options (10-20% additional cost) available for these segments. Ditto for gateways.
In the higher end, the campus switches offered by the competition is not even priced at < 10x the TP-Link switch prices. Which means the immediate cost of using TP-Link right now and replacing it with a much better TP-Link 2-3 years down the lane would justify buying TP-Link only. At this point, the expensive gear from competition feels like an over-engineering + cash grab to an end user.
Shouldn't more competition be about lowering prices and increasing choices? Where are the choices? Is there even an effort being made to help the end users of these budget segments?
I feel like this used to apply to most mass-market home routers. Have things improved recently such that TP-Link is an outlier?
Fundamentally we need to move to a home networking model that involves isolating all clients completely (especially cameras and smart TVs), and using AP hosted services to mediate interaction between them and the Internet at large. This will involve needing to trust the AP, but will have the advantage of being able to deploy slightly less trustworthy devices at the very edge.
The reason this is inevitable is the alternative hasn't worked. Cloud based IoT has been a disaster in both the atrocious edge device security and cloud service bait and switch burning customer confidence in the whole concept. Most people are not going to deploy dedicated servers in their house, but an AP absolutely. The HomeAssistant and Frigate ecosystems demonstrate the demand for functionality is there, but they are very much enthusiast type tools.
(a component of my work is software supply chain security)
Yeah, that is the problem, and I gave up on waiting for it, so kicked off an exploration of the problem space https://github.com/atomirex/umbrella (Hitting video handling first because it is one of the major headaches).
I come from the intersection of embedded/mobile/games and saw what a dumpster fire that was, and am under no illusions this will be solved either fast or by any existing group.
For example, an IoT lightswitch in your home should only talk to what looks like an MQTT broker in the AP. It doesn't need to have any concept what that topic it publishes to does. Similarly, the receiving light doesn't need to know what caused it. This way those devices literally never need any external network access at all.
I started working on this idea by playing with OpenWrt hosted video relays, and learned that it works, and am now extending it: https://github.com/atomirex/umbrella
Right now I am on HN procrastinating when I should be producing a video of ingesting from a TP Link security camera (really) into a webrtc SFU on the AP, sending it to another SFU, and watching the result.
In practice, this will work very poorly. Your whitelist will end up looking like "All of Azure, GCP, AWS, and CloudFlare, plus some one-offs"... which doesn't really stop anything.
I work at a BigCo that tries to do what you're proposing and it works so, so badly. Thankfully, we can turn off the "security" software that does this on our workstations. Unfortunately, cannot do the same for our software that runs on datacenter-hosted hardware that IT manages.
> Clients shouldn't connect to the Internet by default...
I have a couple of VLANs on my LAN that don't provide Internet access just for this reason.
Why?
* A huge-ass slice of the things hosted on The Internet are hosted in or behind one or more of Azure, GCP, AWS, and CloudFlare.
* Recording the set of "cloud provider"-provided IP addresses spoken to by a piece of client software is a bit of a fool's errand. The nature of those services is that one can change the IP address assigned to one's deployed software at a whim... and it's often cheaper to set things up so that one doesn't have an IP address for one's services that survives a VM reboot.
Malicious software is malicious regardless of whether it's running as a VM on Someone Else's Server, or a Linux process on personally-owned bare metal.
> Saying we "need" APs to segment VLANs is missing the point.
> What we "need" is for IoT devices to communicate through purely local networks and have no Internet access. [They will do this via a mechanism using MQTT where they're required to declare if they're bad.]
a) Who said anything about APs? While I do have WiFi Access Points (that I did not mention), I also have hard-wired VLAN segmentation. [0]
b) From a network design perspective, it's a lot easier and more efficient to provide a VLAN that doesn't have Internet egress than to attempt to sort out which of a mess of hosts are permitted to talk to the Internet from which aren't, and ALSO prevent MAC- and/or IP-address spoofing to evade any such filtering.
c) I have no idea why you're invoking MQTT (specifically), but any scheme that requires a potentially-untrusted host running potentially-untrusted hardware and software to declare whether or not it's to be trusted is doomed to failure right off the bat.
[0] Sure, I'm a power user. But, a "VLAN-isolated network for untrusted machines" feature shouldn't be something that only power users get. This SHOULD be a baseline feature in consumer-grade WiFi APs and switches. (The race-to-the-bottom feature of the "market" for consumer gear is very sad.)
The point is isolating devices from each other isn't what people need. They need their devices to accept commands from each other or their computer/phone. What they don't need is their devices to talk to half the Internet.
My htpc talks to exactly one machine, for example (my NAS). It's trivial to audit and would work fine if I blocked Internet access or gave it a whitelist. For people that use home assistant, again their devices should need to talk to a broker and that's it.
A reasonable device only talks to a handful of locations because you didn't ask it to do anything else. The world where Android and Windows and IoT devices chat all day to thousands of servers is what's the problem. Restricting such devices to only talk to the Internet is exactly the wrong solution. You could lock things down once there's an ecosystem in place for local control, but doing it now just ossifies the existing dumpster fire.
If one were to suggest regulation is needed for security (and governments are starting to do so), then what's needed is to ban cloud devices.
When talking about these things in a tech-savvy forum, you'd do well to separate the components (switch, WiFi AP, router) out, rather than thinking them as one indivisible unit. It helps for clarity of conversation and thinking. You have some misconceptions that might arise from this muddling you're doing.
> The point is isolating devices from each other isn't what people need. They need their devices to accept commands from each other or their computer/phone. What they don't need is their devices to talk to half the Internet.
When did I suggest isolating these devices from anything other than the Internet?
The whole point of having a router tied into the various VLANs on your network is so that you can program the router to decide what off-subnet traffic goes where. If you want to have a fully-isolated VLAN, you can... but I never mentioned any isolation other than from Internet egress.
> A reasonable device only talks to a handful of locations because you didn't ask it to do anything else.
If you purchase devices that are hard-coded to talk to machines hosted on someone else's servers, and you don't want to reverse-engineer and take ongoing maintenance responsibility for the software running in those devices, then your only choice in the matter if the manufacturer chooses to "host" those servers in GCP, AWS, or similar is to prevent the devices from talking to the Internet at all.
You might also review this conversation I had regarding the infeasibility of making a whitelist for typical devices and clients that demand Internet access: <https://news.ycombinator.com/item?id=42455401>
In that case I suppose the point is that what's desirable as an end-state from a security perspective is that none of these devices access the Internet (ideally with a firewall rule enforcing that). In the usual home scenario where there is only 1 networking device, VLANs and subnets both seem to me like their main purpose would be to isolate clients from each other, which for mass-market purposes is currently counterproductive (as it basically makes cloud servers a requirement for non-experts). You could use them to make your firewall rules simpler, but then you need routing an multicast forwarding rules. What you really want is to get to a place where your firewall says that your PC/phone can access the Internet and nothing else can.
Basically the infeasibility of making a whitelist for typical devices is exactly the problem to solve/issue to regulate.
No, that was in all of my replies. I've been consistent about this.
> You could use [VLANs] to make your firewall rules simpler, but then you need routing an multicast forwarding rules.
If you're not going to be running your multicast software on a machine that is wired in to all relevant VLANs (like your edge router), then yeah, if you need cross-VLAN multicast you would need to have multicast forwarding set up on such a machine. You'd need to do the same for broadcast, which is "just" all-nodes multicast.
> In the usual home scenario where there is only 1 networking device, VLANs and subnets both seem to me like their main purpose would be to isolate clients from each other...
Then you're confused about how VLANs and subnetting are typically used.
I can think of three ways to do what I think you're envisioning.
1) Use the "client isolation" feature of WiFi APs. I think this uses something OTHER than VLANs, given that clients get allocated IP addresses from the same subnet as each other.
2) Create a subnet and VLAN per client and program your router to not permit traffic originating from these special subnets to go anywhere other than direct to the router or out to the Internet.
3) Have one or more fairly fancy switches that are programmed to only permit packets to flow from each client port to the router port. (I'm pretty sure that this is conceptually what the often-present WiFi "client isolation" feature is.)
I know that you cannot prevent clients in the same subnet and VLAN from talking to one another unless you have direct intervention by a wireless or wired switch. This is because clients in the same subnet trying to talk to each other don't bother talking to the router and just use ARP (or ND) to find their conversation partners.
I'm not CERTAIN, but I think that if you try to have clients in the same subnet, but on different VLANs, it will work poorly (or not at all) because the router will have a hard time with route selection for incoming traffic, as well as traffic originating on the router to the client subnet.
Ideally Apple will resurrect the Airport and make it easy to have privacy and security in the home. An Airport-HomePod combo could do a lot of neat AI things in-house / on-prem.
That having been said, I don't know for sure that most generally available consumer devices would actually work under this arrangement.
I think throwing those features out is a tough sell for the home consumer market, but makes sense in the SMB and above area.
Multicast is widely exploited for fingerprinting by smart TVs, unfortunately, much as I think mdns is a beautifully elegant idea.
There’s also that famous photo of NSA “upgrading” Cisco routers, of course. https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa...
The fix? Blocking all inbound and outbound WAN (internet) traffic to it. Now works flawlessly, just like you think a light strip would. I only ever want to issue commands locally anyway, and why it should be talking to the broader internet in that case is beyond me.
https://arstechnica.com/tech-policy/2024/12/report-us-consid...
OpwnWRT is one distro that runs on it, apparently. Seems you know even less than I do about it.
But yes you’d need to know something about which distribution, ideally listen to someone’s actual experience.
This was the hope that started this thread. It still does work sometimes around here but surely not this time at all.
Anecdote: once I bought the cheapest router I could find online. The idea was to test connecting to a crap AP. Unfortunately the cheapest was a TP-Link and it worked absolutely perfectly, ruining my test plan.
Unless you are willing to re-flash their hardware with third-party firmware such as DD-WRT or OpenWRT, I would always encourage anyone to go with a company that keeps their firmware up to date, like Ubiquity.
It’s not their hardware. It’s their firmware which is the problem.
The nefarious, evil purpose of the cloud service is…just lock in. And being easy to configure.
From there, they can force ISPs to contact their clients to demand the issue be resolved. If the client does not respond to the ISP, the ISP is forced to suspend the connection until the client can demonstrate a fix has been implemented. In all cases, that vulnerability vanishing has the ISP updated so the client is no longer in danger of being pestered.
If the product is still being sold in stores, or is not very far past EoL, and there is no manufacturer patch available, those manufacturers must take their hardware back for a 100% MSRP refund, or provide an equivalent router without those exploits.
It’s only if the product has been no longer manufactured for a minimum set period of time - say, 7 years - that it is deemed “too far past EoL” for the responsibility for patching/replacing to fall on manufacturers, and responsibility finally falls to the consumer to replace/upgrade.
In all cases, a customer can “fix” their router with third-party firmware such as OpenWRT or DD-WRT, but this also requires laws to be written that forces manufacturers to not hardware-lock their routers, and force them to meet the minimum storage/driver-availability specs these third-party firmwares need.
So you have a router built with Chinese components (all of the ones anyone here can afford) with closed and "open" firmware built by them. I bought one of those GL.inet "open" routers and the WRT packages bricked it, so I have a choice of reverting or flashing from the factory (which appears to be a link to HK).
That's probably 99.99% of use cases. They're in your base and they always have been.
Say you know nothing about router firmware without saying you know nothing about router firmware.
OpenWRT and DD-WRT and other open-source third-party firmwares are THIRD PARTY firmwares. They have no connection with the manufacturer whatsoever.
> WikiDevi URL: https://wikidevi.wi-cat.ru/TP-LINK_Archer_C2_v3.x
Every one had a .ru domain. How do you know, exactly, who built it? GL.inet builds their own WRT package. It's a "feature".
Brand-new to the Internet, are ya?
Just because you cherry-pick Russian informational sites doesn’t mean that third-party firmwares have any connection to Russia whatsoever.
Third-party firmwares are open-source projects, worked on by tens of thousands of volunteers from around the planet, and frequently have ZERO CONNECTION to any one hardware manufacturer.
There are some collaboration efforts, when a particular manufacturer decides to adopt an open-source firmware as the exclusive firmware for their own hardware, but that simply means the hardware is fully unlocked for any third-party firmware that wants to be adapted for that hardware. These manufacturers just decided that they had no desire to f**k over the consumer by locking them into custom-made firmware.
For example, I believe Turris https://www.turris.com/ takes a stock, latest copy of OpenWRT and makes a few tweaks to extend its capabilities for additional, server-like features.
WiFi NIC firmware is a much smaller attack surface than the whole Linux OS.
Congrats, you have just identified DD-WRT and OpenWRT.
> The WiFi firmware is closed-source and comes from the silicon vendor rather than the router OEM: Qualcomm, Broadcom, or Mediatek, not TP-Link, ASUS, Netgear, etc.
Never heard of the term “driver”, have you? Look it up. It’s wild. Windows uses them, and so does Linux and other operating systems like DD-WRT and OpenWRT.
> Never heard of the term “driver”, have you? Look it up. It’s wild. Windows uses them, and so does Linux and other operating systems like DD-WRT and OpenWRT.
Please don't post with this kind of attitude, especially when you're so thoroughly wrong.
Look up the term "application processor"; I mentioned it previously but you must not have recognized that it was a concept you are unfamiliar with. This is the ARM (or formerly MIPS) processor that in a router will be running Linux, or on a phone would be running Android or iOS. The AP's CPU cores are not the only processor cores that will be found in the system. Separate from the AP and often at the far end of a PCIe link (and hopefully also an IOMMU) are the WiFi NICs, which have their own embedded processor cores. These embedded cores are not running Linux and instead are running proprietary firmware that is closely tied to the specific hardware. (In a phone, the cellular baseband will have its own processor core(s) running separate code from the AP's OS.)
Linux has its drivers for the WiFi NICs, and those drivers run on the AP cores. Typically, the first responsibility of the Linux driver is to retrieve the correct firmware from storage and transmit it over PCIe to the WiFi NIC so that the processor cores embedded in that NIC can boot up and start running that firmware on cores and a memory address space that is completely separate from what the Linux OS on the AP can directly interact with. The firmware must be uploaded to the NIC by the AP because the NIC typically doesn't have flash memory to store its own firmware, only volatile RAM, and because the firmware version usually must be precisely matched to the driver version running on the AP. This is in contrast to eg. SSDs, which store their own firmware (because they naturally have plenty of non-volatile storage) and expose standard interfaces for drivers to interact with rather than having tight version coupling.
Exactly what the firmware running on the WiFi NIC does will vary between devices. It can often be inferred by inspecting the Linux driver to see what it doesn't do on the AP. Common functionality handled by firmware running on the NIC includes selecting transmission rates and power levels, and handling frame aggregation.
You can readily inspect the filesystem of an OpenWRT image and you'll find the binary blobs that are the firmware which will be sent to the NICs as part of the Linux driver initializing. What you won't find is that binary blob code executing on the AP in any userspace process or kernel thread.
And if you're still arrogantly confused: the WiFi firmware is not the same thing as the Linux driver. In all WiFi hardware that uses firmware running on the NIC (which includes all WiFi hardware supporting anything newer than 802.11n), the WiFi NIC's firmware is closed-source. This is independent of whether or not the Linux driver is closed-source, because the Linux driver is a different piece of code running on a different processor.
All WiFi devices that have received the Free Software Foundation's "Respects your Freedom" certification are limited to 802.11n because those are the newest devices that don't run proprietary blobs on their own processor cores. OpenWRT has looser requirements and tolerates proprietary blobs as long as they don't need to run on the AP as part of the Linux system. The typical setup for an OpenWRT device is an open-source Linux driver communicating over PCIe with closed-source code running on the WiFi NIC.
The Candela Technologies page I linked to is an example of closed-source firmware to run on the WiFi NIC, paired with an open-source Linux driver to run on the AP. This is one of the few examples of the closed-source firmware not coming directly from the creator of the WiFi chip. Both the WiFi firmware and the Linux driver had to be modified in order to add the features Candela Technologies needed. They were able to acquire a license from Qualcomm to modify and redistribute the WiFi firmware, but not to open-source that firmware. The Linux driver was already open-source so no special license was required for that side of their feature enablement.
Some TP-Links are not great -- get a first gen C7, IIRC.
Routers are going to be a bit more expensive and a bit less reliable for a while. We'll live.
Eventually i got through to a human that said you can't run it without registering it. it did NOT say that on the box.
shit like this is what the ftc should crack down on
Another thing I've noticed is companies tend to still sell their models which are close to EOL on their website. Something needs to be done about that.
Selling models close to EOL or trying to hold hardware makers responsible for firmware security has been an issue for decades.
If this is actually the case then you should contact the FTC because Asus under an order to pay attention to security:
* https://www.ftc.gov/news-events/news/press-releases/2016/07/...
I have an Asus RT-AC68U that I bought ages ago that's still getting regular first-party firmware updates (plus the ones from Merlin). Currently using ISP-provided hardware, but given my past experience I'd definitely look at Asus as an option if I needed a new router.
As far as my TP-Link router, I think I remember it being stuck on a 2022/09 firmware until at least 2023/09, and I wound up flashing it with OpenWRT earlier this year.
* https://wikidevi.wi-cat.ru/ASUS_RT-AC1200_series
The V2 seems to be exactly the same except for some minor chip revisions (e.g., -DAN vs -AN), perhaps due to OEM part availability.
OpenWRT also supports (supported?) the V2:
Google and Amazon are full of spyware. I feel I have nowhere to run!
Another option is the recently released official OpenWRT One.
I do like that I can export my config as a script. Haven't had to reboot it yet, excluding firmware updates of course.
I switched to Ubiquiti EdgeRouters for a while but they went the way of the dodo too, so now I use a Protectcli box running Coreboot and OPNSense; it's essentially just a PC with nice Intel NICs that play nice for networking in a small fanless form-factor that you can install a routerOS on (pfSense, OPNSense etc) and always be up to date.
I own one dlink router I bought in 2014. Has been running since then. 0 updates.
What "update" should I give my router ?
Forgive my ignorance
Your D-Link router from 2014 likely stopped receiving updates within 2-4 years of its manufacture so updating now will still leave you quite outdated, if the manufacturer released any updates at all (and if they did, they may even have pulled them offline as we're now 10 years after the fact).
If you're concerned about the security, you can check if your router is supported by an open-source OS like OpenWRT and flash that over the factory software, or upgrade to a newer model (bearing in mind another consumer router will only get you a few short more years of updates).
If you're really cautious (like I am) you buy something that you can install a router OS on that you know will always be updated; pfSense, OPNSense, OpenWRT, Vy etc.
This link is from a quick query on dlink routers.
https://unit42.paloaltonetworks.com/6-new-d-link-vulnerabili...
Just like any other computer, it can be exploited if vulnerabilities are found and in 10 years it's likely some have been found.
Unfortunately, it's likely that dlink stopped providing updates for your product which leaves you with three options:
1. Ignore the problem
2. Install something like OpenWRT if your hardware is supported
3. Purchase new hardware
Old version works fine.
Routers as the gateways into all sorts of networks, and they see/control all of the traffic in and out and often between devices on the network; they're a critical junction.
Two things can hold true at the same time. A US company selling US equipment and US software can have US law enforcement agents show up and point US guns at them for non-compliance.
But that in turns sets up a captive market where the US players in the market are more likely to perform collusion and raise prices.
The FTC went after (Taiwan-based) Asus for security reasons:
> After a public comment period, the Federal Trade Commission has approved a final order resolving the Commission’s complaint against ASUSTeK Computer, Inc., charging that critical security flaws in its routers put the home networks of hundreds of thousands of consumers at risk.
* https://www.ftc.gov/news-events/news/press-releases/2016/07/...
So 'legitimate' security concerns have been a thing in the past.
Ebay, aliexpress, reshipper, friend in europe...there is always a way
The US outsourced absolutely everything to China and is now banning it up down and centre. Shizophrenic much?
In theory no black hat should be able to access them from the Internet but they could call out and ask for commands if they are so programmed.
Huawei was not banned, they were bullied out of the US market, and had restricted access to US technologies.
attracting her best talent works better when the CPC doesn't hold families hostage. because of that, we are unable to trust most chinese nationals.
Sounds like they want to apply pressure to TP-Link so they start to fix more and faster.
https://9to5mac.com/2024/12/18/most-popular-home-internet-ro...
China can produce things cheaper than we can. “Industrial policy” to make a wealthy nation like the US a competitive low-cost manufacturing hub are delusional. Let us focus on what we are good at and other countries focus on what they are good at.
Realpolitik is making our country wealthier and rationally approaching emerging risks, not banning cheap cars and solar panels because other countries are too good at making them. Let alone engaging in trade wars with our allies and banning acquisitions from Japan.
Slowly I am feeling back into world geopolitics of my childhood.