FYI - I updated to the latest source and the issue vanished, so it must have been a bug that was fixed.
On Fri, Oct 6, 2017 at 12:28 PM, Michael Ducharme <[email protected]> wrote: > Bumping this - any ideas? > > On Mon, Sep 18, 2017 at 3:26 PM, Michael Ducharme <[email protected]> > wrote: > >> Hi Dan, >> >> Provided below: >> >> Extension dnsresolve.js in /usr/lib/node_modules/genieacs/config/ext: >> >> const dns = require('dns'); >> const logger = require('../../lib/logger'); >> >> function myResolver(args, callback) { >> let resaddress = 'blah'; >> >> logger.info({message: 'Looking up dns', hostname: args[0]}); >> >> dns.lookup(args[0], (err, address, family) => { >> logger.info({message: 'Setting address', result: address}); >> if (address != 'undefined') { resaddress = address; }; >> logger.info({message: 'DNS lookup complete', result: resaddress}); >> let result = { address: resaddress }; >> callback(null, result); >> }); >> } >> >> exports.resolveAddress = myResolver; >> >> >> Virtual parameter IP-CLOUD-ADDR: >> >> let serial = declare("Device.DeviceInfo.SerialNumber", {value: >> 1}).value[0]; >> let dnsresolve = ext("dnsresolve.js", "resolveAddress", serial + ". >> sn.mynetname.net"); >> >> return {writable: false, value: [dnsresolve.address, "xsd:string"]}; >> >> Virtual parameter VPN-IP: >> >> // Example: Fetch Index for VPN Interface >> let m = ''; >> let x = 'temp'; >> let foundint = false; >> let goodint = false; >> let intnames = declare( >> "Device.X_MIKROTIK_Interface.Generic.*.Name", >> {value: Date.now()}); >> let lowerlayers = declare( >> "Device.IP.Interface.*.LowerLayers", >> {value: Date.now()}); >> if (intnames.size) { >> for (let myint of intnames) { >> if (myint.value[0]=='l2tp-toronto') { >> x = myint.path.substr(0, myint.path.lastIndexOf(".")); >> foundint = true; >> break; >> } >> } >> } >> if (foundint) { >> if (lowerlayers.size) { >> for (let myint of lowerlayers) { >> if (myint.value[0]==x) { >> x = myint.path.substr(0, myint.path.lastIndexOf(".")); >> goodint = true; >> break; >> } >> } >> } >> } >> >> if (goodint) { >> let ipaddress = declare( >> x + ".IPv4Address.*.IPAddress", >> {value: Date.now()}); >> >> if (ipaddress.size) { >> for (let myaddress of ipaddress) { >> if (ipaddress.value[0]) { >> m = ipaddress.value[0]; >> break; >> } >> } >> } >> } >> >> return {writable: false, value: [m, "xsd:string"]}; >> >> Virtual parameter LOOPBACK-IP: >> >> // Example: Fetch Index for loopback Interface >> let m = ''; >> let x = 'temp'; >> let foundint = false; >> let goodint = false; >> let intnames = declare( >> "Device.X_MIKROTIK_Interface.Generic.*.Name", >> {value: Date.now()}); >> let lowerlayers = declare( >> "Device.IP.Interface.*.LowerLayers", >> {value: Date.now()}); >> if (intnames.size) { >> for (let myint of intnames) { >> if (myint.value[0]=='loopback0') { >> x = myint.path.substr(0, myint.path.lastIndexOf(".")); >> foundint = true; >> break; >> } >> } >> } >> if (foundint) { >> if (lowerlayers.size) { >> for (let myint of lowerlayers) { >> if (myint.value[0]==x) { >> x = myint.path.substr(0, myint.path.lastIndexOf(".")); >> goodint = true; >> break; >> } >> } >> } >> } >> >> if (goodint) { >> let ipaddress = declare( >> x + ".IPv4Address.*.IPAddress", >> {value: Date.now()}); >> >> if (ipaddress.size) { >> for (let myaddress of ipaddress) { >> if (ipaddress.value[0]) { >> m = ipaddress.value[0]; >> break; >> } >> } >> } >> } >> >> return {writable: false, value: [m, "xsd:string"]}; >> >> >> Relevant parts of device tree (this is from a device that has all three >> addresses being pulled and works - the devices that are putting the IP >> cloud address into the wrong field are from a device that has no >> l2tp-toronto interface and no loopback0 interface): >> >> >> - Device.DeviceInfo.SerialNumber 27OBFUSCATED >> >> >> - Device.X_MIKROTIK_Interface >> - Device.X_MIKROTIK_Interface.Generic >> - Device.X_MIKROTIK_Interface.Generic.1 >> - Device.X_MIKROTIK_Interface.Generic.1.Enable true >> - Device.X_MIKROTIK_Interface.Generic.1.Status Up >> - Device.X_MIKROTIK_Interface.Generic.1.Name l2tp-toronto >> - Device.X_MIKROTIK_Interface.Generic.1.LowerLayers >> - Device.X_MIKROTIK_Interface.Generic.2 >> - Device.X_MIKROTIK_Interface.Generic.2.Enable true >> - Device.X_MIKROTIK_Interface.Generic.2.Status Up >> - Device.X_MIKROTIK_Interface.Generic.2.Name loopback0 >> - Device.X_MIKROTIK_Interface.Generic.2.LowerLayers >> - Device.X_MIKROTIK_Interface.Generic.3 >> - Device.X_MIKROTIK_Interface.Generic.3.Enable true >> - Device.X_MIKROTIK_Interface.Generic.3.Status Down >> - Device.X_MIKROTIK_Interface.Generic.3.Name afterhours >> - Device.X_MIKROTIK_Interface.Generic.3.LowerLayers >> - Device.X_MIKROTIK_Interface.GenericNumberOfEntries 3 >> >> >> - Device.IP >> - Device.IP.Interface >> - Device.IP.Interface.1 >> - Device.IP.Interface.1.IPv4Address >> - Device.IP.Interface.1.IPv4Address.2 >> - Device.IP.Interface.1.IPv4Address.2.Enable true >> - Device.IP.Interface.1.IPv4Address.2.Status Enabled >> - Device.IP.Interface.1.IPv4Address.2.IPAddress 192.168.0.101 >> - Device.IP.Interface.1.IPv4Address.2.SubnetMask 255.255.255.0 >> - Device.IP.Interface.1.IPv4Address.2.AddressingType >> X_MIKROTIK_Dynamic >> - Device.IP.Interface.1.Enable true >> - Device.IP.Interface.1.LowerLayers Device.Ethernet.Link.1 >> - Device.IP.Interface.1.Status Up >> - Device.IP.Interface.1.IPv4AddressNumberOfEntries 1 >> - Device.IP.Interface.2 >> - Device.IP.Interface.2.IPv4Address >> - Device.IP.Interface.2.Enable true >> - Device.IP.Interface.2.LowerLayers Device.Ethernet.Link.2 >> - Device.IP.Interface.2.Status LowerLayerDown >> - Device.IP.Interface.2.IPv4AddressNumberOfEntries 0 >> - Device.IP.Interface.3 >> - Device.IP.Interface.3.IPv4Address >> - Device.IP.Interface.3.IPv4Address.24 >> - Device.IP.Interface.3.IPv4Address.24.Enable true >> - Device.IP.Interface.3.IPv4Address.24.Status Enabled >> - Device.IP.Interface.3.IPv4Address.24.IPAddress 192.168.77.251 >> - Device.IP.Interface.3.IPv4Address.24.SubnetMask 255.255.255.255 >> - Device.IP.Interface.3.IPv4Address.24.AddressingType >> X_MIKROTIK_Dynamic >> - Device.IP.Interface.3.Enable true >> - Device.IP.Interface.3.LowerLayers Device.X_MIKROTIK_Interface.Ge >> neric.1 >> - Device.IP.Interface.3.Status Up >> - Device.IP.Interface.3.IPv4AddressNumberOfEntries 1 >> - Device.IP.Interface.4 >> - Device.IP.Interface.4.IPv4Address >> - Device.IP.Interface.4.IPv4Address.1 >> - Device.IP.Interface.4.IPv4Address.1.Enable true >> - Device.IP.Interface.4.IPv4Address.1.Status Enabled >> - Device.IP.Interface.4.IPv4Address.1.IPAddress 172.16.50.255 >> - Device.IP.Interface.4.IPv4Address.1.SubnetMask 255.255.255.255 >> - Device.IP.Interface.4.IPv4Address.1.AddressingType Static >> - Device.IP.Interface.4.Enable true >> - Device.IP.Interface.4.LowerLayers Device.X_MIKROTIK_Interface.Ge >> neric.2 >> - Device.IP.Interface.4.Status Up >> - Device.IP.Interface.4.IPv4AddressNumberOfEntries 1 >> - Device.IP.Interface.5 >> - Device.IP.Interface.5.IPv4Address >> - Device.IP.Interface.5.Enable true >> - Device.IP.Interface.5.LowerLayers Device.Ethernet.Link.3 >> - Device.IP.Interface.5.Status LowerLayerDown >> - Device.IP.Interface.5.IPv4AddressNumberOfEntries 0 >> - Device.IP.Interface.6 >> - Device.IP.Interface.6.IPv4Address >> - Device.IP.Interface.6.IPv4Address.1 >> - Device.IP.Interface.6.IPv4Address.1.Enable true >> - Device.IP.Interface.6.IPv4Address.1.Status Enabled >> - Device.IP.Interface.6.IPv4Address.1.IPAddress 10.5.50.1 >> - Device.IP.Interface.6.IPv4Address.1.SubnetMask 255.255.255.0 >> - Device.IP.Interface.6.IPv4Address.1.AddressingType Static >> - Device.IP.Interface.6.Enable true >> - Device.IP.Interface.6.LowerLayers Device.Ethernet.Link.4 >> - Device.IP.Interface.6.Status LowerLayerDown >> - Device.IP.Interface.6.IPv4AddressNumberOfEntries 1 >> - Device.IP.Interface.7 >> - Device.IP.Interface.7.IPv4Address >> - Device.IP.Interface.7.IPv4Address.1 >> - Device.IP.Interface.7.IPv4Address.1.Enable true >> - Device.IP.Interface.7.IPv4Address.1.Status Enabled >> - Device.IP.Interface.7.IPv4Address.1.IPAddress 10.255.50.1 >> - Device.IP.Interface.7.IPv4Address.1.SubnetMask 255.255.255.0 >> - Device.IP.Interface.7.IPv4Address.1.AddressingType Static >> - Device.IP.Interface.7.Enable true >> - Device.IP.Interface.7.LowerLayers Device.X_MIKROTIK_Interface.Ge >> neric.3 >> - Device.IP.Interface.7.Status LowerLayerDown >> - Device.IP.Interface.7.IPv4AddressNumberOfEntries 1 >> >> >> On Mon, Sep 18, 2017 at 10:53 AM, Dan Morphis <[email protected]> wrote: >> >>> Post the code for your vparam and a trimmed down snapshot of the CPE >>> data please. >>> >>> -dan >>> >>> On Fri, Sep 15, 2017 at 4:24 PM, Michael Ducharme <[email protected]> >>> wrote: >>> >>>> I have added three virtual parameters onto some devices, which show >>>> three different IP addresses - the loopback address, a tunnel address, and >>>> the dyndns address. >>>> >>>> A few devices have blank loopback address and blank tunnel address >>>> (because they have no loopback or tunnel) and they do have the dyndns >>>> address. These devices are for some reason sometimes pulling the dyndns >>>> address into the wrong field. Each time I refresh the device it disappears >>>> from one field and reappears in another - moving back and forth between the >>>> "loopback address" field, the "tunnel address" field, and the correct >>>> dyndns address field. >>>> >>>> I thought there was a bug in my code, but I have gone through >>>> everything carefully and it looks like it is simply not possible for my >>>> code to have a bug that would cause the dyndns address to get mixed up with >>>> the others the way I have written it - the dyndns address is pulled by >>>> grabbing the serial number from the device and using dns.lookup in an >>>> external module to get the dyndns IP address. >>>> >>>> The other two (the loopback and the tunnel address) are pulled directly >>>> from the device via TR-069. Because the functions are so different, it is >>>> impossible for the device to return the dyndns address to the virtual >>>> parameter code for the loopback and tunnel address since it doesn't even >>>> provide that address directly via the TR-069 stack. >>>> >>>> Instead, it appears to be a GenieACS bug. It almost seems like GenieACS >>>> is getting the return values mixed up. It doesn't happen with all devices >>>> though - it only happens with these two that have only one out of three of >>>> the parameters on the device, and that one is the dyndns. Devices that have >>>> all three or two out of three (or none) display correctly. >>>> >>>> Could the callback somehow be returning the result to the wrong item? >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.genieacs.com/mailman/listinfo/users >>>> >>>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.genieacs.com/mailman/listinfo/users >>> >>> >> >
_______________________________________________ Users mailing list [email protected] http://lists.genieacs.com/mailman/listinfo/users
