IRM not returning error status on bad setting
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.
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 clx39.fnal.gov.acnet > node065a.fnal.gov.acnet: 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 node065a.fnal.gov.acnet > clx39.fnal.gov.acnet: 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.
#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:
\-040 NUM_BYTES_BAD 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.
unsigned short value for this status is