Wi-Fi 7 Access Point Troubleshooting: A Real Ruijie RG-AP9861-R Customer Deployment

Real Customer Deployment Case - Italy | May-June 2025

Quick Conclusion

Our first customer deployment of Ruijie's flagship RG-AP9861-R became much more than a routine Wi-Fi 7 access point setup. What began as WIS Cloud onboarding developed into a multi-day troubleshooting case covering FAT-mode access, Web GUI behavior, 6 GHz discovery, WPA3/SAE configuration, the role of the fifth radio, multi-gigabit port negotiation, intermittent login problems and firmware follow-up. The important finding was that these symptoms did not have one common cause. Some were configuration or management-mode behaviors; some exposed documentation and usability gaps; some required Ruijie engineering escalation; and several remained observations without a complete surviving root-cause analysis. By combining the customer's real environment, remote sessions, screenshots and actual Web CLI output, the deployment moved from return risk to a working Wi-Fi 7 network-and gave our team product knowledge that a datasheet alone could not provide.

This case matters because enterprise wireless products rarely reveal their full operational complexity in a specification sheet.

The RG-AP9861-R was a newly launched flagship enterprise Wi-Fi 7 access point when this deployment took place. The customer wanted high wireless performance and was willing to experiment with an enterprise platform rather than another consumer-class wireless product.

But the deployment also exposed a common reality with advanced networking equipment:

Powerful hardware does not necessarily mean simple onboarding.

Between May 23 and June 13, 2025, what started as a configuration request developed into a detailed real-world wireless AP troubleshooting case involving the customer, Network-Switch, Ruijie domestic technical support, overseas support engineers and subsequent software/firmware follow-up.

Our First Real-World Deployment of a Flagship Wi-Fi 7 Access Point

This was our first customer deployment of Ruijie's newly launched flagship RG-AP9861-R Wi-Fi 7 access point.

It was not our first customer, nor our first Ruijie wireless project. The distinction matters because this case documents our first real customer experience with this specific flagship model.

The customer was an Italian media professional, content creator and technology enthusiast using the AP in a connected two-building residential/prosumer environment. His objectives were to upgrade his existing wireless network, experiment with a new enterprise wireless brand and deploy a high-end Wi-Fi 7 access point.

The exact product deployed was the Ruijie RG-AP9861-R Wi-Fi 7 access point.

Project Snapshot

The original support case opened on May 23, 2025. The record explicitly identifies an Italian end customer, the RG-AP9861-R and a request for remote assistance with WIS Cloud onboarding. The customer was not comfortable using CLI, so the initial objective was simply to help get the AP online and manageable.

The customer later confirmed that the AP was being powered through PoE++ at 60 W.

When Wireless Access Point Setup Became a Multi-Day Troubleshooting Case

The initial task looked straightforward:

• bring the AP into WIS Cloud;
• create the required SSIDs;
• configure 2.4 GHz;
• configure 5 GHz;
• configure 6 GHz;
• verify wireless operation.

WIS Cloud onboarding was eventually completed, but the configuration process immediately became more complicated.

The customer found the enterprise management workflow significantly different from the consumer wireless products he had previously used. The original discussions explicitly distinguish enterprise-oriented WIS Cloud operation from simpler SMB or consumer-oriented management workflows.

Over the following days, several symptoms appeared:

• FAT mode became difficult to access;
• switching AP modes appeared to remove previous configuration;
• some radio configuration changes returned errors;
• settings appeared not to save;
• 5 GHz and 6 GHz behavior was unclear;
• Radio 5 could not be selected for normal SSID service;
• login/password behavior became inconsistent;
• manually selecting 2.5Gbps appeared to cause connectivity problems;
• Cloud onboarding involved steps the customer considered unnecessarily complicated.

By May 24, the team had already followed the available configuration material, yet the radio configuration issue remained. In WIS Cloud, 5 GHz and 6 GHz could still not be configured as expected, and attempts involving country/region selection continued to return errors.

Ruijie overseas technical support then became involved.

After another remote troubleshooting attempt, the overseas engineer reported that Web configuration changes were repeatedly returning errors and concluded that the specific unit needed further investigation. At that stage, returning the access point was genuinely being considered.

That point is important to preserve.

