New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Hardware support: Unifi AC Mesh #1021

Closed
tuennes opened this Issue Jan 31, 2017 · 33 comments

Comments

Projects
None yet
9 participants
@tuennes

tuennes commented Jan 31, 2017

I think this could be a cool, small device. Hopefully with a nice performance.
Please give me hints how I can support you.

Picture of PCB
Front:
uap-ac-mesh-cbfront
Back without antenna:
uap-ac-mesh-cbback-woantenna

Link to OEM-FW
Some info out of ssh console:
console.txt

Serial console:
serial_console.txt

@rotanid rotanid added the hardware label Feb 1, 2017

@tuennes tuennes changed the title from Add Hardware support: Unify AC Mesh to Add Hardware support: Unifi AC Mesh Feb 2, 2017

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes Feb 10, 2017

Serial console of booted LEDE ramdisk (generic, all drivers):
serial_console_LEDE_ramdisk.txt

Serial console of booted LEDE board=UBNT-UF-AC-LITE:
serial_console_LEDE_UBNT-UF-AC-LITE.txt

Flash memory dump (cat /dev/mtd0 > /tmp/mtd0):
mtd0.zip

tuennes commented Feb 10, 2017

Serial console of booted LEDE ramdisk (generic, all drivers):
serial_console_LEDE_ramdisk.txt

Serial console of booted LEDE board=UBNT-UF-AC-LITE:
serial_console_LEDE_UBNT-UF-AC-LITE.txt

Flash memory dump (cat /dev/mtd0 > /tmp/mtd0):
mtd0.zip

@rotanid rotanid added the upstream label Feb 12, 2017

@rotanid

This comment has been minimized.

Show comment
Hide comment
@rotanid

rotanid Feb 12, 2017

Member

hey @tuennes , primarily this is an upstream issue. gluon won't include hardware that isn't supported by LEDE-upstream. maybe you can gather in information on how to add support from a recent lede hardware PR ( lede-project/source#613 ) or @Brother-Lal can help you out with his notes on the topic.

Member

rotanid commented Feb 12, 2017

hey @tuennes , primarily this is an upstream issue. gluon won't include hardware that isn't supported by LEDE-upstream. maybe you can gather in information on how to add support from a recent lede hardware PR ( lede-project/source#613 ) or @Brother-Lal can help you out with his notes on the topic.

@Brother-Lal

This comment has been minimized.

Show comment
Hide comment
@Brother-Lal

Brother-Lal Feb 12, 2017

Contributor

That looks good.
If you can, join the #gluon irc channel at hackint an i can try to help a little bit along.

I tried to write the whole thing down:
https://gist.github.com/Brother-Lal/3ad312a8aa1c38ac5b9d8ebd47bb3a2a

Its targeted for Atheros devices, and just from my amateurish viewpoint .

Next question then would be, check what works with the ac-lite board: wifi,lan,macadresses,LEDS

Contributor

Brother-Lal commented Feb 12, 2017

That looks good.
If you can, join the #gluon irc channel at hackint an i can try to help a little bit along.

I tried to write the whole thing down:
https://gist.github.com/Brother-Lal/3ad312a8aa1c38ac5b9d8ebd47bb3a2a

Its targeted for Atheros devices, and just from my amateurish viewpoint .

Next question then would be, check what works with the ac-lite board: wifi,lan,macadresses,LEDS

@ArwedSchmidt

This comment has been minimized.

Show comment
Hide comment
@ArwedSchmidt

ArwedSchmidt Mar 27, 2017

I would like to participate.

@tuennes Which pin mapping is required to connect to the UART?
RX/TX/GND/3.3 or 5V?

ArwedSchmidt commented Mar 27, 2017

I would like to participate.

@tuennes Which pin mapping is required to connect to the UART?
RX/TX/GND/3.3 or 5V?

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes Mar 28, 2017

Hey @ArwedSchmidt
same like unifi ac lite, have a look at his picture
It is the left pinheader which is labled with UART
3.3V level, 115200 Baud, 8N1
But only use (from left, towards the LAN connector) ground, rx, tx

tuennes commented Mar 28, 2017

Hey @ArwedSchmidt
same like unifi ac lite, have a look at his picture
It is the left pinheader which is labled with UART
3.3V level, 115200 Baud, 8N1
But only use (from left, towards the LAN connector) ground, rx, tx

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes Mar 28, 2017

Currenly only the generic LEDE ramdisk with boardparameter UBNT-UF-AC-LITE is running fine (Wifi, LAN, LED, reset works).
What I do not understand is that the specific ramdisk for the AC-LITE is not booting out of uboot...

tuennes commented Mar 28, 2017

Currenly only the generic LEDE ramdisk with boardparameter UBNT-UF-AC-LITE is running fine (Wifi, LAN, LED, reset works).
What I do not understand is that the specific ramdisk for the AC-LITE is not booting out of uboot...

@Brother-Lal

This comment has been minimized.

Show comment
Hide comment
@Brother-Lal

Brother-Lal Mar 28, 2017

Contributor

Can you explain what you mean with booting out of uboot?

Contributor

Brother-Lal commented Mar 28, 2017

Can you explain what you mean with booting out of uboot?

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes Mar 28, 2017

The U-Boot envirionment comes up, after any key hit on the message "Hit any key to stop autoboot:" I'm booting via tftp a LEDE initramfs (renamed)
tftpboot 0x80060000 ifs.bin
go 0x80060000 console=ttyS0,115200 board=UBNT-UF-AC-LITE

tuennes commented Mar 28, 2017

The U-Boot envirionment comes up, after any key hit on the message "Hit any key to stop autoboot:" I'm booting via tftp a LEDE initramfs (renamed)
tftpboot 0x80060000 ifs.bin
go 0x80060000 console=ttyS0,115200 board=UBNT-UF-AC-LITE

@Brother-Lal

This comment has been minimized.

Show comment
Hide comment
@Brother-Lal

Brother-Lal Mar 28, 2017

Contributor

That did work, in your second post?
What did you change to "break" it?
Any more logs or error messages?
With specific ramdisk, which file do you refer too?

Sry for the barrage of questions :)

Contributor

Brother-Lal commented Mar 28, 2017

That did work, in your second post?
What did you change to "break" it?
Any more logs or error messages?
With specific ramdisk, which file do you refer too?

Sry for the barrage of questions :)

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes Mar 28, 2017

