linktypes: add DLT for MDB

[martin-kaiser]

Add a link-layer header type for the MDB (Multi-Drop Bus) protocol.

[martin-kaiser]

see the-tcpdump-group/libpcap#1213

[guyharris]

Unless I'm missing something, the length ("len") field is redundant, given that packet records in pcap and pcapng files already have "length on the medium" and "length, possibly sliced before the end" fields.

[guyharris]

So what follows the header is a block, as defined in section 2.2 "Block Format" of the version 4.3 spec?

Presumably a master-to-peripheral message block consists of either:

1. the address byte, the data bytes (if any), and the CHK byte;
2. one byte equal to 0x00 (ACK), 0xAA (RET), or 0xFF (NAK);

i.e., if it's exactly one byte long, that byte should be interpreted either as ACK, RET, NAK, or an error. Otherwise, the first byte should be interpreted as an address, the last byte should be interpreted as a checksum, and everything else (if any) is the data.

Presumably a peripheral-to-master message block consists of either:

1. the data bytes (1 or more) and the CHK byte;
2. one byte equal to 0x00 (ACK) or 0xFF (NAK);

i.e., if it's exactly one byte long, that byte should be interpreted either as ACK, NAK, or an error. Otherwise, the last byte should be interpreted as a checksum, and everything else is the data.

[guyharris]

Does an indication that a 5 ms time-out (t-response) was recognized get put into the capture, or is that implied by the lack of a response within 5 ms?

[martin-kaiser]

Unless I'm missing something, the length ("len") field is redundant, given that packet records in pcap and pcapng files already have "length on the medium" and "length, possibly sliced before the end" fields.

You're right, len is redundant. I've removed len from the pseudo-header and updated https://www.kaiser.cx/pcap-mdb.html.

[martin-kaiser]

So what follows the header is a block, as defined in section 2.2 "Block Format" of the version 4.3 spec?

Presumably a master-to-peripheral message block consists of either:

1. the address byte, the data bytes (if any), and the CHK byte;

2. one byte equal to 0x00 (ACK), 0xAA (RET), or 0xFF (NAK);

i.e., if it's exactly one byte long, that byte should be interpreted either as ACK, RET, NAK, or an error. Otherwise, the first byte should be interpreted as an address, the last byte should be interpreted as a checksum, and everything else (if any) is the data.

Exactly.

Presumably a peripheral-to-master message block consists of either:

1. the data bytes (1 or more) and the CHK byte;

2. one byte equal to 0x00 (ACK) or 0xFF (NAK);

i.e., if it's exactly one byte long, that byte should be interpreted either as ACK, NAK, or an error. Otherwise, the last byte should be interpreted as a checksum, and everything else is the data.

Yes.

For the peripheral->master direction, the dissection of the data depends on the address of the peripheral that sent the response. Each address is linked to a type and a protocol (section 2.3). Matching requests and responses is not always feasible. That's why I added a header field for the sending peripheral's address.

[martin-kaiser]

Does an indication that a 5 ms time-out (t-response) was recognized get put into the capture, or is that implied by the lack of a response within 5 ms?

There's no special indication that a response was received within the 5ms timeout.

[guyharris]

You're right, len is redundant. I've removed len from the pseudo-header

Is the header 3 bytes long now, or is it padded to a 4-byte boundary? (Either one is acceptable.)

[martin-kaiser]

You're right, len is redundant. I've removed len from the pseudo-header

Is the header 3 bytes long now, or is it padded to a 4-byte boundary? (Either one is acceptable.)

I've just removed the len byte. The header is now 2 or 3 bytes long, depending on the event.

(I don't think there is much benefit in starting the MDB payload at a 32-bit aligned position. I'm not aware of any MDB message that starts with a 32-bit field that needs proper alignment.)

[guyharris]

I don't think there is much benefit in starting the MDB payload at a 32-bit aligned position. I'm not aware of any MDB message that starts with a 32-bit field that needs proper alignment.

I suspected that was the case.