Script doesn't like a default/unset value about virgin-media-hub3

[KarlJorgensen]

Interesting. Looks like your router returns 'Qkl9' for a couple of SNMP attributes which are expected to contain IP addresses!

My router is the same hardware and firmware version, but does not exhibit that...

To help diagnose this, would you mind posting the output of the following commands:

hub property-get wan_current_ipaddr_ipv4
hub snmp-get 1.3.6.1.4.1.4115.1.20.1.1.1.7.1.3.1
hub snmp-walk 1.3.6.1.4.1.4115.1.20.1.1.1.7.1
hub property-get ddns_address
hub snmp-get 1.3.6.1.4.1.4115.1.20.1.1.4.18.7.0

(feel free to redact the responses if necessary, but if you do so, please make a note of it)

[InternalLoss]

Sure!

billy@Billys-MacBook-Pro virgin-media-hub3 % python3 hub property-get wan_current_ipaddr_ipv4
python3 hub snmp-get 1.3.6.1.4.1.4115.1.20.1.1.1.7.1.3.1
python3 hub snmp-walk 1.3.6.1.4.1.4115.1.20.1.1.1.7.1
python3 hub property-get ddns_address
python3 hub snmp-get 1.3.6.1.4.1.4115.1.20.1.1.4.18.7.0
Traceback (most recent call last):
  File "hub", line 611, in <module>
    main()
  File "hub", line 606, in main
    args.func(hub, args)
  File "hub", line 411, in property_get
    propvalue = getattr(hub, prop)
  File "/Users/billy/Downloads/virgin-media-hub3/snmp.py", line 612, in __get__
    return self._translator.pyvalue(RawAttribute.__get__(self, instance, owner))
  File "/Users/billy/Downloads/virgin-media-hub3/snmp.py", line 373, in pyvalue
    raise ValueError("Value '%s' is not an SNMP IPv4Address" % snmp_value)
ValueError: Value 'Qkl9' is not an SNMP IPv4Address
1.3.6.1.4.1.4115.1.20.1.1.1.7.1.3.1 = Qkl9
{
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.10.2": "0",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.11.2": "-1",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.12.2": "-1",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.2.1": "1",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.2.2": "2",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.2.3": "4",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.3.1": "Qkl9",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.3.2": "$00000000000000000000000000000000",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.3.3": "$00000000000000000000000000000000",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.4.1": "21",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.4.2": "0",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.5.1": "1",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.5.2": "2",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.6.1": "$516b6801",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.6.2": "$fe8000000000000002015cfffe79d847",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.7.1": "1",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.7.2": "1",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.8.1": "$fffff800",
  "1.3.6.1.4.1.4115.1.20.1.1.1.7.1.9.2": "$00000000000000000000000000000000"
}
Qkl9 is not an SNMP representation of an IP address!?
1.3.6.1.4.1.4115.1.20.1.1.4.18.7.0 = Qkl9

[KarlJorgensen]

This was an interesting one.

Looks like there are multiple ways for the hubs to represent IPv4 addresses - despite being a known hardware/software/firmware version!?

I have just pushed what-I-believe-to-be-a-fix for this to master: 7f6447c

I would be grateful if you could retest on the latest version :-)

7f6447c

[InternalLoss]

Yep, hub info no longer errors! Although.. :P