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
toh:recommended_routers [2019/10/22 21:19] – [SoC? ARM? MIPS? What's All This?] jefftoh:recommended_routers [2023/11/09 22:17] – move wsm20 to the correct place knarrff
Line 4: Line 4:
  
 <WRAP center round important 60%> <WRAP center round important 60%>
-This page is very outdated.+The second half of this page (specific device recommendations) is very outdated.
  
 Users should consider multi-core, ARM-based (or x86_64/AMD64) devices for mid-range and higher applications. Users should consider multi-core, ARM-based (or x86_64/AMD64) devices for mid-range and higher applications.
Line 10: Line 10:
 Purchase of a device with less than 16 MB of flash or less than 128 MB or RAM is unwise at this time (2019). Purchase of a device with less than 16 MB of flash or less than 128 MB or RAM is unwise at this time (2019).
  
-A device with two, "ath10k" radios should have at least 256 MB of RAM. This eliminates the Asus RT-AC58U and similar.+A device with two, "ath10k" radios should have at least 256 MB of RAM. This eliminates the Asus RT-AC58U, RT-ACRH13, and similar.
 </WRAP> </WRAP>
  
Line 16: Line 16:
 Really specific per scenario but these are **__generic recommendations__** based upon what's considered "reasonable" in terms of reliability and performance. **Please note that the OpenWrt project itself does not endorse any hardware or manufacturer unless there's a public statement**, this is solely a list put together by **the community**. General recommendations are **__at least__** 16 Mbyte of flash and 128 Mbyte of RAM.  Really specific per scenario but these are **__generic recommendations__** based upon what's considered "reasonable" in terms of reliability and performance. **Please note that the OpenWrt project itself does not endorse any hardware or manufacturer unless there's a public statement**, this is solely a list put together by **the community**. General recommendations are **__at least__** 16 Mbyte of flash and 128 Mbyte of RAM. 
  
-Note that some manufacturers claim "32 mb flash" or the like -- this is 32 Mbits, or only 4 MBytes.+Note that some manufacturers claim "32 mb flash" or the like (small "b"-- this is 32 Mbits, or only 4 MBytes.
  
 Platforms that have less than 16 Mbyte of flash **will have** noticeable space constraints. Having less than 128 Mbyte of RAM also imposes limitations, basic network functionality may work however there are reports of **memory errors** while using opkg and luci among other services which may operate **unreliable or in worst case freeze the system**. Support for either 4 MB of flash or 32 MB of RAM has already been discontinued, due to the size of the Linux kernel and run-time footprint of the third-party software required for a basic, running OpenWrt system. One should expect that 64 MB RAM will be unsupportable in the near future, as well as support for 8 MB of flash. Platforms that have less than 16 Mbyte of flash **will have** noticeable space constraints. Having less than 128 Mbyte of RAM also imposes limitations, basic network functionality may work however there are reports of **memory errors** while using opkg and luci among other services which may operate **unreliable or in worst case freeze the system**. Support for either 4 MB of flash or 32 MB of RAM has already been discontinued, due to the size of the Linux kernel and run-time footprint of the third-party software required for a basic, running OpenWrt system. One should expect that 64 MB RAM will be unsupportable in the near future, as well as support for 8 MB of flash.
  
-A device with two, "ath10k" radios should have at least 256 MB of RAM for stable operation. This eliminates the Asus RT-AC58U and similar.+A device with two, "ath10k" radios should have at least 256 MB of RAM for stable operation. This [[https://forum.openwrt.org/t/asus-rt-ac58u-crashes-under-heavy-load-after-a-while/33008?u=jeff|eliminates the Asus RT-AC58U, RT-ACRH13]], and similar.
  
 For many opinions, see the OpenWrt Forum. For example [[https://forum.openwrt.org/search?q=favorite%20device|https://forum.openwrt.org/search?q=favorite%20device]] For many opinions, see the OpenWrt Forum. For example [[https://forum.openwrt.org/search?q=favorite%20device|https://forum.openwrt.org/search?q=favorite%20device]]
 +
 +==== Are "Snapshot" Devices Supported? ====
 +
 +Yes, devices are supported by OpenWrt "snapshots" until a formal release includes the device. 
 +
 +In many cases, a newer device (or one that has recently had OpenWrt ported to it) will only be available as a snapshot build for months (or even over a year) before a formal release includes it. Snapshot (or ''master'') builds and code are not necessarily "less stable" than "release" builds. In many cases the snapshot build will outperform a release build, or resolve issues found in the release builds. 
 +
 +The main challenge for many users with snapshot builds are that they don't come with LuCI (GUI) preinstalled, and many "special" packages a user wants to add generally need to be flashed when the ROM is downloaded and flashed. Getting LuCI up and running is easily resolved with an Internet connection, SSH client, and [[docs:guide-user:luci:luci.essentials|a couple of simple commands]].
 +
 +See further [[releases:snapshot|Development builds / snapshots]]
 +
  
 ===== SoC? ARM? MIPS? What's All This? ===== ===== SoC? ARM? MIPS? What's All This? =====
Line 30: Line 41:
 The Ethernet switch //usually// is limited only by the speed of its "phy", the portion that connects to an Ethernet cable. A device with a 100 Mbps phy will be limited to ~95 Mbps //throughput//. A 1000 Mbps phy is //not// a guarantee that the overall device can achieve gigabit rates. For most users working with a reputable manufacturer, it is sufficient to know that the switch and phys in the device were likely properly matched to the rest of device.  The Ethernet switch //usually// is limited only by the speed of its "phy", the portion that connects to an Ethernet cable. A device with a 100 Mbps phy will be limited to ~95 Mbps //throughput//. A 1000 Mbps phy is //not// a guarantee that the overall device can achieve gigabit rates. For most users working with a reputable manufacturer, it is sufficient to know that the switch and phys in the device were likely properly matched to the rest of device. 
  
-The next bottleneck is the connection between the switch and the CPU. This is, unfortunately, not visible to most end users. One point to remember is that often (2019) this is a single "[R]GMII" connection that is limited to 1 Gbps, raw, so bonding ports on the switch doesn't overcome this limitation. Some devices have two gigabit-rate internal links, which are sometimes configured for WAN and LAN.+The next bottleneck is the connection between the switch and the CPU. This is, unfortunately, not visible to most end users. One point to remember is that often (2019) this is a single "[R]GMII" connection ([reduced] [[wp>Media-independent_interface#Gigabit_media-independent_interface|gigabit media-independent interface]]) that is limited to 1 Gbps, raw, so bonding ports on the switch doesn't overcome this limitation. Some devices have two gigabit-rate internal links, which are sometimes configured for WAN and LAN.
  
-The CPU, in most devices, needs to handle the packet flow, including firewall, connection tracking, and NAT. It also needs to handle every packet for SQM, as well as other tasks, such as DNS, DHCP, VPN, logging, time keeping, ...,  as well as any "unnecessary" functions such as GUI or end-user firmware. For most all-in-one routers, this is a primary bottle neck. As Internet speeds have increased, the ability to do this "effortlessly" with a cheap, single-core CPU has been stressed. A multi-core CPU lets one work with the traffic, while another can handle the other moment-to-moment demands. With the computational loads of a VPN, a multi-core CPU becomes even more attractive.  +The CPU, in most devices, needs to handle the packet flow, including firewall, connection tracking, and NAT. It also needs to handle every packet for SQM (smart queue management), as well as other tasks, such as DNS, DHCP, VPN, logging, time keeping, ...,  as well as any "unnecessary" functions such as GUI or end-user firmware. For most all-in-one routers, this is a primary bottleneck. As Internet speeds have increased, the ability to do this "effortlessly" with a cheap, single-core CPU has been stressed. A multi-core CPU lets one work with the traffic, while another can handle the other moment-to-moment demands. With the computational loads of a VPN, a multi-core CPU becomes even more attractive.  
  
 Because there are tasks other than just routing the traffic, the throughput doesn't scale directly with CPU speed. For example, going from 500 MHz to 750 MHz clock with the same CPU core is going to be //less// than 50% faster, often a lot less. Because there are tasks other than just routing the traffic, the throughput doesn't scale directly with CPU speed. For example, going from 500 MHz to 750 MHz clock with the same CPU core is going to be //less// than 50% faster, often a lot less.
Line 43: Line 54:
  
 Solid design, basic performance levels. Generally single-core devices. Good "budget" or "travel router" choice, as long as with at least 16 MB of flash and 128 MB or RAM. Solid design, basic performance levels. Generally single-core devices. Good "budget" or "travel router" choice, as long as with at least 16 MB of flash and 128 MB or RAM.
 +
 +Mid-range, MIPS-based SoCs clock around 600 MHz in 2019. Many higher-performance devices clock around 750-775 MHz. MIPS-based SoCs clocked at 500 MHz or below are likely poor choices for purchase at this time.
  
 Common OpenWrt "targets" include: Common OpenWrt "targets" include:
   * ar71xx (deprecated, ath79 current)   * ar71xx (deprecated, ath79 current)
-  * ath79 +  * ath79 (QCA wireless) 
-  * ramips +  * ramips (MTK wireless) 
-  * lantiq+  * lantiq (QCA or MTK wireless)
  
 +FIXME: Discussion of "unique" MT7621; single/dual-core boards (and any clue as if there is an identifiable, SoC variant), mention of hardware flow-offload (MT7621A for integral switch), including its drawbacks.
 ==== ARM ==== ==== ARM ====
  
Line 60: Line 74:
  
 Common OpenWrt "targets" include: Common OpenWrt "targets" include:
-  * mvebu +  * mvebu (Marvell wireless) 
-  * ipq806x +  * ipq806x (QCA wireless) 
-  * ipq40xx+  * ipq40xx (QCA wireless) 
 +  * mediatek (MTK wireless)
  
 The mvebu units tend to be the highest performance. The ipq40xx units tend to be available at lower price points. The mvebu units tend to be the highest performance. The ipq40xx units tend to be available at lower price points.
Line 70: Line 85:
 ==== x86_64/AMD64 ==== ==== x86_64/AMD64 ====
  
-For those desiring "true" gigabit throughput or high-speed VPN, a low-powerx86_64/AMD64 SBC or ITX with AES-NI and dual NICs is an option. With proper component selection, such devices can actually consume //less// power than a high-end, all-in-one router, even when paired with a suitable AP for wireless.+For those desiring "true" gigabit throughput or high-speed VPN, a low-power x86_64/AMD64 SBC (single-board computer) or an ITX board ([[wp>Mini-ITX|Information Technology eXtended]], a small motherboard form-factor) with AES-NI (Intel's [[wp>AES_instruction_set#x86_architecture_processors|Advanced Encryption Standard New Instructions]]) and dual NICs is an option. With proper component selection, such devices can actually consume //less// power than a high-end, all-in-one router, even when paired with a suitable AP for wireless.
  
 ==== Wireless ==== ==== Wireless ====
  
-Wireless tends to be supplied by the SoC's designer+**//Virtually no 802.11 link between a consumer AP and phone, laptop, or desktop in the real world can reliably support gigabit throughput.//**
  
-//Virtually no 802.11 link between a consumer AP and phonelaptopor desktop in the real world can reliably support gigabit throughput.//+Wireless tends to be supplied by the SoC's designerAlmost always the wireless components are part of the SoC and, if they use a second chip setare from the same vendor. 
 + 
 +In addition to the chips themselves, there are "invisible" components that make a big difference in wireless performance, such as power amplifiers, receiver "chains", and antennas.  
 + 
 +You can't judge the performance of an antenna by its looks. Big, fat antennas generally aren't any better than skinny ones. Well-executed patch antennas or internal antennas can be every bit as good as impressive-looking external antennasFor a variety of reasons, using external antennas on feed lines is often a net loss (exceptions being for professional-quality antennas and feed lines for point-to-point links, which often cost more than a high-end router for just one).  
 + 
 +=== QCA Wireless === 
 + 
 +The Atheros or Qualcomm Atheros ([[wp>Qualcomm_Atheros|QCA Wireless]]) SoCs and chip sets are common, have long-established open-source support with both the upstream (Linux) ath-series drivers and firmware, as well as the ath10k-CT ([[https://www.candelatech.com/ath10k.php|Candella Technologies]]) drivers, currently "default" with OpenWrt (v19). Support for advanced features such as IBSS and 802.11s tends to be good with the recent chip sets under both the upstream drivers, as well as the ath10k-CT drivers. 
 + 
 +older "Wave 1" devices, such as the Archer C7v2, may need to use the non-CT drivers for 802.11s support.  
 + 
 +"ath9k" devices are not "better" or "worse" than "ath10k" devices. 
 + 
 +=== MTK Wireless ===
  
-The Atheros or Qualcomm Atheros (QCA) SoCs and chip sets are common, have long-established open-source support with both the upstream (Linux) ath-series drivers and firmware, as well as the ath10k-CT ([[https://www.candelatech.com/ath10k.php|Candella Technologies]]) drivers, currently "default" with OpenWrt (v19). Support for advanced features such as IBSS and 802.11s tends to be good with the recent chip sets under both the upstream drivers, as well as the ath10k-CT drivers. "ath9k" devices are not "better" or "worse" than "ath10k" devices. 
  
 FIXME: Help describing MTK drivers FIXME: Help describing MTK drivers
 +
 +=== Marvell Wireless ===
 +
  
 FIXME: Help describing Marvell drivers - please note issues with IBSS and 802.11s FIXME: Help describing Marvell drivers - please note issues with IBSS and 802.11s
 +
 +=== Broadcom Wireless ===
 +
  
 FIXME: Which Broadcom wireless chips have meaningful support? FIXME: Which Broadcom wireless chips have meaningful support?
  
-Broadcom wireless is generally problematic, as Broadcom's support for open-source development is very limited.+Broadcom wireless is generally problematic, as Broadcom's support for open-source development is very limited. 
  
 {{section>meta:infobox:broadcom_wifi#infobox_for_tohs&noheader&nofooter&noeditbutton}}  {{section>meta:infobox:broadcom_wifi#infobox_for_tohs&noheader&nofooter&noeditbutton}} 
  
 +See [[https://wireless.wiki.kernel.org/en/users/drivers/brcm80211|https://wireless.wiki.kernel.org/en/users/drivers/brcm80211]] for more details on specific chips and their level of support.
  
 ===== Dual-Firmware Devices ===== ===== Dual-Firmware Devices =====
Line 96: Line 131:
    
  
 +===== Flow Offload (and OEM Throughput) =====
  
-===== Older content (2016?) follows below ===== 
  
 +**//Remember that if you want to use SQM (Smart Queue Management) or similar, hardware flow offloading can't be used.//**
  
 +As discussed above, quite a bit of CPU resources are consumed doing routing and NAT functions. Since router-SoC manufacturers know that device reviewers will measure the throughput of the device under well-known conditions, they often include specialized hardware into the SoC to be able to "offload" basic routing and NAT from the CPU itself. This is a cost-effective way to get "better" numbers and "marketing bullets" for those that use their SoCs ("Full, gigabit routing" or the like). 
  
 +This specialized hardware often requires closed-source drivers and/or proprietary information from the SoC manufacturer to utilize robustly. As a result, //hardware// offload to the switch, or to things like NSS cores in the IPQ806x devices, is generally not supported with open-source firmware. This is often the reason why //any// third-party firmware doesn't match the LAN <=> WAN, NAT-only throughput of OEM firmware.
 +
 +However, if you use SQM (bandwidth shaping, "bufferbloat" mitigation) or similar functionality, you generally can't use hardware flow offloading, but software flow offloading [[https://forum.openwrt.org/t/software-flow-offloading-implications/90957|seems to work]]. Functions like SQM require each packet to be handled by the the CPU, so the various hardware "shortcuts" can't be used. Even with high-bandwidth connections, SQM can greatly reduce "lag", improve responsiveness of Internet browsing, and make VOIP and video calls smoother. OEM firmware generally doesn't support SQM, so no direct comparison is possible. 
 +
 +Flow offload generally does not improve VPN performance significantly as the limitations there come primarily from the CPU and its ability to encrypt/decrypt the packets and move them between interfaces.
 +
 +OpenWrt officially supports software flow offload on several SoCs, which can greatly speed "NAT-only" configurations. At this time (2019), the MT7621A is the only device on which OpenWrt supports //hardware// offload. 
 +
 +
 +----
 +
 +
 +===== Older content (2016?) follows below =====
 +
 +<WRAP center round important 60%>
 +**Many devices listed below are outdated and no longer recommended (2019)**
 +</WRAP>
  
  
Line 148: Line 202:
 filter  : Model=TL-WDR4300 filter  : Model=TL-WDR4300
 ---- ----
-**US lockdown notes goes here**+**US lockdown notes go here**
  
   * **QCA95XX** are the latest family of MIPS based SoCs by QCA and provide a slight boost in performance (~10-15%) compared to the AR934*-series because of the higher clock frequency. These systems are usually shipped with ath10k radios which supports 11ac however these drivers need to rely more on the firmware blob which makes improving the driver hard. Wifi performance peaks at about 400mbit depending on conditions.   * **QCA95XX** are the latest family of MIPS based SoCs by QCA and provide a slight boost in performance (~10-15%) compared to the AR934*-series because of the higher clock frequency. These systems are usually shipped with ath10k radios which supports 11ac however these drivers need to rely more on the firmware blob which makes improving the driver hard. Wifi performance peaks at about 400mbit depending on conditions.
Line 158: Line 212:
 filter  : Versions=v2 filter  : Versions=v2
 ---- ----
-**US lockdown notes goes here**+**US lockdown notes go here**
  
 ---- datatable ---- ---- datatable ----
Line 172: Line 226:
  
 A quite well supported platform, it has 2 cores and 2 threads (somewhat similar to Hyperthreading on x86) along with a more powerful core (MIPS 1004Kc) which makes this SoC about about twice as fast as the AR934X-series (depending on application). These are typically shipped with 11ac hardware and the driver (mt76) works fairly well, it's still under development but is more open than the ath10k driver making it a more interesting choice for the Open Source community. Generic throughput numbers are about 400-500mbit/s (LAN-WAN without PPPoE) and ~45mbyte/s using the USB3 interface. It's also worth noting that products using this SoC are usually cheaper or priced about the same as the Atheros 11n and 11ac counterparts but might be hard to come by. \\ A quite well supported platform, it has 2 cores and 2 threads (somewhat similar to Hyperthreading on x86) along with a more powerful core (MIPS 1004Kc) which makes this SoC about about twice as fast as the AR934X-series (depending on application). These are typically shipped with 11ac hardware and the driver (mt76) works fairly well, it's still under development but is more open than the ath10k driver making it a more interesting choice for the Open Source community. Generic throughput numbers are about 400-500mbit/s (LAN-WAN without PPPoE) and ~45mbyte/s using the USB3 interface. It's also worth noting that products using this SoC are usually cheaper or priced about the same as the Atheros 11n and 11ac counterparts but might be hard to come by. \\
- 
-:!: As of writing there's **no working** VLAN support in the switch for this SoC. \\ 
-:!: Currently, it may have stability issues if you are using more than one wireless network (wifi-iface) for each radio (wifi-device) 
  
 ---- datatable ---- ---- datatable ----
-cols    : Brand, Model, Versions, Platform, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet Gbit ports_, Modem, USB ports_, Device Page_page +cols    : Brand, Model, Versions, Supported Current Rel, CPU, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet Gbit ports_, Modem, USB ports_, Device Page_page 
-header  : Brand, Model, Version,SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB, Device Page+header  : Brand, Model, Version, Current Release, SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB, Device Page
 align   : c,c,c,c,c,c,c,c,c,c,c,c,c align   : c,c,c,c,c,c,c,c,c,c,c,c,c
 filter  : Model=DIR-860L filter  : Model=DIR-860L
 ---- ----
 ---- datatable ---- ---- datatable ----
-cols    : Brand, Model, Versions, Platform, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet Gbit ports_, Modem, USB ports_, Device Page_page +cols    : Brand, Model, Versions, Supported Current Rel, CPU, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet Gbit ports_, Modem, USB ports_, Device Page_page 
-header  : Brand, Model, Version,SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB, Device Page+header  : Brand, Model, Version, Current Release, SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB, Device Page
 align   : c,c,c,c,c,c,c,c,c,c,c,c,c align   : c,c,c,c,c,c,c,c,c,c,c,c,c
-filter  : Model=WF-2881+filter  : Model=WF2881 
 +---- 
 +---- datatable ---- 
 +cols    : Brand, Model, Versions, Supported Current Rel, CPU, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet 1Gbit ports_, Modem, USB ports_, Device Page_page 
 +headers : Brand, Model, Version, Current Release, SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB 
 +align   : c,c,c,c,c,c,
 +filter  : Brand=ZyXEL 
 +filter  : Model=WSM20
 ---- ----
  
Line 199: Line 257:
 === Marvell Armada 385 aka 88F6820 === === Marvell Armada 385 aka 88F6820 ===
  
-This is a relatively new platform based on ARM compared to the other ones here that are MIPS based. It offers the best performance but is also in general the most expensive one. It offers 2 cores running at 1.6Ghz and does linespeed NAT. It's usually coupled with wifi using the mwlwifi driver which is considered unstable for now and may crash the system occationally. Wired performance and stability is good(?), USB (status?), SATA (status?) however. As of writing there are no known user friendly products available that OpenWrt supports, serial access is needed for recovery and stability isn't (yet) up the standard of the other platforms.+This is a relatively new platform based on ARM compared to the other ones here that are MIPS based. It offers the best performance but is also in general the most expensive one. It offers 2 cores running at 1.6Ghz and does linespeed NAT. It's usually coupled with wifi using the mwlwifi driver which is considered unstable for now and may crash the system occasionally. Wired performance and stability is good(?), USB (status?), SATA (status?) however. As of writing there are no known user friendly products available that OpenWrt supports, serial access is needed for recovery and stability isn't (yet) up the standard of the other platforms.
  
 === MediaTek MT7620A === === MediaTek MT7620A ===
Line 207: Line 265:
 Below are some models reported stable. Below are some models reported stable.
 ---- datatable ---- ---- datatable ----
-cols    : Brand, Model, Versions, Platform, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet Gbit ports_, Modem, USB ports_, Device Page_page +cols    : Brand, Model, Versions, Supported Current Rel, CPU, CPU MHz, Flash MB_mbflashs, RAM MB_mbram, WLAN Hardware, WLAN 2.4Ghz, WLAN 5.0Ghz, Ethernet 1Gbit ports_, Modem, USB ports_, Device Page_page 
-header  : Brand, Model, Version,SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB, Device Page+header  : Brand, Model, Version,Current Release, SoC,CPU MHz,Flash MB,RAM MB,WLAN Hardware,WLAN2.4,WLAN5.0,Gbit ports,Modem,USB
 align   : c,c,c,c,c,c,c,c,c,c,c,c,c align   : c,c,c,c,c,c,c,c,c,c,c,c,c
 filter  : Brand=Lenovo filter  : Brand=Lenovo
 filter  : Model*~Y1 filter  : Model*~Y1
 ---- ----
 +
 **Needs confirmation:** Buffalo WHR-1166D seems to be suitable? **Needs confirmation:** Buffalo WHR-1166D seems to be suitable?
  
  • Last modified: 2024/02/11 21:58
  • by 127.0.0.1