QualifierCode 0x27

[kevinherron]

We've got a customer with some oddball device that is using QualiferCode 0x27 (16-bit prefix, 8-bit count).

It's not in the "Preferred qualifier codes" or required by any conformance level, but it is valid...

Any chance this can be implemented as a feature request?

dnp3-master-tcp-client{endpoint="192.168.10.100:20000"}: APP RX - ctrl: [fir: true fin: true con: true uns: true seq: 2] func: UnsolicitedResponse iin1: [] iin2: [] ... (len = 150) decoding err: unknown qualifier: 0x27

[kevinherron]

Ooof, I prototyped this, and the amount of code and files that needed to be touched was discouraging.

QualifierCode and HeaderDetails being enums, and the current assumption that the prefix and count are always the same length being baked into the type system, really makes the changes viral.

kevin@DV-kevin ~/D/T/dnp3 (main)> git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   dnp3/codegen/src/main/scala/dev/gridio/dnp3/codegen/model/enums/protocol/QualifierCode.scala
        modified:   dnp3/codegen/src/main/scala/dev/gridio/dnp3/codegen/render/modules/PrefixedVariationModule.scala
        modified:   dnp3/src/app/app_enums.rs
        modified:   dnp3/src/app/extensions.rs
        modified:   dnp3/src/app/gen/prefixed.rs
        modified:   dnp3/src/app/parse/parser.rs
        modified:   dnp3/src/app/types.rs
        modified:   dnp3/src/master/extract.rs
        modified:   dnp3/src/master/request.rs
        modified:   dnp3/src/outstation/control/collection.rs
        modified:   dnp3/src/outstation/control/prefix.rs
        modified:   dnp3/src/outstation/database/read.rs
        modified:   dnp3/src/outstation/session.rs
        modified:   dnp3/src/outstation/tests/controls.rs
        modified:   ffi/dnp3-ffi/src/handler.rs
        modified:   ffi/dnp3-schema/src/master/read_handler.rs

[jadamcrain]

Before we look at implementing this — does the device have a configuration option to force the usage of 0x28 instead? That would be the simplest path.

If not, I believe receive-only support is feasible without touching the FFI, outstation, or write paths. We'd never emit 0x27, only permit receiving it. The parsed result would be a PrefixedVariation<u16> identical to 0x28. That should keep the scope much smaller than what you experienced.

[kevinherron]

Before we look at implementing this — does the device have a configuration option to force the usage of 0x28 instead?

I'm waiting for the support engineer to meet with the customer again to look into this, as well as get more details about the device (vendor/model/firmware etc).

[kevinherron]

It's a ProSoft PLX51-DNPS, which does seem to have configuration for this:

Customer is going to try changing the default config... I think we may not actually need anything here.

If not, I believe receive-only support is feasible without touching the FFI, outstation, or write paths. We'd never emit 0x27, only permit receiving it. The parsed result would be a PrefixedVariation identical to 0x28. That should keep the scope much smaller than what you experienced.

I gave this a shot... it does reduce the surface area to 2 files, but implementations end up with inaccurate QualifierCode in the HeaderInfo, with docs that are objectively wrong at that point:

    /**
     * 16-bit count and prefix (0x28)
     */
    COUNT_AND_PREFIX_16(6),

[jadamcrain]

Good. That's the right solution. Someone should tell Prosoft (customer?) that their default is very problematic for interop. It'll cost everyone downstream headaches with most of the DNP3 clients that exist.

We'll keep this ticket open until we know for certain this resolves the issue.

[kevinherron]

Yeah, it's literally the worst default they could have chosen - the only one not in the preferred table and not required by any conformance levels.

[jadamcrain]

No kidding. Is this product... new? I have to imagine it's relatively new b/c otherwise they'd already have received reports 20x times. This kind of leads me to believe that maybe TMW silently parses 0x27 even though they don't advertise supporting it. This device supports SAv5 and I can't imagine prosoft implementing that on their own.

The other thing is that it's just a strange setting in the first place. It doesn't make any sense b/c if the points list exceeds the 8 bit-address space or the count exceeds 8 bits, you're forced to use a 16-bit address anyway. What gets sent is more a function of what needs to be reported.