yes
Only the use of the generic ramdisk, not the specific...It is booting as well without any boardparameter
Will follow
lede-ar71xx-generic-vmlinux-initramfs.bin

tuennes commented Mar 28, 2017

yes
Only the use of the generic ramdisk, not the specific...It is booting as well without any boardparameter
Will follow
lede-ar71xx-generic-vmlinux-initramfs.bin

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes Mar 28, 2017

Thanks to @Brother-Lal:
I have flashed a LEDE image onto it (kernel0 partition) via mtd and have booted via bootm this image. Only 5Ghz missing...
Next step is to build an image with ath10k-ct firmware and driver in...
We'll see...

tuennes commented Mar 28, 2017

Thanks to @Brother-Lal:
I have flashed a LEDE image onto it (kernel0 partition) via mtd and have booted via bootm this image. Only 5Ghz missing...
Next step is to build an image with ath10k-ct firmware and driver in...
We'll see...

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes Mar 29, 2017

New image build is running fine:
LEDE with build in athk10-ct firmware and driver (only as modules they are not functional)
2 radios, LUCi...
Gluon 2016.2.4 is running as well, image ubiquiti-unifi-ac-lite

Next step is to build separate target ubiquiti-unifi-ac-mesh

tuennes commented Mar 29, 2017

New image build is running fine:
LEDE with build in athk10-ct firmware and driver (only as modules they are not functional)
2 radios, LUCi...
Gluon 2016.2.4 is running as well, image ubiquiti-unifi-ac-lite

Next step is to build separate target ubiquiti-unifi-ac-mesh

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes Mar 29, 2017

Gluon 2016.2.4, every 2-3 minutes in logread:
Wed Mar 29 09:17:42 2017 kern.debug kernel: [ 1030.880000] ath10k_pci 0000:00:00.0: ath10k_pci ATH10K_DBG_BUFFER:
Wed Mar 29 09:17:42 2017 kern.debug kernel: [ 1030.880000] ath10k: [0000]: 7E851000 244CFC17 14594300 06000000 00000000 40000000 01000000
Wed Mar 29 09:17:42 2017 kern.debug kernel: [ 1030.880000] ath10k_pci 0000:00:00.0: ATH10K_END

tuennes commented Mar 29, 2017

Gluon 2016.2.4, every 2-3 minutes in logread:
Wed Mar 29 09:17:42 2017 kern.debug kernel: [ 1030.880000] ath10k_pci 0000:00:00.0: ath10k_pci ATH10K_DBG_BUFFER:
Wed Mar 29 09:17:42 2017 kern.debug kernel: [ 1030.880000] ath10k: [0000]: 7E851000 244CFC17 14594300 06000000 00000000 40000000 01000000
Wed Mar 29 09:17:42 2017 kern.debug kernel: [ 1030.880000] ath10k_pci 0000:00:00.0: ATH10K_END

@rotanid

This comment has been minimized.

Show comment
Hide comment
@rotanid

rotanid Mar 29, 2017

Member

these messages are there with the Unifi AP AC Pro devices, too.
i think there is some kind of debug switch that wasn't turned off...

Member

rotanid commented Mar 29, 2017

these messages are there with the Unifi AP AC Pro devices, too.
i think there is some kind of debug switch that wasn't turned off...

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes Mar 30, 2017

@Brother-Lal has build within his own repo a dedicated branch and changed all needed files (hopefully)...
When I build with this repo the 5Ghz is not working (f.e. luci is not showing this device).
corresponding logmessages:
[ 8.863015] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[ 8.872438] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[ 8.944828] ath10k_pci 0000:00:00.0: otp calibration failed: 2
[ 8.950858] ath10k_pci 0000:00:00.0: failed to run otp: -22
[ 8.956629] ath10k_pci 0000:00:00.0: could not init core (-22)
[ 8.962745] ath10k_pci 0000:00:00.0: could not probe fw (-22)

If I just clone the LEDE Master tree and choose the AC-LITE device then LEDE is running on the AC-mesh, LOG:
[ 8.841067] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[ 8.850514] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[ 9.769806] ath10k_pci 0000:00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256
[ 9.787894] ath10k_pci 0000:00:00.0: wmi print 'P 128 V 8 T 410'
[ 9.794165] ath10k_pci 0000:00:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0'
[ 9.801536] ath10k_pci 0000:00:00.0: wmi print 'alloc rem: 25908 iram: 25808'
[ 9.859459] ath10k_pci 0000:00:00.0: htt-ver 2.1 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1

What do I wrong during build, menuconfig etc.?

tuennes commented Mar 30, 2017

@Brother-Lal has build within his own repo a dedicated branch and changed all needed files (hopefully)...
When I build with this repo the 5Ghz is not working (f.e. luci is not showing this device).
corresponding logmessages:
[ 8.863015] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[ 8.872438] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[ 8.944828] ath10k_pci 0000:00:00.0: otp calibration failed: 2
[ 8.950858] ath10k_pci 0000:00:00.0: failed to run otp: -22
[ 8.956629] ath10k_pci 0000:00:00.0: could not init core (-22)
[ 8.962745] ath10k_pci 0000:00:00.0: could not probe fw (-22)

If I just clone the LEDE Master tree and choose the AC-LITE device then LEDE is running on the AC-mesh, LOG:
[ 8.841067] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[ 8.850514] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[ 9.769806] ath10k_pci 0000:00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256
[ 9.787894] ath10k_pci 0000:00:00.0: wmi print 'P 128 V 8 T 410'
[ 9.794165] ath10k_pci 0000:00:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0'
[ 9.801536] ath10k_pci 0000:00:00.0: wmi print 'alloc rem: 25908 iram: 25808'
[ 9.859459] ath10k_pci 0000:00:00.0: htt-ver 2.1 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1

What do I wrong during build, menuconfig etc.?

@ArwedSchmidt

This comment has been minimized.

Show comment
Hide comment
@ArwedSchmidt

ArwedSchmidt Apr 2, 2017

We confirmed that the Mesh Pro (codename "dragonfly") is actually using:

QCA 9563-AL3A
QCA 9880-BR4A
QCA 8334-AL3C

Hardware seems to be identical to what's been used with the UAP-AC PRO! Due to all the interesting talks and some debricking, we haven't tried to flash the existing image yet.

