OpenWrt Forum Archive

Topic: Ubiquiti Nanobeam OpenWrt support

The content of this topic has been archived on 2 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Did anybody get their hands on Ubiquiti Nanobeam equipment? Nanobeam is very similar to Nanobridge but it has improved radio and antenna design, and faster cpu.

Guys on the Ubiquiti forums are really stoked about how great they work:
http://community.ubnt.com/t5/Installati … d-p/687967

If anybody has started working on supporting OpenWrt on these devices please let me know and if I can help in any way.

(Last edited by valentt on 3 Mar 2014, 14:07)

I was wondering the exact same thing!

It would be awesome if we could get OpenWRT support on them NanoBeams

We just ordered one piece for testing, will keep you updated!

www.unwired.at

Any news?

I was able to open the device and access the serial port.
This is the output of the bootloader:

U-Boot 1.1.4-s751 (Aug 21 2013 - 12:06:27)

Board: Ubiquiti Networks AR9342 board (e4e5-24.1122.0030)
Reset: Normal
DRAM:  64 MB
Flash:  8 MB (0xc2, 0x20, 0x17)
Net:   AR8035
eth0
Radio: 0777:e4e5
Hit any key to stop autoboot:  0 
## Booting image at 9f050000 ...
   Image Name:   MIPS Ubiquiti Linux-2.6.32.60
   Created:      2013-08-30  13:24:09 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1000716 Bytes = 977.3 kB
   Load Address: 80002000
   Entry Point:  80002000
   Verifying Checksum at 0x9f050040 ...OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

Booting Atheros AR934x

From there on the screen stays blank.
Where to go from here?

Best, G.

Is there any network traffic at that point? You'll probably have to set your card to promiscuous and sniff all UDP traffic. Either way it looks like it may have console redirection set up.

Hi,

qasdfdsaq wrote:

Is there any network traffic at that point? You'll probably have to set your card to promiscuous and sniff all UDP traffic. Either way it looks like it may have console redirection set up.

this is still with the original firmware, which of course boots and i can also login via ssh.

Next i tried to flash UAP-Pro image since this UBNT device also has AR9342 chipset. But the bootloader complains:

Setting default IP 192.168.1.20
Starting TFTP server...
Using eth0 (192.168.1.20), address: 0x81000000
Will reset device configuration (Reset button active after 10 seconds).
find_mtd_part
Clearing partition 'cfg':
        erasing range 0x9F7B0000..0x9F7EFFFF: .... done
Erased 4 sectors
Waiting for connection: /
Receiving file from 192.168.1.19:49531
Received 7274844 bytes
Firmware Version: BZ.ar934x.v6.0.0-OpenWrt-r40422
Setting U-Boot environment variables
Un-Protected 1 sectors
Erasing Flash.... done
Erased 1 sectors
Writing to Flash... write addr: 9f040000
done
Protected 1 sectors
Warning: partition jffs2 not found on flash memory! Skipped.

Firmware update complete.

Resetting...

After this the device reboots with the original firmware still on it.

This is the flash layout according to u-boot:

ar7240> mtdparts

device nor0 <ath-nor0>, # parts = 6
 #: name                        size            offset          mask_flags
 0: u-boot                      0x00040000      0x00000000      0
 1: u-boot-env                  0x00010000      0x00040000      0
 2: kernel                      0x00100000      0x00050000      0
 3: rootfs                      0x00660000      0x00150000      0
 4: cfg                         0x00040000      0x007b0000      0
 5: EEPROM                      0x00010000      0x007f0000      0

active partition: nor0,0 - (u-boot) 0x00040000 @ 0x00000000

defaults:
mtdids  : nor0=ath-nor0
mtdparts: mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM)

Currently i´m looking around in my buildroot to find the correct place to put necessary information, any help is appriciated.

Best, G.

Edit: and that´s why the UAP Pro Image doesn´t fit:

