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-queryurn: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.
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.xmland/tr64desc.xmlfor the device descriptors. https://github.com/mxschmitt/fritzbox_exporter/blob/d6d638b571ab2cb778d498273603c758d77bff81/pkg/fritzboxmetrics/fritzboxmetrics.go#L133 https://github.com/mxschmitt/fritzbox_exporter/blob/d6d638b571ab2cb778d498273603c758d77bff81/pkg/fritzboxmetrics/fritzboxmetrics.go#L149SSDP
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-queryurn: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.xmlhttp://fritz.box:49000/tr64desc.xmlhttp://192.168.178.1:5000/rootDesc.xmlOr 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.xmlis a resource from the root andsomething.xmlis 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:1urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1urn:schemas-upnp-org:service:WANIPConnection:1There'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.