The case is a bit trickier but can be opened by first cutting the silicate seal all around the case (it's just two parts, later). The cover is hold in place by maybe 20 plastic hooks.

One can start to disconnect these hooks most easily by carefully levering the knobs up that hold the cable door in place (lever against the fixed part of the cable outlet). Once the first hook is loose, it's easier to continue with four hands and two screwdrivers.

Here are some pictures of the opened device:

img_7220
img_7218
img_7226

We also found out that one of our AC Meshs was using a bootloader from 2016-06-12 which was not compatible with the latest gluon build. The device was bricked until we recovered with the special recovery process offered by UBNT, effectively upgrading the bootloader. One should update to latest stock firmware before trying to flash anything!

Note: it seems that you cannot be sure whether your device will actually boot from kernel0 or kernel1 partition (haven't searched for an output yet, that hints which one to flash to). This seems to be a safety feature where every upgrade would use the partition that’s not in use.

Testing mesh on 5 GHz has not yielded positive results yet. However, we couldn't confirm that the builds we were using can actually mesh on 5 GHz. Once we disabled 2.4 GHz mesh, no connection was possible to a second "mesh only" UAP-AC-M.

I'm gonna install my UAP-AC-M in a test setup for now and see if it's stable. One thing you can note is that these devices get a little bit hot when used indoors. It uses around 6.9 Watts when idling with gluon-v2016.2.3-8 - more than e.g. NanoStations would draw.

ArwedSchmidt commented Apr 2, 2017

We confirmed that the Mesh Pro (codename "dragonfly") is actually using:

QCA 9563-AL3A
QCA 9880-BR4A
QCA 8334-AL3C

Hardware seems to be identical to what's been used with the UAP-AC PRO! Due to all the interesting talks and some debricking, we haven't tried to flash the existing image yet.

The case is a bit trickier but can be opened by first cutting the silicate seal all around the case (it's just two parts, later). The cover is hold in place by maybe 20 plastic hooks.

One can start to disconnect these hooks most easily by carefully levering the knobs up that hold the cable door in place (lever against the fixed part of the cable outlet). Once the first hook is loose, it's easier to continue with four hands and two screwdrivers.

Here are some pictures of the opened device:

img_7220
img_7218
img_7226

We also found out that one of our AC Meshs was using a bootloader from 2016-06-12 which was not compatible with the latest gluon build. The device was bricked until we recovered with the special recovery process offered by UBNT, effectively upgrading the bootloader. One should update to latest stock firmware before trying to flash anything!

Note: it seems that you cannot be sure whether your device will actually boot from kernel0 or kernel1 partition (haven't searched for an output yet, that hints which one to flash to). This seems to be a safety feature where every upgrade would use the partition that’s not in use.

Testing mesh on 5 GHz has not yielded positive results yet. However, we couldn't confirm that the builds we were using can actually mesh on 5 GHz. Once we disabled 2.4 GHz mesh, no connection was possible to a second "mesh only" UAP-AC-M.

I'm gonna install my UAP-AC-M in a test setup for now and see if it's stable. One thing you can note is that these devices get a little bit hot when used indoors. It uses around 6.9 Watts when idling with gluon-v2016.2.3-8 - more than e.g. NanoStations would draw.

@Brother-Lal

This comment has been minimized.

Show comment
Hide comment
@Brother-Lal

Brother-Lal Apr 7, 2017

Contributor

If somebody has access to an ubiquity ac lite, ac pro and also for the ac mesh pro, i would like to have a look at the flash. So, if you could do a Flash memory dump (cat /dev/mtd0 > /tmp/mtd0) for those three, i would appreciate it if you could drop me a link :)

Update:
AC Lite and AC pro are good, the ac mesh lite is already in the ticket, so the one last i need would be Mesh PRO!

Contributor

Brother-Lal commented Apr 7, 2017

If somebody has access to an ubiquity ac lite, ac pro and also for the ac mesh pro, i would like to have a look at the flash. So, if you could do a Flash memory dump (cat /dev/mtd0 > /tmp/mtd0) for those three, i would appreciate it if you could drop me a link :)

Update:
AC Lite and AC pro are good, the ac mesh lite is already in the ticket, so the one last i need would be Mesh PRO!

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes May 11, 2017

DMESG log original FW:
dmesg_AC_mesh_pro_original_FW.txt

First binwalk info:
binwalk mtd0 -v

Scan Time: 2017-05-11 07:09:40
Target File: /home/frank/mtd0
MD5 Checksum: f29d4c975d56420e97b487e20b89f075
Signatures: 344

DECIMAL HEXADECIMAL DESCRIPTION

150944 0x24DA0 Certificate in DER format (x509 v3), header length: 4, sequence length: 64
175312 0x2ACD0 CRC32 polynomial table, big endian
199639 0x30BD7 Copyright string: "Copyright Ubiquiti Networks Inc. 2014"
203020 0x3190C Ubiquiti end header, header size: 12 bytes, cumulative ~CRC32: 0x454E442E
310152 0x4BB88 CRC32 polynomial table, big endian
312448 0x4C480 Ubiquiti end header, header size: 12 bytes, cumulative ~CRC32: 0x454E442E
316619 0x4D4CB Unix path: /pk/asn1/der/sequence/der_decode_sequence_ex.c
316947 0x4D613 Unix path: /pk/asn1/der/sequence/der_decode_sequence_multi.c
318775 0x4DD37 Unix path: /pk/asn1/der/integer/der_decode_integer.c
319059 0x4DE53 Unix path: /pk/asn1/der/integer/der_length_integer.c
323790 0x4F0CE Ubiquiti partition header, header size: 56 bytes, name: "PARTkernel0", base address: 0x00000001, data size: -2147475456 bytes
323854 0x4F10E uImage header, header size: 64 bytes, header CRC: 0x5CEF3CED, created: 2016-08-30 03:21:13, image size: 7223979 bytes, Data Address: 0x80060000, Entry Point: 0x80060000, data CRC: 0xAB112EF2, OS: Linux, CPU: MIPS, image type: Multi-File Image, compression type: lzma, image name: "MIPS OpenWrt Linux-3.3.8"

Serial:
J1: 3v3 (do not use), tx, rx, ground

log:
serial_log_AC_mesh_pro.txt

Partitions:
BZ.v3.7.12# cat /proc/mtd
dev: size erasesize name
mtd0: 00060000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00790000 00010000 "kernel0"
mtd3: 00790000 00010000 "kernel1"
mtd4: 00020000 00010000 "bs"
mtd5: 00040000 00010000 "cfg"
mtd6: 00010000 00010000 "EEPROM"

After FW upgrade (UniFi firmware 3.7.55 for UAP-AC-Lite/LR/Pro/EDU/M/M-PRO/IW):

Serial log
serial_log_AC_mesh_pro_FW_3755.txt

DMESG
dmesg_AC_mesh_pro_original_FW_3755.txt

Flash memory dump Unify AC mesh pro (FW 3755):
mtd_mesh_pro_3755.zip

tuennes commented May 11, 2017

DMESG log original FW:
dmesg_AC_mesh_pro_original_FW.txt

First binwalk info:
binwalk mtd0 -v

Scan Time: 2017-05-11 07:09:40
Target File: /home/frank/mtd0
MD5 Checksum: f29d4c975d56420e97b487e20b89f075
Signatures: 344

DECIMAL HEXADECIMAL DESCRIPTION

150944 0x24DA0 Certificate in DER format (x509 v3), header length: 4, sequence length: 64
175312 0x2ACD0 CRC32 polynomial table, big endian
199639 0x30BD7 Copyright string: "Copyright Ubiquiti Networks Inc. 2014"
203020 0x3190C Ubiquiti end header, header size: 12 bytes, cumulative ~CRC32: 0x454E442E
310152 0x4BB88 CRC32 polynomial table, big endian
312448 0x4C480 Ubiquiti end header, header size: 12 bytes, cumulative ~CRC32: 0x454E442E
316619 0x4D4CB Unix path: /pk/asn1/der/sequence/der_decode_sequence_ex.c
316947 0x4D613 Unix path: /pk/asn1/der/sequence/der_decode_sequence_multi.c
318775 0x4DD37 Unix path: /pk/asn1/der/integer/der_decode_integer.c
319059 0x4DE53 Unix path: /pk/asn1/der/integer/der_length_integer.c
323790 0x4F0CE Ubiquiti partition header, header size: 56 bytes, name: "PARTkernel0", base address: 0x00000001, data size: -2147475456 bytes
323854 0x4F10E uImage header, header size: 64 bytes, header CRC: 0x5CEF3CED, created: 2016-08-30 03:21:13, image size: 7223979 bytes, Data Address: 0x80060000, Entry Point: 0x80060000, data CRC: 0xAB112EF2, OS: Linux, CPU: MIPS, image type: Multi-File Image, compression type: lzma, image name: "MIPS OpenWrt Linux-3.3.8"

Serial:
J1: 3v3 (do not use), tx, rx, ground

log:
serial_log_AC_mesh_pro.txt

Partitions:
BZ.v3.7.12# cat /proc/mtd
dev: size erasesize name
mtd0: 00060000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00790000 00010000 "kernel0"
mtd3: 00790000 00010000 "kernel1"
mtd4: 00020000 00010000 "bs"
mtd5: 00040000 00010000 "cfg"
mtd6: 00010000 00010000 "EEPROM"

After FW upgrade (UniFi firmware 3.7.55 for UAP-AC-Lite/LR/Pro/EDU/M/M-PRO/IW):

Serial log
serial_log_AC_mesh_pro_FW_3755.txt

DMESG
dmesg_AC_mesh_pro_original_FW_3755.txt

Flash memory dump Unify AC mesh pro (FW 3755):
mtd_mesh_pro_3755.zip

@janhanekom

This comment has been minimized.

Show comment
Hide comment
@janhanekom

janhanekom May 13, 2017

I have a UAP-AC-M-Pro (Mesh Pro); I have tried, but have been unsuccessful at getting non-stock firmware to run, presumably because of UBoot. I tried downgrading firmware to 3.4.7, but anything lower than 3.4.16 doesn't appear to boot on the device (TFTP upgrades succeed, but the device does not boot. fwupdate.real returns an error, stating it doesn't like the 3.4.7 firmware file.)

Arwed: I'm preplexed by your statement that one should update to the latest stock firmware before flashing custom firmware - were you able to get your unit to flash custom firmware, even with the UBoot installed by recent versions of firmware?

janhanekom commented May 13, 2017

I have a UAP-AC-M-Pro (Mesh Pro); I have tried, but have been unsuccessful at getting non-stock firmware to run, presumably because of UBoot. I tried downgrading firmware to 3.4.7, but anything lower than 3.4.16 doesn't appear to boot on the device (TFTP upgrades succeed, but the device does not boot. fwupdate.real returns an error, stating it doesn't like the 3.4.7 firmware file.)

