Refreshing WANIPConnection.* values does not return objects

1

Strange behaviour results in GetParameterNames request NOT returning all items (values & sub-objects).
More specifically, “simple” parameters (values) were returned, objects under WANIPConnection.x were NOT.

After inspecting debug log more closely, issue narrowed down to NextLevel option in request was set to 0 (zero).

<soap-env:Body><cwmp:GetParameterNames><ParameterPath>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.3.</ParameterPath><NextLevel>0</NextLevel></cwmp:GetParameterNames></soap-env:Body>

After identifying where “NextLevel” is being set (lib/session.ts), a variable pop-ed up, GPN_NEXT_LEVEL.

Its default value is 0, which can today be set via Config by adding cwmp.gpnNextLevel. After setting this config variable to a “larger number”, refreshing above path started to work OK.

We have multiple GenieACS running for multiple testing installs and ONLY ONE was presenting this issue. Originally running GenieACS 1.2.3, swithced first to 1.2.5 (GIT pull) and finally to the latest 1.2.8 code, with no changes. Only after setting cwmp**.**gpnNextLevel to 2048 , functionality was restored.

Is this a bug or a feature?

The refresh command always returned ALL the values, but LEFT OUT all the OBJECTS under this path.

This is the code in ‘lib/session.ts’ where we found the possible cause of our issue:
(starting line 1636):

    if (path) {
      let nextLevel: boolean;
      let est = 0;
      if (path.length >= GPN_NEXT_LEVEL) {
        const patterns: [Path, number][] = [[path, 0]];
        for (const p of sessionContext.deviceData.paths.find(
          path,
          true,
          false,
          99
        )) {
          const v = syncState.gpnPatterns.get(p);
          if (v) patterns.push([p, (v >> path.length) << path.length]);
        }
        est = estimateGpnCount(patterns);
      }

      if (est < Math.pow(2, Math.max(0, 8 - path.length))) {
        nextLevel = true;
        syncState.gpn.delete(path);
      } else {
        nextLevel = false;
        for (const p of sessionContext.deviceData.paths.find(
          path,
          false,
          true,
          99
        ))
          syncState.gpn.delete(p);
      }

      return {
        name: "GetParameterNames",
        parameterPath: path.length ? path.toString() + "." : "",
        nextLevel: nextLevel,
      };

Environment on all installations was practically the same.

Any thoughts?

Regards,
Robert.

2

I believe this is by design to prevent pulling back more data than necessary.

3

Well, the problem is that only ONE install has (ok, had) this issue.

Not being able to identify why, all other have same default settings. All installs are based on Debian 10, the only difference are nodejs versions, 12.22.1, 14.17.5, 16.13.0.
Problems presented in 14.17.5.

GenieACS was all kind of versions, between latest 1.2.3 and then up to lastest 1.2.8. All configs with same basic settings.

After locating the code that decides whether to retrieve “nextLevel” (to process sub-objects), I stumbled upon GPN_NEXT_LEVEL check (which is (was) 0 in all versions), and after setting it to larger number (2048), the “problematic install” started working as expected (in lib/session.ts).

This was not preventing pulling back “minimal” data, as it was “breaking” the basic updates.

Maybe has something to do with implementation on the CPE itself, but main issue is that is does not work the same on the same GenieACS code. THAT is the main issue.

It broke provisioning, as CPE never returned “objects” on a specific paths. Only “non-objects”. And therefore it broke provisioning script.

Anyhow, found a workaround, but would like to know what is the actual cause of this.

:frowning: