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
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- Python
- Estrellas
- 141
- Forks
- 49
- Merge medio
- 7 h 54 min
- PR fusionados (30 d)
- 4
Descripción
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
- Authenticate successfully via
/cgi/json-requsing alogInaction. - Attempt to read the container node:
Device/DeviceInfo - Observe error:
XMO_UNKNOWN_PATH_ERR - Read individual leaf paths instead:
Device/DeviceInfo/ProductClass Device/DeviceInfo/InternalFirmwareVersion Device/DeviceInfo/ExternalFirmwareVersion Device/DeviceInfo/UpTime - 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/HostsReturns 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/*
- LAN:
Notable quirks observed:
- Multi-action
/cgi/json-reqrequests 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.
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
Comienza con get_device_info() y el flujo de solicitudes /cgi/json-req; después, reproduce el fallo del contenedor Device/DeviceInfo y las lecturas correctas de las hojas en el F@ST 5364. Define la finalización como la recuperación correcta de la información del dispositivo desde rutas de hojas compatibles, manteniendo resultados independientes a nivel de acción cuando se devuelve un error a nivel de solicitud.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- python
- Área
- api
- Tipo de issue
- Error
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Estado de actividad
- Estancado
- Claridad
- Bastante claro
- Aptitud para principiantes
- 45/100