Closed
Description
Is there an already existing issue for this?
- I have searched the existing issues
Expected behavior
FastDDS should gracefully handle an unknown encapsulation kind.
Current behavior
FastDDS crashes (abort) - Unexpected CDR type received:
$ ./DDSSecureHelloWorldExample subscriber
Starting
Waiting for Data, press Enter to stop the DataReader.
Subscriber matched.
terminate called after throwing an instance of 'eprosima::fastcdr::exception::BadParamException'
what(): Unexpected CDR type received in Cdr::read_encapsulation
[1] 1931236 abort ./DDSSecureHelloWorldExample subscriber
Steps to reproduce
- Run a subscriber process
- My endpoint goes through PDP and EDP with the subscriber
- When writers/readers and topic are matched, my endpoint sends the following DATA submessage to the matched subscriber:
submessageId: DATA (0x15)
Flags: 0x05, Data present, Endianness bit
octetsToNextHeader: 48
0000 0000 0000 0000 = Extra flags: 0x0000
Octets to inline QoS: 16
readerEntityId: 0x00000104 (Application-defined reader (no key): 0x000001)
writerEntityId: 0x00000103 (Application-defined writer (no key): 0x000001)
[Topic Information (from Discovery)]
writerSeqNumber: 1
serializedData
encapsulation kind: Unknown (0x00ff)
encapsulation options: 0x0000
serializedData: 000000000d0000004d65737361676520697320310000000
Note: encapsulation kind is 0xff (should have been 0x01).
Please refer to the attached tcpdump fastdds-assert.pcap.zip for further details. Packet 358 triggers this.
Fast DDS version/commit
v2.9.1
Platform/Architecture
Ubuntu Focal 20.04 amd64
Transport layer
UDPv4
Additional context
No response
XML configuration file
No response
Relevant log output
No response
Network traffic capture
No response