So welcome back, guys.
Now, in this section of the course, we will going to discuss about Netlink attributes.
So, so far, we have set up a very basic netlink socket based communication between user space and
kernel space.
Netlink protocol require the communication parties to make use of Tlv format in order to exchange data.
These tlvs are appended after the netlink message header so you can see in the below diagram we have
a netlink message header and after the netlink message header we have a payload.
Now netlink requires that the data which is present as payload has to be formatted in the form of discrete
tlvs.
In this example you can see that this payload is actually formatted in four tlvs.
Now that we have already understood the concept of tlvs, each Tlv could be of variable size, right?
And each unit has three parts.
The type length and the value.
In the netlink case, the type and the length instead of one byte each, they are two byte each.
Right.
So the tlv looping macro that we wrote has to be adjusted according to the type and the length field
of the tlvs as two bytes.
Now Netlink APIs provide us a data structure called Netlink attribute in order to define the Netlink
type and the Netlink length.
Right?
So you can see each of these is 16 bits or two bytes each.
So this is one netlink attribute where this is called length and this is called type.
And each of these length and type is two bytes each.
Whereas the third part of the Tlv is a value which is variable size.
So you can see a very simple example Here we have a land of size 32 bytes.
The code point is two and there is a value followed by another Tlv whose size is 64 bytes and the Tlv
code point is three and this is the value field of this second tlv.
Similarly we have this third tlv right the recipient.
Now here the recipient could be user space or kernel space.
The recipient needs to be programmed to how to interpret the Tlv codes.
Else if the recipient do not have the knowledge regarding how to interpret a particular Tlv code, the
recipient must simply skip the unknown tlv code point.
So thus user space and kernel space exchange Netlink data is strictly in the below format.
That is, you have the netlink message header and the payload portion of this Netlink message header
is formatted in the form of tlvs.
Linux kernel APIs provides us various macros to work with Netlink headers and tlvs.
We shall discuss those macros directly in the programs and also note that that the netlink message could
be cascaded.
Message that is, we have a netlink message header followed by a set of tlvs as payload and then a brand
new Netlink message header can also be appended after the payload of the first netlink message header.
Right.
So this is called cascading of Netlink messages.
These cascaded netlink messages can also be exchanged between user space and kernel space in either
direction.