Classification: Bug (standards-compliance audit)
CommDExtendedLengthMsg (DF24 Comm-D ELM) derives the KE control-ELM bit (isAck) and the ND segment number (getSequenceNumber) from getDownlinkFormat(), but the base ModeSDownlinkMsg normalizes downlink_format to the constant 24 for every DF>=24 message (discarding the raw low 3 bits of the 5-bit DF octet, i.e. message bits 3-5). The DF24 reply octet 1 is DF(bits 1-2) | spare(bit 3) | KE(bit 4) | ND(bits 5-8); ND is the 4-bit Number-of-D-segment field between the KE bit and the MD field (bits 9-88). Hence ack = (getDownlinkFormat()&0x2)!=0 evaluates (24&0x2)!=0 = ALWAYS false, so an uplink-ELM acknowledgement (KE=1) is never detected; and seqno = (getDownlinkFormat()&0x1)<<3 | getFirstField() supplies 0 for the ND MSB (24&0x1=0) and only getFirstField() (message bits 6-8, i.e. the low 3 of the 4 ND bits), so ND's most-significant bit (message bit 5) is dropped and segment numbers 8-15 are misdecoded as 0-7.
- Code reference:
msgs/modes/CommDExtendedLengthMsg.java:CommDExtendedLengthMsg(ModeSDownlinkMsg):79-80 @ 94df15f
- Standard: DO-181E §2.2.14.4.19 (KE, Control, ELM — 1-bit (bit 4) downlink field that 'defines the content of the ND and MD fields in Comm-D replies, DF=24') p.85 (PDF-index p.85 = printed p.55); §2.2.14.4.23 (MD Message, Comm-D, 80-bit bits 9-88, part of DF=24) p.86 (printed p.56)
Proposed fix: Extract KE and ND from the raw first octet before the DF is collapsed to 24 (e.g. keep the original reply[0] or expose the raw DF octet): KE = bit 4 (control-ELM); ND = 4-bit field at bits 5-8. Do not derive them from getDownlinkFormat() (constant 24) or getFirstField() (only 3 bits). isAck() must reflect the KE bit; getSequenceNumber() must return the full 4-bit ND (0-15).
Filed by the automated lib1090 standards-compliance audit (run 20260715T182455Z, subject commit 94df15f, version 5.0.0-SNAPSHOT). Finding LIB1090-015. Verified against DO-260B / DO-181E / ICAO Doc 9871.
Classification: Bug (standards-compliance audit)
CommDExtendedLengthMsg (DF24 Comm-D ELM) derives the KE control-ELM bit (isAck) and the ND segment number (getSequenceNumber) from getDownlinkFormat(), but the base ModeSDownlinkMsg normalizes downlink_format to the constant 24 for every DF>=24 message (discarding the raw low 3 bits of the 5-bit DF octet, i.e. message bits 3-5). The DF24 reply octet 1 is DF(bits 1-2) | spare(bit 3) | KE(bit 4) | ND(bits 5-8); ND is the 4-bit Number-of-D-segment field between the KE bit and the MD field (bits 9-88). Hence ack = (getDownlinkFormat()&0x2)!=0 evaluates (24&0x2)!=0 = ALWAYS false, so an uplink-ELM acknowledgement (KE=1) is never detected; and seqno = (getDownlinkFormat()&0x1)<<3 | getFirstField() supplies 0 for the ND MSB (24&0x1=0) and only getFirstField() (message bits 6-8, i.e. the low 3 of the 4 ND bits), so ND's most-significant bit (message bit 5) is dropped and segment numbers 8-15 are misdecoded as 0-7.
msgs/modes/CommDExtendedLengthMsg.java:CommDExtendedLengthMsg(ModeSDownlinkMsg):79-80@94df15fProposed fix: Extract KE and ND from the raw first octet before the DF is collapsed to 24 (e.g. keep the original reply[0] or expose the raw DF octet): KE = bit 4 (control-ELM); ND = 4-bit field at bits 5-8. Do not derive them from getDownlinkFormat() (constant 24) or getFirstField() (only 3 bits). isAck() must reflect the KE bit; getSequenceNumber() must return the full 4-bit ND (0-15).
Filed by the automated lib1090 standards-compliance audit (run
20260715T182455Z, subject commit94df15f, version5.0.0-SNAPSHOT). FindingLIB1090-015. Verified against DO-260B / DO-181E / ICAO Doc 9871.