WEBVTT 00:05.340 --> 00:07.020 So welcome back, guys. 00:07.050 --> 00:11.760 Now, in this section of the course, we will going to discuss about Netlink attributes. 00:11.790 --> 00:17.520 So, so far, we have set up a very basic netlink socket based communication between user space and 00:17.520 --> 00:18.710 kernel space. 00:18.720 --> 00:26.640 Netlink protocol require the communication parties to make use of Tlv format in order to exchange data. 00:26.670 --> 00:33.150 These tlvs are appended after the netlink message header so you can see in the below diagram we have 00:33.150 --> 00:38.320 a netlink message header and after the netlink message header we have a payload. 00:38.340 --> 00:45.630 Now netlink requires that the data which is present as payload has to be formatted in the form of discrete 00:45.660 --> 00:46.500 tlvs. 00:46.530 --> 00:52.950 In this example you can see that this payload is actually formatted in four tlvs. 00:53.580 --> 01:00.840 Now that we have already understood the concept of tlvs, each Tlv could be of variable size, right? 01:01.290 --> 01:04.230 And each unit has three parts. 01:04.230 --> 01:06.650 The type length and the value. 01:06.670 --> 01:12.760 In the netlink case, the type and the length instead of one byte each, they are two byte each. 01:12.760 --> 01:13.480 Right. 01:13.960 --> 01:20.560 So the tlv looping macro that we wrote has to be adjusted according to the type and the length field 01:20.560 --> 01:22.930 of the tlvs as two bytes. 01:23.320 --> 01:31.600 Now Netlink APIs provide us a data structure called Netlink attribute in order to define the Netlink 01:31.630 --> 01:33.310 type and the Netlink length. 01:33.340 --> 01:34.030 Right? 01:34.030 --> 01:38.290 So you can see each of these is 16 bits or two bytes each. 01:39.190 --> 01:45.670 So this is one netlink attribute where this is called length and this is called type. 01:46.330 --> 01:49.900 And each of these length and type is two bytes each. 01:49.900 --> 01:54.340 Whereas the third part of the Tlv is a value which is variable size. 01:56.800 --> 02:03.610 So you can see a very simple example Here we have a land of size 32 bytes. 02:03.610 --> 02:11.560 The code point is two and there is a value followed by another Tlv whose size is 64 bytes and the Tlv 02:11.560 --> 02:16.420 code point is three and this is the value field of this second tlv. 02:16.660 --> 02:21.400 Similarly we have this third tlv right the recipient. 02:21.430 --> 02:24.910 Now here the recipient could be user space or kernel space. 02:25.840 --> 02:30.430 The recipient needs to be programmed to how to interpret the Tlv codes. 02:30.460 --> 02:37.810 Else if the recipient do not have the knowledge regarding how to interpret a particular Tlv code, the 02:37.810 --> 02:41.890 recipient must simply skip the unknown tlv code point. 02:43.250 --> 02:49.190 So thus user space and kernel space exchange Netlink data is strictly in the below format. 02:49.220 --> 02:54.800 That is, you have the netlink message header and the payload portion of this Netlink message header 02:54.800 --> 02:57.530 is formatted in the form of tlvs. 02:57.560 --> 03:03.180 Linux kernel APIs provides us various macros to work with Netlink headers and tlvs. 03:03.200 --> 03:10.040 We shall discuss those macros directly in the programs and also note that that the netlink message could 03:10.040 --> 03:10.760 be cascaded. 03:10.760 --> 03:18.710 Message that is, we have a netlink message header followed by a set of tlvs as payload and then a brand 03:18.710 --> 03:24.410 new Netlink message header can also be appended after the payload of the first netlink message header. 03:24.440 --> 03:25.100 Right. 03:25.100 --> 03:28.580 So this is called cascading of Netlink messages. 03:28.760 --> 03:35.030 These cascaded netlink messages can also be exchanged between user space and kernel space in either 03:35.030 --> 03:35.900 direction.