You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TL;DR, I think the current implementation can support non-fritzbox modems fairly quickly.
Sharing some info that I have.
Scrolling through the code, most of it uses UPnP's intended workflow to gather data.
However one main issue stops it from being generic: hardcoding /igddesc.xml and /tr64desc.xml for the device descriptors.
The typical UPnP approach would be to do an SSDP query, matching ST urn:schemas-upnp-org:device:InternetGatewayDevice:1.
My ARRIS modem then reports http://192.168.178.1:5000/rootDesc.xml.
Be sure to try it yourself, ssdp-query urn:schemas-upnp-org:device:InternetGatewayDevice:1.
Afaik, service discovery is not normally the job of an exporter.
Rather I would suggest to accept the URLs of a device descriptor, instead of separate host + port + hardcoded path.
Users could set their target to:
http://fritz.box:49000/igddesc.xml
http://fritz.box:49000/tr64desc.xml
http://192.168.178.1:5000/rootDesc.xml
Or whatever else their SSDP query returns. Very similar to the http blackbox exporter.
Service base URL
SCDP and Control URLs are used here, which are typically relative. According to the UPnP spec, they follow RFC3986 section 5. In short that means it's the same as webpages, /something.xml is a resource from the root and something.xml is a sibling to the current path.
For compatibility we shouldn't use sprintf for this, as we have func (*URL) ResolveReference. (Note the mention of the same RFC)
There's other worthwhile data in these specs. Such as WANIPConnection.ExternalIPAddress (required) or that WANCommonInterfaceConfig.GetAddonInfos is non-standard and other devices may need individual GetTotalBytesSent, GetTotalBytesReceived, etc. actions to fetch this.
The text was updated successfully, but these errors were encountered:
TL;DR, I think the current implementation can support non-fritzbox modems fairly quickly.
Sharing some info that I have.
Scrolling through the code, most of it uses UPnP's intended workflow to gather data.
However one main issue stops it from being generic: hardcoding
/igddesc.xml
and/tr64desc.xml
for the device descriptors.fritzbox_exporter/pkg/fritzboxmetrics/fritzboxmetrics.go
Line 133 in d6d638b
fritzbox_exporter/pkg/fritzboxmetrics/fritzboxmetrics.go
Line 149 in d6d638b
SSDP
The typical UPnP approach would be to do an SSDP query, matching
ST urn:schemas-upnp-org:device:InternetGatewayDevice:1
.My ARRIS modem then reports
http://192.168.178.1:5000/rootDesc.xml
.Be sure to try it yourself,
ssdp-query
urn:schemas-upnp-org:device:InternetGatewayDevice:1
.Afaik, service discovery is not normally the job of an exporter.
Rather I would suggest to accept the URLs of a device descriptor, instead of separate host + port + hardcoded path.
Users could set their target to:
http://fritz.box:49000/igddesc.xml
http://fritz.box:49000/tr64desc.xml
http://192.168.178.1:5000/rootDesc.xml
Or whatever else their SSDP query returns. Very similar to the http blackbox exporter.
Service base URL
SCDP and Control URLs are used here, which are typically relative. According to the UPnP spec, they follow RFC3986 section 5. In short that means it's the same as webpages,
/something.xml
is a resource from the root andsomething.xml
is a sibling to the current path.For compatibility we shouldn't use sprintf for this, as we have
func (*URL) ResolveReference
. (Note the mention of the same RFC)Available metrics
The upnp.org services are outlined here: https://openconnectivity.org/developer/specifications/upnp-resources/upnp/internet-gateway-device-igd-v-2-0/
The Arris modem supports:
urn:schemas-upnp-org:service:Layer3Forwarding:1
urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
urn:schemas-upnp-org:service:WANIPConnection:1
There's other worthwhile data in these specs. Such as WANIPConnection.ExternalIPAddress (required) or that WANCommonInterfaceConfig.GetAddonInfos is non-standard and other devices may need individual GetTotalBytesSent, GetTotalBytesReceived, etc. actions to fetch this.
The text was updated successfully, but these errors were encountered: