Closed 0xA50C1A1 closed 3 months ago
@IvanNardi @utoni Something is wrong with the CRC32 calculation function, it shouldn't be endian dependent. Do you mind if I explore this further and propose a different solution?
S390:
Header FCS: 0xea7a48ce, CRC32: 0x987f130b
X86_64:
Header FCS: 0xea7a48ce, CRC32: 0xea7a48ce
Something is wrong with the CRC32 calculation function, it shouldn't be endian dependent.
I am a little bit surprise by that, since we are already using crc in some protocols and we don't have issues on big endian...
src/lib/protocols/ethersbus.c: u_int16_t crc = ndpi_crc16_xmodem(packet->payload,packet->payload_packet_len-2);
src/lib/protocols/iec62056.c: u_int16_t fcs = le16toh(ndpi_crc16_x25(&packet->payload[1], packet->payload_packet_len-4));
src/lib/protocols/ieee-c37118.c: (crc == ndpi_crc16_ccit_false(packet->payload, packet->payload_packet_len-2)))
EDIT: maybe crc32 vs crc16?
I took a look at the crc32 code: the comment points to http://home.thep.lu.se/~bjorn/crc/crc32_fast.c which seems to be a dead link now. The "same" code seems to be available in https://github.com/DDinghoya/gcdumptool/blob/master/source/crc32_fast.c where the first comment is:
fast public domain implementation for little-endian architectures
BTW, crc32 is used only for extcap with Wireshark. If there is an endianes issue, that might explain why we didn't catch it earlier
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code
@0xA50C1A1, thank you!
Please sign (check) the below before submitting the Pull Request:
Describe changes:
The Train Real Time Data Protocol (TRDP) is a UDP/TCP-based communication protocol designed for IP networks in trains, enabling data exchange between devices such as door controls and air conditioning systems. It is standardized by the IEC under IEC 61375-2-3 and is not related to the Remote Desktop Protocol (RDP).