Arwed: I'm preplexed by your statement that one should update to the latest stock firmware before flashing custom firmware - were you able to get your unit to flash custom firmware, even with the UBoot installed by recent versions of firmware?

@ArwedSchmidt

This comment has been minimized.

Show comment
Hide comment
@ArwedSchmidt

ArwedSchmidt May 13, 2017

@janhanekom I have only flashed normal mesh APs yet. Therefore my comment was primarily meant for that device. My mesh AP came with "latest stock" back in March/April and we had no issues to flash it. Another mesh ap had a fairly outdated u-boot and bricked (details in my previous comment). I assumed that early mesh ap and ap pro's shipped together and would suffer both from ancient u-boot version (first orders).

Which Gluon version have you tried to flash on the device? If you have trouble with latest u-boot/stock I can add a warning to my comment that there might have been changes that cause compatibility issues.

ArwedSchmidt commented May 13, 2017

@janhanekom I have only flashed normal mesh APs yet. Therefore my comment was primarily meant for that device. My mesh AP came with "latest stock" back in March/April and we had no issues to flash it. Another mesh ap had a fairly outdated u-boot and bricked (details in my previous comment). I assumed that early mesh ap and ap pro's shipped together and would suffer both from ancient u-boot version (first orders).

Which Gluon version have you tried to flash on the device? If you have trouble with latest u-boot/stock I can add a warning to my comment that there might have been changes that cause compatibility issues.

@janhanekom

This comment has been minimized.

Show comment
Hide comment
@janhanekom

janhanekom May 13, 2017

Nevermind, I’ve figured it out! The unit has two Ethernet ports, and it turns out LAN and WAN are the other way around than I expected. When installing UAP-AC-PRO LEDE images onto a UAP-AC-M-PRO, LAN is on the “Secondary” port, and WAN is on the “Main” port (where PoE is connected to.)

(Haven't tried a Gluon image yet - right now I've just been trying to keep it basic and just testing "plain" LEDE. Prior to this I’ve tried both 17.01.1 and an image compiled from trunk.)

So as to my reason for asking about UAP 3.4.7 firmware: There is lots of talk on the LEDE pages and elsewhere about U-Boot in versions subsequent to 3.4.7 (3.4.16+) checking for digital signatures in firmware to block 3rd party firmware. Based on what I just did, I suspect that might no longer be the case, at least with recent firmware? (I had 3.7.55 on my device.)

For what it’s worth: Unifi 3.4.7 indeed does not boot properly on the UAP-AC-M-PRO. It gets partway through, as the AP responds to pings and you can SSH to it, but if you log in using ubnt/ubnt, the session closes immediately. (Logging in with a different password results in “access denied”, so pretty sure the credentials are correct.)

After I’d flashed my UAP-AC-M-PRO with LEDE and it didn’t come up (I flashed both firmware partitions – kernel0 and kernel1 – with the same image just to be sure), I assumed that the U-Boot problem was the cause. However, I eventually spotted odd behaviour which caused to me question that:
• I got a single ping response to 192.168.1.1 during boot-up (one and one only, after which the MAC entry timed out of my computer’s ARP table.)
• I started seeing DHCPv4 requests; when issued an IP, the device did not allow connections, but the entry showed up in my ARP table
• I also saw DHCPv6 requests, which had the FQDN field set to “LEDE”  this was the clincher…

Status right now is that I’m up & running on the “Secondary” port. Similar to tuennes’ initial results, 802.11an/802.11ac does not seem to work yet even though I’ve added the qca988x-ct driver and firmware to my image. Subsequent posts infer he got it working, will try to reproduce.

That’s a challenge for another day… right now, I’m just chuffed I got the basics working without having to crack it open for access to a serial console.

janhanekom commented May 13, 2017

