Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
zh:supported_devices:432_warning [2019/01/15 16:23] – 修正小问题 jiangming1399zh:supported_devices:432_warning [2020/01/08 14:31] – [可用性问题] lujimmy
Line 9: Line 9:
 ===== 可用性 ===== ===== 可用性 =====
  
-**最低内存需求** +**内存不足影响运行稳定**
- +
-  * 32MB 内存的设备可以运行基本的路由功能,但可能会经常性的崩溃。稳定与否取决于你的硬件以及路由的用途。 +
-  64MB 内存的设备在稳定性上依然会有一些问题,取决于你的硬件和用途。 +
-  如果你想要将路由用作特殊用途(如挂机下载等),那么推荐使用 128MB 或更大内存的设备。+
  
 +  * 32MB 内存可以用于基本的路由或AP功能,但可能会经常性的崩溃,取决于您的硬件以及具体用途。
 +  * 64MB 内存可能仍然存在稳定性问题,取决于您的硬件以及具体用途。
 +  * 如果要运行软件来获得基本的路由或AP之外的功能,推荐使用128MB或更大的内存。
  
 ===== 扩展性 ===== ===== 扩展性 =====
Line 20: Line 19:
 **需要有足够的闪存来存储OpenWrt固件镜像** **需要有足够的闪存来存储OpenWrt固件镜像**
  
-  * 至少需要 4MB (无法安装 luci) 推荐 8MB (可以装下 luci 以及一些其他的应用程序) +  * 至少需要4MB(无法安装luci)推荐8MB(可以装下luci以及一些其他的应用程序) 
-  * 4MB 已经可以工作了,但工作的不算太好。 >4MB 的闪存会让在使用时感到更为舒畅。 +  * 4MB已经可以工作了,但工作的不算太好。 大于4MB的闪存会让在使用时感到更为舒畅。 
-  * 4MB 的设备几乎无法安装任何重要的软件,除非使用 [[docs:guide-user:additional-software:imagebuilder|the Image Generator (Image Builder)]] (需要使用Linux系统,并且你需要有一点使用的经验) 或者使用 [[docs:guide-user:additional-software:extroot_configuration|Extroot]]. 对于高级用户来说,他们可以创建自定义固件以[[docs:guide-user:additional-software:saving_space|节省固件空间]], 但部分软件无论用什么方法都无法放入其中。  +  * 4MB的设备几乎无法安装任何重要的软件,除非使用 [[docs:guide-user:additional-software:imagebuilder|Image Builder (Image Generator)]] (需要使用Linux系统,并且要有一点使用的经验) 或者使用 [[docs:guide-user:additional-software:extroot_configuration|Extroot]]. 对于高级用户来说,他们可以创建自定义固件以[[zh:docs:guide-user:additional-software:saving_space|节省固件空间]], 但部分软件无论用什么方法都无法放入其中。  
-  * 如果还想要安装一些自定义的软件,那么8MB及以上闪存和64MB及以上内存是必须的。+  * 如果还想要安装一些自定义的软件,那么8MB及以上闪存和64MB及以上内存是必须的。
  
  
-4MB闪存的设备只能存储LEDE固件镜像,故扩展性方面有着极大的限制。对于小闪存设备,你还是不要期望太多吧。 +在多数情况下,如果只有4MB的闪存,将无法安装这些(或其他)热门的软件包:
- +
-在多数情况下,如果只有4MB的闪存,将无法安装这些(或其他)热门的软件包:+
  
   * [[docs:guide-user:network:tunneling_interface_protocols|VPNs]] 以及其他需要加密的软件   * [[docs:guide-user:network:tunneling_interface_protocols|VPNs]] 以及其他需要加密的软件
Line 38: Line 35:
 ===== 支持性 ===== ===== 支持性 =====
  
