|At a glance|
|Product||Ignition Design Labs Portal (Portal-PCW-110-COM) [Website]|
|Summary||AC2350 class router with Gigabit Ethernet ports and mesh capability. Supports DFS 5 GHz channels|
|Pros||• Supports three stream 2.4 GHz and four-stream 5 GHz client connection for good backhaul
• Supports all DFS channels allowed in region
• Supports storage sharing
|Cons||• Wired router throughput may be iffy for gigabit-grade services
• Storage sharing is very slow
• Features still a work in progress
Typical Price: $0 Buy From Amazon
The past few years have seen a number of upstarts hit the Wi-Fi scene, bringing new approaches to shake up the status quo. Ignition Design Labs (IDL) came out of stealth at CES 2016 to reveal technology aimed at enabling easier access to DFS channels. I covered the whys and wherefores on this in my CES 2016 wrapup, so won’t repeat it here. In addition to pursuing OEM deals with service providers and others, IDL decided to spread the word about its technology more broadly by fielding a consumer router.
IDL’s Portal started life as a traditional single point router. But its makers saw the Wi-Fi "mesh" handwriting on the wall and decided to incorporate that technology shortly before it started shipping late last year. So you can buy it as a single router ("ideal for most homes and apartments") or a two-pack ("best for very large homes"). Prices have come down on both and are currently at around $179 for one and $319 for two.
Portal comes in a comparatively large glossy white plastic box that sorta reminds me of a (really big) squashed jelly bean. Although it doesn’t scream Router! by bristling with antennas, it’s large enough to call attention to itself.
Portal and eero
There is only one light (the "O" in the portal logo) on the top uses colors and blinking to indicate status. When everything is okey-dokey, the "O" is lit with a subtle solid green.
Portal LED colors
All connections are on the rear as shown below. All the ports are Gigabit but the USB ports are 2.0. At least they can share an attached drive, unlike all other distributed Wi-Fi systems (DWS) to date. Both FAT and NTFS formatted drives are supported, but only the first partition for now. The bottom cover has plenty of cooling slots, but there are none on the top or sides. Despite this sub-optimal design, Portal’s top didn’t get noticeably warm. The bottom cover also has wall-mount slots that let you hang Potal so its connectors point toward the floor.
Portal rear panel
IDL didn’t play cute with Portal’s FCC internal photos, which allowed identification of all key components. The view below with the bottom cover removed shows why all the air vents are on the bottom cover. The top side of the board has RF cans, but no heatsinks.
The three larger antennas are for the 3×3 2.4 GHz radio; the four smaller are for the 4×4 5 GHz radio. This combination makes Portal an AC2350 / 2400 class router. There is also an eighth antenna that sits up near the logo beneath the top cover. This connects to the "secret sauce" module that I’ll describe shortly.
The next view shows the heatsink and RF can tops stripped away to show the 2.4 (right) and 5 GHz (left) radios.
Portal board – side 1
The empty connector between the two radios holds Portal’s "secret sauce" module (my term, not IDL’s). One of the photos in the FCC internal pictures file identifies this module as "2.4G/BT/BLE Module", but it’s much more than that. The composite photo below shows both sides of the board, which are packed with interesting goodies. In addition to a CSR8811 Bluetooth 4.1 SoC, it also holds the Qualcomm dual-band monitor radio and dedicated Qualcomm "SpectrumBoost" co-processor that enables Portal’s "zero-wait" DFS switching.
Portal board – side 2
This monitor radio, plus associated cloud intelligence, lets Portal switch quickly back to the same DFS channel it vacates if radar is detected. Other routers that support DFS and don’t have continuous monitoring must disconnect clients and listen for radar for a minute before resuming operation. The vacated channel must also be left unused for 30 minutes. Both requirements put a pretty big crimp in most routers’ ability to use DFS channels, which is why (plus the additional FCC certification process) most products don’t bother supporting DFS. Surprisingly, IDL doesn’t talk about this much on their website, instead touting its "FastLanes", which is IDL’s marketing term for all this.
The component summary below shows the key components for Portal, Luma and eero. The comparison makes for an interesting study in how the three companies approach the design of mesh-capable nodes. Although its radios handle both client connect and backhaul duties, Portal is the only DWS product with a client-facing 4×4 5 GHz radio. Portal says it supports MU-MIMO on that 5 GHz radio, but I didn’t check MU-MIMO operation. But since it’s Qualcomm-based, it should support MU-MIMO devices just fine.
|CPU||QCA9563 3×3 11bgn SoC (single-core)||Qualcomm IPQ4018 2×2 a/b/g/n/ac SoC (quad-core)||Qualcomm IPQ8062 @ 1 GHz (dual-core)|
|RAM||256 MB||256 MB||512 MB|
|Flash||48 MB||128 MB
|2.4 GHz Radio||– In QCA9563
– Skyworks SE2565T 2.4 GHz Hi-power Power Amp (x3)
|– In IPQ4018
– Skyworks RFX8425 2.4 GHz RF front end (x2)
|-QCA9982 2×2 MU-MIMO 802.11abgnac radio
– RFMD RFFM4204 2.4 GHz Front End (x2)
|5 GHz radio||– QCA9984
– Skyworks Sky85405-11 5 GHz power amp (x4)
|– In IPQ4018
– Skyworks SKY85716-11 5 GHz RF front end (x2)
|– QCA9982 2×2 MU-MIMO 802.11abgnac radio
– RFMD RFPA5522 5 GHz power amp (x4)
|Bluetooth||CSR8811 Bluetooth 4.1 Soc||CSR8510||CSR8811 Bluetooth 4.1 SoC|
|Monitor||– QCA9887 Dual-Band 1×1 MIMO 802.11ac/abgn WLAN SoC
– QCA4531 (2×2) IEEE 802.11b/g/n SoC
– 128 MB RAM
– 16 MB flash
Table 1: Component summary and comparison
Like most other DWS, Portal sets up with an Android or iOS app, using a Bluetooth connection. One thing I didn’t like was that the app forces you to enable your phone’s location services any time you use the app. IDL said this was to make sure Portal wasn’t being set up in a region it shouldn’t be in due to its DFS support. But since you can enable Portal’s web interface after initial setup and never have to deal with the app again, this strikes me as kind of silly.
On the positive side, IDL doesn’t require you to create an account with them to set up Portal, so has no way to tie any information communicated during setup or operation to you. Only channel load, location and diagnostic info goes up to Portal’s cloud; no useage history is sent.
The YouTube video below walks you through setting up the first Portal.
The next video describes adding the mesh node. I asked IDL if the Ethernet cable connection was required for mesh setup, since it’s not part of any other DWS product mesh setup. They said it was a belt-and-suspenders approach to cover some rare cases they found that prevented proper mesh setup. The app omitted (or I didn’t notice) the Ethernet cable connect step, so I actually was able to add a second portal without the cable.
When I realized my error, I tried to remove the second Portal to try again, but there is no way to do that. Long story short, I ended up using the "Remove as Admin" feature on the app Network Settings screen, deleting the app and using the reset button on both Portals to get everything back to factory-fresh mode to try again.
The app has a long way to go to equal the features and functions found in other DWS product apps, most notably Google WiFi’s. Tapping the Internet icon brings up only Portal’s WAN IP address. There is no way to run the usual internet speed test you find on other products. I’m also not sure why "Everything looks good" if the second portal is M.I.A. I unplugged it and did not receive notification that it was gone.
Portal app – Device settings
Tapping the Guest icon lets you add a Guest network and sometime in the future will also let you add another user. Tapping the Device icon brings up a screen with an icon for each connected device, but tapping the ? or device icon doesn’t bring up any further device information.
After setup, you’ll probably want to drive Portal using its web interface. To get there, tap the left hand Portal icon to bring up the Basic Device Settings screen and tap the Show Advanced Device Settings slider to expose the rest of the screen as shown below. The WebGUI Enabled slider is the control you want. Just tap it and you can then access the web interface at http://192.168.8.1 or http://myportalwifi.com. The Web GUI is also available via HTTPS, but you have to enter it explicitly, i.e. https://myportalwifi.com; it doesn’t auto-redirect.
Portal app – Device settings
If you scan your two-Portal network with Fing or a similar network discovery tool, you’ll find four Portal-related IP addresses. One is for each Portal and the other is for the monitor module in each Portal. Only the root Portal (the Internet-connected one) runs HTTP/S for GUI access. The others all run SSH with login credentials that were not obvious.
The screenshot below provides an overview of Portal’s features, which are a little more extensive than you get with most DWS products. Let me rant a bit about the frickin’ use of soft / pastel / low-contrast colors that seem to be de rigueur in interface design today. Maybe it’s my monitor or just my aging eyes, but the Bridge Mode switch on the LAN screen sure looks "greyed out" to me (it’s not). Same goes for other enables like Parental Control, Dynamic DNS and others.
Portal app – Device settings
I’m not going to go through the whole list, since the feature list is evolving. But a few things are worth noting:
- Bridge / AP mode is supported. So if you already have a router you’re happy with and just want Portal for Wi-Fi, you can do it
- Only one satellite / extension Portal can be added. Not very mesh-y.
- Ethernet backhaul is not supported. So while you have to use a cable to activate the second Portal, you can’t keep it connected that way.
- Per-band SSIDs are supported. Note you have to use the app to futz with anything SSID-related once you are in "Mesh mode". Same goes for setting Guest SSID.
- DHCP, Static, PPPoE and PPTP WAN connection types are supported. (L2TP will not be supported.)
- Can set DHCP address range and address reservations
- Single and port range forwarding (no triggered forwarding)
- Outbound service port and port range blocking
- DMZ support
- UPnP supported (disabled by default)
- Per-device internet access time control with one time period (Parental Control)
On the Wi-Fi side of things, of course the big news is all DFS channels are supported. IDL realizes not all devices support DFS channels, so they’ve provided three compatibility modes shown below. This came in handy, since the NETGEAR A6200 USB adapter I use for mesh tests wasn’t able to see the 5 GHz network, which initially came up on Channel 100. Switching to Mode C moved the radio to Channel 36 and all was well. This setting is available only in the app.
Portal app – Compatibility mode
In fact, once you add the second Portal and activate mesh mode, you can’t do anything with Wi-Fi settings in the web GUI. But even in the app, all you can do is enter the network password, set the SSID, and activate separate 2.4 and 5 GHz SSIDs. The app shows you the channels it’s using, but you can’t change them or any other Wi-Fi setting. Only WPA2/AES (no RADIUS) security is supported and WPS is not supported.
Band steering is supported using 802.11v and k for devices that support it and deauth and probe response witholding for devices that don’t. In other words, IDL has tried to make band steering work for both old and new devices. AP steering (aka fast roaming / load balancing) is not yet supported, but planned for a release coming at the end of next month (March 2017).
As for cloud dependence, Portal didn’t seem particularly tied to a cloud service for normal operation. I was able to run all our Wi-Fi and wired routing tests without having an active WAN connection. IDL told me Portal works just fine including DFS channel support without its cloud services. Portal’s cloud supports coordinating neighboring Portals to optimize channel selection for best bandwidth for all and supports DNS protection, alerts, web portal relay for app access and other miscellaneous services.
Router geeks will like the Portal information (sample file) and logging feature. The latter requires a flash or hard drive in the USB-2 slot. This log is encrypted and intended for customer support purposes in case IDL needs to dig deep in to a customer problem.
The gallery below walks you through a few more of Portal’s web GUI pages.
You can bypass Portal’s NAT router and just use it as an AP. Does that Bridge Mode switch look active to you?
Reserving DHCP addresses is easy.
You can choose among four services.
You can forward single ports or ranges, but can specify only the source port.
Outbound rules block single ports or port ranges.
MAC filters are easy to set.
Both FAT and NTFS volumes can be mounted, but only the first partition.
All you can do here is set per device time limits for internet access.
Portal is the only DWS product that supports storage sharing, albeit via USB 2.0 ports. I ran our router storage test process on Portal. Portal supports only the first partition on drives with multiple partitions, which is how my test drive is formatted. So I had to reformat the first partition to test both FAT32 and NTFS performance.
I’ll dispense with showing comparative charts for storage performance, since Portal came in dead last for write and read with both FAT32 and NTFS formatted drives. This should come as no surprise, given its relatively weak processor.
- FAT32 write: 11 MB/s
- FAT32 read: 7.9 MB/s
- NTFS write: 7.3 MB/s
- NTFS read: 6.3 MB/s
Portal runs fine without an internet connection, so I was able to run our Version 4 router performance tests on it with Portal-1.4.136_prod-1.2.115 firmware. Functional tests were not run because Portal doesn’t provide access to all the settings needed to put the router in the required standard test configuration.
Table 2 summarizes routing test results for Portal, Linksys Velop, Google Wifi and Luma. Portal’s wired routing capability is clearly the lowest of the group. I should note that the TCP retries recorded for each throughput test were very high, over 80,000 for the unidirectional tests and about double that for each direction for the bi-directional tests.
|Test Description||Portal||Linksys Velop||Google Wifi||Luma|
|WAN – LAN TCP (Mbps)||621||940||941||941|
|LAN – WAN TCP (Mbps)||789||941||941||941|
|Total Simultaneous TCP (Mbps)||704||1764||1539||1764|
Table 2: Routing performance comparison
The other performance "feature" worthy of note is the failure of the TCP connection test. Portal supported opening only around 1300 out of the 3000 connections in the test. All connections were opened in the UDP test, but none remained open long enough for the verification pass in the test.
In all, these results show Portal would probably have a difficult time keeping up with a Gigabit class internet connection. But it should do fine for most services it is likely to be connected to.
Portal is not Wi-Fi Certified. Like most other DWS products, Portal does not support Wi-Fi Protected Setup (WPS) and supports WPA2/AES PSK wireless encryption only.
I was able to run the V9 test process using Portal-1.4.136_prod-1.2.115 firmware without Portal connected to the internet. But because Portal provides no control over channel or bandwidth mode, I had to use Channel 1 and 36 instead of our standard 6 and 40. Portal defaulted to 20 MHz bandwidth in 2.4 GHz, which was fine for throughput vs. attenuation, but which resulted in lower throughput for the maximum wireless throughput test, where we set the 2.4 GHz radio to 40 MHz bandwidth.
Portal was centered on the test chamber turntable as shown in the photo below. Because of its low profile, I elevated Portal a bit on a plastic stand to ensure proper pickup from the high-gain chamber antennas. The 0° position had the router front facing the chamber antennas.
Portal in test chamber
Our new router classification separates DWS products for ranking, so I plotted Portal, Linksys Velop, NETGEAR Orbi and Google WiFi for comparison. Note again, Portal and Velop used channels 1 and 36; Orbi and Google WiFi used the standard 6 and 40.
Comparing average 2.4 GHz throughput for all measured points shows Portal not doing that well compared to competing products. Keep in mind that Portal is the only product in this comparison with a 3×3 2.4 GHz radio and 4×4 5 GHz radio. Because all are tested with a 2×2 client, the comparison is fair.
2.4 GHz Average Throughput comparison
Comparing average 5 GHz throughput for all measured points shows Portal doing much better, landing at the top of both down and uplink charts.
2.4 GHz Average Throughput comparison
The 2.4 GHz downlink profile shows the reason for Portal’s low 2.4 GHz average performance, with both lower throughput and earlier disconnection.
2.4 GHz Downlink Throughput vs. Attenuation
Portal is again lower for 2.4 GHz uplink than the NETGEAR and Google products, but this time beats Linksys Velop. Portal still disconnects relatively early, however.
2.4 GHz Uplink Throughput vs. Attenuation
5 GHz downlink shows Portal actually doing quite well, as its high average throughput results would indicate. Portal’s throughput runs above the other three products’ throughput most of the test range. It even stays connected one attenuation step longer than Velop.
5 GHz Downlink Throughput vs. Attenuation
5 GHz uplink reveals a pattern for Portal similar to Velop, with an initial sharp throughput dip, followed by recovery to a higher level. Portal’s dip is a bit steeper than Velop’s, but its recovery is much better. The net result is that Portal’s average throughput still beats the others’ in this group.
5 GHz Uplink Throughput vs. Attenuation
Distributed Wireless Performance
The second part of wireless testing used the open air test process I’ve been using with all DWS products. I’ve done away with the set of tests with the middle node in the "Hallway" location, placing the middle or second test node only in the Living Room location for better connection to the root node.
The downlink bar chart shows results for most DWS products tested to date. I’ve removed the entry level Amplifi because Ubiquiti seems to be focused on selling only the HD model. I’ve also removed the Edimax RE11 because it’s not a full DWS.
DWS throughput summary – downlink
Portal did pretty well in this test, if you discount the Living Room and Kitchen tests and focus on the Office and Kitchen Reconnect. The test client connected on 5 GHz in the Office location, then switched to 2.4 GHz when it roamed to the Living Room, as it often has with other products. Given the Portal’s rather weak 2.4 GHz performance, throughput was pretty low, although not as low as Velop’s. The test client stayed put on 2.4 GHz for the Kitchen test, with throughput dropping as you’d expect at longer distance. But when a reconnect was forced for the Kitchen – Reconnect test, the client moved to 5 GHz and throughput jumped up.
The same pattern can be seen in the Uplink test, although Portal’s throughput was better, as you’d expect from the throughput vs. attenuation plot.
DWS throughput summary – uplink
The reason for Portal’s superior "mesh" performance, which is second only to NETGEAR’s Orbi, is, of course, its 4×4 5 GHz backhaul. The plot below shows throughput measured via Ethernet connection to the living room node of each product. This shows the throughput available to be passed on to clients and / or backhaul to other nodes and it’s obvious more streams means higher throughput.
Orbi still maintains an edge over Portal with its dedicated 4×4 5 GHz backhaul radio, however, because Portal must share its 5 GHz radio between client connect and backhaul. No matter how much algorithmic magic Portal tries to apply to balancing backhaul and fronthaul, an additional radio always wins.
IDL didn’t set out to design a DWS when it created Portal. After all, the company’s main focus is its "zero wait" DFS technology that it’s trying (with some success) to get designed into service provider gateways and set top boxes. But with the "mesh" wave overtaking the consumer router business in the past year, the company was smart to pivot and make sure buyers considering a Portal buy could tick the "mesh" box on their shopping checklist.
But it turns out Portal’s AC2350 class design (3×3 N + 4×4 AC) is a good thing to have in a mesh node, since backhaul performance is key to overall system performance and you want to bring as many streams to bear as you can for high throughput. Portal is the only DWS in addition to NETGEAR’s Orbi to have 4×4 5 GHz backhaul. And even though it’s not dedicated and doesn’t quite equal Orbi’s in performance, Portal’s backhaul gave it a significant edge over the field of 2×2 DWS, including eero, Luma and Google WiFi, in our testing.
NETGEAR’s Orbi showed the value of high bandwidth backhaul to overall DWS performance and what a well designed two node (router + satellite) system can do vs. the three-pack designs that dominated the "mesh" Wi-Fi scene until Orbi appeared.
IDL needs to finish building out Portal’s feature set, support wired backhaul and allow at least one additional node to be added. Once that is done, Portal has the potential to be a lower-cost alternative to Orbi, with the key advantage of providing more 5 GHz channels for both client connection and interference-free backhaul.