This was not a perfectly smooth deployment rewritten afterward as a marketing success story.

At one stage:

But it would have been equally inaccurate to go in the other direction and call every customer-reported problem a firmware bug.

The rest of the case was therefore about classification.

For every symptom, we needed to determine whether we were dealing with:

configuration operating-mode behavior client behavior documentation browser/UI software or hardware.

Separating Wi-Fi Configuration Issues From Product and Documentation Problems

One of the biggest lessons from this case was that a customer-observed symptom and a confirmed product defect are not the same thing.

Issue Classification

FAT mode was not simply "the AP froze"

The early FAT-mode symptom initially looked severe.

When the AP changed from Cloud mode to FAT mode, the customer reported that the management page disappeared, the AP became inaccessible and a reset appeared necessary.

Subsequent troubleshooting showed that part of this behavior was related to the management-mode transition itself.

Changing modes cleared the existing configuration, and FAT mode did not use the Cloud-mode addressing behavior the customer had become accustomed to.

The support team identified separate default addresses associated with the AP interfaces:

• WAN1 - 192.168.110.1
• WAN2 - 192.168.111.1
• LAN1 - 192.168.112.1

The FAT-mode environment did not operate as a DHCP client in the way the customer expected. His existing network used 192.168.1.x, so direct management also required the PC to be placed in the appropriate subnet and connected through the appropriate interface.

That explained part of what initially looked like a FAT-mode crash.

It did not explain everything.

After the customer could enter FAT mode again, Radio 2-5 configuration problems were still being reported. Even after changing from Firefox to Chrome, the reported FAT-mode radio behavior continued. Those remaining symptoms were therefore kept open for further investigation.

That distinction is critical:

6 GHz Wi-Fi required a different interpretation

The customer initially reported that the 6 GHz signal was not broadcasting.

That was a legitimate field observation.

It was not sufficient evidence to conclude that the 6 GHz radio was defective.

Subsequent support work confirmed that the 6 GHz WLAN required the appropriate WPA3/SAE security configuration.

The discussion later went further.

Ruijie support explained that a client may rely on information carried through the 5 GHz Beacon, including RNR, to discover 6 GHz service rather than simply treating 6 GHz scanning exactly like older bands. The recommended test configuration therefore involved 5 GHz together with 6 GHz rather than assuming that an isolated 6 GHz SSID should necessarily appear in the way the customer expected.

So the original symptom remained real.

The interpretation changed.

Radio 5 was not a failed fifth client radio

Radio 5 produced another misleading symptom.

The customer saw a fifth radio in the management system but could not select it for normal SSID broadcasting.

Later support clarification established that:

Radio 5 is the AI Radio.

It is not simply another normal user-service radio intended for ordinary SSID broadcasting in the FAT-mode scenario under test. Ruijie support described its role in an AC + Fit AP environment, where it can participate in optimization and roaming-related functions.

This gives us another useful troubleshooting principle:

The password problem remained an observed issue

The customer also reported intermittent situations in which a previously accepted password stopped working after several hours or after a session expired.

The important evidence came from an attempted reproduction.

The customer powered the AP off and back on and confirmed that the password still worked after that normal power cycle. However, he also reported that the login problem had occurred on multiple previous occasions and reported another access problem after restoring a backup.

Without preserved logs establishing the cause, this should remain classified as:

Observed intermittent login issue.

It should not be rewritten as:

Confirmed firmware password-loss defect.

What the Web GUI and Web CLI Revealed About the Wireless AP

The most valuable technical turning point came when troubleshooting moved beyond the Web GUI.

One major concern involved the multi-gigabit Ethernet uplink.

The customer reported that manually changing WAN1 from AUTO to 2.5Gbps caused the connection to stop working or appear to freeze. This initially created concern around the physical interface itself.

Instead of continuing to change GUI parameters, Ruijie overseas support asked the customer to inspect the live interface state through Web CLI.

The actual deployed AP returned:

RG-AP9861-R#show interface

TenGigabitEthernet 0/1 is UP
line protocol is UP

Admin duplex mode is AUTO
oper duplex is Full

Admin speed is AUTO
oper speed is 2500M

The same interface output recorded:

0 input errors
0 CRC
0 output errors

