Strange behavior with multiple virtual parameters - a bug?
Michael Ducharme
mducharme at gmail.com
Sat May 12 20:39:04 EDT 2018
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 <mducharme at gmail.com>
wrote:
> 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.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 <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/20180512/471773fb/attachment-0001.html>
More information about the Users
mailing list