I need to extract the MQTT topic length from the header. The topic length is variable.
The length is included in the variable header part of the MQTT header. Since I do not know the topic length beforehand, how do I proceed to extract the header so that I can perform comparisons on the header? I used varbits (used the header length provided in the packet)and they worked as far as extractions went, but comparisons are not supported.
Is there any alternative way I could extract the header?
MQTT variable header format.
Hi Paradha,
First of all, I am not proficient in MQTT and neither have I read the specification, so not sure if my thoughts do totally apply to your use case or the all cases in this protocol.
I checked a pcap file to get have to build a use case considering the packets I observed in the transaction. Let’s assume you will ONLY analyze PUBLISH messages for now. Imagine you have a packet like this:
Let’s analyze the first byte:
If you check the first 4 bits, you can get the message type. This means that you can effectively differentiate between types of messages (i.e., you can use a select clause in a parser or a table). And because this is not e text-based protocol, it seems like it could always be 4 bits to define the message type.
Apart from that, I checked three publish messages in the pcap, and they all seem to follow the same structure:
As you can see, the topic can be any of any length, but there is a way to identify the length. The third and forth byte seem to look like they are used to define the topic length. Not sure if this applies to all types of messages you want. But at least for PUBLISH messages, you can easily define that third and forth byte can be used for the purpose you explained.
Since you talk about variable size messages… they are very problematic because it forces devices to be very flexible. One header can be 1 byte or 200 bytes. So forwarding packets at line rate is very difficult if the required resources vary drastically. Variable size headers are less of a problem for software switches compared to ASIC-based switches.
If you have other types of messages that might not be valid for this case, you can always attach it or provide a link to your pcap file and others might be able to check it out.
Cheers,
Hi,
I just figured out you want to both extract the length and also extract the topic into a variable. For some reason, I thought you just wanted the topic length, not the topic “string”. I apologize for the misunderstanding 
. In general terms, variable size headers are very tricky to handle. I only remember using them in In-band Network Telemetry use cases with bmv2.
I would recommend that you limit the size of the topic. Let’s say that the topic could be 1 to 10 characters. This means that it can be 1 to 10 bytes. You could have 10 different headers(topic_1b_h, …, topic_10b_h), let’s say, with 1 field from 1 to 10 bytes. Since you can extract the topic length before you extract the topic itself (as seen in the previous post), then you can create a select statement to properly extract the topic with the appropriate header (parse_topic_1b, … , parse_topic_10b). Once you do that, you could have a table (for each of the headers) to perform the necessary actions.
You don’t necessarily need to use tables. If the header is valid, you could compare the field against any local variable or constant.
As you see, the solution I propose does not cover all cases, and you will probably never find a case that is flexible to cover all topic lengths but also be well-supported by some or many of the P4 software or hardware devices. If you prefer to have 1 to 20 byte length you can do that, but the code will become more difficult to read and the more flexible you want to be, the less likely it is to be supported by other P4 switches or devices that are not the bmv2 Simple Switch.
Cheers,