View Single Post
Old November 15th, 2018   #5
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

I would encourage you to treat this like any other PID.

Check that the Header is correct (Sub StartCode/Target UID/Checksum/Message Count field etc).

Check that you support the PID (ie there is one or more situations where you WILL action a SET request or provide data to a GET request)

Check that the COMMAND class is appropriate for the current PID

Check that the FORMAT of the data (essentially the PDL) is appropriate for the supplied PID.

At this point I would either validate the DATA or issue the WRITE PROTECT dependent on the lock state you are in.

From a systems perspective it would be unhelpfull to respond with WRITE PROTECT even when the PID is unsupported or the PID is incorrectly formated. I regard WP as an error that should stop being returned if I were to legitimately unlock the device by whatever means. Having unlocked the device I would reasonably expect the request to be actioned, not replaced by another NACK message "Ha Ha you wasted your time unlocking as I dont actually support the PID"

As others have said, the LOCK mechansim was never intended to be super high security, just a simple means of reducing the probability of accidental changes being made.

Peter
prwatE120 is offline   Reply With Quote