BZ.v3.1.6# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00f60000 00010000 "jffs2"
mtd3: 00040000 00010000 "cfg"
mtd4: 00010000 00010000 "EEPROM" 

So the NanoBeam uses the same mtd Layout as other AirOS devices, but with the new SoC like the UAP Pro...

(Last edited by glahue on 15 Jun 2014, 13:17)

There is an open ticket here: https://dev.openwrt.org/ticket/16796

And there are few devices on Wiki that have AR9342, so support is not impossible to do. What needs to be done?

Question: how is the cap retained? Clips or is it glued ? Did you manage to get it open without damaging the case?

I've got my hands on an M5 NanoBeam at the moment that I was looking to pop open (trying not to damage the case if it can be avoided.

I figure any firmware has to have the right magic bit (XW) to be loaded by the boot loader.

if these are like the other Ubiquiti devices
I belive you could TFTP a kernel image over and run from there for testing, if not should be able to build an image with the XW magic bit to get a starter OS loaded .  From there device specific testing (LED gpio's for one) can be figured and a profile made into kernel and then toolchain.

Hi,

cmlara wrote:

Question: how is the cap retained? Clips or is it glued ? Did you manage to get it open without damaging the case?

I've got my hands on an M5 NanoBeam at the moment that I was looking to pop open (trying not to damage the case if it can be avoided.

I figure any firmware has to have the right magic bit (XW) to be loaded by the boot loader.

if these are like the other Ubiquiti devices
I belive you could TFTP a kernel image over and run from there for testing, if not should be able to build an image with the XW magic bit to get a starter OS loaded .  From there device specific testing (LED gpio's for one) can be figured and a profile made into kernel and then toolchain.

the cap is glued. If you are very careful you can remove it with a blade without *totally* damaging it, but you might need some extra work to get the parts flat again to be able to glue them together again.
As you can see from my post above, the magic bit is not the problem, but the flash layout.

valentt wrote:

There is an open ticket here: https://dev.openwrt.org/ticket/16796

And there are few devices on Wiki that have AR9342, so support is not impossible to do. What needs to be done?

I know, this ticket is by me ;-)
And i also wrote what needs to be done: A new device has to be created in the toolchain with the correct flash layout. Sadly i don´t know where all the bits are that need consideration inside the toolchain.

Best, Gregor

Thank you for the feedback on the cap.

As for your question of MTD layout I would start with target/linux/ar71xx/image/Makefile

This is the file that (to my knowledge) controls the image generations including mtd layouts. Magic bit, binary formatting, and kernel parameter command line rewriting is also in this file.

https://dev.openwrt.org/browser/trunk/t … e/Makefile

I still suspect some kernel code will be needed too (I've see a file in past but can't  recall where, I will look in the morning, related to the other UBNT devices  ).  This is partly why the board= parameter is added to the kernel line  if I read the code correctly before.

Ubiquiti has renamed NanoBeam line to PowerBeam line and added few new devices, most powerful model is PBE-5AC-500, radio chip is 801.11ac and antenna is 27dBi.

Is there any progress?

I'am able to run openwrt-ar71xx-generic-ubnt-nano-m-xw-initramfs-uImage.bin from today trrunk on nanobeam m2 400 through tftp.

With default config for network with 2 interfaces I see on my side traffic with 802.1q tags 1 and 2. Switch config seems not work, "switchcfg list" shows nothing. Is there switch on this device or only network card?

I think mtd layout is the same as in other ubnt, just kernel not separated from rootfs partition.
But if I flash openwrt-ar71xx-generic-ubnt-nano-m-xw-squashfs-factory.bin it can't mount root on 31,8.
I notice that in original firmware mtd on ath-nor0, in openwrt trunk for this target it's spi0. I tried modify mentioned early Makefile to boot from ath-nor0, but no success.

Unfortunately I have to cut down a cap with a hacksaw and I don't understand how it can be opened with blade, I think plastic is soldered at the factory.

(Last edited by vova on 12 Aug 2014, 18:57)

I haven't had time to test yet,  I've had a few other items come up first.

I gave up on trying to open and just went for the dremel.  The bottom and top  would be the hardest to open (this is where a couple of slip tabs appear to be) as you can't actually slide all the way under.  The sides may have better luck but I went for the dremel.

If you dremel it straight off (watch your depth I knicked the reflector) if you take it smoothly you can get a good fit back later and just add a bit of sealent if you want to reuse it.

ath-nor0 vs spi0 shouldn't matter as I recall its just a name, all the UBNT I have seen use ath-nor0 in the stock UBNT build but the OpenWRT builds call it spi0 instead.

It is a single port device, I don't recall seeing a switch module when I opened it (unless its inside the SOC which I doubt)


The NanoStation is a dual port device so it makes sense it has a switch I don't expect one on the NanoBeam.

I'm away from my device for the week so I can't look until Saturday but I suspect it would only be small tweaks to the patch already sent.

With spi0 it finally works, but rootfs not on 31:8, I temporarly modified /target/linux/ar71xx/generic/config-default for root=31:04 and it's work.

Wifi works too, but I need tagged traffic through wlan0.
I tried  it with ip link and vconfig:

vconfig add wlan0 97
OR
ip link add link wlan0 wlan0.97 type vlan proto 802.1q id 97

ifconfig wlan0.97 up
brctl addif br-lan3 wlan0.97

AP not see tagged Client traffic
24:A4:3C:FA:80:31 - Client
24:a4:3c:fb:80:3e - AP

Client sends ARP (tcpdump -n -i wlan0):
06:10:58.046528 24:a4:3c:fb:80:31 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 97, p 0, ethertype ARP, Request who-has 192.168.2.1 tell 192.168.2.2, length 28
But AP not see it, rx counter on wlan0 not increased, tcpdump not see anything, firewall disabled.

But Client sees AP tagged traffic:
12:57:01.536914 24:a4:3c:fb:80:3e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 97, p 0, ethertype ARP, Request who-has 192.168.2.2 tell 192.168.2.1, length 28
12:57:01.537044 24:a4:3c:fb:80:31 > 24:a4:3c:fb:80:3e, ethertype 802.1Q (0x8100), length 46: vlan 97, p 0, ethertype ARP, Reply 192.168.2.2 is-at 24:a4:3c:fb:80:31, length 28

What's wrong?

(Last edited by vova on 13 Aug 2014, 19:19)

I didn't need to add any root= parameter to get the unit to boot (using the trunk and RC3 image) but I do not have an Ethernet interface (AR8035 type) on the node.

Did you have to do any modifications to bring the eth0 into existence?

cmlara wrote:

I didn't need to add any root= parameter to get the unit to boot (using the trunk and RC3 image) but I do not have an Ethernet interface (AR8035 type) on the node.

Did you have to do any modifications to bring the eth0 into existence?

No. If needed I can give dmesg output. I gave NanoBeam M2-400, not M5. In M5 - gigabit ethernet, in M2 - 100mbit.
But I really stuck with vlan passthrough sad

Ok thank makes sense. I am fighting gigabit driver support as an additional since I have an M5.

Now I know where to go on that.

I really don't know much on VLAN over WIFI.... The limited knowledge I find by google seems to imply that vlan tagging over. 802.11 isn't doable (2008) and that you have to broadcast multiple SSID.


I really don't know enough in that area however to be informative other than to ask does this work on another ath9k device ? (Like a bullet m2 or something)

Reference Material:

IEEE:
https://mentor.ieee.org/802.11/dcn/07/1 … 802-11.ppt

Cisco:
http://www.cisco.com/c/en/us/td/docs/wi … 37vlan.pdf

OpenWrt Forum
https://forum.openwrt.org/viewtopic.php?id=33248
https://forum.openwrt.org/viewtopic.php?id=33225

The discussion might have continued from here.