硬件平台：mdc610 SDK: 1.99.101程序样例： dds_event_async_server_sample，dds_event_async_client_sample具体描述：  在做多进程间传输视频数据项目，视频yuv420数据一帧1920x1200 3M多，cm dds通信中的rawData默认是ara::core::Vector<UInt8>向量，传输效率低，延迟大，想配置dds mbuf 共享内存通信，零拷贝,提高效率，但客户端没收到服务端数据。dds_event_async_server_sample服务端发送数据配置如下：void ServerActivity::Act() { static int32_t sendCount = 1; // 分配Event内存 auto sampleCameraImage = skeleton_->CameraImageAsyncEvent.Allocate(); uint64_t ulTimestamp = 0,ulEndTimestamp=0; HMEV_GET_TIMESTAMP_US(ulTimestamp); // 填值 sampleCameraImage->frameType = sendCount; // 借用frameType传输数据包的index(1..100) sampleCameraImage->dataSize = 1024; // 1024仅作为示例，无实际意义 sampleCameraImage->imageFormat = "yuv_instance1"; // 右侧字符串仅作为示例，无实际意义 sampleCameraImage->width = 100; // 100仅作为示例，无实际意义 sampleCameraImage->height = 100; // 100仅作为示例，无实际意义 sampleCameraImage->header.stampHigh = 33; // 33仅作为示例，无实际意义 sampleCameraImage->header.stampLow = 44; // 44仅作为示例，无实际意义 sampleCameraImage->header.frameId = "test"; // 右侧字符串仅作为示例，无实际意义 sampleCameraImage->timestamp = ulTimestamp; int ret=halMbufAlloc(1024, &m_pMbuf); if(ret==0){ uint8_t *pData=nullptr; uint64_t len=0; if (halMbufGetDataPtr(m_pMbuf, reinterpret_cast<void **>(&pData), &len) != 0) { LOG_ERROR("camera_mviz halMbufGetDataPtr failed!"); } else { for(int i=0;i<5;i++) { if(pData) pData[i]=i; } } } else { LOG_ERROR("halMbufAlloc failed!"); } sampleCameraImage->rawData = reinterpret_cast<Mbuf*>(m_pMbuf); // 发送Event数据包 skeleton_->CameraImageAsyncEvent.Send(std::move(sampleCameraImage)); HMEV_GET_TIMESTAMP_US(ulEndTimestamp); int send_case_ms=(ulTimestamp-ulEndTimestamp)/1000; log_.LogInfo() << "CameraImageAsyncEvent send count: " << sendCount<<",send case(ms):"<<send_case_ms; if(m_pMbuf) halBuffFree(m_pMbuf); sendCount++; }dds_event_async_client_sample客户端接收回调数据配置如下void ClientActivity::CameraImageCallback() { log_.LogInfo() << "CameraImage event received."; proxy_->CameraImageAsyncEvent.GetNewSamples([this](ara::com::SamplePtr<EventAsyncImage const> ptr) { auto sample = ptr.Get(); uint64_t ulTimestamp = 0,ulEndTimestamp=0; HMEV_GET_TIMESTAMP_US(ulTimestamp); log_.LogInfo() << "receive data is: " << sample->frameType<<",case:"<<(ulTimestamp-sample->timestamp)/1000; // 提取Mbuf数据包 Mbuf *pMbuf = reinterpret_cast<Mbuf *>(sample->rawData); uint8_t *pData=nullptr; uint64_t len=0; if (halMbufGetDataPtr(pMbuf, reinterpret_cast<void **>(&pData), &len) != 0) { LOG_INFO("camera_mviz halMbufGetDataPtr failed!"); return; } halMbufGetDataLen(pMbuf, &len); if(pData) { LOG_INFO("recv data:%d %d %d %d",pData[0],pData[1],pData[2],pData[3]); } m_nMsgCnt++; HMEV_GET_TIMESTAMP_US(ulEndTimestamp); int time_case=(ulEndTimestamp-sample->timestamp)/1000; LOG_INFO("got data size:%d,case(ms):%d",sample->dataSize,time_case); }); }EventAsyncImage 结构体rawData定义为rawBuffer*类型struct EventAsyncImage { ::Int32 frameType{ 0 }; ::Int32 height{ 0 }; ::Int32 width{ 0 }; ::Int32 dataSize{ 0 }; ::rawBuffer *rawData{ nullptr }; ::String imageFormat; ::EventAsyncImageHeader header; ::UInt64 timestamp{ 0U }; /// };rm_share_group.yaml文件放在/opt/usr/app/1/gea/conf/rm下，其内容如下DEFAULT_MEM_GROUP:  dds_event_async_server_sample : arw  dds_event_async_client_sample : arw是否mbuf配置有问题？在main函数中都调用了ara::rm::RegisterHisiResource()和aclInit()

一、业务背景我们项目中收支记录、账本数据需高频并发写入系统 。此前，用户记账操作成功率低至 70%，大量用户因记账失败、体验差而流失，严重阻碍业务发展 二、原因分析 全量数据一次性提交，超出系统承载能力当用户批量录入多条记账记录（如导入账单、批量补记）时，前端未做分批处理，直接将所有数据（可能达数百条）通过单次请求提交至后端。后果：单条请求数据量过大（如 100 条记录的 JSON 体积超过 1MB），导致网络传输超时（尤其弱网环境下）；后端接口可能因 “单次请求数据量超限” 直接拒绝（如网关层设置请求体大小限制），或处理时内存占用激增，触发超时熔断未适配设备性能差异，固定逻辑引发低端机崩溃不同设备（如高端旗舰机 vs 入门级手机）的 CPU、内存、网络能力差异显著，但前端采用统一的处理逻辑缺乏操作进度反馈，用户误判失败批量记账时，前端未展示实时进度（如 “已完成 30%”），用户在等待过程中因 “无响应” 误以为操作失败：可能手动刷新页面或重复提交，导致重复请求冲突（如同一笔记录被提交两次），后端因 “数据重复” 返回失败；长时间无反馈触发用户焦虑，直接关闭页面，导致未完成的操作中断三、解决思路动态分批处理：针对全量数据一次性提交超出系统承载的问题，采用 “按需拆分、动态调整” 策略进度可视化与交互反馈：针对用户因无反馈而误判失败的问题，通过 “实时感知、明确反馈” 增强操作透明度异常处理与重试机制：针对网络波动、系统异常导致的写入失败，通过 “容错兜底、自动重试” 降低失败概率四、解决方案4.1 数据分批处理（基础分批逻辑）当用户触发大量记账数据录入操作时，利用 ArkTS 的异步任务调度能力，将数据按固定批次拆分。通过迭代数据数组，每次截取指定数量（初始 20 条）的数据作为一批，调用封装的写入方法逐批处理，避免一次性加载全量数据导致内存溢出或 UI 阻塞// 写入方法async function batchWriteAccountingData(data: AccountingDataItem[]): Promise<void> { const batchSize = 20; for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchData(batch); // 异步写入，避免阻塞主线程 }}// 记账明细interface AccountingDataItem { id: string; amount: number; type: 'income' | 'expense';}4.2 动态分批调整（结合设备状态）借助鸿蒙系统提供的 hidebug 模块获取设备内存占用信息，实时判断设备内存状态。定义内存阈值（需结合实际设备测试确定），动态调整每批数据量：内存充裕时增大批次（如 30 条）以加快处理；内存紧张时减小批次（如 15 条）import { hidebug } from '@ohos.hidebug';async function getDynamicBatchSize(): Promise<number> { const memoryUsage = hidebug.getNativeHeapAllocatedSize(); // 根据实际设备性能测试调整 const lowMemoryThreshold = 1024 * 1024 * 200; // 200MB const highMemoryThreshold = 1024 * 1024 * 500; // 500MB if (memoryUsage < lowMemoryThreshold) { return 30; } else if (memoryUsage > highMemoryThreshold) { return 15; } return 20;}async function dynamicBatchWrite(data: AccountingDataItem[]): Promise<void> { const batchSize = await getDynamicBatchSize(); for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchData(batch); }}4.3 进度可视化与交互反馈（UI 组件集成）在记账操作页面，使用 ArkTS 的 Progress 组件实时展示写入进度。通过计算已处理数据量与总数据量的比例，动态更新进度条数值。同时，结合 Toast 或弹窗反馈关键状态（“数据写入中”“写入完成”“网络异常重试” ），增强用户对操作流程的感知@Entry@Componentstruct AccountingWritePage { @State progressValue: number = 0; @State isWriting: boolean = false; private totalDataCount: number = 0; build() { Column() { Text('记账数据写入中') .fontSize(20) .margin({ bottom: 10 }); Progress({ value: this.progressValue, total: 100 }) .width(300) .height(20) .margin({ bottom: 20 }); if (this.isWriting) { Text(`已完成 ${this.progressValue.toFixed(1)}%`) .fontSize(14) .color(Color.Grey); } else { Button('开始写入') .onClick(async () => { this.isWriting = true; const data = await fetchAccountingData(); this.totalDataCount = data.length; await this.batchWriteWithProgress(data); this.isWriting = false; // 写入完成反馈 Toast.show({ message: '记账数据写入完成！' }); }); } } .padding(20) .width('100%') .height('100%') .justifyContent(FlexAlign.Center); } private async batchWriteWithProgress(data: AccountingDataItem[]): Promise<void> { const batchSize = await getDynamicBatchSize(); const totalBatches = Math.ceil(data.length / batchSize); let processedCount = 0; for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchData(batch); processedCount += batch.length; this.progressValue = (processedCount / this.totalDataCount) * 100; // 业务逻辑 await new Promise(resolve => {}); } }}4.4 异常处理与重试机制在分批写入过程中，捕获网络请求异常、系统写入失败等错误。通过设置重试次数（如 3 次），针对失败批次自动重试；若重试仍失败，记录失败数据并反馈给用户，支持手动触发重试或跳过失败项const MAX_RETRY_COUNT = 3;async function writeBatchDataWithRetry(batch: AccountingDataItem[], retryCount: number = 0): Promise<boolean> { try { await writeBatchData(batch); // 写入 return true; } catch (error) { if (retryCount < MAX_RETRY_COUNT) { // 重试 return writeBatchDataWithRetry(batch, retryCount + 1); } else { // 记录失败数据，可存入本地缓存待后续处理 saveFailedBatch(batch); console.error('写入失败，已达最大重试次数：', error); return false; } }}// 在分批写入循环中替换为带重试的方法async function dynamicBatchWrite(data: AccountingDataItem[]): Promise<void> { const batchSize = await getDynamicBatchSize(); for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchDataWithRetry(batch); }}五、方案总结本方案通过以下核心技术解决性能问题：动态分批处理技术，通过结合设备状态动态调整数据分批大小，形成一套灵活、高效的动态分批处理机制，可复用至其他需批量数据处理的业务场景，优化数据写

最近拜读了https://bbs.huaweicloud.com/blogs/450734这篇文章，里面讲解将ALL-reduce和GEMM融合的分块方式只切分M轴。因为通信任务调用的Hccl API要求分块数据内存连续，若按N轴切分，则每行数据都被切断，导致通信数据的内存不连续，不满足通信要求；若按M轴切分，则每行数据都是内存连续的，满足通信要求。看完后有两个疑问想请教下：文章里提到只对M轴切分，是否可以认为只对左矩阵切分，每个GPU拿到部分左矩阵数据，而右矩阵不切分，每个GPU拿到完整的右矩阵数据若只对M轴切分，则多卡通信汇聚数据的时候，理论上不需要将多卡的数据进行求和，这里为啥需要使用all-reduce而不是all-gather（我知道目前也是支持all-gather与gemm融合的，只不过all-reduce的这个分块方式令我有些困惑）由于我刚接触该融合特性，如果上面的理解有不到位的地方还请指正，多谢！

如题，我想通过AT指令来做SLE通讯，但是关于ws63 SLE AT指令，开发手册里所有SLE AT指令的响应都只有OK或ERROR，对于查询指令我该怎么获取查询后的数据 

我司自主研发的短信平台，从事于电信增值业务其中包含：行业通知类短信，验证码，视频彩信，5G消息，语音短信，在短信终端、数据传输等电信增值业务领域属同行业领先。三网短信服务，包括：验证码（发送速度3-5秒）、会员营销（提供多条备用通道）、通知（到达率99.9%）、消费（价格优惠）、订单（提拱及时状态）、祝福（提拱成功计费）、视频彩信，5G消息，语音短信等。截止目前，渠道代理商和技术合作伙伴达到30余家，产品覆盖全国100余个城市的20余个行业，超过5万家商企客户。其中包括：税务单位、医院、学校、教育局、12345、水务单位、供暖公司、大型软件公司等。实力雄厚，价格优惠，期待与您的合作！联系人：张经理    联系电话：17301310195

您好，使用环境为：AR502H + iCUBE-PLC100 + PLC-IS-1，以下是我从STA上导出的日志，多个头端均设定白名单，想请教如下几个问题:PLC STA日志：2025-02-03 01:07:15 Info[tman]:set sys time 2025-02-03 01:07:151970-01-01 00:00:00 Info[dev]:version: V200R021C10SPC100B1302024-07-24 23:59:59 Info[fanm]:start soft tf, set started2024-07-24 23:59:59 Notice[fanm]:plcmgr init successfully2024-07-25 00:00:00 Notice[fanm]:failed to get RF MAC address: 12024-07-25 00:00:00 Notice[fanm]:Without RF channel2024-07-25 00:00:06 Notice[fanm]:PLC connect2024-07-25 00:00:07 Info[fanm]:stop soft tf, set unstarted2024-07-25 00:00:07 Info[fanm]:set mac profile type by beacon success, type=12024-07-25 00:00:07 Notice[fanm]:PLC connect2025-02-03 04:28:23 Info[fanm]:recover net config successfully: host=fe80::02a4:00ff:fe07:28412025-02-03 04:28:23 Notice[fanm]:PLC authentication passed and online2025-02-03 04:28:24 Info[AUTH]:The 4-thread auth server has been created1970-01-01 00:00:00 Info[dev]:version: V200R021C10SPC100B1302024-07-24 23:59:59 Info[fanm]:start soft tf, set started2024-07-24 23:59:59 Notice[fanm]:plcmgr init successfully2024-07-25 00:00:00 Notice[fanm]:failed to get RF MAC address: 12024-07-25 00:00:00 Notice[fanm]:Without RF channel2024-07-25 00:00:32 Err[fanm]:sta association failed: nid=0xbf588a, freq=15, reason=1, cco mac=00:a4:00:11:53:412024-07-25 00:00:37 Err[fanm]:sta association failed: nid=0x857442, freq=15, reason=1, cco mac=00:a4:00:07:12:412024-07-25 00:01:00 Err[fanm]:sta association failed: nid=0x7ee2aa, freq=15, reason=1, cco mac=00:a4:00:07:27:412024-07-25 00:01:10 Err[fanm]:sta association failed: nid=0x65c7d5, freq=15, reason=1, cco mac=00:a4:00:07:18:412024-07-25 00:01:26 Err[fanm]:sta association failed: nid=0x8ac2c8, freq=15, reason=1, cco mac=00:a4:00:11:25:412024-07-25 00:02:07 Err[fanm]:sta association failed: nid=0xa91664, freq=15, reason=1, cco mac=00:a4:00:11:54:412024-07-25 00:03:00 Err[fanm]:sta association failed: nid=0x3f99a3, freq=15, reason=1, cco mac=00:a4:00:11:76:412024-07-25 00:09:36 Err[fanm]:sta association failed: nid=0x723f20, freq=15, reason=1, cco mac=00:a4:00:11:56:412024-07-25 00:14:36 Err[fanm]:sta association failed: nid=0xc5323e, freq=15, reason=1, cco mac=00:a4:00:11:60:412024-07-25 00:16:57 Err[fanm]:sta association failed: nid=0xee125e, freq=15, reason=1, cco mac=00:a4:00:10:90:412024-07-25 00:27:13 Err[fanm]:sta association failed: nid=0x3, freq=1, reason=1, cco mac=00:a4:00:07:12:412024-07-25 00:39:58 Err[fanm]:sta association failed: nid=0x3, freq=1, reason=1, cco mac=00:a4:00:07:24:412024-07-25 00:40:33 Err[fanm]:sta association failed: nid=0xd, freq=1, reason=1, cco mac=00:a4:00:07:05:412024-07-25 00:40:41 Err[fanm]:sta association failed: nid=0x3, freq=1, reason=1, cco mac=00:a4:00:11:60:412024-07-25 00:53:11 Notice[fanm]:PLC connect2024-07-25 00:53:12 Notice[fanm]:PLC connect2024-07-25 00:53:16 Info[fanm]:stop soft tf, set unstarted2024-07-25 00:53:16 Info[fanm]:set mac profile type by beacon success, type=12025-02-03 07:22:23 Info[fanm]:recover net config successfully: host=fe80::02a4:00ff:fe07:28412025-02-03 07:22:24 Notice[fanm]:PLC authentication passed and online2025-02-03 07:22:24 Info[AUTH]:The 4-thread auth server has been created[admin@huawei internal_storage]$ 问题1：在相同的环境下，且多个CCO均设定白名单，为什么STA第一次入网和第二次入网时，STA两次接入申请请求CCO节点会有这么大的差别，以至于第二次入网上线时间晚40分钟呢？问题2：在第二次入网中，STA在00:00:37申请接入【cco mac=00:a4:00:07:12:41】后，因CCO设定白名单接入时被拒绝，请问为什么在00:27:13还能再次申请呢？STA申请接入CCO的运行规则是怎样的呢？问题3：请问nid字段代表什么意思呢，为什么nid=0x3会有3个相同的呢？问题4：请问freq字段代表什么意思呢，freq=15和freq=1有什么差别呢？freq取值范围多大？内部是如何选择的呢？

深度数据包检测 (DPI) 技术是一种能够深入分析和控制网络流量的技术，其检测粒度达到应用层，可以识别和控制各种应用协议，如HTTP、FTP、DNS等。DPI技术广泛应用于网络安全、网络优化、业务运营等领域，能够帮助企业提高网络性能、保障网络安全、提升用户体验。 DPI技术的工作原理是对网络流量进行深入的分析和控制。当网络流量经过DPI设备时，设备会对流量进行深度分析，识别出流量的应用协议，然后根据预设的策略对流量进行控制，如允许、限制或阻断等。  例如，在网络安全方面，通过对网络流量进行深度分析，DPI可以实时检测和防范各种网络攻击，如DDoS攻击、网络钓鱼等。在网络优化方面，DPI可以识别和控制各种应用层协议，有效优化网络资源，提高网络性能。   DPI技术的应用对于企业和个人都有着重要的意义。对于企业来说，DPI技术可以帮助他们提高网络性能、保障网络安全、提升用户体验，从而提高企业的运营效率和竞争力。对于个人来说，DPI技术可以保护他们的网络安全，避免网络攻击和网络钓鱼等安全威胁，提高他们的网络使用体验。  DPI技术还可以用于构建用户画像。在当今这个信息爆炸的时代，品牌了解自己的用户变得越来越重要。用户画像中包含了用户的年龄、性别、地域、社交关系、兴趣偏好、触媒习惯、行为特征、消费习惯等信息，可以帮助品牌深入了解目标用户群体，洞察用户真正的动机和行为。这对于品牌来说，具有重要的营销和产品设计意义。  

topic定义为：$oc/devices/{device_id}/sys/messages/down错误原因也搜不到

首先我在设备1端上报消息，设置数据转发的规则是设备消息，消息上报，资源空间选择的所有资源空间。然后我在设备2端进行订阅。数据转发规则设置目标topic是设备2的平台下发消息topic。目标是MQTT队列但是我在调试界面只能看到流转规则触发成功，但是并没有出现消息下发的情况，我的接收端也接受不到。同时我直接用云平台进行的消息下发就是能接收到消息的。

使用c语言ebpf和int _sockops(struct bpf_sock_ops *ctx)函数，map随意我是初学者，死活写不出来，求教大佬们。

您好，我们想通过容器内的APP程序查询获取到通信链路的中继等级、衰减和信噪比等参数，实现对通信链路状态的监控，但查阅了《边缘计算网关二次开发指南（AR502H-CN）》，未找到相关方法，请专家提供技术指导，感谢

【问题来源】中讯网联    【问题简要】释放会话返回160001【问题类别】座席【AICC解决方案版本】【AICC版本：AICC 22.100.0】UAP9600 V1R5C00 SPC102【CTI版本：ICDV300R008C25SPC017】【期望解决时间】【尽快】【问题现象描述】 前提：200在线坐席，1400通会话的并发异常点：调用华为侧呼叫释放接口->cid:link_0出现异常：返回code:160001，mag:平台通信异常异常callId：1689082675-17799338时间点：2023/07/18 12：17：29偶现问题，参数配比基本一致      

【问题来源】中讯网联    【问题简要】ideploy安装失败【问题类别】ideploy安装【AICC解决方案版本】【AICC版本：AICC 22.100.0】Breeze iDeploy V100R003C06 UAP9600 V1R5C00 SPC102【期望解决时间】【尽快】【问题现象描述】        在suse12安装iDeploy V100R003C06，按产品文档指导安装install.sh时提示：[2023-7-18 15:04:05][root][install.sh][INFO] Begin to install ideploy. [2023-7-18 15:04:05][root][install.sh][INFO] Begin to check env. ideploy home path:/home/ideploy must be empty,but some files exist,delete it?(yes/no):yes [2023-7-18 15:04:06][root][install.sh][INFO] Success to delete file. [2023-7-18 15:04:06][root][install.sh][INFO] ideploy_listen_ip is empty, read user input. Please input the local listening IP address(can not input 0.0.0.0 and 127.0.0.1):10.69.187.175 [2023-7-18 15:04:13][root][install.sh][INFO] Get ideploy listen ip 10.69.187.175 [2023-7-18 15:04:13][root][install.sh][INFO] Begin to check port. [2023-7-18 15:04:13][root][install.sh][INFO] Success to check port. [2023-7-18 15:04:13][root][install.sh][INFO] Begin to create group:ideploygroup. [2023-7-18 15:04:13][root][install.sh][INFO] Group:ideploygroup exists. [2023-7-18 15:04:13][root][install.sh][INFO] Begin to create user:ideploy. [2023-7-18 15:04:13][root][install.sh][INFO] User:ideploy exists. [2023-7-18 15:04:13][root][install.sh][INFO] Success to check env. [2023-7-18 15:04:13][root][install.sh][INFO] Begin to install ideploy. [2023-7-18 15:04:14][root][install.sh][INFO] Success to install ideploy. [2023-7-18 15:04:14][root][install.sh][INFO] Begin to start ideploy. [2023-7-18 15:04:14][root][startup.sh][INFO] Begin to check space. [2023-7-18 15:04:14][root][startup.sh][INFO] End to check space. [2023-7-18 15:04:14][root][install_jre][INFO] [main] Begin to install jre version. [2023-7-18 15:04:14][root][install_jre][INFO] [main] Begin to uncompress jre package. [2023-7-18 15:04:14][root][install_jre][ERROR] [main] Uncompress jre package failed. install jre failed! [2023-7-18 15:04:14][root][install.sh][ERROR] Failed to start ideploy,please check log:/home/ideploy/logs/ideploy_server_status.log请问什么原因导致[ERROR] [main] Uncompress jre package failed，帮分析怎么解决，谢谢！

1.Q: CPE下挂的PC DHCP拿不到地址？A：CPE关联的AP的上行交换机接口，检查放通的vlan，不可以放通cpe-tunnel的vlan2.Q: CPE关联上之后，在AC上display station all查看发现协商速率只有几兆？A: 需要关闭BSS COLOR，因为我们AP和CPE支持的bss color值不一致，可关闭该功能规避。3.Q: CPE下挂STA 上行链路不稳定，ping上层网关时通时不通？A： 检查CPE-TUNNEL中的vlan配置，双发选收配置下2.4G和5G的cpe-tunnel的pvid vlan不可以一样，frer vlan必须一样。​4.Q：CPE关联成功后，过一段时间就掉线重新关联？A: 检查CPE的iconnect开关，环境里没有iconnect服务器的话，需要关闭该功能才能正常使用。5.Q:CPE和AC/AP建隧道，跑极限性能掉坑或者跑流性能低？A:需要配置MTU 1700，在AP系统模板、AP的capwap vlan和CPE的service-vlan都要配置MTU 17006.Q: CPE与AP建隧道，静止状态下，下挂终端ping上层服务器，ping一晚上，ping包40000，丢包2-20？A: 根据丢包具体时间查看AC是否有该CPE的掉线记录(dis station offline-record all)。查看AC是否开启调优(dis wlan calibrate global configuration / dis channel switch-record all)查看信道是否改变。如果时间一致，就是调优的时候信道切换导致CPE掉线，关闭调优功能可以解决。7.Q: CPE与AP建隧道，AC上执行dis cpe-tunnel remote-station all查看下挂终端设备数量与真实数量不一致?A:AP上查询的终端表项是实时的，但是AC需要等AP同步过来（大概5min），所以AC上的查询结果可能与实际不一致。8.Q:R19C10版本AP，对接九联CPE，CPE关联psk信号失败？A:R19版本AP有问题，升级可解。9.Q:CPE测试极限性能，跑流只有几十兆，无法达到规格？A:如果是用的转接头测试，建议更换转接头尝试，或者更换电脑和网线。10.Q:CPE下挂STA可以ping通百度的ip地址，但是打不开百度网页？     A:1.检查DNS服务器是否可达，配置是否正确。2.检查该电脑的其他网卡配置，如果不用可以先禁用其他网卡。11.Q:CPE下挂STA和上层服务器通讯，网络中一直存在丢包？     A:检查下CPE是否开启漫游，并且漫游阈值设置不合理，导致CPE一直在AP间反复漫游。如果实际使用不需要漫游可以关闭漫游开关，如果需要漫游可以根据现场情况调整漫游阈值。

【问题来源】北京【问题简要】WAS配置助手密码修改之后 再次登录提示密码失败， 如何重新修改密码【问题类别】【AICC】【AICC解决方案版本】【AICC可选择版本：AICC 22.100.0】【问题现象描述】WAS配置助手密码修改之后 再次登录提示密码失败， 如何重新修改密码