Adding a few general notes to Ariyap's great suggestion of checking the 8.12.0.6 release notes.
One can start at the AP defining the failure path, ideally a ping or iperf within the L2 network to avoid routers. default GW or the 7240 whatever is appropriate.
latency or real frame loss ? (7240s include a limited iperf server if useful - see AOS CLI Reference guide 'perf-test' command)
If we start at the AP end of the path, the AP tech-supports are helpful focusing on the 802.11 portion, the reboot to mitigate sounds like a strong clue.
# Basis situation - with client stable on one nearby AP, a few client basics:
show user-table verbose | include <STA ip>
show ap association | inc <STA MAC>
# With a high SNR, what is the TX retry rate (downstream) ? high enough to explain the observed latency/loss ?
show ap debug client-table ap-name <apname> | include <STA mac>
show ap association | inc <STA MAC>
# AP radios general status:
show ap arm state ap-name <apname>
show ap arm history ap-name <apname>
show ap arm rf-summary ap-name <apname>
# how busy is the radio during the latency/loss ?
show ap radio-summary ap-name <apname>
# more detailed to rule in/out the radios, here again - looking at TX/RX retry and drop rates - sufficient to account for latency/loss ?
show ap debug client-stats client-mac 18:69:d4:b9:78:1f advanced | include Trans,etr,rop,rror
show ap debug radio-stats ap-name <apname> radio 0 advanced | include Trans,etr,rop.rror,usy
# The entire AP tech-support might yield clues, just prior to rebooting the ap.
If the radios are low utilization, retry rates good, and don't explain the latency/drops, we can look at the entire path, including a packet-capture
at the 7240
packet-capture dest local
packet-capture datapath mac <STA MAC>
show packet-capture datapath
Hope this helps.
------------------------------
Shawn Adams
------------------------------