iMicknl / iMicknl/python-sagemcom-api
TalkTalk Wi-Fi Hub (F@ST 5364) firmware SG4K100208: Device/DeviceInfo container blocked, leaf fallback works; Device/Hosts/Hosts works; DSL rates + throughput paths confirmed; request-level errors can mask per-action success
还没有人认领这个 Issue。
- 主要语言
- Python
- 星标
- 141
- 派生
- 49
- 平均合并
- 7 小时 54 分钟
- 30 天内合并 PR
- 4
描述
## Model information
| Key | Value |
|------------------|-------|
| Model name | F@ST 5364 (TalkTalk Wi-Fi Hub) |
| Hardware Version | F@ST 5364 |
| Software Version | External: SG4K100208 / Internal: 15.24.42_Prod |
## Describe the bug
On the TalkTalk-branded F@ST 5364, reading the `Device/DeviceInfo` container node fails with `XMO_UNKNOWN_PATH_ERR`, causing `get_device_info()` in python-sagemcom-api to raise an `UnknownPathException`.
However, individual leaf values under `Device/DeviceInfo/*` are readable and return valid data. This suggests the container is intentionally blocked while leaf access remains supported.
## To Reproduce
1. Authenticate successfully via `/cgi/json-req` using a `logIn` action.
2. Attempt to read the container node:
```
Device/DeviceInfo
```
3. Observe error:
```
XMO_UNKNOWN_PATH_ERR
```
4. Read individual leaf paths instead:
```
Device/DeviceInfo/ProductClass
Device/DeviceInfo/InternalFirmwareVersion
Device/DeviceInfo/ExternalFirmwareVersion
Device/DeviceInfo/UpTime
```
5. Observe valid values returned for all leaf paths.
## Expected behavior
`get_device_info()` should succeed on this model.
A possible approach is to fall back to querying known `Device/DeviceInfo` leaf values when the container node returns `XMO_UNKNOWN_PATH_ERR`, and construct a minimal device info object from those values.
## Screenshots
N/A – reproduced via API/XHR calls and browser console (`$.xmo.*`), not GUI interactions.
## Additional context
Other confirmed working paths on this model:
- Hosts:
```
Device/Hosts/Hosts
```
Returns a full list of host objects (MAC, IP, active state, interface type, etc.).
- DSL negotiated rates:
```
Device/DSL/Channels/Channel[@uid='1']/DownstreamCurrRate
Device/DSL/Channels/Channel[@uid='1']/UpstreamCurrRate
```
- Throughput counters without running a speed test:
- LAN:
```
Device/Ethernet/Interfaces/Interface[Alias="PHYx"]/Stats/*
```
- WAN:
```
Device/IP/Interfaces/Interface[Alias="IP_DATA"]/Stats/*
```
Notable quirks observed:
- Multi-action `/cgi/json-req` requests may return a request-level error even when individual actions succeed; action-level results should be evaluated independently.
- Some container nodes are blocked while their leaf children remain accessible (as seen with `Device/DeviceInfo`).
- SFP-related paths appear unsupported on this firmware and return errors.
All MAC addresses, IP addresses, auth tokens, nonces, and session identifiers have been redacted or replaced.
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 get_device_info() 和 /cgi/json-req 请求流程开始,然后在 F@ST 5364 上重现 Device/DeviceInfo 容器失败以及叶节点读取成功的情况。将完成定义为:从受支持的叶节点路径成功获取设备信息,并在返回请求级错误时保留独立的动作级结果。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- python
- 领域
- api
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 停滞
- 描述清晰度
- 基本清楚
- 新手友好度
- 45/100