Nevermind, I’ve figured it out! The unit has two Ethernet ports, and it turns out LAN and WAN are the other way around than I expected. When installing UAP-AC-PRO LEDE images onto a UAP-AC-M-PRO, LAN is on the “Secondary” port, and WAN is on the “Main” port (where PoE is connected to.)

(Haven't tried a Gluon image yet - right now I've just been trying to keep it basic and just testing "plain" LEDE. Prior to this I’ve tried both 17.01.1 and an image compiled from trunk.)

So as to my reason for asking about UAP 3.4.7 firmware: There is lots of talk on the LEDE pages and elsewhere about U-Boot in versions subsequent to 3.4.7 (3.4.16+) checking for digital signatures in firmware to block 3rd party firmware. Based on what I just did, I suspect that might no longer be the case, at least with recent firmware? (I had 3.7.55 on my device.)

For what it’s worth: Unifi 3.4.7 indeed does not boot properly on the UAP-AC-M-PRO. It gets partway through, as the AP responds to pings and you can SSH to it, but if you log in using ubnt/ubnt, the session closes immediately. (Logging in with a different password results in “access denied”, so pretty sure the credentials are correct.)

After I’d flashed my UAP-AC-M-PRO with LEDE and it didn’t come up (I flashed both firmware partitions – kernel0 and kernel1 – with the same image just to be sure), I assumed that the U-Boot problem was the cause. However, I eventually spotted odd behaviour which caused to me question that:
• I got a single ping response to 192.168.1.1 during boot-up (one and one only, after which the MAC entry timed out of my computer’s ARP table.)
• I started seeing DHCPv4 requests; when issued an IP, the device did not allow connections, but the entry showed up in my ARP table
• I also saw DHCPv6 requests, which had the FQDN field set to “LEDE”  this was the clincher…

Status right now is that I’m up & running on the “Secondary” port. Similar to tuennes’ initial results, 802.11an/802.11ac does not seem to work yet even though I’ve added the qca988x-ct driver and firmware to my image. Subsequent posts infer he got it working, will try to reproduce.

That’s a challenge for another day… right now, I’m just chuffed I got the basics working without having to crack it open for access to a serial console.

@janhanekom

This comment has been minimized.

Show comment
Hide comment
@janhanekom

janhanekom May 14, 2017

Just an update: LAN and WAN being inverted (at least in my opinion) should be correctable in the device profile in LEDE; if I have time in the next few days' I'll try to catch up on how to do (and contribute) that, but it will probably be quicker and less error prone if someone else does it.

5Ghz wireless; not sure if this is related to the AC-M-PRO specifically, but: (tried both ath10k and ath10k-ct)

  • I can see and connect to the QCA9880 (?) from 802.11an clients, but 802.11ac clients don't even "see" the SSID. This is true for any channel and bandwidth combination I tested. I also tested setting the "Operation mode" to either AC or N, the behaviour is the same.
  • I can only "see" the AP if I choose a channel in the UNII-1 and UNII-2 Mid bands (36-64.) The subset of channels I tried in the UNII-2 Extended band (100-140) do not seem to work, even though they're permitted in the regdomain I configured (and are listed as such when I run "iw phy0 info".) I could not test UNII-3 Upper due to my regdomain. For what it's worth, channels in the UNII-1/2 Mid band requiring DFS and TPC do come up after a little while, so don't think it's related to that.

I find the above behaviour to be rather "weird." Will keep looking.

janhanekom commented May 14, 2017

Just an update: LAN and WAN being inverted (at least in my opinion) should be correctable in the device profile in LEDE; if I have time in the next few days' I'll try to catch up on how to do (and contribute) that, but it will probably be quicker and less error prone if someone else does it.

5Ghz wireless; not sure if this is related to the AC-M-PRO specifically, but: (tried both ath10k and ath10k-ct)

  • I can see and connect to the QCA9880 (?) from 802.11an clients, but 802.11ac clients don't even "see" the SSID. This is true for any channel and bandwidth combination I tested. I also tested setting the "Operation mode" to either AC or N, the behaviour is the same.
  • I can only "see" the AP if I choose a channel in the UNII-1 and UNII-2 Mid bands (36-64.) The subset of channels I tried in the UNII-2 Extended band (100-140) do not seem to work, even though they're permitted in the regdomain I configured (and are listed as such when I run "iw phy0 info".) I could not test UNII-3 Upper due to my regdomain. For what it's worth, channels in the UNII-1/2 Mid band requiring DFS and TPC do come up after a little while, so don't think it's related to that.

I find the above behaviour to be rather "weird." Will keep looking.

@rotanid

This comment has been minimized.

