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
Personne n'a encore pris cette issue.
- Langage dominant
- Python
- Étoiles
- 141
- Forks
- 49
- Merge moyen
- 7 h 54 min
- PR mergées (30 j)
- 4
Description
## 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.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par get_device_info() et le flux de requêtes /cgi/json-req, puis reproduisez l'échec du conteneur Device/DeviceInfo et les lectures réussies des feuilles sur le F@ST 5364. Définissez l'achèvement comme la récupération réussie des informations de l'appareil à partir des chemins de feuilles pris en charge, tout en préservant des résultats indépendants au niveau de l'action lorsqu'une erreur au niveau de la requête est renvoyée.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- python
- Domaine
- api
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100