ALFA Network N2

This device is NOT RECOMMENDED for future use with OpenWrt due to low flash/ram.
DO NOT BUY DEVICES WITH 4MB FLASH / 32MB RAM if you intend to flash an up-to-date and secure OpenWrt version onto it! See 4/32 warning for details.

1) This device does not have sufficient resources (flash and/or RAM) to provide secure and reliable operation.
This means that even setting a password or changing simple network settings might not be possible any more, rendering the device effectively useless. See OpenWrt on 4/32 devices what you can do now.

2) OpenWrt support for this device has ended in 2022.
19.07.10 was the last official build for 4/32 devices.

Outdoor AP/CPE

Install OpenWrt (generic explanation)

FIXME Please add the installation procedure here for V2 and non-C devices.

The N2C-variation by default comes with a firmware that bugs out when attempting to upload a new firmware. This likely has something to do with the uploader being unable to extract kernel.image and rootfs.image to the filesystem root, where the upgrading script of this device looks for them. Working around this is fairly trivial, but somewhat risky - I have done four devices by this procedure, and none of them bricked, but there's no guarantee it might go awry for you. Double check every step you take. The only way to drop into the bootloader on these seems to be using the serial header, for which you have to open up the device. Only proceed if you're prepared to do this as a back-up plan.

Furthermore, given the hardware restrictions of this device, OpenWRT updates might be far and few between for this device, though I will look into what it takes to keeping the images up-to-date.

These instructions were written and executed on a (at the time) Debian Stable install running on the admin PC. Most commands should be similar in macos. On windows, it might be good to do this in the Ubuntu subsystem.

  1. Log on to the original admin interface. Factory default is, but mine were set to and onwards. Make that mental translation in case you see that IP further down these instructions. These instructions are written assuming you are willing and able to occasionally change the network settings of your workstation, depending on the context, given factory firmware default lives in the 192.168.2.x subnet, and OpenWRT default lives in the 192.168.1.x
  2. In the advanced settings of the factory web interface, disable telnet, enable ssh, and configure a password. You will only briefly be using this password so you can get away with 'hunter2'
  3. Download the firmware file specified in the above table.
  4. Unpack it and retrieve a file named pb9x-2.6.31-jffs2, and a file named vmlinux.gz.uImage
  5. Using the file command on vmlinux.gz.uImage, verify its a “u-boot legacy uImage”, and rename it to kernel.image (optional, but for my own sanity)
  6. Using the file command on pb9x-2.6.31-jffs2, verify its a “Squashfs filesystem”, and rename it to rootfs.image (optional, but for my own sanity)
  7. The built-in ssh server does not allow for modern crypto, neither is scp installed, so copying these files over is unwieldy, but doable:
    1. cat kernel.image | ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@ "cat > /tmp/kernel.image"
    2. cat rootfs.image | ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@ "cat > /tmp/rootfs.image"
  8. These snippets will pipe the images to stdin of the ssh client. The ssh client will be setup to allow for legacy crypto. When executing these commands, you will be asked for the root password, which has been set in the web interface. Both files will be piped into the /tmp directory, for this one is rw.
  9. Now log into your AP as root, like so:
    ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 root@
  10. Navigate to

    , like so:

    cd /usr/sbin
  11. For my own sanity, I like to check if both images are actually there using
    ls /tmp
  12. For my own continued sanity, I like to check '' for which block devices should take which image, like so:
  13. Check for the lines
    flashcp -v /kernel.image /dev/mtd3 > /dev/console


    flashcp -v /rootfs.image /dev/mtd2 > /dev/console

    - If these lines are present, you are rocking the same stock firmware I am and you can proceed with caution.

  14. Now run

    - it dinks out because we're using /tmp and pivot_root is not there, but it handily kills all most of the processes, which intuitively seems important. You might be able to skip this step, but I didn't, and judging from the contents of this script, it really can't do harm so long as there are no .image's in the filesystem root

  15. Now use
    ./flashcp -v /tmp/kernel.image /dev/mtd3

    to write the kernel image to the mtd3 block device. Writing the firmware will be done faster than erasing.

  16. Now use
    ./flashcp -v /tmp/rootfs.image /dev/mtd2

    to write the rootfs image to the mtd2 block device. This will take a bit longer than the kernel. Furthermore, it's going to verify to 100% and then yell at you with a 'Bus Error'. That's probably happening because it's dropping back into the shell and trying to execute code that isn't memory resident. I would've done more research but I needed some functional access points in a pinch.

  17. You are done. Unplug your AP.
  18. Drop out of the ssh session (It's broken, so if Ctrl-D doesn't work: strike Return - Tilde - Period - Return in that order)
  19. Switch your workstation over to an 192.168.1.x IP
  20. Start pinging - It could take a minute or two before it comes up, but when it does, you can
    ssh root@

    - set your


    and have blast with the web interface at


This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2024/02/12 08:58
  • by