[REPORT] OpenWrt on (rebranded) Lanner NCA-1515

Hardware Questions and Recommendations
1

Well, eBay continues to deliver… :zany_face:

Last week, I acquired a Lanner NCA-1515 (rebranded as Kerio NG310) for an all-in cost of USD 45. (When I saw it listed, I rubbed my eyes so hard I almost went blind.) Anyway, here’s a port diagram produced by Kerio:

image
image1599×543 89.8 KB

A little background: Kerio was acquired by GFI in 2017. After the acquisition, GFI began to phase out Kerio’s appliances in favor of a software solution to be run on customer hardware. The NG310 is a member of the last generation of Kerio appliances; it is still in support, but expected to go end-of-life in 2027. (All other Kerio models I have seen are also rebranded Lanner devices; the range starts from the tiny three-port NCA-1010 and goes up to the FW-7000-something rack-mountable.)

On the system board and in POST messages, the device identifies itself as NCB-1515, but I was unable to find any mention of NCB-1515 on Lanner’s Web site, so I will continue to refer to it as NCA-1515. (I suspect that NCB-1515 is the designation of the device’s system board, while NCA-1515 is the complete device.)

NCA-1515 is a highly configurable model. It can be equipped with one of many Atom C3xxx processors (core count from two to 16). The NG310 implementation runs on a quad-core Atom C3558 (2.20 GHz) with a single 8 GB DDR4 ECC memory module. Storage consists of an 8 GB onboard eMMC module and a 2.5” SATA SSD.

Here’s a view of the internals with SATA drive tray removed and a SATA m.2 2242 drive (more on that below) installed:

image
image1376×1033 512 KB

Networking consists of four Intel i350 controllers (two SFP and two RJ-45, arranged in 2x2 matrix) and four Intel x553 (RJ-45, arranged in a single row). The order of port detection by OpenWrt matches the order of on-device numbering (LAN1 is eth0, LAN2 is eth1, and so on; the port labeled INTERNET is eth7). In this implementation, thankfully, there are no bypasses (if you encounter bypasses on a different implementation, see my earlier post for information on how to deal with them). There seems to be a watchdog, which is disabled by default (but if not, it’s controlled from BIOS and can be disabled there).

Out of the box, the device is set for legacy boot mode. That can sometimes be problematic; the device would ignore the choice of the boot drive and boot from the onboard eMMC, which is where the core of the stock OS resides. To work around this, I set the device to boot in UEFI mode, expanded an EFI OpenWrt image onto the boot drive using my computer, and planted the boot drive into the device. This tactic worked with both ext4/EFI and squashfs/EFI images, using a 2.5” SATA drive (I made sure to use a non-stock drive, to test whether the device is locked onto the stock SSD) or an m.2 2242 SATA drive. Note that there are two mSATA slots, but both appear to be for networking devices (in some implementations, NCA-1515 comes with both Wi-Fi and cellular networking).

In conclusion, props to Lanner for the job well done.

2

Got one off ebay mid Dec, paid $43, guess prices are coming down.

3

It just occurred to me that I never explicitly stated that BIOS is unlocked.

Also, after I made the initial post, I decided to replace the squashfs-legacy firmware that I installed on the device’s onboard eMMC storage device (and it never ran right) with the squashfs-EFI version (and keep the device’s boot mode setting at UEFI). This instantly healed the “device is trying to boot the stock OS” problem. Here’s some system information from this iteration:

BusyBox v1.36.1 (2026-01-19 00:20:16 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 24.10.5, r29087-d9c5716d1d
 -----------------------------------------------------
root@NCA1515:~# ubus call system board
{
        "kernel": "6.6.119",
        "hostname": "NCA1515",
        "system": "Intel(R) Atom(TM) CPU C3558 @ 2.20GHz",
        "model": "Default string Default string",
        "board_name": "default-string-default-string",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "24.10.5",
                "revision": "r29087-d9c5716d1d",
                "target": "x86/64",
                "description": "OpenWrt 24.10.5 r29087-d9c5716d1d",
                "builddate": "1766005702"
        }
}
root@NCA1515:~# lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0           7:0    0  7.3G  0 loop /overlay
mmcblk0       179:0    0  7.3G  0 disk
├─mmcblk0p1   179:1    0   16M  0 part /boot
│                                      /boot
├─mmcblk0p2   179:2    0  7.3G  0 part /rom
└─mmcblk0p128 259:0    0  239K  0 part
mmcblk0boot0  179:8    0    4M  1 disk
mmcblk0boot1  179:16   0    4M  1 disk
root@NCA1515:~#

Note the two devices at the end of the lsblk output, mmcblk0boot0 and mmcblk0boot1. Those appear to be read-only devices that hold two copies of bootloader, which is probably what caused the problem in the first place. Looks like once the device was switched to the UEFI mode, the BIOS stopped noticing them as candidates for boot drives…

1 Like