crhowell3 / open-dis-rust Goto Github PK

What is the problem this feature would solve?

The Minefield Family of PDUs is one of the last families not currently implemented in this library. To be completely compliant with the IEEE 1278.1 standard, this family must be fully implemented.

What is the feature you are proposing to solve the problem?

As with the other families, create the minefield module and implement the structs representing all of the PDUs in this PDU family.

What alternatives have you considered?

No response

What is the problem this feature would solve?

When initially implementing all the PDUs, I just input a dummy value for their size in bytes (this information is stored in the PDU header). Most of the PDUs have dynamic sizes, and even the ones that are static are probably incorrect.

What is the feature you are proposing to solve the problem?

Go through and adjust the statically sized PDUs to be the correct size, and then find a way to set sizes for PDUs that have dynamic fields. Some PDUs, as per the standard, have a fairly complex size calculation.

What alternatives have you considered?

None. This must be corrected.

What version of Open DIS Rust is running?

0.1.0-alpha.6

What platform is your computer?

Linux 6.5.6-76060506-generic x86_64 x86_64

What steps can reproduce the bug?

dat in this example is a Vec<u8>, and if I try to deserialize it, it just says Err(InvalidDISHeader), but when I deserialize without header, it deserializes as expected.

loop { 
    let dat = match conn.recv().await.unwrap();

    let mut bytes = BytesMut::from(dat.as_slice());
    let pdu_header = PduHeader::decode(&mut bytes);
    let body_data = BytesMut::from(&dat[12..]);

    match pdu_header.pdu_type {
        PduType::Transmitter => {
            // this does not work
            //let xmsn = TransmitterPdu::deserialize(bytes);

            // this *does* work
            let xmsn = TransmitterPdu::deserialize_without_header(body_data, pdu_header);
            println!("{:?}", xmsn);
            println!("{:?}", pdu_header.pdu_type);
            println!("{:?}", PduType::Transmitter);
            println!("{:?}", pdu_header);
        },
        _ => continue,
    }
}

So with

let xmsn = TransmitterPdu::deserialize(bytes);

the output is:

Err(InvalidDISHeader)
Transmitter
Transmitter
PduHeader { protocol_version: IEEE1278_1A_1998, exercise_id: 1, pdu_type: Transmitter, protocol_family: RadioCommunications, timestamp: 3066130581, length: 104, padding: 0 }

But with

let xmsn = TransmitterPdu::deserialize_without_header(body_data, pdu_header);

The output is:

Ok(TransmitterPdu { pdu_header: PduHeader { protocol_version: IEEE1278_1A_1998, exercise_id: 1, pdu_type: Transmitter, protocol_family: RadioCommunications, timestamp: 3459835265, length: 104, padding: 0 }, entity_id: EntityId { simulation_address: SimulationAddress { site_id: 50, application_id: 2 }, entity_id: 5 }, radio_id: 1, radio_entity_type: RadioEntityType { entity_kind: 7, domain: 0, country: 0, category: 0, nomenclature_version: 0, nomenclature: 0 }, transmit_state: 2, input_source: 0, padding1: 0, antenna_location: Vector3Double { x: 0.0, y: 0.0, z: 0.0 }, relative_antenna_location: Vector3Float { x: 0.0, y: 0.0, z: 0.0 }, antenna_pattern_type: 0, antenna_pattern_count: 0, frequency: 100, transmit_frequency_bandwidth: 25000.0, power: 40.0, modulation_type: ModulationType { spread_spectrum: 0, major: 0, detail: 0, system: 0 }, crypto_system: 0, crypto_key_id: 0, modulation_parameter_count: 0, padding2: 0, padding3: 0, modulation_parameter_list: [], antenna_pattern_list: [] })
Transmitter
Transmitter
PduHeader { protocol_version: IEEE1278_1A_1998, exercise_id: 1, pdu_type: Transmitter, protocol_family: RadioCommunications, timestamp: 3459835265, length: 104, padding: 0 }

What is the expected behavior?

Transmission::deserialize should be able to take a BytesMut containing a pdu and pdu header, and deserialize it into a TranssmissionPdu

What do you see instead?

Transmission::deserialize cannot take a BytesMut containing a pdu and pdu header, and deserialize it into a TranssmissionPdu

Additional information

I have also seen this exact case with SignalPdu as well. I looked at the source code and it doesn't make sense why it would fail to detect the proper pdu_type, but for some reason that is the case. Am I doing something wrong here?

What version of Open DIS Rust is running?

0.1.0-alpha.6

What platform is your computer?

Linux 6.5.6-76060506-generic x86_64 x86_64

What steps can reproduce the bug?

let sig = SignalPdu::deserialize_without_header(body_data, pdu_header);

where body_data contains a signal pdu with 16 bit pcm encoded voice audio data

The panic appears to initiate from this line:

What is the expected behavior?

To deserialize the signal pdu successfully, or at least return an error saying the parsing failed and that 16 bit encodings aren't supported

What do you see instead?

The library panics without possibility of recovery or error handling

Additional information

No response

Lots of Rust clippy issues have been flagged under security. At the time of making this issue, 208 issues have been marked by the clippy job. These should be addressed as soon as possible.

What is the problem this feature would solve?

The Logistics Family of PDUs is not fully implemented at this point. To be completely compliant with the IEEE 1278.1 standard, this family must be fully implemented.

What is the feature you are proposing to solve the problem?

Create the logistics module and implement the structs representing all of the PDUs in this PDU family.

What alternatives have you considered?

No response

What is the problem this feature would solve?

The Entity Management Family of PDUs is not fully implemented at this point. To be completely compliant with the IEEE 1278.1 standard, this family must be fully implemented.

What is the feature you are proposing to solve the problem?

Create the entity management module and implement the structs representing all of the PDUs in this PDU family.

What alternatives have you considered?

No response

What is the problem this feature would solve?

The Synthetic Environment Family of PDUs is not fully implemented at this point. To be completely compliant with the IEEE 1278.1 standard, this family must be fully implemented.

What is the feature you are proposing to solve the problem?

Create the synthetic environment module and implement the structs representing all of the PDUs in this PDU family.

What alternatives have you considered?

No response

What is the problem this feature would solve?

There is a large quantity of enumerations within this project, and at this time, their definitions are scattered throughout the various submodules. It can be confusing to the end user to know which submodule each enumeration resides in.

What is the feature you are proposing to solve the problem?

It would be beneficial to migrate those all into a central, dedicated module containing only those enums.

What alternatives have you considered?

No response

What is the problem this feature would solve?

The RadioCommunications family of PDUs have not been implemented yet. To be fully compliant with the IEEE 1278.1 standard, these must be implemented in accordance with the standard's definitions.

What is the feature you are proposing to solve the problem?

Consult the IEEE 1278.1 standard to map the definitions for the RadioCommunications family of PDUs into working, tested Rust code.

What alternatives have you considered?

No response