Bug #12696

IRM not returning error status on bad setting

Added by Richard Neswold about 4 years ago. Updated about 4 years ago.

Start date:
Due date:
% Done:


Estimated time:


Jim Smedinghoff reported problems trying to send a BASIC CONTROL command to N:TPM108. It was settable using the old DPM environment, but not with the new one. Since this is a setting, it has nothing to do with the actual DPM service since, for settings, CLIB performs the function. Charlie King recently changed CLIB to better separate the new and old DPM support. We suspected there was a bug in the setting code.

We used tcpdump to compare a working setting to the failing one and found our problem. The failed setting is shown below. Unfortunately, this bad setting packet resulted in a good ACNET status (2nd packet, offset 0x2e).

09:55:17.360000 IP > UDP, length 40
    0x0000:  4500 0044 0000 4000 4011 2c32 83e1 7827  E..D..@.@.,2..x'
    0x0010:  83e1 8e8d 1a91 1a91 0030 0eb9 0002 0000  .........0......
    0x0020:  6e09 270e 779c 193c 002e 1fc4 0028 0001  n.'.w..<.....(..
    0x0030:  0001 03a5 0304 1901 065a 000b 0000 0002  .........Z......
    0x0040:  0000 0008                                ....
09:55:17.360472 IP > UDP, length 20
    0x0000:  4500 0030 7215 0000 3f11 fb30 83e1 8e8d  E..0r...?..0....
    0x0010:  83e1 7827 1a91 1a91 001c 7622 0004 0000  ..x'......v"....
    0x0020:  6e09 270e 779c 193c 002e 1fc4 0014 0000  n.'.w..<........

If the IRM simply returned a BAD_LENGTH status, it would have greatly reduced the debugging needed to fix our problem. The IRMs need to report bad settings.


#1 Updated by Richard Neswold about 4 years ago

  • Subject changed from IRM not return error status on bad setting to IRM not returning error status on bad setting

Fix typo in subject.

#2 Updated by Mike Sliczniak about 4 years ago

What's BAD_LENGTH in hex or dec, is there a header file with these?

#3 Updated by Richard Neswold about 4 years ago

The Linac system should probably return statuses using the Linac facility code, 36. The correct status appears to be [36 -40] which, according to the documentation, states:

Invalid #bytes of data requested.
#bytes outside of range 1-5000.
#bytes requested not multiple of datum size for array case.
Invalid #bytes of setting data.
#bytes of data too large for size of setting message.

The unsigned short value for this status is -10204.

Also available in: Atom PDF