Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FCC updates covered list to include foreign-made consumer routers

fcc.gov

Post reply on HN
Print view View original

451–452 of 452 posts

Re: FCC updates covered list to include foreign-made consumer routers

#451

Post by wao0uuno »

vaxman wrote: post #272
wao0uuno wrote: post #235

Earlier quoted context omitted.

Lmao you're an IT guy, right? Get yourself a Raspberry Pi 5, PCIe adapter and a second hand gigabit Intel NIC. Slap a case on that, put OpenWRT on it and bam! High performance, high quality router built from trustworthy parts running open source operating system. Not the prettiest and simplest solution but at least that way you don't have to depend on Realtek chips and Chinese firmware.

There is an entire WORLD that lives in your computer below the operating system (eg, OpenWRT). For example, in your Raspberry Pi 5, there is a chip called the VideoCore GPU and it contains a big blob of code known only to Raspberry Pi Foundation and, perhaps, Five Eyes. The Chinese processors are like that too! Even if you have the source and build system to recreate the exact binary blob and can reload it with Jedec…

I get your point but once you start looking at tech this way you will come to a conclusion that nothing's safe. With RPi you at least know that millions of units have been deployed in companies where monitoring is so strict and stakes so high nothing fishy would go unnoticed. Also there is a reputation of the manufacturer and people in charge being at stake. With no name Chinese hardware you can't really expect firmware updates and if anything fishy gets discovered by someone they'll just change their brand name from King Dong to Dong Xiang and keep selling.

Re: FCC updates covered list to include foreign-made consumer routers

#452

Post by M95D »

mindslight wrote: post #273
M95D wrote: post #215

Earlier quoted context omitted.

> not having straightforward APIs like BIOS/EFI. Oh, no, not this again! > But we generally see that as soon as the manufacturer stops their updates, the community versions start lagging behind as well. Care to demonstrate that? The reason OpenWrt abandoned most routers was 1) insufficient flash space in the kernel partition, or insufficient total flash space in no-USB, no-SPI routers, 2) unwillingness to repartition…

> Oh, no, not this again! What are you referring to? Would you not say there is a difference between OpenWRT having to make a list of supported whole systems, whereas an amd64 Linux distribution making a list of chipsets? I can go buy an off the shelf laptop, stick a generic "Linux install" USB in it, and be reasonably certain most things are going to work. Whereas OpenWrt I have to look at their list of supported ma…

> I can go buy an off the shelf laptop, stick a generic "Linux install" USB in it, and be reasonably certain most things are going to work

Oh, God, I have to repeat it again.

That's because of x86 standards for APICs, keyboard controllers, USB controllers, framebuffer addresses, PnP buses, storage controllers, etc. It has nothing to do with the BIOS, and has even less to do with UEFI, since it removed standard BIOS real mode interrupts (UEFI CSM).

ARM's only standard is CPU instructions. Each chip has different peripherals and each one needs a different driver. ARMv7 didn't even have a standardized timer! How can you expect to run anything without knowing where's the timer? UEFI and ACPI tries to patch it up with software, but the device tree is a better alternative because it can be updated, bug fixed and extended by the end users.

Let me give you a real example, something I did last week:

I have a Radxa Rock 5 ITX. The M.2 E-key slot has PCIe lines but no separate line for eSATA (the E-key doesn't have those). But the CPU has a mux that can switch those PCIe lines into SATA lines. It's in the device tree. Radxa makes a passive SATA adapter for the E-key slot (I bought it), but it doesn't switch the mux by itself.

Rockchip uses device tree. The mux is in there. Radxa didn't write an overlay for the device tree to switch the mux into SATA mode. I wrote that myself. It's a simple PCIe status="disabled" / SATA status="okay".

If Rockchip used UEFI instead of device tree, there would be absolutely nothing I could do if Radxa didn't explicitly add a setting for this mode change. And if they didn't write an overlay as simple as that, I very much doubt they would implement in UEFI.

I couldn't make sense of the second portion of your reply. What are you saying? That is preferable to be able to update a crap OEM distro instead of completely replacing it with something that is derived from mainline Linux kernel and ordinary Linux userspace?

OpenWrt only does "contortions" because routers have various ethernet and wifi configurations. Some have an oboard switch, some don't, some have WAN / LAN ethernet ports, some only have WAN and wifi. They're going very much towards standardization, not "contortions".

DD-WRT doesn't take anything from the original firmware, well... maybe some blobs. AFAIK (I didn't use it much), the old kernels are official Linux kernels. They're just older versions that still work with drivers and blobs that were abandoned and no longer updated by the OEM.

Post reply on HN