-随着时间的发展,小内存和闪存设备将会越来越难得到支持。OpenWRT可能会在近期停止这些设备的支持。+随着时间的发展,小内存和闪存设备将会越来越难得到支持。OpenWrt近期可能会在无照会的情况下结束对这些设备的支持。
  
  
Line 67: Line 64:
 maximum usable firmware size: 3538944 bytes</code> maximum usable firmware size: 3538944 bytes</code>
 (以上数字是包括luci和大致相同的功能集的各发行版本镜像大小) (以上数字是包括luci和大致相同的功能集的各发行版本镜像大小)
 +
 +===== Supportability issues =====
 +
 +It is getting harder or even impossible over time to support devices with low Flash + RAM.
 +OpenWrt support for those devices will likely end without warning at any time in the near future.
 +
 +
 +===== Advice =====
 +
 +Users that are not expert users of OpenWrt (those that can build their own images) should consider 
 +
 +**16/64 as an //absolute// minimum for any device, with at least 128 MB of RAM being preferred.**  
 +
 +Users should expect that devices with less than 16 MB of flash and/or 64 MB of RAM may be unstable in basic operation under current versions of OpenWrt (17.X, 18.X). They should further expect that support for the device may be dropped at any time and that security patches/updates to the kernel, drivers, and/or application software will not be available. While there is no warranty of ongoing support for any device under OpenWrt, those with insufficient resources are at great risk for "end of support".
 +
 +Previous versions of OpenWrt (such as earlier versions of 17.X, 15.X, "Chaos Calmer" and prior) contain now-known security vulnerabilities in the kernel, wireless implementation, and/or application code. The OpenWrt community cannot support running known-vulnerable code under any situation. "It's just my router" is not justification as your router becoming compromised can impact others as a jump-point, command-and-control, or other participant in an attack. In many cases, these known vulnerabilities are being actively targeted, potentially including by [[https://blog.talosintelligence.com/2018/05/VPNFilter.html|advanced, likely state-sponsored or state-affiliated actor]] or actors.
 +
 +===== An analysis of the issue done by forum user slh =====
 +As written in [[https://forum.openwrt.org/t/should-lede-support-devices-with-only-4mb-flash/1018/71| this forum post ]] by forum user **slh**.
 +
 +First of all, I'm not pretending to speak for the LEDE team, however looking at the plain numbers presents a quite obvious situation.
 +
 +Taking "[[https://forum.openwrt.org/t/solved-why-no-images-generated-for-default-d-link-dir-600a1/990| Why no images generated for default D-Link DIR-600A1?]]" as an example (yes, some other 4 MB flash devices are a bit better than this particular specimen, the trend remains to be the same though).
 +
 +<code>D-Link DIR-600A1:
 +Backfire 10.03..............: 2293764 bytes
 +Backfire 10.03.1............: 2949124 bytes
 +Attitude Adjustment 12.09...: 2883588 bytes
 +Barrier Breaker 14.07.......: 3276804 bytes
 +Chaos Calmer 15.05..........: 3342340 bytes
 +Chaos Calmer 15.05.1........: 3407876 bytes
 +LEDE 17.01 release branch...: 3473412 bytes
 +absolute firmware size......: 3735576 bytes
 +maximum usable firmware size: 3538944 bytes</code>
 +(all of these figures are for release images, including luci and a more or less identical feature set).
  
 The erase block size for this (and most other) devices is 64 KB, so you now end up with 256 KB (== 4 erase blocks) free space, compared to 320 KB (== 5 erase blocks before). While this may look comfortable at a first glance, you have to consider that free space can only be assigned in (full) block size chunks, so once you touch the overlay partition at all, you already have one erase block in use (64 KB). Therefore the firmware creation tools used by LEDE enforce at least 3 erase blocks reserve for the overlay filesystem (that's where the maximum usable firmware size comes from, compared to the total size of the firmware partition). In other words, with 17.01 you'll only have 1 erase block (64 KB) before the hard limit, while 15.05.1 still gave you 2 spare erase blocks (128 KB) for your own use. On top of this there is the file system overhead needed for formatting to jffs2 as well (jffs2 does some light compression, but its fs header and log (more or less directory entries) need some space, then there is the hard requirement to keep some free space (in erase block == 64 KB chunks) for the garbage collection to work) at all times, reducing the usable free space even further. Around 25 KB are used by the configuration overlay immediately after firstboot, before you actually get a chance to configure anything. The erase block size for this (and most other) devices is 64 KB, so you now end up with 256 KB (== 4 erase blocks) free space, compared to 320 KB (== 5 erase blocks before). While this may look comfortable at a first glance, you have to consider that free space can only be assigned in (full) block size chunks, so once you touch the overlay partition at all, you already have one erase block in use (64 KB). Therefore the firmware creation tools used by LEDE enforce at least 3 erase blocks reserve for the overlay filesystem (that's where the maximum usable firmware size comes from, compared to the total size of the firmware partition). In other words, with 17.01 you'll only have 1 erase block (64 KB) before the hard limit, while 15.05.1 still gave you 2 spare erase blocks (128 KB) for your own use. On top of this there is the file system overhead needed for formatting to jffs2 as well (jffs2 does some light compression, but its fs header and log (more or less directory entries) need some space, then there is the hard requirement to keep some free space (in erase block == 64 KB chunks) for the garbage collection to work) at all times, reducing the usable free space even further. Around 25 KB are used by the configuration overlay immediately after firstboot, before you actually get a chance to configure anything.
Line 87: Line 119:
 [4] I would expect that there already are a couple of 4 MB flash devices in the target list for which no release firmware can be built for 17.01, because of less ideal flash partitioning schemes chosen by the vendor (dropping free space below 3 erase blocks). Those are probably a minority, but given the close numbers, I'd be very suprised if there wouldn't be any affected. [4] I would expect that there already are a couple of 4 MB flash devices in the target list for which no release firmware can be built for 17.01, because of less ideal flash partitioning schemes chosen by the vendor (dropping free space below 3 erase blocks). Those are probably a minority, but given the close numbers, I'd be very suprised if there wouldn't be any affected.
  
-[[https://forum.lede-project.org/t/lede-a-bit-over-the-top-with-the-minimal-requirements/2009/4?u=tmomas|More explanations]] on this subject by forum user **slh**.+[[https://forum.openwrt.org/t/lede-a-bit-over-the-top-with-the-minimal-requirements/2009/4?u=tmomas|More explanations]] on this subject by forum user **slh**. 
 ===== The opinion of a Core LEDE developer ===== ===== The opinion of a Core LEDE developer =====
-As originally written in [[https://forum.lede-project.org/t/should-lede-support-devices-with-only-4mb-flash/1018/79|this forum post]] by jow.+As originally written in [[https://forum.openwrt.org/t/should-lede-support-devices-with-only-4mb-flash/1018/79|this forum post]] by jow.
  
 Just providing my rather pragmatic opinion on the topic here:\\ Just providing my rather pragmatic opinion on the topic here:\\
  • Last modified: 2020/01/08 14:53
  • by lujimmy