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 [2018/06/10 01:14] – improve translation jiangming1399zh:supported_devices:432_warning [2020/01/08 14:31] – [可用性问题] lujimmy
Line 1: Line 1:
 ====== 4/32警告 ====== ====== 4/32警告 ======
 ~~NOTOC~~ ~~NOTOC~~
-任何一个操作系统都需要: +对于任何一个操作系统都需要: 
-  - 足够的闪存以适应固件像 +  - 足够的闪存以存放固件像 
-  - 足够的内存以保证稳定运行+  - 足够的内存以保证系统的稳定运行
  
 {{section>zh:meta:infobox:432_warning#infobox_for_tohs&noheader&nofooter&noeditbutton}} {{section>zh:meta:infobox:432_warning#infobox_for_tohs&noheader&nofooter&noeditbutton}}
Line 9: Line 9:
 ===== 可用性 ===== ===== 可用性 =====
  
-**稳定运行所需的最低内存要求**+**内存不足影响运行稳定**
  
-  * 32MB 是最低要求。在这个条件下,OpenWRT或许可以运行,取决于使方法。 +  * 32MB 内存可以用于基本的路由或AP功能,但可能会经性的崩溃,取决于硬件以及具体。 
-  * 64MB 可以很流畅的运行,相对于32M说是一个选择+  * 64MB 内存能仍然存在稳定性问题,取决于您硬件以及具体用途。 
 +  * 如果要运行软件获得基本的路由或AP之外的功能,推荐使用128MB或内存
  
 ===== 扩展性 ===== ===== 扩展性 =====
  
-**需要有足够的闪存来存储LEDE固件镜像**+**需要有足够的闪存来存储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]]. 对于高级用户来说,安装特定的或者自定义固件绕过这个限制;对于新手户,他们可能会发现他们浪费了几个小时的时间,因为这个可扩展的系统无法安装在他们的设备上。 +  * 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(或更多)更好选择。 +  * 如果您还想要安装一些自定义软件,那么8MB及以上闪存和64MB及以上内存必须的。
  
  
-4MB闪存的设备只能存储LEDE固件镜像,故扩展性方面有着极大的限制。对于小闪存设备,你还是不要期望太多吧。 +在多数情况下,如果只有4MB的闪存,将无法安装这些(或其他)热门的软件包:
- +
-在多数情况下,如果只有4MB的闪存,将无法安装这些(或其他)热门的软件包:+
  
   * [[docs:guide-user:network:tunneling_interface_protocols|VPNs]] 以及其他需要加密的软件   * [[docs:guide-user:network:tunneling_interface_protocols|VPNs]] 以及其他需要加密的软件
Line 36: Line 35:
 ===== 支持性 ===== ===== 支持性 =====
  
-随着时间的发展,小内存和闪存设备将会越来越难得到支持。OpenWRT可能在未来结束对这些设备的支持。+随着时间的发展,小内存和闪存设备将会越来越难得到支持。OpenWrt近期可能无照会的情况下结束对这些设备的支持。
  
  
 ===== 建议 ===== ===== 建议 =====
  
-  * **对于用户**,无论他们知不知道他们想要什么但如果他们不知道他们需要什么,不知道怎么做的 -> 选择 8/64 +对于并没有什么使用经验的用户(即无法自行编译固件的用户),应当考虑: 
-  * **对于有经验的用户**,道自己想要什么知道需要什么,知道怎么做的 -> 如果适合话可以尝试 4/32 ;不适合就选择 8/64+**16/64 设备是绝对的底线**,有可能的话尽量选择128M内存的设备。  
 + 
 +用户应当知道这些小于16M储存、64M内存的设备在当前版本(17.x, 18.x)的OpenWrt下已经是不稳定的了,他们应当考虑到这些设备在未来有可能会收到安全更新、驱动和应用软件更新。OpenWrt团队并没有对任何设备出过继续支持保证,用户应当考虑到设备在停止支持后的安全问题。 
 + 
 +之前版本OpenWrt包含着一些已知的内核、无线驱动和应软件安全问题。OpenWrt团队不支持在任何条件下继续使用这些包含已安全问题的软件“这是我的路由”并不能成为这台路由器变为跳板和攻击设备而影响他人的理由。在多数情况下这些已知的安全问题将可能会被潜在[[https://​blog.talosintelligence.com/​2018/​05/​VPNFilter.html|黑客甚至是政府机构]]利用。
  
 ===== 由论坛用户slh所做的问题分析 ===== ===== 由论坛用户slh所做的问题分析 =====
-以下内容来自论坛用户 **slh** 的 [[https://forum.lede-project.org/t/should-lede-support-devices-with-only-4mb-flash/1018/71|这个主题帖]]。+以下内容来自论坛用户 **slh** 的 [[https://forum.openwrt.org/t/should-lede-support-devices-with-only-4mb-flash/1018/71|这个主题帖]]。
  
 首先,我并不是假装为LEDE团队发言,但是数字却可以让问题显而易见。 首先,我并不是假装为LEDE团队发言,但是数字却可以让问题显而易见。
  
-以论坛中 "[[https://forum.lede-project.org/t/solved-why-no-images-generated-for-default-d-link-dir-600a1/990| Why no images generated for default D-Link DIR-600A1?]]"这个帖为例,显然其他一些4MB闪存设备比这个特定的样品稍好一点,但趋势仍然是一致的。+以论坛中 "[[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?]]"这个帖为例,显然其他一些4MB闪存设备比这个特定的样品稍好一点,但趋势仍然是一致的。
 <code>D-Link DIR-600A1: <code>D-Link DIR-600A1:
 Backfire 10.03..............: 2293764 bytes Backfire 10.03..............: 2293764 bytes
Line 61: 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 81: 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