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 [2020/01/08 13:55] – [支持性] lujimmyzh:supported_devices:432_warning [2020/01/08 14:31] – [可用性问题] lujimmy
Line 7: Line 7:
 {{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 64: 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 84: 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