Master #1

2026-07-20T14:44:45+08:00

cnbugs commented

2026-07-20 14:44:45 +08:00

No description provided.

cnbugs added 4 commits 2026-07-20 14:44:45 +08:00

fix(snmp): ARP表缺少发现时间字段，在get_arp_table返回值中添加last_seen和discovered_at bd68abee93

feat(scan): 增强MAC厂商识别和主机名自动发现 ccd7fbe2f0

- MAC厂商: 替换硬编码OUI_MAP为mac_vendor_lookup库(IEEE OUI官方数据库)
- 主机名发现新增NetBIOS广播(nmblookup),支持Windows/SMB设备
- 综合扫描支持enable_netbios参数
- 新增NetBIOS主机名发现API端点
- 扫描时自动补全缺失厂商(有MAC无vendor时自动识别)

feat(ips): 批量补全厂商功能 + MAC厂商替换为IEEE OUI数据库 9e34f6f0f9

前端:
- IPs.vue: 新增「补全厂商」按钮，选中网段后一键补全
- scanApi: 新增 batchFillVendor/batchDiscoverHostname + enable_netbios 参数

后端:
- enhanced_scan.py: 新增 POST /scan/batch/vendor 批量补全厂商端点
- enhanced_scan.py: 新增 POST /scan/batch/hostname 批量发现主机名端点
- scan_tasks.py: 透传 enable_netbios 参数

readme bca0da7c7d

cnbugs added 1 commit 2026-07-20 14:46:56 +08:00

add file 845fefd6cf

cnbugs added 1 commit 2026-07-20 17:35:13 +08:00

feat(scripts): add backfill_vendor.py 1a3c2d15c8

一次性运维脚本：对 mac_address 有值但 vendor/hostname 为空的 IP，
重新调用 EnhancedScanService.get_mac_vendor (基于 IEEE OUI 数据库)
和 reverse_dns_lookup 回填字段，不需重新扫描。

解决场景：升级前 mac-vendor-lookup 库未装、或扫描时 vendor
字段因 bug 未写入。

- backend/scripts/backfill_vendor.py: 主脚本，支持 dry-run / --with-hostname / --limit
- backend/scripts/README.md: 用法、参数、故障排查

cnbugs added 1 commit 2026-07-23 13:14:08 +08:00

add jose 5b93e4536f

cnbugs added 13 commits 2026-07-23 15:43:22 +08:00

feat(python3.10): 适配 Python 3.10 并修复 SNMP 问题 a8e764b102

修改内容：
1. 修复 SNMP 凭据显示问题：确保设备列表返回 snmp_credential_id
2. 修复清除 SNMP 凭据功能：新增 clear_snmp_credential 参数
3. 前端适配：处理清除凭据时的参数转换
4. 更新 requirements.txt：添加 Python 3.10 兼容说明和 typing-extensions
5. 添加 PYTHON_3_10_COMPATIBILITY.md 兼容性说明文档

验证：
- 所有代码无 Python 3.11 特有语法
- 依赖包版本均支持 Python 3.10
- typing-extensions 提供向后兼容支持

fix(deps): 修复 pysnmp 兼容性问题 e0cba105b6

问题原因:
- pysnmp==7.1.15 使用已废弃的 asyncio.coroutine 装饰器
- 该装饰器在 Python 3.11 中被完全移除，导致导入失败

解决方案:
- 替换为 pysnmp-lextudio==5.0.31
- 这是社区维护的分支，兼容 Python 3.6+
- API 完全兼容，无需修改业务代码

验证:
- Python 3.10 & 3.11 均可正常导入
- FastAPI 应用可正常加载 (95 routes)
- SNMPService.OID_SYS_DESCR 可正常访问

fix(deps): 修复 pyasn1 版本冲突问题 f66e4d41c9

问题原因:
- pyasn1>=0.5.0 移除了 pyasn1.compat.octets 模块
- python-jose==3.5.0 强制要求 pyasn1>=0.5.0
- 形成版本冲突，导致 pysnmp 无法导入

