RDM respondertest crash

[R]

Hello,

While performing RDM responder test (v0.10.7), it consistently crashes with error message somewhere beyond 80% completion.

The error message is:

An error has occurred: 'Param 65535 out of range, must be one of [0, 9999]'
Traceback (most recent call last):
  File "/usr/bin/rdm_test_server.py", line 274, in _RunTests
    tests, device = runner.RunTests(test_filter, False, self._UpdateStats)
  File "/usr/local/lib/python2.7/dist-packages/ola/testing/rdm/TestRunner.py", line 339, in RunTests
    test.Run()
  File "/usr/local/lib/python2.7/dist-packages/ola/testing/rdm/ResponderTest.py", line 283, in Run
    super(ResponderTestFixture, self).Run()
  File "/usr/local/lib/python2.7/dist-packages/ola/testing/rdm/ResponderTest.py", line 211, in Run
    self.Test()
  File "/usr/local/lib/python2.7/dist-packages/ola/testing/rdm/TestDefinitions.py", line 5433, in Test
    self.SendSet(PidStore.ROOT_DEVICE, self.pid, [self.pin, self.lock_state])
  File "/usr/local/lib/python2.7/dist-packages/ola/testing/rdm/ResponderTest.py", line 496, in SendSet
    return self.SendDirectedSet(self._uid, sub_device, pid, args)
  File "/usr/local/lib/python2.7/dist-packages/ola/testing/rdm/ResponderTest.py", line 516, in SendDirectedSet
    include_frames=True)
  File "/usr/local/lib/python2.7/dist-packages/ola/RDMAPI.py", line 154, in Set
    PidStore.RDM_SET, include_frames)
  File "/usr/local/lib/python2.7/dist-packages/ola/RDMAPI.py", line 193, in _SendRequest
    data = pid.Pack(args, request_type)
  File "/usr/local/lib/python2.7/dist-packages/ola/PidStore.py", line 180, in Pack
    blob, args_used = group.Pack(args)
  File "/usr/local/lib/python2.7/dist-packages/ola/PidStore.py", line 790, in Pack
    chunk, args_consumed = atom.Pack(args[arg_offset:])
  File "/usr/local/lib/python2.7/dist-packages/ola/PidStore.py", line 366, in Pack
    (value, self._GetAllowedRanges()))
ArgsValidationError: Param 65535 out of range, must be one of [0, 9999]
Please report this bug so it can be fixed. Clicking 'Report Bug' will open a new window. You'll need to be logged into GitHub. Only the information you see here will be sent. Alternatively, if you're unwilling to register for a GitHub account, you can also report it via our Google Group https://groups.google.com/forum/#!forum/open-lighting .

I would like to find out which test fails, so that I can exclude it and get a test report.

I run the test on a raspberry Pi on two different images

1. raspberry desktop created somewhere in 2019 with github sources compiled

2. raspberry image of 2021-05-07 with ola-rdm-tests installed via apt install

Both result in same released version  0.10.7

[Simon Newton]

It's the  SetLockState test. I found it by looking what was on line  5433 of https://github.com/OpenLightingProject/ola/blob/master/tools/rdm/TestDefinitions.py .

--

---
You received this message because you are subscribed to the Google Groups "RDM Testing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rdm-testing...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rdm-testing/f345fe74-6cfc-4256-943a-c42945814678n%40googlegroups.com.

[R]

Thanks, Simon, for your quick answer.

This problem was caused by a faulty pin code hash, where get_pin returned -1. After solving that, all tests passed 100%.

Can I ask to change this out-of-range error as a test response error, instead of a test crash report popup?

Kind regards,

Robert.

[Peter Newman]

Hi Robert,

The GET LOCK_PIN PID returns an unsigned int, but I assume you mean you returned 0xFFFF (indeed the error message confirms this)? Or certainly not 0x0000-0x270F (i.e. 0000-9999).

It looks like we currently don't (by default) validate the data returned from a lot of those fairly generic checks (where we're mostly just testing if GET works), we're then using your (incorrectly) returned lock PIN value to try and change the lock state, at which point OLA is complaining that a lock PIN of 65535 isn't valid and everything crashes.

I assume this was just a bug within your code returning an uninitialised PIN? If you're actually trying to stop access, then from the standard:
"Some devices may disallow getting the current PIN code using this message. For devices that protect against the RDM Controller retrieving the current PIN code, any GET_COMMAND messages shall send a NACK with a NACK Reason of NR_UNSUPPORTED_COMMAND_CLASS."

We'll look at getting this fixed soon anyway (and hopefully testing that every returned get value is in range).

[robertluursema]

Peter,

Indeed, your assumptions are correct. 

On my part it was an data corruption error where internal get pin function returned an error. It should not happen in released products, thats why we test.  It was not an attempt to block access. When in unlocked state, the pin code is visible to the user, as intended by the standard. 

The function of the pin code is there so that the end user or installer has the ability to block unintentional change or tampering of settings. It is not a security feature.

Its great that you may find the time to enhance the tests so that it keeps growing.

Keep up the good work.

Robert.

-------- Oorspronkelijk bericht --------

Van: Peter Newman <peterj...@gmail.com>

Datum: 18-07-21 16:22 (GMT+01:00)

Aan: RDM Testing <rdm-t...@googlegroups.com>

Onderwerp: Re: [rdm-testing] RDM respondertest crash

You received this message because you are subscribed to a topic in the Google Groups "RDM Testing" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rdm-testing/IN6qHcPaquc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rdm-testing...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rdm-testing/2912639d-8ecf-4b38-ab9f-8421a4d625a0n%40googlegroups.com.