Show comment
Hide comment
@rotanid

rotanid May 14, 2017

Member

afaik it's the default for every similar device, having WAN on the main port, where PoE also is active...

Member

rotanid commented May 14, 2017

afaik it's the default for every similar device, having WAN on the main port, where PoE also is active...

@rotanid

This comment has been minimized.

Show comment
Hide comment
@rotanid

rotanid Jun 5, 2017

Member

regarding unifi ac mesh (NOT mesh pro)
upstream now has support for this device:
https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/lede-ar71xx-generic-ubnt-unifiac-mesh-squashfs-sysupgrade.bin
next step probably would be to do a PR for lede-17.01 backport and after that, gluon master

the mesh pro is not yet supported upstream.

Member

rotanid commented Jun 5, 2017

regarding unifi ac mesh (NOT mesh pro)
upstream now has support for this device:
https://downloads.lede-project.org/snapshots/targets/ar71xx/generic/lede-ar71xx-generic-ubnt-unifiac-mesh-squashfs-sysupgrade.bin
next step probably would be to do a PR for lede-17.01 backport and after that, gluon master

the mesh pro is not yet supported upstream.

@tuennes

This comment has been minimized.

Show comment
Hide comment
@tuennes

tuennes Jun 6, 2017

@janhanekom : Which qca988x firmware do have in use?
Following this maybe it solves the client problems?

tuennes commented Jun 6, 2017

@janhanekom : Which qca988x firmware do have in use?
Following this maybe it solves the client problems?

@janhanekom

This comment has been minimized.

Show comment
Hide comment
@janhanekom

janhanekom Jun 6, 2017

Thanks for the heads-up Tuennes - will try to take a look and report back.

janhanekom commented Jun 6, 2017

Thanks for the heads-up Tuennes - will try to take a look and report back.

@petabyteboy

This comment has been minimized.

Show comment
Hide comment
@petabyteboy
Contributor

petabyteboy commented Jun 14, 2017

@rotanid

This comment has been minimized.

Show comment
Hide comment
@rotanid

rotanid Aug 3, 2017

Member

as two upstream lede devs now rejected the backport, we need to create a patch for gluon itself for this

Member

rotanid commented Aug 3, 2017

as two upstream lede devs now rejected the backport, we need to create a patch for gluon itself for this

@NeoRaider NeoRaider closed this in 085cf0d Aug 8, 2017

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Aug 8, 2017

Member

I went for the easy solution and simply added an image alias instead of patching LEDE.

Member

NeoRaider commented Aug 8, 2017

I went for the easy solution and simply added an image alias instead of patching LEDE.

@rotanid

This comment has been minimized.

Show comment
Hide comment
@rotanid

rotanid Aug 8, 2017

Member

do we have to change something again as soon as we are based on a newer LEDE branch?

Member

rotanid commented Aug 8, 2017

do we have to change something again as soon as we are based on a newer LEDE branch?

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Aug 8, 2017

Member

@rotanid We'll need to support the changed model string in the manifest in addition to the old one, using manifest_alias.

Member

NeoRaider commented Aug 8, 2017

@rotanid We'll need to support the changed model string in the manifest in addition to the old one, using manifest_alias.

@s13884

This comment has been minimized.

Show comment
Hide comment
@s13884

s13884 Sep 5, 2017

Anyone has Datasheet for QCA9563? Or else anyone suggest where can I get the same?

s13884 commented Sep 5, 2017

Anyone has Datasheet for QCA9563? Or else anyone suggest where can I get the same?

rotanid added a commit to tecff/gluon that referenced this issue Nov 2, 2017

rotanid added a commit to tecff/gluon that referenced this issue Nov 2, 2017

rotanid added a commit to tecff/gluon that referenced this issue Nov 16, 2017

@mobythevan

This comment has been minimized.

Show comment
Hide comment
@mobythevan

mobythevan Jan 4, 2018

Do we know the pinout for connector J3 and if the interface is enabled?

mobythevan commented Jan 4, 2018

Do we know the pinout for connector J3 and if the interface is enabled?

rotanid added a commit to tecff/gluon that referenced this issue Jan 18, 2018

rotanid added a commit to tecff/gluon that referenced this issue Feb 4, 2018

rotanid added a commit to tecff/gluon that referenced this issue Mar 19, 2018

rotanid added a commit to tecff/gluon that referenced this issue Apr 12, 2018

rotanid added a commit to tecff/gluon that referenced this issue Apr 16, 2018

rotanid added a commit to tecff/gluon that referenced this issue Apr 16, 2018

rotanid added a commit to tecff/gluon that referenced this issue Apr 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment