Modify

Opened 23 months ago

Last modified 23 months ago

#22044 new defect

Unifi AP Pro will stop receiving wi-fi packets (eeprom offset error)

Reported by: javrocket Owned by: developers
Priority: high Milestone:
Component: packages Version: Chaos Calmer 15.05
Keywords: unifi, uap-pro, eeprom, ath9k Cc:

Description

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.

Attachments (0)

Change History (3)

comment:1 Changed 23 months ago by javrocket

Looks like I accidentally set this to Component: packages. Please change to base

comment:2 Changed 23 months ago by anonymous

So that is not an issue?

comment:3 Changed 23 months ago by javrocket

I'm confused to what you are referring to. If you're referring to the copy hack that seems to "reset" the interface, that's not a real solution.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.