These were not laboratory results or reconstructed command examples.

They came from the customer's deployed RG-AP9861-R.

Ruijie overseas support therefore advised that there was no need to manually force the port to 2.5G in this environment:

This is an important example of why operational data is more valuable than assumption.

The customer saw a problem after manually selecting 2.5G.

The CLI showed that:

2.5G itself was already working successfully.

So the available evidence did not support the conclusion that the AP had a defective 2.5GbE port.

The CLI also changed how we interpreted the radios

The same show interface output exposed:

• Dot11radio 1/0
• Dot11radio 2/0
• Dot11radio 3/0
• Dot11radio 4/0
• Dot11radio 5/0

The record specifically showed Dot11radio 5/0 present and UP.

That reinforced the Radio 5 conclusion.

The Web GUI prevented the customer from treating it like a conventional SSID radio, but the device itself clearly contained and recognized the radio interface.

This is why our wireless AP troubleshooting process increasingly relies on comparing:

GUI state + CLI state + product role + client behavior

rather than trusting any single interface in isolation.

The Issues That Required Ruijie Engineering Escalation

By May 26-28, enough evidence had accumulated that part of the case could no longer be handled as ordinary Wi-Fi configuration.

Web-based radio settings continued returning errors.

Ruijie support acknowledged that the Web side might require further internal verification and began coordinating with development. The team stated that if the behavior was confirmed as a Web/software problem, a later software version could potentially become part of the resolution path.

The outstanding symptoms were then consolidated into a more structured list, including:

• FAT-mode behavior;
• inability to change some radio settings;
• channel/frequency saving problems;
• manual 2.5G behavior;
• Radio 5;
• 6 GHz.

There was also discussion about collecting the reported items for possible beta-firmware evaluation. 

Evidence Matrix

For example:

2.5GbE AUTO negotiation - Confirmed by CLI.

Radio 5 role - Explained by technical support.

6 GHz configuration/discovery behavior - Explained.

Password rejected after several hours - Observed.

Some FAT/Web radio behavior - Escalated.

This classification is deliberate.

The existence of an engineering escalation does not automatically mean that every item submitted with it was a confirmed firmware bug.

From Return Risk to a Working Wi-Fi 7 Network

By May 29, the conversation had changed considerably.

The customer was no longer simply trying to recover an unusable access point.

The RG-AP9861-R was operating as a Wi-Fi 7 access point and the discussion moved toward real wireless performance.

The customer provided several useful field measurements.

His wired Internet Speedtest baseline was approximately:

2350-2450 Mbps

The test client was a:

Samsung S25 Ultra

The phone was approximately:

2.5-3 meters from the AP

Reported Wi-Fi 7 Speedtest performance was approximately:

1400-1700 Mbps

These values came directly from the customer's field testing.

Another exchange recorded a relatively stable wired result around 2380 Mbps with the phone approximately 2.5 meters away. The customer reported that he had checked for less disturbed channels but was still seeing around 1600 Mbps or below in the wireless tests.

They are:

They are not:

The product page lists a much higher aggregate theoretical/peak wireless rate, but an aggregate multi-radio product rate is fundamentally different from the result obtained by a single smartphone performing an Internet Speedtest.

Comparing those values directly would create a misleading expectation.

The support discussion instead returned to real wireless variables:

• wired baseline;
• client capability;
• negotiated rate;
• AP/client position;
• channel conditions;
• channel bandwidth;
• interference;
• device orientation.

Ruijie support specifically advised establishing the maximum wired rate first and then testing wireless conditions such as position, channel and bandwidth.

That was a significant change from the situation several days earlier.

The case had moved from:

"Should this AP be returned?"

to:

"How should we evaluate and optimize its real Wi-Fi 7 performance?"

How Real Customer Feedback Improved Product and Support Knowledge

By the end of the main troubleshooting period, the customer had effectively become an early adopter providing detailed real-world product feedback.

On May 29, the recorded feedback included:

• Italian language support;
• French language support;
• German language support;
• Spanish language support;
• better Firefox radio-management compatibility;
• clearer 2.5G interface behavior;
• wireless download-performance investigation;
• easier Cloud onboarding without complicated WebCLI steps.

Not every item represented a defect.

Some were feature requests.

Some were documentation problems.

Some were UI or browser-compatibility concerns.

Others required technical investigation.

By this point, the customer was no longer simply reporting a failed wireless access point setup.

He had become a useful early adopter exposing:

usability + documentation + workflow + browser + configuration + field-performance gaps

that are difficult to discover from product specifications alone.

Firmware follow-up continued

The support history also continued beyond May.

On June 13, the records show discussion of the earlier firmware:

AP_RGOS11.9(6)W3B17_S1E16-233_11200904

The Ruijie technical engineer subsequently confirmed that a later software package was available and supplied:

AP_RGOS11.9(6)W5_S1E16-233_12140604_install.bin 

For current product research, readers can also review our Ruijie indoor Wi-Fi 7 access points or broader Ruijie wireless access points portfolio.

Those current products and software versions should not automatically be assumed to reproduce the behavior documented in this May 2025 deployment.

What This Case Changed in How We Support Enterprise Wireless Networks

Selling a new enterprise wireless access point is not the same as truly understanding how it behaves in the field.

A datasheet can tell us:

• radio architecture;
• supported Wi-Fi standards;
• Ethernet interfaces;
• theoretical wireless rates;
• PoE requirements;
• supported management modes.

It cannot tell us exactly what will happen when a real customer:

• changes management mode;
• uses a particular browser;
• places the AP into an existing IP addressing scheme;
• connects through a specific PoE++ switch;
• tests using a specific Wi-Fi 7 phone;
• manually changes Ethernet negotiation;
• restores a configuration backup;
• interprets an AI Radio shown in the GUI;
• or attempts Cloud onboarding for the first time.

This case changed the set of information we want to collect when supporting a new enterprise wireless product.

Instead of relying only on:

datasheet + specification + configuration guide

we increasingly want:

firmware + GUI + CLI + browser + region + client device + PoE environment + switch uplink + negotiation state + wireless security + management mode + cloud platform + recovery behavior + customer workflow

The case also reinforced several practical troubleshooting principles.

First:

Second:

Third:

Fourth:

And finally:

The most useful conclusion from this RG-AP9861-R deployment is therefore broader than one specific technical issue:

Every field deployment adds information that a product datasheet cannot provide.

Readers can explore more real-world network deployment and troubleshooting case studies covering design, migration and fault-isolation work across enterprise and carrier networks.

Resource

Case Evidence & Methodology

This case study is based on first-hand Network-Switch technical-support records from a real RG-AP9861-R customer deployment in Italy between May 23 and June 13, 2025.

The source material reviewed for this article includes:

• customer-support conversations;
• communication between Network-Switch personnel and Ruijie domestic support engineers;
• communication with Ruijie overseas technical support;
• remote troubleshooting sessions;
• customer-provided videos and screenshots;
• actual RG-AP9861-R Web CLI output;
• customer-observed wired and Wi-Fi 7 performance tests;
• configuration and management-mode troubleshooting records;
• software and firmware follow-up.

Evidence Snapshot

The original records contain customer identity, remote-access credentials, device identifiers, account information and private network data.

They are therefore not published in full.

Screenshots and CLI excerpts reproduced in this article have been sanitized to remove information that is unnecessary to the technical explanation.

We also distinguish evidence levels throughout the article.

A customer-reported symptom remains Observed unless it was independently reproduced or technically confirmed.

A behavior explained by Ruijie support is classified as Explained.

An issue submitted to development is Escalated, but not automatically a confirmed firmware defect.

Where the surviving record does not contain a definitive root-cause analysis, the conclusion remains Unconfirmed.

No missing test data, performance results or RCA conclusions have been reconstructed.

Primary Case Evidence

Network-Switch RG-AP9861-R Customer Support Case
Italy May 23-June 13, 2025

Internal primary-source evidence consists of nine support conversation exports, remote troubleshooting records, videos/screenshots, actual device Web CLI output, customer field-test observations and firmware follow-up.

Official Technical References

Ruijie RG-WLAN Series Access Points Web-Based Configuration Guide

https://www.ruijie.com/en-global/support/documents/slide_rg-wlan-series-access-points-rgos11-96w5-web-based-configuration-guide/

Ruijie Networks Support Documentation

https://www.ruijie.com/en-global/support/