refreshObject inconsistency

1

Hi,
from a provisioning script, the following does the minimum number of getParameterNames calls:

declare("InternetGatewayDevice.WANDevice.*.WANConnectionDevice.*.WANIPConnection.*", {path: Date.now()})

How I can achieve the same thing via the API methods? In the v1.2.0 I managed to do this using:

{"name": "refreshObject", 
 "objectName": "InternetGatewayDevice.WANDevice.*.WANConnectionDevice.*.WANIPConnection."}

but on the latest version, it gives me a error:
faultCode=“script.Error” faultMessage=“Invalid parameter path”

and any other combination, just refreshes all child nodes exhaustive which is not optimal and without purpose.

2

There is no inconsistency. This is by design. Because provision scripts and the API are designed for two different scenarios. One for setting up a CPE (provision scripts), and one for getting/setting/refreshing specific values.

To accomplish the same things, you will need to do this, repeated for every instance of WANDevice:

{"name": "refreshObject", 
 "objectName": "InternetGatewayDevice.WANDevice.1.WANConnectionDevice"}

Are you in a situation where the WANIPConnection instances are changing or your code not knowing about them?

3

I’ve tried that also but on the latest version is making a lot more unnecessary requests:

Inform; cpeRequestId="107" informEvent="6 CONNECTION REQUEST" informRetryCount=0
ACS request; acsRequestId="177654754560000" acsRequestName="GetParameterNames"
ACS request; acsRequestId="177654754560001" acsRequestName="GetParameterValues"
ACS request; acsRequestId="177654754560002" acsRequestName="GetParameterValues"
ACS request; acsRequestId="177654754560003" acsRequestName="GetParameterValues"
ACS request; acsRequestId="177654754560004" acsRequestName="GetParameterValues"
ACS request; acsRequestId="177654754560005" acsRequestName="GetParameterValues"
ACS request; acsRequestId="177654754560006" acsRequestName="GetParameterValues"
ACS request; acsRequestId="177654754560007" acsRequestName="GetParameterValues"
ACS request; acsRequestId="177654754560008" acsRequestName="GetParameterValues"
ACS request; acsRequestId="177654754560009" acsRequestName="GetParameterValues"
ACS request; acsRequestId="17765475456000a" acsRequestName="GetParameterValues"
ACS request; acsRequestId="17765475456000b" acsRequestName="GetParameterValues"

From a packet capture, after I make the API call just as you said, this is the stripped “conversation”:

<cwmp:GetParameterNames>
  <ParameterPath>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.</ParameterPath>
  <NextLevel>0</NextLevel>
</cwmp:GetParameterNames>

<cwmp:GetParameterNamesResponse>
  <ParameterList SOAP-ENC:arrayType="cwmp:ParameterInfoStruct[418]">
    <ParameterInfoStruct>
      <Name>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.</Name>
      <Writable>1</Writable>
    </ParameterInfoStruct>
    <ParameterInfoStruct>
      <Name>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnectionNumberOfEntries</Name>
      <Writable>0</Writable>
    </ParameterInfoStruct>
    <ParameterInfoStruct>
      <Name>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnectionNumberOfEntries</Name>
      <Writable>0</Writable>
    </ParameterInfoStruct>
    <ParameterInfoStruct>
      <Name>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.</Name>
      <Writable>1</Writable>
    </ParameterInfoStruct>
    <ParameterInfoStruct>
      <Name>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.2.</Name>
... 1000+ more lines
</cwmp:GetParameterNamesResponse>

<cwmp:GetParameterValues>
  <ParameterNames soap-enc:arrayType="xsd:string[32]">
    <string>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.2.AddressingType</string>
    <string>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.2.AutoDisconnectTime</string>
    ... 
</cwmp:GetParameterValues>

<cwmp:GetParameterValuesResponse>
  <ParameterList SOAP-ENC:arrayType="cwmp:ParameterValueStruct[32]">
    <ParameterValueStruct>
      <Name>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.2.AddressingType</Name>
      <Value xsi:type="xsd:string">DHCP</Value>
    </ParameterValueStruct>
    ...
</cwmp:GetParameterValuesResponse>
....

I think the GetParameterNames should have NextLevel =1 and after it it should skip all the GetParameterValues RPC’s.

The problem is with all objects, the WANIPConnection was just an example … but yes, these instances could change directly on the device and I need to refresh them on demand, and I do this via API but this no longer works the way it did in the previous version I tested (v1.2.0-beta).

4

This task should do the trick:

{
    "name": "provisions",
    "provisions": [["refresh", "InternetGatewayDevice.WANDevice.*.WANConnectionDevice.*.WANIPConnection.*", 1, false, "path"]]
}

Here ‘refresh’ is a default built-in provision that accepts arguments the following arguments:

<path: string>, <seconds: number>, <refreshChildren: boolean>, <attr: string>, [<attr: string>, ...]

2 Likes
5

Hi @zaidka ,

sorry for replying to this old thread, I did try this back then but received an error (“Task name not recognized”) since I was using a older version of genieacs. But I’ve test this now on the latest branch and it throws this error in the cwmp logs:

genieacs-cwmp[23686]: 2021-05-21T11:35:57.737Z [ERROR] Uncaught exception; pid=31671 exceptionName=“TypeError”
exceptionMessage=“Cannot read property ‘add’ of undefined”
exceptionStack=“TypeError: Cannot read property ‘add’ of undefined
at c (/opt/genieacs/dist/bin/genieacs-cwmp:2:87065)
at c (/opt/genieacs/dist/bin/genieacs-cwmp:2:87513)
at c (/opt/genieacs/dist/bin/genieacs-cwmp:2:87513)
at c (/opt/genieacs/dist/bin/genieacs-cwmp:2:87513)
at c (/opt/genieacs/dist/bin/genieacs-cwmp:2:87513)
at c (/opt/genieacs/dist/bin/genieacs-cwmp:2:87513)
at c (/opt/genieacs/dist/bin/genieacs-cwmp:2:87513)
at c (/opt/genieacs/dist/bin/genieacs-cwmp:2:87513)
at /opt/genieacs/dist/bin/genieacs-cwmp:2:87551
at Qs (/opt/genieacs/dist/bin/genieacs-cwmp:2:87571)”

genieacs-cwmp[23686]: 2021-05-21T11:35:57.804Z [ERROR] Worker died; pid=31671 exitCode=0

From a packet capture on the NBI port this is the request:

POST /devices/DEVICESN/tasks/?timeout=3&connection_request HTTP/1.1
Host: 127.0.0.1:7557
Accept: */*
content-type: application/json
Content-Length: 139

{"name":"provisions","provisions":[["refresh","InternetGatewayDevice.WANDevice.*.WANConnectionDevice.*.WANIPConnection.*",1,false,"path"]]}

and this is the response I get, right before the error:

HTTP/1.1 202 Task queued but not processed
GenieACS-Version: 1.2.5+20210521105922
Content-Type: application/json
Date: Fri, 21 May 2021 11:40:42 GMT
Connection: keep-alive
Transfer-Encoding: chunked

fe
{"name":"provisions","provisions":[["refresh","InternetGatewayDevice.WANDevice.*.WANConnectionDevice.*.WANIPConnection.*",1,false,"path"]],"device":"DEVICESN","timestamp":"2021-05-21T11:40:42.852Z","_id":"60a79c3a70f30895067050c5"}
0

I’m doing it wrong? can you give me a hint where is the problem?
thank you!

6

The stack trace seems to indicate that this is a bug that has nothing to do with the structure of the task object. Can you confirm whether you installed it from npm or from source and whether you have made any potentially changes to the code?

FYI, you can pass the following environment variable to enable source map support for better stack traces:

NODE_OPTIONS=--enable-source-maps
1 Like
7

Hi Zaidka,
I’ve installed it from source and I didn’t change anything notable (I’ve run npm audit fix which just changed the version of some dependencies in the package.json and npm-shrinkwrap.json: postcss , hosted-git-info , nanoid, source-map-js).

Thank you very much for the source map hint, I din’t knew about it and enabling it helped me to spot the issue. The stack traces now pointed to the exact location from the source code:

session.ts:2294:57
session.ts:2342:9
session.ts:2342:9
session.ts:2342:9
session.ts:2342:9
session.ts:2342:9
session.ts:2342:9
session.ts:2342:9
session.ts:2352:5
session.ts:992:10

The line that triggered the error was this one:

syncState.refreshAttributes[attrName].add(currentPath);

and since the definition of refreshAttributes object didn’t contained a “path” attribute, I’ve changed the call to the NBI to use “value” instead:

{"name":"provisions","provisions":[["refresh","InternetGatewayDevice.WANDevice.*.WANConnectionDevice.*.WANIPConnection.*",1,false,"value"]]}

and now it works as expected.

Thank you!

8

Good catch! Will fix it such that something like can never cause an exception and crash the process.