Strange behavior with multiple virtual parameters - a bug?

Michael Ducharme mducharme at gmail.com
Fri Oct 6 15:28:56 EDT 2017


Bumping this - any ideas?

On Mon, Sep 18, 2017 at 3:26 PM, Michael Ducharme <mducharme at gmail.com>
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.
>    Generic.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.
>    Generic.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.
>    Generic.3
>    - Device.IP.Interface.7.Status LowerLayerDown
>    - Device.IP.Interface.7.IPv4AddressNumberOfEntries 1
>
>
> On Mon, Sep 18, 2017 at 10:53 AM, Dan Morphis <dan at milkcarton.com> 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 <mducharme at gmail.com>
>> 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
>>> Users at lists.genieacs.com
>>> http://lists.genieacs.com/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.genieacs.com
>> http://lists.genieacs.com/mailman/listinfo/users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genieacs.com/pipermail/users/attachments/20171006/8dbd4e25/attachment-0001.html>


More information about the Users mailing list