#22044: Unifi AP Pro will stop receiving wi-fi packets (eeprom offset error)
-------------------------------------------+-------------------------------
Reporter: javrocket | Owner: developers
Type: defect | Status: new
Priority: high | Milestone:
Component: packages | Version: Chaos Calmer
Keywords: unifi, uap-pro, eeprom, ath9k | 15.05
-------------------------------------------+-------------------------------
Using UniFi AP Pro with Chaos-Calmer 15.05 (r46767). The hardware is
fairly new and purchased in Jan/Feb (has new logo and box). I did not keep
track of the AirOS version or the bootloader version. These APs were
flashed directly from stock to Chaos-Calmer 15.05 (from the downloads
page).
My wireless configuration is the following.
{{{
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.channel='36'
wireless.radio0.hwmode='11a'
wireless.radio0.path='platform/ar934x_wmac'
wireless.radio0.htmode='HT20'
wireless.radio0.disabled='1'
wireless.@wifi-iface[0]=wifi-iface
wireless.@wifi-iface[0].device='radio0'
wireless.@wifi-iface[0].network='lan'
wireless.@wifi-iface[0].mode='ap'
wireless.@wifi-iface[0].ssid='OpenWrt'
wireless.@wifi-iface[0].encryption='none'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.hwmode='11g'
wireless.radio1.path='pci0000:00/0000:00:00.0'
wireless.radio1.htmode='HT20'
wireless.radio1.channel='8'
wireless.radio1.txpower='24'
wireless.radio1.country='US'
wireless.@wifi-iface[1]=wifi-iface
wireless.@wifi-iface[1].device='radio1'
wireless.@wifi-iface[1].network='lan'
wireless.@wifi-iface[1].mode='ap'
wireless.@wifi-iface[1].encryption='none'
wireless.@wifi-iface[1].disabled='1'
wireless.@wifi-iface[1].ssid='UAP081.2.4'
wireless.@wifi-iface[2]=wifi-iface
wireless.@wifi-iface[2].device='radio1'
wireless.@wifi-iface[2].mode='monitor'
wireless.@wifi-iface[2].ssid='Monitor'
}}}
I created a second interface for the 2.4ghz radio in the monitor mode. I'm
running a simple libpcap program that captures certain kind of wi-fi
packets. I have 7 of these APs deployed in a fairly noisy environment. At
least a few times a day the wifi interface of a few of these APs stops
receiving packets. I verify this by checking the number of packets RX in
ifconfig and /sys/kernel/debug/ieee80211/phy1/ath9k/recv don't change
after a while. My libpcap program doesn't crash and simply acts as if no
packets are making it to the interface.
I suspect there is some incorrect indexing/partition of the bootloader,
eeprom, etc. This is because for some odd reason I can simply copy the
contents of
/sys/kernel/debug/ieee80211/phy1/ath9k/ to a newly created directory in
/root/ and the interface starts capturing packets again. The copy fails
with a read error however (doesn't specify what file it fails at)
the logread looks like the following:
{{{
Mon Feb 22 21:21:14 2016 kern.err kernel: [1030304.490000] ath: phy1:
ath_pci_eeprom_read: eeprom read failed, offset 00001ffa is out of range
Mon Feb 22 21:21:14 2016 kern.err kernel: [1030304.500000] ath: phy1:
ath_pci_eeprom_read: eeprom read failed, offset 00001ffb is out of range
Mon Feb 22 21:21:14 2016 kern.err kernel: [1030304.510000] ath: phy1:
ath_pci_eeprom_read: eeprom read failed, offset 00001ffc is out of range
Mon Feb 22 21:21:14 2016 kern.err kernel: [1030304.520000] ath: phy1:
ath_pci_eeprom_read: eeprom read failed, offset 00001ffd is out of range
Mon Feb 22 21:21:14 2016 kern.err kernel: [1030304.530000] ath: phy1:
ath_pci_eeprom_read: eeprom read failed, offset 00001ffe is out of range
Mon Feb 22 21:21:14 2016 kern.err kernel: [1030304.540000] ath: phy1:
ath_pci_eeprom_read: eeprom read failed, offset 00001fff is out of range
}}}
Though this maybe a result of the copying somehow.
the dmesg basically reads the same:
{{{
[1030304.460000] ath: phy1: ath_pci_eeprom_read: eeprom read failed,
offset 00001ff6 is out of range
[1030304.460000] ath: phy1: ath_pci_eeprom_read: eeprom read failed,
offset 00001ff7 is out of range
[1030304.470000] ath: phy1: ath_pci_eeprom_read: eeprom read failed,
offset 00001ff8 is out of range
[1030304.480000] ath: phy1: ath_pci_eeprom_read: eeprom read failed,
offset 00001ff9 is out of range
[1030304.490000] ath: phy1: ath_pci_eeprom_read: eeprom read failed,
offset 00001ffa is out of range
[1030304.500000] ath: phy1: ath_pci_eeprom_read: eeprom read failed,
offset 00001ffb is out of range
[1030304.510000] ath: phy1: ath_pci_eeprom_read: eeprom read failed,
offset 00001ffc is out of range
[1030304.520000] ath: phy1: ath_pci_eeprom_read: eeprom read failed,
offset 00001ffd is out of range
[1030304.530000] ath: phy1: ath_pci_eeprom_read: eeprom read failed,
offset 00001ffe is out of range
[1030304.540000] ath: phy1: ath_pci_eeprom_read: eeprom read failed,
offset 00001fff is out of range
}}}
Looking at the /sys/kernel/debug/ieee80211/phy1/ath9k/reset log, I see the
following:
{{{
Baseband Hang: 0
Baseband Watchdog: 0
Fatal HW Error: 14
TX HW error: 0
Transmit timeout: 0
TX Path Hang: 0
PLL RX Hang: 0
MAC Hang: 0
Stuck Beacon: 0
MCI Reset: 0
Calibration error: 0
Tx DMA stop error: 0
Rx DMA stop error: 0
}}}
Any help would be greatly appreciated I suspect it's bad indexing of the
various partitions due to changed bootloader (maybe a similar issue to
that of the other AirMax products
[https://wiki.openwrt.org/toh/ubiquiti/airmaxm]. However that eeprom issue
maybe a red herring.
--
Ticket URL: <https://dev.openwrt.org/ticket/22044>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
