Live data from Hacker News

OpenWrt Two Approval

openwrt.org

121–130 of 133 posts

Re: OpenWrt Two Approval

#121
post #105

OpenWrt went crazy in the last few years. OpenWrt (the OS) is a mess: - bugs are ignored, - bug fixes ignored, - improvements to core OpenWrt are ignored (although package PRs are still accepted somehow), - almost no new documentation, - no reply for documentation clarifications on the forum, - significant parts of OpenWrt are not accessible for PRs or bug reports: fstools, procd, ubus, etc. - no improvements to crit…

> With OpenWrt Two, I bet they're going to make the same mistakes as OpenWrt One: not enough memory and not upgradable, wifi not replaceable, no usable expansion slots (mini-PCI, M.2) and, of course, no (e)SATA. Another e-waste product that will be obsolete even before it's available to buy. Those are only mistakes if you ignore the realities of what hardware is available. A highly-integrated SoC designed specificall…

> Those are only mistakes if you ignore the realities of what hardware is available.

If you think the focus should be on what hardware is available, then why make a OpenWrt Two instead of buying the existing hardware?

> A highly-integrated SoC designed specifically for wireless router usage is a more cost-effective platform than a generic x86 PC.

This is exactly why OpenWrt One and probably Two too is just e-waste - because those cheap integrated hardware platforms are e-waste to begin with. They are indeed cost-effective, but only for a brief moment in time.

Wifi drivers are one of the most problematic part of linux kernel. Also, wifi standards are still changing very fast. Non-replaceable wifi is one of the things that's going to kill these boards.

OpenWrt One can only be used as a wireless router. There's no storage, no expansion slots, not even USB3. It can't be repurposed, can't be upgraded, can't even be used as an ordinary ethernet router because there's no switch. In less than a year, OpenWrt Two makes it obsolete. OpenWrt Two won't be any different, so why make it at all? What will that improve? There's tons of boards better than that (BananaPi R-series, GLinet routers).

So that's basically my argument.

(I didn't complain about the CPU. The CPU is probably the most future-proof component in there. Using x86 CPU is probably the worst design decision they could make.)

> Adding SATA controllers to a WiFi router SoC does not benefit Netgear, et al.

So what? That's what PCIe is for (and expansion slots).

Turris Omnia is almost 10 YEARS old and it's still being sold, and at outrageous prices, mind you, even second-hand. It's CPU is obsolete, it's miniPCIe slots are obsolete, it's ethernet is (almost) obsolete, it's memory is barely sufficient, and yet it's still usable as a home router, personal web server, file server, NAS, torrent client, remote download manager, TOR node, proxy, etc. etc. after 9 years! Why is that? Because Wifi was replaceable and it had 2GB RAM at a time when most routers only had 32MB.

Beat that, OpenWrt One&Two!

> A focus on the kind of modular, expandable and upgradable hardware platforms that actually currently exist (namely, PCs) is what leads to the distractions you're complaining about: "video acceleration, mesa, X, wayland, Doom, etc."

No, that's not it. A mini-PCIe / M.2 slot won't fit a GPU (well, it could, but...). A SO-DIMM slot instead of soldered memory also won't change anything. Meanwhile, GPUs are already there in most SoCs supported by OpenWrt, not just x86: Rockchip, Mediatek, Broadcom/RaspberryPi, you name it.

If devs were interested in GPU support, they could have contributed to Buildroot instead. Why did they add it to OpenWrt instead of Buildroot? Probably because it was easy: they're the main devs of OpenWrt with commit privileges. I'm not saying that they abused those privileges. I'm saying that their interest doesn't seem aligned with what OpenWrt is: an OS for routers.

> modular, expandable and upgradable hardware platforms that actually currently exist (namely, PCs)

And this is the second problem with OpenWrt One/Two. If an OpenWrt dev wanted to have an OpenWrt NAS, or an OpenWrt server of some kind, anythining other than (just) a router, only PCs fit the requirements. Not even Rockchip/BananaPi SBCs. Of course that dev is going to contribute with support for PCs in OpenWrt.

Re: OpenWrt Two Approval

#122

Earlier quoted context omitted.

> What kind of security vulnerabilities do you think an incompetent PC OEM is going to accidentally introduce to a barebones PC that's basically shipping an Intel reference platform and no SSD? Historically remote code execution in the IME. > an incompetent PC OEM And then it never gets patched.

> Historically remote code execution in the IME. That's only a problem if the Active Management Technology feature is correctly supported by the OEM including wiring it up to a supported NIC, and the feature is enabled and provisioned by default, and the NIC in question is connected to a network that is a potential attack vector. From what I can tell, the current NIC of choice for Chinese router PCs is the Intel i226…

> there's no part of the boot firmware that continues interacting with any NIC after the OS has taken over managing PCIe peripherals

Are you sure about that? Because I remember something called ACPI that gets executed by the OS every time some configuration changes, such as power levels.

Re: OpenWrt Two Approval

#123
post #12

What I would want to have some company to make one device that would at the same time be: 1) router 2) smart tv (airplay, chromecast, miracast) 3) smart speaker 4) smart home gateway (matter) 5) wireless charging pad 6) private cloud (nextcloud) 7) private backup (removable nvm) 8) private vpn / dns / pihole / adguard 9) mini server Everything in a nice package and preconfigure and ideally modular (upgradable ssd, wi…

BananaPi R4 + some storage + OpenWrt + native packages and Docker for everything that's missing from native packages.

Re: OpenWrt Two Approval

#124
post #122

Earlier quoted context omitted.

> Historically remote code execution in the IME. That's only a problem if the Active Management Technology feature is correctly supported by the OEM including wiring it up to a supported NIC, and the feature is enabled and provisioned by default, and the NIC in question is connected to a network that is a potential attack vector. From what I can tell, the current NIC of choice for Chinese router PCs is the Intel i226…

> there's no part of the boot firmware that continues interacting with any NIC after the OS has taken over managing PCIe peripherals Are you sure about that? Because I remember something called ACPI that gets executed by the OS every time some configuration changes, such as power levels.

> that gets executed by the OS

Do you see the problem here?

Which ACPI table do you expect to be used for delivering malicious executable code?

Re: OpenWrt Two Approval

#125
post #121

Earlier quoted context omitted.

> With OpenWrt Two, I bet they're going to make the same mistakes as OpenWrt One: not enough memory and not upgradable, wifi not replaceable, no usable expansion slots (mini-PCI, M.2) and, of course, no (e)SATA. Another e-waste product that will be obsolete even before it's available to buy. Those are only mistakes if you ignore the realities of what hardware is available. A highly-integrated SoC designed specificall…

> Those are only mistakes if you ignore the realities of what hardware is available. If you think the focus should be on what hardware is available, then why make a OpenWrt Two instead of buying the existing hardware? > A highly-integrated SoC designed specifically for wireless router usage is a more cost-effective platform than a generic x86 PC. This is exactly why OpenWrt One and probably Two too is just e-waste -…

Am I understanding you correctly: your complaint about OpenWRT software is that they aren't focused exclusively enough on being a router, and your complaint about OpenWRT hardware is that they are focused exclusively on being a router?

Re: OpenWrt Two Approval

#126

Earlier quoted context omitted.

I’ve reluctantly come to the view that Apple is the best bet for a consumer to get a somewhat reasonable (price notwithstanding) compromise between hardware vertical integration and software that offers substantial bug bounties and large market incentives to not allow bad vulnerabilities to sit for too long. With deep enough pockets to hang tough if needed in various situations.

Apple also ships bloated buggy software with a massive TCB that makes it almost trivially easy for state actors to break in.

I completely agree about the buggy bloated software but all I’m saying is that it’s the best bet compared to actual consumer alternatives which are generally a frankenmix of the lowest cost components sourced from the lowest cost vendor with minimum effort spent to ensure and maintain any semblance of security.

Re: OpenWrt Two Approval

#127
post #105

OpenWrt went crazy in the last few years. OpenWrt (the OS) is a mess: - bugs are ignored, - bug fixes ignored, - improvements to core OpenWrt are ignored (although package PRs are still accepted somehow), - almost no new documentation, - no reply for documentation clarifications on the forum, - significant parts of OpenWrt are not accessible for PRs or bug reports: fstools, procd, ubus, etc. - no improvements to crit…

> they're going to make the same mistakes [...] no (e)SATA.

> I wish they got back to routing.

I feel like you are contradicting yourself.

Re: OpenWrt Two Approval

#128
post #122

Earlier quoted context omitted.

> there's no part of the boot firmware that continues interacting with any NIC after the OS has taken over managing PCIe peripherals Are you sure about that? Because I remember something called ACPI that gets executed by the OS every time some configuration changes, such as power levels.

> that gets executed by the OS Do you see the problem here? Which ACPI table do you expect to be used for delivering malicious executable code?

I'm not that knowledgeable, but I rememember Computrace auto-install on a system that didn't even have UEFI.

Re: OpenWrt Two Approval

#129
post #91

Earlier quoted context omitted.

> There's 30$ usb-c adapters out now. Where-as 10Gbe is usually $130+. Sure, but if you include another SFP+ port, you can run that at 1, 2.5, 5, or 10gbit. Another SFP+ port gives you a BUNCH of options (including the "copper, fiber, or twinax?" option). A 5Gbit copper port locks you in to just that one configuration. As for the expense of SFP+ modules, go check out the 10Gtek company. The optical ones are very inex…

Options for who? 5GBASE-T can run on Cat5e/Cat6 cabling which people probably already have. This makes the router a viable product, which can improve your home network performance with minimal investment, just by swapping out your old router. OTOH, the dual SFP+ configuration is more on the exotic side. It may make sense on some professional setting (or some outlier home network configurations - like yours), but I gu…

> Options for who?

The operator of the device. Who were you thinking of?

> 5GBASE-T can run on Cat5e/Cat6 cabling which people probably already have.

There are SFP and SFP+ modules that will do 1, 2.5, 5, and 10GBASE-T just fine. If the operator wants to run 1GBASE-T, they can. If the operator wants to run 10GBASE-[SL]R, they can do that, too. Options.

> The dual SFP+ configuration is more on the exotic side.

1) Used to be that having a gigabit Ethernet port was on the exotic side, too. (If we go far enough back, 10mbit was hella fancy.) Times change.