解决方案:
- pyasn1==0.4.8 (保留 compat.octets 的版本)
- pyasn1-modules==0.2.8 (配套版本)
- python-jose[cryptography]==3.3.0 (兼容 pyasn1 0.4.8)

验证:
- Python 3.10 & 3.11 均可正常导入
- FastAPI 应用可正常加载 (95 routes)

fix(frontend): 修复 vite 命令冲突问题 ebb04f9ad8

问题原因:
- 系统 PATH 中有另一个也叫 'vite' 的 Qt GUI 程序
- 优先级高于 npm 的 vite，导致 npm run dev 调用了错误的程序
- 出现 Qt X11 显示相关的错误

解决方案:
- 直接使用 node 调用 vite 的完整路径
- 避免依赖 PATH 解析，确保调用正确的 vite

验证:
- node node_modules/vite/bin/vite.js --version
  ✅ vite/5.4.21 linux-x64 node-v23.11.1

fix(frontend): 修复 Vite 缓存过期导致 element-plus 入口解析失败 8a94f535de

问题原因:
- Vite dev server 长时间运行(跨天)后 deps 缓存过期
- import-analysis 阶段无法解析 element-plus 包入口
- 报错: Failed to resolve entry for package "element-plus"

解决方案:
- vite.config.js 添加 optimizeDeps.include 显式预构建 element-plus 等核心依赖
- package.json 添加 predev 脚本, npm run dev 前自动清 .vite 缓存
- 防止其他服务器 git pull 后同样踩坑

fix(frontend): 撤回 optimizeDeps.include 避免 element-plus 解析失败导致启动崩溃 6076e174d5

问题原因:
- 上一次提交添加的 optimizeDeps.include 让 Vite 在启动阶段
  就硬解析 element-plus, 包安装不完整时直接崩 (服务器起不来)
- predev 脚本每次清缓存, 如果源包有问题则重建必然失败

修正:
- 移除 optimizeDeps.include, Vite 自动发现预构建即可
- predev 改为可选的 dev:clean 脚本, 不影响正常启动
- start.sh 加固: 检查 element-plus/es/index.mjs 是否存在
  不存在则自动 npm install

影响范围:
- 其他服务器 git pull 后, start.sh 会自动检测并安装缺失依赖
- 正常 npm run dev 不再每次清缓存, 启动更快

fix(frontend): 修复 element-plus 解析失败问题 8b1df674ec

问题原因:
- element-plus 2.14.x 的 package.json exports 包含 ./*: ./ 通配符
- Vite 5.x 的 import-analysis 在某些场景下无法解析该 exports 配置
- 新机器 git pull + npm install 后 Vite 缓存为空，首次预构建可能失败
- 报错: Failed to resolve entry for package 'element-plus'

解决方案:
1. vite.config.js resolve.alias 添加 element-plus 显式 fallback 路径
   即使 exports 解析失败也能直接定位到 es/index.mjs
2. start.sh 启动前自动清理 .vite 缓存，避免过期缓存问题
3. start.sh 失败自动重试+清缓存机制，提高首次启动成功率

fix(snmp): 修复异步函数同步调用导致'coroutine object is not an iterator'错误 094d2cc112

问题原因:
- pysnmp.hlapi.asyncio 的 getCmd/bulkCmd/nextCmd 都是 async def 协程函数
- 返回的是 coroutine 对象，需要用 await 获取结果
- 原代码用 next() 或 for...in 同步迭代协程对象，报错:
  'coroutine' object is not an iterator

解决方案:
1. snmp_service.py: 所有 SNMP 操作改为 async def
   - test_connection(): getCmd 改为 await getCmd()
   - get_arp_table(): bulkCmd 改为 await bulkCmd()
   - get_mac_address_table(): bulkCmd 改为 await bulkCmd()
   - get_interfaces(): bulkCmd 改为 await bulkCmd()
   - poll_device(): 所有子调用加 await
2. api/v1/snmp.py: API 路由改为 async def + await

bulkCmd await 后返回 (errorIndication, errorStatus, errorIndex, varBindTable)
其中 varBindTable 是列表的列表（table 形式），需双层循环解析

fix(frontend): 移除 element-plus alias 防止 CSS 路径解析失败 ee0552f837

问题原因:
- 上次提交在 vite.config.js resolve.alias 中将 element-plus
  直接映射到 es/index.mjs 文件路径
- 这导致 import 'element-plus/dist/index.css' 时，
  Vite 拼接路径为 es/index.mjs/dist/index.css，文件不存在
- 报错: Failed to resolve import 'element-plus/dist/index.css'

解决方案:
- 移除 element-plus 的 resolve.alias 映射
- 包名保留为包名，Vite 的 node_modules 解析机制可正确处理
  element-plus 的 JS 入口和 CSS 路径
- start.sh 已有清缓存+自动重试机制兜底

feat(mac-vendor): 本地 OUI 数据库替代在线查询，修复厂商识别失败 05cd71ca1a

问题原因:
- mac_vendor_lookup 库依赖从 IEEE 官网在线下载 OUI 数据库
- 其他机器无网络或网络不通时，内置精简版数据库不全
- 导致 SNMP 扫描到 MAC 地址后无法识别厂商

解决方案:
1. 从 IEEE OUI 官方数据库下载完整数据 (39782 条记录)
   保存为 backend/app/data/oui.txt 纳入版本管理
2. 修改 EnhancedScanService.get_mac_vendor()，查询顺序:
   1️⃣ 本地 OUI 数据库（免网络、高性能）
   2️⃣ mac_vendor_lookup 在线库（回退）
   3️⃣ 硬编码常用厂商映射（最终回退）
3. start.sh 启动时检测 OUI 文件是否存在，不存在自动下载
4. 支持 AA:BB:CC、AABBCC、aa-bb-cc、001c.14aa.bbcc 多种 MAC 格式

fix(network): 修复网段 total_ips 包含网络地址和广播地址的问题 13c457acb3

问题原因:
- calculate_total_ips 使用 network.num_addresses 计算总IP数量
- 该值包含网络地址（第一个IP）和广播地址（最后一个IP）
- 而 _create_ip_addresses 使用 hosts() 生成IP列表，排除这两个地址
- 导致 total_ips 比实际存储的IP记录多2个
- 例: /24 显示 256 个IP，实际只有 254 条记录

解决方案:
1. calculate_total_ips 改为 num_addresses - 2（排除网络地址和广播地址）
2. 对于 /31 /32 等没有网络/广播地址的网段，特殊处理
3. 提供 fix_network_total_ips.py 迁移脚本修复已有数据

fix(mac-vendor): 修复 OUI 数据库 key 格式不匹配导致永远查不到厂商 934b604b65

问题原因:
- oui.txt 中的 key 格式为 AABBCC（无冒号，6位十六进制）
- 代码中提取的 oui = mac[:8] 是 AA:BB:CC（带冒号，8字符）
- db.get(oui) 永远匹配不到，且回退的遍历逻辑在4万条字典上
  每次查都全扫描，性能极差

解决方案:
- 提取 OUI 后去掉冒号再查询：oui.replace(':', '')
- 直接 db.get() 精确匹配，O(1) 时间复杂度

fix(snmp): 修复 SNMP 采集 ARP 表时只补 MAC 不补厂商的问题 11d830b496

问题原因:
- snmp_service.py get_arp_table 第267行条件为
  if ip_addr and not ip_addr.mac_address:
- 只给原本没有 MAC 的 IP 设置 MAC + 厂商
- 如果 IP 已有 MAC（来自 Ping/ARP 扫描）但没有 vendor，
  则永远不会补全厂商

解决方案:
- 拆分为两个 if:
  1. if not ip_addr.mac_address: 写入 MAC
  2. if not ip_addr.vendor and ip_addr.mac_address: 补全厂商
- 确保已有 MAC 但无厂商的 IP 也能被补全
- 已有 backfill_vendor.py 脚本可批量回填历史数据

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin master:master

git checkout master

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AI-Agent/ipam#1