2) Here are two SFP+ ports for ~140 USD. [0] Here are four for 150USD. [1] Times change, man.

[0] https://mikrotik.com/product/css318_16g_2s_in>

[1] https://mikrotik.com/product/crs305_1g_4s_in>

Re: OpenWrt Two Approval

#130
post #90

Earlier quoted context omitted.

You should be aware of how much collaboration the OpenWRT folks have with -say- Ubiquiti Networks. [0] And yet, OpenWRT runs fine on the UAP-AC-LITE and -LR. I'd wager there's nearly zero collaboration between the overwhelming majority of the hardware manufacturers that create hardware that OpenWRT runs on and the OpenWRT folks. Your concern is entirely unwarranted and -if I might be a little uncharitable- seems to c…

What does that have to do with anything? I'm speaking about experience of deploying existing gl.inet devices, marketed as "fully open source" with OpenWrt being front-and-center in marketing, as well as being promoted on the OpenWrt wiki. That someone from the community has made OpenWrt run fine on Ubiquiti gear has nothing to do with my comment and is not indicative of anything (if anything perhaps supporting the no…

> Did you read the last line of the comment you replied to?

Yes. I read your entire comment and thought on it for a while before I replied. It's stupid to do otherwise.

> That someone from the community has made OpenWrt run fine on Ubiquiti gear has nothing to do with my comment and is not indicative of anything...

Yeah, except that it is. Your comment indicated that ongoing effort from the GL folks was relevant to having OpenWRT continue to run on the hardware:

> I'm less concerned with their jurisdiction and company profile than their absent software/firmware maintenance.

Ubiquiti is famously anti-open-source. They used to be less so with their routers, but always were very, very nasty when it came to their WiFi access points. There's no way in hell they're providing assistance (especially ongoing assistance) to the OpenWRT project.

Post reply on HN